2nd UK Interoperability Summer School HL7 Standards Part 1 Dr Philip Scott Chair, HL7 UK
Learning Outcomes Justify the necessity for healthcare interoperability standards. Explain the mechanics of parsing an HL7 V2 message fragment. Describe the limitations of HL7 V2 that V3 aimed to address. Outline the purpose of HL7 national affiliates.
The patient s web of care
Information is the strands of the web
The interoperability challenge Many systems need to exchange information Best of breed approach increases the number of different systems within a large organisation such as an acute Trust. There are many hurdles in recording and communicating clinical information in an unambiguous way. Even when it is clear what is needed, many process and organisational hurdles exist.
Recording of clinical information often results in data islands This varies from one country to another but for the NHS, the principal divisions in information recording and sharing are: Primary Care Secondary Care Mental Health Community Social care
Share by exchange or centrally? Acute Care Primary Care Shared EHR Mental Health Community Care
European ehealth EIF levels
Why use standards?
Why use standards? Prevent repeated reinvention of solutions for virtually identical business needs. Act as a form of corporate memory, embodying the knowledge, experience and ethics of dedicated specialist teams. Enable multiple vendors to offer services such as conformance testing, implementation management, training and support.
Why use standards? Health and Social Care Act 2012 requires that health and care organisations have "due regard" for information standards. comply or explain enforcement (?) not yet tested Contractual requirements are the ultimate but least useful incentive to adopt standards.
Healthcare interoperability comprises multiple standards CIMI FHIR CFH MIM ITK Profiles Archetypes Snomed CT HL7 v3 IHE Profiles ISO 13606 DICOM HL7 v2.x IHE XDS Vendor specs Local codes
HL7 provides core standards HL7 was founded in 1987 Version 2 developed in the 1990s, still widely used Version 3 developed from 1999, first normative V3 standard published in 2003 Standard documents or messages are developed for a particular domain use case. Reviewed by wide community: users, payers, providers, clinicians and suppliers. Balloted standards become normative or informative.
HL7 standards HL7 is widely perceived as a messaging standard. V2 is definitely a messaging standard. V3 also incorporates documents (CDA) and clinical payload (Clinical Statement). Emerging FHIR standard is natively RESTful and focusses on resources (e.g. Patient, FamilyHistory, DiagnosticReport).
HL7 also supports... EHR functional model Medical logic syntax (Arden) Clinical guideline expression (GELLO) Evidence-based knowledge links (InfoButton) Genomic data Research (case safety reports - ICSR) Medicinal product identification (IDMP)
HL7 V2 Chapters per domain area 3. PATIENT ADMINISTRATION 4. ORDER ENTRY 5. QUERY 6. FINANCIAL MANAGEMENT 7. OBSERVATION REPORTING 8. MASTER FILES 9. MEDICAL RECORDS/INFORMATION MANAGEMENT (DOCUMENT MANAGEMENT) 10. SCHEDULING 11. PATIENT REFERRAL 12. PATIENT CARE
V2 Message Types Each message is identified as having a type Examples: ADT, ORM, ORU, SIU Message types correlate to the chapters in the standard: ADT (Patient Administration) messages described in Chapter 3 ORU (Results reporting) messages described in Chapter 7 SIU (Scheduling) messages described in Chapter 10
Events HL7 V2 associates each message defined with a specific trigger event which causes this particular message to be sent Example The ADT A01 event (Admit/Visit) is a trigger for a message to be sent when a patient is admitted to a hospital Also sent at the start of each new patient encounter Over time V2 events have become more precise
HL7 V2 optionality Standard messages need to allow for the inclusion of all relevant data that two systems may need to exchange in a particular context. Not all systems or use cases need all items. Business drivers will determine what is mandatory and what is optional. Build message profiles to document and agree what is required in any particular case.
Dissecting a HL7 V2.x Message MESSAGE SEGMENT FIELD [and may repeat] [field may have] COMPONENT [component may have] SUBCOMPONENT Structure elements are separated by delimiters: Segments are delimited by a carriage return character (ASCII 13) Fields are delimited by character Field repetitions are delimited by ~ (tilde) Components are delimited by ^ (caret) Subcomponents are delimited by & (ampersand)
Dissecting a HL7 V2.x Message (2) Segments are identified by a three character name. Segments can be optional, mandatory and can repeat. Segments without any fields do not have to be included in the message unless the segment is mandatory. Fields can repeat. Fields, components and subcomponents are identified by their position (e.g. PV1-5.2 is the second component of the fifth field in the PV1 segment).
Segments Example ADT Message: ADT^A01 (1) MSH ^~\& PAS LSP PAS RR8 20040804125500 ADT^A01^ADT_A01 108041253 P 2.4 36854775807 NE AL GBR EVN 200408031200 PID 9908123645^^^^NHS Adams^Bryan^ Message Version(MSH- 12) John^^MR Weaver 19800101 M Crahmel House^Duhamel ID Type Code Place^Leeds^Yorkshire^LS1 1FF^5842^H 0113 454545 0113 (PID-2.5) 656565 ENGLISH 1 NONE Z Liverpool NSP 5842 N 1 Missing fields Message type and Trigger Event (MSH-9.1 & MSH-9.2) NHS Number (PID-2.1)
Ward (PV1-3) Example ADT Message: ADT^A01 (2) PV1 I Florence Nightingale^^^ A&E 21 G9999985^Collins^Stephen^^^MR 110 19 17 G9999986^Briggs^James^^^MR SERV 123456 789 NSP 2004080412530 0 200408311500 DG1 1 01 427509002^Broken Arm 200408051200 A 1 G9999988^Morrison^J ames^^^mr A Diagnosis (DG1-3.2) Facility (PV1.4)
Workshop exercise HL7 V2 The hand-out shows a specification of how to implement a particular message These documents are MIGs- Message Implementation Guidelines It defines the patient identification (PID) segment For the PID segment HL7 defines all the possible fields that can be included The fields are in a fixed sequence from the message start The fields are numbered from 1 onwards (Seq)
Workshop exercise HL7 V2 All the possible components of a field are also numbered Example: 3.4 describes the fourth component of field 3 Where a particular standard message never uses a field, then there is no need to describe it Example: The guidelines document goes straight from field 1 to field 3, omitting anything about field 2
HL7 V2 encoding in XML When HL7 V2 was first developed, XML was not available as the common method of encoding that it now represents The HL7 V2 XML encoding of HL7 V2 was approved in 2002 There are benefits for any implementer processing messages in one underlying syntax However the approach taken does not prevent interoperability with implementers using the original syntax
MSH V2 message fragment in XML
Different forms of message exchange Point-to-point messaging initiated by a source application and sent to be received by a receiving application. HL7 provides an acknowledgement mechanism but there is often no specific timescale for a business response to the message. Query messaging with an expected immediate response. Broadcast-style message distribution from a single sender to many receivers.
Messaging Patterns: Point to Point
Messaging Patterns: Query
Messaging Patterns: Broadcast
Messaging Patterns: Broadcast (2)
Messaging Patterns: Delayed Acks Example: Release of a final version of diagnostic report
Development of HL7 V3 A completely fresh attempt to construct a messaging standard (started 1997) Objective: to be able to represent complex patient clinical information Starting point: use a form of UML to represent the relationship between types of information to be carried Develop a healthcare Reference Information Model (RIM)
Contrasting HL7 V3 and V2 Explicit methodology and formal guidance for message development (v2 historically ad hoc) Definitions in encoded formalism (natural language for v2) Completely defined relationships based on reference information model (structural relationships between data items not pre-defined for V2) Rigorously defined message types as against inconsistent use of trigger events in V2 Well defined application roles (loose in V2)
HL7 V2 usage HL7 V2 remains the most widely deployed healthcare interoperability standard in the world. For all its defects, it is the plumbing in most hospitals: Laboratory requesting and reporting Radiology requesting and reporting Billing (outside UK) ADT
HL7 national affiliates Education, promotion, strategic advice. Profiling standards for national usage. HL7 affiliates provide a forum for the local stakeholders to work together for development and implementation support. Collaborate with other standards groups.
Learning Outcomes Justify the necessity for healthcare interoperability standards. Explain the mechanics of parsing an HL7 V2 message fragment. Describe the limitations of HL7 V2 that V3 aimed to address. Outline the purpose of HL7 national affiliates.