 |
Return to detail page at www.hitsp.org | HITSP/C37 |
| Prev TOC Next |
| HOME | ABOUT | MEMBERSHIP | NEWS & ANNOUNCEMENTS | MEETINGS | FAQ | CONTACT US | | Powered by American National Standards Institute |
|
Return to detail page at www.hitsp.org | HITSP/C37 |
| Prev TOC Next |
The purpose of this Component is to describe the specification for an electronic document as required by the AHIC EHR and Biosurveillance Use Cases. This is based upon the standard Health Level Seven (HL7) Clinical Document Architecture Release 2 (CDA R2), as in the HL7 V3 2006 normative edition. The goals supported by this Component specification are stated in the EHR and Biosurveillance Use Cases:
Transmission of complete, preliminary, final and updated laboratory results to the EHR system (local or remote) of the ordering clinician
Transmission of complete, preliminary, final and updated (or notification of) laboratory results to the EHR system (local or remote) or other clinical data system of designated providers of care (with respect to a specific patient)
Transmission of laboratory result data from electronically enabled healthcare delivery and public health systems in standardized and anonymized format to authorized Public Health Agencies with less than one day lag time
The Use Cases note that there are obstacles to achieving the stated goals. In particular, the following obstacle is delineated:
Lack of harmonization among data interoperability standards including vocabulary, laboratory and other messaging standards
This Lab Report Document Component is the result of a considered assessment of the current practices in electronic laboratory results reporting and the requirements of the Use Case. The HITSP Technical Committees chose the Integrating the Healthcare Enterprise (IHE) Laboratory Technical Framework Volume 3 (LAB TF-3) Document-based Transactions, Revision 2.0 specification because it generally meets the requirements of the Use Case and it represents the future direction for healthcare information sharing. The creation, use and management of documents have a long tradition in healthcare and the electronic equivalent of a paper document is a useful and efficient paradigm to implement when sharing information.
The HL7 CDA standard is specified as Extensible Markup Language (XML) documents. The ease of rendering electronic information in human readable form can be facilitated by XML. A 'document container' or document section/sub-section is similar to a named battery of laboratory tests, which collect the individual named laboratory tests. Finally, there are several other characteristics about an electronic document that make it well-suited for the Use Cases:
Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements
Stewardship - A clinical document is maintained by an organization entrusted with its care
Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated
Context - A clinical document establishes the default context for its contents
Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document
Readability - An XML clinical document can be rendered simultaneously in human readable and machine-interpretable forms [1]
This Lab Report Document Component is based on the content specifications as defined in the IHE Laboratory Technical Framework Volume 3 (LAB TF-3) Document-based Transactions, Revision 2.0 - For Trial Implementation, published August 16, 2007. This document was written and published in 2006 and subsequently revised and republished by the IHE Initiative. The IHE LAB TF-3 profile is reproduced in part in this specification with specific written permission from IHE. The IHE LAB TF-3 profile provides a set of constraints on the HL7 V3.0 CDA standard to specialize CDA to support a Laboratory Report. The entire IHE LAB TF-3 profile is in the public domain and available on the IHE Web Site.
Excerpts from that document are included here to highlight the HITSP approaches to implementation and to depict how the HITSP Lab Report Document Component should be populated. The descriptions for this Overview and parts of Section 2.2.1.1 Data Structure were taken in lengthy quotes from the publication and therefore, the same terms are used throughout this specification. These terms have the same meaning for purposes of this discussion.
IHE LAB TF-3 describes the scope as follows (quoted text begins here):
It describes a clinical laboratory report as an electronic document. Such an electronic document contains the complete set of final results produced by a clinical laboratory in fulfillment of one or more test orders for a patient. The intention is to share this human readable laboratory report, in an Electronic Health Record (EHR) or in a Personal Health Record (PHR) [2] , so that healthcare professionals taking care of the patient may access it and read it. In addition, this electronic laboratory report may contain test results in a machine readable format, to facilitate the integration of these observations in the database of a consumer system.
This content Integration Profile is focused on the sharing of sets of laboratory results in the form of a laboratory report structured document. Note: Although IHE states that it is not intended to address ordering and return of laboratory results to the ordering provider, HITSP does intend for it to be used for ordering and return of laboratory results to the ordering provider.
The scope covers the specialties already addressed by the IHE Laboratory Technical Framework: All laboratory specialties working on in-vitro specimens, including microbiology. The anatomic pathology specialty is not included in the scope of this Integration Profile. Blood Bank specialty is restricted to non-stock associated testing; results for Blood Banks (e.g., ABO blood group) are included.
The human rendering of the laboratory report defined in this Integration Profile is compatible with laboratory regulations in numerous countries, including CLIA in the USA. The laboratory report described in this Integration Profile, with its set of test results in a machine readable format, may also be used to share historical results with appropriate content anonymization and patient identification pseudonimization to create shared distributed repositories of laboratory information. [3]
The quoted text for the IHE LAB TF-3 ends here.
COPYRIGHT NOTICE
2009 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSIs copyright is clearly noted.
IHE materials used in this document have been extracted from relevant copyrighted materials with permission of Integrating the Healthcare Enterprise (IHE) International. Copies of this standard may be retrieved from the IHE Web Site at www.ihe.net.
This section provides a list of key reference documents and background material.
A list of key reference documents and background material is provided in the table below. These documents can be retrieved from www.hitsp.org.
|
Reference Document |
Document Description |
|
Lists and defines the acronyms used in this document |
|
|
Provides definitions for relevant terms used by HITSP documents |
|
|
TN900 is a reference document that provides the overall context for use of the HITSP Security and Privacy constructs |
This section describes the conformance criteria, which are objective statements of requirements that can be used to determine if a specific behavior, function, interface, or code set has been implemented correctly.
In order to claim conformance to this construct specification, an implementation must satisfy all the requirements and mandatory statements listed in this specification, the associated HITSP Interoperability Specification, its associated construct specifications, as well as conformance criteria from the selected base and composite standards. A conformant system must also implement all of the required interfaces within the scope, subset or implementation option that is selected from the associated Interoperability Specification.
Claims of conformance may only be made for the overall HITSP Interoperability Specification or Capability with which this construct is associated.
A HITSP Interoperability Specification must be implemented in its entirety for an implementation to claim conformance to the specification. HITSP may define the permissibility for interface scoping, subsetting or implementation options by which the specification may be implemented in a limited manner. Such scoping, subsetting and options may extend to associated constructs, such as this construct. This construct must implement all requirements within the selected scope, subset or options as defined in the associated Interoperability Specification to claim conformance.
|
Return to detail page at www.hitsp.org | HITSP/C37 |
| Prev TOC Next |