| HOME | ABOUT | MEMBERSHIP | NEWS & ANNOUNCEMENTS | MEETINGS | FAQ | CONTACT US | | Powered by American National Standards Institute |
![]() |
Return to detail page at www.hitsp.org | HITSP/IS77 |
| Prev TOC Next |
As an introduction to the Healthcare Information Technology Standards Panel (HITSP) Remote Monitoring 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 reference documents and background material.
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 Remote Monitoring Interoperability Specification addresses the data and information exchange requirements for the transfer of remote monitoring information from a device physically attached to or used by a patient in a location that is remote to the clinician.
The data to be transferred is directly related to the type of device that is sourcing the information. The data requirements will include both discrete measurements (e.g., physiological, diagnostic, medication tracking, and activities of daily living (ADL) measurements) as well as more descriptive information regarding the characteristics of the device itself, conditions regarding the monitoring activity, and/or commentary provided by the patient, a family care giver or a professional care coordinator. The objective of the information exchange is to provide a necessary and sufficient level of information to the clinician that has ordered this health monitoring activity to permit this individual to continue in the management of this patients care from a remote location.
The information exchange requirements described in this specification document allow for the maximum segmentation of exchange steps to facilitate the maximum number of implementation variants. The main business actor systems specified as part of this exchange are: the monitoring device, a device intermediary system, a remote monitoring management system, and an EHR system, Although not specifically highlighted in the Use Case, this specification has also covered the implementation variants using a patient PHR system and/or a health information exchange resource as part of the exchange path. The overall remote monitoring information exchange is divided into a sequence of system exchanges between the business actor systems depending on the implementation variant. For example, implementations might be comprised of:
Variant 1. A transfer from the device to a device intermediary system (herein referred to as system data exchange #1), a transfer from a device intermediary to a remote monitoring management system (herein, system data exchange #2), and a transfer from the remote monitoring management system to the EHR (herein, system data exchange #4)
Variant 2. A transfer from the device to a device intermediary system (herein referred to as system data exchange #1), a transfer from a device intermediary to a remote monitoring management system (herein, system data exchange #2), a transfer from a remote monitoring management system to an HIE repository (herein, system data exchange #3), and a transfer from the HIE to the EHR (herein, system data exchange #5).
Per the Use Case, the transfer of the data from the device to the device intermediary has been indicated as out-of-scope at this time but may be re-visited at some time in the future. Despite this out-of-scope designation however, this Table recognizes the device as the originating source of the data and therefore has given full consideration to the IEEE industry specifications for this data at the device and to the harmonization of these data specifications with other related data terminology standards initiatives targeting its use in EHRs and PHRs.
In addition to the transfer of the remote monitoring information itself, this Table also describes the pertinent administrative and finance transactions that need to be supported by the clinicians EHR system to satisfy the eligibility and authorization of the desired remote monitoring activities with a patients health plan.
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 depicted 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 Document Map
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.
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/C74 - Remote Monitoring Observation Document |
The Remote Monitoring Observation Document Component describes the document content to convey medical information collected by remote monitoring management systems from monitoring devices and/or device intermediaries for the purpose of information exchange. The content may include administrative (e.g., registration, demographics, insurance, etc.) and clinical (results, vital signs, etc) information. This specification defines content in order to promote interoperability between participating systems. Such systems may include Remote Monitoring Management Systems, Personal Health Record Systems (PHRs), Electronic Health Record Systems (EHRs), Health Information Exchange infrastructure services and other persons and systems as identified and permitted |
|
HITSP/C80 - Clinical Document and Message Terminology |
The Clinical Document and Message Terminology Component defines the vocabularies and terminologies utilized by HITSP specifications for Clinical Documents and Messages used to support the interoperable transmission of information |
|
HITSP/C83 - CDA Content Modules |
The CDA Content Modules Component defines the content modules for document based HITSP constructs utilizing clinical information. These Content modules are based on IHE PCC Technical Framework Volume II, Release 4. That technical framework contains specifications for document sections that are consistent with all Implementation Guides for clinical documents currently selected for HITSP constructs |
|
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/T31 - Document Reliable Interchange |
The Document Reliable Interchange Transaction provides a standards-based mechanism for conveying a set of medical documents in a point-to-point network-based communication. This Transaction uses the IHE Cross-Enterprise Document Reliable Interchange (XDR) Integration Profile, a companion to the IHE Cross-Enterprise Document Sharing (XDS) Integration Profile. Cross-Enterprise Document Reliable Interchange (XDR) uses the XDS defined metadata formats in a simpler environment in which the communicating parties have agreed to a point-to-point interchange rather than communicating via document sharing |
|
HITSP/T40 - Patient Health Plan Eligibility Verification |
The Patient Health Plan Eligibility Verification Transaction is intended to provide the status of a health plan covering the individual, along with details regarding patient liability for deductible, co-pay and co-insurance amounts for a defined base set of generic benefits or services. The base set of benefits includes, but is not limited to, coverage status and patient liability for medical, chiropractic, dental, hospital inpatient, hospital outpatient, emergency, physician office visit, pharmacy and vision services that are included in the patients generic health plan benefit |
|
HITSP/T68 - Patient Health Plan Authorization Request and Response |
The Patient Health Plan Authorization Request and Response Transaction provides a mechanism for a healthcare provider (other than a retail pharmacy) to request approval from a health plan to authorize certain healthcare services, when required by the patients health plan contract. The information exchanged includes, but is not limited to, approval status for coverage, allowed service provider(s), and certification dates for services that are included in the patients health plan benefits. The response from the health plan indicates that the health plan has determined that the particular service(s) will or will not be covered, and what is the level of coverage if that information is available from the health plan |
|
HITSP/T73 - Aggregate Device Information Communication (planned June 2009 as per Section 4.3.1) |
The Aggregate Device Information Communication Transaction allows a system serving as a device intermediary such as a home hub, a cell phone, a set top box, or a monitoring station to which one or more monitoring devices are connected to forward a set of observations through a local or remote connection to a remote monitoring management system where these device captured observations will be reviewed by a person managing the care of the patient under remote monitoring |
|
HITSP/T79 - Pharmacy to Health Plan Authorization Request and Response Transaction |
The Pharmacy to Health Plan Authorization Request and Response Transaction provides a mechanism for a pharmacy to request approval from a health plan to authorize certain healthcare products and services, as required by the patients health plan contract. The health plan responds to the pharmacys request for the approval of products and/or services. The information exchanged includes, but is not limited to, approval status for coverage of the products and/or services that are included in the patients health plan benefits and/or authorization limitations |
|
HITSP/T85 - Administrative Transport to Health Plan |
The Administrative Transport to Health Plan Transaction will be used as the transport for administrative transactions between a provider and a health plan. Examples include a pharmacy obtaining health plan eligibility, and a physician requesting referral or authorization information from a health plan. This construct is based on the CAQH Phase II CORE #270 Connectivity Rule v2.0.0, which addresses the message envelope metadata, the message envelope standards, and the submitter authentication standards for administrative transactions, as well as communications-level errors, and acknowledgements |
|
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 |
|
HITSP/TP46 - Medication Formulary and Benefits Information |
The Medication Formulary and Benefits Information Transaction Package addresses two tasks. The first task is to perform an eligibility check for a specific patients pharmacy benefits. The second task is to obtain the medication formulary and benefit information |
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).
COPYRIGHT NOTICE
2008 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 |
|
Describes the conventions that are used to convey the full descriptions and usage of standards in the HITSP specifications |
|
|
Provides definitions for relevant terms used by HITSP documents |
|
|
Describes the current framework within which the Interoperability Specifications are built |
|
|
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 product development or product refinement. |
|
|
AHIC Use Case that is the basis of this HITSP Interoperability Specification |
|
|
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. |
|
|
Developed as a reference document to provide the overall context for use of the HITSP Care Management and Health Record constructs. It includes the following: The scope, background, and principles for use in the development of the CMHR constructs A detailed description and schematics of the relationship between CMHR constructs A conceptual framework for the construction of clinical documents An overview of Clinical Document concepts An overview of Vocabulary concepts |
![]() |
Return to detail page at www.hitsp.org | HITSP/IS77 |
| Prev TOC Next |