 |
Return to detail page at www.hitsp.org | HITSP/IS03 |
| 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/IS03 |
| Prev TOC Next |
As an introduction to the Healthcare Information Technology Standards Panel (HITSP) Consumer Empowerment and Access to Clinical Information via Networks Interoperability Specification, this section provides a high level overview of the information sharing scenario enabled by following this specification, provides a document map of the construct relationships for the Interoperability Specification, acknowledges the copyright protections that pertain, and provides a list of key reference documents and background material.
This update to the HITSP Consumer Empowerment and Access to Clinical Information via Networks Interoperability Specification (IS) introduces two new constructs, which address specific gaps identified in previous versions of this IS. This update uses HITSP/C62 Unstructured Document, which allows the user to use documents such as PDF, scanned documents etc. For the purposes of this IS HITSP/C62 is used to provide support for an entry-level advance directive document. The other new construct included in this update is HITSP/T81 Retrieval of Medical Knowledge, which provides a mechanism for the query and receipt of medical knowledge. HITSP/T81 addresses the need to allow users the ability to obtain additional knowledge about a clinical concept including translating concepts into layperson language.
This section provides a high level definition of this Interoperability Specification and background information about the underlying Use Case that it is based upon.
The HITSP Consumer Empowerment and Access to Clinical Information via Networks Interoperability Specification identifies a subset of the functional components of the healthcare enterprises and health information networks, called HITSP actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. This document defines specific implementations of established standards intended to achieve integration goals that promote appropriate exchange of a consumers personal health record information.
The HITSP Consumer Empowerment Use Case describes the active involvement of consumers (i.e., individuals) in managing their healthcare and gaining the benefits of having their health information in a format easily accessible to them. This includes having a personal health record (PHR) system to track healthcare information, insurance, family history, medications, and other special conditions.
As part of a PHR, this specification addresses several key areas: The patients registration data and a healthcare summary including medication history, allergies, encounters, problems and conditions, immunizations, advance directives, and key laboratory tests results.
A vital part of a PHR is the registration information. A visit to the doctor or hospital frequently requires filling out multiple forms. These forms collect information such as name, address, insurance, medications, allergies, etc. When an individual requires laboratory work or other testing, the same information has to be collected again. A single electronic registration will make it easier for individuals to give their information and for clinicians to use it. Additionally, the consumer could update the information once and share it with all healthcare providers.
An electronic healthcare summary provides a set of key health related information at a point in time. It includes a medication history which provides the consumer with an updated list of all pertinent medications and allergies in an easily accessible format. Most individuals do not know the specific medications and exact dosages that have been prescribed to them, and often do not know their own allergies. In addition, clinicians do not always have consistent prescription information about the same individual, nor do they have easy access to medication information directly from the consumer. Too often, this results in errors or unnecessary treatments. An electronic medication history would have all the current data available to the individual and to each authorized healthcare provider. The need for an electronic medication history was highlighted by the high interest in the KatrinaHealth.org web tool. A complete electronic medication list would also prevent drug-to-drug or allergic reactions when subsequent prescriptions are written. The consumers healthcare summary should also include a list of allergies, encounters, identified conditions and problems diagnosed, the current list of immunizations, and laboratory test results as indications of the consumers health status.
Traditionally, registration is viewed from the healthcare providers perspective and consists of patient registration with the healthcare provider organization and the consumer giving their information to the healthcare provider. The concept of consumer empowerment creates a new perspective of healthcare providers and healthcare organizations that goes beyond traditional registration to provide the healthcare providers contact and identification information to the consumer. This process of reciprocal registration and sharing of data are encouraged and facilitated by the Use Case. It is desired, but not required or essential, that healthcare providers who register a patient should also enter their own information into the patients registration summary. Ideally that would include contact information and the identifier, such as a medical record number, that the healthcare provider assigned to that patient. This will facilitate the PHR system to serve as a Regional Health Information Organization (RHIO) of one having all essential master patient index data and record locator data for a single patient.
This Interoperability Specification defines three types of interoperable documents. The first is a registration and healthcare summary document; the second, a laboratory report document (also used for the HITSP/IS01 Electronic Health Records Laboratory Results Reporting); and finally, the third is an unstructured document which can be used for scanned documents (such as advance directives). One means to share these documents is by registering them in a record locator and retrieving them from the referenced document repository. Other types of interoperable documents may be defined by HITSP in the future such as radiology reports, images, electrocardiogram (ECG) reports, etc. These other types of documents are out of scope of the Use Cases presented to HITSP for consideration at this time.
The interoperability requirements are based upon six well-defined scenarios related to a consumers personal health record. This is the first document in a series of documents that need to be understood and implemented in order to conform to this specification.
Each HITSPInteroperability Specification (IS)is comprised of a suite of constructs that, taken as a whole, define how to integrate and constrain existing standards and specifications to satisfy the requirementsimposed by a given Use Case. TheIS groups specific actions and actors to describe the relevant context(s) for the use ofHITSP constructs that further identify and constrain standards where necessary. In addition to ISs, there are three other types of HITSP constructs called Transaction Packages (TP), Transactions (T), andComponents (C). The document map in Figure 1-1depicts how this IS integrates and constrains HITSP constructs to support the information exchange, within the defined context of the Use Case. Implementers should read the documents that describe the constructs depicted in the diagram for their details and specific uses. Note that the baseline Security and Privacy constructs are not shown in the diagram, however, they are described in Table 1-1.
Figure 1-1 Interoperability Specification Construct Roadmap
The following table lists and describes the HITSP constructs that are used by the Interoperability Specification. All references to HITSP specifications are to the current, and Panel approved Released for Implementation versions of the specifications retrieved from www.hitsp.org.
Where HITSP has adopted HL7 V3.0 CDA/CCD for conveying information between Electronic Health Record (EHR) and Personal Health Record (PHR) applications and in other healthcare scenarios, it has consolidated common constraints applied against the Content Modules in HITSP/C83CDA Content Modules.Likewise,HITSP/C80 Clinical Document and Message Terminology maintains commonly applied terminology constraints. Readers should refer to HITSP/TN901 Technical Note for Clinical Documents to better understand how HITSP/C83 and HITSP/C80 are used by other constructs that are based upon HL7 V3.0 CDA/CCD (e.g., HITSP/C32Summary Documents Using HL7 Continuity of Care Document (CCD), HITSP/C48Encounter Document Using IHE Medical Summary (XDS-MS) and HITSP/C84 Consult and History & Physical Note Document).
Table 1-1 List of Constructs
|
Construct |
Description |
|
HITSP/ C19 - Entity Identity Assertion |
The Entity Identity Assertion Component provides the mechanisms to ensure that an entity is the person or application that claims the identity provided. An example of this Component is the validation and assertion of a consumer logging on to a Personal Health Record (PHR) system |
|
HITSP/ C26 - Nonrepudiation of Origin |
The Nonrepudiation of Origin Component provides the mechanisms to support Nonrepudiation of Origin, which refers to both the proof of the integrity and origin of documents in a high-assurance manner, which can be verified by any party. This Component does not provide Nonrepudiation of Receipt |
|
HITSP/ C32 - Summary Documents Using HL7 Continuity of Care Document (CCD) |
The Summary Documents Using HL7 Continuity of Care Document (CCD) Component describes the document content summarizing a consumer's medical status for the purpose of information exchange. The content may include administrative (e.g., registration, demographics, insurance, etc.) and clinical (problem list, medication list, allergies, test results, etc) information. This Component defines content in order to promote interoperability between participating systems such as Personal Health Record Systems (PHRs), Electronic Health Record Systems (EHRs), Practice Management Applications and others |
|
HITSP/ C35 - Lab Result Terminology |
The Lab Result Terminology Component defines the vocabulary for either message-based or document-based laboratory results reporting |
|
HITSP/ C37 - Lab Report Document |
The Lab Report Document Component prescribes the use of the standard Clinical Document Architecture Release 2 (CDA R2), as in the HL7 V3 2006 normative edition profiled by IHE LAB TF-3 for: 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) 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 |
|
HITSP/C62 - Unstructured Document |
The Unstructured Document Component is provided for the capture and storage of patient identifiable, unstructured document content, such as text, PDF, and images rendered in PDF. It is based on the Cross-Enterprise Sharing of Scanned Documents (XDS-SD) profile from the Integrating the Healthcare Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) |
|
HITSP/ T15 - Collect and Communicate Security Audit Trail |
The Collect and Communicate Security Audit Trail Transaction is a means to provide assurance that security policies are being followed or enforced and that risks are being mitigated. This document describes the mechanisms to define and identify security relevant events and the data to be collected and communicated as determined by policy, regulation or risk analysis. It also provides the mechanism to determine the record format to support analytical reports that are needed |
|
HITSP/ T16 - Consistent Time |
The Consistent Time Transaction provides a mechanism to ensure that all of the entities that are communicating within the network have synchronized system clocks |
|
HITSP/ T17 - Secured Communication Channel |
The Secured Communication Channel Transaction provides the mechanisms to ensure the authenticity, integrity, and confidentiality of transmissions, and the mutual trust between communicating parties. Its objectives include providing: mutual node authentication to assure each node of the others identity; transmission integrity to guard against improper information modification or destruction while in transit; and transmission confidentiality to ensure that information in transit is not disclosed to unauthorized individuals, entities, or processes |
|
HITSP/ T23 - Patient Demographics Query |
The Patient Demographics Query Transaction is intended to provide a list patients and their demographics query/patient(s) and their demographics identified response message pair (QBP^Q22, RSP^K22) for use wherever such needs exist. This Transaction document extracts the Health Level Seven (HL7) version 2.5 Query and Response data mapping. The underlying basis for this extraction can be found in the Integrating the Healthcare Enterprise IT Infrastructure Technical Framework, Patient Demographics Query integration profile |
|
HITSP/ T81 - Retrieval of Medical Knowledge |
The Retrieval of Medical Knowledge Transaction enables the request and receipt of additional knowledge about a medical concept based on specific context parameters. This transaction does not prescribe the knowledge content of the message returned but provides the specifications for the query for and receipt of additional knowledge. It uses the Health Level 7 (HL7) Context-Aware Information Retrieval (Infobutton) Specification: URL Implementation Guide as the base standard for implementation |
|
HITSP/ TP13 - Manage Sharing of Documents |
The Manage Sharing of Documents Transaction Package supports the sharing of patient records in the form of source attested objects called documents. A healthcare document is a composite of structured and coded health information, both narrative and tabular, that describes acts, observations and services for the purpose of exchange. No assumption is made by this construct in terms of the format and structure of the content of documents shared |
|
HITSP/TP20 - Access Control |
The Access Control Transaction Package provides the mechanism for security authorizations which control the enforcement of security policies including: role-based access control; entity based access control; context based access control; and the execution of consent directives. An example of this is a functional role that has the permission to perform an act (e.g., consumer updating a Personal Health Record (PHR). In an emergency, this construct must support the capability to alter access privileges to the appropriate level (failsafe/emergency access), which may include override of non-emergency consents |
|
HITSP/TP22 - Patient ID Cross-Referencing |
The Patient ID Cross-Referencing Transaction Package is used for identifying and cross-referencing different attributes for the same patient. It contains a query for cross-reference and patient identity feed transactions. These transactions are used to identify patients from a list of potentials, and/or to communicate patient demographic data |
|
HITSP/TP30 - Manage Consent Directives |
The Manage Consent Directives Transaction Package describes the messages needed to capture, manage, and communicate rights granted or withheld by a consumer to one or more identified entities in a defined role to access, collect, use or disclose individually identifiable health information (IIHI), and also supports the delegation of the patients right to consent. The transactions described in this construct are intended to be carried out by HITSP/TP13 - Manage Sharing of Documents |
COPYRIGHT NOTICE
2007 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.
This section provides a list of key reference documents and background material. If you are already familiar with this information, proceed to Section 2.0.
A list of key reference documents and background material is provided in the table below. These documents can be retrieved from www.hitsp.org.
Table 1-2 Reference Documents
|
Reference Document |
Document Description |
|
HITSP Acronyms List |
Lists and defines the acronyms used in this document |
|
HITSP Conventions List |
Describes the conventions that are used to convey the full descriptions and usage of standards in the HITSP specifications |
|
HITSP Glossary |
Provides definitions for relevant terms used by HITSP documents |
|
HITSP Harmonization Framework |
Describes the current framework within which the Interoperability Specifications are built |
|
HITSP Interoperability Specification Overview |
Provides background information about the HITSP and its role in the overall U.S. efforts to realize large scale interoperability of health information. The document also provides a description of the HITSP process for healthcare standards harmonization and explains how to use the Interoperability Specifications and other related documents to inform your health IT system development or refinement |
|
The Consumer Empowerment Use Case (Registration and Medication History), March 19, 2006 and the Consumer Access to Clinical Information Detailed Use Case, June 18, 2007, the Harmonized Use Case |
AHIC Use Case that is the basis of this HITSP Interoperability Specification |
|
TN900 - Security and Privacy Technical Note |
Developed as a reference document to provide the overall context for use of the HITSP Security and Privacy constructs. It includes the following: The scope, reference policy background, and Security and Privacy principles used in the development of the constructs A detailed description and schematics of the conceptual relationship between the Security and Privacy constructs A mapping of existing standards and constructs to be used in meeting the stated requirements of the AHIC Use Cases A list of identified gaps and the recommended approaches to resolving those gaps A roadmap for how the Security and Privacy constructs will evolve and eventually align with other HITSP Interoperability Specifications A conceptual framework for Security and Privacy management, including reference information on privacy policies, risk assessment, and risk management A description of the application of the Security and Privacy constructs to the HITSP Interoperability Specifications for the three initial AHIC Use Cases Biosurveillance, Electronic Health Records - Laboratory Results Reporting, and Consumer Empowerment HITSP will periodically update this Technical Note as required by the introduction of new contexts for use. |
|
Return to detail page at www.hitsp.org | HITSP/IS03 |
| Prev TOC Next |