Archetypes in HL7 v2
-
Upload
maya-glass -
Category
Documents
-
view
35 -
download
0
description
Transcript of Archetypes in HL7 v2
Archetypes in HL7 v2
Andrew McIntyreMedical-Objects
HL7 InternationalMay 2009
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
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
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 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
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
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
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 > 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^^openEHR-EHR-OBSERVATION.blood_pressure.v1|1.1.1.1.1.1.1.1.2|100|mm[Hg]^^ISO+|||||F
Overview of encoding
Three OBX types:
• Header RP Segment– OBX|1|RP|ENTRY^^EN 13606|1|openEHR-EHR-
OBSERVATION.blood_pressure.v1^Blood pressure measurement&99A-A892E160ECDB6613&L^TX^Octet-stream||||||F
• Non Terminal OBX– OBX|6|CE|15431-0^^LN^CLUSTER^^EN 13606|1.1.12|
103764000^Non reportable items^SNOMED-CT^at0047^Non reportable items^CEN-FULL-BLOOD-COUNT.v1||||||F
• Terminal OBX – “Data”– OBX|2|NM|14749-6^Glucose^LN^22569008^^SNOMED-CT|
1.1.6|7.8|mmol/L^^ISO+|<7.8|+|||F
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
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