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.