The document proposes an interoperability reference architecture (HISO 10040) for New Zealand's health sector to enable consistent and interconnected health information exchange. It outlines principles such as aligning with national strategy, investing in standardized clinical information models, and adopting proven international standards. The reference architecture uses a common clinical content model expressed through archetypes to define clinical concepts in a consistent way. This will allow health information to be exchanged as structured messages between different health IT systems using a service-oriented approach. The goals are to support integrated and shared care through consistent interoperability across the health sector.
Call Girls Jabalpur Just Call 9907093804 Top Class Call Girl Service Available
HISO 10040 Underpinnings of NZ Health Interoperability Architecture
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
2.
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 PrimarySecondary
– 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
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
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
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
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)
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!
Notas del editor
These are the three building blocks – or pillars – of the HISO 10040 series that embodies the central ideas of the Reference Architecture for Interoperability10040.1 is about regional CDRs and transport10040.2 is about a content model for information exchange, shaped by the generic information model provided by CCR, with SNOMED as the default terminology, and openEHR archetypes as the chief means of representation10040.3 is about CDA structured documents as the common currency of exchange – not every single transaction type, but the patient information-laden ones
Published by HISO (2012); Part of the Reference Architecture for Interoperability“To create a uniform model of health information to be reused by different eHealth Projects involving HIE”Consistent, Extensible, Interoperable and Future-Proof Data
Content is ‘clinician’s stuff’ – not techy; yet most existing standards are meaningless for clinicians and vice versa for techiesopenEHR Archetypes are in ‘clinical’ space – easily understood and authored by themArchetypes can be transformed into numerous formats – including CDAArchetypes are ‘maximal datasets’ e.g. They are much more granular than other models when needed. Support more use cases – indeed almost anything to do with EHR (including some workflow). Scope not limited to HIE but whole EHR.One agreed way of expressing clinical concepts – as opposed to multiple ways of doing it with HL7 CDA (CCDA is a good first step though)ECM invest in information fulfilled completely – future proof technology today with ECM for tomorrow’s implementation technology (e.g. FHIR etc., distributed workflows etc.)
... And more
... And more
... And more
Objective of this demo is to show the bottom-up content development approach.Certain Archetypes shared by key HIE (eRef, ePrescribing, PREDICT) undergo an iterative localisation processInternational > Multiple Local projects (added & extended) > Added to ECM