HL7

HL7

Agenda

− Intro

−HL7

−HL7 v2.*

−HL7 v3.*

−HL7 CDA

−HL7 FHIR

−Challenges

−Questions

Introduction

Andy Stopford – Technical Director

−Oversee HAVAS Health Software

− Software Engineer by trade

− 18 years in the software industry

− Experience built in the E-commerce, Insurance & Financial sectors

− Author & Writer

− Technical advisory at Microsoft

−Member of HL7 UK charter

Our partners

The company we keep

Healthcare Installations−UK− NHS Guys & St Thomas Foundation Trust− NHS Buckinghamshire Healthcare Trust− NHS Southend Clinical Commissioning Group

−USA− Henry Ford Health System

Data exchange in healthcare

HL7

−HL7 International was founded in 1987− Standards Body

−HL7 defines a common method of structured data exchange in healthcare

− Very common to find in healthcare IT systems− EHR systems− Patient appointment booking systems

−HL7 is used in over 35 countries

HL7 v2

− Started life in 1988 with version 1

− 2.1 was the first usable standard and arrived in 1991

− 2.2 to 2.7− In 2010 2.1 was still used in over 32 countries

− Very common to see 2.1/2.5 in the NHS

− Subject domains− Patient demographics− Clinical observations− Scheduling of patient appointments Resources− Etc.

HL7 v2 structure

− A unit of data that is transferred between systems− Each information exchange is initiated by a trigger event and consists

of one or more messages

− A message is composed of segments in a defined sequence

− Segments hold fields (data types)− The first segment of each message defines the message type

and the type of trigger event that caused the message to be sent− Each segment is a sequence of data fields, separated by special

data field separators (usually the pipe ‘|’ symbol)− Each data field has a data type, which may be compound –

made up of components which are separated by a component separator (usually the carat ‘̂ ’ symbol)

− Structure is modelled on ANSI X.12 and UN/EDIFACT

HL7 v2 ADT

− Some trigger messages can be classified under Admission, Discharge, Treatment (ADT)

−Coded A01 to A62− A01 – Admit− A05 – Pre-Admit− A02 – Transfer− A08 – Change patient information− etc

HL7 v2 sequence

ENCOUNTER

REGISTRATION

PLANNED ENC.

TRANSFER

TRANSFER

TRANSFER

DISCHARGE

ADMIT

ADT^A04 ADT^A03 ADT^A02

ADT^A12

ADT^A02ADT^A01ADT^A05

HL7 v2 Segments

− Each message structure varies depending on the trigger

− Every message holds segments−MSH – Message Header− EVN – Event Type− PID – Patient Identification− PV1 – Patient Visit

HL7 v2 PID fields (sample)

Name Required Length

Set ID No 4

Patient ID No 0

Patient Identifier List Yes 250

Alternate Patient ID No 0

Patient Name Yes 250

Mother's Maiden Name No 250

Date/Time of Birth No 24

HL7 v2 - Example

HL7 v3

−Newer definition of the HL7 standard

− First developed in 2005

− XML based

− Addresses some of the v2 issues− Schema − Structure− Extension

− “Semantic Interoperability”

− Spec is huge (1.2 gig in size)

HL7 v3 - RIM

− Primary object model (RIM)− Accounting & Billing− Pharmacy− Patient Admission−Medical Records− Laboratory−…My own….− Etc.

HL7 v3 - RIM

−Domain − Story boards− Trigger events− Domain information model (D-MIM)− Refined information models (R-MIM)− Hierarchical Message Descriptions− CMET

HL7 v3 - Reference Information Model (RIM)

HL7 v3 - RIM

−Red: The central block and represents an action,

− Blue: Defines a participant,

− Pink: Represents an act relationship to describe how acts are related,

− Yellow: Describes the role of the participant,

−Green: Represents the entity playing the role

HL7 v3 - RIM

 If I have an inpatient visit for a surgery at a hospital

− The surgery is an act (red) that is a Procedure

− I am participating (blue) as a Record Target

−My surgeon is participating (blue) as the Performer

−My role (yellow) is as a Patient, and

− I am the entity (green) of a Person.

HL7 v3 - D-MIM/R-MIM

−Domain Message Information Model (D-MIM)− D-MIM is based on the RIM−Models a given domain but is not the implementation

−Refined Message Information Model (R-MIM)− R-MIM is derived from the parent D-MIM − Information model, shows data for a particular message

HL7 v3 - Patient Admission D-MIM

HL7 V3 - Activate Patient R-MIM

HL7 v3 - Wrapper

−Wraps a message to support the transport from sender to receiver

− Transmission Wrapper

−Control Act Wrapper

− Payload (the actual domain message)

HL7 v3 – Transmission Wrapper

−Required

−Date/Time

− Identifies the sender and receiver (ID)

− Identifies when acks are required for the message

−Upper level and wraps− Control Act Wrapper− Payload

HL7 v3 – Control Act Wrapper

−Used to communicate information to an interaction that triggered a message.

−Message Control Act (basic)

−Query Infrastructure

−Master File/Registry

−Domain messages have different uses of the control act wrappers

HL7 v3 - CMET

−Common Message Element Type

−Reusable part of a message− E.g. Patient

− Included in the domain− Isolated from the domain

− Vulnerable to change− E.g. Lab states patient needs IQ then pharmacy also has it− Hides the true size of a message

HL7 v3 - Transport

− Big XML messages that we need to move

−MLLP (Minimum Lower Layer Protocol)− Used with v2 a lot− Limited

− SOAP− The most common− XML payload

− ebXML (yuck)− Standard includes a payload spec

HL7 v3 - Example

HL7 CDA

−Clinical Document Architecture

−Represent any clinical document – e.g. Discharge Summary

− Built on the HL7 Reference Information Model (RIM)

−CDA Header

−CDA Body

HL7 CDA Header

−Document Information− ID of the document, confidentiality & relationship to other documents.

− Encounter data− Describes where the encounter took place, time & setting.

− Service actors− Describes who interacted with service being described

− Service targets− Include the patient, family members etc.

HL7 CDA Body

−Describes the body of the document

− A document structure will vary, so too must a CDA body

−CDA Body gives you structures to capture this

− Structures− Sections− Paragraphs− Lists− Tables

HL7 CCR

− Joint HL7/ASTM standard

− Facilitate better cross communication between systems

−CDA Body can vary in structure

−CCR defines templates that fix this structure

HL7 tools

− Server− InterSystems Ensemble− InterfaceWare Iguana−Microsoft BizTalk−Mirth Connect

− Tools− HL7 Inspector (OSS)− 7Edit (commercial

HL7 FHIR

− Fast Health Interoperable Resources

− The future of HL7…

− Free and open!

−Combines parts of v2, v3 and CDA to create a new standard

− Supports XML and JSON

−RESTful

−Working draft available by the end of 2013 with a working process through 2014 and 2015

FHIR Resources

−Clinical−General - AdverseReaction, CarePlan, FamilyHistory etc−Medications - Medication, MedicationPrescription etc− Diagnostics – Observation, DiagnosticReport

− Administrative− Attribution – Patient, RelatedPerson, Practictioner− Resources – Device, Location−Workflow – Encounter, Alert

− Bundles− Combined resources

FHIR REST

−Resources expose certain logical interactions− Create (POST)− Read (GET)− Update (PUT)− Delete (DELETE)

− Bundles− History (GET)− Search (GET)

FHIR Security

−HTTPS/SSL

−OAuth

− Authorization/Access control− HL7 Healthcare Classification System− Access/data segmentation

− Audit− Security events− Provenance

So all good?

The protection of patient data is critical

− Thus it’s not truly open

− Access is limited

−Data is limited

− Storage is almost impossible

− Security is paramount

−HIPAA

How best to work with patient data

− Agree with the trust what you need and what you can see

−Caldicott Guardian

− ISO 27001

− Point to point

− SSL 256

− Accredited data storage (or just don’t do it)− Encrypt the storage, not the data.− 256 at minimum

More information

−Web− HL7 international (http://www.hl7.org)− HL7 UK charter (http://www.hl7.org.uk/)

− Books− Principles of Health Interoperability HL7 and SNOMED (Tim Benson)

QUESTIONS?