Upload
gage-thackston
View
226
Download
0
Tags:
Embed Size (px)
Citation preview
Archetypes in HL7 2.x
Archetypes in HL7 Version 2.x
Andrew McIntyreMedical Objects
http://www.medical-objects.com.au/
9th HL7 Australia Conference, 8th November 2005Sydney, Australia
The first important question
• Why do we want to do this?
Why more structure is desirable• HL7 V2 is a proven & debugged standard – it
works!• We have reliable name=value pairing• It is capable of transmitting atomic data• It lacks clear structure within the atomic Data• Modern terminologies have relationships
between concepts• Archetypes describe this structure “Metadata”• Archetypes provide structure where terminology
does not exist
What use is this structure?• SNOMED-CT post co-ordinated terms• Decision support• Arden• Graphing• Analysis• Provides guidelines for uniform data collection• Allows reports from different institutions to be
compared• Lossless serialization of structured data between
non HL7 systems
Where do we want Archetypes to appear
• ORU messages– Only message in widespread non hospital use– Widely supported– 1 OBR links to many OBX in each report– Not restricted to pathology
• REF messages– Planned referral message– Referral information– Contains a collection of ORU style messages– Contains Medication message– Problems, Goals & Pathways– A wrapper for transport
Where do we want Archetypes to appear
• ORM Messages– 1 OBR links to many OBX– One OBR per “order”– Has ability to carry structured data but not
widely used to do this
• ORF Messages– ORU in a response to a query
Desirable outcomes• Do not break existing infrastructure
– Should not require software update if not used
• No limits on complexity
• Ability to use any Archetypes– OpenEHR– NEHTA?
• Lossless transmission of structure
• Usage within the Standard
Existing Structure• Current structure of messages at segment level
mostly• Messages are a serialised tree structure already• Significant structure already available within OBX
via use of SubID– Grouping– Tree structures
• To serialise Archetypes– Encoding rules are needed to ensure uniformity– No additions to standard required– dotted SubID
What needs to be preserved• OBR has a clear role
– Report header
• Provides the view granularity to software rendering a collection of data – each OBR can be viewed as a single report
– Many OBR segments can be in a message, but each one is a report
• Eg. A Path test, a Clinic visit, an Operation or a Procedure
– DOES NOT MEAN all tests for one hospital admission• Use a REF message with a single OBR for summary
• Each report/path test has original OBR report header
Other important OBR functions• Unique identifier of its contained atomic
data– Filler Order Number Entity Identifier– “This string must uniquely identify the order
from other orders in a particular filling application (eg Clinical Laboratory) - This uniqueness must persist over time” (HL7 v2.3.1 Spec) Ch(s) 4, 7,
– ie. No single item of data should be persisted under more than one OBR Entity Identifier
Structured Observation Reporting
Archetype embedding• OBR retains its role
– Report Header– Unique data identifier
• Multiple archetypes under one OBR if needed– eg. Blood Pressure, pulse, temperature
• Apart from specific terminology no change to existing structure
• Dotted SubID used for tree structure
Dotted SubID – HL7 V2.3.1 manual
Example Archetype to embed
Archetype Driven User experience
Embedded Blood Pressure Archetype
Use the SubID to indicate tree structure
Structural View – added heart rate
Users view of 2 archetypes
The Rules for openEHR• Start Archetype Marker – Baseline SubID here
OBX|1|CE|ARCHETYPE^^OpenEHR|1|at0000^Heart rate^openEHR-EHR-OBSERVATION.heart_rate.v1
• Events with a real name (not “any event”) have a header OBXOBX|2|CE|ITEM_LIST^^OpenEHR|1.1.1|at0002^baseline reading^openEHR-EHR-OBSERVATION.blood_pressure.v1
• Repeating Elements with codes have a header OBXOBX|3|CE|ELEMENT^^OpenEHR|1.1.1.3.1|at0007^System^openEHR-EHR-OBSERVATION.autopsy.v1
• Non ELEMENT nodes with a real name have a header OBXOBX|2|CE|CLUSTER^^OpenEHR|1.1.1.3|at0006^Internal examination^openEHR-EHR-OBSERVATION.autopsy.v1
openEHR – Extracting data• Reference to Archetype is in first OBX• End of Archetype indicated by SubID• Tree structure indicated in OBX SubID
– Is actually optional as can be deduced from codes
• Allows archetypes to be extracted or ignored
• Allows users to add appropriate Archetypes to reports as desired
• Would allow Archetype nesting
The Rules for NEHTA archetypes
• Structure similar, but simpler??
• Need examples to develop rules…
• TBA . . .
Summary• Embedding archetypes
– is legal within current HL7 standard– Preserves current functionality – can be ignored– Does not require mass software updates– Allows writer to specify “view port granularity”– Is compatible with REF, ORU, ORM, ORF messages– Has no limits on complexity
• Requirements– logical archetype structure for linear display
• All archetypes I have seen provide this