This was the prezo for the EMBC 2013 tutorial in Osaka, Japan. Intended for an introduction to the standards and technicalities and implementation of openEHR - which is the original formalism.

1. Implementation and Use of ISO EN
13606 and openEHR
Koray Atalag MD, PhD, FACHI
k.atalag@auckland.ac.nz

2. About
National Institute for Health Innovation (NIHI)
The University of Auckland
Private Bag 92019, Auckland
New Zealand
Koray Atalag, MD, PhD, FACHI
Medical Doctor, PhD Information Systems
Fellow of Australasian College of Health Informatics
Chair openEHR New Zealand
openEHR Localisation Program Leader
HL7 New Zealand Board Member
Health Informatics New Zealand Executive Member
ISO TC215 Working Group Member

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

4. 0
1000
2000
3000
4000
5000
6000
7000
8000
9000
1980 1984 1988 1992 1996 2000 2004 2008
US ($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–2010
Adjusted for Differences in Cost of Living
4
Dollars ($US)
THE
COMMONWEALTH
FUND* 2009

5. 5
99 97 97 96 95 94
72
46
68
37
98 98 97 97
92
88
82
69 67
56
41
0
20
40
60
80
100
NETH NOR NZ UK AUS SWE GER US FR CAN SWIZ
2009 2012
Source: 2009 and 2012 Commonwealth Fund International Health Policy Survey of Primary Care Physicians.
Percent
GPs Use of Electronic Medical Records
in Their Practice, 2009 and 2012

7. 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 be
maintained between systems.
(This includes maintaining/conveying
information such as user roles between systems)
(HL7 Inc.)

8. Read
The Standards Solar System
HL7
V3V2
SNOMED
ICD10
IHE
UML
openEHR
ISO Data Types
UMLS
ASTM
DICOM
HISA
CEN TC251
EN13606
ICD9CM
CDA
CCR

10. 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
summary
exchange
• Main divergence
– Reference Model

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

13. 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 layer
Driven by Archetypes in run-time
High level semantics delegated to terminology

14. Multi-Level Modelling

15. 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 EHR
e.g. per episode, per clinical speciality
Sections Clinical headings reflecting the workflow
and consultation/reasoning process
Clusters Compound entries, test batteries
e.g. blood pressure, full blood count
Elements Element entries: leaf nodes with values
e.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

16. openEHR Reference Model

17. Example: DV_TEXT Data Type

18. Healthcare Specific Aspects of RM

19. Top Level Organisation of EHR

20. Unit of Contributions to EHR

21. Anatomy of an
Archetype

22. Archetype Definition Language (ADL)
OCL
+
DDL

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

24. Archetype Query Language (AQL)
SELECT
o/data[at0001]/events[at0002]/time, o/data[at0001]/ev
ents[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]

25. Localisation
Content definition is language independent

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

29. Towards EHR in New Zealand
• Core health information available electronically
by 2014 – no EHR speak ;)
• National planning, regional implementations
• Shared Care and PrimarySecondary
– 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

30. HISO 10040 Health Information
Exchange
10040.1
R-CDRs
XDS
10040.2
CCR
SNOMED CT
Archetypes
10040.3
Documents
CDA

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

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

36. Usage of the Content Model

37. Creating CDA Payload

38. 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
Map
To
Content
Model
System B
Data Source B
Native openEHR Repository
Secondary Use
Map
To
Content
Model
Automated Transforms
No Mapping

39. Shared Health Information Platform (SHIP)

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

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

42. PREDICT CVD Decision Support System

43. PREDICT Dataset Definitions

44. Current PREDICT Model

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

47. PREDICT extensions  ECM

48. NZ Cardiac
Registry
(ANZACS-QI)

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

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

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

52. An Important “bottleneck”
• Cognitive friction /limits to
human communication
• Unknown requirements
• Wrong requirements
Changing requirements?

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

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

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

56. MST Organization

57. Endoscopic
Observation / Procedure
Heading
Term
Attribute
Value
Site
MST Findings for Duodenum
MST Hierarchy
MST Structure

59. 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 Directivesoperational
templates (XML)
• Creates GUI automatically, validates and persists
user entered data
• Also extended model beyond MST to include
vitals & adverse reactions – hard stuff!

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

62. SDE Parser
OPT
Reference
Model
Skeleton Instance
(ENTRY types, CLUSTERS)
GUI Form: Widgets+Leaf nodes(ELEMENT)
SDE GUI
Generator
AOM Representation

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

65. Maintainability Assessment
– Maintenance vs. maintainability
– ISO/IEC 9216 and 25000 Software Quality std.
– External QualityMaintainability 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

66. Maintainability Assessment
No 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 Ext
MST: Findings (stomach): add term rapid urease test | add attribute result | add
attribute values positive and negative
30 5 45 37
3 Fix
MST: Findings (stomach and colon>protruding lesions>tumor/mass): add attribute:
Diameter | change attribute value diameter in mm.  in mm.
50 13 92 2
4 Ext
MST: Findings (colon>protruding lesions>hemorrhoids): add new attribute type and
add attribute values Internal and External
30 7 46 23
5 Fix MST: Therapeutic procedures (Sphincterotomy>Precut): add attribute value No 6 5 1 4
6 Ext
MST: Therapeutic procedures (Thermal therapy>Device): add attribute value Heat-
probe
11 5 1 4
7 Ext
MST: 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 New
Other: 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 GastrOS
MCthe changes were on average 7 times less complex

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

68. 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
Document
Validates
Continued…

69. CDA
(CCD) CDA R2
ValidatesopenEHR
CEN
13606
Archetype based standard XSL Transform
Template
Data
Document
Standard Transform for CCD
openEHR Display

70. Challenges for Implementing CDA R2
messaging
HealthServicesVendorSystems
HL7 V2 Messaging
HealthServicesVendorSystems
• Well understood
• Lots of expertise
• Many tools for V2 integration
• Many systems natively support V2
messaging at some level

71. Challenges for Implementing CDA R2
messaging
HealthServicesVendorSystems
CDA R2 Messaging
HealthServicesVendorSystems
• Less well known/understood
• Highly abstract schema – complex to express
semantics
• Little expertise
• Few tools
• Expensive to re-engineer systems to natively
support CDA

72. A practical first step
HealthServicesVendorSystems
CDA R2
HealthServicesVendorSystems
• 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
Highly
abstract schema

73. 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
HL7openEHR/13606
Makes terminology WORK!

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