Difference between revisions of "HL7"

From Clinfowiki
Jump to: navigation, search
(Mission statement)
Line 11: Line 11:
 
Founded in 1987, the Health Level Seven (HL7) protocol and corporation behind it are a standard means for exchanging clinical data.  Currently in its third version, this standard describes a framework for the exchange of messages related to patient registrations, lab results, pharmaceutical orders, inventory, billing, et cetera between and within care-delivery systems and organizations.  “Health Level Seven” is an allusion to the Open Systems Interconnection (OSI) model’s “Level Seven”, the conceptual network layer at which data is exchanged between applications and the lower networking layers and infrastructure.  As such, the protocol accepts data from disparate applications, packages it into an appropriately formatted message type with various header and identifying information, and facilitates its transmission across TCP/IP connections between machines hosting these applications.
 
Founded in 1987, the Health Level Seven (HL7) protocol and corporation behind it are a standard means for exchanging clinical data.  Currently in its third version, this standard describes a framework for the exchange of messages related to patient registrations, lab results, pharmaceutical orders, inventory, billing, et cetera between and within care-delivery systems and organizations.  “Health Level Seven” is an allusion to the Open Systems Interconnection (OSI) model’s “Level Seven”, the conceptual network layer at which data is exchanged between applications and the lower networking layers and infrastructure.  As such, the protocol accepts data from disparate applications, packages it into an appropriately formatted message type with various header and identifying information, and facilitates its transmission across TCP/IP connections between machines hosting these applications.
  
== Features ==
+
== History of version 2 ==
  
 
Currently the most common iteration of the HL7 standard is version 2.x.  Messages in this version rely on “triggers” to define the exchange of data.  Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, et cetera.  Upon, e.g., admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”.  This message is populated with demographic information about the patient recently admitted, to include name and address, next-of-kin information, allergies, and related/relevant diagnoses.  Each of these bundles of information is relayed inside an ordered set of reusable “segment” of the message; e.g., Patient IDentifiers are placed inside a segmented component of the ADT message called a “PID segment”.  Discrete pieces of information are separated by “delimiters”, which themselves are meaningful; e.g., “…|LastName^FirstName|…|DateOfBirth|Sex|…” might represent a portion of the PID segment, and is delimited using the ‘|’ character to set apart conceptual entities (e.g., name and date-of-birth), and the ‘^’ characer to set apart components of those entities (e.g., first and last name).  Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient.  The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.
 
Currently the most common iteration of the HL7 standard is version 2.x.  Messages in this version rely on “triggers” to define the exchange of data.  Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, et cetera.  Upon, e.g., admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”.  This message is populated with demographic information about the patient recently admitted, to include name and address, next-of-kin information, allergies, and related/relevant diagnoses.  Each of these bundles of information is relayed inside an ordered set of reusable “segment” of the message; e.g., Patient IDentifiers are placed inside a segmented component of the ADT message called a “PID segment”.  Discrete pieces of information are separated by “delimiters”, which themselves are meaningful; e.g., “…|LastName^FirstName|…|DateOfBirth|Sex|…” might represent a portion of the PID segment, and is delimited using the ‘|’ character to set apart conceptual entities (e.g., name and date-of-birth), and the ‘^’ characer to set apart components of those entities (e.g., first and last name).  Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient.  The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.
  
== Example ==
+
=== Disadvantages ===
 +
 
 +
Version 2 has no formal information model; the model is implicit, not explicit.
 +
Version 2 models are similar to programming language “structures”, but without formal operations and without important OO concepts, such as generalization-specialization hierarchies.
 +
Version 2 has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific.
 +
Version 2 identifier datatypes are insufficient for large-scale integration.
 +
Diminishing returns from increased work on 2.X
 +
Compatibility with previous versions is getting very heavy
 +
The tower of Babel, or a New Dark Age
 +
 
 +
==== Example ====
  
 
An example of an HL7 message follows.  Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:
 
An example of an HL7 message follows.  Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:
Line 24: Line 34:
 
   DG1|1|||OSTEOARTHROS NOS-L/LEG
 
   DG1|1|||OSTEOARTHROS NOS-L/LEG
  
 +
== Version 3 new additions ==
 +
 +
#Top-down message development emphasizing reuse across multiple contexts
 +
#Representation of complex temporal and non-temporal relationships
 +
#Formalisms for vocabulary support
 +
#Support for large scale integration
 +
#Solving the identifiers problem
 +
#Solving re-use and interoperability across multiple domain contexts
 +
#Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical #genomics, security, etc.
  
Submitted by Kit Crafton
 
  
 
[[Category:BMI512-WINTER-11]]
 
[[Category:BMI512-WINTER-11]]

Revision as of 22:18, 14 September 2011

Health Level Seven (HL7)

Mission statement

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

"Level Seven" refers to the seventh level of the International Organization for Standardization (ISO) seven-layer communications model for Open Systems Interconnection (OSI) - the application level. The application level interfaces directly to and performs common application services for the application processes. Although other protocols have largely superseded it, the OSI model remains valuable as a place to begin the study of network architecture. [1]

History

Founded in 1987, the Health Level Seven (HL7) protocol and corporation behind it are a standard means for exchanging clinical data. Currently in its third version, this standard describes a framework for the exchange of messages related to patient registrations, lab results, pharmaceutical orders, inventory, billing, et cetera between and within care-delivery systems and organizations. “Health Level Seven” is an allusion to the Open Systems Interconnection (OSI) model’s “Level Seven”, the conceptual network layer at which data is exchanged between applications and the lower networking layers and infrastructure. As such, the protocol accepts data from disparate applications, packages it into an appropriately formatted message type with various header and identifying information, and facilitates its transmission across TCP/IP connections between machines hosting these applications.

History of version 2

Currently the most common iteration of the HL7 standard is version 2.x. Messages in this version rely on “triggers” to define the exchange of data. Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, et cetera. Upon, e.g., admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”. This message is populated with demographic information about the patient recently admitted, to include name and address, next-of-kin information, allergies, and related/relevant diagnoses. Each of these bundles of information is relayed inside an ordered set of reusable “segment” of the message; e.g., Patient IDentifiers are placed inside a segmented component of the ADT message called a “PID segment”. Discrete pieces of information are separated by “delimiters”, which themselves are meaningful; e.g., “…|LastName^FirstName|…|DateOfBirth|Sex|…” might represent a portion of the PID segment, and is delimited using the ‘|’ character to set apart conceptual entities (e.g., name and date-of-birth), and the ‘^’ characer to set apart components of those entities (e.g., first and last name). Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient. The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.

Disadvantages

Version 2 has no formal information model; the model is implicit, not explicit. Version 2 models are similar to programming language “structures”, but without formal operations and without important OO concepts, such as generalization-specialization hierarchies. Version 2 has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific. Version 2 identifier datatypes are insufficient for large-scale integration. Diminishing returns from increased work on 2.X Compatibility with previous versions is getting very heavy The tower of Babel, or a New Dark Age

Example

An example of an HL7 message follows. Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:

 MSH|^~\&|||||200501100455||ADT^A01|ADT66561|P|2.3||||||| 
 PID|||10006579||DUCK^DONALD D||19241010|M|||111^QUACK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234
 PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452 
 DG1|1|||OSTEOARTHROS NOS-L/LEG

Version 3 new additions

  1. Top-down message development emphasizing reuse across multiple contexts
  2. Representation of complex temporal and non-temporal relationships
  3. Formalisms for vocabulary support
  4. Support for large scale integration
  5. Solving the identifiers problem
  6. Solving re-use and interoperability across multiple domain contexts
  7. Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical #genomics, security, etc.