This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Product V2 IG"

From HL7Wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
=Product Brief - V2 Implementation Guides=
 
=Product Brief - V2 Implementation Guides=
−
back to [[Main_Page]]<br/>back to [[Product_List]]
+
*[[Product_V2_IG#Product_Name_-_V2.2_Implementation_Support_Guide|Version 2.2]]
 +
*[[Product_V2_IG#Product_Name_-_V2.3_Implementation_Support_Guide|Version 2.3]]
 +
*[[Product_V2_IG#Product_Name_-_V2.3.1_Implementation_Guide|Version 2.3.1]]
 +
*[[Product_V2_IG#Product_Name_-_V2_IG_Lab_Result_Report|V2 Lab Results]]
 +
*[[Product_V2_IG#Product_Name_-_V2.5.1_Orders_and_Observations_-_Lab_ELINCS|V2.5.1 Lab Orders/Observations - ELINCS]]
 +
*[[Product_V2_IG#Product_Name_-_NCPDP-HL7_V2_Electronic_Prescribing_Coordination_Mapping_Document|V2 E-Prescribing with NCPDP]]
 +
*[[Product_V2_IG#Product_Name_-_V2.5.1_ELR_to_Public_Health|V2.5.1 ELR to Public Health]]
 +
*[[Product_V2_IG#Product_Name_-_V2.5_German_Message_Profiles|Version 2.5 German Message Profiles]]
 +
 
 +
__TOC__
 +
back to [[Main_Page]]<br/>back to [[Product_List]]<br/> back to [[Product_V2]]
 +
 
 +
 
 +
==Product Name - V2.2 Implementation Support Guide==
 +
*HL7-V2.2 Implementation Support Guide
 +
 
 +
===Type===
 +
 
 +
 
 +
===Releases===
 +
 
 +
 
 +
===Summary===
 +
This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:
 +
 
 +
*Planning Methodology
 +
*Design and Implementation Methodology
 +
*HL7 Transaction Checklist
 +
*HL7 Message Diagrams
 +
 
 +
===Description===
 +
 
 +
 
 +
===Business Case (Intended Use, Customers)===
 +
Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology. Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3. HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.
 +
 
 +
===Benefits===
 +
It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.
 +
 
 +
===Implementations/ Case Studies (Actual Users)===
 +
The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world.
 +
 
 +
*Over 95 % of US healthcare organizations use HL7 V2.x
 +
*More than 35 countries have HL7 V2.x implementations
 +
 
 +
===Resources===
 +
 
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/pafm/index.cfm Patient Administration]
 +
*[http://www.hl7.org/Special/committees/orders/index.cfm Orders & Observations]
 +
*[http://www.hl7.org/Special/committees/fm/index.cfm Financial Management]
 +
*[http://www.hl7.org/Special/committees/patientcare/index.cfm Patient Care]
 +
*[http://www.hl7.org/Special/committees/education/index.cfm Education]
 +
*[http://www.hl7.org/Special/committees/ictc/index.cfm Implementation and Conformance]
 +
 
 +
 
 +
Education
 +
* See this link http://www.hl7.org/implement/training.cfm for V2 Introductory Tutorial
 +
*See the bottom of the page at  http://www.hl7.org/implement/standards/v2messages.cfm for V2 Standard Reference Materials available
 +
 
 +
Presentations
 +
*
 +
 
 +
Relationship to/ Dependencies on, other standards
 +
*
 +
 
 +
Links to current projects in development
 +
*none
 +
 
 +
==Product Name - V2.3 Implementation Support Guide==
 +
*HL7-V2.3 Implementation Support Guide
 +
 
 +
===Type===
 +
 
 +
 
 +
===Releases===
 +
June 1998
 +
 
 +
===Summary===
 +
This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:
 +
 
 +
A. Planning Methodology <br/>
 +
B. Design and Implementation Methodology<br/>
 +
C. Overview of HL7 Version 2.2<br/>
 +
D. Overview of HL7 Version 2.3<br/>
 +
E. HL7 Transaction Checklist<br/>
 +
F. HL7 Message Diagrams<br/>
 +
G. Lower Layer Protocols<br/>
 +
H. Helpful Hints<br/>
 +
I. Case Studies<br/>
 +
J. Sample Templates (RFI/RFP/Contract Points)<br/>
 +
K. Frequently Asked Questions<br/>
 +
 
 +
===Description===
 +
 
 +
 
 +
===Business Case (Intended Use, Customers)===
 +
Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology.  Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3.  HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.
 +
 
 +
===Benefits===
 +
It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.
 +
 
 +
===Implementations/ Case Studies (Actual Users)===
 +
The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. The HL7 Standard is intended to standardize data interchanges, not the underlying applications systems.  This means that there will be a wide variety in the manner in which the Standard is applied in different institutions.
 +
 
 +
*Over 95 % of US healthcare organisations use HL7 V2.x
 +
*More than 35 countries have HL7 V2.x implementations
 +
 
 +
===Resources===
 +
 
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/pafm/index.cfm Patient Administration]
 +
*[http://www.hl7.org/Special/committees/orders/index.cfm Orders & Observations]
 +
*[http://www.hl7.org/Special/committees/fm/index.cfm Financial Management]
 +
*[http://www.hl7.org/Special/committees/patientcare/index.cfm Patient Care]
 +
*[http://www.hl7.org/Special/committees/ictc/index.cfm Implementation and Conformance]
 +
 
 +
 
 +
Education
 +
* See this link http://www.hl7.org/implement/training.cfm for V2 Introductory Tutorial
 +
*See the bottom of the page at  http://www.hl7.org/implement/standards/v2messages.cfm for V2 Standard Reference Materials available
 +
 
 +
Presentations
 +
*
 +
 
 +
Relationship to/ Dependencies on, other standards
 +
*The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols.  A considerable liaison effort has been made with ACR/NEMA DICOM, X12, ASTM 1238.88 Laboratory Data Reporting, NCPDP, IEEE P1157 (“MEDIX”). 
 +
 
 +
Links to current projects in development
 +
*none
 +
 
 +
==Product Name - V2.3.1 Implementation Guide==
 +
*HL7-V2.3.1 Implementation Support Guide
 +
 
 +
===Type===
 +
 
 +
 
 +
===Releases===
 +
1999
 +
 
 +
===Summary===
 +
This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:
 +
 
 +
A. Planning Methodology <br/>
 +
B. Design and Implementation Methodology <br/>
 +
C. Overview of HL7 Version 2.2 <br/>
 +
D. Overview of HL7 Version 2.3 <br/>
 +
E. HL7 Transaction Checklist <br/>
 +
F. HL7 Message Diagrams <br/>
 +
G. Lower Layer Protocols <br/>
 +
H. Helpful Hints <br/>
 +
I. Case Studies <br/>
 +
J. Sample Templates (RFI/RFP/Contract Points) <br/>
 +
K. Frequently Asked Questions <br/>
 +
 
 +
===Description===
 +
 
 +
 
 +
===Business Case (Intended Use, Customers)===
 +
Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology.  Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3.  HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.
 +
 
 +
===Benefits===
 +
It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.
 +
 
 +
===Implementations/ Case Studies (Actual Users)===
 +
The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. The HL7 Standard is intended to standardize data interchanges, not the underlying applications systems.  This means that there will be a wide variety in the manner in which the Standard is applied in different institutions.
 +
 
 +
*Over 95 % of US healthcare organisations use HL7 V2.x
 +
*More than 35 countries have HL7 V2.x implementations
 +
 
 +
===Resources===
 +
 
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/pafm/index.cfm Patient Administration]
 +
*[http://www.hl7.org/Special/committees/orders/index.cfm Orders & Observations]
 +
*[http://www.hl7.org/Special/committees/fm/index.cfm Financial Management]
 +
*[http://www.hl7.org/Special/committees/patientcare/index.cfm Patient Care]
 +
*[http://www.hl7.org/Special/committees/education/index.cfm Education]
 +
*[http://www.hl7.org/Special/committees/ictc/index.cfm Implementation and Conformance]
 +
 
 +
Education
 +
* See this link http://www.hl7.org/implement/training.cfm for V2 Introductory Tutorial
 +
*See the bottom of the page at  http://www.hl7.org/implement/standards/v2messages.cfm for V2 Standard Reference Materials available
 +
 
 +
Presentations
 +
*
 +
 
 +
Relationship to/ Dependencies on, other standards
 +
*The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols.  A considerable liaison effort has been made with ACR/NEMA DICOM, X12, ASTM 1238.88 Laboratory Data Reporting, NCPDP,IEEE P1157 (“MEDIX”). 
 +
 
 +
Links to current projects in development
 +
*none
 +
 
 
==Product Name - V2 IG Lab Result Report==
 
==Product Name - V2 IG Lab Result Report==
−
*HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR, Release 1
+
*HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR, Release 1 (US Realm)
  
 
===Type===
 
===Type===
Line 8: Line 200:
  
 
===Releases===
 
===Releases===
−
V2.5.1 LABRSLTRPT
+
V2.5.1 LABRSLTRPT, 2007
  
 
===Summary===
 
===Summary===
Line 51: Line 243:
 
*LOINC,  
 
*LOINC,  
 
*UCUM
 
*UCUM
 +
*Link to [http://www.hl7.org/Memonly/downloads/Standards_Messaging_v251/InteroperabilitySpecificationLabResultMessage_v251.zip document] (member login required)
  
 
Links to current projects in development
 
Links to current projects in development
 
*none
 
*none
  
−
 
+
==Product Name - V2.5.1 Orders and Observations - Lab ELINCS==
−
==Product Name - V2.5.2 Orders and Observations - Lab ELINCS==
 
 
*V 2.5.1 Implementation Guide: Orders & Observations; Ambulatory Care Lab Result (ELINCS),  
 
*V 2.5.1 Implementation Guide: Orders & Observations; Ambulatory Care Lab Result (ELINCS),  
  
Line 110: Line 302:
  
 
===Description===
 
===Description===
−
The NCPDP SCRIPT Standard Implementation Guide was recommended by the United States (US)National Committee on Vital and Health Statistics (NCVHS) as a standard for Patient Medical Records Information (PMRI) in the US. It is used to facilitate the transfer of prescription data between pharmacies and prescribers. The current standard supports messages regarding new prescriptions, prescription changes, refill requests, prescription fill status notification, and prescription cancellation. In the future, enhancements may be included such as lab values, diagnosis, patient drug profiles, prescription transfers, and formulary inquiries. The NCPDP SCRIPT Standard Implementation Guide can be used in both the inpatient and outpatient settings, but is primarily used to facilitate messages related to ambulatory prescriptions.
+
The NCPDP SCRIPT Standard Implementation Guide was recommended by the United States (US) National Committee on Vital and Health Statistics (NCVHS) as a standard for Patient Medical Records Information (PMRI) in the US. It is used to facilitate the transfer of prescription data between pharmacies and prescribers. The current standard supports messages regarding new prescriptions, prescription changes, refill requests, prescription fill status notification, and prescription cancellation. In the future, enhancements may be included such as lab values, diagnosis, patient drug profiles, prescription transfers, and formulary inquiries. The NCPDP SCRIPT Standard Implementation Guide can be used in both the inpatient and outpatient settings, but is primarily used to facilitate messages related to ambulatory prescriptions.
  
 
===Business Case (Intended Use, Customers)===
 
===Business Case (Intended Use, Customers)===
Line 128: Line 320:
  
 
Work Groups
 
Work Groups
−
*[http://www.hl7.org/Special/committees/pharmacy/index.cfm Pharmacy]
+
*[http://www.hl7.org/Special/committees/medication/index.cfm Pharmacy]
  
 
Education
 
Education
Line 139: Line 331:
 
*HL7 2.4
 
*HL7 2.4
 
*NCPDP SCRIPT 4.2
 
*NCPDP SCRIPT 4.2
 +
 +
 +
Links to current projects in development
 +
*none
 +
 +
==Product Name - V2.5.1 ELR to Public Health==
 +
*HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm)
 +
 +
===Type===
 +
R1 Informative, ANSI Technical Report, HL7 Technical Report
 +
 +
===Releases===
 +
V2.5.1 LABRPTPH R1, 2010
 +
 +
===Summary===
 +
This guide contains the necessary specifications for clinical laboratory results reporting to public health, for use in the U.S. Realm.
 +
 +
===Description===
 +
This implementation guide describes the transmission of laboratory-reportable findings to appropriate local, state, territorial and federal health agencies using the HL7 2.5.1 ORU^R01 message.  In particular, this guide addresses messaging content and dynamics related to the transmission of Laboratory Reportable Result Messages (i.e.,. Electronic Laboratory Reporting, or ELR). <br/>
 +
Each state and territory has requirements for laboratories to report certain findings to health officials. In the past, these reports were written by hand on forms provided by health departments and mailed to appropriate offices. With computerization of laboratories, it has become possible for laboratories to send reportable data to health departments electronically. The message described in this guide is not specific to any pathogen or reportable condition and is applicable for most biological and chemistry laboratory-reportable findings, but does not cover reporting of results from laboratory to laboratory.<br/>
 +
Obsolete ELR guides for versions 2.3x, 2.3.1 and 2.4 exist. This guide responds to requests from U.S. laboratories that ELR to public health guidance be made consistent with recently approved laboratory-related v2.5.1 IGs such as the HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperability Laboratory Result Reporting to EHR (US Realm), Release 1.    <br/>
 +
This guide is designed to align as closely as possible with the Laboratory Result Reporting to EHR IG.  Both implementation guides focus on key points of broad interoperability. These key points include the following:
 +
* Use of strong identifiers for key information objects: These information objects include patients, orders, providers and organizations. A strong identifier is one that uniquely identifies the object in question in a global fashion. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. This is accomplished through the use of assigning authorities for the identifier. In this guide, an assigning authority is normally handled as an ISO Object Identifier (OID). The combination of the identifier and the OID should always be unique. Assigners of identifiers need to create and register OIDs such that each identifier associated with an assigning authority is globally unique (i.e., it does not collide with another identifier assigned by the same or another assigning authority). This uniqueness ensures that each identifier can be broadly shared among independent healthcare organizations and still point to its originally associated object.
 +
*Use of vocabulary standards: This guide calls for specific vocabulary standards for the exchange of laboratory information. Use of standard vocabularies is important for a number of reasons. Use of standard vocabularies allows broad distribution of healthcare information without the need for individual institutions to exchange master files for data such as test codes or result codes. Each institution maps its own local vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a single island of information. Standard vocabularies, particularly coded laboratory results, enable more automated decision support for patient healthcare, as well as more automated public health surveillance of populations.
 +
 +
===Business Case (Intended Use, Customers)===
 +
The American Recovery and Reinvestment Act of 2009 (Recovery Act) authorizes the Centers for Medicare & Medicaid Services (CMS) to provide reimbursement incentives for eligible professionals and hospitals who are successful in becoming “meaningful users” of certified electronic health record (EHR) technology.  The Medicare EHR incentive program will provide incentive payments to eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) that are meaningful users of certified EHR technology.  Electronic submission of reportable (as required by state or local law) lab results to public health agencies is proposed as a stage 1 criterion of meaningful use ([http://edocket.access.gpo.gov/2010/E9-31217.htm Notice of Proposed Rulemaking]). <br/>
 +
ONC has issued an [http://edocket.access.gpo.gov/2010/E9-31216.htm Interim Final Rule (IFR)] that specifies the Secretary’s adoption of an initial set of standards, implementation specifications, and certification criteria for electronic health record (EHR) technology.  HL7 v2.5.1 has been specified as the messaging standard for transmission of laboratory reports to public health. This IG supports that process. <br/>
 +
'''''Stakeholders''''' include:
 +
*Clinical and public health laboratories in the US
 +
*US local, state. territorial and tribal public health jurisdictions
 +
*Council of State and Territorial Epidemiologists (CSTE)
 +
*Centers for Disease Control and Prevention (CDC)
 +
*Centers for Medicare and Medicaid Services (CMS)
 +
*Laboratory information system developers and vendors
 +
 
 +
===Benefits===
 +
*Consistent implementation across disparate systems. 
 +
*Improved efficiency for laboratories needing to report to multiple jurisdictions. 
 +
*Improved efficiency for public health organizations receiving reports from multiple laboratories.
 +
 +
 +
===Implementations/ Case Studies (Actual Users)===
 +
U.S. Public Health
 +
 +
===Resources===
 +
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/pher/index.cfm Public Health and Emergency Response]
 +
*[http://www.hl7.org/Special/committees/orders/index.cfm Orders & Observations]
 +
 +
 +
Education
 +
*TBD
 +
 +
Presentations
 +
*TBD
 +
 +
Relationship to/ Dependencies on, other standards
 +
*HL7 v2.5.1
 +
*SNOMED
 +
*LOINC
 +
*UCUM
  
 
Links to current projects in development
 
Links to current projects in development
 
*none
 
*none
 +
 +
==Product Name - V2.5 German Message Profiles==
 +
*HL7-V2.5 German Message Profiles
 +
 +
===Type===
 +
German Realm
 +
 +
===Releases===
 +
*Release 2.1, June 2007
 +
*Release 2.0, Feb 2006
 +
*Release 1.1, Dec 2004
 +
*Release 1.0, Oct 2004
 +
 +
===Summary===
 +
These documents - one for each profile - provides guidance on how to constrain the standard messages for certain scenarios like standard ADT, DRG and billing. The messages cover the following domains:
 +
 +
# ADT
 +
# BAR
 +
# DFT
 +
# MDM
 +
 +
===Description===
 +
The set of documents provide some guidance for general implementation, detailed segment and data type specification as well as the different messages in different scenarios. E.g., the German health insurance card is supported.
 +
 +
===Business Case (Intended Use, Customers)===
 +
 +
===Benefits===
 +
 +
 +
===Implementations/ Case Studies (Actual Users)===
 +
 +
===Resources===
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/pafm/index.cfm Patient Administration]
 +
*[http://www.hl7.org/Special/committees/fm/index.cfm Financial Management]
 +
 +
Links
 +
[[http://www.hl7.de/download/documents/Profile_2.1.zip ZIP file for download]] (in German)
 +
 +
 +
==Product Name - V2 Implementation Guide for vMR - CDS==
 +
*HL7 Version 2 Implementation Guide: Implementing the Virtual Medical Record for Clinical Decision Support (vMR-CDS) in HL7 Version 2, Release 1
 +
 +
===Type===
 +
Informative
 +
 +
===Releases===
 +
Release 1 balloting Informative May 2010
 +
 +
===Summary===
 +
This project is developing a Virtual Medical Record specification for clinical decision support for use with the HL7 version 2 family of standards.
 +
 +
===Description===
 +
A Virtual Medical Record (vMR) for clinical decision support (CDS) is a data model for representing clinical information inputs and outputs that can be exchanged between CDS engines and local clinical information systems, through mechanisms such as CDS services.  The goal of the overall vMR project is to create HL7 vMR data models capable of supporting scalable, interoperable CDS.  This specific sub-project within the overall vMR project is developing a guide for implementing the vMR using HL7 v2 messages.  It is derived from the vMR Domain Analysis Model (DAM), which is being developed through a separate sub-project within the overall vMR project.
 +
 +
 +
===Business Case (Intended Use, Customers)===
 +
In order to enable scalable and interoperable clinical decision support (CDS), there is a critical need for the definition and adoption of a common CDS information model, which has generally been referred to as a virtual medical record (vMR).  The objective of this project is to address this need by establishing a standard information model for representing clinical information inputs and outputs that can be exchanged between CDS engines and clinical information systems, through mechanisms such as CDS services.
 +
 
 +
===Benefits===
 +
vMR advantages to CDS are: - Creates one CDS data model, reducing data and terminology discrepancies. - Identifies restrictions that can be made to existing HL7 data models to simplify CDS development, while still ensuring support for needed CDS capabilities. - Enables CDS through a consistent set of standardized data inputs and outputs. - Encourages CDS at the point of care by reducing costs and response turn around time. - Eliminates the need for EHR vendors to maintain proprietary CDS structures and messages.
 +
 +
===Implementations/ Case Studies (Actual Users)===
 +
Pending
 +
 +
===Resources===
 +
 +
Work Groups
 +
*[http://www.hl7.org/Special/committees/dss/index.cfm Clinical Decision Support]
 +
 +
Education
 +
*http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)
 +
<!--
 +
Presentations
 +
*TBD
 +
-->
 +
Relationship to/ Dependencies on, other standards
 +
*Based on [[Product_vMR_DAM|vMR Domain Analysis Model.]]
 +
 +
Links to current projects in development
 +
*[http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=184 Project Insight # 184], Virtual Medical Record (vMR) for Clinical Decision Support

Latest revision as of 16:00, 29 November 2011

Product Brief - V2 Implementation Guides

Contents

back to Main_Page
back to Product_List
back to Product_V2


Product Name - V2.2 Implementation Support Guide

  • HL7-V2.2 Implementation Support Guide

Type

Releases

Summary

This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:

  • Planning Methodology
  • Design and Implementation Methodology
  • HL7 Transaction Checklist
  • HL7 Message Diagrams

Description

Business Case (Intended Use, Customers)

Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology. Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3. HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.

Benefits

It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.

Implementations/ Case Studies (Actual Users)

The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world.

  • Over 95 % of US healthcare organizations use HL7 V2.x
  • More than 35 countries have HL7 V2.x implementations

Resources

Work Groups


Education

Presentations

Relationship to/ Dependencies on, other standards

Links to current projects in development

  • none

Product Name - V2.3 Implementation Support Guide

  • HL7-V2.3 Implementation Support Guide

Type

Releases

June 1998

Summary

This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:

A. Planning Methodology
B. Design and Implementation Methodology
C. Overview of HL7 Version 2.2
D. Overview of HL7 Version 2.3
E. HL7 Transaction Checklist
F. HL7 Message Diagrams
G. Lower Layer Protocols
H. Helpful Hints
I. Case Studies
J. Sample Templates (RFI/RFP/Contract Points)
K. Frequently Asked Questions

Description

Business Case (Intended Use, Customers)

Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology. Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3. HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.

Benefits

It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.

Implementations/ Case Studies (Actual Users)

The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. The HL7 Standard is intended to standardize data interchanges, not the underlying applications systems. This means that there will be a wide variety in the manner in which the Standard is applied in different institutions.

  • Over 95 % of US healthcare organisations use HL7 V2.x
  • More than 35 countries have HL7 V2.x implementations

Resources

Work Groups


Education

Presentations

Relationship to/ Dependencies on, other standards

  • The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols. A considerable liaison effort has been made with ACR/NEMA DICOM, X12, ASTM 1238.88 Laboratory Data Reporting, NCPDP, IEEE P1157 (“MEDIX”).

Links to current projects in development

  • none

Product Name - V2.3.1 Implementation Guide

  • HL7-V2.3.1 Implementation Support Guide

Type

Releases

1999

Summary

This document provides assistance to health care institutions, hospital information systems vendors, consultants and other support groups that are considering systems development and implementation activities in a multi-system environment using the Health Level Seven (HL7) protocol. This support guide includes the following information:

A. Planning Methodology
B. Design and Implementation Methodology
C. Overview of HL7 Version 2.2
D. Overview of HL7 Version 2.3
E. HL7 Transaction Checklist
F. HL7 Message Diagrams
G. Lower Layer Protocols
H. Helpful Hints
I. Case Studies
J. Sample Templates (RFI/RFP/Contract Points)
K. Frequently Asked Questions

Description

Business Case (Intended Use, Customers)

Institutions that are considering major systems development activities (e.g. comprehensive system upgrades/replacements), migration to an open systems architecture and/or integration of various clinical, financial or administrative systems with a central Hospital Information System (HIS) - and are considering HL7 as a mechanism for integrating these systems should refer to the planning component of the methodology. Institutions that have already made a decision to implement one or more HL7 interfaces in any type of an environment will also find certain information in the planning section useful, but should concentrate on the design and implementation sub-section of the implementation methodology covered in Chapter 3. HIS vendors should focus on the design and implementation sections, but may also consider reviewing the planning section as background.

Benefits

It is critical when planning for implementation of a multi-system environment that an overall systems strategy and technical architecture be established. These strategies will help guide the health care institution through critical issues such as how information technology will be utilized to support business goals and objectives, whether an HL7 approach is appropriate for your organization and what the overall technical architecture of the organization will be.

Implementations/ Case Studies (Actual Users)

The Version 2 Messaging Standard is one of the most widely implemented standards for healthcare information in the world. The HL7 Standard is intended to standardize data interchanges, not the underlying applications systems. This means that there will be a wide variety in the manner in which the Standard is applied in different institutions.

  • Over 95 % of US healthcare organisations use HL7 V2.x
  • More than 35 countries have HL7 V2.x implementations

Resources

Work Groups

Education

Presentations

Relationship to/ Dependencies on, other standards

  • The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols. A considerable liaison effort has been made with ACR/NEMA DICOM, X12, ASTM 1238.88 Laboratory Data Reporting, NCPDP,IEEE P1157 (“MEDIX”).

Links to current projects in development

  • none

Product Name - V2 IG Lab Result Report

  • HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR, Release 1 (US Realm)

Type

R1 Informative, ANSI Technical Report, HL7 Technical Report

Releases

V2.5.1 LABRSLTRPT, 2007

Summary

This guide contains the necessary specifications for clinical laboratory results reporting to EHRs for use in the U.S. Realm. It is one component of an overall project for HITSP to establish implementation guides for aspects of the American Health Information Community (AHIC) use cases that can be recognized by the Secretary of the Department of Health and Human Services (HHS). In particular, this guide addresses messaging content and dynamics related to the AHIC Harmonized Use Case for Electronic Health Records (Laboratory Result Reporting), an AHIC EHR-Lab Result use case.

Description

The U.S. Realm – Interoperability Specification: Lab Result Message to EHR is the Health Level Seven (HL7) response to a request from the U.S. Health Information Technology Standards Panel (HITSP) for a standard laboratory message to meet the requirements of its use case. In March, 2006, the HHS Office of the National Coordinator For Health IT published the Harmonized Use Case for Electronic Health Records (Laboratory Result Reporting) in response to a request and specifications from the American Health Information Community (AHIC). The use case focuses on widely-available, well-standardized methods that will support the secure access to electronic laboratory results and interpretations for clinical care by authorized parties and is driven by the need for timely electronic access to ordered, referred and historical lab results. Ordering clinicians receive lab test results as a response to an order by having the test results sent either directly to the clinician’s EHR system (local or remote) or to another clinical data system in support of the provisioning of historical results.

HITSP received the harmonized use case and developed Interoperability Specification 1 (IS01) for Electronic Health Records Laboratory Reporting. HITSP has requested this implementation guide to serve as guidance for implementers and those certifying electronic health record systems. This document is intended to meet the needs and requirements of implementation guidance in relevant HITSP Interoperability Specifications.

This specification provides an applicable ambulatory care lab-reporting specification that can be adopted as a US industry standard, thereby obviating the need for clinical laboratories and EHR systems to define anew the specifications of each laboratory-to-EHR interface that is implemented. This standard covers the exchange of laboratory results from the testing source between providers and other authorized parties, such as Public Health. Be aware, this guide does not address laboratory orders.

One of the primary features of this implementation guide is its focus on key points of broad interoperability. These key points include the following:

  • Use of strong identifiers for key information objects – These information objects include patients, orders, providers and organizations. A strong identifier is one that uniquely identifies the object in question in a global fashion. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. This is accomplished through the use of assigning authorities for the identifier. In this guide, an assigning authority is normally handled as an ISO Object Identifier (OID). The combination of the identifier and the OID should always be unique. Assigners of identifiers need to create and register OIDs such that each identifier associated with an assigning authority is globally unique (i.e., it does not collide with another identifier assigned by the same or another assigning authority). This uniqueness ensures that each identifier can be broadly shared among independent healthcare organizations and still point to its originally associated object.
  • Use of Vocabulary Standards This guide calls for specific vocabulary standards for the exchange of laboratory information. Use of standard vocabularies is important for a number of reasons. Use of standard vocabularies allows broad distribution of healthcare information without the need for individual institutions to exchange master files for data such as test codes, result codes, etc. Each institution maps its own local vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a single island of information. Standard vocabularies, particularly coded laboratory results, enable more automated decision support for patient healthcare, as well as more automated public health surveillance of populations.

Business Case (Intended Use, Customers)

  • Provider:Laboratory Services,
  • Vendor: Lab,
  • Stakeholder: US Clinical and Public Health Laboratories, Local and State Departments of Health

Benefits

Consistent implementation across disparate systems.

Implementations/ Case Studies (Actual Users)

Public Health

Resources

Work Groups

Education

Presentations

Relationship to/ Dependencies on, other standards

  • HL7 2.5.1,
  • SNOMED,
  • LOINC,
  • UCUM
  • Link to document (member login required)

Links to current projects in development

  • none

Product Name - V2.5.1 Orders and Observations - Lab ELINCS

  • V 2.5.1 Implementation Guide: Orders & Observations; Ambulatory Care Lab Result (ELINCS),

Type

R1 Informative, ANSI Technical Report, HL7 Technical Report

Releases

HL7 TR V2.5.1 OO ELINCS R1-2008

Summary

The HL7 Ambulatory Care Laboratory Result Implementation Guide (US Realm) is a messaging specification intended to standardize the electronic reporting of test results from clinical laboratories to electronic health record (EHR) systems found in ambulatory care practices. It is specific to the US Realm.

This specification provides an applicable ambulatory care lab-reporting specification that can be adopted as a US industry standard, thereby obviating the need for clinical laboratories and EHR systems to define anew the specifications of each laboratory-to-EHR interface that is implemented.

This specification focuses exclusively on the electronic reporting of ambulatory care lab results in the US Realm. Electronic messaging for other tasks and other contexts is outside the scope of the specification at this time, including messaging for ordering ambulatory lab tests, for reporting inpatient lab results, for reporting lab results outside of the US Realm, and for special-purpose reporting such as public health or biosurveillance.

Business Case (Intended Use, Customers)

Provider:Laboratory Services, Vendor: Lab

Benefits

Consistent implementation across disparate systems.

Implementations/ Case Studies (Actual Users)

Quest Diagnostics Incorporated, LabCorp, see more at http://elincs.chcf.org/Implementations.aspx

Resources

Work Groups

Education

Relationship to/ Dependencies on, other standards

  • HL7 2.5.1,
  • SNOMED,
  • LOINC,

Links to current projects in development

  • none

Product Name - NCPDP-HL7 V2 Electronic Prescribing Coordination Mapping Document

  • HL7-NCPDP Electronic Prescribing Coordination Mapping Document, Release 1

Type

R1 Informative

Releases

V2 EPCMAPPING, R1; January 2007

Summary

This NCPDP-HL7 Electronic Prescribing Coordination Mapping Document is intended to provide mapping requirements for electronic prescribing systems using HL7 Versions 2.4 and above to communicate with systems using NCPDP SCRIPT Standard Implementation Guide Version 4.2 and above, for transactions in electronic prescribing business functions.

Description

The NCPDP SCRIPT Standard Implementation Guide was recommended by the United States (US) National Committee on Vital and Health Statistics (NCVHS) as a standard for Patient Medical Records Information (PMRI) in the US. It is used to facilitate the transfer of prescription data between pharmacies and prescribers. The current standard supports messages regarding new prescriptions, prescription changes, refill requests, prescription fill status notification, and prescription cancellation. In the future, enhancements may be included such as lab values, diagnosis, patient drug profiles, prescription transfers, and formulary inquiries. The NCPDP SCRIPT Standard Implementation Guide can be used in both the inpatient and outpatient settings, but is primarily used to facilitate messages related to ambulatory prescriptions.

Business Case (Intended Use, Customers)

The NCPDP SCRIPT Standard Implementation Guide has been adopted by US community pharmacies as the means by which they will receive and send prescription information with prescribers; long-term care facilities are reviewing SCRIPT usage. The HL7 2.x standards were not specifically designed to manage transactions between prescribers and retail pharmacies, although this functionality is available in HL7 V3. Because inpatient facilities use HL7 2.x as their primary means for managing prescription information, there is a need to map HL7 to SCRIPT for the purposes of communicating with ambulatory pharmacies.

Benefits

The creation of an HL7 to NCPDP mapping document facilitates a number of potential interactions:

  • Inpatient facilities using HL7 could write prescriptions for patients being discharged from the hospital using their existing system. The message could then be translated in an automated fashion to a SCRIPT-compliant message, which could be delivered to the pharmacy for dispensing.
  • Similarly, outpatient facilities using HL7-based prescription tools could write prescriptions for patients. The message could then be translated in an automated fashion to a SCRIPT-compliant message, which could be delivered to the pharmacy for dispensing. Likewise, pharmacies could communicate refill or renewal requests to prescribers from SCRIPT messages that are then mapped to HL7 messages.
  • Inpatient facilities and prescribers could receive SCRIPT fill notification messages from pharmacies, providing patient compliance information of whether the patient picked up the prescription, picked up a partial prescription, or never picked up the prescription.
  • Prescription history messages in SCRIPT can be communicated between prescribing entities using SCRIPT or HL7 standards.

Implementations/ Case Studies (Actual Users)

Resources

Work Groups

Education

Presentations

Relationship to/ Dependencies on, other standards

  • HL7 2.4
  • NCPDP SCRIPT 4.2


Links to current projects in development

  • none

Product Name - V2.5.1 ELR to Public Health

  • HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm)

Type

R1 Informative, ANSI Technical Report, HL7 Technical Report

Releases

V2.5.1 LABRPTPH R1, 2010

Summary

This guide contains the necessary specifications for clinical laboratory results reporting to public health, for use in the U.S. Realm.

Description

This implementation guide describes the transmission of laboratory-reportable findings to appropriate local, state, territorial and federal health agencies using the HL7 2.5.1 ORU^R01 message. In particular, this guide addresses messaging content and dynamics related to the transmission of Laboratory Reportable Result Messages (i.e.,. Electronic Laboratory Reporting, or ELR).
Each state and territory has requirements for laboratories to report certain findings to health officials. In the past, these reports were written by hand on forms provided by health departments and mailed to appropriate offices. With computerization of laboratories, it has become possible for laboratories to send reportable data to health departments electronically. The message described in this guide is not specific to any pathogen or reportable condition and is applicable for most biological and chemistry laboratory-reportable findings, but does not cover reporting of results from laboratory to laboratory.
Obsolete ELR guides for versions 2.3x, 2.3.1 and 2.4 exist. This guide responds to requests from U.S. laboratories that ELR to public health guidance be made consistent with recently approved laboratory-related v2.5.1 IGs such as the HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperability Laboratory Result Reporting to EHR (US Realm), Release 1.
This guide is designed to align as closely as possible with the Laboratory Result Reporting to EHR IG. Both implementation guides focus on key points of broad interoperability. These key points include the following:

  • Use of strong identifiers for key information objects: These information objects include patients, orders, providers and organizations. A strong identifier is one that uniquely identifies the object in question in a global fashion. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. This is accomplished through the use of assigning authorities for the identifier. In this guide, an assigning authority is normally handled as an ISO Object Identifier (OID). The combination of the identifier and the OID should always be unique. Assigners of identifiers need to create and register OIDs such that each identifier associated with an assigning authority is globally unique (i.e., it does not collide with another identifier assigned by the same or another assigning authority). This uniqueness ensures that each identifier can be broadly shared among independent healthcare organizations and still point to its originally associated object.
  • Use of vocabulary standards: This guide calls for specific vocabulary standards for the exchange of laboratory information. Use of standard vocabularies is important for a number of reasons. Use of standard vocabularies allows broad distribution of healthcare information without the need for individual institutions to exchange master files for data such as test codes or result codes. Each institution maps its own local vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a single island of information. Standard vocabularies, particularly coded laboratory results, enable more automated decision support for patient healthcare, as well as more automated public health surveillance of populations.

Business Case (Intended Use, Customers)

The American Recovery and Reinvestment Act of 2009 (Recovery Act) authorizes the Centers for Medicare & Medicaid Services (CMS) to provide reimbursement incentives for eligible professionals and hospitals who are successful in becoming “meaningful users” of certified electronic health record (EHR) technology. The Medicare EHR incentive program will provide incentive payments to eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) that are meaningful users of certified EHR technology. Electronic submission of reportable (as required by state or local law) lab results to public health agencies is proposed as a stage 1 criterion of meaningful use (Notice of Proposed Rulemaking).
ONC has issued an Interim Final Rule (IFR) that specifies the Secretary’s adoption of an initial set of standards, implementation specifications, and certification criteria for electronic health record (EHR) technology. HL7 v2.5.1 has been specified as the messaging standard for transmission of laboratory reports to public health. This IG supports that process.
Stakeholders include:

  • Clinical and public health laboratories in the US
  • US local, state. territorial and tribal public health jurisdictions
  • Council of State and Territorial Epidemiologists (CSTE)
  • Centers for Disease Control and Prevention (CDC)
  • Centers for Medicare and Medicaid Services (CMS)
  • Laboratory information system developers and vendors

Benefits

  • Consistent implementation across disparate systems.
  • Improved efficiency for laboratories needing to report to multiple jurisdictions.
  • Improved efficiency for public health organizations receiving reports from multiple laboratories.


Implementations/ Case Studies (Actual Users)

U.S. Public Health

Resources

Work Groups


Education

  • TBD

Presentations

  • TBD

Relationship to/ Dependencies on, other standards

  • HL7 v2.5.1
  • SNOMED
  • LOINC
  • UCUM

Links to current projects in development

  • none

Product Name - V2.5 German Message Profiles

  • HL7-V2.5 German Message Profiles

Type

German Realm

Releases

  • Release 2.1, June 2007
  • Release 2.0, Feb 2006
  • Release 1.1, Dec 2004
  • Release 1.0, Oct 2004

Summary

These documents - one for each profile - provides guidance on how to constrain the standard messages for certain scenarios like standard ADT, DRG and billing. The messages cover the following domains:

  1. ADT
  2. BAR
  3. DFT
  4. MDM

Description

The set of documents provide some guidance for general implementation, detailed segment and data type specification as well as the different messages in different scenarios. E.g., the German health insurance card is supported.

Business Case (Intended Use, Customers)

Benefits

Implementations/ Case Studies (Actual Users)

Resources

Work Groups

Links [ZIP file for download] (in German)


Product Name - V2 Implementation Guide for vMR - CDS

  • HL7 Version 2 Implementation Guide: Implementing the Virtual Medical Record for Clinical Decision Support (vMR-CDS) in HL7 Version 2, Release 1

Type

Informative

Releases

Release 1 balloting Informative May 2010

Summary

This project is developing a Virtual Medical Record specification for clinical decision support for use with the HL7 version 2 family of standards.

Description

A Virtual Medical Record (vMR) for clinical decision support (CDS) is a data model for representing clinical information inputs and outputs that can be exchanged between CDS engines and local clinical information systems, through mechanisms such as CDS services. The goal of the overall vMR project is to create HL7 vMR data models capable of supporting scalable, interoperable CDS. This specific sub-project within the overall vMR project is developing a guide for implementing the vMR using HL7 v2 messages. It is derived from the vMR Domain Analysis Model (DAM), which is being developed through a separate sub-project within the overall vMR project.


Business Case (Intended Use, Customers)

In order to enable scalable and interoperable clinical decision support (CDS), there is a critical need for the definition and adoption of a common CDS information model, which has generally been referred to as a virtual medical record (vMR). The objective of this project is to address this need by establishing a standard information model for representing clinical information inputs and outputs that can be exchanged between CDS engines and clinical information systems, through mechanisms such as CDS services.

Benefits

vMR advantages to CDS are: - Creates one CDS data model, reducing data and terminology discrepancies. - Identifies restrictions that can be made to existing HL7 data models to simplify CDS development, while still ensuring support for needed CDS capabilities. - Enables CDS through a consistent set of standardized data inputs and outputs. - Encourages CDS at the point of care by reducing costs and response turn around time. - Eliminates the need for EHR vendors to maintain proprietary CDS structures and messages.

Implementations/ Case Studies (Actual Users)

Pending

Resources

Work Groups

Education

Relationship to/ Dependencies on, other standards

Links to current projects in development

Retrieved from "https://wiki.hl7.org/w/index.php?title=Product_V2_IG&oldid=56577"