Georges De Moor, MD, PhD « Electronic Health Record systems’ Quality Labelling and Certification And Validation of Clinical Archetypes » Georges De Moor,

Georges De Moor, MD, PhDGeorges De Moor, MD, PhD

« Electronic Health Record systems’

Quality Labelling and Certification

And Validation of Clinical Archetypes »

Georges De Moor, MD, PhD

Gent University, Gent, Belgium

EuroRec President

(Copenhagen, 5 November 2008)

Georges De Moor, MD, PhDGeorges De Moor, MD, PhD

EuroRec (http://www.eurorec.org )

• The « European Institute for Health Records »

• A European not-for-profit organisation (April 16, 2003)

• Mission: the promotion of high quality Electronic Health Record systems (EHRs) in Europe

• Federation of National ProRec Centres (all types of stakeholders)

Georges De Moor, MD, PhD Vienna, 23/10/2007

Established

ProRec Centers

Belgium

Bulgaria

Denmark

France

Italy

Germany

Ireland

Romania

Slovenia

Spain

Slovakia

Serbia

(UK)

“ Differences in languages, cultures and HC-delivery/funding systems ”


Contacts and Liaison

BT and TC 251 TC 215

DG INFSO

IHTSDO


The QREC project: Main Objective

To develop formal methods and to create a mechanism for the quality labelling and certification of EHR systemsin Europe (in primary- and in acute hospital-care settings)

EuroRec Institute is coordinating partner QREC has 12 partners and 2 subcontractorsProject duration is 30 months (1/1/2006-30/6/2008)


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.


EHR systems

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)

« The boundaries between EHR systems are fading away… »


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 and more structured and coded

• Intelligent (cf. decision support)


EHRs: Secondary Uses (examples)

User / Clinician

re-use

ClinicalTrial Safety and

Adverse event

Register

EHR

Decision Support

UtilisationReview

MarketingBillingt2 t4

t5

t6

t3

KnowledgeMgmt

Platform

t1 (de-identification)

Patient


QREC: ORIGIN

Several EU-member states (Belgium, Denmark, UK, Ireland,France …) have already proceeded since years with (EHRs-) quality labelling and/or certification (more often in primary care) but these differ in scope, in legal framework under which they operate, in policies and organisation, and perhaps most importantly in the quality and conformance criteria used for benchmarking …

These differences represent a richness but also a risk: harmonisation efforts should help to avoid further market fragmentation in Europe


EuroRec’s Central Repository and Tools

EuroRec has installed a central repository of « validated » quality criteria and other relevant materials and has developed tools that can be used to harmonise quality labelling, product documentation and procurement specification of EHR systems.

EuroRec will not impose particular certification models or 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.


EHRs Criteria: just a few Business Cases

• An e-Health programme wishing to implement quality labelling or certification as to ensure consistent EHR system functionality nationally

• A purchaser wishing to procure an EHR system module

• A vendor/developer wishing 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


Benefits for the Stakeholders

Industry

EHRs - Quality Labelling / Certification

Market ( R.O.I.)

Quality and Safety Efficiency of HC Delivery Systems

Health Services Management

Patients, Clinicians

Public HealthHealth Authorities


Pressure

New functions

New instruments

€1

2

3

4


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 ensuring interoperability with other systems

- Certification of EHRs is essential for buyers and 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!)


Methodology for the Repository Design

1. Typology of EHR system statements (the quality criteria)2. Generic information model for the repository3. Design of indices (indexing system, ontology)4. Planning of the repository management workflow5. Design of web-based user interface requirements

• 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



Typology of EHR System Statements• Source Statements/ Referenced Statements (RS)

– faithfully extracted from 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



Typology of IndexesMultiple 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)

•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

•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

•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

•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

•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

Component Types

Care Settings

Business Functions


Good Practice Requirements - Links



EuroRec Languages (non-exhaustive list)

• English (default language)• Bulgarian• Danish• Dutch• French• German• Italian• Romanian• Slovakian• Slovenian• Serbian



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 Baskets for Certification, Documentation and/or Procurement purposes.


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


TestProcedures

EuroRecBaskets

Certification Documentation Procurement

TestScenarios

Test Criteria

Sets

EuroRecRepository

ofStatements

Composer

ProcurerDocumenter

Certifier

Scripter

EuroRec Use Tools


Other EuroRec Activities and Services

1. An Inventory of Certification Criteria for EHR systems

2. An Inventory of Standards relevant for EHR systems

3. EHR Archetype validation

4. Open Source Components and XML Schemas

5. EHR Tutorials

6. Register of Health Coding Systems in use in Europe

7. Events


How to Manage Certification? EuroRec open for Multiple Options:

1. Authority: Government (or mandated subcontr.) vs. Non Gov.

2. National based vs. Pan European (or joint, cf. specific/generic)

3. Mandatory vs. voluntary (with or without incentives)

4. Formal audit/testing vs. self-assessment (or pre-test assessment)

5. Scoring/rating scheme: pass/fail or more graded approach

6. Scheme review rate (1,2,…n year cycles)

7. Quality Assurance vs. Quality Improvement focus


EuroRec at your Service !

1. Developing & maintaining a central repository with quality criteria

2. Developing tools: certification, procurement and product doc.

3. Providing guidance and assistance to all stakeholders

4. Assisting Authorities in introducing / adopting certification

5. Training and accreditation of surveyors (European level)

6. Set-up of certification session (incl. scenario scripting/operations)

7. Continous & total Q.A. of processes and procedures


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


• 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)



• 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…)


Georges De Moor, MD, PhD 13 mei 2008

Page 34


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.


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


Content of the Seal (2)

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


The GPR with most selected FGS


EHR Q TN: a new Project Proposal

Thematic Network on Quality Labelling andCertification of EHR Systems


28 Partners

24 Countries

Belgium

Austria

Bulgaria

Slovakia

Cyprus

Croatia

Denmark

Estonia

France

Germany

Greece

Hungary

IrelandItaly

Luxembourg

Netherlands

Norway

Poland

Portugal

Romania

Serbia

Slovenia

Spain

United Kingdom

Beneficiaries


1. Validate and Customise the EuroRec criteria on e- prescription and patient summary in 24 countries

2. Database of stakeholders (incl. EHRs vendors)

3. Inventory of legal issues

4. Local coordination & education

5. Annual EHR-QTN International Conferences

6. Five Regional EHR-QTN Conferences EHR-QTN (Mediteranian, Eastern, Central, Western and Nordic regions)

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


Clinical archetypes are a formal, rigorous and standardised (interoperable) specification for an agreed consensus or best practice representation of clinical data structures (within an electronic health record). They provide a standardised way of specifying EHR clinical data hierarchies and the kinds of data values that may be stored within each kind of entry. An archetype defines (or constrains) relationships between data values within an EHR data structure, expressed as algorithms, formulae or rules.

ISO/EN13606 Definition of Archetype


Patient safety management and 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 services and the support of public health and clinical research through 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.


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.


openEHR Semantic architecture


When authoring an archetype, additional details need to be provided about each node such as the number of occurrences that are permitted within instances of EHR data, the terminology values that may be used, numeric ranges and measurement units.

Schematic diagram of an archetype for adverse reaction (to medication)


• Enterprise viewpoint will contain the use case, i.e. the standardised work process;

• Information viewpoint contains the Message Information Model;

• Computational viewpoint is about the choreography of messages in the interaction schemas;

• Engineering viewpoint is the level where the XML schema is defined.

Messages: “an older way to support semantic interoperability”


Archetypes and templates can play a key role in semantic interoperability.

Archetypes define what is maximally documented in the world about a specific health record entity. An archetype defines a data structure, including optionality and multiplicity, data value constraints, and relevant bindings to natural language and terminology systems.

Templates define what in a specific context at a specific point in time, will be stored, retrieved, presented, exchanged and archived.

In part, clinical meaning within an EHR will be expressed through the structure of the archetype/template, and in part the meaning will be expressed through codes from coding systems

Archetypes and Templates


A way to view this metaphorically is:

Archetypes and Templates

•codes are the words in a dictionary;•the structure of the archetype/template is the grammar;•with both codes and archetypes sentences can be formed that make

or do not make sense;•but archetypes define what makes sense;•and templates define what makes sense in a specific context.


To support semantic interoperability clinical archetypes need to be shared and used consistently by EHR system vendors and their users, so that the EHR data they create is consistently organised. Archetypes therefore need to be shared and managed as a common knowledge asset, and incorporated into the design of clinical applications, rather like a terminology system.


Given that many archetypes may be needed to cover a given domain, it is also important for them to be mutually consistent and bind to terminology systems in appropriate and consistent ways. This is necessary in order to minimise the diversity of ways in which a given kind of EHR data might be represented.


Clinical archetypes need to be quality assured, since they will direct the ways in which clinical data are captured, processed and communicated. It is important that the design of individual archetypes is an accurate and faithful reflection of good practice for the clinical disciplines in which each of them might be used.They need to be optimally designed for their purpose, and considered trustworthy within their intended communities of use.

Large and comprehensive sets of archetypes are needed that cover whole clinical domains in a systematic and inclusive way, catering for the inevitable diversity of use cases and users but helping to foster consensus and best practice. For these to be endorsed by health systems, implemented by vendors and trusted by end users, these archetypes need to be quality assured and to be published and maintained by reliable certified sources.


• Certification is a powerful weapon: use it!

• Continuity of certification should be guaranteed (credibility issue)

• Efficiency: do not (re-) invent the wheel

• Take advantage of the growing EuroRec repository and of the broadening certification scope (e.g. EHRs in other settings and other software applications) resulting from European investments

• Align choices & strategies with European and International ones (cf. standards, coding systems ...)

• Professionalize the certification procedures

• Build a long term, incremental and consistent certification roadmap which is in harmony with your overall healthcare strategy

• ...EuroRec is your partner and is at your service !

Some Conclusions

Georges De Moor, MD, PhD « Electronic Health Record systems’ Quality Labelling and Certification And Validation of Clinical Archetypes » Georges De Moor,

Documents

phd vienna

phd qrec

europe slide

phd contacts

primary care

certification of ehr

phd eurorec http

care pathway