Ref : KER3-NOT-HEALTHLAB-SCOPE-20131107-EPU

Scope of the accreditation

Standards

• ANSI/HL7 CDA R2-2005 (ISO/HL7 27932:2009)
• ANSI/HL7 V2.x
• OASIS
• CEN/ISO EN 13606
• ISO-TS 15000

IHE Profiles

• XDS.b (Cross-Enterprise Document Sharing)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 10 - Cross-Enterprise Document Sharing (XDS.b)
• XDS-MS (Cross-Enterprise Document Sharing - Medical Summaries)
• http://ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol1.pdf, Section 3 - Cross-Enterprise Sharing of Medical Summaries (XDS-MS)
• XDS-SD (Cross-Enterprise Sharing of Scanned Document)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 20 - Cross-Enterprise Sharing of Scanned Document content integration profile
• ATNA (Audit Trail and Node Authentication)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 9 - Audit Trail and Node Authentication (ATNA)
• CT (Consistent Time)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 7 - Consistent Time (CT)
• PIX (Patient Identity Cross-Referencing)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 5 - Patient Identity Cross-Referencing (PIX)
• PDQ (Patient Demographics Query)
• http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, Section 8 - Patient Demographics Query (PDQ)

Normative methods

eHealth Conformance Interoperability Assessment Scheme

• HITCH (Healthcare Interoperability Testing and Conformance Harmonisation)
• http://www.hitch-project.eu

Effective date : 11/07/2013

Approved by Eric POISEAU

• Edit page
• The contributor must log on for the "Edit" function pages.
• Once editing is complete, the status of the page is changed from "Draft" to "To be reviewed" by the author.
• In case of modification of a page already approved, the contributor is allowed to keep the status approved, in case of minor modification (e.g.: format) but he/she must make the approver aware of the modification.  
• Validation
• The author asks for a validation from the Health Lab Manager or from the quality manager, depending in the type of subjects.
• The manager can thus change the status : "to be reviewed", "rejected", "approved" or "deprecated".
• Disseminate the publication
• Once a publication is made, the contributor must send an email to make the team aware of the availability of new information on ihe@kereval.com. It is also possible for readers to subscribe to the Drupal site based on RSS feeds.
• Traceability
• Traceability of changes made page per page is only visible for the team KEREVAL and administrator.
  The information is drawn through the "Track" module for any changes, while change status follow-up is drawn through the "Workflow" module.

Actors & Roles

General roles

 Test Session

Test Tools Development

Organization of KEREVAL Health Lab

Test Tools interactions

Test Tools Lifecycle

• Lifecycle of a Test Tool
  

Development & Validation

Objectives

• Manage evolution and maintenance of KEREVAL HEALTH Lab platform

Validation tools

• XML Based Validators development and validation process
• Gazelle HL7 Validator development and validation process

Simulation tools

• Simulators development and validation process

Test management tool

• Test Management development and validation process

Support Tools

• Gazelle Proxy
• EVS Client

Tool release management

• Test Tools Delivery Process

Gap Analysis

A watch is kept on the evolution of our references.

When a reference evolves, impact analysis is performed by the Lab Manager to determine possible changes.

Following this analysis, one (or more) ticket (s) is created in JIRA to take these changes into account.

These changes are then included in the traditional development process of testing tools.

Test Strategy applied to test tools

• Introduction

The purpose of this section is to present the test strategy and KEREVAL Health test Lab approach.

This section takes into account the comprehensive approach to Project Management in the IHE group and applies to any project portfolio IHE.

Test strategy describes in an organization all the activities and methods of conducting activities verification and validation in a project to ensure:

• The objectives addressed by the project
• Lack of critical regression system
• Compliance with the specifications
• Compliance with the quality
• Robustness of the system

It defines the test phases, tasks and deliverables, roles and responsibilities of different stakeholders, manage the coordination of actors and the sequence of tasks.

ISTQB advocates that it is not possible to test everything, and test strategy is based on the analysis of risks and priorities to focus testing efforts.

•  Test Strategy applied to test tools

Test Session Management

Objectives

• Prepare Test Session in order to be successful

Processes

• 01 - Preparation
• 02 - Execution
• 03 - Reporting

Tools

• The Gazelle Test Management tool provides the user with the ability to define a jasper report to generate a contract for the participation to the testing session. The contract is then generated based on the content of the template, and can be customized accordingly (link to sample generated contract)

Objectives

Ensure adequation between required skills and availalble skills to endorse specific roles in KEREVAL Health lab. Identify nominatively who is allowed to play this role.

Qualified roles

The Laboratory Chart identifies roles for which qualification is required.

For a test session

The required level of skills (knowledge and experience) is established by the Lab manager. He is then in charge of analysing, assessing and qualifying candidates for a role on the basis of their autodeclaration.

A candidate is then qualified with an assessed level : With Coaching, Autonomous, Expert. With Coaching means that the candidate can act within his/her role, but with an expert coaching.

Qualification is valid for one test session.

Test session manager

A test session manager is a resource acting on the behalf of KEREVAL Health Lab. 

He/she must be ISTQB fondation certified, autonomous on this job, autonomous on skills in all Health test tools domain and IHE standards.

Monitor

A monitor is a resource acting on the behalf of KEREVAL Health Lab.

Monitors are recruited within KEREVAL team for on-line testing session, but can be recruited outside KEREVAL team for mobile testing session (see connectathon monitor's documentation).  They must fill in a form with their skills (e.g. : monitor's form for Bern Connectathon). Independance and potential conflict of interest are checked.

SUT operator

SUT operators must be qualified to take part to a test session covered by the accreditation: they must have good knowledge and sufficient experience to be autonomous on SUT, IHE and Test tools.

Knowledge and experience are collected before such a test session.

Other roles involved in KEREVAL Health Lab

The required level of skills is established on the basis of KEREVAL experience related to other labs. Skills for lab manager, his substitue and auditors are assessed compared with established criteria.

Qualification is valid for one year.

Note : Lab Manager and substitute : they are the only ones allowed to sign test reports

 The table above is valid from 2013-11-04, and for one year.

This process is inspired from SCRUM, an agile project management method, where the Scrummaster is the test tools development project manager.

This process is largely tooled, based on Jira.

Quality of KEREVAL HEalth Lab activities is continously monitored with 3 main tools :

Management of non-conforming Works

or how to detect eventual non-conforming works, identify impacts on our test results and take appropriate decisions.

KPI monitoring

or how to follow and monitor Key Performance Indicators and warnings on committments of the lab, test activities, on level of resoruces...

KPI are defined in the contract with the customer of the lab, IHE-EUrope.

On a monthly basis, Quality engineer is in charge of collecting and reporting these KPI. The lab manager gives his/her analysis.

In case of major findings between planned and actual data, actions could be taken either with IHE-Europe, or internally at the top level management of KEREVAL.

References monitoring

or how to ensure that the lab will always use the up-to-date and applcable reference in terms of testing.

The lab and its staff commit themselves to always use the correct version of applicable methods and reference material related to tested profiles.

The lab manager is always aware of any modification concerning tested profiles.

General references of methods ([GITB], [HITCH], [17025], [ISTQB]) are always checked as input of Quality committee.

In case of modification of one of these references, an impact analysis is performed by the quality Manager and/or the Lab manager, in order to decide appropriate actions to take into account these modifications (process modification, new training, new qualification...).

Abbrevations

• CAT : Connectathon 

• CDA : Clinical Document Architecture

• EVS : External Validation Services 

• IHE : Integrating the Healthcare Enterprise 

• PAT : Projectathon

• PDT : Test Plan

• SUT : System Under Test 

• TM : Test Management 

• XDS : Cross Enterprise Document Sharing

Glossary

•  Benchmark Test : A standard against which measurements or comparisons can be made. A test that is be used to compare components or systems to each other or to a standard
•  Beta testing  : Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a compone nt or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing in order to acquire feedback from the market
•  Black box testing : Testing, either functional or non-functional, without reference to the internal structure of the component or system
•  Black box test design techniques : Documented procedure to derive and select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure
•  Blocked test case : A test case that cannot be executed because the preconditions for its execution are not fulfilled 

•  Certification : The process of confirming that a component, system or person complies with its specified requirements, e.g. by passing an exam
•  Code coverage : An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage 
•  Compliance : The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions
•  Component : A minimal software item that can be tested in isolation
•  Coverage : The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite

•  Defect : A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system
•  Driver : A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system
•  Dynamic analysis : The process of evaluating behavior, e.g. memory performance, CPU usage, of a system or component during execution 
•  Dynamic testing : Testing that involves the execution of the software of a component or system 

•  Exit criteria : The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used by testing to report against and to plan when to stop testing 
• Expected result : he behavior predicted by the specification, or another source, of the component or system under specified conditions  

•  Fail : A test is deemed to fail if its actual result does not match its expected result 
•  Failure : Actual deviation of the component or system from its expected delivery, service or result. [After Fenton] The inability of a system or system component to perform a required function within specified limits. A failure may be produced when a fault is encountered 
• Functional requirement : A requirement that specifies a function that a component or system must perform  

•  Impact analysis : The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements 
•  Incident : Any event occurring during testing that requires investigation 
•  Interoperability : The capability of the software product to interact with one or more specified components or systems 

• Non-functional requirement : A requirement that does not relate to functionality, but to attributes of such as reliability, efficiency, usability, maintainability and portability 

•  Pass : A test is deemed to pass if its actual result matches its expected result 
•  Precondition : Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure  

•  Requirement : condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document 

•  Simulator : A device, computer program or system used during testing, which behaves or operates like a given system when provided with a set of controlled inputs 
•  Static analysis : Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out by means of a supporting tool
•  Stub : A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component 

•  Test case : A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement 
•  Test condition : An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, quality attribute, or structural element 
•  Test level : A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test
•  Test strategy : A high-level document defining the test levels to be performed and the testing within those levels for a programme (one or more projects) 

• Use case : A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system 

•  Validation : Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled
•  Verification : Confirmation by examination and through the provision of objective evidence  that specified requirements have been fulfilled

• White box test design technique : Documented procedure to derive and select test cases based on an analysis of the internal structure of a component or system