Archetypes in HL7 v2

1
Archetypes in HL7 v2

• Andrew McIntyre
• Medical-Objects
• HL7 International
• May 2009

2
Overview

• HL7 v2 in widespread use in Australia
• Many legacy applications
• Administrative models well covered
• Limited support for Clinical Models
• Need for Structured Clinical data
• SNOMED-CT support
• Patient history/Family History transfer
• Decision Support
• Registries
• Archetypes allow detailed Clinical Models
• No changes required to standard
• Backward compatible

3
Long-term goals

• Support of Complex Clinical Models
• No limit on complexity
• Allow reuse of models
• Represent model in V2/V3/CDA/CCD formats
• Smooth migration of legacy applications
• Complexity hidden from legacy applications
• Common clinical models in use
• Allows data transfer across systems
• Allows data transfer across encodings
• Allow rich SNOMED-CT use
• Support post-coordination

4
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

5
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

6
Archetypes

• Built on a domain model
• CEN 13606 European Standard
• OpenEHR
• Domain model is mappable
• 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

7
Archetypes

• Describe semantic relationships
• Between atomic data items
• Between archetypes
• Between/within terminologies
• Constrain data
• 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

8
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

9
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

10
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.
11
Example Archetypes
12
Archetype Data Model

• An Identifier for the Archetype
• A tree of Atomic data elements
• Elements map to single OBX
• OBX - 4 Observation sub ID used
• Organised by Non Terminal Nodes
• 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 gt 1 in archetype requires extra nodes

13
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

14
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

15
Walking the path
OBX6NM163031004diastolicSNOMED-CTat0005ope
nEHR-EHR-OBSERVATION.blood_pressure.v11.1.1.1.1.1
.1.1.2100mmHgISOF
16
Overview of encoding

• Three OBX types

• Header RP Segment
• OBX1RPENTRYEN 136061openEHR-EHR-OBSERVATION
  .blood_pressure.v1Blood pressure
  measurement99A-A892E160ECDB6613LTXOctet-stream
  F
• Non Terminal OBX
• OBX6CE15431-0LNCLUSTEREN
  136061.1.12103764000Non reportable
  itemsSNOMED-CTat0047Non reportable
  itemsCEN-FULL-BLOOD-COUNT.v1F
• Terminal OBX Data
• OBX2NM14749-6GlucoseLN22569008SNOMED-CT1.
  1.67.8mmol/LISOlt7.8F

17
Potential Alternatives

• CDA
• Solves problem of inadequate HL7 parsers
• This is small piece of puzzle however
• Does not solve all semantic issues
• Minimal existing CDA support in Australia
• Requires overnight upgrade of all pms systems
• CCR/CCD
• 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

18
Conclusions

• Archetypes allow data models to be defined
• Usable in HL7 V2 and CDA
• Archetypes in V2 would allow migration
• Requires solid HL7 parsers
• Prerequisite for any semantic interoperability
• Investment required in low level technology
• Standards Compliance
• Would improve quality of existing messages
• Allows possibility of taking next step
• Common archetypes ideal
• Useful without this however