 |
Return to detail page at www.hitsp.org | HITSP/IS04 |
| 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/IS04 |
| Prev TOC Next |
As an introduction to the Healthcare Information Technology Standards Panel Emergency Responder-Electronic Heath Record (ER-EHR) 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 links to key 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.
Pre-hospital care and emergency response lack interoperable information technology and infrastructure and Standard Development Organizations (SDO) consensus standards. From an interoperability perspective, the American Health Information Community (AHIC) Emergency Responder Use Case treats pre-hospital response and care similar to hospital care in spite of heterogeneous pre-hospital organizational structures and overlapping policy jurisdictions which must deal with cross-affinity domain interactions, poor communications, emerging technologies and policies. Additionally, emergency responders must potentially deal with unreliable communications, power and failure prone systems while working under stressful conditions with inadequate resources. HITSP was challenged by wanting to focus on interoperability, achieve closure, be pragmatic and have a futuristic perspective.
The ER-EHR Use Case focuses on the deployment of standardized and secure solutions for accessing and exchanging current and patient-specific historical health information. The historical information typically resides or is available from a Personal Health Record (PHR), Emergency Contact Registry (ECON) and/or Electronic Health Record (EHR). The current data can be generated by a variety of emergency responders, and from third party data sources. The Use Case is driven by the requirements of timely electronic access and exchange of critical health information which should support the assessment, stabilization and treatment of the victims of emergency incidents, as well as, on a treatment non-interference basis, facilitate family member reunification, expedite next-of-kin notification following such incidents, and other related matters (e.g., aggregates of victims in different stages of care, needed transport, etc.). This could range from routine incidents involving individuals suffering from motor vehicle crashes or acute episodes of illness, to large groups of people suffering as the result of mass casualty incidents including natural disasters, pandemics and terrorism.
The ER-EHR Use Case covers the workflow from the time responders become aware that there is an emergency. It covers the perspective of incident commencement and situational awareness (9-1-1, Dispatch or Emergency Communications System) to on-site care providers (Emergency Medical Services (EMS), Law Enforcement, Fire) and emergency care clinicians. Emergency care clinicians involved in the care and treatment of emergency incident victims, medical examiner/fatality managers investigating cause of death, emergency managers, and public health practitioners also use information generated/collected by various responders. This Use Case focuses on interoperability requirements and does not attempt to include all of their functions and interactions, or the data the actors need to perform their particular functions.
The Emergency Responder EHR envisioned by this Use Case is an amalgam of current emergency incident and patient-specific historical health information collected over time from a number of sources. Patient-specific historical health information includes Emergency Contact Registry (ECON) data, Personal Health Record (PHR) data and Electronic Health Record (EHR) data. Current emergency incident information includes all information from the first notification to an Emergency Responder through the completion of the last encounter. This is defined as an Episode of Care. These data are collected from the beginning of the incident, from a number of systems and are assembled into a growing ER-EHR that is used by the actors within the Use Case as the incident proceeds through the scenarios. We have referred to these data throughout the Interoperability Specification as the Episode of Care Record, which is ultimately loaded into the ER-EHR repository. The reader should recognize that Episode-of-Care data includes the pre-hospital Patient Care Report and patient-specific historical data from the Personal Health Record (PHR), Emergency Contact Registry (ECON) and/or Electronic Health Record (EHR). Moreover, the Episode of Care Record is comprised of a number of Encounter Records, including the ED and Definitive Care. The Health Level Seven (HL7) Continuity of Care (CCD) Clinical Summary is used to provide initial clinical information to the emergency responders and is used at each hand off of care to provide clinical information to the Emergency Care Department, Definitive Care, transfer or final disposition of the Episode of Care.
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-1 depicts 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 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 HL7V3 CDA/CCD for conveying information between EHR and PHR applications and in other healthcare scenarios, it has consolidated common constraints applied against the Content Modules in HITSP/C83 CDA 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 CDA/CCD (e.g., HITSP/C32Summary Documents Using HL7 Continuity of Care Document (CCD), HITSP/C48Encounter Document Using IHE Medical Summary (XDS-MS), HITSP/C84 Consult and History & Physical Note).
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/C28 - Emergency Care Summary Document Using IHE Emergency Department Encounter Summary (EDES) |
The Emergency Care Summary Document Using IHE Emergency Department Encounter Summary (EDES) Component is the collection of data from multiple sources (such as physicians, nurses, technologists, etc.) recording the assessments and care delivered by the ED team in response to an ED visit. It is a summary of the patients current health status and care tendered in the ED between arrival and ED departure. This Component specifies the use of the IHE Emergency Department Encounter Summary (EDES), Technical Framework Supplement, Volume I, Revision 3.0, 2007-2008 |
|
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/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/C39 - Encounter Message |
The Encounter Message Component supports the process of sending patient encounter data (excluding laboratory, radiology) from a Biosurveillance Message Sender to a Biosurveillance Message Receiver |
|
HITSP/C47 - Resource Utilization Message |
The Resource Utilization Message Component specifies the message and content necessary to report utilization and status of health provider resources to public health agencies. This specification reflects the current status of harmonization efforts between HL7 and OASIS |
|
HITSP/C48 - Encounter Document Using IHE Medical Summary (XDS-MS) |
The Encounter Document Using IHE Medical Summary (XDS-MS) Component supports the process of sending patient encounter data (excluding laboratory and radiology) in a document sharing functional flow scenario. Patient encounter data are captured as part of the normal process of care performed by healthcare providers, such as hospitals, emergency departments and outpatient clinics |
|
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/C82 - Emergency Common Alerting Protocol |
The Emergency Common Alerting Protocol Component selects the OASIS Common Alerting Protocol (CAP) v1.1 standard, and is used as a multicast notification message sent to an identified channel. The intended recipients are populations such as all emergency departments in XXX county, within a geographic area, etc. |
|
HITSP/C84 - Consult and History & Physical Note |
The Consult and History & Physical Note Component supports two types of commonly used clinical notes, a consult note, and a history and physical note. It is intended for use to support the exchange of information from a consulting provider to a referring provider; and may also be used to provide background information from a referring provider to a consulting provider (e.g., prior reports) |
|
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/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/T63 - Emergency Message Distribution Element |
The Emergency Message Distribution Element Transaction selects the Emergency Data Exchange Language (EDXL) Distribution Element (DE) v1.0 standard, and is a multicast notification message sent to an identified population (assume this is not to the general public, but to specifically identified populations, such as emergency departments) |
|
HITSP/T64 - Identify Communication Recipients |
The Identify Communication Recipients Transaction is intended to serve the purpose of identification of communication recipients and the subsequent purpose of delivery of alerts and bi-directional communications (e.g., public health agencies notifying a specific group of service providers about an event.) The method and criteria by which individuals are added to a directory is a policy decision, which is out of scope for this construct. It uses the Integrating the Healthcare Enterprise (IHE) Personnel White Pages profile which provides access to basic directory information for identifying one or more recipients |
|
HITSP/T66 - Retrieve Value Set |
The Retrieve Value Set Transaction is used to transform human or computer vocabularies. For example, it can be used to convert the initial capture of a human-readable concept into a computer vocabulary captured in a document or message that will be communicated. It may also be used in the reverse, to take computer vocabulary and convert to human-readable form |
|
HITSP/T67 - Clinical Referral Request Transport |
The Clinical Referral Request Transport Transaction will be used to transport the provider to provider (clinical) referral request interaction. It is based on the Integrating the Healthcare Enterprise (IHE) Document-based Referral Request (DRR) profile which is used to bundle a referral request document with other relevant clinical documents of interest and optionally to send a trigger message to the receiving provider system |
|
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/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 |
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 |
|
Emergency Responder Electronic Health Record (ER-EHR) Use Case, December 20, 2006 |
AHIC Use Case that is the basis of this Interoperability Specification |
|
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 |
|
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. |
|
TN901 Technical Note for Clinical Documents |
Developed as a reference document to provide the overall context for use of the HITSP Care Management and Health Records (CMHR) 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/IS04 |
| Prev TOC Next |