Implementation and Use of ISO EN 13606 and openEHR

Koray Atalag MD, PhD, FACHIk.atalag@auckland.ac.nz

About

National Institute for Health Innovation (NIHI)The University of AucklandPrivate Bag 92019, AucklandNew Zealand

Koray Atalag, MD, PhD, FACHI

Medical Doctor, PhD Information SystemsFellow of Australasian College of Health Informatics

Chair openEHR New ZealandopenEHR Localisation Program LeaderHL7 New Zealand Board MemberHealth Informatics New Zealand Executive MemberISO TC215 Working Group Member

New Zealand Quick Facts

• Population: 4.5million – (~20% Maori & Pacific)– <30 million sheep >60 million cattle!

• GDP (PPP) per Capita: USD 28,800• Good healthcare, low cost• High IT adoption, good integration• Single health identifier ~20 years• National eHealth strategy and plan

– National Health IT Board

1980

1982

1984

1986

1988

1990

1992

1994

1996

1998

2000

2002

2004

2006

2008

2010

0

1000

2000

3000

4000

5000

6000

7000

8000

9000US ($8,233)

NOR ($5,388)

SWIZ ($5,270)

NETH ($5,056)

DEN ($4,464)

CAN ($4,445)

GER ($4,338)

FR ($3,974)

SWE ($3,758)

AUS ($3,670)*

UK ($3,433)

JPN ($3,035)*

NZ ($3,022)

Source: OECD Health Data 2012.

Average Health Care Spending per Capita, 1980–2010Adjusted for Differences in Cost of Living

4

Dollars ($US)

THECOMMONWEALTH

FUND* 2009

5

NETH NOR NZ UK AUS SWE GER US FR CAN SWIZ0

20

40

60

80

100 99 97 97 96 95 94

72

46

68

37

98 98 97 9792

8882

69 67

56

41

2009 2012

Source: 2009 and 2012 Commonwealth Fund International Health Policy Survey of Primary Care Physicians.

Percent

GPs Use of Electronic Medical Recordsin Their Practice, 2009 and 2012

Types of Interoperability Technical Interoperability: systems can send and receive data successfully.

(ISO: Functional/Data Interoperability)

Semantic Interoperability: information sent and received between systems is unaltered in its meaning. It is understood in exactly the same way by both the sender and receiver.

Process Interoperability: the degree to which the integrity of workflow processes can bemaintained between systems. (This includes maintaining/conveying information such as user roles between systems)

(HL7 Inc.)

Read

The Standards Solar System

HL7V3V2

SNOMED

ICD10

IHE

UML

openEHR

ISO Data TypesUMLS

ISO13606

ASTM

IHE

DICOM

HISA

CEN TC251EN13606

OMG

OHT

ICD9CM

CDA

CCR

ISO EN 13606 & openEHR• 13606 is a subset of openEHR specification

– Snapshot ~2008-2010– Update in progress (sync w/ openEHR)

• Not a full EHR standard– for health

summaryexchange

• Main divergence– Reference Model

Open source specs & software for representing health information and person-centric records– Based on 18+ years of international implementation experience

including Good European Health Record Project– Superset of ISO/CEN 13606 EHR standard

Not-for-profit organisation - established in 2001 www.openEHR.org

Extensively used in research Separation of clinical

and technical worlds• Big international community

Key Innovations

“Multi-level Modelling” – separation of software model into distinct layers:

1) Technical information model (generic)

2) Concept models: Archetypes (domain-specific)

3) Terminology/Ontology (SNOMED etc.)

Software code is based on only the first layerDriven by Archetypes in run-timeHigh level semantics delegated to terminology

Multi-Level Modelling

Logical building blocks of EHR

Compositions Set of entries comprising a clinical care session or document e.g. test result, letter

EHR The electronic health record for one person

Folders High-level organisation of the EHRe.g. per episode, per clinical speciality

Sections Clinical headings reflecting the workflowand consultation/reasoning process

Clusters Compound entries, test batteriese.g. blood pressure, full blood count

Elements Element entries: leaf nodes with valuese.g. reason for encounter, body weight

Data values Date types for instance values e.g. coded terms, measurements with units

Entries Clinical “statements” about Observations,Evaluations, and Instructions

openEHR Reference Model

Example: DV_TEXT Data Type

Healthcare Specific Aspects of RM

Top Level Organisation of EHR

Unit of Contributions to EHR

Anatomy of an Archetype

Archetype Definition Language (ADL)

OCL

+

DDL

Archetype based Queries• Path-based – not brute-force like SQL• Archetypes provide ‘map’ to data items• Use ‘clinical-speak’ rather than ‘tables/fields’ etc.

openEHREHR

Archetype Query Language (AQL)

SELECT o/data[at0001]/events[at0002]/time, o/data[at0001]/events[at0002]/data[at0003]/items[at0013.1]/value

FROM Ehr[uid=@EhrUid] CONTAINS Composition c[openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS Observation o[openEHR-EHR-OBSERVATION.laboratory-lipids.v1]

LocalisationContent definition is language independent

State of the world

• US: advanced provider-centric systems but little inter-connectivity (HL7 v2/CDA)

• Canada: CHI providing leadership & standards (v2/v3/CDA)

• UK: bootstrapping from CfH disaster, focus on high value/established systems (HL7/13606)

• Nordic: well established, (↑13606 / HL7 v2/CDA)

• EU: very patchy – HL7/↑13606/openEHR

• Asia: patchy -propriety / HL7 / little 13606/openEHR

• Brazil/Paraguay: mainly openEHR & HL7 v2/CDA

• Australia: Nehta/PCEHR, v2/v3/CDA & openEHR

Towards EHR in New Zealand

• Core health information available electronically by 2014 – no EHR speak ;)

• National planning, regional implementations• Shared Care and PrimarySecondary

– Shared care projects: long term conditions, maternity, well child etc.

• Clinical Data Repository (CDR) as enabler

– GP2GP, Transfer of Care– ePrescribing & medicines reconciliation– Others: NZULM, new NHI/HPI

• Good emphasis & support for standards

HISO 10040 Health Information Exchange

10040.1R-CDRs

XDS

10040.2 CCR

SNOMED CTArchetypes

10040.3Documents

CDA

The Principles

1. Align to national strategy: as per national and regional plans

2. Invest in information: use a technology agnostic common content model, and use standard terminologies

3. Use single content model: information for exchange will be defined and represented in a single consistent way

4. Align to business needs: prioritise the Reference Architecture in line with regional and national programmes

5. Work with sector: respect the needs of all stakeholders

6. Use proven standards: adopt suitable and consistent national and international standards wherever they exist (in preference to inventing new specifications)

7. Use a services approach: move the sector from a messaging style of interaction to one based on web services

What is ECM?

• IT IS A REFERENCE LIBRARY - for enabling consistency in HIE Payload

• Superset of all clinical dataset definitions – normalised using a standard EHR record organisation (openEHR)– Expressed as reusable and computable models – Archetypes

• Top level organisation follows CCR• Further detail provided by:

– Existing relevant sources (CCDA, Nehta, epSoS, HL7 FHIR etc.)– Extensions (of above) and new Archetypes (NZ specific)

• Each HIE payload (CDA) will correspond to a subset (and conform)

Usage of the Content Model

Creating CDA Payload

Exploiting Content Model for Secondary Use

Single Content Model

CDA

FHIR

HL7 v2/3

EHR Extract

UML

XSD/XMI

PDF

Mindmap

PAYLOAD

System A

Data Source A

MapTo

Content Model

System B

Data Source B

Native openEHR Repository

Secondary Use

MapTo

Content Model

Automated Transforms

No Mapping

Shared Health Information Platform (SHIP)

Implementation Examples

• PREDICT CVD Risk Prediction and Management System (NZ)– Primary care Decision Support System– Secondary use: research database

• NZ Cardiac Events Registry– Extending PREDICT to hospitals– Also secondary use like PREDICT

• GastrOS Endoscopy Reporting System (NZ)– Clinical Information System

PREDICT & Cardiac Registry

• Fully fledged CDSS + research database + clinical QI– Extending to secondary (acute Predict)– Improving risk prediction models– Creating a variation map/atlas of NZ

• Data linkages to:– National Mortality Register, – National Minimum Dataset (public and private hospital

discharges)– National Pharmaceutical Collection (drugs dispensed from

community pharmacies with government subsidy)– National PHO Enrolment Collection– Regional CVD-relevant laboratory data

PREDICT CVD Decision Support System

PREDICT Dataset Definitions

Current PREDICT Model

Results Archetype based content model can faithfully represent

PREDICT dataset• Modelling:

– two new archetypes‘Lifestyle Management’ and ‘Diabetic Glycaemic Control’ checklists

– NZ extensions for demographics (DHB catchment, meshblock/domicile, geocode NZDep)

• Difficulty: overlap between openEHR and NEHTA repositories – different archetypes for tobacco use, laboratory results and diagnosis which we reused– Considering both repositories are evolving separately it is

challenging to make definitive modelling decisions.

PREDICT extensions ECM

NZ Cardiac Registry(ANZACS-QI)

GastrOS – Endoscopy Reporting

Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical Information Systems using openEHR. Stud Health Technol Inform. 2011;169:849–53.

http://gastros.codeplex.com

Study Context• Maintaining software in healthcare is hard!

– Real world experience: endoscopy reporting application– Almost entirely driven by MST – standard domain terminology

(Minimal Standard Terminology for Digestive Endoscopy – version 2)

• Essence of problem:– Biomedical ‘stuff’ is volatile– hardcoding domain knowledge into sofware (code + DB)

• New Model Driven Development – using openEHR– Archetype modelling + Defined GUI directives – Extended openEHR.NET library (Ocean Informatics)– Formal comparative evaluation of the ‘old’ and ‘new’ system– ALL Open Source http://gastros.codeplex.com

http://openehr.codeplex.com

Maintenance of HIS

• Constitutes the majority of development costs• Degrades overall quality / longevity / satisfaction• Source of problem change in domain related

requirements (mostly functional)• How?

– Incomplete / wrong req. at outset– New / no longer valid requirements

• Why?– Essential + handover– Volatility of domain concepts & processes

An Important “bottleneck”

• Cognitive friction /limits to human communication

• Unknown requirements

• Wrong requirements

Changing requirements?

“handover”

Research Questions

• Is openEHR implementable at all? Feasible?(for our specific requirements)

• How to create usable GUI?• Is it bad to hardcode domain knowledge into

software (code + DB)• Can software evolve without (significant)

techy intervention? To what extent?• Any other challenges?

Research Domain

• Gastroenterologic Endoscopy– A small and manageable (niche) domain– Visualisation of the gastrointestinal tract for both

diagnostic and therapeutic purposes– Quite invasive procedure results need to be

reliable, complete and unambiguous – Good level of common medical language – Worldwide accepted terminology

Minimal Standard Terminology for Digestive Endoscopy (MST)

– Initiated by the European Society for Gastrointestinal Endoscopy (ESGE) in 1990

– Joined by the Japanese endoscopy association – Now official terminology for World Society of Gastro-

intestinal Endoscopy (OMED)– A "minimal" list of terms for use in computer system

used to record the results of a gastrointestinal endoscopy

– Validation in EU project – GASTER and an US project– Already integrated with the NLM’s Unified Medical

Language System (UMLS)– Eleven language translations (inc. Japanese)

MST Organization

EndoscopicObservation / Procedure

Heading

Term

Attribute

Value

Site

MST Findings for Duodenum

MST Hierarchy

MST Structure

Implementation Methodology

• GastrOS: Windows forms app using .Net/C#• A basic ‘Wrapper’ + SDE component • openEHR.Net: Release 1.0.1 RM & AOM• Templates with GUI Directivesoperational

templates (XML)• Creates GUI automatically, validates and persists

user entered data• Also extended model beyond MST to include

vitals & adverse reactions – hard stuff!

GUI Directives

• Archetypes & Templates only to do with structure + semantics of health information

• Need to define presentation aspects• Majority thinks a separate model for that• We don’t:

– hard to separate at times– Archetypes expected to change rapidly so maintaining a

separate model might be hard– Perhaps with good tooling might work

• We exploited Template Annotations

SDE ParserOPT

ReferenceModel

Skeleton Instance(ENTRY types, CLUSTERS)

GUI Form: Widgets+Leaf nodes(ELEMENT)

SDE GUI Generator

AOM Representation

Conclusions

• Is openEHR implementable at all? Feasible?(for our specific requirements) YES

• How to create usable GUI? Described• Is it bad to hardcode domain knowledge into

software (code + DB) DEFINITELY• Can software evolve without (significant) techy

intervention? To what extent? Cautious Yes• Any other challenges? need more time!!!

Maintainability Assessment– Maintenance vs. maintainability– ISO/IEC 9216 and 25000 Software Quality std.– External QualityMaintainability characteristic; Changeability

Subcharacteristic – Two metrics: (mainly look at maintenance tasks)

• Change cycle efficiency (CCE)time from initial request to resolution of the problem

• Modification complexity (MC)sum of time spent on each change per size of software change divided by total number of changes

– 10 CR – real ones from GST usage– SVN + JIRA tools for documentation + measure

Maintainability AssessmentNo Type Description

Time (min)Changed

LOC

GST GastrOS GST GastrOS

1 Fix MST: Anatomic site (colon): add site anal canal 3 10 1 83

2 ExtMST: Findings (stomach): add term rapid urease test | add attribute result | add attribute values positive and negative

30 5 45 37

3 FixMST: Findings (stomach and colon>protruding lesions>tumor/mass): add attribute: Diameter | change attribute value diameter in mm. in mm.

50 13 92 2

4 ExtMST: Findings (colon>protruding lesions>hemorrhoids): add new attribute type and add attribute values Internal and External

30 7 46 23

5 FixMST: Therapeutic procedures (Sphincterotomy>Precut): add attribute value No

6 5 1 4

6 ExtMST: Therapeutic procedures (Thermal therapy>Device): add attribute value Heat-probe

11 5 1 4

7 ExtMST: Diagnoses (stomach): add main diagnoses Antral superficial, Pangastritis, Atrophic, Alkaline reflux and Somatitis

6 8 4 20

8 Ext MST: Diagnoses: Add free text description for each organ 50 10 60 20

9 NewOther: Split lower gastrointestinal examination type into colonoscopy and rectoscopy. Bind both types to Findings for colon

30 10 6 2

10 New Other: Localise MST Findings for Stomach form to English 1116 70 722 499

TOTAL 1332 143 978 694

Metric GST GastrOS

CCE 133.20 14.30

MC 0.14 0.02

CCE 9 times less effort overall to modify GastrOSMCthe changes were on average 7 times less complex

Questions?k.atalag@nihi.auckland.ac.nz

Automatic Production of CDA R2 using openEHR Archetypes and Templates

openEHR Standarised Semantic Environment

Client Data

Client Schema

Validates

Client Systems

Archetypes

Templates

Implementation Standardised XML Environment

Template Data

Schema

Generate from Tools

Template Data

DocumentValidates

Continued…

CDA(CCD) CDA R2

ValidatesopenEHR CEN13606

Archetype based standard XSL Transform

Template Data

Document

Standard Transform for CCDopenEHR Display

Challenges for Implementing CDA R2 messaging H

ealth Services\Vendor Systems

HL7 V2 Messaging

Hea

lth S

ervi

ces\

Vend

or S

yste

ms

• Well understood• Lots of expertise• Many tools for V2 integration• Many systems natively support V2

messaging at some level

Challenges for Implementing CDA R2 messaging H

ealth Services\Vendor Systems

CDA R2 Messaging

Hea

lth S

ervi

ces\

Vend

or S

yste

ms

• Less well known/understood• Highly abstract schema – complex to express

semantics• Little expertise• Few tools• Expensive to re-engineer systems to natively

support CDA

A practical first stepH

ealth Services\Vendor Systems

CDA R2

Hea

lth S

ervi

ces\

Vend

or S

yste

ms

• XML is well understood• XML expertise is common• XML Tools are widely available• Able to be automated • CDA messages conform to an agreed

standardised schema and reduce the need for ‘pre-negotiation’

Translation layer using

standardised XML

transforms

Translation layer using

standardised XML

transforms

Highlyabstract schema

Bottom Line

openEHR is the only means to capture clinical requirements and turn them into computable artefacts

Modelling with Archetypes is ‘standards agnostic’ – no commitment for openEHR implementation pathway

A full blown international standard (13606)Clinical content can be transformed

HL7openEHR/13606Makes terminology WORK!

Recommended Steps for National eHealth Programs

• 1) Develop a set of clinical models in a formalism that is international and computable - openEHR is really the only candidate here. The initial models may only be for those 10 or 20 top pieces of clinical information that need to be shared.

• 2) These models can be used without requiring a commitment to openEHR everywhere by publishing XML schemas that are derived from template based use cases; i.e. GP notes, discharge summary etc.

• 3) XML schemas can be used by vendors without a commitment to openEHR. Data instances that conform to the schemas can be transformed into HL7 messages or openEHR instances.

• 4) These messages can either be consumed by message based systems or converted back into XML data instances that conform to the schemas. This enables everyone to be compliant with only XML skills. There is still a large role for HL7 to in transport related space; not only messaging but also terminology service, identifiers, etc.