Regarding the HL7 standard for data transfer...

The goal of health care system interoperability (and to further encourage EHR adoption among health care providers) meant making systems that could transfer key bits of information between disparate systems or other health care entities, and to do so meant using a common data format that would be readable on any computer system.  To meet this challenge, the widely recognized standard developing organization called Health Level 7 (or HL7 for short) launched in 1987. The standards developed by HL7 ensure EHR components can readily communicate and the electronic health record works as a complete system¹.  The HL7 technical standard is used for the format of the electronic messages that communicate health care events, and also used for the transmission of data such as lab tests and results from one entity to another. The full designation is “ANSI/HL7 V2.7-2011 Health Level Seven Standard Version 2.7 Application Protocol for Electronic Data Exchange in Healthcare Environments”². There have been a number of revisions that maintained backwards compatibility, and HL7 v2.7 is the current version in use in clinical applications and healthcare environments³.

An HL7 file is basically a text file or text message string divided up with specific markers or delimiters to separate the text into message segments and data fields. The message is divided into segments, and each segment contains specific fields in a standard sequence. The fields may be of different data types, and may be a single value or repeated with multiple components and start and end indicators².

Within each message segment there are a handful of text characters that are used to delineate specific parts of the message, and function "like traffic signs and signals"². The Field Separator is a pipe character (|) and is declared on the fourth character of each data segment after the segment’s identifying information. The Component Separator is the “ ^ “ character, and  this divides the field data within the field separators (Such as name divided into last and first name). The tilde ( ~ ) character represents the Repetition Separator which divides up multiple occurrences of similar information, and the slash ( \ ) is the escape character which can be used for special processing or to indicate special commands or filters. The ampersand ( & ) is used to separate subcomponents².

The messages are divided into segments, the most common being  the message header or MSH, the event type or EVN, the patient identification details or PID, patent visit request (PV1), the specimen details (OBR), the result details or OBX ².

The MSH segment defines the delimiter or field separator, the sender’s ID, the message date and time, the message type, the message control id, the processing status, and the syntax version.

MSH|Delimiters||Sender|||DateTime||MessageType|MessageID|ProcessingStatus|SyntaxVer

The EVN segment is an optional line that indicates date/time information for the event being depicted by the HL7 message.

 

EVN|Type|Date|Time|Event|Reason|Operator

The PID section contains the patient identifiers, starting with the message identifiers and any optional components, followed by the patient name (last name first, separated by a component separator) , Date of Birth, then gender, followed by optional provider information, then followed by address and postal information.

PID|||patientID^^^source^IDtype||familyName^givenName||dateOfBirth|sex|||streetAddress^addressLine2^^^postcode
 

The PV1 segment normally contains the patient’s location and care provider information

PV1|||patientLocation|||||patientsGP

The OBR segment contains lab specific information starting with the accession number used by the lab, then specific test codes and then specimen dates, site information, and optional modifier information.

OBR|||accessionNumber|testCode^testName^codeType|||specimenDate||||||||specimenSource^^^bodySite^siteModifier|requester

An OBX segment is used to represent result details, observations, code types, and abnormal indicators.

 

OBX||valueType|observableCode^observableName|observationSubID|valueCode^valueText^valueCodeType|||abnormalFlag

A complete message or message file sent from an EHR system to a Lab vendor may look like:

MSH|^~\&||^123457^Labs|||201208141530||ORU^R01|123456789|P|2.4
EVN|A28|20080501140006|||000338475^Author^Arthur^^^^^
PID|||123456^^^SMH^PI||SMITH^JOHN||19620114|M|||38 Green St^Orlando^FL^^MM1 9DL
PV1|||5N|||||G123456^DR Samwell
OBR|||54321|555789^LABTESTCODE^LN|||20120802||||||||SW^^^HAND^RT|C987654
OBX||CE|0^ORG|01|STAU||||||F
OBX||CE|600152^AMP|01||||R|||F

For support and reference, the data field names themselves are referred to by where they sit sequentially in the segment, along with the segment abbreviation itself. For example, MSH-7 indicates the seventh field of a segment called MSH. This field will be preceded by seven delimiters with or without information for other fields in between². HL7 messages can cover a variety of healthcare information transfers are sent when specified events in a clinical application designated as ‘triggers’ are enacted.  For instance, a lab order system changes status to Sample Received, and an HL7 message containing the patient info, order, results and everything a lab office needs is sent electronically to the lab system².

The HL7 format is of significance because it can be used in a variety of data transfer types or files types and is universally understood by healthcare applications.

 

References:

1 Atherton (2011). Retrieved from: http://journalofethics.ama-assn.org/2011/03/mhst1-1103.html or http://journalofethics.ama-assn.org/2011/03/pdf/mhst1-1103.pdf

2 Benson, T. (2012). Principles of Health Interoperability HL7 and SNOMED. Springer London. ISBN: 978-1-4471-2800-7 (Print) 978-1-4471-2801-4 (Online)

3 Health Level 7 (2015). HL7/ASTM Implementation Guide for CDA R2 Continuity of Care document, Release 1. Health Level Seven International. Retrieve 2/3/15 from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=6