Archetypes in HL7 2.x Archetypes in HL7 Version 2.x Andrew McIntyre Medical Objects 9 th HL7 Australia Conference, 8.

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