Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology

AGENCY:

Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services.

ACTION:

Final rule.

SUMMARY:

With this final rule, the Secretary of Health and Human Services adopts certification criteria that establish the technical capabilities and specify the related standards and implementation specifications that Certified Electronic Health Record (EHR) Technology will need to include to, at a minimum, support the achievement of meaningful use by eligible professionals, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs beginning with the EHR reporting periods in fiscal year and calendar year 2014. This final rule also makes changes to the permanent certification program for health information technology, including changing the program's name to the ONC HIT Certification Program.

DATES:

These regulations are effective October 4, 2012. The incorporation by reference of certain publications listed in the rule is approved by the Director of the Federal Register as of October 4, 2012.

FOR FURTHER INFORMATION CONTACT:

Steven Posnack, Director, Federal Policy Division, Office of Policy and Planning, Office of the National Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION:

This final rule is issued under section 3004 of the Public Health Service Act.

Commonly Used Acronyms

CAH Critical Access Hospital

CDA Clinical Document Architecture

CDC Centers for Disease Control and Prevention

CDS Clinical Decision Support

CEHRT Certified EHR Technology

CFR Code of Federal Regulations

CHPL Certified HIT Products List

CMS Centers for Medicare & Medicaid Services

CQM Clinical Quality Measure

CY Calendar Year

EH Eligible Hospital

EHR Electronic Health Record

EP Eligible Professional

FY Fiscal Year

HHS Department of Health and Human Services

HIPAA Health Insurance Portability and Accountability Act of 1996

HIT Health Information Technology

HITECH Health Information Technology for Economic and Clinical Health

HITPC HIT Policy Committee

HITSC HIT Standards Committee

HL7 Health Level Seven

ICD-9-CM International Classification of Diseases, 9th Revision, Clinical Modification

ICD-10 International Classification of Diseases, 10th Revision

ICD-10-CM International Classification of Diseases, 10th Revision, Clinical Modification

ICD-10-PCS International Classification of Diseases, 10th Revision, Procedure Coding System

IHE Integrating the Healthcare Enterprise®

LOINC® Logical Observation Identifiers Names and Codes

MU Meaningful Use

ONC Office of the National Coordinator of Health Information Technology

NCPDP National Council for Prescription Drug Programs

NIST National Institute of Standards and Technology

PHSA Public Health Service Act

SNOMED CT® Systematized Nomenclature of Medicine Clinical Terms

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Major Provisions

1. Overview of the 2014 Edition EHR Certification Criteria

2. Certified EHR Technology

3. ONC HIT Certification Program

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. HIT Certification Programs

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

2. Medicare and Medicaid EHR Incentive Programs Rules

3. HIT Certification Programs Rules

III. Provisions of the Final Rule Affecting Standards, Implementation Specifications and Certification Criteria

A. 2014 Edition EHR Certification Criteria

1. Certification Criteria Relationship to MU

2. Applicability

3. Scope of a Certification Criterion for Certification

4. Explanation and Revision of Terms Used in Certification Criteria

5. Consensus-Based Standards

6. Adopting Versions of Standards

7. Display of Vocabulary Standards

8. Common Data Elements in Certification Criteria

9. New Certification Criteria

a. Ambulatory and Inpatient Setting

b. Ambulatory Setting

c. Inpatient Setting

10. Revised Certification Criteria

a. Ambulatory and Inpatient Setting

b. Ambulatory Setting

c. Inpatient Setting

11. Unchanged Certification Criteria

a. Refinements to Unchanged Certification Criteria

b. Unchanged Certification Criteria Without Refinements

12. Gap Certification

13. “Disability” Status

B. Redefining Certified EHR Technology and Related Terms

1. Certified EHR Technology (CEHRT) Definition

2. Base EHR Definition

3. Complete EHR Definition

4. Certifications Issued for Complete EHRs and EHR Modules

5. Adaptations of Certified Complete EHRs or Certified EHR Modules

IV. Provisions of the Final Rule Affecting the Permanent Certification Program for HIT (“ONC HIT Certification Program”)

A. Program Name Change

B. “Minimum Standards” Code Sets

C. Revisions to EHR Module Certification Requirements

1. Privacy and Security Certification

2. Certification to Certain New Certification Criteria

D. ONC-ACB Reporting Requirements

E. Continuation and Representation of Certified Status

1. 2011 or 2014 Edition EHR Certification Criteria Compliant

2. Updating a Certification

3. Representation of Meeting the Base EHR Definition

F. EHR Technology Price Transparency

G. Certification and Certification Criteria for Other Health Care Settings

V. Collection of Information Requirements

VI. Regulatory Impact Statement

A. Statement of Need

B. Overall Impact

1. Comment and Response

2. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis

a. Costs

i. Development and Preparation Costs for 2014 Edition EHR Certification Criteria

ii. Overall Development and Preparation Estimated Costs Over a 3-Year Period

iii. Costs for Reporting Test Results Hyperlinks

b. Benefits

3. Regulatory Flexibility Act Analysis

4. Executive Order 13132—Federalism

5. Unfunded Mandates Reform Act of 1995

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

The HIT Standards Committee (HITSC) issued recommendations for standards, implementation specifications, and certification criteria to the National Coordinator for Health Information Technology (the National Coordinator) on September 28, 2011 and October 21, 2011. In fulfilling his duties under sections 3001(c)(1)(A) and (B) of the Public Health Service Act (PHSA), the National Coordinator reviewed the recommendations made by the HITSC, endorsed certain standards, implementation specifications, and certification criteria, and reported his determinations to the Secretary for consideration. On March 7, 2012, the Secretary published a proposed rule (77 FR 13832) with her determinations regarding the standards, implementation specifications, and certification criteria endorsed by the National Coordinator, as required by section 3004(a)(3) of the PHSA. The proposed rule solicited public comment on the standards, implementation specifications, and certification criteria the Secretary proposed for adoption.

This final rule addresses comments received on the proposed rule and specifies the adoption by the Secretary, under sections 3004(a)(3) and 3004(b)(3) of the PHSA, of the standards, implementation specifications, and certification criteria that will establish the technical capabilities that electronic health record (EHR) technology must include to be certified. EHR technology certified to these standards, implementation specifications, and certification criteria makes it possible for eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) to adopt Certified EHR Technology (CEHRT) and subsequently attempt to demonstrate its meaningful use (MU) under the Medicare and Medicaid EHR Incentive Programs (the “EHR Incentive Programs”).

Consistent with Executive Order 13563, we have undertaken a retrospective review of our regulations. The final rule establishes multiple means for reducing regulatory burden and increasing regulatory flexibility for stakeholders, including changes to current regulatory requirements and approaches.

B. Summary of Major Provisions

1. Overview of the 2014 Edition EHR Certification Criteria

We have adopted certification criteria that will support the changes to the EHR Incentive Programs, including the new and revised objectives and measures for Stages 1 and 2 of MU finalized by CMS. The adopted certification criteria also enhance care coordination, patient engagement, and the security, safety, and efficacy of EHR technology. We refer to the adopted certification criteria as the 2014 Edition EHR certification criteria and the certification criteria previously adopted through rulemaking (75 FR 2014, 75 FR 44590) as the 2011 Edition EHR certification criteria. To permit efficient certification methods and reduce regulatory burden, we have identified those certification criteria that we have adopted as part of the 2014 Edition EHR certification criteria that include unchanged capabilities that were also included in the 2011 Edition EHR certification criteria. For EHR technology previously certified to the 2011 Edition EHR certification criteria, this will permit, where applicable, the use of prior test results for certification to the 2014 Edition EHR certification criteria (see the discussion of “gap certification” in section III.A.12 of this preamble).

2. Certified EHR Technology

Since the publication of the Standards and Certification Criteria final rule in July 2010, 75 FR 44590 (July 28, 2010) (the “S&CC July 2010 final rule”), HHS received significant feedback from stakeholders which suggested that we change our CEHRT policy (and definition) to one that would provide EPs, EHs, and CAHs the flexibility to have only the EHR technology they need to demonstrate MU. Consistent with stakeholder feedback and recommendations received from the HITSC, we proposed to revise the CEHRT definition to offer the requested flexibility. Based on comments received, we have finalized a CEHRT definition that provides even more flexibility for EPs, EHs, and CAHs than we originally proposed. In order to have EHR technology that meets the CEHRT definition for FY and CY 2014 and subsequent years, EPs, EHs, and CAHs must have EHR technology certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition (EHR technology that includes fundamental capabilities all providers would need to have) as well as the additional EHR technology certified to the 2014 Edition EHR certification criteria necessary to meet the MU objectives and measures for the stage of MU that they seek to meet and to capture, calculate, and electronically submit clinical quality measures. In addition, this final rule permits EPs, EHs, and CAHs to adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use it in their attempts to achieve MU prior to FY/CY 2014. We further discuss the new dynamic CEHRT definition, including the Base EHR definition in section III.B (“Redefining Certified EHR Technology and Related Terms”).

We note that we continue to permit only two types of EHR technology, Complete EHRs and EHR Modules, to be certified to meet these definitions under the “ONC HIT Certification Program.” A Complete EHR requires EHR technology to meet, at a minimum, all the mandatory certification criteria for either the ambulatory or inpatient setting, while an EHR Module can be any EHR technology certified to one less than all the mandatory certification criteria for either the ambulatory or inpatient setting (as noted, it would be a Complete EHR if it was certified to all the mandatory certification criteria for a setting). A Complete EHR, by definition, would meet the Base EHR definition and could be used to meet the CEHRT definition, but we note that an EP may need EHR technology certified to the optional “cancer registries” certification criteria to support their attempt to achieve MU. A single EHR Module could also be developed to meet the Base EHR definition and CEHRT definition for an EP, EH, or CAH. Additionally, an EP, EH, or CAH could use multiple certified EHR Modules or a certified EHR Module(s) in conjunction with a certified Complete EHR to meet the Base EHR definition and CEHRT definition.

3. ONC HIT Certification Program

This final rule revises the permanent certification program in ways that increase regulatory clarity and transparency, reduce regulatory burden, and add flexibility for the health information technology (HIT) community. One of these revisions includes changing the permanent certification program title to the “ONC HIT Certification Program,” which provides clearer attribution to the agency responsible for the program and an appropriate description of the program's scope, covering both current and potential future activities. The final rule also revises the process for permitting the use of newer versions of “minimum standard” code sets. The new approach is expected to reduce regulatory complexity and burden by providing the industry with the flexibility to utilize newer versions of adopted “minimum standard” code sets in a timelier manner.

The final rule modifies the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) will need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria. It also reduces regulatory burden by eliminating the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria. Instead, the privacy and security capabilities are included in the Base EHR definition that every EP, EH, and CAH must meet as part of meeting the CEHRT definition.

To increase clarity for purchasers in the HIT market, we have established methods for representing certified Complete EHRs and certified EHR Modules, including when Complete EHRs and EHR Modules meet the Base EHR definition. We also require that test results used for EHR technology certification be made publicly available in an effort to increase transparency and provide EPs, EHs, and CAHs a potential starting point from which to assess any implementation issues associated with certified Complete EHRs and certified EHR Modules. Finally, as another means of increasing transparency and mitigating any potential confusion in the market, we require that ONC-ACBs ensure that EHR technology developers include in their marketing materials and communications notification to potential purchasers any additional types of costs that an EP, EH, or CAH would pay to implement their certified Complete EHR or certified EHR Module in order to attempt to meet MU objectives and measures.

C. Costs and Benefits

We determined that this final rule is not an economically significant rule as its overall costs will be less than $100 million in any one year. We have, however, estimated the costs and benefits of the final rule. The final rule does not account for the estimated costs that EPs, EHs, and CAHs will incur in adopting and implementing certified Complete EHRs and certified EHR Modules. Those costs are estimated in the CMS Medicare and Medicaid EHR Incentive Programs Stage 2 final rule (Stage 2 final rule) published elsewhere in this issue of the Federal Register. The estimated costs expected to be incurred by EHR technology developers to develop and prepare EHR technology (i.e., Complete EHRs and EHR Modules) to be tested and certified in accordance with the 2014 Edition EHR certification criteria are represented in monetary terms in Table 1 below. We believe that there will be market pressures to have certified Complete EHRs and certified EHR Modules ready and available prior to when EPs, EHs, and CAHs must meet the revised CEHRT definition for FY/CY 2014, particularly with the option provided by this final rule for EPs, EHs, and CAHs to adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use it in their attempts to achieve MU in FY/CY 2013. Due to these market pressures, we believe that most of the estimated costs for developing EHR technology to meet the 2014 Edition EHR certification criteria will be incurred during the remainder of 2012 and throughout 2013, rather than in 2014. As a result, as represented in Table 1, the estimated costs attributable to this final rule are distributed as follows: 45% for 2012, 45% for 2013, and 10% for 2014. The dollar amounts expressed in Table 1 are expressed in 2012 dollars.

There are multiple potential benefits that stem from the 2014 Edition EHR certification criteria. Foremost, the 2014 Edition EHR certification criteria promote enhanced interoperability, functionality, utility, and security of EHR technology through the capabilities they include and the standards they require EHR technology to meet for certification. EHR technology certified to the 2014 Edition EHR certification criteria also will be capable of supporting EPs, EHs, and CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The revised CEHRT definition, the availability of gap certification, and the revisions to the ONC HIT Certification Program, will, as noted, increase regulatory clarity, improve transparency, and add flexibility, while also reducing the regulatory burden on the HIT industry. Last, the provisions of this final rule are supportive of other initiatives, such as the Partnership for Patients, Medicare Shared Savings Program, and other quality measure programs administered by CMS.

II. Background

A. Statutory Basis

The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the PHSA and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of HIT and electronic health information exchange.

1. Standards, Implementation Specifications, and Certification Criteria

With the passage of the HITECH Act, two new Federal advisory committees were established, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC) (sections 3002 and 3003 of the PHSA, respectively). Each is responsible for advising the National Coordinator on different aspects of standards, implementation specifications, and certification criteria. The HITPC is responsible for, among other duties, recommending priorities for the development, harmonization, and recognition of standards, implementation specifications, and certification criteria. The HITPC also considers and provides recommendations to ONC and CMS on meaningful use (MU) policy under the EHR Incentive Programs. The HITSC is responsible for recommending standards, implementation specifications, and certification criteria for adoption by the Secretary under section 3004 of the PHSA consistent with the ONC-coordinated Federal Health IT Strategic Plan.

Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant Federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register.

Section 3004(b)(3) of the PHSA titled “Subsequent Standards Activity” provides that the “Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent” with the schedule published by the HITSC. We consider this provision in the broader context of the HITECH Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITSC and endorsed by the National Coordinator, as well as other appropriate and necessary HIT standards, implementation specifications, and certification criteria. Throughout this process, the Secretary intends to continue to seek the insights and recommendations of the HITSC.

2. HIT Certification Programs

Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of HIT. Specifically, section 3001(c)(5)(A) specifies that the “National Coordinator, in consultation with the Director of the National Institute of Standards and Technology, shall keep or recognize a program or programs for the voluntary certification of health information technology as being in compliance with applicable certification criteria adopted under this subtitle” (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA). The certification program(s) must also “include, as appropriate, testing of the technology in accordance with section 13201(b) of the [HITECH] Act.”

Section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of the National Institute of Standards and Technology (NIST), in coordination with the HITSC, “shall support the establishment of a conformance testing infrastructure, including the development of technical test beds.” The HITECH Act also indicates that “[t]he development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing.”

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

The Secretary issued an interim final rule with request for comments titled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014, Jan. 13, 2010) (the “S&CC January 2010 interim final rule”), which adopted an initial set of standards, implementation specifications, and certification criteria. After consideration of the public comments received on the S&CC January 2010 interim final rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for MU Stage 1. Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule, 75 FR 44590 (July 28, 2010). On October 13, 2010, an interim final rule with a request for comment was issued to remove certain implementation specifications related to public health surveillance that had been previously adopted in the S&CC July 2010 final rule (75 FR 62686).

The standards, implementation specifications, and certification criteria adopted by the Secretary in the S&CC July 2010 final rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs under the Medicare and Medicaid EHR Incentive Programs Stage 1 final rule (the “Stage 1 final rule”) (see 75 FR 44314 for more information about MU and the Stage 1 requirements).

On March 7, 2012, ONC published a proposed rule (“the Proposed Rule”) (77 FR 13832) in the Federal Register that proposed new and revised certification criteria that would support the achievement of MU beginning with the EHR reporting periods in FY/CY 2014. These certification criteria are referred to as the 2014 Edition EHR certification criteria. The rule also proposed revisions to the CEHRT definition.

2. Medicare and Medicaid EHR Incentive Programs Rules

On January 13, 2010, CMS published the EHR Incentive Programs Stage 1 proposed rule (75 FR 1844). The rule proposed a definition for Stage 1 MU of CEHRT and regulations associated with the incentive payments made available under Division B, Title IV of the HITECH Act. Subsequently, CMS published a final rule (75 FR 44314) for the EHR Incentive Programs on July 28, 2010, simultaneously with the publication of the S&CC July 2010 final rule. The Stage 1 final rule established the objectives, associated measures, and other requirements that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 1.

On March 7, 2012, CMS published a proposed rule (77 FR 13698) in the Federal Register for MU Stage 2 that included proposed revisions to MU Stage 1 beginning with the EHR reporting periods in FY/CY 2013 (Stage 2 proposed rule).

3. HIT Certification Programs Rules

On March 10, 2010, ONC published a proposed rule (75 FR 11328) titled “Proposed Establishment of Certification Programs for Health Information Technology” (the “Certification Programs proposed rule”). The rule proposed both a temporary and permanent certification program for the purposes of testing and certifying HIT. It also specified the processes the National Coordinator would follow to authorize organizations to perform the certification of HIT. A final rule establishing the temporary certification program was published on June 24, 2010 (75 FR 36158) (the “Temporary Certification Program final rule”) and a final rule establishing the permanent certification program was published on January 7, 2011 (76 FR 1262) (“the Permanent Certification Program final rule”).

In the Proposed Rule mentioned above, ONC also proposed revisions to the permanent certification program, including changing the program's name to the ONC HIT Certification Program.

III. Provisions of the Final Rule Affecting Standards, Implementation Specifications, and Certification Criteria

To make a clear distinction between previously adopted certification criteria and the ones proposed for adoption in the Proposed Rule, we stated we would refer to and define the certification criteria adopted in the S&CC July 2010 final rule and included in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria.” We proposed to revise § 170.102 to add this definition.

Comments. Commenters expressed support for “editions” of certification criteria, particularly the use of “2011 Edition EHR certification criteria” for collectively referencing §§ 170.302, 170.304, and 170.306.

Response. We appreciate the expression of support and have revised § 170.102 to include the definition of 2011 Edition EHR certification criteria as proposed.

A. 2014 Edition EHR Certification Criteria

In the Proposed Rule, we proposed new, revised, and unchanged certification criteria that would establish the technical capabilities and specify the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of MU by EPs, EHs, and CAHs under the EHR Incentive Programs beginning with the EHR reporting periods in FY/CY 2014. We referred to these new, revised, and unchanged certification criteria as the “2014 Edition EHR certification criteria” and proposed to add this term and its definition to § 170.102. Additionally, we proposed to include all of the 2014 Edition EHR certification criteria in § 170.314 to set them apart and make it easier for stakeholders to quickly determine which certification criteria would be required beginning with the EHR reporting periods that start in FY/CY 2014.

Comments. Commenters expressed support for “editions” of certification criteria, particularly the use of “2014 Edition EHR certification criteria” to reference the certification criteria adopted in § 170.314. One commenter, however, did not agree with our approach to include all of the 2014 Edition EHR certification criteria in § 170.314. The commenter suggested that we should maintain the approach used for the 2011 Edition EHR certification criteria (i.e., to separate general, ambulatory, and inpatient certification criteria into three sections of the Code of Federal Regulations (CFR)).

Response. We appreciate the expression of support for our “editions” approach and have revised § 170.102 to include the definition of 2014 Edition EHR certification criteria as proposed. Use of “2014 Edition EHR certification criteria” coupled with our use of “2011 Edition EHR certification criteria” should eliminate any ambiguity and provide a clear distinction between the certification criteria that are part of the 2011 Edition EHR certification criteria and those in the 2014 Edition EHR certification criteria.

We believe by including all the 2014 Edition EHR certification criteria in one section of the CFR is a better approach than our previous approach of separating general, ambulatory, and inpatient certification criteria into three sections of the CFR. As noted in the Proposed Rule, the inclusion of all 2014 Edition EHR certification criteria in one regulatory section will simplify the regulatory framework for stakeholders.

1. Certification Criteria Relationship to MU

Many of the certification criteria that we proposed supported the MU objectives and measures proposed by CMS in the Stage 2 proposed rule as well as the reporting of MU objectives and measures and clinical quality measures (CQMs). To the extent CMS has changed (e.g., added, revised, or removed) the MU objectives, measures, or reporting requirements in its final rule, we have made appropriate changes to the associated certification criteria so that they continue to support the MU objectives, measures, and reporting requirements.

We received many comments on the 2014 Edition EHR certification criteria that were not within this rulemaking's scope. These comments focused on the MU objectives, measures, CQM measures, and reporting requirements. For responses to such comments, we direct readers to the Stage 2 final rule published elsewhere in this issue of the Federal Register.

We reiterate and emphasize for commenters to remember that certification is a floor not a ceiling. It does not specify an exhaustive set of capabilities that EHR technology must include. Rather, certification assesses a subset of capabilities (generally capabilities that support MU requirements) that may be part of the overall EHR technology that an EP, EH, or CAH adopts. In this regard, certification focuses on providing assurance to EPs, EHs, and CAHs that EHR technology certified to a certification criterion includes the specified capabilities, that those capabilities perform correctly and, where applicable, that those capabilities properly utilize/support adopted standards.

We discuss the new, revised, and unchanged certification criteria that we are adopting as the 2014 Edition EHR certification criteria in sections A.8 through A.10 below. We include a table at the beginning of the discussion of each certification criterion or criteria that specifies the MU objective that the 2014 Edition EHR certification criterion or criteria support. The objective cited is either a Stage 1 or Stage 2 objective that will be effective for the EHR reporting periods in FY/CY 2014. We provide this frame of reference because beginning in FY/CY 2014 EHR technology will need to be certified to the 2014 Edition EHR certification criteria to meet the CEHRT definition and the tables clearly associate the certification criterion or criteria with the MU objective it supports. The tables also specify the CFR location for each certification criterion adopted in § 170.314.

2. Applicability

Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. Section 170.300(a) establishes the applicability of the adopted certification criteria to the testing and certification of Complete EHRs and EHR Modules. Section 170.300(b) specifies that when a certification criterion refers to two or more standards as alternatives, the use of at least one of the alternative standards will be considered compliant. Section 170.300(c) specifies that Complete EHRs and EHR Modules are not required to be compliant with certification criteria that are designated as optional.

We proposed to revise § 170.300 to reflect our proposed regulatory structure for the 2014 Edition EHR certification criteria. We proposed to revise paragraph (c) to add that Complete EHRs and EHR Modules are also not required to be certified to specific capabilities within a certification criterion that are designated as optional. We also proposed to add a paragraph (d) that would clarify which certification criteria or specific capabilities within a certification criterion included in § 170.314 have general applicability (i.e., apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting.

Comments. Comments asked for clarification on how the optionality provided for capabilities within certification criteria would be clearly identified to purchasers of certified EHR technology.

Response. We expect that the certifications issued to EHR technology will clearly indicate whether the EHR technology was certified to any optional capability within a certification criterion or, for that matter, any optional certification criterion. The Certified HIT Product List (CHPL) will also indicate whether a certified Complete EHR or certified EHR Module was certified to an optional certification criterion or an optional specific capability within a certification criterion.

3. Scope of a Certification Criterion for Certification

In the Proposed Rule, based on our proposal to codify all the 2014 Edition EHR certification criteria in § 170.314, we clarified that certification to the certification criteria at § 170.314 would occur at the second paragraph level of the regulatory section. We noted that the first paragraph level in § 170.314 organizes the certification criteria into categories. These categories include: clinical (§ 170.314(a)); care coordination (§ 170.314(b)); clinical quality measures (§ 170.314(c)); privacy and security (§ 170.314(d)); patient engagement (§ 170.314(e)); public health (§ 170.314(f)); and utilization (§ 170.314(g)). Thus, we stated that a certification criterion in § 170.314 is at the second paragraph level and would encompass all of the specific capabilities in the paragraph levels below with, as noted in our discussion of “applicability,” an indication if the certification criterion or the specific capabilities within the criterion only apply to one setting (ambulatory or inpatient).

Comments. We received no comments on this clarification.

Response. Having adopted the 2014 Edition EHR certification criteria in § 170.314 as we proposed, our clarification remains accurate. Additionally, we offer further clarity with an illustration of this principle using the “demographics” certification criterion adopted at § 170.314(a)(3) (second paragraph level). The certification criterion includes two specific capabilities at (3)(i) and (ii) (third paragraph level): “(i)” enable a user to electronically record, change, and access patient demographic data including preferred language, gender, race, ethnicity, and date of birth (in accordance with the specified standards for race, ethnicity, and preferred language (§ 170.314(3)(i)(A) and (B)); and, “(ii)” for the inpatient setting only, enable a user to electronically record, change, and access preliminary cause of death in the event of mortality. Consequently, to meet the demographics certification criterion, for example, EHR technology designed for the inpatient setting would need to meet § 170.314(a)(3)(i)(A) and (B) and (ii), while EHR technology designed for the ambulatory setting would only need to meet (3)(i)(A) and (B) because the capability at (3)(ii) only applies to the inpatient setting.

4. Explanation and Revision of Terms Used in Certification Criteria

In the Proposed Rule, we noted that certain terms are repeatedly used in the proposed 2014 Edition EHR certification criteria. We stated that, based on our experience and stakeholder feedback related to how terms in the 2011 Edition EHR certification criteria have been interpreted, it was necessary in certain cases to select different terms. Therefore, we provided the following list of terms that are repeatedly used in the 2014 Edition EHR certification criteria and the intended meaning for each term.

“User” is used to mean a health care professional or his or her office staff or a software program or service that would interact directly with the CEHRT. This is essentially the same description that we gave to “user” in the S&CC July 2010 final rule (75 FR 44598). We clarified that, unless expressly stated otherwise, “user” does not mean a patient.

“Record” is used to mean the ability to capture and store information in EHR technology. We consider this meaning complementary to and consistent with related terms, namely “change and “access,” and their associated capabilities.

“Change” is used to mean the ability to alter or edit information previously recorded in EHR technology. We proposed to replace the term “modify” used in the 2011 Edition EHR certification criteria with “change.” Although we interpret both terms to have essentially the same meaning, we believe “change” connotes a more plain language meaning as recommended by plainlanguage.gov. In certification criteria in which this term is used, we stated that we do not intend for it to be interpreted to mean that information previously recorded would be able to be changed without the retention of prior value(s). Rather, a change must be retained as an audited event and in a viewable format that identifies the changed information in a patient's record (similar to how one might see changes represented in a word-processing application). How such changes are displayed is a design decision left to EHR technology developers.

“Access” is used to mean the ability to examine or review information in or through EHR technology. We proposed to replace the term “retrieve” used in the 2011 Edition EHR certification criteria with “access” because we believe it is clearer and more accurately expresses the capability we intend for EHR technology to include. We noted that some stakeholders had interpreted “retrieve” to suggest that the EHR technology also needed to be able to obtain data from external sources. Nevertheless, we stated that we interpret both “access” and “retrieve” to have essentially the same meaning, but note that “access” should not be interpreted to include necessarily the capability of obtaining or transferring the data from an external source.

“Incorporate” is used to mean to electronically import, attribute, associate, or link information in EHR technology. With the exception of import, we previously used these terms to describe the “incorporate” capability included in certification criteria as illustrated by the capability specified at § 170.302(h)(3). We proposed to revise its unique meaning for the 2014 Edition EHR certification criteria and the purposes of certification to account for the ability to electronically import information.

“Create” is used to mean to electronically produce or generate information. We proposed to replace the term “generate” used in the 2011 Edition EHR certification criteria with “create.” We stated that “create” is clearer and is a better word choice than generate from a plain language perspective.

“Transmit” is used to mean to send from one point to another.

Comments. Commenters expressed general support for our proposed replacement of terms in certification criteria with the proposed terms described above. A few commenters, however, expressed confusion about our description of “incorporate” as we described it and used it in different certification criteria such as the proposed “transitions of care-incorporate summary care record” certification criterion (§ 170.314(b)(1)) and the “incorporate laboratory tests and values/results” certification criterion (§ 170.314(b)(5)).

Response. We appreciate the support for the proposed term replacements and are replacing the terms as proposed, except for the term “incorporate.” We agree with commenters that our description of incorporate could create confusion based on the context in which we proposed to use it in different certification criteria. In consideration of comments received, we have revised our description of incorporation to reflect the common interpretation commenters stated they assigned to the term. Thus, when the term incorporate is used within a certification criterion it is intended to mean to electronically process structured information from another source such that it is combined (in structured form) with information maintained by EHR technology and is subsequently available for use within the EHR technology by a user. As part of the 2014 Edition EHR certification criteria, the “transitions of care” and “incorporate laboratory tests and values/results” certification criteria at § 170.314(b)(2) and (b)(5), respectively, reference this term in the context of a specific capability that would require EHR technology to be able to incorporate information.

Comments. Commenters expressed confusion about how to interpret our use of the phrase “included in one or any combination of the following” in certification criteria.

Response. To eliminate any potential confusion, we have revised the certification criteria containing this phrase to read “each one and at least one combination of the following data.” We use this phrase to mean that the capability for which certification is required must be able to individually address each of the data specified in the certification criterion and at least one combination of those data. “One combination” means a combination of two or more of the data listed in the certification criterion. For example, in the clinical decision support (CDS) certification criterion six categories of data are listed in paragraphs § 170.314 (a)(8)(i)(A) through (F). The certification criterion states “enable a limited set of identified users to select (i.e., activate) one or more electronic clinical decision support interventions … based on each one and at least one combination of the following data.” Thus, to meet this certification criterion EHR technology must be able to enable the selection of CDS interventions that would be separately applicable to the data listed in (A) through (F) and at least one combination of the data listed in (A) through (F), such as (A) and (D) (problems and demographics).

To provide further clarity for the 2014 Edition EHR certification criteria, we have revised a number of certification criteria to now begin with “EHR technology must be able to * * *” rather than “Enable a user to * * *.” We believe this approach more clearly communicates that the EHR technology must demonstrate the capability to be certified to the certification criterion. As one last point of clarification, we replaced “data element” references in certification criteria, where appropriate, with simply “data.” We believe this clarifies when we intend to mean data that includes types and elements. We also believe this will prevent confusion when the reference point is solely a “data element.”

Comments. Commenters asked how terms used in MU objectives and measures are defined for the purposes of the 2014 Edition EHR certification criteria, such as “electronic notes,” “images,” “care plan,” and “care team.”

Response. We incorporate in our certification criteria the terms used in MU objectives and measures as they are defined or described in the Stage 2 final rule.

5. Consensus-Based Standards

Comments. Commenters stated that for interoperability to be successful, it was essential that standards be created through collaborative, consensus-based processes that take into consideration the needs and concerns of all interested stakeholders. Response. Federal agencies are required under the National Technology Transfer and Advancement Act of 1995 (NTTAA) (15 U.S.C. § 3701 et seq.) and OMB Circular A-119 to use, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. Both the NTTAA and OMB Circular A-119 provide for certain exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. In this final rule, we have adopted or refer to voluntary consensus standards, except for the following government-unique standards: the Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity; the three transport standards adopted in § 170.202; the standard that identifies the data elements referenced by clinical quality measures (adopted at § 170.204(c)); and certain standards related to the protection of electronic health information adopted in § 170.210. We are aware of no voluntary consensus standards that would serve as alternatives to these standards for the purposes that we have identified.

Comments. A commenter suggested that we incorporate the HL7 EHR System Functional Model (ISO/HL7 10781 standard) into certification. The commenter noted that is a long-standing international consensus standard for EHR System functionality and that Release 2 of this standard is currently in ballot by the International Standards Organization Technical Committee 215 on Health Informatics (ISO TC215), the Committee for European Normalization Technical Committee 251 (CEN TC251), the International Health Terminology Standards Development Organisation (IHTSDO), the Clinical Data Interchange Standards Consortium (CDISC) and Health Level Seven (HL7). The commenter suggested that “linking” the function and conformance criteria of the internationally-recognized ISO/HL7 10781 standard to the 2014 Edition EHR certification criteria for the purposes of certification would make EHR technology certified under the ONC HIT Certification Program more competitive in international markets.

Response. It is our understanding that the HL7 EHR System Functional Model provides a comprehensive set of EHR system functional requirements that in many cases goes beyond the scope of the capabilities required by the 2014 Edition EHR certification criteria. As such, this comment is outside the scope of this current rulemaking. However, we strongly support methods that could be used to increase international interoperability and acceptance of EHR technology certified under the ONC HIT Certification Program. Accordingly, we intend to explore and request that the HITPC and HITSC consider the applicability and usefulness of the HL7 EHR System Functional Model as a basis for future recommendations on certification criteria.

6. Adopting Versions of Standards

Comments. We received comments recommending that we adopt standards at a higher level of abstraction and that we should not be overly prescriptive about the exact version and release of vocabulary and messaging protocols. That is, that we should not adopt a particular version of a content exchange standard for which certification would be required, (e.g., HL7 2.x, where “x” could be any version within the version 2 family) and accompany the adopted standards with detailed implementation specifications or guidance outside of rulemaking.

Response. While the commenters' recommendation may provide added flexibility, we are unable to accept the recommendation for multiple reasons. First, it has the potential to create interoperability challenges. Second, there are processes under the Administrative Procedure Act that must be followed for the adoption of substantive requirements. Third, in accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow for this final rule, the publications we reference are “limited to the edition of the publication that is approved” and do not include “[f]uture amendments or revisions of the publication.” Consequently, we do not include regulatory language that refers, for instance, to “Version 1.X” when “X” remains a variable.

We note, however, that we have taken two steps for certain vocabulary standards designated as minimum standards code sets. First, in this final rule we have adopted updated versions of four vocabulary standards that we proposed for certification in the Proposed Rule. We proposed the use of the January 2012 International Release of SNOMED CT®, but have adopted the July 2012 International Release of SNOMED CT® as well as the March 2012 U.S. Extension to SNOMED CT®. We proposed the use of version 2.38 of LOINC®, but have adopted version 2.40. We proposed the use of the February 2012 monthly version of RxNorm, but have adopted the August 2012 monthly version of RxNorm. We proposed the use of the August 15, 2011 version of CVX code sets, but have adopted the updated through July 11, 2012 version. In all these instances, we have found that the newer versions improve interoperability and EHR technology implementation, support MU, and do not create additional substantive requirements in comparison to the proposed versions of these vocabulary standards. Further, the adoption of these versions establishes the baseline in the CFR with the most recent versions of these vocabulary standards that is possible. Second, we have also established an approach that permits the use of newer versions of these standards than the one adopted in the CFR. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets.

7. Display of Vocabulary Standards

Comments. Several commenters asked a similarly themed question with respect to the vocabulary standards we proposed to adopt. The question centered on whether EHR technology was required to display a particular vocabulary to a user (for the certification criteria that require recording certain patient information in a vocabulary standard) in order to be certified. Commenters explained that for the problem list certification criterion that SNOMED CT® codes should not be required for display in EHR technology and that an organization should be able to use whichever code set they prefer to display. Others provided similar rationale and said that health care providers are typically unfamiliar with SNOMED CT®. Commenters raised similar questions regarding the display of race and ethnicity as well as smoking status.

Response. We agree with commenters and want to make clear that EHR technology does not have to display an adopted vocabulary to a user to be certified to the certification criterion that includes the vocabulary standard. For a more detailed discussion and example of our intent please review our responses to the problem list certification criterion.

8. Common Data in Certification Criteria

Comments. Several commenters pointed out that we repeat much of the same data in the “view, download, and transmit to a 3rd party,” “clinical summaries,” and both “transitions of care” certification criteria. These commenters suggested that we specify a single definition that included this common data and then reference that definition in the applicable certification criteria. They added that this would cut down on the repetitiveness of the certification criteria, make the certification criteria smaller and, thus, easier to read, and that this approach would be more efficient overall. Commenters recommended that we define a “Summary Care Record.”

Response. We agree with commenters' suggestions. Further, we note that the data we reference in these certification criteria mirror those specified by CMS for the objectives and measures to which these certification criteria correlate. Because there is a common set of MU data types/elements for which certification would be required across several certification criteria, we have created the term “Common MU Data Set.” We define this term by only the data that is common to (i.e., included in all five certification criteria) the “view, download, and transmit to a 3rd party,” “clinical summary,” “transitions of care—receive, display, and incorporate transition of care/referral summaries,” “transitions of care—create and transmit transition of care/referral summaries,” and “data portability” certification criteria (see Table 2 below). We decline to create a specific definition for “summary care record” because the Common MU Data Set definition serves multiple certification criteria that reference different “summary” oriented documents. For instance, data referenced in the “clinical summary” shares the data in the Common MU Data Set with the “transitions of care” certification criteria, but also includes unique data that is specific to a clinical summary. The following data are included in the Common MU Data Set definition and where applicable reference the standard that would have otherwise been assigned if the data were individually included within the certification criteria.

We also believe that further clarity for stakeholders can be provided through the use of more specific descriptions for the different types of “data summaries” referenced in certification criteria. These specific descriptions are listed below and are used in the applicable certification criteria and referenced in the preamble discussions of the certification criteria. This revision is intended to make the data referenced in the final rule and the “data summary” to which it is assigned more readily apparent to readers. We note that the use of these specific descriptions in the certification criteria are for regulatory clarity purposes only and do not imply any additional meaning.

9. New Certification Criteria

In the Proposed Rule, we described certification criteria that we considered “new.” We noted the following factors that we would consider when determining whether a certification criterion is “new”:

• The certification criterion only specifies capabilities that have never been included in previously adopted certification criteria; or
• The certification criterion was previously adopted as “mandatory” for a particular setting and subsequently adopted as “mandatory” or “optional” for a different setting.

Comments. We did not receive comments questioning our description of new certification criteria.

Response. We therefore continue to use this description of new certification criteria to categorize the following certification criteria we have adopted as part of the 2014 Edition EHR certification criteria. The adopted new certification criteria include those certification criteria that we explicitly proposed in the Proposed Rule and two additional certification criteria stemming from proposals related to quality management principles for EHR technology development and data portability for which we solicited comments. We have not adopted the proposed “non-percentage-based measure use report” certification criterion.

a. Ambulatory and Inpatient Setting

We have adopted 9 new certification criteria that will be applicable to both the ambulatory and inpatient settings. We also discuss the proposed “non-percentage-based measure use report” certification criterion but, as noted above, we have not adopted it as part of the 2014 Edition EHR certification criteria.

• Electronic Notes

We proposed a certification criterion that was similar to the one recommended by the HITSC to support the MU objective and measure recommended by the HITPC. CMS did not specifically propose the HITPC recommended MU objective and measure for Stage 2, but requested public comment on whether the objective and measure should be incorporated into MU Stage 2.

We proposed to replace the terms “modify” and “retrieve” in the recommended criterion with “change” and “access,” respectively. We proposed that “search” in the certification criterion was intended to mean the ability to search free text and data fields of electronic notes. We further proposed that the ability to search would mean the ability to search the notes that any licensed health care professional has included within the EHR technology and the ability to search for information across separate notes rather than just within notes.

Comments. Many commenters stated that we should not adopt an electronic notes certification criterion without CMS establishing a corresponding MU objective and measure. Commenters requested that we define a note for qualifying in the numerator and clarify who could create, edit, and sign a note. Commenters suggested permitting a range of options for capturing notes, such as templates and free text. A few commenters suggested that electronic notes should be recorded in structured data. These commenters thought this would help avoid illegible scanned notes or make searching more efficient and useful (e.g., searching be defined attributes such as physician name). One commenter suggested structured data fields that include: symptomatic (subjective); objective; assessment; and plan. The same commenter suggested specific note structure for patient problem lists.

Commenters expressed general support for the search functionality. They stated that the ability to search notes for relevant keywords will reduce time spent reviewing documentation that is irrelevant to the patient's current medical condition(s). Commenters, however, asked for further clarification on the extent of the search capability EHR technology needed to have in order to meet this certification criterion. Commenters expressed concern that this certification criterion would require a capability to search across notes, especially across providers and patients' charts. Multiple commenters suggested that a reasonable requirement for certification would be to require the capability to search for a free-text string within a particular open note, while other search capabilities should be left as competitive differentiators within the marketplace. These commenters noted that more specific certification requirements could interrupt innovative ways to do effective chart search and information display. Conversely, other commenters suggested requiring additional search functionality, such as searching across notes based on date ranges or indexing of notes in much the same way today's common search engines create background indexes allowing for almost instant retrieval of documents (e.g., Google, Spotlight on the Mac or “locate” on Unix-based machines).

Commenters stated that some providers will find it particularly challenging and burdensome to directly document their notes into EHRs. For example, some EPs would need to have their notes dictated or transcribed. Commenters stated that many hospitals scan physician paper notes into EHR technology, particularly in the small hospital setting where the EPs are not normally employed by the hospital.

A commenter suggested that the capabilities included in this certification criterion be expanded to require EHR technology to be able to export electronic notes as CDA Level 2 documents. The commenter stated that this would require the electronic notes to be wrapped with a CDA document header and to identify the document type and section headings with LOINC® codes. The commenter stated that this would not be an onerous requirement because most commercial transcription services can already meet these requirements. The commenter further stated that this requirement would provide hundreds of millions of interoperable clinical documents per year and enrich the clinical content shared during care transitions.

Response. We have adopted an “electronic notes” certification criterion for the 2014 Edition EHR certification criteria at § 170.314(a)(9) as proposed. After consideration of public comments, CMS has included an “electronic notes” objective and measure in the MU Stage 2 menu set and the adoption of this certification criterion will support that objective and measure. We direct commenters to the Stage 2 final rule for further discussion of the “electronic notes” objective and measure, including description of notes that qualify for the numerator and explanation of who can create, edit, and sign a note.

We did not propose, nor do we believe, that there is a standard and industry-wide accepted format for capturing electronic notes. Therefore, we agree with the commenters that suggested that a range of options be permitted for capturing notes, including templates and free text. We also note that in the Stage 2 final rule scanned notes that are text searchable are acceptable for inclusion in the numerator. This requirement should address the commenters' concern about illegible scanned notes.

We appreciate the support expressed for the search capability included in this certification criterion. After consideration of comments, we have concluded that the search capability that EHR technology must demonstrate to meet this certification criterion should be limited to the ability to search within a note. We believe this will provide EPs, EHs, and CAHs with a search capability that will be useful, but still permit EHR technology developers to design and develop search capabilities that meet specific customer needs. Additionally, as commenters noted, this will permit the market to innovate and offer various search capabilities for EPs, EHs, and CAHs.

While we appreciate the commenter's suggestion that the capabilities included in this certification criterion be expanded to require EHR technology to be able to export electronic notes as CDA Level 2 documents, we decline to require EHR technology to demonstrate this capability as a condition of certification since such a capability would go beyond what we believe it is necessary to require for certification in support of MU.

• Image Results

We proposed to adopt a new “imaging” certification criterion as part of the 2014 Edition EHR certification criteria to support an EP's, EH's, and CAH's performance of the proposed new MU objective and measure. In the Proposed Rule, we clarified that the phrase “immediate electronic access” was intended to mean that a user should be able to electronically access images and their narrative interpretations directly and without, for example, having to log in to a separate electronic system or repository. We stated that this access could be provided by multiple means, including, but not limited to, “single sign-on” and “secure identity parameter passing.” We also considered the Digital Imaging and Communications in Medicine (DICOM) standard for this certification criterion, but concluded that the adoption of this or other standards was not necessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion.

We have categorized and responded to comments under subheadings for the purposes of clarity and readability.

Types of Images

Comments. Commenters requested a clear definition of “image” as well as “narrative interpretation.” Commenters asked whether both cardiology and pathology images are included or whether images were limited to radiology. A few commenters specifically suggested that images be limited to radiology and MRIs and not include photography or electrocardiograms (ECGs). One commenter suggested the inclusion of ECGs.

Response. It is outside the scope of this rulemaking to define the scope of images and narrative interpretations. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and responses to these comments.

Internal and External and Storage of Images

Comments. Commenters stated that the requirement to display diagnostic images is ideal; however, the infrastructure to display images from all possible modalities, along with all possible technology solutions within the ambulatory setting, would require huge numbers of costly interfaces to integrate the images into the EHR technology. Commenters further stated that clinical images are often large and stored on external PACS systems. As such, these commenters contended that requiring EHR technology to duplicate image storage and perform at the level of a PACS system would be difficult and unnecessary functionality for EHR technology. Some commenters stated that EHR systems should not be required to store images, since the use of reference pointers is enabled by DICOM Web Access to DICOM Persistent Objects (WADO) standards. Commenters stated that the incorporation of scanned images into EHRs is generally ineffective at improving patient care. These commenters stated that when images are scanned into EHRs, physicians cannot manipulate the data, which may prevent them from truly seeing the images or understanding what the images represent. A few other commenters stated that the storing of images by any means to facilitate access will be costly.

Commenters recommended that the certification capability be limited to directly linking to images stored in the EHR technology or providing a context-sensitive link to an external application, which provides access to images and their associated narrative. Other commenters asserted that current EHR technology does not track whether a PACS link is “available” or “clicked on” because the user interaction happens largely with the Web-based PACS application. These commenters believed that there might be barriers to EHR technology collecting information about the availability of third party data accessible via a Web link within the EHR to sufficiently meet this requirement. A few commenters suggested that we limit the capability to provide narrative interpretations and recommended that the ability to view images within or through EHR technology be optional.

Response. We have adopted a new “image results” certification criterion to support the new MU objective and measure. We clarify that we did not propose nor are we requiring that EHR technology has to be able to store images to meet this certification criterion. EHR technology can meet this certification criterion by demonstrating a capability to directly link to images stored in the EHR system or providing a context-sensitive link to an external application which provides access to images and their associated narrative. By “context sensitive link” we mean that the link to the image will ideally include parameters that enable access to the images themselves rather than access to a system—which would require login, patient search, image selection, and (finally) image viewing. However, we agree with commenters that there is insufficient penetration of single sign-on or services-oriented integration capabilities between EHR technology and PACS systems, and that the fluidity with which this access is enabled may not be under the CEHRT's control. We therefore do not explicitly require that this link provide “immediate access” as described below. Finally, we emphasize that access to both narrative and imaging data must available to the user. In cases where there is no narrative data (for example when a radiographic image has not yet been interpreted by a radiologist) there will obviously be no narrative available. Nonetheless, the EHR technology must be capable of retrieving and displaying the narrative information in order to meet this certification criterion.

Comments. A commenter requested clarification on whether the proposed certification criterion pertains only to EPs who send x-rays outside of their facility or whether providers that take x-rays in their own offices required to meet this certification criterion.

Response. This certification criterion applies to EHR technology designed for both the ambulatory and inpatient setting and expresses the capabilities that EHR technology would need to include in order to be certified to this certification criterion.

Clarification of Certification Criterion Text

Comments. A few commenters asked for clarification of “and/or” and whether it implies optionality regarding either images or the corresponding narratives. Alternatively, the commenters asked if it means that the EHR technology must be certified for both availability of images and narrative interpretations. Other commenters asked whether the intent of “electronically indicated to a user the availability of a patient's images” was to identify imaging results as available in order to circumvent redundant imaging tests. If that is the intent, the commenter recommend that we require, at minimum that information on when the imaging test was completed, results pending, results location and date of completion be provided. Similarly, a commenter requested clarification of whether a “list” of past imaging tests completed would helpful.

Response. For clarity, we have removed the “or” from the “and/or” in the regulation text. EHR technology must be capable of electronically indicating the availability of both images and narrative interpretations. Redundant imaging tests can lead to unnecessary costs. We believe that the capabilities included in this certification criterion can assist in preventing redundant testing. This certification criterion, however, includes those capabilities that are necessary to support an EP, EH, or CAH's attempt to achieve the associated MU objective and measure. Therefore, we decline to include the additional capabilities recommended by the commenters.

Immediate Electronic Access

Comments. Some commenters expressly supported our proposal that users should have “immediate electronic access” to images and their narrative interpretations directly and without having to login to a separate electronic system. Many commenters stated that the requirements for “immediacy” go beyond the capabilities of the EHR system. Some commenters suggested the term “immediate” be removed from the certification criterion. Other commenters requested clarification of what immediate electronic access entailed. A commenter stated that there appeared to be two different functions coupled with the word “immediate”—taking the image and getting access to the image. Commenters also specifically stated that the requirements for “immediacy” via additional sign-on capabilities and other system requirements are beyond the control of the EHR system and, thus, should not be required for certification. One commenter suggested that, in order to ensure immediate access, EHR technology should provide stream-capable hyperlinks to images that can be viewed in a typical web browser without the delay related to use of DICOM file transfer and without the requirement to install additional software beyond the standard web browser itself.

Response. We agree with commenters that “immediate” access is vague and would be difficult to implement in EHR technology at this time, particularly with methods such as single sign-on. Therefore, we are removing the term “immediate” from the certification criterion.

Applicable Standard

Comments. Some commenters suggested that no standard be adopted for this certification criterion. Conversely, some commenters recommended the inclusion of the DICOM standard as a requirement for EHR certification, as well as certification of DICOM compliance for the storage and transmission of images. Commenters reasoned that the DICOM standards and complementary implementation guides developed by Integrating the Healthcare Enterprise® (IHE) provide satisfactory methods for the formatting of medical imaging and for their access through EHR systems. Some commenters specifically recommended that DICOM Supplement 127: CT Radiation Dose Reporting (Dose SR) should be required for the transmission of patient radiation dose information.

Some commenters suggest that we adopt the Consolidated CDA Diagnostic Imaging Report standard and the DICOM image standard for exchanging images and their interpretations. A few commenters recommended that we at least communicate that we intend to move towards requiring this standard to complement the DICOM image standard for use in exchanging images and their interpretations.

Response. We appreciate commenters' recommendations regarding the DICOM standard, but the recommendations and information provided has not altered our position expressed in the Proposed Rule nor has CMS made revisions to the associated MU objective and measure that would alter our position. As stated in the Proposed Rule, we concluded that the adoption of the DICOM standard (or any other standards) was unnecessary to enable users with electronic access to images and their narrative interpretations, the capability required by this certification criterion and for MU.

• Family Health History

We proposed to adopt at § 170.314(a)(13) a 2014 Edition EHR certification criterion for family health history. The proposed certification criterion required that EHR technology be able to, at minimum, electronically record, change, and access the health history of a patient's first-degree relatives. The Proposed Rule also solicited comment on whether we should adopt specific standards for this certification criterion, including the HL7 Pedigree standard and the use of Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT®) terms for familial conditions. We also noted that the Surgeon General had produced a tool that can capture, save, and manage family health histories using standard vocabularies and can export the data in eXtensible Markup Language (XML) format and sought comments on the maturity and breadth of adoption of this tool and its export format.

Comments. Commenters generally supported the concept of including a certification criterion related to family health history. A commenter noted that our description of the capabilities in this certification criterion was somewhat ambiguous and thus requested confirmation that we did not mean to imply that this criterion requires the capability to access the patient's first degree relatives' records. Many commenters expressed that the HL7 Pedigree standard was not widely used or sufficiently mature to adopt at the present time. Similarly, many commenters also expressed that if a specific terminology is required for coding familial conditions, then SNOMED CT® would be an appropriate terminology. Commenters requested that the certification criterion permit unstructured/free text entry.

Response. We appreciate commenters' general support for this certification criterion. Equally, CMS received a great deal of support and has included a family health history objective in the MU Stage 2 menu set. Accordingly, we have finalized a certification criterion for family health history.

We clarify that this certification criterion requires EHR technology to demonstrate that it is capable of enabling a user to electronically record, change, and access a patient's family health history. This means that EHR technology must, at minimum, be capable of recording information about a patient's first degree relative in the patient's record and permitting a user to change and access that information as needed. EHR technology would not need to be able to access the records of a patient's first degree relatives.

In support of MU, this certification criterion requires that EHR technology be capable of capturing family health history in structured data. Therefore, the certification criterion we have adopted does not permit unstructured/free text for certification because such entries would not constitute MU of CEHRT. Similar to commenters, we believe that SNOMED CT® is an appropriate terminology, and perhaps the best intermediate step, for coding family health history in structured data if one was not to use the HL7 Pedigree standard. We also understand that some organizations have built family health history CDS interventions using SNOMED CT®.

The HL7 Pedigree standard was originally released in 2007. Release 1 was recently reaffirmed by the American National Standards Institute (ANSI), which is a process that occurs every five years. We have adopted this reaffirmed version as it is the same version (Release 1) of the standard as the version we proposed. An implementation guide for this standard is scheduled to be published shortly after this final rule. Although EHR technology will not be required to conform to the implementation guide for certification, the implementation guide will provide important guidance for use of the HL7 Pedigree standard with EHR technology.

We have finalized that EHR technology may meet this certification criterion by either being able to capture a patient's family health history in SNOMED CT® or in the HL7 Pedigree standard. Since the use of SNOMED CT® is required for meeting several other certification criteria, we do not believe that it will be a challenge to meet this certification criterion. We emphasize, as specified in the § 170.300(b), when “a certification criterion refers to two or more standards as alternatives, use of at least one of the alternative standards will be considered compliant.” Thus, an EHR technology can demonstrate use of SNOMED CT® or the HL7 Pedigree standard to meet this certification criterion.

• Amendments

We proposed to adopt a new “amendments” certification criterion (§ 170.314(d)(4)) as part of the 2014 Edition EHR certification criteria. We made this proposal based on HITPC and HITSC recommendations which included that a certification criterion should be adopted that provides some of the basic technical tools to support compliance with the HIPAA Privacy Rule. We noted in the Proposed Rule that the proposed certification criterion does not address all of the requirements specified at 45 CFR 164.526 and that EHR technology certification is not a substitute for, or guarantee of, HIPAA Privacy Rule compliance. Finally, we requested comment on whether EHR technology should be required to be capable of appending patient supplied information in both free text and scanned format or only one or these methods to be certified to this proposed certification criteria.

Comments. Many commenters recommended that the proposed certification criterion's reference to “free text or scanned” patient supplied information be revised. Many supported both and suggested that both be permitted. Others contended that the certification criterion was over specified and suggested that ONC not specify one or the other because patient-supplied information could take many forms. In general, commenters suggested that EHR technologies have different ways of appending information and that either of these methods would be sufficient for certification. Another commenter noted that scanning patient amendments could be problematic from a storage perspective. One commenter agreed with the certification criterion but recommended that ONC should have robust standards for how patient information is appended to EHR technology before allowing EHR technology developers to create multiple versions of this workflow. Yet another stated that the ability to append patient supplied information should be no different from the ability to append any other ancillary information (outside reports from other providers). One commenter stated that EHR technology developers should only need to be certified to one method of amendment and not all (i.e., free text, scanned information, or embedded links) in order to meet the certification criterion. Additionally, a commenter noted that amending the patient record should be allowed via the two methods proposed, but that scanned documents should have to adhere to a standard such as PDF or JPG.

Last, a group of commenters took issue with the phrase “electronic link” in the certification criterion. They raised concerns that the phrase “embedding an electronic link” in the certification criterion could be interpreted in many ways, including some that would create security risks. Commenters suggested removing “or by embedding an electronic link” to allow different forms and ways to append patient-supplied information. They also noted that the HIPAA Privacy Rule does not mention electronic links.

Response. In consideration of the comments received, we have modified this proposed certification criterion to make clear the capabilities that EHR technology must include in order to be certified. As we indicated in the Proposed Rule, we proposed this certification criterion at the HITPC's recommendation. Along those lines, we reiterated our agreement with the HITPC's expectation for this certification criterion, that it be “kept as simple as possible and evolve over time to greater complexity, including potentially greater standardization and automation.” Our revisions seek to make clear this certification criterion's focus on supporting the instance where a HIPAA covered entity agrees or declines to accept a patient's request for an amendment. Additionally, this certification criterion is meant to be a starting point from which more comprehensive capabilities and standards can be included, so we disagree with the commenter that suggested we wait until more comprehensive standards are available.

In response to commenter feedback, we have revised the certification criterion to more closely mirror the language in the HIPAA Privacy Rule at 45 CFR § 164.526. In doing so, we no longer specify a particular format (i.e., free text or scanned) and we have revised the language associated with “electronic link.” The “link,” which is an alternative to appending the patient's record must convey to a user or enable a user to obtain the information associated with an amendment's acceptance or denial. We believe this adjustment to the certification criterion provides EHR technology developers with more flexibility with which to design a capability that can accommodate the outcome this certification criterion expresses.

Comment. A commenter supported this proposed certification criterion and stated that there should be a mechanism to identify and make visible the source of the information to allow evaluation by any recipient that the information came from a reliable and accurate source.

Response. We appreciate this commenter's suggestion. However, it appears to be more specific than we believe necessary at this point for this new certification criterion. We believe that the requirements we have included in the final certification criterion are a sufficient start. We also believe that the certification criterion may, in part, address this commenter's suggestion in that the information appended or linked in the case of an accepted or denied amendment should at least have an indication as to the source of the information (i.e., patient or provider/organization).

Comments. Several commenters sought clarification as to whether patient-supplied information had to be appended to specific data in the patient's health record or attached to a specific instance of a clinical note or document. Another commenter expressed concern regarding the feasibility of being able to append patient supplied information to specific data. The commenter stated that this practice would be inconsistent with common provider policies that require all amendments to documents be classified as separate documents. In this way such information is clearly identified and maintained in a section or folder of the electronic record, and then subject to clinician review for what may be actually incorporated into the record upon acceptance. They indicated that by following this approach the patient requested amendment has its own “wholeness” or integrity as a medical record entry. In general, other commenters echoed this statement and suggested that it should be acceptable to have a separate section of the record for patient-supplied information.

Response. The final certification criterion does not require that accepted or denied amendments be appended to specific data in order for compliance to be demonstrated. As indicated above, this criterion is intended to support compliance with the HIPAA Privacy Rule's amendment requirements at 45 CFR 164.526. The Privacy Rule provides some flexibility with how accepted or denied amendments are appended to an individual's protected health information, recognizing that the type and scope of an amendment will vary based on the circumstances. For example, the affected record could include a link to documentation of an accepted or denied amendment, while still allowing, in the case of an accepted amendment, any necessary corrections to be incorporated directly into the record itself.

Comments. A couple of commenters requested clarification regarding the interplay between the terms “amend” and “append” in the certification criterion. One commenter stated that amendments are documentation meant to clarify health information within a health record whereas addendums are new documentation used to add information to an existing entry, and corrections are changes to information meant to clarify inaccuracies after the original document has been signed or rendered complete. The other commenter stated that we described “amending” a patient's record as allowing clinicians to correct errors or update the information within their record and that later we referred to the act of “appending” patient supplied information by using free text and/or scanned material. This commenter stated that “amend” and “append” are distinct concepts and should not be combined into one certification criterion because if we intend to allow these functions of correcting and/or attaching information to the patient's record they should remain separate. The commenter reasoned that amending should not permit any overwriting of the existing documentation and should include a date, time and authentication record of who took the action—while appending data should accurately capture the date, time, and authentication of the appended information.

Response. The terminology used in this certification criterion is meant to mirror the terms used in the HIPAA Privacy Rule at 45 CFR 164.526. Put simply, those rules describe that a patient is permitted to request an amendment to their health information and the corresponding obligations a HIPAA covered entity must follow to either accept or deny the requested amendment. As stated in 45 CFR § 164.526(c)(1), for example, if the amendment is accepted, “[t]he covered entity must make the appropriate amendment to the protected health information or record that is the subject of the request for amendment by * * * appending or otherwise providing a link to the location of the amendment.” Thus, this certification criterion reflects some of the capabilities needed in the event of an accepted or denied amendment.

Comment. A commenter stated that § 170.314(d)(4)(i)(A) conflicts with the description of the term of “Change” included in the Proposed Rule and that this criterion needs to be consistent with that definition.

Response. This comment is incorrect. The term “change” as described in the Proposed Rule was not included in this certification criterion. Thus, there is no conflict with respect to the clarity of the capabilities specified by this certification criterion and others that include the term “change.”

Comment. A commenter asked for clarification on the degree of information retained. They stated that too much information makes the data storage requirements burdensome on providers and superfluous data makes it difficult for auditors to detect unauthorized access.

Response. This certification criterion seeks to specify the EHR technology capabilities necessary to support, in part, the requirements specified at 45 CFR § 164.526 and it is not within its scope to address the degree or amount of information retained.

Comment. A commenter recommended that the electronic amendment contain a date/time stamp and reflect the user who took such action when content is amended.

Response. We appreciate this commenter's suggestion, however, we expect that this kind of event would be subject to the audit log requirements we have already specified (and which includes time and date stamp).

Comments. One commenter asked for clarification as to whether this criterion makes a distinction between “work in progress” records and “signed off” records. They stated, for example, a user may make several changes to the same data while working within a particular screen of the EHR technology. They suggested that the changes should only be captured when the user saves their changes and signs off on the record.

Response. No, this certification criterion does not make such a distinction because those distinctions are inapplicable to this certification criterion. We believe the commenter misinterpreted the purpose of this certification criterion and its focus on incrementally building in the capacity of EHR technology to make compliance with the HIPAA Privacy Rule more efficient.

Comment. One commenter noted a concern that if this certification criterion is applied to EHR Modules that are not part of the Base EHR definition that it could result in conflicting and overlapping practices and result in incorrect or inconsistent information in a patient record. For example, the commenter noted that it was a downstream business associate (or business associate subcontractor) and an intermediary, and thus does not amend patient information. Further they stated that they provide notice of any requests for amendments to their upstream business associates and covered entities with whom they directly contract. They concluded by stating that requiring an intermediary or developers of certain EHR Modules to have the capability to amend information could present confusion and should be applicable to core functionality of the EHR technology utilized at the provider level.

Response. For some of the reasons expressed by this commenter, we proposed to remove the requirement that EHR Modules also be certified to the privacy and security criteria. We clarify that this certification criterion is not separately applied to any EHR Modules in order for them to be certified. An EHR technology developer needs to include such capability, however, if they seek certification for EHR technology that would meet the Base EHR definition.

Comments. Two commenters recommended that we remove this certification criterion. One agreed that HIT should support workflow for complying with HIPAA privacy regulations, including allowing a user to amend a patient record, but contended that this functionality is typically found in a Medical Record Management system. Thus, they encouraged ONC to remove the certification criterion. However, they stated that if it remained, we should only require scanned documents. The other commenter recommended that we delay this certification criterion's adoption to a later edition of EHR certification criteria because the technical and legal implications of supporting patient amendments to the EHR are complex and evolving.

Response. We have not removed this proposed certification criterion. We agree with the HITPC that starting with a simple certification criterion can set us on a path to include more comprehensive capabilities over time. We acknowledge that the processes involved in supporting patient amendments can sometimes be difficult, which is why we explained in the Proposed Rule and reiterated in the above responses that this certification criterion can only help support (and potentially make more efficient) a HIPAA covered entity's compliance with the HIPAA Privacy Rule.

Comments. Several commenters supported the proposed certification criterion, but requested joint confirmation from ONC and CMS that EPs, EHs, and CAHs do not have to demonstrate use of this capability in order to meet meaningful use. Other commenters urged us to acknowledge that this functionality has importance beyond a privacy and security context.

Response. This certification criterion expresses capabilities that EHR technology would need to include in order to meet this certification criterion. Given that this certification criterion is included as part of the Base EHR definition, EPs, EHs, and CAHs, will need to have EHR technology certified to this certification criterion in order to have EHR technology that meets both the Base EHR and CEHRT definitions. We have consulted with CMS and clarify that since there is not a meaningful use objective expressly requiring the use of this capability to satisfy an associated measure that EPs, EHs, and CAHs do not need to demonstrate use of this capability in order to meet any meaningful use stage. However, we encourage EPs, EHs, and CAHs to consider if this capability could make compliance with the requirements of the HIPAA Privacy Rule, particularly, 45 CFR § 164.526, more efficient.

• View, Download, and Transmit to 3rd Party

We proposed a new criterion at § 170.314(e)(1) to subsume the certification criteria previously adopted at §§ 170.304(f), 170.304(g), 170.306(d), and 170.306(e). This proposal was based on the HITPC issued MU recommendation that patients (or their authorized representative(s)) be able to view and download their health information online (i.e., Internet/web-based). The HITPC recommended that this MU objective should replace or subsume the objectives for providing patients with timely electronic access to their health information and providing patients with an electronic copy of their health information and hospital discharge instructions upon request. Consistent with these recommendations, the HITSC recommended a certification criterion that framed the capabilities EHR technology would need to include to support this new objective and that, for the 2014 Edition EHR certification criterion, the criterion should replace the certification criteria previously adopted at §§ 170.304(f), 170.304(g), 170.306(d), and 170.306(e).

In addition to the view and download capabilities recommended by the HITSC, we proposed to include a third specific capability in this certification criterion—the ability to transmit an ambulatory and inpatient summary to a third party. Coupled with this addition, we proposed that EHR technology would need to be capable of transmitting an ambulatory and inpatient summary according to the two specifications—developed under the Direct Project—which we proposed for adoption: (1) Applicability Statement for Secure Health Transport and (2) Cross-Enterprise Document Reliable Interchange (XDR) and Cross-Enterprise Document Media Interchange (XDM) for Direct Messaging. We indicated that these transport standards were ideal for this purpose and would make it possible for patients to transmit a copy of their ambulatory or inpatient summary to the destination of their choice. Additionally, because we proposed requiring the capability to perform transmissions in accordance with these transport standards (which provide for encryption and integrity protection) in this criterion and in the “transitions of care—create and transmit transition of care/referral summaries” certification criterion, we determined that it would not be necessary to include in the 2014 Edition EHR certification criteria the “encrypting when exchanging” certification criterion adopted in the 2011 Edition EHR certification criteria (§ 170.302(v)). We stated our belief that to include the 2011 Edition EHR certification criterion would be redundant and that our proposed approach more explicitly tied security to a particular transmission.

At the recommendation of the HITSC, the proposed certification criterion required that EHR technology certified to this criterion include a “patient accessible log” to track the use of the view, download, and transmit capabilities included in this certification criterion and make that information available to the patient. We required this specific capability within this certification criterion because we believed that it was highly likely numerous EHR Modules could be certified to this criterion without also being certified to the auditable events and tamper resistance certification criterion we proposed to adopt at § 170.314(d)(2) (due to the proposed policy change we specified in section IV.C.1 of the proposed rule related to EHR Modules and privacy and security). Thus, this explicit proposal was meant to guarantee that an EHR Module certified to this criterion would include the capability to track who has viewed, downloaded, or transmitted to a third party electronic health information and that patients would have access to this information. That being said, we noted that we did not intend for this portion of the certification criterion to impose a redundant requirement on EHR technology developers who present a Complete EHR or EHR Module for certification to both this certification criterion and the auditable events and tamper resistance certification criterion. Accordingly, we provided in paragraph (e)(1)(ii)(B) of § 170.314 that EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of § 170.314 if it is also certified to the certification criterion proposed for adoption at § 170.314(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) of § 170.314 is accessible to the patient. In other words, we clarified that an EHR technology certified to § 170.314(d)(2) would not need to also include the “patient accessible log” capability specified in paragraph (e)(1)(ii)(A) of § 170.314 because it would be capable of logging such events and providing the information to the patient.

We also proposed that the “patient accessible log” capability would need to record the date and time each action occurs using a system clock that has been synchronized following either Request for Comments (RFC) 1305 Network Time Protocol (NTP) v3 or RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification (NTPv4).

We proposed to require EHR technology to be capable of enabling images formatted according to the Digital Imaging and Communications in Medicine (DICOM) standard to be downloaded and transmitted to a third party. We stated our belief that this specific capability has the potential to empower patients to play a greater role in their own care coordination and could help assist in reducing the amount of redundant and duplicative imaging-oriented tests performed.

Consistent with our belief that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality, we proposed that the viewing capability must meet Level AA conformance with the most recent set of the Web Content Accessibility Guidelines (WCAG). We explained that the most recent set of guidelines (WCAG 2.0) were published in 2008 and are organized under 4 central principles with testable “success criteria”: Perceivable, Operable, Understandable, and Robust. We further explained that each guideline offers 3 levels of conformance: A, AA, and AAA. We proposed compliance with Level AA because it provides a stronger level of accessibility and addresses areas of importance to the disabled community that are not included in Level A. In addition to WCAG 2.0 Level AA conformance, we requested public comment on whether commenters believed additional standards were needed for certification to ensure accessibility for the viewing capability, such as the User Agent Accessibility Guidelines (UAAG).

We proposed to require that EHR technology be capable of providing the information that CMS proposed be required in an ambulatory or inpatient summary that is provided to patients or their authorized representatives. This proposal was based on the HITSC's recommendation that we move to one standard for capturing this information and our belief that moving to one standard would lead to increased interoperability and spur innovation. We explained that we believed the Consolidated CDA was the most appropriate standard to achieve this goal because it was designed to be simpler and more straightforward to implement and, in relation to this rulemaking, its template structure can accommodate the formatting of an ambulatory or inpatient summary that includes all of the data elements that CMS proposed be available to be populated in an ambulatory or inpatient summary.

In certain instances in § 170.314(e)(1), we proposed to require that the capability be demonstrated in accordance with the specified vocabulary standard—which were previously adopted or proposed for adoption in the Proposed Rule consistent with the recommendations of the HITSC. With the exception of four standards (LOINC®, ICD-10-CM, ICD-10-PCS, and CPT/HCPCS), the vocabulary standards included in the certification criterion were discussed elsewhere in the Proposed Rule in connection with the certification criteria where the vocabulary standard is central to the required data or serves a primary purpose (e.g., RxNorm for e-prescribing).

For encounter diagnoses and procedures, we proposed the use of ICD-10 (ICD-10-CM and ICD-10-PCS, respectively). We requested comment, however, on whether we should be more flexible with this proposed requirement based on any potential extension of the ICD-10 compliance deadline or possible delayed enforcement approach. More specifically, we noted our interest in whether commenters believed it would be more appropriate to require EHR technology to be certified to a subset of ICD-10; either ICD-9 or ICD-10; or to both ICD-9 and ICD-10 for encounter diagnoses and procedures. We also asked that commenters consider these options when reviewing and commenting on the other proposed certification criteria that include these standards (i.e., § 170.314(a)(3), (b)(2), and (e)(2)). For procedures, we proposed to continue to permit a choice for EHR technology certification, either ICD-10-PCS or the combination of Health Care Financing Administration Common Procedure Coding System (HCPCS) and Current Procedural Terminology, Fourth Edition (CPT-4). For outbound messages including laboratory tests, we stated that EHR technology must be capable of transmitting the tests performed in LOINC® 2.38 to meet this certification criterion and for all other proposed certification criteria that include the capability to transmit laboratory tests in the LOINC® 2.38 standard. We proposed to adopt the “view, download, and transmit to 3rd party” certification criterion at § 170.314(e)(1) and the ICD-10-PCS and ICD-10-CM standards for procedures and encounter diagnoses at § 170.207(b)(3) and (m), respectively.

We received a significant amount of comments on the proposed view, download, and transmit to a 3rd party certification criterion. To make clear the policy expressed in our responses to comments, we have used subheadings under which specific comment themes will be discussed. In response to comments, we have made several revisions to the proposed certification criterion. Those revisions are explicitly noted in the applicable response.

View

Comments. Many commenters raised questions and concerns about the data we specified EHR technology would need to be capable of making viewable to a patient or their authorized representative. Some contended that the data exceeded those required for this use case and questioned the value of such data. Others pointed out that we did not have a consistent list of data between the “view” and “download” paragraphs. Commenters specifically called out “encounter diagnoses” as being inconsistently applied and raised concerns about our proposal to refer to ICD-10-CM.

With respect to the vocabularies we proposed for procedures several commenters disagreed with our proposal to permit EHR technology to be certified to represent procedures in ICD-10-PCS. Overall, commenters suggested in one form or another that SNOMED CT® should be the sole clinical vocabulary for documentation because it would help better meet the information objectives for MU. They further stated that SNOMED CT® is most appropriate when data is to be represented for clinical purposes and clinical accuracy. Commenters also contended that ICD-10-PCS was an inappropriate standard to reference for the purposes of clinical data exchange and was best suited for billing diagnosis and billing purposes. Among those comments at least one commenter stated that SNOMED CT® should be an alternative vocabulary standard included in the final rule. Another commenter stated that permitting the use of ICD-10-PCS to represent procedures in a Consolidated CDA formatted document would unnecessarily limit the usefulness of the Consolidated CDA document. This commenter stated that SNOMED CT® was the appropriate reference terminology to use to encode procedures. Similarly, other commenters recommended we replace ICD-10-PCS with SNOMED CT® because they believed that ICD-10-PCS would be inappropriate to use to represent procedures. They contended that procedures need to address counseling, education, and specific interventions that are not managed with a billing vocabulary. Last, one commenter stated that we should adopt the American Dental Association's Current Dental Terminology (CDT) as a vocabulary to represent procedures. They reasoned that CDT is a named HIPAA standard for use in electronic administrative transactions for dental claims and that this is the standard vocabulary dentists use to represent procedures.

Response. The data that is specified in this certification criterion was proposed to directly mirror the data that CMS proposed should be available for patients to view, download, and transmit to a 3rd party. Thus, we disagree that the data exceeds what is required for this use case. We have worked with CMS to align the data specified in this certification criterion. In that respect if there were any discrepancies we have corrected them. Additionally, as discussed earlier in this preamble we have revised this certification criterion to refer to the Common MU Data Set, which has significantly reduced the certification criterion's overall size and complexity. Further, we have removed “encounter diagnoses” from this certification criterion because it is no longer data that is minimally necessary to support what CMS has finalized for the objective and measure this certification criterion is designed to support. “Encounter diagnoses” is referenced by the transitions of care certification criterion (§ 170.314(b)(2)) and the data portability certification criterion (§ 170.314(b)(7)). Since the data portability certification criterion mirrors a portion of the transitions of care certification criterion, we have chosen to provide our response to comments on encounter diagnoses when we discuss the transitions of care certification criterion.

In consideration of the comments we received in response to our questions about ICD-10-PCS, we agree with those commenters that argued SNOMED CT® is a more appropriate vocabulary to reference in this case. As commenters noted, SNOMED CT® is more appropriate for clinical purposes and provides greater clinical accuracy. Thus, this final rule requires that in order for EHR technology to be certified to a certification criterion that references “procedures” data, it must demonstrate compliance with the use of SNOMED CT® or CPT/HCPCS (the latter is already adopted as part of the 2011 Edition EHR certification criteria and was carried forward in the Proposed Rule). However, in recognition that it may be beneficial for inpatient EHR technology developers to demonstrate compliance with, and support for the use of, ICD-10-PCS to represent procedures in the various certification criteria that reference procedures, we have adopted ICD-10-PCS as an “optional” vocabulary standard to which EHR technology developers can seek certification for their EHR technology.

In consideration of the comment suggesting that we include CDT as an alternative vocabulary for dentists, we have done so. However, we have adopted this vocabulary as “optional” and in addition to (not in lieu of) one of the primary vocabularies necessary for representing procedures data. Therefore, in the event that an EHR technology developer seeks to get its EHR technology certified to CDT, it will have to also be certified to one of the mandatory standards we have adopted for representing procedures, either SNOMED CT® or CPT/HCPCS.

Comments. Commenters recommended that we delineate which data for view is optional as which data is required.

Response. We decline to make this change. In order to be certified, EHR technology must be capable of permitting a patient or their authorized representative access to all of the data specified by the certification criterion. What information is actually made available by an EP, EH, or CAH and how it is displayed to a patient or their authorized representative should be determined by the EP, EH or CAH.

Comments. Some commenters asked that we clarify that the term “gender” as proposed was really intended to mean “sex” given the wide range of characteristics that could be encompassed by the term gender.

Response. We agree. Both ONC and CMS have included the term “sex” in our final rules.

Comments. A commenter advocated that the substitution of patient friendly terms for diagnoses should be permitted.

Response. We agree. We clarify and have modified the regulation text to explicitly indicate that for view (and download) that where certain coded data exists, the English language descriptions and not the codes should be viewable to a patient or their authorized representative.

Comments. Commenters recommended that we include the additional flexibility of being able to import (save “as is”) and view CCD/C32 and CCR documents in order to provide a transition between Stages 1 and 2. They stated that as a patient if they viewed an old CCD it should still count towards the MU numerator.

Response. We did not accept this recommendation and have not included this type of capability in the certification criterion. In large part, these comments are out of scope for this rulemaking and focus on measurement, which is relevant to the MU objective and measure with which this certification criterion correlates. That being said, the certification criterion does not specify how data is made viewable. Taking this approach is not necessarily precluded by the certification criterion and may somehow be able to address the view capability. However, we are uncertain, without additional details, whether the use of these older standard document formats would in practicality meet the numerator and denominator requirements for the MU measure or the new data required to be made viewable.

Comment. A commenter requested that we provide detailed requirements to EHR technology developers on how to address potential language barriers in their products (especially with regard to the use of the patient portal). They stated that a language barrier would negatively impact providers' abilities to engage patients and get them to use the view, download, and transmit capabilities. They contended that it would be inconsistent to require patient engagement through the use of a patient portal and not provide common standards for multi-lingual or predominantly non-English speaking communities where providers might exclusively practice.

Response. While we appreciate this commenter's suggestion and believe in the importance of multi-lingual accommodations, we believe this suggestion is a significant departure from the certification criterion proposed and would require additional study to determine how to appropriately frame it as a certification requirement for EHR technology. Thus, we have not changed the certification criterion in response to this comment.

Comments. A commenter recommended that this certification criterion should include more specific capabilities than we proposed such as, accommodate patient generated data to “upload” into the EHR; include linkages to patient specific education materials; and be based upon a standing patient preference.

Response. We did not accept this recommendation. We believe the certification criterion is properly scoped to support its correlated MU objective and measure and do not seek to introduce additional burden that could be value-added functionality outside the scope of certification that EHR technology developers can include for competitive purposes.

Accessibility

Comments. Commenters generally supported the underlying rationale behind the proposal, with some endorsing the requirement as proposed. Other commenters contended that achieving WCAG Level AA compliance in the time available would be extremely difficult for EHR developers to achieve. They stated that it is very complex to achieve compliance in a real world scenario and that Level AA conformance imposes a burden too great at this point in time. Further, they stated that the requirements for interfacing to independent accessibility tools (also required by WCAG 2.0), such as those that read screen text aloud can be impossible to achieve for “snappy” and “intelligent” JavaScript-dependent applications. One commenter noted that as of April 2012, two well-known news sites reported 76 and 104 known problems, respectively. Some commenters suggested removing this requirement altogether while others suggested that we take a more incremental approach and start with Level A conformance which could set the stage for a predictable progression to Level AA at a later date. Commenters also requested that we clarify that the WCAG standard would apply only to patient viewable information as intended by this certification criterion.

Response. We appreciate commenters support for this proposal. As we noted in the proposed rule, we believe that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality. We recognize that this was a new requirement proposed for the 2014 Edition EHR certification criteria and in considering the burden concerns identified by commenters and need for greater experience with WCAG generally, we have decided to require Level A conformance instead of Level AA. As some commenters noted starting at Level A will provide a baseline from an accessibility perspective and one on which we can build in future rulemakings. Accordingly, we would like to express our intention to propose requiring Level AA in our next rulemaking cycle and encourage EHR technology developers to take the steps necessary to be on a path towards Level AA conformance. We also clarify, as requested, that the WCAG standards apply to the information that is viewable to the patient or their authorized representative through the capabilities EHR technology includes that would enable them to electronically view, download, and transmit their health information to a 3rd party.

Comments. Comments stated that most patients want functions and content provided in a more visually appealing manner than the standard allows. Commenters requested that we clarify for certification whether an EHR technology developer would need to show how the product can be configured for WCAG 2.0 requirements by an implementer or whether the EHR technology must be “preconfigured” to those requirements (e.g. preset for font, contrast, color settings, etc). They stated, for example, that an EHR technology developer might have a configuration choice for accessibility that a consumer could opt for using that would include setting the contrast, font, color scheme, etc. to be conformant to accessibility requirements but allow other users to be able to select other settings as a matter of choice. They suggested that for certification it should be sufficient for an EHR technology developer to show how the settings for accessibility can be configured, but not predefined or preset.

Response. In order to demonstrate conformance with the certification criterion, EHR technology will need to meet WCAG Level A. So long as the EP, EH, or CAH (as the customer) can appropriately configure the EHR technology for the patient, then that is sufficient. The certification criterion does not specify that certain design elements be predefined or preset.

Comment. A commenter suggested that we consider if there are third parties that can provide supportive independent evidence of conformance to the WCAG standards or if any self-attestation evidence can be provided for review by the NVLAP-accredited testing laboratory so that if a vendor has pursued such third party review, it does not have to do so in repetition for the sake of 2014 certification.

Response. While we believe that such documentation could expedite the review by a NVLAP-accredited testing laboratory, the EHR technology would still need to be independently assessed by the testing laboratory for conformance following test procedures approved by the National Coordinator.

Comments. Several commenters, in response to our request for comment on the UAAG standard, did not support its adoption as part of this certification criterion because they contended that it does not apply to Web sites like patient portals. Rather, they stated that it applies only to web browsers.

Response. We have not included or adopted the UAAG standards at this time and appreciate commenters' detailed feedback.

Download

Comments. A couple of commenters stated their belief that in order to meet the “human readable” aspect of this certification criterion that an HTML view of the XML file for the Consolidated CDA should be adequate for both viewing and downloading.

Response. As we have previously stated in the S&CC July 2010 final rule (75 FR 44598) in response to questions about the meaning of human readable, the use of a style sheet associated with a document formatted according to the Consolidated CDA would be permitted.

Comments. Commenters asked that we specifically clarify that for the “download and transmit” requirements, the data itself must be downloaded and transmitted and not merely a link to the data is what is downloaded and transmitted.

Response. Yes, the data itself must be downloaded and transmitted. A hyperlink to the data would not be sufficient for EHR technology to demonstrate compliance with this certification criterion.

Comments. Many commenters supported the proposed adoption of the Consolidated CDA standard and our proposal to move to this as the single standard. Some opposed this proposal altogether, while others suggested that the previously adopted CCD standard as well as the CCR standard should continue to be permitted because the Consolidated CDA was immature.

Several commenters requested clarification related to the aspects of the Consolidated CDA that are required for certification. More specifically, they stated that the Consolidated CDA is an implementation guide for nine different document types (eight structured and one unstructured), and that it would not only be inappropriate to require the use of all of these document types for all environments but would in fact not make sense for elements like a discharge summary for an EP). Many recommended that the certification requirement be that the EHR technology should demonstrate the ability to generate at least one of the available CCDA document types and that providers will be able to use the document type most appropriate to the clinical situation.

A couple of commenters stated that we should explicitly prohibit the use of the unstructured document template because not doing so would allow EHR technology developers to bypass using structured and coded data.

Last, a couple of commenters noted that each time a “care summary” is specified in the Proposed Rule that it was described slightly differently. They contended that these differences will cause unnecessary confusion and disruption throughout the care delivery process. Additionally, they noted that none of the data sets specified for the certification criteria that reference the Consolidated CDA precisely matched any existing document-level templates in the Consolidated CDA.

Response. We appreciate commenters support for the Consolidated CDA, and have finalized its adoption in the final rule. We believe that moving to a single standard is absolutely necessary to advance interoperability. The Consolidated CDA represents a significant amount of effort by industry stakeholders and we believe it is the best available standard to require for certification and to meet our policy objectives for interoperability. As noted by some commenters and, what appeared to be unknown to others, the Consolidated CDA is not per se a competing standard with the CCD because it contains within it a document-template that describes how to implement a CCD according to new, harmonized and consolidated implementation guidance (CCD v1.1). So the CCD document-template represented in the Consolidated CDA is an update to the CCD/C32 implementation guidance. That being said, as precisely noted by commenters, none of the 8 specific structured document-level templates in the Consolidated CDA neatly support the data specified by this certification criterion as well as the others in which it is also referenced (clinical summary, transitions of care, and data portability). Accordingly, we clarify that, with respect to the Consolidated CDA, certification will not focus on a specific document-level template because none are particularly suited to support MU's policy objectives and the data elements specified across the different certification criteria that reference the Consolidated CDA. Rather, certification will focus on an EHR technology's ability to properly implement the US Realm header and the associated section-level templates necessary to support each certification criterion in which the Consolidated CDA is referenced and for the appropriate data specified in each of those certification criteria. We intend for testing and the test data made available for these certification criteria to enable consistent Consolidated CDA implementations. Further, based on our policy decision to focus testing and certification on section-templates, we have performed additional analysis of the Consolidated CDA. Based on our analysis, we note that absent certain conformance requirements otherwise specified in a particular document-level template, our approach could result in implementation ambiguities. These ambiguities could exist because section-templates when viewed independently of a particular document-template permit the use of narrative text, coded entries optional, or narrative text and required structured data, coded entries required. Thus, we believe it is necessary to clarify for EHR technology developers that in all instances where we have adopted a vocabulary standard in § 170.207 the accompanying section-template implemented must be done so using the section-template with required structured data, coded entries required.

We agree with the comments that suggested we prohibit the use of the unstructured document-template included in the Consolidated CDA. As referenced in the Consolidated CDA, an “unstructured document is a document which is used when the patient record is captured in an unstructured format that is encapsulated within an image file or as unstructured text in an electronic file such as a word processing or Portable Document Format (PDF) document.” We believe that permitting this document template to be used as part of the Consolidated CDA or leaving any ambiguity as to whether it can be used to meet this certification criterion would be inconsistent with our policy objectives. Thus, we have indicated in § 170.205(a)(3) where we have adopted the Consolidated CDA that the use of the unstructured document template is not permitted.

We also take this opportunity to identify for stakeholders a modification we believe must be made to this certification criterion in order to align our final rule with clarifications made in CMS's final rule and, ultimately, in order to ensure the CEHRT EHs and CAHs adopted can support their achievement of MU. Further, this modification is only applicable to the inpatient setting only and is designated in the certification criterion as such. In its proposed rule (77 FR, 13730) CMS proposed that one of the information types, a patient should be able to download would be their “care transition summary and plan.” In response to comments, CMS clarified and has listed these two information types as separate kinds of information that must be able to be downloaded. Accordingly, we have included in this certification criterion that for the inpatient setting a patient would need to be able to electronically download transition of care/referral summaries that were created as a result of a transition of care/referral (pursuant to the capability expressed in the certification criterion adopted at paragraph § 170.314(b)(2)). We believe this addition poses limited additional burden since EHR technology would just need to be able to make available for download any transition of care/referral summaries created as a result of a transition of care (so if a patient has had multiple hospitalizations during the EHR reporting period and been transitioned out of the hospital, the EHR technology would need to be capable of making available both inpatient summaries and transition of care/referral summaries that were created as a result of the transitions).

We received comments on our proposal to adopt the Consolidated CDA where it was proposed for other certification criteria. In drafting this comment and response we considered those comments and included them in the comment summary above. Accordingly, our response here to the proposal to adopt the Consolidated CDA is not repeated in the other certification criteria where its adoption was also proposed.

Comments. A couple of commenters stated that we mentioned in the Proposed Rule that there needs to be a confidentiality type included in the CCDA. They noted that it was unclear what that requirement meant in the use case where a patient downloads their information. They requested further clarification and guidance on the indication of this element within this certification criterion.

Response. As we noted in the Proposed Rule, one of the metadata elements required by the US Realm Header is the ConfidentialityCode which should be populated with a value from the value set of BasicConfidentialityKind (this value set includes 3 possible values: “N” Normal, “R” Restricted, and “V” Very Restricted). In this context, we believe that “N” would likely be the default value.

Comments. Several commenters stated that we should require EHR technology to include the capability to do a “Blue Button” download. Other commenters opposed this idea because all that would be downloaded would be a text file. They contended that such an outcome would be a step backwards from requiring the Consolidated CDA.

Response. The view, download, and transmit capabilities required by this certification criterion are fully aligned with the Blue Button goals of empowering patients to be partners in their health care through access to and use of personal health information. We expect the Blue Button vision to evolve and expand to encompass a variety of technical solutions beyond the traditional download of a text file, including view, download, and transmit capabilities. Along those lines, we strongly encourage every EHR technology developer to associate this certification criterion's download capability related to a human readable file with the increasingly popular “Blue Button” phrase and logo. To be clear, we also require for certification that EHR technology be capable of enabling a patient or their authorized representative to be able to download a file formatted according to the Consolidated CDA.

Comments. Commenters noted that the Consolidated CDA had been updated since the Proposed Rule was published and urged us to adopt the most recent version in the final rule.

Response. We agree with commenters and have adopted the HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Draft Standard for Trial Use (DSTU) Release 1.1 (US Realm) Draft Standard for Trial Use, July 2012. This version of the Consolidated CDA constitutes the most recent balloted version—a process which has been underway since the Proposed Rule was published. It corrects errors in the prior version, and was modified to more fully and closely support capturing the MU data that CMS requires for EPs, EHs, and CAHs to meet certain MU objectives and measures related to transitions of care, clinical summaries, and providing patients with the ability to view, download and transmit their health information. As noted by HL7 in its documentation, this DSTU version of the standard will be open for comment for 24 months and following this evaluation period, it will be revised as necessary and then submitted to ANSI for approval as an American National Standard (normative standard). Further, HL7 specifies that implementation of this DSTU version will be valid during the ANSI approval process and “for up to six months after publication” of the normative standard. Given the state at which this DSTU version of the standard is and the fact that this version alone is subject to the evaluation period, we believe that it is the best possible choice for this final rule, especially in place of the draft version we referenced in the Proposed Rule.

Comments. A few commenters stated that this certification criterion did not expressly include privacy and security requirements. They suggested that we should require EHR technology to be able to ensure that a patient's online experience is secure. They recommended that we specify requirements for authentication such as OAuth as well as a specific level of assurance (NIST level 3). They also recommended that we require EHR technology to be certified for its ability to establish a secure channel for view and download.

Response. We are convinced by commenters that it is important and necessary to add a more explicit requirement for security in this certification criterion. In that respect, we have revised our proposed criterion to accept commenters' suggestions in part. As suggested, we have included a requirement that EHR technology must be able to establish a secure channel through which a patient can access the capabilities to view, download, and transmit their electronic health information. We agree that certification can provide some assurance that EHR technology can properly establish for a secure channel through which health information can be viewed, downloaded, and transmitted. This secure channel requirement mirrors that portion of the secure messaging certification criterion. Thus, it is possible for an EHR technology to be certified to both this certification criterion and the secure messaging certification criterion, depending on how it is designed.

We continue to decline to change the certification criterion in response to commenters' recommendations that we prescribe a particular form or “level of assurance” for authentication. It is not that we disagree that some form of authentication will be necessary when EHR technology certified to this certification criterion is implemented. Rather, as some comments suggest, there is significant innovation taking place with respect to authentication. Thus, we believe that requiring a particular form in this certification criterion would be overly prescriptive and have little practical effect on the eventual authentication approach EPs, EHs, or CAHs implement.

Comment. A commenter noted that the Consolidated CDA stated that vital signs are an optional section which may be included in CCDs, while the Proposed Rule stated that this section is required. They contended that if such discrepancies are allowed to persist, EHR technology developers will inevitably make mistakes on what they choose to include and marked heterogeneity will persist.

Response. We seek to make clear for this commenter (and this response is generally applicable to any instance where we have adopted certification criteria that reference standards and required data) that this final rule and its requirements take precedence (i.e., override) any “optional” requirements in a standard or implementation specification if they are deemed required as part of a certification criterion. For example, if sections or certain data in an implementation guide are designated “optional,” but a certification criterion requires compliance with such sections or data, EHR technology must be designed to comply or accommodate those sections or data in order to meet the certification criterion.

Transmit

Comments. Many commenters asked that we clarify why a SOAP-based transport standard was not proposed as part of this certification criterion when it was for the transitions of care certification criterion. Commenters contended that this was an inconsistency and asked that ONC and CMS reconcile the two. They also referenced CMS's proposed rule and preamble that stated that transmission could occur via any means of electronic transmission according to any transport standards for the view, download, and transmit to a third party objective. Other commenters stated that other transport standards should be permitted for use, such as those for query and response. Last, commenters asked questions about workflow and how transmission should be implemented so that a patient's information can be transmitted to a 3rd party.

Response. There was no inconsistency between the ONC and CMS proposed rules. The proposed transport standard(s) for each certification criterion were purposefully chosen and proposed to specify the capabilities EHR technology would need to include in order to demonstrate compliance with each certification criterion. Commenters have confused two very distinct concepts: (1) What is required for EHR technology to demonstrate compliance with a certification criterion; and (2) how EHR technology, once certified, must be used to demonstrate meaningful use. We seek to make this distinction clear to prevent any further confusion.

The certification criteria adopted in this final rule apply to EHR technology and only EHR technology. The final rule specifies the technical capabilities that EHR technology must include and other requirements that must be met in order for EHR technology to be certified. This rule does not specify in any way how EHR technology, once certified, must be used in order to achieve meaningful use. That policy is expressed in CMS's rules and is identified for each MU objective and associated measure. In this scenario with the view, download, and transmit to a 3rd party and transitions of care objectives and measures, CMS purposefully proposed two different policies.

For view, download, and transmit to a 3rd party CMS expressly indicated that other transport standards beyond those required for certification could be used by EPs, EHs, and CAHs. However, for transitions of care, CMS expressly indicated that only the transport standards permitted for certification would count in an EP, EH, or CAH's numerator for the measure. Thus, for the transitions of care certification criterion, we included the SOAP-based transport standard as an option for certification to expand the potential approaches EPs, EHs, and CAHs could take to also include electronically transmitted transition of care/referral summaries according to that standard in the transitions of care measure's numerator. In other words, had we not proposed the SOAP-based transport standard as an option in the transitions of care certification criterion, EPs, EHs, and CAHs would have been limited to meeting that MU objective and measure through only the use of the Applicability Statement for Secure Health Transport specification (the primary Direct Project specification). In the case of view, download, and transmit to a 3rd party, we proposed the adoption of the Applicability Statement for Secure Health Transport specification because we believe it is necessary for EHR technology certified to this certification criterion to include at least the capability to use that transport standard, even though CMS permits EPs, EHs, and CAHs to use alternative transport standards. We note that consistent with the changes we have made in the transitions of care certification criterion, we are requiring certification only to the Applicability Statement for Secure Health Transport standard and not also the second Direct Project specification (XDR and XDM for Direct Messaging). Additionally, the Applicability Statement for Secure Health Transport has been updated to Version 1.1 (July 10, 2012). We have adopted this version of the specification because it improves EHR technology implementation and the testing of the specification's requirements and, consequently, makes the version of the specification we proposed outdated. Version 1.1 was established by the stakeholder community during this final rule's drafting. Version 1.1 of the specification provides clearer instruction for implementation through additional guidance on how certificates can be discovered in a consistent manner. If we had adopted the proposed version, EHR technology developers would have encountered difficulty with consistently implementing EHR technology to the specification and testing of the specification's requirements would have been hindered. Last, we do not believe that it is within this rule's scope to specifically describe a particular workflow or how transmission should be implemented. Many commenters raised certification concerns related to the Applicability Statement for Secure Health Transport specification when they commented on the transitions of care certification criterion. Thus, we do not repeat those concerns and our responses and instead address them once in the transitions of care certification criteria comment and responses.

Comments. Commenters stated that the reference to the Applicability Statement for Secure Health Transport specification was the right direction to take for provider-to-provider (or clinician or organization) transmissions but that it was unclear whether this specification was also appropriate for a patient-focused certification criterion. They requested that the “transmit to third party” via this standard should be clarified to express that the intended transmission was to another provider or a personal health record (PHR). They contended that the standard should not be required for transmission to other individuals who are not providers (e.g., friends, relatives, etc.). Additionally, they stated that in this latter case the word “transmission” may not necessarily mean it was transmitted electronically (or in a manner that can be tracked) because the information could be loaded onto a USB drive, DVD, or even printed in being transferred to a new physician by a patient.

Response. We expect that if the Applicability Statement for Secure Health Transport specification is used to complete a transmission to a 3rd party that the receiving party would be another health care-oriented entity, like a PHR company the patient is using and that it would not be a patient's friend or relative. Furthermore, for the purposes of this certification criterion, the more generic interpretation of the word “transmission” stated by the commenter would not be within the scope of this certification criterion as we do not consider transferring data to electronic media like a USB drive or DVD to constitute an “electronic transmission” for the purposes of certification.

Comments. Some commenters agreed that patients should be permitted to transmit their health information to another entity, but stated that we should not burden the health care provider to be the party that transmits this information on their behalf. They contended that health care providers should not be a relaying entity on behalf of their patients.

Response. For clarity, we have revised this certification criterion to state that EHR technology must provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party the data required by the certification criterion. In this sense, it is the EHR technology that an EP, EH, or CAH has that is performing this function, not the EP, EH, or CAH. Thus, we believe that the burden identified by commenters is misplaced.

Comments. A commenter recommended that we consider requiring the transmittal of a provider's National Provider Identification (NPI) number when an NPI has been assigned. They reasoned that including the NPI would allow receiving systems to more easily cross reference provider information that might already exist in the receiving system database.

Response. We decline to change the certification criterion based on this suggestion. We note that the US Realm Header for the Consolidated CDA does require that at least one “author” be identified and further that the “assigned Author” shall contain at least one “id” which the standard recommends with a “should” as being the NPI.

Download and Transmission of Images

Comments. Commenters generally supported the principle of providing patients with access to images, however, only a few commenters outright supported our proposal. One commenter that supported our proposal suggested that images also be included in the “view” part of the certification criterion and stated that diagnostic quality is unnecessary for patient viewing. They encouraged us not to suggest a standard for image viewing by patients. Another commenter asked if we intended for images to be available for viewing in a basic distribution viewer or if small images embedded in the report or images viewed without tools in a browser would meet the certification criterion's intent. They suggested that we require a basic distribution viewer to be part of the “view” portion of the certification criterion. One commenter stated that if we did not specify DICOM as a requirement for certification, that we should at least make available the option for EHR technology to be certified to the standard for the purposes of image downloads.

Several commenters strongly opposed or requested that we remove the capability and proposed standard. These commenters stated that including images for download and transmission by a patient would be a challenging requirement. They also contended that this capability exceeded the requirements in CMS's proposed rule. Additionally, these commenters stated that images are typically stored in a system separate from EHR technology (i.e., a PACS system) and that this requirement would add significant complexity and burden to the certification criterion. They followed this comment by stating that the industry norm is for CDs with pertinent images to be given to a patient with an image reader that allows for viewing. A similar point was made by other commenters who stated that requiring DICOM for the transmission would force the recipient of the images to have a DICOM compliant viewer and to import the images into that viewer before they could be viewed. Many commenters noted that an image's average file size would present significant storage and cost challenges for online downloading and transmitting. The JPEG file format was recommended as a potential solution since patients did not necessarily need diagnostic quality images.

Response. In consideration of the comments received and the complexity and potential burden identified by commenters, we have decided to remove the requirement for images to be available for download and transmission to a third party. We believe further industry dialogue needs to occur with respect to images and our policy goal of enabling patients to have ready, online access to their images. We expect to include this topic on the HITSC's agenda for the next edition of EHR certification criteria we would adopt through rulemaking and intend to propose a requirement for online image access in a future edition of this certification criterion.

Comments. We received the following additional comments that did not fall within the general scope of the comments summarized above. One commenter proposed that a secure hyperlink to the image, supplied by the radiologist and conveyed via the Direct Project standard, become the method of making DICOM images and radiology reports available to patients and ordering providers. A commenter suggested that for image download a patient should be able to identify the location of a study to be referred to another provider as acceptable for the certification criterion. Last, a separate commenter asked that we specify for the “download and transmit” requirements, the IHE Portable Data for Imaging (PDI) profile.

Response. We appreciate commenters' feedback. Given our decision to remove the requirement for image downloading and transmission to a third party, we will take this feedback into consideration for our future work with the HITSC as well as our next rulemaking.

Patient Accessible Log

Comments. Several commenters opposed this proposed specific capability in the certification criterion because they thought it was a means to implement the HHS Office for Civil Rights (OCR) HIPAA Privacy Rule accounting of disclosures proposal (76 FR 31426) for patients to be able to get an “access report.”

Response. These commenters are mistaken. This aspect of the certification criterion was not intended to implement the Department's proposal to give individuals a right to receive an “access report.” However, given this confusion, we have decided to change the paragraph heading for this part of the certification criterion to state “activity history log.” The purpose of this paragraph in the certification criterion is to simply require that EHR technology be able to monitor when a patient or their authorized representative(s) views, downloads, or transmits their health information to a third party. Those are the actions to which this paragraph referred in the proposed certification criterion. Put simply, this activity log is meant to assist a patient track the history of their actions or those of their authorized representatives.

Comments. Many commenters stated that the Proposed Rule did not clarify or offer a statement regarding how far back in time a patient accessible log should be able to retrieve log event data. They also sought clarification on who a user could be and what would be sufficient data to include in the log.

Response. The time period for which the activity history log should be available is a policy determination that should be made by the organization who implements EHR technology certified to this certification criterion. Thus, we decline to specify a particular retention period in this certification criterion. What is necessary for certification is that an EHR technology can demonstrate that it can properly create such a log. As noted in our response directly above, we intend for “user” in this context to be the patient and any authorized representative(s) to whom they have provided access to view, download, and/or transmit their health information to a third party.

Comments. Several commenters supported the “credit” we sought to provide if EHR technology leveraged its general auditing capabilities to fulfill the requirements specified by this capability. However, they asked that we clarify that our proposal did not imply electronic or immediate access to the general audit trail via either the Complete EHR or portal. Some commenters explicitly stated that they would oppose any requirement for immediate electronic access to the general EHR technology audit log online. They also requested confirmation that the access does not need to be provided online. Rather, they suggested that EHR technology could produce a printed document for a patient to review, upon request. They also requested clarification that the log could provide summary information, (e.g., that a patient summary was sent to a third party) and not be required to list all the information contained in the summary document that was transmitted.

Response. This certification criterion does not require an EP, EH, or CAH's general EHR technology security audit log to be made available to patients online. However, the activity history log must be available online and readily accessible. We hope that the past two responses have helped clarify many scope-oriented points for these commenters because it was our proposal and our continued belief that the activity history log should be online and readily available for a patient (or their authorized representative) to review “on demand.” Given the clarifications and the limited burden we believe is associated with tracking when a “view,” “download,” and “transmission” has occurred and by whom and when, we do not believe that this should be a significantly challenging capability to include. Accordingly, we have finalized this portion of the proposed certification criterion by changing the paragraph heading and making clear that the actions that need to be tracked are simply “views,” “downloads,” and/or “transmissions” that have occurred and by whom and when.

Comments. Commenters expressed support for our proposed “synchronized clocks” standard and our proposal to permit either NTPv3 or NTPv4. They noted that the use of these synchronization technologies is very common and supported in all major operating systems. Along those lines, they stated that it was unclear why this would be a requirement for EHR technology certification because it is unlikely that the EHR technology itself will be directly implementing this type of synchronization and more likely that it will be relying on the lower level systems' clock functionality (e.g., the operating system within which the EHR technology runs). One commenter stated that it is important to avoid a requirement that would make the operating system (that provides the standard clock) part of what is needed for EHR certification as this would impose artificial limits on what operating systems can be used without certifying multiple permutations. This commenter contended that because the ability to use an operating system clock is common, it was unnecessary for this standard to be required for certification. They requested that if we did include it for certification, that we acknowledge that: the operating system keeps the time, the EHR technology gets the system clock, and that a particular operating system is not required to be part of EHR technology for certification.

Response. We thank commenters for supporting this proposal. As we indicated in the Proposed Rule, our responses here also apply to comments received on other certification criteria that also referenced the “synchronized clocks” standard. We acknowledged in the Proposed Rule and here again our understanding and expectation that EHR technology will likely obtain a system time from a system clock that has been synchronized following the NTPv3 or NTPv4 standard. We expressly worded the standard to acknowledge this likely scenario by stating “[t]he date and time recorded utilize a system clock that has been synchronized * * *.” (Emphasis added.) We do not intend for this specific capability to create a binding relationship between EHR technology and a particular operating system. For certification, EHR technology must be able to demonstrate, as the standard states, that it can utilize a system clock that has been synchronized following NTPv3 or NTPv4. Accordingly, we have retained this proposal and finalized it for the certification criteria to which it pertains.

• Automated Numerator Recording

To complement the “automated measure calculation” certification criterion adopted at § 170.314(g)(2), we proposed to adopt a 2014 Edition EHR certification criterion that would apply solely to EHR Modules that include capabilities to support an MU objective with a percentage-based measure. We stated that the focus of this new certification criterion would be on the EHR Module's capability to automatically record the numerator for those measures. We proposed to adopt this new certification criterion at § 170.314(g)(1).

We clarified that, while a Complete EHR would need to be capable of meeting the “automated measure calculation” which requires the capability to accurately calculate MU denominators, we did not believe that it would be practicable for an EHR Module to do the same because, in most cases, an EHR Module would likely be unable to record or have access to an accurate denominator. We did, however, believe that EHR Modules presented for certification to certification criteria that include capabilities for supporting an MU objective with a percentage-based measure should at least be able to readily and accurately record the numerator for those capabilities.

Comments. Many commenters supported our proposal in concept and as written. Some of these commenters stated that this certification criterion was a welcome improvement and would ease the reporting burden for small providers and hospitals. Other commenters contended that our proposal had a logical flaw and requested that we clarify how an EHR Module would be able to accurately capture the appropriate numerator because the numerator is often a subset of the patients or actions that qualify to be in the denominator. As such, some commenters echoed what we had stated in the Proposed Rule (that it may be difficult for an EHR Module to know the true denominator) and expressed concern that this requirement could not be implemented without additional burden. Some commenters suggested that we remove this certification criterion altogether, while others requested that modify this certification criterion to fix the logic challenge and asked that we clarify the expected testing and certification process for this certification criterion if it were to remain in the final rule.

Response. We appreciate commenters support for this certification criterion. We have adopted a revised version of the certification criterion. We acknowledge that this certification criterion requires additional explanation and clarity related to our intended outcome. We agree with commenters that, unless clarified, this proposed certification criterion could pose logic problems for EHR technology developers and, correspondingly, that the conditions we expected to be met in our proposal would be difficult to achieve. Especially in circumstances where the EHR Module has no basis on which to determine the patients or actions that would be part of the denominator specified for a given MU measure.

In response, we offer the following clarifications. We proposed this certification criterion in order to make it easier and more efficient for EPs, EHs, and CAHs who pursue an EHR Module approach to meet the CEHRT definition to determine their EHR MU measure percentages. As we acknowledged in the Proposed Rule, this certification criterion could only help so much because of the potential that an EHR Module would not necessarily have the ability to determine the appropriate denominator for a given measure. We agree with commenters that this limitation can extend to the numerator in cases where the numerator is a subset of the denominator. To address this logic issue, we have modified the certification criterion to focus on what we believe an EHR Module will be able to determine without any specific dependency on an MU measure's denominator. This certification criterion now focuses on an EHR Module's ability to correctly identify the patients or actions that would meet the numerator's requirements generally and without the denominator's limitations applied. Thus, we clarify that for the purposes of testing and certification, an EHR Module would not need to be able to precisely identify the MU numerator after all of the denominator's filtering had been applied. Instead, it will need to be able to identify the patients or actions that would generally meet the numerator and the minimum denominator criteria that would be necessary to match the information provided by the EHR Module to the full denominator criteria from other data sources. We have revised the certification criterion to make this point clear. Additionally, to reflect that in order for this information to be useful to an EP, EH, or CAH to determine the true numerator, the EHR Module (similar to the automated measure calculation certification criterion) would need to be able to produce a file/report that identifies those patients or actions that would meet the numerator. We provide the following examples to illustrate the capability that an EHR Module would need to include. We note that depending on the certification criterion or criteria to which the EHR Module is presented for certification that the potential approach to determine the overall number of patients or actions may be different. We intend to provide guidance as necessary with more examples for each MU objective and measure that this certification criterion would need to support. Ultimately, we believe this information will also help EHR technology developers better understand the numerators and denominators associated with the MU measures.

• Example 1:

An EHR Module presented for certification that includes CPOE and seeks to be certified to certification criterion at 170.314(a)(1). To meet the automated numerator calculation certification criterion, the EHR Module would need to be able to correctly identify a simple number, the number of orders created using the EHR Module. An EP, EH, or CAH would then need to take this output from the EHR Module and compare it to the total number of orders made (inclusive of those where the EHR Module was not used).

• Example 2:

An EHR Module presented for certification that includes e-prescribing capabilities and seeks to be certified to certification criteria at 170.314(a)(10) (drug formulary check) and 170.314(b)(3) (electronic prescribing). To meet the automated numerator calculation certification criterion, the EHR Module would need to be able to correctly identify a slightly more complicated number, number of permissible prescriptions for which the existence of a drug formulary was queried and a prescription subsequently electronically transmitted. Given this overall number, an EP, EH, or CAH would then need to take this output from the EHR Module and compare it to the total number of permissible prescriptions written for drugs requiring a prescription, which would need to be obtained from somewhere else.

• Example 3:

An EHR Module presented for certification that includes the ability to record patient demographics and seeks to be certified to certification criterion at 170.314(a)(3). To meet the automated numerator calculation certification criterion, the EHR Module would need to be able to correctly generate a list of patients that identifies each and every patient in the EHR Module who have all of the demographic elements recorded as structured data (or that the patient declined or not collectable under state or local law). An EP, EH, or CAH would then need to take this output from the EHR Module and compare it to the data source they would use to identify unique patients seen during the EHR reporting period (the denominator limitations for this MU measure).

• Example 4:

An EHR Module presented for certification that includes the ability to provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party electronic health information and seeks to be certified to certification criterion at 170.314(e)(1). To meet the automated numerator calculation certification criterion, the EHR Module would need to be able to correctly generate a slightly different list of patients that identifies each and every patient in the EHR Module who have taken one of those three actions. An EP, EH, or CAH would then need to take this output from the EHR Module and compare it to the data source they would use to identify unique patients seen during the EHR reporting period (the denominator limitations for this MU measure).

As illustrated by these examples, many MU measures share similar denominators. Thus, we expect that once an EP, EH, or CAH identifies the source they will use as the basis for a denominator (i.e., number of unique patients seen during the EHR reporting period) that it should be relatively straight forward given the information an EHR Module would be required to produce for the EP, EH, or CAH to determine the true numerator.

Comment. A commenter acknowledged that this proposed certification criterion would be applicable to EHR Modules and requested that we clarify whether this policy applied to EHR technology developers who follow an incremental EHR Module certification approach on the way to designing EHR technology that could satisfy the Complete EHR definition. They stated that if our answer was yes, that it would be overwork for such EHR technology developers and requested an exemption for this scenario.

Response. This requirement is broadly applicable to every EHR Module presented for certification and we decline to provide any exemption. While an EHR technology developer may pursue this approach, we do not believe that it would be prudent to offer such an exemption because it is equally likely that the EHR technology developer could decide to stop before it could seek certification for enough EHR Modules that would cumulatively satisfy the Complete EHR definition. If that were to occur, EPs, EHs, and CAHs that had adopted these EHR Modules would be at a disadvantage. Given the revised CEHRT definition and the fact that EPs, EHs, and CAHs do not necessarily need to have the same quantity of EHR technology certified to the 2014 Edition EHR certification criteria as they would have under our prior CEHRT definition, we believe that this could reduce the potential burden assumed by this commenter and, depending on its customer base, reduce the need to seek Complete EHR certification in the first place.

Comment. A commenter asked that we confirm whether it would be permissible for an EHR Module presented for testing and certification get certified to the automated measure calculation certification criterion instead of the automated numerator certification criterion.

Response. Yes, this approach is permitted and encouraged in instances where EHR technology developers have developed a sufficiently large EHR Module such that it could meet the automated measure calculation certification criterion for all of the capabilities it includes and that correlate to percentage-based MU measures. We clarify that this approach would satisfy the EHR Module certification requirement specified in § 170.550(f)(1). Where possible, we encourage EHR technology developers to follow this approach in order to provide EPs, EHs, and CAHs with the most efficient means of identifying the numerators and denominators for an MU EHR reporting period. We also note that it is also permitted and encouraged for EHR technology developer to seek certification for a combination of automated numerator and measure calculation certification criteria where the EHR Module may have a reliable and known denominator that can be used as the basis for calculating certain percentage-based MU measures.

• Non-Percentage-Based Measure Use Report (not adopted)

In the Proposed Rule, we proposed to adopt a certification criterion at § 170.314(g)(3) that would have applied to any EHR technology presented for certification that included capabilities associated with MU objectives and measures that were not percentage based. We noted that this certification criterion would focus on a Complete EHR's or EHR Module's capability to record that a user had certain EHR technology capabilities enabled during an EHR reporting period and had used those capabilities to demonstrate MU. Further, we stated that in consultation with CMS, we believed that EPs, EHs, and CAHs would benefit from this type of capability being required as a condition of certification and that such a capability could provide EPs, EHs, and CAHs with valuable evidence in the event of a MU audit. We proposed that any EHR technology presented for certification to any one of the following certification criteria would need to be certified to this certification criterion.

Comments. Several commenters opposed this proposed certification criterion and suggested that it was unduly burdensome. Many indicated that we had significantly underestimated the complexity involved with accurately capturing this information. Commenters cited several examples and noted that this proposed certification criterion required different analysis far beyond just “yes/no” settings for many of the certification criteria listed above. They noted that the use of eMAR is not an on/off step and questioned how we expected enabling “ongoing submission” for public health reporting to be recorded. Commenters stated that requiring this certification criterion would take away from the EHR technology development time necessary to address the certification criteria that were necessary to support MU objectives and associated measures. Last, commenters indicated that the fact the capability was active should be sufficient for MU, as well as attestation, because there is not a separate requirement in MU associated with the frequency each particular capability is used.

Response. In response to commenters' feedback we have not included this proposed certification criterion in the final rule. We acknowledge some of the complexities raised by commenters and that additional aspects as well as specificity would be necessary for a more effective certification criterion. However, we continue to believe in the spirit and direction of this certification criterion so that ultimately EPs, EHs, and CAHs could be in a position to electronically report even the non-percentage based MU objectives and measures. In light of the questions raised by stakeholders we intend to engage the HITSC and HITPC on how to best reach this goal.

• Safety-Enhanced Design and Quality Management System

Safety-enhanced Design

In the Proposed Rule, we provided an overview of the ISO definition of usability as “[t]he extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.” We outlined that EHR technology certification could introduce some improvements in usability, which we believed would enhance both the safety and efficiency of CEHRT. In the Proposed Rule, we also reviewed the November 2011 Institute of Medicine (IOM) report titled, “Health IT and Patient Safety: Building Safe Systems for Better Care,” in which the usability of EHR technology and quality management was often referenced. The IOM noted that “[w]hile many vendors already have some types of quality management principles and processes in place, not all vendors do and to what standard they are held is unknown.” The IOM recommended that “[t]he Secretary of HHS should specify the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability.”

We proposed that a significant first step toward improving overall usability would be to focus on the process of user-centered design (UCD). While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” we expressed that it would be inappropriate for ONC to seek to measure EHR technology in this way. Recognizing that EHR technologies exist and are in use today, we prioritized eight certification criteria and associated capabilities to which the proposed certification criterion would require UCD to have been applied. We chose these eight because we believed they pose the greatest risk for patient harm and therefore the greatest opportunity for error prevention. As proposed, this approach was designed to limit this certification criterion's potential burden.

We proposed that the methods for how an EHR technology developer could employ UCD are well defined in documents and requirements such as ISO 9241-11, ISO 13407, ISO 16982, and NISTIR 7741. We proposed that it would be best to enable EHR technology developers to choose their UCD approach and not to prescribe specific UCD processes that would be required to meet this certification criterion. Thus, the use of any one of these processes to apply UCD would meet this certification criterion. We acknowledged and expected that EHR technology developers who have already followed UCD in previous development efforts for the identified certification criteria would be performing a retrospective analysis. However, if UCD had not been previously applied to capabilities associated with the certification criteria, the EHR technology would ultimately need to have such UCD processes applied before it would be able to be certified. We proposed that testing to this certification criterion would entail EHR technology developers documenting that their UCD incorporates all of the data elements defined in the Customized Common Industry Format Template for EHR Usability Testing (NISTIR 7742). We noted that with respect to demonstrating compliance with this certification criterion that this information would need to be available to an ONC-ACB for review, but that the form and format for how the data would be presented for testing would not necessarily need to be according to NISTIR 7742 (i.e., an EHR technology developer could capture information specified in NISTIR 7742 without having to use the template). Finally, we indicated that this documentation would become a component of the publicly available testing results on which a certification is based.

Comments. A majority of commenters strongly urged ONC to include this proposed certification criterion in the final rule. We note, however, that of all of the proposed certification criteria, this one appeared to be the most polarizing. Provider organizations, hospitals, and consumer advocates supported its inclusion in certification and most (but not all) EHR technology developers expressed some form of opposition—with concern about the public availability of user-centered design testing results.

Many commenters expressed support for our proposal adding, in many cases, arguments about the critically important role that usability plays in the aspect of the safety and reliability of EHR systems, noting that if usability is not carefully analyzed it can cause design induced errors. Other commenters were clear that they felt the results of UCD and quality systems testing should not be made publicly available, and that doing so would open the door for EHR developers' intellectual property to be misappropriated. Some commenters were simply opposed to this criterion, citing an unnecessary burden on the industry.

Many commenters supported our proposal to not specify certain standards or requirements for UCD processes. Commenters also agreed with our proposal to require that the documentation for how UCD was applied in the software development process would be publicly available. These commenters noted that this transparency would foster EHR technology developer competition to make UCD a competitive advantage, thus spurring innovation, improving clinician adoption, and enhancing patient safety. These commenters also suggested that the proposed certification criterion would not compromise innovation nor require the release of intellectual property. Most commenters agreed with the decision not to include NISTIR 7804, and asked for clarification regarding the proposed CIF template (NISTIR 7742) and which specific elements are required. One commenter asked for clarification of the testing methods, and whether self-attestation would be sufficient for consumers and purchasers of Certified EHR Technology.

Many commenters quoted an AHRQ report as follows, “Usability studies are often difficult to generalize or transfer across settings, in part because medication management health IT (MMIT) effectiveness is linked strongly to the culture, institutional leadership, and other situation specific factors. Therefore, applicability of findings related to usability is problematic in MMIT applications.” Along those lines, they suggested a slight alternative to what we proposed by suggesting that EHR technology developers attest to and document their current processes for incorporating UCD practices into their software design, as well as any UCD approaches used for currently certified products, but not be required to have the findings published publicly. These commenters also suggested that summative testing, as used in the referenced NIST template, can catch the most basic usability errors, but is unlikely to have a significant impact on patient safety relative to cost. These commenters advised that we broaden the criteria to include other, formative UCD techniques instead of just summative testing as valid for certification. Finally, these same commenters expressed strong objections to the requirement for retrospective UCD analysis and application. Many commenters were supportive of our identification of several applicable UCD standards, but requested some changes including the replacement of ISO 13407 with ISO 9241-11, and the addition of ISO/IEC 62366 and ISO 9241-210.

One commenter asked for clarification on what was meant by “retrospective analysis” and whether it means summative testing or simply asserting and providing evidence that a UCD process was followed. Many commenters agreed that EHR technology developers should be able to choose the UCD approach that best supports their design principles and products, adding that this would help minimize the burden of testing and will raise awareness on the importance of usability from end-users. One commenter noted that usability is a quality of interactive software that can be objectively defined and evaluated. This commenter suggested that we adopt the following standards for EHR technology certification: Standard 13407, UCD/NISTIR 7804, ISO Standard 25062, and Common Industry Format for Summative Usability Tests NISTIR 7742. This commenter noted that some EHR technology developers have published objections that the scope of this type of testing would be unrealistic for an EHR that would be used in a wide variety of conditions, but also noted that by limiting the scope to eight high priority certification criteria identified in the Proposed Rule mitigates any such concerns.

One commenter expressed disagreement with the component of the proposal that would require all testing elements to be made public and strongly argued that this part be removed from the final rule. This commenter stated that this equates to the public disclosure of trade secrets and other proprietary information may force EHR technology developers that are publicly-traded to violate their obligations to shareholders, as defined in regulations enforced by the Securities and Exchange Commission (SEC) that govern the disclosure of both financial and non-financial information.

One commenter expressed the opinion that UCD is subjective, while several others request clarification regarding this proposal and ask if this certification criterion will allow each EHR technology developer to implement the UCD approach which best suits their development methodology.

Response. We thank commenters for the detailed and thoughtful responses. We agree with those commenters who saw this proposed certification criterion as an important way to improve both EHR technology design and safety. Therefore, we have adopted this certification criterion as proposed. We disagree with commenters who argued that this certification criterion represented an unnecessary burden. However, in response to those comments, we have issued several clarifications to better explain the certification criterion's intent and the requirements that are necessary to demonstrate compliance with this certification criterion.

To demonstrate compliance with this certification criterion, UCD must have been applied to each capability of an EHR technology that is associated with the eight certification criteria named in this certification criterion. We clarify that the application of UCD is limited to only those eight certification criteria specified in this certification criterion and for which certification is sought. For example, if an EHR Module is presented for certification and includes capabilities to which this certification criterion would apply, but for which certification is not sought, then those other capabilities for which certification is not sought would not have to have had UCD applied because they would be beyond the scope of the EHR Module's certification.

We clarify that what we meant by “retrospective analysis” is that an EHR technology developer would not necessarily have to initiate new UCD analysis to meet this certification criterion if they had already completed UCD for the capability in the past. In other words, if an EHR technology had never applied UCD to the capabilities to which this certification criterion applies then UCD would need to be completed before that EHR technology could be certified. However, if UCD had been applied to an EHR technology for the capabilities relevant to this certification criterion, UCD would not need to be redone and an EHR technology developer could provide the required information specified by NISTIR 7742 that reflects the UCD that they had previously completed. We make this clarification to acknowledge that many EHR technologies are designed to follow standard UCD processes and we did not intend to disregard that prior work. We also believe this clarification will help assuage commenters' concerns about the potential burden posed by this certification criterion.

The method(s) that could be employed for UCD (e.g., ISO 9241-11, ISO 13407, ISO 16982, and NISTIR 7741) and that were listed in the Proposed Rule are examples of resources that EHR technology developers may choose to review in order to select a UCD. We agree that ISO/IEC 62366 and ISO 9241-210 are also acceptable alternatives. Any UCD process selected by an EHR technology developer is appropriate, and it need not be listed in the examples we provided in order to be acceptable. We do, however, strongly advise EHR technology developers to select an industry standard process because compliance with this certification criterion requires submission of the name, description, and citation (URL and/or publication citation) of the process that was selected. In the event that an EHR technology developer selects a UCD process that is not an industry standard (i.e., not developed by a voluntary consensus standards organization (VCSO)), but is based on one or more industry standard processes, the developer may name the process(es) and provide an outline of the process in addition to a short description. Submission of the information specified in the NISTIR 7742 template will need to be submitted for each and every one of the applicable eight certification criteria specified in this certification criterion and for which certification is sought. This information will become part of the EHR technology's test report that is required to be made publicly available.

The following information/sections in NISTIR 7742 are required for submission:

• Name and version of the product
• Date and location of the test
• Test environment
• Description of the intended users
• Total number of participants
• Description of participants: their experience and demographic characteristics
• Description of the user tasks that were tested
• List of the specific metrics captured during the testing for effectiveness, efficiency and satisfaction
• Data scoring
• Results of the test and data analysis
• Major test findings
• Identified area(s) of improvement(s)

There are illustrative tables on pages 11 and 20 of the NIST 7742 document that may not need to be populated, depending on the tasks tested. We clarify that all of the sections specified above must to be completed, including “major findings” and “areas for improvement.” We note that EHR technology developers can perform many iterations of summative user testing. Thus, the submission that is ultimately provided for testing and certification may be the expression of a final iteration in which few areas for improvement would be identified. We do not expect EHR technology developers to include trade secrets or proprietary information in these reports. We disagree that UCD is subjective, and have offered several examples of industry standard UCD processes above. Regarding one commenter's concern that the publication of usability testing may violate SEC regulations regarding public disclosure, this commenter provided no additional detail as to why this would pose a conflict with SEC regulations, nor did it cite a particular SEC regulatory provision that they believed was in conflict with the proposed certification criterion. We are unaware of any provision that would result in EHR technology developers violating any SEC regulations.

Comments. One commenter expressed support for the certification criterion, but disagreed with the assumption that user interface (UI) validation testing must be performed by end-users. This commenter's experience was that UI validation tests performed by internal design experts are more effective than the same testing performed by end-users. This commenter reported that engineering a UI to the needs of a user who is encountering that interface for the very first time, invariably results in an interface designed to accommodate the novice, at the expense of denying power and efficiency to the same user who will quickly gain familiarity with a well designed interface.

Response. The NISTIR 7742 includes several sections: Executive Summary, Introduction, Method, Results, and Appendices. In each of these sections, there are required data elements—and some of these elements call for the expression of the number of study participants, their level of experience with EHR technology, and other pertinent details. Regarding comments about the participants of usability testing, many UCD processes incorporate involvement of end-users in formative and summative testing. The cohort of users who are selected as participants will of course vary with the product and its intended users.

Comments. One commenter supported this criterion, but expressed concern that testing in a lab setting would be insufficient and would need to be augmented by field testing as well, advocating for provisional certification for this certification criterion until it had been implemented and tested in the field.

Many commenters expressed support for this criterion, stating agreement that EHR technology developers should conduct usability testing. One commenter suggested that usability testing be conducted and mandated by a third party such as a Sharp C grant recipient, and strongly recommending standardization of EHR data output to make the transfer of data more seamless, less administratively burdensome, and less costly.

One commenter suggested that ensuring usability is the key to successful physician adoption of EHRs, yet expressed concern that our proposals as drafted gave no consideration as to the clinician decision-making process or practice workflow.

One commenter expressed concern that the adoption of a particular methodology does not guarantee that software will improve. Other commenters suggested that the testers would need to be selected who are professionals already familiar with more than one EHR technology and are in the same specialty as the target market of the EHR technology developer.

One commenter contended that the NISTIR 7804 would be appropriate, and advocated for its inclusion as a certification requirement.

Many commenters suggested that we enhance our usability testing requirements beyond what was described in our proposed rule such as: (1) Requiring the collection of data based on an EHR user (physician) satisfaction survey that can be included in the attestation phase of the MU program; (2) collecting and disseminating survey results on usability experiences based on practice size, specialty type, and geographic location, and incorporation of this feedback into future certification processes; (3) including usability and patient safety criteria into the certification process as discussed in the IOM report; (4) promoting innovation in EHR technology design that not only addresses patient safety and usability, but can be more seamlessly integrated into smaller practices that do not have the luxury of resources to completely redesign the way they work to accommodate the EHR; (5) seeking industry feedback—including physician feedback—on what constitutes an appropriate level of risk as it relates to patient safety; and (6) applying the principles in the NISTIR 7804 to the entire EHR certification process.

Response. We thank these commenters for their thorough and thoughtful feedback. Although the implementation of suggestions 1 through 5 may provide a better understanding of EHR usability today and chart a path toward improved usability in the future, they fall outside the scope of this certification criterion. We have not included NISTIR 7804 in the 2014 Edition EHR certification criteria, but may consider it for future editions of certification criteria. We do believe that UCD will—by definition—consider the clinical decision-making process and disagree with the commenter that it does not. Finally, we agree that both formative and summative testing are valuable, and we agree that testing in a lab setting and testing in the field are also important. This certification criterion is a first step toward formal usability testing becoming part of the culture of EHR technology development. We therefore clarify that, at a minimum, only lab-based summative testing is necessary to be performed in order to demonstrate compliance with this certification criterion. Nothing precludes field-testing and formative testing from also being performed and we encourage EHR technology developers to do so.

Quality Management System

In the Proposed Rule we noted that the IOM had also recommended that we “[establish] quality management principles and processes in health IT.” We stated that, working with other Federal agencies, we intended to publish a quality management document that would be customized for the EHR technology development lifecycle and express similar principles to those included in ISO 9001, IEC 62304, ISO 13485, ISO 9001, and 21 CFR part 820. We anticipated that this document would provide specific guidance to EHR technology developers on best practices in software design processes in a way that mirrors established quality management systems, but would be customized for EHR technology development We stated that we understood that some EHR technology developers already have processes like these in place, but did not believe, especially in light of the IOM recommendation, that the EHR technology industry as a whole consistently follows such processes. We indicated our expectation to publish the quality management document around the same time as the Proposed Rule would be available for public comment. We indicated that we were considering including an additional certification criterion in the final rule that would require an EHR technology developer to document how their EHR technology development processes either aligned with, or deviated from, the quality management principles and processes that would be expressed in the document. We emphasized that this certification criterion would not require EHR technology developers to comply with all of the document's quality management principles and processes in order to be certified. Rather, to satisfy the certification criterion, EHR technology developers would need to review their current processes and document how they do or do not meet the principles and processes specified in the document (and where they do not, what alternative processes they use, if any). We stated our expectation that this documentation would be submitted as part of testing and would become a component of the publicly available testing results on which a certification is based.

We explained that we were considering adopting this additional certification criterion as part of the 2014 Edition EHR certification criteria for three reasons. First, all EHR technology developers that seek certification of their EHR technology would become familiar with quality management processes. Second, the public disclosure of the quality management processes used by EHR technology developers would provide transparency to purchasers and stakeholders, which could inform and improve the development and certification of EHR technology. Last, EHR technology developers' compliance with the certification criterion would establish a foundation for the adoption of a more rigorous certification criterion for quality management processes in the future without placing an immediate significant burden on EHR technology developers. We requested public comment on this additional certification criterion and the feasibility of requiring EHR technology developers to document their current processes.

Comments. Most comments supported our proposal to adopt a certification criterion for quality management practices. Several commenters expressed concern that the quality management systems document referenced in our proposal was not available for review during the public comment period as we had proposed. Many commenters expressed concern that public availability of the documentation produced for this certification criterion might reveal proprietary and confidential software information.

Other commenters expressed support for having quality management systems in place and the general approach proposed of describing the nature of each EHR technology developer's quality processes. These commenters also expressed that the proposal is preferable to a specific requirement for EHR technology developers to adopt a particular quality management system.

One commenter observed that due to the recent FDA rule for Medical Device Data Systems (MDDS), they are actively implementing these quality principles across their enterprise development projects and believe that the use of quality management systems will help to: Improve traceability of clinician requirements to EHR system features, keeping requirements at the forefront; improve consistency of development and commissioning activities and thus increase the ability to predict when EHR system updates will become available to the clinicians; and lower the overall cost of quality by minimizing a whole range of failure costs. This commenter also noted additional advantages of quality management systems including: The opportunity to clarify roles and responsibilities in the development organization allowing more precise definition of scope, schedule, and resources needed to develop its clinical systems; improved visibility into the development project progress, providing greater predictability of when resources assigned to projects will be available for other strategic priorities; highlight needs for communication and safety/risk discussions on critical issues; and creation of ownership of quality at all levels of the organization.

One commenter did not support the requirement to provide a gap analysis as part of the certification, due to the fact that this commenter's EHR technology is comprised of many disparate self-developed modules spanning multiple years of development and use, multiple teams and multiple technologies where consistent processes were not performed. This commenter also expressed concern that the publication of this analysis is irrelevant to organizations that develop their EHR technology and do not sell it to others. Finally, this commenter stated that they are already familiar with quality management systems and are actively tightening up their software development lifecycle processes and other QMS related activities to become compliant with the FDA MDDS rule.

One commenter stated that they are actively implementing a quality management system, and that disclosing where [they] are in this process to an agency that currently does not have jurisdiction in this area would add no value. Several commenters expressed that they would not support any requirement that did not align with international standards such as ISO-62304, ISO-14971, ISO-13485, or with FDA's quality system regulation in 21 CFR part 820.

Some commenters noted that the work required to meet this requirement will be very time consuming and costly to provide a formal assessment on each of the legacy development processes that have been employed, and that the review for certification should focus on new development rather than historical development. They stated that certification bodies could perform a spot check quality management systems audit on new processes instead of requiring EHR technology developers to retrospectively define old processes. The commenter expressed that this would be far less burdensome and would allow EHR technology developers to appropriately focus efforts on future development efforts, not past work.

Several commenters agreed that it is important for EHR technology developers to follow rigorous quality management systems and welcomed the inclusion of a quality management systems certification criterion. These commenters suggested that optimal quality management systems for EHR technology should expressly permit modern “Agile” development processes, as Agile processes can efficiently yield higher quality software than traditional methods. A commenter also noted that some of the existing quality management regimes referenced (ISO 9001, IEC 62304, ISO 13485, and 21 CFR part 820) predate the development of Agile software development methodologies and were written assuming an old-fashioned stage-gate “waterfall” software development process. The commenter stated, for example, that while medical device manufacturers have begun to successfully embrace Agile there has been some confusion about whether Agile processes are even allowed under 21 CFR part 820. This commenter argued that a modern quality management system for EHR technology should expressly permit Agile software development, and should set high-level requirements for software development process and work-product, without unnecessarily constraining the order in which particular process steps are followed. Comments indicated that a quality management system certification criterion should cover the processes associated with custom software development. They stated that unlike other medical devices covered by the quality management systems mentioned (IEC 62304, ISO 13485, and 21 CFR part 820), EHR technology implementations often involve a substantial amount of custom, site-specific, software (including templates, interfaces, and custom code).

One commenter expressed agreement with IOM that it would be useful to establish “quality management principles and processes in health IT.” This commenter supported the proposed gradual introduction of a generic quality management system certification criterion with key requirements called out. They suggested that a gradual introduction would support those EHR technology developers who already have quality management systems in place without requiring them to rip and replace to conform to a “standard” quality management system that may not offer any significant improvement over what they already have in place. These commenters also stated that it is important for EHR technology developers who are currently following one of the existing ISO or FDA standard processes not be disadvantaged by new MU equivalencies.

Response. We appreciate the very thorough and thoughtful comments on our proposal to adopt a quality management system (QMS) oriented certification criterion. We share the sentiments expressed by commenters that selecting and implementing an optimal quality management system (QMS) for EHR technology development can be complex. We agree that existing standards may not explicitly state support for agile development methodologies and that such methods may be part of an optimal QMS. We appreciate the detailed comments that offered guidance regarding the optimal components of an ideal QMS for EHR technology and we agree with many of these suggestions. Because we were unable to publish the quality management document referenced in the Proposed Rule we recognize that there was an insufficient opportunity to comment on this document and have not included an explicit requirement to use this document.

We agree with the many commenters who described the advantages of an incremental implementation of QMS requirements for EHR technology. Additionally, we support the position of the commenters that stated this requirement should strive not to burden EHR technology developers with the task of documenting previous development processes. We disagree with the commenter who believed that this requirement was beyond our authority. The Secretary has the statutory authority to adopt standards, implementation specifications, and certification criteria for HIT and the National Coordinator has the statutory authority to establish a certification program for the certification of HIT to certification criteria adopted by the Secretary. Additionally, we disagree with the commenter with internally developed EHR technology that objected to our proposed gap analysis because we believe that the purchasers of EHR technology are not the only stakeholders who would take interest in the transparency provided by the submission of this information. Patients, employees, business partners, and shareholders of such organizations would be other such interested parties.

In consideration of comments received for and against this proposal, we have decided to adopt a certification criterion in this final rule at § 170.314(g)(4) that will generally focus on QMS and, as suggested by many commenters, is meant to be a first step that can be built on in an incremental fashion. All EHR technology certified to the 2014 Edition EHR certification criteria would need to be certified to this certification criterion, and we have taken steps to ensure that EHR Modules are certified to this certification criterion by revising § 170.550 as discussed in more detail under section IV.C.2 of this preamble.

We have adopted a certification criterion that accounts for the fact that we did not publish the quality management document as we had proposed. The certification criterion we have adopted is more general and provides more flexibility. The certification criterion expresses that for each capability an EHR technology includes and for which that capability's certification is sought, the use of a QMS in the development, testing, implementation and maintenance of that capability must be identified. Unlike our proposal, any QMS may be used to meet this certification criterion and even an indication that no QMS was used for particular capabilities for which certification is requested is permitted. The commenter who stated that they are implementing the FDA's Quality System (QS) regulations (for example, under the MDDS rule) would—by definition—be meeting this certification criterion so long as they cite their compliance with FDA's QS regulations for certification. Given this flexibility, we cannot foresee any reason why this certification criterion cannot be satisfied nor do we believe that it will be a significant burden to indicate the QMS used (or not used) in the development of capabilities for which certification is sought.

We understand that some EHR technology developers have several teams who work on different functional components of EHR technology. In the case where the whole development organization uses the same QMS (or not at all) across all teams, then this certification criterion may be met with one report. Where there is variability across teams, the EHR technology developer will need to indicate the individual QMS' followed for the applicable certification criteria for which the EHR technology is submitted for certification.

We encourage EHR technology developers to choose an established QMS, but developers are not required to do so, and may use either a modified version of an established QMS, or an entirely “home grown” QMS. We also clarify that we have no expectation that there will be detailed documentation of historical QMS or their absence. As specified above, we believe that the documentation of the current status of QMS in an EHR technology development organization is sufficient.

EHR Technology Safety Reporting

We also considered adopting a certification criterion (as mandatory or optional) that would require EHR technology to enable a user to generate a file in accordance with the data required by the Agency for Healthcare Research and Quality (AHRQ) Common Format, including the “Device or Medical/Surgical Supply, including HIT v1.1a.” We requested public comment on whether we should adopt such a certification criterion and what, if any, challenges EHR technology developers would encounter in implementing this capability.

Comments. Many commenters requested that ONC not adopt a certification criterion at this time, but take the opportunity to study the role of EHRs in patient safety incident reporting in order to determine if something more reflective of EHR technology's role in such reporting as a future certification criterion would be appropriate. Many of these commenters also stated that there is insufficient experience with the AHRQ Common Format—especially in the ambulatory domain, and that extension of the Common Format would be necessary for it to be of value. Other commenters expressed additional concerns about the maturity of the Common Format, and the ability of EHR technology to generate the appropriate file format, and whether there would be any near-term value to such reports without more experience with adverse event reporting from EHR technology.

Response. We agree with these concerns and have not adopted a certification criterion for reporting patient safety events according to the Common Formats in the 2014 Edition EHR certification criteria.

• Data Portability

In the Proposed Rule we sought public comment on whether we should adopt a certification criterion to focus on the portability of data stored within CEHRT. We recited the scenario where a provider might seek to change EHR technology (and EHR technology developers). We stated that in such a scenario providers should have the ability to easily switch EHR technology—at a low cost—and migrate most or all of their data in structured form to another EHR technology. We noted that in the absence of this capability, providers could be “locked-in” to their current EHR technology, which could ultimately impede innovation. With our belief that data portability is a key aspect of the EHR technology market that requires maturity, we sought public comment on specific questions that could inform our decision on whether to adopt a certification criterion focused on data portability. We asked: (1) Whether EHR technology is capable of electronically providing a sufficient amount of a patient's health history using export summaries formatted according to the Consolidated CDA for the scenario described above; (2) whether all of the data in a provider's EHR #1 is necessary to migrate over to EHR #2 in the event the provider wants to switch (We noted that potential effect of medical record retention laws, but sought to determine whether the loss of some data would be tolerable and if so, which data.); (3) considering the standards that have been adopted and proposed for adoption in the Proposed Rule, what additional standards and guidance would be necessary to meet market needs for data portability, including the portability of administrative data such as Medicare and Medicaid eligibility and claims; (4) whether a specific set of patient data could be used as a foundation for an incremental approach to improve data portability for the situation described above as well as other situations; and (5) whether the concept of a capability to batch export a single patient's records (or a provider's entire patient population) poses unintended consequences from a security perspective and what factors should be considered to mitigate any potential abuse of this capability if it existed.

Comments. Commenters strongly supported our efforts to improve data portability, including in the specific provider situation we outlined in the Proposed Rule. Many commenters generally noted that medical record retention laws, as well as those governing fraud and abuse investigations, largely determine the amount and type of information that must be retained, and therefore, needs to be portable. Commenters also noted that there may be other reasons for retaining longitudinal information on patient care, such as clinical trial participation, post approval study requirements and other clinical reasons.

Many commenters stated that some data loss is inevitable, with some commenters noting this was due to variations in clinical content and data schema(s) between EHR systems. Commenters gave varying responses on what specific data would be important to migrate to a new EHR. Some commenters stated the decision would be situational, best left to the provider, or, as previously noted, based on medical records retention laws and requirements. Commenters stated that demographics, problems, medications, medication allergies, allergies, immunizations, vital signs, lab results, and encounter notes would fall into the category of “not tolerable” to lose in transfer. For all “other” data, commenters stated that it would be sufficient for the data to be accessible in a human readable form through, but not necessarily stored within, the EHR. A few commenters also stated that documentation metadata should be readily available for all databases. Some commenters stated that the loss of data at a granular, visit-oriented level would be tolerable. Other commenters stated that because administrative data is normally stored in practice management systems—and not in EHRs—it would not need to be transferred from one of these systems to another.

One commenter suggested an incremental approach starting with requiring indexed and searchable documents including visit notes, letters, and reports. The commenter noted that this might require manual addition or automated generation of metadata and might need to include only documents generated after a given date for complete header information. The commenter noted that subsets of the patient's record (records of children must include immunizations and growth data) could be effective, but the commenter emphasized that the summary must be focused on the patient's lifetime data and not the most recent clinical events. Over time, the commenter stated that external standards for data portability would govern the internal structure of data within an EHR so that data can be exported and imported without data loss. The commenter stated that a good example is retention of laboratory results in LOINC® codes after import so that they can be exported in the future and used in a different EHR to identify data elements needed for clinical decision support or clinical quality measures.

Commenters stated that the Consolidated CDA would not be capable of sufficiently capturing all patient information that would be needed. Commenters stated that the Consolidated CDA is designed to be a summary and would not capture longitudinal patient information, administrative billing data, or other necessary data (e.g., trend analysis, operational data, and master file data). A few commenters noted that the CDA does not support the inclusion of information on whether meaningful use measures were applicable to or addressed for patients. Other commenters stated that CDA document types may not be the most efficient means to migrate data from one EHR to another. These commenters further stated that it is critical that such migration happens as quickly as possible. Therefore, the commenters contended that other data transfer mechanisms would be better suited for that purpose, particularly when large data volumes are in play (e.g., large multi-provider entities migrations).

A commenter stated that one possible solution would be to require EHR technology developers to tag key data elements that would typically be moved in an EHR transition with standardized XML. EHR technology developers would also need to be able to receive and process data feeds with this standardized XML, storing it in their native tables.

A few commenters stated that batch migrations are one of the more typical migration methods used when a provider moves from one EHR to another. Some commenters stated that batch exports of a patient's record poses serious security risks, while other commenters stated that current safeguards exist. These commenters pointed to the use of business associate agreements, encryption, and the use other internal controls to mitigate any security concerns.

Response. We thank commenters for the depth and breadth of their responses to our questions and proposals. In consideration of comments received, we have adopted a certification criterion for data portability. As discussed later in this final rule, we have also included this certification criterion as part of the Base EHR definition in order to ensure that all EPs, EHs, and CAHs, have this capability as part of the EHR technology they use to meet the CEHRT definition. While we recognize that no “silver bullet” exists with respect to data portability, we strongly believe that more attention must be paid to this market challenge and that with the interests of EPs, EHs, and CAHs in mind, small steps can be taken to improve the data portability between EHR technologies. We intend for this certification criterion to be a starting point and have framed it in such a way as to leverage capabilities that will already be included in an EP, EH, and CAH's CEHRT.

The certification criterion leverages and requires the same capabilities specified in the “transitions of care—create and transmit transition of care/referral summaries” certification criterion at § 170.314(b)(2)(i). The only difference between the capability specified in the data portability certification criterion and the capability specified in the transitions of care certification criterion is that the data portability certification criterion expressly limits the scope of the data to the most current clinical information about each patient for which an export summary is created. For the purposes of certification and for all of the patients on which an EP's, EH's, or CAH's CEHRT maintains data, the EHR technology must enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the Consolidated CDA that includes each patient's most recent clinical information. While this is the minimum capability required for certification, we encourage EHR technology developers to include patients' longitudinal information for laboratory test results, immunizations, and procedures, and intend to consider including this broader requirement in the next edition of this certification criterion. We believe this initial capability provides a strong starting point for the fluid transition from one EHR technology to another. Primarily, we anticipate that this capability will be enable transitions to be more efficient by reducing the need for EPs, EHs, and CAHs to manually re-enter all of their patients' recent data into a new EHR system.

b. Ambulatory Setting

We propose to adopt 3 certification criteria that would be new certification criteria for the ambulatory setting.

• Secure Messaging

We proposed the 2014 Edition EHR certification criterion for secure messaging (at § 170.314(e)(3)) to support the MU objective and measure recommended by the HITPC and proposed by CMS. We agreed with the direction provided by both HITSC recommendations and merged the two into a refined proposed certification criterion. We also proposed to include in the certification criterion a baseline standard in terms of the encryption and hashing algorithms that would need to be used to implement secure messaging. More specifically, we proposed that only those identified in FIPS 140-2 Annex A be permitted to be used to meet this criterion and proposed to adopt a new standard in § 170.210(f) to refer to FIPS 140-2 Annex A's encryption and hashing algorithms. Additionally, we referenced several standards and implementations specifications that EHR technology developers could use to implement various secure messaging approaches, including IETF RFC 2246 (TLS 1.0), SMTP/SMIME, NIST Special Publication 800-52 (“Guidelines for the Selection and Use of TLS Implementations”), and specifications developed as part of nationwide health information network initiatives.

Comments. Several commenters conveyed that the certification and testing process would need to accommodate the range of messaging mechanisms permitted by CMS, while being certified within the proposed standards. One commenter asked if there were approved modes of electronic messaging and whether secured and encrypted email would be a method. Another stated that use of a secure messaging capability from within a portal application should be an acceptable method. One commenter recommended that we equally support the standards and specifications developed as part of the NwHIN Exchange with the intent to support the broadest possible adoption of health information exchange capabilities. Other commenters generally requested that we provide some examples of common access mechanisms and acceptable security protocols. Another commenter suggested that we consider particular transport methods be certified similar to the certification criteria discussed in the Proposed Rule that referenced the Direct specifications and other acceptable transport methods. One commenter stressed the importance of adequate privacy and security, but urged ONC to take a reasonable approach and not make the use of secure electronic messaging to communicate with patients unduly burdensome. One commenter stated that functionality such as a patient portal would be handled through normal browser HTTPS functionality and, therefore, should be easily managed through a visual inspection and should not require additional verification. One commenter supported secure messaging in general, but did not support secure email as the only secure messaging methodology. The commenter indicated that they currently send patients an unsecure email prompt that they have a message and that upon receipt the patient can securely log-in to their patient portal using an SSL-protected session to retrieve the message and send new ones.

Response. We share commenters' sentiment that this certification criterion needs to permit/accommodate a range of possible innovative options. To that end, we intentionally proposed this certification criterion to only specify the particular baseline security and functional capabilities we believed were necessary to require for certification. So long as the method included with EHR technology presented for certification can meet these baseline requirements it would be able to meet this certification criterion. Thus, secure email, a secure portal, even some type of mobile application could all be examples for secure messaging methods that could potentially meet this certification criterion. Along those lines, we decline to specify or restrict certification in this case to a particular transport standard because, again, we intend to permit a wide range of different secure messaging solutions, that will likely use different approaches and transport standards.

In consideration of these comments and the ones responded to below, we are finalizing this certification criterion as proposed with one exception. The only modification we have made is to explicitly note as we already have in the view, download, and transmit to a 3rd party certification criterion that it could be the patient or their authorized representative that engages in secure messaging.

Comment. A commenter stated that patients must be able to directly communicate with health professionals via patient portals and OAuth.

Response. We decline to incorporate this suggestion into the certification criterion because it would be unnecessarily limiting. Our response, however, is not meant to preclude this type of functionality from being used to satisfy this certification criterion.

Comment. A commenter questioned how the capability to receive a secure message from a patient would be tested and what we intended to be certified. They asked whether it was a provider application that would be used to send and receive secure messages or a consumer application to do the same; or both. Further, the commenter stated that an EHR technology developer presenting EHR technology for certification may not have a patient portal or PHR technology from which to demonstrate the sending of a message to the EHR technology and that testing using a public email service is likely not to meet the FIPS 140-2 Annex A requirement for encryption. The commenter also indicated that the certification criterion presumes the EHR technology developer has a technology to support the consumer and that the EHR technology developer must have both abilities (send and receive) within its span of control to be able to present technology for certification. Ultimately, the commenter suggested that either the provider requirement to send a message be removed or that this be split into two criteria. They reasoned that from a measurement perspective, only the “receive” from the provider perspective is required by the Stage 2 proposed rule for the associated objective, and the measurement numerator is based on a consumer perspective and the vendor having access to event data that may only be available in a portal or similar consumer application. As an alternative to certifying send and receive as two distinct criterion (or even as a single criterion to help EHR technology developers who may only automate provider or consumer messaging), the commenter suggested that ONC consider working with NIST to provide a test harness for vendors to certify with to prove messages are successfully sent and received.

Response. The EHR technology that enables secure messages to be exchanged is what would be required to be tested and certified. Thus, whatever would be necessary for a patient to communicate with an EP (and vice versa) would need to be demonstrated for testing and certification. We do not believe that separating the capability for communication by send and receive would add any significant value or provide any additional benefit because it is the capability as a whole (to send and receive secure messages) that needs to be demonstrated for testing and certification in order for EPs to have assurance that EHR technology can enable bidirectional communication. We thank the commenter for the recommendation to work with NIST to develop testing methods that ensure messages can be successfully sent and received. We will take this recommendation under consideration in discussions with NIST and when approving a test procedure for this certification criterion. Finally, we note that to keep the final rule as current as possible at the time of publication, we have referenced the May 30, 2012 version of Annex A. The May 30, 2012 version replaces the version we adopted in the S&CC July 2010 final rule and is the only readily accessible version available. Further, NIST has included additional reference guidance for the AES standard as well as updated references to other FIPS publications that have been updated, such as changing the reference to FIPS 180-3 to FIPS 180-4.

Comments. One commenter supported the proposed certification criterion but requested clarification on the reference to the standard, which they noted is a collection of many standards in several categories. They asked if we could clarify which specific parts of FIPS Annex A are applicable to secure messaging. In addition, the commenter asked how the additional guidance we provided in the preamble related to the standard we proposed to adopt. They requested clarification as to whether we intended to say “FIPS 140-2 Annex A plus TLS 1.0 and SMTP/SMIME and * * *.” or whether something else was intended.

Response. As noted in the standard proposed just the encryption and hashing algorithms are in scope. Random number generator standards would not necessarily be within scope. The other guidance we referenced in the Proposed Rule is just that. It was not intended to be part of the standard as questioned by the commenter.

Comment. One commenter recommended that we discourage the use of or remove the allowance for 3DES as the encryption algorithm is on track to be deprecated by NIST in the near future.

Response. We agree, please see our response to similar comments in the “end-user device encryption” certification criterion.

Comment. One commenter recommended that we investigate evolving secure email and other supporting technologies to protect and verify transactions that include personally identifiable health information. They noted that current Direct Project guidance requires the use of organizational PKI certificates for which the FBCA does not include a profile in its certificate policy. They stated that certificates cited in the Direct project documentation also suggest that the encryption, digital signature and non-repudiation bits all be turned on and that this requirement is an unacceptable practice under the terms of RFC 3647. They concluded by recommending that federally approved NIST LOA 3, 2-factor credentials for patients to authenticate to secure email and or/or portals should be used to fulfill this requirement.

Response. At this point, we decline to include such a specific requirement as part of this certification criterion. As the industry gains more experience with different secure messaging approaches, we will consider whether additional specificity such as this is necessary.

Comments. A few commenters stated that because CMS' proposed rule left it to the provider to determine the “relevance” of information, the capability to assess or document relevance should not be in the automated measure calculation certification criterion nor be part of this certification criterion.

Response. Certification does not address the relevance of the information that is part of a secure message. Please see CMS's discussion related to secure messaging in the Stage 2 final rule published elsewhere in this issue of the Federal Register.

• Cancer Case Information; and Transmission to Cancer Registries

We proposed to adopt two new 2014 Edition EHR certification criteria to support a new proposed MU objective and measure for reporting cancer cases to cancer registries. One certification criterion focused on the capability to electronically record, change, and access cancer care information (data capture) and the other certification criterion focused on the capability to electronically create cancer case information for electronic transmission in accordance with specified standards. Following consultation with the Centers for Disease Control and Prevention (CDC), we proposed to adopt HL7 CDA, Release 2 as the content exchange standard. Additionally, we proposed to adopt the Implementation Guide for Healthcare Provider Reporting to Central Cancer Registries, Draft, February 2012. We stated in the Proposed Rule that the CDC would consider comments received on the Proposed Rule in finalizing the guide. We also stated that if the CDC finalized the guide, we would consider adopting the final version of the guide in this final rule with consideration of public comment received on the appropriateness of the guide for certification. Last, we proposed to adopt SNOMED CT® International Release January 2012 and LOINC® version 2.38 as applicable vocabulary standards.

Comments. Commenters expressed strong support for the proposed certification criteria. Many of the commenters that supported the certification criteria stated that they believed this requirement would increase cancer reporting and improve it in various ways, including improving the timeliness, efficiency, completeness, and quality of the data reported as well as reducing the reporting burden on ambulatory providers.

While many commenters supported the proposed certification criteria, many also requested that the certification criteria be designated “optional” for Complete EHR certification. The commenters requesting that the certification criteria be designated optional claimed that the certification criteria would only be relevant to a small number of providers who report to cancer registries. Further, they contended that the capability would be inappropriate for inclusion in EHR technologies that are not focused on meeting the needs of EPs who will report to cancer registries, since some of the cancer case information data utilizes extensive cancer-specific, specialized fields and vocabularies (e.g., NAACCR data standards) that are not typically captured in EHRs beyond those specifically marketed as oncology specialty products. A couple of commenters noted that few, if any, EHR technology developers provide this functionality, and most applications that are used for this purpose are not likely to meet the standard cited in the Proposed Rule. A few other commenters stated that this requirement is burdensome and should not be required.

Response. We appreciate the support expressed by commenters. We also agree with commenters that it is appropriate to designate these certification criteria as optional. By designating the certification criteria as optional, EHR technology would not need to be certified to these certification criteria in order to satisfy the Complete EHR definition. The optional designation will permit EHR technology developers that support EPs intending to report on the associated MU menu objective and measure to still get certified to these certification criteria, but will alleviate the requirement that all Complete EHRs be certified to these certification criteria. Designating these certification criteria as optional will mitigate any perceived unnecessary costs and burden mentioned by commenters. To clarify for MU purposes, if an EP seeks to meet the associated MU objective and measure, they will need EHR technology certified to these certification criteria, including the adopted standards and implementation guide, in order to have EHR technology that meets the CEHRT definition.

Comments. Many commenters supported the adoption of the proposed HL7 CDA, Release 2 and Implementation Guide for Healthcare Provider Reporting to Central Cancer Registries, Draft, February 2012 for registry reporting, stating that they had widespread support from the CDC and cancer registry community. A few of these commenters specifically stated that public health central cancer registries have been operational for many years and the cancer registry community has been preparing for the transition to CDA for some time. Commenters noted that cancer reporting in most jurisdictions requires industry and occupation information and stated that EHR technology certification to support cancer reporting by EPs would facilitate their compliance with applicable law and improve the quality and completeness of cancer reporting. One commenter recommended that cancer laboratory results reporting be included in addition to cancer case reporting.

Many commenters also pointed out that the implementation guide was still in draft format and suggested that it should be finalized before being adopted. A few commenters contended that it was premature to adopt the proposed standard and implementation guide as a basis for certification, stating that the standard was not in widespread use for reporting cancer events to registries from EHRs. One commenter stated that the proposed implementation guide is not harmonized with the Consolidated CDA guide and that harmonization should be completed before we adopted the implementation guide. A commenter stated that centralized cancer registries receive batch reports containing large numbers of cases and that the cancer-related information required by the cancer registries is dense in its level of detail. Therefore, the commenter was concerned that the CDA standard may not provide the necessary content framework or the processing efficiency necessary to transmit and receive complex, bulk data.

A commenter requested that the minimum data elements required for the transmission of cancer case information be explicitly and clearly stated. Another commenter noted concerns that the implementation guide has requirements for structured data capture for social history that may not reflect widespread current practice and, thus, represents a change in practice for EPs. Other commenters stated that there is potential for confusion in coding “occupation” and “industry” because there is a discrepancy between description and language in the implementation guide and the descriptions for the corresponding LOINC® codes. A commenter suggested that the implementation guide needed values for cancer staging variables that allow for “not staged” or “unknown.” The commenter stated that for every required field (R), the value sets should be double checked to make sure that there is a “none” or “unknown” option or the EP's EHR will not have a value all the time.

Response. The implementation guide was jointly developed by the CDC and the North American Association of Central Cancer Registries (NAACCR). It is based on many years of harmonized cancer registry reporting across the country. The finalized implementation guide, Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, Release 1, August 2012, reflects the comments received on the draft and clarifies ambiguities such as minimum data elements required and vocabularies for occupation, stage, and other data elements where none/unknown should be an option. In particular, the use of HL7 null flavor is better described such that it may be used where appropriate to indicate lack of information and clarifications were made to the use case scenarios in response to questions about workflow and triggers. While this implementation guide is based on the CDA, the guide was revised in some aspects to harmonize it with the recently developed Consolidated CDA. The implementation guide was revised to take advantage of the document format used by the Consolidated CDA, including the formatting of the data element tables and conformance statements. The new consensus conformance verbs used in Consolidated CDA (i.e., shall, should, may, and should not) were also adopted in the implementation guide to clarify the optionality of data elements. These improvements resolve the ambiguity on required data elements and vocabularies. Overall, the revisions to the draft implementation guide that have been incorporated into the final (Release 1) improve the ability to test and certify EHR technology to the implementation guide and make it easier for EHR technology developers to implement the guide's requirements based on the corrections and clarifications. Accordingly, we have adopted Release 1 of the implementation guide for the “transmission to cancer registries” certification criterion.

Comments. Commenters generally supported the use of SNOMED CT® and LOINC®. One commenter recommended the use of ICD-9-CM and ICD-10-CM as well since many physician practices work with and are familiar with these standards. Another commenter acknowledged that SNOMED CT® and LOINC® are valuable for much of the required content, but believed the context of data is not necessarily included in these code systems. The commenter further noted additional data requirements (e.g., medications) which will require RxNorm, allergy data (medication in RxNorm, reaction in SNOMED CT®), procedures performed, and patient characteristics to which other sections of this report refer. One commenter stated that for dental systems the HL7 CDA and SNODENT should be required.

Response. We appreciate the support commenters indicated for SNOMED CT® and LOINC® and have adopted them as vocabulary standards for this certification criterion. We acknowledge that the implementation guide references other vocabulary standards, but believe that the vocabulary standards we have adopted in this final rule are the most important to focus on in support of cancer case reporting. We decline to adopt SNODENT for the “transmission to cancer registries” certification criterion for the same reasons we gave when we declined to adopt it for the “problem list” certification criterion in this preamble (section III.A.9.a).

Comments. Commenters noted that both SNOMED CT® and LOINC® code sets are updated regularly. Therefore, for the purposes of certification, commenters recommended that we adopt these standards in regulation as “SNOMED CT®—current international release” and “LOINC®—current release.” Commenters also recommended that we simply state in regulation that EHR technology can be certified to the most recent version of the implementation guide, which would acknowledge the evolving nature of implementation specifications.

Response. We have established a process for adopting certain vocabulary standards, including SNOMED CT® and LOINC®, which permits the use of newer versions of those standards than the one adopted in regulation. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets. In response to the commenters' suggestion that we permit the use of the “most recent version” of the implementation guide for certification, we refer the commenters to section III.A.5 found earlier in this preamble. This section explains why we cannot take such an approach.

Comments. A commenter recommended that CMS develop a common national data submission standard in order to limit the burden on providers and vendors operating in multiple states and therefore connecting to multiple registries and other public health organizations.

Response. We do not believe this comment fits within the scope of the proposed certification criteria. We note, however, that for all public health reporting, CDC is co-leading (with ONC) the efforts of the S&I Framework Public Health Reporting Initiative to harmonize data elements, vocabularies, and format across public health diseases and conditions. The cancer registry community is an active participant in this initiative. For cancer reporting, CDC, NCI SEER, and NAACCR have worked closely with public health cancer registries to establish a single data submission standard, which is already reflected in the implementation guide.

Comments. A couple of commenters suggested that we make clear that the state cancer registry, as it is used in the MU objective, may be operated directly by a Public Health Authority (PHA) or under contract or other delegation agreement with a designated entity, such as a university. In either case, they stated that the cancer registry is a part of the PHA and EPs should report to it if they choose this Menu objective. A few commenters recommended changing “state cancer registry” to “public health central cancer registries” to clearly distinguish from hospital‐based cancer registries which they asserted should not satisfy MU requirements.

Commenters also requested clarification and guidance. A commenter requested clarification on what constituted an acceptable registry. Another commenter noted that specialized disease registries are often proprietary and require special consideration for use and suggested that we, therefore, make a distinction for the support of an open and public specialized disease registry. One commenter requested clarification as to whether the reporting institution is responsible for creating report events for residents outside of its respective state. A couple of commenters requested clarification on “in accordance with applicable law” and further explanation on “except where prohibited.” Another commenter requested clarification regarding whether state-specific requirements pertain to the state the provider is in, or to the state the patient resides in. One commenter requested guidance on meeting this objective due to new reporting methodology being created and the readiness of registries to adopt the proposed HL7 CDA standard.

Response. We appreciate the submission of these comments, but they are outside the scope of this rulemaking. This final rule does not create or modify any obligations or choices of EPs to report to disease registries or the operations of those registries. It seeks only to facilitate such reporting through CEHRT. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and a response to these comments.

c. Inpatient Setting

We propose to adopt 3 certification criteria that would be new certification criteria for the inpatient setting.

• Electronic Medication Administration Record

We proposed to adopt a new “eMAR” certification criterion with the inclusion of the “synchronized clocks” standard. We made this proposal based on the recommendation of the HITSC for a new 2014 Edition EHR certification criterion to support the MU objective and measure to automatically track medications from order to administration. In our proposal, consistent with the intent of the HITSC and HITPC, we emphasized that EHR technology certified to this certification criterion must enable a user to electronically confirm the “rights” (i.e., right patient, right medication, right dose, right route, and right time) in relation to the medication(s) to be administered in combination with an assistive technology (e.g., bar-coding, location tracking, and radio-frequency identification (RFID)) which provides automated information on the “rights.” We also noted that an electronic “checklist” through which a user would manually confirm the “rights” without any automated and assistive feedback from EHR technology would be insufficient to demonstrate compliance with this certification criterion.

Comments. Commenters requested clarification on the definition of “assistive technology.” One suggested that we should not define assistive technology as barcode scanning, RFID or any other technology solution. Another asked whether it could be a nurse at the bedside recording medication on a handheld device such as a smart phone or tablet; a bedside computer; or if it needed to be a barcode scanner that scans the patient, the medication, and automatically records the time. A few comments noted that if there is a future requirement to progress towards RFID, advance notice would be appropriate because they consider all technologies currently acceptable, including various bar code formats.

Response. We have purposefully framed this certification criterion to leave open a range of different technologies that could be used to demonstrate compliance with the certification criterion. We do not intend to single out only one particular technology that would meet this certification criterion. We interpret “assistive technology” to be a technological solution that when paired with EHR technology automates the comparative aspects of the five rights that a user would otherwise have to manually complete.

Comment. A commenter requested clarification on whether “electronically” recording the time, date, and user ID at the time of administration is a function automatically performed by the system, or whether allowing a user to manually enter this data is sufficient.

Response. We intend for this information to be automatically and simultaneously recorded with the use of the assistive technology. A manual entry feature for emergency/unanticipated circumstances is not prohibited by this certification criterion from existing, but would not alone allow for EHR technology to meet this certification criterion.

Comments. A few comments indicated support for the clarification we issued in the Proposed Rule that “automated” tracking not simply be a presentation of an electronic “checklist” to an end user, but that it provide for electronic confirmation of the results of an automated tracking event such as to scan a patient wrist band or a medication bar code to match the right medication for the right patient. Commenters suggested that we offer some additional guidance to make it clear that the assistive technology used to automate the five rights should not be a substitute for clinical judgment and that automated does not mean to imply no user confirmatory action. They suggested that we clarify that medication administration would include at least a confirmatory step for an end user to validate the outcome of an automated check before proceeding. They stated that just as manual work steps can lead to error, automated tracking should not be relied upon absent a human element to confirm (and take responsibility for) the outcome. The commenter suggested that we strengthen the language in the certification criterion to highlight that “automated” also requires some type of user confirmatory action.

A couple of commenters asked whether “automated” means that all “five rights” are based on some automated method or if some manual interaction is still allowed such as patient selection, signing the administration event, performing witnessing if required for patient identification as completed and other steps that still may depend on user interaction to make an entry into the system. A commenter requested clarification on the role of the assistive technology with the care provider in “providing information” on the “rights.”

Several commenters requested that we clarify the meaning of “electronically verify” in the certification criterion (or “electronically confirm” as we stated in the Proposed Rule's preamble). Additionally, commenters suggested that we specifically state that the EHR technology is not required to provide messaging to the user unless one of the “rights” is compromised in the medication administration process. Additionally, they stated that current systems typically do not message a user when all of the five rights are in compliance.

Response. We concur with commenters that the assistive technology used to automate the five rights should not be a substitute for clinical judgment. A professional clinical user is still responsible for his or her actions and should utilize the assistive technology to complement, not replace, his or her experience, training, and clinical judgment. Along those lines, we interpret “electronically verify” in the certification criterion to mean that upon the use of an assistive technology a user would be able to review and compare within the EHR technology the five rights information associated with the medication to be administered. By being able to verify this information, the user would be able to assess whether the five rights are correct and subsequently administer the medication with appropriate documentation. Consistent with the clarification requested by commenters, “electronically verify” does not require EHR technology to provide some type of explicit notification to a user if all of the five rights are correct. However, if one or more are incorrect, the EHR technology must provide some indication to a user which “right(s)” are incorrect/not within compliant parameters.

With respect to the automation expectations expressed by this certification criterion, yes, upon the use of an assistive technology, information about each of the rights would need to be automatically available for a user to verify. We acknowledge that there are other steps within the medication administration workflow for which user interaction with, and entries into, EHR technology may be necessary. This certification criterion is not meant to preclude those other steps nor are they within the current scope of this certification criterion.

In considering these comments, stakeholder interactions during the public comment period, and our own additional research, we would like to call to readers attention an error in the certification criterion with respect to the “fifth right” that we specified. Instead of specifying “right time” as it is commonly understood—to refer to the information about when the medication is to be administered relative to the current time—we specified “right time” in the proposed certification criterion as what is commonly understood to mean “right documentation.” In light of this oversight, and to ensure that the true “five rights” are included in this certification criterion, we have added in the correct description for “right time” into the certification criterion and revised the proposed capability to be called “right documentation.” This latter concept remains unchanged from our proposal and would require the EHR technology to record the time, date, and user identification when a medication is administered. We have finalized the eMAR certification criterion with the discussed revisions in § 170.314(a)(16) (the CFR paragraph was changed due to the combination of two other certification criteria).

Comment. A commenter requested clarification on how automation can determine the “right route.” They contended that technology can determine the ordered route, and whether the medication can be delivered via that route, but only manual actions and manual documentation can provide evidence of the route administered.

Response. The automated aspect of this certification criterion is the provision of information associated with the medication to be administered; in other words, that the dosage form of the medication is appropriate to the ordered route. Thus, when an assistive technology is used, the information about the route of medication delivery would need to be automatically available for a user to verify.

• Electronic Prescribing

We proposed to adopt for the inpatient setting the same revised electronic prescribing certification criterion that we proposed to adopt for the ambulatory setting (i.e., we proposed to adopt the certification criterion at § 170.314(b)(3) for both settings). We proposed to require the use of RxNorm as the vocabulary standard and NCPDP SCRIPT version 10.6 as the only content exchange standard for this certification criterion. In our discussion of this certification criterion for the ambulatory setting, we proposed to not include the NCPDP SCRIPT version 8.1 in the 2014 Edition EHR certification criterion. This proposal was premised on our understanding that CMS was planning to propose the retirement of NCPDP SCRIPT version 8.1 for the Medicare Part D e-prescribing program soon after our proposed rule was to be published. We noted that if we received information indicating a change in CMS' plans prior to the issuance of our final rule, we may, based also on public comment, retain this standard in a final revised certification criterion. We stated that we were proposing to adopt this certification criterion for both the ambulatory and inpatient settings because it supports our desired policy and interoperability outcome for content exchange standards to be used when information is exchanged between different legal entities.

Comments. Many commenters supported our proposal to require certification to NCPDP SCRIPT 10.6 for this certification criterion. Other commenters suggested that we should continue to permit certification to NCPDP SCRIPT 8.1 until it is officially retired from the Part D e-prescribing program by CMS.

Response. We appreciate commenters support for our proposal to require certification to NCPDP SCRIPT 10.6 and have finalized the certification criterion as proposed. We are not including NCPDP SCRIPT 8.1 in this certification criterion. CMS has recently proposed (77 FR 45022) to retire version 8.1 and only permit version 10.6 as of 11/1/2013. More importantly, NCPDP SCRIPT 10.6 is backwards compatible with version 8.1, so 10.6 users will be able to communicate with version 8.1 users. Therefore, even in the event that CMS does not retire version 8.1 before the FY/CY 2014 EHR reporting period, use of version 10.6 should not have an adverse impact on stakeholders. Moreover, we understand that version 10.6 includes much needed improvements and better supports stakeholders' e-prescribing needs across a variety of health care settings.

Comments. A number of commenters requested that we establish a deeming provision as part of our e-prescribing certification criterion that would make Surescripts certification for participation in its network an acceptable method to demonstrate compliance with this certification criterion. That is, in lieu of being certified by an ONC-ACB according to the adopted certification criterion and standards, EHR technology could be deemed to be certified to meet this certification criterion if it were certified according to Surescripts certification requirements.

Response. As we did not propose deeming authorities in the Proposed Rule, these suggestions are outside the scope of this final rule. Furthermore, we believe that the best way to ensure that EHR technology includes the capabilities specified by the certification criteria adopted by the Secretary is to require EHR technology to be tested and certified to these certification criteria under the provisions and procedures specified by the ONC HIT Certification Program.

Comments. Several commenters requested that we include HL7 v2.x standards for discharge e-prescribing. They reasoned that discharge prescriptions filled by a pharmacy within the walls of a hospital facility frequently use HL7 v2.x prescribing messages. Some commenters also stated that EHR technology certified to the HL7 v2.x standards for discharge e-prescribing should be permitted even in cases where the pharmacy inside the hospital facility may be a different legal entity from the source of the discharge medication. Commenters asserted that hospitals currently use HL7 transmissions to send their prescriptions to an onsite pharmacy that is a separate legal entity. Another commenter requested clarification as to whether NCPDP SCRIPT needed to be used by an EH/CAH to transmit electronic prescriptions for discharge medications that would be filled by that EH/CAH's hospital-based pharmacy, including when that pharmacy is a separate legal entity. Other commenters supported our approach of focusing on interoperability between different legal entities and not on transactions within a legal entity.

Response. We appreciate the support for our e-prescribing approach to certification. We continue to believe, as we stated in the Proposed Rule that it would be inappropriate and without sufficient benefit to require certification of EHR technology for transmissions that would be conducted within a single legal entity. We continue to believe, as we stated in the Proposed Rule (77 FR 13845), that doing so would be inconsistent with our approach of adopting standards for the electronic exchange of health information between different legal entities. We encourage commenters to read the Stage 2 proposed rule (77 FR 13710) because it discusses the various ways in which the e-prescribing MU objectives can be met such that it should address the concerns expressed by these comments. We also encourage commenters that indicated that HL7 transmissions were used even in situations where a pharmacy is considered a different legal entity to carefully read the Medicare Part D e-prescribing rules at 42 CFR 423.160(a)(3)(iii) (noting that HL7 transmissions are only permitted when the sender and recipient are part of the same legal entity). In light of the Part D e-prescribing program bar on the use of HL7 between different legal entities, we are not considering allowing it in our certification criterion.

Comments. A commenter requested that we clarify what the use of RxNorm as the sole vocabulary would entail. The commenter asked whether RxNorm would be a drug description or a drug qualifier and urged ONC to reference RxNorm as a drug qualifier, specifically via the use of RxNorm concept unique identifiers (RXCUIs), similar to how NDC identifiers are currently being used. The commenter stated that since most EHR technologies use proprietary commercial drug databases for their clinical terminology needs, that there is a critical and urgent need for RxNorm RXCUI mappings to proprietary drug database codes to be made readily available to the industry by either drug database companies or a third party in order to foster the adoption of RxNorm.

Response. The use of RxNorm as the sole vocabulary standard would entail its use to represent medications within an electronic prescription formatted according to the SCRIPT 10.6 standard. We intend for the RxNorm concept unique identifiers (RXCUIs) to be used as drug qualifiers. Mappings are not something within the scope of this rulemaking and we decline to make any changes in response to this comment.

Comments. Many commenters agreed with our proposal to adopt RxNorm, but requested certain clarifications. These commenters noted that not all medications in source vocabularies have an equivalent RxNorm code. Further, they suggested that the standard should state that the RxNorm vocabulary will be utilized when there is an equivalent concept mapping. Others requested clarification that the reference to RxNorm means that RxNorm codes must be included in transmitted messages, not that only RxNorm codes can be transmitted because there are some prescriptions that do not have corresponding RxNorm codes and will require other code sets. A commenter expanded on these concerns with the following observation: Some drug descriptions in RxNorm are over 105 characters in length, but the NCPDP SCRIPT standard limits drug descriptions to 105 characters, which means that transmission of some e-prescriptions that include RxNorm drug descriptions would be either truncated or not possible. As such, they suggested that certification criteria for RxNorm should be limited to use of this standard for drug qualifiers only. They also cautioned that RxNorm is not yet a complete drug compendium, and that RxNorm qualifiers are not available for all prescriptions that are currently sent electronically (e.g., medical supplies). Similar to other commenters, they also suggested that we clarify that the transition to the certification criterion would not preclude use of other drug databases and qualifiers if circumstances require it.

Response. We acknowledge that all medications may not yet have an equivalent RxNorm code. We do not believe it is necessary to modify the standard to explicitly state that RxNorm “be utilized when there is an equivalent concept mapping” because certification is meant to verify that EHR technology can properly use this standard. This certification criterion requires the capability to use RxNorm, specifically RXCUIs as noted in our prior response. Thus, where no RxNorm code exists, nothing prohibits another code from being used. However, where corresponding RxNorm codes exist, EHR technology must be able to use those codes. As RxNorm continues to expand, we expect that the concerns raised by commenters about its comprehensiveness will subside.

Comment. Commenters noted that the same e-prescribing certification criterion applies to both ambulatory and inpatient settings. They stated that it would be important for the final rule and subsequently developed test procedures to identify any differences between the two settings.

Response. With the exception of which test data elements might be required, this certification criterion applies equally to both settings. EHR technology certified to this certification criterion will need to enable a user to electronically create prescriptions and prescription-related information in accordance with NCPDP SCRIPT 10.6 and RxNorm.

Comment. A commenter stated that there needs to be a clear way to differentiate whether a prescription is merely sent “in house” (scenarios 1 and 2 in the Stage 2 proposed rule or “transmitted” (scenario 3)).

Response. Given the flexibility provided by CMS, we believe this will need to be determined on an implementation-by-implementation basis and would be difficult to assess for the purpose of certification in a simulated testing laboratory environment.

Comment. A commenter recommended that EHR technologies support integration with HIEs in support of the e-prescribing process.

Response. This suggestion is outside the scope of our final rule. We appreciate the commenter's feedback and will consider whether a certification criterion to address this type of capability would be appropriate for a future rulemaking.

Comments. A few commenters discussed the electronic prescribing of controlled substances. Some encouraged ONC and CMS to work to include controlled substances into future meaningful use measures. Others agreed with CMS's proposal to continue to exclude controlled substances from the e-prescribing objectives and asked that we make clear that the electronic prescribing of controlled substances (EPCS) is not required (and will not be tested) from a certification standpoint. They noted that e-prescribing of controlled substances involves many other workflow requirements for prescription review and acknowledgment, technical requirements for electronic signature and security of the transmitted prescription that go well beyond the scope of what was proposed. One commenter stated that adopting NCPDP SCRIPT version 10.6 without also mandating e-prescribing of controlled substances is contradictory and will create unnecessary costs and undesirable results due to the lack of synchronization. They contended that NCPDP SCRIPT version 10.6 should not be required for certification because it will slow the progress being made by the industry as stakeholders are coupling their development efforts for NCPDP SCRIPT version 10.6 and e-prescribing of controlled substances together. Last, a commenter suggested that we should require that EHR technology that includes e-prescribing capabilities to be implemented according to the recently released DEA requirements for all e-prescribing.

Response. While we intend to continue to work with CMS on the issue of controlled substance e-prescribing, we believe it is premature to include controlled substances in the 2014 edition of the certification requirements. We will need to carefully evaluate the practicality of what would amount to duplicating DEA's regulatory requirements for certification in our regulations and the potential unintended consequences of taking such a step. Furthermore if we were to adopt some or all of the provisions in the DEA's interim final rule in our program and, if DEA were to make any changes as it finalizes its interim final rule, our adopted certification criteria would be out of compliance with DEA's requirements. Further, DEA permits a certification option in its interim final rule and has approved at least one certification body's processes to perform certifications for EPCS. Thus, we question the value in ONC replicating these already established processes. Finally, we do not see how the adoption of NCPDP SCRIPT 10.6 without mandating EPCS could be contradictory. They are both separate and distinct regulatory requirements and one does not necessarily depend on the other to succeed.

Comment. A commenter recommended that we revise the certification criterion as follows, “generate and transmit permissible discharge prescriptions electronically.”

Response. We do not believe that this editorial suggestion adds any tangible value or clarifies the wording in the certification criterion in a major way. Thus, we decline to modify this certification criterion in response to this suggestion.

Comment. A commenter recommended that we include a capability in the certification criterion that ensures a provider is actively alerted when an e-prescription fails.

Response. This suggested capability is beyond the scope of the proposed certification criterion and we decline to modify the certification criterion. We will consider whether such a requirement would be appropriate to include in later editions of EHR certification criteria.

Comment. A commenter recommended that there be a way for patients to review e-prescriptions and participate in medication reconciliation with both their doctors and pharmacists via a patient portal.

Response. This suggested capability is beyond the scope of the proposed certification criterion and we decline to modify the certification criterion. We will consider whether such a requirement would be appropriate to include in later editions of EHR certification criteria.

Comment. A commenter stated that they would like standards and testing to demonstrate using e-prescribing for refills that allows multiple medications to be refilled from a single screen through a single transaction. They explained that for some EHR technologies the refill process is more problematic than the initial prescription process and that certification should ensure this is not the case.

Response. We do not believe that this is an issue that can be readily addressed through certification. Rather, this comment appears to focus on a particular user interface and workflow design shortcomings of certain EHR technology. This aspect is outside the scope of what is required by this certification criterion.

• Transmission of Electronic Laboratory Tests and Values/Results to Ambulatory Providers

We proposed a certification criterion that was similar to the one recommended by the HITSC to support the MU objective and measure recommended by the HITPC for EHs and CAHs to send electronic laboratory tests and values/results to EPs. CMS did not specifically propose the HITPC recommended MU objective and measure for Stage 2, but requested public comment on whether the objective and measure should be incorporated into MU Stage 2.

We proposed to include in the certification criterion the standards and implementation specification recommended by the HITSC and HITPC for the transmission of laboratory tests and values/results. In particular, we referenced the work of the Standards and Interoperability Framework Laboratory Results Interface Initiative which focused on the identification of a consistent set of data content that would need to be exchanged when laboratory tests and values/results are electronically delivered. We proposed to include the HL7 2.5.1 standard and the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI). We proposed to adopt LOINC® version 2.38 as the vocabulary standard, at the recommendation of the HITPC and agreement of the HITSC. We noted that the LRI specification was undergoing HL7 balloting and that we would monitor its progress in relation to the publication of this final rule.

With respect to testing and certification for this certification criterion, we stated that, among other aspects, inpatient EHR technology would need to demonstrate its compliance with the “Common Profile Component” and other required profiles included within the LRI implementation guide. We also noted that we had proposed to adopt a revised certification criterion for the ambulatory setting that would require EHR technology to be capable of incorporating laboratory tests and values/results according to the standards and implementation specifications we proposed for this certification criterion.

In proposing this certification criterion, we stated that requiring inpatient EHR technology to be capable of creating for transmission laboratory tests and values/results formatted in accordance with the LRI specification could make it more cost effective for electronic laboratory results interfaces to be set up in an ambulatory setting (i.e., minimal additional configuration and little to no additional/custom mapping) and that the electronic exchange of laboratory tests and values/results would improve.

Comments. Many commenters supported this certification criterion. Some commenters stated that we should not adopt this certification criterion without CMS establishing a corresponding MU objective and measure, while other commenters did not support this certification criterion for concerns related to implementation costs, the proposed standards, and the inclusion of this functionality in EHR technology.

Response. We are adopting this certification criterion for the 2014 Edition EHR certification criteria at § 170.314(b)(6). After consideration of public comments, CMS has included a corresponding objective and measure in the MU Stage 2 menu set and the adoption of this certification criterion will support that objective and measure. We discuss our responses to the other commenters' concerns in our responses below.

Comments. Commenters recommended that the transmission of electronic laboratory tests and values/results from inpatient EHR technology should follow the same standard that applies to the incorporation of laboratory tests and values/results in ambulatory EHR technology. Some of these commenters stated that this certification criterion should not be adopted without ambulatory EHR technology having the same requirements.

Response. We agree with commenters. We proposed and have adopted in the “incorporate laboratory tests and values/results” certification criterion (§ 170.314(b)(5)) a requirement that EHR technology designed for the ambulatory setting must be certified to be able to receive and incorporate laboratory tests and values/results in accordance with the LRI specification. The certification criterion discussed here, and which is applicable to inpatient EHR technology, requires that such EHR technology be able to create laboratory test reports in the same manner.

Comments. Many commenters supported the proposed standards and implementation guide. Other commenters stated that while the S&I Framework LRI is based on previously used standards, it is not in widespread production and may not be sufficiently mature for nationwide use. A few commenters noted that pilots currently in process were using the LRI specification. One commenter stated that the LRI specification was developed for the types of tests commonly ordered in the ambulatory setting and does not address electronic messaging of complex test results such as molecular genetics, anatomic pathology, and cytology. The commenter contended that messaging for these test results needs further development and testing before they can be included in routine electronic messaging transmission of laboratory results from hospitals to ambulatory providers. Therefore, the commenter recommended postponing inclusion of the LRI specification until the next edition of certification criteria.

Response. We believe that the S&I Framework LRI implementation guide is mature enough for adoption and inclusion in this certification criterion. As we noted above and in the Proposed Rule, the LRI implementation guide has been undergoing balloting by HL7. The LRI implementation guide was approved by HL7 as a Draft Standard for Trial Use (DSTU) in July 2012. This confirms its adoption as a consensus-based standard ready for use. This DSTU version of the standard updates the version we proposed by correcting errors and clarifying requirements. These corrections and clarifications will assist EHR technology developers in implementing the standard and will improve testing to the standard. As noted by HL7 in its documentation, this DSTU version of the standard will be open for comment for 24 months and following this evaluation period, it will be revised as necessary and then submitted to ANSI for approval as an American National Standard (normative standard). Further, HL7 specifies that implementation of this DSTU version will be valid during the ANSI approval process and “for up to six months after publication” of the normative standard. Given the state at which this DSTU version of the standard is and the fact that this version alone is subject to the evaluation period, we believe that it is the best possible choice for this final rule, especially in place of the draft version we referenced in the Proposed Rule. Accordingly, we have adopted this version of the LRI implementation guide for requiring the electronic creation of laboratory tests and values/results for electronic transmission and to support the associated MU objective and measure.

As we acknowledged in a response to a comment on the revised “incorporate laboratory tests and values/results” certification criterion (§ 170.314(b)(5)), we erred in referencing the HL7 2.5.1 standard in addition to the LRI specification. Thus, we have removed the reference to the HL7 2.5.1 standard in this certification criterion. We also clarify that with the exception of the baseline minimum version of LOINC® that must be supported by EHR technology, we expect, in adopting this specification that it will be followed and implemented as authored.

Comments. Some commenters agreed that this certification requirement could potentially lead to reduced costs for laboratory interfaces, while other commenters thought it was unlikely to reduce costs. Commenters stated that lab system vendors are not necessarily bound to conform to the LRI specification which would create an undesirable situation where EHRs would be forced to provide conforming and non-conforming interfaces (one set to comply with certification and the other to be used for communication with lab systems). Commenter also stated that laboratory information systems (LIS) typically produce the reportable results. Commenters stated that these systems are not normally integrated with the hospital EHR. Rather these systems send lab results directly to the ordering physicians based on rules defined by CLIA (Clinical Laboratory Improvement Amendments) and are often further refined by state regulation.

Commenters noted that this certification criterion may serve to open up the strong possibility that laboratory information systems (LISs) will become certified as EHR modules on a more regular basis, and may motivate some vendors to seek certification on that basis both for this criterion as well as the public health reporting of lab results (which some LIS vendors have already done).

Response. The MU objective and measure that this certification criterion supports is in the MU Stage 2 menu set. Based on the revised CEHRT definition, the final rule provides EHs and CAHs the regulatory flexibility to determine whether to adopt EHR technology certified to this certification criterion in order to meet this MU objective and measure. Further, as noted by some commenters, the relevant LIS capabilities could potentially be certified to this certification criterion, perhaps as an EHR Module, and used to meet the associated MU objective and measure. Considering these points, we do not believe this certification criterion creates any undue burden and, as agreed to by commenters, could facilitate more cost effective electronic laboratory results interfaces in the ambulatory setting.

Comments. Some commenters suggested we focus on a “standard receiver” or “universal interface” that could accept multiple types of results in one interface. These commenters stated that it is cost-prohibitive to providers to purchase different interfaces for each set of information received. Therefore, these commenters recommended that we permit the use of existing interfaces or postpone certification and/or MU requirements related to use of the LRI, while efforts are pursued towards a “universal interface.”

Response. The adopted LRI specification for the ambulatory setting is intended to provide the desired interface uniformity commenters have noted for the receipt of laboratory test results. We believe this standard is appropriate and mature for the purposes of EHR technology certification. As we have indicated in other responses in this final rule certification addresses the technical capabilities that EHR technology must include. It does not address how it must be used, once certified. Therefore, we do not agree with the comment that we should postpone adoption of this certification criterion until a “universal interface” is developed. In the Stage 2 final rule published elsewhere in this edition of the Federal Register, CMS specifies the requirements and flexibilities related to the incorporation of laboratory test results.

Comments. Commenters supported the adoption of the LOINC® standard for transmitting laboratory test results. Commenters stated, however the full LOINC® coding of all tests and analytes is unnecessary. Rather, the commenters stated that the subset that accounts for most frequent ambulatory use and alignment with quality measures and public health requirements should be the requirement.

Response. To meet this certification criterion, EHR technology must meet the LRI specification using LOINC®. For the purposes of testing and certification, we expect that EHR technology will be evaluated based on its ability to use most commonly reported LOINC® codes. We expect that the test procedure developed for this certification criterion will leverage LOINC® materials published by the Regenstrief Institute and available through the National Library Medicine, which in this case would be the “LOINC® Top 2000+ Lab Observations and Mapper's Guide.” This guide is an empirically-based list of the most common LOINC® result codes for laboratories, practices, researchers, and others who wish to map their laboratory test codes to universal LOINC® codes. This list contains over 2000 of the most commonly reported LOINC® codes that represent about 98% of the test volume carried by three large organizations that mapped all of their laboratory tests to LOINC® codes. We believe this scope for testing and certification will help aid EHR technology developers and focus development efforts toward these top 2000+ codes first.

Comments. Commenters suggested that we simply state in regulation that EHR technology can be certified to the most recent versions of LOINC®.

Response. We have established a process for adopting certain vocabulary standards, including LOINC®, which permits the use of newer versions of those standards than the one adopted in regulation. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets.

Comment. A commenter requested a list of CPT codes that define imaging studies and a listing of CPT codes that define a laboratory test.

Response. The commenter did not provide any supporting rationale as to why a list of CPT codes would be relevant to the capabilities expressed by this certification criterion. Thus, we decline to provide any additional information.

Comments. A commenter recommended inclusion of a date/time stamp on all values sent to ambulatory providers.

Response. The LRI specification's message header includes a required date/time stamp and the result segment (OBX) includes a test performed date/time stamp that is required if it exists.

Comments. A commenter suggested that NwHIN query-and-response protocol be required for use in sharing laboratory test results as part of this certification criterion. The commenter stated that such a requirement would encourage EHR technology developers to use the NwHIN protocol to have providers in different care settings access clinical information, including laboratory tests.

Response. We appreciate the commenter's suggestion, but did not propose specific transport approaches to require for certification and intend to focus certification on the proper implementation of the LRI specification.

Comments. Commenters requested clarification about to whom the transmission may occur, whether directly to EPs or through an HIE structure.

Response. This certification criterion focuses on the proper implementation of the LRI specification. How or by what means the laboratory test report gets to an EP is not currently within the scope the certification criterion and, in part, is likely dictated by other regulatory requirements, such as the CLIA rules.

Comments. A few commenters suggested that ONC work with CMS to encourage laboratories to adopt and use the S&I Framework LRI specification. They contended that without the “source systems” on board that requiring capabilities on receiving systems (EHR technology) would fall short of the intended purpose of reducing development time and costs and improving quality.

Response. We appreciate these comments and will continue to work with our sister agencies in HHS to advance health IT policy in other programs and regulations that affect stakeholders that are not eligible to receive EHR incentive payments.

Comment. A commenter stated that patients should also have access to all laboratory tests and results immediately, both inpatient and ambulatory, as a matter of patient safety.

Response. We appreciate this comment, but it is not something a capability in EHR technology, per se, can resolve. Through the EHR Incentive Programs, EPs, EHs, and CAHs, will have to provide online access to patients to view their electronic health information. This should provide a means for patients to get prompt access to their laboratory test results. We also note that CMS and OCR have engaged in rulemaking to permit patients to directly access their lab test reports (75 FR 56712).

10. Revised Certification Criteria

In the Proposed Rule, we described certification criteria that we considered “revised.” We noted the following factors that we would consider when determining whether a certification criterion is “revised:”

• The certification criterion includes changes to capabilities that were specified in the previously adopted certification criterion;
• The certification criterion has a new mandatory capability that was not included in the previously adopted certification criterion; or
• The certification criterion was previously adopted as “optional” for a particular setting and is subsequently adopted as “mandatory” for that setting.

For clarity, we explained that, in some cases, a certification criterion could be both “revised” and “new.” For example, a previously adopted certification criterion could have been adopted for only the ambulatory setting. Subsequently, we could revise the certification criterion by adding a new capability and making it mandatory for both the ambulatory and inpatient settings. Once adopted, the certification criterion would be “new” for the inpatient setting and “revised” for the ambulatory setting.

Comments. We did not receive comments questioning our description of revised certification criteria.

Response. Given that we received no comments, we will continue to use this description of revised certification criteria to categorize the following certification criteria we have adopted as part of the 2014 Edition EHR certification criteria. We note that the following adopted revised certification criteria included certification criteria that were not only proposed as revised certification criteria, but also certification criteria that were proposed as unchanged certification criteria in the Proposed Rule.

a. Ambulatory and Inpatient Setting

We propose to adopt the following revised certification criteria for both the ambulatory and inpatient settings.

• Vital signs, body mass index, and growth charts

We proposed the “vital signs, body mass index, and growth charts” certification criterion (§ 170.314(a)(4)) of the 2014 Edition EHR certification criteria as an unchanged certification criterion. We proposed to replace the terms “modify” and “retrieve” with “change” and “access,” respectively. We also proposed to add the alternative term “length” to go with “height” as it is the clinically appropriate term for newborns and assisted in clarifying the intent of the “vital signs” capability. The only other refinements that we proposed were for the plot and display growth charts capability. First, we proposed that this capability be designated “optional” within this certification criterion because some EPs, EHs, and CAHs would not (or would never) use such a capability due to scope of practice or other reasons. Thus, to reduce regulatory burden and to not require EHR technology developers to include a specific growth chart capability when they do not intend to market their EHR technology to EPs, EHs, or CAHs that would use such a capability, we proposed to designate growth charts as “optional” for certification. Second, we proposed to remove the age range reference (2-20 years old) from this capability. We noted that this proposed refinement was consistent with other certification criteria such as “smoking status” where the MU objective it supports specifies an age threshold (13), but the capability is not dependent on a patient's age.

Comments. Many commenters recommended that this certification criterion remain unchanged. A couple of commenters recommended the use of the LOINC® (for observations), SNOMED CT® (for qualitative results), and UCUM (for units of measure), as applicable, for the recording of the data elements specified in this certification criterion. One commenter recommended that requirements for specific data elements that would be included as part of vital signs data in MU Stage 2, such as ECG waveforms, be defined so that the appropriate device integration standards can be developed to support interoperability and certification standards and criteria for these important physiologic signals.

A commenter stated that the capability to plot and display growth charts should be a required capability and should be specified in more detail. Another commenter requested clarification on what type of growth charts were applicable based on age ranges. In particular, the commenter pointed to the World Health Organization for growth standards for children 0 to 2 years old and CDC growth charts for ages 2 and older. Another commenter requested clarification that growth charts would not need to be included in a transition of care/referral summary formatted in accordance with the Consolidated CDA because they are not listed as a “vital sign” in the Consolidated CDA. Commenters also requested guidance on how the optional capability of plotting and displaying growth charts would be indicated in an EHR technology's certification and for marketing purposes.

Response. We thank commenters for generally supporting this certification criterion. We decline to revise this certification criterion in response to the comment that recommended we require EHR technology to natively record vital signs data in specific vocabularies. We did not propose this requirement and believe that the complexity of wholesale change to the data capture processes of existing EHR technologies for this purpose cannot be understated. Additionally, it is our understanding that many EHR technologies capture this information, but do not currently map it to standardized terminologies such as LOINC®—and there are currently many different workflows, templates, and forms that are used to capture this information. Thus, we believe that requiring vital signs data that is recorded to, for example, be mapped to LOINC® is too burdensome a requirement to impose for certification to the 2014 Edition EHR certification criteria. Moreover, our concern stems from the possibility that such a requirement could cause EHR technology developers to map vital signs capture to a standardized terminology in one workflow but perhaps not others—which would then cause providers to be forced to use a given workflow/form/template to achieve MU that is not consistent with optimal workflow/usability. We do intend, however, to require as part of the next edition of EHR certification criteria that EHR technology would need to be able to record all vital signs according to standardized terminologies. Further, we emphasize to EHR technology developers that nothing precludes you from taking this step for certification to the 2014 Edition EHR certification criteria.

Nonetheless, in response to these comments we evaluated the specificity and clarity of the certification criterion and believe that it needs to be revised. First, we believe the grammar in the certification criterion makes it more difficult than necessary to read. Second, while we have declined to revise this certification criterion in the way commenters suggested (that we require explicit recording of vital signs in standardized codes), we believe that an important, but modest, intermediate step must be taken to improve the certification criterion's specificity and its ability to affect patient safety. Accordingly, we have revised this certification criterion to explicitly state that the data recorded by EHR technology for height/length, weight, and blood pressure must be in numeric values only (i.e., alphabetic characters such as “lbs,” “kg,” or “cm” would not be permitted to included as part of the value recorded). This restriction has significant clinical and patient safety benefits because it prevents the inappropriate recording of text in fields that should be constrained to numeric values. Additional attributes that may be used to document (e.g., which arm a blood pressure is taken from, whether the patient is sitting or standing, or a reason that the value could not be obtained) should be recorded in a supplemental field rather than the field for the value itself. We expect that a significant majority of EHR technologies already function this way. Thus, we anticipate that this revision poses little, if any, practical burden to most EHR technology developers. However, in cases where this revised certification criterion will cause EHR technology to be updated for certification, we believe that better patient safety outweighs the burden.

With respect to the commenter's recommendation for defining and including data elements such as ECG waveforms as part of vital signs data in MU Stage 2, we note that this data element goes beyond the requirements of the associated MU objective and measure. Thus, we have not made any changes in response to this recommendation.

We do not believe that the capability to plot and electronically display growth charts should be a required capability because, as we noted in the Proposed Rule, not all EP, EHs, and CAHs will necessarily need this capability. For certification to this certification criterion, we clarify that EHR technology is not required to demonstrate the capability to provide growth charts based on subsets of age ranges within the 0-20 age range required by the MU objective. However, we encourage EHR technology developers to include the specificity that best addresses their customers' needs. We further clarify that the growth chart capability included in this certification criterion requires EHR technology to be capable of plotting and electronically displaying growth charts of patients. We do not expect growth charts to be transmitted in a transition of care/referral summary formatted in accordance with the Consolidated CDA. Last, we expect that certifications issued to EHR technology certified to this certification criterion will indicate whether the EHR technology is capable of plotting and electronically displaying growth charts and that such information would be accessible on the CHPL.

• Drug-Formulary Checks

We proposed the “drug-formulary checks” certification criterion (§ 170.314(a)(10)) of the 2014 Edition EHR certification criteria as an unchanged certification criterion.

Comments. Many commenters supported this certification criterion remaining unchanged for the 2014 Edition EHR certification criteria. A few commenters suggested that EHR technology developers who had completed Surescripts' Eligibility and Formulary certification could be permitted to attest to this certification criterion. Commenters recommended that EPs be able to obtain drug-formulary information that is accurate, in real-time, and includes the necessary details for the prescriber's review. One commenter recommended that we specifically include a capability in this certification criterion to capture the plan name, plan identification number, group identification number, and pharmacy benefit management care coverage in structured data. A couple of commenters recommended that we adopt the NCPDP Formulary and Benefit Standard Implementation Guide, Version 3.0, or alternatively, at a minimum, the NCPDP Formulary and Benefit Standard Implementation Guide, Version 1.0 as the standard to enable electronic formulary checking. A commenter suggested that we require EHR technology to be capable of making available all necessary formularies, which the commenter stated would help address situations where there is a lack of consistent access to Medicaid formularies, including Medicaid Managed Care formularies.

Response. We appreciate the support expressed for the certification criterion and the specific feedback commenters provided. In response to this feedback and clarifications issued by CMS in its final rule for the MU objectives and measures this certification criterion supports, we have determined that it is necessary to revise this certification criterion. The revised certification criterion is designed to ensure that a drug formulary check poses minimal burden on EPs, EHs, and CAHs. Further, the revision we have included specifies that EHR technology must perform an automated check for the existence of a drug formulary that is specific to a patient for the medication to be prescribed. In other words, an EHR technology would not satisfy this revised certification criterion if it provided a hyperlink to a patient's drug formulary that an EP, EH, or CAH then had to manually open and navigate. With respect to commenters' suggestions to further modify this certification criterion to include additional capabilities, such as those that would ensure real-time information, capture of specific information (e.g., plan name, plan identification number, etc.) in structured data, and making available all necessary formularies, we believe these suggestions exceed the baseline requirements for certification that we have included to support MU. Thus, we decline to make any further revisions to the certification criterion except those noted above. As discussed in the e-prescribing comment and responses part of this final rule, CMS has issued a proposed rule (77 FR 45022) that would update Medicare Part D e-prescribing standards, including a new version of the formulary and benefit standard. We strongly encourage EHR technology developers to utilize these standards, but do not believe that it is necessary at this time to require them as a condition of certification—as having current drug formularies stored locally in the EHR technology would also be a permitted approach. Further, as we discussed in the S&CC July 2010 final rule (75 FR 44602), because some EPs, EHs, and CAHs, do not have external access to a drug formulary and would be able to satisfy the MU requirements by checking an internally managed drug formulary, we believe the flexibility provided by the certification criterion is still warranted. We intend to seek recommendations from the HITSC on further requirements related to this certification criterion in developing the next edition of our EHR certification criteria.

Last, the ONC HIT Certification Program does not include any form of reciprocity for certification under other private sector certification programs, including Surescripts' certification program. The ONC HIT Certification Program will be a “new” certification program that will replace the temporary certification program upon the effective date of this final rule. At its onset, we believe that the best way to ensure that EHR technology has the capabilities included in the certification criteria adopted by the Secretary is to require the EHR technology to be tested and certified to the certification criteria under the provisions and procedures specified by the ONC HIT Certification Program.

• Smoking Status

The 2011 Edition EHR certification criterion for smoking status (§ 170.302(g)) specifies a list of six smoking status types that EHR technology must be capable of recording, modifying, and retrieving. For the 2014 Edition EHR certification criteria, we proposed a “smoking status” certification criterion that replaced the terms “modify” and “retrieve” with “change” and “access,” respectively. We also proposed to specify the six smoking status types included in the 2011 Edition EHR certification criterion as a standard at § 170.207(l). We stated that this refinement would provide additional clarity for the certification criterion and consistency with the structure of similar certification criteria.

Comments. Multiple commenters expressed agreement with this certification criterion as proposed. More commenters, however, recommended that we adopt an industry developed and accepted standard and pointed to SNOMED CT® as the appropriate standard. If SNOMED CT® was not adopted, commenters asked that we provide a crosswalk from the smoking status types included in the certification criterion to the appropriate SNOMED CT® codes.

Commenters raised questions about the definitions/categories of the smoking status types. One commenter suggested that all tobacco use should be captured. Another commenter recommended that the smoking status types reflect the questions used in community health assessment that track smoking and tobacco use cessation interventions or medical assistance such as: (a) Advising smokers and tobacco users to quit “patient has been offered a smoking cessation program;” (b) discussing smoking and tobacco use cessation medications; (c) discussing smoking and tobacco use cessation strategies or “assistance in setting a quit date.” A few commenters asked whether mapping to the smoking status types included in the certification criterion would be permitted for certification and, if so, for further clarification of potential categories that would suitably map to the smoking status types included in the certification criterion. For example, commenters asked whether mapping would apply to only cigarettes or other forms of combustible tobacco use as well.

A few commenters noted that the smoking status types adopted for the 2011 Edition EHR certification criteria and proposed for the 2014 Edition EHR certification criteria do not align with those used in the quality measures in Stage 1 and proposed for Stage 2, such as NQF 0028 (Preventive Care and Screening: Tobacco Use: “Screening and Cessation Intervention (percentage of patients aged 18 years and older who were screened for tobacco use one or more times within 24 months AND who received cessation counseling intervention if identified as a tobacco user”). The commenters noted that NQF 0028 goes beyond documenting smoking status to encourage cessation counseling. Consequently, the commenters suggested that we could alleviate reporting burdens and workflow issues by agreeing on a single tobacco use value set for all meaningful use objectives and clinical quality measures.

Response. We thank commenters for their feedback and agree with much of what was said. We have now provided mappings to a set of SNOMED CT® concepts to assist the developers and implementers of EHR technology in the implementation of this requirement. We have also expanded the number of available concepts from six to eight in order to better reflect the way that many EPs capture smoking status. We clarify that the eight smoking statuses provided here need not be the exact words that are displayed for a user. Rather, any appropriate concept or concepts that the EHR technology displays for an EP may be mapped to one or more compatible smoking status codes, but if an alternative approach is used, the EHR technology must ultimately be able to record the semantic representation of a patient's smoking status in at least one of these eight status. Further, these eight codes must be used as specified elsewhere in this final rule when smoking status is referenced, such as within the transitions of care certification criterion. We clarify that smoking status includes any form of tobacco that is smoked, but not all tobacco use. Working with CMS, we have added these eight value sets to NQF 0028, so that (for the portion of NQF 0028 that captures smoking status) an EP or EH can capture this data only once rather than twice.

As described above, these eight smoking statuses have been provided in order to permit EHR technology developers to incorporate the capture of smoking status as part of an efficient, fluid user experience. We have added two smoking statuses to the standard adopted in § 170.207(h) in order to better reflect clinically relevant differences between smokers, and provide options that may in fact be preferable to many providers, while retaining the existing six codes from the 2011 Edition certification program in order to give EHR developers the option of migrating to the newer codes over time. “Light smoker” is interpreted to mean fewer than 10 cigarettes per day, or an equivalent (but less concretely defined) quantity of cigar or pipe smoke. “Heavy smoker” is interpreted to mean greater than 10 cigarettes per day or an equivalent (but less concretely defined) quantity of cigar or pipe smoke. Since many EHR technology developers have asked questions about this certification criterion, we offer the following example of an implementation that would be acceptable: an EP user of CEHRT ABC is taking the social history from patient XYZ. The EP is using a template for facilitated data entry in the CEHRT. The template has options such as “smoker” and “nonsmoker.” When the EP selects “smoker,” several other options become available including “1-9 cigarettes/day” and “1/2 pack/day” and “1 pack/day” and “greater than 1 pack/day.” The EP selects “1 pack/day,” and moves on to other parts of the discussion with the patient. The CEHRT records (and displays) “1 pack/day” and maps this internally as SNOMED CT® concept 428071000124103 (“Current Heavy Smoker”). When a transition of care/referral summary is generated for exchange, the SNOMED CT® concept must be included, as well as the text description “heavy smoker” (“1 pack/day” and any other metadata could also be included as appropriate). Note that “heavy smoker” is not the only concept that is appropriate here, and we leave the decision regarding which of the eight codes is the most accurate descriptor of clinical intent to the judgment of those implementing the form, template, or other EHR data capture interface. In the case above, the developer of the template chose “heavy smoker” rather than “current every day smoker” because this is more clinically relevant with respect to the patient's risk for disease and the urgency of intervention. Nonetheless, “Current every day smoker” would have been technically acceptable and would therefore be acceptable for certification testing.

• Patient List Creation (proposed “Patient Lists” and “Patient Reminders”)

We proposed the 2014 Edition EHR certification criteria for “patient” lists and “patient reminders” as “unchanged” certification criteria (as described in section III.A.11 of this preamble). In our proposal for the “patient reminders” certification criterion, we clarified and emphasized that EHR technology certified to this certification criterion would need to be capable of creating a patient reminder list that includes a patient's communication preferences, which would be consistent with current testing procedures for this capability as included in the 2011 Edition EHR certification criterion (§ 170.304(d)). We also noted that, consistent with patient communication preferences, we would anticipate that EPs, EHs, and CAHs could use communication mediums made available by EHR technology certified to the proposed “secure messaging” certification criterion (§ 170.314(e)(3)) or the “view, download and transmit to 3rd party” certification criterion (§ 170.314(e)(1)) to send patient reminders. Last, we stated that we anticipated that other modes of communication would be available and may be preferred by patients for sending patient reminders, such as regular mail.

We also proposed the “patient lists” certification criterion for the 2014 Edition EHR certification criteria as unchanged and without any refinements. The proposed “patient lists” certification criterion specified that EHR technology enable a user to electronically select, sort, access, and create lists of patients according to, at a minimum, the data elements included in: (i) Problem list; (ii) Medication list; (iii) Demographics; and (iv) Laboratory tests and values/results.

Comments. One commenter agreed that being able to provide information to patients in the manner they prefer is important, but expressed concern about the adoption of the “patient reminder” certification criterion for Stage 2. They stated that their comments to CMS indicated that non-CEHRT systems that provide the actual reminders should be exempt from certification criteria.

Response. This adopted 2014 Edition EHR certification criterion focuses on an EHR technology's capability to electronically create a patient reminder list for preventive or follow-up care according to patient preferences based on certain data elements. It does not focus on the IT systems that may be used to provide the reminders.

Comment. A commenter suggested that the proposed “patient reminders” certification criterion include the element of when patients were last seen so that the EHR technology user can perform date range searches (i.e., diabetics not seen for 6 months).

Response. We agree with this commenter's suggestion. Although we proposed the “patient reminders” certification criterion as an unchanged certification criterion, we believe this commenter has identified a critical flaw in the way the certification criterion is currently expressed. We interpret the commenter's request to mean that as an EHR technology user they would want to be able to create a patient reminder list on an ad-hoc basis according to at least the parameters specified in the certification criterion. As we considered this comment and analyzed the way the certification criterion is specified, we realized that it does not necessarily express this outcome, which was our intent for this certification criterion. Rather, we believe that as currently worded, the certification criterion could permit an EHR technology developer to design and get EHR technology certified that could only permit a user to generate patient reminder lists based on a few static reports. We believe that kind of outcome is unacceptable and does little to support an EP's ability to engage in follow-up care communications—especially if the EP wants to focus on a patient population that should be supported by virtue of certification, but is not because the EP cannot dynamically (i.e., on-the-fly) and while interacting with the EHR technology add or subtract certain factors from the underlying query. Additionally, in the continued context of reducing redundancy and regulatory burden as well as our continued efforts to improve the clarity of our regulation, we compared this certification criterion with the “patient lists” certification criterion (proposed at § 170.314(a)(14)) and have determined that these two certification criteria should be combined into a single certification criterion. At a high-level, both require EHR technology to be able to electronically create a list of patients. However, where the “patient lists” certification criterion includes more specific filtering, the “patient reminders” does not, but it does include two additional data elements (medication allergies, patient's communication preference).

Accordingly, we have finalized a single certification criterion that merges the strengths of each certification criterion as well as this commenter's suggestion for a date/time component. We believe this single certification criterion will be clearer for EHR technology developers and will more clearly express the kind of capability EHR technology must include in order to be certified. Within the certification criterion, we interpret “select” to mean filter and “sort” to mean that the user gets to provide a sequence or range (e.g., by hemoglobin A1C levels). For consistency purposes, we have included the same revisions we have made in other certification criteria and state “each one and at least one combination* * *” to indicate that EHR technology must be able to create a list based on each element separately as well as based on at least one combination of any of the data. Finally, we seek to indicate our expectation that for the next EHR certification criteria edition, we would propose that EHR technology be able to initiate a patient reminder based on a patient's identified communication preference (where it is electronically feasible).

Comment. A commenter asked that we provide additional guidance as to what constitutes “patient preference.”

Response. In the Proposed Rule we indicated that patient preference constituted the communication method by which the patient preferred to be contacted. This could include but is not limited to: email, secure messaging, regular mail, phone, and text message. EHR technology designed for an ambulatory setting must support an EP, EH, or CAH's ability to record a patient's communication preference, which we believe is now explicitly clear in the revised combined certification criterion. We encourage EHR technology developers to include a variety of the most common choices patients may select.

Comments. Many comments were not focused on the capability that EHR technology would need to provide a user in order to meet the certification criterion, but on: how a reminder needed to be provided; what an acceptable reminder would be; whether the purpose of the reminder and its clinical relevance mattered; how a reminder could be reported; and that exclusions to the meaningful use objective and measure should be established for specialists.

Response. All of these comments go beyond the scope of capabilities for which EHR technology certification is required.

• Drug-Drug, Drug-Allergy Interaction Checks

We proposed a “drug-drug, drug-allergy interaction checks” certification criterion (§ 170.314(a)(2)) that included the recommendations of the HITSC to eliminate for certification the ability for EHR technology to permit users to adjust drug-allergy interaction checks, replace the term “real-time” with “before the order is executed,” revise the language to specify that notifications should happen during CPOE, specify that the level of severity of the notifications is what can be adjusted, and limit the ability to make adjustments to an identified set of users or available as a system administrative function. We also expressed agreement with the HITSC that drug-allergy contraindications should be interpreted to include adverse reaction contraindications. We also clarified that the phrase “identified set of users” means that the EHR technology must enable an EP, EH, and CAH to assign only certain users (e.g., system administrator) with the ability to adjust severity levels. We noted that in other certification criteria that use the phrase “identified set of users,” a similar principle would apply (i.e., assigning the capability to only certain users).

Comments. Of the comments received on this proposed certification criterion, many supported it as proposed. A set of commenters recommended that we change the language at the beginning of the certification criterion to state, “Before an order is being completed and acted upon * * *” instead of “Before a medication order is placed * * *.” They noted that this change would clearly define the interaction notification's “real-time” nature and make it clear that the licensed provider would need to see the interaction intervention and be able to act on it. Similarly, with respect to this proposed language, a commenter questioned how EHR technology workflow would be tested to know if the check is completed before the order is entered.

Response. We appreciate this detailed feedback and agree with commenters' revisions. We have modified this language in the certification criterion to reflect the recommended text by replacing “placed” with “completed and acted upon.” We believe that this revision should also address the testing timing question raised by the last comment. Additionally, due to this revision, we removed “at the point of care” from the certification criterion's language because we believe the prior clarification appropriately indicates when the drug-drug or drug-allergy interaction needs to be indicated to a user.

Comments. Some commenters focused on our proposal to not include in the 2014 Edition EHR certification criterion the capability for EHR technology to permit users to adjust drug-allergy interaction checks. One commenter stated that it was unclear in the Proposed Rule whether this also applied to drug-drug interactions. The commenter appeared to presume that we were also applying this proposal to drug-drug interactions because the commenter explained that such a limitation would not comport with the current state of interaction databases available in practice. Specifically, the commenter stated that current systems, especially those based on shared excipients (i.e., substances) or other components across formulations, are often strongly biased toward sensitivity (i.e., an alert is generated even when a low probability of a clinically significant interaction exists). As a result, the specificity of alerts, and hence their positive predictive value, is low. The commenter stated that the phenomenon of “alert fatigue” is well-documented and the inflexible approach promoted by the Proposed Rule contributes to this phenomenon. Similarly, another commenter expressed concern that EHR technology developers may interpret this section to prohibit physicians in small practices from tailoring alerts to fit their practice. The commenter also noted that alert fatigue is a well-known problem and expressed concern that our proposal may lead to a diminution in safety through alert fatigue rather than an improvement.

One commenter stated that we should reword paragraph (ii)(B) to ensure that EHR technology has the capability to permit a limited set of users to make adjustments to the severity levels of drug-allergy interaction checks, in addition to drug-drug. In contrast to this position, another commenter expressed agreement with the proposed change from the 2011 Edition EHR certification criterion to the 2014 Edition EHR certification criterion and stated that adjusting notifications of drug-allergy interaction checks is inconsistent with clinical work and confusing in the current certification process.

One commenter contended that providers should retain the ability to define thresholds for any alert which they would like to receive. Without this capability, the commenter argued EPs are liable to experience “alert fatigue” due to high “noise to signal”; that is, the presentation of a large number of alerts which are simply irrelevant to the care which the physician is providing.

Response. On our proposal to remove the drug-allergy adjustment capability expressed in the 2011 Edition version of this certification criterion, we believe that the negative reaction expressed is due to misinterpreting our proposal. We are fully aware of the concerns expressed regarding alert fatigue. The certification criterion addresses this concern by requiring that EHR technology include the capability to adjust the severity level of interventions provided for drug-drug interaction checks. This capability should allow for EPs, EHs, and CAHs to find an appropriate balance with respect to the frequency of interventions. In regards to severity level adjustments for drug-allergy interactions, the proposal in question sought to remedy a concern raised by the HITSC and other stakeholders after the S&CC July 2010 Final Rule that certification focused on ensuring that EHR technology had the capability to adjust the severity of drug-allergy interventions when there were few clinical reasons to do so. Unlike drug-drug alerts, the rationale we provided was that it is important for drug-allergy interventions to be indicated and continue to believe that this will generally be the case. Thus, we have finalized the “adjustments” paragraph (§ 170.314(a)(2)(ii)) as proposed and decline to include for the purposes of certification a severity adjustment requirement for drug-allergy interventions.

Comment. A commenter requested clarification on paragraph (a)(2)(ii)(A). They asked whether the certification criterion would require that the severity level be able to be changed from what a pharmaceutical company's research recommended. Additionally, they asked if we were suggesting that a provider or person with appropriate administrative privileges be able to downgrade that alert level to moderate or minor or simply that they be able to modify the type of interaction that triggers a warning. They concluded by stating that a valid clinical use case is that many commonly prescribed combinations are labeled as having a potential drug-drug reaction and the provider wants to prevent being alerted each time.

Response. The certification criterion does not specifically address a particular drug-drug intervention. Rather it is meant to ensure that EHR technology that meets this certification criterion includes a capability that permits certain users to adjust the severity level of interventions. So in response to the commenter's question, this certification criterion is meant to make it possible for a health care provider to reduce the frequency of/threshold for certain interventions.

Comments. A commenter asked that we clarify the definition of “adverse reaction contraindication.” Additionally, they asked what vocabulary or vocabulary subsets would be used for the input of the adverse reaction and whether EHR technology would need to be able to distinguish between alerts for allergy contraindications and alerts for adverse reaction contraindications. They stated that many EHR technologies are not configured to register other reactions that are not true allergies. A second commenter stated that we should recommend specific vocabularies/codes and referenced RxNorm for the drugs as well as the drugs to which the patient is allergic and SNOMED CT® for the type of allergy.

Response. We agree that there is a clinical distinction between “adverse reaction” and “allergic reaction,” and we hope to be able to support such a distinction in future rulemaking. However, for the purpose of this certification criterion, we do not make a clinical distinction between “medication adverse reaction” and “allergic reaction.” In many cases, the use of a medication will be contraindicated because a patient has a history of an adverse reaction to the medication. While this may be clinically distinct from an allergic (antibody-mediated hypersensitivity) reaction, it is a contraindication nonetheless. The same clinical vocabulary (e.g., RxNorm) that would be used for allergic reactions will be required for adverse reactions.

Comment. A commenter requested that we clarify the meaning of “identified set of users” with respect to the severity adjustments. They asked whether each facility would have the ability to define this for its users.

Response. As stated in the Proposed Rule, identified set of users means that the EHR technology must enable an EP, EH, and CAH to assign only certain users (e.g., system administrator) with the ability to adjust severity levels. With respect to the follow-up question, EHR technology certified to this certification criterion would need to enable certain users to be assigned with the ability to adjust the severity levels of interventions provided for drug-drug interactions. How that capability is subsequently implemented and used is not within the scope of certification and we are unable to determine what the commenter had in mind when they referenced “each facility.”

Comment. A commenter requested that we clarify the alignment of drug-drug, drug-allergy alerts with CDS. Specifically, they asked us to confirm that the proposed adoption of the HL7 “Infobutton” standard for retrieving referential information would not apply to the drug-drug, drug-allergy alerts certification criterion.

Response. As with the past edition of EHR certification criteria, the drug-drug, drug-allergy certification criterion is a separate and distinct certification criterion from the CDS certification criterion. We did not propose the adoption of the HL7 Infobutton standard for this certification criterion and its use would not be necessary to demonstrate compliance with this certification criterion.

Comment. A commenter agreed with the certification criterion but recommend that we consider expressing additional capabilities to support food-drug interactions (i.e., changes in how medications work caused by food, caffeine or alcohol).

Response. We appreciated this comment but decline to make such changes at this time. EHR technology developers are encouraged and free to include this functionality which would be outside the scope of certification. We will keep this addition in mind as we work with the HITSC on the next edition of EHR certification criteria.

Comment. A commenter suggested that it is important to specify in this certification criterion and the CDS certification criterion that EHR technology be able to provide timely access to FDA Drug Safety Alerts (Boxed Warnings, Risk Evaluation and Mitigation Strategies (REMS) programs and Drug Safety Alerts). Further, they stated that these FDA Drug Safety Alerts include drug-drug interactions, allergic reactions and critical safety information directly related to clinical decision making.

Response. We wholeheartedly agree with this comment and encourage EHR technology developers to make FDA Drug Safety Alert information accessible to health care providers as part of their normal workflows. We believe this capability and the availability of such information is best addressed by the specific capability included in the CDS certification criterion related to referential CDS. Additionally, as part of an EHR technology's CDS we could see this capability being enhanced through the use of the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) Standard so that EHR technology could gain access to new REMS/drug alerts on an ongoing and dynamic basis.

• Demographics

We proposed to adopt the ISO 639-1 code set as the vocabulary standard for preferred language based on the recommendation of the HITSC. We also proposed to adopt ICD-10-CM for recording the preliminary cause of death, stating that its use will permit additional specificity.

As for the Office of Management and Budget (OMB) standards for the classification of federal data on race and ethnicity, we noted that the standard for classifying federal data according to race and ethnicity requires that the option for selecting one or more racial designations be provided. The standard also permits the use of more than the minimum standard categories for race and ethnicity as long as the data can be aggregated to the minimum standard categories, which would be confirmed through the testing and certification processes. We proposed to clarify the reference to the adopted standard as the “Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity,” which was issued on October 30, 1997, as referenced at § 170.207(f). Last, we proposed to revise the certification criterion to require that EHR technology be capable of recording that a patient declined to specify his or her race, ethnicity, and/or preferred language.

We received comments that generally applied to the certification criterion and comments that focused on each of the specific data elements in the certification criterion. We have categorized and respond to these comments in a similar manner.

Comments. A few commenters expressed general agreement with the proposed certification criterion, while a commenter recommended that this certification criterion should remain unchanged.

Response. We appreciate the commenters support for the proposed certification criterion and our adopting it as a revised certification criterion for the reasons discussed below.

Preferred Language

Comments. Some commenters expressed support for the ISO 639-1 standard. One commenter recommended the ISO 639-3 standard as being more comprehensive. Another commenter suggested adopting the 2009 IOM recommendations on how to ask for language data. Multiple commenters suggested that we should use ISO 639-2. The HITSC clarified in their comments that their recommendation to ONC was that preferred language should be expressed by constraining 639-2 to those that are in ISO 639-1, noting that 639-1 includes only active languages, while 639-2 includes languages no longer in use. A few commenters asked for clarification as to whether all languages listed in the standard must be visible for a customer to select.

Response. We agree with the clarification provided by the HITSC. Accordingly, we are adopting ISO 639-2 constrained by ISO 639-1. This will constrain ISO 639-2 to only the active languages in ISO 639-1, but will permit the use of the alpha-3 codes of ISO 639-2. As such it is a better approach than adopting solely ISO 639-2 or 639-1. We believe that ISO-639-3 exceeds the baseline we seek to specify for certification and have not adopted it. Last, in response to the commenters' request for clarification, EHR technology is not required to display all the languages of the standard to meet the certification criteria. But, it must be capable of recording a patient's language according to any of the languages in the standard.

Race and Ethnicity

Comments. Some commenters suggested the use of other vocabulary standards such as CDC vocabulary standards, standards based on the 2009 IOM recommendations, or the HHS survey standards recently adopted by HHS in compliance with ACA section 4302. A few commenters recommended that EHR technology only record the “primary” race and ethnicity value as identified by the individual and that the eligible professional regards as clinically significant because the commenters contended that most EHR technology is unable to accommodate multiple values for patients. Commenters also suggested that a multiple question approach for patients that may wish to designate multi-race or ethnicity be acceptable. A commenter asked for clarification as to whether the data elements must be stored as aggregated to the standard (i.e., it must be done this way), or could it be aggregated to the standard by a third party and not the EHR technology. Commenters also requested clarification as to how the OMB race and ethnicity codes must be used in conjunction with providing patients the option to not respond to questions regarding race and ethnicity.

Response. The OMB race and ethnicity codes constitute a government-unique standard. We have adopted this standard because it provides an easily understood structure and format for electronically transmitting the data elements identified by the associated MU objective. The standard is readily available, was previously adopted as part of the 2011 Edition EHR certification criteria and, in general, provides the best standard to use to support our policies goals. Therefore, we believe this standard is more appropriate than the alternative CDC, IOM and HHS survey standards.

EHR technology must be capable of meeting the standard and the other requirements of the certification criterion in order to be certified. As such, EHR technology must record race and ethnicity according to the OMB standard by providing the option for one or more racial designations to be selected in a manner consistent with the standard. EHR technology must also be capable of aggregating/mapping more granular race and/or ethnicity data to the minimum race and ethnicity categories in the standard if an EHR technology developer implements such an approach. Additionally, to meet the certification criterion, EHR technology must, in conjunction with complying with the OMB standard, be capable of recording that a patient declined to specify his or her race and/or ethnicity. As noted in the Proposed Rule, this ensures inclusion of such patients in the numerator of the MU percentage-based measure.

Gender/Sex

Comments. Commenters requested clarification regarding the data element “gender,” asking whether it was intended that sex and/or gender be collected.

Response. We have clarified that the certification criterion requires the recording of sex, which is consistent with the change made by CMS for its MU objectives and measures.

Comments. Commenters recommended that gender identity and/or sexual orientation be recorded.

Response. We appreciate the submission of these comments, but the certification criterion includes only data required to support the associated MU objective and measure. Therefore, we decline to include these additional data elements.

Preliminary Cause of Death

Comments. A few commenters stated that ICD-10, not ICD-10-CM, was the appropriate standard. A commenter stated that the preliminary cause of death should be in the same vocabulary standard as the problem list (i.e., SNOMED CT®). Conversely, many commenters stated that no standard should be required. These commenters suggested that a text entry for “preliminary cause of death” is most appropriate. These commenters stated that this would avoid the need for provider education on the use of the standard, the difficulty in narrowing down the standard code list to one that might be usable for coding the preliminary cause of death, and workflow changes. Commenters stated that the significance of the preliminary cause of death being a codified value is not of great importance when compared to the final cause of death determined by a coroner through autopsy or as may be required for death certificate purposes. Commenters further stated that the information required by this capability is preliminary and by its very nature will not carry the same weight as a later more final determination. Overall, commenters questioned the cost and burden involved in collecting this information in accordance to a standard versus any perceived benefit as a means of meeting this certification criterion.

Response. We agree with the commenters that the burden and costs, as outlined by commenters, outweigh the potential benefits of recording the preliminary cause of death in accordance with a standard. Therefore, we are not adopting a standard for this data element and free text entry will continue to be permitted.

Comments. A few commenters stated that the preliminary cause of death should not be collected as a data element. A commenter stated that if EHs are not required to record a preliminary cause of death within a specified timeframe from the death, then the commenter requested confirmation that deceased patients must simply have a preliminary cause of death recorded in their charts in order to be included in the MU measure. Otherwise, the commenter stated that it was unclear how EHs would be expected to report on patients who died near the end of the reporting period and have not yet had a cause of death recorded. Commenters also requested clarification for the proposed exclusion that specified if a demographic element is prohibited to be captured by state law, that the EP or EH is excluded from capturing that demographic. Commenters asked if it was acceptable to note once in CEHRT the state law prohibition or if it needed to be recorded for each patient.

Response. Collection of preliminary cause of death data supports the associated MU objective and measure and, therefore, EHR technology must be capable of collecting it. Comments on when the preliminary cause of death must be recorded and the measure exclusion are beyond the scope of this rulemaking. We direct commenters to the Stage 2 final rule for a discussion of the MU objective and measure and responses to these comments.

Additional Data Elements

Comments. Commenters recommended a wide range of additional data elements for inclusion in the certification criterion based on the rationale that the capturing of the data elements could contribute to identifying health disparities and potential reasons for the health disparities. The recommended additional data elements are: residency information (state, county, zip code, street address); country of origin; nationality; type of employment; primary place of employment; highest education level completed; and hobbies.

Response. We appreciate the recommendations for inclusion of additional data elements, but have chosen to limit this certification criterion's scope to only include the data required to support the associated MU objective and measure. Therefore, we decline to include any of the recommended additional data.

• Problem List

In the Proposed Rule, we proposed to replace the terms “modify” and “retrieve” in the certification criterion with “change” and “access,” respectively. Consistent with the interpretation we provided in the S&CC July 2010 final rule, we also reiterated and clarified that “longitudinal care” is used to mean over an extended period of time. For the ambulatory setting, we stated that this would be over multiple office visits. For the inpatient setting, we stated that this would be for the duration of an entire hospitalization, which would include the patient moving to different wards or units (e.g., emergency department, intensive care, and cardiology) within the hospital during the hospitalization. We noted that the HITSC suggested we consider longitudinal care to cover multiple hospitalizations, but we stated that this could be difficult to achieve and may not offer added value based on the duration of time between a patient's hospitalizations and the reason for the hospitalizations. We stated that our clarification of the meaning of longitudinal care also applies to its use in the certification criteria for medication lists and medication allergy lists. We further stated that if we were to interpret longitudinal care as suggested by the HITSC, it would apply to these certification criteria as well and could constitute a change in the capabilities included in the criteria, which in turn would cause them to become revised certification criteria.

We proposed to adopt the International Release January 2012 version of SNOMED CT®. We stated that we agreed with the HITSC that the use of ICD-9-CM should no longer be required due to the pending move to ICD-10-CM, but also stated that it would be inappropriate to require the use of ICD-10-CM for problem lists. We stated that SNOMED CT® (and not ICD-10-CM) would be required for calculation of CQMs and proposed only SNOMED CT® as the appropriate standard for the recording of patient problems in a problem list. We noted that this proposal did not, however, preclude the use of ICD-10-CM for the capture and/or transmission of encounter billing diagnoses.

Comments. One commenter asked why it is necessary to specify a vocabulary for the problem list within an EHR. The commenter agreed with the necessity of SNOMED CT® for exchange, but suggested that we permit the flexibility to either use the vocabulary internally or map to it when exchanging information.

Response. We agree with this commenter that SNOMED CT® is the best vocabulary to use in those certification criteria that focus on electronic health information exchange. It is necessary that we specify a vocabulary for the problem list within EHR technology because it supports the current requirement that EPs, EHs, and CAHs need to meet to demonstrate MU. Since CMS's initial proposal for meaningful use Stage 1 (75 FR 1860), it has explicitly prioritized recording problems in the adopted standards. Further, at 75 FR 44337, CMS states “[w]e further specify that in order to meet this objective and measure, an EP, eligible hospital, or CAH must use the capabilities Certified EHR Technology includes as specified and standards at 45 CFR 170.302(c)” which is the 2011 Edition EHR certification criterion for problem list that requires EHR Technology be able to record problems in either ICD-9 or SNOMED CT® in order to be certified. We also responded to similar questions such as this in our S&CC July 2010 final rule (75 FR 44603).” In the Proposed Rule, we proposed to only permit EHR technology to be certified to record, change, and access problems in SNOMED CT® because we believe that it is the best vocabulary standard for the representation of clinical data and should be used to represent problems beginning in FY/CY 2014. We clarify that this certification criterion does not preclude the use of interface terms, local terms, or other terms from being displayed to a health care provider in lieu of SNOMED CT® to find, select, or view a patient's problem list. However, if such an approach is taken, the EHR technology must ultimately be able to record the semantic representation of the problem list in SNOMED CT®. For example, if a user of a given EHR technology is using a set of interface terms or any other clinical vocabulary that has been mapped to SNOMED CT®, this user may perform a search for a term that represents the patient's problem, select the appropriate term, and “save” that term to the patient's problem list, where it may be displayed. The EHR technology is required to record the problem in SNOMED CT® because this is the requirement described above for alignment with the EHR Incentive Programs. For information exchange, the EHR technology must send the problem in SNOMED CT® because this is the requirement of other certification criteria specified elsewhere in this final rule.

Comments. Commenters expressed support for use of only SNOMED CT® and stated that it is the best standard for optimal clinical data capture and reuse of information captured in problem lists. Some of these commenters stated that the use of a classification system such as ICD-10-CM limits data analysis for clinical research, quality of care measurement and communication between care providers and patients. These commenters stated that ICD-10-CM is a classification, and it is still designed to capture diagnoses and reasons for encounters, not every “problem.” The commenters recommended that ICD-10 CM and PCS, where appropriate, should continue to be required for billing purposes. The commenters also recommended that EHR technology developers should not utilize the problem list for billing since billing practices and national coding guidelines require that claims only reflect those conditions attended to during the encounter being billed and the problem list includes all conditions that may or may not be active and may or may not have been attended to during the encounter.

Conversely, commenters were concerned that they would face additional costs and burden by having to adopt and implement SNOMED CT® as well as ICD-10-CM or ICD-9-CM until ICD-10-CM is required for implemented. Commenters also stated that SNOMED CT® is not currently in widespread use among hospitals. For these reasons, commenters suggested that they be able to use ICD-10-CM for problem lists in lieu of adopting SNOMED CT®. A few commenters suggested this same approach, but also recommended signaling a move to adopt only SNOMED CT® for the next edition of certification criteria. One commenter suggested that we pursue development of a national problem list and centralized services developed and maintained by a cooperative partnership between the public and private sectors.

Response. We appreciate the comments supporting the use of only SNOMED CT®. We agree with commenters that SNOMED CT® provides much better clinical data capture than ICD-10 CM, ICD-9, and ICD-10 PCS, while ICD-10-CM is more appropriate for encounter billing purposes. With the adoption of the 2011 Edition EHR certification criteria we permitted the use of either ICD-9-CM or SNOMED CT® to demonstrate compliance with this certification criterion. In our response to comments in the S&CC July 2010 final rule, we stated that a single standard for clinical information would be desirable in the long term. While SNOMED CT® may not currently be used by a majority of EPs, EHs, and CAHs, we cannot expect its usage to dramatically increase without some encouragement. By requiring EHR technology to be certified to this standard, soon all EPs, EHs, and CAHs will have the capability to record patient problems with SNOMED CT®. This will improve the semantic interoperability of clinical systems, improve the accuracy of data capture, and may in fact provide a better transition to ICD-10-CM. With mapping tools from SNOMED CT® to ICD-10-CM, available from the National Library of Medicine, we anticipate that clinical users will be able to use a clinician-friendly terminology (SNOMED CT®) while administrative users can interact with ICD-10-CM, an administrative terminology. Guidance from the HITSC and our own research has indicated a clear need for clinicians to interact with SNOMED CT® rather than ICD-10-CM, and we view this as an opportunity to improve the usability, accuracy, and safety of problem list management.

The development of a national problem list and centralized services is beyond the scope of our certification program and this rule, but we will consider this as we look to how ONC and other Federal agencies can best prepare the industry for successful EHR technology development and implementation.

Comment. A commenter stated that while SNOMED CT® is the appropriate standard for clinical use (as opposed to ICD for billing and epidemiological purposes), clinicians' experience with this standard is limited, and therefore suggest that we consider requiring the addition of a mapping tool within the EHR technology.

Response. We agree with this commenter, as stated above, that SNOMED CT® is the appropriate standard for clinical use, and we agree that mapping from SNOMED CT® to appropriate administrative codes such as ICD-10-CM will be necessary. The National Library of Medicine is developing mapping tools, and such mappings are also available from commercial vocabulary vendors. We do not, however, intend to require the use of such mappings as part of this 2014 Edition EHR certification criterion.

Comment. A commenter suggested that for dental systems, SNODENT, the dental subset of SNOMED CT®, is the appropriate code set for the recording of dental patient problems in a problem list.

Response. While the commenter may be correct in regards to SNODENT, certification to this certification criterion requires that EHR technology be able to record a patient problem list in accordance with SNOMED CT®. It is our understanding that novel SNODENT content produced by the American Dental Association will be incorporated into SNOMED CT® or the U.S. Extension to SNOMED CT®. This will cause all dental diagnoses to be available in SNOMED CT®. We believe this will be beneficial to EPs that rely more on SNODENT. We also encourage EHR technology developers to include SNODENT in EHR technology when it would be beneficial to providers.

Comments. Commenters stated that SNOMED CT® codes should not be required for display in the EHR. Commenters explained that an EP, EH, or CAH should be able to use whichever code set they prefer for display.

Response. We agree with commenters. As noted above, SNOMED CT® codes are not required for display in the EHR technology in order for it to meet this certification criterion.

Comments. Commenters stated that the SNOMED CT® standard should include the U.S. Extension to SNOMED CT® (citation to National Library of Medicine) and apply to all uses of the standard in certification criteria. Commenters stated that the US extension includes terms important for the MU program, specifically those used in the US but not found in the SNOMED CT® International Release (e.g. for adopting pre-coordinated terms in SNOMED CT® to match those found in ICD-10-CM).

Response. We agree with the commenters that, although not proposed for use, the U.S. Extension is necessary to support the MU program and, therefore, have adopted it in conjunction with SNOMED CT®.

Comments. Commenters stated that to accommodate the regular updates that occur to SNOMED CT® we should establish a mechanism for updating the minimum regulatory standards. Alternatively, a commenter suggested we simply adopt “SNOMED CT®—current International release” as the vocabulary standard.

Response. We appreciate the suggestions by commenters. We have established a process for adopting certain vocabulary standards, including SNOMED CT®, which permits the use of newer versions of those standards than the one adopted in regulation. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets. In response to the commenter's suggestion that we adopt in regulation “the current release of SNOMED CT®” as the standard, we refer the commenter to section III.A.5 earlier in this preamble. This section explains why we cannot take such an approach.

Longitudinal Care

Comments. Commenters expressed agreement with our clarification of the meaning of the term “longitudinal care” for the purposes of this certification criterion and the certification criteria for medication lists and medication allergy lists. However, commenters recommend that we eliminate the term “longitudinal care” from this certification criterion and the “medication list” and “medication allergy list” certification criteria. Commenters stated that our use of the term as described in the Proposed Rule was inconsistent with the common understanding of the term among the health care community. These commenters stated that “longitudinal” should be reserved for referring to care provided across care settings and across episodes or encounters of care. Some commenters suggested replacing the term with “encounter of care,” “episode of care,” or “durational care.” A commenter suggested that for hospital patient problems that are longitudinal across encounters be acceptable given ONC's proposed definition of longitude for hospital inpatients of an admission. This commenter noted that some EHRs are designed such that problems as clinical data objects are distinct from encounter diagnosis, and are longitudinal in concept and design.

Response. We agree with commenters that our use of longitudinal care in this certification criterion and in the certification criteria for medication lists and medication allergy lists has the potential to create confusion. Accordingly, we have replaced this term in the certification criteria with the descriptions we provided in the Proposed Rule and with a terminology change recommended by commenters. Specifically, for the ambulatory setting, we have replaced the term “longitudinal care” with “over multiple encounters.” We believe using “encounters” instead of “office visits” is a more clinically appropriate. We note that this revision has no substantive impact on current or future testing and certification processes. For the inpatient setting, we have replaced the term “longitudinal care” with “duration of an entire hospitalization,” which would continue to include situations where the patient moves to different wards or units (e.g., emergency department, intensive care, and cardiology) within the hospital during the hospitalization and continue to maintain that it would not cover multiple hospitalizations for the purpose of certification. As we stated above and in the Proposed Rule, capturing patient problems over multiple hospitalizations could be difficult to achieve and may not offer added value based on the duration of time between a patient's hospitalizations and the reason for the hospitalizations.

• Clinical Decision Support

We proposed to adopt a revised clinical decision support (CDS) certification criterion as part of the 2014 Edition EHR certification criteria. We noted in the Proposed Rule that we refined the HITSC's recommended certification criterion to provide a clearer understanding of the capabilities that must be tested and certified and to provide greater flexibility to EHR technology developers in designing EHR technology to meet this proposed certification criterion. We proposed to replace the term “clinical decision support rule” used in the 2011 Edition EHR certification criteria and the HITSC recommended criterion with the term “clinical decision support intervention” to better align with, and clearly allow for, the variety of decision support mechanisms available that help improve clinical performance and outcomes. We described that a CDS intervention is not simply an alert, notification, or explicit care suggestion. Rather, it should be more broadly interpreted as the user-facing representation of evidence-based clinical guidance. Our goal in clarifying the nomenclature was to focus more on the representation of the guidance (the CDS intervention) that the EHR technology should offer to the user rather than prescribe the form of either the logical representation of the clinical guidance or how the intervention interacts with the user.

We also proposed to require the use of the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) Standard, International Normative Edition 2010, for retrieving diagnostic or therapeutic reference information and proposed to require the use of CDS when a summary care record was incorporated. We noted that the Infobutton standard has been in active use for several years with many reference content vendors now providing their products in this form, and we proposed to adopt its most recent edition (International Normative Edition 2010) in order to enable a user to retrieve diagnostic or therapeutic reference information. We stated our belief that the use of standard reference information retrieval formats would accelerate the delivery of content to providers and hospitals, and would enhance the flexibility of such implementations because these formats reduce the need to “hard wire” the content databases to installed EHR technology. We indicated that this flexibility would allow EPs, EHs, and CAHs more choices and easier migration across content providers, encouraging innovation and competitiveness among these content providers.

We asserted that it is important for CDS interventions to be triggered when new information is incorporated into EHR technology as a result of a care transition. Consistent with this belief, we proposed that EHR technology enable interventions to be triggered when the specified data elements are incorporated into a summary care record pursuant to the capability specified at § 170.314(b)(1). In consideration of whether EHR technology should be capable of importing or updating value sets for the expression of CDS vocabulary elements using the HL7 Common Terminology Services, Revision 1, standard, we requested comment on industry readiness to adopt this standard and on the benefits it could provide if required as a part of this certification criterion.

Consistent with the HITSC's stated intent, for EHR technology to be certified to this criterion we proposed that it must be capable of providing interventions and the reference resources in paragraph (a)(8)(ii)(A) of § 170.314 by leveraging each one or any combination of the patient-specific data elements listed in paragraphs (a)(8)(i) and (ii) of § 170.314 as well as one or any combination of the user context data points listed in paragraph (a)(8)(iii)(A) of § 170.314. We asserted that EHR technology must also be capable of generating interventions automatically and electronically when a user is interacting with the EHR technology.

Last, expanding on the HITSC's recommendation that the source attributes of suggested interventions be displayed or available for users, we proposed that, at a minimum, a user should be able to review the: bibliographic citation (i.e., the clinical research/guideline) including publication; developer of the intervention (i.e., the person or entity who translated the intervention from a clinical guideline into electronic form, for example, Company XYZ or University ABC); funding source of the intervention development; and release and, if applicable, revision date of the intervention. We asserted that the availability of this information would enable the user to fully evaluate the intervention and enhance the transparency of all CDS interventions, and thus improve their utility to healthcare professionals and patients.

To aid readers, we have done our best to group comments and corresponding responses under subheadings that align with the specific capabilities proposed for the CDS certification criterion.

General Comments on CDS Interventions

Comments. There was overwhelming support for replacing the term “rule” with “intervention.” A few commenters suggested that we provide an expanded list of example CDS interventions such as patient-specific order sets, dosing guidance, documentation forms, and display of patient-specific relevant information.

Response. We appreciate the support for the more expansive term, “CDS intervention” and have used it in the final rule. We would like to note that the examples of CDS interventions in the NPRM were illustrative only, as our focus is not the type of intervention but the clinical intent of an intervention that offers guidance.

Comments. Several commenters commented on the specific capability proposed at § 170.314(a)(8)(i) “Evidenced-based decision support interventions.” They stated that they were confused by and would like clarification on the statement “each one or any combination of the following.”

Response. As noted in the section III.A.4 of this preamble (“Explanation and Revision of Terms Used in Certification Criteria”), in any certification criterion where we had this or similar language, we have revised it to clarify its intent. We refer readers to this section of the preamble for further clarification.

Comments. We received many comments and questions about the mechanism of counting or measuring that the CDS event was enabled or activated. Many commenters believed that that it would be very difficult to track CDS interventions “live” in multiple locations within the EHR technology and within many workflows. As such, some commenters believed this requirement should just be met thorough provider attestation, while others commented that the occurrence, rather than the enabling, of the CDS intervention should be measured. Commenters expressed concern about providers needing or choosing to modify or replace interventions during a reporting period based on quality improvement or clinical needs and how that might endanger their ability to meet MU requirements.

Response. The Stage 2 final rule, published elsewhere in this edition of the Federal Register, provides guidance regarding how an EP or EH would report CDS interventions, or how activation would be managed relative to the EHR reporting period. We thank commenters for their suggestions regarding other methods of tracking CDS, but we believe that the best method of tracking CDS interventions is to capture when they are enabled. So long as EHR technology is capable of recording such an event, then the EHR technology will be capable of generating a report that expresses the CDS interventions that were enabled across a given time-frame such as during an EHR reporting period. In response to these comments, we have revised the first specific capability of this certification criterion to clarify two points: 1) that we intended for an identified set of limited users to be able to select CDS interventions (thus, per the statements above, it should be apparent when these users have enabled certain interventions); and 2) when we used the parenthetical (or activate) we did not mean to imply that activate was a separate functionality from select. In that respect we have clarified the parenthetical to say (i.e., activate).

Comments. Some commenters requested that we not limit CDS interventions to only those tied to CQMs so that providers, hospitals, and specialists could target specific areas where they feel improvement is needed. Other commenters asked that we permit locally defined and developed CDS content and references.

Response. We appreciate both of these suggestions. We refer readers to the EHR Incentive Programs final rule published elsewhere in this edition of the Federal Register for a description of CDS objectives for Meaningful Use. Locally defined and developed CDS content and references are certainly permitted to be used with the capabilities for which certification is required by this certification criterion.

Comments. Several commenters were concerned about “hard coding” CDS to CQMs in EHR technology.

Response. We share this concern and agree that EHR technology presented for certification should leverage standards where possible to retrieve CDS content from external sources (which can be maintained and updated independently from the software release cycle). The Proposed Rule noted that referential sources such as medical texts, primary research articles, and clinical practice guidelines have long been available in electronic form, but the means and manner of accessing them have historically been disconnected from the points in providers' patient care workflows when the immediate availability of the reference sources would optimize clinical decisions. We noted that these tools are being made available through links in EHRs, offering information at relevant points within the clinical workflow. The Infobutton standard was proposed in order to enable a user to retrieve diagnostic or therapeutic reference information. We suggested that the use of standard reference information retrieval formats would accelerate the delivery of content to providers and hospitals, and would enhance the flexibility of such implementations because these formats reduced the need to “hard wire” the content databases to installed EHR technology. This flexibility would allow EPs, EHs, and CAHs more choices and easier migration across content providers, encouraging innovation and competitiveness among these content providers.

Comment. One commenter requested clarification concerning proposed § 170.314(a)(8)(i), expressing an interpretation that an EHR Module can be certified to this paragraph (as well as meeting other 4 paragraphs) if it implements one or more CDS interventions, that none of the interventions need be drug-drug or drug-allergy related, but only if it uses data from the enumerated list in § 170.314(a)(8)(i)(A)-(F). This commenter noted that the EHR Module may address high priority health conditions not included by CMS as a Clinical Quality Measure, and recommended that there not be any inconsistency between the two rules (i.e. a CQM that does not use one of the enumerated data elements present in § 170.314(a)(8)(i)(A)-(F)).

Response. This certification criterion specifies the minimum capabilities EHR technology needs to include in order to be certified. It does not preclude the incorporation of CDS interventions that address health conditions not included in CQMs identified in the EHR Incentive Programs. We expect to have tighter alignment with CDS and CQM in future editions of EHR certification criteria.

Comment. One commenter noted that there would be “mixed ability to meet” several of the specific capabilities proposed in § 170.314(a)(8).

Response. We thank the commenter for their feedback, and understand the concern. We have modified several of the specific capabilities expressed by this certification criterion as well as clarified them in our responses to provide better guidance and more flexibility.

HL7 Common Terminology Services

Comments. Many commenters expressed that additional, ground-laying work would be necessary before the adoption of the HL7 Common Terminology Services could be a requirement for certification. These commenters noted that there would need to be a standardization of value sets, certification of a value set service, and mechanisms to update, maintain, and distribute value sets.

Response. We thank commenters for their feedback and agree that there is not currently a set of publicly available resources that are accessible using this standard. We are coordinating efforts with other Federal agencies to create a value set repository that will be hosted by the National Library of Medicine. This repository will provide value sets in a manner consistent with the HL7 Common Terminology Services in the very near future, and we encourage EHR technology developers to use this valuable resource in order to capture and maintain value sets for CDS and CQM in the future. We intend to reconsider this for certification in a future edition of certification criteria.

Linked Referential CDS

Comments. Many commenters expressed concern that our reference to the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) standard was intended to be required for interactive CDS interventions, and suggested that it was an inappropriate standard for such interventions. Some commenters disagreed with our inclusion of linked clinical references in the CDS certification criterion. Several commenters expressed support for the “Infobutton” standard for referential CDS, while some did not because they were concerned that there was insufficient industry adoption for this standard to be a requirement. One commenter suggested that while this standard is appropriate for linked referential CDS, there may be other methods of providing access to relevant clinical references, and that we should allow for other methods as well.

Response. We agree that the HL7 Infobutton standard is an inappropriate standard for “interactive” CDS interventions. As we described in the Proposed Rule, we intended to require this standard be applied only for referential CDS. Thus, for the purposes of referential CDS, we agree with commenters that expressed concern as to whether there is sufficient industry adoption of this standard. We agree that there may be other methods of providing context aware reference information and, that in some cases, it may be appropriate to use other methods. Nonetheless, we remain convinced that the widespread adoption of HL7 Context-Aware Knowledge Retrieval standard for the retrieval of clinical reference information is an important capability for EHR technology to include. In response to commenters concerns, we have adopted this standard as an alternative to a general capability for referential decision support that does not require a standard. We took this approach because we recognize that in order for CDS to benefit from the HL7 Context-Aware Knowledge Retrieval standard a large enough pool of publishers providing content in a standards-compliant manner need to be available. Thus, had we required that the HL7 Context-Aware Knowledge Retrieval Standard be implemented in order to meet this certification criterion, our requirement could have caused many EHR technology developers to invest in work that would have resulted in no clinical value to an EP or EH—as there may not be a desirable selection of referential CDS content available for consumption through the use of this standard. In future rulemaking, we do expect to require this standard for certification, and we encourage EHR technology developers to begin plans to implement functionality that would support the incorporation of knowledge resources made available with this standard, and seek optional certification for 2014. While we do not certify knowledge publishers, we also encourage such organizations to adopt this standard as a method of providing patient and/or provider facing clinical content to EHR technology. We clarify that because we have expressed the HL7 Context-Aware Knowledge Retrieval Standard-enabled capability in the certification criterion with an “or,” EHR technology that is presented for certification with this capability would not also need to meet the general capability in order to be certified (i.e., one capability or the other will be sufficient to satisfy the certification criterion). Finally, we note that consistent with our adoption of the HL7 Context-Aware Knowledge Retrieval implementation guides (discussed in the patient-specific education resources certification criterion), we have also applied both implementation guides to this standard here.

CDS Configuration; CDS Interventions Automatically and Electronically Occur

Comments. Commenters requested that we clarify our language regarding the configuration of CDS for a given “setting,” when CDS interventions occur in the workflow, and requested that we clarify “user” to mean licensed healthcare professional.

Response. After further evaluation and consideration as to whether they could be unambiguously tested, we have removed references to setting and workflow from this portion of the certification criterion. However, we have retained the first requirement—that CDS can be configured “based on a user's role.” We do not constrain “user” to mean “licensed healthcare professional,” because some users of CEHRT may not be licensed healthcare professionals. For example, a clerical user or a patient user may interact with CEHRT in some way, and there is no reason that the CDS should not be configurable to expose appropriate interventions (screening reminders, for example) to a patient or clerical user. Our requirement here is simply that the system be capable of configuration based on the user's role in the system. We expect that a physician, nurse, clerical worker, and patient would all have different settings, as the CDS interventions to which they should be exposed may differ—or may have different presentation formats.

Comments. Many commenters expressed concern about the term “when incorporated” and the timing of CDS interventions being “triggered” based on data incorporated from the transition of care/referral summary.

Response. We agree that reconciling information into EHR technology requires many steps in order to determine what information is clinically significant and valid. We also understand that there are semantic interoperability challenges for data at this granular level that may make accurate and responsive CDS intervention triggers overly difficult and/or unreliable. In the Proposed Rule, we proposed that EHR technology would need to be able to “enable interventions to be triggered, based on the data elements specified in paragraph (a)(8)(i) of this section, when a transition of care/referral summary is incorporated pursuant to § 170.314(b)(1).” We have revised this language to make explicit three instances that this certification criterion implicitly required:

(1) CDS interventions must be triggered based on data that is already recorded and stored within EHR technology;

(2) CDS interventions must be triggered when a patient's medications, medication allergies, and problems have been incorporated by EHR technology upon receipt of a transition of care/referral summary formatted in accordance with the Consolidated CDA; and

(3) For the ambulatory setting only, CDS interventions must be triggered when laboratory test results/values are incorporated by EHR technology upon receipt of a laboratory test report formatted in accordance with the LRI specification.

We clarified our interpretation of the term “incorporate” earlier in this final rule and have also clarified that the only time incorporation is implicated by the adopted certification criteria is for the incorporation of certain data as a result of a transition of care and, for the ambulatory setting only, when lab results/values are received and incorporated by EHR technology according to the LRI specification. This modification reduces the “incorporated data” that would be expected to trigger a CDS intervention to at most four out of the six originally proposed data elements (three out of six for inpatient EHR technology) (i.e., for the ambulatory setting it would be problems, medications, medication allergies, and laboratory tests and values/results and for the inpatient setting it would be problems, medications, and medication allergies). Thus, for the purposes of this certification criterion, we clarify that EHR technology must be capable of demonstrating that it behaves differently in two states: before and after the incorporation of new information. We make no specification regarding the timing of events. That is—we do not specify that the EHR technology must “trigger” an intervention at the time of incorporation. For example, if a transition of care/referral summary is incorporated into a patient's record with a new medication allergy, the EHR technology will behave differently in this state (would alert the EP who attempts to prescribe this medication) than it did before the transition of care/referral summary had been incorporated.

CDS Source Attributes

Comment. Many commenters expressed support for transparency of the source attributes for CDS interventions. Some commenters expressed concern that requiring the display of such information could be distracting and not well accepted by end users. Commenters wanted clarification that the EHR technology must only enable the display, not be required to supply the content of the CDS intervention and reference source attributes.

Response. The intent of the source attribute requirement is to permit end users of EHR technologies to have transparent access to information about their CDS resources, interventions, and reference information. We do not require the automatic display of the source attributes, just the availability of the information to the end-user. For example, additional action may be required for a user to “drill down” or “link out” to view the source attributes of CDS. We are also not requiring that the EHR technology create the content for the source attributes. In a scenario where the EHR technology developer uses a third party content provider for a clinical reference or interventions it would be the third party from which the EHR technology developer would get this information.

Comment. One commenter suggested that the CDS source attributes should supply not only (A)-(D) but also the specific CQMs associated with the CDS intervention.

Response. We appreciate this comment, which aligns with the direction we stated in the Proposed Rule to align the capabilities of EHR technology, CQMs, and CDS for future stages of the EHR Incentive Programs. Since many CDS interventions are not today directly linked to CQMs, we will not implement this as a certification requirement. This does not prevent CDS intervention developers or EHR technology developers from providing and leveraging this additional attribute to assist EPs, EHs, and CAHs in meeting the expectations of the EHR Incentive Programs.

Comment. Several respondents wanted to eliminate the source attribute requirements for drug-drug and drug-allergy CDS interventions.

Response. Drug-drug and drug-allergy interventions are clinical decision support resources. We proposed that EHR technology be required to enable the user to review the attributes for each intervention or reference source for all CDS resources. We believe that this is important because most EHR technology developers acquire the clinical knowledge that is represented in CDS from external sources. These sources should be available to the EP, EH, or CAH for reasons stated in the Proposed Rule and above. We agree with the commenter that it may be unnecessary or inappropriate for each and every such intervention to offer all of the source attributes. For example, a drug-allergy alert that warns a user not to prescribe a medication to which that patient is allergic may not merit the same scrutiny by the EP, EH, or CAH as an intervention that informs a provider of an opportunity to prescribe a new medication for which a given patient may be a candidate. We therefore have modified this criterion to constrain the required information to a bibliographic citation and identification of the developer of the intervention, and further clarify that global citations are permitted in cases where all interventions of a given type are provided by the same reference. For example, if all drug-drug and drug-allergy alerts are part of product ABC, provided by company XYZ, then one global statement that attributes these references to this product and company is acceptable, and need not be made available for each and every intervention.

Comment. Some respondents requested additional clarity regarding the source attribute requirement. One commenter noted that further clarification is required for “revision dates” “funding source,” and “developer of the intervention” and noted that some CDS recommendations are developed in-house and may not be the result of published work. Additionally, they noted that “developer of the intervention,” and “funding source” may not be easily obtained.

Response. We describe these requirements as follows:

• “Bibliographic citation” (clinical research/guideline) is a reference (if available) to a publication of clinical research that documents the clinical value of the intervention. If no such reference exists, as may be the case for a locally developed intervention, the EHR technology should make this information available as well. In this scenario, an EP, EH, or CAH who is interacting with guidance offered by the EHR would see that there is no clinical evidence available. The absence of such information is, in this case, valuable information and may (or may not) cause the EP, EH, or CAH to heed or ignore the guidance. Note that our goal here is not to assess the quality or evidence basis of decision support, but to enable the EP, EH, or CAH to do so.
• “Developer of the intervention (translation from clinical research/guideline)” is the team, person, organization, department, or other entity that interpreted the clinical research and translated it into computable form. In some cases, this is a “knowledge vendor.” In some cases, this is the EHR technology developer, and in some cases it is an EP or an employee of an EH/CAH. In all cases, there is interpretation and translation from prose to logic that can be interpreted and managed by the EHR technology.
• “Funding source of the intervention development technical implementation” is the source of funding for the work performed by the “developer of the intervention.” In many cases, this will be the same organization as the developer of the intervention, but in some cases, this may be a government agency or Department of Health, commercial insurance carrier, employer, or biomedical product developer. For example, if the Health Department of State XYZ funds company JKL to create an intervention that translates a clinical practice guideline for management of disease ABC that can be incorporated into certified EHR technology as decision support, company JKL would be the “developer of the intervention,” while Health Department of State XYZ would be the “funding source.” In cases where this information is unknown, then the EP, EH, or CAH should have access to the fact that this information is unknown.
• Patient-Specific Education Resources

We proposed to adopt a revised 2014 Edition EHR certification criterion that does not have the language “as well as provide such resources to the patient” at the end of the paragraph. This language is in the 2011 Edition EHR certification criterion, but is redundant of the capability expressed at the beginning of the paragraph. Additionally, we proposed to adopt the HL7 Context-Aware Knowledge Retrieval (Infobutton) standard, International Normative Edition 2010, as the required standard. We stated that HL7 Context-Aware Knowledge Retrieval standard is being increasingly used by more providers to electronically identify and provide patient-specific education resources. Therefore, we stated that it was appropriate to require EHR technology to enable a user to identify and provide patient-specific education resources based on the specified data elements and in accordance with HL7 Context-Aware Knowledge Retrieval standard.

Comments. With respect to patient-specific education materials, commenters focused on some aspect, or the potential affect, of the proposed inclusion of the HL7 Context-Aware Knowledge Retrieval standard. Some commenters supported its adoption as part of this certification criterion. Many commenters requested clarification on whether the use of the HL7 Context-Aware Knowledge Retrieval standard was mandatory (as a replacement of existing functionality). They qualified their support for the standard by suggesting that EHR technology developers (and their customers) be permitted to present education materials for any reference content using existing product capabilities or through a partnership with a content provider of such reference materials. These commenters reasoned that many EHR technologies are designed to allow for self-developed content or for use of third party content without the EHR technology having to go an external source. Some commenters suggested that the HL7 Context-Aware Knowledge Retrieval standard be positioned to augment, rather than completely replace other patient education mechanisms currently in place (e.g., vendor supplied, physician defined). Other commenters opposed the standard's adoption with some stating that its adoption was immature and that limiting the certification to just this standard would create limitations that could have negative effects on workflow and efficiency.

Response. Our goal is to enable EPs, EHs, and CAHs to provide patients with the best possible information in the most efficient and cost-effective ways possible. While we believe Infobutton meets this goal, we also agree with commenters that alternative means for identifying patient-specific education materials could meet this goal and should be available to EPs, EHs, and CAHs. Therefore, we are adopting a certification criterion that requires EHR technology to demonstrate a capability to identify patient-specific education materials using the HL7 Context-Aware Knowledge Retrieval standard (with the applicable implementation guide) as well as through another means (i.e., at minimum, 2 different ways, one of which is through the use of the HL7 Context-Aware Knowledge Retrieval Standard). By doing so, we believe EPs, EHs, and CAHs will have added flexibility in meeting the MU objective and measure and an improved ability to provide quality care to patients.

Comments. A few commenters recommended that we change the wording in the certification criterion. Specifically, they recommended that we change the phrasing in the proposed certification criterion from “each one of the data elements” to “one or more of the data elements.”

Response. As noted above, we have revised the certification criterion to require that EHR technology demonstrate the capability of using HL7 Context-Aware Knowledge Retrieval Standard and another means to identify patient-specific education resources. We have also revised the language referenced by this certification criterion to make it clearer. The certification criterion requires that EHR technology be capable of identifying patient-specific education resources based on data included in a patient's problem list, medication list, and laboratory tests and values/results. To clarify, EHR technology must be capable of identifying patient-specific education resources based on data from any one of these categories. The identification of patient-specific education resources based on a combination of data from these categories would also be acceptable, but in order to demonstrate compliance with this certification criterion EHR technology must be able to identify patient-specific education materials, in some manner, for all of the categories (i.e., a combination of 2 out of 3 categories would be insufficient to satisfy this certification criterion's requirements).

Comments. A commenter stated that the HL7 Context-Aware Knowledge Retrieval Standard, International Normative Edition 2010 (Infobutton) by itself is not implementable, but it can be implemented in conjunction with one of the two available implementation guides: the URL-based Implementation Guide and/or the SOA-based Implementation Guide. They recommended that the certification criterion explicitly require implementation to at least one of the two implementation guides. Other commenters echoed the same point and recommended that the URL-based Implementation Guide as the best implementation guide to accompany the standard.

Response. We agree with the commenters that guidance is necessary for the implementation of the Infobutton standard. Accordingly, as recommended by the commenters, we are adopting the URL-Based Implementation Guide and the SOA-based Implementation Guide. We have adopted them as an “or” meaning that only one would need to be used to demonstrate compliance with this certification criterion. While we recognize that more EHR technology developers may use the URL-based version, we also wanted it to be possible for EHR technology to get certified to the SOA-based version.

Comment. One commenter suggested that CEHRT should permit integration of MedlinePlus Connect to enhance patient education with other languages and topics that may not be available in the vendor's patient education product. They reasoned that this would also help standardize patient education content across different EHR technology developers.

Response. We do not preclude the integration of MedlinePlus Connect in EHR technology and note that MedlinePlus Connect supports the Infobutton standard.

Comments. One commenter recommended that we amend the certification criterion to require that EHR technology identify patient-specific education resources that are compliant with low health literacy standards and provide those resources to the patient in the patient's preferred language. Another commenter provided an opposing view in stating that meaningful users should not be required to provide materials at specific reading and cultural competency levels. They reasoned that for short hospital visits (such as emergency department visits) identifying patients who would need materials at different levels could be difficult.

Response. We appreciate the commenters' recommendations on both sides of the matter. The capability we require EHR technology to demonstrate to meet this certification criterion for the 2014 Edition EHR certification criteria sufficiently supports the correlated MU objective and measure. Therefore, we decline to require a more explicit capability at this time. We note, however, that a patient's preferred language should be recorded per the “demographics” certification criterion (§ 170.314(a)(3)). We would anticipate that, in an effort to be responsive to a patient and provide quality care, EPs, EHs, and CAHs would take the patient's recorded preferred language into consideration when providing patient education materials.

Comments. Many comments also included aspects about: The MU numerator and denominator associated with this certification criterion; the proposal to move the meaningful use objective to core from menu; when education materials needed to be provided; how they needed to be provided; principles behind providing education materials; the quality of the education materials; and that patient educational material need to be provided digitally and free of charge as well as free of any advertising and produced either without sponsorship by parties with conflicts, or with full editorial control vested in the authors, not the sponsors.

Response. We do not believe it is within the purview of certification to regulate some of these matters in the manner suggested by the commenters (e.g., requiring all education materials be free) and believe it best to have the policy for providing education materials set first through MU and then supported by certification. We direct commenters to the Stage 2 final rule for a discussion on the MU objective and measures, including how to interpret the measure, its requirements, and the numerator and denominator of the measure.

• Transitions of Care

We proposed two revised certification criteria for the 2014 Edition EHR certification criteria at § 170.314(b)(1) and (2). The first certification criterion we proposed would have required EHR technology to be able to incorporate a summary care record formatted according to the Consolidated CDA. The second certification criterion we proposed would have required that EHR technology be capable of creating and transmitting a summary care record in accordance with the Consolidated CDA, with certain specified vocabulary standards, and two specified transport standards. As noted in the Proposed Rule, the HITSC recommended a merged revised certification criterion for the 2014 Edition EHR certification criteria that would be generally applicable to both the ambulatory and inpatient settings, with a deviation based on the setting-specific information that would be included in the summary care record. However, based on stakeholder feedback received after the publication of the S&CC July 2010 final rule, we stated our belief that the criterion should be split into two separate certification criteria based on the capabilities required. We explained that this approach would provide developers greater flexibility for certification.

For the same reasons we discussed in the proposal for the new “view, download, and transmit to 3rd party” certification criterion (§ 170.314(e)(1)), we proposed to adopt the Consolidated CDA for this certification criterion because its template structure can accommodate the formatting of a summary care record that includes all of the data elements that CMS proposed be available for inclusion in a summary care record. We acknowledged that care plan, additional care team members, referring or transitioning provider's name and contact information as well as certain hospital discharge information are not explicitly required to be captured by separate certification criteria, unlike most other data included in the summary care record. We noted that the ability to capture these data elements is both implicit and necessary to satisfy this certification criterion (as well as the other certification criteria that rely on the same data). Therefore, we considered, but did not propose, adopting separate data capture certification criteria for each of these data elements in order to make it clear that they are required to be captured. We requested public comment on whether we should create separate certification criteria for all of these data elements in this final rule.

For certain other data elements in § 170.314(b)(2), we proposed to require that the capability to provide the information be demonstrated in accordance with the specified vocabulary standard. We noted that these vocabulary standards were either previously adopted or proposed for adoption in the Proposed Rule, consistent with HITSC recommendations. Additionally, we requested public comment on whether we should require, as part of the “incorporate summary care record” certification criterion proposed at § 170.314(b)(1), that EHR technology be able to perform some type of demographic matching or verification between the patient in the EHR technology and the summary care record about to be incorporated. We believed this would help prevent a summary care record from being combined with or attributed to the wrong patient.

We proposed that EHR technology would need to be capable of transmitting a summary care record according to both of the Direct Project's specifications for secure transport. We also proposed to adopt as an optional standard at § 170.202(a)(3) the SOAP-Based Secure Transport RTM version 1.0 which was developed under the nationwide health information network Exchange Initiative and to which we stated EHR technology should be able to be certified. We included this option to provide added flexibility to those EPs, EHs, or CAHs that may seek to use EHR technology with the ability to transmit health information using SOAP as a transport standard in addition to SMTP to meet MU. We noted that, while we would only permit EHR technology to be certified to these two transport standards, we intended to monitor innovation around transport standards and would consider including additional transport standards, such as a RESTful implementation in this certification criterion.

Further, we requested public comment on whether equivalent alternative transport standards exist to the ones we proposed to exclusively permit for certification. We also requested comment on our proposed approaches for deciding whether additional transport standards would be appropriate and for adopting any such standards through interim final rulemaking with comment. Additionally, in the context of the proposed limitations included as part of the proposed MU Stage 2 measure associated with this objective (which is percentage-based), we requested public comment on any difficulties EHR technology developers might face in determining the numerator and denominator values to demonstrate compliance with the automated numerator calculation or automated measure calculation certification criteria we proposed to adopt.

General Summary

Many commenters reiterated or pointed to the comments they issued in response to the view, download and transmit to a 3rd party certification criterion. Many commenters also repeated points about a consistent set of data to be referenced across the certification criteria that proposed the adoption of the Consolidated CDA. In that respect, we do not repeat those responses where we have already addressed comments in other parts of this preamble that would also be applicable to the transitions of care certification criteria. Similar to the other certification criteria where we received detailed groups of comments on distinct concepts, we have used subheadings to improve the preamble's overall readability.

Receipt/Receive

Comments. Some commenters expressed that the certification criterion proposed at § 170.314(b)(1) was ambiguous. They also indicated that “upon receipt” in the certification criterion implied a capability that should be explicitly stated—that the EHR technology be able to receive a transition of care/referral summary according to the same transport standards we require (and permit) for certification for the transmission of a transition of care/referral summary. These commenters argued that we needed to include this specificity because EHR technology should be tested for both its ability to send and receive data. Further they suggested that we change the paragraph heading to include “receive.”

Response. We agree with commenters that the capability to receive transition of care/referral summaries according to the proposed transport standards was implied and that we should make it explicit. Further, in revising the proposed certification criterion to do so, we also noticed that § 170.314(b)(1) should mirror the same structure as § 170.314(b)(2) with its “ambulatory setting only” and “inpatient setting only” because we had just included a list of data in our proposal that mixed both settings. We are finalizing these changes as well as changing the paragraph heading to better describe the overall capabilities specified by this finalized certification criterion. Any changes to § 170.314(b)(2) in response to public comments, such as the applicability of certain transport standards are discussed in our responses below.

Display

Comments. Several commenters recommended that, at the very least, we include some form of “backwards compatibility” in this certification criterion by requiring EHR technology to be able to display transition of care/referral summary formatted according to the standards adopted as part of the 2011 Edition EHR certification criteria. They reasoned that many EPs, EHs, and CAHs will have 2011 Edition CEHRT capable of creating and displaying a transition of care/referral summary according to the CCD/C32 and CCR. Additionally, they stated that by not doing so, we would significantly limit the ability of trading partners to continue to communicate with each other as they each separately upgraded their EHR technology to the capabilities required by the 2014 Edition EHR certification criteria. These commenters indicated that this requirement would be a relatively low burden since it is already required for certification.

Response. We agree with commenters. We have revised the final certification criterion to require that EHR technology must be able to display in human readable format the data included in transition of care/referral summaries received and formatted according to each of the transition of care/referral summary standards we have adopted (i.e., CCD/C32; CCR; and Consolidated CDA). We believe this modification to the certification criterion, as expressed by commenters, results in a significant benefit while imposing very limited practical burden because it essentially builds on the 2011 Edition version of the certification criterion that we proposed to revise.

Comments. A couple of commenters expressed concern regarding hospitalizations with large volumes of data such as lab results and how this information would display in a summary document of considerable length.

Response. This certification criterion expresses that EHR technology must be able to display transition of care/referral summaries received according to any one of the three adopted standards mentioned in the above response. It does not, however, dictate how that information is displayed to a user. Those design decisions are fully within an EHR technology developer's discretion.

Incorporate

Comments. We received a significant number of comments related to the specific “incorporate” capability expressed in this certification criterion. Many contended that the general description we provided at the beginning of the Proposed Rule was too generic, ambiguous, or inconsistent with their understanding of what it meant to “incorporate” data as this certification criterion described. Commenters offered many perspectives on what incorporation should mean for this certification criterion. Most commenters described incorporation to mean the EHR technology's ability to store and reference data from a transition of care/referral summary.

Many commenters stated that this proposal went far beyond what was required in the 2011 Edition EHR certification criterion's requirements and that it seemed to require that each and every data element referenced be incorporated as structured data. These commenters argued that for the 2011 Edition certification criterion, EHR technology only had to be able to incorporate the CCD or CCR transition of care/referral summary as a whole, thus maintaining its integrity. Some commenters stated that incorporating an entire clinical summary might trigger the creation of a new encounter. Further, they added that for the 2014 Edition version, the only data that should be required to be incorporated (and that should be decomposed from the transition of care/referral summary) should be the same data specified in the “clinical information reconciliation” certification criterion (i.e., problems, medications, and medication allergies) and focus on these data “at a minimum.” Other commenters argued that it made no sense to incorporate all of the data specified in the Proposed Rule because the data would be contextually specific—and could lose its semantic value if removed from the context of the whole document.

Response. We agree with commenters that the single description for “incorporate” in the Proposed Rule was insufficient to provide the clarity necessary for this certification criterion. As many comments expressed, and as we clarified in the beginning of this final rule, we intended for the term “incorporate” to mean that EHR technology would be able to process the structured data contained in those three Consolidated CDA sections (medications, problems, medication allergies) such that it could be combined (in structured form) with data already maintained by EHR technology and would subsequently be available for use, such as to be used as part of the clinical information reconciliation capabilities (expressed in the certification criterion adopted at (§ 170.314(b)(4)). We have revised this certification criterion to make this distinction clear.

In consideration of comments, such as those that indicated it may make no sense to incorporate specific data, we believe that there is clinical value to the extraction and individual display of the individual sections of the Consolidated CDA. To ensure that an EP, EH, or CAH, can reap the most benefit from a Consolidated CDA formatted transition of care/referral summary, we have added to this certification criterion a specific capability that EHR technology be able to extract and allow for individual display each additional section or sections (and the accompanying document header information (i.e., metadata)) that were included in a transition of care/referral summary received and formatted in accordance with the Consolidated CDA. For example, if a user wanted to be able to review other sections of the transition of care/referral summary that were not incorporated (as required by this certification criterion), such as a patient's procedures and smoking status, EHR technology would need to provide the user with a mechanism to select and just view those sections without having to navigate through what could be a lengthy document. We intend for testing and certification to verify that the document header information can be displayed with whatever individual sections are selected, but leave the ultimate quantity of header data to be displayed through implementation up to the EHR technology developer and its customers' preferences.

We recognize this certification criterion is more rigorous than the 2011 Edition EHR certification criterion, but believe that it is necessary to continue to introduce more demanding certification requirements for interoperability in order to advance our policy objectives for widespread electronic health information exchange. We stress that an EHR technology's ability to incorporate data for medications, medication allergies, and problems in structured form from a Consolidated CDA formatted document is the bare minimum necessary for EHR technology to meet this certification criterion. Even though we do not explicitly require more data to be incorporated in a structured form from a Consolidated CDA formatted document, we highly encourage EHR technology developers to go beyond this minimum as we intend to consider a more rigorous incorporation requirement in our next edition of EHR certification criteria. Finally, we believe our response under the “display” heading addresses the comments about incorporating a transition of care/referral summary as a whole, since such a capability would be addressed by the display requirement in this certification criterion.

Comments. A few commenters stated that incorporation should not be automated and that there is a potential safety issue with bringing in data elements that have not been reconciled. Another commenter noted that one of the reasons incorporation cannot be automated is because many EHR technologies require that a term be in their “problem list master file” in order to get onto the problem list and that many EHR technologies have local problem terms that are mapped to SNOMED-CT. As a result, they stated that one cannot assume that two CCDs, each having a problem mapped to the same SNOMED-CT code, are both referring to exactly the same thing. They suggested that this capability be designated as optional. A couple of commenters noted that EPs, EHs, and CAHs should have some control over how exactly they want to be able to incorporate data into their EHR technology as part of their practice/organization.

Along these same lines, commenters responded to our question regarding whether some form of demographic matching would be important to include for this certification criterion. Commenters responded favorably, but requested that we not dictate a standard or any particular matching methodology so as to permit a range of different options and to let innovation continue in this area. One commenter stated that EHR technology must perform patient matching in order to aggregate PHI from multiple sources that provide electronic feeds into the EHR technology. Additionally, the commenter noted that the EHR technology developer typically determines the most appropriate patient matching algorithm based on a number of factors relating to the data available in order to facilitate a correct patient match. They also stated that some EHR technology developers may choose a very robust matching capability based on available demographics or practice size. Another commenter requested guidance on what data would be used for patient demographic matching. While a different commenter recommended that we establish a minimum set of demographic information that could be used to accurately match patient records.

Response. We appreciate commenters' feedback and expressed concerns. We anticipate that EHR technology developers will be able to automate the incorporate capability in some manner, but this certification criterion does not necessarily require that it be fully automated. It is our understanding and, it was implied by the certification criterion, that some form of matching would occur when a transition of care/referral summary is received in order to correctly determine that the document as a whole (as discussed under the “display” heading) was attributed to the right patient. Further, that upon receipt of a transition of care/referral summary is the appropriate point at which to verify that the transition of care/referral summary is being attributed to the correct patient. Accordingly, we have not included this type of matching as part of the clinical information reconciliation certification criterion since the data will have already been attributed to a particular patient at the point in time reconciliation is executed. Finally, we have revised this certification criterion to include a general statement that the EHR technology must be able to demonstrate that a transition of care/referral summary received is or can be properly match to the correct patient. As requested by commenters, we have intentionally left this requirement flexible to permit many different ways for this capability to be designed. As such, we decline to provide specific guidance on particular demographic information except to note that the demographics certification criterion would be a good starting point in addition to any data that may be available in the header of a transition of care/referral summary. We encourage EHR technology developers to apply this specific capability to other capabilities where it may prove beneficial.

Comments. Some commenters asked that we clarify that information made available in an HIE or a portal counts as incorporation for this certification criterion.

Response. Considering the response above and how we have explained our interpretation of “incorporate,” we do not believe or see how this could satisfy the capability required by the certification criterion.

Comment. A commenter in support of incorporating problems, medications, and medication allergies suggested that this data should be incorporated into EHR technology in such a way that those data elements can be used for real-time clinical decision support and recommend that the ONC consider this as an additional criterion.

Response. We refer readers to our discussion of the clinical decision support certification criterion.

Create and Transmit (now Also Applicable To Receive as Part of § 170.314(b)(1))

Comments. As noted in the view, download, and transmit to a 3rd party certification criterion's comment and response section, we indicated that the only place where the data type “encounter diagnoses” would be included was as part of a transition of care/referral summary in the transition of care certification criterion. Similar to the comments we received and discussed related to “procedures,” some comments supported the use of ICD-10-CM while others stated that we should refer to SNOMED CT® and only SNOMED CT® for the same reasons they stated before (e.g., clinical accuracy versus a billing diagnosis code set). One commenter stated that both ICD-10-CM and SNODENT should be a requirement for diagnoses coding in dental systems. They reasoned that SNODENT has been mapped to ICD-9-CM and the mappings between SNODENT and ICD-10-CM are being developed.

Response. We appreciate commenters' feedback. As with procedures, commenters provided many different perspectives on the appropriate vocabulary to adopt for encounter diagnoses. Because this is a billing data type, we have decided to finalize our proposal to allow for the use of ICD-10-CM to represent encounter diagnoses in addition to permitting SNOMED-CT. We believe this is the best approach to take for all parties involved. Additionally, the National Library of Medicine has created a publicly available mapping from SNOMED-CT to ICD-10-CM, available at http://www.nlm.nih.gov/healthit/meaningful_use.html. This mapping is available to any EHR technology developer, or practice management/billing system developer for the translation of SNOMED CT® to ICD-10-CM. In this way, EHR technology may send a representation of encounter diagnosis using either SNOMED-CT or ICD-10-CM. Since providers will most likely be using SNOMED CT® for the selection of problems, this criterion allows for the use of only clinical vocabularies in such clinical systems and the association of problems with encounters, thereby encouraging the translation of SNOMED CT® to ICD-10-CM to occur in an administrative system. By permitting ICD-10-CM to be used to represent encounter diagnosis for certification, we also accommodate EHR technology developers who choose to make this translation within the clinical system as well. We decline to accept the recommendation for us to adopt SNODENT for the same reasons we provide elsewhere in this final rule in response to this comment.

Comments. In response to our question as to whether we should create separate certification criteria for the data elements implicit and necessary to satisfy this certification criterion (as well as the other certification criteria that rely on the same data) some comments expressed support while others opposed doing so and suggested it was unnecessary. Those who opposed the adoption of separate certification criteria for the additional data (e.g., care plans) stated that while standards do not exist at the present time for these elements, they can be incorporated in the Consolidated CDA as text. They did, however, add that because no standards exist, we should consider deferring their adoption until the next edition of EHR certification criteria.

Response. We thank commenters for responding to the question we posed. As suggested by those commenters that opposed the adoption of explicit certification criteria for each of these additional elements, we have not done so. We agree with the logic provided by commenters. So long as the Consolidated CDA can support this information, we believe it is sufficient to continue our approach of referencing this data within the applicable certification criteria. Consistent with our general approach to support MU, we have made sure to align all of the data specified and expected by CMS in applicable certification criteria. Thus, unless CMS removed a particular data element/type, we have included the data element/type in our final rule for the applicable certification criteria.

Comment. A commenter stated that there appeared to be a hidden requirement for CEHRT to translate local codes to standard codes for all data in all instances, including when the original source of the data did not provide the data in standard codes. They suggested that in instances where the EHR technology simply passes-through the data that the requirement to use a standard vocabulary for outbound data exchange be waived. They further explained that when source data such as laboratory results or documentation from non-CEHRT/HIT is received by the CEHRT it may not contain data according to the adopted standard vocabulary. They contended that translating such data to a standard vocabulary should be the responsibility of the data source (to ensure the standard vocabulary is used most appropriately). They noted that downstream translation may not capture the translation subtleties that are clear within the source system's environment. They concluded by stating that it was unreasonable for us to implicitly or explicitly require that outbound data exchange from the CEHRT always apply a standard vocabulary to data that the CEHRT did not itself create until all relevant source systems utilize standard vocabularies.

Response. We agree that there could be scenarios in which an EP, EH, or CAHs CEHRT receives data from a source that has not formatted the data according to the applicable adopted vocabulary standard. In instances where the EP, EH, or CAH's CEHRT receives data from an outside source, we acknowledge that requiring the CEHRT to translate the data into an adopted standard vocabulary could alter its intended meaning. We understand that there may be scenarios in which local or proprietary codes are transmitted in a transition of care/referral summary, laboratory report, or other exchanged document. Further, we agree with this commenter that the responsibility of the sending EP or EH/CAH is to send information with standard terms, and in the case when such standard terms are not used, it should not be the responsibility of the receiving EP or EH to translate local or proprietary codes into standard codes. However, we emphasize that for the purposes of certification, and demonstrating compliance with this certification criterion, EHR technology will need to be tested and certified as being able to apply all of the adopted standard vocabularies to data required to be included in a Consolidated CDA formatted transition of care/referral summary. This response is applicable to the other certification criteria to which this clarification would apply.

Comments. Many commenters supported our proposal to require the Applicability Statement for Secure Health Transport specification (the primary Direct Project specification) and the second Direct Project specification (XDR and XDM for Direct Messaging). Others supported our reference to the SOAP-based transport standard as well. Some commenters contended that we should require both transport approaches for certification. Other commenters stated that we should only require the primary Direct Project specification. While others specified that we should reference the XDR and XDM for Direct Messaging specification as a bridge for the primary Direct Project specification and the SOAP-based transport standard.

Response. In considering the range of comments received, we have finalized a modified certification approach with respect to transport standards. We have adopted, as proposed, that the Applicability Statement for Secure Health Transport specification be a required condition of certification as part of this certification criterion. We have removed the XDR and XDM for Direct Messaging specification as also being required in lieu of a broader range of options for certification. Thus, to be certified to this certification criterion an EHR technology must enable a user to electronically transmit a transition of care/referral summary in accordance with the Applicability Statement for Secure Health Transport specification. This requirement sets a baseline for EHR technology certification and enables simple and secure SMTP-based exchange. Additionally, because this certification criterion is part of the Base EHR definition, all EHR technology used by EPs, EHs, and CAHs and that meets the CEHRT definition will, at a minimum, be capable of SMTP-based exchange. For the reasons we discussed under the “view, download, and transmit to 3rd party” certification criterion earlier in this preamble, we have adopted the updated version of this specification that was established by the stakeholder community during this final rule's drafting.

To permit additional flexibility and options for EHR technology developers to provide their customers with EHR technology that has been certified to support an EP, EH, or CAH's achievement of the “transitions of care” MU objective and associated measure, we have adopted two optional certification approaches for transport standards. For each option, EHR technology would need to demonstrate its compliance with both of the identified specifications in that option in order to be certified to the option.

• The first option would permit EHR technology to be certified as being in compliance with our original proposal: Certification to both the Applicability Statement for Secure Health Transport specification and the XDR and XDM for Direct Messaging specification.
• The second option would permit EHR technology to be certified to: The Simple Object Access Protocol (SOAP)-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 standard and the XDR and XDM for Direct Messaging specification.

We have included the XDR and XDM for Direct Messaging specification as a required specification for both of these options because it serves as the bridge or translator for electronic exchange partners that engage in SMTP to SOAP and SOAP to SMTP exchanges.

Comments. A few commenters noted that the proposal to adopt the Simple Object Access Protocol (SOAP)-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 specification was confusing and requested that we clarify whether its adoption permitted the use of other nationwide health information network specifications to be used (e.g., patient discovery, document query, document retrieval). Some of the same commenters also suggested that we added the IHE-XDR profile as an implementation guide for the proposed standard. Last, these commenters requested that we change the paragraph heading for the transport standards so as not to imply their use is limited to directed exchange.

Response. We seek to clarify any confusion that may have been caused by our proposed adoption of the SOAP-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 specification. As indicated within the specification, its purpose is to “define the primary set of security and transport protocols needed to establish a messaging, security, and privacy foundation for health information exchange.” Further, it is “constrained to technical specifications for security and transport protocols and does not address any content specifications.” Last, it is “intended to provide an understanding of the context in which the web service interface is meant to be used, the behavior of the interface, the Web Services Description Language (WSDLs) used to define the service, and any Extensible Markup Language (XML) schemas used to define the content.

This specification, and not IHE designated specifications, was purposefully adopted because it serves as the baseline SOAP specification on top of which other (March 1, 2012 effective) Nationwide Health Information Network Exchange specifications can be implemented. If an EHR technology is presented for certification to this optional transport standard, we intend for testing and certification to establish that the SOAP specification is properly implemented (i.e., EHR technology's ability to send and receive messages in accordance with the specification). Because this specification serves as the underlying set of web services protocols for other more detailed context/use case specific specifications, we clarify that so long as EHR technology is certified to this baseline SOAP specification other more detailed/use case specific specifications may be used in addition to, or on top of, this specification (i.e., not in lieu of).

With respect to the recommended IHE profile, we did not accept this recommendation. We have included the bridge specification in the XDR and XDM for direct messaging specification and have concerns about the testability of the IHE-XDR profile. As we understand it and as currently described in the IHE Technical framework, the IHE XDR is a “pattern” of a transaction that can be tailored and implemented by EHR technology developers as they wish, based on a particular use case. Additionally, both of the transport standards adopted in this final rule can be used independent of IHE XDR profile. This does not preclude EHR technology developers from also implementing it outside of certification, but we decline to require it as a condition of certification.

Finally, we have removed the paragraph heading in § 170.202 as indicated by commenters so as not to imply that the specifications can only be used in the context of directed exchange.

Comments. Commenters raised several questions and concerns related to the proposed Direct Project specifications and how EHR technology would be tested and certified to the transitions of care certification criteria. Commenters indicated that there are multiple ways to deploy, configure, and implement EHR technology to meet the specifications. Some asked that we clarify whether all implementation options must be simultaneously supported or if some were intended to be prohibited. Further these commenters stated that only one test of a particular implementation/configuration would be necessary to verify that an appropriate SMTP + S/MIME communication was correctly structured, but all implementations would rely on that capability to be present. Commenters recommended that we clarify what would be required to demonstrate compliance with these certification criteria. They recommended that testing and certification focus on EHR technology's ability to correctly create and receive messages formatted in accordance with the Applicability Statement for Secure Health Transport specification. They concluded by stating that this approach would enable EPs, EHs, and CAHs to utilize other email infrastructures without requiring EHR technology developers to test with multiple infrastructures.

Response. We thank commenters for the detailed comments and in some cases illustrations to describe the different deployment and configurations anticipated by the Applicability Statement for Secure Health Transport specification. These detailed comments greatly aided our policy deliberations. We agree with commenters on the approach that should be used to test and certify whether EHR technology is in compliance with the Applicability Statement for Secure Health Transport specification. Specifically, we agree that testing and certification should not focus on particular deployments or configurations, but rather on what will remain constant across those variances—EHR technology's ability to correctly produce and receive SMTP + S/MIME messages formatted in accordance with the Applicability Statement for Secure Health Transport specification. We further clarify that we do not intend for testing and certification to focus on the particular email protocols that may be implemented to support the routing of these messages, such as Internet Message Access Protocol (IMAP), Post Office Protocol (POP) and other vendor-specific proprietary protocols. These capabilities and others such as mailbox management, storage, and forwarding of received messages that would be implementation or deployment specific would not be assessed as part of testing or as a condition of certification.

Further, we expect that the National Coordinator will approve a test procedure for the transitions of care certification criteria that rigorously assesses EHR technology's ability to transmit and receive electronic health information according to the adopted transport, content exchange, and vocabulary standards. We anticipate that this test procedure will be specified to ascertain the EHR technology's ability to engage in standards-based exchange with any other EHR technology that has also implemented the standards we have adopted. To enable this form of electronic testing, the NIST has developed a conformance test tool that receives and validates a Consolidated CDA formatted file from the EHR technology under test. The conformance tool will be a part of a “test bed” that simulates exchange between a test EHR technology and a standards-compliant EHR technology. This will eventually allow for all levels of interoperability to be assessed in the electronic exchange of transition of care/referral summaries. This capability will also provide a future platform for testing more comprehensive forms of interoperability between EHR technologies.

Comment. A commenter requested that we clarify whether a health information exchange using only CONNECT to exchange could meet the certification criterion. Another commenter asked that we confirm that the transport capabilities can be demonstrated by a Complete EHR or EHR Module itself, or through demonstration by the Complete EHR or EHR Module to achieve the transport capability through integration with a service provider—such as a network or health information service provider (HISP). They stated their interpretation that the current definition of an EHR Module permits a combination of a service and a component to be certified.

Response. While we would need to examine a specific fact pattern to issue a definitive response, it seems possible for a health information exchange using CONNECT to seek certification to this certification criterion. We have always maintained and reaffirm that any EHR technology that can demonstrate compliance with a certification criterion can be issued an EHR Module certification as evidence that the capability the EHR technology included was certified. We interpret and use the term EHR technology (and intentionally not the term EHR) broadly so as to permit innovative market-based electronic exchange solutions to be paired with other EHR technology that performs clinically focused capabilities. Thus, to the degree that a HISP or like entity would be performing a capability for which certification is required and an EP, EH, or CAH would like to use the entity's technological capabilities as a way to meet the definition of CEHRT, the entity would need to seek certification for the technical capabilities that its systems can perform as if those capabilities were natively part of the EP, EH, or CAH's CEHRT. In these situations, we highly encourage EHR technology developers to work together to make the use of these capabilities as seamless as possible.

Comments. Commenters suggested that ONC offer guidance on how the sending system will know the transport protocol understood by the receiving system unless that is something the Health Information Service Provider (HISP) would be responsible for indicating so the sending system sends using XDR or XDM appropriately.

Response. Pursuant to our responses above, we believe this comment drifts into a specific implementation dependent scenario. However, we will consider whether additional guidance is required after this final rule to assist stakeholders.

Comments. Several commenters stated that they reviewed potential RESTful transport alternatives and concluded that the alternatives lacked maturity and sufficient testing. A few commenters supported RESTful as an optional standard.

Response. We agree with those commenters that have concluded potential RESTful transport alternatives lack sufficient maturity at this time for adoption. We will, however, continue to monitor the testing and implementation of RESTful transport alternatives to determine whether they have reached a maturity sufficient enough to consider for adoption.

• Clinical Information Reconciliation

In the Proposed Rule, we proposed to revise this certification criterion and adopt as part of the 2014 Edition EHR certification criteria an expanded version that focuses on the reconciliation of data in each of a patient's medication, problem, and medication allergy lists. We proposed to adopt a revised certification criterion at § 170.314(b)(4) which we labeled as “clinical information reconciliation” to express the three specific capabilities that EHR technology would need to include.

We specified that EHR technology would first need to be able to electronically display the data from two or more sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date of the information. We proposed that the second specific capability EHR technology would need to include would be to enable a user to merge and remove individual data. We clarified that, while not required or expected for certification, this capability could be designed to automatically suggest to the user which medications could be merged or removed. The third and final specific capability we proposed that EHR technology would need to include would be to enable a user to review and validate the accuracy of a final set of data elements and, upon a user's confirmation, automatically update the patient's medication, problem, and/or medication allergy list. In our proposal, we emphasized that EHR technology's role is to be assistive and not to determine without human judgment which data elements should be reconciled. Thus, we noted that this third specific capability would require EHR technology to present a final set of merged data for a user to validate and confirm before updating the prior list. Finally, we requested public comment on whether as part of this certification criterion we should require EHR technology to perform some type of demographic matching or verification between the data sources used.

Comments. Commenters were generally in favor of the proposed clinical information reconciliation certification criterion. Many agreed with our proposal to expand reconciliation to include problems and medication allergies, but some stated that it exceeded what was minimally required for meaningful use and that we should just keep the certification criterion focused on medication reconciliation. A couple of commenters stated that the certification criterion was over specified, premature, and prescribed workflow. One followed suit and stated that the requirement to merge the data from a source and automatically update from a foreign source requires common data models and terminology sufficient to instantiate the medication, medication allergy, or problem into the receiving system and that these models and terminologies are not fully defined.

Response. We appreciate commenters support and constructive feedback. We have finalized this certification criterion with specific modifications as detailed below in other responses. We believe these changes may address some commenters concerns, however, we have maintained this certification criterion's scope to include medications, medication allergies, and problems. We believe this is the minimum that EHR technology should be able to assist EPs, EHs, and CAHs reconcile. Further, as we have noted in the transitions of care certification criterion § 170.314(b)(2), we intend for these same three data types to be able to be incorporated from a transition of care/referral summary formatted according to the Consolidated CDA standard and subsequently available to use for reconciliation as part of this capability. We anticipate that test procedures will be developed to thread these steps together where EHR technology presented for certification includes both capabilities (transitions of care incorporation and clinical information reconciliation). While we typically do not express capabilities in certification criteria that exceed what would be necessary to support meaningful use, we remind readers that our authority to adopt certification criteria is not limited by meaningful use. That is, meaningful use does not set a ceiling for certification. Rather, we generally use it as the baseline upon which we propose and adopt, in some cases, more rigorous requirements.

Comments. Some commenters asked for clarification regarding the term “source” in the certification criterion and what would be used to indicate source. They asked if the information would be needed in the future, would be stored as part of the patient record, or if a link could be used to get to the source. Some did not support including this information.

Response. We believe that, at a minimum, EHR technology needs to be able indicate to a user the data's source (i.e., where the data came from). For the purposes of this certification criterion and its linkage to the transitions of care certification criterion (§ 170.314(b)(2)), we intend to focus certification on the identification of the source from the transition of care/referral summary's header. However, we do not preclude other sources, such as patients from being able to be identified as part of this certification criterion. Given the additional specificity in this 2014 Edition version, we intend to incrementally increase and enhance the assistive power of this capability over time.

Comments. Commenters asked what “last modification date” in the certification criterion meant. They asked whether it was the last date of medication reconciliation or the date that the medication was added or updated. Some did not support including this information.

Response. For the purpose of this certification criterion, “last modification date” should be interpreted differently for each data type. For medications, it should be interpreted as the last date the medication was documented, ordered, prescribed, refilled, dispensed or edited. For problems it should be interpreted as the last date the problem was documented or edited. For medication allergies, it should be interpreted as the date that the medication allergy was last documented, edited, or updated.

Comments. Some commenters requested clarification on the term “merge” in the certification criterion and what our expectation was for merge. They also asked that we clarify that merging would only be for medications, medication allergies, and problems.

Response. We interpret “merge” to generally mean that EHR technology assists a user in creating a single list that is representative of the medications, medication allergies, or problems that are relevant to a patient. However, we believe that an approach using plain language to express the desired outcome would make this certification criterion clearer. It would also represent the many acceptable approaches we had in mind when we drafted this proposed certification criterion. Accordingly, we have modified § 170.314(b)(4)(ii) to state that EHR technology would need to enable a user to “create a single reconciled list of medications, medication allergies, or problems.” How this would be accomplished is up to the EHR technology developer, but could include a user's ability to merge equivalent elements and remove/deactivate no longer relevant information.

Comments. Some commenters requested clarification that “confirm” was meant to be interpreted as the list itself and not each individual element within the list.

Response. Confirm is meant to apply to the single reconciled list (not each element) once it meets a user's satisfaction.

Comments. A couple of commenters requested that we expand this certification criterion to require that EHR technology be capable of conducting medication reconciliation using electronic health information exchange to obtain a medication history.

Response. We appreciate this suggestion and recognize its value, however, we did not propose this type of extended capability, nor does meaningful use presently require it. Thus, we encourage EHR technology developers to consider including this capability if they have not already and we intend to bring this topic to the HITSC for recommendations on our next edition of certification criteria.

Comments. Commenters requested that we clarify that the reconciliation process does not require all reconciliation activities to occur in one system function but may be performed in more than one function so that the functions can be placed in appropriate workflows. Commenters also asked that we clarify that each list type was expected to be separately reconciled and not that we expected two or more different list types to be reconciled at the same time (e.g., medication list and problem list). They suggested that we revise the certification criterion to expressly indicate that it would be at least two lists or at least two sources.

Response. To clarify, we did not intend to imply that the reconciliation capability had to happen all in one step. For instance, if medications are reconciled at a different points in the clinical workflow than problems, this would not be precluded by the certification criterion. However, the same underlying reconciliation capability required by the certification criterion would need to be initiated for each of those different list reconciliations. To make this clear we have modified the certification criterion, as commenters suggested to say “from at least two list sources.” We also wish to further explain for commenters that as the certification criterion begins to express each specific capability there is the following introductory text, “For each list type:” This should and is meant to be interpreted as separately applying to each list type. For instance, (b)(ii) would be interpreted as “For each list type enable a user to create a single reconciled list of medications, medication allergies, or problems”. As in, there would be a single list for medications, a single list for medication allergies, and a single list for problems.

Comments. A few comments asked that we provide an example for what an acceptable capability for this certification criterion would be. A commenter explicitly suggested (as part of our example) we clarify that, at a minimum, the EHR technology should have the ability to simultaneously display and update the appropriate list type.

Response. First, we agree with the commenter that EHR technology should have the ability to simultaneously display the list type that is actively being reconciled. We have modified the certification criterion to make this implicit requirement explicit. We believe this is a critical clarification so as to prevent EHR technology from being certified that requires a user to toggle between different views to reconcile data for one list type. As far as an example goes, (and keeping in mind the revisions we have made to this certification criterion) assuming a transition of care/referral summary has been received as part of a transition of care, an EP's CEHRT would need to be able to receive the transition of care/referral summary and make a logical identification of the medications, medication allergies, and problems from the Consolidated CDA formatted transition of care/referral summary pursuant to the incorporation requirement. Next, at the appropriate points in the EP's workflow, the EP would be able to interact with CEHRT to create a single reconciled list for each of the data included in the medication, medication allergy, and problem lists. For each of these lists, once the EP has the data reconciled to his or her satisfaction, the EP would be able to review the list and confirm the reconciled list, which would then be updated and saved as the single medication, problem or allergy list.

Comments. Commenters requested clarification regarding the scenario where the source list is unstructured data. One stated that if the source list is unstructured, then whatever manner the EHR enables unstructured data to be presented which could subsequently be reconciled through manual transcription should be acceptable for certification. One commenter suggested that medications should be reconciled in whatever process the EHR technology supported for the 2011 Edition EHR certification criterion. Other commenters requested clarification that a document received as a Consolidate CDA must contain structured data. They stated that for unstructured data, certification should not require corresponding items to appear on the reconciliation screens.

Response. We agree with commenters suggestions. In the event that data is in unstructured form, any method implemented by which the EHR is capable of assisting in reconciliation is acceptable. Presumably, this is how (at a minimum) reconciliation is performed in accordance with the 2011 Edition EHR certification criterion. With respect to data received from a document formatted in accordance with the Consolidated CDA, we expect EHR technology to be tested on its ability to utilize structured data to assist in the reconciliation process.

Comment. One commenter stated that reconciliation based on two or more lists has been and would continue to be artificial. They stated that the purpose of reconciliation is to reset and consider the patient at transitions of care. Further, they stated that a transition of care may or may not require reconciliation between two or more autonomous, overlapping lists. As an example they indicated that they support both ambulatory and acute care and that a transition from ambulatory to acute care involves a pruning, adding, and filtering the problem list from the ambulatory setting to a working problem list in the acute care setting. They stated that this does not require a demographic match nor does it involve foreign lists. They stated that if the intent of the Proposed Rule was to include lists coming from different legal entities or systems that we should state that it is.

Response. While we understand this commenter's concern, we believe it is somewhat misdirected. This certification criterion is appropriate and broadly applicable to a vast majority of EPs, EHs, and CAHs, many of which will be getting data from multiple sources. Further, this certification criterion applies to EHR technology as a capability required for certification and does not prevent the actions described by the commenter from taking place.

• Incorporate Laboratory Tests and Values/Results

In the Proposed Rule, we noted that, although the HITSC did not recommend that we revise the “incorporate laboratory test results” certification criterion (adopted as part of the 2011 Edition EHR certification criteria at 45 CFR 170.302(h)), we believed that we should leverage the significant progress made by the S&I Framework LRI initiative. We believed that we could achieve this by proposing revisions to this certification criterion for the ambulatory setting. We acknowledged that, by requiring ambulatory EHR technology to be capable of receiving laboratory tests and values/results formatted in accordance with the HL7 2.5.1 standard and the LRI implementation guide, it would be significantly easier and more cost effective for electronic laboratory results interfaces to be set up in an ambulatory setting (i.e., minimal additional configuration and little to no additional/custom mapping). Moreover, we stated that it would increase the likelihood that data would be properly incorporated into ambulatory EHR technology upon receipt and thus, facilitate the subsequent use of the data by the EHR technology for other purposes, such as CDS. We proposed to adopt LOINC® version 2.38 as the vocabulary standard, because the LRI specification requires the use of LOINC® for laboratory tests. We requested public comment on whether the proposed standards for the ambulatory setting should also apply for the inpatient setting and whether the LRI specification (even though it was developed for an ambulatory setting) could be adopted for certification of the inpatient setting as well. Besides the proposed revisions discussed, we also proposed to use the term “incorporate” to replace the terms “attribute,” “associate,” and “link” which were used in the 2011 Edition EHR certification criterion.

In the Proposed Rule, we acknowledged that the LRI specification was undergoing HL7 balloting and stated that we intended to continue to monitor its progress and anticipated that a completed specification would be available prior to the publication of this rule.

Comments. A few commenters commented on our proposal to specify HL7 2.5.1 as the content exchange standard for the receipt of laboratory test results. A couple of these commenters recommended that we should permit HL7 2.3.1 and signal a direction to the market. Another opposed this requirement because they opposed any meaningful use requirement that would restrict laboratory results sent in HL7 2.5.1 to count towards the meaningful use objective this certification criterion supports. They contended that a vast majority of lab results are in HL7 2.3.1.

A couple of commenters indicated that we had erred in specifying HL7 2.5.1 because the Laboratory Results Interface (LRI) specification references both HL7 2.5.1 elements and HL7 2.7.1 elements. Thus a literal interpretation of what we proposed would create conflicts for implementers. These commenters suggested that only the LRI specification should be referenced as the standard. Another commenter suggested that we clarify that code sets should be used in accordance with the guidance provided in the LRI specification. One commenter recommended that we reference a transport standard to transmit laboratory test results.

Response. As we have stated in other places in this final rule, just because EHR technology is required to demonstrate certain capabilities for certification, it does not necessarily mean that those capabilities must always and only be used to demonstrate MU. Those policies are established by CMS.

After conducting additional research, we agree with commenters that we erred in referencing the HL7 2.5.1 standard in addition to the LRI specification. We have removed the reference to the HL7 2.5.1 standard in this certification criterion. We also note, for the same reasons we discussed earlier in this preamble in adopting it for the “transmission of electronic laboratory tests and values/results to ambulatory providers” certification criterion (§ 170.314(b)(6)), we have adopted for this certification criterion the LRI implementation guide approved as a Draft Standard for Trial Use in July 2012 by HL7. We clarify that with the exception of the baseline minimum version of LOINC® that must be supported by EHR technology, we expect, in adopting this specification that it will be followed and implemented as authored. Further, we note that consistent with other certification criteria that rely on lab test results, we expect that EHR technology certified to this certification criterion will be able to make available for subsequent use (such as clinical decision support) the structured laboratory tests and values/results data received. Because we have specified a standard by which EHR technology designed for an ambulatory setting must be capable of receiving lab results, we clarify that testing and certification for this setting will examine whether EHR technology can properly extract lab tests results/values and incorporate the data from the LRI specification for subsequent use. We have included the term incorporate in this portion of the certification criterion for clarity. Last, because this certification criterion only focuses on receipt and not transmission of laboratory orders we decline to modify this certification criterion in response to the commenter's recommendation that we reference a transport standard for transmission of laboratory orders.

With the exception of the change already noted, the only additional modification we have made in response to public comment was to reinsert the phrase “attribute, associate, or link” in 170.314(b)(5)(iii) to reflect the 2011 Edition version of this certification criterion due to the confusion we caused by overloading the term “incorporate.”

Comments. Commenters supported the adoption of LOINC® but expressed concern that LOINC® is subject to frequent updates and that the version we adopt in the rule would be quickly out dated.

Response. We refer commenters to our responses later in this document on our approach to “minimum standards” code sets.

Comments. A few commenters suggested that ONC work with CMS to encourage labs to adopt and use the S&I Framework LRI specification. They contended that without the “source systems” on board that requiring capabilities on receiving systems (EHR technology) would fall short of the intended purpose of reducing development time and costs and improving quality.

Response. We appreciate these comments and will continue to work with our sister agencies in HHS to advance health IT policy in other programs and regulations that affect stakeholders that are not eligible to receive EHR incentive payments.

Comment. A commenter asked that we confirm that “internal exchanges” within an organized health care arrangement (OHCA) (e.g., between the OHCA's clinical laboratories and its EHR systems) are not subject to this certification criterion.

Response. This certification criterion specifies the capabilities that EHR technology must include in order to be certified. It does not implicate organizational exchanges.

Comments. Several commenters echoed that the LRI specification should not be applied for the inpatient setting.

Response. We agree and have not referenced it for the inpatient setting in the final certification criterion.

Comment. A commenter requested a list of CPT codes that define imaging studies and a listing of CPT codes that define a laboratory test.

Response. We received this same comment on the “transmission of electronic laboratory tests and values/results to ambulatory providers” certification criterion. As with the comment on that certification criterion, the commenter did not provide any supporting rationale as to why a list of CPT codes would be relevant to the capabilities expressed by this certification criterion. Thus, we decline to provide any additional information.

Comments. A couple of commenters stated that the LRI specification includes a number of different “profiles” that provide options for users. They added that this approach was taken because the authors of the LRI specification recognized that not all systems or users would or should be able to meet a single set of requirements. These commenters recommended that the profile choice be left to the EHR technology developer and that we not require all combinations of all profiles to be required.

Response. We do not intend to specify a particular profile or limit the use of the LRI specification to only one profile at this time. We understand that the LRI specification was drafted to create a path toward more constrained and specific implementations, the most rigorous being the Base + GU + RU (GU = Globally Unique Identifiers and RU = Unique Filler or Order Number Required). We intend to move toward this direction in our future rulemakings. We also seek to clarify for EHR technology developers that we do not expect the optional portions of the LRI specification/profile to be tested.

Comment. A commenter asked that we clarify that the certification criterion only applies to the electronic receipt of laboratory results and does not apply to the electronic transmission of the laboratory test order to the laboratory.

Response. This certification criterion only applies to the electronic receipt of laboratory tests and does not focus on the transmission of orders.

Comments. A couple of commenters requested we clarify that because EHR technology would need to include the capability to display all of the test report information specified in the CLIA rules at 42 CFR 493.1291(c)(1)-(7) in order to meet this certification criterion, that doing so with transport standards that provided an acknowledgement back to the laboratory that the complete message was received as sent would satisfy the CLIA requirements for the delivery of a laboratory report.

These same commenters touched on a different point and suggested that because the capability expressed by this certification criterion required EHR technology to be capable of displaying all of the test report information specified in the CLIA rules at 42 CFR 493.1291(c)(1)-(7), that such capability should be enabled by default and must not be capable of being changed, overwritten, or deleted. They suggested this modification to the certification criterion because “CLIA mandates that the physician actually view the information.”

Response. As we stated in the S&CC July 2010 Final Rule (75 FR 44608) “the scope of our authority under this final rule only applies to capabilities that Certified EHR Technology must include. As a result, we cannot provide the regulatory relief that these commenters seek.” However, we would note that what the commenters have described could go a long way towards meeting the requirements set forth in 42 CFR 493.1291. We encourage commenters to consult with CMS regarding particular implementations and questions with CLIA regulatory compliance. We also note that significant progress has been made to ensure that Direct Project specifications can be implemented in a CLIA compliant manner.

With respect to the interpretation provided by the commenters, that “CLIA mandates that the physician actually view the information,” we have consulted with CMS and seek to clarify that this interpretation is incorrect. The CLIA rules do not specify how results can be viewed by a provider, just that they can be accurately, timely, confidentially and reliably transmitted to the final destination. Laboratories need to verify that this occurred, as well as that the CLIA required elements were sent, but there is no requirement in the CLIA rules that a provider must be able to immediately view all of the information. Thus, we did not modify this certification criterion in response to the additional requirements suggested by the commenters as they would artificially lead to design limits that are unnecessary to impose as part of certification. We do, however, encourage EHR technology developers to present the laboratory test data in a format that is most useful to the provider who will use them.

• Clinical Quality Measures

For the 2014 Edition EHR certification criteria, we proposed to revise previously adopted CQM certification criteria for the ambulatory and inpatient settings to more explicitly specify the capabilities EHR technology would need to include. These revisions focused on:

• Data capture—the capability of EHR technology to record the data that would be required in order to calculate CQMs.
• Export—the capability of EHR technology to create a data file that can be incorporated by another EHR technology which could be used to calculate CQMs.
• Calculate—the capability of EHR technology to incorporate data (from other EHR technology where necessary) and correctly calculate the result for CQMs.
• Report—the capability of EHR technology to create a standard data file that can be electronically accepted by CMS.

We noted that by explicitly proposing separate CQM certification criteria focused on these discrete capabilities user experiences relative to CQMs could be enhanced, the burden of capturing data elements necessary for CQMs could be reduced, and ultimately, EPs, EHs, and CAHs would be better positioned to assess in real-time the quality of care they provide.

Data Capture

We explained in the Proposed Rule that prior to the EHR Incentive Programs, measure stewards did not routinely or traditionally specify CQMs with consideration of EHR technology and its capacity to capture certain data. We further explained how the National Quality Forum (NQF), under contract with CMS, created the Quality Data Model (QDM), which today serves as the information model from which new CQMs are specified. We explained that because older CQMs were not specified as “EHR-ready” when initially developed, they may implicitly specify certain data capture requirements that most EHR technologies cannot perform (or do not perform in any structured way) as well as constructs that would still require human intervention or judgment (i.e., “chart abstraction”). Despite the best efforts to “re-tool” older measures for inclusion at the beginning of the EHR Incentive Programs, we acknowledged in the Proposed Rule that we understood that the CQMs required for certification as part of the S&CC July 2010 final rule did not, in some cases, adequately reflect a pure “EHR-ready” CQM. We further noted that as a result, EHR technology developers created new data fields and/or advised their customers to use specified (and in some cases alternative and atypical) workflows, templates, or form elements to capture these data in a consistent manner in order to facilitate CQM calculation.

In the Proposed Rule, we explained that the CQM lifecycle in the EHR starts with the determination of data to be captured and the subsequent capture of clinical or demographic data. Thus, the first specific capability we proposed for CQM certification (§ 170.314(c)(1)(i)) focused on the capability of EHR technology to electronically record all of the data elements that are represented in the QDM. More specifically, we stated that EHR technology would need to be able to record data in some representation that can be associated with the categories, states, and attributes represented by the QDM. We provided the following simple example: EHR technology would need to be able to record a representation of “Medication active” or “Problem active” where the first term represents the QDM category and the second represents the QDM “state of being.” We noted that in certain cases, such as in the prior example with “Problem active,” the data capture necessary is already specified by another certification criterion proposed for adoption as part of the 2014 Edition EHR certification criteria (i.e., § 170.314(a)(5) to record active problems). However, we acknowledged that in other cases an EHR technology developer would need to review the QDM to ensure the EHR technology presented for certification captures data elements that are not explicitly required to be recorded in other proposed certification criteria. We explained that because the QDM is agnostic to health care settings (e.g., ambulatory and inpatient settings) and all of the CQMs ultimately adopted by CMS in a final rule would be based on the QDM, we did not believe that it would be necessary or possible to propose specific separate ambulatory and inpatient setting certification requirements as we have with other proposed certification criteria. Thus, we stated that all EHR technology regardless of the setting for which it is designed would need to meet § 170.314(c)(1)(i) if it is presented for certification to this certification criterion.

We recognized in the Proposed Rule that the gap between the data defined by the QDM and the data traditionally captured in EHR technology is, in some areas, broad. We requested comments regarding: (1) Industry readiness for the expansion of EHR technology data capture; (2) how this would impact system quality, usability, safety, and workflow; and (3) how long the industry believes it would take to close this gap. We also acknowledged that some specialty-focused EHR technologies may not need to capture all of the data that the QDM describes and requested public comment on how certification could accommodate specialty EHR technology developers so that they would not have to take on development work (solely to get certified) for functionality that their customers may not require. Finally, we requested public comment with respect to whether we should pursue one or more of the alternative approaches below for certification in the final rule and made specific requests for public comment on those alternatives.

• CQM-by-CQM Data Capture: As an alternative to our proposal on certification for data capture, we considered a data capture approach that would be based on the data elements reflected in the individual CQMs selected by CMS instead of the entire QDM.
• Explicit Certification Criteria: We recognized that, in some cases, many EHR technologies already capture data elements included in the QDM even though they are not explicitly required by an adopted certification criterion. In these cases, we considered and believed that it would be clearer (and easier for EHR technology developers) if we were to either add specific CQM data capture requirements to already existing certification criteria or adopt new certification criteria in order to explicitly require the data that is specified by the QDM to be captured. In other cases, we noted that despite a measure steward specifying that certain data capture occur, we are unaware of a consistent or established method with which EHRs capture certain information. For example, we stated that most EHR technology of which we are aware does not consistently capture why a particular medication was not prescribed, nor do they systematically make a distinction between “patient reason,” “system reason,” and “medical reason.”
• CQM Exclusions: In cases where a CQM specifies a negation exclusion, we proposed that EHR technology would not be required to capture the “reason” justification attribute of any data element in an encoded way. Rather, we proposed to permit “reason” to allow for free text entries. For calculation and reporting purposes, we proposed that the presence of text in the “reason” field may be used as a proxy for any “reason” attribute.

• Constrain the QDM: Based on our work with CMS and NQF, we considered the creation of a draft “style guide” to constrain the QDM in a manner that would identify a subset of data types and their associated attributes that we believe EHR technology could reasonably be expected to be captured. We noted that measure stewards would then need to constrain CQMs to reference only data elements that are within the boundaries of the data types/attribute pairs expressed in the constrained QDM style guide. We expressed that such CQMs would be identified as “2014-EHR-ready” while other CQMs would not. We stated that we would subsequently collaborate with CMS to remove CQMs that did not qualify as “2014-EHR-ready” from the EHR Incentive Programs requirements and, as discussed above, could add certification criteria in our final rule in order to explicitly define the data types and attributes that will be necessary for complete CQM data capture according to the constrained QDM style guide. We believed this option would serve to align the capabilities of EHR technology with the expectations of CQMs and would provide a solid path toward an additional alignment of CQMs with CDS for future stages of the EHR Incentive Programs. We suggested that CDS could provide the interactive capability that would be required in order to capture the granular exclusion data that is expected today by many CQMs. We noted that with the inclusion of CDS in the clinical quality improvement strategy for future stages of this program, we expected to be able to remove the flexibility for the capture of “reason” attributes. This would improve the accuracy of CQMs while retaining optimal clinical workflow because CDS would ideally be engaged to prompt for this information only where indicated rather than in all cases.
• Explicit Data Capture List: The last approach we considered was (instead of specifying the QDM) to publish the complete list of unique data elements that would be required for data capture in order to be assured that CQMs could be calculated. We explained that the advantage of this list is that it would provide explicit guidance to EHR technology developers and could potentially reduce the upfront work that each individual EHR technology developer would need to do in order to prepare their EHR technology for certification.

Data Export

In addition to being able to capture data elements for CQMs, we proposed that EHR technology presented for certification must be able to export this data in the event that an EP, EH, or CAH chooses to use a different certified EHR Module to perform the calculation of CQM results. We included the export capability as part of the certification criterion proposed at § 170.314(c)(1). We indicated that this approach would preserve portability and flexibility and offer the EPs, EHs, and CAHs the option of using regional or national CQM calculation and/or reporting solutions, such as registries or other types of data intermediaries that could obtain an EHR Module certification for the services that they offer. We acknowledged that we were unaware of the existence of a widely adopted standard to export captured CQM data. We also proposed that it would be at the EHR technology developer's discretion to determine the format of the data file that its EHR technology would be able to produce as well as whether the data would be exported in aggregate or by individual patients. We recognized that this scenario would not be ideal, but we believed that it could also create a market in which EHR Modules focused on CQM calculation (and reporting) could be designed to exploit the disparate data files that EHR technologies produce. Finally, we requested comment on whether any standards (e.g., QRDA category I or III, or Consolidated CDA) would be adequate for CQM data export as well as whether Complete EHRs (that by definition would include calculation and reporting capabilities) should be required to be capable of data export.

Import and Calculate

In the S&CC July 2010 final rule (75 FR 44611) and finalized in the respective certification program rules (75 FR 36170, 76 FR 1276), we discussed requirements that ONC-Authorized Testing and Certification Bodies (ONC-ATCBs) and ONC-Authorized Certification Bodies (ONC-ACBs) must report to ONC the CQMs to which a Complete EHR or EHR Module has been certified and that ONC-ATCBs and ONC-ACBs must ensure that Complete EHR and EHR Module developers include on their Web sites and in all marketing materials, communications statements, and other assertions related to a Complete EHR or EHR Module's certification the CQMs to which the Complete EHR or EHR Module was certified. These requirements can be found at § 170.423(h)(5) and (k)(1)(ii) and § 170.523(f)(5) and (k)(1)(ii). The posting of this information on the Certified HIT Products List (CHPL) combined with Complete EHR and EHR Module developers making this information available in association with their certified Complete EHRs and EHR Modules provides both transparency and useful information for potential purchasers (e.g., EPs, EHs, and CAHs) that are trying to determine what EHR technology best meets their needs.

We discussed that we previously adopted at § 170.304(j) the CQM certification criterion for EHR technology designed for an ambulatory setting and expressed that it was treated as a threshold. We explained that, if an EHR technology included all 6 of the core CQMs specified by CMS and at least 3 other additional CQMs, it could meet the certification criterion. We noted that if there was an additional CQM that the EHR technology included, CMS permits the EP to report on that CQM, even though it was not expressly listed on the CHPL. We also explained that some EHR technology developers sought certification to only the 9 CQMs required to meet the threshold, and thus the criterion, but subsequently communicated to EPs that their EHR technology was certified for all of the CQMs it included. We noted that other EHR technology developers took the opposite approach and sought certification for more than the 9 CQMs and consequently, those EHR technologies were listed on the CHPL as being certified to more CQMs.

We sought to eliminate this disparity by proposing that EHR technology presented for certification to § 170.314(c)(2) would need to be certified to each and every individual CQM for which the EHR technology developer seeks to indicate its EHR technology is certified. We believed this approach would provide transparency and greater certainty regarding the “certified CQMs” that EHR technology includes, given CMS' proposal to only permit EPs, EHs, and CAHs to report on CQMs with EHR technology that has been certified to capture and calculate those CQMs.

We proposed a separate certification criterion at § 170.314(c)(2) for the calculation of CQMs in anticipation that, in many cases, the calculation of CQMs could be performed by an EHR technology that is different from the one that was certified to capture the CQM data. For example, the calculation of CQMs could be performed with a commercial solution or the popHealth tool. The certification criterion we proposed included two specific capabilities. The first capability (§ 170.314(c)(2)(i)) would require that EHR technology presented for certification would need to be able to electronically incorporate all of the data elements necessary to calculate CQMs for which it is to be certified. We explained that, for cases where an EHR technology developer presents an EHR technology for certification that is also being certified to § 170.314(c)(1) and (3) (i.e., the EHR technology would be able to do all three capabilities: capture, calculate, and report), we did not believe that it would be necessary for an EHR technology to demonstrate its compliance to § 170.314(c)(2)(i). However, we specifically requested public comment on this assumption before we added this exception to the certification criterion. In all other cases, an EHR technology would need to meet § 170.314(c)(2)(i) and (ii).

The second specific capability (§ 170.314(c)(2)(ii)) we proposed focused on an EHR technology's ability to calculate each CQM for which it is presented for certification. We clarified that if an EHR technology is presented for certification with test results for 20 CQMs, then the most CQMs that could be included as part of its certification and listed on the CHPL would be 20. Furthermore, we emphasized that an ONC-ACB would need to review each of the 20 CQMs for which the EHR technology is presented for certification and make a separate determination as to whether the calculation test results for each CQM are satisfactory and accurate. We expressed our expectation that EHR technology certified to this criterion would be capable of accurately, and without errors, calculating CQMs and that the accuracy of these calculations would be verified through testing. We requested public comment, especially from measure stewards and EHR technology developers, on the best way for CQM test data sets to be developed.

Given the separation between capture and calculation, combined with CMS's policy that only CQMs calculated by CEHRT would count for attestation and electronic submission, we acknowledged that a scenario could arise where an EP's, EH's, or CAH's CEHRT (composed of certified EHR Modules—perhaps from different vendors) could capture more data than it is certified to calculate. Recognizing that this scenario could present challenges for providers who possess licenses to such mismatched certified EHR modules, we requested comment regarding this scenario and its likelihood and any additional methods we could employ to mitigate this risk.

Reporting

We proposed a certification criterion at § 170.314(c)(3) to require EHR technology to enable a user to electronically create for transmission CQM results in a data file defined by CMS. We noted our expectation that this capability would require EHR technology to generate an eXtensible Markup Language (XML) data file with aggregate CQM calculation results in the format CMS would have the capacity to accept. We also anticipated that CMS would make available the XML data file template in time for us to adopt it in our final rule. We believed that this approach would give EPs, EHs, and CAHs a default solution for reporting CQMs electronically. We noted that if EPs, EHs, and CAHs elect to use their CEHRT to pursue an alternative reporting mechanism permitted by CMS for the EHR Incentive Programs, then it would be the EP, EH, or CAH's responsibility for ensuring compliance with the alternative mechanism's requirements.

We organized the comments and responses below using the same subheadings we used in the Proposed Rule as well as other more specific subheadings on particular topics.

Capture

Comments. Many commenters stated that certification to the entire QDM would place too much of a burden on EHR technology developers, noting that the QDM includes many data elements not traditionally captured in the EHR. Many commenters stated that ONC should require capture of only data elements that are contained within the CQMs that EHR technology developers chose to implement for calculation via their technology as opposed to a requirement that EHR technology capture all of the data elements required for calculation and reporting for all of the clinical quality measures or the entire QDM. Some commenters also noted that design and development for capture of the entirety of the QDM would be a distraction from much needed development of features and enhancements to existing technology. Many commenters also expressed concern with the clinical relevance of the entire QDM. Several commenters suggested ONC require EHR technology to capture to a constrained QDM as described in our Proposed Rule.

Several commenters noted that the QDM is not intended as a certification standard, but as an extensible model for discussing the types of data that are included in quality measures, and that for an EHR to be usable, each of these pieces of information would need to be captured with appropriate standard terms, at appropriate points in the appropriate user's workflow. These commenters also stated that the scope of the work to be done to capture all of the data elements envisioned in the QDM is “enormous.” One commenter compared the capabilities of EHR software today against 2,100 of the category and attribute combinations in the QDM, and found that only 400 of the 2,100 were always or usually captured in EHR workflows. More than half were never captured in EHR workflows. This commenter suggested that we publish a list of all data elements required for the CQMs included in the Stage 2 final rule rather than reference the QDM.

One commenter suggested that ONC work to constrain the QDM by aligning parts of the QDM with “core” and “optional” CQMs.

Some commenters suggested that EHR technology be required to capture all data elements that are components of the EHR Incentive Programs CQM measure set.

One commenter suggested that we perform a full assessment of the data elements and associated attributes that are required by the QDM to determine if each of these are appropriate and required for CQM reporting.

Some commenters stated that all EHR technology developers should be required to certify their EHR technology to all CQM data elements in the EHR Incentive Programs measure set to ensure that EPs, EHs and CAHs have the flexibility of selecting appropriate CQMs from the entire set to avoid situations where EHR technology developers have too much influence over provider quality improvement measures rather than the local institutions' quality improvement goals.

One commenter stated that some Stage 1 CQMs require a level of clinical documentation and the capture of data that are far more extensive than the 2011 Edition EHR certification requirements and are not necessarily in common use. Furthermore, this commenter stated that some data for the inpatient measures comes from documentation that may be contained in written or dictated notes in the EHR and therefore not available in encoded form.

A commenter stated that is critical that EHR systems support the collection of data from all sources, including from patients, nurses, other providers, and other systems and that quality measurement should not be dependent on the direct entry of data by EPs.

Response. We agree that capture of the entirety of the QDM as a requirement for certification is not appropriate, and we know of no systematic constraints to the QDM, including a distinction between “core” and “optional” measures that would meet the needs of our certification program for 2014. Yet, we are optimistic that a future version of the QDM may provide guidance for CQM developers on the feasibility of certain elements or element types for EHR technology. We may therefore incorporate the QDM and a QDM “style guide” in future rulemaking. We do not believe that it is appropriate for all EHR technology developers to have to seek certification for their EHR technology to all of the data elements necessary for all CQMs included in the Stage 2 final rule. We understand that there exist many EHR technologies that have been developed for specialty markets such as chiropractics, dentistry, ophthalmology, and wound care. Some CQMs are not relevant to the providers in these specialties and are therefore unnecessary to be built into the systems that they purchase. Such a requirement would cause these EHR technology developers to divert development resources away from the features and functionality that these providers need in future releases to functionality that would be present only for certification—and would never be used. It is our intent that this program aligns the functionality of CEHRT with the true clinical needs of EPs, EHs, and CAHs and, by extension, their patients. We agree that EHR technology developer selection of measures may impact the options available to providers, and we encourage the developers of EHR technology submitted for certification to present the broadest range of measures for certification possible, in order for EPs, EHs, and CAHs to have as much flexibility as possible in selecting measures for reporting under the EHR Incentive Programs. If EHR technology developers create sufficient functionality to meet EP, EH, and CAH needs in the future, we will not need to mandate an expansive requirement (such as a requirement to certify EHR technology for all CQMs selected for the EHR Incentive Programs) in subsequent rulemaking.

We will therefore require EHR technology submitted for certification to § 170.314(c)(1)(i) to be capable of capturing the data elements specified in the standard adopted at § 170.204(c) (Data Element Catalog) as required for each and every CQM for which the technology is to be certified (the “CQM-by-CQM Data Capture” option discussed in our Proposed Rule (77 FR 13851)). For example, if EHR technology developer XYZ is seeking to certify their EHR technology for CQMs 1 through 10, 13, 15 and 22, then the EHR technology developer will need to review the list of data elements in the standard adopted at § 170.204(c) for each of these CQMs and demonstrate that each of these data elements can be captured by the EHR technology. Also included in the standard adopted at § 170.204(c) is a list of “supplemental” data elements required for CQM data submission to CMS. The list of supplemental data elements will be required for capture and transmission in each and every CQM report and includes (but is not limited to) race, ethnicity, sex, payer, Medicare HIC number, and where appropriate, NPI, CCN and TIN.

We selected this option for several reasons. First, as noted above, there was strong support for this option in response to the Proposed Rule. Second, this option provides flexibility for EHR technology developers because it allows them to clearly understand the necessary data elements required to be captured for their customers (based on the CQMs for which they intend to seek certification) rather than the entirety of the QDM. This is a significant improvement from our 2011 Edition CQM certification criteria, and will, in combination with a publicly available value set repository that the National Library of Medicine will release, assist EHR technology developers in meeting the requirements of CQM reporting. We believe that many of the historical problems with CQM reporting were due to the absence of accurate and complete data capture. A provider cannot accurately report on data from EHR technology that was not captured by EHR technology. With specific guidance and defining of the data that will be required for each CQM, we are now providing the foundation on which more accurate and reliable CQM reporting can be based. The supplemental data elements mentioned above are required by CMS, and will be important for the accurate processing, stratification, and assignment of CQM reports.

EPs, EHs, and CAHs may employ many methods to capture the information required by CQMs and we do not intend for this criterion to imply that technology submitted for certification would be required to demonstrate manual data entry through a user interface (such as form fields or templates). Rather, the technology must be capable of capturing the information in some manner, and this includes information transferred from other systems (such as a practice management system, PHR, portal or kiosk).

We appreciate the comments on the CQM measure set from the Stage 1 Final Rule. Some EHR technology certified to the 2011 Edition EHR certification criteria do not capture all data elements of these CQMs as structured data, and we note that this was not explicitly required for 2011 certification. This will be required for 2014 certification, as described above.

CQM Exclusions

Comments. One commenter stated that only exclusions that are clinically meaningful to ongoing care of the patient, for example, an allergy or drug intolerance should be required for CQMs in order to reduce the burden on documentation. Other commenters stated that negation rationales, exclusions and exceptions, should be minimized and be clinically relevant. Multiple commenters also suggested that negation rationales should not allow any free text submissions by providers, because free text would be very difficult to codify, use for decision support, or normalize or perform analytics.

Many commenters expressed support for linking CQM and CDS to improve the quality of care and patient outcomes. Some commenters expressed concern that the linkage of CDS to CQM would lead to alert fatigue and if a 1:1 CQM:CDS intervention was required and that would be a burden to both developers and users of EHR technology. Commenters also expressed concern that our Proposed Rule does not include criteria for “linking” or “relating” CDS and CQM.

Response. We appreciate the comments on our proposal regarding CQM exclusions. We agree that all data elements needed for CQM calculation should be discrete and codified. We don't believe that exclusions and exceptions must be captured to the granular level of detail described by a CQM that was developed for manual chart abstraction, but agree that where this granular data is available in coded form, it can and should be employed. In light of these comments, we will not require free text, but will permit that free text be captured and made available in addition to a codified entry. Codified entries may include specific terms as defined by each CQM, or may include codified expressions of the three global concepts: “patient reason,” “system reason” or “medical reason.” In addition, we appreciate the comments regarding linkage of CDS to CQM, and agree that this should not be an explicit requirement for 2014 certification, as we have not formally defined how CDS and CQM should be “linked” or how this would be tested. We do not intend to require a 1:1 requirement of CDS interventions to CQM. Rather, we suggest that EHR technology developers incorporate CDS interventions for the clinical areas in which they have selected to submit CQMs for certification. For example, if an EHR technology developer has selected to seek certification for NQF 0028 “Preventive Care and Screening: Tobacco Use: Screening and Cessation Intervention,” then we would recommend that they incorporate CDS that would enable their customers to assess their patients' smoking status and facilitate the documentation of smoking cessation interventions.

Data Export

Comments. Several commenters supported standardized patient level data export capability as a certification criterion. A few commenters stated concern regarding the use of QRDA category I as an export standard noting that requiring a separate export format to support clinical quality measurement is an extra step in quality improvement with “little value added” that increases maintenance costs and represents an additional potential point of failure. One commenter also noted that many EHRs are, in fact, particularly highly modularized in the inpatient setting, noting that it is rare for a single module to include all the data necessary for calculation. Others noted that QRDA Category I standard is too narrow in focus to support calculation and analytics because not all of the data elements that would be required for calculation are included in a QRDA Category I report. A few commenters encouraged investigation to determine the feasibility of using the Consolidated CDA or other applicable standard to support the required export.

Several commenters stated they did not believe that “complete EHRs,” which can calculate CQMs, should be required to support data export and that patient-level data export, should be optional.

Other commenters argued in support of this requirement, and one noted that there would be value in a “simple and standardized CQM data export format.” One commenter expressed support for our approach to CQM export and believes that this approach “will support both the development of certification standards for all CQMs and encourage interoperability among systems.”

Response. We appreciate the comments on export of clinical quality data, and after careful review of these comments, we have decided to require this functionality for certification at § 170.314(c)(1)(ii). As stated in our Proposed Rule, for many care delivery settings, CQM calculation and reporting may occur through the use of different EHR technologies from those used to capture data. For example, certified EHR Module #1 may be part of an EH's EHR technology that meets the Base EHR definition, but the EH may use certified EHR Module #2 to perform the analytics needed for CQM calculation and reporting. By requiring that all EHR technology presented for certification capture CQM data and also export the data, we believe EPs, EHs, and CAHs will be provided the flexibility to use separate EHR Modules for calculation and/or reporting, even if they have purchased or licensed an integrated solution.

We believe this approach preserves portability and flexibility and offers the EPs, EHs, and CAHs the option of using regional or national CQM calculation and/or reporting solutions, such as registries or other types of data intermediaries that could obtain modular certification for the services that they offer. We requested comment regarding the appropriate data standard for this export functionality, and at the time of publication of our Proposed Rule, the HL7 QRDA Category I standard had not yet been successfully balloted. Several commenters noted that it was at that time too immature for inclusion in our regulation. QRDA Category I has now been successfully balloted through HL7, has been selected by CMS as an accepted form of quality data reporting, and will therefore be required for certification to § 170.314(c)(1)(ii). We disagree that this criterion or this standard format provide little “value added.” Indeed, this standard provides, for the first time—a method of moving a “snapshot” of patient data from one EHR technology to another without loss of semantic integrity. We anticipate that there may be opportunities for this model to be of value beyond quality measurement in the future—such as in the domain of clinical decision support services.

Import and Calculate

Comments. Many commenters supported certification of incorporation and calculation capabilities to each CQM. One commenter noted that some EHR technology developer products have been certified for CQMs with very light testing requirements and that the certification process for EHRs did not include testing the accuracy of the embedded measure calculations, nor did it examine whether the needed data were, in fact, available in the EHR. Several commenters described frustration with the lack of testing devoted to CQMs under the temporary certification program. One commenter expressed concern about errors encountered in measures that have been transcribed from paper abstraction to e-specification. This commenter noted that the original measure developer specified measures for non-EHR use and in many cases did not e-specify the measures for EHR-use and that subsequent changes in measures occur with e-specification. This commenter called for a process to ensure comparable data calculations across EHR technology developers and hospitals and a systematic process to ensure these changes are broadly communicated and systematically incorporated. Multiple commenters suggested methods for the field testing of new measures. One commenter noted that there was minimal feasibility testing of CQM measure specifications for the Stage 1 CQMs.

Response. We appreciate the comments on CQM calculation and testing. Through the rulemaking comment period and via additional channels, we have become aware of challenges that providers have faced in the use of technology certified under our 2011 Edition EHR certification criterion. Our proposed changes were intended to rectify these concerns. Notably, we have modified our proposal for § 170.314(c)(2) to finalize a more specific and clear certification requirement that EHR technology be able to import a QRDA category I file that has been generated by the “export” capability in § 170.314(c)(1)(ii) specified above. Unlike for the 2011 Edition EHR certification criteria for CQMs, EHR technology will be tested and certified for conformance with this capability. As we noted in the Proposed Rule, we now seek to provide express guidance to ONC-ACBs that when an EHR technology is presented for certification and includes capabilities to meet all three CQM certification criteria (i.e., the certification criteria adopted at § 170.314(c)(1), (2), and (3)) that the capability to “import” as specified in § 170.314(c)(2)(i) will not need to be assessed. Given that the CQM capabilities within the EHR technology are in essence “self-contained,” we believe that it is unnecessary to require EHR technology to be able to import data from itself. EHR technology that is eligible for this treatment would still have to meet all of the other specific capabilities required by all three of the CQM certification criteria. Finally, consistent with other terminology changes we have made, we changed the term “incorporate” to “import” in this certification criterion to provide more clarity regarding the action that is required to be demonstrated for certification. Note that in our discussion of § 170.314(c)(1) (Clinical quality measures—capture and export), we did not require that all data be directly entered through a user interface. Some data may flow into EHR technology through other means. These functions are not required for certification, nor will they be tested as part of the certification process.

We appreciate the comments on e-specification of chart-abstracted measures, but note that many comments about the selection, content, and management of the CQMs are beyond the scope of this final rule. We appreciate the value of reliability and validity testing for CQM technical specifications and support testing of CQMs prior to public release. CMS is responsible for CQM testing and we defer to their comments on this subject in their Final Rule that is published elsewhere in this issue of the Federal Register. We also appreciate the many comments in reference to feasibility testing. Feasibility testing in preparation for Stage 2 of MU has been enhanced in order to minimize variation and post-specification modifications to electronically specified CQMs.

Electronic Submission

Comments. Commenters were supportive of our proposal. One commenter suggested that the XML file format should be a valid standard that has been tested for accuracy and completeness. Another commenter expressed agreement with the use of aggregate XML and recommend that the technical structure align with 2011 Physician Quality Reporting System registry reporting. One commenter suggested that we employ the Core Measure XML and particularly The Joint Commission's “HCD” XML.

Response. We referred to this capability as “reporting” in the Proposed Rule, but now refer to this capability as “electronic submission” in this final rule and in regulation. This renaming more accurately reflects the required capability, which is the ability to create a file in a particular format and be capable of submitting that file to CMS in a manner that CMS is able to accept. We appreciate the supportive comments regarding a standard XML format and aggregate reporting methods. In order to provide CQM file submission flexibility for EPs, EHs and CAHs, CMS intends to offer several reporting methods from which providers will choose, as described in the Stage 2 final rule published elsewhere in this issue of the Federal Register and is considering other mechanisms/methods that could be implemented or relied upon in the future. In this regard, we believe that EHR technology should be capable of creating CQM data files that would support the forms of electronic submission that CMS makes available to EPs, EHs, and CAHs. Therefore, we have adopted both the HL7 QRDA Category I standard to support a patient level data submission approach and HL7 QRDA Category III to support an aggregate level data submission approach.

As noted above, we proposed that the electronic submission capability would require EHR technology to generate an (XML) data file with aggregate CQM calculation results in the format CMS would have the capacity to accept. CMS has since specified that the optimal XML format for aggregate reporting will be the HL7 QRDA Category III. CMS has also made a policy decision to provide an option for patient-level reporting. CMS has specified that the optimal XML format for patient-level reporting will be the HL7 QRDA Category I. Although these standards were in development at the time of our Proposed Rule, QRDA Category I has now been balloted through HL7, and QRDA Category III is much more complete than it was at the time of the Proposed Rule, with balloting scheduled in the near future. We understand that the timing of the QRDA Category III balloting is suboptimal, but note that the alternative would have been for CMS to develop its own XML specification for a format that performs precisely the same functionality as QRDA Category III. This would have been redundant of the QRDA Category III effort and could have adversely affected its progress. We also note that the patient-level reporting standard (QRDA Category I) is the same standard as the standard we have adopted for the “export” capability in § 170.314(c)(1). Therefore, we anticipate that the burden on EHR technology developers that also submit EHR technology for certification to this certification criterion will be minimal.

In general, we expect that providers who choose to submit aggregate reports will use the standard specified at § 170.205(k) (HL7 QRDA Category III), and providers who choose to submit patient-level reports will use the standard specified at § 170.205(h) (HL7 QRDA Category I). We require that EHR technology, regardless of the setting (inpatient or ambulatory) for which it was designed, be certified to produce CQM data that could be submitted by an EP, EH, or CAH according to either standard. While the HL7 QRDA Category III standard has not yet been successfully balloted, we expect it to become a normative standard in the near future. Further, we agree with and support CMS's decision to select this format rather than developing its own CMS-defined XML template because QRDA Category III is a product of several years of industry consensus work. EHR technology presented for certification will therefore need to be certified as being capable of creating results for transmission to CMS according to both reporting standards (§ 170.205(h) (HL7 QRDA Category I)) and § 170.205(k) (HL7 QRDA Category III)).

We note for readers that we have modified this certification criterion to more explicitly address the fact that CMS must be able to receive an electronic data file created by EHR technology and submitted by an EP, EH, or CAH. If this could not occur then, arguably, the most important aspect of what certification was intended to support would go unmet. Accordingly, we have added to this certification criterion, not only that EHR technology be able generate both QRDA Category I and QRDA Category III data files, but that such files can also be electronically accepted by CMS. This explicit requirement creates two benefits while also reducing regulatory burden due to CMS' intended programmatic alignment efforts. It benefits providers and CMS in that each will know as a result of certification that when EHR technology is used to electronically submit a QRDA Category I or III that CMS will be able to receive it. With respect to testing, we expect to approve a test procedure for this certification criterion that will assess an EHR technology's ability to create data files conformant to the QRDA Category I and III standards, and upon a positive conformance assessment, verify that these data files could be accepted by CMS. If the data files were conformant and verified by the accredited testing laboratory in terms of their ability to be accepted by CMS, then the EHR technology would have fully demonstrated compliance with this certification criterion.

• Auditable Events and Tamper-Resistance; and Audit Report(s)

We proposed two revised certification criteria at § 170.314(d)(2) and (3)—one focused on the capability to record auditable events and another focused on the capability to create audit reports—in place of the single 2011 Edition EHR certification criterion for audit logs adopted at § 170.302(r). We also proposed to move the specific capability “detection” from the integrity certification criterion (§ 170.302(s)(3)) to the proposed auditable events and tamper-resistance certification criterion. We made these proposals based on HITSC recommendations as well as stakeholder feedback that indicated splitting the 2011 Edition certification criterion into two separate certification criteria would permit a wider variety of EHR technologies to be certified as EHR Modules. We also expanded upon the scope of the HITSC's recommendation to address input from the HHS Office of Inspector General (May 2011 report ) and to reflect our general belief that a more stringent certification policy for audit logs will ultimately assist EPs, EHs, and CAHs to better detect and investigate breaches. The proposed expansion included the specific capabilities that the audit log must be enabled by default (i.e., turned on), immutable (i.e., unable to be changed, overwritten, or deleted), and able to record not only which action(s) occurred, but more specifically the electronic health information to which the action applies. The proposed certification criterion would also require that the ability to enable and disable the recording of actions be limited to an identified set of users (e.g., system administrator). Further, to accommodate these changes, we proposed a revised standard at § 170.210(e) and proposed to require that: (1) When the audit log is enabled or disabled, the date and time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)), user identification, and the action(s) that occurred must be recorded; and (2) as applicable, when encryption for end-user devices managed by EHR technology is enabled or disabled, the date and time (in accordance with the standard specified at § 170.210(g) (synchronized clocks)), user identification, and the actions that occurred must be recorded. Finally, we acknowledged, as recommended by the HITSC, that an example standard that could be followed in designing EHR technology to meet these certification criteria could include, but is not limited to ASTM E2147-01, Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems.

General Comment Summary. Many commenters generally supported the more detailed certification criteria and the standards we proposed. Comments on the two certification criteria and standards we proposed focused on a number of different dimensions. The following comment summaries and responses address each of these dimensions.

Comments. Many commenters requested clarifications related to the proposed certification criterion's first specific capability—that the auditable events capability be “enabled by default.” Many commenters noted that our proposal essentially skipped a step from an implementation perspective. They contended that the certification criterion should include, make reference to, or that we should make clear that the certification criterion did not prohibit the audit recording capability or service from being be subject to some type of initial configuration. Further they stated that once initial configuration was complete the audit log could be “enabled by default.” Another commenter stated that audit logs should not be enabled by default by EHR technology developers because the decision of whether settings in the software are enabled or disabled are the responsibility of each organization, not the EHR technology developer. Additionally, this commenter and others indicated that EHR technology developers cannot enable the audit logs of organizations that already have this capability in use.

Response. We understand the concerns raised by commenters and seek to clarify this proposal as follows. It appears that by including the parenthetical “(i.e., turned on)” that we confused many commenters because, as they noted, steps needed to occur before the auditing service could actually be “turned on.” We acknowledge that 2014 Edition EHR technology will need to be setup and configured at each practice or hospital in which EHR technology with this capability is installed. This certification criterion is not meant to prohibit such configuration. Rather, what this certification criterion expresses (and what we have made clear in modifications to the certification criterion) is that in order for the EHR technology to be certified it must be set by default to record the actions and information specified in the standards referenced by the certification criterion. Thus, this part of the certification criterion is meant to ensure that at the point of installation or upgrade EHR technology certified to this 2014 Edition EHR certification criterion, the EHR technology will be set by default for an EP, EH, or CAH to record the actions and information specified in the standards referenced by the certification criterion.

Comments. Commenters also expressed a set of concerns with respect to another element included in the proposed certification criterion's first specific capability—that only a limited set of identified users be permitted to be disable (and re-enable) the capability to record auditable events. Some commenters, typically EHR technology developers, referenced that some EHR technologies do not include any capability at all for users to change (enable/disable) auditable event recording. As such, these commenters stated that the final rule should accommodate this approach with respect to certification. Further, commenters agreed that if auditable events can be disabled, that it only be able to be done so by a limited set of users. Echoing that this provided separation of duties, so that a user who is able to access or make changes to a patient's health information is not also able to modify the audit log to remove traces of suspicious activity. One commenter stated that since EHR technology cannot interpret the meaning of “limited,” that we should change the wording to “ * * * by authorized users.” Another commenter noted that it may be necessary to turn off the auditable events capability for performance, patching, or other events.

Response. In response to comments, we have modified the certification criterion to make the accommodations requested. As noted by at least one commenter, the practice indicated by others to never permit anyone to be able to disable an audit log is not uniformly applied in EHR technology. Therefore, we have reframed and reordered the specific capabilities within the certification criterion. As a general rule, the certification criterion identifies the actions and statuses that EHR technology must be able to record. The actions related to electronic health information are listed first; the change in audit log status second; and the change in encryption status of electronic health information locally stored by EHR technology on end-user devices third. With respect to the latter two (the two status oriented requirements), we have included conditional statements as requested by commenters to permit EHR technology to meet this certification criterion if the EHR technology developer can demonstrate that no user has the ability to change those statuses. Further, we have reworded and moved to the third specific capability within this certification criterion the separation of duties aspect that many commenters endorsed. This modified requirement specifies that if EHR technology permits the recording of auditable actions or statuses to be disabled the ability to do so must be restricted to a limited set of identified users. We decline to modify this certification criterion in response to the commenter's suggestion to change the wording related to “limited” set of identified users because the commenter has misinterpreted the requirement that the certification criterion specifies. EHR technology does not have to interpret the meaning of “limited.” Rather, to meet this certification criterion, EHR technology would need to include a capability that allows only a limited set of identified users (by the EP, EH, or CAH) to be have the privileges necessary to change when auditing is enabled or disabled. In general, we do not expect and would discourage any general EHR technology user from being permitted to perform such actions.

Comments. Some commenters requested clarification on the meaning of “as applicable” in the “auditable events” certification criterion and accompanying standard with respect to auditing the encryption status of end-user devices managed by EHR technology. Consistent with other comments provided in terms of the capabilities within the scope of an EHR technology's control, commenters noted that “as applicable” in this context should be if an EHR technology developer supplied the end-user device and if the sole purpose of the device is to use the EHR technology. In other words, tracking the enabling and disabling of encryption on health care providers' personal devices (such as smart phones) should not apply.

Response. The phrase “as applicable” was originally intended (in this proposed certification criterion and standard) to accommodate situations where the EHR technology did not locally store electronic health information on any end-user devices. In general, we agree with commenters that tracking the enabling and disabling of encryption on health care providers personal devices would not apply, because the primary certification criterion implicated by this requirement (170.314(d)(7)) is not applicable to all end-user devices. However, we note for commenters that this situation is fact dependent and could apply to the health care provider's personal device if EHR technology is run on the device and locally stores electronic health information on the device after use has stopped. Consistent with the changes discussed in our responses above, we believe the certification criterion has been clarified. Further we have removed the phrase “as applicable” in the standard listed at 170.210(e) in favor of more plain language usage in the certification criterion itself.

Comments. Several comments applied to the standards we proposed to adopt and associate with the proposed “auditable events” certification criterion. Consistent with other comments summarized above, commenters asked that we accommodate situations where EHR technology does not allow for an audit log to be disabled or when it does not permit the encryption of electronic health information managed by EHR technology on end-user devices to be disabled. Other commenters suggested that we rely on SDO standards compared to the enumerated requirements we specified in the proposed standard at 170.210(e). They reasoned that an SDO standard has undergone much more extensive review and socialization than the list of requirements embedded in the proposal and that an SDO standard is much more broadly adopted than a “standard” embedded in a regulation, and therefore more likely to take on uniform interpretation. Along those lines, they suggested that the ASTM E2147 standard we referenced in the proposed rule would be preferred over enumerating a list of requirements embedded in regulation. One commenter further suggested that a variety of HL7 and ASTM standards be referenced by this certification criterion to denote information objectives, actions, structural roles, participation function codes with security permissions, and data types to encode user identification. Another commenter asked that we clarify if the part of the ASTM E2147-01 standard that deals with disclosures has applicability to this certification criterion. One commenter suggested that we clarify that audit logging requires at a minimum date, time, and user id to determine who accessed certain electronic health information. With limited exceptions, commenters generally supported the adoption and application of the clock synchronization standards we had proposed.

Response. As discussed in the responses directly above related to changes already made to the certification criterion, we do not believe that it would be necessary or appropriate to include the conditional language suggested by commenters in the standards (and have since removed it from what we proposed). We agree with commenters that we should leverage SDO produced standards wherever possible and not embed an enumerated list in regulation. Accordingly, and as suggested by commenters, we analyzed ASTM E2147-01(2009) and believe that it includes an equivalent set of requirements as we proposed. Thus, the standards we express now refer to the appropriate sections of ASTM E2147-01(2009), rather than an enumerated list. For the first specific capability related to actions involving electronic health information, we have required that the data elements specified in sections 7.2 through 7.4, 7.6, and 7.7 of ASTM E2147-01(2009) be captured. For the other two specific capabilities related to the status of the audit log or the encryption status of electronic health information managed by EHR technology on end-user devices, we have required that the data elements specified in sections 7.2 and 7.4 of ASTM E2147-01(2009) be recorded. All three of these standards require that the user ID, date and time be recorded. We note that not all of the section 7.X parts of the ASTM E2147-01(2009) standard have been specified as they go beyond what we proposed to include. Thus, we seek to make clear that only those sections in section 7 that we have explicitly included in our standards are the minimum required for certification.

We decline to modify the certification criterion in response to the commenter's suggestion that we include a variety of standards to denote information objectives, actions, structural roles, participation function codes with security permissions, and data types to encode user identification. We did not propose such specificity, nor did the HITSC recommend that we include such specificity in the certification criterion. As we have noted in other responses, certification is a minimum. Thus, where additional standards exist and can be used to further improve capabilities for which certification is required, we encourage EHR technology developers to consider doing so. As requested by a commenter, we confirm that the “disclosure log” section (section 8) of ASTM E2147-01(2009) has no applicability to this particular requirement.

Last, we are finalizing the changes we discuss in this response as well as our proposal to adopt the clock synchronization standards we proposed.

Comments. Numerous commenters requested different clarifications related to the expected granularity of actions and information to be recorded. A commenter suggested that the granularity of electronic health information be limited to the metadata involved in identifying the patient whose record has been accessed, be sufficient for recording actions, and that it not require lower level clinical data objects to be logged if appropriate context of what kinds of information is logged is otherwise recorded. Another recommended that the certification criterion be more explicit in describing the level of how the “action taken” should be captured in terms of what was done, the data, and how it was changed. Yet another suggested that the information logged should be sufficient to enable a system administrator to identify, for example, that a specific patient's order that was modified, deleted, etc., or that a user accessed a patient's medication list. Other commenters raised concerns about the about the granularity of the information recorded in the audit log and its potential to include electronic health information. They contended that requiring this level of specificity would inappropriately duplicate clinical information in the audit log and could cause greater security issues. Instead, they suggested that the type of data acted upon should be the proper scope of this certification criterion and that implementing this approach would be more feasible and less costly. Further, these commenters expressed concern that the certification criterion could be interpreted to require very granular auditing which would adversely impact system performance and place undue burden on security auditors who may not be able to find the information they need. They argued that requiring this type of very granular auditing may introduce a burden on EHR adopters because of the amount of disk space required to store these audit logs. Other commenters stated that the scope of the data recorded should not be at the same level as a “history table” or “action/event history table.” Commenters indicated that the clinical level of detail included in those tables is appropriate to maintain the wholeness of clinical documents and data, but not for security audit trails. Instead, commenters suggested that HHS consider adopting a “medical record history and completeness” objective that is not related to security auditing.

Response. We appreciate the detail and thoughtfulness of the comments submitted on this certification criterion. In consideration of comments received, we agree that further explanation is necessary related to the scope and granularity of the information expected to be recorded. Given that we are now referencing relevant sections of ASTM E2147-01(2009), we believe that this standard reinforces what we would have said had we maintained our enumerated requirements. Section 7.7 of ASTM E2147-01(2009) discusses the “identification of patient data that is accessed.” It states that the “granularity should be specific enough to clearly determine if data designated by federal or state law as requiring special confidentiality protection has been accessed.” And, more to the point, Section 7.7 goes on to state that “[s]pecific category of data content, such as demographics, pharmacy data, test results, and transcribed notes type, should be identified.” We agree with commenters and understand the burden and security and privacy concerns issued as well as the disk space limitations referenced. Thus, we believe that it is appropriate for actions made to electronic health information and recorded in the audit log to be identified at a categorical (or type) level—this is also consistent with the guidance included in ASTM E2147-01(2009). For instance, as noted by a commenter, we believe that the ability of the audit log to record that a user accessed a patient's medication list would be sufficient for certification and that the audit log would not have to also record the specific medication.

Comment. One commenter asked whether we intended for the certification criterion to require that relevant information be captured in a manner that supports the forensic reconstruction of the sequence of changes to a patient's chart or if we intended for the certification criterion to require that users be provided with on-demand snapshot views of the patient chart at any point in time with a highlighted comparison of data which is changed at any given moment. This commenter preferred the former because it stated that in order to implement the latter EHR technology developers would need to expend substantially more effort into the development of user interface capabilities, which would be used only in rare circumstances.

Response. We intend for the former, as stated by the commenter, that the actions and information can be captured in a manner that supports the forensic reconstruction of the sequence of changes to a patient's chart.

Comments. Commenters almost unanimously focused on the scope of the proposed certification criterion's third specific capability—that actions record must not be capable of being changed, overwritten, or deleted. Commenters' feedback included a range of different opinions. One commenter noted that this certification criterion should focus on access and alterations, while being cautious about pursuing attainment of immutable audit logs and detection of audit logs because the EHR technology can still be circumvented by select individuals with malicious intent. Another indicated that there were other techniques such as using separate hardened audit log technologies and suggested that this capability be met by proving separation of duty for security auditors and clinical EHR end users, detection of changes in audit system configuration to the extent it is allowed by the audit system for recording, and audit log abilities that may be present in the audit log solution itself for detecting accesses to the log. The majority of commenters noted that from a technological perspective there is only so much that is within the control of the EHR technology. These commenters sought clarifications in terms of the extent to which EHR technology is responsible for preventing changes, overwrites or deletions to the audit log. Several provided similar examples referencing the fact that users could access a file or database used by the EHR technology through the operating system on top of which the EHR technology may run or by directly accessing the database in which the audit information is stored. In general, all of these commenters requested that we should limit the scope of this specific capability to make clear that the audit log should not be able to be changed, overwritten or deleted through the EHR technology by its users.

Response. We appreciate the detailed responses and examples offered by commenters. As noted by many commenters, we acknowledge that there is only so much that is within the control of EHR technology and that nothing is ever 100% impenetrable. Thus, we have revised this specific capability within the certification criterion to state that the audit log must not be capable of being changed, overwritten, or deleted by the EHR technology. We believe this addition properly scopes the capability for which certification is required and will address commenters' concerns. As discussed in other responses, where the EHR technology permits the auditable actions and statuses to be disabled, we have required that some form of separation of duty be implemented in that only a limited set of identified users should be able to modify audit settings.

Comments. Several commenters expressed concern that the proposed certification criterion's third specific capability we proposed—that actions recorded must not be capable of being changed, overwritten, or deleted—did not permit the deletion of the audit log. Further commenters stated that this specific capability disallows the purging of audit logs after the required legal retention period has expired. They recommend adding “except when disposing of log information after a legally defined retention period.” Another commenter expressed a similar concern with the implications of an “immutable” audit log. They stated that data may not be kept on the same physical device as it ages and that data is “added” to another device and “deleted,” and thus cannot be “immutable.” They also stated that immediate storage of an audit log on “write once read many” (WORM) technology is not practical in all configurations.

Response. We are uncertain as to what in the Proposed Rule led commenters to make this interpretation since this certification criterion focuses on a capability that EHR technology would need to include. It was not our intention, nor did the certification criterion specify, that audit logs could not be deleted or purged after a legal retention period. Such a step would be an organizational policy decision and not within the scope of certification. Thus, we decline to make the more detailed suggested modifications. However, to make it clear that such steps are not prevented by the certification criterion, we have added to the specific capability related to the audit log's immutability that the audit log must not be capable of being changed, overwritten, or deleted by the EHR technology. We believe this addition properly scopes the capability for which certification is required and will address commenters' concerns.

Comments. A few commenters indicated that they believed an inconsistency existed between the proposed certification criterion's third and fourth specific capabilities. Commenters noted that if the certification criterion requires that an audit log not be capable of being changed, overwritten, or deleted that it was unclear why we would also require EHR technology to detect an alteration to the audit log. The commenters questioned whether the third specific capability rendered the fourth capability moot and if the fourth was still necessary. Last, a commenter requested clarification regarding what would constitute an alteration of an audit log.

Response. Given the reordering of the specific capabilities within this certification criterion and the clarification that we made above regarding the scope of the now finalized fourth specific capability “(iv)” (that requires that an audit log not be capable of being changed, overwritten, or deleted by the EHR technology), we believe that it is also necessary to clarify the scope of the specific capability we proposed regarding EHR technology's ability to detect an alteration to the audit log. This specific capability, which is now designated as the fifth specific capability “(v),” has been revised to state that “EHR technology must be able to detect whether the audit log has been altered.” We believe that this specific capability complements the other capability specified at (d)(2)(iv) from a defense-in-depth perspective. Further, we clarify that this specific capability requires EHR technology to be able to determine whether activity outside of its control has in some way altered the audit log (e.g., that the operating system was exploited to modify the EHR technology's database). In this respect, the EHR technology will be able to detect whether its audit log has been corrupted. While this may not be the only approach EHR technology developers can use, we encourage the use of hashing algorithms specified in FIPS 180-4 (Secure Hash Standard) to determine whether the audit log has been altered.

Comments. Commenters strongly supported the two certification criteria we proposed from the single 2011 Edition EHR certification criterion. Further, a commenter encouraged that testing and certification for these two certification criteria should be done independently to allow for separate security audit log technologies to be presented for certification as EHR Modules. This commenter urged that there should not be a dependence for an EHR technology developer of a free standing audit log reporting technology to certify with each and every source EHR that may send it audit events and data as if a business partnership were required to do so. In essence the commenter sought clarification that it was possible for the certification criterion proposed at 170.314(d)(3) to be certified independently and on a standalone basis.

Response. Yes, it is possible for EHR technology to be independently certified to 170.314(d)(3). We proposed two separate certification criterion for exactly this reason. Previously the 2011 Edition EHR certification criterion required that EHR technology demonstrate both the recording of auditable events and the report generation in order to be certified. With this separation EHR technology can be separately certified to perform these two capabilities. A stand-alone EHR Module for audit log reporting would not need to certify with each and every source EHR technology that may send it auditable events. In order to meet the certification criterion the EHR technology would need to demonstrate that it could capture the required data.

Comments. We received only a few comments on the proposed audit reports certification criterion at 170.314(d)(3). They expressed support for the proposed certification criterion and one commenter requested clarification of the expectation for reports generation.

Response. We appreciate commenters' support. We are finalizing the certification criterion as proposed. This certification criterion expresses the capability that EHR technology must enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the elements specified in the standards at § 170.210(e). Anything beyond that requirement is beyond the scope of certification and likely depends upon organizational policy.

• End-User Device Encryption

In the Proposed Rule, we proposed to revise the “general encryption” certification criterion adopted at § 170.302(u) as part of the 2011 Edition EHR certification criteria in favor of a certification criterion focused on the capability of EHR technology to encrypt and decrypt electronic health information managed by EHR technology on end-user devices if such electronic health information would remain stored on the devices after use of EHR technology on that device has stopped. We proposed this revised approach because we thought it would be more practical, effective, and easier to implement than the otherwise general encryption requirement adopted at § 170.302(u). Further, we agreed with the HITSC that we should focus more attention on promoting EHR technology to be designed to secure electronic health information on end-user devices (which are often a contributing factor to a breach of protected health information ). The OIG provided similar rationale in its May 2011 report (previously cited under the discussion of the “auditable events and tamper-resistance” and “audit report(s)” certification criteria) in which it recommended that ONC address IT security controls for encrypting data on mobile devices. The proposed certification criterion was drafted to permit EHR technology developers to demonstrate in one of two ways that a Complete EHR or EHR Module is compliant.

The first proposed way, § 170.314(d)(7)(i), accounted for circumstances in which EHR technology was designed to manage electronic health information on end-user devices and on which electronic health information would remain stored on the end-user devices after use of the EHR technology on the devices has stopped. We clarified that we intended for the term “stopped” to mean that the session had been terminated, including the termination of the network connection. We stated that in these circumstances, EHR technology presented for certification must be able to encrypt the electronic health information that remains on end-user devices. And, to comply with paragraph (d)(7)(i), that this capability must be enabled (i.e., turned on) by default and only be permitted to be disabled (and re-enabled) by a limited set of identified users. We did not include “decrypt” in the proposed certification criterion because we determined it was best to focus certification on the most critical capability, the act of encryption after use of the EHR technology on the end-user device has stopped. Last, we explained that the phrase “manages electronic health information” in the certification criterion meant that the EHR technology was designed in a way that it could exert control over the electronic health information that remains on an end-user device after the use of EHR technology on that device has stopped. We stated, for example, that if an EHR technology was designed to manage a client application that can be executed on a laptop or tablet, and electronic health information would remain stored—even in temporary storage—on that end-user device when a user stops using the client application on the laptop or tablet, the EHR technology would need to meet the requirements specified at § 170.314(d)(7)(i) in order to be certified.

The second proposed way to demonstrate compliance with this certification criterion was for an EHR technology developer to demonstrate that its EHR technology could meet § 170.314(d)(7)(ii) and prove that electronic health information managed by EHR technology never remains on end-user devices after use of EHR technology on those devices has stopped. We explained that this alternative method was important to include because it: (1) Verifies as part of certification that the EHR technology was, in fact, designed in a way such that it does not enable electronic health information to remain on end-user devices after use of EHR technology on those devices has stopped; (2) provides EHR technology developers a way to demonstrate compliance with this certification criterion; and (3) it encourages an outcome that is more secure (i.e., when no electronic health information is permitted to remain, the potential for a breach is mitigated).

Comments. Many commenters offered their support for this certification criterion. One applauded the decision to allow the option to either encrypt end-user devices or make sure no data remains on end user devices managed by the EHR technology. Several noted that since a majority of breaches by HIPAA covered entities or their business associates have been due to lost or stolen unencrypted portable media, requiring default encryption functionality for end-user devices managed by CEHRT should help reduce health data breaches. Another commenter indicated that this security measure has largely been ignored and agreed that making encryption a requirement for EHR certification should help spur industry to protect data security.

Response. We thank commenters for the positive feedback. As we have stated elsewhere in this final rule, we believe that certification can help to ensure that in adopting CEHRT EPs, EHs, and CAHs have technical capabilities that they can use to enhance their security practices and make compliance with other regulatory requirements more efficient.

Comments. A few commenters requested clarification of the term “stopped.” One suggested that we include “in the prescribed manner.” A second referenced “prescribed manner” and stated that they thought it would be difficult to test that an EHR technology never leaves electronic health information on an end-user device when it is terminated in the prescribed or non-prescribed manner. They encouraged that attestation be permitted for the test procedure. Another suggested that we consider whether “stopped” includes abnormal termination of a session and a network connection versus normal termination. They explained that routines that manage temporary storage may only be part of normal session termination whereas there may be processes to preserve images or caches for session resumption in the case of an abnormal termination that could pose risk by persisting health information in order to prevent data loss when an abnormal interruption such as battery failure or power outage to the device occurs.

Response. We decline to modify this certification criterion to add “in a prescribed manner.” We do not believe that this qualifying phrase is necessary or adds significant clarity to the proposed certification criterion. We continue to believe that our general description of “stopped” in the proposed rule (“that the session has been terminated, including the termination of the network connection”) is sufficient for this certification criterion. In other words, use of EHR technology is considered to be stopped when a user closes or exits the EHR technology application and would need to re-execute the EHR technology application to again engage in use. However, we acknowledge, as commenters pointed out, that there could be predictable/prescribed stops and unpredictable/abnormal stops (i.e., power or battery failure). For the purposes of certification to this 2014 Edition EHR certification criterion, we clarify that testing and certification will focus on normal terminations. We will consider whether more advanced and rigorous testing and certification requirements for future editions of certification criteria would be necessary. In the following responses when we refer to “stop” or “stopped,” we are referring to normal stops.

Comments. Numerous commenters requested clarification regarding the phrase “managed by” in the certification criterion. Along those lines many asked that we clarify the certification criterion's scope and applicability. Some stated that we should clarify that it only applies to storage capabilities that are designed for use with EHR technology developer provided or supported technologies for desktop, laptop, mobile, cellular based technologies or similar technologies, and not to capabilities that may be present in technology components such as operating systems, swap files, and memory management technologies that are embedded and non-configurable as to their use by the EHR system (since the EHR technology developer is unable to change those capabilities). These commenters suggested that this certification criterion be applied to the deliberate use of storage capabilities that are configurable or to the management of caching files that the EHR technology developer, by design, elects to use and manage on such devices. One commenter asked whether the EHR technology is expected to enforce encryption or if it must be capable of notifying the receiving device that the data being downloaded contains electronic health information and therefore such data must be encrypted.

A few sets of comments on the “managed by” concept included detailed information on two points. The first asked whether we had intended for the certification criterion to apply only in cases where the EHR technology has control over the ability of the user to store data on their device, installs a client application, etc. This commenter suggested that the language in the certification criterion may be unclear when it is read in isolation, outside of the preamble. Further, this commenter noted (as was echoed in a different comment) that the meaning of the term “managed by” was missed by many of its contributors and that many assumed that the certification criterion required the EHR technology to enforce encryption on any mobile or portable device. The second point addressed a technical concern and limitation. Commenters stated that the operating system or other technology on the end-user device may cache electronic health information and retain it after use of the EHR technology on an end user device has stopped. They indicated that, for example, swap and cache files, sleep and hibernate features, and application context switching in Windows 8 Metro apps or iOS may all cause electronic health information to be cached to disk. Similarly, they stated that some browsers do not respect “no-cache” headers, potentially leading to electronic health information being cached on the end-user device if users access the EHR with a non-vendor supported browser. Additionally, commenters indicated that these instances were beyond the control of the CEHRT and are subject to user configuration and control to achieve the desired objective. These commenters requested a reasonable clarification of the term “manage” and stated that it would be unreasonable to expect EHR technology to control how operating systems and other technologies perform memory management and that they did not consider this information to be managed by the EHR technology.

Last, a commenter asked who was responsible for encryption on end-user devices (e.g., EHR developer, covered entity/business associate, etc.). They stated that in practice this requirement will affect all desktops—even home computers—that cache content from web-based EHR systems. Further, they questioned how this requirement interacted with the proposal that the encryption capability must only be disabled by a limited set of identified users.

Response. We appreciate the detailed and thoughtful feedback provided by commenters. Because all of the comments revolved around the phrase “managed by,” we believe it will be most effective to respond to the general clarifications up front and then explain the revisions we have made to this proposed certification criterion. We believe this approach will be clearer and more efficient with respect to how we interpret this certification criterion than if we were to individually address each specific comment within this comment summary.

As noted in the Proposed Rule, we proposed this certification criterion to focus and encourage EHR technology developers to design secure implementations and equip EHR technology with the ability to assist users in keeping end-user devices secure. End-user devices can pose a specific vulnerability, especially as they become more prevalent and computationally powerful.

Given the uniform confusion surrounding the phrase “managed by,” we have revised this certification criterion to functionally describe the event that we had intended to capture with the phrase—the local storage and persistence of electronic health information on end-user devices. The general policy we express in this certification criterion requires EHR technology designed to locally store electronic health information on end-user devices to encrypt such information after use of EHR technology on those devices stops. We clarify that in this context, locally stored electronic health information is intended to mean the storage actions that EHR technology is programmed to take (i.e., creation of temp files, cookies, or other types of cache approaches) and not an individual or isolated user action to save or export a file to their personal electronic storage media. Similar to the changes we made to the auditable events certification criterion, we have clarified that in this scenario, the EHR technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users. While it may not “enforce” encryption per se, this certification criterion does require that EHR technology designed in this way be set by default to encrypt when electronic health information is locally stored on end-user devices.

We agree with commenters and clarify that this certification criterion focuses on, and only applies with respect to, the storage capabilities that are designed for use with EHR technology developer provided or supported technologies for desktop, laptop, or mobile technologies (and similar variations of such technologies) (i.e., it is generally not intended to apply to personally owned end-user devices, unless an EHR technology developer supported technology is loaded/installed on such a device). The certification criterion does not apply with respect to capabilities that may be present in the underlying technology on which EHR technology may run, but is unable to control through the EHR software, such as operating systems, swap files, and memory management technologies that are embedded and non-configurable by the EHR technology. Thus, these revisions are consistent with the sentiments issued by commenters that suggested this certification criterion be applied to the deliberate use of storage capabilities that are configurable or to the management of caching files that the EHR technology developer, by design, elects to use and manage on such end-user devices. We recognize that a spectrum of different implementations exist and that they may range from a “thin client,” to a viewer that shows the screen of remote virtual server, to a web browser that accesses a remote web service, to more traditional client/server “thick client” implementations, and to where EHR technology in its entirety could run entirely on single a device. On one end of the spectrum no electronic health information would persist when a user stops using EHR technology. Toward the other end of the spectrum electronic health information would always persist when a user stops using EHR technology. Ultimately, as expressed in the paragraph (d)(7)(i) of this certification criterion, if the EHR technology developer designs EHR technology that requires or utilizes locally stored electronic health information, it is the EHR technology developer's responsibility to ensure that such information is set to be encrypted by default in order to meet this certification criterion. We expect that this capability could be accomplished through a number of different technical mechanisms, including techniques to “sandbox” and limit the extent to which data can be accessed and used to only be within a secure session.

With respect to paragraph (d)(7)(ii) of this certification criterion, we have revised the language to acknowledge that despite an EHR technology developer's best effort to design EHR technology in such a way (as suggested by our proposal) that electronic health information never remains, we understand from commenters that such absolutes cannot always be guaranteed (especially when an EHR technology developer is unable to modify the functionality a particular web browser or operating system employs). With this in mind, we have revised this portion of the certification criterion to state that an EHR technology developer would not have to demonstrate that its EHR technology can encrypt electronic health information locally stored on end-users devices if the EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops. We interpret “prevent” to include, for example, situations where EHR technology is designed to and would normally disallow electronic health information to be locally stored on end-user devices after use of EHR technology on those devices stops, but is run in a browser that does not respect “no-cache” headers. In this circumstance, and if shown under normal circumstances (i.e., running in a browser that does respect “no-cache” headers), the EHR technology could meet paragraph (d)(7)(ii) of this certification criterion.

Comment. A commenter stated that they considered information that has been sent to a print queue or downloaded by the user (such as downloading a PDF report) to no longer be managed by the EHR technology.

Response. We generally agree with this statement.

Comment. A commenter asked that we clarify whether data at rest on a server located at a secure data center must be encrypted and, if yes, to please reconsider this requirement because they believed it would slow down response times in large cloud-based EHR systems.

Response. As indicated above, this certification criterion does not focus on server-side or data center hosted EHR technology. We recognized that these implementations could employ a variety of different administrative, physical, and technical safeguards, including hardware enabled security protections that would be significantly more secure than software oriented capabilities.

Comment. One commenter recommended that disk level encryption, which is implemented outside of CEHRT, be deemed an acceptable means through which to fulfill this criterion. They contended that EHR technology developers should not be forced to create their own proprietary encryption implementations, when this capability is already available through other means.

Response. We cannot deem this approach acceptable to fulfill this certification criterion because it would not be a capability that could be demonstrated by EHR technology. However, in situations where a user has implemented disk encryption hardware and would be using EHR technology that is designed to save electronic health information to local storage on end-user devices, the user may, through a risk analysis, determine that disabling the EHR technology's encryption capability is prudent since its data will be protected through the disk encryption hardware.

Comment. A commenter recommended that we discourage the use of or remove the allowance for 3DES because the algorithm is on track to be deprecated by NIST in the near future.

Response. We agree with this commenter and encourage EHR technology developers to use the other encryption algorithms, such as AES, that are included in FIPS 140-2 Annex A.

Comment. A commenter expressed concern that this certification criterion would cause financial hardship related to the additional involvement of copy machines, EKG machines, etc., and stated that health care practices need to be aware of the cost.

Response. Given our responses above, we do not believe that this concern is valid.

Comment. In the context of this certification criterion, a commenter encouraged ONC to evaluate the necessary steps to incorporate the ability to access a patient's health information during urgent or emergency situations.

Response. We have considered this comment and do not believe that any change to the certification criterion is warranted given the clarifications we have made above.

Comments. A commenter indicated that the proposed certification criterion could be interpreted to exceed the requirements set forth in the HIPAA Security Rule, which provides that encryption is addressable requirement (evaluated as part of a risk assessment), rather than a required control. They stated that one might infer that the implementing organization must use this capability if their EHR technology was required to be certified to it. The commenter suggested that we clarify any distinction between the HIPAA Security Rule and the proposed certification criterion. Last, they suggested that if the encryption of data on connecting devices is truly considered a best practice, that it seems that it is best first addressed by OCR as a new required control in the HIPAA Security Rule, which could then be incorporated into the MU requirements (compared to using the MU requirements to indicate best practice for a limited set of HIPAA regulated entities).

Response. This certification criterion applies to EHR technology and does not supersede or affect the HIPAA Security Rule's requirements or associated flexibilities. As we have stated in this preamble and prior rules, we believe that by requiring these capabilities to be part of an EP, EH, or CAH's CEHRT that it will assist and enable them to more efficiently comply with security requirements such as the HIPAA Security Rule. We note that HHS has issued guidance around encryption as a possible risk management strategy to address storage of electronic protected health information. In addition, HHS has issued guidance on how to render unsecured protected health information unusable, unreadable, or indecipherable to unauthorized individuals.

• Immunization Information; and Transmission to Immunization Registries

We proposed two certification criteria for immunization registries that were essentially a split of the 2011 Edition EHR certification criterion for submission to immunization registries (§ 170.302(k)). We proposed one certification criterion that focused just on the capabilities to electronically record, change, and access immunization information (data capture) and another that focused on the capability to electronically create immunization information for electronic transmission in accordance with specified standards. We discussed these two proposed certification criteria together in the Proposed Rule for simplicity and to prevent confusion, but noted that we did not consider the certification criterion we proposed to focus on data capture to be a revised certification criterion. Rather, we stated that we believed that the certification criterion would constitute an unchanged certification criterion because all the capabilities included in the criterion were the same as the capabilities included in the corresponding 2011 Edition EHR certification criterion (§ 170.302(k)). Additionally, for this certification criterion, we proposed to replace the terms “retrieve” and “modify” in the revised criterion with “access” and “change,” respectively.

For the certification criterion focused on electronically creating immunization information for electronic transmission, we clarified that this criterion focuses on the capability of EHR technology to properly create immunization information for electronic transmission in accordance with the applicable standards and implementation specifications. We further emphasized that the criterion does not address the ability to query and evaluate immunization history from the immunizations information systems (IIS) to determine a patient's vaccination need, nor does it address the specific connectivity requirements that an EP, EH, or CAH would need to establish or meet to successfully transmit immunization information, as such requirements are likely to vary from state to state and are outside the scope of certification. We proposed the use of only the HL7 2.5.1 standard for formatting immunization information because immunization registries are rapidly moving to this standard. We also proposed to adopt the HL7 2.5.1 Implementation Guide for Immunization Messaging Release 1.3 as the implementation specification which provides corrections and clarifications to Release 1.0 and contains new guidance on how to message vaccines for children (VFC) eligibility. Finally, we proposed to adopt the August 15, 2011 version of CVX code sets.

Comments. Commenters supported our proposed “two certification criteria approach.” One commenter noted strong support for ONC's change in terminology from “retrieve and modify” to “access and change” and the clarification that this criterion does not include in scope the retrieval of immunization data from an external source to the EHR.

Response. We appreciate the support for the proposed certification criteria and the change in terminology. We are adopting these certification criteria as proposed, but with the inclusion of an updated implementation guide as discussed below.

Comments. Commenters expressed support for moving to only HL7 2.5.1. Commenters stated that requiring all EHR technology developers to consistently adopt the same standards would promote the access and use of immunization data and further boost interoperability and exchange. A couple of commenters recommended that HL7 2.3.1 and HL7 2.5.1 both be accepted for certification as part of the 2014 Edition EHR certification criteria. These commenters also recommended that HL7 2.5.1 could be required and HL7 2.3.1 could be optional as a means of allowing a reasonable transition period.

Response. We appreciate the support for the moving solely to HL7 2.5.1. We do not believe that permitting EHR technology to continue to be certified to HL7 2.3.1 as a means of meeting this certification criterion promotes improved exchanged and interoperability. Therefore, we are adopting only HL7 2.5.1 for the “transmission to immunization registries” certification criterion.

Comments. Commenters generally agreed with our proposal to adopt the HL7 2.5.1 Implementation Guide for Immunization Messaging Release 1.3 as the implementation specifications. One commenter contended that the implementation guide is vague on several important points regarding requirements for specific types of data and the circumstances in which specific data should be sent. The commenter recommended using the HL7 2.3.1 standard for certification because the HL7 2.3.1 Implementation Guide for Immunization Messaging is more clear on these important points than the 2.5.1 guide.

Response. We appreciate the support for the implementation guide. The CDC has worked to clarify ambiguities in Release 1.3 of the implementation guide and has published a new version of the implementation guide, Release 1.4, which reflects these clarifications. In particular, Release 1.4 clarifies the separate usage responsibilities for senders and receivers, provides conformance statements identifying core data elements that must be supported based on the National Vaccine Advisory Committee (NVAC) core data elements, adds support for messaging Vaccine Information Statement (VIS) data based on a 3D barcode, and provides HL7 version 2.7.1 usage guidance that improves clarity for conformance criteria and the requirements for HL7 message elements. Overall, these revisions do not establish additional substantive requirements in comparison to Release 1.3. Rather, the revisions improve the ability to test and certify EHR technology to the implementation guide and make it easier for EHR technology developers to implement the guide's requirements based on the corrections and clarifications. Accordingly, in lieu of adopting Release 1.3 of the implementation guide as we had proposed, we have adopted Release 1.4 for the “transmission to immunization registries” certification criterion. For the reasons stated above, we are not adopting HL7 2.3.1.

Comments. One commenter recommended that EPs, EHs and CAHs comply with the public health agency's local HL7 specifications guide as these guides describe what data elements are required within the jurisdiction that may go beyond those described in the CDC HL7 implementation guide. Conversely, another commenter stated variances at the local public health agency level in the content and transmission specifications continue to add challenges and cost to the adoption of immunization reporting (e.g., additional requirements or proprietary specifications). The commenter stated these challenges are further exacerbated by the fact that there are no standard specifications for the transmission of immunization reports. The commenter urged ONC to work with the CDC to identify ways to improve the adoption of the CDC implementation guides (content and transmission specifications) by the state immunization registries.

Response. Release 1.4 of the implementation guide reduces variability and standardizes the required data elements across public health jurisdictions. Release 1.4 also notes a standard format for states to indicate any variability. The certification criteria do not address transport standards, as this is left to the receiving public health authority. However, an expert panel convened by CDC and American Immunization Registry Association (AIRA) has recommended a SOAP-based standard for transport of immunization data.

Comments. Commenters stated that at least several states have made recording a patient's consent decision relative to the disclosure of immunization data by the provider (or consent to its re-disclosure by the external agency collecting it) a de facto requirement for electronic submission of immunization data. Commenters noted that recording patient consent was not part of the testing and certification for the 2011 Edition EHR certification criterion, but asked whether recording a patient's consent will be part of certification to the 2014 Edition EHR certification criteria. Some commenters more specifically asked whether patient consent would not to be recorded per the PD1-12 Protection Indicator of the referenced implementation guide.

Response. We believe that Release 1.4 of the implementation guide reduces the variability and standardized the required data elements across public health jurisdictions, including requirements for consent.

Comments. Commenters expressed support of the continued use of the CVX code sets and the August 15, 2011 version. Commenters requested that we specify that the vaccine administered be coded by the CVX and MVX (where known) as the combination would allow a specific vaccine to be identified accurately. One commenter recommended that a detailed review be conducted between ONC, the AIRA, CDC, and selected public and commercial stakeholders, for the purpose of revising the current CVX immunization code set to account for a small but significant number of remaining common discrepancies between data necessary to comprise an accurate and minimally complete immunization record which remains unaccounted for in current certified EHR systems. A few commenters recommended the inclusion of the National Vaccine Advisory Committee (NVAC) approved Immunization Information System Core Data Elements as required elements. One commenter noted that these are currently under review and revision but expected to be in place for 2013. One commenter requested clarification on what data should be included in immunization history.

Response. As we required for the 2011 Edition EHR certification criterion for immunization reporting, we continue to believe that the adoption of CVX is appropriate and that no other vocabulary standard need to be expressly adopted for the purposes of certification. We do, however, appreciate the points raised by commenters and will discuss them with our colleagues at CDC for consideration in proposals for the next edition of EHR certification criteria we propose.

Comments. One commenter noted a challenge facing transitioning data entry immunization registry challenges relating to replacing the “Vaccines for Children” inventory tracking and ordering functionality with EHR functionality.

Response. It is not clear exactly what the commenter was specifically addressing. The Implementation Guide defines a standardized way to record and track VFC eligibility. However, it does not address issues of inventory tracking.

Comments. A commenter expressed concern about specifying a particular CVX code set in regulation, particularly as the code set has been updated since the August 15, 2011 version. Commenters recommended the following wording change: “HL7 2.5.1 and Implementation Guide for Immunization Messaging Release 1.3, or the most recent version as published by CDC” for adoption of the implementation guide in regulation.

Response. We have established a process for adopting certain vocabulary standards, including CVX, which permits the use of newer versions of those standards than the one adopted in regulation. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets. In response to the commenters' suggestion that we permit the use of the “most recent version” of the implementation guide for certification, we refer the commenters to section III.A.5 found earlier in this preamble. This section explains why we cannot take such an approach. To note, as discussed above, in lieu of adopting Release 1.3 of the implementation guide as we had proposed, we have adopted Release 1.4.

Comments. A commenter noted concerns about the meaning of the language regarding reporting immunizations after receipt of a CCDA. It should be the responsibility of the EHR transmitting the CCDA to report the original immunization information. Requiring EHRs to report immunizations not administered within the context of the EHR may lead to duplicate results and require additional reconciliation at state immunization registry level.

Response. We cannot locate the exact language in the Proposed Rule that would have led this commenter to raise these concerns. The triggering event for reporting of an immunization is not part of the certification criteria. Certification focuses on the ability of EHR technology to properly create immunization information for electronic transmission according to the adopted standard and implementation specification.

Comments. One commenter disagreed with the requirement to transmit data to an immunization registry. The commenter stated that a process where data is directly entered into a state's certified application that is provided by the state immunization registry should be acceptable. The commenter noted that this information is stored directly in the state's immunization database and then the commenter's EHR technology hosts the state's immunization application. The commenter argued that this obviates the need for an interface and does not put the data at risk. The commenter stated that because of the inflexibility of the certification requirements, it has had to create a costly and inefficient interface to send data from its EHR technology to the state's registry. Therefore, the commenter recommended that § 170.314(f)(2) be made optional for those institutions that use a certified module provided by a state registry to directly enter immunization information as part of their EHR technology.

Response. The purpose of this certification criterion is to support interoperability between EHR technology and public health. Thus, any EHR technology that meets the certification requirements can be utilized to submit data to an Immunization Registry. Again, to meet this certification criterion, EHR technology must be able to properly create immunization information for electronic transmission according to the adopted standard and implementation specification. How this standardized data created by CEHRT gets to public health is not within the scope of certification. Additionally, we are aware that some states are considering modular certification of the state immunization registry to accomplish this function.

Comments. Commenters noted that the HITSC commented that it would be useful to have a standard for updating registries with groups or lists of patients instead of only individual patient transactions. The commenters stated that we should consult standards development organizations (i.e., HL7 for the v.2.5.1 message) to determine the most appropriate standard to achieve this goal.

Response. It is our understanding that most state immunization registries can accept batch reporting via the HL7 2.5.1 message standard and we previously indicated this approach was acceptable in FAQ 9-10-002-1.

Comments. Commenters expressed confusion over whether EHR technology must be certified to a transport standard to meet this certification criterion and whether EPs, EHs, and CAHs must use certain transport standards for submitting immunization information to immunization registries. Several commenters supported the requirement that eligible professionals utilize the transport method or methods supported by the public health agency to achieve meaningful use. Conversely, commenters requested that ONC require EHRs be certified in SOAP web services as well as Direct. These commenters also recommended that SOAP web services requirements should include the Centers for Disease Control and Prevention (CDC)'s Transport Layer Expert Panel WSDL specifications.

Response. We want to make clear that we do not require EHR technology to be certified to any transport standard, including Direct, to meet this certification criterion. There is no consensus transport standard that states and public health agencies use for the reporting of immunization information. Therefore, we believe that it is appropriate for EHR technology developers to have the flexibility to include in their EHR technology and implement the transport standards that permit EPs, EHs, and CAHs to report in their states and to local public health agencies.

Comments. Several commenters suggested using the preferred term “Immunization Information Systems” for the “transmission” certification criterion rather than “Immunization Registries.”

Response. We appreciate this suggestion, but are retaining the same naming convention for the certification criterion to prevent confusion with the associated MU objective and measure. The associated MU objective specifically references immunization registries.

Comments. Commenters stated that EPs, EHs, and CAHs that are currently successfully submitting immunization data in an ongoing manner using the HL7 2.3.1 and its implementation guide should continue to be able to do so for MU. One commenter suggested we explore offering additional incentives to early-adopting EPs, EHs, and CAHs that upgrade to the HL7 2.5.1 standard. A few commenters stated that, although bi-directional communication is not proposed for MU Stage 2, we should indicate that it will likely be required for MU Stage 3.

Response. We appreciate the submission of these comments, but they are outside the scope of this rulemaking. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and a response to these comments.

Comments. A commenter stated that patients should be able to have access to immunization records and receive an accounting of all disclosures for public health surveillance. Another commenter requested that interoperable immunization registries which require all registries to accept the proposed standards without requiring additional data.

Response. We thank commenters for these comments, but they are outside the scope of this rulemaking.

Comments. One commenter requested that Federal sources build a common portal for connectivity to immunization registries and other external data sources (e.g., HIEs, public health agencies, cancer registries, and non-cancer registries) so that the financial burden on EHR technology developers and end users is reduced.

Response. We appreciate this feedback, but it is outside the scope of certification and this rulemaking. We note that while no proposal for a single interface to all immunization registry exists, an expert panel convened by CDC and AIRA recommended standards for transport that include a standard WSDL which should help reduce the financial burden on EHRs to interface with immunization registries.

• Transmission to Public Health Agencies—Syndromic Surveillance

We proposed two certification criteria for reportable laboratory tests and values/results that were essentially a split of the 2011 Edition EHR certification criterion for reportable lab results (§ 170.302(l)). We proposed one certification criterion that focused just on the capabilities to electronically record, change, and access syndrome-based public health surveillance information (data capture) and another that focused on the capability to electronically create syndrome-based public health surveillance information for transmission in accordance with specified standards. We discussed these two proposed certification criteria together in the Proposed Rule for simplicity and to prevent confusion, but noted that we did not consider the certification criterion we proposed to focus on data capture to be a revised certification criterion. Rather, we stated that we believed that the certification criterion would constitute an unchanged certification criterion because all the capabilities included in the criterion were the same as the capabilities included in the corresponding 2011 Edition EHR certification criterion (§ 170.302(1)).

For the certification criterion focused on creating syndrome-based public health surveillance information for transmission, we proposed the use of only the HL7 2.5.1 standard for formatting syndrome-based public health surveillance. We stated that we proposed only the HL7 2.5.1 standard because public health agencies are rapidly moving to this standard and all stakeholders would benefit from focusing on a single standard for public health surveillance. We also proposed to constrain the standard for hospitals with the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data HL7 Version 2.5.1 (Release 1.0). We further proposed that certification to this guide be optional for the ambulatory setting because certification of ambulatory EHR technology to this guide could be useful for EHR developers that provide EHR technology to EPs that practice in urgent care settings.

Comments. Commenters supported our proposed “two certification criteria approach.” Commenter also stated that proposing the certification criteria in the manner that we had would permit HIEs to be certified to the certification criterion that includes the capability to create syndrome-based public health surveillance for transmission in accordance with specified standards and then serve as intermediaries for the transport of syndromic information to public health agencies. Another commenter noted that there should be no certification requirement required of the HIE to support this MU measure.

Response. We appreciate the support expressed by commenters for our approach. We are adopting as part of the 2014 Edition EHR certification criteria the certification criterion focused on the capability to create syndrome-based public health surveillance in accordance with the standards we have specified (§ 170.314(f)(3)). We are not, however, adopting the certification criterion we proposed that focused on data capture. We have chosen to drop this proposed certification criterion because we do not believe that it is essential to focus on from a testing and certification perspective. It is our understanding that EPs, EHs, and CAHs will not necessarily be recording, accessing, and capturing separate kinds of “syndromic surveillance” information to facilitate the transmission of syndrome-based public health surveillance information to public health agencies. Rather, they will simply be “passing on” or reporting the information that already exists in their CEHRT to public health agencies. Thus, upon further reflection, this “data capture” certification criterion is unnecessary for certification.

We agree with commenters regarding HIEs and noted in the Proposed Rule that our approach to the public health certification criteria could enable additional EHR technologies (likely in the form of EHR Modules) to be certified and provides additional pathways and flexibility to EPs, EHs, and CAHs to have EHR technology that can be used to satisfy the proposed revised definition of CEHRT. In regard to the commenters assertion that HIE should not be required to be certified, we note that there is no such requirement. However, if an HIE performs a capability for which certification is required and an EP, EH, or CAH uses that capability for MU, then that capability must be certified.

Comments. Many commenters supported the use of the HL7 2.5.1 standard and moving to a single standard. Some commenters asserted that imposing new standards, like a move from HL7 2.3.1 or HL7 2.5.1 to a requirement for HL7 2.5.1 only, on all systems will penalize early-adopting providers. One commenter suggested that newer data formats supported through the consolidated CDA be acceptable alternatives for transmission to public health agencies for medical research and public health.

Response. We appreciate the support for the HL 2.5.1 standard we proposed and have now adopted this standard as the sole standard for this certification criterion. We are adopting only the 2.5.1 standard because, as noted above and in the Proposed Rule, public health agencies are rapidly moving to this standard and all stakeholders would benefit from focusing on a single standard for public health surveillance. In regard to the concern expressed by commenters that our approach would punish early adopters using HL7 2.3.1, we direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a response to this comment. Last, we do not believe that the Consolidated CDA is appropriate for this certification criterion at the present time.

Comments. A commenter believed that it would be sufficient to simply adopt the implementation guide itself for this certification criterion because it incorporates the HL7 2.5.1 standard.

Response. We believe it is appropriate to specifically adopt this standard and not just the implementation guide that references this standard to provide clarity around the certification requirements for this certification criterion. In particular, the implementation guide is optional for the ambulatory setting. Therefore, clearly specifying the standard will ensure that EHR technology designed for the ambulatory setting will be certified to the HL7 2.5.1 standard.

Comment s. Commenters supported the adoption of the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data HL7 Version 2.5.1 (Release 1.0). Commenters also supported having certification to the implementation guide optional for the ambulatory setting, while one commenter requested that it be mandatory and another commenter stating that it was unnecessary to have for the ambulatory setting.

Response. We appreciate the support expressed for the implementation guide. The CDC has recently published Release 1.1 of the implementation guide. Release 1.1 reflects the work of the CDC to correct errors and clarify ambiguities that were present in Release 1.0 as well as provide information that was missing in Release 1.0. The CDC also recently published an addendum to the implementation guide, titled “Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance.” The addendum consolidates Release 1.1 information and clarifies existing conformance requirements of the implementation guide. For example, it specifies conformance statements and conditional predicates that clarify message requirements. It also specifies value set requirements and provides general clarifications and PHIN MG corrections. Overall, Release 1.1 and the addendum do not create additional substantive requirements in comparison to Release 1.0. Therefore, we believe the adoption of Release 1.1 and the addendum is appropriate as they will improve the ability to test and certify EHR technology to the implementation guide, as well as make it easier for EHR technology developers to implement the guide's requirements.

EHR technology designed for the inpatient setting seeking certification to this certification criterion must be certified to the implementation guide, while EHR technology designed for the ambulatory setting will have the option of being certified to the implementation guide. We believe that the guide can provide necessary clarity for ambulatory EHR developers that provide EHR technology to EPs that practice in urgent care settings.

Comments. Several commenters recommended replacing “Inpatient” with “Hospital or urgent care.” The commenters asserted that such a change more appropriately reflects the clinical settings that transmit syndromic surveillance data to health departments.

Response. While we appreciate the commenters' recommendation, the designation “inpatient” is a general designation that we use to distinguish certification criteria and capabilities that apply to a particular setting for certification. We currently designate only two settings for certification, the inpatient setting and the ambulatory setting without variation. EHs use “inpatient-certified” EHR technology for their inpatient department and emergency departments. For urgent care settings that are not the emergency department, the providers would be non-hospital-based EPs and would require “ambulatory-certified” EHR technology. Therefore, we are retaining the “inpatient” designation.

Comment. Commenters recommended adding in regulation after the implementation guide the following statement “or the most recent version as published by CDC.”

Response. We refer the commenters to section III.A.5 found earlier in this preamble. This section explains why we cannot take such an approach.

Comments. Commenters expressed confusion over whether EHR technology must be certified to a transport standard to meet this certification criterion and whether EPs, EHs, and CAHS must use certain transport standards for submitting syndrome-based public health surveillance information to public health agencies. Some commenters requested that we require EHR technology to be certified in SOAP web services as well as Direct. One commenter encouraged us to expand the required transport standards to include commonly used transports, such as MLLP (HL7) and IHE XDS, or define specific data types and transactions for each transport type.

Response. We want to make clear that we do not require EHR technology to be certified to any transport standard, including Direct, to meet this certification criterion. There is no consensus transport standard that states and public health agencies use for the reporting of syndrome-based public health surveillance information. Therefore, we believe that it is appropriate for EHR technology developers to have the flexibility to include in their EHR technology and implement the transport standards that permit EPs, EHs, and CAHs to report in their states and to local public health agencies.

Comment. One commenter suggested that this certification criterion include the capability to capture adverse drug events for reporting to public health agencies. Another commenter recommended that we should require the capture of occupational exposure and industry worker health information.

Response. The certification criterion does not preclude other types of reportable events from being captured and reported by EHR technology. We do not believe, however, that it is appropriate to modify the certification criterion to explicitly reference adverse drug events or any other specific syndrome-based surveillance information for the purposes of EHR technology certification.

Comments. A commenter recommended that the ONC tighten the message structures within the HL7 message, such that one single message works with all registries of the same type. Specifically, there should not be 50 different flavors of the HL7 2.51 format for 50 different states for each transmission type. In addition, to make transmission simple, the registries captioned above should be required to accept messages via the Direct Project messaging system only as this will reduce the burden on providers for making dozens of point-to-point connections with registries.

Response. We acknowledge this commenter's recommendation, but do not believe that the recommended outcome can be effectively reached through certification. While certification can ensure that EHR technology can create a single, standardized message it cannot affect the additional data states may also require be submitted or the IT system differences across states.

Comments. One commenter stated that in consideration of the challenges for many public health agencies to receive this data electronically, the objective and associated criterion should be removed.

Response. We appreciate the submission of this comment, but it is outside the scope of this rulemaking. We direct the commenter to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and a response to this comment.

• Automated Measure Calculation

We proposed to adopt a revised “automated measure calculation” certification criterion for the 2014 Edition EHR certification criteria. We revised the certification criterion to clearly identify that the recording, calculating, and reporting capabilities required by this certification criterion apply to the numerator and denominator associated with the capabilities that support an MU objective with a percentage-based measure. We clarified that the capabilities are the capabilities included in the certification criteria to which a Complete EHR or EHR Module is presented for certification.

We emphasized that testing to this certification criterion would not only include verification of the ability of EHR technology to generate numerators and denominators, but would also verify the accuracy of the numerators and denominators generated by the EHR technology. We stated testing to ensure the accuracy of these calculations would significantly reduce the reporting burden for MU attestation. Additionally, we stated that testing and certification to this revised certification criterion would include testing and certifying the ability to electronically record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable MU measure that is supported by a capability in the new certification criteria proposed and adopted in a final rule.

Comments. Commenters supported this certification criterion and emphasized the value of automated measure calculation for EPs, EHs, and CAHs. Commenters noted that it is important to ensure that EHR technology can accurately calculate these measures and stated that accurate measure calculations are critical to reducing the burden of reporting and for promoting adoption. One commenter noted that although “automated measure calculation” suggests a simple process is required for physicians to calculate their data for meeting MU measures, they recommended that ONC explicitly require that EHR technology enable the automatic creation of reports.

Response. We thank commenters for supporting this certification criterion and agree that the improved accuracy of measure calculations will reduce reporting burdens for EPs, EHs, and CAHs. We have adopted this certification criterion as proposed. This certification criterion requires EHR technology to demonstrate the capability to automatically create reports based on the numerator and denominator for MU objectives with percentage-based measures.

Comments. A commenter stated that this certification criterion does not fall into patient-centric care and while a necessary component of reporting, the functionality it includes could be performed by another technical component outside the EHR.

Response. As stated in the S&CC July 2010 final rule (75 FR 44642), we adopted this certification criterion to reduce the reporting burden associated with participating in MU. This certification criterion is required in order for EHR technology presented for certification to meet the Complete EHR definition. We permit, but do not require, EHR technology presented as an EHR Module for certification to also be certified to this certification criterion. In instances where an EHR Module is not presented for certification to this certification criterion, it would need to be certified to the “automated numerator calculation” certification criterion adopted in this final rule. We also note that CMS permits reporting outside certified EHR technology per FAQ 3063, which can be found at https://questions.cms.gov/faq.php?id=5005&faqId=3063.

Comments. A commenter recommended that EHR technology developers be required to provide not only the numerator, denominator, and percentage for the selected reporting period, but also offer the capability to display a detail level that includes patient identifiers and data elements and if the patient record assessed met or did not meet the objective.

Response. While we realize such detailed information may have value for an EP, EH, and CAH, but we do not believe that we need to require such level of detail be displayed to the user for purposes of certification and to support the calculation and reporting of objectives with percentage-based measures. We note, however, that this level of detail may be useful to demonstrate an EHR technology's compliance with this certification criterion during testing.

Comments. Commenters requested clarification on the testing procedures that will be used for this certification criterion. Commenters also provided many recommendations for testing EHR technology to this certification criterion. One commenter suggested not moving forward with this criterion unless a test data set is provided from ONC that validates the ability of EHR technology to generate these accurate calculations and reports. Other commenters requested clarification on whether test data would be provided and EHR technology would be expected to match some predetermined calculations by the tester. These commenters stated if EHR technology developers are expected to demonstrate each measure calculation on the report, then they are concerned about the time that could be required to validate such accuracy and thus added to the time it takes to certify EHR technology. Another commenter suggested providing specifications on how the numerators and denominators for these measures should be calculated. The commenter also requested that in giving EHR technology developers a test data set, they are also given multiple ways to accommodate the different approaches that exist to importing practical data sets.

Some commenters expressed concerns that testing tools similar to Cypress are not accurate. For an accuracy test, commenters recommended that test scripts be developed that can be used by EHR developers. The commenters further recommended that the test scripts be based on real-world clinical workflows where a patient should be included or excluded from the numerators and denominators of an objective in an expected manner. The commenters noted that the test would determine the accuracy of the EHR technology based on whether the patient is included or excluded from the numerators and denominators according to expectations. Commenters also recommended that testing include time-based elements to simulate an EHR reporting period.

Response. We appreciate the many comments on testing to this certification criterion. Consistent with the process we outlined in the Permanent Certification Program final rule (76 FR 1280), we anticipate approving a test procedure for this certification criterion that, at minimum, is clearly traceable to the capabilities included in the certification criterion, sufficiently comprehensive (i.e., assesses all required capabilities) for NVLAP-accredited testing laboratories to use in testing a Complete EHR's or EHR Module's compliance with the certification criterion, and was developed using an appropriate public comment process. With CMS, we intend to be more proactive about explaining numerator and denominator requirements so that misinterpretations are reduced to a minimum. To that end, we will work with CMS to provide education materials and any additional guidance necessary to help EHR technology developers better understand the numerator and denominator requirements for MU objectives and measures. Finally, we wish to make clear that for MU objectives which CMS has provided flexibility in its final rule for EPs, EHs, and CAHs to pursue alternative approaches to measuring a numerator and denominator, the EHR technology must be able to support all CMS-acceptable approaches in order to meet this certification criterion. For example, there are two options for counting emergency department admissions. If an EHR technology developer only included one option in its EHR technology for certification, the EHR technology developer would take away the flexibility granted to the EP, EH or CAH by CMS. We believe that this flexibility should be available to all EPs, EHs, and CAHs regardless of what Certified EHR Technology they utilize.

b. Ambulatory Setting

We propose to adopt the following revised certification criteria for the ambulatory setting.

• Electronic Prescribing

We proposed to adopt a revised certification criterion for the ambulatory setting that requires the use of RxNorm as the vocabulary standard. We proposed to continue to permit the use of NCPDP SCRIPT version 10.6 to meet this certification criterion, but also to no longer include the use of NCPDP SCRIPT version 8.1 as a way to meet the 2014 Edition EHR certification criterion. We stated that we made this proposal because we understood CMS was planning to propose the retirement of NCPDP SCRIPT version 8.1 (adopted as a Medicare Part D e-prescribing standard) in a proposed rule that was scheduled to be issued soon after the Proposed Rule was published. We noted that if we received information indicating a change in CMS' plans prior to the issuance of our final rule, we may, based also on public comment, reinstate this standard in a final revised certification criterion. We stated that we were proposing to adopt this certification criterion for both the ambulatory and inpatient settings because it supports our desired policy and interoperability outcome for content exchange standards to be used when information is exchanged between different legal entities.

In the interest of providing readers with a clear, cohesive, and consistent recitation of comments and our response and to also avoid redundancy, we direct readers to our discussion of the adopted “electronic prescribing” certification criterion (§ 170.314(b)(3)) under section III.A.8.c.

• Clinical Summary

We proposed to revise the “clinical summaries” certification criterion for the 2014 Edition EHR certification criteria to reflect the proposed new and revised standards for problem lists and other vocabulary standards. We noted in the Proposed Rule that we made several refinements to the HITSC recommended certification criterion to ensure that EHR technology meets the appropriate standards and is capable of making available the information CMS is proposing be provided to a patient after an office visit.

We proposed that when information is provided electronically, the information should be provided according to the Consolidated CDA standard. We stated in the Proposed Rule that adopting the Consolidated CDA for this certification criterion is advantageous since its template structure can accommodate the formatting of a summary of care record that includes all of the data elements that CMS proposed be provided to a patient after an office visit. We requested public comment on whether we should adopt separate certification criteria to explicitly require the capture of unique data elements included in clinical summaries, such as care plans and future scheduled tests. For certain other data elements in § 170.314(e)(2), we proposed to require that the capability to provide the information be demonstrated in accordance with the specified vocabulary standard. We noted that these vocabulary standards had been previously adopted or were proposed for adoption in the Proposed Rule.

Comments. Many commenters expressed agreement with this certification criterion and the use of the Consolidated CDA. Commenters noted that the use of the Consolidated CDA would be beneficial for interoperability purposes.

Response. We appreciate the support for this certification criterion and the use of the Consolidated CDA for the clinical summary. We are adopting this certification criterion as proposed with Release 2.0 (July 2012) of the Consolidated CDA standard as discussed earlier in the preamble under the “view, download, and transmit to a 3rd party” certification criterion, which fully supports the clinical summary as defined by CMS in the Stage 2 final rule for the MU objective and measure associated with this certification criterion. To note, we have revised the certification criteria heading to the singular form (“clinical summary”).

Comments. We received numerous comments regarding what should and should not be included in a clinical summary, including requests for clarification of data in the clinical summary and care plan. We also received requests for alignment of the data in a clinical summary used for this certification criterion and with the data included in the clinical summary used for other certification criteria. We also received requests for alignment with the use of the clinical summary by CMS for MU.

Some commenters stated that the inclusion of names and contact information of any additional care team members provides no clinical benefit and will likely distract the patient and degrade the effectiveness of the clinical summary. A few commenters stated that we postpone the adoption of standards and certification criteria for care plans and future scheduled tests as part of the clinical summaries. Other commenters stated that EHR technology should offer EPs the capability to customize the clinical summary, where omitting some information is in the best interest of the patient.

Response. As noted in the Proposed Rule, this certification criterion specifies the capabilities that EHR technology would need to include in order for an EP to provide the information identified by CMS to a patient after an office visit. A clinical summary and the data it includes such as a care plan are defined or described by CMS. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a complete discussion of the “clinical summaries” MU objective and measure, including the clinical summary data that are required to be provided after an office visit. We have adopted the Consolidated CDA standard, which supports all of the data that CMS has included for the MU objective and measure to which this certification criterion correlates.

Further to make this certification criterion easier to read and to clearly express the capabilities that EHR technology must include in order to support MU, we have broken the certification criterion into three separate specific capabilities. The first echoes the requirement that EHR technology must be able to create a clinical summary in both human readable format and according to the Consolidated CDA. The second would require EHR technology to enable a user to customize (e.g., be able to edit) the data they include in the clinical summary. This capability supports CMS's policy for this MU objective and measure that permits EPs excluding certain data from a clinical summary and clarifies as well as makes explicit the customization capability other commenters mentioned should be present. And, overall we believe this capability will assist EPs in determining how to best structure the clinical summary they want to provide their patients based on the data their CEHRT is able to produce. The third specific capability identifies the minimum data EHR technology must permit a user to select for inclusion in a clinical summary.

Comments. A commenter stated that future appointments could be a part of scheduling system and not readily available to the EHR to include in the summary. The commenter noted that this could perhaps require that another application be included in the “process for certification.”

Response. We interpret EHR technology broadly for the purposes of certification in that any technology that meets a certification criterion is defined as an EHR Module.

To meet this certification criterion, EHR technology must demonstrate all the capabilities included in the certification criterion. These capabilities support the associated MU objective and measure, which includes providing any future appointments in a clinical summary.

Comments. Commenters stated that it was unnecessary to adopt separate certification criteria to explicitly require the capture of unique data elements included in clinical summaries such as care plans and future scheduled tests, while a few commenters suggested we pursue such an approach.

Response. We agree with those commenters that stated it was unnecessary to adopt separate certification criteria. We made this similar response in the transitions of care certification criterion where we also posed this question.

Comments. Commenters stated that they support the increased focus on supporting patients' access to their information through various means, but were concerned that the proposed certification criterion for clinical summaries included requirements to share information with unknown third parties. A commenter suggested that patients as well as their designated agent(s) be registered on the EP's CEHRT to enable transmission of their clinical data to them.

Response. We are unclear as to what language in the Proposed Rule prompted commenters to raise this concern. This certification criterion does not require the sharing of patient health information with third parties. We encourage commenters to review our responses to comments on the view, download, and transmit to a 3rd party certification criterion.

Comments. A commenter noted that patients should be able to access, download, and use clinical summaries which are a matter of patient safety so errors and omissions can be detected.

Response. This certification criterion requires EHR technology to be capable of enabling a user to electronically create a clinical summary in human readable format and formatted according to the Consolidated CDA.

Comment. A commenter stated that EHR technology should support integration with HIEs to enable the export of clinical summaries, making the information available to any authorized provider involved in the patient's care.

Response. This certification criterion focuses on capabilities that EHR technology would have to demonstrate for certification that would support an EP's ability to provide a clinical summary to a patient, including electronically. It is not focused on the exchange of a patient's health information. Therefore, we decline to modify this certification criterion in response to this recommendation. We note, however, that the “transitions of care-create and transmit transition of care/referral summaries” certification criterion (§ 170.314(b)(2)) requires EHR technology to be capable of formatting a patient's transition of care/referral summary in accordance with the Consolidated CDA and capable of using transport standards.

c. Inpatient Setting

We are adopting the following revised certification criterion for the inpatient setting.

• Transmission of Reportable Laboratory Tests and Values/Results

We proposed two certification criteria for reportable laboratory tests and values/results that were essentially a split of the 2011 Edition EHR certification criterion for reportable lab results (§ 170.306(g)). We proposed one certification criterion that focused just on the capabilities to electronically record, change, and access laboratory rests and values/results (data capture) and another that focused on the capability to electronically create reportable laboratory tests and values/results for electronic transmission in accordance with specified standards. We discussed these two proposed certification criteria together in the Proposed Rule for simplicity and to prevent confusion, but noted that we do not consider the certification criterion we proposed to focus on data capture to be a revised certification criterion. Rather, we stated that we believed that the certification criterion would constitute an unchanged certification criterion because all the capabilities included in the criterion were the same as the capabilities included in the corresponding 2011 Edition EHR certification criterion (§ 170.306(g)).

For the certification criterion focused on creating reportable laboratory rests and values/results for transmission, we proposed the use of only the HL7 2.5.1 standard and LOINC® version 2.38 as the vocabulary standard. Following consultation with the Centers for Disease Control and Prevention, we also proposed to adopt the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) with Errata and Clarifications and SNOMED CT® International Release January 2012 version—which, we noted, contains corrections and will require minor changes to conformance testing and certification to account for newly assigned OIDs (object identifiers) identifying the message profiles in the implementation guide.

Comments. Commenters supported our proposed “two certification criteria approach.” Commenter also stated that proposing the certification criteria in the manner that we had would permit HIEs to be certified to the certification criterion that includes the capability to create reportable laboratory tests and values/results for transmission in accordance with specified standards and then serve as intermediaries for the transport of laboratory tests and values/results to public health agencies.

Response. We appreciate the support expressed by commenters for our approach. We are adopting as part of the 2014 Edition EHR certification criteria the certification criterion focused on the capability to electronically create reportable laboratory rests and values/results for electronic transmission in accordance with the standards we have specified (§ 170.314(f)(4)). We are not, however, adopting the certification criterion we proposed that focused on data capture. For similar reasons as expressed in the syndromic surveillance certification criterion, we have dropped this requirement because we believe it is not necessary to focus on for the purposes of EHR technology certification.

We agree with commenters regarding HIEs and noted in the Proposed Rule that our approach to the public health certification criteria could enable additional EHR technologies (likely in the form of EHR Modules) to be certified and provides additional pathways and flexibility to EPs, EHs, and CAHs to have EHR technology that can be used to satisfy the proposed revised definition of CEHRT.

Comments. Commenters supported maintaining the use of the HL7 2.5.1 standard and adopting the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) with errata, as well as the latest versions of SNOMED CT® and LOINC®. Commenters suggested that we simply state in regulation that EHR technology can be certified to the most recent versions of the vocabulary standards (SNOMED CT® and LOINC®) and the implementation guide for certification.

Response. We appreciate the commenters' support for the standards and implementation guide we proposed. We have adopted the proposed certification criterion, including the proposed standards and implementation guide with errata and clarifications and a recently published supplement to the implementation guide, titled ““ELR 2.5.1 Clarification Document for EHR Technology Certification.” The supplement was not available when the Proposed Rule was published. It does not specify additional substantive requirements. Rather, it clarifies conformance requirements and other aspects of Release 1 with errata and clarifications that will improve testing and certification to the implementation guide. Accordingly, we are adopting the supplement and the proposed Release 1 with errata and clarifications.

We have established a process for adopting certain vocabulary standards, including SNOMED CT® and LOINC®, which permits the use of newer versions of those standards than the one adopted in regulation. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets. In response to the commenters' suggestion that we permit the use of the “most recent version” of the implementation guide for certification, we refer the commenters to section III.A.5 found earlier in this preamble. This section explains why we cannot take such an approach.

Comments. A commenter expressed concern about the ongoing volatility of the LOINC® and SNOMED CT® code sets and the burden that will be placed on laboratory staff. The commenter further stated that the failure to adopt national standards for that coding may result in less than optimal interstate sharing of laboratory results. Another commenter noted that the mapping of local codes to our standard codes is needed but little guidance is provided.

Response. We are not familiar with the “volatility” that the commenter references and believe that LOINC® and SNOMED CT® constitute consensus-based national standards. The CDC has published the Reportable Condition Mapping Table (RCMT) that provides a subset of LOINC® and SNOMED CT® codes associated with reportable conditions. RCMT can be obtained from CDC vocabulary server PHIN VADS ( http://phinvads.cdc.gov ). The CDC vocabulary team provides guidance to implementers regarding the implementation of RCMT and mapping of LOINC® and SNOMED CT® codes to local lab tests. CDC vocabulary team can be reached directly via email at phinvs@cdc.gov or through the CDC Meaningful Use technical assistance team (meaningfuluse@cdc.gov). In addition, the LOINC® SDO has created a tool known as “RELMA,” which helps to map the local tests to standard LOINC® laboratory tests. LOINC® SDO provides RELMA training twice a year and, through a partnership with LOINC® SDO, the CDC provides RELMA training to the public health community at least twice a year with a special focus on microbiology lab tests.

Comments. Commenters pointed to what they believed to be an inconsistency between the Proposed Rule and the Stage 2 proposed rule. Commenters stated that the Stage 2 proposed rule stated that “Public Health Agencies may specify the means of transport as long as it does not go above and beyond what is required in ONC's certification criteria.” These commenters further stated that we only required the Direct Protocol for transport.

One commenter strongly recommended the inclusion of PHIN-MS as a required transport mechanism for hospital EHR systems and further noted that leaving “other transport mechanisms” undefined or defined by state will likely result in EHR vendor implementation variance. Another commenter suggested the use of the NwHIN query-and-response protocol to share reportable laboratory tests and values/results. Conversely, other commenters strongly supported the requirement that transport method or methods supported by the public health agency should be used for MU.

Response. We want to make clear that we do not require EHR technology to be certified to any transport standard, including Direct, to meet this certification criterion. There is no consensus transport standard that states and public health agencies use for the reporting of laboratory test and values/results. Therefore, we believe that it is appropriate for EHR technology developers to have the flexibility to include in their EHR technology and implement the transport standards that permit EPs, EHs, and CAHs to report in their states and to local public health agencies.

Comments. Some commenters stated that the MU objective related to these certification criteria describes a function of a laboratory information system rather than EHRs. A commenter stated that if standards we propose for this certification criterion are mandated, then state-level programs must also be amended to support the standards. Other commenters stated that early adopters that support only HL7 2.3.1, common among public health systems, should not be penalized in MU Stage 2. One commenter requested clarification that ongoing submission means that all relevant data is transmitted in a timely fashion as required by the agency. Another commenter suggested that we clarify that “reportable laboratory tests” means only those whose transmission is required under state and local law.

Response. We appreciate the submission of these comments, but they are outside the scope of this rulemaking. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and responses to these comments.

Comments. A commenter stated that is important that public health authorities have the prerogative to prioritize which submitters are moved in to production first.

Response. This certification criterion and certification in general does not address or regulate these decisions made by public health agencies.

11. Unchanged Certification Criteria

In the Proposed Rule, we described the certification criteria that we considered “unchanged.” We noted the following factors in determining whether a certification criterion would be “unchanged:”

• The certification criterion includes only the same capabilities that were specified in previously adopted certification criteria;
• The certification criterion's capabilities apply to the same setting as they did in previously adopted certification criteria; and
• The certification criterion remains designated as “mandatory,” or it is re-designated as “optional,” for the same setting for which it was previously adopted certification criterion.

For clarity, we explained that an unchanged certification criterion could be a certification criterion that includes capabilities that were merged from multiple previously adopted certification criteria as long as the capabilities specified by the merged certification criterion remain the same. The “authentication, access control, and authorization” certification criterion discussed below and adopted at § 170.314(d)(1) meets this description. Additionally, as we specified in the Proposed Rule, an unchanged certification criterion could be a certification criterion that has fewer capabilities than a previously adopted certification criterion as long as the capabilities that remain stay the same. The “integrity” certification criterion discussed below and adopted at § 170.314(d)(8) meets this description. We discussed in the Proposed Rule and in the description of revised certification criteria in this final rule that a certification criterion could be characterized differently based on the setting to which it applies or the designation it is given (“mandatory” or “optional”). For example, a certification criterion that includes the same capabilities that were specified in a previously adopted certification criterion would be considered unchanged for the ambulatory setting if the previously adopted certification criterion only applied to the ambulatory setting and certification to the criterion was “mandatory.” However, this same certification criterion would be considered new for the inpatient setting if it were subsequently adopted for both settings.

Comments. We did not receive comments questioning our description of unchanged certification criteria.

Response. Therefore, we continue to use this description of unchanged certification criteria to categorize the following certification criteria we have adopted as part of the 2014 Edition EHR certification criteria. For clarity, we have adopted these unchanged certification criteria in addition to the unchanged certification criteria previously discussed in this preamble (“immunization information” § 170.314(f)(1) and “receive laboratory test and values/results” § 170.314(b)(5)—inpatient setting only).

a. Refinements to Unchanged Certification Criteria

In the Proposed Rule, we proposed refinements to the following unchanged certification criteria. We received public comments on all of the certification criteria. We discuss the public comments received and the adoption of these unchanged certification criteria as part of the 2014 Edition EHR certification criteria below.

• Computerized provider order entry

We proposed a CPOE certification criterion that merged the separate ambulatory and inpatient CPOE certification criteria in the 2011 Edition EHR certification criteria into one criterion because they those certification criteria are identical. We proposed to replace the terms “modify” and “retrieve” with “change” and “access,” respectively. We also proposed to remove the term “store” from the criterion because it is redundant with our interpretation of the term “record.” Finally, we proposed to move the phrase “at a minimum” in the certification criterion to eliminate any possible ambiguity as to what the phrase modifies. As proposed, the certification criterion made clear that the phrase modifies the order types and not the terms “record,” “change,” and “access.”

Comments. Many commenters expressed general support for this certification criterion as proposed. We also received many comments requesting further clarification of the CPOE denominator, including clarifying what orders count, what providers may enter the orders, and how current MU EHR users should report measures when transitioning to EHR technology certified to the 2014 Edition EHR certification criteria during an EHR reporting period in 2013. One commenter requested clarification as to whether the change in the CMS measure definition would require “re-certification” to this certification criterion or if it would only affect certification to the automated measure calculation certification criterion.

A commenter recommended that this certification criterion include the capability to send the order information in an electronic format consistent with the content exchange standard identified in the Proposed Rule at section 170.205(k) (HL7 2.5.1 and the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Lab Results Interface, Release 1 (US Realm)). Another commenter recommended that this certification criterion should be amended to require some notation about a patient's predominant race when multiple races are identified.

One commenter recommended that CPOE of radiology be separated into its own certification criterion. The commenter stated that the new “radiology” certification criterion should require that CPOE of radiology have integrated CDS tied to national physician association-developed appropriateness criteria guidelines. The commenter reasoned that appropriateness criteria-guided CDS at the point-of-order will inform referring physicians and their patients as to the most clinically appropriate imaging examinations for the given indications.

Response. We appreciate the support for the certification criterion as proposed and are adopting this certification criterion as an unchanged certification criterion for the 2014 Edition EHR certification criterion at § 170.314(a)(1). The comments requesting clarification related to the denominator and the reporting of the CPOE measure during 2013 are outside the scope of this rulemaking. We direct commenters to the Stage 2 final rule for a discussion of these issues. However, we do clarify that the change in the CPOE denominator affects the “automated measure calculation” certification criterion (§ 170.314(g)(2)), which is a revised certification criterion for the 2014 Edition EHR certification criteria.

This certification criterion focuses on enabling a user to electronically record, change, and access, at a minimum, medication, laboratory and radiology/imaging orders. It does not focus on the transmission of these orders. Additionally, the standard recommended by the commenter is incorrect because it focuses on the receipt of laboratory tests results, not the outbound transmission of laboratory orders. Therefore, we decline, as recommended by the commenter, to include the standard. We also do not believe that the recording of race should be associated with this certification criterion as recommended by a commenter because such an action would dictate workflow and the recording of race is already required by the “demographics” certification criterion (§ 170.313(a)(3)). Last, we decline to separate out radiology orders into a separate certification criterion. While we appreciate the enhanced clinical functionality presented in the commenter's recommendation, this certification criterion is focused on the general CPOE capability for various types of orders and supporting the associated MU objective and measure. Additionally, as structured, this certification criterion contemplates the general functionality applying to more than just radiology or the other two types of orders specified.

• Authentication, access control, and authorization

We proposed to merge the “access control” certification criterion at § 170.302(o) and the “authentication” certification criterion at § 170.302(t) into one certification criterion for the 2014 Edition EHR certification criteria. We reasoned that since the two test procedures developed for these certification criteria were similar and that the capabilities included in the certification criteria go hand-in-hand, it was best to merge the two certification criteria into one certification criteria. We stated that this would allow for more efficient testing and was consistent with EHR technology development.

In combination with this proposal, we proposed to adopt part of the HITSC's recommendation related to person/user authentication, which was reflected in the proposed certification criterion. We also expressed the HITSC's authentication recommendation as additional guidance for this certification criterion in that the capability to authenticate human users would consist of the assertion of an identity and presentation of at least one proof of that identity. We stated that it is most appropriate for this certification criterion to focus on users that would be able to access electronic health information in EHR technology within an EP, EH, or CAH's organization and not to focus on external users that may make requests for access to health information contained in the EHR technology for the purpose of electronic health information exchange. We further stated that the latter purpose would likely require a different/additional security approach(es) and rely on a health care provider's overall infrastructure beyond its EHR technology.

We acknowledged in the Proposed Rule's preamble, as recommended by the HITSC, example standards and implementation specifications which could be followed in designing EHR technology to meet this certification criterion. In particular, we specified that these example standards and implementation specifications could include, but were not limited to: NIST Special Publication 800-63, Level 2 (single-factor authentication) and ASTM, E1986-09 (Information Access Privileges to Health Information).

Comments. A majority of comments on the proposed certification criterion supported it as proposed and without any changes for the final rule. One commenter voiced its appreciation for the consolidation of the two prior 2011 Edition EHR certification criteria. Another commenter requested that we clarify whether the certification criterion applies to: internal system and/or human users; external system and/or human users that are recipients of “push” type health information exchanges such as those required for in the Stage 2 proposed rule; or excludes all external system and/or human users. The commenter went on to note that this certification criterion does not include standards to consistently specify electronic health information as distinguishable security objects; specify whether the access is at a coarse or fine grain level as would likely be required for data segmentation for privacy; encode the “actions” in a consistent and meaningful manner using standard data operations vocabulary; and specify an interoperable value set of standard structural and functional roles. Further, commenters noted that we should clarify the users to which the certification criteria apply; and require adoption of the privacy and security standard vocabularies such as those established by HL7 and ASTM. Other commenters noted that the test procedure would need to be updated for this certification criterion. Last, a commenter stated that we should revise the requirement for single factor level of assurance (LOA) 2 authentication and increase it to LOA 3, 2-factor authentication. The commenter reasoned that by the time the final rule goes into effect, additional LOA 3, 2-factor credential form factors will be available to the general public and that these credentials will be readily available from multiple commercial sources.

Response. We appreciate commenters support for this certification criterion and have adopted it in this final rule as proposed. As we stated in the Proposed Rule, we intend and believe that it is most appropriate for this certification criterion to focus on users that would be able to access electronic health information in EHR technology within an EP, EH, or CAH's organization and not to focus on external users that may make requests for access to health information contained in the EHR technology for the purpose of electronic health information exchange. The latter purpose would likely require a different/additional security approach(es) and rely on a health care provider's overall infrastructure beyond its EHR technology. With respect to the other points raised in comments, we have purposefully left this certification criterion flexible to accommodate for different implementations, deployments, and organizational policy decisions. Ultimately, this certification criterion sets a minimum requirement and provides assurance that an EP, EH, and CAH's CEHRT includes capabilities that can perform authentication, access control, and authorization. Contrary to a commenter's suggestion, the certification criterion does not specify an LOA, which in turn permits EHR technology developers to satisfy it in a number of different ways. Practically speaking, however, one-factor authentication would, at a minimum, be needed to satisfy the certification criterion. Finally, we appreciate the commenters' suggestions about specific security vocabulary standards. We did not propose to include any of these standards and believe that it would be prudent to first have the HITSC consider their inclusion and whether it would be necessary to specify them in a certification criterion or in guidance or some other type of educational material.

• Automatic log-off

In the Proposed Rule, we proposed to adopt the automatic log-off certification criterion from the 2011 Edition EHR certification criteria (i.e., as unchanged). We did, however, seek to clarify what “terminate” in the certification criterion conveyed. We stated that terminating a session should not be confused with locking a session, where access to an active session is permitted after re-authentication. We then indicated that EHR technology must have the capability to terminate the session, including terminating the network connection.

Comments. Many commenters supported our proposal and agreed that the certification criterion should remain unchanged for the 2014 Edition EHR certification criteria. Several commenters, though, took issue with our clarification. One commenter noted that our proposal does not describe what impact termination has on documentation in progress at the time termination occurs. The commenter stated that this would create the potential for information loss and give clinicians a false sense that information entered into the patient's medical record had been saved. Another commenter disagreed with our clarification because it would draw a distinction between a session “termination” and a session “lock.” The commenter contended that any attempt to draw such a distinction is purely subjective. The commenter stated that, for example, an application's session state may persist in local memory or in a centralized data store and that both of these could be used to reconstitute a session which has been suspended by various means. In the latter case, where a centralized data store is used for the persistence of session state, the user may terminate the application, reboot the workstation, restart the application and pick up where they left off during their previous session. In the end, the commenter proposed that any application state which: (a) Renders application information completely inaccessible; (b) requires login authentication to access the application; and (c) requires the same credentials to access previous session state should qualify as a termination. Further, they stated that this definition should apply regardless of whether the application is physically terminated or not, and regardless of whether the ability to reconstitute a previous session is implemented through a centralized data store, or through in-memory persistence of session state. Another comment sought clarification that automatic log-off of an application does not lead to automatically terminated network connections of other applications active on, e.g., the desktop or server. Similarly, another commenter stated that multiple applications may be running and concurrently using the network connection on the same device. The commenter stated that the proposed language implies that all network connections from the end-user device are terminated automatically when the application shuts down. They suggested that the termination of network connections be limited to those used by the application being shut down. Once commenter believed that we should clarify that it is the user's session within the EHR that should be terminated.

Response. We appreciate the thoughtful and detailed responses provided by commenters. In considering the prior response we issued in the S&CC July 2010 Final Rule (75 FR 44617-618), our clarification in the Proposed Rule, and the comments received on the Proposed Rule, we believe that additional clarity is necessary regarding the capability expressed by this certification criterion. Given the scenarios identified by commenters, we believe that EHR technology developers should interpret this certification criterion to require (as one commenter described) that after a period of inactivity the EHR technology must make a user's session inaccessible and subsequently require the user to re-authenticate using the same credentials used to begin or resume the session. To make the capability expressed by this certification criterion clearer to EHR technology developers, we have replaced “Terminate” with “Prevent a user from gaining further access to * * *.” Although this may be longer phrasing toward the same meaning, we believe it less ambiguous than “terminate,” is more plain language, and that it is also consistent with the language used for the “session lock” security control specified in NIST 800-53 rev3. Additionally, we clarify that this certification criterion is not meant to result in the termination of network connections, especially network connections that are not in use by the EHR technology, but by other applications.

• Emergency access

In the Proposed Rule, we proposed to include in the 2014 Edition EHR certification criteria a refined version of the 2011 Edition EHR certification criterion for emergency access codified at § 170.302(p). We proposed to remove the parenthetical “who are authorized for emergency situations” from the certification criterion and include the phrase “identified set of users.” We stated that these refinements would more clearly convey the capabilities included in this certification criterion and align with our consistent use of the phrase “identified set of users” in every certification criterion where we intend for the same capability to be available. We explained that the purpose of this certification criterion is to provide certain users (“identified set of users”) with the ability to override normal access controls in the case of an emergency.

Comments. Almost all commenters that commented on this certification criterion expressed their support for the certification criterion as an unchanged certification criterion. One commenter recommended that organizations be afforded the opportunity to define their solution for emergency access based on their organizational security policy, which may differ from the certification criterion and testing procedures for emergency access. Another commenter suggested that we create a more specific requirement because the current requirements are ambiguous and do not provide enough guidance to EHR technology developers.

Response. We appreciate the support expressed by many commenters and are finalizing this certification criterion as proposed. With respect to the two comments expressing alternative options for certification, we believe these comments represent the opposite ends of the continuum we seek to balance and manage when we adopt a certification criterion. If the certification criterion was too specific, the capability provided by a Complete EHR or EHR Module may not be able to accommodate various organizational implementations. If not specific enough, EHR technology developers could include significantly different capabilities. The clarifying language provided in the Proposed Rule and recited above as well as our prior responses to comments included in the S&CC July 2010 Final Rule (75 FR 44617) for the 2011 Edition version of this certification criterion provide ample specificity for EHR technology developers. They also include for the benefit of commenters the citation to the HIPAA Security Rule requirement on which this certification criterion is modeled (68 FR 8355).

• Integrity

We proposed an “integrity” certification criterion at § 170.314(d)(8) that was consistent with the HITSC's recommendation. We also proposed to remove the capability to detect changes to an audit log because we proposed to add that capability to the proposed certification criterion for “auditable events and tamper resistance” at § 170.314(d)(2). The 2011 Edition EHR certification criterion adopted at § 170.304(b) specifies that EHR technology must be able to create a message digest in accordance with the standard specified at § 170.210(c). The adopted standard is: “A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1)) * * * must be used to verify that electronic health information has not been altered.” We stated in the Proposed Rule that, after consultation with NIST, we understood that the strength of a hash function in digital signature applications is limited by the length of the message digest and that in a growing number of circumstances the message digest for SHA-1 is too short for secure digital signatures (SHA-2 produces a 256-bit message digest that is expected to remain secure for a long period of time). We also stated that certain operating systems and applications upon which EHR technology may rely use SHA-1 and do not or cannot support SHA-2 at the present time. Therefore, we requested public comment on whether we should leave the standard as SHA-1 or replaces it with SHA-2.

Comments. Many commenters expressed support for the certification criterion as proposed. These commenters also recommended retaining the SHA-1 standard as a baseline because it is still relied upon in many instances. One commenter noted that the use of SHA-1 and its security strength is sufficient until digital signatures are broadly required in the industry. Other commenters supported moving to SHA-2 as a better long-term alternative.

One commenter did not support the use of “message logs” as the only method of protecting health information during transmission. The commenter contended that this certification criterion accounts for a single-vendor system and does not address self-developed systems that may use multiple platforms and internally-developed systems that are interfaced together. The commenter further contended that there are available methods to provide for secure and accurate exchange without limiting the solution to message logs. As such, the commenter suggested that this certification criterion should be modified to account for internal versus external transmissions.

Response. We thank commenters for their support. We are finalizing this certification criterion and its associated standard as proposed. We agree with commenters that EHR technology developers should migrate towards the use of SHA-2 because of its increased security strength, but only where possible and voluntarily. The SHA-1 standard included in this certification criterion serves as a floor and permits EHR technology to be certified if it includes hashing algorithms with security strengths equal to or greater than SHA-1. As expressed by many commenters, the use of SHA-1 is still relied upon in many instances. For example, the Applicability Statement for Secure Health Transport standard that we have adopted in other certification criteria requires that SHA-1 must be supported in addition to SAH-256. We decline to accept the commenter's recommendation to have the certification criterion differentiate between internal and external transmissions as that distinction is not necessary for the purposes of certification and determining whether EHR technology can perform this capability according to the adopted standard. The capability's subsequent use for internal and/or external transmissions, as the commenter advocates, is up to the EP, EH, and CAH to determine in accordance with its organizational policies. As a final note, we seek to call to readers' attention that NIST has superseded FIPS 180-3 with FIPS 180-4. The changes in FIPS 180-4 are limited in scope and do not affect the approach we have expressed in the standard we adopted for this certification. Therefore, in order keep the regulation current with this recent publication we have modified the regulation text to refer to FIPS 180-4 instead of 180-3.

b. Unchanged Certification Criteria Without Refinements

We proposed to include the following unchanged certification criteria in the 2014 Edition EHR certification criteria without any substantial refinements, except, where appropriate, replacing the terms “generate,” “modify,” and “retrieve” with “create,” “change,” and “access,” respectively. For the “accounting of disclosures” certification criterion, we specifically requested comments whether we should revise the criterion. We received public comments on all of the certification criteria. We discuss the public comments received and the adoption of these certification criteria as part of the 2014 Edition EHR certification criteria below.

• Accounting of Disclosures

We proposed to adopt the same optional “accounting of disclosures” certification criterion included in the 2011 Edition EHR certification criteria (§ 170.302(w)) as an optional certification criterion for the 2014 Edition EHR certification criteria (§ 170.314(d)(9)). We did, however, specifically request public comment on whether we should adopt a revised certification criterion. We noted that since publication of the S&CC July 2010 final rule, the HHS Office for Civil Rights (OCR) issued a proposed rule (76 FR 31426) addressing the changes required by section 13405(c) of the HITECH Act, including changes to the accounting of disclosure requirements under the HIPAA Privacy Rule. We expressed interest in knowing whether commenters believed that the 2014 Edition EHR certification criterion for “accounting of disclosures” should be revised to be a mandatory certification criterion. We also expressed interest in knowing whether commenters thought that the 2014 Edition EHR certification criterion should be revised to include capabilities that would more fully support an EP's, EH's, and CAH's ability to comply with the current HIPAA Privacy Rule accounting for disclosure requirements at 45 CFR 164.528. Additionally, we expressed interest in receiving input on whether, and what additional, changes to the certification criterion would be needed to support compliance with the proposed HIPAA Privacy Rule accounting for disclosure provisions, if they were to be adopted by final rule in substantially the same form as they were proposed. For those commenters that believed revisions were appropriate, we asked that their comments identify whether the certification criterion should be changed from optional to mandatory and identify the specific capabilities that the certification criterion should include and the rationale for including those capabilities.

Comments. Commenters overwhelmingly supported keeping this certification criterion as optional and without revision. Many commenters pointed to the significant amount of comments that were submitted on the “accounting of disclosures” proposed rule (76 FR 31426) issued by OCR, particularly the comments they characterized as expressing significant concern with the proposals in the proposed rule. Most commenters stated that this certification criterion must be fully aligned with the specifics of the “accounting of disclosures” final rule and suggested that ONC and OCR work together in this regard. A few commenters even suggested that we remove the certification criterion until a “accounting of disclosures” final rule is issued. A few commenters recommended that this certification criterion become mandatory and generally stated that it should be revised to include capabilities that would more fully support an EP's, EH's, and CAH's ability to comply with the current HIPAA Privacy Rule accounting for disclosure requirements. One commenter recommended that the specific capabilities that the “accounting of disclosures” certification criterion should be revised to include are: (1) The access report capability set forth in the proposed rule proposing to modify the HIPAA Privacy Rule's accounting for disclosures requirements; and (2) the universal accessibility of accounting of disclosures. Another commenter recommended that the certification criterion include a requirement to account for disclosures of protected health information, including release of information to third parties for care coordination, data-sharing and research purposes. Along these lines, a commenter recommended that EHR technology have the capability to document whether a patient has accepted or denied a disclosure agreement (e.g., for research purposes).

A commenter requested clarification regarding whether the data elements required to be recorded for accounting of disclosures be in structured format or free text. One commenter asked whether the part of the ASTM E2147-01 standard that deals with disclosures has applicability to this certification criterion and suggested that it should be applicable to this certification criterion.

Response. We thank commenters for their feedback. We are adopting this certification criterion as an unchanged certification criterion for the 2014 Edition EHR certification criterion at § 170.314(d)(9) and have continued to designate it as “optional.” After consideration of the comments received, we agree with those commenters that recommended we wait and consider how best to align this certification criterion with the provisions of an “accounting of disclosures” final rule issued by OCR. We appreciate the suggested revisions offered by commenters, but believe that alignment with an “accounting of disclosures” final rule will provide the most certainty and useful functionality for EPs, EHs, and CAHs, while also mitigating any EHR technology development and implementation burdens that may accrue through compliance with potential multiple adopted versions of this certification criterion.

We clarify for commenters that each disclosure that has been recorded must be done so in accordance with the standard at § 170.210(d) and must include the date, time, patient identification, user identification and the description of each disclosure. As to the commenter's question about whether this information could be captured in free text, we expect that date, time, patient identification, and user identification would be automatically recorded only by EHR technology. With respect to the description of each disclosure, we reiterate what we stated in the S&CC July 2010 Final Rule in response to this question (75 FR 44624). “As we discussed in the Interim Final Rule, we intended to leave Complete EHR and EHR Module developers with the flexibility to innovate in this area and to develop new solutions to address the needs of their customers. We anticipated that a `description of the disclosure' would, at the present time, be a free text field that would have included any information that could be readily and electronically associated with the disclosure. For example, we envisioned that some descriptive information could be included such as the words `treatment,' `payment,' or `health care operations' separately or together as a general category.”

The ASTM E2147-01 standard has not been adopted in whole or in part for this certification criterion and we decline to adopt any part of the ASTM E2147-01 standard for this certification criterion at this time. Consistent with our rationale above, we believe it is most appropriate to wait and consider the provisions of an “accounting of disclosures” final rule to be issued by OCR before making any revisions to this certification criterion.

• Advance Directives

Comments. The majority of commenters expressed support for this certification criterion as an unchanged certification criterion. More specifically, commenters stated that this certification criterion should include the capability to record whether a patient has an advance directive, but not require the EHR technology to demonstrate that the actual advance directive document is recorded as an electronic document in the EHR technology. A commenter recommended that this requirement be included for the ambulatory setting as well so that this data could be easily exchanged between EPs, EHs, and CAHs. One commenter suggested that EHR technology be required to provide user access to the advance directive. Another commenter suggested that EHR technology should provide patients with access to their advance directives and provide patients the capability to change the advance directive.

Some commenters recommended that the certification criterion be modified to accommodate scanned copies of advance directives as well as reconciliation and version control capabilities. Other commenters suggested that standard vocabulary was needed to describe and capture an advance directive, including in the Consolidated CDA. A few commenters suggested that we consider requiring EHR technology be capable of recording the type of advance directive (e.g., Intubation, Tube Feedings, Life Support) and the effective date/time periods for the advance directive. The commenters reasoned that, while the indication of an advance directive is not part of the summary of care record for MU, the Consolidated CDA that will be used for the 2014 Edition EHR certification criteria calls for an indication of the type of advance directive. Therefore, these commenters suggested this was an opportunity to encourage EHR technology developers to implement such functionality in conjunction with the Consolidated CDA functionality. Conversely, some commenters stated that it is not necessary to require specific codes for “types” of advance directives because they are not often collected and may vary from state to state.

A few commenters requested clarification on whether “yes” and “no” data fields constituted “structured” data. Another commenter requested clarification on whether structured data implied a Boolean indicator.

Response. We appreciate the support for the certification criterion as proposed and are adopting this certification criterion as an unchanged certification criterion for the 2014 Edition EHR certification criterion at § 170.314(a)(17). This certification criterion's scope focuses on the capabilities necessary to support MU, which requires the recording of whether a patient 65 years old or older has an advance directive. A patient's advance directive is not required to be available or accessible with EHR technology. Under MU, advance directive information is also not included in the summary care record, required to be provided after a patient's office visit, or required to be available for online viewing or downloading by a patient. Accordingly, while we appreciate the commenters' suggested modifications and inclusion of additional capabilities for this certification criterion (i.e., requiring this capability for the ambulatory setting, making the actual advance directive available in scanned or structured format, noting the type of advance directive, providing user or patient access to the advance directive and the ability to change the advance directive), we decline to make any revisions to this certification criterion at this time since such additional capabilities would be beyond those needed to support MU.

We clarify that EHR technology would only need to demonstrate that it can include an advance directive indicator and that the indicator is stored in the patient's record. The use of “yes” and “no” data fields may be one method for EHR technology to meet this certification criterion. A Boolean search capability based on patients with advance directives is not a requirement to meet this certification criterion.

• Medication List

Comments. The majority of commenters recommended that this certification criterion remain unchanged. Commenters reasoned that it is appropriate to be non-prescriptive related to standards for internal EHR functionality, while requiring the use of standards for health information exchange. Conversely, a few commenters suggested that we evaluate the applicability of standards for this certification criterion with one commenter suggesting the use of the RxNorm standard. These commenters suggested that this would lead to EPs, EHs, and CAHs having the capability of providing this information as structured data in an interoperable format. One commenter suggested that this certification criterion be modified to require that EHR technology be capable of providing a description of each medication's class and intended purpose. One commenter stated that EHR technology should support the import of medication lists from external sources, such as an HIE, for true longitudinal care across providers.

Response. We appreciate the support for the certification criterion as proposed and are adopting this certification criterion as an unchanged certification criterion for the 2014 Edition EHR certification criterion at § 170.314(a)(6). We believe that this certification criterion as adopted supports MU. Therefore, requiring EHR technology to be capable of providing a description of each medication's class and intended purpose is not necessary for certification. However, as we state elsewhere, EHR technology developers are free to include capabilities that go beyond certification requirements.

As discussed in other certification criteria, we have required the use of RxNorm in instances where EHR technology would be used to perform external transmissions (e.g., for a transition of care (§ 170.314(b)(2)). Additionally, we require the capability to reconcile a patient's medication list as part of the adopted “clinical information reconciliation” certification criterion at § 170.314(b)(4) and the receipt of RxNorm codes in a transition of care/referral summary should greatly facilitate this process. Thus, at this juncture, we do not believe it is necessary to require as a condition of certification that EHR technology natively record medications directly into RxNorm although such an approach may be more efficient and expeditious for some. We continue to remain cognizant of the potential burden that requiring a standard for this certification criterion could cause and continue to believe it is appropriate to provide EPs, EHs, and CAHs with the flexibility to internally record such information in a manner that includes the medication vocabularies with which they are familiar.

We note that in response to comments received on our use of the term “longitudinal care” in this certification criterion and in other certification criteria, we have replaced the term with the meaning we gave the term for the ambulatory and inpatient settings in the Proposed Rule. We refer readers to our discussion of the revised “problem list” certification criterion earlier in this preamble.

• Medication Allergy List

Comments. The majority of commenters recommended that this certification criterion remain unchanged. A couple of commenters suggested expanding to include all allergies, including food and substance allergies. The commenters reasoned that it was important to maintain lists of these allergies to prevent adverse reactions and other patient-safety events. These commenters also suggested referencing a standard such as RxNorm or UNII as applicable for these additional types of allergens. Another commenter specifically suggested that we require the use of RxNorm for this certification criterion. One commenter stated that EHR technology should support the import of medication allergy lists from external sources, such as an HIE, for true longitudinal care across providers.

Response. We appreciate the support for the certification criterion as proposed and are adopting this certification criterion as an unchanged certification criterion for the 2014 Edition EHR certification criterion at § 170.314(a)(7). While we appreciate the commenters' suggestion to expand the capabilities included in this certification criterion to cover additional types of allergens and patient safety is one our utmost concerns, such additional capabilities would be beyond those needed to support MU. Therefore, although we decline to adopt this recommendation, we continue to encourage EHR technology developers to include capabilities that may go beyond certification requirements, particularly where that may improve patient safety. Similar to the rationale provided in our response above regarding the “medication list” certification criterion, we decline to require as a condition of certification that EHR technology natively record medication allergies directly into RxNorm. We have however, in response to these comments and other comments received on the other certification criteria that reference medication allergies, adopted RxNorm for instances where this data would be included in a CCDA formatted document.

We note that in response to comments received on our use of the term “longitudinal care” in this certification criterion and in other certification criteria, we have replaced the term with the meaning we gave the term for the ambulatory and inpatient settings in the Proposed Rule. We refer readers to our discussion of the revised “problem list” certification criterion earlier in this preamble.

12. Gap Certification

“Gap certification” is “the certification of a previously certified Complete EHR or EHR Module(s) to: (1) [a]ll applicable new and/or revised certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results of a NVLAP-accredited testing laboratory; and (2) [a]ll other applicable certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results used to previously certify the Complete EHR or EHR Module(s).” We stated in the Permanent Certification Program final rule (76 FR 1307) and reiterated in the Proposed Rule that gap certification will focus on the difference between certification criteria that are adopted through rulemaking at different points in time. We discuss in section III.A of this preamble, as we did in the Proposed Rule, the factors we would consider in determining whether a 2014 Edition EHR certification criterion is “new” or “revised.” Examples of new certification criteria are the “secure messaging” certification criterion at § 170.314(e)(3) and the “electronic medication administration record” certification criterion at § 170.314(a)(17). An example of a revised certification criterion is the “CDS” certification criterion at § 170.314(a)(8). This certification criterion is “revised” because it add capabilities to the certification criteria for CDS that were previously adopted at §§ 170.304(e) and 170.306(c). An example of a certification criterion that we would consider both new and revised is the “e-prescribing” certification criterion at § 170.314(b)(3). This certification criterion is a revised certification criterion for the ambulatory setting, but would be considered a new certification criterion for the inpatient setting.

We stated in the Proposed Rule that for a Complete EHR or EHR Module that was previously certified to the 2011 Edition EHR certification criteria to be certified to the 2014 Edition EHR certification criteria, test results from a NVLAP-accredited testing laboratory would be required for all of the applicable new and revised certification criteria that are adopted. For the certification criteria that we identified as unchanged in the Proposed Rule, we stated that test results that were used previously to certify a Complete EHR or EHR Module to the 2011 Edition EHR certification criteria could be used to certify the Complete EHR or EHR Module to the corresponding 2014 Edition EHR certification criteria that we identified. We provided an illustration of how gap certification would work with our proposed 2014 Edition EHR certification criteria. An EHR Module that was previously certified to the “CPOE” and “drug-drug, drug-allergy interaction checks” certification criteria (i.e., previously tested and certified to § 170.304(a) or § 170.306(a) and § 170.302(a)) would not need to be retested to the “CPOE” certification criterion at § 170.314(a)(1) because this criterion has been identified as an unchanged certification criterion. However, the previously certified EHR Module would need to be retested for “drug-drug, drug-allergy interaction checks” because the “drug-drug, drug-allergy interaction checks” certification criterion at § 170.314(a)(2) has been identified as a revised certification criterion as part of the 2014 Edition of EHR certification criteria.

Comments. Multiple comments expressed support for our gap certification policy and the identification of unchanged certification criteria for the purposes of gap certification. Commenters noted that gap certification would increase the efficiency of the certification process and reduce costs for EHR technology developers and EPs, EHs and CAHs. A commenter requested clarification about whether a Complete EHR or EHR Module previously certified to the 2011 Edition EHR certification criteria would need to maintain the same scope of certification to be able to be “gap-certified” to the 2014 Edition EHR certification criteria, and whether pursuing a different scope of certification would require a “new” certification even if the same criteria are part of the scope of the 2014 Edition certification. This same commenter also noted that for some Complete EHRs and EHR Modules certified to unchanged certification criteria, they would still need to be tested to § 170.314(g)(2). Another commenter requested that ONC provide ONC-ACBs with gap certification guidance so that there is consistency in the implementation of the policy.

Response. We appreciate commenters support for gap certification. We agree with commenters that gap certification would be a less costly and more efficient certification option for EHR technology developers. We assume that by “same scope of certification,” the commenter meant whether a Complete EHR or EHR Module previously certified to the 2011 Edition EHR certification criteria could only be certified to the corresponding 2014 Edition EHR certification criteria. We clarify that a previously certified Complete EHR or EHR Module would not need to maintain the same scope of certification to be gap certified. For example, it would be impossible for a Complete EHR designed for the ambulatory setting presented for certification to the 2014 Edition EHR certification criteria to be the same in scope as a Complete EHR previously certified to the 2011 Edition EHR certification criteria because the 2014 Edition EHR certification criteria applicable to the ambulatory setting include new certification criteria adopted by the Secretary. Similarly, an EHR Module presented for certification to the 2014 Edition EHR certification criteria may be certified to more certification criteria than it was previously certified to the 2011 Edition EHR certification criteria and still be gap certified to the unchanged certification criteria it includes. Along these lines, as referenced by a commenter, EHR Modules certified to the 2014 Edition EHR certification criteria that include a capability that supports a MU percentage-based measure will need to be certified to either the new certification criterion at § 170.314(g)(1) or the revised certification criterion at § 170.314(g)(2) independent of the designation (i.e., new, revised, or unchanged) of the certification criterion that includes the capability that supports a MU percentage-based measure (to note, Complete EHRs would need to be certified to § 170.314(g)(2)). As stated in the Permanent Certification Program final rule (76 FR 1308), in all of these examples, an ONC-ACB would issue a certification to the entire Complete EHR or EHR Module it certifies to the 2014 Edition EHR certification criteria. We also provided a detailed explanation of gap certification and initial guidance in the Permanent Certification Program final rule (76 FR 1307-08) and intend to provide additional guidance as necessary to facilitate a consistent implementation of gap certification by ONC-ACBs.

For the purposes of gap certification, table 3 below provides a crosswalk of unchanged 2014 Edition EHR certification criteria to the corresponding 2011 Edition EHR certification criteria. This table has been revised compared to the table included in the Proposed Rule (77 FR 13860-61). We have removed from the table both the certification criteria that have now been adopted as revised certification criteria and those that were not adopted as part of the 2014 Edition EHR certification criteria. The proposed unchanged certification criteria that have been adopted as revised certification criteria are: “drug-formulary checks” (§ 170.314(a)(10)); “vital signs, body mass index, and growth charts” (§ 170.314(a)(4)); “smoking status” (§ 170.314(a)(11)); “patient lists” (§ 170.314(a)(14)); and “patient reminders” (§ 170.314(a)(15))[now combined and collectively referred to as “patient list creation” (§ 170.314(a)(14)) in this final rule]. The certification criteria that were proposed as part of the 2014 Edition EHR certification criteria, but were not adopted are “public health surveillance” (§ 170.314(f)(3)) and “reportable laboratory tests and values/results” (§ 170.314(f)(5)). We also note, as identified in table 3, that for the certification criterion at § 170.314(b)(5) (Incorporate laboratory tests and values/results), EHR technology designed for an ambulatory setting would need to be tested by a NVLAP-accredited testing laboratory because such EHR technology must meet new standards and implementation specifications, while the capabilities required for the inpatient setting are unchanged.

13. Disability Status

In the Proposed Rule, we solicited comments on whether EHR technology certified to the 2014 Edition EHR certification criteria should be capable of recording the functional, behavioral, cognitive, and/or disability status of patients (collectively referred to as “disability status”). We stated that the recording of disability status could have many benefits. It could facilitate provider identification of patients with disabilities and the subsequent provision of appropriate auxiliary aids and services for those patients by providers. It could promote and facilitate the exchange of this type of patient information between providers of care, which could lead to better quality of care for those with disabilities. The recording of disability status could also help monitor disparities between the “disabled” and “nondisabled” population.

We asked commenters whether there exists a standard(s) that would be appropriate for recording disability status in EHR technology. We pointed commenters to the standard for disability status approved by the Secretary for use in population health surveys sponsored by HHS and standards under development as part of the Standards and Interoperability Framework and the Continuity Assessment Record and Evaluation (CARE) assessment tool. We asked commenters whether these standards or any other standards would be appropriate for recording disability status in EHR technology.

We requested that commenters consider whether the recording of disability status should be a required or optional capability that EHR technology would include for certification to the 2014 Edition EHR certification criteria. We also requested that commenters consider whether the recording of disability status should be part of a Base EHR definition and included in a separate certification criterion or possibly the “demographics” certification criterion (§ 170.314(a)(3)). Last, we requested that commenters consider whether disability status recorded according to the standard should also be included in other certification criteria such as “transitions of care—incorporate summary care record” (§ 170.314(b)(1)), “transitions of care—create and transmit summary care record” (§ 170.314(b)(2)), “view, download and transmit to 3rd party” (§ 170.314(e)(1)), and “clinical summaries” (§ 170.314(e)(2)).

Comments. Commenters stated that there could be many benefits from the recording of disability status, such as the ones we described in the Proposed Rule. Commenters, however, expressed a significant lack of consensus on how to define disability status. Some commenters stated that “functional status,” is a more precise, comprehensive, and objective measure for describing the patient's clinical status. Other commenters stated that functional, cognitive, and disability status were distinct. One commenter suggested that we use the definition for “disability” identified in the Americans with Disabilities Act Amendments Act. A couple of commenters stated that there is no commonly accepted definition that could be used for our purposes.

Commenters also expressed concern over disability status being improperly defined, accurately recorded for a patient, and shared with others. A few commenters stated that there may be legal ramifications for patients or providers if the term “disability” is erroneously applied to a patient record as benefit determinations, entitlement to protected class status, and/or reimbursement could be affected. Another commenter noted concerns that the accuracy of the data could differ if the definition has subjective components and information is entered by multiple providers. A couple of commenters noted that disability status is not required for all patients or all specialties and should not be required in any reports (they noted that when needed, it will be sent as part of existing information). A couple of other commenters noted privacy and security concerns with sharing and reporting patient disabilities.

Commenters made a variety of recommendations regarding how “disability status” should be incorporated into the 2014 Edition EHR certification criteria. Commenters suggested including it as its own certification criterion, in and not in the “demographics” certification criterion, in all the certification criteria we mentioned in the Proposed Rule, and in the Base EHR definition. A few commenters also suggested that disability status could be captured in patient problem lists. One commenter suggested that if the recording of disability status is part of certification, then its recording should be optional.

Commenters gave varying views on the availability of appropriate standards and tools for capturing disability standards. Many commenters also expressed views that standards were not mature enough. Commenters suggested the Consolidated CDA be used for capturing cognitive and functional status, but noted that it was not yet mature enough for capturing other kinds of disabilities in a structured way. Some of these commenters suggested that the Consolidate CDA could serve as a “stepping stone.” A commenter suggested the collection of disability status data using the American Community Survey (ACS) questions on disability (these constitute the 6-question data collection disability standard used for population health surveys sponsored by HHS). Another commenter noted that the World Health Organization created an entire framework and vocabulary standard—the International Classification of Functioning, Health and Disability (ICF)—to capture and record functional and disability status. A commenter also suggested SNOMED CT® (used in the SSA CCD) or ICD-10-CM/PCS could have potential for use in recording disability status. Multiple commenters suggested that the CARE assessment tool should be used. However, one commenter stated that the CARE tool in its current form will not accurately document medical severity, functional status, and other factors related to outcomes as the questions lack sensitivity and, therefore, the type of information about the patient needed to measure outcomes and severity is not being collected by this instrument. A few other commenters stated that there is no current standard(s) appropriate for recording disability status in EHR technology at this time. These comments suggested a new standard be developed using the CARE assessment tool and ICF Core Sets to help guide the development of the standard. Another commenter suggested that new standards could be developed for including this as a separate section such as “disability history” (alongside “social history”).

Response. We appreciate the responses and various recommendations from commenters. Although commenters did not express consensus around a single definition or standard for recording or transmitting “disability status,” commenters generally provided a framework from which forward progress on this topic can be made. Commenters noted that benefits could be realized when such information is captured. Commenters were also clear that we should not use a single term, such as “disability status,” to capture both demographics (i.e., impairments that are generally permanent and do not change over time) and clinical information (i.e., clinically assessed impairments that may improve, worsen, or go away over time). Commenters did suggest that functional and cognitive status be used for clinical information and that standards were available to use for both capture and transmission.

We acknowledge that the Proposed Rule's use of a single term, “disability status,” was too imprecise to represent at least the two different concepts expressed by commenters. As shown by the diversity in commenters' views and considering that, in most cases, a standard defines the information that must be recorded, we believe that further stakeholder input is necessary before EHR technology is required as a condition of certification to be capable of recording a patient's disability(ies) in a specific standard. As a starting point, we ask that stakeholders consider whether the recently developed 6-question “data standard for disability status” adopted for population health surveys sponsored by HHS or any other standard would be appropriate for requiring the recording of the types of impairments identified in the 6-question survey standard (e.g., “are you deaf or do you have serious difficulty hearing”). Unlike clinical cognitive or functional status assessments, this information can be used by health care providers to better accommodate and respond to individual patient needs. In turn, we will ask the HITPC and HITSC to consider during their deliberations on recommendations for MU Stage 3 that they review the 6-question “data standard for disability status” and any other relevant standard for the recording of disabilities.

As a current means of moving forward, we believe we can build on commenters' recommendations for transmitting cognitive and functional status. We agree with commenters that we should consider “disability status,” at minimum, in terms of functional and cognitive status. We also agree with commenters that the Consolidated CDA can serve as a “stepping stone.” The Consolidated CDA can capture functional and cognitive status as well as other “disability statuses.” Therefore, considering that the “transitions of care” certification criteria already require that EHR technology be capable of using the Consolidated CDA, we are also requiring that EHR technology be capable of including patient data on functional and cognitive status in order to align with inclusion of this information by CMS for transitions of care/referrals in the Stage 2 final rule.

Overall, we believe these initial steps will put us on a path forward using EHR technology to improve the quality of care for those patients with disabilities.

B. Redefining Certified EHR Technology and Related Terms

1. Proposed Revisions to the Definition of Certified EHR Technology

Based on feedback ONC and CMS received on the CEHRT definition from numerous stakeholders, including EPs, EHs, CAHs, EHR technology developers, and multiple associations representing these and other stakeholders and the recommendations of the HITSC, we proposed a more flexible CEHRT definition. Overall, a majority of stakeholders and the HITSC recommended a definition that would provide EPs, EHs, and CAHs the flexibility to have or possess only the EHR technology certified to adopted certification criteria that they would need/use to demonstrate MU. Accordingly, consistent with the instruction of the President's Executive Order (EO) 13563 to identify and consider regulatory approaches that reduce burden and maintain flexibility for the public, we proposed to revise the CEHRT definition at § 170.102. The proposed revised CEHRT definition was broken into two parts based on years of applicability.

For FYs/CYs Up to and Including 2013

For the first part of the revised definition of CEHRT that would apply for the FYs/CYs up to and including 2013, we proposed two specific changes. The first was to include a reference to “the 2011 Edition EHR certification criteria” in order to make clear that these are the certification criteria previously adopted by the Secretary at §§ 170.302, 170.304, and 170.306. We stated that this clarification was necessary because with the adoption of the 2014 Edition EHR certification criteria in this final rule at § 170.314, there would be two “editions” of adopted certification criteria in the CFR. Both the 2011 Edition and the 2014 Edition EHR certification criteria must be effective at the same time for EHR technology to continue to be tested and certified to the 2011 Edition EHR certification criteria and so EHR technology developers may begin to have their EHR technology tested and certified to the 2014 Edition EHR certification criteria.

The second change we proposed would allow EPs, EHs, and CAHs to satisfy the definition by having EHR technology certified to the 2014 Edition EHR certification criteria that are “equivalent” to the 2011 Edition EHR certification criteria. We stated that we would consider ”equivalent” certification criteria to be those proposed 2014 Edition EHR certification criteria that include capabilities that are at least equal to the capabilities included in certification criteria that were previously adopted as part of the 2011 Edition EHR certification criteria. For further clarity, we provided a cross-walk between 2011 Edition EHR certification criteria and what we considered equivalent proposed 2014 Edition EHR certification criteria (77 FR 13863). We stated that this revision was necessary to permit EPs, EHs, and CAHs with the flexibility to adopt or upgrade to EHR technology certified to the 2014 Edition EHR certification criteria without adversely affecting the certified status of previously adopted EHR technology or their ability to meet the definition of CEHRT. With respect to CQMs, however, we noted that EPs, EHs, and CAHs who adopt or upgrade to EHR technology certified to the 2014 Edition EHR certification criteria during FY/CY 2012 or FY/CY 2013 must ensure that their CEHRT will enable them to report on the CQMs required for the 2012 and 2013 EHR reporting periods. More specifically, the EHR technology required to electronically capture, calculate, and report CQMs during those years will be different than the EHR technology needed to do the same in FY/CY 2014 and subsequent years because CMS did not propose to change the set of CQMs on which EPs, EHs, and CAHs would need to report until FY/CY 2014. Therefore, we clarified that EPs, EHs, and CAHs will need to have EHR technology certified to the CQM certification criteria included in the 2011 Edition EHR certification criteria to be able to report on the CQMs required for the 2012 and 2013 EHR reporting periods. For further guidance, we encouraged EPs, EHs, and CAHs to read CMS' Stage 2 proposed rule to understand the CQMs that would need to be reported for a given EHR reporting period.

For FY and CY 2014 and Subsequent Years

We stated that the second part of the revised definition of CEHRT that would apply beginning with FY/CY 2014 would accomplish four main policy goals:

1. It defines CEHRT in plain language and makes the definition and its requirements readily understandable to EPs, EHs, CAHs, EHR technology developers, and other stakeholders.

2. It continues the progress towards increased interoperability requirements for EHR technology by requiring all CEHRT to have, at a minimum, the capabilities included the Base EHR definition.

3. It accounts for stakeholder feedback, which expressed that the definition should align more closely with MU requirements under the EHR Incentive Programs.

4. It follows the tenets expressed in EO 13563 by reducing regulatory burden, providing more flexibility to the regulated community, and making regulatory text more understandable.

We reminded stakeholders in the Proposed Rule that the definition of CEHRT does not speak to just one audience. EPs, EHs, and CAHs may view the definition of CEHRT in a way that informs them of the EHR technology that they must possess to accomplish MU. Alternatively, EHR technology developers may see the definition differently and in a way that informs them of the potential market demand for certain EHR technologies and, more specifically, the EHR technology that their customers will need to achieve MU.

We affirmed in the Proposed Rule that only two types of EHR technology, Complete EHRs and EHR Modules, can be certified under the “ONC HIT Certification Program.” However, we pointed out that under the revised definition of CEHRT that we proposed for FY/CY 2014 and subsequent years, an EP, EH, or CAH could meet the definition with a certified Complete EHR, a single certified EHR Module, a combination of separately certified EHR Modules, or any combination of the three. For example, an EHR technology developer could get an EHR Module certified that would subsequently enable an EP, EH, or CAH to have EHR technology that would satisfy the proposed revised definition of CEHRT. Alternatively, an EP, EH, or CAH could use a certified Complete EHR and a certified EHR Module to meet the proposed revised definition of CEHRT.

We provided the following scenarios in the Proposed Rule to demonstrate the added flexibility the proposed revised CEHRT definition could provide EPs, EHs, and CAHs. One scenario of added flexibility would be where an EP, EH, or CAH qualifies for an exclusion for a MU objective and associated measure. With respect to this scenario, we expect that this new flexibility would apply in situations where the MU objective and associated measure would not be applicable to the EP, EH, or CAH. In most cases, we expect this would occur for EPs based on their scope of practice and would be significantly less likely to occur for most EHs and CAHs. For example, a dentist will never give immunizations and, thus, would not need EHR technology with the capability to submit immunization information to immunization registries in order to satisfy the proposed revised definition of CEHRT. As another example, and as noted earlier, an EP may not have any office visits during an EHR reporting period and thus may qualify for the exclusion for the MU objective and associated measure requiring clinical summaries to be provided to patients for each office visit. Under the proposed revised definition of CEHRT, the EP would not need to have EHR technology that supports this capability. The second scenario would be where an EP, EH, or CAH is able to and has chosen to defer a MU “menu set” objective and associated measure for a particular stage of MU. In such a case, the EP, EH, or CAH would not necessarily need to have EHR technology with the capability to meet the menu set objective and associated measure in order to have EHR technology that satisfies the proposed revised definition of CEHRT. Ultimately, under the proposed revised definition of CEHRT for FY/CY 2014 and subsequent years, the EP, EH, and CAH would be responsible for ensuring that they have the necessary EHR technology to meet the Base EHR definition and support the MU objectives and measures that they seek to achieve under the EHR Incentive Programs. This means that EPs, EHs, and CAHs could run the risk of not having sufficient CEHRT to support their achievement of MU if, for example, they turn out not to be able to exclude a MU objective and measure as anticipated or they end up needing to satisfy a menu objective and measure that they originally expected to defer.

Having offered these examples of the added flexibility the proposed revised definition of CEHRT for FY/CY 2014 and subsequent years could provide, we also emphasized that under the proposed revised definition, all EPs, EHs, and CAHs must have EHR technology certified under the ONC HIT Certification Program to the 2014 Edition EHR certification criteria that meets the Base EHR definition as defined in the Proposed Rule. For example, even if an EP could claim an exclusion from the MU objective and associated measure for CPOE, he or she would still need to have EHR technology that has been certified to the CPOE certification criterion adopted by the Secretary because this capability would be included in the Base EHR definition.

After consultation with CMS, we determined that it would be least confusing and burdensome for EPs, EHs, CAHs, and EHR technology developers if our revised definition would apply beginning with the EHR reporting periods that will occur in FY/CY 2014. We stated that this approach would account for the proposed start of MU Stage 2 in FY/CY 2014; the policy change we have made related to the Base EHR definition; the time it would take EHR developers to update their EHR technology to meet the proposed new and revised certification criteria and have the EHR technology tested and certified to those criteria; and the time it would take EPs, EHs, and CAHs to subsequently implement EHR technology certified to the 2014 Edition EHR certification criteria. We requested public comment on alternative approaches that would provide equivalent simplicity and flexibility for EPs, EHs, and CAHs, as well as EHR technology developers, but that would still meet our programmatic goals and timelines.

We clarified and emphasized in the Proposed Rule that the revised definition of CEHRT would apply for all EPs, EHs, and CAHs, regardless of whether they are in Stage 1 or Stage 2 of MU. For example, EPs, EHs, and CAHs that are in Stage 1 or Stage 2 of MU for the EHR reporting periods in FY/CY 2014 would need to meet the revised definition of CEHRT (which includes the Base EHR definition).

Comments. Commenters expressed appreciation and agreement with the added flexibility the proposed revised CEHRT definition provided EPs, EHs, and CAHs. The majority of commenters, however, expressed concern that the time available between the publication of this final rule and the proposed compliance dates (October 1, 2013 for EHs and CAHs and January 1, 2014 for EPs) for the revised CEHRT definition that would apply beginning with FY/CY 2014 would be insufficient. Commenters stated that there would not be sufficient time for developing, testing, and certifying EHR technologies to the 2014 Edition EHR certification criteria and subsequently implementing these EHR technologies in the healthcare environments of all EPs, EHs, and CAHs that intend to participate in the EHR Incentive Programs in FY/CY 2014. EHR technology developers suggested a minimum of 15 months is necessary from the availability of testing and certification for EHR technology to the 2014 Edition EHR certification criteria if all EHs must have CEHRT that meets the CEHRT definition for FY/CY 2014 on October 1, 2013.

Commenters suggested various alternatives to our proposed revised CEHRT definition and the CMS proposed EHR reporting periods in FY/CY 2014. These alternative proposals suggested ways to provide additional flexibility and reduce burden for EHR technology developers, EPs, EHs, and CAHs in complying with the proposed revised CEHRT and meaningful use requirements. Some commenters suggested permitting EPs, EHs, and CAHs to meet the revised CEHRT definition for FY/CY 2014 at any time during their Stage 2 EHR reporting period in 2014. This would essentially give EHs and CAHs until September 30, 2014, and EPs until December 31, 2014. Other commenters suggested a shorter EHR reporting period for EPs, EHs, and CAHs in their first year of MU Stage 2, such as a 90-day or 180-day EHR reporting period. Commenters stated this would be similar to how MU Stage 1 was implemented. Some commenters suggested permitting EPs, EHs, and CAHs to use EHR technology certified to the 2011 Edition EHR certification criteria until at least FY/CY 2015. A few commenters suggested that we directly correlate the definition of CEHRT with the MU stage. The commenters suggested that an EP, EH, or CAH would only need to have EHR technology that could support the MU stage they were attempting to achieve, such as EHR technology certified to the 2011 Edition if they were attempting to achieve MU Stage 1. The commenters also suggested that it should be optional for EPs, EHs, and CAHs to use EHR technology certified to the 2014 Edition in Stage 1.

A few commenters suggested an approach within the framework of our proposed revised CEHRT definition. These commenters suggested making the flexibility provided by our proposed revised CEHRT definition for FY/CY 2014 and subsequent years available during FY/CY 2012 and 2013. In particular, one commenter suggested that we revise the first part of the proposed CEHRT definition (applicable through FY/CY 2013) to provide EPs, EHs, and CAHs with the option of meeting a CEHRT definition similar to the definition for FY/CY 2014 and subsequent years. The commenter suggested this could be achieved by revising the CEHRT definition for FY/CY 2013 to include a Base EHR definition based on the 2011 Edition EHR certification criteria or by permitting the use of EHR technology in FY/CY 2013 that meets the CEHRT definition for FY/CY 2014 and subsequent years. The commenter stated that we could add flexibility by permitting an EP, EH, or CAH to use either option in lieu of our proposal that would limit them to only being able to use EHR technology certified to all of the applicable 2011 Edition EHR certification criteria or equivalent 2014 Edition EHR certification criteria. The commenter identified, however, that if we adopt an approach allowing EPs, EHs, and CAHs to meet the proposed revised CEHRT definition for FY/CY 2014 and subsequent years in FY/CY 2013, it would create a potential inconsistency with respect to CQMs. More specifically, the commenter stated that such an approach would require an EP, EH, or CAH who wanted to adopt only 2014 Edition EHR technology to still have 2011 Edition EHR technology that could calculate the CQMs required for the EHR reporting periods in 2013. To address this alignment issue, the commenter recommended that EPs, EHs, and CAHs be permitted to use 2014 Edition EHR technology and attest in FY/CY 2013 using the CQMs designated for the 2014 EHR reporting period (and that would be part of their 2014 Edition EHR technology) in lieu of the other CQM reporting requirements for FY/CY 2013.

Response. We appreciate commenters' support for our proposed revised CEHRT definition. We understand the concerns expressed by commenters regarding time constraints and the steps needed for EPs, EHs, and CAHs to achieve compliance with the proposed revised CEHRT definition for FY/CY 2014. We believe with the timely publication of this final rule and the steps taken by CMS to add flexibility to the EHR reporting periods in FY/CY 2014, there will be sufficient time for all EPs, EHs, and CAHs that intend to participate in the EHR Incentive Programs in FY/CY 2014 to adopt and implement EHR technology that meets the CEHRT definition. The recommendations commenters made related to MU Stage 2 timing fall within the purview of CMS and the EHR Incentive Programs (i.e., length of EHR reporting periods and when EPs, EHs, and CAHs must possess CEHRT in relation to the EHR reporting periods). However, we have discussed the recommendations related to the length of EHR reporting periods with CMS, and CMS has determined to adopt three-month quarter EHR reporting periods in FY/CY 2014. This will provide additional time for EHR technology developers as well as give EPs, EHs, and CAHs up to an additional 9 months to adopt EHR technology that meets the revised CEHRT definition for FY/CY 2014.

We decline to accept commenters' suggestions about correlating “editions” of certification criteria with MU stages (i.e., 2011 Edition with Stage 1 and 2014 Edition with Stage 2), permitting the use of EHR technology certified to the 2011 Edition EHR technology through FY/CY 2015, or making the use of EHR technology certified to the 2014 Edition EHR certification criteria optional for those EPs, EHs, or CAHs participating in MU Stage 1. While these approaches could assuage commenters' timing concerns, they do not account for the fact that such a policy decision would have significant long-term consequences with respect to accelerating electronic health information exchange and interoperability. For example, as CMS illustrated in the Stage 2 proposed rule (77 FR 13703) and again in the Stage 2 final rule published elsewhere in this issue of the Federal Register, its policy remains that an EP, EH, and CAH will begin demonstrating meaningful use according to the Stage 1 criteria. Thus, if we implemented an approach of certifying EHR technology to MU stages (without a cutoff date), an EP, EH, and CAH could participate in MU Stage 1 well into the future with EHR technology certified to the 2011 Edition EHR certification criteria. Similarly, in a scenario where all three anticipated MU stages are in effect at the same time, EPs, EHs, and CAHs would all have different EHR technologies certified to different functional and interoperability capabilities. Such an outcome could potentially create a disparity among meaningful EHR users just because of the EHR technology they used to demonstrate MU and would serve as a limiting step for the adoption of more advanced capabilities for patient care, engagement, and safety. Moreover, this suggestion does not account for how confusing or challenging it could potentially be in the scenario where different EPs in a group practice are meeting different MU stages during an EHR reporting period nor does it appear to account for how feasible it would be for EHR technology developers to simultaneously support EHR technologies certified to different functional and interoperability capabilities for the time spans necessary. Alternatively, we believe, as we have finalized, that it is simpler for EPs, EHs, and CAHs, as well as their EHR technology developers, to have a single EHR technology edition upon which to reference and rely that can support any MU stage an EP, EH, or CAH seeks to achieve.

We agree with the commenter's detailed suggestion that we provide EPs, EHs, and CAHs with the option of using EHR technology that meets the proposed revised definition of CEHRT for FY/CY 2014 and subsequent years as soon as practicable. We are therefore modifying the first part of the proposed revised CEHRT definition to include this flexibility. In other words, for the EHR reporting periods in CY/FY 2012 and 2013, EPs, EHs, and CAHs may use technology that satisfies the CEHRT definition that will apply in FY/CY 2014 and subsequent years. We believe this is a better approach than retrospectively creating a CEHRT definition for FY/CY 2012 and 2013 based on the 2011 Edition EHR certification criteria, which would include a “2011 Edition” Base EHR definition. A revised CEHRT definition based on 2011 Edition EHR certification criteria for FY/CY 2012 and 2013 would only be effective for about a year and during a period of time when most EHR technology developers will be focused on designing and upgrading their EHR technology to meet the 2014 Edition EHR certification criteria and not on meeting a new “2011 Edition” Base EHR definition. More importantly, providing such flexibility earlier will support continued forward momentum towards increased electronic health information exchange and interoperability, as well as avoid the potentially unnecessary and duplicative adoption of 2011 Edition and 2014 Edition CEHRT in the same year. To this last point and to emphasize, if an EP, EH, or CAH does not take advantage of this new flexibility, then to meet the CEHRT definition for FY/CY 2012 and 2013, the EP, EH, or CAH will need to have EHR technology certified to all of the mandatory 2011 Edition EHR certification criteria (or equivalent 2014 Edition EHR certification criteria) for either the ambulatory or inpatient setting, as applicable. Last, with respect to the potential CQM misalignment the commenter raised, we understand CMS is adopting a policy to accommodate EPs, EHs, and CAHs that choose to use only 2014 Edition CEHRT in FY/CY 2013. For further explanation, we refer readers to CMS's final rule published elsewhere in this issue of the Federal Register.

Consistent with EO 13563, this additional flexibility and the original flexibility we proposed in the revised CEHRT definition should create additional regulatory efficiencies for EPs, EHs, and CAHs. Accordingly, the CEHRT definition will be revised at § 170.102 to reflect our proposal in the Proposed Rule with the additional modification to the first part of the definition discussed above. Table 4 below provides a crosswalk between the 2011 Edition EHR certification criteria and the 2014 Edition EHR certification criteria that we consider equivalent for the purposes of revised CEHRT definition for any Federal FY or CY up to and including 2013. Table 5 below provides a general overview of the revised CEHRT definition in relation to the stages of MU and the EHR reporting periods in FY/CY 2011 through 2014.

Comments. Some commenters expressed confusion about the impact of our proposed revised CEHRT definition on our “possession” policy.

Response. In FAQs 9-10-017-2 and 12-10-021-1, we describe our “possession” policy. We consider “possessing” (or “having”) Certified EHR Technology to include either the physical possession of medium on which a certified Complete EHR or combination of certified EHR Modules resides, or a legally enforceable right by an eligible health care provider to access and use, at its discretion, the capabilities a certified Complete EHR or combination of certified EHR Modules includes. An eligible health care provider may determine the extent to which it will implement or use these capabilities, which will not affect the provider's “possession” of Certified EHR Technology. In sum, prior to our revised CEHRT definition, an EP would need to possess EHR technology certified to all mandatory certification criteria for an ambulatory setting, and an EH or CAH would need to possess EHR technology certified to all mandatory certification criteria for an inpatient setting. As discussed above, this would still hold true for FY/CY 2012 and 2013, unless an EP, EH, or CAH chooses to use EHR technology that satisfies the FY/CY 2014 revised CEHRT definition for those years. As also noted in our discussion above, our revised CEHRT definition for FY/CY 2014 and subsequent years does limit the potential quantity of EHR technology EPs, EHs, and CAHs would need to “possess” to meet the CEHRT definition by requiring EPs, EHs, and CAHs to have only EHR technology that meets the Base EHR definition and would support the objectives and measures, and their ability to successfully submit the CQMs, for the MU stage that they seek to achieve.

We reiterate that an EP, EH, or CAH must continue to possess all of a certified Complete EHR or certified EHR Module (i.e., the capabilities for which certification is required) in order to receive the benefit of such certification. An EP, EH, or CAH cannot purchase or possess only “components” of a certified Complete EHR or certified EHR Module for the purposes of meeting the CEHRT definition. That is, unless independently certified, those “components” could not be used to meet the CEHRT definition. We refer commenters to our discussion in section III.B.4 of this preamble for further discussion related to certifications issued to Complete EHRs and EHR Modules. Also, we seek to make clear that the possession policy does not apply to those capabilities that an EHR technology developer may include with those that constitute a certified Complete EHR or certified EHR Module but for which certification is not required. In those instances, because these other included capabilities are not required for certification, an EP, EH, or CAH, would not necessarily need to possess them if the EHR technology developer would separately sell them. For more on this point, we refer commenters to our “EHR Technology Price Transparency” discussion in section IV.F of this preamble.

2. Base EHR Definition

In the Proposed Rule, we proposed to add to § 170.102 a new defined term, “Base EHR,” which would essentially serve as a substitute for the term “Qualified EHR” in the definition of CEHRT. We stated that the Base EHR definition would reflect all of the capabilities specified in the Qualified EHR statutory definition (that is, in section 3000(13) of the PHSA) plus the additional capabilities we proposed. We stated our intention to use the term “Qualified EHR” only as necessary and that its use would refer to the statutory definition unless otherwise indicated. We stated that the term “Base EHR” is more intuitive and conveys a plain language meaning. Moreover, we noted that the term “Qualified EHR” does not inherently convey the kinds of capabilities it includes. The term “Base EHR,” though, conveys that EHR technology includes certain fundamental capabilities. We also noted that the terms “qualified EHR” and “qualified EHR products” have been used by CMS in other programs and with a different meaning. Therefore, we concluded that the term “Base EHR” would be more easily understood and readily accepted by stakeholders.

We proposed that the Base EHR definition would include all the capabilities specified in the definition of a “Qualified EHR” under section 3000(13) of the PHSA. We also proposed that it would include an “extra” privacy and security capacity beyond what the Qualified EHR statutory definition required. Last, for clarity, we expressly listed the certification criteria to which an EP, EH, or CAH would need to make sure they had EHR technology certified in order to meet the Base EHR definition.

With respect to CQMs, we proposed that the Base EHR definition would include the certification criteria proposed at § 170.314(c)(1) and (2). We stated that the inclusion of § 170.314(c)(2) in a Base EHR ensures that EPs, EHs, and CAHs have the capability to incorporate all the data elements of, and calculate, at least one CQM. We stated that we anticipate that EHR technology developers will design EHR technology to incorporate the data elements for, and calculate, those CQMs they believe their EHR technology would need to include in order to support the providers to which they market their EHR technology. We acknowledged, however, that this approach could leave a void in the market for EHR technology that would support certain CQMs that EPs, EHs, and CAHs would need to report beginning in 2014. Accordingly, we sought comments on whether we should require certification to a set number of CQMs as part of certification to § 170.314(c)(2) and provided potential options for such as an approach.

For one option, we stated that we could require EHR technology designed for the ambulatory setting to be able to incorporate data elements and calculate a specific number of CQMs for each of the CQM “domains” proposed by CMS for EPs in the Stage 2 proposed rule. For EHR technology designed for the inpatient setting, we stated that we could require that the EHR technology be able to incorporate data elements and calculate a minimum threshold number of CQMs proposed by CMS for EHs and CAHs (e.g., 24 or 36). Conversely, we noted a potential challenge with this more explicit approach. In order for EPs, EHs, and CAHs to have EHR technology that would meet the definition of a Base EHR, their EHR technology developers could be required to demonstrate that their EHR technology can incorporate and calculate data for certain CQMs that may ultimately be irrelevant their customers, but nonetheless are necessary for the EHR technology to be certified.

We also requested comment on whether a Base EHR should include, in addition to § 170.314(c)(1) and (2), the CQM reporting certification criteria proposed at § 170.314(c)(3), which would enable a user to electronically create a data file for transmission of clinical quality measurement results to CMS.

With respect to the “privacy and security” certification criteria associated with the Base EHR definition's proposed capacity to protect the confidentiality, integrity, and availability of health information stored and exchanged, we proposed that the certification criteria should apply equally to both the ambulatory and inpatient settings. We specifically requested public comment on whether there should be a distinction between the ambulatory and inpatient settings for EHR technology certification to the privacy and security certification criteria.

Comments. Commenters expressed support for the Base EHR definition and how it serves as the foundation of the CEHRT definition. However, it was also evident from comments that many commenters misunderstood the proposed Base EHR concept. That is, they interpreted the Base EHR as a singular, independent type of EHR technology that could or would be separately certified.

One commenter suggested adding a capacity to the Base EHR definition, including the ability to produce a health record for legal, business, and disclosure purposes. Other commenters suggested including additional certification criteria in the Base EHR definition, such as new certification criteria addressing nutrition, diet, and allergies, or proposed certification criteria such as family health history, electronic notes, and automated measure calculation. Conversely, other commenters suggested removing certification criteria from the Base EHR definition. One of these commenters suggested limiting the certification criteria included in the Base EHR definition to the minimum number of certification criteria that would still be consistent and compliant with the HITECH Act. Multiple commenters suggested not including certification criteria with capabilities that would not be needed by all EPs, EHs, and CAHs to attempt to achieve MU. These commenters contended that this would increase flexibility for EPs, EHs, and CAHs as well as prevent them from incurring unnecessary costs by being required to purchase unwanted and unwarranted EHR technology. More specifically, commenters suggested removing the “vital signs” certification criterion (§ 170.314(a)(4)), the “drug-drug, drug-allergy interaction check” certification criterion (§ 170.314(a)(2)), and the “view, download, and transmit to 3rd party” certification criterion (§ 170.314(e)(1)). Commenters did, however, express support for keeping the privacy and security certification criteria in the Base EHR definition.

Commenters suggested that certification for privacy and security should be consistent across both ambulatory and inpatient settings. Commenters did, however, express confusion over how privacy and security certification criteria correlated with other certification criteria included in the Base EHR definition as well as other certification criteria in general. In particular, commenters asked whether the privacy and security capabilities needed to integrate with the capabilities included in the other certification criteria that are part of the Base EHR definition. If such integration is not required, commenters suggested that we consider requiring integration certification, particularly where the capabilities do not share a common security architecture. One commenter asked for confirmation as to whether EPs, EHs, and CAHs bear the responsibility for appropriately implementing the privacy and security capabilities included in the Base EHR definition, including with other capabilities of their CEHRT they use to attempt to achieve MU.

Commenters expressed concern about the proposed CQM certification criteria included, or considered for inclusion, in the Base EHR definition. In response to our specific request for comment, many commenters strongly recommended that, as part of the Base EHR definition, we require certification to all CQMs by the setting the EHR technology is designed to meet. As an alternative approach, commenters suggested establishing a list of CQMs for certification by practice setting (e.g., cardiology, pediatrics, etc.) and that the list(s) be part of the Base EHR definition. One commenter suggested that the “CQM reporting” certification criterion (§ 170.314(c)(3)) be included in the Base EHR definition as a means of providing additional flexibility for those wishing to contain the measures within their local data warehouse infrastructure. Conversely, another commenter stated that not all EPs, EHs, and CAHs will need the CQM reporting capability and that it should not be a certification criterion that is part of the Base EHR definition.

Response. We appreciate the support expressed for the Base EHR definition. First, we would like to make clear that the Base EHR definition must be satisfied in order to meet the CEHRT definition. Stated another way, EPs, EHs, and CAHs should treat the Base EHR definition like a checklist. In order to ultimately have EHR technology that meets the CEHRT definition, an EP, EH, or CAH must ensure that the EHR technology it has first meets the Base EHR definition. We also want to make clear that the Base EHR definition is not meant to convey our expectation that EHR technology must be separately certified as “a Base EHR.” Nor should it be interpreted to mean that EHR technology presented for certification must include all the certification criteria included in the Base EHR definition. Rather, similar to the revised CEHRT definition, the Base EHR definition can be satisfied through a number of ways: (1) A certified Complete EHR; (2) a single certified EHR Module; (3) a combination of separately certified EHR Modules; or (4) a combination of 1 through 3.

As stated above and in the Proposed Rule, we believe that the Base EHR definition should include the fundamental capabilities that any EP, EH, or CAH must have to demonstrate MU. Therefore, we are revising the proposed Base EHR definition to be more consistent with this approach.

First, we agree with commenters that certain certification criteria should be removed from the Base EHR definition. In particular, we have removed the certification criteria for “vital signs” (§ 170.314(a)(4)), “drug-drug, drug-allergy interaction check” (§ 170.314(a)(2)), and “view, download, and transmit to 3rd party” (§ 170.314(e)(1)). The capabilities specified by these three certification criteria are not necessarily needed by all EPs, EHs, and CAHs to support their achievement of MU.

Second, based on public comments, we have added one new certification criterion to the Base EHR definition. In response to our request for comments in the Proposed Rule and as discussed in section III.A.8 of this preamble, we received overwhelming feedback from EPs, EHs, and CAHs recommending that steps be taken to improve data portability. In response, we have adopted an initial data portability certification criterion and have included it in the Base EHR definition. We believe this initial data portability certification criterion directly aligns with the statutory capacity specified in the PHSA “Qualified EHR” definition “to exchange electronic health information with, and integrate such information from other sources.” We believe that by including this certification criterion in the Base EHR definition it will provide EPs, EHs, and CAHs with a mechanism to potentially expedite and enhance the migration of data from one EHR technology to another.

As noted above, the capabilities to capture (§ 170.314(c)(1)) and calculate (§ 170.314(c)(2)) CQMs remain part of the Base EHR definition. The ability to capture information relevant to health care quality aligns with statutory requirements for the Base EHR definition and we believe the ability to calculate CQMs through EHR technology is a fundamental capability all EPs, EHs, and CAHs should have to support their achievement of MU and their own continuous quality improvement. We have also amended our proposed Base EHR definition to require certification to no fewer than the minimum number of CQMs that an EP, EH, or CAH must report under the EHR Incentive Programs beginning in FY/CY 2014. Additionally, in light of the fact that CMS identified for EPs a subset of CQMs as a “recommended core,” we are separately requiring that to meet the Base EHR definition EPs must have EHR technology that has been certified to § 170.314(c)(1) and § 170.314(c)(2) for at least 6 CQMs from the “recommended core.” This final rule provision is meant to complement CMS' reporting requirements. We included this additional provision to support and highlight the “recommended core” CQMs prioritized by CMS. Further, we believe that by including this requirement in the Base EHR definition, EHR technology developers will seek to be certified to those “recommended core” CQMs that are most relevant to their customer base. As a result, EPs will then have the ability to report on some portion of the “recommended core” CQMs in support of CMS' CQM policy priorities.

In order for an EP to have EHR technology that meets the Base EHR definition, he or she would need to have EHR technology certified to § 170.314(c)(1) and § 170.314(c)(2) for no fewer than 9 CQMs that in total cover at least 3 domains and include at least 6 CQMs from the recommended “core set” for adult and pediatric populations as identified in the Stage 2 final rule published elsewhere in this issue of the Federal Register. In other words, of the minimum of 9 CQMs necessary to meet the Base EHR definition, at least 6 CQMs must be from the recommended core set identified by CMS, and altogether the 9 CQMs must cover at least 3 domains. In support of the Million Hearts initiative, we strongly urge EHR technology developers that serve customers for which NQF 0018 (Controlling High Blood Pressure) and NQF 0028 (Preventive Care and Screening: Tobacco Use: Screening and Cessation Intervention) would be applicable to include these two CQMs as part of the 6 recommended core set CQMs selected for certification. These two CQMs support this HHS priority and will be broadly leveraged through many Federal quality measurement programs.

Similarly, in order for an EH or CAH to have EHR technology that meets the Base EHR definition, it would need to have EHR technology certified to § 170.314(c)(1) and § 170.314(c)(2) for no fewer than 16 CQMs that cover at least 3 domains as identified in the Stage 2 final rule published elsewhere in this issue of the Federal Register. Additionally, by setting this minimum requirement, EHR technology developers will now need to ensure that their EHR technology includes the appropriate amount of CQMs if they seek to market their EHR technology as meeting the Base EHR definition.

We decline to establish a list of CQMs by practice specialty for certification. Considering the evolving nature of CQM specification and development, the applicability and availability of CQMs for different scopes of practice, and the varied customer bases of EHR technology developers, we believe that this option would be both infeasible and impractical at the present time. We also decline to include as part of the Base EHR definition, even for the inpatient setting, a requirement that EHR technology must be certified to all of the CQMs selected by CMS for the EHR Incentive Programs because of instances where this type of policy approach would require EPs (because of scope of practice) and EHs and CAHs (e.g., children's hospitals and hospitals without an emergency department) to have EHR technology certified for CQMs on which they would have no information relevant to health quality to report. We believe the policy we have established minimizes this type of situation from occurring. It also seeks to balance the potential burden faced by EHR technology developers to include and get their EHR technology certified to CQMs on which their customers would not necessarily have information relevant to health quality to report. We acknowledge that EHR technology developers get to choose the CQMs to which their EHR technology is certified and that those CQMs may not necessarily meet the needs of every EP, EH or CAH. We continue to believe, however, that EHR technology developers will be cognizant of their customers' needs and will in most cases select CQMs for certification that can broadly support their customer base. EPs, EHs, and CAHs can also consult the CMS MU Stage 2 final rule to determine whether the EHR technology they intend to purchase has the necessary CQM capabilities. Last, we have included in the Base EHR definition the capability to electronically submit CQMs as specified by the certification criterion at § 170.314(c)(3). As noted under the discussion of CQM submission earlier in this preamble, EHR technology certified to § 170.314(c)(3) is required to enable the electronic submission of CQM data to CMS according to adopted standards. We believe that this capability will be useful to all EPs, EHs, and CAHs because it is now structured to support the electronic submission of CQMs for MU or as applicable under PQRS. Accordingly, we believe that it is appropriate and beneficial to include this capability and certification criterion in the Base EHR definition.

Last, we decline to expand the Base EHR definition beyond those capabilities already proposed and the one addition we discuss above because requiring the additional capabilities and certification criteria suggested by some commenters would be inconsistent with our stated approach of only requiring in the Base EHR definition capabilities that are as universally applicable as possible.

With these revisions to the proposed Base EHR definition, we now limit the definition to those certification criteria that most closely align with the capacities specified in the definition of a “Qualified EHR” under section 3000(13) of the PHSA and, as supported by commenters, improve data portability and protect the confidentiality, integrity and availability of patient health information. We see this as the most appropriate starting point from which to potentially expand (as necessary) the Base EHR definition in future rulemakings. Furthermore, this modified Base EHR definition gives EPs, EHs, and CAHs even more flexibility than we had proposed and could potentially further reduce CEHRT adoption costs.

We agree with commenters that, as proposed, certification for privacy and security should be consistent across both ambulatory and inpatient settings. The privacy and security certification criteria included in the Base EHR definition are designed to provide EPs, EHs, and CAHs with basic technical capabilities that can support compliance with parts of the HIPAA Privacy and Security Rules. As we stated in the Proposed Rule, EPs, EHs, and CAHs are responsible for implementing their CEHRT in ways that meet applicable privacy and security requirements under Federal law (such as the HIPAA Privacy Rule and Security Rule and 42 CFR Part 2) and applicable state law. The Base EHR definition gives EPs, EHs, and CAHs the flexibility to implement and combine EHR technology capabilities (particularly those capabilities used for MU) in their healthcare environment in ways that they determine are the most functional (e.g., with various different certified EHR Modules), efficient, and cost effective.

“Integration certification” is not currently part of the temporary certification program nor is it included in the ONC HIT Certification Program. We responded to similar comments in a prior rulemaking (76 FR 1273) that integration certification was impractical because of technical and logistical concerns (e.g., the integrated healthcare environment of a hospital) as well as financial costs (e.g., bringing certified EHR Modules from different EHR technology developers together for additional certification after being separately certified). For these reasons, we continue to believe that such certification should not be part of the ONC HIT Certification Program at this time, even for only privacy and security. We reiterate, however, our position stated in the Permanent Certification Program final rule (76 FR 1273) that nothing precludes an ONC-ACB or other entity from offering a service to certify EHR Module-to-EHR Module integration. To be clear, although we do not require or specifically preclude an ONC-ACB from certifying EHR Module-to-EHR Module integration, any EHR Module-to-EHR Module certification performed by an ONC-ACB or other entity will be done without specific authorization from the National Coordinator and will not be considered part of the ONC HIT Certification Program.

The Base EHR definition is included at § 170.102 and has been revised to remove the certification criteria referenced in the discussion above, to add in a minimum number of CQMs for the ambulatory and inpatient settings, and to add the certification criterion at § 170.314(c)(3). Table 6 below specifies the 2014 Edition EHR certification criteria included in the Base EHR definition and the Base EHR capacities they support. To note, as mentioned under section III.B.1 “Revisions to the Definition of Certified EHR Technology,” the Base EHR definition will now be one part of an optional means for meeting the definition of CEHRT for any FY or CY up to and including 2013.

3. Complete EHR Definition

We stated in the Proposed Rule that we intended to maintain the concept of a Complete EHR and permit EHR technology developers to seek Complete EHR certifications for their EHR technology. We proposed, however, to revise the Complete EHR definition for clarity to mean “EHR technology that has been developed to meet, at a minimum, all mandatory certification criteria of an edition of certification criteria adopted by the Secretary for either an ambulatory setting or inpatient setting.”

Comments. We received a few comments expressing support for our proposed revised Complete EHR definition.

Response. We are revising our approach to the Complete EHR definition based on modifications we have made to the Base EHR definition and to clarify the applicability of the revised CEHRT definition for any FY or CY up to and including 2013 to a Complete EHR. In our proposal, a Complete EHR would have inherently met the Base EHR definition because it would have required certification to all the certification criteria included in the proposed Base EHR definition. We have, however, modified the Base EHR definition to require that EHR technology be certified to a minimum number of CQMs per the ambulatory or inpatient setting in order to meet the Base EHR definition, which will require certification to § 170.314(c)(1) and (2) for more than one CQM. To ensure that a Complete EHR encompasses the Base EHR definition, we are establishing two separate Complete EHR definitions, one for the 2011 Edition EHR certification criteria and one for the 2014 Edition EHR certification criteria. As stated in the Proposed Rule, for certification to the 2011 Edition EHR certification criteria, a Complete EHR designed for an ambulatory setting must meet the mandatory certification criteria adopted at §§ 170.302 and 170.304, while a Complete EHR designed for an inpatient setting must meet the mandatory certification criteria adopted under §§ 170.302 and 170.306. For certification of a Complete EHR to the 2014 Edition EHR certification criteria, EHR technology must meet the Base EHR definition and all mandatory certification criteria for either the ambulatory or inpatient setting. Our addition of paragraph (d) to § 170.300 and the use of “ambulatory setting only” and “inpatient setting only” headings within § 170.314 clarifies which certification criteria have general applicability (apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting. Additionally, we have made a guidance document available on our Web site that clearly specifies the 2014 Edition EHR certification criteria that apply to a Complete EHR designed for the ambulatory setting and a Complete EHR designed for an inpatient setting.

Our revised CEHRT definition for any FY or CY up to and including 2013 states that a Complete EHR meets the definition if it “meets the requirements included in the definition of a Qualified EHR and has been tested and certified in accordance with the certification program established by the National Coordinator as having met all applicable certification criteria adopted by the Secretary for the 2011 Edition EHR certification criteria or the equivalent 2014 Edition EHR certification criteria.” We want to make clear that, although the “equivalency option” permits EPs, EHs, and CAHs to use a combination of EHR technology certified to the 2011 Edition and 2014 Edition EHR certification criteria to meet the revised CEHRT definition, a certification cannot be issued for a Complete EHR based on a combination of 2011 Edition and 2014 Edition EHR certification criteria. This would be inconsistent with how we described a Complete EHR in the Proposed Rule and with our “representation requirement” for Complete EHRs and EHR Modules certified under the ONC HIT Certification Program at § 170.523(k)(1)(i) (i.e., 2011 Edition or 2014 Edition compliant). Further, we believe a Complete EHR certified to a combination of 2011 Edition and 2014 Edition EHR certification criteria would cause confusion for EPs, EHs, and CAHs, particularly when transitioning to meet the CEHRT definition for FY/CY 2014 and subsequent years, which only permits EPs, EHs, and CAHs to use of EHR technology certified to the 2014 Edition EHR certification criteria to meet the definition. Accordingly, we are replacing the Complete EHR definition at § 170.102 with the 2011 Edition Complete EHR definition described above and adding the 2014 Edition Complete EHR definition also as described above.

4. Certifications Issued for Complete EHRs and EHR Modules

We restated frequently asked question (FAQ) 9-10-005-1 and its supporting policy rationale in the Proposed Rule. FAQ 9-10-005-1 clarifies that a stand-alone, separate component of a certified Complete EHR cannot derive “certified” status based solely on it having been included as part of the Complete EHR when the Complete EHR was certified. We noted that this same principle applies to certified EHR Modules with multiple capabilities in that the components of the EHR Modules cannot be separately sold or purchased as certified EHR technology unless they have been separately certified.

Comments. We received two comments that supported our policy and a comment that criticized it. The commenter that offered criticism stated that EHR technology developers have been inclined to only get their EHR technology certified as Complete EHRs and have not obtained certification for their EHR technologies in the form of EHR Modules that would best benefit EPs, EHs, and CAHs. The commenter stated that as a consequence, EPs, EHs, and CAHs must possess more EHR technology than they need or want from a particular EHR technology developer. The commenter further stated that the option of EHR technology self-developer certification to address such situations was not a viable option because of the costs and complexity to pursue such an approach was too daunting for most EPs, EHs, and CAHs. The commenter suggested that as an alternative that we require that every Complete EHR presented for certification also be certified as individual EHR Modules.

Response. After consideration of the comments received, we reaffirm our policy incorporated in FAQ 9-10-005-1. We believe that allowing separate components of a certified Complete EHR or certified EHR Module to derive “certified” status from the certification of the entire certified Complete EHR or certified EHR Module would undermine the purpose of the ONC HIT Certification Program. As stated in the Proposed Rule, it would permit EHR technology developers to “self-declare” certifications for components of a certified Complete EHR or certified EHR Module that have never been independently reviewed by an ONC-ACB as actually being able to work as separate, independent technologies. This approach could result in inaccurate, deceptive, or false representations about an EHR technology's capabilities. Furthermore, it is important for all stakeholders to recognize that a certification is assigned to a Complete EHR or EHR Module, not to a capability. And, as we look forward towards the development and introduction of combined and/or workflow-based test procedures, one would be unable to infer that a specific component of a certified Complete EHR or certified EHR Module was compliant with a particular certification criterion unless the component had been separately certified as performing the required capability.

In regard to the commenter's specific suggestion that we require Complete EHR technology developers to have their Complete EHR also certified as EHR Modules, we reiterate that, in accordance with PHSA section 3001(c)(5), the act of seeking certification is voluntary. More importantly, in some cases it may not be practicable (from an EHR technology design and functionality perspective or financially or otherwise) for an EHR technology developer to seek separate certifications for its EHR technology (Complete EHR or EHR Module) as a more limited EHR Module or even in a manner that meets the needs of a particular EP, EH, or CAH. Further, we question whether such an approach could be equitably operationalized. There does not readily appear to be an objective, non-arbitrary and practical way to identify the make-up of each potentially smaller EHR Module that would need to be certified from a Complete EHR or large EHR Module. With these considerations in mind, we strongly encourage EHR technology developers to seek, where possible, certification for separate components of a certified Complete EHR or certified EHR Module that would provide the solutions that EPs, EHs, and CAHs seek to adopt. Additionally, from a practical perspective, we believe our more flexible CEHRT definition will spur EHR technology developers to move in this direction at a much more rapid pace.

5. Adaptations of Certified Complete EHRs or Certified EHR Modules

We stated in the Proposed Rule that it would be possible for an EHR technology developer of a certified Complete EHR or certified EHR Module (and only that EHR technology developer) to create an adaptation of a certified Complete EHR or certified EHR Module without the need for additional certification of the adaptation. We went on to say that we consider an “adaptation” of a certified Complete EHR or certified EHR Module to be a software application designed to run on a different medium, which includes the exact same capability or capabilities included in the certified Complete EHR or certified EHR Module. As an example, we indicated that an adaptation of a certified Complete EHR that is capable of running on a tablet device or smart phone could include the capabilities of a certified Complete EHR to e-prescribe, take electronic notes, and manage a patient's active medication list. In this example, we specified that the adaptation would be covered by the Complete EHR's certification so long as the adaptation included the full and exact same capabilities required for the particular certification criteria to which the Complete EHR was certified (i.e., in this case, the capabilities required by the certification criteria proposed at § 170.314(b)(3), (a)(9), and (a)(6), respectively)). We noted that the user of the adaptation would need to ensure, perhaps through contractual assurances from the EHR technology developer that provides such adaptation, that the adaptation does not introduce privacy and security vulnerabilities into the certified Complete EHR or certified EHR Module. We further noted that, while an EHR technology developer may create an adaptation without needing to obtain an additional certification, the adaptation would be subject to the provisions of the certification issued for the Complete EHR or EHR Module. ONC-ATCBs and ONC-ACBs maintain authority over the certifications that they issue and can take appropriate action when there is evidence of non-conformance with those certifications.

Comments. Many commenters supported our approach to adaptations. Some commenters did not, however, support extending a Complete EHR's or EHR Module's certification to adaptations without further evaluation by ONC-ACBs. These commenters expressed concern about an adaptation's privacy and security capabilities, noting that such capabilities will be fundamentally different from device to device. Commenters also requested that we further clarify the term “full and exact same capabilities.” Some commenters suggested a strict interpretation of the term so that EPs, EHs, and CAHs could be confident that their adapted EHR technology performs and interoperates as seamlessly as the certified Complete EHR or certified EHR Module. Last, commenters inquired about how this process would be monitored. For example, commenters asked whether EHR technology developers needed to seek formal inclusion of adaptations in their original certification and/or attest that the adaptation has the “exact same capabilities” as the certified Complete EHR or certified EHR Module.

Response. We are implementing our adaptation policy as explained in the Proposed Rule and supplemented by the additional guidance provided here in this final rule. As noted in the Proposed Rule, we believe adaptations can serve as innovative ways to facilitate efficient workflows and user interactions. While we believe our example recited above and in the Proposed Rule specifies what constitutes “full and exact same capabilities,” we provide the following as additional clarification. In order for a software application to be treated as an adaptation (and not as a unique, stand-alone EHR Module or Complete EHR for which a separate certification would be required) it must include the full and exact same capabilities required by the certification criteria to which the EHR technology it is serving as an adaptation of was certified. Stated another way, an adaptation cannot partially address the capabilities required by a certification criterion. To illustrate this simply, an adaptation of a certified Complete EHR would need to enable a user to record all of the demographics specified at § 170.314(a)(3) and would not be in compliance with this policy if it only provided a user the ability to record a patient's race and ethnicity. Further, we acknowledge that adaptations will naturally require the certified Complete EHR or certified EHR Module's user interface and other design features to be changed in order to perform efficiently on mobile platforms. Again, our concern is that the capabilities included in the adaptation and available to a user are a one-for-one match with the capabilities that have been adapted from the certified Complete EHR or certified EHR Module. In other words, an adaptation may include less overall capabilities than the certified Complete EHR or certified EHR Module, but for those capabilities it does include they must be the full and exact same capabilities for which certification is required. For example, it would be acceptable for an adaptation to include the full and exact same capabilities specified by 3 of the 10 certification criteria to which an EHR Module was certified.

We appreciate the concerns expressed by commenters related to privacy and security, but remind commenters of certification's limitations. Certification is not a substitute for, or guarantee of, compliance with the HIPAA Privacy and Security Rules. Certification is designed to provide EPs, EHs, and CAHs with basic technical capabilities that can support compliance with parts of the HIPAA Privacy and Security Rules. EPs, EHs, and CAHs remain responsible for implementing their CEHRT in ways that meet applicable privacy and security requirements under Federal law (such as the HIPAA Privacy Rule and Security Rule and 42 CFR Part 2) and applicable state law. We would expect that EHR technology developers would include the relevant privacy and security capabilities in their adaptations where appropriate. For example, we would expect that an adaptation designed to run on a mobile device would employ authentication, access control, and authorization capabilities consistent with those specified in the certification criterion adopted at § 170.314(d)(1). Similarly, we could see scenarios where electronic health information used or processed by an adaptation could be protected in accordance with the “end-user device encryption” certification criterion adopted at § 170.314(d)(7)(i). As noted above and in the Proposed Rule, an EP, EH, or CAH should take steps to ensure, perhaps through contractual assurances from the EHR technology developer that provides such adaptation, that privacy and security capabilities are implemented appropriately and that the adaptation does not introduce privacy and security vulnerabilities into the certified Complete EHR or certified EHR Module. An EP, EH, and CAH should also take independent steps, or again through contractual assurances from the EHR technology developer that provides such adaptation, to address any privacy and security vulnerabilities that may be introduced by the different medium(s) on which the adaptation runs.

An adaptation would need to be based on an already certified Complete EHR or certified EHR Module in order to be treated as being part of the certification issued to these EHR technologies. In this regard, an EHR technology developer would not need to obtain an additional certification for an adaptation nor have to attest to the functionality, capabilities, or otherwise for an adaptation. We believe that contractual relationships with customers and compliance with certifications issued by ONC-ATCBs and ONC-ACBs should be sufficient measures to ensure the integrity of adaptations, while eliminating the burden and costs of certification and attestation on EHR technology vendors and their customers (EPs, EHs, and CAHs). EPs, EHs, and CAHs should take note that absent an EHR technology developer actively seeking a separate certification for an adaptation (which would not be required under our policy), the adaptation itself would not be independently listed on the CHPL because it is considered part of the certification of a previously certified Complete EHR or certified EHR Module. Thus, an EP, EH, and CAH would need to select as part of its attestation process the certified Complete EHR or certified EHR Module from which the adaptation was created. Last, we seek to make clear that an EHR technology developer can always seek certification for its adaptation. Certification of the adaptation would lead to its listing on the CHPL and would permit the EHR technology developer to openly sell the adaptation to all potential purchasers since it would be separately certified.

IV. Provisions of the Proposed Rule Affecting the Permanent Certification Program for HIT (“ONC HIT Certification Program”)

A. Program Name Change

As explained in the Proposed Rule, we have established two certification programs, the “temporary certification program for HIT” and the “permanent certification program for HIT” (see 75 FR 36158 and 76 FR 1262, respectively). We noted in the Proposed Rule that we expected that the permanent certification program would replace the temporary certification program upon the effective date of this final rule. As we discussed, at that time, there would no longer be a need to continue to differentiate between the certification programs based on their expected duration. Therefore, we proposed to replace all references in Part 170 of the Code of Federal Regulations to the permanent certification program with “ONC HIT Certification Program.”

Comments. A few comments expressed agreement with our proposal to change the program name. A commenter noted that having two names was somewhat confusing and that shifting to one name would be desirable.

Response. We thank these commenters for their support and have finalized our proposal. We are revising subpart E of Part 170, Title 45, Subtitle A, Subchapter D of the Code of Federal Regulations to replace all references to the “permanent certification program” with “ONC HIT Certification Program.” We believe this new program name provides clear attribution to the agency responsible for the program and an appropriate description of the program's scope, covering both current and future HIT certification activities. We also note that, as we indicated in the Proposed Rule and in our notice published in the Federal Register on November 3, 2011 (76 FR 68192), the temporary certification program will officially sunset upon the effective date of this final rule and will be replaced with the ONC HIT Certification Program. When the temporary certification program sunsets, ONC-Authorized Testing and Certification Bodies (ONC-ATCBs) will be prohibited from accepting new requests to test and certify EHR technology and will be permitted up to six months after the sunset date to complete all testing and certification activities associated with requests received prior to the sunset date. If these activities are not completed within the 6-month period, the EHR technology would have to be resubmitted for testing and certification under the ONC HIT Certification Program.

B. “Minimum Standards” Code Sets

In the Proposed Rule, we described the current process for the Secretary to identify and accept newer versions of “minimum standards” code sets. Section 170.555 allows ONC-ACBs to certify Complete EHRs and/or EHR Modules to newer versions of certain code sets identified as “minimum standards” in Subpart B of part 170 if the Secretary has accepted a newer version for certification and implementation of EHR technology. We explained that, based on our experience, newer versions of the “minimum standards” code sets that we have adopted are issued more frequently than our current process can reasonably accommodate. We also stated, based on the “minimum standards” code sets we have previously adopted and the ones proposed, that permitting EHR technology to be upgraded and certified to newer versions of these code sets would not normally pose an interoperability risk, cause unintended consequences, or place an undue burden on the HIT industry. Therefore, we proposed to revise § 170.555 such that, unless the Secretary prohibits the use of a newer version of a “minimum standards” code set identified in subpart B of part 170, the newer version could be used voluntarily for certification and implemented as an upgrade to a previously certified Complete EHR or EHR Module without adversely affecting the EHR technology's certified status. In consideration of this proposed new approach, we clarified that when we refer to a “newer” version of a “minimum standard” code set, we mean a final version or release as opposed to a draft version or release of a code set.

We outlined a process for determining when to prohibit the use of a newer version of a “minimum standards” code set that was similar to the process we used for accepting newer versions of “minimum standards” code sets. The public could inform ONC or the Secretary could proactively identify a newer version of a “minimum standard” code set that may not be appropriate for use. We indicated our expectation that we would still seek a recommendation from the HITSC, based on their assessment of the newer version and on any public comments that they receive, as to whether the Secretary should prohibit the use of the newer version of the “minimum standard” code set. After considering the HITSC's recommendation, the National Coordinator would make a recommendation to the Secretary as to whether or not to allow the continued use of the newer version. Finally, if the Secretary decides to prohibit the use of a newer version of a minimum standard code set, we stated that we would issue guidance indicating that the newer version of the adopted “minimum standards” code set cannot be used for certification under the ONC HIT Certification Program, and thus upgrading previously certified Complete EHRs and EHR Modules to the newer version would adversely affect their certified status.

As an exception to the process outlined above, we specified that, in limited circumstances, it may be necessary for the Secretary to act more quickly to prohibit the use of a newer version of a “minimum standards” code set. Instances could arise where the use of a newer version of a “minimum standards” code set may have an immediate negative effect on interoperability, cause an obvious unintended consequence, or pose an undue burden on the HIT industry. Therefore, under such circumstances, we specified that the Secretary may choose to prohibit the use of a newer version of a “minimum standards” code set for purposes of certification and upgrading certified EHR technology without seeking a recommendation from the HITSC in advance.

To provide additional clarity and consistency, we proposed to also make minor revisions to the text of § 170.555, including removing the terms “adopted” and “accepted” and replacing the term “Certified EHR Technology” in § 170.555(b)(2) with “A certified Complete EHR or certified EHR Module.”

Comments. Most commenters supported our proposal to revise the process for permitting the use of new versions of “minimum standards” code sets. Several commenters commended our proposed approach and indicated it would reduce regulatory complexity and burden by providing the industry with the flexibility to quickly utilize newer versions of adopted “minimum standards” code sets. A few of the commenters that agreed also expressed concern that it may be difficult for EPs, EHs, and CAHs to reconcile different code set releases if one EHR technology developer rolls them out faster than another. A few other commenters recommended that we should require backward compatibility as a condition for Secretary acceptance of newer versions of code sets. These commenters stated this would serve as a means of mitigating the challenges associated with different code set releases. A couple of commenters also recommended that providing technical support for previous versions should be a condition of certification of EHR technology to newer versions of “minimum standards” code sets. One commenter specifically suggested that support for the previous version be offered for at least 12 to 18 months unless otherwise abandoned due to extenuating circumstances (e.g., security or patient safety concerns). One commenter suggested that when a newer version release is available and accepted by the Secretary (with or without a recommendation from the HITSC) that there be a period of 180 days when vendors may test to either the previous or newer versions of the standard. Another commenter recommended that a regular and rational strategy be established to refresh the “minimum standards” called for in MU.

Response. We appreciate the comments submitted in support of our proposal and are revising § 170.555 such that, unless the Secretary prohibits the use of a newer version of a “minimum standards” code set identified in subpart B of part 170, the newer version could be used voluntarily for certification and implemented as an upgrade to a previously certified Complete EHR or certified EHR Module without adversely affecting the EHR technology's certified status. We believe this approach reduces regulatory complexity and provides the industry with the flexibility to utilize newer versions of adopted “minimum standards” code sets without regulatory interference. We are also finalizing our proposal to make the minor text changes to § 170.555, as well as the process we outlined in the Proposed Rule for determining when to prohibit the use of a newer version of a “minimum standards” code set and the exception to that process.

With respect to the comments regarding the additional condition of certification for technical support, timing for when new versions of the code sets are released, and a schedule to refresh the “minimum standards” that would be required as part of MU, we believe that these commenters may have misinterpreted the flexibility and approach offered by our proposal and the way in which newer versions of “minimum standards” code sets would be treated by the final rule. Therefore, we offer this additional explanation. In general, we understand that the code sets we have identified as “minimum standards” code sets are frequently updated to keep pace with industry needs. For example, when a new medication becomes available, a new code for that medication would be added to the next release of RxNorm. As finalized, our revision to § 170.555 permits an EHR technology developer to, for example, immediately include that newer version of RxNorm when presenting its Complete EHR or EHR Module for certification rather than having to use the older version adopted in the Code of Federal Regulations in order to get certified. As we explained, inclusion of the newer version would be voluntary, and the developer would still have the option for its EHR technology to be certified to the version specified in regulation. It also permits certified Complete EHRs and certified EHR Modules to be voluntarily upgraded to these newer versions without adversely affecting the EHR technology's certified status. With respect to comments about EPs, EHs, and CAHs reconciling different releases and requiring backwards compatibility, we do not believe that these are acute concerns with respect to the code sets we have designated as “minimum standards” code sets because newer releases should subsume or include the codes that were in a prior version (subject to the natural retirement/deprecation of no longer useful codes). As stated in the Proposed Rule, based on the “minimum standards” code sets we have previously adopted and proposed, we believe that permitting EHR technology to be upgraded and certified to newer versions of these code sets would not normally pose an interoperability risk, cause unintended consequences, or place an undue burden on the HIT industry. In limited circumstances where the use of newer versions of a “minimum standards” code set may have an immediate negative effect, we can use the process we described above for the Secretary to prohibit the use of a newer version of a “minimum standards” code set for purposes of certification and upgrading certified Complete EHRs and certified EHR Modules. Accordingly, we do not believe that it is necessary to establish a backwards compatibility condition for “minimum standards” code sets as suggested. Further, we believe that the process we have in place for prohibiting the use of newer versions will mitigate any potential adverse affect for EPs, EHs, or CAHs should a major change to an adopted minimum standard occur. With respect to the comment about the refresh cycles for “minimum standards” code sets, we intend to make such updates as part of the normal rulemaking cycle that we engage in to adopt new certification criteria editions. Thus, we expect that regulatory updates to newer versions of “minimum standards” code sets will be on predictable schedule.

C. Revisions to EHR Module Certification Requirements

1. Privacy and Security Certification

In the Proposed Rule, we proposed that EPs, EHs, and CAHs must have EHR technology that meets the proposed Base EHR definition. The proposed Base EHR definition referenced all of the proposed privacy and security certification criteria at § 170.314(d) except the optional “accounting of disclosure” certification criterion at § 170.314(d)(9). Based on the policy expressed by the proposed Base EHR definition and stakeholder feedback received since the S&CC July 2010 final rule, we proposed to eliminate the current privacy and security certification requirements in § 170.550(e) for EHR Modules starting with the 2014 Edition EHR certification criteria.

Comments. Several commenters supported our proposed revisions to EHR Module certification and expressed agreement that it would reduce regulatory burden and enable greater flexibility. A few commenters disagreed with our position and contended that we should continue our existing approach to the privacy and security certification of EHR Modules as specified in § 170.550(e) with the 2014 Edition EHR certification criteria. A couple of commenters expressed concern that our approach could lead to certain negative effects if, as a result of this proposed change, the EHR technology certified and used by an EP, EH, or CAH to satisfy the Base EHR definition could not be configured to also apply those privacy and security capabilities to other separately certified EHR Modules an EP, EH, or CAH may choose to implement. Along those lines, some commenters requested greater clarity regarding our proposed EHR Module certification change and how it interacts with the Base EHR definition. One commenter suggested that if ONC finalizes this proposal that we should evaluate its effect to determine if additional requirements would subsequently be necessary. Another commenter recommended that remote components providing services to a Complete EHR or EHR Module should be secured with Transport Layer Security (TLS) and should not be required to be separately certified to the privacy and security requirements.

Response. In consideration of comments received, we are revising § 170.550(e) as proposed. Upon this final rule's effective date, EHR Modules presented for certification to the 2014 Edition EHR certification criteria will not be required to be certified to the privacy and security certification criteria adopted at § 170.314(d). We continue to believe, as echoed by many commenters, that our proposed change would reduce regulatory burden on EHR technology developers and the potential for EPs, EHs, and CAHs to purchase EHR Modules that have redundant or conflicting privacy and security capabilities.

With respect to the concern identified by some commenters, we reiterate what we stated in the Proposed Rule. EPs, EHs, and CAHs ultimately remain responsible for implementing their EHR technology in ways that meet applicable privacy and security requirements under Federal and applicable state law (e.g., the HIPAA Privacy Rule and Security Rule and 42 CFR Part 2). Certification is in no way a substitute or proxy for compliance with these legal requirements. Per the commenters' scenario and the other request for greater clarification on the Base EHR definition, we acknowledge it could be possible for an EP, EH, or CAH to adopt, for example, a certified EHR Module (certified EHR Module #1) that satisfies the Base EHR definition as well as other certified EHR Modules, and that those other certified EHR Modules might not be able to utilize or leverage the privacy and security capabilities included in certified EHR Module #1. Therefore, we strongly encourage EPs, EHs, and CAHs (presumably as they would with any other EHR technology necessary to meet MU or not) to carefully evaluate as part of their ongoing risk analysis processes whether the implementation of an additional separate certified EHR Module could pose new risks to privacy and security. As suggested by these commenters, we intend to monitor the effects of these changes to determine whether alternative requirements would be necessary as part of future rulemaking. For a more detailed discussion of the Base EHR definition, its requirements and relationship to CEHRT and certified EHR Modules, and our response to comments, we refer readers to section III.B.2 of this final rule. Finally, with respect to the commenter's two-part recommendation related to remote components providing services to a certified Complete EHR or certified EHR Module, we find the commenter's scenario and limited description of a “remote component” too ambiguous to issue a definitive response. In the Proposed Rule, we proposed that EHR technology presented for certification as an EHR Module would no longer need to be separately certified to the adopted privacy and security criteria—a proposal we have finalized. In general, we agree that TLS could be an appropriate standard in this situation, but, again, do not believe that the commenter provided sufficient detail on which to respond.

2. Certification to Certain New Certification Criteria

We proposed to revise § 170.550 to ensure certification of EHR Modules to the following 2014 Edition EHR certification criteria, as applicable: (1) Electronic recording of the numerator for each MU objective with a percentage-based measure (§ 170.314(g)(1) “automated numerator recording”); (2) electronic recording of activities related to non-percentage-based measures (§ 170.314(g)(3) “non-percentage-based measure use report”); and (3) user-centered design processes to be applied to EHR technology that includes certain capabilities (§ 170.314(g)(4) “safety-enhanced design”). More specifically, we proposed to revise § 170.550 to ensure that EHR Modules that are presented for certification to certification criteria that include capabilities for supporting a MU objective with a percentage-based measure are certified to § 170.314(g)(1). However, we also proposed that this requirement would not apply if the EHR Module was certified to § 170.314(g)(2) “automated measure calculation” in lieu of certification to § 170.314(g)(1). We proposed to revise § 170.550 to ensure that EHR Modules that are presented for certification to certification criteria that include capabilities for supporting an MU objective with a non-percentage-based measure are certified to § 170.314(g)(3). Last, we proposed to revise § 170.550 to ensure that EHR Modules that are presented for certification to any of the certification criteria listed in proposed § 170.314(g)(4) are also certified to § 170.314(g)(4). We proposed to include these revisions at § 170.550(f).

Comments. We received a few comments expressing support for requiring certification to these certification criteria.

Response. We appreciate the support expressed by commenters and are finalizing our proposals to have ONC-ACBs ensure EHR Modules are certified to these certification criteria, except for our proposal concerning the “non-percentage-based measure use report” certification criterion at § 170.314(g)(3). As discussed earlier in this preamble, we are not finalizing the proposed “non-percentage-based measure use report” certification criterion as part of the 2014 Edition EHR certification criteria. Therefore, ONC-ACBs would not need to ensure that EHR Modules were certified to the certification criterion. We also note that, because we are not finalizing the proposed “non-percentage-based measure use report” certification criterion, we have re-designated the “safety-enhanced design” certification criterion to § 170.314(g)(3).

After consideration of comments received on our proposal to adopt a certification criterion related to quality management processes for EHR technology, we have adopted a “quality management system” certification criterion at § 170.314(g)(4). This certification criterion applies to all EHR technology certified to the 2014 Edition EHR certification criteria. Therefore, to ensure ONC-ACBs certify all EHR Modules presented for certification to the 2014 Edition EHR certification criteria to this new certification criterion, we have revised § 170.550(f) to require that EHR Modules are certified to § 170.314(g)(4).

D. ONC-ACB Reporting Requirements

We proposed to revise § 170.523(f) to require ONC-ACBs to include an additional data element in the data set they must provide to ONC for the Complete EHRs and/or EHR Modules they certify. Specifically, we proposed that an ONC-ACB would need to provide ONC a hyperlink for each Complete EHR and EHR Module it certifies that would enable the public to access the test results that the ONC-ACB used to certify the EHR technology. As with all of the other data ONC-ACBs are required to report to ONC about certified Complete EHRs and certified EHR Modules, we proposed to make the hyperlink available on the CHPL with the respective certified Complete EHR or certified EHR Module. As noted in the Proposed Rule, we expect that ONC-ACBs would ensure the functionality of the hyperlink for a minimum of five years consistent with § 170.523(g), unless a certified Complete EHR or certified EHR Module is removed from the CHPL. Under such circumstances, we stated that the ONC-ACB would no longer need to ensure the functionality of the hyperlink, although retention of the test results would be required.

Comments. Many commenters supported our proposal. Some commenters, however, opposed publicly posting test results. Commenters that supported our proposal stated that publicly posting the test results would improve transparency. Some of these same commenters also indicated that the public availability of test results would empower customers. Specifically, they stated that customers could review and compare the test results against expected performance as a way to troubleshoot any implementation challenges posed by a certified Complete EHR or certified EHR Module. Conversely, commenters that expressed opposition to publicly posting test results stated that doing so could compromise EHR technology developers' intellectual property rights. These commenters expressed concern about the publication of source code as well as the publication of copyrighted materials that may be present in testing screenshots. A few commenters also argued that there was little value in publicly posting test results because the true value for consumers was in knowing whether the EHR technology was certified. As alternatives to, or rationale against, publicly posting test results, commenters suggested that test results could be obtained by consumers (e.g., EPs, EHs, and CAHs) during purchase negotiations and that ONC could post information about the testing and certification processes in lieu of posting test results. Commenters also noted that a standardized format for test results does not currently exist under the temporary certification program and suggested that such a format was necessary for testing results to be equitably treated and for any analysis or comparison of test results.

Response. We have considered the comments received on this proposal. We strongly believe that transparency should be an integral component of the ONC HIT Certification Program. Transparency can provide for additional access to and scrutiny of the ONC HIT Certification Program as well as improve program performance and increase public confidence in the EHR technology certified under the program.

We believe that an appropriate balance can be struck that supports transparency, protects EHR technology developers' potential intellectual property rights, and provides testing results in a consistent and identifiable manner. We have finalized our proposal and will require that ONC-ACBs submit a hyperlink of the test results used to issue a certification to a Complete EHR or EHR Module, which can be accessed by the public. In light of the concern expressed by some commenters, we intend to provide guidance to ONC-ACBs regarding the test results information that should be excluded from the publicly accessible hyperlink they submit to ONC. As an example, we expect ONC-ACBs would exclude from the publicly available hyperlink any screenshots produced as part of the testing process. Although we do not anticipate that source code would be visible in a test result report, if it is visible, we expect ONC-ACBs would exclude it from the information made available through the hyperlink. We would also expect any negative test results to be excluded from publicly posted test results because only passed test results would be necessary for obtaining certification of a Complete EHR or EHR Module from an ONC-ACB. We believe this should mitigate the concerns identified by commenters, and we will provide additional guidance to ONC-ACBs in the future if other unique circumstances not discussed here arise. We also intend, as suggested by commenters, to work closely with NVLAP to develop a standardized format for test results that can be used by all accredited testing laboratories and submitted to any ONC-ACB to be used for certification.

E. Continuation and Representation of Certified Status

1. 2011 or 2014 Edition EHR Certification Criteria Compliant

To align with our proposal to designate the certification criteria adopted in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria” and to designate the certification criteria proposed in the Proposed Rule at § 170.314 as the “2014 Edition EHR certification criteria,” we proposed to revise § 170.523(k). The proposed revision to § 170.523(k) would require ONC-ACBs to ensure as part of certification that a developer of a Complete EHR or EHR Module would indicate in all marketing materials, communications, statements, and other assertions the certification criteria edition to which it had been certified rather than the compliance years the certification issued to the Complete EHR or EHR Module represented. We proposed that this revision would apply to all certifications issued after the effective date of this final rule.

As noted in the Proposed Rule, we considered multiple options to address certified Complete EHRs and certified EHR Modules already designated as “2011/2012” compliant and concluded that the best approach was to not require any changes to the “2011/2012” designation. Rather, we stated that we would simply make clear that certified Complete EHRs and certified EHR Modules that are designated as “2011/2012 compliant” would remain valid for purposes of the EHR reporting periods in FY/CY 2013. We requested public comment on this approach and any other approach that would present the least burden for EHR technology developers and the least confusion for the market.

We also proposed to revise § 170.523(k)(1)(i) by removing the following statement: “* * * or guarantee the receipt of incentive payments” because although incentives will be available under the Medicaid EHR Incentive Program until 2021, they will no longer be available under the Medicare EHR Incentive Program after 2016.

Comments. Commenters supported the concept of “editions” of certification criteria and stated that identifying EHR technology's compliance with editions of certification criteria would be less confusing than using multiple years as a means of identifying an EHR technology's certified status and validity.

Response. We thank the commenters for their support and are revising § 170.523(k) as proposed. When an ONC-ACB issues a certification it must require that the EHR technology developer include on its Web site(s) and in all marketing materials, communications, statements, and other assertions, the certification criteria edition to which the Complete EHR or EHR Module was certified. This revision applies to all certifications issued after the effective date of this final rule and means that EHR technology certified to the 2011 Edition EHR certification criteria will be designated as “2011 Edition EHR certification criteria compliant” and EHR technology certified to the 2014 Edition EHR certification criteria will be designated as “2014 Edition EHR certification criteria compliant.” We believe this revision will assist in eliminating confusion about the “expiration” of certifications, align with our revised definition of CEHRT, and provide the market with greater clarity regarding the capabilities certified Complete EHRs and certified EHR Modules include. As stated above and in the Proposed Rule, EHR technology that has already been designated as “2011/2012 compliant” does not need to be re-designated as “2011 Edition EHR certification criteria complaint.” Finally, consistent with our proposal, we are removing the statement: “* * * or guarantee the receipt of incentive payments” from § 170.523(k)(1)(i) to prevent confusion about the parameters of the EHR Incentive Programs.

2. Updating a Certification

To ensure that the information required by § 170.523(k)(1)(i) remains accurate and reflects the correct EHR certification criteria edition, ONC-ACBs, under § 170.550(d), are permitted to provide updated certifications to previously certified EHR Modules under certain circumstances. In the Permanent Certification Program final rule (76 FR 1306) and at § 170.502, we defined “providing or provide an updated certification” to an EHR Module as “the action taken by an ONC-ACB to ensure that the developer of a previously certified EHR Module(s) shall update the information required by § 170.523(k)(1)(i), after the ONC-ACB has verified that the certification criterion or criteria to which the EHR Module(s) was previously certified have not been revised and that no new certification criteria adopted for privacy and security are applicable to the EHR Module(s).” Based on our proposal in the Proposed Rule to no longer apply the privacy and security certification requirements at § 170.550(e) to EHR Modules certified to the proposed 2014 Edition EHR certification criteria, we proposed to revise the definition of “providing or provide an updated certification” at § 170.502. The proposed revised definition would eliminate the requirement that ONC-ACBs must verify whether any new privacy and security certification criteria apply when they issue an updated certification to an EHR Module.

We also noted in the Proposed Rule that the certification criteria and certification requirements that apply to previously certified EHR Modules may change with each new edition of certification criteria that is adopted by the Secretary. Therefore, we stated that we can provide the best guidance to stakeholders on when “updating” a certification would be permitted with each rulemaking for a certification criteria edition. For the 2014 Edition EHR certification criteria, we stated that if we were to adopt in a final rule the proposed certification criteria at § 170.314(g)(1) (automated numerator recording) and § 170.314(g)(3) (non-percentage-based measure use report), then no previously certified EHR Module could have its certification “updated” to the 2014 Edition EHR certification criteria because it would need to be certified to one of the above certification criteria (with the option of an EHR Module being certified to § 170.314(g)(2) in lieu of being certified to § 170.314(g)(1)).

Comments. We received no comments on this proposal.

Response. We are finalizing the proposed revisions to the definition “providing or provide an updated certification” at § 170.502. We also specify that “updating” an EHR Module's certification to the 2014 Edition EHR certification criteria will not be available. As noted previously in this preamble, we have adopted a “quality management system” certification criterion (§ 170.314(g)(4)) that applies to all EHR technology certified to the 2014 Edition EHR certification criteria. Therefore, when certifying EHR Modules to the 2014 Edition EHR certification criteria, ONC-ACBs must certify EHR Modules to this new certification criterion. Additionally, we have finalized the proposed new certification criteria “automated numerator recording” (§ 170.314(g)(1)) and “safety-enhanced design” (now designated as § 170.314(g)(3)). ONC-ACBs must also ensure that EHR Modules presented for certification to the 2014 Edition EHR certification criteria are, as applicable, certified to these new certification criteria. Consequently, an ONC-ACB may not issue “updated” certifications to previously certified EHR Modules for the 2014 Edition EHR certification criteria. As we noted in the Proposed Rule, “updating” a certification may still be a viable option under certain conditions when the Secretary adopts another edition of certification criteria in the future.

3. Representation of Meeting the Base EHR Definition

With respect to the Base EHR definition, we explained in the Proposed Rule that EPs, EHs, and CAHs would benefit from knowing which certified EHR technologies on the market meet the Base EHR definition because they would need to have EHR technology that meets the Base EHR definition to satisfy the proposed revised definition of CEHRT beginning with FY/CY 2014. We stated that it was unnecessary to expressly propose a requirement for ONC-ACBs to identify EHR technology that meets the Base EHR definition because EHR technology developers, in order to gain a competitive advantage in the market, would likely identify on their Web sites and in marketing materials, communications, statements, and other assertions whether their certified Complete EHR or certified EHR Module(s) also met the Base EHR definition (designed for either the ambulatory or inpatient setting). We did, however, consider (as a potential alternative and complementary approach) permitting ONC-ACBs when issuing certifications to Complete EHRs and EHR Modules that meet the Base EHR definition to formally indicate such fact to the EHR technology developer and permit the EHR technology developer in association with its EHR technology's certification to represent that the EHR technology meets the Base EHR definition. We requested public comment our approach and whether there was any other potential approach that we had not identified.

Comments. Many commenters supported the Base EHR concept and suggested that EHR technologies meeting the Base EHR definition should be listed as such, and searchable, on the Certified HIT Products List (CHPL). Commenters stated that specifically listing EHR technologies that meet the Base EHR definition on the CHPL would provide the most purchasing clarity for EPs, EHs, and CAHs. Some commenters also stated that leaving it up to the EHR technology developers to identify whether their EHR technologies met the Base EHR definition could be misleading to purchasers.

Response. We believe, as indicated in the Proposed Rule, that EHR technology developers will be able to identify on their Web sites and in marketing materials, communications, statements, and other assertions whether their certified Complete EHR or certified EHR Module(s) meet the Base EHR definition (designed for either the ambulatory or inpatient setting). This will enable EHR technology developers to market the post-certification combination of multiple certified EHR Modules as meeting the Base EHR definition. We believe this is the best way to address situations where an EHR technology developer has EHR Modules certified at different times, but those EHR Modules together meet the Base EHR definition. This approach will also permit multiple affiliated EHR technology developers to market the post-certification combination of their certified EHR Modules if together they meet the Base EHR definition.

We do not believe that purchasers should be concerned about misleading practices related to the identification of certified Complete EHRs and certified EHR Modules as meeting the Base EHR definition. First, a certified Complete EHR by definition meets the Base EHR definition. Second, ONC-ACBs oversee the certifications they issue to Complete EHRs and EHR Modules. When ONC-ACBs are accredited, their conformance to ISO/IEC Guide 65:1996 (Guide 65) is verified. Section 14.3 of Guide 65 states that “incorrect references to the certification system or misleading use of licenses, certificates or marks, found in advertisement, catalogues, etc., shall be dealt with by suitable action.” Based on this provision, we are confident that any misleading practices by EHR technology developers as they relate to their certified EHR Modules will be dealt with appropriately by ONC-ACBs.

We understand the commenters' desire to have EHR technology listed on the CHPL designated as whether it meets the Base EHR definition. We believe, however, that it would be impractical and administratively burdensome to prospectively list or designate all EHR technologies that could be combined post-certification to meet the Base EHR definition. Rather, a more efficient and less burdensome approach will be to enable the CHPL Web site to identify whether EHR technologies selected from the CHPL meet the Base EHR definition. For example, if an EP, EH, or CAH selected on the CHPL EHR technology developer A's certified EHR Module and EHR technology developer B's certified EHR Module, we expect that the CHPL would be able to identify whether the certified EHR Modules together meet the Base EHR definition (i.e., have been certified to all of the certification criteria specified in the Base EHR definition and the requisite number of CQMs). This approach would permit EPs, EHs, and CAHs to determine whether they have EHR technology that meets the Base EHR definition and also limits inefficiencies and burdens associated with EHR technology developers having ONC-ACBs verify that their EHR technologies meet the Base EHR definition (potentially post certification), reporting this information to the CHPL, and/or having the CHPL attempt to prospectively identify all EHR technologies (and combinations) that meet the Base EHR definition.

F. EHR Technology Price Transparency

In response to stakeholder feedback, the Proposed Rule described our belief that the EHR technology marketplace could benefit from price transparency associated with certified Complete EHRs and certified EHR Modules. We further stated that price transparency could be achieved by requiring ONC-ACBs to ensure that EHR technology developers include clear pricing of the full cost to purchasers of their certified Complete EHR and/or certified EHR Module on their Web sites and in all marketing materials, communications, statements, and other assertions related to a Complete EHR's or EHR Module's certification. In other words, ONC-ACBs could require EHR technology developers to disclose a purchaser's full cost (a single price) for all of the capabilities for which certification was required and that were included in a certified Complete EHR or certified EHR Module. We noted in the Proposed Rule, however, that in no way would this requirement dictate the price an EHR technology developer could assign to its EHR technology. We requested comment on the feasibility and value of price transparency for certified Complete EHRs and certified EHR Modules in the manner described.

Comments. EHR technology developers and organizations representing EHR technology developers opposed this proposal. Providers and provider organizations supported the concept of price transparency, but not necessarily as proposed. Commenters questioned our proposed form of price transparency and stated that its anticipated value to purchasers was unclear because of the complexity and multiple costs associated with purchasing EHR technology. Alternatively, commenters stated that knowing a certified Complete EHR or certified EHR Module's “total cost of ownership” would be more valuable than just the price associated with the capabilities that the certification assigned to a Complete EHR or EHR Module represented. For commenters, total ownership costs included: Implementation costs (e.g., local implementation, subscription to an ASP, or web-based service); customization/configuration (e.g., configurations of interfaces); training; and maintenance. Commenters also suggested that price transparency should mean that, in a multiple EHR technology developer scenario, the amount paid to each EHR technology developer would be identified. Other commenters noted that our proposed price transparency approach added little benefit because EHR technology developers could offer a low initial cost for the acquisition of a certified Complete EHR or certified EHR Module and then charge additional costs for other essential components of total ownership, such as implementation. Commenters also pointed out that a single price could give a false impression of equality. They cited, for example, that two certified Complete EHRs may have the same price, but offer substantially different capabilities and services in addition to those capabilities for which certification is required.

Commenters stated that our proposal could hinder innovation and flexibility in product development, pricing, and market strategies. Some commenters stated, for example, that many products are not sold or licensed with only the capabilities for which certification is required and that our proposal could negatively alter current practices by confusing customers familiar with customary pricing and purchasing practices. A few commenters were also concerned about the proposal's impact on confidential, competitive and, some thought, proprietary marketing strategies. These commenters also noted that they were unaware of any other industry with the type of pricing dimensions and complexities as the HIT market and in which the Federal government required prices to be publicly available.

Commenters stated that it would be burdensome to include prices on all materials as proposed, particularly if prices change. A few EHR technology self-developers requested that we exempt them from the price transparency proposal because they would not be selling their certified Complete EHR or certified EHR Module on the open market. Commenters noted that Regional Extension Centers have taken extensive steps to identify the true cost of EHR technologies inclusive of software (in-house vs. hosted), services, training, maintenance, and other factors in an effort to help their constituents properly compare certified Complete EHRs and certified EHR Modules. Last, commenters sought clarification regarding how EHR technology developers would be held accountable to this requirement (i.e., what would be the consequences for EHR technology developers).

Response. We appreciate the variety and specificity of comments issued in response to this proposal. For the reasons stated in the Proposed Rule as well as those raised by commenters in favor of this proposal, we continue to believe that there is value in requiring ONC-ACBs to ensure that EHR technology developers are transparent about the costs associated with certified Complete EHRs and certified EHR Modules. Further, we believe that such transparency can provide greater purchasing clarity for EPs, EHs, and CAHs. In considering that almost all commenters found fault with our proposal to list a purchaser's full cost or single price for a certified Complete EHR or certified EHR Module (for the various reasons identified in the comments above), we have finalized a modified approach based on those same comments and their suggestions for what would be helpful. This modified approach focuses on an EHR technology developer's responsibility to notify EPs, EHs, and CAHs about additional types of costs (i.e., one-time, ongoing, or both) that may affect a certified Complete EHR or certified EHR Module's total cost of ownership for the purposes of achieving MU.

We noted in the Proposed Rule that stakeholder feedback on unclear pricing prompted us to offer the proposal to require ONC-ACBs to ensure that EHR technology developers to specify the purchaser's full cost of a certified Complete EHR or certified EHR Module. We identified that stakeholders had conveyed to us that EHR technology developers were specifying prices for multiple groupings of capabilities even though the groupings did not correlate to the entire certified Complete EHR or certified EHR Module. Further, as commenters reinforced, EHR technologies that may be certified under the ONC HIT Certification Program could be sold or licensed with capabilities that are in addition to those that fall under the scope of certification.

We acknowledge that many factors, such as those mentioned by commenters (e.g., costs from purchasing EHR technology from multiple EHR technology developers, maintenance of the EHR technology, and training of staff on the EHR technology), go into a purchaser's total ownership cost for a certified Complete EHR or certified EHR Module(s). Our proposal sought, however, to clearly identify for purchasers the cost associated with the capabilities that the certification assigned to a Complete EHR or EHR Module represented, separate and apart from those capabilities and services that are not required for certification but are sold by EHR technology developers with the purchase of a certified Complete EHR or certified EHR Module. On balance, we believe that the best approach to address the concerns that prompted our proposal, as well as those received in response, is to amend § 170.523(k)(1) to add a third provision related to price transparency. Section § 170.523(k)(1) requires an ONC-ACB to ensure that a Complete EHR or EHR Module developer conspicuously includes on its Web site and in all marketing materials, communications statements, and other assertions related to the Complete EHR or EHR Module's certification the information specified in paragraphs (k)(1)(i) and (k)(1)(ii). This new provision, finalized at § 170.523(k)(1)(iii), requires an ONC-ACB to ensure that a Complete EHR or EHR Module developer discloses any additional types of costs that an EP, EH, or CAH would pay to implement the capabilities a certified Complete EHR or certified EHR Module includes in order to attempt to meet MU objectives and measures. We clarify that these types of costs are in addition to those costs that an EP, EH, or CAH would pay to purchase (or upgrade to) the EHR technology capabilities for which certification is required. These may be one-time or recurring costs, or both. We also clarify that ONC-ACBs would only be required to ensure that EHR technology developers disclose the types of additional costs, and not the actual dollar amounts of such costs.

For example, if EHR technology is certified to the “view, download, and transmit to a 3rd party” certification criterion, and an EP would be expected to pay an “ongoing” monthly service fee to the EHR technology developer for it to host/administer this capability in order for the EP to meet the correlated MU objective and measure, the existence of this potential “ongoing” cost would need to be disclosed by the EHR technology developer. As another example, an EHR Module certified to the public health electronic lab reporting certification criterion (§ 170.314(f)(4)) would be able to create a valid HL7 message for electronic submission. However, for the purposes of achieving MU, a hospital may be expected to pay their EHR technology developer a separate “one-time” and/or “ongoing” interface development and configuration fee to establish connectivity between their certified EHR Module and a public health authority. In such a situation, the potential costs of the interface development and configuration fee would need to be disclosed. A final example would be where an EHR technology developer charges a “one-time” fee to integrate its certified EHR technology with a hospital's other certified EHR Modules or a health information exchange organization. Again, just like the other examples, the potential for this fee would need to be disclosed by the EHR technology developer. Building off these examples, we would expect that an EHR technology developer could satisfy § 170.523(k)(1)(iii) by disclosing: 1) the type(s) of additional cost; and 2) to what the cost is attributed. In reference to the first example above, an EHR technology might state that “an additional ongoing fee may apply to implement XYZ online patient service.” In situations where the same types of cost apply to different services, listing each as part of one sentence would be acceptable, such as “a one-time fee is required to establish interfaces for reporting to immunization registries, cancer registries, and public health agencies.”

We believe that the limited scope required by this new disclosure will not hinder innovation and flexibility in product development pricing, and marketing strategies, nor is it likely to implicate confidential or proprietary information. We remind commenters that certification already requires certain transparency provisions. Under the ONC HIT Certification Program, ONC-ACBs must ensure that EHR technology developers specify certain information about their certified Complete EHR or certified EHR Module on their Web sites, in all marketing materials, communication statements, and other assertions (see § 170.523(k)(1)(i) and (ii)). This information conveys all of the capabilities that the certification issued to the Complete EHR or EHR Module represents and what must be provided to an EP, EH, or CAH in order for the EHR technology developer to properly convey the benefit (i.e., certification) assigned to the certified Complete EHR or certified EHR Module. Further, this information also notifies the customer of any additional software that the EHR technology developer relied on to meet certain certification criteria. In cases where additional software is relied on, it is also encompassed by the certification issued to the certified Complete EHR or certified EHR Module. From a transparency perspective, this new requirement will provide clarity to purchasers regarding the potential additional types of costs they may face when implementing a certified Complete EHR or certified EHR Module. It may also help prevent purchasers from being surprised by additional costs beyond those associated with the adoption and implementation of the capabilities that comprise their CEHRT.

We described “self-developed” EHR technology in the Permanent Certification Program final rule (76 FR 1300-1301). We described self-developed EHR technology to mean a Complete EHR or EHR Module that has been designed, modified, or created by, or under contract for, a person or entity that will assume the total costs for its testing and certification and will be a primary user of the Complete EHR or EHR Module. We further noted that this distinction served to distinguish between those Complete EHRs and EHR Modules that would be created once and most likely sold to many EPs, EHs, and CAHs from those that would be certified once and used primarily by the person or entity who paid for testing and certification. On the developer level, we used the terms “self-developer” and commercial vendor to distinguish between the two types of developers. As requested by commenters, EHR technology self-developers would be exempt from the new requirement because they will not be marketing or making their certified Complete EHRs or certified EHR Modules commercially available for sale. To obtain this exemption, EHR technology self-developers will need to provide written notification to the ONC-ACB when presenting their EHR technology for certification that they are an EHR technology self-developer and their EHR technology will not be marketed or made commercially available for sale to health care providers.

ONC-ACBs are responsible for ensuring compliance with § 170.523(k)(1) and will determine appropriate consequences if EHR technology developers fail to disclose the information specified in § 170.523(k)(1).

G. Certification and Certification Criteria for Other Health Care Settings

The HITECH Act did not authorize the availability of incentives under the EHR Incentive Programs for all health care providers. Consequently, in the Proposed Rule, we noted that the certification criteria proposed for adoption focused primarily on enabling EHR technology to be certified and subsequently adopted and used by EPs, EHs, and CAHs who seek to demonstrate MU under the EHR Incentive Programs. We discussed, however, the National Coordinator's statutory authority to establish a voluntary certification program or programs for other types of HIT besides the EHR technology that could be used to demonstrate meaningful use. We explained that any steps towards certifying other types of HIT, including EHR technology such as “Complete EHRs” or “EHR Modules” for settings other than inpatient or ambulatory, would first require the Secretary to adopt certification criteria for other types of HIT and/or other types of health care settings. With this consideration, we sought public comment on whether we should focus any certification efforts towards the HIT used by health care providers that are ineligible to receive incentives under the EHR Incentive Programs.

In particular, we requested comments on whether we should consider adopting certification criteria for other health care settings, such as the long-term care, post-acute care, and mental and behavioral health settings. We asked that commenters specify the certification criteria that would be appropriate as well as the benefits they believe a regulatory approach would provide. Last, we asked that the public consider whether the private sector could alternatively address any perceived need or demand for such certification and specifically mentioned that the Certification Commission for Health Information Technology (CCHIT) has certification programs for long-term and post-acute care as well as behavioral health EHR technology.

Comments. Commenters strongly supported certification for other health care settings. A few commenters suggested that we develop certification criteria for other health care settings. However, the majority of commenters also noted that the lack of financial incentives for other health care settings (e.g., long term, post acute, home health, hospice, and behavioral settings) was a significant barrier and would render attempts to adopt certification or certification criteria for other health care settings infeasible. Multiple commenters noted that voluntary certification programs for other health care settings have been developed by the private sector with industry-wide stakeholder input. Commenters specifically pointed to the certification programs run by the CCHIT, which cover long-term and post-acute care, skilled nursing facilities, and home health. Comments stated that private sector certification programs provide for greater flexibility, such as being able to revise and develop standards more in line with the pace of technology development. Commenters also noted that these programs are synchronized with applicable standards adopted to support MU, such as standards for transitions of care and privacy and security.

Commenters recommended that we focus on interoperability and health information exchange among all health care settings. Specifically, commenters suggested that we identify a subset of MU certification criteria and standards that support standards-based exchange of health information that protect the privacy and security of the health information being exchanged. Some commenters also suggested that we identify certification criteria that would support the ability of providers practicing in other health care settings to comply with federal reporting requirements. Commenters also recommended that we encourage EHR technology developers to obtain certification for EHR Modules that would specifically support these types of capabilities, like the exchange of a transition of care/referral summary.

Response. We appreciate the interest in other health care settings expressed by commenters. We agree that it makes good policy sense to support interoperability and the secure electronic exchange of health information between all health care settings. We believe the adoption of EHR technology certified to a minimal amount of certification criteria adopted by the Secretary can support this goal. To this end, we encourage EHR technology developers to certify EHR Modules to the transitions of care certification criteria (§ 170.314(b)(1) and (2)) as well as any other certification criteria that may make it more effective and efficient for EPs, EHs, and CAHs to electronically exchange health information with health care providers in other health care settings. The adoption of EHR technology certified to these certification criteria can facilitate the secure electronic exchange of health information. We concur with commenters that there are currently private sector organizations that are addressing requests for certification programs for other health care settings.

VII. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995 (PRA), agencies are required to provide 60-day notice in the Federal Register and solicit public comment on a proposed collection of information before it is submitted to the Office of Management and Budget for review and approval. In order to fairly evaluate whether an information collection should be approved by the Office of Management and Budget, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues:

1. Whether the information collection is necessary and useful to carry out the proper functions of the agency;

2. The accuracy of the agency's estimate of the information collection burden;

3. The quality, utility, and clarity of the information to be collected; and

4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

In the Proposed Rule, published March 7, 2012 (77 FR 13832), we solicited public comment on each of these issues for revisions to OMB control number 0990-0378. We did not receive any comments on this collection of information. We have finalized at § 170.523(f)(8) the requirement, as proposed, for ONC-ACBs to additionally report to ONC a hyperlink with each EHR technology they certify that provides the public with the ability to access the test results used to certify Complete EHRs and EHR Modules. Having not obtained any information that would suggest we reconsider our original burden estimates, we have maintained those same estimates.

Abstract

Under the ONC HIT Certification Program, accreditation organizations that wish to become the ONC-Approved Accreditor (ONC-AA) must submit certain information, organizations that wish to become an ONC-Authorized Certification Bodies (ONC-ACBs) must submit the information specified by the application requirements, and ONC-ACBs must comply with collection and reporting requirements, records retention requirements, and submit annual surveillance plans and annually report surveillance results. These collections of information were approved under OMB control number 0990-0378. In the Proposed Rule, we proposed to revise § 170.523(f) and, correspondingly, proposed to revise OMB control number 0990-0378 by requiring ONC-ACBs to include one additional data element in the list of information about Complete EHRs and EHR Modules they report to ONC.

Section 170.523(f) requires an ONC-ACB to provide ONC, no less frequently than weekly, a current list of Complete EHRs and/or EHR Modules that have been certified as well as certain minimum information about each certified Complete EHR and/or EHR Module. We proposed to require ONC-ACBs to additionally report to ONC a hyperlink with each EHR technology they certify that provides the public with the ability to access the test results used to certify the EHR technology. We proposed to add this requirement at § 170.523(f)(8).

For the purposes of estimating this additional potential burden, we used the following assumptions. We assumed that all of the estimated applicants will apply and become ONC-ACBs (i.e., 6 applicants) and that they will report weekly (i.e., respondents will respond 52 times per year). We assumed an equal distribution among ONC-ACBs in certifying EHR technology on a weekly basis. As such, based on the number of Complete EHRs and EHR Modules listed on the CHPL at the end of September of 2011 (approximately one year since the CHPL's inception), we estimated that, on average, each ONC-ACB will report 4 test results hyperlinks to ONC on a weekly basis.

We believe that it will take approximately 5 minutes to report each hyperlink to ONC. Therefore, as reflected in the table below, we estimated an additional 20 minutes of work per ONC-ACB each week. Under the regulatory impact statement section, we discuss the estimated costs associated with reporting the hyperlinks to ONC.

With the additional collection of information at § 170.523(f)(8), we added 103 burden hours to our burden estimate in OMB control number 0990-0378. Our estimates for the total burden hours under OMB control number 0990-0378 are expressed in the table below.

VII. Regulatory Impact Statement

A. Statement of Need

Section 3004(b)(1) of the PHSA requires the Secretary to adopt an initial set of standards, implementation specifications, and certification criteria. On January 13, 2010, the Department issued an interim final rule with a request for comments to adopt an initial set of standards, implementation specifications, and certification criteria. On July 28, 2010, the Department published in the Federal Register a final rule to complete the adoption of the initial set of standards, implementation specifications, and certification criteria. Collectively, the initial set is referred to as the 2011 Edition EHR certification criteria. This final rule adopts another edition of standards, implementation specifications, and certification criteria that we refer to as the 2014 Edition EHR certification criteria. The 2014 Edition EHR certification criteria support the MU objectives and measures under the EHR Incentive Programs and will be used to test and certify EHR technology (Complete EHRs and EHR Modules). EPs, EHs, and CAHs must adopt and implement certified Complete EHRs and/or certified EHR Modules in order to have CEHRT. EPs, EHs, and CAHs who seek to qualify for incentive payments under the EHR Incentive Programs are required by statute to use CEHRT.

B. Overall Impact

We have examined the impact of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).

1. Comment and Response

Comments. A few other commenters stated we did not account for the costs that public health agencies will incur by having to meet the standards we adopt for certification criteria that support reporting to public health agencies. Some commenters stated that the regulatory impact analysis does not account for costs that EPs, EHs, and CAHs will incur in adopting and implementing CEHRT. One commenter suggested that we should increase our average overall hours for development and preparation of EHR technology for certification to the 2014 Edition EHR certification criteria by a multiplier of four to account for integration of these new features into current EHR workflows.

Response. The information technology public health agencies use or would need to employ or modify in order to receive data according to the standards we adopt for EHR technology certification is not within the scope of this rulemaking. In promulgating this final rule, we have considered the standards adopted by public health agencies before including them in the relevant certification criteria.

The costs that EPs, EHs, and CAHs will incur in adopting and implementing certified Complete EHRs and certified EHR Modules are not within the scope of this final rule. Those costs would include the costs of integrating new features into their EHR workflows. Those costs are estimated in the Stage 2 final rule published elsewhere in this issue of the Federal Register.

2. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We have determined that this final rule is not an economically significant rule because our primary estimate of the costs to prepare Complete EHRs and EHR Modules to be tested and certified will be less than $100 million in any given year. Nevertheless, because of the public interest in this final rule, we have prepared an RIA that to the best of our ability presents the costs and benefits of the final rule.

a. Costs

This rule adopts standards, implementation specifications, and certification criteria that establish the capabilities that EHR technology would need to demonstrate to be certified. Our analysis focuses on the direct effects of the provisions of this final rule—the costs incurred by EHR technology developers to develop and prepare Complete EHRs and EHR Modules to be tested and certified in accordance with the certification criteria adopted by the Secretary. That is, we focus on the technological development and preparation costs necessary for a Complete EHR or EHR Module already certified to the 2011 Edition EHR certification criteria to be upgrade to the adopted 2014 Edition EHR certification criteria and for developing a new Complete EHR or EHR Module to meet the 2014 Edition EHR certification criteria. The estimated costs for having EHR technology actually tested and certified were discussed in the Permanent Certification Program final rule (76 FR 1318-23). Last, we estimate the costs for ONC-ACBs to report to ONC hyperlinks to the test results used to certify EHR technology.

i. Development and Preparation Costs for 2014 Edition EHR Certification Criteria

The development costs we estimate are categorized based on the type of 2014 Edition EHR certification criteria discussed in this final rule (i.e., new, revised, and unchanged). The numbers of Complete EHRs and EHR Modules that we estimate will be developed to each 2014 Edition EHR certification criterion are based on the statistics we obtained from the CHPL on July 6, 2012. We attempted to identify the total number of Complete EHRs and EHR Modules that were developed to the 2011 Edition EHR certification criteria as of July 6, 2012. By this we mean that we first attempted to discern how many Complete EHRs and EHR Modules were certified that would not constitute a newer version of the same EHR technology. Second, we attempted to determine how many certified Complete EHRs and certified EHR Modules shared much of the same development costs. For example, when a Complete EHR is certified first and then an EHR technology developer subsequently seeks one or more EHR Module certifications for portions of that Complete EHR in order to provide its customers with more options. Using this number, we adjusted it based on additional considerations unique to the 2014 Edition EHR certification criteria such as the adoption of optional certification criteria, certification criteria included in the Base EHR definition, and the revised CEHRT definition. The revised CEHRT definition will only require EPs, EHs, and CAHs to possess the CEHRT they need to demonstrate MU for the stage they seek to accomplish, which could conceivably directly affect the number of EHR technologies developed to certain certification criteria that support MU menu objectives and measures. Using the final estimate of Complete EHRs and EHR Modules that we believe will be developed to meet each certification criterion, we have established an estimated range of 10% less and 10% more EHR technologies being developed to each 2014 Edition EHR certification criterion. We believe this will account for potential new entrants to the market as well as for those EHR technologies developed to meet the 2011 Edition EHR certification criteria that may not be upgraded to the 2014 Edition EHR certification criteria because of such factors and company mergers or acquisitions and the loss of market share for some Complete EHRs and EHR Modules. For unchanged certification criteria, we have only calculated development and preparation costs for a potential 10% increase in new EHR technologies being developed and prepared to meet the certification criteria.

As noted in the Proposed Rule, we are not aware of an available independent study (e.g., a study capturing the efforts and costs to develop and prepare Complete EHRs and EHR Modules to meet the requirements of the 2011 Edition EHR certification criteria) that we could rely upon as a basis for estimating the efforts and costs required to develop and prepare EHR technology to meet the 2014 Edition EHR certification criteria. Therefore, we have relied upon our own research to estimate the effort required to develop and prepare EHR technology to meet the requirements of the 2014 Edition EHR certification criteria. We have identified 3 levels of effort that we believe can be associated with the development and preparation of EHR technology to meet the requirements of the 2014 Edition EHR certification criteria. These levels of effort are the average range of hours we would expect to be necessary to develop EHR technology to meet the requirements of the 2014 Edition EHR certification criteria. This means that a few EHR technology developers' costs may be less than this range and a few may exceed the range. Level 1 is for certification criteria that we believe will require the least amount of effort to develop and prepare EHR technology for testing and certification to the criteria, with a range of 40-100 hours. Level 2 is for certification criteria that we believe will require a moderate amount of effort to develop and prepare EHR technology for testing and certification to the criteria, with a range of 100-300 hours. Level 3 is for certification criteria that we believe will require the most amount of effort to develop and prepare EHR technology for testing and certification to the criteria, with a range of 300-400 hours.

We have based the effort levels on the hours necessary for a software developer to develop and prepare the EHR technology for testing and certification. The U.S. Department of Labor, Bureau of Labor Statistics estimates that the mean hourly wage for a software developer is $44.27. We have also calculated the costs of an employee's benefits. We have calculated these costs by assuming that an employer expends thirty-six percent (36%) of an employee's hourly wage on benefits for the employee. We have concluded that a 36% expenditure on benefits is an appropriate estimate because it is the routine percentage used by HHS for contract cost estimates. We have rounded the average software developer's wage with benefits to $60 per hour.

To calculate our low cost estimates for each certification criterion in the tables below, we have multiplied the low number of the estimated range of EHR technologies expected to be developed and prepared by the low number of estimated hours (“level of effort” described above) for a software developer to develop and prepare the EHR technologies for testing and certification. To calculate our high cost estimates for each certification criterion in the tables below, we have multiplied the high number of the estimated range of EHR technologies expected to be developed and prepared to the criterion by the high number of estimated hours (“level of effort” described above) for a software developer to develop and prepare the EHR technologies for testing and certification. For the following tables (Tables 7 through Table 13), dollar amounts are expressed in 2012 dollars.

In comparison to the listed certification criteria in the regulatory impact analysis for the Proposed Rule, we note the following changes based on the certification criteria we adopted. We have included the two new adopted certification criteria: data portability (§ 170.314(b)(7); and quality management systems (§ 170.414(g)(4)). We have moved the proposed unchanged certification criteria that have been adopted as revised certification criteria into the revised certification criteria section. These include: “drug-formulary checks” (§ 170.314(a)(10)); “vital signs, body mass index, and growth charts” (§ 170.314(a)(4)); “smoking status” (§ 170.314(a)(11)); “patient lists” (§ 170.314(a)(14)); and “patient reminders” (§ 170.314(a)(15)) [now combined and collectively referred to as “patient list creation”]. Last, we have moved the new “view, download, and transmit to 3rd party” certification criterion (§ 170.314(e)(1)) from a level 3 effort down to a level 2 effort. We changed the level of effort because we did not adopt our proposals regarding images and WCAG 2.0 level AA for this certification criterion and because many of the EHR technologies that will be designed to meet this certification criterion have already met the 2011 Edition “timely access” certification criterion (§ 170.304(g)).

New Certification Criteria

Revised Certification Criteria

Unchanged Certification Criteria

ii. Overall Development and Preparation Estimated Costs Over a 3-Year Period

In total, we estimate the overall costs for a 3-year period to be $101.90 million to $288.94 million, with a cost mid-point of approximately $195.42 million. If we were to evenly distribute the overall estimated costs to develop and prepare Complete EHRs and EHR Modules between calendar years 2012 and 2014, we believe they would likely be in the range of $33.97 million to $96.31 million per year with an annual cost mid-point of approximately $65.14 million. We have used the mid-point cost as our primary annual cost estimate for this regulatory impact analysis.

We do not believe that the estimated costs will be spread evenly over these three years due to market pressures, primarily consisting of EPs, EHs, and CAHs needing to adopt and implement EHR technology certified to the 2014 Edition EHR certification criteria in order to have CEHRT in FY/CY 2014. Based on this market pressure, in the Proposed Rule, we distributed the majority of the estimated costs in 2012 (40%) and 2013 (50%), while only distributing 10% of the estimated costs in 2014. With the additional flexibility that we have adopted in the CEHRT definition for FY/CY 2013, namely permitting EPs, EHs, and CAHs to meet the CEHRT definition for FY/CY 2014 in FY/CY 2013, we believe that the market pressure for EHR technology certified to the 2014 Edition EHR certification criteria to be available sooner will further increase. Given this consideration and the fact that we have issued this final rule sooner than we anticipated when publishing the Proposed Rule, we have revised our distribution of estimated costs to place more of the total estimated costs in 2012. As such, the estimated costs attributable to this final rule are distributed as follows: 45% for 2012, 45% for 2013, and 10% for 2014. This distribution of estimated costs for the year in which this final rule is published is also consistent with the distribution we used in the S&CC July 2010 final rule (75 FR 44648) for the year in which it was published. Table 14 below expresses the distribution of estimated costs for 2012 through 2014 in 2012 dollars.

iii. Costs for Reporting Test Results Hyperlinks

Costs to ONC-ACBs

Under § 170.523(f)(8), ONC-ACBs are required to provide ONC, no less frequently than weekly, a hyperlink with each EHR technology it certifies that provides the public with the ability to access the test results used to certify the EHR technology. As stated in the collection of information section, the reporting of this information will be required on a weekly basis and it will take each ONC-ACB about 20 minutes to prepare and electronically transmit an estimated four test results hyperlinks with the other required information to ONC each week.

We believe that an employee equivalent to the Federal Classification of GS-9 Step 1 could report the hyperlink to ONC. We have utilized the corresponding employee hourly rate for the locality pay area of Washington, DC, as published by OPM, to calculate our cost estimates. We have also calculated the costs of the employee's benefits while completing the specified tasks. We have calculated these costs by assuming that an ONC-ACB expends thirty-six percent (36%) of an employee's hourly wage on benefits for the employee. We have concluded that a 36% expenditure on benefits is an appropriate estimate because it is the routine percentage used by HHS for contract cost estimates. Our cost estimates are expressed in Table 15 below and are expressed in 2012 dollars.

To estimate the highest possible cost, we assume that all of the applicants we estimated for the purposes of the collection of information (i.e., six) will apply and become ONC-ACBs under the ONC HIT Certification Program. Therefore, we estimate the total annual development and reporting cost under the ONC HIT Certification Program to be $3,136 (rounded using a total of 103 hours).

Costs to the Federal Government

We do not believe that the collection of information requirement of § 170.523(f)(8), through our posting of test results hyperlinks on the CHPL, will require us to incur any additional costs than the costs we estimated for having personnel post a list of all certified Complete EHRs and certified EHR Modules on our Web site (i.e., the CHPL), which was $10,784 on an annualized basis (76 FR 1323).

b. Benefits

We believe that there will be several benefits that may arise from this final rule. Foremost, EHR technology certified to the 2014 Edition EHR certification criteria will be capable of supporting EPs, EHs, and CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The 2014 Edition EHR certification criteria also promote enhanced interoperability, functionality, utility, and security of EHR technology through the capabilities they include and the standards they require EHR technology to meet for certification. The capabilities specified in the 2014 Edition EHR certification criteria will help ensure that health care providers have the necessary information technology tools to improve patient care, and reduce medical errors and unnecessary tests. The standards adopted will aid in fostering greater interoperability.

The provisions in this final rule will increase the competition and innovation in the HIT marketplace that was spurred by the Secretary's adoption of the 2011 Edition EHR certification criteria. The revised CEHRT definition, the process for approving newer versions of minimum standards, and the revised privacy and security certification of EHR Modules will reduce the regulatory burden and add flexibility for EHR technology developers, EPs, EHs, and CAHs. Further, the “splitting” of certain certification criteria into multiple certification criteria should increase the opportunity and flexibility for EHR technology developers to have more EHR technology eligible for certification. Last, the provisions of this final rule are supportive of other initiatives, such as the Partnership for Patients, Medicare Shared Savings Program, and other quality measure programs administered by CMS.

3. Regulatory Flexibility Act

The RFA requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities.

The Small Business Administration (SBA) establishes the size of small businesses for Federal government programs based on average annual receipts or the average employment of a firm. While Complete EHRs and EHR Module developers represent a small segment of the overall information technology industry, we believe that the entities impacted by this final rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services” specified at 13 CFR 121.201 where the SBA publishes “Small Business Size Standards by NAICS Industry.” The SBA size standard associated with this NAICS code is set at $25.5 million in annual receipts which “indicates the maximum allowed for a concern and its affiliates to be considered small entities.”

Based on our analysis, we believe that there is enough data generally available to establish that between 75% and 90% of entities that are categorized under the NAICS code 541511 are under the SBA size standard, but note that the available data does not show how many of these entities will develop a Complete EHR or EHR Module. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many Complete EHR and EHR Module developers are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult to locate empirical data related to many of the Complete EHR and EHR Module developers to correlate to the SBA size standard. However, although not correlated to the size standard for NAICS code 541511, we do have information indicating that over 60% of EHR technology developers that have had Complete EHRs and/or EHR Modules certified to the 2011 Edition EHR certification criteria have less than 51 employees.

We estimate that this final rule will have effects on Complete EHR and EHR Module developers, some of which may be small entities. However, we believe that we have established the minimum amount of requirements necessary to accomplish our policy goals, including a reduction in regulatory burden and additional flexibility for the regulated community; and that no additional appropriate regulatory alternatives could be developed to lessen the compliance burden associated with this final rule. In order for a Complete EHR or EHR Module to provide the capabilities that an EP, EH, or CAH would be required to use under the Stage 2 final rule, it will need to comply with the applicable 2014 Edition EHR certification criteria adopted by the Secretary. Moreover, we note that this final rule does not impose the costs cited in the regulatory impact analysis as compliance costs, but rather as investments which Complete EHR and EHR Module developers voluntarily take on and expect to recover with an appropriate rate of return. Accordingly, we do not believe that this final rule will create a significant impact on a substantial number of small entities. The Secretary certifies that this final rule will not have a significant impact on a substantial number of small entities.

4. Executive Order 13132—Federalism

Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a final rule that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. Nothing in this final rule imposes substantial direct compliance costs on state and local governments, preempts state law or otherwise has federalism implications. We are not aware of any state laws or regulations that are contradicted or impeded by any of the standards, implementation specifications, or certification criteria that the Secretary has adopted.

5. Unfunded Mandates Reform Act of 1995

Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. The current inflation-adjusted statutory threshold is approximately $139 million. This final rule will not impose an unfunded mandate on state, local, and tribal governments or on the private sector that will reach the threshold level.

The Office of Management and Budget reviewed this final rule.

List of Subjects in 45 CFR Part 170

• Computer technology
• Electronic health record
• Electronic information system
• Electronic transactions
• Health
• Health care
• Health information technology
• Health insurance
• Health records
• Hospitals
• Incorporation by reference
• Laboratories
• Medicaid
• Medicare
• Privacy
• Reporting and recordkeeping requirements
• Public health
• Security

For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, part 170, is amended as follows:

PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

1. The authority citation for part 170 continues to read as follows:

Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 552.

2. In § 170.102, remove the “Complete EHR” definition, add in alphanumeric order the definitions “2011 Edition EHR certification criteria,” “2014 Edition EHR certification criteria,” “Base EHR,” “Common MU Data Set,” “Complete EHR, 2011 Edition,” and “Complete EHR, 2014 Edition,” and revise the definition of “Certified EHR Technology” to read as follows:

3. Add § 170.202 to read as follows:

4. Add § 170.204 to read as follows:

5. In § 170.205, republish the introductory text and add paragraphs (a)(3), (d)(3), (e)(3), and (g) through (k) to read as follows:

6. In § 170.207, republish the introductory text and add paragraphs (a)(3), (b)(3), (b)(4), revise paragraphs (c), (d), (e), and (f) and add paragraphs (g) through (j) to read as follows:

7. In § 170.210:

a. Republish the introductory text;

b. In paragraph (a)(1), add the phrase “, (January 27, 2010)” after “140-2”;

c. In paragraph (c), remove “180-3 (October, 2008))” and add in its place “180-4 (March 2012))”; and

d. Add paragraphs (e) through (h) to read as follows:

8. Amend § 170.299 by revising paragraphs (b) through (j) and adding paragraphs (k) through (n) to read as follows:

9. In § 170.300, republish paragraphs (a) and (b), revise paragraph (c) and add paragraph (d) to read as follows:

10. Add § 170.314 as follows:

11. In subpart E, consisting of §§ 170.500 through 170.599, remove the phrases “permanent certification program for HIT” and “permanent certification program” and add in their place “ONC HIT Certification Program” wherever they may occur.

12. Amend § 170.502 by revising the definition of “providing or provide an updated certification” to read as follows:

13. In § 170.523, republish the introductory text, add paragraph (f)(8), revise paragraphs (k)(1)(i) and (ii), and add paragraph (k)(1)(iii) to read as follows:

14. In § 170.550, revise paragraph (e), redesignate paragraph (f) as paragraph (g), and add a new paragraph (f) to read as follows:

15. Revise § 170.555 to read as follows: