Difference between revisions of "HL7"

From Clinfowiki
Jump to: navigation, search
Line 226: Line 226:
 
[[Category:BMI512-FALL-12]]
 
[[Category:BMI512-FALL-12]]
 
[[Category:Terminology and Coding]]
 
[[Category:Terminology and Coding]]
 +
[[Category:Interoperability]]

Revision as of 04:42, 7 October 2015

Health Level Seven (HL7) provides standards for interoperability that reduce ambiguity and enhance data transfer among providers, government agencies, and electronic medical records. [1]

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. [2]

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.


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.


The HL7 Clinical Document Architecture is an ANSI standard with release 2 being published early in 2005 [3]. Like other HL7 standards it is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems.

Features

A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as SNOMED and LOINC.

Inter nationality

The CDA standard holds great potential for sharing information and is being trialled in many countries including the Netherlands, Spain, Germany, Japan and Mexico to name a few.

2012 HL7 Initiatives

1 S T R A T E G I C I N I T I A T I V E S - S U M M A R Y

HL7 Recognition: Attain recognition as the lead developer and harmonizer of global technical and functional health informatics standards • Realm specifications have been advanced to international HL7 specifications • International HL7 specifications have achieved ISO recognition • Global adoption has increased • HL7's role and value proposition in the overarching standards landscape has been clarified • Key stakeholder groups have been identified, with value propositions and action plans for engaging each group

HL7 Internal Processes: Streamline the HL7 standards development process • A globally applicable business model has been developed • Working Group Meetings have been effective • Product quality has improved • End to end V3/CDA template and implementation guide infrastructure has been developed • Requirements traceability has been enabled • Cross-artifact inconsistency is reduced

HL7 Implementation: Develop standards that are easier to implement and more responsive to customer needs • Industry responsiveness has been demonstrated through the timely development and maintenance of key standards • HL7 Standards implementation has gotten easier • HL7 Education Plan has been developed • Tooling strategy has been developed

2 S T R A T E G I C I N I T I A T I V E S - D E T A I L E D

2.1 HL7 Recognition: Attain recognition as the lead developer and harmonizer of global technical and functional health informatics standards o Description: Assume a leadership position in the development of global technical and functional health informatics standards for electronic health records, personal health records, health information exchange, and clinical and operational data representation.

2.1.1 Realm specifications have been advanced to international HL7 specifications o Description: Standards that have been successfully deployed in a limited number of realms are brought to ballot within HL7 as Universal Realm specifications.

2.1.2 International HL7 specifications have achieved ISO recognition o Description: Universal Realm HL7 standards are advanced to ISO recognition, so that barriers to adoption across the globe are resolved, their use becomes ubiquitous, barriers to health information exchange across country boundaries are lessened, and those implementing standards have an international market.

2.1.3 Global adoption has increased o Description: "Adoption" is a decision to implement or use an HL7 standard. It can refer to choosing HL7 standards, and/or incorporating HL7 standards into the "outside world" (external to HL7) (e.g. RFPs, strategies, specifications, software).

2.1.4 HL7's role and value proposition in the overarching standards landscape has been clarified o Description: HL7 must work closely with national (for example, ONC, US TAG to ISO, NHS, Infoway, NEHTA), international (for example, ISO JIC, IHE, IHTSDO), and other complementary (such as. NQF, CIHI) stakeholder groups so as to ensure a complete interoperability solution including implementation guides. HL7's role, and HL7's relationship to these other organizations, needs to be clear, so as to minimize duplication of effort and the cost of standards adoption.

2.1.5 Key stakeholder groups have been identified, with value propositions and action plans for engaging each group o Description: Groups that play a valuable role in the development of HL7 standards, whether through technical development, functional requirement or identification have been defined. There is a written plan that describes how HL7 will seek to engage and involve each group in the standards development process. 2.2 HL7 Internal Processes: Streamline the HL7 standards development process

o Description: Optimize HL7 internal processes to more efficiently deliver global and realm-specific standards.

2.2.1 A globally applicable business model has been developed o Description: An efficient HL7 standards development process relies on engagement and contributions from across the globe. Components of a globally applicable business model include, but are not limited to, policy for use and redistribution of HL7 IP, membership and governance, and dues structure.

2.2.2 Working Group Meetings have been effective o Description: Ensure that all WGMs have all strategic business areas represented by healthy Work Groups as measured by the TSC with appropriate cross section of expertise.

2.2.3 Product quality has improved o Description: Product quality can be defined as "fitness for purpose". As part of quality improvement, there is a need to clearly define the purpose for which a standard is created, and to articulate the desired fitness criteria.

2.2.4 End to end V3/CDA template and implementation guide infrastructure has been developed o Description: A template infrastructure supports requirements analysis, development of templates that are consistent with domain models, and instance validation. This infrastructure must align with other Strategic Initiatives (e.g. must facilitate standards implementation), and must address the potential for layered complexity, where one artifact constrains another, which constrains another, and so on.

Implementation guides further profile or characterize the use of an HL7 standard, and may describe how HL7 specifications operate within a broader health information exchange ecosystem. Infrastructure supports publishing and development of sample instances. The requirement is for infrastructure that provides for the development of *consistent* implementation guides, with easy to use human and machine readable representations.

2.2.5 Requirements traceability has been enabled o Description: Traceability refers to the ability to link back, from a specification to the requirements that lead to its development, to the requirements that lead to certain design decisions. 2.2.6 Cross-artifact inconsistency is reduced o Description: This applies within a product "family" and between families (CDA, messages, services). Once inconsistencies can be measured, and once we have a plan for decreasing inconsistencies, we need to execute the plan and measure the effects.

2.3 HL7 Implementation: Develop standards that are easier to implement and more responsive to customer needs o Description: Improve HL7 processes to enable clinicians, technical experts, policy makers, SDOs and other stakeholder to collaborate in the development of standards and related solutions that are easier to implement, and more efficiently deliver global and realm-specific standards in response to new "customer" requirements.

2.3.1 Industry responsiveness has been demonstrated through the timely development and maintenance of key standards o Description: HL7 demonstrates its ability to assess and respond to key interoperability challenges (e.g. a nationally prioritized interoperability use case) and business needs through the timely development of relevant standards.

2.3.2 HL7 Standards implementation has gotten easier o Description: "Implementation" refers to the use of HL7 material in the development of software applications and messaging systems, for the exchange of health information.

2.3.3 HL7 Education Plan has been developed o Description: An education plan lays the HL7 strategy for dramatically increasing the number of folks with V3/CDA implementation-level knowledge. HL7 should be supporting the delivery of training - both training developed and provided by HL7, and that developed and provided by the market. Demand for HL7 products can be stimulated by both direct and indirect users of HL7 (an example of the former is implementers of HL7-based products and the latter is a user of HL7-based products).

2.3.4 Tooling strategy has been developed o Description: Efficiency in HL7 implementation is supported by tools. Tools developed for internal HL7 use are also of use externally. Components of a tooling strategy include, but are not limited to, prioritization of new tool development vs. ongoing support of existing tools, process for evaluating and incorporating externally developed tools.

2.3.5 Product strategy has been developed o Description: An HL7 product strategy and roadmap have been developed. Today, HL7 products are often organized to reflect how the product (standard) was developed. The product strategy should address organizing and packaging of products in ways that implementers of standards find useful. The product strategy should look at the products already held out as products and determine those that have a position where they can exist independent of other products, or as part of a formal product we have not yet recognized.

Submitted by Leah Lewis


References

Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2005 Oct 12;

http://www.hl7.org/documentcenter/public_temp_4BF5D005-1C23-BA17-0CE1A58E38D45506/strategic/roadmap/HL7_2012_Strategic_Initiatives%20FINAL.pdf

  1. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006 Jan-Feb;13(1):30-9. Epub 2005 Oct 12.