Extending “Certification of Electronic Health Records” at a Pan-European Level

1. Extending “Certification of Electronic Health Records” at a Pan-European Level (Prague, 19 February 2009) Georges De Moor, MD, PhD Gent University, Gent, Belgium EuroRec President

2. Electronic Health Records (EHR) All stakeholders across the EU have recognized that the Electronic Health Record is: • a key tool in the provision of safe, high quality and effective care ; • and a critical factor for clinical research .

3. EuroRec (http://www.eurorec.org ) • The « European Institute for Health Records » • AEuropeannot-for-profit organisation (April 16, 2003) • Mission:the promotion of high quality Electronic Health Record systems (EHRs) in Europe • Federationof National ProRec Centres (incl. all types of stakeholders)

4. Austria Belgium Bulgaria Denmark France Italy Germany Ireland Romania Slovenia Spain Slovakia Serbia The Netherlands United Kingdom Established ProRec Centers New applicants: Cyprus Greece Hungary Norway Poland Portugal Sweden “ Differences in languages, cultures and HC-delivery/funding systems ”

5. Contacts and Liaison DG INFSO BT and TC 251 TC 215 IHTSDO

6. Trends in Health Systems The Old World Provider-focused Illness Site-of-care Episode Management Supply Management Solitary Decision Making Efficiency General care The New World Patient and family-focused Wellness Continuum of care Disease Management Demand Management Collaborative,evidence-based decisions Effectiveness Specialized care (from UHN, Toronto)

7. Trends in eHealth systems • Patient-centered (gatekeeper?) and longitudinal (life-long) records • Multi-disciplinary / multi-professional • Transmural and virtual • Structured and coded (cf. semantic interoperability) • Intelligent (cf. decision support) • More sensitive content (e.g. genetic data)

8. The eHealth Contexts In Health and eHealth, the data are delivered from multiple sourcesusing many different communication channels. The data may be used by different types of usersfordifferent purposes (e.g.: care, research, management…).

9. EHR systems « The boundaries between EHR systems are fading away… » Settings: primary care, acute hospital care, tertiary care, … Content: summary records, emergency records, discharge records, … Approach: problem-oriented, care pathway-, clinical pathway-oriented, … Context: prevention, diagnostic, therapeutic (care & cure), monitoring, palliation (or combination), research, … Author: medical record (EMR), nursing record, administrative record, patient personal health record (PHR)

10. eHealth Stakeholders Clinicians: care… (access to medical records, e-prescription, care pathways… administrative simplifications !…) Researchers: clinical trials, disease management studies, post-marketing surveillance, health economics… Health Authorities: pharmacovigilance, healthcaremanagement, quality assessment, utilisation review… Data-brokers & industry: research, marketing, promotion… Third Party Payers: billing, reimbursement… Academics: education… IT-vendors: software development Regulators: legislation Patients: their role inthe future…?

11. Clinical Trials & Research Safety and Adverse Event Registers Marketing Knowledge Mgmt Platforms Healthcare Management Decision Support Systems Secondary use of (medical) data Patient TRUST Clinician EHR (EMR, EPR…) PHR Privacy Enhancing Techniques Billing

12. EuroRec: History of EC Projects • MediRec (1994-95), Medical Records and Quality • ProRec (1996-98), Promotion Strategy for EHRs in Europe • Widenet (2000-03), Establishing EuroRec’s Network • RIDE (2008-10), Semantic Interoperability (partner) - EHR-Implement (2008-10), Political, Social and Economical aspects when implementing national EHRs systems • QREC (2006-08), Quality Labeling and Certification of EHRs in Europe • EHR-Q-TN (2009-2011), Thematic Network

13. The QREC project: Main Objective To develop formal methods and to create a mechanism for the quality labelling andcertification of EHR systems in Europe (in primary- and in acute hospital-care settings) EuroRec Institute was coordinating partner QREC had 12 partners and 2 subcontractors Project duration was 30 months (1/1/2006-30/6/2008)

14. Q-REC Rationale (Why Certification is Essential) • - To assure the quality of EHR systems: patient safety • Sharing of information requires a quality assessment of EHR products with a view to ensuringinteroperability with other systems • - Certification of EHRs is essentialfor both the buyers and the suppliers to ensure that EHR systems are robust enough to deliver the anticipated benefits. • (EHR systems and related product quality - data portability and interoperability- are difficult to judge!)

15. QREC: ORIGIN Several EU-member states (Belgium, Denmark, UK, Ireland,France …) have already proceeded since many years with (EHRs-) quality labelling and/or certification (more often in primary care)but these differin scope, inlegal framework under which they operate, in policies andorganisation, and perhaps most importantly in the quality andconformance criteriaused for benchmarking … These differences represent a richness but also a risk:harmonisation efforts should help to avoid further market fragmentation in Europe

16. EuroRec’s Central Repository and Tools EuroRec has installed a central repositoryof « validated » quality criteriaand other relevant materials and has developed tools that can be used to harmonise quality labelling, product documentation and procurement specificationof EHR systems. EuroRec willnot impose particular certification modelsor specific criteria on any member country but wishes to foster, via authorized channels, the progressive adoption of consistent and comparable approaches to EHR system quality labelling. EuroRec should be considered as a service provider.

17. EHRs Quality Criteria: just a few Business Cases • Ane-Health programmewishing to implement quality labelling or certification as to ensure consistent EHR system functionality regionally or nationally • A purchaserwishing to procure an EHR system module • Avendor/developerwishing to document his system or to (re-) develop an EHR system module or wishing to interface a given module of his system across multi-vendor systems

18. Benefits for the Stakeholders Industry Market ( R.O.I.) EHRs - Quality Labelling / Certification Quality and Safety Efficiency of HC Delivery Systems Health Services Management Patients, Clinicians Public Health Health Authorities

19. Administrative simplification Electronic billing Care pathways and disease management projects Electronic prescription Interaction with validated databases Secure medical data exchange (summary records!) Interoperability, operability and portability ... A growing number of strategic eHealth projects Are or become certification dependent, e.g.:

20. Certification: a powerful weapon… New instruments Newfunctions 4 3 1 € 2 Pressure

21. How to Manage Certification? EuroRec has Multiple Options: • Authority: Government (or mandated subcontr.) vs. Non Gov. • Self-certification by Industry (also an option!) • National based vs. Pan European (or joint, cf. specific/generic) • Mandatory vs. voluntary (with or without incentives) • Formal audit/testing vs. self-assessment (or pre-test assessment) • Scoring/rating scheme: pass/fail or more graded approach • Scheme review rate (1,2,…n year cycles) • Quality Assurance vs. Quality Improvement focus

22. EuroRec’s Workflow

23. Typology of EHR System Statements • Source Statements/ Referenced Statements (RS) • faithfully extracted from existing original EHR system specifications and test plans • translated if necessary • Fine Grained Statements (FGS) (at present: n>1500) • usually derived from source statements • made more generic, decomposed, reworded, corrected • Good Practice Requirements (GPR) (n~150) • recomposed from FGS into the more common useful building blocks • may enhance or extend the scope of FGS: “push the boat out a bit” • Generic Test Criteria • derived from FGS and/or GPR • formally worded as testable functions

25. Methodology for the Repository Design • Typologyof EHR system statements (the quality criteria) • Generic informationmodelfor the repository • Design ofindices(indexing system, ontology) • Planning of the repository managementworkflow • Design of web-baseduser interfacerequirements • Review of other relevant work of this kind • e.g. HL7, CCHIT, ISO TC/215, academic work • Learning from early iterations of statement classification • Testing of the pilot repository

26. B1 Health care enterprises • B10 Long-term care (institution) • B11 General practice • B12 Secondary care (hospital) • B13 Tertiary care centre (specialist hospital) • B14 Domain specific • B15 Profession specific • B2 Secondary uses • B20 Research and knowledge discovery • B21 Education • B22 Health service and planning • B0 Generic or ubiquitous • B01 Regional healthcare network (specific distribution) • B02 Virtual or telehealth • B03 Personal health • B04 Community and home care • B05 Health, wellness and prevention • B06 Occupational health • B07 Public health • A0 EHR data (record) management • A00 EHR data entry • A01 EHR data analysis • A02 EHR data content • A03 EHR data structure • A04 EHR data display • A05 EHR data export/import • A09 EHR generic data attributes • A1 Clinical functions • A10 Clinical: medication management • A11 Clinical: long-term illness management • A12 Clinical: health needs assessment • A13 Clinical: care planning and care pathways • A14 shared care • A15 Clinical: alerts, reminders and decision support • A16 Clinical: workflow and task management • A17 Clinical: patient screening and preventive care services • A2 Administrative services • A20 Appointments and scheduling • A21 Patient consents, authorisations, directives • A22 Patient demographic services • A23 Certificates and related reporting services • A24 Patient financial and insurance services • A3 Care Supportive services • A30 Supportive care service requests (orders) • A31 Supportive care service reporting (results) • A32 Laboratory services • A33 Imaging services • A34 Diagnostic and therapeutic services (other): ECG/EEG etc. • A35 Pharmacy services • A4 Analysis and reporting • A40 Screening and preventive health • A41 Care setting reports • C3 Directory services • C30 Directory: patients • C31 Directory: personnel • C32 Directory: equipment • C33 Directory: health service directories • C34 Directory: service resources • C35 Third parties • C4 Profiling or authoring tool • C5 Documentation, support etc. • C6 EHR system functional component • C0 EHRS functional component • C1 EHRS infrastructure component • C10 EHRS Interoperability component • C11 Security management component • C2 Knowledge resources • C20 Knowledge: terminology • C21 Knowledge: ontology • C22 Knowledge: archetype • C23 Knowledge: template • C24 Knowledge: data set • C25 Knowledge: guideline • C26 Knowledge: algorithm Typology of Indexes • Multiple indexing of each statement to maximise the likelihood of finding • all relevant statements when searching via the indices • Business Functions(50 in 8 subcategories) • Care Settings(18 in 3 subcategories) • Component Types(18 in 4 subcategories) Business Functions Care Settings Component Types

27. Good Practice Requirements - Links

29. EuroRec Languages(non-exhaustive list) • English (default language) • Bulgarian • Danish • Dutch • French • German • Italian • Romanian • Slovakian • Slovenian • Serbian

31. EuroRec Use Tools The EuroRec Composer ™ To compose user defined, re-usable and exchangeable baskets of Fine Grained Statements. The EuroRec Certifier ™ To format a EuroRec Basket content to obtain the basic layer for the certification of EHR systems. This is done by adding structure and attributes to the selected Fine Grained Statements (e.g. mandatory, optional...) The EuroRec Documenter ™ To document EHR systems and their functions, enhancing their understanding and comparability by using the EuroRec statements. The EuroRec Procurer ™ To list and describe, for purchase purposes, required functionalities and product characteristics using EuroRec statements. The EuroRec Scripter ™ To produce and link Test Scenarios to EuroRec Basketsfor Certification, Documentation and/or Procurement purposes.

32. EuroRec stakeholders(Users of the EuroRec tools) • National or Regional Healthcare Authorities (quality labelling) • EHR System providers (self assessment/ product documentation) • Health IT purchasers (procurement) • Health IT professional users • Health IT research and education

33. Composer EuroRec Baskets EuroRec Repository of Statements Certifier Procurer Documenter Certification Documentation Procurement Test Criteria Sets Scripter Test Procedures Test Scenarios EuroRec Use Tools

34. EuroRec at your Service ! • Developing & maintaining a central repository with quality criteria • Developing tools: certification, procurement and product doc. • Providing guidance and assistance to all stakeholders • Assisting Authorities in introducing / adoptingcertification • Training and accreditation of surveyors(European level) • Set-up of certification session (incl. scenario scripting/operations) • Validation of clinical archetypes (clinical models) • Continous & total Q.A.of processes and procedures

35. Certification – Step 1 Agree - as authority - with the users and suppliers what should be certified. Select appropriate criteria to be validated during a particular certification session: initial certification might be comprehensive; but is later often limited to specific (new/changed) functions. Use the Indexes and Good Practice Requirements as filters. If needed, complete the set with new statements (and send to the EuroRec repository). Result => Basket of Fine Grained Statements

36. Structure the Basket: Order Grouping in subsets Define: Essential (mandatory) criteria Optional criteria Criteria “for later” Assign weights to individual criteria and/or subsets Produce certification documentation (for the suppliers & users) Certification – Step 2

37. Define test scripts Link to each script a number of FGS / criteria that will be validated by that script Combine scripts in a test scenario Link one or more test scenarios to a certification session Produce certification forms (to be completed during a certification session…) Certification – Step 3

38. 13 mei 2008

39. Unveiling the EuroRec Seal To have a “base” level set of functions that can be accredited across Europe. This will greatly appeal to the supplier industry and allow for more early stage accreditation of systems across national boundaries. Harmonisation of the certification will favour harmonisation of products. Develop a strong, growing and profitable EHR supplier industry that can be competitive globally.

40. Content of the Seal (1) Not all EHR functions can - at present - be harmonised across the European Community: Specific regulations (incl. HC reimbursement systems); Linguistic and cultural issues; Differences in available services (e.g. drug- and other databases in use); Even sometimes different options regarding evidence based medicine (EBM) issues ! (cf. decision support modules). First versions of the EuroRec seal & criteria will therefore mainly focus on what is really essential and thus be related to “generic” aspects, e.g. “the trustworthiness of the content of an EHR”.

41. The first set of selected criteria will: not be too specific, e.g not related to very particular functions; correspond with what is considered essential (e.g. security, medication management, ....) Fair chance that a large number of existing EHR products will conform to the chosen criteria. Content of the Seal (2)

42. The GPR with most selected FGS

43. EHR-Q-TN: EuroRec’s new Project Thematic Network on Quality Labelling and Certification of EHR Systems (2009-2011)

44. Poland Norway United Kingdom Austria Hungary Portugal Ireland Belgium Romania Bulgaria Italy Croatia Cyprus Czech Republic Serbia Denmark Slovakia Estonia Slovenia Luxembourg France Spain Germany Netherlands Greece Beneficiaries 28 Partners 25 Countries

45. Validate and Customise the EuroRec criteria on e- prescription and patient summaries in 24 countries Database of stakeholders (incl. EHRs vendors) Inventory of legal issues Local coordination & education Annual EHR-QTN International Conferences Five Regional EHR-QTN Conferences EHR-QTN (Mediteranian, Eastern, Central, Western and Nordic regions) In each country one workshop every year on: Validation of EuroRec Repository (Y1) Tools for certification, product documentation & procurement (Y2) Procedures for EHR Quality Labelling and Certification Objectives of the EHR Q Thematic Network

46. Other EuroRec Activities and Services • An Inventory of Certification Criteria for EHR systems • An Inventory of Standards relevant for EHR systems • EHR Archetype validation • Open Source Components and XML Schemas • EHR Tutorials • Register of Health Coding Systems in use in Europe • Events

47. The EuroRec Institute is partnering the openEHR Foundation in developing governance practices for archetype development, and the quality criteria and editorial policies by which certified libraries of archetypes can be recognised. As part of the quality labelling and certification of EHR-systems, it may take joint responsibility for the governance of archetypes and templates alongside the openEHR Foundation.

48. What is a Clinical Archetype A clinical archetype is an agreed, formal and interoperable specification for representing a given clinical entity such as a clinical observation, a finding, a plan or a treatment within an electronic health record • invented and maintained by openEHR • ratified by CEN: EN 13606 Part 2 • being balloted by ISO • to be quality labelled by EuroRec

49. Patient safety managementand the pursuit of evidence based care require computable information that can be linked to and queried by alerting components, decision support and clinical pathway systems. The efficient management of health servicesand the support of public health and clinical researchthrough audits and population analyses also require EHRs that can semantically be processed. All these purposes of use ideally require that the clinical findings within EHRs are represented and organised consistently across vendor products and communities of use: semantic interoperability.

50. openEHR Semantic architecture