2nd UK Interoperability Summer School HL7 Standards – Part 1 Dr Philip Scott Chair, HL7 UK
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Mental Health
Primary Care
Acute Care
Community Care
Shared
EHR
Share by exchange or centrally?
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
Snomed CT HL7 v3
HL7 v2.x ISO 13606
Archetypes
CFH MIM
DICOM
Local codes
Vendor specs
IHE Profiles
IHE XDS
CIMI
ITK Profiles
FHIR
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).
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^
John^^MR|Weaver|19800101|M|||Crahmel House^Duhamel Place^Leeds^Yorkshire^LS1 1FF^5842^H||0113 454545|0113 656565|ENGLISH|1|NONE|||||Z|Liverpool|||NSP||5842||N||1 NHS Number
(PID-2.1)
Segments
Missing fields
Message type and Trigger Event (MSH-9.1 & MSH-9.2)
Message Version(MSH-12)
ID Type Code (PID-2.5)
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|123456789|||||||||||||||||NSP||||||||20040804125300|200408311500
DG1|1|01|427509002^Broken Arm||
200408051200|A|||||||||1|G9999988^Morrison^James^^^MR|A
Ward (PV1-3)
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.
Related Documents
