This one I presented at the HINZ conference 7-9 Nov 2012 at Rotorua, New Zealand. ABSTRACT: As we are moving into new paradigms of care, sharing of health information becomes crucial. We need new systems and more interconnectivity to support this. The regional approach to eHealth solutions in New Zealand hinges on establishing trusted and interoperable systems. The Interoperability Reference Architecture is a first step towards providing overall principles and standards to reach this goal. A core group from the Sector Architects Group was formed and prepared the first draft of this document. After initial internal feedback it went through wider consultation – including public. Good feedback was received, including international. It then went through formal HISO processes and was approved as a national interim standard. The Reference Architecture comprises three pillars which define: 1) XDS based access to clinical data repositories, 2) a common content model underpinned by CCR and openEHR Archetypes to which all health information exchange should conform, and 3) use of CDA as common currency for payload. A trial implementation is yet to be conducted, however we used the Content Model to align ePrescribing data model with the Australian model in order to validate the methodology. The Reference Architecture will provide an incremental step-by-step implementation approach to interoperability and thus minimise risk.

1. Underpinnings of the
Interoperability Reference
Architecture
(HISO 10040)
Koray Atalag1, Alastair Kenworthy2, David Hay3
1.NIHI – University of Auckland
2.Ministry of Health
3.Orion Health

3. The Problem
• Patient centred integrated/shared care paradigms
hinge on more interconnectivity
• We all know about silos: 1+1 >2 when shared
• It’s all about People, processes and technology
• Standards crucial – but need an overarching framework
– No one size fits all! depends on needs, resources
– Myriad of standards, methods etc.
– Not so much success so far worldwide 
• Narrow opportunity window in NZ to enable sector-
wide consistency & interoperability
(too many projects in-early flight or kicking off)

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

5. State of the nation
• Core EHR by 2014 – are we getting there?
• 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, eMedications
– Medicines reconciliation, specialist CIS
– Others: NZULM, new NHI/HPI
• Good emphasis & support for standards

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

7. HISO 10040 Building Blocks
10040.1 10040.2 10040.3
R-CDRs CCR CDA
XDS SNOMED CT
openEHR
Acknowledge Alastair Kenworthy

9. 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 (aka DCM)
– 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)
* kind of – CCDA may be more appropriate

11. Creating Payload
?

12. ECM Working Principle
Exchange Content Model
Conforms to
Message
Payload
(CDA)
Source System Recipient System
Map Map
Source to Web Service ECM to
ECM Recipient
Exchange
Data
Object
Source data Recipient data

13. Authoring & HISO process
• Initiated & funded by Health Sector Architects Group
(SAG), an advisory group to the NHITB
• 4 co-authors – from Interoperability WG
• Initial feedback from SAG then publish on HIVE
• ABB produced - condensed version of IRA (2011)
• Public comment and evaluation panel October 2011
• Ballot round February 2012
• Interim standard April 2012
• Trial implementation with Northern DHBs, 2012/13

14. Archetypes
• The way to go for defining clinical content
 CIMI (led by S. Huff @ Intermountain & Mayo)
 In many nat’l programmes (eg. Sweden, Slovenia, Australia, Brazil)
• Smallest indivisible units of clinical information with clinical context
• Brings together building blocks from Reference Model (eg. record
organisation, data structures, types)
• Puts constraints on them:
– Structural constraints (List, table, tree, clusters)
– What labels can be used
– What data types can be used
– What values are allowed for these data types
– How many times a data item can exist?
– Whether a particular data item is mandatory
– Whether a selection is involved from a number of items/values

15. Logical building blocks of EHR
EHR
Folders
Compositions
Sections
Entries
Clusters
Elements
Data values

16. BP Measurement Archetype

17. Extending ECM
• Addition of new concepts
• Making existing concepts more specific
– powerful Archetype specialisation mechanism:
– Lab result > HbA1C result, Lipid profiles etc.
Problem First level specialisation
Text or Coded Term Diagnosis Second level specialisation
Clinical description
Date of onset Coded Term Diabetes
Date of resolution + diagnosis
No of occurrences Grading +
Diagnostic criteria Diagnostic criteria
Stage  Fasting > 6.1
 GTT 2hr > 11.1
 Random > 11.1

18. ECM > HIE Payload

19. Case Study: Medication
• Essential to get it right – first in patient safety!
• Single definition of Medication will be reused in many
places, including:
– ePrescribing
– My List of Medicines
– Transfer of care
– Health (status & event) summary
– Specialist systems
– Public Health / Research
• Currently no standard def in NZ
(coming soon 10043 Connected Care)
• NZMT / NZULM & Formulary > bare essentials

20. Current state & projects
• PMS: each vendor own data model
• GP2GP: great start for structure
• NZePS: started with propriety model, now waiting
for standard CDA.
– PMS vendors implementing Toolkit based Adapter
• Hospitals: some using CSC MedChart
• Pharmacies?
• Others?
 Actually we’re not doing too bad 

21. Why bother?
(with a standard structured Medication definition)
“If you think about the seemingly simple concept of
communicating the timing of a medication, it readily
becomes apparent that it is more complex than most
expect…”
“Most systems can cater for recording ‘1 tablet 3 times a
day after meals’, but not many of the rest of the
following examples, ...yet these represent the way
clinicians need to prescribe for patients...”
Dr. Sam Heard

22. Medication timing
Dose frequency Examples
every time period …every 4 hours
n times per time period …three times per day
n per time period …2 per day
…6 per week
every time period range …every 4-6 hours,
…2-3 times per day
Maximum interval …not less than every 8 hours
Maximum per time period …to a maximum of 4 times per
day
Acknowledgement: Sam Heard

23. Medication timing cont.
Time specific Examples
Morning and/or lunch and/or …take after breakfast and
evening lunch
Specific times of day 06:00, 12:00, 20:00
Dose duration
Time period …via a syringe driver over 4
hours
Acknowledgement: Sam Heard

24. Medication timing cont.
Event related Examples
After/Before event …after meals
…before lying down
…after each loose stool
…after each nappy change
n time period before/after …3 days before travel
event
Duration n time period …on days 5-10 after
before/after event menstruation begins
Acknowledgement: Sam Heard

25. Medication timing – still cont.
Treatment duration Examples
Date/time to date/time 1-7 January 2005
Now and then repeat after n …start, repeat in 14 days
time period/s
n time period/s …for 5 days
n doses …Take every 2 hours for 5 doses
Acknowledgement: Sam Heard

26. Medication timing – even more!
Triggers/Outcomes Examples
If condition is true …if pulse is greater than 80
…until bleeding stops
Start event …Start 3 days before travel
Finish event …Apply daily until day 21 of
menstrual cycle
Acknowledgement: Sam Heard

27. Modelling Medication Definition
• NZePS data model (v1.9) & draft 10043
Connected Care CDA templates
• Start from Nehta ePrescribing model
– Analyse models and match data elements
– Extend where necessary as per NZ requirements
• Add new items or rename existing
• Tighter constrains on existing items (e.g.
cardinality, code sets, data types)

29. Nehta Medication Model

31. Results & Outlook
• Extended model 100% covering NZePS
(community ePrescribing)
• Must consider secondary care
• Need to look in more detail:
– Consolidated CDA
– epSoS (European framework)
– Other nat’l programmes
• Generate Payload CDA using transforms

32. Value Proposition
• Content is ‘clinician’s stuff’ – not techy; yet most existing standards are
meaningless for clinicians and vice versa for techies
– Archetypes in ‘clinical’ space – easily understood & authored by them
• Single source of truth for entire sector
– One agreed way of expressing clinical concepts – as opposed to
multiple ways of doing it with HL7 CDA (CCDA is a good first step)
• Archetypes can be transformed into numerous formats – including CDA
• Archetypes are ‘maximal datasets’
– Much easier to agree on
• Scope not limited to HIE but whole EHR; workflow supported
• ECM principle invest in information fulfilled completely
– future proof content today for tomorrow’s implementation technology
(e.g. FHIR etc., distributed workflows etc.)

33. Thank you – Questions?
Empowered by openEHR - Clinicians in the Driver’s Seat!