Cross-UK and International ehealth Systems Interoperability Approaches to Accreditation and Testing Welcome Ed Conley, SW AHSN

Transcription

1 Cross-UK and International ehealth Systems Interoperability Approaches to Accreditation and Testing Welcome Ed Conley, SW AHSN

2 Theme: UK ehealth Interoperability

3 Theme: International ehealth Interoperability UK Dissemination

4 Theme: Satisfying Future UK Demand Listening to Audience Lyn Whitfield, ehealth Insider as we go along 1. JOT DOWN comments to inform Lyn s debate 2. Think about any provocative comments

5 and finally

6 Housekeeping No fire drill planned / facilities Certificates of Attendance Exhibitors

7 Cross-UK and International ehealth Systems Interoperability Approaches to Accreditation and Testing Chair: Roger Wallhouse IHE-UK

8 ehealth Systems Interoperability the role of standards Indi Singh April 2014 Building choice of high quality support for commissioners 8

9 A People Powered Health & Care System Good Data Open Outcomes Transparency Participation Interoperability Patient in control Active Citizenship

10 Future Vision Empowered patients Vibrant Supplier Market Open API IT Suppliers Secure linking of e-health & care records Individualcentred 8,000 GP Practices Apps and tools GPSoC extension Summary Care Record GP2GP Encourage innovation

11 Patient Pathway not care setting Social Care Community Care Primary Care Acute Care Urgent Care Can t look at one care setting in isolation

12 What the benefits.. Safety Patient Experience Clinical Effectiveness

13 The Integrated Digital Care Record - Vision Safer Wards/Safer Hospitals outlines the vision for the Integrated Digital Care Record: In order for the NHS to provide high quality and effective care for all, information must flow both within health organisations and across boundaries into social care, allowing vital data to follow patients through their care pathways. Patients and citizens must also be able to access and use this data their data whenever they wish. Need to move from vision into the underpinning architecture to support this

14 Integrated Digital Care Record Safe, digital record keeping 500m Technology Fund NHS Number as primary identifier Use of Open APIs Underpinned by Interoperability Standards Integrated Digital Care Records are a prerequisite for integrated care

15 The Architecture for Interoperability Use interfaces to be able to push information between system. Ability to push information between care settings through Open APIs But in addition, use of local information exchanges and portals to locate and retrieve as needed (and if needed potentially how these are linked on a national basis) The ability to locate and retrieve information from across care settings The ability to locate and retrieve information across organisations

16 Interoperability not just a technical concept Standard Record Headings CDGRS Standard Data Elements Standard Terminology Meds. Allergies SNOMED Data Implementation Standards Message Transport Standards CDA SOAP RESTful Need to look at interoperability as a whole: Enterprise Architecture Business, Information & Technical Architecture

17 Who benefits Clinicians Industry Patient Multiple beneficiaries of taking an interoperability approach Interoperability is underpinning building block NHS Number Open APIs Interoperability Standards

18 Logical Architecture - PHR Patient access online services through GP system patient portal or app Patient portal Patient portal GP Clinical systems Patient portal Acute Clinical Systems app Social Care app GP system APIs Clinician app PHR app Patient provides information into a PHR associated with clinical information sourced from multiple points app app app app Secure transmission to user Carer can access patient information and also enter information Secure transmission to clinical system Clinician 18

19 Next Waves of Technological Revolution Big Data and Pharma Nanotechnology Stratified Medicine Genomics mhealth But to realise this potential need data to flow across information systems Interoperability is underpinning building block

20 Focus on use of standards but.. APPROPRIATE STANDARDS e.g. use of FHIR for PHR e.g. use of CDA for Document Exchange Need BOTH BUT FOR DIFFERENT THINGS! WHAT PRIORITY FOR NOW? Clinical headings Less on the transport? What is already out there! - CDA, FHIR, IHE XDS But most importantly - EA What are the business drivers? What are the Information flows? BEFORE jumping to technology answers!

21 Summary.. Benefit now and in the future with focus on interoperability Benefit to patients, clinicians and industry Don t re-invent but re-use Start with the business need and determine what s relevant (as opposed to just interesting!) Open Source: #NHSOpenSource

22

23 Cross-UK and International ehealth Systems Interoperability Approaches to Assurance and Accreditation for the NHS (England) Presented by Richard Dobson HSCIC, Operation and Technical Services Directorate 23

24 Introduction Richard Dobson - Assurance Manager within HSCIC Solution Assurance HSCIC Interoperability Toolkit initiative (ITK) Interop Strategy accreditation/assurance perspective

25 HSCIC Setup April Executive Non Departmental Public Body The HSCIC responsibilities have been set out within the Health and Social Care Act 2012

26 HSCIC Strategic Themes Support for Patient Centric pathways of care using technology as a unifying force Data providing Information and Knowledge which must be recorded and shared Focus on social care and community services Greater integration of services Underpinned by Interoperability

27 Challenges Shift towards locally held and controlled records brings a number of challenges Information Consistency Locating Information Retrieving Information Managing Changes Knowing when things change

28 Data Standards HSCIC deliver Data Standards HL7v2 and HL7v3 (MIM), and HL7v3 CDA HL7 UK board membership HL7 FHIR working groups RCP Standards Adoption - CDGRS

29 Local Interoperable Solutions Interoperability Toolkit (ITK) launched in 2010 XML, HL7, Web Services,. National Specifications using HL7 at the heart Focused on the push pattern Mapping to Antilope ALT Model: Technical Level (explicit), Logical Level (partly), Application level (guidance) ITK Accreditation forms part of the offering

30 ITK Accreditation - Test Tooling Testing tool ITK Toolkit Workbench (TKW) which is open source Supplier selects Profile and Transport e.g. Discharge Summary over Web Services Automated test suite based around prescribed test plan Generates evidence of technical conformance

31 ITK Accreditation Service provided by HSCIC Over 60 accredited systems ITK Accredited Systems Accredited Systems CDA Correspondence HL7v2 ADT SMSP Others (HL7 v3)

32 Challenges Local Integration Driver for Adoption NHS marketing drive to push adoption through procurement 2013 Information Challenge Sharing Fund Technology Fund 2 (standards adoption)

33 National Services - Contrast with Local Greater Emphasis on IG and Security Programme Requirements Prescriptive technical integration (HL7v3, ebxml, Web Services) The Assurance Balancing Act Integration Time Assurance

34 Changing Face of Assurance The NHS e-referral System (e-rs) will replace Choose and Book this year New API will be exposed, heavily influenced by HL7 FHIR New assurance approach being developed as part of an overall e-rs ecosystem

35 NHS e-rs Ecosystem Components

36 CERTIFIED SOLUTION NHS e-rs API Ecosystem Journey EXPLORE ASSURE DEVELOP

37 Thank You HSCIC Interoperability TRUD (ITK Specifications) ITK Accreditation Catalogue Contact NHS Developer Network

38

39 Strategy, standards and progress Gary Bullock April 30th 2014

40 3bn Budget 3,000,000 Patients 81,000 Staff 15,000 Beds 400 GP Practices 135 Hospitals 7 1 Assembly 3 Trusts LHBs

41 The Challenges of NHS Wales The Challenges of NHS Fewer specialist Severe financial Wales service hospitals pressures from austerity Difficulties finding appropriately qualified staff Specialist services lacking critical mass Major reconfiguration Community /social care integration Crossorganisational boundaries

42 Ageing Poulation v Funding The Challenges of NHS Wales

43 Distinct Welsh Informatics Programme Elements Distinctively Welsh Informatics Programme Informing Healthcare Strategy National information services for local use - Incremental by design - Corporate not central - Engagement and persuasion - Led by service transformation not technology National leadership - programme management and funding NHS Wales Informatics Service Governance - integrates national and local organisations together

44 Technology Principles Incremental by design Remain valid in the face of services redesign Permits differing organisational priorities during migration To enable interoperability Pragmatic use of standards

45 National Architecture Service-oriented Interoperability key factor - business functions as services Service messages as well as defined payloads can be consumed by participating systems Messaging Fabric at the heart of the architecture Synchronous and asynchronous message based integration Technical standards, documentation and guidance Governance and assurance 45

46 Core Architecture Services User Identity and Authentication (NADEX) Patient Identity (MPI) National Reference Data Service Providing access to the Patient s Records Providing users with a single application experience Transfer care between staff and organisations Alerts and warnings service Access to schedules and care plans National Audit Services Welsh Care Record Service

47 Viewing records WCRS Registry Welsh Clinical Portal Repository Documents and Records indexed in WCRS Registry File Shares Clinical System Databases LHB Scanned Documents Copy Documents also written to WCRS Repository if required

48 National component Architecture National Alerts and Notifications service National Reference Data Service Welsh Care Record Service Maternity MPI GP Systems Primary care requesting Child Health Community Individual Health Record Integration Services PAS Other Clinical systems Structured/Unstructured Documents WCP screen NADEX A&E Another application screen WCP Requests, Results, Meds & others

49 LIMS Interoperability Architecture Intersystems Pathology application (Intersystems TRAKcare) Legacy CSC and Masterlab Lab Systems Master Patient Index (MPI) via IBM Initiate Patient Record/Report Viewing systems via the Welsh Clinical Portal Test requesting and results reporting repository Pathology catalogue and rules engine (Wales Pathology Handbook)

50 LIMS Interoperability Architecture diagram MPI TrakCar e MasterLa b LIMS systems Telepath Patient context established via PDQ web service Generate OUL R22 result message and route to repository WCP Pathology catalogue Web service WPH Generate OML O33 Order Message and route to LIMS Requests and Results Repository Write to repository Raise order web service

51 XDS Image Sharing Architecture RADIS RIS Fuji PACS Synapse XDS Registry/Repository ACUO/Perceptive Vendor Neutral Archive ACUO/Perceptive Master Patient Index (MPI) IBM Initiate Patient Record/Report Viewing systems Welsh Clinical Portal (WCP)

52 MPI PIX Query LHB 1 RIS Requests and Reports Reports WCP Requests & Results Repository EID registrations and merges A28, A40 PIX Query LHB 2 XDS Requests and Reports Registry Patient Registrations/Updates Requests and Reports PACS Patient Registrations, merges and Updates A28, A40, A31 Images ID updates/ merges Vendor Neutral Archive (VNA) RIS Patient Registrations/Updates Requests and Reports Images PACS WCP Requests & Results Repository Reports Patient Registrations, merges and Updates A28, A40, A31

53 Conclusion Use the right standards Often standardisation is good enough pragmatism Integrate within an architecture and technical platform Publishing NHS Wales Interoperability toolkit (the SDK) We have evidence of success! This is a long term journey and requires strong leadership

54

55 Northern Ireland Desmond O Loan Head of Strategy, Design & Programme Control Health & Social Care Board, Belfast Information for better, safer, faster care

56 N.I Interoperability Background to N. Ireland Strategic challenges and direction Integration Current successes Future plans Information for better, safer, faster care

57 Background to N. Ireland Background Self governing region 1.8m population 4b health budget Health department Health Board Six Hospital groups Integrated Health & Social Care General Practice Private Dentist, Pharmacy, Optometrists Voluntary & Commercial sector Transforming Your Care reform programme Information for better, safer, faster care

58 Strategic challenge Fragmented record... Information for better, safer, faster care

59 Strategic design; One virtual patient/client record Information for better, safer, faster care

60 CORE ECR CORE DATA ITEMS Lab Results GP Practice Detail Demographics & ID s Meds & Med History Clinical Documents Diagnosis Rad reports & results Encounters Special Factors & Problem List Alerts & Allergies

61 Systems Integration Patient Administration Systems x 8 Laboratory x 6 PACS x 3 RIS x 3 Emergency Department systems x General Practice x 360 GP OOH Messages x 4 GP Electronic Referrals x 1 Cancer Tracking x 1 In/ Out/ Day/ Result letters Social Care systems x 6 (PARIS, Socare, LCID) RVH, Children s EPEX (NT Mental Health) Cardiology (TTE and TOE/MDM Forms) Orthopaedics Electronic Document management Maternity system x 7 Prescribing Tele monitoring Tele Health Cardiology x 3 Information for better, safer, faster care

62 Challenges and Barriers How was NIECR achieved Political, Vision, Clinically lead No ripe and Replace Clinical leadership Testing critical First mistake = setback Record structure information Business as usually gets in way, No spare time Limited resources EU funds helpful, hard to get. Information for better, safer, faster care

63 Interfaces Additional interfaces over time CORE Data Items Information for better, safer, faster care

64 Where next ECR Integration Projects Diabetes PAS Pre-Admissions OP/IP Waiting Lists Infection Control Information Emed Renal COIS Historical Reports Endoscopy Reports Theatre Management System enisat Remote Telemonitoring Stroke System Blood Transfusion Information for better, safer, faster care

65 More functionality Short Term Future Functionality Flowsheets Shared Worklists Alerts & Notifications eforms Pre-Operative assessment, MUST, EWS Patient Handover Add Document Function Alert Document Template Shared Integrated Care Plans Referral Triage Management Solution Key Information Summary Results sign Off Information for better, safer, faster care

66 More functionality Medium and Long term Future eprescribing Immediate Discharge Letters Order Communications Patient Portal Business Intelligence tools to support more informed decisions in treatment and care planning Clinical Workflow Suite (Forms technology for Chronic Disease Management) Mobile applications for specific workflows to improve efficiency and access to information (sign-off, patient drugs) Information for better, safer, faster care

67 Framework Integration Framework Clinical Users Security Layer Authentication Security Patients Audit Logs Authentication Security Application Layer Audit Logs... Generic Search Data Integration Layer CDV Problem List Integration Engine Case Mgmt Orders Existing Systems... PAS PACS Laboratory Radiology Clinical Portal Patient Portal Orion Health Third Party Rhapsody CDR Clinical Data Repository Existing Systems Clinical Portal Patient Portal ECS Information for better, safer, faster care

68 NI Electronic Care Record Regional solution live since July 4th ,000 Unique Patients Accessed 950,000 accesses to Patient Records 195 Million Messages Stored 2 million patient centre documents accessed 13,000 Drug Accesses per week 100,000 Print Requests 250,000 Radiology Reports Viewed 3.3 million Cumulated Laboratory results 1250 ereferrals per week Information for better, safer, faster care

69 ECR usage Information for better, safer, faster care

70 Methods and tools Message types Propriety, HL7, CSC, Methods Real Time Transactional Push, Pull, Batch Integration brokers Rhapsody, Clover Leaf Record Matching Enterprise Master Patient Index Information for better, safer, faster care

71 Future Integration Private sector Two way Different applications Apps ( IOS, Android) Commercial and HSC Security Authentication Data security Connected Health Interoperability Platform New York NI Ecosystem Information for better, safer, faster care

72 N. Ireland Summary Strategic vision and determination Country wide ECR Continuous Integration Interoperability CHIP ROI, New York Success 10,00 users in 10 months Information for better, safer, faster care

73 Coffee Break 20 min

74 Why International ehealth Standards? Ian Hay IMT/OLN/OLNC/SED 30th April 2014

75 Orange Healthcare objectives: for joining up healthcare modernize the healthcare infrastructure and equip healthcare facilities with communications solutions connected medicine for management of healthcare information expertise in communications to enable healthcare professionals to increase patient comfort and peace of mind

76 Developing healthcare ICT solutions in 3 areas Services for professionals Remote monitoring Preventive services Professionalsto-professionals Professionalsto-patients Patient Infrastructure for coordination, collaboration, and information flow Patients keep in touch with healthcare professionals Sharing of medical images Remote cardiac monitoring improve prevention by self-management Drug authentication

77 Working with recognized leaders Manufacturers Elite schools Professionals International Alliances

78 Growth of Health & GSM 1983 FCC Approves First Cellular Phone GSM Over 1M UK customers launch GSM USA Launch SMS interop 5bn one month 2002 SMS 400bn in one year 7 BILLION bn customers 1tr SMS 3bn customers 2tr SMS HL7 launched HL7 ANSI Accredited IHE launched Orange Healthcare launched bn customers bn customers Continua 1st guidelines Released launched 3rd guidelines Released GSM Association founded in same year as HL7 (1987) 3GPP launched in same year as IHE (1998) Similar start dates different adoption rates 78 78

79 Some Perspective: Early days easily forgotten Remember? 1982: A phone for $4,000 for just a few voice calls? Unable to contact friends on Voda when you were Cellnet

80 What I used to do

81 Good ideas can take time

82 Adopting a common (sense) standard COMMON USB TERMINAL COMMON POWER SUPPLY COMMON USB CABLE

83 Standards Landscape Standards Landscape There are (too) many standards to choose from: Variations on a theme with many interpretations Everyone agrees on the need for them but the lack of them is often cited as a barrier 83 83

84 Many ways to implement Everyone has their personal favourite

85 Perception The way in which something is regarded, understood, or interpreted

86 What people think standards people do

87 Corporate tourists

88 In reality meanwhile

89 Challenge a call to prove or justify something

90 Too much Legacy equipment

91 Security Security is critical Orange presentation is Key

92 Common Interfaces in Continua HEALTH RECORD HR Device * HRN-IF TLS v1.0 IHE XDM (S/MIME) IHE XUA, IHE XUA++ IHE PIX IG for HL7 CDA R2 Consent Directive IHE Document Encryption (DEN) Profile IHE ATNA Confidentiality, Integrity and Authentication Confidentiality, Integrity and Authentication Entity authentication Identity management Consent Management Consent Enforcement Auditing * WAN WAN Device * WAN-IF WS-I BSP (TLS v1.0) WS-I BSP (WS-Security + SAML 2.0) IG for HL7 CDA R2 Consent Directive XML Encryption Specification IHE ATNA OAuth v2.0 Confidentiality, Integrity, authentication Entity authentication Consent Management Consent Enforcement Auditing Authorization Zigbee security Confidentiality, Integrity and Authentication Bluetooth security Confidentiality, Integrity and Authentication NFC security Confidentiality, Integrity and Authentication * APP HOST Application Hosting Device * PAN-IF * TAN-IF * * LAN-IF * * DEVICES PAN Device TAN Device LAN Device

93 Guidelines - Certification - Recognizable Logo Guidelines SOFTWARE strict interoperability Certification and Logo recognizable - promise of interoperability with other certified products APPLICATIONS SUBSTRATES PACKAGING

94 Certified devices (>90 in total) 9 4

95 Breaking Down Interoperability Barriers INCREMENTALLY HCP A patients WAN CLOUD X X WAN HRN IF sender HEALTH ECOSYSTEM HRN IF receiver EHR data X X ROUTING Home Care Provider B EHR Home Care Provider C EHR Pharma EHR. Care mgmt. EHR Research EHR Analytics HCP B patients X Home Care Provider A MESSAGES X HCP C patients X X DEVICES X GATEWAYS PLATFORM

96 KEEP CALM AND ADOPT (INTEROPERABLE) STANDARDS

97 Thanks Ian Hay Head of Emerging Ecosystems

98

99 Thematic Network UK perspective Adoption and taking up of standards and profiles for ehealth Interoperability Roger Wallhouse Director IHE-UK Ltd 07/05/2014 Antilope 99

100 UK current perspective? Common standards for ehealth systems are critical for the realisation of patient-centred healthcare Drive towards integrated care pathways and processes Approaches chosen will also radically affect the UK s future competitiveness in the global marketplace. The UK has become fragmented with regards to interoperability standards System suppliers respond to market demand, especially mandatory requirements? 7/05/2014 Produced by RAMIT 100

101 Objectives of Antilope Support the dissemination and adoption of an Interoperability Framework Concretely build on these recommendations and roadmaps National/Regional and local Interoperability projects. In particular it will: Drive the adoption of recognised sets of profiles and underlying standards for ehealth interoperability Define and validate testing guidelines and common approaches on Interoperability Labelling and Certification processes at European and at National/Regional level. 07/05/2014 Antilope 101

102 Antilope Core and Experts Partners Antilope 102

103 Antilope Validation Partners Denmark, Norway, Sweden Finland, Iceland, Estonia, Lithuania, Latvia Poland, Czech Republic, Slovakia, Hungary Ireland, United Kingdom Belgium, The Netherlands, Luxemburg France, Switzerland, Germany, Austria Slovenia, Croatia, Serbia, Bosnia, FYE Macedonia, Montenegro Italy, Malta Portugal, Spain Antilope Romania, Bulgaria, Greece, Cyprus, Turkey 103

104 Scope of Antilope 07/05/2014 Antilope 104

105 WorkPackages WP1: Refinement of the ehealth European Interoperability Framework actually in progress WP2: Definition of Interoperability testing guidelines (contribution to the quality manual for interoperability testing) WP3: Testing tools (where new test tools are identified) WP4: Interoperability Labelling and certification process WP5: Validation, Scability to EIP and Adoption WP6: Communication WP7: Project Management 07/05/2014 Antilope 105

106 ANTILOPE Thematic Network Thank you 07/05/2014 Antilope 106

107

108 Labelling and certification in Europe London Summit 30 April 2014 Karima Bourquard, IHE - Europe Presented by Jos Devlies, EuroRec

109 What do we want? What do we need? As patient, we want the best possible care. As physician (and care giver), we want to provide that best possible care. As community we want to enable / to enforce that best possible care. We need therefore resources and tools, ehealth is one of these tools. ehealth tools need to be of appropriate quality and used adequately How do we know ehealth facilities to be of appropriate quality? 30/04/2014 Antilope London 109

110 Another dimension of quality ANTILOPE Focuses on interoperability / data exchange More precisely on the quality of the quality assessment Addressing: Quality issues related to the organisations involved in quality assessment The use case based approach The tools used during the quality assessment process The quality issues related to the quality assessment processes ANTILOPE MISSION design a European quality label or certification process that supports ehealth interoperability in Europe 30/04/2014 Antilope London 110

111 Quality Assessing ehealth applications / functions Two Thematic Network projects studied the possibilities HITCH (Healthcare Interoperability Testing and Conformance Harmonisation) EHR-QTN (Electronic Healthcare Record Quality) They addressed different / complementary domains Interoperability between systems (starting with exchange) Functionality of the applications at both end (sender / receiver) They identified two tracks and two methods Public / accredited versus private market driven Third party versus self-assessment 30/04/2014 Antilope London 111

112 HITCH Project Recommendations 1 Develop an European ecosystem by promoting recognized profiles, test plans and test tools 2 Define flexible testing processes 3 Provide a European Interoperability Assessment Scheme 11/2014 Antilope 112

113 EHR-QTN Project Recommendations Apply generic criteria of quality to the initiatives 1 (independence, openness, impartiality, transparency and confidentiality) 2 Involve stakeholders to the definition of the priorities in defining feasible goals 3 Structure the Quality label and Certification processes in line with ISO standards 11/2014 Antilope 113

114 UK and all EC health communities 1 Recognise that each health care system is different 2 Build upon local status, developments and initiatives 3 Antilope aims to foster collaboration not impose an EC wide standard 11/2014 Antilope 114

115 HITCH Roadmap Get ready European Strategic Milestones eeif Ehealth Interoperability Framework Testing & Certification Processes Evaluation of Testing & LabelCert. EuropeanTesting & LabelCert. Operational Support of Project-Level Testing & LabelCert Process European-Level Testing Process Proposed European-Level Testing Process Proposed European-Level LabelCert. Process European-Level LabelCert Process Testing Tools Interop/functional Linkage Test Management Platform V2.0 Testing Management Platform V1.0 Test Cases V1.0 Support of Project-Level Testing Tools Test Cases V2.0 Test Tools V1.0 30/04/2014 Pilot Testing & LabelCert. European-Level QMS V2.0 European-Level QMS V1.0 Test Methodology Deploy XX Operationalize Antilope London Test Tools V

116 Testing, Quality labelling and Certification processes Functional Model 30/04/2014 Antilope London 116

117 Quality Label and Certification processes - Definitions QL & C processes Requirements, activities and tasks to support high quality interoperability assurance or certification Conformity assessment demonstration that specified requirements relating to a product, process, system, person or body are fulfilled (ISO/IEC 17000) 30/04/2014 Antilope London 117

118 Functions A certification or quality label process requires: A Certification/Label Scheme Owner: a party that sets the Certification or a quality label program or system; A label/certification Body: a party that issues the quality label or certificate on the basis of the conformity assessment performed by a conformity assessment body; A Conformity Assessment Body: a party that assesses the conformity of products, services and/or suppliers (often called a testing laboratory) 30/04/2014 Antilope London 118

119 Quality label and Certification Functional Model 30/04/2014 Antilope London 119

120 Case Studies 30/04/2014 Antilope London 120

121 Case study 1 : DMP in France Step 1 Step 2 Step 3 Registration of the Vendor to the process (ASIP Santé) Registration and published candidates for DMP compatibility Access to the test environment Access to the support Pre-Homologation: upload files and validation of the tests Homologation and testing validation Update and bugs resolution Final decision by the committee and publication of the results Label (Homologation) Process Mapping Services/Standards and Profiles 30/04/2014 Antilope London 121

122 Case study 2 : epsos project eeif UC1, UC2a UC2b epsos Specifications IHE Profiles epsos Testing Process Test Plans Testing Tools 30/04/2014 Antilope London 122

123 Harmonisation of the quality label or certification processes in Europe 30/04/2014 Antilope London 123

124 The Quality Label and Certification processes (1/2) 30/04/2014 Antilope London 124

125 Guidelines and recommendations 30/04/2014 Antilope London 125

126 In Europe: Three key steps 1 Define the Interoperability Conformance Assessment Scheme closely related with the eeif 2 Promote creation of accredited Conformance Assessment Bodies in Europe 3 Develop Suitable Organisation for the QL&C process 30/04/2014 Antilope London 126

127 At the National and Regional levels 1 National and Regional Project leverage profiles recognized by eeif and use flexibility with needed national extensions 2 Ensure that the European level certification may be used as an entry criteria at the national level 3 Organise acceptance and the recognition of profiles candidates in the eeif based on local use cases 30/04/2014 Antilope London 127

128 Scenarios of implementation An ANTILOPE cross-border model, focusing on Interoperability Use case implementation Considering eeif A (complementary) model, focusing on Functionality Primarily national requirements 30/04/2014 Antilope London 128

129 For more information, please refer to document D4.1. available on the Antilope website 30/04/2014 Antilope London 129

130 Next steps for the project Next steps: Collecting all the feedbacks from the summits and other conferences: January to June 2014 New version to be submitted to the SEPs (experts) Validation by the Core Group in November Final drafts of the deliverables on January 2015 Few feedbacks received due to the complexity of the topic where expertise is needed Benefit: Align with ISO standards Mutualisation and harmonisation in Europe One QL&C processes at the EU level where derivation is described 30/04/2014 Antilope London 130

131

132 Antilope refinement of the eeuropean Interoperability Framework Vincent van Pelt Nictiz, the Netherlands

133 Introduction Vincent van Pelt, MD Nictiz, the Netherlands National Healthcare ICT Competence center IHE PCC Technical committee Antilope

134 Overview Three key messages Goals of Antilope Deliverables ehealth European Interoperability Framework Antilope Use Cases Linking Use Cases to IHE and Continua Profiles Templates for Use Cases and Realisation Scenarios Refined interoperability schema Three key messages (with solutions from Antilope) Antilope

135 Three key messages Interoperability requires a shared definition of interoperability levels, terms and use cases Use Cases are important building blocks in the realisation of interoperability Using open, international standards and profiles in the implementation of Use Cases future-proofs investment Antilope

136 Goals Refinement of ehealth European Interoperability Framework Provide a comprehensive set of Use Cases that can be used throughout Europe as a basis for national and regional implementations Provide tools and schemas that can assist in a shared understanding of interoperability issues Educational material For summits, discussions, collaborations and projects Antilope

137 Deliverables 1. D1.1 Refinement Definition document Set of Use Cases Linking to interoperability Standards and Profiles (through Realisation Scenarios) Templates for description of Use Cases and Realisation Scenarios Model for interoperability levels Glossary of interoperability terms and definitions Overview of the IHE and Continua Profiles mentioned in the Antilope Use Cases Recommendations for governance and lifecycle 2. D1.2 Educational material PowerPoint presentation (this presentation) Refinement Definition document (see above) Antilope

138 Interoperability Framework Antilope

139 The Antilope Use Cases # Medical domain Description Scale 1 Medication 2 Radiology e-prescription and e-dispensing 1a) Cross-border 1b) National/Regional 1c) Intra-hospital 1d) Citizens at home Request and results sharing workflow for radiology 2a) National/Regional 3 Laboratory Request and results sharing workflow for laboratory 3a) National/Regional 4 Patient Summary Patient Summary sharing 4a) Cross-border 4b) National/regional 4c) Citizens at home 5 Referral- and discharge reporting 6 Participatory healthcare 7 Telemonitoring Cross-enterprise Referral and Discharge Reporting National /Regional 5a) Referral of patient from primary to secondary care 5b) Discharge report from secondary care Involvement by chronic patients in electronic documentation of healthcare information Citizens at home 8 Multidisciplinary consultation Medical Board Review 2b) Intra-hospital 3b) Intra-Hospital Remote monitoring and care of Citizens at home people at home or on the move using sensor devices National/Regional

140 Linking Use Cases to Interoperability Profiles High-level Use Case Functional description of the interactions between the participants in a process, for a certain purpose. Implementation-agnostic. Realisation Scenario High level direction for the realisation of a Use Case Can be linked to interoperability Profiles. Antilope

141 Linking Use Cases to Profiles Functional description of the interactions between the participants in a process Antilope Use Cases can be realised through High level direction for the realisation of a Use Case Realisation Scenarios make use of Functionalities, transactions Abstract processes (for instance, patient login ) can be implemented using Guidelines for standards-based implementation Profiles and Standards Antilope

142 Use Cases and Realisation Scenarios Medication Patient Summaries Radiology workflow Referral and discharge reports Telehome monitoring Laboratory workflow Medical Board Review Patient Data Entry Consist of functionalities Functionalities Workflow interoperability Workflow descriptions Content Document Terminology HCP Identification Access Control Patient Identification Cross-community Services Intra-community Communication can be implemented with Profiles Profiles IHE Continua are based upon standards Standards HL7 IHTSDO LOINC ISO DICOM CEN GS1

143 Using Profiles to realise functionalities Content Workflow interoperability Workflow descriptions XDW Document Workflow LTW Laboratory Testing Workflow XBeR-WD Basic ereferral SWF Scheduled Workflow (Radiol.) XTB-WD Medical Board Review CMPD Commun. Medic. PRE and DIS Document Terminology XPHR Exch. of Personal Health Record DEN Document Encryption SVS Shared Value Sets XD-LAB DSG Document Signature RTM Rosetta Terminology Mapping DSUB Document Notification LCSD Laboratory Code Sets Distribution DIS, PRE Sharing Laboratory Results MS Medical Summaries HCP Identification HPD Healthcare Provider Discovery Access Control Patient Identification XUA(++) Rights and Authorization PIX/PDQ Patient Discovery BPPC Patient Consent PAM Patient Administration Mgt XCPD Cross-Comm. Patient Discovery Cross-community XCA Cross-Community Access Intra-community Communication XDS, XDR Document Sharing HRN Health Record Network ATNA Audit Trailing & NA WAN, LAN, PAN Network protocols CT Consistent Time DEC Device-Enterprise Communic.

144 Templates for Use Case description Structured description of Use Cases and accompanying Realisation Scenarios Separate templates for the Use Case (= problem description ) and the Realisation Scenario (= solution direction ) Can be used for the structured description of additional Use Cases. Antilope

145 Use Case description template Title Purpose (Number and) Name of the Use Case Domain The key functional domain of the Use Case: Medication, Radiology, Laboratory, Patient Summary, Referral and Discharge Reporting, Participatory healthcare, Telemonitoring, Multidisciplinary consultation Scale Organisational dimensions of the Use. The following scales have been defined for the Antilope Use Cases: Cross-border, National/regional, Intra-hospital, Citizens at home and on the move Business Case The Business Case explains the why of the Use Case. It describes the relevance of the Use Case (both medical and economical). This part can contain a short SWOT analysis. Context Information Participants Steps Describes the current situation, influencing factors The Purpose of a Use Case describes the objective that needs to be achieved, the goal of the use case. It also describes the relevance of the Use Case (both from the care process and the economical viewpoint). High-level description of what type of information is shared, like patient summary or medication prescription List of the main participants in the process. These can be individuals or organisational units. They are realworld parties. Real-world, functional description of a sequence of interactions between the participants in the different interaction steps of a process Antilope

146 Realisation Scenario description template Title Related Use Case (Number and) Name of the Realisation Scenario Use Case that this Realisation Scenario is related to Scenario context Actors Information and background about the real-world scenario. List of the main participating systems, also (confusingly) called Actors, in the process. In this context, an Actor is an ICT system, as opposed to a participant (see above). Actors are involved with each other through transactions. Transactions Interoperability workflow steps describing the process steps between systems, including the information that is exchanged. Process flow A numbered list of process steps (optionally accompanied by a schematic overview), describing transactions between systems (actors), and the information units that are exchanged. The process flow describes the interoperability steps, i.e. the steps between the systems, and not the steps within the systems. The process flow can be linked to IHE and/or Continua Profiles. In this part, also swimming lanes and other schemas can be used Linked Profiles A list of Profiles that are relevant for the entire process flow, and a numbered list of the Profiles that can be linked to the Process flow steps. Possible issues Issues such as legislation and guidelines, social acceptance, language issues, architectural flaws, et cetera, that may affect the realisation of this scenario. 7/05/2014 Produced by RAMIT 146

147 Refined interoperability schema - background Many different approaches for arranging interoperability levels 7/05/2014 Produced by RAMIT 147

148 Refined interoperability schema - background Many different representations Often: too generic to be applicable, or too technical to be understandable too extensive to be practical Antilope

149 Antilope Refined interoperability schema Standards and Profiles, Certification Security, Governance Legal and regulatory Policy Care Process Information Applications IT Infrastructure

150 Refined interoperability schema Standards and Profiles, Certification Security, Governance Activities for reaching interoperability in the different layers Legal and regulatory Compatible legislation and regulations Policy Collaboration agreements between organisations Care Process Alignment of care processes, shared Use Cases Information Datamodel, terminologies, interchange format Applications Integration in healthcare applications IT Infrastructure Communication, network, servers, databases

151 Refined interoperability schema Stakeholders in the different levels Standards and Profiles, Certification Security, Governance Legal and regulatory Regulators and advisors Policy Care Process Information analysts Policy makers Healthcare managers Information Information architects Applications Software developers IT Infrastructure System architects Lawyers Healthcare professionals System engineers

152 Three key messages Interoperability requires a shared definition of interoperability levels, terms and use cases Use Cases are important building blocks in the realisation of interoperability Using open, international standards and profiles in the implementation of Use Cases is a future-proof investment and facilitates cross-border solutions Antilope offers a set of Use Cases, a glossary of interoperability terms and definitions, a schema for interoperability levels, and a template for the description of use cases. The Antilope Use Cases can be used as practical starting points for national/regional ehealth projects. The Antilope Use Cases are linked to proven and widely accepted standards and profiles. Antilope

153 Further information More information is available at the Antilope website: Antilope

154 Lunch 60 min

155 Quality Manual for Interoperability Testing Morten Bruun-Rasmussen

156 Quality and quality assurance Quality in manufacturing A measure, stating that a product is free from defects and significant variations Quality in information technology product and services Meeting the requirements of the customer Quality Assurance Any systematic process for ensuring quality Quality and Quality Assurance for Interoperability Testing An immature professional discipline 156

157 Quality Manual - documents Quality Manual for Interoperability Testing - PART I: D2.1: Quality Management System for Interoperability Testing Quality Manual for Interoperability Testing - PART II: D2.2: Interoperability Testing Processes D2.3a: Educational material (this presentation) D2.3b: Executive summary. Quality management System D2.3c: Executive summary. Interoperability Testing Processes 157

158 Quality Manual for Interoperability Testing Part I D2.1 Quality Management System Part II D2.2 Interoperability Testing Processes CAB Requirements for the operation of Conformity Assessment Bodies performing Interoperability Testing 158

159 Quality Manual for Interoperability Testing A brief look into: Part I: Quality Management System Requirements for entities performing Interoperability Testing 159

160 Quality Management System (one definition) A Quality Management System is a set of interrelated or interacting elements that organisations use to direct and control how quality policies are implemented and quality objectives are achieved. Source: ISO 9000: Quality Management Systems 160

161 Quality Manual for Interoperability Testing A brief look into: Part II: Interoperability Testing Processes 161

162 Interoperability (one definition) The ability of two or more systems or components to exchange information and to use the information that has been exchanged Source: Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY:

163 Interoperability and the ALT-model Organisational level Continuity and quality presentation presentation Application level functionality Clinical Interoperability clinical content clinical content Logical level Technical level terminology functionality Semantic interoperability terminology model model format & storage format & storage transmission Technical interoperability Communication transmission 163

164 Interoperability Testing Processes Scope The Interoperability Testing Processes are generic and can be adjusted and customized by any Interoperability Testing entity The Interoperability Testing Processes is a set of interconnected guidelines that describes how to run a test session from start to end. Each process has defined input and output and can be maintained and improved in isolation and by different people with the required experience and skills. 164

165 Interoperability Testing Processes Actors and roles Term Definition The top level management coordinates the different activities. It gets reports from QA Manager, Test Manager and Auditors QA Committee A committee has the role to ensure the quality of the testing process, discusses the needs and decides on what needs to be done in terms of quality. QA Manager Manages the QA process. Gets input from the QA Committee and reports to Top Level Management. Test Manager(TM) Manages the testing. Organises the testing activities, reports to the Top Level Management. Follows the rules from the QA Committee to ensure the overall quality of the process Testing team Performs the tests and is under the supervision of the Test Manager. System Under Test (SUT) Operators Auditors SUT Operators execute their SUTs test steps required by the test Top Level Management Auditors verify that the QMS process is correctly used. The auditors report to the Top Level Management. 165

166 Interoperability Testing Processes Nine interconnected steps 1. Quality Planning 2. Test Plan Definition 3. Design Tests 4. Develop or Select Test Tools 5. Validation 6. Prepare Test Session 7. Test Plan Execution 8. Test Management 9. Test Management Update 166

167 Interoperability Testing Processes A generic template for each process Why? Objective Work to be done Risk planning Roles and responsibilities Checklist: How to adjust and localise the process description 167

168 Example: Test Plan Definition Why? Interoperability Testing complexity Fit of testing, managerial and monitoring skills. Rigorous standardisation and conformance. 168

169 Example: Test Plan Definition Objective It will describe the test strategy and its implementation. Activities are defined and planned in order to test profile specification in a given context. 169

170 Example: Process Test Plan Definition Work to be done Definition of the scope and objective Specification of the test design Development or the selection of the test tools Preparation of the test session: Execution of the test session Reporting of test results. 170

171 Example: Process Test Plan Definition Risk planning The equilibrium between resources, schedule and the test design needs to be established. A bad risk assessment and a weakness on the requirements specifications are also possible causes of failure. If customers notice a weakness in the quality of products, they will no longer have confidence in the testing process of a particular project. If the feedback to the organisation that has made the specification (eq. a profile for patient identification) is not well documented, the testing process has no sense or will be the bad quality. 171

172 Example: Test Plan Definition Roles and responsibilities The test plan definition is under the responsibility of the Test Manager who organises the complete testing process. 172

173 Key messages A Quality Management System will ensure: - continuous improvement of Interoperability - improve ehealth deployment - adoption of International ehealth standards 173

174 Thank you More information on the Quality Manual Part I: D2.1 Quality Management System for Interoperability Testing Part II: D2.2 Interoperability Testing Processes Is available on the Antilope website 174

175 Quality Management levels Strategic Operational Policy statements including clear objectives derives from the policy Description of processes how are the policy statements implemented Administrative Supporting documents to be used to implement the policies 175

176 Quality Management System and the PDCA cycle What to do? How to do it? How to improve next time? Do what was planned Did things happen according to the plan? Source: The Deming wheel (named after W. Edwards Deming). A model for continuous improvement. 176

177 Requirements for management (1/2) Organisation Management system Document control General procedures Approval and issue Changes Review of requests, tenders and contracts Complaints 177

178 Requirements for management (2/2) Control of nonconforming testing work Improvement Corrective action Cause analysis Selection and implementation of corrective actions Monitoring of corrective actions Preventive action Control of records Technical records Internal audits Management reviews 178

179 Requirements for: Personnel and test methods Personnel ensure the competence of all who perform test, evaluate results, and sign test reports formulate the goals with respect to the education, training and skills of the Interoperability Test entity use personnel who are employed by, or under contract to, the Interoperability Test entity maintain job descriptions for managerial, technical and key support personnel involved in tests Test methods Use methods and procedures as described in the Quality Manual Part II. D2.2 Interoperability Testing Processes. 179

180

181 Antilope Testing tools Milan Zoric ETSI

182 ANTILOPE objectives for testing tools Identify existing & new testing tools required to cover the selection of Use Cases described in the ehealth European Interoperability Framework (eeif) and their refinement Promote the use of existing testing tools Promote the development of required new or improved testing tools ANTILOPE Summit, London

183 Do we need testing and tools -1? Interoperability of future ehealth systems is first addressed when specifications for a system are set. Basing the solution on internationally accepted standard is the key step. The next step is setting the profiles that would restrict the level of freedom in standards to the level that would make them interoperable. ehealth solutions are built with intention to respect all the requirements set in the standards and profiles. ANTILOPE Summit, London

184 Do we need testing and tools 2? However, standard and profile specifications are, as a rule, not tight enough and differing interpretations and erroneous implementations lead to interoperability problem. It has been proven many times that the only solution to that problem is the appropriate level of testing. In order for the testing to be precise, efficient and less dependent on human intervention testing tools are required. ANTILOPE Summit, London

185 Testing tools gap analysis process eeif Use Cases ANTILOPE refined Use Cases Selection of Profiles and underlying standards adapted to the Use Cases Existing Testing Tools for Selected Profiles and standards Gaps in existing testing tools ANTILOPE Summit, London

186 Key messages on testing tools Testing tools are key to achieving interoperability Testing and certification of eeif Use Cases is relying on recognized profiles and will require robust and high quality testing tools ANTILOPE is contributing by consolidating and Use good testing tools disseminating the knowledge about the testing tools that that exist already available. New or improved test ANTILOPE is identifying the gaps and will stimulate the development of required additional tools need to be capabilities of testing tools developed ANTILOPE Summit, London