Opportunities for Engaging Long-Term and Post-Acute Care Providers in Health Information Exchange Activities: Exchanging Interoperable Patient Assessment Information. Overview

12/01/2011

The leveraging of federally required assessment instruments for data reuse requires the implementation of specified standards. This appendix outlines the current standards landscape to describe the standards that are currently in use, available and applicable to the LTPAC sector. Appendix G identifies a roadmap for leveraging the reuse of content from the assessment instruments, specifies tools to support implementation, and makes recommendations for advancing and accelerating adoption of health IT standards.

 

HL7 Clinical Document Architecture (CDA)

Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2, or CDA R2, is a document markup standard that specifies the structure and semantics of clinical documents for the purpose of electronic health information exchange. CDA has been an ANSI standard since 2000.

CDA documents are encoded in Extensible Markup Language (XML). The CDA model is derived from HL7's central Reference Information Model (RIM), thereby enabling data reusability. CDA is similar in format to traditional clinical documents with a header setting the context of the document type (e.g., "History and Physical") and containing administrative data such as the patient's name, the providers involved in the patient's care, the date of creation. The body of the document typically holds clinical information such as problems, medications and allergies. This body can be highly structured with computer parsable information or can be unstructured information for human reading only. This flexibility provides a mechanism for incremental semantic interoperability, providing a gentle on-ramp to information exchange. The CDA standard by itself it does not define sections -- rather it defines the standard (architecture) to be used to define CDA Sections. CDA Implementation Guides describe how to assemble CDA sections in order to satisfy a specific use case (e.g., discharge summary, operation note, referral, etc.).

Consolidated CDA:

The Consolidated CDA sought to eliminate confusion, conflicts, and redundancy by balloting and publishing new single definitions for each of 58 existing CDA sections. From here on out, HL7 will maintain a list of CDA sections in a single publication.

Green CDA:

The CDA is a complex standard and HL7 is working on ways to simplify it -- simplifying the CDA is known as the Green CDA Project. The project was launched to developed methodology for creating simplified schemas that can be transformed directly to or from normative CDA.1 It is a lighter version of the CDA standard that just includes the data and metadata.2

 

Relevant CDA Implementation Guides

The following CDA Implementation guides are most relevant to the LTPAC setting.

HL7 Continuity of Care Document (CCD)

The purpose of the Continuity of Care Document (CCD) is to describe constraints on the CDA R2 specification based on the requirements defined in the American Society for Testing and Materials (ASTM) E2369-05 Standard Specification for Continuity of Care Record (CCR). The CCD lets data exchangers choose from among 17 standard CDA sections. The combination of sections one chooses to use depends on the business case -- essentially, the sender's intent. The 17 Sections available for use in CCD are a subset of the total number of CDA Sections which have so far been defined.

The CCR is a core dataset of the most relevant administrative, demographic, and clinical information facts about a patient's health care covering one or more health care encounters. It provides a means for one health care practitioner, system, or setting to aggregate patient data and forward it to another practitioner, system, or setting to support continuity of care. The primary use case for the CCR is to provide a snapshot of the pertinent clinical, demographic, and administrative data for a specific patient.

The resulting specification, the CCD, is developed as a collaborative effort between ASTM and HL7.3

CCD was the first CDA implementation guide (IG) to define templates for representation of data elements and important concepts in the health care arena. Many IGs and conformance profiles in HL7 as well as in other standards organizations have reused CCD templates by further constraining them for specific business use cases.

HITSP/C32

The Healthcare Information Technology Standards Panel (HITSP)4 developed a specification (component) for summary documents using CCD. This component defines the minimum critical or pertinent patient summary information to communicate between healthcare providers in the United States.

HITSP/C32 is a brief document that selects HITSP CDA templates for use in summary documents in the United States. These selected templates are defined in the HITSP/C83 CDA Content Modules document that houses all of HITSP-constrained CDA templates. The clinical terminology referenced by C32 and other HITSP components is contained in the HITSP Clinical Document and Message Terminology component called C80. The U.S. Office of the National Coordinator for Health Information Technology (ONC) has adopted the HITSP C32 Summary Document as one of the standards for summary documents for Meaningful Use of certified EHR technology. The HITSP/C83 CDA templates used in C32 are used in many standardized HL7, HITSP, and IHE clinical document conformance profiles. For these reasons, we expect CDA use to increase significantly in the next five years.

Work has been undertaken to represent patient assessment summary documents (as well as other document types) in the HITSP C32/CCD. As described elsewhere in this report (Appendix X), issues have been identified in using this specification to represent and for the interoperable exchange of these document types. The S&I Framework Transition of Care Initiative is expected to undertake work to address these issues.

HL7 Questionnaire Assessments and CDA Representation of the MDS

The HL7 CDA Implementation Guide (IG) specifies a standard for electronic submission of CDA questionnaire assessments that allows health care facilities to communicate case reports in an interoperable, industry-standard format.

Section 1 of the IG describes constraints on CDA R2 that provide a framework for patient questionnaire assessments that can be used internationally. The questionnaire assessments contain multiple questions with specific answers and may include scales to quantify the responses. The questions typically assess a variety of clinical domains, including the patient's functional and disability status. Frequently, these types of assessments are used in LTPAC settings and other settings that specialize in chronic physical and mental health conditions.

Section 2 of the IG further pinpoints and applies the CDA constraints identified in Section 1 to meet the requirements for a specific example in the US Realm -- the MDSv3 (v1.00.1), describing how to communicate an MDSv3 as a conformant CDA document.5

HL7 Quality Reporting Document Architecture (QRDA)

The HL7 Quality Reporting Document Architecture (QRDA) is an XML document format that defines constraints on CDA R2 Header and Body elements for quality reporting. It provides a standard structure with which to report endorsed quality measure data to organizations that will analyze and interpret it.

Whereas the PQRI XML format called out in the Meaningful Use Final Rule provides a means of communicating aggregate numerator and denominator data, the QRDA Draft Standard for Trial Use (DSTU) focuses on an individual patient-level quality report. Each report contains quality data for one patient for one or more quality measures, where the data elements in the report are defined by the measure(s) being reported on. A QRDA report contains raw applicable patient data. When this data is pooled and analyzed, each report contributes the quality data necessary to calculate population metrics.6

HL7 Personal Healthcare Monitoring Report (PHMR)

The HL7 Personal Healthcare Monitoring Report (PHMR) is an XML document format that defines constraints on the CDA Header and Body elements for PHMR documents. The information may have multiple characteristics such as representation of measurements captured by devices, representation of narrative information that may be added by caregivers or by the patient's who use the devices in their homes. Representation of graphs may be added by intermediary devices that represent trends in home care patient's health.

This CDA conformance profile is relevant to the LTPAC industry because it allows for standardized collection of critical information in the home environment for communication to all health care providers, regardless of their EHR systems.

HL7 Hospital Discharge Summary CDA Implementation Guide

The HL7 Discharge Summary CDA IG describes constraints on the Clinical Document Architecture (CDA) header and body elements for hospital discharge summary documents. This hospital discharge summary IG is designed to capture a synopsis of a patient's admission to a hospital and provides pertinent information for the continuation of care following discharge. The hospital discharge summary is a required document often dictated by a physician and transcribed. This implementation guide provides a standardized structure for exchange. This specification is not the same as a Continuity of Care Document (CCD). Though not designed for the needs of a discharge summary from an LTPAC setting the LTPAC setting could be a recipient of a hospital discharge summary CDA and thus could make use of the pertinent information.7

HL7 Health Quality Measures Format (HQMF)

The Health Quality Measures Format (HQMF) is a standard for representing a health-quality measure as an electronic document. A quality measure is a quantitative tool that measures an action, process, or outcome of clinical care to indicate an individual's or organization's performance in relation to a specified process or outcome.

The HQMF allows for consistency and unambiguous interpretation of quality measures by standardizing a measure's structure, metadata, definitions, and logic. A health quality measure encoded in the HQMF format is known as an "eMeasure".

Standardization of document structure (e.g., sections), metadata (e.g., author, verifier), and definitions (e.g., "numerator", "initial patient population") achieves a minimal level of consistency and readability across measures in a variety of formats, even if not fully machine-processable. Based on this standardization, formal representation of the clinical, financial, and/or administrative concepts and logic within an eMeasure supports unambiguous interpretation and consistent reporting.8 The Center for Medicare and Medicaid Services' (CMS) final rule states that CMS required quality measures will be available in an electronic format. Though not specifically stated in their final rule, this electronic format is the HQMF eMeasure format.9

 

View full report

Preview
Download

"StratEng.pdf" (pdf, 1.74Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-A.pdf" (pdf, 198.14Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-B.pdf" (pdf, 534.93Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-C.pdf" (pdf, 214.97Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-D.pdf" (pdf, 4.65Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-D1.pdf" (pdf, 12.32Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-D2a.pdf" (pdf, 3.62Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-D2b.pdf" (pdf, 3.58Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-E.pdf" (pdf, 3.66Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-F.pdf" (pdf, 162.5Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-G.pdf" (pdf, 340.24Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-H.pdf" (pdf, 173.91Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-I.pdf" (pdf, 194.52Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-J.pdf" (pdf, 311.03Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-K.pdf" (pdf, 4Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-L.pdf" (pdf, 2.33Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"StratEng-M.pdf" (pdf, 164.3Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®