1. 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

2. The first important question Why do we want to do this?

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. Structured Observation Reporting

12. 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

13. Dotted SubID – HL7 V2.3.1 manual

14. Example Archetype to embed

15. Archetype Driven User experience

16. Embedded Blood Pressure Archetype

17. Use the SubID to indicate tree structure

18. Structural View – added heart rate

19. Users view of 2 archetypes

20. 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

21. 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

22. The Rules for NEHTA archetypes Structure similar, but simpler?? Need examples to develop rules… TBA...

23. 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