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

Product V2 IG

From HL7Wiki
Jump to navigation Jump to search

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 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

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

Type

R1 Informative, ANSI Technical Report, HL7 Technical Report

Releases

V2.5.1 LABRSLTRPT

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

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

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)

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