230 likes | 345 Views
Archetypes in HL7 2.x. Archetypes in HL7 Version 2.x Andrew McIntyre Medical Objects http://www.medical-objects.com.au/ 9 th HL7 Australia Conference, 8 th November 2005 Sydney, Australia. The first important question. Why do we want to do this?. Why more structure is desirable.
E N D
Archetypes in HL7 2.x Archetypes in HL7 Version 2.x Andrew McIntyre Medical Objects http://www.medical-objects.com.au/ 9th HL7 Australia Conference, 8th November 2005 Sydney, 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
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
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 OBX OBX|2|CE|ITEM_LIST^^OpenEHR|1.1.1|at0002^baseline reading^openEHR-EHR-OBSERVATION.blood_pressure.v1 • Repeating Elements with codes have a header OBX OBX|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 OBX OBX|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