Health Level Seven
EHR Technical Committee –
EHR Interoperability Project Team
ONC/AHIC/HITSP Use Case Alignment w/HL7 EHR/PHR Models
Chapter 6
Quality Detail Use Case
Working Draft (v2.0), 2 October 2008
For EHR TC Internal Review and Comment
TABLE OF CONTENTS
SECTIONS PAGE
Introduction……………………………………………………………………….3
Section 1. Purpose………………………………………………………………..5
Section 2. Objectives……………………………………………………………..5
Section 3. Methodology………………………………………………………….6
Section 4. Title Use Case Narrative………………………………………………7
Section 5. EHR/PHR System Functionality………………………………………8
Section 6. EHR Record Persistence and Lifecycle………………………………38
Section 7. EHR Record Interoperability…………………………………………49
Section 8. Discoveries and Comments…………………………………………..53
APPENDICES
Appendix A
Section A.1. Terms and Acronyms
Section A.2. 2006-07 ONC/AHIC/HITSP Use Cases
Appendix B
HITSP Interoperability Specification:
HITSP Consumer Empowerment Interoperability Specification/HITSP/IS03 Version 2.0
Appendix C
Office of the National Coordinator for Health Information Technology (ONC)
Harmonized Use Case for Consumer Empowerment (Registration and Medication History)
ONC/AHIC/HITSP Use Case Alignment w/HL7 EHR/PHR Models
Chapter 6 – Quality Detailed Use Case, DRAFT v2.0
Health Level Seven Electronic Health Record Technical Committee
EHR Interoperability Project Team
21 March 2008
Introduction
Since the outset of standards harmonization activities within ANSI HITSP, use cases – developed by ONC and AHIC – have driven the process (reference http://www.hhs.gov/healthit/usecases/). Use cases describe health(care) business and clinical scenarios.
This alignment draft follows a process of discovery, to document applicability of HL7 Electronic Health Record (EHR) and Personal Health Record (PHR) Models with the formalized ONC/AHIC/HITSP use cases, and to identify relevant gaps.
The use cases are organized as a four level hierarchy:
Use Case; which has one or more
Scenario(s); which have one or more
Event(s); which have one or more
Action(s).
Actions are the elemental tasks of each Use Case: Actions = discrete tasks. Actions are supported by specific EHR system functions, typically invoked as the Action is performed/provided. Also, most provider-related Actions require persistent evidence of their occurrence (in the form of a persistent Action Record).
To inform ongoing development work of the EHR TC, the analysis started with a single ONC/AHIC/HITSP Use Case. The resulting alignment draft confirms applicability, detailed to the Use Case Action level, as follows:
HL7EHR/PHR Model / Alignment Analysis intends to…
EHR/PHR System Functional Models
(system functions) / · Specify functions required (or likely to be invoked) by each Use Case Action
· Optionally, specify related conformance criteria
· Identify gaps (i.e., missing functions or criteria)
EHR Interoperability Model
(record interoperability characteristics) / · Show Action documented by Action Record
· Show Action Record in context of Common EHR Record Unit (CRU)
· Show how Action Records (as CRUs) are interoperable
· Show how Action Records (as CRUs) might be implemented (ref. CDAr2 Profile)
· Show how Action Record is ascribed as to Who, What, When, Where
· Show how Action Record is consistent with legal record requirements (ref. Legal Profile)
· Show how trust aspects of Action Record are assured – access control, authentication, audit, traceability
· Show how Action Records are originated, amended and versioned (also ref. CDAr2 Profile)
· Identify gaps (i.e., missing interoperability characteristics or criteria)
EHR Lifecycle
Model
(record lifecycle events) / · Show Action consistency with Action Record lifecycle events
· Identify gaps (i.e., missing lifecycle events)
Section 1. Purpose
This document describes results of the alignment analysis of ONC/AHIC/HITSP Use Cases vis-à-vis the HL7 EHR/PHR Models, including both coverage and gaps. The analyses together encompass EHR/PHR system functionality and EHR record interoperability and EHR record lifecycle. The four HL7 Models include:
.1 HL7 Electronic Health Record System Functional Model (EHRS/FM): Normative, ANSI approved, submitted as ISO TC215/WG8 Work Item, February 2007
.2 HL7 Personal Health Record System Functional Model (PHRS/FM): Public Comment Draft, August 2007
.3 HL7 EHR Interoperability Model (EHR/IM): Draft Standard for Trial Use, February 2007
.4 HL7 EHR Lifecycle Model (EHR/LM): Current Working Draft
This is Chapter 6, focusing on analysis of the Quality Detailed Use Case. Subsequent Chapters will describe analyses of the remaining Use Cases.
Section 2. Objectives
Following are the objectives of this alignment analysis:
.1 To analyze specifications of ONC/AHIC (use cases) and ANSI HITSP (Interoperability Specifications) to discover how they align with HL7 EHR/PHR Models.
.2 For the EHRS/FM, to show which EHR system functions (functional characteristics) are invoked by each Use Case Action.
.3 For the PHRS/FM, to show which PHR system functions (functional characteristics) are invoked by each Use Case Action. [Not applicable to this Use Case.]
.4 For the EHR/IM, to show which EHR interoperability characteristics are required to fulfill (or persistently evidence) each Use Case Action.
.5 For the EHR/LM, to show which EHR lifecycle events, as specified in the EHR/LM, are invoked to fulfill each Use Case Action.
.6 To first inform continuing work of the HL7 EHR Technical Committee.
.7 To also inform development of HITSP Interoperability Specifications and CCHIT certification criteria.
Section 3. Methodology
Following is the proposed alignment analysis methodology.
.1 Review Use Case narrative, Scenarios, Events and Actions.
.2a Complete Section 5, EHRS/FM column, specifying for each Use Case Action which EHR system function(s) it likely invokes.
.2b Specify for each Use Case Action, any EHR system function(s) that are required but absent from the current EHRS/FM.
.3a Complete Section 5, PHRS/FM column, specifying for each Use Case Action which PHR system function(s) it likely invokes.
.3b Specify for each Use Case Action, any PHR system function(s) that are required but absent from the current PHRS/FM draft.
.4a Many provider Actions are accountable from a clinical and medical/legal perspective and require a persistent Action Record. Determine which Use Case Actions require the origination of an Action Record, as persistent evidence of Action occurrence.
.4b For purposes of the persistent EHR, an Action is often logically combined with other closely corresponding Actions. (An Action may be comprised of one or more other Actions, thus an Action Record instance may document one or more Actions.) Determine which Actions may be logically combined in a single Action Record.
.4c Determine, as applicable, Actions which invoke Act Record Lifecycle Events (per the EHR Lifecycle Model).
.4d Complete Section 6, EHR Record Persistence and Lifecycle, specifying each Use Case Action as per Steps 4a-4c.
.5 Complete Section 7, specifying which EHR Interoperability characteristics (per Act/Action Record, Section 3 of the EHR Interoperability Model) are pertinent to evidence Action occurrence – in the form of a persistent Action Record.
Section 4. Title Use Case Narrative
The overall purpose of this Use Case is to provide recommendations on how health information technology (HIT) can: 1) provide the data needed for the development of quality measures, 2) automate the measurement, feedback and reporting of a comprehensive and future set of quality measures, 3) accelerate the use of clinical decision support (CDS) to improve performance on these quality measures, and 4) how performance measures should align with the capabilities and limitations for HIT. The Use Case is broken down into two main perspectives related to quality measurement, feedback, and reporting with respect to the patient encounter: hospital and clinician. There is the presumption that the settings have implemented an EHR and models the exchange of information between the EHR and the quality measurement, feedback, and reporting systems. However, it does allow for some claims data and or manual data collection on certain measures that are not supported through EHRs.
AHIC acknowledges various issues and obstacles in achieving the intent of the Use Case, and is based on the premise that these issues and obstacles will be addressed through HIT standardization and harmonization activities, policy development, and other related initiatives. Among the issues and obstacles noted are the lack of standardized quality measures, the lack of standardized EHR functionality for quality measurement purposes, and issues related to data ownership, sharing, and responsibility. Confidentiality, privacy, and security also remain issues to be dealt with in the implementation of this Use Case.
There are two scenarios in this Use Case, the first one dealing with hospital-based care. This scenario is broken into three alternate scenarios: hospital-based care, information exchange, and multi-hospital measurement and reporting. The activities cover the documentation, collection, transmission and feedback of patient information relevant to the calculation of an established quality measure, when care is provided to a patient. The events and actions relate to the measurement, feedback and reporting of quality information related to hospital performance, and may include care provided I hospital-based outpatient departments, emergency departments, and hospital-based clinics.
The second scenario deals with physician performance and covers the documentation, collection and transmission of patient information relevant to the calculation of an established quality measure for clinician quality – where a specific clinician can be identified as responsible for ensuring adherence to best practices. The scenario is broken into three alternate scenarios: clinician quality information collection and reporting; information exchange; and multi-entity measurement and reporting. The settings for this scenario can be for both inpatient and outpatient, including but not limited to physician offices, emergency departments, or surgical settings.
HL7 EHR Technical Committee – EHR Interoperability Project Team Page 1 of 53
ONC/AHIC/HITSP Use Case Alignment w/HL7 EHR/PHR Models – DRAFT Chapter 6 – Quality Detailed Use Case v.1
Section 5. EHR/PHR System Functionality
[See Methodology, Steps 2a-2b above.] The following specifies EHR/PHR system functions invoked by Actions of the Quality Detailed Use Case. Both coverage (existing EHRS/FM and PHRS/FM functions) and gaps (missing functions) are identified. Please note the following keywords are used in the Functional Model conformance criteria to convey how the use case actions are met by the conformance requirements.
• SHALL – to indicate a mandatory requirement to be followed (implemented) in order to conform. Synonymous with ‘is required to’.
• SHALL NOT – to indicate a prohibited action. Synonymous with ‘prohibited’.
• SHOULD - to indicate an optional recommended action, one that is particularly suitable, without mentioning or excluding others. Synonymous with ‘is permitted and recommended’.
• MAY - to indicate an optional, permissible action. Synonymous with ‘is permitted’.
Use Case Ref / Quality DetailedUse Case Event/Action / EHRS/FM / PHRS/FM /
Hospital-based Care Quality Information Collection and Reporting Scenario
6.1.1 / Event: Receive listing of defined measures & abstraction guidelines
6.1.1.1 / Action: Hospitals receive the listing of quality measures and detailed measure specifications for how a quality measure will be calculated. / S.3.7.4 Public Health Related Updates. Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines. Information and reporting requirements from outside groups, such as public health organizations, may be made available to patient care providers. Examples may include requirements to report on new disease types, or changes to reporting guidelines. The information in these public health updates may be applied to the system so that appropriate data can be collected and reported to comply with requirements. / No match in FM
6.1.1.2 / Action: Hospitals identify applicable measures and incorporate into EHR where possible. / S.2.1.2 Performance and Accountability Measures. Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable. CC#2 - The system SHOULD provide the ability to define multiple data sets required for performance and accountability measures. / No match in FM
6.1.2 / Event: Perform and document patient care
6.1.2.1 / Action: Clinical personnel treat the patient’s injuries or illness. The patient is assessed and observations are documented; appropriate diagnostics and treatments are ordered and completed. Clinical information is entered into the patient’s EHR. / DC 1.2 Manage Patient History. DC.1.6 Care Plans, Treatment Plans, Guidelines, and Protocols. DC.1.7 Orders and Referrals Management. DC.1.8 Documentation of Care, Measurements and Results / PH.2.5 Manage Historical and Current State Data
PH.3.1 Manage Personal Clinical Measurements and Observations
PH.3.2 Manage Account Holder Implemented Care Plans
PH.3.3 Manage Provider Implemented Care Plans
PH.3.4 Manage Medications
6.1.3 / Event: Filter EHR data for information matching inclusion/exclusion factors
6.1.3.1 / Action: Based on the defined measure specifications and associated technical specifications incorporated into the EHR workflow, the patients relevant for each “denominator” (a case relevant to include for a particular quality measure) are identified using information available. If the information is present, the patient is identified as eligible for the measure, based on inclusion criteria. / DC.2.2.2 Support Consistent Healthcare Management of Patient Groups or Populations. Provide the ability to identify and consistently manage healthcare, over time and across populations or groups of patients, that share diagnoses, problems, functional limitations, treatment, medications, and demographic characteristics that may impact care, e.g. population management, disease management, wellness management or care management. CC#3 - The system SHOULD provide the ability to include or exclude a patient from an existing healthcare management protocol group. / IN.1.7 Patient Record Locator and Directory Services. CC#8 - PHR-S MAY provide the ability to use patient record locator services or directories to retrieve links to relevant healthcare information regarding a patient. CC#9 - The PHR-S MAY provide the ability to use patient record locator services and directories to supply links to relevant healthcare information regarding a patient.
6.1.3.2 / Action: Based on documentation entered by the clinician, the data are filtered by exclusion criteria for each case identified as eligible for a quality measure. / DC.2.2.2, CC#3 See 6.1.3.1 above. / No match in FM
6.1.4 / Event: Discharge patient
6.1.4.1 / Action: Once treatment is complete, the patient is discharged. Additional data may be extracted from the patient record to inform the quality measure. / S.2.1.2 Performance and Accountability Measures. Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable. CC#1 - The system SHOULD provide the ability to export or retrieve data required to assess health care quality, performance and accountability. / IN.1.4 Extraction of Health Record Information. Provide data extraction capabilities, including data aggregation, in accordance with data exchange, analysis, reporting and printing requirements as authorized by the account holder. CC#11 - The PHR-S SHOULD provide the ability to extract data for quality analysis purposes as authorized by the account holder.