Transcript Archetypes2009

Archetypes in HL7 v2
Andrew McIntyre
Medical-Objects
HL7 International
May 2009
Overview

HL7 v2 in widespread use in Australia




Need for Structured Clinical data





Many legacy applications
Administrative models well covered
Limited support for Clinical Models
SNOMED-CT support
Patient history/Family History transfer
Decision Support
Registries
Archetypes allow detailed Clinical Models


No changes required to standard
Backward compatible
Long-term goals

Support of Complex Clinical Models


Allow reuse of models


Complexity hidden from legacy applications
Common clinical models in use



Represent model in V2/V3/CDA/CCD formats
Smooth migration of legacy applications


No limit on complexity
Allows data transfer across systems
Allows data transfer across encodings
Allow rich SNOMED-CT use

Support post-coordination
The Present Australian
Situation

Clinical Models basic






Blob of text in single OBX
Blob of RTF (un-escaped) in single OBX
Little or No semantic interoperability
Opaque documents eg. PDF
No atomic data, minimal terminology
Pathology Models improving




Atomic data
Terminology (LOINC) in private labs
Hamstrung by unreliable imports of HL7
Many packages lack CE (Coded Entry) support
Development up to present

2006: Archetypes in V2 implementation









Part of Medical-Objects ITOL project
“Lymphoma wizard”
Archetypes for Registry notification
Archetypes for GLIF/GELLO data structures
Total HL7 solution
Experience used to inform standards work
Proven round trip semantic interoperability
CEN Archetypes used
Used for AS4700.2 Lab system with GELLO

Messages are being delivered to existing PMS
systems now
Archetypes

Built on a domain model



Domain model is mappable



CEN 13606 – European Standard
OpenEHR
Existing HL7 V2 data models
Medication/Allergies already exist
Archetype content is mapped to OBX
segments or messages



Existing HL7 semantics are preserved
Existing applications are mostly unaware
Minimal overhead
Archetypes

Describe semantic relationships




Constrain data





Between atomic data items
Between archetypes
Between/within terminologies
Occurrences
Cardinality
Terminology
Datatypes/Constraints
Provide metadata that is lacking



Potential overlap with SNOMED-CT/V3 models
Minimal overlap with V2
Exception is Medications/Allergies
Archetypes

Allow organisations to define data structures






Discharge summaries
Registry notification
Referral requirements/prerequisites
Notifications
EHR notes transfer
Ideally standard Archetypes used



Allow easy interoperability
Some metadata better than none however
Decision support needs flexibility to define its
own custom data structures
Archetype Options

CEN Archetype




Generic structure
Standards based
Developed in conjunction with OpenEHR
OpenEHR




Similar to CEN
Have diverged
Extended semantics that are OpenEHR specific
Not a formal standard
CEN Philosophy
The challenge for EHR interoperability is to devise a
generalised approach to representing every conceivable kind
of health record data structure in a consistent way. This needs
to cater for records arising from any profession, speciality or
service, whilst recognising that the clinical data sets, value
sets, templates etc. required by different health care domains
will be diverse, complex and will change frequently as clinical
practice and medical knowledge advance. This requirement is
part of the widely acknowledged health informatics challenge
of semantic interoperability.
Example Archetypes
Archetype Data Model


An Identifier for the Archetype
A tree of Atomic data elements



Organised by Non Terminal Nodes






Elements map to single OBX
OBX - 4 Observation sub ID used
Nodes usually descriptive
Data does not change
Not required for semantics as can be inferred
Useful for human readers “Headers”
Represented by display OBX segment
Data model is not the same tree as metadata

Occurences > 1 in archetype requires extra
nodes
The HL7 V2 Version
• Archetype Nodes have
– Cardinality
– Occurrences
• The data structure is similar to an xml representation
– Dotted SubID used to build the tree
OBX Tree Structure
• Only nodes that are valued need inclusion
• Missing nodes inferred by Archetype
• Requires receiver to have access to
archetype for Semantic interoperability
Walking the path
OBX|6|NM|163031004^diastolic^SNOMED-CT^at0005^^openEHREHROBSERVATION.blood_pressure.v1|1.1.1.1.1.1.1.1.2|100|mm[Hg]^^I
SO+|||||F
Overview of encoding

Three OBX types:
• Header RP Segment
– OBX|1|RP|ENTRY^^EN 13606|1|openEHR-EHROBSERVATION.blood_pressure.v1^Blood pressure
measurement&99A-A892E160ECDB6613&L^TX^Octetstream||||||F
• Non Terminal OBX
– OBX|6|CE|15431-0^^LN^CLUSTER^^EN
13606|1.1.12|103764000^Non reportable items^SNOMEDCT^at0047^Non reportable items^CEN-FULL-BLOODCOUNT.v1||||||F
• Terminal OBX – “Data”
– OBX|2|NM|14749-6^Glucose^LN^22569008^^SNOMEDCT|1.1.6|7.8|mmol/L^^ISO+|<7.8|+|||F
Potential Alternatives

CDA

Solves problem of inadequate HL7 parsers





Does not solve all semantic issues
Minimal existing CDA support in Australia
Requires overnight upgrade of all pms systems
CCR/CCD




This is small piece of puzzle however
ASTM standard +/- CDA format
?Useful for GP interoperability project
Could be archetyped and carried in V2
Handbooks

Provide detailed Human readable specs

Has not worked to date
Conclusions

Archetypes allow data models to be defined



Requires solid HL7 parsers



Prerequisite for any semantic interoperability
Investment required in low level technology
Standards Compliance



Usable in HL7 V2 and CDA
Archetypes in V2 would allow migration
Would improve quality of existing messages
Allows possibility of taking next step
Common archetypes ideal

Useful without this however