Dr Farzad Jahedi October – 2015 Malaysia Introduction to HL7 Dr Farzad Jahedi October – 2015 Malaysia

Outline Implementation HL7 Message HL7 Organization Interoperability Message Types Message Syntax Data types HL7 Organization Interoperability

Main Components of Comprehensive Electronic Health Record Clinical Documentation Decision Support Order Entry Test and Imaging results

Interoperability Technical Semantic Process moves data from system A to system B, neutralizing the effects of distance Semantic ensures that system A and system B understand the data in the same way Process coordinates work processes, enabling the business processes at the organizations that house system A and system B to work together

Hospital A Hospital B Inter-hospital Transfer Patient_Name Patient_Family DOB Adm_D Surname Family_Name Birth_Date Date_of_Adm

STANDARD

International Standard Development Organizations (SDO) ISO  International Standard Organization ISO TC215 ANSI  American National Standards Institute BSI  British Standards Institute BSI IST/35 CEN  European Standards Organization CEN TC251

International Organizations (non-ISO) IHTSDO  [SNOMED CT] International Health Terminology Standards Development Organization CDISC  [coordinating data capture for clinical trials] Clinical Data Interchange Standards Consortium IHE  Integrating the Healthcare Enterprise Continua home tele-health devices OpenEHR  elements of EHR architecture

HL7 HL7 creates standards for the of electronic healthcare information exchange management integration of electronic healthcare information for clinical and administrative purposes. Other ANSI-accredited SDOs have responsibility for pharmacy (NCPDC) medical devices (IEEE) imaging (ACR/NEMA) insurance (claims processing) transactions (X12) dentistry (ADA)

Why? Health H L 7 ! ? Level

ISO’s Open Systems Interconnect (OSI) model Layer 7 – Application  The only domain-specific aspect  Semantics or meaning of what is exchanged Layer 6 – Presentation Layer 5 – Session Layer 4 – Transport Layer 3 – Network various aspects of technical interoperability Layer 2 – Data-link Layer 1 – Physical

HL7 versions HL7 V2 HL7 V3 ASCII Messages XML Messages UML Model

HL7 V2 Message Syntax Data Type describes the overall structure of messages and how the different parts are recognized Data Type Each message is composed of segments in specified sequence each of which contains fields also in a specified sequence these fields have specified data types

Message Syntax ADT^A04 Messages are sent in response to trigger events Message name is derived from the message type and a trigger event The trigger event indicates what happened to cause a message to be generated. Trigger events are specific to a message type. Examples of Message Types Some Trigger Events of ADT ACK  General acknowledgment message ADT  ADT message ORM  Order message ORU  Observation result – unsolicited A01  Admit/visit notification A02  Transfer a patient A03  Discharge/end visit A04  Register a patient ADT^A04 Message name

HL7 Message Types Admission, Discharge, Transfer (ADT) Order Message (ORM, ORR, RDE, etc.) Financial Management (DFT, BAR) Ancillary Data Reporting (ORU, CRM, etc.) Master File Notification (MEN, MEQ, etc.) Medical Records Information Management (MDM) Scheduling (SRM, SIU, SQM) Patient Referral (RQI, REF, RQA, etc.) Patient Care (PGL, PPR, PPG, etc.)

Allowable content a simple message message syntax table The overall structure and allowable content of each message Is defined in an abstract message syntax table, lists segments in the order in which they occur. shows which segments are optional and which can be repeated a simple message MSH  Message Header EVN  Event Type PID  Patient Identification PV1  Patient Visit message syntax table ADT^A01 ADT Message . MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics [ { NK1 } ] Next of Kin/Associated Parties PV1 Patient Visit Optional Segment Optional + Repeatable Mandatory

Segments Segments contain fields Fields contain components Each segment has a three-character identifier the segment ID (e.g., MSH). In a message this segment ID is always the first three characters of the line. Segments contain fields Fields contain components Components may contain subcomponents

Delimiters field separators component separators Subcomponent separators Symbol Usage . | Field separator ^ Component separator ~ Repetition separator \ Escape character & Subcomponent separator <CR> Segment terminator

Some of commonly used segments MSH  Message Header PID  Patient Identification Details PV1  Patient Visit OBR  Request and Specimen Details OBX  Result Details Z-segment

MSH  Message Header

PID  Patient Identification Details

PV1  Patient Visit

OBX  Result Details

OBR  Request and Specimen Details

Z-Segment develop your own segments, message types, and trigger events using names beginning with Z. are widely used and are one of the main reasons why there are so many different variants of HL7 V2 messages. can be placed anywhere in a message.

Data Types Simple Data Types Complex Data Types DT (date)  YYYY[MM[DD]]. DTM (date/time)  YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/–ZZZZ] FT (formatted text) embedded formatting commands ID a value from a HL7-defined table. IS a value from a user-defined table. NM (numeric) numeric values SI (set ID) gives the order of a segment instance within a message ST (string) short strings up to 200 characters. TX (text) longer texts up to 64 K characters. Complex Data Types Coded values Identifiers Names Addresses

abstract syntax of the HL7 V2 message MSH Message header PID Patient Identification Details PV1 Patient Visit OBR Results header {OBX} Results detail (repeats) MSH|delimiters||sender|||dateTime||messageType|messageID |processingStatus|syntaxVersion PID|||patientID^^^source^IDtype||familyName^givenName||d ateOfBirth|sex|||streetAddress^addressLine2^^^postCode PV1|||patientLocation|||||patientsGP OBR|||accessionNumber|testCode^testName^codeType|||speci menDate||||||||specimenSource^^^bodySite^siteModifier |requester OBX||valueType|observableCode^observableName|observatio nSubID|valueCode^valueText^valueCodeType|||abnormalFl ag|||result status OBX ...

MSH|^~\&||^123457^Labs|||200808141530||ORU^R01|123456789|P|2.4 PID|||123456^^^SMH^PI||MOUSE^MICKEY||19620114|M|||14 Disney Rd^Disneyland^^^MM1 9DL PV1|||5N|||||G123456^DR SMITH OBR|||54321|666777^CULTURE^LN|||20080802||||||||SW^^^FOOT^RT|C987654 OBX||CE|0^ORG|01|STAU||||||F OBX||CE|500152^AMP|01||||R|||F OBX||CE|500155^SXT|01||||S|||F OBX||CE|500162^CIP|01||||S|||F ORU HL7 message ASCII Report from Lab123457, 15:30 14-Aug-2008, Ref 123456789 Patient: MICKEY MOUSE, DoB: 14-Jan-1962, M Address: 14 Disney Rd, Disneyland, MM1 9DL Specimen: Swab, FOOT, Right, Requested By: C987654, Location: 5N Patients GP: Dr Smith (G123456) Organism: STAU Susceptibility: AMP R SXT S CIP S

<. -- v2. xml Message Definitions Version v2 <!-- v2.xml Message Definitions Version v2.2 - ADT_A04 Copyright (C) Sun Microsystems. All rights reserved. --> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:com.sun:encoder-hl7-1.0" targetNamespace="urn:hl7-org:v2xml" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" jaxb:version="2.0"> <!-- include segment definitions for version v2.2 --> <xsd:include schemaLocation="segments.xsd"/> <xsd:annotation> <xsd:appinfo source="urn:com.sun:encoder"> <encoding xmlns="urn:com.sun:encoder" name="HL7 v2 Encoding" namespace="urn:com.sun:encoder-hl7-1.0" style="hl7encoder-1.0"/> </xsd:appinfo> </xsd:annotation> <!-- MESSAGE ADT_A04 --> <!-- .. groups used in message ADT_A04 --> <xsd:complexType name="ADT_A04.INSURANCE.CONTENT"> <xsd:sequence> <xsd:element ref="IN1" minOccurs="1" maxOccurs="1"/> <xsd:element ref="IN2" minOccurs="0" maxOccurs="1"/> <xsd:element ref="IN3" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> <xsd:element name="ADT_A04.INSURANCE" type="ADT_A04.INSURANCE.CONTENT"/> <!-- .. message definition ADT_A04 --> <xsd:complexType name="ADT_A04.CONTENT"> <xsd:element ref="MSH" minOccurs="1" maxOccurs="1"/> <xsd:element ref="EVN" minOccurs="1" maxOccurs="1"/> <xsd:element ref="PID" minOccurs="1" maxOccurs="1"/> <xsd:element ref="NK1" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="PV1" minOccurs="1" maxOccurs="1"/> <xsd:element ref="PV2" minOccurs="0" maxOccurs="1"/> <xsd:element ref="OBX" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="AL1" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DG1" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="PR1" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="GT1" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="ADT_A04.INSURANCE" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="ACC" minOccurs="0" maxOccurs="1"/> <xsd:element ref="UB1" minOccurs="0" maxOccurs="1"/> <xsd:element ref="UB2" minOccurs="0" maxOccurs="1"/> <xsd:element name="ADT_A04" type="ADT_A04.CONTENT"> <xsd:appinfo source="urn:com.sun:encoder"> <top xmlns="urn:com.sun:encoder">true</top> </xsd:appinfo> </xsd:element> </xsd:schema> ADT HL7 message XSD

ACK HL7 message ASCII vs XML Version 2.3.1 (87 characters of data) MSH|^~\&|LAB^foo^bar|767543|ADT|767543|19900314130405||ACK^|XX3657|P|2.3.1 MSA|AA|ZZ9380 Version 3 (477 characters of data) <ACK> <MSH> <MSH.1>|</MSH.1> <MSH.2>^~\&</MSH.2> <MSH.3> <HD.1>LAB</HD.1> <HD.2>foo</HD.2> <HD.3>bar</HD.3> </MSH.3> <MSH.4> <HD.1>767543</HD.1> </MSH.4> <MSH.5> <HD.1>ADT</HD.1> </MSH.5> <MSH.6> </MSH.6> <MSH.7>19900314130405</MSH.7> <MSH.9> <CM_MSG_TYPE.1>ACK</CM_MSG_TYPE.1> </MSH.9> <MSH.10>XX3657</MSH.10> <MSH.11><PT.1>P</PT.1></MSH.11> <MSH.12> <VID.1>2.3.1</VID.1> </MSH.12> </MSH> <MSA> <MSA.1>AA</MSA.1> <MSA.2>ZZ9380</MSA.2> </MSA> </ACK> ACK HL7 message ASCII vs XML

HL7  and  ICD DG1 - diagnosis segment to transmit one patient diagnosis Additional DG1 segments are sent for separate diagnoses. If there is a new diagnosis, or a change in any of the diagnoses, they should all be resent. Diagnosis coding method ICD9 is the only valid coding system supported by the interface. This field should contain "I9" if the diagnosis is an ICD9 Otherwise, the field should be omitted. Diagnosis code If the ICD9 code is available, it should be placed here. Diagnosis description This field should contain the diagnosis description (i.e., either the one related to the ICD9 code, or free text). Diagnosis/DRG type Valid types include "ADMITTING", "INTERIM" and "FINAL" HL7  and  ICD Seq Len Fmt Opt Element Name 3    R Segment ID = "DG1" 1 4 SI O Set ID – Diagnosis 2 ID Diagnosis coding method 8 Diagnosis code 40 ST Diagnosis description 5 14 TS Diagnosis date/time 6 Diagnosis/DRG type 7 Major diagnostic category Diagnosis related group (DRG) 9 DRG approval indicator 10 DRG grouper review code 11 Outlier type 12 NM Outlier days 13 Outlier cost Grouper version and type

ICD-10 in HL7 HL7 Vocabulary Value sets using code system

A HIPAA-compliant ORU message One or more observation request (OBR) segments defining observation type and request specifics. One or more observation result (OBX) segments defining, quantifying, and qualifying the results. One or more LOINC (Logical Observation Identifier Names and Codes) modifier codes used in the OBR and/or OBX segments as universal identifiers for laboratory and other clinical observations. Health Insurance Portability and Accountability Act

HIS PACS Implementation HL7 Broker HL7 txt HL7 DICOM txt xml html C3DEVER xml html DICOM PACS INFOPSY

What you may learn Why Interoperability Standards? Why HL7? Message Types? HL7 V2 Structure? Trigger Events? Message Syntax? Data Types? Segments? Delimiter? Fields? HL7 Broker? Components / Subcomponents?