Electronic Health Record Systems Certification: the European Perspective

1. Electronic Health Record Systems Certification: the European Perspective Georges De Moor, MD, PhD EuroRec President Portoroz, 5 May 2008

2. EuroRec: current standing on EHR certification in Europe EuroRec (http://www.eurorec.org ) • The « European Institute for Health Records » • Anot-for-profit organisation, established April 16, 2003 • Mission:the promotion of high quality Electronic Health Record systems (EHRs) in Europe • Federationof national ProRec centres in Europe Georges De Moor, MD, PhD

3. Belgium Bulgaria Denmark France Italy Germany Ireland Romania Slovenia Spain Slovakia Serbia UK ProRec Centers “ Differences in languages, cultures and HC-delivery/funding systems ”

4. Contacts and Liaison DG INFSO BT and TC 251 TC 215

5. 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- or 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)

6. EHR systems: Future Trends • Patient-centered (access keeper?) and longitudinal (life-long) • Multi-disciplinary / multi-professional • Transmural (cf. interoperability) and virtual • More sensitive content (biomedical/genetic data) • More structured and coded • Intelligent (cf. decision support) 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 end a critical factor for clinical research.

7. Clinical Trial Safety and Adverse event Register Marketing Utilisation Review Knowledge Mgmt Platform Decision Support Patient User / Clinician EHRs: Secondary Uses (examples) EHR re-use t1 t6 (de-identification) t5 t2 t4 t3 Billing

8. The QREC project: 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 is coordinating partner QREC has 12 partners and 2 subcontractors Project duration is 30 months (1/1/2006-30/6/2008)

9. QREC: ORIGIN Several EU-member states (Belgium, Denmark, UK, Ireland, …) have already proceeded since 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

10. Central Repository EuroRec has installed a central repository ofvalidated quality criteriaand other relevant materials that can be used to harmonise European quality labelling, product documentation and procurement specification of EHR systems. It willnot impose particular certification modelsor specific criteria on any member country but will foster, via authorized channels, the progressive adoption of consistent and comparable approaches to EHR system quality labelling.

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

12. Q-REC Rationale –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 systemsbecause: • healthcare information, in particular clinical information, is often scattered over a number of informatics systems • the structures of these EHRs may significantly differ from one system to the other, depending on the creator and the purpose. • more and more incentives are being given to share patients’ medical data to support high quality care and “continuity of care” in a seamless way. Certification of EHRs is essentialfor buyers and suppliers • to ensure that EHR systems are robust enough to deliver the anticipated benefits as EHR systems and related product quality (data portability and interoperability) are difficult to judge.

13. EHRs Criteria: Business Cases • A purchaserwishing to procure an EHR system module • Ane-Health programmewishing to implement certification as to ensure consistent EHR system functionality nationally • Avendor/developerwishing to (re-)develop an EHR system module or wishing to interface a given EHR system module across multi-vendor systems

14. Example Use Cases for the Repository • For a givenEHR system module, to • browse the functional criteria • query for specific requirements or criteria • extract (download) the full set of criteria for the module • to put into a procurement specification • to use in order to develop a local test plan for certification • for product documentation • For a givencare setting • identify which modules are relevant • choose which requirements are of greatest local relevance • find certified suppliers that meet these

15. Methodology for the Repository Design • Typologyof EHR system statements • Generic informationmodelfor the repository • Design ofindices(ontology) • Planning of the repository managementworkflow • Design of the 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

16. Repository Workflow

17. Typology of EHR System Statements • Source Statements • faithfully extracted from original EHR system specifications and test plans • translated if necessary • Fine Grained Statements (FGS) • usually derived from source statements • made more generic, decomposed, reworded, corrected • Good Practice Requirements (GPR) • 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

18. 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

19. List of Good Practice Requirements, with • number of Fine Grained Statements included • number of EuroRec Baskets with this GPR selected • view icon on indexes • display icon of links and indexes • icon enabling the user to give comments • view icon on the translations • maintenance icon

20. 16. Multilingual Good Practice Requirement Example of Good Practice Requirement in English, Bulgarian, German, Danish, French, Dutch, Romanian and Slovenian

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

22. 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. 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.

23. For Q-REC repository managers • Manage users and authorisations • Enter or importing statements • Maintain indices • Manage cross-references For Q-REC classifiers • Search for statements using multiple index terms • Index statements • Cross-reference similar statements • Compose new FGS or GPR based on existing statements For end users • Browse statements through EuroRec Profiles • Search for statements using multiple index terms • Export query results • Save personal profiles and searches

24. EuroRec stakeholders(possible 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

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

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

28. To have a “base” level set of functions (minimum baseline requirements) that can be accredited across Europe, which 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; A European Seal

29. Not all EHR functions can - at present - be harmonised across the European Community: Specific reimbursement systems; Language specific issues; Differences in available drug- and other databases; Even sometimes different options regarding evidence based issues ! First set of criteria will therefor mainly focus on what is really essential and thus be related to “generic” aspects of “the trustworthiness of the content of an EHR”. Content of the Seal (1)

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

31. The GPR with most selected FGS

32. Important but not selected

34. I thank you for your attention! www.eurorec.org Georges.DeMoor@UGent.be