Centers for Medicare & Medicaid Services
7500 Security Blvd
Baltimore, MD 21244-1850
Data Submission Specifications Utilizing HL7 QRDA
Implementation Guide Based on HL7 CDA Release 2.0
Version: 4.1
Last Modified: April 25, 2012
1 of 104
4/25/2012
Contributors:
Diane Davis – Business Analyst III, CSC
Kathy Kain – Program Manager, Buccaneer
Shauna Kerby – Associate Program Manager, Buccaneer
Srinivas Velamuri – Application Architect, CSC
Jyothi Mallampalli – Principal Lead Architect, CSC
Llewelyn Brown – Systems Analyst II, CSC
2 of 104
4/25/2012
Date
Changed By
Changes
Version
04/01/09
Kris Duroe
Initial document finalized.
1.0
04/02/09
Kris Duroe
Updates made to the References section.
1.1
“EHR Quick Start Guide” reference was updated to the
following: “HIMSS Electronic Health Record
Association - Continuity of Care Document (CCD)
Quick Start Guide” which also links to a website where
the document can be referenced
(http://www.himssehra.org/docs/ccd_qsg.zip).
07/01/09
Srinivas Velamuri
Updated in line with Implementation guide for QRDA
Release 1 published on April 2009
1.2
07/02/09
Kristin Knudson
Edited to ensure 508 compliance
1.2
07/07/09
Kristin Knudson
Place holder codes for Measures/MeasureSet are
replaced with the codes generated out of the CMS root
OID.
1.2
09/18/09
Kathy Kain
Updates made to document. See Release Notes for
complete details.
1.3
09/23/09
Kathy Kain
Further updates to name elements. See Release
Notes for complete details.
1.3
01/14/10
Kelly Falke
Updates to OID distribution policy, Capturing Vendor
Software details
1.4
07/01/10
Kelly Falke
201+-1 EHR Measure Specifications
2.0
5/27/11
Diane Davis
2012 EHR Measure Specifications
3.0
6/15/11
Diane Davis
Updates for the inclusion of providing an email
address for the NPI/TIN.
3.0
6/29/11
Diane Davis
Updates for the inclusion of the ONC certification
number for providers participating in the
PQRS/HITECH combination.
3.0
7/12/11
Diane Davis
Miscellaneous updates for an error condition.
3.0
7/20/11
Jyothi Mallampalli
Added details for security code, removed plan of care
negation rules and medication equipment negation
rules and example
3.0
7/27/11
Jyothi Mallampalli
Updated the ONC Certification number section
3.0
3 of 104
4/25/2012
11/7/2011
Jyothi Mallampalli
Updated Fig 16 and made ONC certification number
optional for Hitech submission.
3.0
3/7/2012
Llewelyn Brown
Added references to International Classification of
Diseases Tenth Revision, Clinical Modifications (ICD10 (CM)) in sections that previously referred
exclusively to ICD-9. Updated contact information for
LOINC database. Updated references to SNOMED's
trademark ownership from SNOMED International to
IHTSDO. Updated the approximate number of
concepts contained in SNOMED CT. Updated
SNOMED contact information. Updated copyright
information for CPT. Added hyperlink to ICD-10
Implementation Guide. Updated OID for measure set
in Figure 17.
4.0
3/19/2012
Llewelyn Brown
Updated Ethnicity and Race elements, which are no
longer required. Updated name of measure 3 in
Figure 19.
4.0
3/21/2012
Jyothi Mallampalli
Updated Figure 9, Figure 14 and Figure 38. Updated
Conf-QRDA-1-216 to remove the reference to SSN.
4.0
4/25/2012
Llewelyn Brown
Updated record target to specify inclusion of email
address. Updated Payor Section to require HIC
number. Updated reference to figure 16.
4.1
4 of 104
4/25/2012
Table of Contents
DATA SUBMISSION SPECIFICATIONS UTILIZING HL7 QRDA IMPLEMENTATION GUIDE
BASED ON HL7 CDA RELEASE 2.0.................................................................................................... 1
VERSION: 4.0 ............................................................................................................................................... 1
LAST MODIFIED: MARCH 7, 2012 ............................................................................................................. 1
INTRODUCTION......................................................................................................................................... 12
1.1
Purpose ................................................................................................................................ 12
1.2
Conceptual Approach ........................................................................................................... 12
1.2.1
Background .................................................................................................................... 12
1.3
CMS EHR Warehouse Quality Measures ............................................................................ 13
1.4
Standards ............................................................................................................................. 13
1.4.1
Logical Observation Identifier Names and Codes (LOINC®) ........................................ 13
1.4.2
SNOMED Clinical Terms (SNOMED-CT®) ................................................................... 13
1.4.3
Current Procedural Terminology, Fourth Edition (CPT4®) ............................................ 14
1.4.4
The International Classification of Diseases. ................................................................ 15
1.4.5
RxNorm .......................................................................................................................... 15
Definition of a Quality Measure and QRDA’s Role .............................................................. 15
1.5
1.5.1
Types of Quality Measure Reports ................................................................................ 16
1.5.1.1
QRDA Category I – Single Patient Report .............................................................. 16
1.5.1.2
QRDA Category II – Multi-patient-level Report ....................................................... 16
1.5.1.3
QRDA Category III – Calculated Report ................................................................. 16
1.5.2
Approach........................................................................................................................ 17
1.5.3
Use of Templates ........................................................................................................... 17
1.5.3.1
Originator Responsibilities ...................................................................................... 17
1.5.3.2
Recipient Responsibilities ....................................................................................... 17
1.5.4
Conventions Used in This Specification ........................................................................ 17
1.5.4.1
Explanatory Statements .......................................................................................... 18
1.5.4.2
Conformance Requirements ................................................................................... 18
1.5.4.3
Vocabulary Conformance ........................................................................................ 18
1.5.4.4
XPath Notation ........................................................................................................ 19
1.5.4.5
Keywords ................................................................................................................. 19
1.5.4.6
XML Examples ........................................................................................................ 19
1.5.4.7
File Size Limitations ................................................................................................ 20
5 of 104
4/25/2012
1.5.4.8
1.6
Use of Object Identifiers (OIDs) .............................................................................. 20
Road map ............................................................................................................................. 25
1.6.1
OID ................................................................................................................................. 25
1.6.2
Qualified EHR Software Version – Security Code ......................................................... 25
1.7
Key Assumptions .................................................................................................................. 25
1.7.1
Updates to Specification ................................................................................................ 25
1.7.2
Transmission Media Impacts ......................................................................................... 25
2 CMS EHR QRDA (Category I) Report Constraints .............................................................................. 26
2.1
CMS EHR QRDA Report Header Constraints ..................................................................... 26
2.1.1
Header Attributes ........................................................................................................... 26
2.1.1.1
ClinicalDocument/realmCode .................................................................................. 26
2.1.1.2
ClinicalDocument/typeId ......................................................................................... 26
2.1.1.3
ClinicalDocument/templateId .................................................................................. 26
2.1.1.4
ClinicalDocument/id ................................................................................................. 26
2.1.1.5
ClinicalDocument/code............................................................................................ 27
2.1.1.6
ClinicalDocument/title .............................................................................................. 27
2.1.1.7
ClinicalDocument/effectiveTime .............................................................................. 27
2.1.1.8
ClinicalDocument/confidentialityCode ..................................................................... 27
2.1.1.9
ClinicalDocument/setId............................................................................................ 28
2.1.1.10
ClinicalDocument/versionNumber ........................................................................... 28
2.1.2
Header Participants ....................................................................................................... 28
2.1.2.1
recordTarget ............................................................................................................ 28
2.1.2.2
author…. .................................................................................................................. 31
2.1.2.3
informant ................................................................................................................. 32
2.1.2.4
custodian ................................................................................................................. 33
2.1.2.5
legalAuthenticator .................................................................................................... 34
2.1.2.6
participant (Primary Care Provider) ......................................................................... 35
2.1.2.7
documentationOf ..................................................................................................... 36
2.2
CMS EHR QRDA Report Body Constraints ......................................................................... 39
2.3
CMS EHR QRDA Report Section Constraints ..................................................................... 39
2.3.1
Measure Set Section ..................................................................................................... 39
2.3.2
Measure Section ............................................................................................................ 40
2.3.2.1
Representation of the Measure(s) ........................................................................... 42
2.3.3
Reporting Parameters Section ....................................................................................... 42
2.3.4
Patient Data Section ...................................................................................................... 43
6 of 104
4/25/2012
3 Templates used in eHr QRDA Technical Specification ........................................................................ 45
3.1.1
Overview of Templates .................................................................................................. 45
3.1.1.1
Section-level Templates .......................................................................................... 45
3.1.1.2
Clinical Statement Templates ................................................................................. 46
3.1.1.3
Supporting (Entry) Templates ................................................................................. 47
3.1.2
Problems Section ........................................................................................................... 47
3.1.2.1
Section Conformance .............................................................................................. 48
3.1.2.2
Clinical Statement Conformance ............................................................................. 48
3.1.2.2.1
Representation of Problems .......................................................................... 48
3.1.2.2.1.1 Problem Act ....................................................................................................... 48
3.1.2.2.1.2 Problem Observation ......................................................................................... 49
3.1.2.2.2
Representation of “Status” Values ................................................................ 49
3.1.2.2.3
Problem Negation reason template ............................................................... 50
3.1.3
Procedures Section ....................................................................................................... 53
3.1.3.1
Section conformance............................................................................................... 53
3.1.3.2
Clinical statement conformance .............................................................................. 53
3.1.3.2.1
Procedure activity .......................................................................................... 53
3.1.3.2.2
Procedure related products ........................................................................... 54
3.1.4
Payers Section ............................................................................................................... 55
3.1.4.1
Section conformance............................................................................................... 56
3.1.4.2
Clinical statement conformance .............................................................................. 56
3.1.4.2.1
Payer representation ..................................................................................... 56
3.1.4.2.1.1 Coverage activity ............................................................................................... 56
3.1.4.2.1.2 Policy Activity..................................................................................................... 57
3.1.4.2.1.3 Authorization Activity ......................................................................................... 58
3.1.5
Alerts (Allergies, Adverse Reactions) Section ............................................................... 61
3.1.5.1
Section conformance............................................................................................... 61
3.1.5.2
Clinical statement conformance .............................................................................. 61
3.1.5.2.1
Representation of alerts ................................................................................ 61
3.1.5.2.1.1 Problem act ....................................................................................................... 61
3.1.5.2.1.2 Alert Observation ............................................................................................... 61
7 of 104
4/25/2012
3.1.5.2.2
Representation of “Status” Values ................................................................ 62
3.1.5.2.3
Representation of Agent ................................................................................ 62
3.1.5.2.4
Reaction Observations and Interventions ..................................................... 63
3.1.5.2.4.1 Reaction Observation ........................................................................................ 64
3.1.5.2.4.2 Severity Observation ......................................................................................... 64
3.1.5.2.5
3.1.6
Reaction Intervention..................................................................................... 65
Medications Section ....................................................................................................... 67
3.1.6.1
Section conformance............................................................................................... 67
3.1.6.2
Clinical statement conformance .............................................................................. 68
3.1.6.2.1
Medication and supply activities .................................................................... 68
3.1.6.2.1.1 Medication activity ............................................................................................. 68
3.1.6.2.1.2 Supply activity.................................................................................................... 69
3.1.6.2.2
Medication related information ...................................................................... 69
3.1.6.2.2.1 Indications ......................................................................................................... 69
3.1.6.2.2.2 Patient Instructions ............................................................................................ 70
3.1.6.2.2.3 Fulfillment Instructions ....................................................................................... 70
3.1.6.2.2.4 Medication Series Number Observation ........................................................... 70
3.1.6.2.2.5 Reaction Observations and Interventions ......................................................... 71
3.1.6.2.3
Representation of “Status” Values ................................................................ 72
3.1.6.2.4
Representation of a Product .......................................................................... 72
3.1.6.2.5
Medication Negation Reason template ......................................................... 73
3.1.7
Immunizations Section ................................................................................................... 77
3.1.7.1
Section conformance............................................................................................... 77
3.1.7.2
Clinical statement conformance .............................................................................. 77
3.1.8
Results Section .............................................................................................................. 79
3.1.8.1
Section conformance............................................................................................... 80
3.1.8.2
Clinical statement conformance .............................................................................. 80
3.1.8.3
Results representation ............................................................................................ 80
3.1.8.3.1.1 Result organizer ................................................................................................ 80
3.1.8.3.1.2 Result observation ............................................................................................. 81
3.1.8.3.1.3 Result negation reason template....................................................................... 82
3.1.9
Vital Signs Section ......................................................................................................... 85
8 of 104
4/25/2012
3.1.9.1
Section conformance............................................................................................... 85
3.1.9.2
Clinical statement conformance .............................................................................. 85
3.1.10
Structural Design Section .............................................................................................. 87
3.1.11
Advance Directives Section ........................................................................................... 88
3.1.11.1
Section conformance............................................................................................... 88
3.1.11.2
Advance directive observations .............................................................................. 88
3.1.11.3
Representation of “status” values ........................................................................... 89
3.1.11.4
Advance directive references .................................................................................. 89
3.1.12
Plan of Care Section ...................................................................................................... 92
3.1.12.1
Section conformance............................................................................................... 92
3.1.12.2
Clinical statement conformance .............................................................................. 92
3.1.12.3
Plan of care activities .............................................................................................. 92
3.1.13
Social History Section .................................................................................................... 93
3.1.13.1
Section conformance............................................................................................... 93
3.1.13.2
Social history observation ....................................................................................... 93
3.1.13.3
Representation of “status” values ........................................................................... 94
3.1.13.4
Episode observations .............................................................................................. 94
3.1.14
Encounters Section ........................................................................................................ 96
3.1.14.1
Section conformance............................................................................................... 96
3.1.14.2
Encounter activities ................................................................................................. 96
3.1.14.3
Encounter location ................................................................................................... 97
3.1.15
Medical Equipment ........................................................................................................ 98
3.1.15.1
Section conformance............................................................................................... 98
3.1.15.2
Clinical Statement conformance ............................................................................. 99
3.1.15.2.1.1
3.1.15.2.2
3.1.15.3
3.1.16
Supply activity ........................................................................................... 99
Representation of “Status” Values ................................................................ 99
Representation of a Product instance ..................................................................... 99
Family History .............................................................................................................. 100
3.1.16.1
Section conformance............................................................................................. 101
3.1.16.2
Clinical conformance ............................................................................................. 101
3.1.16.2.1
Family history representation ...................................................................... 101
3.1.16.2.1.1
Family history observation ...................................................................... 101
3.1.16.2.1.2
Family history organizer ......................................................................... 101
3.1.16.2.2
Family history participants ........................................................................... 102
9 of 104
4/25/2012
Table of Figures
Figure 1: ClinicalDocument Example ................................................................................................... 20
Figure 2: RealmCode Example ............................................................................................................... 26
Figure 3: ClinicalDocument/TemplateId Example ............................................................................ 26
Figure 4: id Example .............................................................................................................................. 27
Figure 5: effectiveTime Example ........................................................................................................... 27
Figure 6: confidentialityCode Example ................................................................................................. 27
Figure 7: setId Example ......................................................................................................................... 28
Figure 8: versionNumber Example ....................................................................................................... 28
Figure 9: recordTarget Example ........................................................................................................... 31
Figure 10: Author Example ................................................................................................................... 32
Figure 11: Informant Example .............................................................................................................. 33
Figure 12: Custodian Example ............................................................................................................. 34
Figure 13: legalAuthenticator Example ............................................................................................... 35
Figure 14: Participant Example ............................................................................................................ 36
Figure 15: documentationOf Example ................................................................................................. 38
Figure 16: CMS EHR QRDA Report Use of Measure Set Sections .................................................. 39
Figure 17: Measure Set section Example ............................................................................................ 40
Figure 18: Nested Measure Section in Measure Set Example ......................................................... 41
Figure 19: Measure Act Example ......................................................................................................... 42
Figure 20: Reporting parameters Time Example ............................................................................... 43
Figure 21: Generic Section level Template Example ......................................................................... 46
Figure 22: Generic Clinical Statement Template Example ............................................................... 46
Figure 23: Generic Supporting Template Example ............................................................................ 47
Figure 24: Problem Entry Example ...................................................................................................... 51
Figure 25: Problem Entry Negation Example ..................................................................................... 52
Figure 26: Procedure Example .............................................................................................................. 54
Figure 27: Procedure Negation Example ............................................................................................. 55
Figure 28: Payers Example .................................................................................................................... 60
Figure 29: Alerts Example ..................................................................................................................... 66
Figure 30: Medication Example ............................................................................................................ 75
Figure 31: Medication Negation Example ........................................................................................... 76
Figure 32: Immunization Example ....................................................................................................... 78
10 of 104
4/25/2012
Figure 33: Immunization Negation Example ...................................................................................... 79
Figure 34: Results Example .................................................................................................................. 83
Figure 35: Results Negation Example .................................................................................................. 84
Figure 36: Vital Signs Example ............................................................................................................ 86
Figure 37: Vital Signs Negation Example ............................................................................................ 86
Figure 38: Structural Data Example.................................................................................................... 87
Figure 39: Advance Directives Example .............................................................................................. 91
Figure 40: Plan of Care Example .......................................................................................................... 93
Figure 41: Social History Example ....................................................................................................... 95
Figure 42: Encounter Example ............................................................................................................. 98
Figure 43: Medical Equipment Example ........................................................................................... 100
Figure 44: Family History Example.................................................................................................... 103
11 of 104
4/25/2012
1.1
Purpose
This document describes the Electronic Health Record (EHR) data submission required for
reporting information for the Center for Medicare & Medicaid Services (CMS) physicianfocused EHR quality initiatives. The data consists primarily of patient observational data related
to a physician’s practice. From this information, EHR quality measures are computed.
The purpose of this specification is to communicate the data requirements necessary for EHR
vendors to incorporate into their applications. It is intended to serve as the roadmap for software
vendors to use on behalf of physician offices submitting data into the CMS EHR Warehouse.
By leveraging the Health Level Seven (HL7) Quality Reporting Document Architecture (QRDA)
standard, the CMS EHR Warehouse becomes another ancillary system to which health care
systems can submit information in a standard format. In order to transmit data into the CMS
EHR Warehouse, the EHR system must transmit data pursuant to the Health Level Seven (HL7)
QRDA standard.
The Consolidated Health Informatics (CHI) is fostering the adoption of federal health
information interoperability standards for health data segments. For example, vocabulary that
includes specific health data models and communication standards; alignment with Health
Insurance Portability and Accountability Act (HIPAA) administration transaction records and
code sets; and data registry functionality are objectives that CHI hopes to achieve. This
specification requires the use of a standard coding system(s) to identify diagnoses, medical
exclusions, vital signs, drug history, observations, and lab test results. Standard coding systems
such as International Classification of Diseases, Ninth Revision, Clinical Modifications (ICD-9
CM), International Classification of Diseases, Tenth Edition, Clinical Modifications (ICD-10CM), Current Procedural Terminology, Fourth Edition (CPT4), RxNorm, Logical Observation
Identifier Names and Codes (LOINC) and Systematized Nomenclature of Medicine Clinical
Terms (SNOMED CT) will be used for recording patient activities.
1.2
Conceptual Approach
The CMS EHR Warehouse will accept clinical documents originating from EHR systems. Upon
transmission of data to the warehouse, the messages will be validated per the edit requirements
and inserted into the CMS EHR Warehouse. Subsequently, the CMS EHR Warehouse will
evaluate the clinical documents to determine if the measurement criteria have been satisfied for a
given patient. If this occurs, the CMS EHR Warehouse will process the clinical documents and
calculate measurements in accordance with the analytical specifications approved by CMS.
The EHR system must generate clinical documents for each patient according to the
specifications. The physician office transfers the clinical documents to the CMS EHR
Warehouse.
12 of 104
4/25/2012
1.3
CMS EHR Warehouse Quality Measures
This list represents the CMS EHR measures. Additional measures may be adopted as
deemed appropriate. The patient clinical documents will be used to determine if the
patient has met the measurement criteria and the accompanying results. For applicable
measures, refer Appendix_AJ-Custom_Template_IDs tab of the Downloadable Resources table.
1.4
Standards
The use of standards, both clinical and systems integration is a prerequisite for data submission
to the CMS EHR Warehouse. This Specification will adopt future standards as they evolve and
are approved by CMS.
HL7 encoding makes extensive use of the code set, Logical Observation Identifier Names and
Codes (LOINC). LOINC codes are available for commercial use without charge, subject to the
terms of a license that assures the integrity and ownership of the codes. The LOINC database
provides sets of universal names and ID codes for identifying laboratory and clinical
observations and other units of information meaningful in cancer registry records.
Each LOINC record corresponds to a single observation. The LOINC codes are not intended to
transmit all possible information about a test or observation. They are only intended to identify
the observations. The LOINC code for a name is unique and permanent. LOINC codes must
always be transmitted with a hyphen before the check digit (e.g., “10154-3”). The numeric code
is transmitted as a variable length number, without leading zeros.
LOINC codes are copyrighted by Regenstrief Institute and the Logical Observation Identifier
Names and Codes Consortium.
The LOINC database can be obtained from:
The Regenstrief Institute, Inc
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
Telephone: (317) 423-5558
Systematized Nomenclature of Medicine Clinical Terms or SNOMED CT. is a registered
trademark of the International Health Terminology Standards Development Organisation
(IHTSDO). SNOMED CT contains over 300,000 health care concepts with unique meanings and
formal logic-based definitions organized into hierarchies. The fully populated table with unique
descriptions for each concept contains more than 957,000 descriptions. Approximately 1.37
million semantic relationships exist to enable reliability and consistency of data retrieval.
13 of 104
4/25/2012
IHTSDO maintains the SNOMED CT technical design, the core content architecture, and the
SNOMED CT Core content. SNOMED CT Core content includes the technical Specification of
SNOMED CT and fully integrated multi-specialty clinical content. The Core content includes the
concepts table, description table, relationships table, history table, and ICD-9-CM and ICD-10CM mapping, and the Technical Reference Guide.
Each SNOMED record corresponds to a single observation. The SNOMED codes are not
intended to transmit all possible information about an observation, or procedure. They are only
intended to identify the observation or procedure. The SNOMED code for a name is unique and
permanent.
SNOMED CT combines the content and structure of the SNOMED Reference Terminology
(SNOMED RT) with the United Kingdom's Clinical Terms Version 3 (formerly known as the
Read Codes). For information on obtaining the standard, contact:
IHTSDO
Rued Langgaards Vej 7, 5te, 5A56
2300 Copenhagen S
Denmark
Telephone: +45 36 44 87 36
www.ihtsdo.org/snomed-ct
CPT is a registered trademark of the American Medical Association (AMA) for the Current
Procedural Terminology, Fourth Edition (CPT4). The CPT4 is a listing of descriptive terms and
identifying codes for reporting medical services and procedures performed by physicians. The
purpose of the terminology is to provide a uniform language that will accurately describe
medical, surgical, and diagnostic services, and will thereby provide an effective means for
reliable nationwide communication among physicians, patients, and third parties.
Each CPT4 record corresponds to a single observation or diagnosis. The CPT4 codes are not
intended to transmit all possible information about an observation, or diagnosis. They are only
intended to identify the observation or diagnosis. The CPT4 code for a name is unique and
permanent.
Current Procedural Terminology, Fourth Edition (CPT®) is copyrighted by the American
Medical Association. All Rights Reserved. CPT is a registered trademark of the American
Medical Association. For questions regarding the use of CPT codes, contact the American
Medical Association CPT Information and Education Services at (800) 634-6922 or via the web
at www.ama-assn.org.
H
14 of 104
4/25/2012
The International Classification of Diseases, Ninth Revision, Clinical Modification ICD9 (CM)
and Tenth Revision, Clinical Modification (CM) are based on the U.S. modification of the World
Health Organization’s International Classification of Diseases. ICD9 (CM) and ICD10 (CM)
classifies morbidity data for indexing medical records, medical care review, ambulatory and
other medical care programs, as well as for basic health statistics.
Each ICD9 (CM) and ICD10 (CM) record corresponds to a single diagnosis. The ICD9 (CM)
and ICD10 (CM) codes are not intended to transmit all possible information about a diagnosis.
They are only intended to identify the diagnosis. The ICD9 (CM) and ICD10 (CM) code for a
name is unique and permanent.
For questions regarding ICD9 (CM) and ICD10 (CM) codes, refer to the National Center for
Health Statistics at: www.cdc.gov/nchs/
RxNorm is the recommended national standard for medication vocabulary for clinical drugs and
drug delivery devices produced by the National Library of Medicine (NML). RxNorm is
intended to cover all prescription medications approved for human use in the United States.
Because every drug information system that is commercially available today follows somewhat
different naming conventions, a standardized nomenclature is needed for the smooth exchange of
information. The goal of RxNorm is to allow various systems using different drug
nomenclatures to share data efficiently at the appropriate level of abstraction.
Each (RxNorm) clinical drug name reflects the active ingredients, strengths, and dose form
comprising that drug. When any of these elements vary, a new RxNorm drug named is created
as a separate concept.
More information may be found at the U.S. National Library of Medicine Unified Medical
Language System: http://www.nlm.nih.gov/research/umls/rxnorm/docs/index.html
1.5
Definition of a Quality Measure and QRDA’s Role
“A quality measure is a mechanism that enables the user to
quantify the quality of a selected aspect of care by comparing it to
a criterion. A subtype of a quality measure is a clinical
performance measure. Specifically, a clinical performance measure
is a mechanism for assessing the degree to which a provider
competently and safely delivers clinical services that are
appropriate for the patient in the optimal time period.”
Quality measures are used for three general purposes: quality improvement, accountability, and
research. Without the ability to accurately communicate the data in these measures to external
15 of 104
4/25/2012
agencies, the benefit of collecting the information is limited. QRDA’s role is to standardize the
representation of measure-defined data elements to enable interoperability between all of the
stakeholder organizations.
Three types of QRDA quality measure reports have been defined as described in the following
sections.
1.5.1.1
QRDA Category I – Single Patient Report
A QRDA Category I report is an individual patient-level quality report. Each report
contains quality data for one or more quality measures, where the data elements in the
report are defined by the particular measure(s) being reported on. A QRDA Category I
report contains raw applicable patient data. When pooled and analyzed, each report
contributes the quality data necessary to calculate population measure.
NOTE: CMS EHR Warehouse accepts only QRDA Category I reports.
1.5.1.2
QRDA Category II – Multi-patient-level Report
A QRDA Category II report is a multi-patient-level quality report. Each report
contains quality data for a set of patients for one or more quality measures, where the
data elements in the report are defined by the particular measure(s) being reported on.
Whereas a QRDA Category I report contains only raw patient data, a QRDA Category
II report includes flags for each patient indicating whether the patient qualifies for a
measure’s numerator, denominator, exclusion, or other aggregate data element.
1.5.1.3
QRDA Category III – Calculated Report
A QRDA Category III report is an aggregate quality report. Each report contains
calculated summary data for one or more measures for a specified population of
patients within a particular health system over a specific period of time.
Whereas a QRDA Category I and a QRDA Category II report contain data for
individual patients, a QRDA Category III report only contains calculated data (e.g.,
number of meeting numerator criteria, number of meeting denominator criteria) on
the population.
Healthcare Information Technology Standards Panel (HITSP)’s Quality
Implementation Specification (HITSP IS06) describes a “processing entity,” which is
an application role that collects QRDA Category I reports and generates QRDA
Category II and QRDA Category III reports. From the perspective of a processing
entity, all data needed to generate QRDA Category II and QRDA Category III reports
must be included in the collected QRDA Category I reports, as the processing entity
will not have access to additional data sources.
16 of 104
4/25/2012
This Technical Specification uses Continuity of Care Document (CCD) templates for collecting
patient data as the CCD documents are well-known to the EHR vendors and there is an existing
certification process by Certification Commission for Healthcare Information Technology
(CCHIT) for generation and consumption of CCD documents by EHR systems. The usage of
standard CCD templates would make the adoption of this technical specification by the EHR
vendors relatively an easy task.
NOTE: Any additional CCD templates submitted beyond what is specified in this specification
will not be validated or cause the file to reject.
When valued in an instance, the template identifier signals the imposition of a set of templatedefined constraints. The value of this attribute provides a unique identifier for the templates in
question.
1.5.3.1
Originator Responsibilities
An originator can apply a templateId if there is a desire to assert conformance with a
particular template.
In the most general forms of QRDA exchange, an originator need not apply a
templateId for every template that an object in an instance document conforms to.
When templateIds are required for conformance, it shall be asserted within the
technical specification.
1.5.3.2
Recipient Responsibilities
A recipient may reject an instance that does not contain a particular templateId (e.g., a
recipient looking to only receive CCD documents can reject an instance without the
appropriate templateId).
A recipient may process clinical data in incoming QRDA files that do not contain a
templateId (e.g., a recipient can process entries that contain Observation acts within a
Problems section, even if the entries do not have templateIds).
If an object does not have a templateId, a recipient shall not report a conformance error
about a failure to conform to a particular template on classes that do not claim
conformance to that template and that are not required to be conformant by other
templates.
This Specification is a conformance profile, as described in the Refinement and Localization
section of the HL7 Version 3 standards. The base standards for this Specification are the QRDA
H
17 of 104
4/25/2012
H
and HL7 Clinical Document Architecture, Release 2.0 . Though effort is made to describe all the
aspects of applicable QRDA and Clinical Document Architecture Release 2 (CDA R2), every
aspect of the QRDA and CDA R2 may not be described in this Specification.
H
1.5.4.1
H
Explanatory Statements
As an annotation profile, portions of this specification summarize or explain the base
standard. Some originate in the base specification. Those requirements that do not add
further constraints to the base standard and which can be validated through CDA.xsd
do not have corresponding conformance statements.
Where no constraints are stated in this specification, the report instances are subject to
and are to be created in accordance with the QRDA and base CDA R2 specification.
Where, for instance, the CDA R2 Specification declares an attribute to be optional
and this specification contain no additional constraints that attribute remains optional
for use.
1.5.4.2
Conformance Requirements
Conformance requirements for the EHR HL7 QRDA Technical Specification are
numbered sequentially and are displayed as shown in the following example:
CONF-QRDA1-1: Conformance statement for the QRDA Category I framework.
1.5.4.3
Vocabulary Conformance
Measure-specific modeling and constraints should use and define the formalisms for
value set constraints when applicable. In addition, when SNOMED codes are used in
this text, the rules defined in “Using SNOMED CT in HL7 Version 3” should be
adhered to.
Formalisms for value set constraints are based on the latest recommendations from
the HL7 Vocabulary Committee. Value set constraints can be “STATIC,” meaning that
they are bound to a specified version of a value set, or “DYNAMIC,” meaning that they
are bound to the most current version of a value set. A simplified constraint is used
when binding is to a single code.
Syntax for vocabulary binding to DYNAMIC or STATIC value sets is as follows:
The value for (“pathname of coded element”) (SHALL | SHOULD | MAY) be selected from
ValueSet valueSetOID localValueSetName DYNAMIC | STATIC (valueSetEffectiveDate).
CONF-ex1: The value for "ClinicalDocument/code" SHALL be selected from ValueSet
2.16.840.1.113883.1.11.10870 DocumentType DYNAMIC.
CONF-ex2: The value for "ClinicalDocument/code"
SHALL be selected from ValueSet
2.16.840.1.113883.1.11.10870 DocumentType STATIC 20061017.
18 of 104
4/25/2012
Syntax for vocabulary binding to a single code is as follows:
The value for (“pathname of coded element”) (SHALL | SHOULD | MAY) be “code” [“displayName”]
codeSystemOID [codeSystemName] STATIC.
CONF-ex3: The value for “ClinicalDocument/code” SHALL be “34133-9”
"Summarization of episode note" 2.16.840.1.113883.6.1 LOINC STATIC.
1.5.4.4
XPath Notation
Instead of the traditional dotted notation used by HL7 to represent Reference
Information Model (RIM) classes, this document uses XPath notation in conformance
statements and elsewhere to identify the Extensible Markup Language (XML)
elements and attributes within the QRDA document instance to which various
constraints are applied. The implicit context of these expressions is the root of the
document. The purpose of using this notation is to provide a mechanism that will be
familiar to developers for identifying parts of an XML document.
1.5.4.5
Keywords
The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT and SHALL NOT, in this
document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator’s
Guide. The keyword "SHALL" implies a lower cardinality of 1 but does not
disallow NULL values. If NULL values are to be excluded, it will be via additional
explicit conformance statement.
H
Table 1 Keywords
To convey the sense of:
Required/Mandatory
Best Practice/Recommendation
Acceptable/Permitted
1.5.4.6
Use the following:
SHALL
SHALL NOT
SHOULD
SHOULD NOT
MAY
NEED NOT
XML Examples
XML examples appear in various figures in this document in this fixed-width font.
Portions of the XML content may be omitted from the content for brevity, marked by
an ellipsis (…) as shown in the example below.
19 of 104
4/25/2012
Figure 1: ClinicalDocument Example
…
XPath expressions are used in the narrative and conformance requirements to identify
elements because they are familiar to many XML implementers.
1.5.4.7
File Size Limitations
A CDA document is a defined and complete information object that can include text,
images, sounds, and other multimedia content. This Specification does not expect the
inclusion of multimedia content. To prevent inclusion of multimedia content, the
CMS EHR QRDA report size SHALL NOT be more than 10 MB.
1.5.4.8
Use of Object Identifiers (OIDs)
The CMS EHR QRDA Report will use International Organization for Standardization
(ISO) object identifiers (OIDs) to uniquely specify the domain of a coded data value
or an identifier for a person, organization, or other entity. OIDs are used in HL7
Clinical Documents to add global uniqueness to the various identifiers used within the
document.
The identifier consists of two parts:
root: a globally unique identifier composed of an OID whose root is registered at HL7
or constructed based on US National Provider Identifier (NPI).
extension: The value of this attribute is the responsibility of the organization, system,
and/or application where the document is created and stored.
Together, the root and extension, when concatenated, result in a universally unique
string for identification of the document, person, or organization.
Restrictions on OIDs: An OID is an identifier in the form of a tree of nodes and arcs.
Each arc is represented by an unbounded decimal number. OIDs are limited to no
more than 64 characters. Although the digit sequences between the decimal points are
unbounded, some implementations that deal with an OID data type use integers to
represent each arc. The practical limit for an internal arc is 2^31-1. HL7 treats OIDs
as opaque identifiers. The only meaningful comparison between two OIDs is that of
equivalence. If two OIDs match character for character, they are equivalent.
OID Usage Scenarios
The various kinds of identifiers appearing in QRDA documents are described in more
detail below.
Documents
20 of 104
4/25/2012
The first identifier encountered in a QRDA document is the one that explicitly
identifies the document. There is only one of these identifiers in the document, and it
uniquely identifies the specific document that contains it.
Patients
Several types of patient identifiers will likely need to be managed. First,
organizationally assigned patient ids should have their own unique root OID that
scopes them. Each type of id should have a separate OID.
In addition to organizationally assigned ids, it is likely that external ids for a person
will also appear in QRDA documents (i.e. Social Security Number, driver's license
numbers, etc.). For ids that already have OIDs, the existing ones should be utilized for
interoperability. Otherwise an organizational OID should be created for each
namespace to scope each type of id.
Personnel
In cases where the organization instead of some other authority assigns an identifier
to non-patient personnel, the issues surrounding OID management for those persons
(authors, authenticators, informants, healthcare providers, and other document
participants) are largely the same as for patients.
Locations
If facilities or locations will be listed in QRDA documents, then each facility should
have a unique id. Each facility can be assigned its own unique OID, or an
organization can create an OID for facility ids in general, and then assign unique
extensions for each facility.
Devices and Systems
It will likely be very useful to assign OIDs to systems that span multiple locations.
These OIDs will be usable directly when they are listed as authors of a QRDA
document (/ClinicalDocument/author/id).
Encounters
OIDs should be created to scope any service event or encounter ids.
Orders
OIDs should be created to scope the different kinds of identifiers generated by an
application for orders. Some applications generate a placer order number, others
generate a filler order number, and yet others generate both, though usually not for
the same order.
Sections
Sections within a QRDA document may be identified. An OID should be generated to
identify the namespace of QRDA sections.
Entries
21 of 104
4/25/2012
Entries within a QRDA document may also be identified.
Templates
Templates can also be identified. Each template has its own unique OID.
Obtaining an OID
Organizations that do not already have an OID may obtain a root OID from a number
of different sources. These are described in further detail below. There is no
requirement that an organization obtain the OIDs used in their QRDA documents
from any particular source. However obtained, an OID owned by an organization
should be registered with the HL7 registry to enable others to identify the
organization as the owner. See Registering an OID with HL7 below.
From HL7
An OID can be obtained from HL7 by using the HL7 OID Registry found on the web
at http://www.hl7.org/oid/index.cfm . When the organization obtains a new
OID from HL7, it is automatically registered rather than requiring an additional step.
H
From a US National Provider Identifier (NPI)
For providers in the US that do not already have an OID from another source, an OID
can be constructed from the National Provider Identifier (NPI) assigned to an
organization or individual provider by concatenating the assigned NPI to the string
"HL7-NPI-AUTOMATIC-OID-ROOT" (Note: this value is currently a placeholder
for a true OID that will be assigned by HL7) Thus, if a provider organization is
assigned the NPI of 999999999, then their root OID could be "HL7-NPIAUTOMATIC-OID-ROOT.999999999". The other OIDs needed in a QRDA
document would then be created by adding additional arcs to this OID to create new
root OIDs for the different kind of identifiers being used in the QRDA document.
IMPORTANT: It should be noted that OIDs, once created, are simply strings, and are
not bound in any way to an NPI that may have been used to create it. The sole
purpose of this method is to make it easy to receive an OID. Once received, one
should not treat it like an NPI in any way, or assume that an OID must change with an
NPI. This is of particular importance when organizations split or merge. If the lack of
a persistent binding between an NPI and an OID seems confusing, it may be more
appropriate for an organization to obtain an OID from another source such as the HL7
OID registry, so that it is very clear that there is no link whatsoever.
Suggestions for Partitioning an OID for Use in an Organization
The following guidelines are for use by organizations that are new to OIDs and are
looking for some guidance on OID implementation and management.
IMPORTANT: This specification does not suggest that organizations that already
have OIDs and have been managing them for some time should change to using the
approaches outlined below.
22 of 104
4/25/2012
Small to Medium Sized Organizations (such as Practices)
There are several assumptions made in this section with regard to the way that OIDs
are managed. If these assumptions do not apply, then one should look to the OID
partitioning scheme defined for Large Organizations.
The organization uses the same identifier to uniquely identify a patient across
different encounters and locations. This can either be the medical record number
or master patient identifier used by the organization to identify a patient.
The organization makes use of a single electronic medical record system (EMR)
across its various locations of care.
The organization uses the same identifier to uniquely identify personnel
regardless of location.
There is a manageable number of locations, and a way to uniquely identify each
of these within the scope of the organization.
There is a manageable number of entities that the organization places orders with,
and a way to uniquely identify each of these within the scope of the organization.
Once an organization receives a root OID of their own, it is recommended that
they create arcs below that OID using the values in the table below.
Table 2: OIDArc Values
Arc
Description
.1
Documents
.2
Patients
.3
Non-licensed Personnel
.4
Locations
.5
Non-licensed Organizations
.6
Devices
.7
Encounters
.8
Orders
.9
Sections
.10
Entries
.11
Templates
For example: if an organization had a root OID of 2.16.840.1.113883.19.4, then their
arc for documents would be 2.16.840.1.113883.19.4.1, patients would be
2.16.840.1.113883.19.4.2, etc.
Large Organizations (such as Hospitals)
The recommended solution for managing OIDs for large organizations or
organizations with the potential to expand is to start with the organization's OID and
having a three leaf hierarchy for each particular OID.
23 of 104
4/25/2012
The organizational OID would be the root to start. The first leaf is the assigned
system IDs. The second leaf is the site specific ID, and the third leaf is the OID
category (1 for document ids, 2 for patient ids, 3 for provider ids, etc.). The OID
categories should be predefined as much as possible, but if the local site needed an
OID category that was not predefined, they would have the flexibility to define their
own OID category. If possible, that new OID category should be added to this
document so other sites can use the same OID category if needed.
Scenario: In order to completely explain how the recommended solution should work,
here are a few pieces of information that will be used to create the organizational
OIDs.
Good Health Clinic has an organizational NPI of 999999999 and has multiple
facilities in several locations.
Each facility uses the same computer systems which they have identified as
system 120 (outpatient care), 150 (inpatient care) and 170 (emergency care). Each
of those systems operates independently.
There is one central master patient index (MPI) that helps tie all of the records
together. The MPI has been identified as system 2000 and is located at the main
clinic which is clinic 1.
Each of the clinics has been incrementally assigned an ID in order that the clinic
was opened. The first clinic has an ID of 001. The second clinic is 002, etc. When
using these in an OID, the leading zeros need to be removed.
Based on the information above, here are a few examples of how the OIDs would be
created: (each example is followed by the explanation)
HL7-NPI-AUTOMATIC-OID-ROOT.999999999
Good Health organizational OID
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.120
(120) is the outpatient system. (This is the first leaf and the OID is not yet
complete.)
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.120.1
The outpatient system (120) hosted at clinic 001 (1). (This is the second leaf and
the OID is not yet complete.)
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.120.1.1
A document ID (1) on that system. (This is the third leaf - the complete OID)
More examples of complete OIDs:
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.120.1.2
Description: outpatient system (120), hosted at clinic 001 (1), with a patient ID (2)
24 of 104
4/25/2012
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.120.5.2
Description: outpatient system (120), hosted at clinic 005 (5), with a patient ID (2)
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.150.5.2
Description: inpatient system (150), hosted at clinic 005 (5), with a patient ID (2)
HL7-NPI-AUTOMATIC-OID-ROOT.999999999.2000.1.2
Description: MPI system (2000), hosted at clinic 001 (1), with a patient ID (2)
1.6
Road map
The vendors and providers need to approach HL7 to obtain an object identifier (OID).
The Submission Engine Validation Tool (SEVT) within the PQRS Portal shall assign a unique
security Code for each CMS qualified EHR vendor application. Prior to submitting any vetting
data the vendor shall request a security code from SEVT within the PRQS portal. Each Provider
needs to include the Security Code within the generated QRDA files. (NOTE: Author Header
Element is used for that purpose). In the long term, this Qualification ID will likely move to the
metadata layer or to the XDR wrapper information in the Nationwide Health Information
Network (NHIN) environment.
1.7
Key Assumptions
Recognize that this "final" version of the specification is the best information available till date.
If continued qualification or testing reveals new essential changes and CMS and all vendors
concur, there may be further specification updates published.
There may be impacts to the specifications based on the transmission media technology (e.g.,
Portal submissions VS. NHIN submissions).
25 of 104
4/25/2012
2.1
CMS EHR QRDA Report Header Constraints
This section describes constraints that apply to the CMS EHR Quality Reporting Document
Architecture document (QRDA) report header.
2.1.1.1
ClinicalDocument/realmCode
CONF-QRDA1-1: The realmCode element SHALL be present where the value of @code is US.
Figure 2: RealmCode Example
2.1.1.2
ClinicalDocument/typeId
CONF-QRDA1-2: The value of typeId/@root SHALL be 2.16.840.1.113883.1.3 and value of
typeId@etxension SHALL be POCD_HD000040.
2.1.1.3
ClinicalDocument/templateId
This ClinicalDocument/templateId element identifies the template that defines constraints
on the content of an EHR QRDA document.
CONF-QRDA1-3: The CMS EHR QRDA Report SHALL contain at least one Clinical
Document/templateId element.
CONF-QRDA1-4: QRDA Category I templateId ‘root’ value SHALL be
’2.16.840.1.113883.10.20.12’ and PQRI QRDA category l templateId ‘root’ value
SHALL be.’2.16.840.1.113883.3.249.11.100.1’
Figure 3: ClinicalDocument/TemplateId Example
2.1.1.4
ClinicalDocument/id
The id represents the unique instance identifier (UID) of a clinical document. The id element
uniquely and universally distinguishes a document from all other documents. This allows
documents to move among systems without ID collision within those systems. The id element
contains a root and an extension attribute.
CONF-QRDA1-5:
A clinicalDocument/id SHALL be present.
26 of 104
4/25/2012
Figure 4: id Example
2.1.1.5
ClinicalDocument/code
CONF-QRDA1-6: The CMS EHR QRDA Report SHALL contain exactly one
ClinicalDocument/code with a value of “55182-0” 2.16.840.1.113883.6.1 LOINC
STATIC.
2.1.1.6
ClinicalDocument/title
CONF-QRDA1-7: The CMS EHR QRDA Report SHALL contain exactly one
clinicalDocument/title element valued with a case-insensitive, text string containing
“QRDA Incidence Report” or “Quality measure Report.”
2.1.1.7
ClinicalDocument/effectiveTime
Signifies the document creation time, when the document first came into being. Where the CDA
document is a transform from an original document in some other format, the effectiveTime is
the time the original document was created.
CONF-QRDA1-8:
A clinicalDocument/effectiveTime SHALL be present.
CONF-QRDA1-9: The value of effectiveTime/@value SHALL be at least precise to the day
(YYYYMMDD).
Figure 5: effectiveTime Example
2.1.1.8
ClinicalDocument/confidentialityCode
Confidentiality is a required contextual component of this Specification, where the value
expressed in the header holds true for the entire document.
CONF-QRDA1-10: A clinicalDocument/confidentialityCode SHALL be present.
CONF-QRDA1-11: The value of confidentialityCode/@code SHALL be “N” (Normal
confidentiality, only authorized individuals with medical or business need may access this
clinical document) and the value of confidentialityCode/@codeSystem SHALL be
“2.16.840.1.113883.5.25”.
Figure 6: confidentialityCode Example
27 of 104
4/25/2012
2.1.1.9
ClinicalDocument/setId
The elements – setId and versionNumber establish a specific version of a document in a series or
set. Each document is a member of a set as determined by the value of the setId with the
versionNumber indicating where in a series of documents a particular instance is located. This
specification allows replacements to the parent documents. Hence the setId element is a required
element of this specification.
CONF-QRDA1-12: A clinicalDocument/setId SHALL be present.
CONF-QRDA1-13: Providers that already have OIDs and have been managing them for some
time MAY continue using their existing OID policy to populate the value of setId/@root
CONF-QRDA1-14: The value of setId SHALL remain the same as the Parent document for
“replacements”.
Figure 7: setId Example
2.1.1.10
ClinicalDocument/versionNumber
The elements – setId and versionNumber establish a specific version of a document in a series or
set. Each document is a member of a set as determined by the value of the setId with the
versionNumber indicating where in a series of documents a particular instance is located. This
specification allows replacements to the parent documents. Hence the versionNumber element is
a required element of this specification.
CONF-QRDA1-15: A clinicalDocument/versionNumber SHALL be present.
CONF-QRDA1-16: The value of versionNumber/@value SHALL be integer.
Figure 8: versionNumber Example
This section describes the participants in the CMS EHR QRDA Report header.
2.1.2.1
recordTarget
The CMS EHR QRDA Report contains quality measure information about a single
patient.
28 of 104
4/25/2012
CONF-QRDA1-17:
The CMS EHR QRDA Report SHALL contain exactly one
clinicalDocument/recordTarget/PatientRole.
CONF-QRDA1-18:
A recordTarget/patientRole/id element SHALL be present
where the value of @root contains OID for the coding system used to identify the patient.
The value of @extension contains unique patient identifier, the EHR system uses to
record activity on a patient. Commonly used OIDs for entities to identify patient such as TIN,
DLN etc. are available at Appendix_AA-OIDs tab of the Downloadable Resources table.
CONF-QRDA1-19:
The value of recordTarget/patientRole/id element SHALL
remain the same throughout the reporting period.
CONF-QRDA1-20:
The report MAY contain one recordTarget/PatientRole/addr.
CONF-QRDA1-21:
The report SHALL contain exactly one
recordTarget/PatientRole/patient.
CONF-QRDA1-22:
The report SHALL at least contain patient’s legal name at
recordTarget/PatientRole/patient/name.
CONF-QRDA1-23:
The report SHALL contain at least one
recordTarget/patientRole/patient/name/given element for patient’s legal
name.
CONF-QRDA1-24:
The report SHALL contain at least one
recordTarget/patientRole/patient/name/family element for patient’s legal
name.
CONF-QRDA1-25:
A recordTarget/patientRole/patient/ethnicGroupCode
element SHOULD be present where the value of @codeSystem SHALL be
2.16.840.1.113883.5.50 and the value of @code SHALL be from Appendix_AB-Ethnicity tab
of the Downloadable Resources table.
CONF-QRDA1-26:
recordTarget/patientRole/patient/administrativeGender
Code element SHALL be present where the value of @codeSystem SHALL be
2.16.840.1.113883.5.1 and the value of @code SHALL be from Appendix_AC-Gender tab of
the Downloadable Resources table.
CONF-QRDA1-27:
A recordTarget/patientRole/patient/raceCode element
SHOULD be present where the value of @codeSystem SHALL be 2.16.840.1.113883.5.104
and the value of @code SHALL be from Appendix_AD-Race tab of the Downloadable
Resources table.
CONF-QRDA1-28:
SHALL be present.
A recordTarget/patientRole/patient/birthTime element
CONF-QRDA1-29:
recordTarget/patientRole/patient/birthTime SHALL be at
least precise to the day (YYYYMMDD).
CONF-QRDA1-30:
The report SHALL contain exactly one
recordTarget/PatientRole/providerOrganization
29 of 104
4/25/2012
CONF-QRDA1-31:
A recordTarget/patientRole/providerOrganization/id
element SHALL be present where the value of @root SHALL be 2.16.840.1.113883.4.6 and
the value of @extension contains the National Provider Identifier (NPI) of the provider.
CONF-QRDA1-32:
recordTarget/patientRole/providerOrganization/name
element SHOULD be present.
CONF-QRDA1-33:
The report SHALL contain at least one
recordTarget/patientRole/providerOrganization/addr.
CONF-QRDA1-34:
recordTarget/patientRole/providerOrganization/addr/st
reetAddressLine element MAY be present.
CONF-QRDA1-35:
recordTarget/patientRole/providerOrganization/addr/ci
ty element MAY be present.
CONF-QRDA1-36:
recordTarget/patientRole/providerOrganization/addr/st
ate element SHALL be present. All the applicable states that could be used in this element
are available in Appendix_AK-States.
CONF-QRDA1-37:
recordTarget/patientRole/providerOrganization/addr/po
stalCode element MAY be present.
CONF-QRDA1-38:
The report SHALL contain exactly one
recordTarget/patientRole/providerOrganization/asOrganizationPartOf.
CONF-QRDA1-39:
The report SHALL contain exactly one
recordTarget/patientRole/providerOrganization/asOrganizationPartOf/
wholeOrganization.
CONF-QRDA1-40:
A
recordTarget/patientRole/providerOrganization/asOrganizationPartOf/
wholeOrganization/id element SHALL be present where the value of @root SHALL
be 2.16.840.1.113883.4.2 and the value of @extension contains the Taxpayer
Identification Number (TIN) of the provider.
CONF-QRDA1-41.1: The report SHOULD contain exactly one email address for the provider at
recordTarget/patientRole/providerOrganization/telecom.
CONF-QRDA1-41.2: The report SHOULD contain exactly one email address for the
organization at recordTarget/patientRole/providerOrganization/
asOrganizationPartOf/wholeOrganization/telecom.
30 of 104
4/25/2012
Figure 9: recordTarget Example
1200 Eads StreetArlingtonVA22202JohnWalkerDoeJohnGood Health Clinic1200 Joyce StreetArlingtonVA22202
2.1.2.2
author
CONF-QRDA1-41:
The CMS EHR QRDA Report SHALL contain exactly one
clinicalDocument/author.
CONF-QRDA1-42:
An author/time element SHALL be present.
CONF-QRDA1-43:
An author/time SHALL be at least precise to the day (YYYYMMDD).
CONF-QRDA1-44:
An author/assignedAuthor element SHALL be present.
CONF-QRDA1-45:
An author/assignedAuthor/id element SHALL be present. The
value of ClinicalDocument/author/assignedAuthor/id @root SHALL be
31 of 104
4/25/2012
"2.16.840.1.113883.3.249.6". The @extension value represents Security Code
assigned by the SEVT.
CONF-QRDA1-46:
An author/assignedAuthor/id element MAY be present. The
value of ClinicalDocument/author/assignedAuthor/id @root SHALL be
"2.16.840.1.113883.3.249.14”. The @extension value represents the ONC
Approved EHR certification number. It MAY be populated when the submissions are for a
provider participating in the PQRS/HITECH combination.
CONF-QRDA1-47:
present.
An author/assignedAuthor/assignedPerson element MAY be
CONF-QRDA1-48:
The report MAY contain exactly one
author/assignedAuthor/assignedPerson.
CONF-QRDA1-49:
The report MAY contain at least one legal name
author/assignedAuthor/assignedPerson/name.
CONF-QRDA1-50:
At least one
author/assignedAuthor/assignedPerson/name/given element MAY be present.
CONF-QRDA1-51:
At least one
author/assignedAuthor/assignedPerson/name/family element MAY be present.
CONF-QRDA1-52:
The report MAY contain one
author/assignedAuthor/representedOrganization
CONF-QRDA1-53:
If present, an
author/assignedAuthor/representedOrganization/id element MAY be present
where the value of @root contains OID for the authoring organization.
CONF-QRDA1-54:
If present, an
author/assignedAuthor/representedOrganization/name element MAY be
present.
Figure 10: Author Example
2.1.2.3
informant
The CMS EHR QRDA Report must have a stated source so that any data within the
report can be validated. The Source of report is the reporting facility collected via the
informant participant.
32 of 104
4/25/2012
CONF-QRDA1-55:
The CMS EHR QRDA Report SHALL contain exactly one
clinicalDocument/informant, which may represent a reporting facility.
CONF-QRDA1-56:
The report SHALL contain exactly one informant/assignedEntity.
CONF-QRDA1-57:
An informant/assignedEntity/id element SHALL be present.
CONF-QRDA1-58:
If informant has no valid value for id of assignedEntity, then the
value for informant/assignedEntity/id @NullFlavor SHALL be “NA” (Not
applicable).
CONF-QRDA1-59:
An informant/assignedEntity/representedOrganization
element SHALL be present.
CONF-QRDA1-60:
An informant/assignedEntity/representedOrganization/id
element SHALL be present.
CONF-QRDA1-61:
An
informant/assignedEntity/representedOrganization/name element SHOULD be
present.
Figure 11: Informant Example
Good Health Clinic
2.1.2.4
custodian
Custodian represents the organization from which the document originates and that is
in charge of maintaining the document. The custodian is the steward that is entrusted
with the care of the document.
CONF-QRDA1-62:
The CMS EHR QRDA Report SHALL contain exactly one
custodian/assignedCustodian/representedCustodianOrganization/id
element.
CONF-QRDA1-63:
The value of
custodian/assignedCustodian/representedCustodianOrganization/id
element SHALL be the id of the custodian organization.
CONF-QRDA1-64:
A
custodian/assignedCustodian/representedCustodianOrganization/name
element SHOULD be present.
33 of 104
4/25/2012
Figure 12: Custodian Example
Good Health Clinic
2.1.2.5
legalAuthenticator
A legal authenticator is a verifier who officially authenticates the accuracy of the
document. An example would be a Quality Nurse Manager who compiles a quality
report and is responsible for verifying and sending the quality reports. A
legalAuthenticator is recommended in the CMS EHR QRDA Report, but
workflow may be such that in some institutions’ legal authenticator may not be
identified. In the case where a local document is transformed into a QRDA document
for exchange, authentication occurs on the local document, and that fact is reflected in
the exchanged QRDA document.
CONF-QRDA1-65:
The CMS EHR QRDA Report SHOULD contain exactly one
legalAuthenticator element.
CONF-QRDA1-66:
If legalAuthenticator is present, CMS EHR QRDA Report
legalAuthenticator SHALL contain exactly one
clinicalDocument/legalAuthenticator/time element.
CONF-QRDA1-67:
If legalAuthenticator is present,
clinicalDocument/legalAuthenticator/time SHALL be at least precise to the day
(YYYYMMDD).
CONF-QRDA1-68:
If legalAuthenticator is present, CMS EHR QRDA Report
legalAuthenticator SHALL contain exactly one signatureCode element.
CONF-QRDA1-69:
If legalAuthenticator is present, the value of a QRDA
clinicalDocument/signatureCode SHALL be @code “S” (signed).
CONF-QRDA1-70:
If legalAuthenticator is present, CMS EHR QRDA Report
legalAuthenticator SHALL contain exactly one assignedEntity element that
represents the legalauthenticator of the document.
CONF-QRDA1-71:
If legalAuthenticator is present, the clinicalDocument/
legalAuthenticator/assignedEntity SHALL contain an id element.
CONF-QRDA1-72:
If legalAuthenticator is present, a clinicalDocument/
legalAuthenticator/assignedEntity/assignedPerson SHOULD be present.
CONF-QRDA1-73:
If legalAuthenticator is present, clinicalDocument/
legalAuthenticator/assignedEntity/assignedPerson/name/given MAY be
present.
34 of 104
4/25/2012
CONF-QRDA1-74:
If legalAuthenticator is present, clinicalDocument/
legalAuthenticator/assignedEntity/assignedPerson/name/family MAY be
present.
CONF-QRDA1-75:
If legalAuthenticator is present, a clinicalDocument/
legalAuthenticator/assignedEntity/representedOrganization SHOULD be
present.
CONF-QRDA1-76:
If legalAuthenticator is present, clinicalDocument/
legalAuthenticator/assignedEntity/representedOrganization/id SHALL be
present.
CONF-QRDA1-77:
If legalAuthenticator is present, clinicalDocument/
legalAuthenticator/assignedEntity/representedOrganization/name
SHOULD be present.
Figure 13: legalAuthenticator Example
Dr.NancyNightingaleMDGood Health Clinic
2.1.2.6
participant (Primary Care Provider)
The participant header element is used to capture the details of the Primary care
provider.
CONF-QRDA1-78:
The value of participant@typeCode SHALL be “PRF” (performer).
CONF-QRDA1-79:
A participant/functionCode element SHALL be present.
CONF-QRDA1-80:
The value of participant/functionCode@code SHALL be “PCP”
(primary care physician).
CONF-QRDA1-81:
The value of participant/functionCode@codeSystem SHALL be
2.16.840.1.113883.5.88.
CONF-QRDA1-82:
A participant/associatedEntity element SHALL be present.
CONF-QRDA1-83:
The value of participant/associatedEntity@classCode SHALL
be “PROV” (healthcare provider).
35 of 104
4/25/2012
CONF-QRDA1-84:
be present.
A participant/associatedEntity/id/@root element SHALL
CONF-QRDA1-85:
A participant/associatedEntity/associatedPerson element
SHOULD be present.
CONF-QRDA1-86:
If participant/associatedEntity/associatedPerson element
is present, participant/associatedEntity/associatedPerson/name/given
at least one legal given name MAY be present.
CONF-QRDA1-87:
If participant/associatedEntity/associatedPerson element
is present, participant/associatedEntity/associatedPerson/name/family
at least one legal family name MAY be present.
Figure 14: Participant Example
Dr.JohnDoe
2.1.2.7
documentationOf
The documentationOf element describes the encounter during which the subject
was seen and may include a code to describe the encounter as well as identifying the
provider, location, time. There could be one or more documentationOf elements
depending upon number of encounters that are being documented during the reporting
period. Each documentationOf element shall elaborate one single service event.
The encounter codes associated with patient visits are captured using this element.
CONF-QRDA1-88:
The CMS EHR QRDA Report SHALL contain one or more
clinicalDocument/documentationOf elements.
CONF-QRDA1-89:
A documentationOf/serviceEvent element SHALL be present.
CONF-QRDA1-90:
A documentationOf/serviceEvent/code element SHALL be
present. All the applicable encounter codes that could be used in this element are available
in Appendix_B_Encounters.
CONF-QRDA1-91:
A documentationOf/serviceEvent/effectiveTime element
SHALL be present.
CONF-QRDA1-92:
A documentationOf/serviceEvent/effectiveTime element
SHALL contain one low element and one high element indicating the starting and ending
times of the encounter.
36 of 104
4/25/2012
CONF-QRDA1-93:
A documentationOf/serviceEvent/effectiveTime low and high
element SHALL be at least precise to the day (YYYYMMDD).
CONF-QRDA1-94:
A documentationOf/serviceEvent/performer@typeCode SHALL
be either PRF (performer – a person who actually and principally carries out an action) or
PPRF (primary performer - principal performer of the Service event) or SPRF (secondary
performer – a person assisting in the Service event through their substantial presence and
involvement. This may include assistants, technicians, associates, or other performers).
CONF-QRDA1-95:
A
documentationOf/serviceEvent/performer/assignedEntity element SHALL be
present.
CONF-QRDA1-96:
A
documentationOf/serviceEvent/performer/assigndedEntity/id element
SHALL be present, where the value of @root SHALL be 2.16.840.1.113883.4.6 and the value
of @extension SHALL contain the National Provider Identifier (NPI) of the provider, whom the
patient had encountered during the service event.
CONF-QRDA1-97:
A
documentationOf/serviceEvent/performer/assigndedEntity/code element
SHOULD be present.
documentationOf/serviceEvent/performer/assigndedEntity/code element
SHALL be submitted at least once.
CONF-QRDA1-98:
A
documentationOf/serviceEvent/performer/assigndedEntity/addr element
SHOULD be present.
CONF-QRDA1-99:
If
documentationOf/serviceEvent/performer/assigndedEntity/addr is present,
documentationOf/serviceEvent/performer/assigndedEntity/addr/streetA
ddressLine element SHOULD be present.
CONF-QRDA1-100: If
documentationOf/serviceEvent/performer/assigndedEntity/addr is present,
documentationOf/serviceEvent/performer/assigndedEntity/addr/city
element SHOULD be present
CONF-QRDA1-101: If
documentationOf/serviceEvent/performer/assigndedEntity/addr is present,
documentationOf/serviceEvent/performer/assigndedEntity/addr/state
element SHOULD be present. All the applicable states that could be used in this element are
available in Appendix_AK-States.
CONF-QRDA1-102: If
documentationOf/serviceEvent/performer/assigndedEntity/addr is present,
documentationOf/serviceEvent/performer/assigndedEntity/addr/postalc
ode element SHOULD be present.
37 of 104
4/25/2012
CONF-QRDA1-103: A
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on element SHOULD be present.
CONF-QRDA1-104: If
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on is present,
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on/name at least one legal name element MAY be present.
CONF-QRDA1-105: If
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on is present,
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on/name/given at least one legal given name element MAY be present.
CONF-QRDA1-106: If
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on is present,
documentationOf/serviceEvent/performer/assigndedEntity/assignedPers
on/name/family at least one legal family name element MAY be present.
Figure 15: documentationOf Example
21 North AveBurlingtonMA01803Dr.BernardWisemanSr.
38 of 104
4/25/2012
2.2
CMS EHR QRDA Report Body Constraints
The CMS EHR QRDA Report requires a structuredBody. The report will typically contain
several sections and subsections. The top-level sections shall be Measure Set sections which
contain a group of measures being reported. This is illustrated in Figure 16: CMS EHR QRDA
Report Use of Measure Set Sections.
X
Figure 16: CMS EHR QRDA Report Use of Measure Set Sections
Measure Set Section
– Description and Version of Measure Set
Measure Section
- Measure One entries
- Measure Two entries
- Measure Three entries
Reporting Parameters Section
- Reporting Period Entry
Patient Data Section
- Problems Section
- Procedures Section
- Payers Section
- Alerts Section
- Medications Section
- Immunizations Section
- Vital signs Section
- Results Section
- Structural Data Section
- Advance Directives Section
- Plan of Care Section
- Social History Section
- Encounters Section
- Family History
- Medical equipment
CONF-QRDA1-113: The CMS EHR QRDA Report SHALL contain exactly one
clinicalDocument/component/structuredBody.
CONF-QRDA1-114:
section.
The CMS EHR QRDA Report SHALL contain exactly one Measure Set
CONF-QRDA1-115: The Measure Set section SHALL contain one nested Measure section and
SHALL NOT contain more than one nested Measure section.
2.3
CMS EHR QRDA Report Section Constraints
This section describes constraints that apply to the CMS EHR QRDA Report sections within the
Body of the document.
A measure set is a group of individual quality measures applicable to patients with an identified
health-related status such as a demographic profile (i.e., age and sex parameters germane to
preventive health measure sets) or an abnormal health condition (e.g., pneumonia, diabetes
mellitus).
39 of 104
4/25/2012
Quality measures within a measure set may or may not have the same denominator. For example,
measures within the Pneumonia (PN) measure set from the National Hospital Inpatient Quality
Measures manual utilize a consistent definition of pneumonia (from a specified ICD-9 or ICD-10
value set) contributing to denominator inclusion, but other denominator inclusion criteria, such
as age, vary according to the intent of the specific quality measure.
The Measure Set section will contain measures from the measure set that are applicable to the
patient. It does not have to contain all of the measures within a given professionally defined
measure set.
NOTE: Make sure that you supply appropriate "section-code" for this section, to ensure that
correct validation rules could be performed on the section.
CONF-QRDA1-116: The Measure Set section SHALL contain a templateId uniquely identifying
the Measure Set name and version. Use the value from Appendix_AJ Custom_Template_IDs tab of the Downloadable Resources table.
CONF-QRDA1-117:
The Measure Set section SHALL contain a section/code element.
CONF-QRDA1-118: The value for section/code SHALL be 55185-3 MEASURE SET
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-119: The Measure Set section SHALL be valued with section/title with a
case-insensitive, text string containing Measure set: CMS EHR Measure Set.
CONF-QRDA1-120: The Measure Set section MAY contain a section/text element for the
description of the measure set or MAY contain a formal representation of a description of the
measure set.
Figure 17: Measure Set section Example
Measure Set: CMS EHR Measure Set... (optional) description of measure set ...
...
CONF-QRDA1-121: The nested Measure section SHALL contain at least one measure that
belongs to the measure set.
CONF-QRDA1-122:
The Measure section contains information about the measure or measures and patient data about
the measure being reported. The Measure section contains two nested sections: the Reporting
Parameters section and the Patient Data section, which are required.
40 of 104
4/25/2012
NOTE: Make sure that you supply appropriate "section-code" for this section, to ensure that
correct validation rules could be performed on the section.
CONF-QRDA1-123: A nested Measure section SHALL be valued with section/title with a
case-insensitive, text string containing Measure section. The nested measure section
SHALL contain section/code element. In the nested measure section, the value for
section/code SHALL be 55186-1 MEASURE 2.16.840.1.113883.6.1 LOINC STATIC
CONF-QRDA1-124: A nested Measure section SHALL contain at least one templateId
corresponding to the measures. Refer Appendix_AJ-Custom_Template_IDs tab of the
Downloadable Resources table.
CONF-QRDA1-125: A Measure section SHALL contain exactly one nested Reporting
Parameters section (as described in Section 2.3.3 Reporting Parameters Section).
CONF-QRDA1-126: A Measure section SHALL contain exactly one nested Patient Data
section (as described in Section 2.3.4 Patient Data Section).
CONF-QRDA1-127: The Measure section MAY contain a section/text element for the
description of the measure(s).
Figure 18: Nested Measure Section in Measure Set Example
Measure Section Measure #1: Diabetes Mellitus: Hemoglobin A1c Poor
Control in Diabetes Mellitus Measure #2: Diabetes Mellitus: Low Density Lipoprotein
(LDL-C) Control in Diabetes Mellitus Measure #3: Diabetes Mellitus: High Blood Pressure
Control in Diabetes Mellitus
...
Reporting Parameters
...
Patient Data
...
...
41 of 104
4/25/2012
2.3.2.1
Representation of the Measure(s)
The measure is represented as an in definition mood. The version number or
code of the professional society’s definition of the measure is captured in the act’s
code.
CONF-QRDA1-128:
Each measure SHALL be represented with act.
CONF-QRDA1-129: For each Act in the Measure section, the value for act @classCode in
a measure act SHALL be ACT 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-130: For each act in the Measure section the act/@moodCode in a measure
act SHALL be DEF 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-131: For each act in the Measure section there SHALL be an act/code
reflecting the measure name and version. Refer Appendix_AJ-Custom_Template_IDs tab of
the Downloadable Resources table.
CONF-QRDA1-132: Each measure act MAY contain an act/text element containing a
description of the measure.
Figure 19: Measure Act Example
... (optional) description of measure ...
The Reporting Parameters section provides information about the reporting time interval and
may contain other information that helps provide context for the patient data being reported.
NOTE: Make sure that you supply appropriate "section-code" for this section, to ensure that
correct validation rules could be performed on the section.
CONF-QRDA1-133:
element.
The Reporting Parameters section SHALL contain a section/code
CONF-QRDA1-134: The value for Section/code SHALL be 55187-9 Reporting
Parameters 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-135: The Reporting Parameters section SHALL be valued with Section/title with
a case-insensitive, text string containing Reporting Parameters.
CONF-QRDA1-136: The Reporting Parameters section SHALL contain exactly one
Observation Parameters Act, represented as an Act.
CONF-QRDA1-137: The value for act/@classCode in an Observation Parameters Act
SHALL be ACT 2.16.840.1.113883.5.6 ActClass STATIC.
42 of 104
4/25/2012
CONF-QRDA1-138: The value for act/@moodCode in an Observation Parameters Act SHALL
be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-139: The reporting time period shall be represented with effectiveTime/low
element combined with a high element representing respectively the first and last days of
the period reported. The effectiveTime (start date and end date) shall be at least precise to
the day (YYYYMMDD).
CONF-QRDA-139.1: The value for act / code SHALL be 252116004 Observation
Parameters 2.16.840.1.113883.6.96 SNOMED-CT STATIC.
Figure 20: Reporting parameters Time Example
The Patient Data section contains patient data elements and measure-specific grouping data
elements as defined by the particular measure(s).
A patient data element is information about a particular person (as opposed to a population).
Examples include: individual’s test results, individual’s encounter location, individual’s date of
birth etc.
This section reuses CCD section templates and clinical statement templates when appropriate,
such as the problem observation and result observation template to model the observations.
NOTE: Make sure that you supply appropriate "section-code" for this section, to ensure that
correct validation rules could be performed on the section.
CONF-QRDA1-140:
The Patient Data section SHALL contain a section/code element.
CONF-QRDA1-141: The value for Section/code SHALL be 55188-7 Patient Data
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-142: The Patient Data section SHALL be valued with section/title with a
case-insensitive, text string containing Patient Data.
CONF-QRDA1-143: The Patient Data section SHOULD contain patient data pertaining to
measures stated in the Measure section. Any patient data that is not applicable to the
measures will be ignored.
CONF-QRDA1-144:
The measure data SHALL be represented as clinical statements.
43 of 104
4/25/2012
CONF-QRDA1-145: Measure data using SNOMED SHALL be represented per the Using
SNOMED CT® in HL7 Version 3 DSTU.
CONF-QRDA1-146: Measure data SHOULD use CCD and other CDA IG templates where
possible. All the templates that are used by this specification are described in Chapter-3
44 of 104
4/25/2012
3.1 Templates
This specification uses several HL7 CCD templates. For more information on these templates,
refer to the CCD Quick Start Guide (QSG), which is provided free of charge by HIMSS
Electronic Health Record Association (EHRVA), as a service to vendors and others who will be
implementing healthcare documents based on the CCD Implementation Guide. EHRVA’s goal is
to accelerate implementation of this standard which is endorsed by Healthcare Information and
Management Systems Society (HIMSS), integral to several key HITSP interoperability
specifications and IHE content profiles, and is expected to be required for CCHIT certification.
The link to the Quick Start Guide is: http://www.himssehra.org/docs/ccd_qsg.zip
The pattern for section templates specifies required elements and attributes that establish an
unambiguous context for each section.
NOTE: CCD body section templates share a common pattern that applies across all sections.
This pattern is described here and is not repeated in the content areas devoted to individual
sections.
NOTE: Make sure that you supply appropriate "template ID" for all the CCD templates in the
Data Submission files, to ensure that correct validation rules could be performed on the Data
Submission files. Any additional CCD templates submitted beyond what is specified in this
specification will not be validated or cause the file to reject.
3.1.1.1
Section-level Templates
All CCD section-level templates share these requirements:
CCD contains one, but not more than one, instance of a type of section
section SHALL contain a templateId with the value assigned to that type of
section
section SHALL contain a narrative block
section SHOULD contain clinical statements
section SHALL contain a code specific to that section type; all sections in the
CCD body are assigned LOINC codes.
section SHALL contain a title, and the text string within the title SHALL
include a string specific to that section. (Case and language are not significant.)
45 of 104
4/25/2012
The following example illustrates the pattern for section-level templates:
Figure 21: Generic Section level Template Example
section title text goes here
NOTE: For brevity, all subsequent examples include only the entry elements,
excluding the wrapping component, section, section-level templateId, and required
code, title, and text elements.
3.1.1.2
Clinical Statement Templates
Collectively, the nine act classes within the CDA Refined Message Information
Model (RMIM) and their associated relationships and participants constitute the
Clinical Statement pattern and constraints on the pattern are called “clinical
statements.” Combining the semantic classes within the CDA body in a defined
pattern is an example of use of the Clinical Statement pattern developed by HL7 and
used in CDA and other RIM-based Specifications. Therefore, such constructs are
called clinical statements.
A key component of the Clinical Statement is the entryRelationship and
entryRelationship@typeCode, which create relationships between the
entries. While CDA allows arbitrary entry to entryRelationship structures,
only certain combinations of source, target, and typeCode make sense.
Clinical statement templates describe patterns that can be used within one or more
sections. Thus, a problem template may also be used in a family history section,
possibly with addition constraints required for that section.
Figure 22: Generic Clinical Statement Template Example
46 of 104
4/25/2012
3.1.1.3
Supporting (Entry) Templates
Supporting templates are used for recurring concepts such as status, age, product, and
reaction observation. In the example that follows, the reaction observation template is
the target of an alert observation. Taken together, they assert that hives is a
manifestation of an allergic reaction to penicillin. Supporting templates may be used
within clinical statement templates.
Figure 23: Generic Supporting Template Example
The template identifier for the problem section is 2.16.840.1.113883.10.20.1.11.
This section lists and describes all relevant clinical problems for the reporting period.
At a minimum, all pertinent current and historical problems should be listed. CDA R2
represents problems as Observations.
CONF-QRDA1-147: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Problem section (templateId 2.16.840.1.113883.10.20.1.11). The
Problem section SHALL contain a narrative block, and SHALL contain clinical statements.
Clinical statements SHALL include one or more problem acts (templateId
2.16.840.1.113883.10.20.1.27). A problem act SHALL include one or more problem
47 of 104
4/25/2012
observations (templateId 2.16.840.1.113883.10.20.1.28). A problem observation MAY
include one or more negation reasons (templateId 2.16.840.1.113883.3.249.13.100.25)
3.1.2.1
Section Conformance
CONF-QRDA1-148:
The problem section SHALL contain Section / code.
CONF-QRDA1-149: The value for Section / code SHALL be 11450-4 Problem list
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-150:
The problem section SHALL contain Section / title.
CONF-QRDA1-151: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing problems.
3.1.2.2
Clinical Statement Conformance
3.1.2.2.1
Representation of Problems
The template identifier for a problem act is 2.16.840.1.113883.10.20.1.27.
The template identifier for a problem observation is 2.16.840.1.113883.10.20.1.28.
A problem is a clinical statement that a clinician is particularly concerned about and
wants to track. It has important patient management use cases (e.g. health records
often present the problem list as a way of summarizing a patient's medical history).
3.1.2.2.1.1
Problem Act
CONF-QRDA1-152: A problem act (templateId 2.16.840.1.113883.10.20.1.27) SHALL be
represented with Act.
CONF-QRDA1-153: The value for Act / @classCode in a problem act SHALL be ACT
2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-154: The value for Act / @moodCode in a problem act SHALL be EVN
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-155:
A problem act SHALL contain at least one Act / id.
CONF-QRDA1-156: The value for Act / code / @NullFlavor in a problem act SHALL be
NA Not applicable 2.16.840.1.113883.5.1008 NullFlavor STATIC.
CONF-QRDA1-157: A problem act MAY contain exactly one Act / effectiveTime, to
indicate the timing of the concern (e.g. the interval of time for which the problem is a
concern).
CONF-QRDA1-158: A problem act SHALL contain one or more Act /
entryRelationship.
CONF-QRDA1-159: A problem act MAY reference a problem observation, alert observation or
other clinical statement that is the subject of concern, by setting the value for Act /
entryRelationship / @typeCode to be SUBJ 2.16.840.1.113883.5.1002
ActRelationshipType STATIC.
48 of 104
4/25/2012
CONF-QRDA1-160: The target of a problem act with Act / entryRelationship /
@typeCode=SUBJ SHOULD be a problem observation (in the Problem section) or alert
observation, but MAY be some other clinical statement.
3.1.2.2.1.2
Problem Observation
CONF-QRDA1-161: The CMS EHR QRDA Report Problem observation
(2.16.840.1.113883.3.249.11.100.8) SHALL confirm to the rules of Problem observation
(2.16.840.1.113883.10.20.1.28) and SHALL be represented with Observation.
CONF-QRDA1-162: The value for "Observation / moodCode" in a problem observation
SHALL be "EVN" 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-163:
statusCode.
A problem observation SHALL include exactly one Observation /
CONF-QRDA1-164: The value for Observation / statusCode in a problem observation
SHALL be completed 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-165: A problem observation SHALL contain exactly one Observation /
effectiveTime, to indicate the biological timing of condition (e.g. the time the condition
started, the onset of the illness or symptom, the duration of a condition).
Observation/effectiveTime SHALL be the time Stamp of the format YYYYMMDDHHMMSS.
CONF-QRDA1-166: The value for Observation / code in a problem observation MAY be
selected from ValueSet 2.16.840.1.113883.1.11.20.14 ProblemTypeCode STATIC
20061017.
CONF-QRDA1-167: The value for Observation / entryRelationship / @typeCode
in a problem observation MAY be SUBJ Subject 2.16.840.1.113883.5.1002
ActRelationshipType STATIC to reference an age observation (templateId
2.16.840.1.113883.10.20.1.38).
CONF-QRDA1-168: The value for Observation / value/@code in a problem observation
SHALL be from the Appendix_C-Problems tab of the Downloadable Resources table.
CONF-QRDA-168.1: The value for observation / @negationInd in Problem
Observation SHALL be either “true” or “false”.
3.1.2.2.2
Representation of “Status” Values
The template identifier for a problem status observation is
2.16.840.1.113883.10.20.1.50.
The template identifier for a problem healthstatus observation is
2.16.840.1.113883.10.20.1.51.
CONF-QRDA1-169: A problem observation SHALL contain exactly one CMS EHR QRDA
Problem status observation and A CMS EHR QRDA Problem status observation
(2.16.840.1.113883.3.249.11.100.12) SHALL confirm to the rules of Problem status
observation (2.16.840.1.113883.10.20.1.50).
49 of 104
4/25/2012
CONF-QRDA1-170: The value for observation/code/@code in problem status
observation (templateId 2.16.840.1.113883.10.20.1.50) SHALL be 33999-4 status
2.16.840.1.113883.6.1 LOINC STATIC
CONF-QRDA1-171: The value for Observation / value in a problem status observation
SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.13 ProblemStatusCode
STATIC 20061017. Refer Appendix_AE-Vocabs_and_ValueSets tab of the Downloadable
Resources table
CONF-QRDA1-172: A problem observation MAY contain exactly one problem
healthstatus observation.
CONF-QRDA1-173: Value for Observation / code in a problem healthstatus
observation SHALL be 11323-3 Health status 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-174: The value for Observation / value in a problem healthstatus
observation SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.12
ProblemHealthStatusCode STATIC 20061017. Refer Appendix_AEVocabs_and_ValueSets tab of the Downloadable Resources table
CONF-QRDA-174.1: A problem status observation SHALL contain exactly one
observation / effectiveTime. The value for ovservation / effectiveTime Shall be at
least precise to the day (YYYYMMDD).
3.1.2.2.3
Problem Negation reason template
CONF-QRDA-174.2: CMS EHR QRDA Problem negation reason
(2.16.840.1.113883.3.249.11.100.25) SHALL confirm to the rules of CMS EHR QRDA Negation
reason (2.16.840.1.113883.3.249.11.100.24).
CONF-QRDA-174.3: The value for observation / @classCode in a Negation reason SHALL
be OBS.
CONF-QRDA-174.4: The Value for observation / @moodCode in a Negation reason SHALL
be EVN.
CONF-QRDA-174.5: The value for observation / code@code SHALL be ASSERTION and
the value for observation / code@codeSystem SHALL be 2.16.840.1.113883.5.4.
CONF-QRDA-174.6: The value for Problem Negation Reason observation / value/
@code and observation / value / @codeSystem SHALL be from the Appendix_C1Problems (negation) tab of the Downloadable Resource table.
CONF-QRDA-174.7: The value for observation / statusCode in a Negation Reason SHALL
be “completed” 2.16.840.1.113883.5.14 Act Status STATIC.
CONF-QRDA-174.8: Negation Reason SHALL contain exactly one observation /
effectiveTime, which SHALL be at least precise to the day (YYYYMMDD).
50 of 104
4/25/2012
Figure 24: Problem Entry Example
51 of 104
4/25/2012
Figure 25: Problem Entry Negation Example
codeSystem="2.16.840.1.113883.5.8"
52 of 104
4/25/2012
The template identifier for the procedures section is 2.16.840.1.113883.10.20.1.12.
This section defines all interventional, surgical, diagnostic, or therapeutic procedures or
treatments pertinent to the patient historically at the time the document is generated. The section
may contain all procedures for the period of time being summarized, but should include notable
procedures.
CONF-QRDA1-175: The CMS EHR QRDA Report Document SHOULD contain exactly one and
SHALL NOT contain more than one Procedures section (templateId
2.16.840.1.113883.10.20.1.12). The Procedures section SHALL contain a narrative block,
and SHALL contain clinical statements. Clinical statements SHALL include one or more
procedure activities (templateId 2.16.840.1.113883.10.20.1.29). A procedure activity MAY
include one or more negation reasons (templateId 2.16.840.1.113883.3.249.11.100.26).
3.1.3.1
Section conformance
CONF-QRDA1-176:
The procedure section SHALL contain Section / code.
CONF-QRDA1-177: The value for Section / code SHALL be 47519-4 History of
procedures 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-178:
The procedure section SHALL contain Section / title.
CONF-QRDA1-179: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing procedures.
3.1.3.2
Clinical statement conformance
3.1.3.2.1
Procedure activity
The template identifier for a procedure activity is 2.16.840.1.113883.10.20.1.29.
CONF-QRDA1-180: The CMS EHR QRDA Report Procedure activity
(2.16.840.1.113883.3.249.11.100.9) SHALL confirm to the rules of Procedure activity
(2.16.840.1.113883.10.20.1.29) and SHALL be represented with Act, Observation, or
Procedure.
CONF-QRDA1-181: The value for [Act | Observation | Procedure] / @moodCode
in a procedure activity SHALL be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-182: A procedure activity SHALL contain at least one [Act | Observation
| Procedure] / id.
CONF-QRDA1-183: A procedure activity SHALL contain exactly one [Act | Observation
| Procedure] / statusCode.
CONF-QRDA1-184: The value for [Act | Observation | Procedure] /
statusCode in a procedure activity SHALL be selected from ValueSet
2.16.840.1.113883.1.11.20.15 ProcedureStatusCode STATIC 20061017.
53 of 104
4/25/2012
CONF-QRDA1-185: A procedure activity SHALL contain exactly one [Act | Observation
| Procedure] / effectiveTime. The effectiveTime SHALL be the time stamp of the
format YYYYMMDDHHMMSS.
CONF-QRDA1-186: A procedure activity SHALL contain exactly one [Act | Observation
| Procedure] / code.
CONF-QRDA1-187: The value for [Act | Observation | Procedure] / code/
@code and @codeSystem in a procedure activity SHALL be selected from the
Appendix_G-Procedures tab of the Downloadable Resources table.
CONF-QRDA1-187.1:
The value for procedure / @negationInd in procedure
activity SHALL be either “true” or “false”.
CONF-QRDA1-187.2:
CMS EHR QRDA Procedure negation reason
(2.16.840.1.113883.3.249.11.100.26) SHALL confirm to the rules of CMS EHR QRDA
negation reason (2.16.840.1.113883.3.249.11.100.24).
CONF-QRDA1-187.3:
reason SHALL be OBS.
The value for observation / @classCode in a negation
CONF-QRDA1-187.4:
reason SHALL be EVN.
The value for observation / @moodCode in a negation
CONF-QRDA1-187.5:
The value for observation / code@code in a negation
reason SHALL be ASSERTION and the value for observation / code@codeSystem
SHALL be 2.16.840.1.113883.5.4.
CONF-QRDA1-187.6:
The value for procedure negation reason observation /
value / @code and observation / value / @codeSystem SHALL be from the
Appendix_G1- Procedures (negation) tab of the Downloadable Resource Table.
CONF-QRDA1-187.7:
The value for observation / statuscode in a negation
reason SHALL be “completed” 2.16.840.1.113883.5.14 Act Status STATIC.
CONF-QRDA1-187.8:
Negation reason SHALL contain exactly one observation /
effectiveTime, which SHALL be at least precise to the day (YYYYMMDD)
3.1.3.2.2
Procedure related products
Figure 26: Procedure Example
54 of 104
4/25/2012
Figure 27: Procedure Negation Example
The template identifier for the Payers section is 2.16.840.1.113883.10.20.1.9.
Payers contains data on the patient’s payers, whether “third party” insurance, self-pay, other
payer or guarantor, or some combination of payers, and is used to define which entity is the
responsible fiduciary for the financial aspects of a patient’s care.
Each unique instance of a payer and all the pertinent data needed to contact, bill to, and collect
from that payer should be included. Authorization information that can be used to define
pertinent referral, authorization tracking number, procedure, therapy, intervention, device, or
similar authorizations for the patient or provider, or both should be included. At a minimum, the
patient’s pertinent current payment sources should be listed.
The CMS EHR QRDA Report represents the sources of payment as a coverage act, which
identifies all of the insurance policies or government or other programs that cover some or all of
the patient's healthcare expenses. The policies or programs are sequenced by order of
preference. Each policy or program identifies the covered party with respect to the payer, so that
the identifiers can be recorded.
CONF-QRDA1-188: The CMS EHR QRDA Report SHALL contain exactly one and SHALL NOT
contain more than one Payers section (templateId 2.16.840.1.113883.10.20.1.9). The
Payers section SHALL contain a narrative block, and SHALL contain clinical statements.
55 of 104
4/25/2012
Clinical statements SHALL include one or more coverage activities (templateId
2.16.840.1.113883.10.20.1.20).
3.1.4.1
Section conformance
CONF-QRDA1-189:
The payer section SHALL contain Section / code.
CONF-QRDA1-190: The value for Section / code SHALL be 48768-6 Payment sources
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-191:
The payer section SHALL contain Section / title.
CONF-QRDA1-192: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing insurance or payers.
3.1.4.2
Clinical statement conformance
3.1.4.2.1
Payer representation
The template identifier for a coverage activity is 2.16.840.1.113883.10.20.1.20.
The template identifier for a policy activity is 2.16.840.1.113883.10.20.1.26.
The template identifier for an authorization activity is 2.16.840.1.113883.10.20.1.19.
Insurance and authorization acts are represented as Acts within the section. These acts
are grouped together under a single coverage activity, which serves to order the
payment sources. A coverage activity contains one or more policy activities, each of
which contains zero or more authorization activities.
3.1.4.2.1.1
Coverage activity
CONF-QRDA1-193: A coverage activity (templateId 2.16.840.1.113883.10.20.1.20)
SHALL be represented with Act.
CONF-QRDA1-194: The value for Act / @classCode in a coverage activity SHALL be ACT
2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-195: The value for Act / @moodCode in a coverage activity SHALL be DEF
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-196:
A coverage activity SHALL contain at least one Act / id.
CONF-QRDA1-197:
A coverage activity SHALL contain exactly one Act / statusCode.
CONF-QRDA1-198: The value for Act / statusCode in a coverage activity SHALL be
completed 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-199:
A coverage activity SHALL contain exactly one Act / code.
CONF-QRDA1-200: The value for Act / code in a coverage activity SHALL be 48768-6
Payment sources 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-201: A coverage activity SHALL contain one or more Act /
entryRelationship.
56 of 104
4/25/2012
CONF-QRDA1-202: An entryRelationship in a coverage activity MAY contain exactly one
entryRelationship / sequenceNumber, which serves to prioritize the payment
sources.
CONF-QRDA1-203: The value for Act / entryRelationship / @typeCode in a
coverage activity SHALL be COMP 2.16.840.1.113883.5.1002 ActRelationshipType
STATIC.
CONF-QRDA1-204: The target of a coverage activity with Act / entryRelationship /
@typeCode='COMP' SHALL be the CMS EHR QRDA Policy activity
(2.16.840.1.113883.3.249.11.100.7) which SHALL confirm to the rules of Policy activity
(2.16.840.1.113883.10.20.1.26)
3.1.4.2.1.2
Policy Activity
A policy activity represents the policy or program providing the coverage. The person
for whom payment is being provided (i.e. the patient) is the covered party. The
subscriber of the policy or program is represented as a participant that is the holder of
the coverage. The payer is represented as the performer of the policy activity.
CONF-QRDA1-205: A policy activity (templateId 2.16.840.1.113883.10.20.1.26) SHALL
be represented with Act.
CONF-QRDA1-206: The value for Act / @classCode in a policy activity SHALL be ACT
2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-207: The value for Act / @moodCode in a policy activity SHALL be EVN
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-208: A policy activity SHALL contain at least one Act / id, which represents
the group or contract number related to the insurance policy or program.
CONF-QRDA1-209:
A policy activity SHALL contain exactly one Act / statusCode.
CONF-QRDA1-210: The value for Act / statusCode in a policy activity SHALL be
completed 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-211: A policy activity SHOULD contain zero to one Act / code., which
represents the type of coverage.
CONF-QRDA1-212: The value for Act / code / @code in a policy activity SHALL be
selected from ValueSet 2.16.840.1.113883.1.11.19832 ActCoverageType DYNAMIC.
The applicable values of ActCoverageType are available at Appendix_AH-Payers of
Downloadable Resource table. The value of Act/code/@codeSystem SHALL be
2.16.840.1.113883.5.4
CONF-QRDA1-213: A policy activity SHALL contain exactly one Act / performer
[@typeCode=PRF], representing the payer.
CONF-QRDA1-214: A payer in a policy activity SHALL contain one or more performer /
assignedEntity / id, to represent the payer identification number. In addition to the
payer identification number, an additional id SHALL be submitted, which represents the
insurance plan type. The insurance plan type id/ @root SHALL be represented as
57 of 104
4/25/2012
2.16.840.1.113883.12.86 where as the id/ @extension SHALL be selected from the values at
Appendix_AI-Insurance_Plan_Type. NOTE: The EHR Warehouse allows patients with any
type of insurance to be submitted. CMS EHR program participants must submit all Medicare
beneficiary data related to the measures to ensure comparable data is available for potential
incentive calculations.
CONF-QRDA1-215: A policy activity SHALL contain exactly one Act / participant
[@typeCode=COV], representing the covered party.
CONF-QRDA1-216: A covered party in a policy activity SHALL contain one or more
participant / participantRole / id, to represent the patient’s member or
subscriber identifier with respect to the payer. For participant/participantRole/id,
HIC Number SHALL be submitted for Medicare patients. For HIC number, id/@root SHALL be
2.16.840.1.113883.3.249.13.
CONF-QRDA1-217: A covered party in a policy activity SHOULD contain exactly one
participant / participantRole / code, to represent the reason for coverage (e.g.
Self, Family dependent, student).
CONF-QRDA1-218: The value for participant / participantRole / code in a
policy activity’s covered party MAY be selected from ValueSet
2.16.840.1.113883.1.11.19809 PolicyOrProgramCoverageRoleType DYNAMIC.
CONF-QRDA1-219: A covered party in a policy activity MAY contain exactly one
participant / time, to represent the time period over which the patient is covered.
CONF-QRDA1-220: A policy activity MAY contain exactly one Act / participant
[@typeCode=HLD], representing the subscriber.
CONF-QRDA1-221: A subscriber in a policy activity SHOULD contain one or more
participant / participantRole / id, to represent the subscriber’s identifier with
respect to the payer.
CONF-QRDA1-222: A subscriber in a policy activity MAY contain exactly one participant
/ time, to represent the time period for which the subscriber is enrolled.
CONF-QRDA1-223: The value for Act / entryRelationship / @typeCode in a policy
activity SHALL be REFR 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-QRDA1-224: The target of a policy activity with Act / entryRelationship /
@typeCode=REFR SHALL be an authorization activity (templateId
2.16.840.1.113883.10.20.1.19) or an Act, with Act [@classCode = ACT] and Act
[@moodCode = DEF], representing a description of the coverage plan.
CONF-QRDA1-225: A description of the coverage plan SHALL contain one or more Act /
Id, to represent the plan identifier.
3.1.4.2.1.3
Authorization Activity
An authorization activity represents authorizations or pre-authorizations currently
active for the patient for the particular payer.
58 of 104
4/25/2012
Authorizations are represented using an act subordinate to the policy or program that
provided it. The policy or program is referred to by the authorization. Authorized
treatments can be grouped into an Organizer class, where common properties, such as
the reason for the authorization, can be expressed. Subordinate acts represent what
was authorized.
CONF-QRDA1-226: An authorization activity (templateId
2.16.840.1.113883.10.20.1.19) SHALL be represented with Act.
CONF-QRDA1-227: The value for Act / @classCode in an authorization activity SHALL be
ACT 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-228:
An authorization activity SHALL contain at least one Act / id.
CONF-QRDA1-229: The value for Act / @moodCode in an authorization activity SHALL be
EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-230: An authorization activity SHALL contain one or more Act /
entryRelationship.
CONF-QRDA1-231: The value for Act / entryRelationship / @typeCode in an
authorization activity SHALL be SUBJ 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-QRDA1-232: The target of an authorization activity with Act /
entryRelationship / @typeCode=SUBJ SHALL be a clinical statement with
moodCode = PRMS (Promise).
CONF-QRDA1-233: The target of an authorization activity MAY contain one or more performer,
to indicate the providers that have been authorized to provide treatment.
59 of 104
4/25/2012
Figure 28: Payers Example
TN Blue Insurance Organization
60 of 104
4/25/2012
The template identifier for the alerts section is 2.16.840.1.113883.10.20.1.2.
This section is used to list and describe any allergies, adverse reactions, and alerts that are
pertinent to the patient’s current or past medical history. At a minimum, currently active and any
relevant historical allergies and adverse reactions should be listed.
CONF-QRDA1-234: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Alerts section (templateId 2.16.840.1.113883.10.20.1.2). The
Alerts section SHALL contain a narrative block, and SHALL contain clinical statements.
Clinical statements SHALL include one or more problem acts (templateId
2.16.840.1.113883.10.20.1.27). A problem act SHALL include one or more alert
observations (templateId 2.16.840.1.113883.10.20.1.18).
CONF-QRDA1-235: The absence of known allergies, adverse reactions, or alerts SHALL be
explicitly asserted.
3.1.5.1
Section conformance
CONF-QRDA1-236:
The alert section SHALL contain Section / code.
CONF-QRDA1-237: The value for Section / code SHALL be 48765-2 Allergies,
adverse reactions, alerts 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-238:
The alert section SHALL contain Section / title.
CONF-QRDA1-239: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing alert and/or allergies and adverse reactions.
3.1.5.2
Clinical statement conformance
3.1.5.2.1
Representation of alerts
The template identifier for a problem act is 2.16.840.1.113883.10.20.1.27.
The template identifier for an alert observation is 2.16.840.1.113883.10.20.1.18.
A problem is a clinical statement that a clinician is particularly concerned about and
wants to track.
3.1.5.2.1.1
Problem act
The problem act (templateId 2.16.840.1.113883.10.20.1.27) is defined above in the
Problem section.
3.1.5.2.1.2
Alert Observation
CONF-QRDA1-240: The CMS EHR QRDA Report Alert observation
(2.16.840.1.113883.3.249.11.100.6) SHALL confirm to the rules of Alert observation
(2.16.840.1.113883.10.20.1.18) and SHALL be represented with Observation.
61 of 104
4/25/2012
CONF-QRDA1-241: The value for Observation / @moodCode in an alert observation
SHALL be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-242:
statusCode.
An alert observation SHALL include exactly one Observation /
CONF-QRDA1-243: The value for Observation / statusCode in an alert observation
SHALL be completed 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-244: An alert observation SHALL contain exactly one Observation /
effectiveTime, to indicate the biological timing of condition (e.g. the time the condition
started, the onset of the illness or symptom, the duration of a condition).
Observation/effectiveTime SHALL be at least precise to the day (YYYYMMDD).
CONF-QRDA1-245: The value for Observation / value in an alert observation MAY be
slected from Valueset 2.16.840.1.113883.1.11.20.4 AlertTypeCode STATIC 20061017
CONF-QRDA1-246: The absence of known allergies SHOULD be represented in an alert
observation by valuing Observation / value with 160244002 No known allergies
2.16.840.1.113883.6.96 SNOMED CT STATIC.
3.1.5.2.2
Representation of “Status” Values
The template identifier for an alert status observation is
2.16.840.1.113883.10.20.1.39.
CONF-QRDA1-247: An alert observation SHALL contain exactly one CMS EHR QRDA Alert
status observation (2.16.840.1.113883.3.249.11.100.11) which SHALL confirm to the rules
of Alert status observation (2.16.840.1.113883.10.20.1.39)
CONF-QRDA1-248: The value of observation/code in alert status observation
(templateId 2.16.840.1.113883.10.20.1.39) SHALL be 33999-4 status 2.16.840.1.113883.6.1
LOINC STATIC
CONF-QRDA1-249: The value for Observation / value in an alert status observation
SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.3 AlertStatusCode STATIC
20061017.
3.1.5.2.3
Representation of Agent
The agent indicates the entity that is the cause of the allergy or adverse reaction.
While the agent is often implicit in the alert observation (e.g. “allergy to penicillin”),
it should also be asserted explicitly as an entity.
CONF-QRDA1-250: An alert observation SHALL contain at least one Observation /
participant, representing the agent that is the cause of the allergy or adverse reaction.
CONF-QRDA1-251: An agent participation in an alert observation SHALL contain exactly one
participant / participantRole / playingEntity.
62 of 104
4/25/2012
CONF-QRDA1-252: The value for Observation / participant / @typeCode in an
agent participation SHALL be CSM Consumable 2.16.840.1.113883.5.90 ParticipationType
STATIC.
CONF-QRDA1-253: The value for Observation / participant / participantRole
/ @classCode in an agent participation SHALL be MANU Manufactured
2.16.840.1.113883.5.110 RoleClass STATIC.
CONF-QRDA1-254: The value for Observation / participant / participantRole
/ playingEntity / @classCode in an agent participation SHALL be MMAT
Manufactured material 2.16.840.1.113883.5.41 EntityClass STATIC.
CONF-QRDA1-255: An agent participation in an alert observation SHALL contain exactly one
participant / participantRole / playingEntity / code.
CONF-QRDA1-256: The value for participant / participantRole /
playingEntity / code SHALL be selected from the Appendix_H-Alerts tab of the Downloadable
Resources table.
3.1.5.2.4
Reaction Observations and Interventions
The template identifier for a reaction observation is 2.16.840.1.113883.10.20.1.54.
The template identifier for a severity observation is 2.16.840.1.113883.10.20.1.55.
A reaction represents an adverse event due to an administered or exposed substance.
A reaction can be defined with respect to its severity, and can have been treated by
one or more interventions.
CONF-QRDA1-257: An alert observation MAY contain one or more reaction
observations (templateId 2.16.840.1.113883.10.20.1.54), each of which MAY contain
exactly one severity observation (templateId 2.16.840.1.113883.10.20.1.55) AND/OR one or
more reaction interventions.
CONF-QRDA1-258: The value for entryRelationship / @typeCode in a relationship
between an alert observation and reaction observation SHALL be MFST Is
manifestation of 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
63 of 104
4/25/2012
3.1.5.2.4.1
Reaction Observation
CONF-QRDA1-259: The CMS EHR QRDA Report Reaction observation
(2.16.840.1.113883.3.249.11.100.14) SHALL confirm to the rules of Reaction observation
(2.16.840.1.113883.10.20.1.54) and SHALL be represented with Observation.
CONF-QRDA1-260: The value for Observation / @classCode in a reaction observation
SHALL be OBS 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-261: The value for Observation / @moodCode in a reaction observation
SHALL be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-262:
statusCode.
A reaction observation SHALL include exactly one Observation /
CONF-QRDA1-263: The value for Observation / statusCode in a reaction observation
SHALL be completed 2.16.840.1.113883.5.14 ActStatus STATIC.
3.1.5.2.4.2
Severity Observation
CONF-QRDA1-401: A severity observation (templateId 2.16.840.1.113883.10.20.1.55) SHALL be
represented with Observation.
CONF- QRDA1-402: The value for entryRelationship / @typeCode in a relationship
between a reaction observation and severity observation SHALL be SUBJ Has subject
2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF- QRDA1-403: The value for Observation / @classCode in a severity observation
SHALL be OBS 2.16.840.1.113883.5.6 ActClass STATIC.
CONF- QRDA1-404: The value for Observation / @moodCode in a severity observation
SHALL be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF- QRDA1-405: A severity observation SHALL include exactly one Observation /
statusCode.
CONF- QRDA1-406: The value for Observation / statusCode in a severity observation
SHALL be completed 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF- QRDA1-407: A severity observation SHALL contain exactly one Observation / code.
CONF- QRDA1-408: The value for Observation / code in a severity observation SHALL be
SEV Severity observation 2.16.840.1.113883.5.4 ActCode STATIC.
CONF- QRDA1-409: A severity observation SHALL contain exactly one Observation / value.
The element contains the level of severity. It is always represented using the CD
datatype (xsi:type='CD'), even though the value may be a coded or uncoded string. If coded,
it should use the HL7 SeverityObservation vocabulary
(codeSystem='2.16.840.1.113883.5.1063') containing three values (H, M, and L),
representing high, moderate and low severity depending upon whether the severity is life
threatening, presents noticeable adverse consequences, or is unlikely substantially effect the
situation of the subject.
64 of 104
4/25/2012
3.1.5.2.5
Reaction Intervention
CONF-QRDA1-264: The value for entryRelationship / @typeCode in a relationship
between a reaction observation and reaction intervention SHALL be RSON Has reason
2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-QRDA1-265: A reaction intervention SHALL be represented as a procedure
activity (templateId 2.16.840.1.113883.10.20.1.29), a medication activity
(templateId 2.16.840.1.113883.10.20.1.24), or some other clinical statement.
65 of 104
4/25/2012
Figure 29: Alerts Example
entry typeCode="DRIV">
66 of 104
4/25/2012
The template identifier for the medications section is 2.16.840.1.113883.10.20.1.8.
The Medications section defines a patient’s current medications and pertinent medication history.
At a minimum, the currently active medications should be listed. The section may also include a
patient’s prescription history, and enables the determination of the source of a medication list
(e.g. from a pharmacy system vs. from the patient).
CONF-QRDA1-266: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Medications section (templateId 2.16.840.1.113883.10.20.1.8).
The Medications section SHALL contain a narrative block, and SHALL contain clinical
statements. Clinical statements SHOULD include one or more medication activities
(templateId 2.16.840.1.113883.10.20.1.24) and/or supply activities (templateId
2.16.840.1.113883.10.20.1.34).
CONF-QRDA1-267:
The absence of known medications SHALL be explicitly asserted.
CONF-QRDA1-267.1:
A medication activity MAY include one or more negation reasons
(templateId 2.16.840.1.113883.3.249.11.100.27).
3.1.6.1
Section conformance
CONF-QRDA1-268:
The medications section SHALL contain Section / code.
CONF-QRDA1-269: The value for Section / code SHALL be 10160-0 History of
medication use 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-270:
The medications section SHALL contain Section / title.
CONF-QRDA1-271: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing medication.
67 of 104
4/25/2012
3.1.6.2
Clinical statement conformance
3.1.6.2.1
Medication and supply activities
The template identifier for a medication activity is 2.16.840.1.113883.10.20.1.24.
The template identifier for a supply activity is 2.16.840.1.113883.10.20.1.34.
A medication activity (templateId 2.16.840.1.113883.10.20.1.24) is used to describe
what is administered whereas a supply activity (templateId
2.16.840.1.113883.10.20.1.34) is used to describe what has been dispensed.
3.1.6.2.1.1
Medication activity
CONF-QRDA1-272: A medication activity (templateId 2.16.840.1.113883.10.20.1.24)
SHALL be represented with SubstanceAdministration. CMS EHR QRDA Medication
Activity (2.16.840.1.113883.3.249.11.100.28) SHALL confirm to the rules of Medication
Activity (templateId 2.16.840.1.113883.10.20.1.24).
CONF-QRDA1-273: The value for SubstanceAdministration / @moodCode in a
medication activity SHALL be EVN or INT 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-274: A medication activity SHALL contain at least one
SubstanceAdministration / id.
CONF-QRDA1-275: A medication activity SHOULD contain exactly one
SubstanceAdministration / statusCode.
CONF-QRDA1-276: A medication activity SHALL contain one or more
SubstanceAdministration / effectiveTime elements, used to indicate the actual
or intended start and stop date of a medication, and the frequency of administration.
SubstanceAdministration/effectiveTime SHALL be the timestamp of the format
YYYYMMDDHHMMSS.
CONF-QRDA1-277: A medication activity SHOULD contain exactly one
SubstanceAdministration / routeCode.
CONF-QRDA1-278: The value for SubstanceAdministration / routeCode in a
medication activity SHOULD be selected from the HL7 RouteOfAdministration
(2.16.840.1.113883.5.112) code system.
CONF-QRDA1-279: A medication activity SHOULD contain exactly one
SubstanceAdministration / doseQuantity or SubstanceAdministration /
rateQuantity.
CONF-QRDA1-280: A medication activity MAY contain exactly one
SubstanceAdministration / maxDoseQuantity, which represents a maximum dose
limit.
CONF-QRDA1-281: A medication activity MAY contain one or more
SubstanceAdministration / performer, to indicate the person administering a
substance.
68 of 104
4/25/2012
CONF-QRDA1-281.1:
The value for the substanceadministration /
@negationInd in a medication acitivity SHALL be either “true” or “false”.
3.1.6.2.1.2
Supply activity
CONF-QRDA1-282: A supply activity (templateId 2.16.840.1.113883.10.20.1.34) SHALL
be represented with Supply.
CONF-QRDA1-283: The value for Supply / @moodCode in a supply activity SHALL be EVN
or INT 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-284:
A supply activity SHALL contain at least one Supply / id.
CONF-QRDA1-285:
A supply activity SHOULD contain exactly one Supply / statusCode.
CONF-QRDA1-286: A supply activity SHOULD contain exactly one Supply /
effectiveTime, to indicate the actual or intended time of dispensing.
CONF-QRDA1-287: A supply activity MAY contain exactly one Supply / repeatNumber, to
indicate the number of fills. (Note that Supply / repeatNumber corresponds to the number of
fills, as opposed to the number of refills).
CONF-QRDA1-288: A supply activity MAY contain exactly one Supply / quantity, to
indicate the actual or intended supply quantity.
CONF-QRDA1-289: A supply activity MAY contain one or more Supply / author, to
indicate the prescriber.
CONF-QRDA1-290: A supply activity MAY contain one or more Supply / performer, to
indicate the person dispensing the product.
CONF-QRDA1-291: A supply activity MAY contain exactly one Supply / participant /
@typeCode = LOC, to indicate the supply location.
3.1.6.2.2
Medication related information
The template identifier for a patient instruction is 2.16.840.1.113883.10.20.1.49.
The template identifier for a fulfillment instruction is 2.16.840.1.113883.10.20.1.43.
The template identifier for a medication series number observation is
2.16.840.1.113883.10.20.1.46.
The template identifier for a reaction observation is 2.16.840.1.113883.10.20.1.54.
The template identifier for a severity observation is 2.16.840.1.113883.10.20.1.55.
3.1.6.2.2.1
Indications
An indication describes the rationale for an activity. The indication can be an existing
problem or can be a criterion that if met would warrant the activity. Criteria are
typically associated with PRN (from the Latin “pro re nata”, meaning “as needed”)
medications (e.g. “give Medication X as needed for nausea”).
69 of 104
4/25/2012
CONF-QRDA1-292: A medication activity MAY contain one or more
SubstanceAdministration / precondition / Criterion, to indicate that the
medication is administered only when the associated (coded or free text) criteria are met.
CONF-QRDA1-293: A medication activity MAY contain one or more
SubstanceAdministration / entryRelationship, whose value for
entryRelationship / @typeCode SHALL be RSON Has reason
2.16.840.1.113883.5.1002 ActRelationshipType STATIC, where the target of the
relationship represents the indication for the activity.
CONF-QRDA1-294: SubstanceAdministration / entryRelationship /
@typeCode=RSON in a medication activity SHALL have a target of problem act
(templateId 2.16.840.1.113883.10.20.1.27), problem observation (templateId
2.16.840.1.113883.10.20.1.28), or some other clinical statement.
3.1.6.2.2.2
Patient Instructions
Patient instructions are additional information provided to a patient related to one of
their medications (e.g. “take on an empty stomach”).
CONF-QRDA1-295: A medication activity MAY contain one or more patient
instructions.
CONF-QRDA1-296: A patient instruction (templateId 2.16.840.1.113883.10.20.1.49) SHALL be
represented with Act.
CONF-QRDA1-297: The value for Act / @moodCode in a patient instruction SHALL be INT
Intent 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-298: The value for entryRelationship / @typeCode in a relationship to
a patient instruction SHALL be SUBJ Subject 2.16.840.1.113883.5.1002
ActRelationshipType STATIC.
3.1.6.2.2.3
Fulfillment Instructions
Fulfillment instructions are additional information provided to the dispensing party
(e.g. “label in Spanish”).
CONF-QRDA1-299: A supply activity MAY contain one or more fulfillment
instructions.
CONF-QRDA1-300: A fulfillment instruction (templateId 2.16.840.1.113883.10.20.1.43) SHALL
be represented with Act.
CONF-QRDA1-301: The value for Act / @moodCode in a fulfillment instruction SHALL be
INT Intent 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-302: The value for entryRelationship / @typeCode in a relationship
between a supply activity and fulfillment instruction SHALL be SUBJ Subject
2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
3.1.6.2.2.4
Medication Series Number Observation
70 of 104
4/25/2012
The medication series number observation can be used to indicate which in a series of
administrations a particular administration represents (e.g. “hepatitis B vaccine
number 2 was administered on Feb 07, 2004).
CONF-QRDA1-303: A medication activity MAY contain exactly one medication series
number observations.
CONF-QRDA1-304: The value for entryRelationship / @typeCode in a relationship
between a medication activity and medication series number observation SHALL be SUBJ
Subject 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-QRDA1-305: A medication series number observation (templateId
2.16.840.1.113883.10.20.1.46) SHALL be represented with Observation.
CONF-QRDA1-306: The value for Observation / @classCode in a medication series
number observation SHALL be OBS 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-307: The value for Observation / @moodCode in a medication series
number observation SHALL be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-308: A medication series number observation SHALL include exactly one
Observation / statusCode.
CONF-QRDA1-309: A medication series number observation SHALL contain exactly one
Observation / code.
CONF-QRDA1-310: The value for Observation / code in a medication series number
observation SHALL be 30973-2 Dose number 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-311: A medication series number observation SHALL contain exactly one
Observation / value.
CONF-QRDA1-312: The data type for Observation / value in a medication series
number observation SHALL be INT (integer).
3.1.6.2.2.5
Reaction Observations and Interventions
A reaction represents an adverse event due to an administered substance. Significant
reactions are to be listed in the Alerts section. Reactions in the Medications section
can be used to track reactions associated with individual substance administrations or
to track routine follow up to an administration (e.g. “no adverse reaction 30 minutes
post administration”).
The reaction observation (templateId 2.16.840.1.113883.10.20.1.54) and severity
observation (templateId 2.16.840.1.113883.10.20.1.55) templates are defined above,
in the Alerts section.
CONF-QRDA1-313: A medication activity MAY contain one or more reaction
observations (templateId 2.16.840.1.113883.10.20.1.54), each of which MAY contain
exactly one severity observation (templateId 2.16.840.1.113883.10.20.1.55) AND/OR
one or more reaction interventions.
71 of 104
4/25/2012
CONF-QRDA1-314: The value for entryRelationship / @typeCode in a relationship
between a medication activity and reaction observation SHALL be CAUS Is etiology
for 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
3.1.6.2.3
Representation of “Status” Values
The template identifier for a medication status observation is
2.16.840.1.113883.10.20.1.47.
CONF-QRDA1-315:
observation.
A medication activity MAY contain exactly one medication status
CONF-QRDA1-316:
A supply activity MAY contain exactly one medication status observation.
CONF-QRDA1-317: A medication status observation (templateId
2.16.840.1.113883.10.20.1.47) SHALL be a conformant status observation (templateId
2.16.840.1.113883.10.20.1.57).
CONF-QRDA1-318: The value for Observation / value in a medication status
observation SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.7
MedicationStatusCode STATIC 20061017.
3.1.6.2.4
Representation of a Product
The template identifier for a product is 2.16.840.1.113883.10.20.1.53.
The template identifier for a product instance is 2.16.840.1.113883.10.20.1.52.
CONF-QRDA1-319: A medication activity SHALL contain exactly one SubstanceAdministration
/ consumable, the target of which is a product template.
CONF-QRDA1-320: A supply activity MAY contain exactly one Supply / product, the target of
which is a product template.
CONF-QRDA1-321: The CMS EHR QRDA Report Product
(2.16.840.1.113883.3.249.11.100.13) SHALL confirm to the rules of Product
(2.16.840.1.113883.10.20.1.53) and SHALL be represented with the ManufacturedProduct
class.
CONF-QRDA1-322: A manufacturedProduct in a product template SHALL contain exactly one
manufacturedProduct / manufacturedMaterial.
CONF-QRDA1-323: A manufacturedMaterial in a product template SHALL contain exactly one
manufacturedMaterial / code.
CONF-QRDA1-324: The value for manufacturedMaterial / code in a product template SHALL
be selected from the Appendix_A-Medications tab of the Downloadable Resources table.
CONF-QRDA1-325: The value for manufacturedMaterial / code in a product template
SHALL contain a precoordinated product strength, product form, or
product concentration (e.g. “metoprolol 25mg tablet”, “amoxicillin 400mg/5mL
suspension”).
72 of 104
4/25/2012
CONF-QRDA1-326: If manufacturedMaterial / code contains a precoordinated unit
dose (e.g. “metoprolol 25mg tablet”), then SubstanceAdministration /
doseQuantity SHALL be a unitless number that indicates the number of products given
per administration.
CONF-QRDA1-327: If manufacturedMaterial / code does not contain a
precoordinated unit dose (e.g. “metoprolol product”), then SubstanceAdministration /
doseQuantity SHALL be a physical quantity that indicates the amount of product given per
administration.
CONF-QRDA1-328: A manufacturedMaterial in a product template SHALL contain
exactly one Material / code / originalText, which represents the generic name of
the product.
CONF-QRDA1-329: A manufacturedMaterial in a product template MAY contain exactly
one Material / name, which represents the brand name of the product.
CONF-QRDA1-330: A manufacturedProduct in a product template MAY contain exactly
one manufacturedProduct / manufacturerOrganization, which represents the
manufacturer of the Material.
CONF-QRDA1-331: A manufacturedProduct in a product template MAY contain one or
more manufacturedProduct / id, which uniquely represent a particular kind of
product.
CONF-QRDA1-332: manufacturedProduct in a product template contains
manufacturedProduct / id, then ManufacturedProduct SHOULD also contain
manufacturedProduct / manufacturerOrganization.
CONF-QRDA1-333: A medication activity MAY contain one or more product instance
templates (templateId 2.16.840.1.113883.10.20.1.52) to identify a particular product
instance.
CONF-QRDA1-334: A supply activity MAY contain one or more product instance templates
(templateId 2.16.840.1.113883.10.20.1.52) to identify a particular product instance.
CONF-QRDA1-335: Supply / participant / participantRole / id SHOULD be
set to equal a [Act | Observation | Procedure] / participant /
participantRole / id to indicate that the Supply and the Procedure are referring to the
same product instance.
3.1.6.2.5
Medication Negation Reason template
CONF-QRDA1-335.1:
CMS EHR QRDA Medication negation reason
(2.16.840.1.113883.3.249.11.100.27) SHALL confirm to the rules of CMS EHR QRDA
negation reason (2.16.840.1.113883.3.249.11.100.24).
CONF-QRDA1-335.2:
reason SHALL be OBS.
The value for observation / @classCode in a negation
CONF-QRDA1-335.3:
reason SHALL be EVN.
The value for observation / @moodCode in a negation
73 of 104
4/25/2012
CONF-QRDA1-335.4:
The value for observation / code@code in a negation
reason SHALL be ASSERTION and the value for observation / code@codeSystem
SHALL be 2.16.840.1.113883.5.4.
CONF-QRDA1-335.5:
The value for Medication Negation reason observation /
value / @code and observation / value / @codeSystem SHALL be from the
Appendix_ A1 – Medications (negation) tab of the Downloadable Resource table.
CONF-QRDA1-335.6:
The value for observation / statuscode in a negation
reason SHALL be “completed” 2.16.840.1.133833.5.14 ActStatus STATIC.
CONF-QRDA1-335.7:
Negation reason SHALL contain exactly one observation /
effectiveTime, which SHALL be at least precise to the day (YYYYMMDD).
74 of 104
4/25/2012
Figure 30: Medication Example
24 HR Metformin hydrochloride 750 MG Extended
Release Tablet
75 of 104
4/25/2012
Figure 31: Medication Negation Example
24 HR Metformin hydrochloride 750 MG
Extended Release Tablet
76 of 104
4/25/2012
The Immunizations section defines a patient’s current immunization status and
pertinent immunization history. The primary use case for the Immunization section is
to enable communication of a patient’s immunization status. The section should
include current immunization status, and may contain the entire immunization history
that is relevant to the period of time being summarized.
CONF-QRDA1-336: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL
NOT contain more than one Immunizations section (templateId
2.16.840.1.113883.10.20.1.6). The Immunizations section SHALL contain a narrative block,
and SHALL contain clinical statements. Clinical statements SHOULD include one or more
medication activities (templateId 2.16.840.1.113883.10.20.1.24) and/or supply
activities (templateId 2.16.840.1.113883.10.20.1.34).
3.1.7.1
Section conformance
CONF-QRDA1-337:
The immunizations section SHALL contain Section / code.
CONF-QRDA1-338: The value for Section / code SHALL be 11369-6 History of
immunizations 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-339:
The immunizations section SHALL contain Section / title.
CONF-QRDA1-340: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing immunization.
3.1.7.2
Clinical statement conformance
The CMS EHR QRDA Report defines Immunizations using the same data objects and
constraints as for Medications except use Appendix_D-Immunizations tab of the
Downloadable Resources table for value for manufacturedMaterial / code in a product
template. Also use Appendix_D1-Immunizations (negation) tab of the Downloadable
Resource table for the values of observation / value / @code and
@codeSystem. Further the immunization negation reason template
(2.16.840.1.113883.3.249.11.100.29) SHALL confirm to the rules of CMS EHR QRDA
negation reason template (2.16.840.1.113883.3.249.11.10.24).
77 of 104
4/25/2012
Figure 32: Immunization Example
INFLUENZA VACCINATION PROCEDURE
78 of 104
4/25/2012
Figure 33: Immunization Negation Example
INFLUENZA VACCINATION PROCEDURE
The template identifier for the results section is 2.16.840.1.113883.10.20.1.14.
This section contains the results of observations generated by laboratories, imaging procedures,
and other procedures. The scope includes hematology, chemistry, serology, virology, toxicology,
microbiology, plain x-ray, ultrasound, CT, MRI, angiography, cardiac echo, nuclear medicine,
pathology, and procedure observations. The section may contain all results for the period of time
being summarized, but should include notable results such as abnormal values or relevant trends.
Lab results are typically generated by laboratories providing analytic services in areas such as
chemistry, hematology, serology, histology, cytology, anatomic pathology, microbiology, and/or
virology. These observations are based on analysis of specimens obtained from the patient,
submitted to the lab.
Imaging results are typically generated by a clinician reviewing the output of an imaging
procedure, such as where a cardiologist reports the left ventricular ejection fraction based on the
review of a cardiac echo.
Procedure results are typically generated by a clinician wanting to provide more granular
information about component observations made during the performance of a procedure, such as
where a gastroenterologist reports the size of a polyp observed during a colonoscopy.
79 of 104
4/25/2012
CONF-QRDA1-341: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL
NOT contain more than one Results section (templateId 2.16.840.1.113883.10.20.1.14).
The Results section SHALL contain a narrative block, and SHALL contain clinical statements.
Clinical statements SHALL include one or more result organizers (templateId
2.16.840.1.113883.10.20.1.32), each of which SHALL contain one or more result
observations (templateId 2.16.840.1.113883.10.20.1.31).
3.1.8.1
Section conformance
CONF-QRDA1-342:
The result section SHALL contain Section / code.
CONF-QRDA1-343: The value for Section / code SHALL be 30954-2 Relevant
diagnostic tests and/or laboratory data 2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-344:
The results section SHALL contain Section / title.
CONF-QRDA1-345: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing results.
3.1.8.2
Clinical statement conformance
3.1.8.3
Results representation
The template identifier for a result organizer is 2.16.840.1.113883.10.20.1.32.
The template identifier for a result observation is 2.16.840.1.113883.10.20.1.31.
3.1.8.3.1.1
Result organizer
The result organizer identifies an observation set, contained with the result organizer
as a set of result observations. It contains information applicable to all of the
contained result observations.
CONF-QRDA1-346: A result organizer (templateId 2.16.840.1.113883.10.20.1.32)
SHALL be represented with Organizer.
CONF-QRDA1-347: The value for Organizer / @moodCode in a result organizer SHALL be
EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-348:
A result organizer SHALL contain at least one Organizer / id.
CONF-QRDA1-349:
statusCode.
A result organizer SHALL contain exactly one Organizer /
CONF-QRDA1-350:
A result organizer SHALL contain exactly one Organizer / code.
CONF-QRDA1-351: The value for Organizer / code in a result organizer MAY be selected
from LOINC (codeSystem 2.16.840.1.113883.6.1) or SNOMED CT (codeSystem
2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (codeSystem
2.16.840.1.113883.6.12) or ValueSet 2.16.840.1.113883.1.11.20.16 ResultTypeCode
STATIC.
80 of 104
4/25/2012
CONF-QRDA1-352: A result organizer SHOULD include one or more Organizer /
specimen if the specimen isn't inherent in Organizer / code.
CONF-QRDA1-353: Organizer / specimen SHALL NOT conflict with the specimen inherent
in Organizer / code.
CONF-QRDA1-354: Organizer / specimen / specimenRole / id SHOULD be set to
equal a Procedure / specimen / specimenRole / id to indicate that the Results
and the Procedure are referring to the same specimen.
CONF-QRDA1-355:
component.
A result organizer SHALL contain one or more Organizer /
CONF-QRDA1-356: The target of one or more result organizer Organizer / component
relationships MAY be a procedure, to indicate the means or technique by which a result is
obtained, particularly if the means or technique isn’t inherent in Organizer / code or if
there is a need to further specialize the Organizer / code value.
CONF-QRDA1-357: A result organizer Organizer / component / procedure MAY be a
reference to a procedure described in the Procedure section.
CONF-QRDA1-358: The target of one or more result organizer Organizer / component
relationships SHALL be a result observation.
3.1.8.3.1.2
Result observation
CONF-QRDA1-359: The CMS EHR QRDA Report Result observation
(2.16.840.1.113883.3.249.11.100.10) SHALL confirm to the rules of Result observation
(2.16.840.1.113883.10.20.1.31) and SHALL be represented with the observation.
CONF-QRDA1-360: The value for Observation / @moodCode in a result observation SHALL
be EVN 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-361:
A result observation SHALL contain at least one Observation / id.
CONF-QRDA1-362:
statusCode.
A result observation SHALL contain exactly one Observation /
CONF-QRDA1-363: A result observation SHALL contain exactly one Observation /
effectiveTime, which represents the biologically relevant time (e.g. time the specimen was
obtained from the patient). The result observation time SHALL be the time stamp of the
format YYYYMMDDHHMMSS.
CONF-QRDA1-364:
A result observation SHALL contain exactly one Observation / code.
CONF-QRDA1-365: The value for Observation / code in a result observation SHALL be
selected from Appendix_F-Results tab of the Downloadable Resources table.
CONF-QRDA1-366: A result observation MAY contain exactly one Observation / methodCode
if the method isn't inherent in Observation / code or if there is a need to further specialize
the method in Observation / code.
CONF-QRDA1-367: Observation / methodCode SHALL NOT conflict with the method inherent
in Observation / code.
81 of 104
4/25/2012
CONF-QRDA1-368:
A result observation SHALL contain exactly one Observation / value.
CONF-QRDA1-369: The Results observation 'value' SHALL be greater than or equal to the
MINIMUM VALUE and less than or equal to the MAXIMUM VALUE as referenced in
Appendix F of the Downloadable Resource table for the observation 'code' submitted. The
Results observation 'unit' value SHALL be submitted using a valid UNIT OF MEASURE as
referenced in Appendix F of the Downloadable Resource table for the observation 'code'
submitted.
CONF-QRDA1-370: A result observation SHOULD contain exactly one Observation /
interpretationCode, which can be used to provide a rough qualitative interpretation of the
observation, such as “N” (normal), “L” (low), “S” (susceptible), etc. Interpretation is generally
provided for numeric results where an interpretation range has been defined, or for
antimicrobial susceptibility test interpretation.
CONF-QRDA1-371: A result observation SHOULD contain one or more Observation /
referenceRange to show the normal range of values for the observation result.
CONF-QRDA1-372: A result observation SHALL NOT contain Observation / referenceRange /
observationRange / code, as this attribute is not used by the HL7 Clinical Statement or Lab
Committee models.
CONF-QRDA1-373:
A result observation SHALL contain one or more sources of information.
CONF-QRDA-373.1: The value for observation / @negationInd in a result
observation SHALL be either “true” or “false”.
CONF-QRDA-373.2: A result observation MAY include one or more negation reasons
(templateId 2.16.840.1.113883.3.249.11.100.30).
3.1.8.3.1.3
Result negation reason template
CONF-QRDA-373.3: CMS EHR QRDA results negation reason
(2.16.840.1.113883.3.249.11.100.30) SHALL confirm to the rules of CMS EHR QRDA
negation reason (2.16.840.1.113883.3.249.11.100.24).
CONF-QRDA-373.4: The value for observation / @classCode in a negation reason
SHALL be OBS.
CONF-QRDA-373.5: The value for observation / @moodCode in a negation reason
SHALL be EVN.
CONF-QRDA-373.6: The value for observation / code@code SHALL be ASSERTION
and the value for observation / code@codeSystem SHALL be 2.16.840.1.113883.5.4.
CONF-QRDA-373.7: The value for result negation reason observation / value /
@code and observation / value / @codeSystem SHALL be from the Appendix_F1Results (negation) tab of the Downloadable Resources table.
CONF-QRDA-373.8: The value for observation / statuscode in a negation reason
“completed” 2.16.840.1.113883.5.14 ActStatus STATIC.
SHALL be
CONF-QRDA-373.9: Negation reason SHALL contain exactly one observation /
effectivetime, which SHALL be at least precise to the day (YYYYMMDD).
82 of 104
4/25/2012
Figure 34: Results Example
4 - 6%
83 of 104
4/25/2012
Figure 35: Results Negation Example
4 - 6%
84 of 104
4/25/2012
The template identifier for the vital signs section is 2.16.840.1.113883.10.20.1.16.
This section contains current and historically relevant vital signs, such as blood pressure, heart
rate, respiratory rate, height, weight, body mass index, head circumference, crown-to-rump
length, and pulse oximetry. The section may contain all vital signs for the reporting period of
time.
Vital signs are represented like other results, but are aggregated into their own section in order to
follow clinical conventions.
CONF-QRDA1-374: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL
NOT contain more than one Vital signs section (templateId
2.16.840.1.113883.10.20.1.16). The Vital signs section SHALL contain a narrative block, and
SHALL contain clinical statements. Clinical statements SHALL include one or more vital
signs organizers (templateId 2.16.840.1.113883.10.20.1.35), each of which SHALL
contain one or more result observations (templateId 2.16.840.1.113883.10.20.1.31).
A result observation MAY include one or more negation reasons (templateId
2.16.840.1.113883.3.249.11.100.31). A vital signs result observation
(2.16.840.1.113883.3.249.11.100.33) SHALL confirm to the rules of Result observation
(2.16.840.1.113883.10.20.1.31).
3.1.9.1
Section conformance
CONF-QRDA1-375:
The vital signs section SHALL contain Section / code.
CONF-QRDA1-376: The value for Section / code SHALL be 8716-3 Vital signs
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-377:
The vital signs section SHALL contain Section / title.
CONF-QRDA1-378: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing vital signs.
3.1.9.2
Clinical statement conformance
The template identifier for a vital signs organizer is 2.16.840.1.113883.10.20.1.35.
Vital signs are represented like other results with additional vocabulary constraints.
Except the value for Observation / code in a result observation template of Vital Signs
Entry SHALL be selected from Appendix_E-Vital_Signs tab of the Downloadable
Resources table. Also use Appendix_E1- Vital_Signs(negation) tab of Downloadable
Resource table for the values of observation / value / @code and
@codeSystem. Further the vital signs negation reason template
(2.16.840.1.113883.3.249.11.100.31) SHALL confirm to the rules of CMS EHR QRDA
negation reason template (2.16.840.1.113883.3.249.11.100.24).
CONF-QRDA1-379: A vital signs organizer (templateId 2.16.840.1.113883.10.20.1.35) SHALL
be a conformant results organizer (templateId 2.16.840.1.113883.10.20.1.32).
85 of 104
4/25/2012
Figure 36: Vital Signs Example
Figure 37: Vital Signs Negation Example
86 of 104
4/25/2012
This is an optional section, needed to supply information applicable to structural measures to
indicate the use of specific types of health information technology systems. Refer to
Appendix_K-Structural_Codes of the Downloadable Resources table.
CONF-QRDA1-380:
Structural Data SHOULD be represented with Act.
CONF-QRDA1-381: The value for Act / @classCode in a Structural Data SHALL be ACT
2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-382: The value for Act / @moodCode in a Structural Data SHALL be EVN
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-383:
A Structural Data entry SHOULD contain at least one Act / id.
CONF-QRDA1-384:
A Structural Data entry SHALL contain exactly one Act / code.
CONF-QRDA1-385: The value for Act / code in a Structural Data entry SHALL be selected
from Appendix_K-Structural_Codes tab of the Downloadable Resources table.
CONF-QRDA1-386: In a Structured Data entry, an act/effectiveTime element SHALL be
present. An act/effectiveTime element SHALL at least be precise to the day (YYYYMMDD).
CONF-QRDA1-387: One Structured Data entry MAY need to be supplied for each of the
patient encounters during the reporting period. The encounter dates that are mentioned in
the documentationOf Header element MAY match with the date elements of the Structured
Data entry elements.
CONF-QRDA1-388: Structured Data Section SHALL contain section/code element, the value
of section/code/@code SHALL be STRUCT and the value of section/code/@codeSystem
SHALL be 2.16.840.1.113883.3.249.12
CONF-QRDA1-389: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Structural Data section (templateId 2.16.840.1.113883.3.249.11.16).
CONF-QRDA1-390: The template identifier for EHR measure act is
2.16.840.1.113883.3.249.11.13 The template identifier for eRx measure act is
2.16.840.1.113883.3.249.11.14
Figure 38: Structural Data Example
Structured data section ..some text on Structured data section>
87 of 104
4/25/2012
The template identifier for the Advance Directives section is 2.16.840.1.113883.10.20.1.1.
This section contains data defining the patient’s advance directives and any reference to
supporting documentation. The most recent and up-to-date directives are required, if known, and
should be listed in as much detail as possible. This section contains data such as the existence of
living wills, healthcare proxies, and CPR and resuscitation status.
NOTE: The descriptions in this section differentiate between “advance directives”
and “advance directive documents”. The former are the directions whereas the latter
are legal documents containing those directions. Thus, an advance directive might be
“no cardiopulmonary resuscitation”, and this directive might be stated in a legal
advance directive document.
CONF-QRDA1-470: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Advance directives section (templateId
2.16.840.1.113883.10.20.1.1). The Advance directives section SHALL contain a
narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD
include one or more advance directive observations (templateId
2.16.840.1.113883.10.20.1.17). An advance directive observation MAY contain exactly
one advance directive reference (templateId 2.16.840.1.113883.10.20.1.36) to an
external advance directive document. The Advance directives section SHOULD include
one or more CMS EHR QRDA Advance directive observations (templateId
2.16.840.1.113883.3.249.11.100.15) and it SHALL confirm to the rules of Advance
directive observation (2.16.840.1.113883.10.20.1.17).
3.1.11.1
Section conformance
CONF-QRDA1-471: The advance directive section SHALL contain Section / code.
CONF-QRDA1-472: The value for “Section / code” SHALL be “42348-3” “Advance directives”
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-473: The advance directive section SHALL contain Section / title.
CONF-QRDA1-474: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “advance directives”.
3.1.11.2
Advance directive observations
The template identifier for an advance directive observation is 2.16.840.1.113883.10.20.1.17.
The template identifier for verification of an advance directive observation is templateId
2.16.840.1.113883.10.20.1.58.
CONF-QRDA1-475: Advance directive observation SHALL be represented with Observation
CONF-QRDA1-476: The value for “Observation / @classCode” in an advance directive observation
SHALL be “OBS” 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-477: The value for “Observation / @moodCode” in an advance directive observation
SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-478: An advance directive observation SHALL contain at least one Observation / id.
88 of 104
4/25/2012
CONF-QRDA1-479: An advance directive observation SHALL contain exactly one Observation /
statusCode.
CONF-QRDA1-480: The value for “Observation / statusCode” in an advance directive observation
SHALL be “completed” 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-481: An advance directive observation SHOULD contain exactly one Observation /
effectiveTime, to indicate the effective time of the directive.
CONF-QRDA1-482: An advance directive observation SHALL contain exactly one Observation / code.
CONF-QRDA1-483: The value for “Observation / code” in an advance directive observation SHALL be
selected from ValueSet 2.16.840.1.113883.1.11.20.2 AdvanceDirectiveTypeCode
STATIC 20061017.
CONF-QRDA1-484: There SHOULD be an advance directive observation whose value for “Observation
/ code” is “304251008” “Resuscitation status” 2.16.840.1.113883.6.96 SNOMED CT
STATIC.
CONF-QRDA1-485: A verification of an advance directive observation (templateId
2.16.840.1.113883.10.20.1.58) SHALL be represented with Observation / participant.
CONF-QRDA1-486: An advance directive observation SHALL include one or more verifications.
CONF-QRDA1-487: The value for “Observation / participant / @typeCode” in a verification SHALL be
“VRF” “Verifier” 2.16.840.1.113883.5.90 ParticipationType STATIC.
CONF-QRDA1-488: A verification of an advance directive observation SHOULD contain Observation /
participant / time.
CONF-QRDA1-489: The data type of Observation / participant / time in a verification SHALL be at
least precise to the day (YYYYMMDD).
3.1.11.3
Representation of “status” values
The template identifier for an advance directive status observation is
2.16.840.1.113883.10.20.1.37.
CONF-QRDA1-491: An advance directive observation SHALL contain exactly one advance directive
status observation.
CONF-QRDA1-492: An advance directive status observation (templateId 2.16.840.1.113883.10.20.1.37)
SHALL be a conformant status observation (templateId 2.16.840.1.113883.10.20.1.57).
CONF-QRDA1-493: The value for “Observation / value” in an advance directive status observation
SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.1
AdvanceDirectiveStatusCode STATIC 20061017.
3.1.11.4
Advance directive references
The template identifier for an advance directive reference is 2.16.840.1.113883.10.20.1.36.
Referenced advance directive documents are represented with the ExternalDocument class.
CONF-QRDA1-494: An advance directive reference (templateId 2.16.840.1.113883.10.20.1.36) SHALL
be represented with Observation / reference / ExternalDocument.
CONF-QRDA1-495: An advance directive observation MAY contain exactly one advance directive
reference.
CONF-QRDA1-496: The value for “Observation / reference / @typeCode” in an advance directive
reference SHALL be “REFR” 2.16.840.1.113883.5.1002 ActRelationshipType STATIC.
CONF-QRDA1-497: ExternalDocument SHALL contain at least one ExternalDocument / id.
89 of 104
4/25/2012
CONF-QRDA1-498: The URL of a referenced advance directive document MAY be present, and SHALL
be represented in Observation / reference / ExternalDocument / text / reference. A
element containing the same URL SHOULD be present in the associated
CDA Narrative Block.
CONF-QRDA1-499: The MIME type of a referenced advance directive document MAY be present, and
SHALL be represented in Observation / reference / ExternalDocument / text /
@mediaType.
90 of 104
4/25/2012
Figure 39: Advance Directives Example
This description of a “Do not resuscitate” order is verified, current and links to a PDF document.
91 of 104
4/25/2012
The template identifier for the plan of care section is 2.16.840.1.113883.10.20.1.10.
The plan of care section contains data defining pending orders, interventions, encounters,
services, and procedures for the patient. It is limited to prospective, unfulfilled, or incomplete
orders and requests only. All active, incomplete, or pending orders, appointments, referrals,
procedures, services, or any other pending event of clinical significance to the current and
ongoing care of the patient should be listed, unless constrained due to issues of privacy.
The plan of care section also contains information regarding goals and clinical reminders.
Clinical reminders are placed here for purposes of providing prompts that may be used for
disease prevention, disease management, patient safety, and healthcare quality improvements,
including widely accepted performance measures.
CONF-QRDA1-550: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Plan of Care section (templateId 2.16.840.1.113883.10.20.1.10). The Plan
of Care section SHALL contain a narrative block, and SHOULD contain clinical statements.
Clinical statements SHALL include one or more plan of care activities (templateId
2.16.840.1.113883.10.20.1.25). Plan of Care section SHALL include one or more CMS EHR
QRDA Plan of care activity (2.16.840.1.113883.3.249.11.100.2) which SHALL confirm to the rules
of Plan of care activity (2.16.840.1.113883.10.20.1.25).
3.1.12.1
Section conformance
CONF-QRDA1-551: The plan of care section SHALL contain Section / code.
CONF-QRDA1-552: The value for “Section / code” SHALL be “18776-5” “Treatment plan”
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-553: The plan of care section SHALL contain Section / title.
CONF-QRDA1-554: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “plan”.
3.1.12.2
Clinical statement conformance
3.1.12.3
Plan of care activities
The template identifier for a plan of care activity is 2.16.840.1.113883.10.20.1.25.
CONF-QRDA1-555: Plan of care activity SHALL be represented with Observation.
CONF-QRDA1-556: A plan of care activity SHALL contain at least one Observation / id.
CONF-QRDA1-557: A plan of care activity SHALL contain exactly one Observation / @moodCode.
CONF-QRDA1-560: The value for “Observation / @moodCode” in a plan of care activity SHALL be
[“INT” (intent) | “PRMS” (promise) | “PRP” (proposal) | “RQO” (request) | “GOL” (goal)]
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-561: The Plan of care section SHALL contain exactly one observation combination of
'code' and 'codeSystem' attribute values from Appendix_I of the Downloadable Resource table
(for the current program year) identifying clinical data according to the
specifications.
92 of 104
4/25/2012
CONF-QRDA1-562: The value for "Observation / statusCode" in a Plan of care observation SHOULD be
selected from ValueSet 2.16.840.1.113883.1.11.20.10 PlanOfCareStatusCode STATIC
20061017.
CONF-QRDA1-563: Plan of care observation 'effectiveTime' in the Plan of care activity entry SHALL be
the time stamp of the format (YYYYYMMDDHHMMSS).
Figure 40: Plan of Care Example
The template identifier for the social history section is 2.16.840.1.113883.10.20.1.15.
This section contains data defining the patient’s occupational, personal (e.g. lifestyle), social, and
environmental history and health risk factors, as well as administrative data such as marital
status, race, ethnicity and religious affiliation. Social history can have significant influence on a
patient’s physical, psychological and emotional health and wellbeing so should be considered in
the development of a complete record.
CONF-QRDA1-590: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Social history section (templateId 2.16.840.1.113883.10.20.1.15). The
Social history section SHALL contain a narrative block, and SHOULD contain clinical statements.
Clinical statements SHOULD include one or more social history observations (templateId
2.16.840.1.113883.10.20.1.33). Social history section SHOULD include one or more CMS EHR
QRDA Social history observations (templateId 2.16.840.1.113883.3.249.11.100.5) and it SHALL
confirm to the Social History Observation (2.16.840.1.113883.10.20.1.33).
3.1.13.1
Section conformance
CONF-QRDA1-591: The social history section SHALL contain Section / code.
CONF-QRDA1-592: The value for “Section / code” SHALL be “29762-2” “Social history”
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-593: The social history section SHALL contain Section / title.
CONF-QRDA1-594: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “social history”.
3.1.13.2
Social history observation
93 of 104
4/25/2012
The template identifier for a social history observation is 2.16.840.1.113883.10.20.1.33.
CONF-QRDA1-595: A Social history observation SHALL be represented with Observation.
CONF-QRDA1-596: The value for “Observation / @classCode” in a social history observation SHALL
be “OBS” 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-597: The value for “Observation / @moodCode” in a social history observation SHALL
be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-598: A social history observation SHALL contain at least one Observation / id.
CONF-QRDA1-599: A social history observation SHALL include exactly one Observation / statusCode.
CONF-QRDA1-600: The value for “Observation / statusCode” in a social history observation SHALL be
“completed” 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-601: The value for “Observation / code” in a social history observation SHALL be
selected from Appendix_J_Social_History.
CONF-QRDA1-602: Observation / value can be any datatype. Where Observation / value is a physical
quantity, the unit of measure SHALL be expressed using a valid Unified Code for Units of
Measure (UCUM) expression.
3.1.13.3
Representation of “status” values
The template identifier for a social history status observation is 2.16.840.1.113883.10.20.1.56.
CONF-QRDA1-604: A social history observation SHALL contain exactly one CMS EHR QRDA Social
history status observation (2.16.840.1.113883.3.249.11.100.4) which SHALL confirm to
the rules of Social history status observation (2.16.840.1.113883.10.20.1.56).
CONF-QRDA1-605: Social history status observation SHALL be a conformant status observation
(templateId 2.16.840.1.113883.10.20.1.57).
CONF-QRDA1-606: The value for “Observation / value” in a social history status observation SHALL be
selected from ValueSet 2.16.840.1.113883.1.11.20.17 SocialHistoryStatusCode STATIC
20061017.
3.1.13.4
Episode observations
The template identifier for an episode observation is 2.16.840.1.113883.10.20.1.41.
CONF-QRDA1-607: A social history observation MAY contain exactly one episode observation
(templateId 2.16.840.1.113883.10.20.1.41).
94 of 104
4/25/2012
Figure 41: Social History Example
95 of 104
4/25/2012
The template identifier for the encounters section is 2.16.840.1.113883.10.20.1.3.
This section is used to list and describe any healthcare encounters pertinent to the patient’s
current health status or historical health history. An Encounter is an interaction, regardless of the
setting, between a patient and a practitioner who is vested with primary responsibility for
diagnosing, evaluating, or treating the patient’s condition. It may include visits, appointments, as
well as non face-to-face interactions. It is also a contact between a patient and a practitioner who
has primary responsibility for assessing and treating the patient at a given contact, exercising
independent judgment. This section may contain all encounters for the time period being
summarized, but should include notable encounters.
CONF-QRDA1-630: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Encounters section (templateId 2.16.840.1.113883.10.20.1.3).
The Encounters section SHALL contain a narrative block, and SHOULD contain clinical
statements. Clinical statements SHOULD include one or more encounter activities
(templateId 2.16.840.1.113883.10.20.1.21). Encounters section SHOULD include one or more
CMS EHR QRDA Encounter activity (2.16.840.1.113883.3.249.11.100.3) which SHALL confirm to
the rules of Encounter activity (2.16.840.1.113883.10.20.1.21)
3.1.14.1
Section conformance
CONF-QRDA1-631: The encounters section SHALL contain Section / code.
CONF-QRDA1-632: The value for “Section / code” SHALL be “46240-8” “History of encounters”
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-633: The encounters section SHALL contain Section / title.
CONF-QRDA1-634: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “encounters”.
3.1.14.2
Encounter activities
The template identifier for an encounter activity is 2.16.840.1.113883.10.20.1.21.
CONF-QRDA1-635: Encounter activity SHALL be represented with Encounter.
CONF-QRDA1-636: The value for “Encounter / @classCode” in an encounter activity SHALL be “ENC”
2.16.840.1.113883.5.6 ActClass STATIC.
CONF-QRDA1-637: The value for “Encounter / @moodCode” in an encounter activity SHALL be “EVN”
2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-638: An encounter activity SHALL contain at least one Encounter / id.
CONF-QRDA1-639: An encounter activity SHALL contain exactly one Encounter / code.
CONF-QRDA1-640: The value for “Encounter / code” in an encounter activity SHALL be selected from
ValueSet 2.16.840.1.113883.1.11.13955 EncounterCode 2.16.840.1.113883.5.4 ActCode
DYNAMIC.
CONF-QRDA1-641: An encounter activity SHALL contain exactly one Encounter / effectiveTime, and it
SHALL be at least precise to the day (YYYYMMDD).
96 of 104
4/25/2012
CONF-QRDA1-642: An encounter activity MAY contain one or more Encounter / entryRelationship,
whose value for “entryRelationship / @typeCode” SHALL be “RSON” “Has reason”
2.16.840.1.113883.5.1002 ActRelationshipType STATIC, where the target of the
relationship represents the indication for the activity.
CONF-QRDA1-643: An encounter activity MAY contain one or more Encounter / performer, used to
define the practioners involved in an encounter.
CONF-QRDA1-644: Encounter / performer MAY contain exactly one Encounter / performer /
assignedEntity / code, to define the role of the practioner.
CONF-QRDA1-645: An encounter activity MAY contain one or more patient instructions (templateId
2.16.840.1.113883.10.20.1.49).
CONF-QRDA1-646: The value for “Encounter / entryRelationship / @typeCode” in an encounter
activity MAY be “SUBJ” “Subject” 2.16.840.1.113883.5.1002 ActRelationshipType
STATIC to reference an age observation (templateId 2.16.840.1.113883.10.20.1.38).
CONF-QRDA1-647: One Encounter Activity MAY need to be supplied for each of the patient encounters
during the reporting period. The encounter dates that are mentioned in the
documentationOf Header element MAY match with the date elements of Encounter
Activity.
3.1.14.3
Encounter location
The template identifier for a location participation is 2.16.840.1.113883.10.20.1.45.
CONF-QRDA1-648: An encounter activity MAY contain one or more location participations.
CONF-QRDA1-649: A location participation (templateId 2.16.840.1.113883.10.20.1.45) SHALL be
represented with the participant participation.
CONF-QRDA1-650: The value for “participant / @typeCode” in a location participation SHALL be
“LOC” 2.16.840.1.113883.5.90 ParticipationType STATIC.
CONF-QRDA1-651: A location participation SHALL contain exactly one participant / participantRole.
CONF-QRDA1-652: The value for “participant / participantRole / @classCode” in a location
participation SHALL be “SDLOC” “Service delivery location” 2.16.840.1.113883.5.110
RoleClass STATIC.
CONF-QRDA1-653: Participant / participantRole in a location participation MAY contain exactly one
participant / participantRole / code.
CONF-QRDA1-654: The value for “participant / participantRole / code” in a location participation
SHOULD be selected from ValueSet 2.16.840.1.113883.1.11.17660
ServiceDeliveryLocationRoleType 2.16.840.1.113883.5.111 RoleCode DYNAMIC.
CONF-QRDA1-655: Participant / participantRole in a location participation MAY contain exactly one
participant / participantRole / playingEntity.
CONF-QRDA1-656: The value for “participant / participantRole / playingEntity / @classCode” in a
location participation SHALL be “PLC” “Place” 2.16.840.1.113883.5.41 EntityClass
STATIC.
97 of 104
4/25/2012
Figure 42: Encounter Example
<Good Health Clinic
The template identifier for the medical equipment section is 2.16.840.1.113883.10.20.1.7.
The Medical Equipment section defines a patient’s implanted and external medical devices and
equipment that their health status depends on, as well as any pertinent equipment or device
history. This section is also used to itemize any pertinent current or historical durable medical
equipment (DME) used to help maintain the patient’s health status. All pertinent equipment
relevant to the diagnosis, care, and treatment of a patient should be included.
The CMS EHR QRDA report defines medical equipment using the same data objects and
constraints as for Medications.
CONF-QRDA1-657: The CMS EHR QRDA report SHOULD contain exactly one and SHALL NOT contain
more than one Medical Equipment section (templateId 2.16.840.1.113883.10.20.1.7).
The Medical Equipment section SHALL contain a narrative block, and SHOULD contain
clinical statements. Clinical statements SHOULD include one or more supply activities
(templateId 2.16.840.1.113883.10.20.1.34) and MAY include one or more medication
activities (templateId 2.16.840.1.113883.10.20.1.24).
3.1.15.1
Section conformance
CONF-QRDA1-658: The medical equipment section SHALL contain Section / code.
CONF-QRDA1-659: The value for “Section / code / @code” SHALL be “46264-8” “History of medical
device use”. The value for “Section / code / @codeSystem” SHALL be
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-660: The medical equipment section SHALL contain Section / title.
98 of 104
4/25/2012
CONF-QRDA1-661: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “equipment”.
3.1.15.2
Clinical Statement conformance
The CMS EHR QRDA report defines medical equipment using the same data objects and
constraints as for Medications.
3.1.15.2.1.1
Supply activity
CONF-QRDA1-662: A supply activity (templateId 2.16.840.1.113883.10.20.1.34) SHALL be
represented with Supply. The CMS EHR QRDA Report supply activity
(2.16.840.1.113883.3.249.11.100.22) SHALL confirm to the rules of Supply Activity
(2.16.840.1.113883.10.20.1.34).
CONF-QRDA1-663: The value for Supply / @moodCode in a supply activity SHALL be EVN or INT
2.16.840.1.113883.5.1001 ActMood STATIC
CONF-QRDA1-664: A supply activity SHALL contain at least one Supply / id.
CONF-QRDA1-665: A supply activity SHOULD contain exactly one Supply / statusCode.
CONF-QRDA1-666: A supply activity SHALL contain exactly one Supply / effectiveTime, to
indicate the actual or intended time of dispensing. Supply / effectiveTime SHALL be the time stamp of the
format YYYYMMDDHHMMSS.
3.1.15.2.2
Representation of “Status” Values
The template identifier for a medication status observation is 2.16.840.1.113883.10.20.1.47.
CONF-QRDA1-667: A supply activity SHALL contain exactly one medication status observation.
CONF-QRDA1-668: A medication status observation (templateId 2.16.840.1.113883.10.20.1.47)
SHALL be a conformant status observation (templateId 2.16.840.1.113883.10.20.1.57).
CONF-QRDA1-669: The value for Observation / value in a medication status observation SHALL
be selected from ValueSet 2.16.840.1.113883.1.11.20.7 MedicationStatusCode STATIC 20061017.
3.1.15.3
Representation of a Product instance
The template identifier for a product instance is 2.16.840.1.113883.10.20.1.52.
CONF-QRDA1-670: The CMS EHR QRDA Report Product instance
(2.16.840.1.113883.3.249.11.100.23) SHALL confirm to the rules of Product instance
(2.16.840.1.113883.10.20.1.52).
CONF-QRDA1-671: The value for playingDevice / code in a product instance template SHALL be
selected from the Appendix_L-Medical Equipment table of the Downloadable Resoure table.
CONF-QRDA1-672: A supply activity SHALL contain one or more product instance templates (templateId
2.16.840.1.113883.10.20.1.52) to identify a particular product instance.
99 of 104
4/25/2012
Figure 43: Medical Equipment Example
The template identifier for the family history section is 2.16.840.1.113883.10.20.1.4.
This section contains data defining the patient’s genetic relatives in terms of possible or relevant
health risk factors that have potential impact on the patient’s heathcare risk profile.
CONF-QRDA1-673: The CMS EHR QRDA Report SHOULD contain exactly one and SHALL NOT
contain more than one Family history section (templateId
2.16.840.1.113883.10.20.1.4). The Family history section SHALL contain a
narrative block, and SHOULD contain clinical statements. Clinical statements
SHOULD include one or more family history observations (templateId
2.16.840.1.113883.10.20.1.22), which SHALL be contained within family history
organizers (templateId 2.16.840.1.113883.10.20.1.23). Family history section
SHOULD include one or more CMS EHR Family History Organizers
(2.16.840.1.113883.3.249.11.100.20) which SHALL confirm to the rules of
Family History Organizers (2.16.840.1.113883.10.20.11.23).
100 of 104
4/25/2012
3.1.16.1
Section conformance
CONF-QRDA1-674: The family history section SHALL contain Section / code.
CONF-QRDA1-675: The value for “Section / code / @code” SHALL be “10157-6” “History of family
member diseases”. The value for “Section / code / @codeSystem” SHALL be
2.16.840.1.113883.6.1 LOINC STATIC.
CONF-QRDA1-676: The family history section SHALL contain Section / title.
CONF-QRDA1-677: Section / title SHOULD be valued with a case-insensitive language-insensitive text
string containing “family history”.
CONF-QRDA1-678: The family history section SHALL NOT contain Section / subject.
3.1.16.2
Clinical conformance
3.1.16.2.1
Family history representation
The template identifier for a family history observation is 2.16.840.1.113883.10.20.1.22.
The template identifier for a family history organizer is 2.16.840.1.113883.10.20.1.23.
Family history observations shall be contained within a family history organizer in order to
group those observations related to a particular family member.
3.1.16.2.1.1
Family history observation
CONF-QRDA1-679: A family history observation (templateId 2.16.840.1.113883.10.20.1.22) SHALL be
represented with Observation.
CONF-QRDA1-680: The value for “Observation / @moodCode” in a family history observation SHALL
be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-681: A family history observation SHALL contain at least one Observation / id.
CONF-QRDA1-682: A family history observation SHALL include exactly one Observation / statusCode.
CONF-QRDA1-683: The value for “Observation / statusCode” in a family history observation SHALL be
“completed” 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-684: A family history observation SHOULD include Observation / effectiveTime.
CONF-QRDA1-685: The value for “Observation / value / @code” and “@CodeSystem” in a Family
history observation SHALL be selected from Appendix_M- Family_History.
3.1.16.2.1.2
Family history organizer
CONF-QRDA1-686: A family history organizer (templateId 2.16.840.1.113883.10.20.1.23) SHALL be
represented with Organizer.
CONF-QRDA1-687: The value for “Organizer / @classCode” in a family history organizer SHALL be
“CLUSTER” 2.16.840.1.113883.5.6 ActClass STATIC.
101 of 104
4/25/2012
CONF-QRDA1-688: The value for “Organizer / @moodCode” in a family history organizer SHALL be
“EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-QRDA1-689: A family history organizer SHALL contain exactly one Organizer / statusCode.
CONF-QRDA1-690: The value for “Organizer / statusCode” in a family history organizer SHALL be
“completed” 2.16.840.1.113883.5.14 ActStatus STATIC.
CONF-QRDA1-691: A family history organizer SHALL contain one or more Organizer / component.
CONF-QRDA1-692: The target of a family history organizer Organizer / component relationship SHALL
be a family history observation. Family history organizer SHALL include one or
more CMS EHR QRDA Family history observations
(2.16.840.1.13883.3.249.1.100.21) which SHALL conform to the rules of Family
history observations (2.16.840.1.113883.10.20.1.22).
3.1.16.2.2
Family history participants
CONF-QRDA1-693: A family history organizer SHALL contain exactly one subject participant,
representing the family member who is the subject of the family history
observations.
CONF-QRDA1-694: A subject participant SHALL contain exactly one RelatedSubject, representing the
relationship of the subject to the patient.
CONF-QRDA1-695: The value for “RelatedSubject / @classCode” SHALL be “PRS” “Personal
relationship” 2.16.840.1.113883.5.110 RoleClass STATIC
CONF-QRDA1-696: RelatedSubject SHALL contain exactly one RelatedSubject / code.
CONF-QRDA1-697: The value for “RelatedSubject / code” SHOULD be selected from ValueSet
2.16.840.1.113883.1.11.19579 FamilyHistoryRelatedSubjectCode DYNAMIC or
2.16.840.1.113883.1.11.20.21 FamilyHistoryPersonCode DYNAMIC.
CONF-QRDA1-698: RelatedSubject SHOULD contain exactly one RelatedSubject / subject.
CONF-QRDA1-699: RelatedSubject / subject SHOULD contain exactly one RelatedSubject / subject /
administrativeGenderCode.
CONF-QRDA1-700: RelatedSubject / subject SHALL contain exactly one RelatedSubject / subject /
birthtime.
102 of 104
4/25/2012
Figure 44: Family History Example
103 of 104
4/25/2012
References
Implementation Guide for CDA Release 2 – Quality Reporting Document
Architecture (QRDA) Release 1 – Draft Standard for Trial use - available through
Health Level Seven®, Inc. All Rights Reserved.
AMA Collaborative for Performance Measure Integration with EHR Systems:
http://www.ama-assn.org/go/collaborative
CDA: Clinical Document Architecture Release 2: Last Published: 09/25/2005
9:14 PM - available through Health Level Seven®, Inc. All Rights Reserved.
CCD: Continuity of Care Document - available through Health Level Seven®,
Inc. All Rights Reserved.
H
Collaborative for Performance Measure Integration with EHR Systems Work
Group A Recommendations to full Collaborative: http://www.amaassn.org/ama1/pub/upload/mm/472/wkgrparecommendation.pd
f
HIMSS Electronic Health Record Association - Continuity of Care Document
(CCD) Quick Start Guide: http://www.himssehra.org/docs/ccd_qsg.zip
HITSP Quality Interoperability Specification:
http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=1&PrefixNumeri
c=06
ICD-10 Implementation Guide: https://www.cms.gov/ICD10/
Logical Observation Identifiers Names and Codes (LOINC®) http://loinc.org/
National Quality Forum: http://www.qualityforum.org/
NCQA > HEDIS & Quality Measurement:
http://www.ncqa.org/tabid/59/Default.aspx
SNOMED CT®: http://www.ihtsdo.org/snomed-ct
104 of 104
4/25/2012