13832 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

DEPARTMENT OF HEALTH AND 

HUMAN SERVICES 

Office of the Secretary 

45 CFR Part 170 

RIN 0991–AB82 

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: Proposed rule. 

SUMMARY: Under section 3004 of the 

Public Health Service Act, the Secretary 

of Health and Human Services is 

proposing to revise the initial set of 

standards, implementation 

specifications, and certification criteria 

adopted in an interim final rule 

published on January 13, 2010, and a 

subsequent final rule that was published 

on July 28, 2010, as well as to adopt 

new standards, implementation 

specifications, and certification criteria. 

The proposed new and revised 

certification criteria would establish the 

technical capabilities and specify the 

related standards and implementation 

specifications that Certified Electronic 

Health Record (EHR) Technology would 

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 notice of 

proposed rulemaking also proposes 

revisions to the permanent certification 

program for health information 

technology, which includes changing 

the program’s name. 

DATES: To be assured consideration, 

written or electronic comments must be 

received at one of the addresses 

provided below, no later than 5 p.m. on 

May 7, 2012. 

ADDRESSES: You may submit comments, 

identified by RIN 0991–AB82, by any of 

the following methods (please do not 

submit duplicate comments). Because of 

staff and resource limitations, we cannot 

accept comments by facsimile (FAX) 

transmission. 

• Federal eRulemaking Portal: Follow 

the instructions for submitting 

comments. Attachments should be in 

Microsoft Word, Microsoft Excel, or 

Adobe PDF; however, we prefer 

Microsoft Word. http:// 

www.regulations.gov. 

• Regular, Express, or Overnight Mail: 

Department of Health and Human 

Services, Office of the National 

Coordinator for Health Information 

Technology, Attention: 2014 Edition 

EHR Standards and Certification Criteria 

Proposed Rule, Hubert H. Humphrey 

Building, Suite 729D, 200 Independence 

Ave. SW., Washington, DC 20201. 

Please submit one original and two 

copies. 

• Hand Delivery or Courier: Office of 

the National Coordinator for Health 

Information Technology, Attention: 

2014 Edition EHR Standards and 

Certification Criteria Proposed Rule, 

Hubert H. Humphrey Building, Suite 

729D, 200 Independence Ave. SW., 

Washington, DC 20201. Please submit 

one original and two copies. (Because 

access to the interior of the Hubert H. 

Humphrey Building is not readily 

available to persons without federal 

government identification, commenters 

are encouraged to leave their comments 

in the mail drop slots located in the 

main lobby of the building.) 

Enhancing the Public Comment 

Experience: To enhance the accessibility 

and ease with which the public may 

comment on this proposed rule, a copy 

will be made available in Microsoft 

Word format. We believe this version 

will make it easier for commenters to 

access and copy portions of the 

proposed rule for use in their individual 

comments. Additionally, a separate 

document will be made available for the 

public to use to provide comments on 

the proposed rule. This document is 

meant to provide the public with a 

simple and organized way to submit 

comments on the certification criteria 

and associated standards and 

implementation specifications and 

respond to specific questions posed in 

the preamble of the proposed rule. 

While use of this document is entirely 

voluntary, we encourage commenters to 

consider using the document in lieu of 

unstructured comments or to use it as 

an addendum to narrative cover pages. 

Because of the technical nature of this 

proposed rule, we believe that use of the 

document may facilitate our review and 

understanding of the comments 

received. The Microsoft Word version of 

the proposed rule and the document 

that can be used for providing 

comments can be found at http:// 

www.regulations.gov as part of this 

proposed rule’s docket and on ONC’s 

Web site (http://healthit.hhs.gov). 

Inspection of Public Comments: All 

comments received before the close of 

the comment period will be available for 

public inspection, including any 

personally identifiable or confidential 

business information that is included in 

a comment. Please do not include 

anything in your comment submission 

that you do not wish to share with the 

general public. Such information 

includes, but is not limited to: A 

person’s social security number; date of 

birth; driver’s license number; state 

identification number or foreign country 

equivalent; passport number; financial 

account number; credit or debit card 

number; any personal health 

information; or any business 

information that could be considered 

proprietary. We will post all comments 

that are received before the close of the 

comment period at http:// 

www.regulations.gov. 

Docket: For access to the docket to 

read background documents or 

comments received, go to http:// 

www.regulations.gov or the Department 

of Health and Human Services, Office of 

the National Coordinator for Health 

Information Technology, Hubert H. 

Humphrey Building, Suite 729D, 

200 Independence Ave. SW., 

Washington, DC 20201 (call ahead to the 

contact listed below to arrange for 

inspection). 

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: 

Commonly Used Acronyms 

CAH Critical Access Hospital 

CDA Clinical Document Architecture 

CDS Clinical Decision Support 

CEHRT Certified EHR Technology 

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–CM International Classification of 

Diseases, 10th Revision, Clinical 

Modification 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13833 

ICD–10–PCS International Classification of 

Diseases, 10th Revision, Procedure Coding 

System 

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. Initial Set of Standards, Implementation 

Specifications, and Certification Criteria 

Interim Final and Final Rules 

2. Medicare and Medicaid EHR Incentive 

Programs Stage 1 Proposed and Final 

Rules 

3. HIT Certification Programs Proposed 

Rule and the Temporary and Permanent 

Certification Programs Final Rules 

III. Provisions of the Proposed Rule affecting 

Standards, Implementation 

Specifications and Certification Criteria 

A. 2014 Edition EHR Certification Criteria 

1. Applicability 

2. Scope of a Certification Criterion for 

Certification 

3. Explanation and Revision of Terms Used 

in Certification Criteria 

4. New Certification Criteria 

a. Ambulatory and Inpatient Setting 

b. Ambulatory Setting 

c. Inpatient Setting 

5. Revised Certification Criteria 

a. Ambulatory and Inpatient Setting 

b. Ambulatory Setting 

c. Inpatient Setting 

6. Unchanged Certification Criteria 

a. Refinements to Unchanged Certification 

Criteria 

b. Unchanged Certification Criteria 

Without Refinements 

7. Gap Certification 

B. Redefining Certified EHR Technology 

and Related Terms 

1. Proposed Revisions to the Definition of 

Certified EHR Technology 

2. Base EHR 

3. Complete EHR 

4. Certifications Issued for Complete EHRs 

and EHR Modules 

5. Adaptations of Certified Complete EHRs 

or Certified EHR Modules 

IV. Provisions of the Proposed 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. Base EHR Representation 

V. Request for Additional Comments 

A. Certification and Certification Criteria 

for Other Health Care Settings 

B. 2014 Edition EHR Accounting of 

Disclosures Certification Criterion 

C. Disability Status 

D. Data Portability 

E. EHR Technology Price Transparency 

VI. Response to Comments 

VII. Collection of Information Requirements 

VIII. Regulatory Impact Statement 

A. Statement of Need 

B. Overall Impact 

1. 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 

Costs Over a 3-Year Period 

iii. Costs for Reporting Test Results 

Hyperlinks 

b. Benefits 

2. Regulatory Flexibility Act Analysis 

3. Executive Order 13132—Federalism 

4. 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. This proposed rule serves 

as the Secretary’s publication of 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 adoption by the Secretary, under 

sections 3004(a)(3) and 3004(b)(3) of the 

PHSA, of the standards, implementation 

specifications, and certification criteria 

proposed in this rule would 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’’) beginning 

with the EHR reporting periods in 

Federal fiscal year (FY) 2014 for EHs 

and CAHs and calendar year (CY) 2014 

for EPs (hereafter referred to as ‘‘FY/CY 

2014’’). 

Consistent with Executive Order 

13563, we have undertaken a 

retrospective review of our regulations. 

The proposed rule introduces multiple 

means for reducing regulatory burden 

and increasing regulatory flexibility for 

stakeholders, including proposed 

changes to current regulatory 

requirements and approaches. 

B. Summary of Major Provisions 

1. Overview of the 2014 Edition EHR 

Certification Criteria 

We propose to adopt certification 

criteria that will support the proposed 

changes to the EHR Incentive Programs, 

including the new and revised 

objectives and measures for Stages 1 and 

2 of MU proposed by CMS. The 

certification criteria we propose for 

adoption would also enhance care 

coordination, patient engagement, and 

the security, safety, and efficacy of EHR 

technology. For clarity, we refer to the 

certification criteria proposed for 

adoption as the 2014 Edition EHR 

certification criteria and the currently 

adopted certification criteria as the 2011 

Edition EHR certification criteria. To 

permit efficient certification methods 

and reduce regulatory burden, we have 

identified those certification criteria that 

we propose to include in 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 would 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.7 

of this preamble). 

2. Certified EHR Technology 

Since the publication of the Standards 

and Certification Criteria final rule in 

July 2010, HHS has received significant 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13834 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

feedback from stakeholders suggesting 

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, this rule proposes to revise the 

definition of CEHRT. Of most 

significance, beginning with the EHR 

reporting periods in FY/CY 2014, we are 

proposing a revised definition of CEHRT 

that would provide more flexibility for 

EPs, EHs, and CAHs. In sum, in order 

to have EHR technology that meets the 

definition of CEHRT for FY and CY 

2014 and subsequent years, EPs, EHs, 

and CAHs would be required to have a 

Base EHR (EHR technology that 

includes fundamental capabilities all 

providers would need to have) as well 

as the additional EHR technology 

necessary to meet the MU objectives and 

measures for the stage of MU that they 

seek to meet and to capture, calculate, 

and report clinical quality measures. We 

further discuss this proposal, including 

the concept of a ‘‘Base EHR’’ in section 

III.C (Redefining Certified EHR 

Technology and Related Terms). 

3. ONC HIT Certification Program 

This rule proposes revisions to the 

permanent certification program which 

aim to 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 rule 

also proposes to revise the process for 

permitting the use of newer versions of 

‘‘minimum standard’’ code sets. The 

proposed new approach seeks to reduce 

regulatory complexity and burden by 

providing the industry with the 

flexibility to quickly utilize newer 

versions of adopted ‘‘minimum 

standard’’ code sets. The rule proposes 

to modify the certification processes 

ONC–Authorized Certification Bodies 

(ONC–ACBs) would need to follow for 

certifying EHR Modules as a means of 

providing clear implementation 

direction and compliance with 

proposed new certification criteria, and 

also proposes to reduce 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 that must be 

a part of every EP’s, EH’s, and CAH’s 

CEHRT. To increase clarity for the HIT 

market, we propose methods for clearly 

representing certified Complete EHRs 

and certified EHR Modules, including 

the representation of a ‘‘Base EHR.’’ 

Finally, we propose to require that test 

results used for the certification of EHR 

technology be available to the public in 

an effort to increase transparency 

around the certification process. 

C. Costs and Benefits 

We determined that this proposed 

rule is not an economically significant 

rule as its overall costs will be less than 

$100 million per year. We have, 

however, estimated the costs and 

benefits of the proposed rule. 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 proposed 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 proposed revised definition of 

CEHRT for FY/CY 2014. We assume this 

factor will cause a greater number of 

developers to prepare EHR technology 

for testing and certification towards the 

end of 2012 and throughout 2013, rather 

than in 2014. As a result, we believe, as 

represented in Table 1, that the costs 

attributable to this proposed rule will be 

distributed as follows: 40% for 2012, 

50% for 2013, and 10% for 2014. The 

dollar amounts expressed in Table 1 are 

expressed in 2012 dollars. 

There are multiple potential benefits 

from the adoption of the proposed 

certification criteria in this rule. 

Foremost, EHR technology certified to 

the proposed certification criteria would 

be capable of supporting EPs, EHs, and 

CAHs’ attempts to demonstrate MU 

under the EHR Incentive Programs. The 

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. 

Proposals such as the revised definition 

of CEHRT, the availability of gap 

certification, and the proposed revisions 

to the permanent certification program, 

will, as noted, increase regulatory 

clarity, improve transparency, and add 

flexibility, while also reducing the 

regulatory burden on the HIT industry. 

Finally, we believe the proposals in this 

rule will support other initiatives, such 

as the Partnership for Patients. 

TABLE 1—ESTIMATED COSTS OF THE PROPOSED RULE: DISTRIBUTED TOTAL PREPARATION COSTS FOR COMPLETE EHR 

AND EHR MODULE DEVELOPERS (3-YEAR PERIOD)—TOTALS ROUNDED

Year Ratio percent 

Total low cost 

estimate 

($M) 

Total high cost 

estimate 

($M) 

Total average 

cost estimate 

($M) 

2012 ................................................................................................................. 40 36.80 95.01 65.91 

2013 ................................................................................................................. 50 46.01 118.76 82.38 

2014 ................................................................................................................. 10 9.20 23.75 16.48 

3–Year Totals ........................................................................................... ........................ 92.01 237.52 167.53 

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. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13835 

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, while 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. Initial Set of Standards, 

Implementation Specifications, and 

Certification Criteria Interim Final and 

Final 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) (the ‘‘S&CC July 2010 

final rule’’). 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 ‘‘EHR Incentive 

Programs Stage 1 final rule’’) (see 75 FR 

44314 for more information about MU 

and the Stage 1 requirements). 

2. Medicare and Medicaid EHR 

Incentive Programs Stage 1 Proposed 

and Final 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 EHR Incentive Programs 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. 

3. HIT Certification Programs Proposed 

Rule and the Temporary and Permanent 

Certification Programs Final 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13836 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

1When we refer to CMS’s Medicare and Medicaid 

EHR Incentive Programs Stage 2 proposed rule, we 

are referring to the NPRM published elsewhere in 

this issue of the Federal Register. 

Permanent Certification Program final 

rule’’). 

III. Provisions of the Proposed Rule 

Affecting Standards, Implementation 

Specifications, and Certification 

Criteria 

In the S&CC July 2010 final rule, the 

Secretary adopted certification criteria 

in title 45, part 170, §§ 170.302, 170.304, 

and 170.306 of the Code of Federal 

Regulations. To make a clear distinction 

between these previously adopted 

certification criteria and the ones 

discussed in this proposed rule, we will 

refer to 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’’ and 

propose to revise § 170.102 to add this 

definition. 

A. 2014 Edition EHR Certification 

Criteria 

This rule proposes 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 

refer to these new, revised, and 

unchanged certification criteria as the 

‘‘2014 Edition EHR certification 

criteria’’ and propose to add this term 

and its definition to § 170.102. 

Additionally, we propose to codify the 

2014 Edition EHR certification criteria 

in section 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. This approach, 

coupled with our reference to the 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 we propose to include in the 

2014 Edition EHR certification criteria. 

Further, we believe the inclusion of all 

2014 Edition EHR certification criteria 

in one regulatory section will simplify 

the regulatory framework for 

stakeholders. 

Many of the certification criteria that 

we propose in this rule are intended to 

support the MU objectives and measures 

proposed in the CMS Medicare and 

Medicaid EHR Incentive Programs Stage 

2 proposed rule (Stage 2 proposed 

rule) 1 as well as the reporting of MU 

objectives and measures and clinical 

quality measures (CQMs) to CMS. To 

the extent CMS may change (e.g., add, 

revise, or remove) MU objectives, 

measures, or reporting requirements in 

a final rule, we may also find it 

necessary or appropriate to change 

proposed supporting certification 

criteria. Commenters recommending 

changes to the proposed MU objectives 

and measures, CQMs, or reporting 

requirements should consider whether 

changes to the certification criteria 

would also be needed and offer those 

suggested changes. Similarly, 

commenters should consider and 

specify whether any of their suggested 

revisions to the proposed certification 

criteria would impact the proposals in 

CMS’s Stage 2 proposed rule. 

We discuss the new, revised, and 

unchanged certification criteria that we 

propose to adopt as the 2014 Edition 

EHR certification criteria in sections A.4 

through A.6 below. We specify where 

the proposed certification criteria would 

be included in § 170.314. We include a 

table at the beginning of the discussion 

of each certification criterion or criteria 

that specifies the MU objective that the 

proposed 2014 Edition EHR certification 

criterion or criteria and associated 

standards and implementation 

specifications support. The objective 

cited is either a proposed Stage 1 or 

Stage 2 objective that would be effective 

for the EHR reporting periods in FY/CY 

2014. We provide this frame of reference 

because we propose that beginning in 

FY/CY 2014 EHR technology would 

need to be certified to the 2014 Edition 

EHR certification criteria to meet the 

definition of CEHRT and the table 

permits commenters to easily associate 

the certification criterion with the MU 

objective it supports. We provide the 

rationale for the proposed certification 

criteria, including citing the 

recommendations of the HITPC and 

HITSC, where appropriate. Last, in 

certain instances, we specifically 

request comment on the maturity and 

industry-acceptance of various 

standards and implementation 

specifications. 

1. 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 propose to revise 

§ 170.300 to reflect our proposed 

regulatory structure for the 2014 Edition 

EHR certification criteria. We propose 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 propose 

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. 

2. Scope of a Certification Criterion for 

Certification 

In the certification programs final 

rules (75 FR 36176, 76 FR 1290–91) and 

the S&CC July 2010 final rule (75 FR 

44622), we clarified that a single 

certification criterion would encompass 

all of the specific capabilities referenced 

below the first paragraph level. As an 

example in the Permanent Certification 

Program final rule, we stated that the 

certification criterion at 45 CFR 170.302, 

paragraph ‘‘(f)’’ (the first paragraph 

level) identifies that the certification 

criterion relates to recording and 

charting vital signs. The certification 

criterion includes three specific 

capabilities at (f)(1), (2), and (3) (the 

second paragraph level): The ability to 

record, modify, and retrieve patients’ 

vital signs; the ability to calculate body 

mass index (BMI); and the ability to plot 

and display growth charts. We stated 

that we viewed the entire set of specific 

capabilities required by paragraph ‘‘(f)’’ 

(namely, (f)(1), (2), and (3)) as one 

certification criterion, and that the 

specific capability to calculate BMI 

would not be equivalent to one 

certification criterion. 

Based on our proposal to codify all 

the 2014 Edition EHR certification 

criteria in § 170.314, we are clarifying 

that certification to the certification 

criteria at § 170.314 would occur at the 

second paragraph level of the regulatory 

section. The first paragraph level in 

§ 170.314 would be used to organize the 

certification criteria into categories. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13837 

2http://www.plainlanguage.gov/howto/ 

wordsuggestions/simplewords.cfm#lm. 

These categories would be: 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, for this proposed 

rule, a certification criterion in 

§ 170.314 would be 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). For example, 

we propose to adopt the revised 

certification criterion for demographics 

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 in accordance 

with the standard specified in 

§ 170.207(k). Consequently, to meet the 

proposed certification criterion for 

demographics, 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. 

3. Explanation and Revision of Terms 

Used in Certification Criteria 

Certain terms are repeatedly used in 

the proposed 2014 Edition EHR 

certification criteria. Based on our 

experience and stakeholder feedback 

related to how terms in the 2011 Edition 

EHR certification criteria have been 

interpreted, we have determined that it 

is necessary in certain cases to select 

different terms. The following is a list of 

terms we repeatedly use in the proposed 

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 

further clarify 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 are 

replacing 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.2 In 

certification criteria in which this term 

is used, 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 wordprocessing 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 are 

proposing 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 note 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 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 only propose 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 are proposing to 

replace the term ‘‘generate’’ used in the 

2011 Edition EHR certification criteria 

with ‘‘create.’’ We believe ‘‘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. 

4. New Certification Criteria 

In the Permanent Certification 

Program final rule (76 FR 1302), we 

described new certification criteria as 

those that specify capabilities for which 

the Secretary has not previously 

adopted certification criteria. We further 

stated that new certification criteria also 

include certification criteria that were 

previously adopted for Complete EHRs 

or EHR Modules designed for a specific 

setting and are subsequently adopted for 

Complete EHRs or EHR Modules 

designed for a different setting (for 

example, if the Secretary previously 

adopted a certification criterion only for 

Complete EHRs or EHR Modules 

designed for an ambulatory setting and 

then subsequently adopts that 

certification criterion for Complete 

EHRs or EHR Modules designed for an 

inpatient setting). Based on our 

experience trying to appropriately 

categorize the certification criteria we 

propose to be part of the 2014 Edition 

EHR certification criteria, we have 

determined that our description of new 

certification criteria needs to be 

clarified. Accordingly, we list below the 

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. 

We propose to adopt new certification 

criteria that will support new MU 

objectives and associated measures, the 

reporting of MU measures, and will 

enable EHR technology to enhance 

patient engagement. Some of the new 

criteria would apply to both ambulatory 

and inpatient settings, while some 

certification criteria would only apply 

to one of the settings or would be new 

for a particular setting. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13838 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

3http://www.hl7.org/implement/standards/ 

product_brief.cfm?product_id=8. 

4http://www.nlm.nih.gov/research/umls/ 

Snomed/snomed_main.html. 5https://familyhistory.hhs.gov. 

a. Ambulatory and Inpatient Setting 

We propose to adopt 8 certification 

criteria that would be new certification 

criteria for both the ambulatory and 

inpatient settings. 

• Electronic notes 

MU Objective 

Record electronic notes in patient 

records. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(9) (Electronic notes) 

The HITSC recommended a 

certification criterion similar to the 2014 

Edition EHR certification criterion we 

propose at § 170.314(a)(9) (with specific 

reference to ‘‘physician, physician 

assistant, or nurse practitioner’’ 

electronic notes) to support the MU 

objective and measure recommended by 

the HITPC. CMS has not proposed the 

MU objective and measure for Stage 2, 

but has requested public comment on 

whether the objective and measure 

should be incorporated into Stage 2. 

Consistent with our discussion in the 

preamble section titled ‘‘Explanation 

and Revision of Terms Used in 

Certification Criteria,’’ we have replaced 

the terms ‘‘modify’’ and ‘‘retrieve’’ in 

the recommended criterion with 

‘‘change’’ and ‘‘access,’’ respectively. 

Additionally, we are providing the 

following clarifications for the 

electronic ‘‘search’’ capability. ‘‘Search’’ 

means the ability to search free text and 

data fields of electronic notes. It also 

means the ability to search the notes 

that any licensed health care 

professional has included within the 

EHR technology, including the ability to 

search for information across separate 

notes rather than just within notes. We 

believe that this certification criterion 

would encompass the necessary 

capabilities to support the performance 

of the MU objective and measure as 

discussed in the MU Stage 2 proposed 

rule. 

• Imaging 

MU Objective 

Imaging results and information are accessible through Certified EHR Technology. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(12) (Imaging) 

We propose to adopt the 2014 Edition 

EHR certification criterion at 

§ 170.314(a)(12) to support the 

performance of the proposed MU 

objective and measure. We clarify that 

the phrase ‘‘immediate electronic 

access’’ is intended to mean that a user 

should be able to electronically access 

images and their narrative 

interpretations directly and without, for 

example, having to login to a separate 

electronic system or repository. This 

access could be provided by multiple 

means, including, but not limited to, 

‘‘single sign-on’’ and ‘‘secure identity 

parameter passing.’’ We also note that 

there are data format standards for the 

transmission of imaging data (Digital 

Imaging and Communications in 

Medicine (DICOM)) that we reviewed 

for this certification criterion, but do not 

believe that the adoption of these 

standards is necessary to enable users to 

electronically access images and their 

narrative interpretations, as required by 

this certification criterion. We request 

public comment regarding whether 

there are appropriate and necessary 

standards and implementation 

specifications for this certification 

criterion. 

• Family health history 

MU Objective 

Record patient family health history as 

structured data. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(13) (Family health history) 

We propose to adopt the 2014 Edition 

EHR certification criterion at 

§ 170.314(a)(13) to support the 

performance of the proposed MU 

objective and measure. In defining 

family health history, this capability 

requires, at minimum, the ability to 

electronically record, change, and 

access the health history of a patient’s 

first-degree relatives. As proposed in the 

Stage 2 proposed rule, a first degree 

relative is a family member who shares 

about 50 percent of their genes with a 

particular individual in a family (first 

degree relatives include parents, 

offspring, and siblings). 

We considered adopting specific 

standards for this certification criterion, 

including the HL7 Pedigree standard 3

and the use of Systematized 

Nomenclature of Medicine—Clinical 

Terms (SNOMED-CT®) 4 terms for 

familial conditions. We seek comments 

on the maturity and breadth of industry 

adoption of the HL7 Pedigree standard 

format for export and import of family 

health history and the use of SNOMEDCT® terms for familial conditions and 

their inclusion, where appropriate, on a 

patient’s problem list. We also note that 

the Surgeon General has 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.5 We seek comments on the 

maturity and breadth of adoption of this 

tool and its export format. 

• Amendments 

MU Objective 

Protect electronic health information created or maintained by the Certified 

EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(4) (Amendments) 

We propose to adopt the 2014 Edition 

EHR certification criterion at 

§ 170.314(d)(4). Based on HITPC 

recommendations submitted to the 

National Coordinator on July 25, 2011, 

the HITSC recommended two versions 

of a draft 2014 Edition EHR certification 

criterion for amendments. As part of its 

recommendation, the HITPC (based on 

the work done by its Privacy and 

Security Tiger Team) noted that the 

technical capabilities included in a 

certification criterion should be ‘‘kept as 

simple as possible and evolve over time 

to greater complexity, including 

potentially greater standardization and 

automation.’’ The HITPC also 

recommended that this certification 

criterion be adopted to assist 

stakeholders by providing them with 

some of the technical tools to comply 

with parts of the Health Insurance 

Portability and Accountability Act of 

1996 (HIPAA) Privacy Rule 

requirements specified at 45 CFR 

164.526. In addition, the HITPC 

considered issues related to ‘‘data 

integrity and quality when a clinician 

corrects errors that were not reported by 

the patient or needs to communicate 

updates to a patient’s information.’’ We 

agree with the HITPC and HITSC 

recommendations, including that a 

certification criterion should be adopted 

that provides some of the basic 

technical tools necessary to comply 

with the HIPAA Privacy Rule. The 

proposed certification criterion does not 

address all of the requirements specified 

at 45 CFR 164.526 and we note that EHR 

technology certification is not a 

substitute for, or guarantee of, HIPAA 

Privacy Rule compliance. However, we 

believe that by adopting the proposed 

certification criterion, EPs, EHs, and 

CAHs would be provided some of the 

basic technical tools for compliance 

with 45 CFR 164.526. 

We specifically request comment on 

whether EHR technology should be 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13839 

6http://wiki.directproject.org/

Documentation+Library. 

7http://wiki.directproject.org/Applicability+

Statement+for+Secure+Health+Transport. 

8http://wiki.directproject.org/XDR+and+

XDM+for+Direct+Messaging. 

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. 

• View, download, and transmit to 

3rd party 

MU Objective 

EPs 

Provide patients the ability to view online, 

download, and transmit their health information within 4 business days of the information being available to the EP. 

EHs and CAHs 

Provide patients the ability to view online, 

download, and transmit information about 

a hospital admission. 

2014 Edition EHR Certification Criterion 

§ 170.314(e)(1) (View, download, and transmit to 3rd party) 

Standards 

§ 170.204(a) (Web Content Accessibility 

Guidelines (WCAG) 2.0, Level AA Conformance); § 170.205(a)(3) (Consolidated 

CDA); § 170.205(j) (DICOM PS 3–2011); 

§ 170.207(f) (OMB standards for the classification of federal data on race and ethnicity); § 170.207(j) (ISO 639–1:2002 

(preferred language)); § 170.207(l) (smoking status types); § 170.207(a)(3) 

(SNOMED-CT® International Release 

January 2012); § 170.207(m) (ICD–10– 

CM); § 170.207(b)(2) (HCPCS and CPT– 

4) or § 170.207(b)(3) (ICD–10–PCS); 

§ 170.207(g) (LOINC version 2.38); 

§ 170.207(h) (RxNorm February 6, 2012 

Release); § 170.202(a)(1) (Applicability 

Statement for Secure Health Transport) 

and § 170.202(a)(2) (XDR and XDM for 

Direct Messaging); and § 170.210(g) (synchronized clocks) 

The HITPC issued a MU 

recommendation that patients (or their 

authorized representative(s)) be able to 

view and download their health 

information online (i.e., Internet/Webbased). The HITPC recommended that 

this 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 

criteria, the criterion should replace the 

certification criteria previously adopted 

at §§ 170.304(f), 170.304(g), 170.306(d), 

and 170.306(e) because the new 

criterion encompassed the data 

elements required by these capabilities 

and was seen as a more efficient and 

effective means for patients to access 

their health information. We have made 

several refinements to the recommended 

certification criterion, while 

maintaining the critical elements 

recommended by the HITSC. 

In addition to the view and download 

capabilities recommended by the 

HITSC, we propose to include a third 

specific capability in this certification 

criterion—the ability to transmit a 

summary care record to a third party. 

Given that this objective is about 

making health information more 

accessible to patients and their 

caregivers, we believe that patients 

should have another option available to 

access their health information. We also 

believe that in certain cases patients 

may want to direct their health care 

provider(s) to transmit a copy of their 

electronic health information to another 

entity the patient might use for 

centralizing their health information 

(e.g., a personal health record). This 

additional capability is consistent with, 

and supports, the right of access 

standard at 45 CFR 164.524 of the 

HIPAA Privacy Rule as expanded by 

section 13405(e) of the HITECH Act 

with respect to covered entities that use 

or maintain an EHR on an individual. 

Section 13405(e) states that, in applying 

45 CFR 164.524, an ‘‘individual shall 

have a right to obtain from [a HIPAA] 

covered entity a copy of such 

information in an electronic format and, 

if the individual chooses, to direct the 

covered entity to transmit such copy 

directly to an entity or person 

designated by the individual* * *.’’ 

Coupled with this addition, we have 

proposed that EHR technology would 

need to be capable of transmitting a 

summary care record according to both 

transport standards we propose to 

adopt. These transport standards 

include the two transport specifications 

developed under the Direct Project 6: (1) 

Applicability Statement for Secure 

Health Transport 7 and (2) External Data 

Representation (XDR) and CrossEnterprise Document Media Interchange 

(XDM) for Direct Messaging.8 The 

Applicability Statement for Secure 

Health Transport specification describes 

how electronic health information can 

be securely transported using simple 

mail transport protocol (SMTP), Secure/ 

Multipurpose Internet Mail Extensions 

(S/MIME), and X.509 certificates. The 

XDR and XDM for Direct Messaging 

specification describes the use of XDR 

and XDM as a means to transport 

electronic health information and serve 

as a bridge between entities using/ 

following Web services and SMTP 

transport methods. We believe that 

these transport standards are ideal for 

these purposes and will make it possible 

for patients to transmit a copy of their 

summary care record to the destination 

of their choice. Additionally, because 

we have 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 summary care record’’ 

certification criterion, we have 

determined that it is not 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 

believe that to include the 2011 Edition 

EHR certification criterion would be 

redundant and that our proposed 

approach more explicitly ties security to 

a particular transmission. 

At the recommendation of the HITSC, 

this proposed certification criterion 

requires 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 (i.e., record the 

user identification, the user’s actions, 

and the health information viewed, 

downloaded, or transmitted) and make 

that information available to the patient. 

We have required this specific 

capability within this certification 

criterion because we believe that it is 

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 propose to 

adopt at § 170.314(d)(2) due to the 

proposed policy change we specify in 

section IV.C.1 below related to EHR 

Modules and privacy and security. 

Thus, this express requirement 

guarantees 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 do 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13840 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

9http://www.ietf.org/rfc/rfc1305.txt. 

10http://www.ietf.org/rfc/rfc5905.txt. 

11 ftp://medical.nema.org/medical/dicom/2011/. 

12http://report.nih.gov/recovery/

investmentreports/ViewARRAInvRpt.

aspx?csid=211. 

13https://www.fbo.gov/index?s=opportunity&

mode=form&id=ccb2340f4d8711b16f

9e625b6b519371&tab=core&_cview=0 [solicitation 

#: NHLBI–CSB–EB–2012–5–RP]. 

14 76 FR 76640 (December 8, 2011). http://

www.gpo.gov/fdsys/pkg/FR-2011-12-08/pdf/2011- 

31462.pdf#page=1. 

15 76 FR 59307 (September 26, 2011). http://

www.gpo.gov/fdsys/pkg/FR–2011–09–26/pdf/2011– 

24298.pdf. 

16http://www.w3.org/Consortium/. 

17http://www.w3.org/WAI/intro/wcag. 

18http://www.w3.org/TR/WCAG20/. 

19http://www.w3.org/WAI/intro/uaag.php. 

tamper resistance certification criterion. 

Accordingly, we provide 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, 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 propose for the ‘‘patient 

accessible log’’ capability to require that 

the date and time each action occurs be 

recorded 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). These are final standards 

published by the Internet Engineering 

Task Force, a voluntary consensus 

standards body. Having correctly 

synchronized clocks is an information 

security best practice and the NTP, 

especially version 3, has been widely 

used and implemented since its 

publication in 1992.9 RFC 5905 NTPv4 

was published in 2010 10 and is 

backwards compatible with NTPv3. It 

does, however, include a modified 

protocol header to accommodate the 

Internet Protocol version 6 (IPv6) 

address family. For the same reasons we 

discuss here, we have included in the 

new certification criterion for electronic 

medication administration proposed for 

adoption at § 170.314(a)(17) and the 

auditing standard proposed for adoption 

at § 170.210(e) this same ‘‘synchronized 

clocks’’ standard because each includes 

a capability that requires date and time 

to be recorded. As a general best 

practice, we highly encourage and 

expect EHR technology developers that 

associate date and/or time with 

capabilities included in certification 

criteria not specifically mentioned here 

to utilize a system clock that has been 

synchronized following NTPv3 or 

NTPv4. Additionally, the HITSC 

recommended that we require as a 

condition of certification other privacy 

and security oriented capabilities such 

as single factor authentication and 

secure download. We did not include 

these additional capabilities in our 

proposals because we believe their 

technical implementations are 

commonplace and ubiquitous. Thus, 

there would seem to be little value 

added by requiring that these 

capabilities be demonstrated as a 

condition of certification. 

We propose to require EHR 

technology to be capable of enabling 

images formatted according to the 

Digital Imaging and Communications in 

Medicine (DICOM) standard 11 to be 

downloaded and transmitted to a third 

party. We believe 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. In fact, the National 

Institutes of Health has recently funded 

activities focused on personally 

controlled sharing of medical images 12

and published a solicitation notice on 

the same topic.13

We believe that all patients should 

have an equal opportunity to access 

their electronic health information 

without barriers or diminished 

functionality or quality. Thus, after 

consultation with the HHS Office for 

Civil Rights and HHS Office on 

Disability and reviewing the efforts of 

other Federal agencies, we propose that 

the viewing capability must meet Level 

AA conformance with the most recent 

set of the Web Content Accessibility 

Guidelines (WCAG). Federal agencies 

are considering, or proposing to adopt, 

WCAG 2.0 Level AA conformance for 

industries and technology they regulate. 

The Architectural and Transportation 

Barriers Compliance Board (Access 

Board) is considering applying WCAG 

2.0 Level AA conformance to Federal 

agencies and telecommunications 

accessibility, which apply to 

telecommunication manufacturers.14

The Department of Transportation is 

proposing to require WCAG 2.0 Level 

AA conformance for air carrier Web 

sites and airport kiosks.15

The WCAG were developed through 

an open process by the World Wide 

Web Consortium (W3C16).17 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.18 Each guideline offers 3 

levels of conformance: A, AA, and AAA. 

Level A conformance corresponds to the 

most basic requirements for displaying 

Web content. Level AA conformance 

provides for a stronger level of 

accessibility by requiring conformance 

with Level A success criteria as well as 

Level AA specific success criteria. Level 

AAA conformance comprises the 

highest level of accessibility within the 

WCAG guidelines and includes all Level 

A and Level AA success criteria as well 

as success criteria unique to Level AAA. 

We are proposing 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. For example, success criteria 

unique to Level AA include 

specifications of minimum contrast 

ratios for text and images of text, and a 

requirement that text can be resized 

without assistive technology up to 200 

percent without loss of content or 

functionality. In addition to WCAG 2.0 

Level AA conformance, we are 

interested in whether commenters 

believe additional standards are needed 

for certification to ensure accessibility 

for the viewing capability, such as the 

User Agent Accessibility Guidelines 

(UAAG).19 Version 2.0 of the UAAG is 

designed to align with WCAG 2.0, but 

is currently only in draft form. 

The HITSC recommended that we 

move to one summary care record 

standard. We agree with this 

recommendation and believe that 

moving to one summary care record 

standard would lead to increased 

interoperability and spur innovation. 

The Consolidated CDA is 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 a 

summary care record that includes all of 

the data elements that CMS is proposing 

be available to be populated in a 

summary care record. Accordingly, we 

are proposing to require that EHR 

technology be capable of providing the 

information that CMS is proposing be 

required in a summary care record that 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13841 

is provided to patients or their 

authorized representatives. 

In certain instances in § 170.314(e)(1), 

we propose to require that the capability 

be demonstrated in accordance with the 

specified vocabulary standard. These 

vocabulary standards have been 

previously adopted or are proposed for 

adoption in this proposed rule 

consistent with the recommendations of 

the HITSC. With the exception of the 

four standards discussed below (LOINC, 

ICD–10–CM, ICD–10–PCS, and HCPCS), 

the vocabulary standards included in 

this certification criterion are discussed 

elsewhere in this preamble 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 eprescribing). 

For encounter diagnoses and 

procedures, we propose the use of ICD– 

10 (ICD–10–CM and ICD–10–PCS, 

respectively). We request 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 are interested in 

whether commenters believe 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 ask 

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 propose 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, 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 propose 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 at 

§ 170.207(b)(3) and (m), respectively. 

In August 2011, we published an 

advance notice of proposed rulemaking 

(ANPRM) (76 FR 48769) to seek public 

comment on the metadata standards we 

could propose for adoption in this 

proposed rule. In the ANPRM, we 

stated: 

We are considering whether to propose, as 

a requirement for certification, that EHR 

technology be capable of applying the 

metadata standards in the context of the use 

case selected by the HIT Policy Committee 

(i.e., when a patient downloads a summary 

care record from a health care provider’s EHR 

technology or requests for it to be transmitted 

to their PHR). For example, if a patient seeks 

to obtain an electronic copy of her health 

information, her doctor’s EHR technology 

would have to be capable of creating a 

summary care record and subsequently 

assigning metadata to the summary care 

record before the patient receives it. 

We noted in the ANPRM that, after 

reviewing public comments, we would 

re-consider our proposals and use this 

proposed rule to seek further public 

comment on more specific proposals. 

Given our proposed adoption of solely 

the Consolidated CDA standard for 

summary care records and the fact that 

this standard requires EHR technology 

developers to follow the requirements 

specified in the ‘‘US Realm Header’’ 

(section 2.1 of the Consolidated CDA), 

which includes the metadata elements 

we were considering for patient identity 

and provenance, we do not believe that 

it would be necessary or prudent to 

propose separate metadata standards at 

this time. Accordingly, we believe that 

for the first use case we identified in the 

ANPRM our policy goals can be 

accomplished through the adoption of 

the Consolidated CDA standard. This 

approach also addresses the HITSC’s 

recommendation for this certification 

criterion to include ‘‘data provenance’’ 

with any health information that is 

downloaded. Finally, consistent with 

public comments on the ANPRM, we 

are not proposing metadata standards 

for ‘‘privacy’’ and intend to continue to 

work with the industry to further flesh 

out what such metadata standards could 

be. However, we note that 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). We intend to continue 

to work with SDOs and other 

stakeholders on some of the HITSC 

recommendations discussed in the 

ANPRM relative to the CDA header. For 

example, we welcome comment on, and 

will consider moving from, the use of 

object identifiers (OIDs) to uniform 

resource identifiers (URIs). 

• Automated numerator recording 

MU Objective 

N/A 

2014 Edition EHR Certification Criterion 

§ 170.314(g)(1) (Automated numerator recording) 

To complement the ‘‘automated 

measure calculation’’ certification 

criterion adopted at § 170.302(n) (and 

now proposed for adoption as a revised 

certification criterion at § 170.314(g)(2)), 

we propose to adopt a 2014 Edition EHR 

certification criterion which would 

apply solely to EHR Modules that 

include capabilities for an MU objective 

with a percentage-based measure. This 

certification criterion would focus on 

the EHR Module’s capability to 

automatically record the numerator for 

those measures. While a Complete EHR 

would need to be capable of meeting the 

automated measure calculation 

certification criterion which requires the 

capability to accurately calculate MU 

denominators, we do 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, especially in the 

case where multiple certified EHR 

Modules are being used by an EP, EH, 

or CAH. That said, we 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. 

Therefore, we propose to adopt this new 

certification criterion at § 170.314(g)(1). 

As noted, a Complete EHR would 

need to be certified to the proposed 

automated measure calculation criterion 

(§ 170.314(g)(2)). We would consider a 

Complete EHR certified to 

§ 170.314(g)(2) as having met the 

proposed automated numerator 

recording certification criterion at 

§ 170.314(g)(1) and, thus, there would 

be no need for the Complete EHR to be 

separately certified to § 170.314(g)(1). 

However, as discussed under section 

IV.C.2 of this preamble, EHR Modules 

that are presented for certification to 

certification criteria that include 

capabilities for supporting an MU 

objective with a percentage-based 

measure would need to be certified to 

this proposed certification criterion. 

This would not preclude an EHR 

Module from being certified to the 

automated measure calculation 

certification criterion if the EHR Module 

developer sought such certification. In 

such instances, similar to our stance on 

Complete EHR certification to 

§ 170.314(g)(2), there would be no need 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13842 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

20 ISO 9241–11. 

21http://www.nist.gov/healthcare/usability. 

22 § 170.314(a)(1) (CPOE); § 170.314(a)(2) (Drugdrug, drug-allergy interaction checks); 

§ 170.314(a)(6) (Medication list); § 170.314(a)(7) 

(Medication allergy list); § 170.314(a)(8) (Clinical 

decision support); § 170.314(a)(17) (Electronic 

medication administration record); § 170.314(b)(3) 

(Electronic prescribing); and § 170.314(b)(4) 

(Clinical information reconciliation). 

for the EHR Module to be separately 

certified to § 170.314(g)(1). 

• Non-percentage-based measure use 

report 

MU Objective 

N/A 

2014 Edition EHR Certification Criterion 

§ 170.314(g)(3) (Non-percentage-based 

measure use report) 

Standard 

§ 170.210(g) (synchronized clocks) 

To further complement the 

certification criteria proposed for 

adoption at § 170.314(g)(1) and (g)(2), 

we propose to adopt a new 2014 Edition 

EHR certification criterion at 

§ 170.314(g)(3) which would apply to 

any EHR technology presented for 

certification that includes capabilities 

associated with MU objectives and 

measures that are not percentage based. 

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. We also propose to 

require that the date and time be 

recorded according to the 

‘‘synchronized clocks’’ standard that we 

explain in more detail in the preamble 

discussion of the new ‘‘view, download, 

and transmit to 3rd party’’ certification 

criterion proposed for adoption at 

§ 170.314(e)(1). 

In consultation with CMS, we believe 

that EPs, EHs, and CAHs would benefit 

from this type of capability being 

required as a condition of certification. 

Additionally, we believe that such a 

capability could provide EPs, EHs, and 

CAHs with valuable evidence in the 

event of an MU audit. We propose that 

any EHR technology presented for 

certification to any one of the following 

certification criteria would need to be 

certified to this certification criterion. 

170.314(a)(2) ............................................................................................ Drug-drug, drug-allergy interaction checks. 

170.314(a)(8) ............................................................................................ Clinical decision support. 

170.314(a)(10) .......................................................................................... Drug-formulary checks. 

170.314(a)(14) .......................................................................................... Patient lists. 

170.314(a)(17) .......................................................................................... Electronic medication administration record. 

170.314(f)(2) ............................................................................................. Transmission to immunization registries. 

170.314(f)(4) ............................................................................................. Transmission to public health agencies (surveillance). 

170.314(f)(6) ............................................................................................. Transmission of reportable laboratory tests and values/results. 

170.314(f)(8) ............................................................................................. Transmission to cancer registries. 

EHR technology that is presented for 

certification to any of these certification 

criteria would need to be able to record 

the date and time and enable a user to 

create a report that indicates when each 

capability was enabled and disabled, 

and/or executed. We intend for the term 

‘‘executed’’ to apply only to the 

certification criteria in the table above 

except those proposed for adoption at 

§ 170.314(a)(2) and (17). The MU 

measures associated with § 170.314(a)(2) 

and (17) require that the capabilities 

CEHRT include be ‘‘enabled’’ or 

‘‘implemented’’ for an entire EHR 

reporting period. Moreover, they do not 

require unique action(s) by an EP, EH, 

or CAH. Last, we clarify that the privacy 

and security certification criteria 

proposed for adoption in § 170.314(d) 

which are associated with the MU 

objective ‘‘protect electronic health 

information created or maintained by 

the Certified EHR Technology through 

the implementation of appropriate 

technical capabilities’’ and measure 

which is not percentage based would 

not be included within the scope of this 

certification criterion. We do not believe 

that EHR technology would be able to 

capture that a security risk analysis was 

performed by an EP, EH, or CAH except 

through a manual entry by the EP, EH, 

or CAH affirming the completion of the 

risk analysis. 

• Safety-enhanced design 

MU Objective 

N/A 

2014 Edition EHR Certification Criterion 

§ 170.314(g)(4) (Safety-enhanced design) 

The International Organization for 

Standardization (ISO) defines 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.’’ 20 Many 

industry stakeholders have 

acknowledged that a gap exists between 

optimal usability and the usability 

offered by some current EHR 

technologies. However, to date, little 

consensus has been reached on what 

might help close this gap and what role, 

if any, the Federal government should 

play related to the usability of EHR 

technology. In June 2011, the HITPC 

issued a report to ONC that explored the 

challenges associated with EHR 

technology usability and user-centered 

design (UCD). In its report, the HITPC 

identified certain ‘‘desired outcomes of 

improved usability’’ including 

improved safety and reduced cost, 

clinician frustration, training time, and 

cognitive load for clinical and nonclinical users alike. 

In November 2011, the Institute of 

Medicine (IOM) released a 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.’’ Moreover, given this 

concern, 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 fundamentally agree with the 

sentiment expressed by both the HITPC 

and the IOM. As we consider the shared 

goals stated by stakeholders from all 

sides of this discussion, we believe that 

a significant first step toward improving 

overall usability is to focus on the 

process of 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,’’ 21 we are 

concerned that it would be 

inappropriate at this juncture for ONC 

to seek to measure EHR technology in 

this way. Recognizing that EHR 

technologies exist and are in use today, 

we have prioritized eight certification 

criteria 22 and associated capabilities to 

which this proposed certification 

criterion would require UCD to have 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13843 

23The National Voluntary Laboratory 

Accreditation Program, as administered by NIST, is 

responsible for testing under the permanent 

certification program (‘‘ONC HIT Certification 

Program’’) (76 FR 1278). 

24The quality management document will be 

published on ONC’s Web site during the public 

comment period of this proposed rule and notice 

of its availability will be made through a notice 

published in the Federal Register. 

25http://www.pso.ahrq.gov/formats/

commonfmt.htm. 

26https://psoppc.org/web/patientsafety/ahrqcommon-formats-device-or-medical/surgicalsupply-including-hit-device. 

been applied. We chose these eight 

because we believe they pose the 

greatest risk for patient harm and, 

therefore, the greatest immediate 

opportunity for error prevention and 

user experience improvement. We 

believe this approach limits this new 

certification criterion’s potential burden 

while providing for a much needed 

focus on the application of UCD to 

medication-related certification criteria. 

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. 

Presently, we believe it is best to enable 

EHR technology developers to choose 

their UCD approach and not to prescribe 

one or more 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. 

Moreover, we acknowledge and expect 

that EHR technology developers who 

have already followed UCD in past 

development efforts for the identified 

certification criteria would be 

performing a retrospective analysis to 

document for the purposes of testing 

and certification that UCD had been 

applied to the specified certification 

criteria. However, if UCD had not been 

previously applied to capabilities 

associated with any of the certification 

criteria proposed, the EHR technology 

would ultimately need to have such 

UCD processes applied before it would 

be able to be certified. 

We propose to adopt this certification 

criterion at § 170.314(g)(4). If we adopt 

this certification criterion in a final rule, 

we anticipate that testing 23 to this 

certification criterion would entail EHR 

technology developers documenting 

that their UCD incorporates, in any form 

or format, all of the data elements 

defined in the Customized Common 

Industry Format Template for EHR 

Usability Testing (NISTIR 7742). We 

note that with respect to demonstrating 

compliance with this certification 

criterion that this information would 

need to be available to an ONC–ACB for 

review. This documentation would 

become a component of the publicly 

available testing results on which a 

certification is based (see section IV.D of 

this preamble for our proposal to make 

the test results used for certification 

publicly available). 

In addition to our proposed safetyenhanced design certification criterion, 

we request comment on two other 

safety-related certification criteria under 

consideration for adoption by the 

Secretary. 

Quality Systems 

The IOM also recommended that we 

‘‘[establish] quality management 

principles and processes in health IT.’’ 

Working with other Federal agencies, 

we intend to publish a quality 

management document that is 

customized for the EHR technology 

development lifecycle and expresses 

similar principles to those included in 

ISO 9001, IEC 62304, ISO 13485, ISO 

9001, and 21 CFR 820. The 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 the development of EHR 

technology. We understand that some 

EHR technology developers already 

have processes like these in place, but 

do not believe, especially in light of the 

IOM recommendation, that the EHR 

technology industry as a whole 

consistently follows such processes. We 

expect that this document would be 

published around the same time as this 

proposed rule and would be available 

for public comment.24 Accordingly, we 

are considering including in the final 

rule an additional certification criterion 

that would require an EHR technology 

developer to document how their EHR 

technology development processes 

either align with, or deviate from, the 

quality management principles and 

processes that would be expressed in 

the document. We emphasize 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 

principles and processes specified in 

the document (and where they do not, 

what alternative processes they use, if 

any). We expect 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 are 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 a significant 

burden on developers. We request 

public comment on this additional 

certification criterion and the feasibility 

of requiring EHR technology developers 

to document their current processes. 

Patient Safety Events 

We are considering 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,25 including the ‘‘Device or 

Medical/Surgical Supply, including HIT 

v1.1a.’’ 26 The Common Formats are 

designed to capture information about 

patient safety events. In line with IOM’s 

recommendations, we believe that 

requiring this capability for certification 

could be an essential first step in 

creating the infrastructure that would 

support the reporting of potential 

adverse events involving EHR 

technology to patient safety 

organizations (PSOs). We request 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. 

b. Ambulatory Setting 

We propose to adopt 3 certification 

criteria that would be new certification 

criteria for the ambulatory setting. 

• Secure messaging 

MU Objective 

Use secure electronic messaging to communicate with patients on relevant health 

information. 

2014 Edition EHR Certification Criterion 

§ 170.314(e)(3) (Ambulatory setting only— 

secure messaging) 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13844 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

27Poon EG, Keohane CA, Yoon CS, et al. (2010) 

Effect of Bar-Code Technology on the Safety of 

Medication Administration New England Journal of 

Medicine 362:1698–1707. 

Standard 

§ 170.210(f) 

The HITSC recommended two 

versions (based in large part on the work 

of the Implementation Workgroup and 

Privacy and Security Workgroup) of the 

2014 Edition EHR certification criterion 

for secure messaging to support the MU 

objective and measure recommended by 

the HITPC, and now proposed by CMS. 

We agree with the direction provided by 

both recommendations and have merged 

the two into a refined certification 

criterion. We have also included what 

we believe should be the baseline 

standard in terms of encryption and 

hashing algorithms used to implement 

secure messaging. More specifically, we 

are proposing that only those identified 

in FIPS 140–2 Annex A be permitted to 

be used to meet this criterion. As such, 

we propose to adopt a new standard in 

§ 170.210(f) to refer to FIPS 140–2 

Annex A’s encryption and hashing 

algorithms. Additionally, we are 

proposing, consistent with the HITSC’s 

recommendations, that methods for 

meeting this certification criterion could 

include, but would not be limited to, 

designing EHR technology to meet the 

following standards: IETF RFC 2246 

(TLS 1.0) and SMTP/SMIME as well as 

implementation specifications such as 

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. We propose to adopt this 

new certification criterion at 

§ 170.314(e)(3). 

• Cancer registry 

MU Objective 

Capability to identify and report cancer 

cases to a State cancer registry, except 

where prohibited, and in accordance with 

applicable law and practice. 

2014 Edition EHR Certification Criteria 

§ 170.314(f)(7) (Ambulatory setting only— 

cancer case information) 

§ 170.314(f)(8) (Ambulatory setting only— 

transmission to cancer registries) 

Standards and Implementation Specifications 

§ 170.205(i) (HL7 CDA, Release 2 and Implementation Guide for Healthcare Provider Reporting to Central Cancer Registries, Draft, February 2012); 

§ 170.207(a)(3) (SNOMED CT® International Release January 2012); and 

§ 170.207(g) (LOINC version 2.38) 

The HITPC provided 

recommendations that CMS consider 

requiring EPs to submit reportable 

cancer conditions. CMS has proposed 

this as a new objective and measure for 

EPs. We propose to adopt two new 2014 

Edition EHR certification criteria to 

enable the performance of the objective 

and measure with the use of CEHRT. 

The proposed adoption of two criteria, 

one focused on the data capture and the 

other focused on the formatting and 

transmission of such data in the 

proposed standards is consistent with 

the HITSC recommendation to consider 

splitting the public health certification 

criteria in this manner. In consultation 

with the Centers for Disease Control and 

Prevention (CDC), we propose to adopt 

HL7 CDA, Release 2 as the content 

exchange standard. We also propose to 

adopt SNOMED CT® International 

Release January 2012 and LOINC 

version 2.38 as the vocabulary 

standards. Additionally, we propose to 

adopt the Implementation Guide for 

Healthcare Provider Reporting to 

Central Cancer Registries, Draft, 

February 2012. This implementation 

guide was jointly developed by the CDC 

and the North American Association of 

Central Cancer Registries (NAACCR) 

and is available at http://www.cdc.gov/ 

ehrmeaningfuluse. CDC will consider 

comments received on this proposed 

rule in finalizing the guide. Assuming 

CDC finalizes the guide, we would 

consider adopting the final version of 

the guide in a final rule with 

consideration of public comment on the 

appropriateness of the guide for 

certification. 

We propose to adopt these 

certification criteria at § 170.314(f)(7) 

and (8). We propose to adopt the HL7 

CDA standard and implementation 

guide at § 170.205(i). We propose to 

adopt SNOMED CT® International 

Release January 2012 and LOINC 

version 2.38 at § 170.207(a)(3) and (g), 

respectively. 

c. Inpatient Setting 

We propose to adopt 3 certification 

criteria that would be new certification 

criteria for the inpatient setting. 

• Electronic medication 

administration record 

MU Objective 

Automatically track medications from order 

to administration using assistive technologies in conjunction with an electronic 

medication administration record (eMAR). 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(17) (Inpatient setting only— 

electronic medication administration 

record) 

Standard 

§ 170.210(g) (synchronized clocks) 

The HITSC recommended a new 2014 

Edition EHR certification criterion to 

support the MU objective and measure 

recommended by the HITPC, now 

proposed by CMS, for EHs and CAHs to 

automatically track medications from 

order to administration. We have 

refined the recommended certification 

criterion to clearly state the capabilities 

that must be tested and certified. The 

certification criterion continues to 

reflect the intent of the HITPC and 

HITSC, including the basic ‘‘rights’’ 

(right patient, right medication, right 

dose, right route, and right time). It is 

our intent, consistent with the HITSC’s 

recommendation, to permit a range of 

acceptable technical solutions for 

certification. However, we wish to make 

clear that in order to demonstrate 

compliance with this certification 

criterion, EHR technology must enable a 

user to electronically confirm the 

‘‘rights’’ in relation to the medication(s) 

to be administered in combination with 

an assistive technology (such as barcoding, location tracking, and radiofrequency identification (RFID)) which 

provides automated information on the 

‘‘rights.’’ An electronic ‘‘checklist’’ 

through which a user would manually 

confirm the ‘‘rights’’ without any 

automated and assistive feedback from 

EHR technology would not be sufficient 

to demonstrate compliance with this 

certification criterion. We believe this 

clarification and distinction are 

important because an electronic 

medication administration record 

together with some type of assistive 

technology has been shown to decrease 

medication errors 27 and it is not our 

intent to digitize a paper process that 

would not realize the safety benefits that 

could be provided with the use of an 

assistive technology. We propose to 

adopt this new certification criterion at 

§ 170.314(a)(17) with inclusion of the 

‘‘synchronized clocks’’ standard as 

discussed earlier in this preamble under 

the ‘‘view, download, and transmit to 

3rd party’’ certification criterion. 

• Electronic prescribing 

MU Objective 

Generate and transmit permissible discharge prescriptions electronically (eRx). 

2014 Edition EHR Certification Criterion 

§ 170.314(b)(3) (Electronic prescribing) 

Standards 

§ 170.205(b)(2) (NCPDP SCRIPT version 

10.6) and § 170.207(h) (RxNorm February 

6, 2012 Release) 

In response to the HITPC’s 

recommendation for a new MU Stage 2 

objective and measure for e-prescribing 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13845 

28http://wiki.siframework.org/ 

Lab+Results+Interface+%28LRI%29+Initiative. 

of discharge medications by EHs and 

CAHs (now proposed by CMS), the 

HITSC recommended a certification 

criterion for electronic prescribing of 

discharge medications. As part of the 

HITSC recommendation, it was 

recommended that we require as a 

condition of certification for the 

inpatient setting that certain HL7 

standards be adopted for exchange 

within a legal entity. We did not accept 

this part of the recommendation because 

it is inconsistent with our approach of 

adopting standards for the electronic 

exchange of health information between 

different legal entities. We are proposing 

to adopt for the inpatient setting the 

same revised electronic prescribing 

certification criterion we propose to 

adopt for the ambulatory setting (i.e., we 

propose to adopt the certification 

criterion at § 170.314(b)(3) for both 

settings). We discuss this revised 

certification criterion in further detail 

under the ambulatory setting subsection 

of the revised certification criteria 

section of this preamble. 

• Transmission of electronic 

laboratory tests and values/results to 

ambulatory providers 

MU Objective 

Provide structured electronic laboratory results to eligible professionals. 

2014 Edition EHR Certification Criterion 

§ 170.314(b)(6) (Inpatient setting only— 

transmission of electronic laboratory tests 

and values/results to ambulatory providers) 

Standards and Implementation Specifications 

§ 170.205(k) (HL7 2.5.1 and HL7 Version 

2.5.1 Implementation Guide: Standards 

and Interoperability Framework Lab Results Interface, Release 1 (US Realm)); 

and § 170.207(g) (LOINC version 2.38) 

The HITSC recommended a new 2014 

Edition EHR certification criterion to 

support the MU objective and measure 

recommended by the HITPC for EHs and 

CAHs to send electronic laboratory tests 

and values/results to eligible 

professionals. CMS has not proposed 

the MU objective and measure for Stage 

2, but has requested public comment on 

whether the objective and measure 

should be incorporated into Stage 2. 

We have refined the recommended 

certification criterion, primarily to 

include the standards and 

implementation guide recommended by 

the HITSC and HITPC. The HITSC 

recommended that we consider 

requiring the Standards and 

Interoperability Framework Laboratory 

Results Interface Initiative (S&I 

Framework LRI).28 The S&I Framework 

LRI was created to reduce the variability 

of ambulatory laboratory interfaces as 

well as reduce the cost and time to 

initiate new electronic laboratory tests 

and values/results interfaces between 

clinical labs and ambulatory EHR 

technology. The S&I Framework LRI 

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 believe that 

our proposal to require for certification 

that inpatient EHR technology 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. 

To further reduce costs and improve 

the electronic exchange of laboratory 

tests and values/results, we are building 

off the HITSC recommendation and are 

proposing 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 discussed here, including 

the LRI implementation guide (see 

discussion of proposed § 170.314(b)(5) 

under the revised certification criteria 

section below). We are also proposing to 

adopt LOINC version 2.38 as the 

vocabulary standard. The HITPC 

recommended using LOINC where 

available and the HITSC expressed 

agreement with this approach during 

their deliberations. Moreover, the LRI 

implementation guide requires the use 

of LOINC for laboratory tests. With 

respect to testing and certification for 

this certification criterion, we expect, 

among other aspects, that 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 propose to adopt this new 

certification criteria for the 2014 Edition 

EHR certification criteria at 

§ 170.314(b)(6). We propose to adopt the 

HL7 2.5.1 standard and LRI 

implementation guide at § 170.205(k), 

acknowledging that the LRI 

specification is currently undergoing 

HL7 balloting. We intend to continue to 

monitor its progress and anticipate that 

a completed specification will be 

available before we publish a final rule. 

We propose to adopt LOINC version 

2.38 at § 170.207(g). 

5. Revised Certification Criteria 

In the Permanent Certification 

Program final rule (76 FR 1302) we 

described revised certification criteria as 

certification criteria previously adopted 

by the Secretary that are modified to 

add, remove, or otherwise alter the 

specified capabilities and/or the 

standard(s) or implementation 

specification(s) referred to by the 

certification criteria. We also stated that 

revised certification criteria may also 

include certification criteria that were 

previously adopted as optional, but are 

subsequently adopted as mandatory. 

Again, based on our experience in trying 

to appropriately categorize the 

certification criteria we propose to be 

part of the 2014 Edition EHR 

certification criteria we have 

determined that our description of 

revised certification criteria needs to be 

refined. Accordingly, we list below the 

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. 

To clarify, 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. 

We propose to adopt revised 

certification criteria that will support 

proposed revisions to MU objectives 

and measures and that will increase the 

interoperability, functionality, utility, 

safety, and security of EHR technology. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13846 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

29http://www.loc.gov/standards/iso639–2/php/

code_list.php—Also note that The Library of 

Congress has been designated the ISO 639–2/RA for 

the purpose of processing requests for alpha-3 

language codes comprising the International 

Standard. 

a. Ambulatory and Inpatient Setting 

We propose to adopt the following 

revised certification criteria for both the 

ambulatory and inpatient settings. 

• Drug-drug, drug-allergy interaction 

checks 

MU Objective 

Implement drug-drug and drug-allergy interaction checks. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(2) (Drug-drug, drug-allergy 

interaction checks) 

The HITSC recommended a revised 

certification criterion for the 2014 

Edition EHR certification criteria to 

eliminate the ability for EHR technology 

to permit users to adjust drug-allergy 

interaction checks and to provide 

additional clarity for the capabilities 

that EHR technology must demonstrate. 

The HITSC reasoned that it would be 

clinically inappropriate to allow users 

to adjust drug-allergy interaction 

checks. The HITSC also reasoned that 

clarity could be provided with 

additional revisions. The HITSC 

recommended replacing the term ‘‘realtime’’ with ‘‘before the order is 

executed.’’ The HITSC also 

recommended revising the language to 

specify that notifications should happen 

during CPOE. Additionally, the HITSC 

recommended specifying that the level 

of severity of the notifications is what 

can be adjusted. The HITSC also 

recommended limiting the ability to 

make adjustments to an identified set of 

users or available as a system 

administrative function. Last, the HITSC 

recommended that drug-allergy 

contraindications should be interpreted 

to include adverse reaction 

contraindications. We agree with all of 

the HITSC’s recommendations. We have 

revised and refined the language of the 

HITSC’s recommended certification 

criterion, but otherwise have included 

all the recommended capabilities. As to 

the phrase ‘‘identified set of users,’’ we 

clarify 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. 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). We believe this 

revised language more clearly indicates 

the intent of the criterion. We propose 

to adopt this revised certification 

criterion at § 170.314(a)(2). 

• Demographics 

MU Objective 

Record the following demographics: preferred language; gender; race; ethnicity; 

date of birth; and for the inpatient setting 

only, date and preliminary cause of death 

in the event of mortality in the EH or 

CAH. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(3) (Demographics) 

Standards 

§ 170.207(f)(OMB standards); § 170.207(j) 

(ISO 639–1:2002); and § 170.207(k) 

(ICD–10–CM ) 

The HITSC recommended that we 

adopt a revised ‘‘demographics’’ 

certification criterion that requires the 

use of ISO 639–1 as the vocabulary 

standard for preferred language.29 We 

agree with the HITSC’s recommendation 

because it appropriately limits the 

burden on EHR technology developers 

since the ISO 639–1 code set which uses 

an alpha-2 code for language names is 

roughly 40% that of the ISO 639–2 code 

set which uses an alpha-3 code. We also 

propose to adopt ICD–10–CM for 

recording the preliminary cause of 

death. We believe that the use of 

ICD–10–CM will permit additional 

specificity for this data element. As for 

the Office of Management and Budget 

(OMB) standards for the classification of 

federal data on race and ethnicity, we 

note 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 also propose 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 propose to revise 

this 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. This proposed revision would 

ensure inclusion of such patients in the 

numerator of the MU percentage-based 

measure. We propose to adopt this 

revised certification criterion for the 

2014 Edition EHR certification criteria 

at § 170.314(a)(3) and the proposed 

standards at § 170.207(j) and (k). 

• Problem list 

MU Objective 

Maintain an up-to-date problem list of current and active diagnoses. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(5) (Problem list) 

Standards 

§ 170.207(a)(3) (SNOMED CT® International Release January 2012) 

Consistent with our discussion in the 

preamble section titled ‘‘Explanation 

and Revision of Terms Used in 

Certification Criteria,’’ we have replaced 

the terms ‘‘modify’’ and ‘‘retrieve’’ in 

the recommended criterion with 

‘‘change’’ and ‘‘access,’’ respectively. 

Further, consistent with the 

interpretation we provided in the S&CC 

July 2010 final rule, we are reiterating 

and clarifying that ‘‘longitudinal care’’ 

is used to mean over an extended period 

of time. For the ambulatory setting, this 

would be over multiple office visits. For 

the inpatient setting, 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. The HITSC 

suggested that we consider longitudinal 

care to cover multiple hospitalizations, 

but we believe 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. To note, 

our clarification of the meaning of 

longitudinal care applies equally to its 

use in other certification criteria, such 

as ‘‘medication list’’ and ‘‘medication 

allergy list.’’ If we were to change our 

interpretation of 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 

welcome comments on our 

interpretation of longitudinal care. We 

also welcome comments on whether a 

term other than ‘‘longitudinal care’’ 

could and should be used to express the 

capability required by this certification 

criterion and the other referenced 

certification criteria (‘‘medication list’’ 

and ‘‘medication allergy list’’). We 

understand that the longitudinal care 

description we use for the purposes of 

EHR technology certification may differ 

from the meaning that providers 

attribute to it, including the meaning 

given to it by the Longitudinal 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13847 

30http://wiki.siframework.org/ 

Longitudinal+Coordination+of+Care+WG. 

31http://www.nlm.nih.gov/research/umls/ 

licensedcontent/snomedctfiles.html. 

Coordination of Care Workgroup within 

the Standards and Interoperability 

Framework.30

The HITSC recommended that we 

adopt the appropriate version of 

SNOMED CT® for the revised criterion. 

We have determined, and propose to 

adopt, the International Release January 

2012 version of SNOMED CT.® This is 

the most recent version of the code 

set.31 The HITSC also recommended 

that ICD–9–CM be replaced with ICD– 

10–CM. We agree that the use of ICD– 

9–CM should no longer be required due 

to the pending move to ICD–10–CM. 

However, we do not believe it would be 

appropriate to require the use of ICD– 

10–CM for problem lists. SNOMED CT®

(and not ICD–10–CM) will be required 

for calculation of CQMs. Therefore, we 

propose that only SNOMED CT® is an 

appropriate standard for the recording 

of patient problems in a problem list. 

This does not, however, preclude the 

use of ICD–10–CM for the capture and/ 

or transmission of encounter billing 

diagnoses. We propose to adopt this 

revised certification criterion for the 

2014 Edition EHR certification criteria 

at § 170.314(a)(5) and the International 

Release January 2012 version of 

SNOMED CT® at § 170.207(a)(3). 

• Clinical decision support 

MU Objective 

Use clinical decision support to improve 

performance on high-priority health conditions. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(8) (Clinical decision support) 

Standard 

§ 170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval (‘‘Infobutton’’) Standard, 

International Normative Edition 2010) 

The HITSC recommended a revised 

clinical decision support (CDS) 

certification criterion for the 2014 

Edition EHR certification criteria. We 

have refined the 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 also propose 

to require the use of the HL7 ContextAware Knowledge Retrieval 

(‘‘Infobutton’’) Standard, International 

Normative Edition 2010, for retrieving 

diagnostic or therapeutic reference 

information and specifically require the 

use of CDS with the incorporation of a 

summary care record. 

We have replaced 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. A CDS intervention is not 

simply an alert, notification, or explicit 

care suggestion. Rather, it should be 

more broadly interpreted as the userfacing representation of evidence-based 

clinical guidance. Our goal in clarifying 

the nomenclature is 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. 

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. Increasingly, these 

tools are being made available through 

links in EHRs, offering information at 

relevant points within the clinical 

workflow. 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 propose to adopt its most recent 

edition (International Normative Edition 

2010) in order to enable a user to 

retrieve diagnostic or therapeutic 

reference information. The use of 

standard reference information retrieval 

formats will accelerate the delivery of 

content to providers and hospitals, and 

will enhance the flexibility of such 

implementations because these formats 

reduce the need to ‘‘hard wire’’ the 

content databases to installed EHR 

technology. This flexibility allows EPs, 

EHs, and CAHs more choices and easier 

migration across content providers, 

encouraging innovation and 

competitiveness among these content 

providers. 

We believe it is important for CDS 

interventions to be triggered when new 

information is incorporated into EHR 

technology as a result of a care 

transition. Therefore, we are proposing 

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) (transitions of care— 

incorporate summary care record). We 

are also considering 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 

request 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 stated 

intent, for EHR technology to be 

certified to this criterion 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. 

EHR technology must also be capable of 

generating interventions automatically 

and electronically when a user is 

interacting with the EHR technology. 

Last, the HITSC recommended that the 

source attributes of suggested 

interventions be displayed or available 

for users. We agree that this capability 

is important, but believe further 

clarification is necessary regarding what 

types of information must be provided 

for EHR technology to meet this 

criterion. We believe 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. The availability of this 

information will enable the user to fully 

evaluate the intervention. The 

availability of this information will also 

enhance the transparency of all CDS 

interventions, and thus improve their 

utility to healthcare professionals and 

patients. 

We propose to adopt this revised 

certification criterion at § 170.314(a)(8) 

and the Infobutton standard at 

§ 170.204(b)(1). 

• Patient-specific education resources 

MU Objective 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13848 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

32http://modularspecs.siframework.org/ 

NwHIN+SOAP+Based+Secure+Transport+Artifacts. 

Use clinically relevant information from Certified EHR Technology to identify patientspecific education resources and provide 

those resources to the patient. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(16) (Patient-specific education 

resources) 

Standard 

§ 170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval (Infobutton) Standard, 

International Normative Edition 2010) 

We propose 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 propose 

to adopt the HL7 Context-Aware 

Knowledge Retrieval (Infobutton) 

Standard, International Normative 

Edition 2010, as the required standard. 

Infobutton is being increasingly used by 

more providers to electronically identify 

and provide patient-specific education 

resources. Therefore, we believe it is 

appropriate now 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 

Infobutton. We propose to adopt this 

revised certification criterion at 

§ 170.314(a)(16) and the Infobutton 

standard at § 170.204(b)(1). 

• Transitions of care 

MU Objective 

The EP, EH, or CAH who transitions their 

patient to another setting of care or provider of care or refers their patient to another provider of care should provide 

summary care record for each transition 

of care or referral. 

2014 Edition EHR Certification Criteria 

§ 170.314(b)(1) (Incorporate summary of 

care record) 

§ 170.314(b)(2) (Create and transmit summary care record) 

Standards 

§ 170.205(a)(3) (Consolidated CDA); 

§ 170.207(f) (OMB standards for the classification of federal data on race and ethnicity); § 170.207(j) (ISO 639–1:2002 

(preferred language)); § 170.207(l) (smoking status types); 

§ 170.207(a)(3) (SNOMED–CT® International Release January 2012); 

§ 170.207(m) (ICD–10–CM); 

§ 170.207(b)(2) (HCPCS and CPT–4) or 

§ 170.207(b)(3) (ICD–10–PCS); 

§ 170.207(g) (LOINC version 2.38); 

§ 170.207(h) (RxNorm February 6, 2012 

Release); and § 170.202(a)(1) (Applicability Statement for Secure Health Transport); § 170.202(a)(2) (XDR and XDM for 

Direct Messaging); and § 170.202(a)(3) 

(SOAP–Based Secure Transport RTM 

version 1.0) 

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. 

We have made refinements to the 

recommended certification criterion. We 

believe that the criterion should be split 

into two separate certification criteria 

based on the capabilities required. We 

base this revision on stakeholder 

feedback received after the publication 

of the S&CC July 2010 final rule, which 

explained that (especially for inpatient 

settings) two different EHR technologies 

are sometimes used to perform the 

capabilities of incorporation and 

creation of a summary care record. 

Consequently, adopting two separate 

certification criteria provides developers 

greater flexibility for certification. The 

first proposed certification criterion 

would require EHR technology to be 

able to incorporate a summary care 

record formatted according to the 

Consolidated CDA, and the second 

certification criterion would require that 

EHR technology be capable of 

generating and transmitting a summary 

care record in accordance with the 

Consolidated CDA, with certain 

specified vocabulary standards, and two 

specified transport standards. 

For the same reasons we discussed for 

the new ‘‘view, download, and transmit 

to 3rd party’’ certification criterion 

(§ 170.314(e)(1)), we believe that 

adopting the Consolidated CDA for this 

certification criterion is advantageous 

since its template structure can 

accommodate the formatting of a 

summary care record that includes all of 

the data elements that CMS is proposing 

be available to be populated in a 

summary care record. We recognize 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 elements included in the clinical 

summary. 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 have not proposed, 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 request 

public comment on whether in the final 

rule we should create separate 

certification criteria for all of these data 

elements. For certain other data 

elements in § 170.314(b)(2), we propose 

to require that the capability to provide 

the information be demonstrated in 

accordance with the specified 

vocabulary standard. These vocabulary 

standards have been previously adopted 

or are proposed for adoption in this 

proposed rule consistent with the 

recommendations of the HITSC. 

Additionally, we request 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. This 

would help prevent two different 

patients summary care records from 

being combined. 

As with the ‘‘view, download, and 

transmit to 3rd party’’ certification 

criterion, we are proposing that EHR 

technology be capable of transmitting a 

summary care record according to both 

the transport standards we propose to 

adopt to enable directed exchange. We 

believe the use of these standards is a 

critical first step in achieving a common 

means of transporting health 

information to support MU and future 

exchange needs. For this certification 

criterion, we also propose to adopt as an 

optional standard at § 170.202(a)(3) the 

SOAP–Based Secure Transport RTM 

version 1.0 32 which was developed 

under the nationwide health 

information network Exchange Initiative 

and to which we believe EHR 

technology should be able to be 

certified. We believe including this 

option provides 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. While 

we would only permit EHR technology 

to be certified to these two transport 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13849 

standards, we intend to monitor 

innovation around transport and would 

consider including additional transport 

standards, such as a RESTful 

implementation, in this certification 

criterion. The inclusion of additional 

standards in this certification criterion 

would permit EHR technology to be 

certified to added transport standard(s) 

and could ultimately enable EPs, EHs, 

and CAHs to meet MU using EHR 

technology certified with the added 

transport standard(s). 

In deciding whether additional 

standards are appropriate for inclusion, 

we would seek the HITSC’s 

recommendation on whether a new 

transport standard should be adopted. 

We expect that the HITSC would 

consider, among other factors, whether 

the standard is ‘‘open’’ or nonproprietary, the public comment 

processes involved in its development, 

and any pilot testing completed/results. 

If the HITSC were to recommend that 

we adopt an additional transport 

standard, we believe that it should be 

designated as optional (consistent with 

our discussion at 75 FR 44599) and that 

we would likely pursue interim final 

rulemaking with comment to adopt the 

transport standard, which would enable 

EHR technology to be expeditiously 

certified to the transport standard and 

EPs, EHs, and CAHs to subsequently use 

EHR technology certified to this added 

transport standard to meet MU. 

We welcome comments on whether 

equivalent alternative transport 

standards exist to the ones we propose 

to exclusively permit for certification. 

We also welcome comment on our 

proposed approaches for deciding 

whether additional transport standards 

are 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 request 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 propose to adopt. 

We propose to adopt these revised 

certification criteria for the 2014 Edition 

EHR certification criteria at 

§ 170.314(b)(1) and (2). 

• Clinical information reconciliation 

MU Objective 

The EP, EH, or CAH who receives a patient 

from another setting of care or provider of 

care or believes an encounter is relevant 

should perform medication reconciliation. 

2014 Edition EHR Certification Criterion 

§ 170.314(b)(4) (Clinical information reconciliation) 

In the S&CC January 2010 interim 

final rule, we adopted a certification 

criterion for medication reconciliation 

that stated ‘‘[e]lectronically complete 

medication reconciliation of two or 

more medication lists by comparing and 

merging into a single medication list 

that can be electronically displayed in 

real-time.’’ In response to public 

comments requesting additional clarity 

and expressing concerns that EHR 

technology should not automatically 

(i.e., without any human intervention) 

be required to perform this capability, 

we revised this certification criterion 

(adopted at § 170.302(j) in the S&CC July 

2010 final rule) to say ‘‘[e]nable a user 

to electronically compare two or more 

medication lists.’’ 

At the end of one of our responses to 

comments in the S&CC July 2010 final 

rule, we stated ‘‘[w]e do, however, see 

great promise in making this capability 

more comprehensive and anticipate 

exploring ways to improve the utility of 

this capability before we adopt a 

subsequent round of certification 

criteria’’ (75 FR 44613). We now 

propose 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 elements in each 

of a patient’s medication, problem, and 

medication allergy lists. We believe that 

EHR technology can be designed to 

assist users in remarkable ways and that 

reconciling information from multiple 

sources in a way that is assistive to a 

user is something at which EHR 

technology should excel. We also 

believe that with an increased focus on 

care coordination and use of CDS for 

advanced care processes, it will be 

significantly more important for EPs, 

EHs, and CAHs to have accurate and 

updated medication, problem, and 

medication allergy lists. 

Accordingly, we propose a revised 

certification criterion which we are 

labeling as ‘‘clinical information 

reconciliation’’ to express three specific 

capabilities that EHR technology would 

need to include. First, EHR technology 

would need to be able to electronically 

display the data elements from two or 

more sources in a manner that allows a 

user to view the data elements and their 

attributes, which must include, at a 

minimum, the source and last 

modification date of the information. 

For example, when assisting a user to 

reconcile a medication list, the EHR 

technology would need to display the 

medication(s) and, at a minimum, the 

source of medications (e.g., ‘‘patient’’ or 

‘‘summary care record from XYZ’’) and 

the last modification date of the 

information associated with those 

medications. The second medication 

source in this example would be the 

current medication list the EHR 

technology maintains for the patient. 

The second specific capability EHR 

technology would need to include 

would be to enable a user to merge and 

remove individual data elements. For 

example, if a medication from source #1 

and a medication from source #2 were 

the same, the user would be able to use 

EHR technology to merge such 

medications into a single representation. 

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 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. Per comments on our prior 

rules, we want to make clear that EHR 

technology’s role is to be assistive and 

not to determine without human 

judgment which data elements should 

be reconciled. Thus, this third specific 

capability would require EHR 

technology to present a final set of 

merged data elements for a user to 

validate and confirm before updating 

the prior list. Finally, we request 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. This 

would help prevent two different 

patients’ clinical information from being 

reconciled. We propose to adopt this 

revised certification criterion at 

§ 170.314(b)(4). 

• Incorporate laboratory tests and 

values/results 

MU Objective 

Incorporate clinical laboratory test results 

into Certified EHR Technology as structured data. 

2014 Edition EHR Certification Criterion 

§ 170.314(b)(5) (Incorporate laboratory tests 

and values/results) 

Standards and Implementation Specifications 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13850 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

33Quality Data Model—National Quality Forum: 

http://www.qualityforum.org/Projects/h/ 

QDS_Model/Quality_Data_Model.aspx. 

§ 170.205(k) (HL7 2.5.1 and HL7 Version 

2.5.1 Implementation Guide: Standards 

and Interoperability Framework Lab Results Interface, Release 1 (US Realm)); 

and § 170.207(g) (LOINC version 2.38) 

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 believe, however, that 

we should leverage the significant 

progress made by the S&I Framework 

LRI discussed under the proposed new 

certification criterion for the 

transmission of electronic laboratory 

tests and values/results to ambulatory 

providers (§ 170.314(b)(6)). This can be 

achieved by proposing revisions to this 

certification criterion for the ambulatory 

setting. 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, 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 propose to adopt LOINC 

version 2.38 as the vocabulary standard, 

because the LRI implementation guide 

requires the use of LOINC for laboratory 

tests. We request 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) is 

generalizable to an inpatient setting and 

could be adopted for certification for 

that setting as well. Besides the 

proposed revisions discussed, we have 

used the term ‘‘incorporate’’ to replace 

the terms ‘‘attribute,’’ ‘‘associate,’’ and 

‘‘link’’ which were used in the 2011 

Edition EHR certification criterion. 

We propose to adopt this revised 

certification criteria for the 2014 Edition 

EHR certification criteria at 

§ 170.314(b)(5). We propose to adopt the 

HL7 2.5.1 standard and LRI 

implementation guide at § 170.205(k), 

acknowledging that the LRI 

specification is currently undergoing 

HL7 balloting. We intend to continue to 

monitor its progress and anticipate that 

a completed specification will be 

available before we publish a final rule. 

We propose to adopt LOINC version 

2.38 at § 170.207(g). 

• Clinical quality measures 

MU Objective 

N/A 

2014 Edition EHR Certification Criteria 

§ 170.314(c)(1) (Clinical quality measures— 

capture and export) 

§ 170.314(c)(2) (Clinical quality measures— 

incorporate and calculate) 

§ 170.314(c)(3) (Clinical quality measures— 

reporting) 

Standard 

§ 170.204(c) (NQF Quality Data Model) 

The HITSC recommended certain 

vocabularies and codes sets for 

inclusion in the Quality Data Model 

(QDM),33 but did not recommend CQM 

certification criteria or offer 

recommendations for the certification of 

CQMs. For the 2014 Edition EHR 

certification criteria, we propose to 

revise previously adopted CQM 

certification criteria for the ambulatory 

and inpatient settings to specify more 

explicitly the capabilities EHR 

technology would need to include, 

focusing 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 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. 

• Reporting—The capability of EHR 

technology to create a standard data file 

that can be electronically accepted by 

CMS. 

By explicitly separating the certification 

of CQMs into these discrete criteria, we 

believe that user experiences relative to 

CQMs can be enhanced, the burden of 

capturing data elements necessary for 

CQMs can 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 

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. To 

assist in the effort of preparing CQMs in 

a more uniform manner, the National 

Quality Forum (NQF), under contract 

with CMS, created the QDM which 

today serves as the information model 

from which new CQMs are specified. 

Because older CQMs were not specified 

as ‘‘EHR-ready’’ when initially 

developed, they 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 now understand 

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 

have been informed 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 elements in a consistent 

manner that would enable such data to 

be captured for a CQM calculation. 

To build on past feedback and lessons 

learned, we have, with CMS, jointly 

conducted extensive research, consulted 

with subject matter experts, and 

received recommendations (on CQMs 

generally) from the HITPC and HITSC. 

We have sought to determine how to 

best address the difference between the 

data capture capabilities we believe 

most EHR technologies can reasonably 

perform and the requirements that 

measure stewards have specified in 

CQMs. This work has led us to believe 

that a more explicit and extensible 

approach for CQM certification is 

required, an approach that would be 

able to support the CQMs proposed for 

MU Stages 1 and 2 beginning in FY/CY 

2014 as well as CQMs adopted for future 

MU stages. 

The CQM lifecycle starts with the 

determination of data elements to be 

captured and the subsequent capture of 

clinical or demographic data. Thus, the 

first specific capability we propose for 

CQM certification (§ 170.314(c)(1)(i)) 

focuses on the capability of EHR 

technology to electronically record all of 

the data elements that are represented in 

the QDM. More specifically, 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. As a 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13851 

‘‘state of being.’’ 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, 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. 

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 do 

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, 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. Furthermore, because data 

capture is fundamental to the eventual 

calculation of CQMs, we have proposed 

an EP, EH, or CAH would need to have 

EHR technology certified to 

§ 170.314(c)(1) in order to have EHR 

technology that meets the definition of 

a Base EHR (discussed later in this 

preamble). 

We recognize that EPs, EHs, and 

CAHs may employ many methods to 

capture the information required by 

CQMs and we do not intend for this 

certification criterion to imply that EHR 

technology developers would need to 

include manual data entry requirements 

if such data can be easily obtained from 

other electronic sources. For example, 

we anticipate that a patient’s smoking 

status could be captured through a 

variety of approaches such as an ‘‘app’’ 

on a mobile phone, a portal, personal 

health record (PHR), from a patient 

registration kiosk, or practice 

management system. Regardless of the 

data’s origin or source system, an EHR 

technology developer would need to 

show for certification that its EHR 

technology can electronically record a 

representation of that data. Moreover, 

we do not require for certification that 

data must be recorded according to a 

specific vocabulary standard, in 

recognition of, and to accommodate, 

environments in which local codes and 

terminologies have been used or where 

the data may originate from another 

electronic source. We do, however, 

expect that wherever possible, EHR 

technology developers will use standard 

vocabularies as this will minimize the 

need for mapping processes that will 

require development and maintenance. 

As described below, we expect that 

exported quality data would be 

formatted according to the standard 

vocabularies in the QDM, where 

applicable. 

Alternative Data Capture Certification 

Options Considered 

The above proposal for data capture 

represents the certification option that 

best describes the capabilities that EHR 

technology would need to include in 

order to capture the data required for 

the EHR Incentive Programs CQM 

proposals from CMS. We recognize that 

this option may be a suboptimal longterm solution—compared to one that 

can fundamentally reshape the path 

measure stewards take to develop ‘‘EHRready’’ CQMs. Through our work with 

CMS, it has become clear that gaps still 

remain between the data capture 

expectations of the CQMs included by 

CMS in its Stage 2 proposed rule and 

the capabilities of EHR technology. 

While the QDM was created in order to 

facilitate the development of ‘‘EHRready’’ CQMs, it is a model that reflects 

the data representation of CQMs and 

does not consider whether a given data 

type would or should be captured by 

EHR technology. We recognize that the 

gap between the data defined by the 

QDM and the data traditionally 

captured in EHR technology is, in some 

areas, broad and we request 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. 

Additionally, we recognize that some 

specialty-focused EHR technologies may 

not need to capture all of the data that 

the QDM describes. We request public 

comment regarding how certification 

can 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. 

We believe that there are alternative 

options to our proposal and request 

public comment with respect to whether 

we should pursue one or more of the 

alternative approaches below for 

certification in the final rule. 

• CQM-by-CQM Data Capture: Our 

proposed data capture certification 

criterion specifies that EHR technology 

must be able to capture all of the data 

elements represented in the QDM. As an 

alternative to our proposal, we 

considered an approach to certification 

for data capture that would be based on 

the data elements reflected in the 

individual CQMs selected by CMS 

instead of the entire QDM. When EHR 

technology is presented for certification 

for data capture, the developer would 

identify the specific CQMs that the 

technology is capable of supporting, and 

the technology must capture each and 

every data element reflected in those 

CQMs in order to be certified. For 

example, if a developer presents for 

certification EHR technology designed 

for an inpatient (e.g., emergency 

department) setting that would support 

the hospital quality measures NQF 0495 

and 0497, the technology would have to 

demonstrate that it could capture all of 

the data elements included in those 

measures. An EHR technology 

developer would design its EHR 

technology to capture the data elements 

for those CQMs it believed its EHR 

technology would need to support for 

the types of providers to which it 

markets its EHR technology. We believe 

this approach may be advantageous 

because it poses a lower initial burden 

for EHR technology developers. But it 

also has its disadvantages because it 

could lead to 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. 

We request public comment on whether 

we should take this approach instead of 

our proposal on certification for data 

capture. 

• Explicit Certification Criteria: In 

some cases, we recognize that while not 

required for certification, many EHR 

technologies already capture data 

elements included in the QDM. For 

example, inactive medical problems 

may be captured and represented as past 

medical history. For these cases, we 

considered and believe 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, 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, 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13852 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

34A negation exclusion or exception is a factor 

that removes a given patient from the denominator 

of a CQM with a statement about why a given event 

or intervention did not occur. For example, a CQM 

may state that all patients with X condition must 

have Y intervention, except patients who did not 

receive the intervention for reason Z. A CQM may 

state that all patients over the age of 6 months 

should have an influenza vaccine between October 

and February (Y intervention), except patients with 

allergy to egg albumin (reason Z–1) or patients who 

decline vaccination (reason Z–2). In some measures, 

the unit of analysis is not a patient, but an 

encounter or a procedure. In such measures the 

exclusion or exception can apply to individual 

patient factors or factors affecting the specific unit 

of analysis. Additionally, exclusions for ratio 

measures can also remove a patient from the 

numerator. 

reason.’’ We request public comment on 

whether this approach would be 

preferred, which certification criteria 

should be expanded, and where new 

certification criteria would be 

appropriate. We believe this approach 

could also ensure when EHR Modules 

are used in combination to meet the 

definition of CEHRT that all of the data 

necessary to capture for CQM 

calculations would be electronically 

available. 

• CQM Exclusions: Our research 

indicates that CQM exclusions represent 

the majority of CQM data that are 

expected by measure stewards to be 

captured or represented in EHR 

technology but are not. In cases where 

a CQM specifies a negation exclusion,34

we propose that EHR technology would 

not be required to capture the ‘‘reason’’ 

justification attribute of any data 

element in an encoded way. Rather, we 

would permit ‘‘reason’’ to allow for free 

text entries. For calculation and 

reporting purposes, the presence of text 

in the ‘‘reason’’ field may be used as a 

proxy for any ‘‘reason’’ attribute. We 

request public comment regarding the 

impact this flexibility would have on 

the accuracy of CQM reporting. 

• Constrain the QDM: Working with 

CMS and NQF, we have 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. 

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. Such CQMs would be identified 

as ‘‘2014-EHR-ready’’ while other CQMs 

would not. We would subsequently 

collaborate with CMS to remove CQMs 

that do 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. 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. CDS can 

provide the interactive capability that 

would be required in order to capture 

the granular exclusion data that is 

expected today by many CQMs. With 

the inclusion of CDS in the clinical 

quality improvement strategy for future 

stages of this program, we expect to be 

able to remove the flexibility outlined 

above for the capture of ‘‘reason’’ 

attributes. This would improve the 

accuracy of CQMs while retaining 

optimal clinical workflow, as CDS 

would ideally be engaged to prompt for 

this information only where indicated, 

rather than in all cases. We seek public 

comment, especially from measure 

stewards, as to the difficulty and 

timeliness with which CQMs could be 

re-specified in accordance with the 

constrained QDM style guide. 

• Explicit Data Capture List: Another 

approach we considered instead of 

specifying the QDM would be 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. 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 

Equally fundamental to data capture 

is the ability of EHR technology to put 

the data that has been captured to use. 

Thus, we believe that it is prudent to 

propose that EHR technology presented 

for certification not only be able to 

capture data for CQMs based on the 

QDM, but be able to export this data as 

it is represented in the QDM in the 

event that an EP, EH, or CAH chooses 

to use another certified EHR Module to 

perform the calculation of CQM 

results—which is why we include the 

export capability as part of the 

certification criterion proposed at 

§ 170.314(c)(1). We recognize that in 

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 Base 

EHR, 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 

would 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 are unaware of the 

existence of a widely adopted standard 

to export captured CQM data. Thus, for 

certification, 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. While this scenario 

is not ideal, we believe 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. We request 

comment on whether any standards 

(e.g., QRDA category 1 or 2, 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. 

Calculation 

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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13853 

35http://healthit.hhs.gov/portal/server.pt/ 

community/onc_regulations_faqs/3163/faq_12/ 

20774. 

36https://questions.cms.hhs.gov/app/answers/ 

detail/a_id/10649. 

§ 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. 

In the S&CC July 2010 final rule, we 

adopted at § 170.304(j) the CQM 

certification criterion for EHR 

technology designed for an ambulatory 

setting. As expressed in the S&CC July 

2010 final rule and in ONC FAQ 9–10– 

012 35 and CMS FAQ 10649,36 this 

certification criterion was treated as a 

threshold. In other words, 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, and if there 

was an additional CQM that the EHR 

technology included, CMS permitted 

the EP to report on that CQM, even 

though it was not expressly listed on the 

CHPL. 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. Other EHR 

technology developers took the opposite 

approach and sought certification for 

more than the 9 CQMs. Those EHR 

technologies were consequently listed 

on the CHPL as being certified to more 

CQMs. We seek 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 believe this 

approach provides 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. 

As noted above, we anticipate 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 this reason, we propose a 

separate certification criterion for the 

calculation of CQMs. We believe this 

separation enables market flexibility 

and creates room for innovation. The 

certification criterion we propose 

includes two specific capabilities. The 

first capability 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. In 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 do 

not believe that it would be necessary 

for an EHR technology to demonstrate 

its compliance to § 170.314(c)(2)(i). 

However, we specifically request public 

comment on this assumption before we 

will add this exception to the 

certification criterion, which we may do 

in our final rule. 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), focuses on an EHR 

technology’s ability to calculate each 

CQM for which it is presented for 

certification. For example, 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, 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. 

It is our expectation that EHR 

technology certified to this criterion 

would be capable of accurately, and 

without errors, calculating CQMs. We 

expect the accuracy of these 

calculations would be verified through 

thorough testing. We request 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 could foresee 

a scenario 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. We recognize 

that this scenario could present 

challenges for providers who possess 

licenses to such mismatched certified 

EHR modules and we request comment 

regarding this scenario and its 

likelihood and any additional methods 

we could employ to mitigate this risk. 

Reporting 

The last CQM-oriented certification 

criterion we propose would require EHR 

technology to enable a user to 

electronically create for transmission 

CQM results in a data file defined by 

CMS. We expect 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. 

Similar to other CMS quality programs’ 

reporting requirements, we expect that 

CMS would make available the XML 

data file template in time for us to adopt 

it in our final rule. We believe that this 

approach gives EPs, EHs, and CAHs a 

default solution for reporting CQMs 

electronically. We note 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. 

• Auditable events and tamperresistance; and audit report(s) 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criteria 

§ 170.314(d)(2) (Auditable events and tamper-resistance) 

§ 170.314(d)(3) (Audit report(s)) 

Standard 

§ 170.210(e) (Record actions related to 

electronic health information, audit log 

status, and encryption of end user devices) 

The HITSC recommended two revised 

certification criteria—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). It also recommended, for 

clarity, that we move the specific 

capability ‘‘detection’’ from the integrity 

certification criterion (§ 170.302(s)(3)) to 

the proposed auditable events and 

tamper-resistance certification criterion. 

Further, it recommended two versions 

of this certification criterion. We agree 

with the HITSC’s recommendations 

because they provide more flexibility 

and are consistent with the stakeholder 

feedback we have received since the 

publication of the S&CC July 2010 final 

rule. As for the two recommended 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13854 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

37http://oig.hhs.gov/oas/reports/other/ 

180930160.pdf. 

38http://www.hhs.gov/ocr/privacy/hipaa/ 

administrative/breachnotificationrule/ 

breachrept.pdf. 

39http://www.hhs.gov/ocr/privacy/hipaa/ 

administrative/breachnotificationrule/ 

brguidance.html. 

40http://csrc.nist.gov/publications/nistpubs/800- 

111/SP800-111.pdf. 

41Consistent with NIST SP 800–111, we consider 

‘‘end-user devices’’ to include, but not be limited 

to: personal computers, laptops, smart phones, 

tablet computers, external memory devices and 

similar removable storage media (e.g., universal 

serial bus [USB] flash drive, memory card, external 

hard drive, writeable or re-writeable CD or DVD). 

versions of the certification criterion, we 

propose a certification criterion that 

combines both recommended versions. 

Stakeholder feedback has indicated 

that splitting this 2011 Edition 

certification criterion into two separate 

certification criteria would permit a 

wider variety of EHR technologies to be 

certified as EHR Modules. We have also 

expanded upon the scope of the 

HITSC’s recommendation to address 

input from the HHS Office of Inspector 

General (May 2011 report 37) and 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. 

This expansion includes 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 are proposing a 

revised standard at § 170.210(e) and 

proposing 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 enduser 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. 

We did not use the phrase ‘‘securityrelevant events’’ in the standard, as 

recommended by the HITSC, because 

we believe it is ambiguous and provides 

insufficient guidance in terms of what 

constitutes an event that would need to 

be audited. Rather, we believe that the 

proposed minimum set of actions that 

would be required to be captured 

provides greater clarity for EHR 

technology developers and allows for 

consistent testing. Finally, we 

acknowledge, as recommended by the 

HITSC, that an example implementation 

specification which 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. We 

propose to adopt these revised 

certification criteria at § 170.314(d)(2) 

and (3); and the revised standard at 

§ 170.210(e). 

• Encryption of data at rest 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(7) (Encryption of data at rest) 

The HITSC recommended that we 

revise the ‘‘general encryption’’ 

certification criterion adopted at 

§ 170.302(u) 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. Their rationale, 

with which we agree, was that this 

approach would be more practical, 

effective, and easier to implement than 

the otherwise general encryption 

requirement adopted at § 170.302(u). 

Further, we interpret this HITSC 

recommendation to suggest 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 unsecured protected health 

information 38). The OIG provided 

similar rationale in its May 2011 report 

(cited above) in which it recommended 

that ONC address IT security controls 

for encrypting data on mobile devices. 

Additionally, we understand that the 

HITSC intended to recommend a 

certification criterion that would 

complement already existing HHS 

policy related to breaches of unsecured 

protected health information (i.e., the 

guidance from the HHS Office for Civil 

Rights on rendering unsecured 

protected health information unusable, 

unreadable, or indecipherable to 

unauthorized individuals 39). As noted 

in the guidance provided by the HHS 

Office for Civil Rights, NIST Special 

Publication (SP) 800–111 40 serves as a 

resource to guide how encryption 

should be applied to end-user devices. 

This proposed certification criterion 

is drafted to permit EHR technology 

developers to demonstrate in one of two 

ways that a Complete EHR or EHR 

Module is compliant. The first way, 

§ 170.314(d)(7)(i), accounts for 

circumstances in which EHR technology 

is designed to manage electronic health 

information on end-user devices 41 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 use 

‘‘stopped’’ to mean that the session has 

been terminated, including the 

termination of the network connection. 

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), this capability must be enabled 

(i.e., turned on) by default and only be 

permitted to be disabled (and reenabled) by a limited set of identified 

users. We did not include ‘‘decrypt’’ in 

the proposed certification criterion 

because we believe that the critical 

capability to require for certification is 

the act of encryption after use of the 

EHR technology on the end-user device 

has stopped. We presume that EHR 

technology developers would also 

include the capability to decrypt the 

electronic health information, when 

appropriate; otherwise subsequent use 

or access to the data would not be 

possible. We use the phrase ‘‘manages 

electronic health information’’ in this 

certification criterion to mean that the 

EHR technology is designed in a way 

that it can 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. For example, if an EHR 

technology is 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13855 

specified at § 170.314(d)(7)(i) in order to 

be certified. 

We recognize that in some scenarios 

EHR technology may not be designed to 

manage electronic health information on 

the end-user devices on which a user 

may ultimately choose to store 

electronic health information. For 

example, an EHR technology may not be 

designed to manage electronic health 

information on a USB-drive, but a user 

may choose to store electronic health 

information from the EHR technology 

on such an end-user device. We wish to 

make clear that in order to comply with 

this certification criterion, an EHR 

technology developer would not need to 

anticipate such scenarios. More 

specifically, the EHR technology 

developer would not have to 

demonstrate for certification that the 

EHR technology could encrypt 

electronic health information on the 

USB-drive (or similar end-user device) 

since the EHR technology was not 

designed to manage electronic health 

information on that USB-drive. We 

further note that if a user chooses to 

store electronic health information on 

an end-user device on which EHR 

technology was not designed to manage 

electronic health information, then the 

user would be responsible for ensuring 

such information is protected in 

accordance with applicable law. 

The second way to demonstrate 

compliance with this certification 

criterion would be for an EHR 

technology developer to demonstrate 

that its EHR technology can 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 believe this alternative 

method is 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). An example of this 

circumstance would be a situation 

where an EHR technology is designed to 

manage a client application on an enduser device (locally or over the Internet) 

and the client application enables the 

user to complete a full suite of actions 

related to electronic health information. 

Once the use of EHR technology on the 

end-user device has stopped, the 

electronic health information does not 

remain on the device on which the 

client application was executed. 

We propose to adopt this revised 

certification criterion at § 170.314(d)(7). 

• Immunization registries 

MU Objective 

Capability to submit electronic data to immunization registries or immunization information systems except where prohibited, and in accordance with applicable 

law and practice. 

2014 Edition EHR Certification Criteria 

§ 170.314(f)(1) (Immunization information) 

§ 170.314(f)(2) (Transmission to immunization registries) 

Standards and Implementation Specifications 

§ 170.205(e)(3) (HL7 2.5.1 and Implementation Guide for Immunization Messaging 

Release 1.3); and 

§ 170.207(i) (CVX code set: August 15, 

2011 version) 

The HITSC recommended that we 

consider splitting this certification 

criterion into two criteria—one focused 

on the data capture and the other 

focused on the formatting of such data 

in the proposed standards and 

implementation specifications. We have 

followed this recommendation and 

propose two separate certification 

criteria. We believe this approach 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. We note 

that we are discussing these criteria 

together for simplicity and to prevent 

confusion, but we do not consider the 

certification criterion we propose to 

focus on data capture to be a ‘‘revised’’ 

certification criterion. Rather, we 

believe that the certification criterion 

proposed at § 170.314(f)(1) constitutes 

an unchanged certification criterion 

because all the capabilities included in 

the criterion are the same as the 

capabilities included in the 

corresponding 2011 Edition EHR 

certification criterion (§ 170.302(k)). 

For the certification criterion 

proposed at § 170.314(f)(1), consistent 

with our discussion in the preamble 

section titled ‘‘Explanation and Revision 

of Terms Used in Certification Criteria,’’ 

we have replaced the terms ‘‘retrieve’’ 

and ‘‘modify’’ in the revised criterion 

with ‘‘access’’ and ‘‘change,’’ 

respectively. For the certification 

criterion proposed at § 170.314(f)(2), we 

have stated the ‘‘transmission 

capability’’ as the capability to 

electronically create immunization 

information for electronic transmission 

in accordance with the applicable 

standards and implementation 

specifications. We clarify that this 

criterion focuses on the capability of 

EHR technology to properly create for 

transmission immunization information 

in accordance with the applicable 

standards and implementation 

specifications. 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. 

The HITSC recommended, and we 

agree, that the use of only the HL7 2.5.1 

standard should be permitted for 

submitting immunization information 

because immunization registries are 

rapidly moving to this standard. In 

consultation with the Centers for 

Disease Control and Prevention, we also 

propose to adopt the HL7 2.5.1 

Implementation Guide for 

Immunization Messaging Release 1.3 as 

the implementation specification. This 

release provides corrections and 

clarifications to Release 1.0 and 

contains new guidance on how to 

message vaccines for children (VFC) 

eligibility. Finally, we propose to adopt 

the August 15, 2011 version of CVX 

code sets. We propose to adopt the 

revised certification criteria for the 2014 

Edition EHR certification criteria at 

§ 170.314(f)(1) and (2). We propose to 

adopt the HL7 2.5.1 standard with 

implementation guide at § 170.205(e)(3) 

and the CVX code set at § 170.207(i). 

• Public health agencies 

MU Objective 

Capability to submit electronic syndromic 

surveillance data to public health agencies except where prohibited, and in accordance with applicable law and practice. 

2014 Edition EHR Certification Criteria 

§ 170.314(f)(3) (Public health surveillance) 

§ 170.314(f)(4) (Transmission to public 

health agencies) 

Standards and Implementation Specifications 

§ 170.205(d)(2) (HL7 2.5.1) and 

§ 170.205(d)(3) (HL7 2.5.1 and the PHIN 

Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data HL7 Version 2.5.1) 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13856 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

Similar to the immunization 

certification criteria above, the HITSC 

recommended that we consider splitting 

the public health surveillance 

certification criterion into two separate 

certification criteria. We have followed 

this recommendation, and we have 

made similar wording changes to these 

proposed certification criteria for the 

same reasons expressed in the revisions 

to the certification criteria for 

immunization information and 

transmission. As noted under the 

proposed immunization certification 

criteria, we are discussing these two 

proposed syndromic surveillance 

criteria together for simplicity and to 

prevent confusion, but we do not 

consider the certification criterion we 

propose to focus on data capture to be 

a ‘‘revised’’ certification criterion. 

Rather, we believe that the certification 

criterion proposed at § 170.314(f)(3) 

constitutes an unchanged certification 

criterion because all the capabilities 

included in the criterion are the same as 

the capabilities included in the 

corresponding 2011 Edition EHR 

certification criterion (§ 170.302(l)). 

The HITSC recommended and we 

agree that the use of only the HL7 2.5.1 

standard should be permitted for 

formatting syndrome-based public 

health surveillance information because 

public health agencies are rapidly 

moving to this standard and all 

stakeholders would benefit from 

focusing on a single public health 

surveillance standard. The HITSC also 

recommended and we agree that the 

standard be constrained for hospitals 

with the PHIN Messaging Guide for 

Syndromic Surveillance: Emergency 

Department and Urgent Care Data HL7 

Version 2.5.1. We also believe that 

certification of ambulatory EHR 

technology to this guide can be useful 

for EHR developers that provide EHR 

technology to eligible professionals that 

practice in urgent care settings. 

Therefore, we propose that certification 

to this guide be optional for the 

ambulatory setting. We propose to adopt 

the revised certification criteria for the 

2014 Edition EHR certification criteria 

at § 170.314(f)(3) and (4) and the HL7 

2.5.1 standard and implementation 

guide for the inpatient setting (and 

optional for the ambulatory setting) at 

§ 170.205(d)(3). The required exchange 

standard for the ambulatory setting has 

already been adopted at § 170.205(d)(2). 

• Automated measure calculation 

MU Objective 

N/A 

2014 Edition EHR Certification Criterion 

§ 170.314(g)(2) (Automated measure calculation) 

We propose to adopt a revised 

automated measure calculation 

certification criterion for the 2014 

Edition EHR certification criteria. We 

have 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. To be clear, the capabilities to 

which we refer are the capabilities 

included in the certification criteria to 

which the EHR technology is presented 

for certification. 

We want to emphasize 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 believe that testing to 

ensure the accuracy of these 

calculations would significantly reduce 

the reporting burden for MU attestation. 

Additionally, testing and certification to 

this proposed 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 in this 

rule that are adopted in a final rule. 

We propose to adopt this revised 

certification criterion at § 170.314(g)(2). 

b. Ambulatory Setting 

We propose to adopt the following 

revised certification criteria for the 

ambulatory setting. 

• Electronic prescribing 

MU Objectives 

Generate and transmit permissible prescriptions electronically (eRx). 

2014 Edition EHR Certification Criterion 

§ 170.314(b)(3) (Electronic prescribing) 

Standards 

§ 170.205(b)((2) (NCPDP SCRIPT version 

10.6) and § 170.207(h) (RxNorm February 

6, 2012 Release) 

The HITSC recommended that we 

adopt a revised certification criterion for 

the ambulatory setting that required the 

use of RxNorm as the vocabulary 

standard. We agree that RxNorm should 

be adopted as the vocabulary standard 

instead of the current adopted standard 

which specifies any source vocabulary 

that is included in RxNorm. 

Additionally, with respect to content 

exchange standards, we are proposing to 

no longer include the use of NCPDP 

SCRIPT version 8.1 as a way to meet the 

2014 Edition EHR certification criterion 

because we understand that CMS is 

planning to propose retiring this 

standard (adopted as a Medicare Part D 

e-prescribing standard) in a proposed 

rule that is scheduled to be issued soon 

after this proposed rule is published. If 

we should receive 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 believe that it 

is appropriate for this certification 

criterion to be adopted for both the 

ambulatory and inpatient settings (as 

discussed under the proposed new 

certification criteria section) as it 

supports our desired policy and 

interoperability outcome for content 

exchange standards to be used when 

information is exchanged between 

different legal entities. We propose to 

adopt this revised certification criterion 

at § 170.314(b)(3) and the February 6, 

2012 Release of the RxNorm standard at 

§ 170.207(h). 

• Clinical summaries 

MU Objective 

Provide clinical summaries for patients for 

each office visit. 

2014 Edition EHR Certification Criterion 

§ 170.314(e)(2) (Ambulatory setting only— 

clinical summaries) 

Standards 

§ 170.205(a)(3) (Consolidated CDA); 

§ 170.207(f) (OMB standards for the classification of federal data on race and ethnicity); § 170.207(j) (ISO 639–1:2002 

(preferred language)); § 170.207(l) (smoking status types); 

§ 170.207(a)(3) (SNOMED–CT® International Release January 2012); 

§ 170.207(m) (ICD–10–CM); 

§ 170.207(b)(2) (HCPCS and CPT–4) or 

§ 170.207(b)(3) (ICD–10–PCS); 

§ 170.207(g) (LOINC version 2.38); and 

§ 170.207(h) (RxNorm February 6, 2012 

Release) 

The HITSC recommended that the 

certification criterion be revised for the 

2014 Edition EHR certification criteria 

to reflect the proposed new and revised 

standards for problem lists and other 

vocabulary standards. We agree with 

these recommendations. We have made 

several refinements to the recommended 

revised certification criterion to ensure 

that EHR technology meets the 

appropriate standards and is capable of 

making available the information CMS 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13857 

is proposing be provided to a patient 

after an office visit. 

We further propose that when 

information is provided electronically, 

the information be provided according 

to the Consolidated CDA standard. For 

the same reasons as provided in the new 

‘‘view, download, and transmit to 3rd 

party’’ certification criterion discussion, 

we believe that adopting the 

Consolidated CDA for this certification 

criterion is advantageous since its 

template structure can accommodate the 

formatting of a summary care record 

that includes all of the data elements 

that CMS is proposing be provided to a 

patient after an office visit. As we 

similarly noted in the discussion of the 

transitions of care certification criteria 

(§ 170.314(b)(1) and (2)), we considered, 

but have not proposed, adopting 

separate certification criteria to 

explicitly require the capture of unique 

data elements included in clinical 

summaries, such as care plans and 

future scheduled tests. We welcome 

public comment on whether we should 

adopt separate certification criteria for 

these data elements. For certain other 

data elements in § 170.314(e)(2), we 

propose to require that the capability to 

provide the information be 

demonstrated in accordance with the 

specified vocabulary standard. These 

vocabulary standards have been 

previously adopted or are proposed for 

adoption in this proposed rule, 

consistent with the recommendations of 

the HITSC. We propose to adopt this 

revised certification criterion for the 

2014 Edition EHR certification criteria 

at § 170.314(e)(2). 

c. Inpatient Setting 

We propose to adopt the following 

revised certification criteria for the 

inpatient setting. 

• Reportable laboratory tests and 

values/results 

MU Objective 

Capability to submit electronic reportable 

laboratory results to public health agencies, except where prohibited, and in accordance with applicable law and practice. 

2014 Edition EHR Certification Criteria 

§ 170.314(f)(5) (Inpatient setting only—reportable laboratory tests and values/results) 

§ 170.314(f)(6) (Inpatient setting only— 

transmission of reportable laboratory tests 

and values/results) 

Standards and Implementation Specifications 

§ 170.205(g) (HL7 2.5.1 and HL7 Version 

2.5.1 Implementation Guide: Electronic 

Laboratory Reporting to Public Health, 

Release 1 (US Realm) with errata); 

§ 170.207(a)(3) (SNOMED CT® International Release January 2012); and 

§ 170.207(g) (LOINC version 2.38) 

Similar to the immunization and 

syndromic surveillance certification 

criteria above, the HITSC recommended 

that we consider splitting the 

‘‘reportable laboratory results’’ 

certification criterion into two separate 

certification criteria. We have followed 

this recommendation, and for the same 

reasons expressed above, we have made 

similar wording changes to these 

proposed certification criteria. Also, as 

noted under the proposed immunization 

and syndromic surveillance certification 

criteria, we are discussing these two 

proposed laboratory tests and values/ 

results certification criteria together for 

simplicity and to prevent confusion, but 

we do not consider the certification 

criterion we propose to focus on data 

capture to be a revised certification 

criterion. Rather, we believe that the 

certification criterion proposed at 

§ 170.314(f)(5) constitutes an unchanged 

certification criterion because all the 

capabilities included in the criterion are 

the same as the capabilities included in 

the corresponding 2011 Edition EHR 

certification criterion (§ 170.306(g)). 

The HITSC recommended that we 

maintain the use of only the HL7 2.5.1 

standard and that we adopt the most 

current version of LOINC as the 

vocabulary standard. We agree and 

propose to adopt LOINC version 2.38 as 

the vocabulary standard as it is the most 

recent version. Based on our 

consultation with the Centers for 

Disease Control and Prevention, we also 

propose to adopt HL7 Version 2.5.1 

Implementation Guide: Electronic 

Laboratory Reporting to Public Health, 

Release 1 (US Realm) with errata and 

SNOMED CT® International Release 

January 2012 version. This version of 

the implementation guide 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. The 

International Release January 2012 

version of SNOMED CT® is the most 

recent version and SNOMED CT® is 

required by the implementation guide, 

as is LOINC. We propose to adopt the 

revised certification criteria for the 2014 

Edition EHR certification criteria at 

§ 170.314(f)(5) and (6). We propose to 

adopt the HL7 2.5.1 standard with the 

revised implementation guide at 

§ 170.205(g). We propose to adopt the 

version of SNOMED CT® at 

§ 170.207(a)(3) and LOINC version 2.38 

standard at § 170.207(g). 

6. Unchanged Certification Criteria 

In our prior rulemakings, we did not 

expressly describe what we considered 

to be ‘‘unchanged’’ certification criteria. 

Based on our experience with this 

rulemaking, we take this opportunity to 

describe the certification criteria that we 

would consider unchanged. We would 

consider the following factors in 

determining whether a certification 

criterion is 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 redesignated as ‘‘optional,’’ for the same 

setting for which it was previously 

adopted certification criterion. 

For clarity, we explain 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 proposed for 

adoption at § 170.314(d)(1) meets this 

description. Additionally, 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 proposed for 

adoption at § 170.314(d)(8) meets this 

description. As discussed in the 

description of revised certification 

criteria, 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13858 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

if it were subsequently adopted for both 

settings. 

We identify some of the proposed 

unchanged certification criteria 

included in the 2014 Edition EHR 

certification criteria below and have 

also identified unchanged certification 

criteria previously in the preamble. As 

noted, the capabilities included in the 

certification criteria below are the same 

capabilities that were adopted in 2011 

Edition EHR certification criteria. We 

propose to add all of these unchanged 

certification criteria to the 2014 Edition 

EHR certification criteria at § 170.314. 

a. Refinements to Unchanged 

Certification Criteria 

We propose to refine the following 

certification criteria as discussed below. 

• Computerized provider order entry 

MU Objective 

Use computerized provider order entry 

(CPOE) for medication, laboratory, and 

radiology orders directly entered by any 

licensed healthcare professional who can 

enter orders into the medical record per 

state, local and professional guidelines to 

create the first record of the order. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(1) (Computerized provider 

order entry) 

We have merged the separate 

ambulatory and inpatient CPOE 

certification criteria in the 2011 Edition 

EHR certification criteria into one 

criterion because they are identical. 

Consistent with our discussion in the 

preamble section titled ‘‘Explanation 

and Revision of Terms Used in 

Certification Criteria,’’ we have also 

replaced the terms ‘‘modify’’ and 

‘‘retrieve’’ with ‘‘change’’ and ‘‘access,’’ 

respectively. We have also removed the 

term ‘‘store’’ from the criterion because 

it is redundant with our interpretation 

of the term ‘‘record.’’ Finally, we moved 

the phrase ‘‘at a minimum’’ in the 

sentence to eliminate any possible 

ambiguity as to what the phrase 

modifies. As the proposed certification 

criterion is now written, we believe it is 

clear that the phrase modifies the order 

types and not the terms ‘‘record,’’ 

‘‘change,’’ and ‘‘access.’’ 

• Vital signs, body mass index, and 

growth charts 

MU Objective 

Record and chart changes in the following 

vital signs: height/length and weight (no 

age limit); blood pressure (ages 3 and 

over); calculate and display body mass 

index (BMI); and plot and display growth 

charts for patients 0–20 years, including 

BMI. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(4) (Vital signs, body mass 

index, and growth charts) 

Consistent with our discussion in the 

preamble section titled ‘‘Explanation 

and Revision of Terms Used in 

Certification Criteria,’’ we have replaced 

the terms ‘‘modify’’ and ‘‘retrieve’’ with 

‘‘change’’ and ‘‘access,’’ respectively. 

We have also added the alternative term 

‘‘length’’ to go with ‘‘height’’ as it is the 

clinically appropriate term for newborns 

and clarified the intent of the ‘‘vital 

signs’’ capability. The only other 

refinements that we propose are for the 

plot and display growth charts 

capability. First, we propose that this 

capability be designated ‘‘optional’’ 

within this certification criterion 

because even though this certification 

criterion is proposed to be part of a Base 

EHR that every EP, EH, and CAH would 

need to have in order to satisfy the 

proposed revised definition of CEHRT, 

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 have designated it 

as ‘‘optional’’ for certification. In 

addition, we propose to remove the age 

range reference (2–20 years old) from 

this capability. This is 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 the patient’s age. 

• Smoking status 

MU Objective 

Record smoking status for patients 13 years 

old or older. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(11) (Smoking status) 

Standard 

§ 170.207(l) (smoking status types) 

As part of the 2011 Edition EHR 

certification criteria, the smoking status 

certification criterion is codified at 

§ 170.302(g), specifying a list of six 

smoking status types that EHR 

technology must be capable of 

recording, modifying, and retrieving. 

Consistent with our discussion in the 

preamble section titled ‘‘Explanation 

and Revision of Terms Used in 

Certification Criteria,’’ we have replaced 

the terms ‘‘modify’’ and ‘‘retrieve’’ with 

‘‘change’’ and ‘‘access,’’ respectively. 

We also propose to specify the six 

smoking status types included in the 

2011 Edition EHR certification criterion 

as a standard at § 170.207(l). This 

refinement will provide additional 

clarity for the certification criterion and 

consistency with the structure of similar 

certification criteria. 

• Patient reminders 

MU Objective 

Use clinically relevant information to identify 

patients who should receive reminders for 

preventive/follow-up care. 

2014 Edition EHR Certification Criterion 

§ 170.314(a)(15) (Ambulatory setting only— 

patient reminders) 

We clarify and emphasize 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 note 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. We also anticipate that other 

modes of communication would be 

available and may be preferred by 

patients for sending patient reminders, 

such as regular mail. 

• Authentication, access control, and 

authorization 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(1) (Authentication, access control, and authorization) 

As part of the 2011 Edition EHR 

certification criteria, the ‘‘access 

control’’ certification criterion is 

codified at § 170.302(o) and the 

‘‘authentication’’ certification criterion 

is codified at § 170.302(t). Based on 

consultations with NIST, the similarity 

of the two test procedures that were 

developed for these certification criteria, 

and that these capabilities go hand-inhand, we have determined that it would 

be best to merge the two certification 

criteria. We believe this would allow for 

more efficient testing and is consistent 

with EHR technology development. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13859 

Given this proposal, we have adopted in 

part the recommendations of the HITSC, 

which are reflected in the proposed 

certification criterion. We have 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 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 at a EP, EH, or CAH 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. We also 

acknowledge, as recommended by the 

HITSC, that example standards and 

implementation specifications which 

could be followed in designing EHR 

technology to meet this certification 

criterion could include, but are not 

limited to: NIST Special Publication 

800–63, Level 2 (single-factor 

authentication) and ASTM, E1986–09 

(Information Access Privileges to Health 

Information). 

• Automatic log-off 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(5) (Automatic log-off) 

We are not revising or refining this 

certification criterion as part of the 

proposed 2014 Edition EHR certification 

criteria, but are clarifying that to 

terminate a session should not be 

confused with locking a session, where 

access to an active session is permitted 

after re-authentication. EHR technology 

must have the capability to terminate 

the session, including terminating the 

network connection. 

• Emergency access 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(6) (Emergency access) 

We are refining the 2011 Edition EHR 

certification criterion for emergency 

access codified at § 170.302(p) for the 

2014 Edition EHR certification criteria 

by removing the parenthetical ‘‘who are 

authorized for emergency situations’’ 

from the certification criterion and 

including the phrase ‘‘identified set of 

users’’ to more clearly convey this 

certification criterion’s intent and to 

consistently use this phrase through 

every certification criterion where we 

intend for the same capability to be 

available. The purpose of this criterion 

is to provide certain users (‘‘identified 

set of users’’) with the ability to override 

normal access controls in the case of an 

emergency. The refinement to the 

criterion coupled with our explanation 

should provide sufficient clarity for 

testing and certifying to this 

certification criterion. 

• Integrity 

MU Objective 

Protect electronic health information created 

or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 

2014 Edition EHR Certification Criterion 

§ 170.314(d)(8) (Integrity) 

Standard 

§ 170.210(c) (Verification that electronic 

health information has not been altered) 

The certification criterion at 

§ 170.314(d)(8) is consistent with the 

recommendation and recommended 

certification criterion by the HITSC for 

the 2014 Edition EHR certification 

criteria. The capability to detect changes 

to an audit log has been removed from 

this proposed certification criterion and 

added to the proposed certification 

criterion for ‘‘auditable events and 

tamper resistance’’ at § 170.314(d)(2). 

The adopted certification criterion 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.’’ After 

consultation with NIST, we understand 

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 understand 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. 

Thus, we request public comment on 

whether we should leave the standard 

as it currently reads or replace SHA–1 

with SHA–2. 

b. Unchanged Certification Criteria 

Without Refinements 

The following table (Table 2) 

identifies the proposed unchanged 2014 

Edition EHR certification criteria and 

the corresponding 2011 Edition EHR 

certification criteria that include the 

same capabilities that are in the 

proposed unchanged 2014 Edition EHR 

certification criteria. We propose to 

adopt these certification criteria as part 

of the 2014 Edition EHR certification 

criteria without any substantial 

refinements, except, consistent with our 

discussion in the preamble section titled 

‘‘Explanation and Revision of Terms 

Used in Certification Criteria,’’ we have, 

where appropriate, replaced the terms 

‘‘generate,’’ ‘‘modify,’’ and ‘‘retrieve’’ 

with ‘‘create,’’ ‘‘change,’’ and ‘‘access,’’ 

respectively. Table 2 also identifies the 

corresponding paragraphs of § 170.314 

where the certification criteria would be 

added and the proposed titles of those 

paragraphs/certification criteria. 

TABLE 2—UNCHANGED CERTIFICATION CRITERIA WITHOUT REFINEMENTS

2014 Edition 2011 Edition 

Regulation section Title of regulation paragraph Regulation section Title of regulation paragraph 

170.314(a)(10) ........... Drug-formulary checks ..................................... 170.302(b) ................. Drug-formulary checks. 

170.314(a)(6) ............. Medication list ................................................... 170.302(d) ................. Maintain active medication list. 

170.314(a)(7) ............. Medication allergy list ....................................... 170.302(e) ................. Maintain active medication allergy list. 

170.314(a)(14) ........... Patient lists ....................................................... 170.302(i) .................. Generate patient lists. 

170.314(d)(9) ............. Accounting of disclosures ................................ 170.302(w) ................ Accounting of disclosures. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13860 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

TABLE 2—UNCHANGED CERTIFICATION CRITERIA WITHOUT REFINEMENTS—Continued 

2014 Edition 2011 Edition 

Regulation section Title of regulation paragraph Regulation section Title of regulation paragraph 

170.314(a)(18) ........... Advance directives ........................................... 170.306(h) ................. Advance directives. 

7. Gap Certification 

In the Permanent Certification 

Program final rule (76 FR 1307), we 

explained the concept of ‘‘gap 

certification’’ and defined it at § 170.502 

as ‘‘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 that gap 

certification will focus on the difference 

between certification criteria that are 

adopted through rulemaking at different 

points in time. We discussed in section 

III.A of this preamble the factors we 

would consider in determining whether 

a proposed 2014 Edition EHR 

certification criterion is ‘‘new’’ or 

‘‘revised.’’ Examples of new certification 

criteria are the ‘‘secure messaging’’ 

certification criterion we propose for 

adoption at § 170.314(e)(3) and the 

‘‘electronic medication administration 

record’’ certification criterion we 

propose for adoption at § 170.314(a)(17). 

An example of a revised certification 

criterion is the ‘‘CDS’’ certification 

criterion we propose for adoption at 

§ 170.314(a)(8). This certification 

criterion is ‘‘revised’’ because it would 

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 proposed for 

adoption 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. 

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. However, for 

the certification criteria that we identify 

as unchanged, test results that were 

used previously to certify a Complete 

EHR or EHR Module to the 2011 Edition 

EHR certification criteria identified in 

Table 3 below could be used to certify 

the Complete EHR or EHR Module to 

the corresponding 2014 Edition EHR 

certification criteria identified in the 

table. To illustrate, for gap certification, 

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 we propose to add 

to the 2014 Edition EHR certification 

criteria 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 we have proposed to 

adopt a revised certification criterion for 

‘‘drug-drug, drug-allergy interaction 

checks’’ as part of the 2014 Edition of 

EHR certification criteria at 

§ 170.314(a)(2). We note, as identified in 

Table 3, that for the proposed 

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 we propose to 

require that such EHR technology meet 

new standards and implementation 

specifications, while the capabilities 

required for the inpatient setting are 

unchanged. 

TABLE 3—GAP CERTIFICATION: CROSSWALK OF UNCHANGED 2014 EDITION EHR CERTIFICATION CRITERIA TO THE

CORRESPONDING 2011 EDITION EHR CERTIFICATION CRITERIA

2014 Edition 2011 Edition 

Regulation section Title of regulation paragraph Regulation section Title of regulation paragraph 

170.314(a)(10) ........... Drug-formulary checks ..................................... 170.302(b) ................. Drug-formulary checks. 

170.314(a)(6) ............. Medication list ................................................... 170.302(d) ................. Maintain active medication list. 

170.314(a)(7) ............. Medication allergy list ....................................... 170.302(e) ................. Maintain active medication allergy list. 

170.314(a)(4) ............. Vital signs, body mass index, and growth 

charts.

170.302(f) .................. Vital signs. 

170.314(a)(11) ........... Smoking status ................................................. 170.302(g) ................. Smoking status. 

170.314(b)(5) ............. Incorporate laboratory tests and values/results 

(inpatient setting only) ......................................

170.302(h) ................. Incorporate laboratory test results. 

170.314(a)(14) ........... Patient lists ....................................................... 170.302(i) .................. Generate patient lists. 

170.314(f)(1) .............. Immunization information ................................. 170.302(k) ................. Submission to immunization registries. 

170.314(f)(3) .............. Public health surveillance ................................. 170.302(l) .................. Public health surveillance. 

170.314(d)(1) ............. Authentication, access control, and authorization.170.302(o) ................. Access control. 

170.314(d)(6) ............. Emergency access ........................................... 170.302(p) ................. Emergency access. 

170.314(d)(5) ............. Automatic log-off .............................................. 170.302(q) ................. Automatic log-off. 

170.314(d)(8) ............. Integrity ............................................................. 170.302(s) ................. Integrity. 

170.314(d)(1) ............. Authentication, access control, and authorization.170.302(t) .................. Authentication. 

170.314(d)(9) ............. Accounting of disclosures ................................ 170.302(w) ................ Accounting of disclosures. 

170.314(a)(15) ........... Patient reminders ............................................. 170.304(d) ................. Patient reminders. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13861 

42http://healthit.hhs.gov/portal/server.pt?open=

512&mode=2&objID=3163&PageID=20779. 

TABLE 3—GAP CERTIFICATION: CROSSWALK OF UNCHANGED 2014 EDITION EHR CERTIFICATION CRITERIA TO THE

CORRESPONDING 2011 EDITION EHR CERTIFICATION CRITERIA—Continued 

2014 Edition 2011 Edition 

Regulation section Title of regulation paragraph Regulation section Title of regulation paragraph 

170.314(a)(1) ............. CPOE ............................................................... 170. 304(a) ................

170. 306(a) ................

CPOE. 

170.314(f)(5) .............. Reportable laboratory tests and values/results 170.306(g) ................. Reportable lab results. 

170.314(a)(18) ........... Advance directives ........................................... 170.306(h) ................. Advance directives. 

As we have previously stated in our 

rules (75 FR 11351, 76 FR 1308), we 

believe gap certification is a less costly 

and more efficient certification option 

for EHR technology developers to get 

their EHR technologies certified without 

the time and costs associated with 

retesting to unchanged certification 

criteria. As we established in the 

permanent certification program final 

rule (76 FR 1308), however, gap 

certification will only be available 

under the permanent certification 

program, which we are proposing to 

rename the ‘‘ONC HIT Certification 

Program.’’ We have extended the sunset 

date of the temporary certification 

program (and delayed the start of the 

ONC HIT Certification Program), which 

was originally anticipated to be 

December 31, 2011. The sunset date will 

now coincide with the effective date of 

the final rule that will result from this 

proposed rule (76 FR 68192). 

B. Redefining Certified EHR Technology 

and Related Terms 

1. Proposed Revisions to the Definition 

of Certified EHR Technology 

Certified EHR Technology is defined 

in section 3000(1) of the PHSA as a 

‘‘qualified electronic health record that 

is certified pursuant to section 

3001(c)(5) as meeting standards adopted 

under section 3004 that are applicable 

to the type of record involved (as 

determined by the Secretary, such as an 

ambulatory electronic health record for 

office-based physicians or an inpatient 

hospital electronic health record for 

hospitals).’’ In the S&CC July 2010 final 

rule (75 FR 44590), we further defined 

Certified EHR Technology (CEHRT) at 

§ 170.102 in relation to the applicable 

setting-specific certification criteria 

(ambulatory or inpatient) adopted by the 

Secretary to mean: 

1. A Complete EHR that 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; or 

2. A combination of EHR Modules in 

which each constituent EHR Module of 

the combination 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, and the resultant 

combination also meets the 

requirements included in the definition 

of a Qualified EHR. 

Under the current definition, EPs, 

EHs, and CAHs must have Certified EHR 

Technology that has been tested and 

certified to all applicable certification 

criteria adopted for the setting 

(ambulatory or inpatient) for which it 

was designed. We refer readers to 

frequently asked question (FAQ) 9–10– 

017–2 for further explanation.42 Since 

the publication of the S&CC July 2010 

Final Rule, ONC and CMS have received 

feedback on the definition of CEHRT 

from numerous stakeholders, including 

EPs, EHs, CAHs, EHR technology 

developers, and multiple associations 

representing these and other 

stakeholders. Overall, a majority of 

stakeholders felt that we should change 

our CEHRT policy to provide EPs, EHs, 

and CAHs the flexibility to have or 

possess only the CEHRT they will use 

to demonstrate MU. This view was 

supported by the HITSC in their 

November 16, 2011 recommendation 

(transmitted to ONC on January 17, 

2012) that we consider requiring EPs, 

EHs, and CAHs to possess EHR 

technology that has been certified only 

to the certification criteria that include 

capabilities they will use to attempt to 

achieve MU. Such a change would mean 

that the definition of CEHRT would be 

largely determined or driven by how an 

EP, EH, or CAH chooses to accomplish 

MU rather than requiring certification to 

all certification criteria adopted for an 

applicable setting (ambulatory or 

inpatient). 

We have considered all of the 

feedback we have received, particularly 

the recommendation of the HITSC, and 

are proposing a revised definition of 

CEHRT that would provide significantly 

more flexibility for EPs, EHs, and CAHs 

than exists under the current definition. 

We are convinced by stakeholder 

feedback and our own independent factfinding that when combined with the 

complexity of the health care delivery 

environment, the current CEHRT 

definition has, in some cases, 

introduced challenges for certain EPs, 

EHs, and CAHs by requiring them to 

have EHR technology they would not 

necessarily choose to use to demonstrate 

MU under the EHR Incentive Programs. 

For example, under CMS regulations, an 

EP who has no office visits during the 

EHR reporting period may qualify for an 

exclusion for the MU objective and 

associated measure requiring clinical 

summaries to be provided to patients for 

each office visit, but under our current 

definition of CEHRT, the EP must still 

have EHR technology that supports this 

capability. 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 have decided to 

propose a revised definition of CEHRT 

that we believe would more closely 

align with the desired flexibility 

stakeholders have requested while 

reducing the potential burden 

associated with acquiring EHR 

technology. We propose to revise the 

definition of CEHRT at § 170.102 to 

read: 

Certified EHR technology means: 

1. For any Federal fiscal year (FY) or 

calendar year (CY) up to and including 

2013: 

i. A Complete EHR that 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; or 

ii. A combination of EHR Modules in 

which each constituent EHR Module of 

the combination has been tested and 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13862 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

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, and the resultant 

combination also meets the 

requirements included in the definition 

of a Qualified EHR. 

2. For FY and CY 2014 and 

subsequent years, the following: EHR 

technology certified under the ONC HIT 

Certification Program to the 2014 

Edition EHR certification criteria that 

has: 

i. The capabilities required to meet 

the definition of a Base EHR; and 

ii. All other capabilities that are 

necessary to meet the objectives and 

associated measures under 42 CFR 495.6 

and successfully report the clinical 

quality measures selected by CMS in the 

form and manner specified by CMS (or 

the States, as applicable) for the stage of 

meaningful use that an eligible 

professional, eligible hospital, or critical 

access hospital seeks to achieve. 

As noted in the ‘‘Executive Summary’’ 

(section I.A) of this preamble, FY 

applies to EHs and CAHs and CY 

applies to EPs. For the first part of the 

revised definition of CEHRT that would 

apply for the FYs/CYs up to and 

including 2013, we note two specific 

changes. The first is 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. This clarification is necessary 

because if the proposed 2014 Edition 

EHR certification criteria are 

subsequently adopted in a 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 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 

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 a cross-walk between 2011 Edition 

EHR certification criteria and what we 

would consider equivalent proposed 

2014 Edition EHR certification criteria, 

see Table 4 below. We believe this 

revision is necessary and that our 

proposal provides 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. We note, however, 

that with respect to CQMs, 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 has not proposed to 

change the set of CQMs on which EPs, 

EHs, and CAHs would need to report 

until FY/CY 2014. Therefore, 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 encourage 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. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13863 

BILLING CODE 4150–45–C 

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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3EP07MR12.000</GPH>
13864 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

for EHR technology by requiring all 

CEHRT to have, at a minimum, the 

capabilities of a Base EHR. 

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 believe it is important to briefly 

remind stakeholders 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. 

Two types of EHR technology, 

Complete EHRs and EHR Modules, can 

be certified under the ‘‘ONC HIT 

Certification Program,’’ which is the 

new name we are proposing for the 

permanent certification program (see 

section IV.A below). Under the revised 

definition of CEHRT that we are 

proposing 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. 

Consistent with stakeholder feedback, 

an EP, EH, or CAH would generally not 

need to have or possess EHR technology 

in the following two scenarios in order 

to satisfy the proposed revised 

definition of CEHRT for FY/CY 2014 

and subsequent years. One scenario 

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 will be responsible for ensuring 

that they have the necessary EHR 

technology to meet the definition of a 

Base EHR 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. 

We emphasize that under the 

proposed revised definition of CEHRT 

for FY/CY 2014 and subsequent years, 

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 definition of a Base EHR as 

defined below. 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 a Base EHR. 

We have consulted with CMS and 

have determined that it would be least 

confusing and burdensome for EPs, EHs, 

CAHs, and EHR technology developers 

if this revised definition would apply 

beginning with the EHR reporting 

periods that will occur in FY/CY 2014. 

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 definition of a Base EHR; 

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 request public comment on 

alternative approaches we should 

consider 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. 

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 definition of a Base 

EHR). Table 5 is intended to provide a 

general overview of the proposed 

revised definition of CEHRT in relation 

to the stages of MU and the EHR 

reporting periods in FY/CY 2011 

through 2014 (including the extension 

of Stage 1 in 2013 as proposed by CMS). 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13865 

TABLE 5—PROPOSED REVISED DEFINITION OF CEHRT 

EHR reporting periods 

FY/CY 2011 FY/CY 2012 FY/CY 2013 FY/CY2014 

MU Stage 1 MU Stage 1 MU Stage 1 MU Stage 1 or MU Stage 2 

All EPs, EHs, and CAHs must have EHR technology that has been certified to all 

applicable 2011 Edition EHR certification criteria or equivalent 2014 Edition 

EHR certification criteria adopted by the Secretary. 

All EPs, EHs, and CAHs must have EHR technology (including a Base EHR) that has been certified to the 2014 Edition EHR certification criteria that would support the objectives and measures, and their ability to successfully report 

the CQMs, for the MU stage that they seek to achieve. 

2. Base EHR 

Section 3000(1) of the PSHA defines 

Certified EHR Technology to include a 

Qualified EHR. Section 3000(13), in 

turn, defines a ‘‘qualified electronic 

health record’’ or Qualified EHR as an 

electronic record of health-related 

information on an individual that: 

1. Includes patient demographic and 

clinical health information, such as 

medical history and problem lists; and 

2. Has the capacity: 

i. To provide clinical decision 

support; 

ii. To support physician order entry; 

iii. To capture and query information 

relevant to health care quality; and 

iv. To exchange electronic health 

information with, and integrate such 

information from other sources. 

This definition of Qualified EHR is 

codified at 45 CFR 170.102 and is part 

of the current definition of CEHRT. We 

now propose to add the term ‘‘Base 

EHR’’ to § 170.102. This term is 

essentially a substitution for the term 

‘‘Qualified EHR’’ in the revised 

definition of CEHRT that would apply 

in FY/CY 2014 and subsequent years. A 

Base EHR would have all of the 

capabilities specified in the statutory 

definition of a Qualified EHR (that is, in 

section 3000(13) of the PHSA) and 

additional capabilities as described 

below. Hereafter, we intend to use the 

term ‘‘Qualified EHR’’ only as necessary 

and to refer to the statutory definition, 

unless otherwise indicated. We believe 

that the term ‘‘Base EHR’’ is more 

intuitive and conveys a plain language 

meaning. Moreover, the term ‘‘Qualified 

EHR’’ does not inherently convey the 

kinds of capabilities it includes. The 

term ‘‘Base EHR,’’ though, conveys that 

the EHR technology possesses 

capabilities that are fundamental and 

should be a part of any CEHRT that an 

EP, EH, or CAH must have to 

demonstrate MU. We also note that the 

terms ‘‘qualified EHR’’ and ‘‘qualified 

EHR products’’ have been used by CMS 

in other programs and with a different 

meaning. Therefore, we believe that the 

term ‘‘Base EHR’’ will be more easily 

understood and readily accepted by 

stakeholders. 

We propose to define a Base EHR as 

an electronic record of health-related 

information on an individual that: 

1. Includes patient demographic and 

clinical health information, such as 

medical history and problem lists; 

2. Has the capacity: 

i. To provide clinical decision 

support; 

ii. To support physician order entry; 

iii. To capture and query information 

relevant to health care quality; 

iv. To exchange electronic health 

information with, and integrate such 

information from other sources; 

v. To protect the confidentiality, 

integrity, and availability of health 

information stored and exchanged; and 

3. Meets the certification criteria 

adopted by the Secretary at: 

§ 170.314(a)(1) through (8); (b)(1) and 

(2); (c)(1) and (2); (d)(1) through (8); and 

(e)(1). 

We previously adopted, without 

modification, the statutory definition of 

Qualified EHR in regulation (§ 170.102). 

This was due to our requirement that 

the definition of CEHRT could only be 

met if the EHR technology an EP, EH, 

or CAH had in its possession was 

certified to all of the general 

certification criteria and all applicable 

ambulatory or inpatient setting specific 

certification criteria. This requirement 

ensured that EPs’, EHs’, and CAHs’ 

CEHRT included capabilities related to 

privacy and security even though the 

statutory definition of Qualified EHR 

did not include a requirement for those 

capabilities. Based on our proposed 

revised definition of CEHRT, we believe 

it is necessary now to expand the Base 

EHR definition to include a capacity 

that addresses privacy and security. 

In Table 6, we explain the 

certification criteria specified in 

paragraph (3) of the proposed Base EHR 

definition. As discussed in section 

III.A.1 of this preamble, some 

capabilities within the proposed 2014 

Edition EHR certification criteria may 

only apply to the ambulatory or 

inpatient setting. For example, to be 

certified to the proposed 

‘‘demographics’’ certification criterion 

(§ 170.314(a)(3)), EHR technology 

designed for either an ambulatory or 

inpatient setting would need to enable 

a user to electronically record, change, 

and access patient demographic data 

including preferred language, gender, 

race, ethnicity, and date of birth 

(§ 170.314(a)(3)(i)), while EHR 

technology designed specifically for an 

inpatient setting would also need to 

enable a user to electronically record, 

change, and access the ‘‘date and 

preliminary cause of death in the event 

of mortality in accordance with the 

standard specified in § 170.207(k)’’ 

(§ 170.314(a)(3)(ii)). 

In relation to CQMs, we propose that 

a Base EHR include EHR technology 

certified to the certification criteria 

proposed at § 170.314(c)(1) and (2). 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 anticipate that EHR 

technology developers would 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. Therefore, 

we expect that EHR technology certified 

to § 170.314(c)(2) would be capable of 

incorporating all necessary data 

elements and calculating more than one 

CQM. This approach may, however, 

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 are interested in 

comments on whether we should 

require certification to a set number of 

CQMs as part of certification to 

§ 170.314(c)(2). For example, we could 

require EHR technology designed for the 

ambulatory setting and that would 

constitute an EP’s Base EHR 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13866 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

rule. And for EHR technology designed 

for the inpatient setting and that would 

constitute an EH’s or CAH’s Base EHR, 

we could require that it 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). However, we see 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 to their 

customers, but nonetheless are 

necessary for the EHR technology to be 

certified. We also request 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 capacity to protect the 

confidentiality, integrity, and 

availability of health information stored 

and exchanged, we are proposing that 

the certification criteria should apply 

equally to both the ambulatory and 

inpatient settings. We are, however, 

interested in public comment on 

whether there should be a distinction 

between the ambulatory and inpatient 

settings for the certification of EHR 

technology to the privacy and security 

certification criteria, including for 

which certification criteria there could 

be a distinction and the basis for that 

distinction. 

We would like to make clear that the 

definition of Base EHR is a requirement 

that must be satisfied to meet the 

definition of CEHRT. The proposed Base 

EHR definition is not meant to convey 

our expectation that EHR technology 

must be separately certified as a Base 

EHR. Rather, similar to the proposed 

revised definition of CEHRT, the 

definition of a Base EHR can be satisfied 

through a certified Complete EHR, a 

single EHR Module certified to all of the 

certification criteria specified in Table 6 

below, or a combination of certified 

EHR Modules where the resultant 

combination has been collectively 

certified to all of the certification 

criteria specified in Table 6 below. In 

section IV.D of this preamble, we 

discuss proposals and options for the 

representation and marketing of EHR 

technology that meets the definition of 

a Base EHR. 

3. Complete EHR 

We are proposing to slightly revise the 

Complete EHR definition for clarity. A 

Complete EHR is currently defined as 

‘‘EHR technology that has been 

developed to meet, at a minimum, all 

applicable certification criteria adopted 

by the Secretary.’’ In the S&CC January 

2010 interim final rule, we clarified, 

based on our understanding of Congress’ 

intent, that the term ‘‘applicable’’ in the 

definition of Certified EHR Technology 


tkelley on DSK3SPTVN1PROD with PROPOSALS3EP07MR12.001</GPH>
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13867 

43http://healthit.hhs.gov/portal/server.pt/

community/onc_regulations_faqs/3163/faq_5/ 

20767. 

meant the adopted certification criteria 

applicable to either an ambulatory or to 

an inpatient setting. Therefore, to be 

certified to the 2011 Edition EHR 

certification criteria adopted by the 

Secretary, 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. 

We intend to maintain the concept of 

a Complete EHR and permit EHR 

technology developers to seek 

certification of their EHR technology as 

Complete EHRs, but propose to revise 

the definition for clarity. We propose 

that ‘‘Complete EHR’’ 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.’’ We believe 

this revised definition is consistent with 

the previous definition of Complete 

EHR and clarifies that a Complete EHR 

can be setting-specific and must meet all 

adopted mandatory certification criteria 

for a setting. Our proposed addition of 

paragraph (d) to § 170.300 clarifies 

which certification criteria in proposed 

§ 170.314 have general applicability 

(apply to both ambulatory and inpatient 

settings) or apply only to an inpatient 

setting or an ambulatory setting. This 

proposed revised definition, if adopted, 

would be effective upon the final rule’s 

effective date. 

While a certified Complete EHR 

(under the proposed revised definition 

of CEHRT) will likely have more 

capabilities than are necessary for any 

single EP, EH, or CAH to achieve MU, 

we believe the ‘‘Complete EHR’’ 

designation still has significant market 

value in that: It provides purchasing 

clarity and assurance to EPs, EHs, and 

CAHs that the EHR technology they 

have meets the regulatory definition of 

CEHRT; it can support EPs, EHs, and 

CAHs if they attempt to achieve all MU 

objectives and measures; and it ensures 

all the capabilities the Complete EHR 

includes have been tested and certified 

to work properly together. We believe 

that the choice to adopt or upgrade a 

Complete EHR may be more appealing 

(in some cases for EHs and CAHs and 

more so for EPs given that there are over 

668 certified ambulatory Complete 

EHRs (which includes newer versions of 

the same Complete EHR)), than having 

to assume the responsibility to 

determine which certified EHR Modules 

include the capabilities needed to 

support the achievement of MU or 

having the responsibility to ensure that 

the certified EHR Modules work 

properly together. 

4. Certifications Issued for Complete 

EHRs and EHR Modules 

Following the S&CC July 2010 final 

rule’s publication, some stakeholders 

contended that the linkage between a 

certification issued for an EHR 

technology and the possession of all of 

that EHR technology’s capabilities 

should be dropped. In other words, they 

argued that an EHR technology 

developer should be able to sell any 

component of a certified Complete EHR 

or EHR Module as certified and, equally, 

that an EP, EH, or CAH should be able 

to buy something less than 100% of a 

certified Complete EHR or EHR Module 

and still be able to say it is using 

‘‘certified’’ EHR technology. In response 

to these stakeholder contentions, we 

issued FAQ 9–10–005–1.43 This FAQ 

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. 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. 

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. In essence, 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. 

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, in the event that 

combined and/or workflow-based test 

procedures are developed, 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. 

As we have stated in prior 

rulemakings, Congress made clear that 

the act of seeking certification must be 

voluntary. We therefore 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. Conversely, EPs, 

EHs, and CAHs should take note that in 

some cases it may not be practicable for 

an EHR technology developer to 

separate out one or more components 

for certification without adversely 

affecting the proper functioning of the 

remaining components. 

5. Adaptations of Certified Complete 

EHRs or Certified EHR Modules 

As the hardware on which EHR 

technology can run continues to evolve, 

we expect and encourage EHR 

technology developers to pursue 

innovative ways to facilitate efficient 

workflows and user interactions. In this 

regard, we believe 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 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. For example, 

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, 

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 note 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13868 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

and security vulnerabilities into the 

certified Complete EHR or certified EHR 

Module. 

If an adaptation does not make it 

possible for a user to use the capability 

or capabilities that were required for the 

Complete EHR or EHR Module to be 

certified, then the adaptation could 

jeopardize an EP’s, EH’s, or CAH’s 

ability to meet MU because the user of 

the adaptation would not be 

meaningfully using EHR technology that 

had been certified. Furthermore, 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 nonconformance with those certifications. 

We invite comment on our proposed 

adaptation policy and whether it strikes 

an appropriate balance between 

permitting innovation and providing 

certainty that the EHR technology used 

by an EP, EH, or CAH has satisfied the 

certification criteria adopted by the 

Secretary. 

IV. Provisions of the Proposed Rule 

Affecting the Permanent Certification 

Program for HIT (‘‘ONC HIT 

Certification Program’’) 

A. Program Name Change 

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). 

The permanent certification program 

will replace the temporary certification 

program, which we expect will occur 

upon the effective date of the final rule 

that would follow this proposed rule. At 

that time, there will no longer be a need 

to continue to differentiate between the 

certification programs based on their 

expected duration. Therefore, we 

propose to replace all references in Part 

170 of the Code of Federal Regulations 

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 

potential future activities. 

B. ‘‘Minimum Standards’’ Code Sets 

In § 170.555, we allow 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 in EHR technology. 

This approach permits a Complete EHR 

and/or EHR Module to be certified to a 

newer version of an adopted code set 

without the need for additional 

rulemaking and enables CEHRT to be 

upgraded with a newer version of an 

adopted minimum standard code set 

without adversely affecting its certified 

status. We finalized two methods 

through which the Secretary would 

identify new versions of adopted 

‘‘minimum standards’’ code sets (76 FR 

1294–1295). The first method would 

allow any member of the general public 

to notify the National Coordinator about 

a new version. Under the second 

method, the Secretary would 

proactively identify newly published 

versions. After a new version has been 

identified, a determination would be 

issued as to whether the new version 

constitutes maintenance efforts or minor 

updates to the adopted code set and 

consequently may be permitted for use 

in certification. 

The process we have followed 

involves presenting the identified new 

version of an adopted ‘‘minimum 

standard’’ code set to the HITSC for 

assessment, solicitation of public 

comments on the new version, and 

issuing a recommendation to the 

National Coordinator which would 

identify whether the Secretary’s 

acceptance of the newer version for 

voluntary implementation and 

certification would burden the HIT 

industry, negatively affect 

interoperability, or cause some other 

type of unintended consequence. After 

considering the recommendation of the 

HITSC, the National Coordinator would 

determine whether or not to seek the 

Secretary’s acceptance of the new 

version of the adopted ‘‘minimum 

standard’’ code set. If the Secretary 

approves the National Coordinator’s 

request, we would issue guidance 

indicating that the new version of the 

adopted ‘‘minimum standard’’ code set 

has been accepted by the Secretary. 

Our experience has shown that newer 

versions of the ‘‘minimum standards’’ 

code sets we adopted are issued more 

frequently than this process can 

reasonably accommodate. Additionally, 

based on the ‘‘minimum standard’’ code 

sets we have previously adopted and are 

proposing in this rule, 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. We propose to revise § 170.555 

such that, unless the Secretary prohibits 

the use of a newer version of a 

‘‘minimum standard’’ 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. We believe 

this proposed approach would reduce 

regulatory complexity by providing the 

industry with the flexibility to utilize 

newer versions of adopted ‘‘minimum 

standard’’ code sets. In consideration of 

this proposed new approach we want to 

clarify 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 expect that we would generally 

use the same process for determining 

whether to prohibit the use of a newer 

version of a ‘‘minimum standard’’ code 

set. 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 expect 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 would issue guidance 

indicating that the newer version of the 

adopted ‘‘minimum standard’’ 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 believe, 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 standard’’ code set. 

Instances could arise where the use of 

a newer version of a ‘‘minimum 

standard’’ 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, 

the Secretary may choose to prohibit the 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13869 

use of a newer version of a ‘‘minimum 

standard’’ code set for purposes of 

certification and upgrading certified 

EHR technology without seeking a 

recommendation from the HITSC in 

advance. 

We propose 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.’’ We believe the revisions 

provide additional clarity and 

specificity. 

C. Revisions to EHR Module 

Certification Requirements 

1. Privacy and Security Certification 

Section 170.550(e) states that ‘‘EHR 

Module(s) shall be certified to all 

privacy and security certification 

criteria adopted by the Secretary, unless 

the EHR Module(s) is presented for 

certification in one of the following 

manners: 

1. The EHR Modules are presented for 

certification as a pre-coordinated, 

integrated bundle of EHR Modules, 

which would otherwise meet the 

definition of and constitute a Complete 

EHR, and one or more of the constituent 

EHR Modules is demonstrably 

responsible for providing all of the 

privacy and security capabilities for the 

entire bundle of EHR Modules; or 

2. An EHR Module is presented for 

certification, and the presenter can 

demonstrate and provide 

documentation to the ONC–ACB that a 

privacy and security certification 

criterion is inapplicable or that it would 

be technically infeasible for the EHR 

Module to be certified in accordance 

with such certification criterion.’’ 

We propose not to apply the privacy 

and security certification requirements 

at § 170.550(e) for the certification of 

EHR Modules to the 2014 Edition EHR 

certification criteria. Stakeholder 

feedback, particularly from EHR 

technology developers, has identified 

that this regulatory requirement is 

causing unnecessary burden (both in 

effort and cost). EHR Module developers 

have expressed that they have had to 

redesign their EHR technology in 

atypical ways to accommodate this 

regulatory requirement, which 

sometimes leads to the inclusion of a 

privacy or security feature that would 

not normally be found in a certain type 

of EHR Module. In turn, this has led to 

EPs, EHs, and CAHs purchasing EHR 

Modules that have redundant or 

sometimes conflicting privacy and 

security capabilities. Based on our 

proposal that EPs, EHs, and CAHs must 

have a Base EHR to meet our proposed 

revised definition of CEHRT that would 

apply beginning with FY/CY 2014, we 

believe that we can be responsive to 

stakeholder feedback with our proposal 

not to apply the privacy and security 

certification requirements at 

§ 170.550(e) for the certification of EHR 

Modules, while still requiring an 

equivalent or higher level of privacy and 

security capabilities to be part of 

CEHRT. 

In section III.B of this preamble, we 

propose that a Base EHR include all the 

proposed mandatory privacy and 

security certification criteria (i.e., all 

privacy and security certification 

criteria except the optional ‘‘accounting 

of disclosure’’ certification criterion at 

§ 170.314(d)(9)). This ensures that EPs, 

EHs, and CAHs have the capabilities to 

support the MU objective to protect 

electronic health information created or 

maintained by CEHRT through the 

implementation of appropriate technical 

capabilities. In addition, EPs, EHs, and 

CAHs 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). These factors reduce 

the importance of certifying EHR 

Modules to all of the privacy and 

security certification criteria or 

requiring EHR Module developers to 

demonstrate that privacy and security 

certification criteria are inapplicable to 

or technically infeasible to implement 

for their EHR Modules. Thus, a 

regulatory burden and associated costs 

for EHR Module developers would be 

eliminated, and EPs, EHs, and CAHs 

would not have to purchase EHR 

Modules that have privacy and security 

capabilities that are redundant or 

conflict with the capabilities of the EHR 

technology that would make up their 

Base EHR. 

2. Certification to Certain New 

Certification Criteria 

As discussed in section III.A of this 

preamble, we propose to adopt new 

2014 Edition EHR certification criteria 

that would require the following: 

Electronic recording of the numerator 

for each MU objective with a 

percentage-based measure 

(§ 170.314(g)(1) ‘‘automated numerator 

recording’’); electronic recording of 

activities related to non-percentagebased measures (§ 170.314(g)(3) ‘‘nonpercentage-based measure use report’’); 

and user-centered design processes to be 

applied to EHR technology that includes 

certain capabilities (§ 170.314(g)(4) 

‘‘safety-enhanced design’’). To ensure 

proper certification of EHR Modules to 

these proposed certification criteria, we 

propose to revise § 170.550. 

We propose 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 percentage-based 

measure are certified to proposed 

§ 170.314(g)(1). However, we propose 

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 propose to revise 

§ 170.550 in order to ensure that EHR 

Modules that are presented for 

certification to certification criteria that 

include capabilities for supporting an 

MU objective with a non-percentagebased measure are certified to proposed 

§ 170.314(g)(3). We propose to revise 

§ 170.550 to ensure that EHR Modules 

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 propose to include 

these three revisions at § 170.550(f). 

D. ONC–ACB Reporting Requirements 

In the permanent certification 

program final rule (76 FR 1318–1323), 

we adopted (§ 170.523) principles of 

proper conduct to which ONC–ACBs 

must adhere for their authorization to 

remain in good standing under the 

program. The principle of proper 

conduct at § 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 which includes, 

at a minimum: The Complete EHR or 

EHR Module developer name (if 

applicable); the date certified; the 

product version; the unique certification 

number or other specific product 

identification; the clinical quality 

measures to which a Complete EHR or 

EHR Module has been certified; where 

applicable, any additional software a 

Complete EHR or EHR Module relied 

upon to demonstrate its compliance 

with a certification criterion adopted by 

the Secretary; and where applicable, the 

certification criterion or certification 

criteria to which each EHR Module has 

been certified. 

We propose to require that ONC– 

ACBs include an additional data 

element in the set of data they are 

required to provide regarding the 

Complete EHRs and/or EHR Modules 

they report as certified to ONC under 

§ 170.523(f). Specifically, we propose 

that an ONC–ACB would need to 

provide to ONC a hyperlink for each 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13870 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

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 an ONC– 

ACB reports to ONC regarding a 

Complete EHR or EHR Module it 

certifies, we would make the hyperlink 

available on the CHPL with the 

respective certified Complete EHR or 

certified EHR Module. As with other 

records related to certification, 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, the ONC–ACB would no 

longer need to ensure the functionality 

of the hyperlink, although retention of 

the test results would be required. We 

believe this additional element is 

important to increase transparency in 

the testing and certification processes 

and would serve to make more 

information available to prospective 

purchasers of certified Complete EHRs 

and certified EHR Modules as well as 

other stakeholders. 

E. Continuation and Representation of 

Certified Status 

1. 2011 or 2014 Edition EHR 

Certification Criteria Compliant 

In our certification program final rules 

(76 FR 1302, 75 FR 36189), we indicated 

that we anticipated adopting new and/ 

or revised certification criteria every 

two years to coincide with changes to 

the MU objectives and measures under 

the EHR Incentive Programs. We did 

not, however, set a specific expiration 

date for certifications. Rather, we 

explained that once the Secretary adopts 

new and/or revised certification criteria, 

EHR technology may need to be tested 

and certified again. In other words, the 

previous certifications may no longer 

accurately represent what is required to 

meet the adopted certification criteria. 

Based on this expectation, we 

established in the Permanent 

Certification Program final rule and at 

§ 170.523(k) that ONC–ACBs must 

require as part of certification that EHR 

technology developers include on their 

Web sites and in all marketing 

materials, communications, statements, 

and other assertions, the years (‘‘20[XX]/ 

20[XX]’’) for which a certification issued 

for a Complete EHR or EHR Module 

would be considered compliant. Again, 

anticipating that every two years 

certification criteria would be adopted 

and EHR technology would need to be 

certified to the certification criteria to 

meet the definition of CEHRT, we 

clarified this provision in the Permanent 

Certification Program final rule with 

examples (76 FR 1305). These examples 

indicated that EHR technology certified 

to the adopted certification criteria (i.e., 

the certification criteria adopted at 

§§ 170.302, 170.304, and 170.306) 

would include ‘‘2011/2012’’ compliant 

and that certifications based on 

certification criteria adopted through 

future rulemaking would indicate 

‘‘2013/2014’’ compliant. 

In this proposed rule, we have 

referred to the adopted certification 

criteria collectively as the ‘‘2011 Edition 

EHR certification criteria’’ and the 

certification criteria proposed in this 

rule collectively as the ‘‘2014 Edition 

EHR certification criteria’’ (terms we 

also propose to include as defined terms 

in § 170.102). In line with this 

convention, we propose to revise 

§ 170.523(k) to require the edition of 

certification criteria for which a 

certification issued for a Complete EHR 

or EHR Module would be considered 

compliant instead of the years (i.e., 

‘‘2014 Edition EHR certification criteria 

compliant).’’ This proposed revision 

would apply to all certifications issued 

after the effective date of a final rule. We 

believe this proposal would further 

assist in eliminating confusion about the 

‘‘expiration’’ of certifications, align with 

our proposed revised definition of 

CEHRT, and provide the market with 

greater clarity regarding the capabilities 

of certified Complete EHRs and certified 

EHR Modules. 

For certified EHR technologies that 

are already designated as ‘‘2011/2012’’ 

compliant, we have considered multiple 

options and concluded that the best 

approach is to not require any changes 

to the ‘‘2011/2012’’ designation, such as 

having them re-designated as ‘‘2011 

Edition EHR certification criteria 

compliant.’’ Rather, 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 believe this approach minimizes the 

burden on EHR technology developers. 

We request public comment on our 

approach and any other approach that 

would present the least burden for EHR 

technology developers and the least 

confusion for the market. 

Section 170.523(k)(1)(i) states, in part, 

that ‘‘[A] certification does not represent 

an endorsement by the U.S. Department 

of Health and Human Services or 

guarantee the receipt of incentive 

payments.’’ We propose to revise this 

statement by removing ‘‘* * * 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. Therefore, to prevent confusion 

and to defer to CMS in establishing and 

specifying the parameters of the EHR 

Incentive Programs, we propose this 

revision to the statement. 

2. Updating a Certification 

To ensure that the information 

required by § 170.523(k)(1)(i) remains 

accurate and reflects the correct edition 

of EHR certification criteria, 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 to 

not apply the privacy and security 

certification requirements at 

§ 170.550(e) to EHR Modules certified to 

the proposed 2014 Edition EHR 

certification criteria, we propose to 

revise the definition of ‘‘providing or 

provide an updated certification’’ to 

eliminate the requirement that ONC– 

ACBs would need to verify that any new 

privacy and security certification 

criteria apply when they issue an 

updated certification. However, ONC– 

ACBs would still need to verify whether 

the certification criterion or criteria to 

which the EHR Module(s) was 

previously certified have not been 

revised and that no new certification 

criteria are applicable to the EHR 

Module(s). 

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 believe that 

we can provide the best guidance to 

stakeholders on when ‘‘updating’’ a 

certification would be permitted with 

each rulemaking for an edition of 

certification criteria. For the 2014 

Edition EHR certification criteria, if we 

were to adopt in a final rule all the 

proposed new certification criteria 

discussed above in section IV.C.2 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13871 

44http://www.cchit.org/get_certified/cchitcertified-2011. 45http://www.gpo.gov/fdsys/pkg/FR-2011-05-31/

pdf/2011-13297.pdf. 

(‘‘Certification to Certain New 

Certification Criteria’’) of this preamble, 

then no previously certified EHR 

Modules could be issued updated 

certifications because every EHR 

Module would require certification to, 

at a minimum, the certification criterion 

at § 170.314(g)(1) (automated numerator 

recording) (or § 170.314(g)(2) in lieu of 

being certified to § 170.314(g)(1)) or the 

certification criterion at § 170.314(3) 

(non-percentage-based measure use 

report). Although ONC–ACBs would not 

be able to issue updated certifications to 

the 2014 Edition EHR certification 

criteria, ‘‘updating’’ certifications may 

still be a viable option under certain 

conditions when the Secretary adopts 

another edition of certification criteria 

in the future. 

3. Base EHR Representation 

An EHR technology developer’s 

Complete EHR, single EHR Module or 

combination of EHR Modules could 

constitute a Base EHR by meeting all the 

certification criteria required by the 

definition of Base EHR for the 

ambulatory setting or inpatient setting. 

We believe EPs, EHs, and CAHs would 

benefit from knowing which certified 

EHR technologies on the market 

constitute a Base EHR because they 

would need to have a Base EHR to 

satisfy the proposed revised definition 

of CEHRT beginning with FY/CY 2014. 

We do not believe that it is necessary to 

expressly propose a requirement for 

ONC–ACBs related to the identification 

of EHR technology that meets the 

definition of a Base EHR. To gain a 

competitive advantage in the market, we 

believe EHR technology developers 

would likely identify on their Web sites 

and in marketing materials, 

communications, statements, and other 

assertions whether their certified 

Complete EHR or EHR Module(s) meet 

the definition of a Base EHR (designed 

for either the ambulatory or inpatient 

setting). However, we considered as a 

potential alternative or complementary 

approach to permit ONC–ACBs when 

issuing certifications to Complete EHRs 

and EHR Modules that meet the 

definition of a Base EHR 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 definition of a Base EHR. We 

welcome comments on these and any 

other approaches that we have not 

identified. 

V. Request for Additional Comments 

A. 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, the 

certification criteria proposed for 

adoption in this rule focus 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. 

In the Permanent Certification 

Program final rule (76 FR 1294), we 

discussed the National Coordinator’s 

statutory authority to establish a 

voluntary certification program or 

programs for other types of HIT besides 

EHR technology. However, as explained 

in the Permanent Certification Program 

final rule, 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. 

As we continue to adopt new and 

revised certification criteria to support 

MU, we believe that it is prudent to seek 

public comment on whether we should 

focus our efforts on the certification of 

the HIT used by health care providers 

that are ineligible to receive incentives 

under the EHR Incentive Programs. In 

particular, we are interested in 

commenters’ thoughts 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. For those commenters that 

believe we should consider certification 

criteria for other health care settings, we 

respectfully request that their comments 

specify the certification criteria that 

would be appropriate as well as the 

benefits they believe a regulatory 

approach would provide. Last, we ask 

that the public consider whether the 

private sector could alternatively 

address any perceived need or demand 

for such certification. For example, we 

are aware 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.44

B. 2014 Edition EHR Accounting of 

Disclosures Certification Criterion 

We previously adopted an 

‘‘accounting of disclosures’’ optional 

certification criterion for the 2011 

Edition EHR certification criteria 

(§ 170.302(w)), which requires EHR 

technology to be capable of 

electronically recording disclosures 

made for treatment, payment, and 

health care operations in accordance 

with the standard specified in 

§ 170.210(d) (‘‘Record treatment, 

payment, and health care operations 

disclosures. The date, time, patient 

identification, user identification, and a 

description of the disclosure must be 

recorded for disclosures for treatment, 

payment, and health care operations, as 

these terms are defined at 45 CFR 

164.501’’). We are proposing to adopt 

this same certification criterion as an 

optional certification criterion for the 

2014 Edition EHR certification criteria 

(§ 170.314(d)(9)), but are requesting 

public comment on whether we should 

adopt a revised certification criterion. 

Since publication of the S&CC July 2010 

final rule, the HHS Office for Civil 

Rights 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.45 We are 

interested in whether commenters 

believe that the 2014 Edition EHR 

certification criterion for ‘‘accounting of 

disclosures’’ should be revised to be a 

mandatory certification criterion. We 

are also interested in whether 

commenters think 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 are interested 

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 believe revisions are 

appropriate, we respectfully request 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 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13872 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

46http://www.minorityhealth.hhs.gov/templates/

browse.aspx?lvl=2&lvlid=208. 47http://wiki.siframework.org/file/detail/

CARE+Tool+Functional%2C+Cognitive+and+Skin+

Status.xls. 

and the rationale for including those 

capabilities. 

C. Disability Status 

We are interested in whether 

commenters believe that 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’’). 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 also 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. Further, the recording of 

disability status could help monitor 

disparities between the ‘‘disabled’’ and 

‘‘nondisabled’’ population. 

We are specifically requesting 

comment on whether there exists a 

standard(s) that would be appropriate 

for recording disability status in EHR 

technology. We are aware of a standard 

for disability status approved by the 

Secretary for use in population health 

surveys sponsored by HHS 46 and 

standards under development as part of 

the Standards and Interoperability 

Framework and the Continuity 

Assessment Record and Evaluation 

(CARE) assessment tool.47 We welcome 

comments on whether these standards 

or any other standards would be 

appropriate for recording disability 

status in EHR technology. 

We ask 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 ask commenters to consider 

whether the recording of disability 

status should be part of a Base EHR and 

included in a separate certification 

criterion or possibly the 

‘‘demographics’’ certification criterion 

(§ 170.314(a)(3)). Last, we ask 

commenters to 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)). 

D. Data Portability 

We seek public comment on whether 

we should adopt a certification criterion 

that focuses on the portability of data 

stored within CEHRT. When a provider 

seeks to change EHR technology, we 

believe that they 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. In the absence of this 

capability, providers may be ‘‘lockedin’’ to their current EHR technology. 

This could ultimately impede 

innovation and is a key aspect of the 

EHR technology market that requires 

significant maturity. With these 

considerations, we seek responses to the 

following questions: 

1. Is EHR technology capable of 

electronically providing a sufficient 

amount of a patient’s health history 

using summary of care records 

formatted according to the Consolidated 

CDA for the scenario described above? 

2. Is all of the data in a provider’s 

EHR #1 necessary to migrate over to 

EHR #2 in the event the provider wants 

to switch? We recognize that medical 

record retention laws affect the 

provider’s overall approach in terms of 

a full archived data set, but our question 

seeks to determine whether the loss of 

some data would be tolerable and if so, 

which data? 

3. Considering the standards we have 

adopted and propose for adoption in 

this rule, we request comment on what 

additional standards and guidance 

would be necessary to meet these 

market needs for data portability, 

including the portability of 

administrative data such as Medicare 

and Medicaid eligibility and claims. 

Additionally, we are interested in 

commenters’ thoughts related to an 

incremental approach where a specific 

set of patient data could be used as a 

foundation to improve data portability 

for the situation described above as well 

as other situations. 

4. Does the concept of a capability to 

batch export a single patient’s records 

(or a provider’s entire patient 

population) pose unintended 

consequences from a security 

perspective? What factors should be 

considered to mitigate any potential 

abuse of this capability, if it existed? 

E. EHR Technology Price Transparency 

Section 170.523(k)(3) requires that 

when an ONC–ACB issues a 

certification to a Complete EHR or EHR 

Module based solely on the applicable 

certification criteria adopted by the 

Secretary at subpart C of this part, the 

certification must be separate and 

distinct from any other certification(s) 

based on other criteria or requirements 

(such as those not part of the ONC HIT 

Certification Program). During 

implementation of the temporary 

certification program, we have received 

feedback from stakeholders that some 

EHR technology developers do not 

provide clear price transparency related 

to the full cost of a certified Complete 

EHR or certified EHR Module. Instead, 

some EHR technology developers 

identify prices for multiple groupings of 

capabilities even though the groupings 

do not correlate to the capabilities of the 

entire certified Complete EHR or 

certified EHR Module. Thus, with the 

transparency already required by 

§ 170.523(k)(3) in mind, we believe that 

the EHR technology market could 

benefit from transparency related to the 

price associated with a certified 

Complete EHR or certified EHR Module. 

We believe price transparency could be 

achieved through a requirement that 

ONC–ACBs ensure that EHR technology 

developers include clear pricing of the 

full cost 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. Put simply, this provision 

would require EHR technology 

developers to disclose only the full cost 

of a certified Complete EHR or certified 

EHR Module. It would in no way dictate 

the price an EHR technology developer 

could assign to its EHR technology, just 

that a single price for all the capabilities 

in the certified Complete EHR or 

certified EHR Module be made publicly 

available. We believe price transparency 

would provide purchasing clarity for 

health care providers and lead to more 

competitive EHR technology pricing. 

We request comment on the feasibility 

and value of price transparency for 

certified Complete EHRs and certified 

EHR Modules in the manner described. 

VI. Response to Comments 

Because of the large number of public 

comments normally received in 

response to Federal Register 

documents, we are not able to 

acknowledge or respond to them 

individually. We will consider all 

comments we receive by the date and 

time specified in the DATES section of 

this preamble, and, when we proceed 

with a subsequent document, we will 

respond to the comments in the 

preamble of that document. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13873 

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. 

Under the PRA, the time, effort, and 

financial resources necessary to meet 

the information collection requirements 

referenced in this section are to be 

considered. We explicitly seek, and will 

consider, public comment on our 

assumptions as they relate to the PRA 

requirements summarized in this 

section. To comment on the collection 

of information or to obtain copies of the 

supporting statements and any related 

forms for the proposed paperwork 

collections referenced in this section, 

email your comment or request, 

including your address and phone 

number to Sherette.funncoleman@hhs.

gov, or call the Reports Clearance Office 

at (202) 690–6162. Written comments 

and recommendations for the proposed 

information collections must be directed 

to the OS Paperwork Clearance Officer 

at the above email address within 60 

days. 

Abstract 

Under the permanent 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. 

In the Permanent Certification 

Program final rule (76 FR 1312–14), we 

solicited public comment on each of the 

information collections associated with 

the requirements described above (and 

included in regulation at 45 CFR 

170.503(b), 170.520, and 170.523(f), (g), 

and (i), respectively). These collections 

of information are currently approved 

under OMB control number 0990–0378. 

In this proposed rule, we seek to revise 

§ 170.523(f) and, correspondingly, seek 

to revise the approved collection of 

information 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 propose 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 

propose to add this requirement at 

§ 170.523(f)(8). 

For the purposes of estimating this 

additional potential burden, we have 

used the following assumptions. We 

assume 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 

assume 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 estimate that, on 

average, each ONC–ACB will report 4 

test results hyperlinks to ONC on a 

weekly basis. 

We believe it will take approximately 

5 minutes to report each hyperlink to 

ONC. Therefore, as reflected in the table 

below, we estimate 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. 

ESTIMATED ANNUALIZED BURDEN HOURS

Type of respondent Number of 

respondents 

Number of 

responses per 

respondent 

Average 

burden hours 

per response 

Total burden 

hours 

45 CFR 170.523(f)(8) ...................................................................................... 6 52 .33 103 

With the additional proposed 

collection of information at 

§ 170.523(f)(8), we believe 103 burden 

hours will be added 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. 

ESTIMATED ANNUALIZED TOTAL BURDEN HOURS

Type of respondent Number of 

respondents 

Number of 

responses per 

respondent 

Average 

burden 

hours per 

response 

Total 

burden 

hours 

45 CFR 170.503(b) ........................................................................................ 2 1 1 2 

45 CFR 170.520 ............................................................................................ 6 1 1 6 

45 CFR 170.523(f) ......................................................................................... 6 52 1 .33 415 

45 CFR 170.523(g) ........................................................................................ n/a n/a n/a n/a 

45 CFR 170.523(i) ......................................................................................... 6 2 1 12 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13874 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

ESTIMATED ANNUALIZED TOTAL BURDEN HOURS—Continued 

Type of respondent Number of 

respondents 

Number of 

responses per 

respondent 

Average 

burden 

hours per 

response 

Total 

burden 

hours 

Total burden hours for OMB control number 0990–0378 ...................... ........................ ........................ .......................... 435 

VIII. 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. 

This proposed rule is being published to 

revise previously adopted standards, 

implementation specifications, and 

certification criteria and to propose the 

adoption of new standards, 

implementation specifications, and 

certification criteria in order to support 

future MU Stages’ objectives and 

measures. Certification criteria and 

associated standards and 

implementation specifications will be 

used to test and certify Complete EHRs 

and EHR Modules in order to make it 

possible for EPs, EHs, and CAHs to 

adopt and implement 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 

proposed 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. 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 proposed rule 

is not an economically significant rule 

because we estimate that the costs to 

prepare Complete EHRs and EHR 

Modules to be tested and certified will 

be less than $100 million per year. 

Nevertheless, because of the public 

interest in this proposed rule, we have 

prepared an RIA that to the best of our 

ability presents the costs and benefits of 

the proposed rule. 

a. Costs 

This rule proposes the adoption of 

standards, implementation 

specifications, and certification criteria 

that would 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 proposed 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 upgrade to the 

proposed 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 develop and 

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 

certification criteria discussed in this 

proposed rule (i.e., new, revised, and 

unchanged). The numbers of Complete 

EHRs and EHR Modules that we 

estimate would be tested and certified to 

each certification criteria are based on 

the statistics we obtained from the 

CHPL on September 11, 2011. We 

attempted to identify the total number 

of unique Complete EHRs and EHR 

Modules that had been certified to the 

2011 Edition EHR certification criteria 

as of September 11th. By this we mean 

that we attempted to discern how many 

Complete EHRs and EHR Modules were 

certified that would not constitute a 

newer version of the same EHR 

technology. Using this number, we have 

adjusted it based on additional 

considerations such as our proposals 

related to optional certification criteria, 

to the Base EHR certification criteria, 

and to our revised definition of CEHRT. 

The proposed revised CEHRT definition 

would 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 

certified to each certification criterion, 

we have then created 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 

tested and certified to the 2011 Edition 

EHR certification criteria that may not 

be tested and certified 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 since there would not be any 

costs associated with upgrading EHR 

technologies previously certified to the 

2011 Edition EHR certification criteria. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13875 

48http://www.bls.gov/oes/current/oes151132.htm. 

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 $43.47.48 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 up 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 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 

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. 

New Certification Criteria 

TABLE 7—2014 EDITION NEW EHR CERTIFICATION CRITERIA: LEVEL 1 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average 

development and preparation 

costs 

Low 

($M) 

High 

($M) 

170.314(a)(9) ............. Electronic notes ................................................................................... 420–514 1.01 3.08 

170.314(a)(13) ........... Family health history ........................................................................... 420–514 1.01 3.08 

170.314(b)(3) ............. Electronic prescribing (inpatient) ......................................................... 101–123 .24 .74 

170.314(f)(7) .............. Cancer case information ..................................................................... 320–392 .77 2.35 

170.314(g)(3) ............. Non-percentage-based measure use report ....................................... 567–693 1.36 4.16 

Total .................... .............................................................................................................. ........................ 4.39 13.41 

TABLE 8—2014 EDITION NEW EHR CERTIFICATION CRITERIA: LEVEL 2 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(a)(12) ........... Imaging ................................................................................................ 420–514 2.52 9.25 

170.314(b)(6) ............. Transmission of electronic laboratory tests and values/results to ambulatory providers.146–178 .88 3.20 

170.314(d)(4) ............. Amendments ....................................................................................... 566–691 3.40 12.44 

170.314(e)(3) ............. Secure messaging ............................................................................... 320–392 1.92 7.06 

170.314(f)(8) .............. Transmission to cancer registries ....................................................... 320–392 1.92 7.06 

170.314(g)(1) ............. Automated numerator recording ......................................................... 398–486 2.39 8.75 

Total .................... .............................................................................................................. ........................ 13.03 47.76 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13876 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

TABLE 9—2014 EDITION NEW EHR CERTIFICATION CRITERIA: LEVEL 3 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(a)(17) ........... Electronic medication administration record ....................................... 101–123 1.82 2.95 

170.314(e)(1) ............. View, download, and transmit to 3rd party ......................................... 567–693 10.21 16.63

170.314(g)(4) ............. Safety-enhanced design ...................................................................... 567–693 10.21 16.63 

Total .................... .............................................................................................................. ........................ 22.24 36.21 

Revised Certification Criteria 

TABLE 10—2014 EDITION REVISED EHR CERTIFICATION CRITERIA: LEVEL 1 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(a)(2) ............. Drug-drug, drug-allergy interaction checks ......................................... 420–514 1.01 3.08 

170.314(a)(3) ............. Demographics ..................................................................................... 460–562 1.10 3.37 

170.314(a)(5) ............. Problem list .......................................................................................... 438–536 1.05 3.22 

170.314(a)(16) ........... Patient-specific education resources ................................................... 421–515 1.01 3.09 

170.314(b)(3) ............. Electronic prescribing (ambulatory) ..................................................... 328–400 .79 2.40 

170.314(b)(5) ............. Incorporate laboratory tests and values/results (ambulatory setting) 277–339 .66 2.03 

170.314(c)(2) ............. Clinical quality measures—incorporate and calculate ........................ 379–463 .91 2.78 

170.314(d)(3) ............. Audit report(s) ...................................................................................... 567–693 1.36 4.16 

170.314(e)(2) ............. Clinical summaries .............................................................................. 314–384 .75 2.30 

170.314(f)(2) .............. Transmission to immunization registries ............................................. 382–466 .92 2.80

170.314(f)(4) .............. Transmission to public health agencies .............................................. 373–455 .90 2.73

170.314(f)(6) .............. Transmission of reportable laboratory tests and values/results ......... 63–77 .15 .46 

Total .................... .............................................................................................................. ........................ 10.61 32.42 

TABLE 11—2014 EDITION REVISED EHR CERTIFICATION CRITERIA: LEVEL 2 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(b)(1) ............. Transitions of care—incorporate summary care record ...................... 381–465 2.29 8.37 

170.314(b)(4) ............. Clinical information reconciliation ........................................................ 434–530 2.60 9.54 

170.314(c)(3) ............. Clinical quality measures—reporting ................................................... 379–463 2.27 8.33 

170.314(d)(2) ............. Auditable events and tamper resistance ............................................. 567–693 3.40 12.47

170.314(d)(7) ............. Encryption of data at rest .................................................................... 566–691 3.40 12.44 

170.314(g)(2) ............. Automated measure calculation .......................................................... 396–484 2.21 8.71 

Total .................... .............................................................................................................. ........................ 16.17 59.86 

TABLE 12—2014 EDITION REVISED EHR CERTIFICATION CRITERIA: LEVEL 3 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(a)(8) ............. Clinical decision support ...................................................................... 409–501 7.36 12.02 

170.314(b)(2) ............. Transitions of care—create and transmit ............................................ 381–465 6.86 11.16

170.314(c)(1) ............. Clinical quality measures—capture and export ................................... 379–463 6.82 11.11 

Total .................... .............................................................................................................. ........................ 21.04 34.29 

Unchanged Certification Criteria 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13877 

TABLE 13—2014 EDITION UNCHANGED EHR CERTIFICATION CRITERIA: LEVEL 2 EFFORT

Regulation section Title of regulation paragraph 

Estimated # of 

EHR technologies to be 

developed with 

this capability 

Average development and 

preparation costs 

Low 

($M) 

High 

($M) 

170.314(a)(1) ............. CPOE .................................................................................................. 42 .25 .76 

170.314(a)(4) ............. Vital signs, body mass index, and growth charts ............................... 48 .29 .86 

170.314(a)(6) ............. Medication list ...................................................................................... 50 .30 .90 

170.314(a)(7) ............. Medication allergy list .......................................................................... 50 .30 .90 

170.314(a)(10) ........... Drug-formulary checks ........................................................................ 47 .28 .85 

170.314(a)(11) ........... Smoking status .................................................................................... 50 .30 .90 

170.314(a)(14) ........... Patient lists .......................................................................................... 46 .28 .83 

170.314(a)(15) ........... Patient reminders ................................................................................ 36 .22 .65 

170.314(a)(18) ........... Advance directives .............................................................................. 11 .07 .20 

170.314(b)(5) ............. Incorporate laboratory tests and values/results (inpatient setting) ..... 16 .10 .29 

170.314(d)(1) ............. Authentication, access control, and authorization ............................... 64 .38 1.15 

170.314(d)(5) ............. Automatic log-off ................................................................................. 63 .38 1.13 

170.314(d)(6) ............. Emergency access .............................................................................. 62 .37 1.12 

170.314(d)(8) ............. Integrity ................................................................................................ 63 .38 1.13 

170.314(d)(9) ............. Accounting of disclosures ................................................................... 15 .09 .27 

170.314(f)(1) .............. Immunization information .................................................................... 42 .25 .76 

170.314(f)(3) .............. Public health surveillance .................................................................... 41 .25 .74 

170.314(f)(5) .............. Reportable laboratory tests and values/results ................................... 7 .04 .13 

Total .................... .............................................................................................................. ........................ 4.53 13.57 

ii. Overall Development and Preparation 

Costs Over a 3-year Period 

In total, we estimate the overall costs 

for a 3-year period to be $92.01 million 

to $237.52 million, with a cost midpoint of approximately $164.77 million. 

If we were to evenly distribute the 

overall 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 $30.67 million to $79.17 

million per year with an annual cost 

mid-point of approximately $54.92 

million. However, we do not believe 

that the costs will be spread evenly over 

these three years due to market 

pressures to have certified Complete 

EHRs and certified EHR Modules ready 

and available prior to when EPs, EHs, 

and CAHs must meet the proposed 

revised definition of CEHRT for FY/CY 

2014. We assume this factor will cause 

a greater number of developers to 

prepare EHR technology for testing and 

certification towards the end of 2012 

and throughout 2013, rather than in 

2014. As a result, we believe as 

represented in Table 14 that the costs 

attributable to this proposed rule will be 

distributed as follows: 40% for 2012, 

50% for 2013, and 10% for 2014. The 

dollar amounts expressed in Table 14 

are expressed in 2012 dollars. 

TABLE 14.— DISTRIBUTED TOTAL PREPARATION COSTS FOR COMPLETE EHR AND EHR MODULE DEVELOPERS (3 YEAR

PERIOD)—TOTALS ROUNDED

Year Ratio 

(percent) 

Total low cost 

estimate 

($M) 

Total high cost 

estimate 

($M) 

Total average 

cost estimate 

($M) 

2012 ................................................................................................................. 40 36.80 95.01 65.91 

2013 ................................................................................................................. 50 46.01 118.76 82.38 

2014 ................................................................................................................. 10 9.20 23.75 16.48 

3-Year Totals ................................................................................................... ........................ 92.01 237.52 167.53 

iii. Costs for Reporting Test Results 

Hyperlinks 

Costs to ONC–ACBs 

Under § 170.523(f)(8), ONC–ACBs 

will be 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, we 

will require the reporting of this 

information on a weekly basis and that 

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. 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13878 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

49The SBA references that annual receipts means 

‘‘total income’’ (or in the case of a sole 

proprietorship, ‘‘gross income’’) plus ‘‘cost of goods 

sold’’ as these terms are defined and reported on 

Internal Revenue Service tax return forms. http://

www.sba.gov/sites/default/files/Size_Standards_

Table.pdf. 

TABLE 15—ANNUAL COSTS FOR AN ONC–ACB TO REPORT TEST RESULTS HYPERLINKS TO ONC 

Program requirement Employee equivalent 

Annual burden 

hours per 

ONC–ACB 

Employee 

hourly wage 

rate 

Employee 

Benefits 

Hourly Cost 

Total cost per 

ONC–ACB 

45 CFR 170.523(f)(8) ........................ GS–9 Step 1 .................................... 17.16 $22.39 $8.06 $522.52 

To estimate the highest possible cost, 

we assume that all of the estimated 

applicants (i.e., six) that we anticipate 

will apply under the permanent 

certification program will become ONC– 

ACBs. Therefore, we estimate the total 

annual development and reporting cost 

for under the permanent certification 

program to be $3,136 (rounded using a 

total of 103 hours). 

Costs to the Federal Government 

We do not believe that we will incur 

any additional costs to post test results 

hyperlinks than the costs we estimated 

for posting a list of all certified 

Complete EHRs and 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 

proposed rule. Foremost, the proposed 

2014 Edition EHR certification criteria 

include the capabilities that CEHRT 

must have to support EPs’, EHs’, and 

CAHs’ attempts to demonstrate MU and 

qualify for incentive payments under 

the EHR Incentive Programs. 

Additionally, by adopting the proposed 

new and revised certification criteria, 

the interoperability, functionality, 

utility, and security of EHR technology 

will be further enhanced. The 

capabilities specified in the adopted 

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 

proposals in this proposed rule would 

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 

proposals to revise the definition of 

CEHRT, the process for approving 

newer versions of minimum standards, 

and the 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 proposed splitting of 

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, we believe the 

proposals in this proposed rule will be 

supportive of other initiatives, such as 

the Partnership for Patients. 

2. 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 proposed 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 million in 

annual receipts 49 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 proposed rule 

would have effects on Complete EHR 

and EHR Module developers, some of 

which may be small entities. However, 

we believe that we have proposed 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 proposed 

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 EHR Incentive 

Programs Stage 2 final rule, it will need 

to comply with the applicable 

certification criteria adopted by the 

Secretary. Moreover, we note that this 

proposed 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 the proposed rule 

will create a significant impact on a 

substantial number of small entities. 

The Secretary certifies that this 

proposed rule will not have a significant 

impact on a substantial number of small 

entities. We do, however, request 

comment on whether there are small 

entities that we have not identified that 

may be affected in a significant way by 

this proposed rule. 

3. Executive Order 13132—Federalism 

Executive Order 13132 establishes 

certain requirements that an agency 

must meet when it promulgates a 

proposed rule (and subsequent final 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13879 

rule) that imposes substantial direct 

requirement costs on State and local 

governments, preempts State law, or 

otherwise has federalism implications. 

Nothing in this proposed 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 we propose for adoption. 

4. 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 $136 

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 proposed 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, proposes to amend 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. Amend § 170.102 by adding in 

alphanumeric order the definitions 

‘‘2011 Edition EHR certification 

criteria,’’ ‘‘2014 Edition EHR 

certification criteria,’’ and ‘‘Base EHR’’ 

and revising the definitions of ‘‘Certified 

EHR Technology’’ and ‘‘Complete EHR’’ 

to read as follows: 

§ 170.102 Definitions. 

* * * * * 

2011 Edition EHR certification criteria 

means the certification criteria at 

§§ 170.302, 170.304, and 170.306. 

2014 Edition EHR certification criteria 

means the certification criteria at 

§ 170.314. 

Base EHR means an electronic record 

of health-related information on an 

individual that: 

(1) Includes patient demographic and 

clinical health information, such as 

medical history and problem lists; 

(2) Has the capacity: 

(i) To provide clinical decision 

support; 

(ii) To support physician order entry; 

(iii) To capture and query information 

relevant to health care quality; 

(iv) To exchange electronic health 

information with, and integrate such 

information from other sources; 

(v) To protect the confidentiality, 

integrity, and availability of health 

information stored and exchanged; and 

(3) Meets the certification criteria 

adopted by the Secretary at: 

§ 170.314(a)(1) through (8); (b)(1) and 

(2); (c)(1) and (2); (d)(1) through (8); and 

(e)(1). 

* * * * * 

Certified EHR Technology means: 

(1) For any Federal fiscal year (FY) or 

calendar year (CY) up to and including 

2013: 

(i) A Complete EHR that 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; or 

(ii) A combination of EHR Modules in 

which each constituent EHR Module of 

the combination 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, and the resultant 

combination also meets the 

requirements included in the definition 

of a Qualified EHR. 

(2) For FY and CY 2014 and 

subsequent years, the following: EHR 

technology certified under the ONC HIT 

Certification Program to the 2014 

Edition EHR certification criteria that 

has: 

(i) The capabilities required to meet 

the definition of a Base EHR; and 

(ii) All other capabilities that are 

necessary to meet the objectives and 

associated measures under 42 CFR 495.6 

and successfully report the clinical 

quality measures selected by CMS in the 

form and manner specified by CMS (or 

the States, as applicable) for the stage of 

meaningful use that an eligible 

professional, eligible hospital, or critical 

access hospital seeks to achieve. 

Complete EHR means 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. 

* * * * * 

3. Add § 170.202 to read as follows: 

§ 170.202 Transport standards. 

The Secretary adopts the following 

transport standards: 

(a) Directed exchange. (1) Standard. 

Applicability Statement for Secure 

Health Transport (incorporated by 

reference in § 170.299). 

(2) Standard. External Data 

Representation and Cross-Enterprise 

Document Media Interchange for Direct 

Messaging (incorporated by reference in 

§ 170.299). 

(3) Standard. Simple Object Access 

Protocol (SOAP)-Based Secure 

Transport Requirements Traceability 

Matrix (RTM) version 1.0 (incorporated 

by reference in § 170.299). 

(b) [Reserved] 

4. Add § 170.204 to read as follows: 

§ 170.204 Functional standards. 

The Secretary adopts the following 

functional standards: 

(a) Accessibility. Standard. Web 

Content Accessibility Guidelines 

(WCAG) 2.0, Level AA Conformance 

(incorporated by reference in § 170.299). 

(b) Reference source. Standard. 

Health Level Seven Context-Aware 

Knowledge Retrieval (Infobutton), 

International Normative Edition 2010 

(incorporated by reference in § 170.299). 

(c) Clinical quality measure data 

capture and export. Standard. National 

Quality Forum (NQF) Quality Data 

Model, Version 2011 (incorporated by 

reference in § 170.299). 

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: 

§ 170.205 Content exchange standards 

and implementation specifications for 

exchanging electronic health information. 

The Secretary adopts the following 

content exchange standards and 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13880 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

associated implementation 

specifications: 

(a) * * * 

(3) Standard. HL7 Implementation 

Guide for Clinical Document 

Architecture, Release 2.0 (Consolidated 

CDA) (US Realm), Draft, September 

2011 (incorporated by reference in 

§ 170.299). 

* * * * * 

(d) * * * 

(3) Standard. HL7 2.5.1 (incorporated 

by reference in § 170.299). 

Implementation specifications. PHIN 

Messaging Guide for Syndromic 

Surveillance: Emergency Department 

and Urgent Care Data HL7 Version 2.5.1 

(incorporated by reference in § 170.299). 

(e) * * * 

(3) Standard. HL7 2.5.1 (incorporated 

by reference in § 170.299). 

Implementation specifications. HL7 

2.5.1 Implementation Guide for 

Immunization Messaging Release 1.3 

(incorporated by reference in § 170.299). 

* * * * * 

(g) Electronic transmission of lab 

results to public health agencies. 

Standard. HL7 2.5.1 (incorporated by 

reference in § 170.299). Implementation 

specifications. HL7 Version 2.5.1 

Implementation Guide: Electronic 

Laboratory Reporting to Public Health, 

Release 1 (US Realm) with errata 

(incorporated by reference in § 170.299). 

(h) [Reserved] 

(i) Cancer information. Standard. HL7 

Clinical Document Architecture (CDA), 

Release 2 (incorporated by reference in 

§ 170.299). Implementation 

specifications. Implementation Guide 

for Healthcare Provider Reporting to 

Central Cancer Registries, Draft, 

February 2012 (incorporated by 

reference in § 170.299). 

(j) Imaging. Digital Imaging and 

Communications in Medicine (DICOM) 

PS 3—2011. 

(k) Electronic incorporation and 

transmission of lab results. Standard. 

HL7 2.5.1 (incorporated by reference in 

§ 170.299). Implementation 

specifications. HL7 Version 2.5.1 

Implementation Guide: Standards and 

Interoperability Framework Lab Results 

Interface, Release 1 (US Realm) 

(incorporation by reference in 

§ 170.299). 

6. In § 170.207, republish the 

introductory text, revise paragraph (f), 

and add paragraphs (a)(3), (b)(3), and (g) 

through (m) to read as follows: 

§ 170.207 Vocabulary standards for 

representing electronic health information. 

The Secretary adopts the following 

code sets, terminology, and 

nomenclature as the vocabulary 

standards for the purpose of 

representing electronic health 

information: 

(a) * * * 

(3) Standard. International Health 

Terminology Standards Development 

Organization (IHTSDO) Systematized 

Nomenclature of Medicine Clinical 

Terms (SNOMED CT®) International 

Release January 2012 (incorporated by 

reference in § 170.299). 

(b) * * * 

(3) Standard. The code set specified at 

45 CFR 162.1002(c)(3). 

* * * * * 

(f) Race and Ethnicity. Standard. The 

Office of Management and Budget 

Standards for Maintaining, Collecting, 

and Presenting Federal Data on Race 

and Ethnicity, Statistical Policy 

Directive No. 15, as revised, October 30, 

1997 (see ‘‘Revisions to the Standards 

for the Classification of Federal Data on 

Race and Ethnicity,’’ available at 

http://www.whitehouse.gov/omb/ 

fedreg_1997standards). 

(g) Laboratory tests. Standard. Logical 

Observation Identifiers Names and 

Codes (LOINC®) version 2.38 

(incorporated by reference in § 170.299). 

(h) Medications. Standard. RxNorm, a 

standardized nomenclature for clinical 

drugs produced by the United States 

National Library of Medicine, February 

6, 2012 Release (incorporated by 

reference in § 170.299). 

(i) Immunizations. Standard. HL7 

Standard Code Set CVX—Vaccines 

Administered, August 15, 2011 version 

(incorporated by reference in § 170.299). 

(j) Preferred language. Standard. ISO 

639–1:2002 (incorporated by reference 

in § 170.299). 

(k) Preliminary determination of 

cause of death. Standard. The code set 

specified at 45 CFR 162.1002(c)(2) for 

the indicated conditions. 

(l) Smoking status. Standard. 

Smoking status types must include: 

Current every day smoker; current some 

day smoker; former smoker; never 

smoker; smoker, current status 

unknown; and unknown if ever smoked. 

(m) Encounter diagnoses. Standard. 

The code set specified at 45 CFR 

162.1002(c)(2) for the indicated 

conditions. 

7. In § 170.210 republish the 

introductory text and add paragraphs 

(e), (f), and (g) to read as follows: 

§ 170.210 Standards for health information 

technology to protect electronic health 

information created, maintained, and 

exchanged. 

The Secretary adopts the following 

standards to protect electronic health 

information created, maintained, and 

exchanged: 

* * * * * 

(e) Record actions related to 

electronic health information, audit log 

status, and encryption of end-user 

devices. (1) When EHR technology is 

used to create, change, access, or delete 

electronic health information, the 

following information must be recorded: 

(i) The electronic health information 

affected by the action(s); 

(ii) The date and time each action 

occurs in accordance with the standard 

specified at § 170.210(g); 

(iii) The action(s) that occurred; 

(iv) Patient identification; and 

(v) User identification. 

(2) When the audit log is enabled or 

disabled, the following must be 

recorded: 

(i) The date and time each action 

occurs in accordance with the standard 

specified at § 170.210(g); and 

(ii) User identification. 

(3) As applicable, when encryption of 

electronic health information managed 

by EHR technology on end-user devices 

is enabled or disabled, the following 

must be recorded: 

(i) The date and time each action 

occurs in accordance with the standard 

specified at § 170.210(g); and 

(ii) User identification. 

(f) Encryption and hashing of 

electronic health information. Any 

encryption and hashing algorithm 

identified by the National Institute of 

Standards and Technology (NIST) as an 

approved security function in Annex A 

of the Federal Information Processing 

Standards (FIPS) Publication 140–2 

(incorporated by reference in § 170.299). 

(g) Synchronized clocks. The date and 

time recorded utilize a system clock that 

has been synchronized following 

Request for Comments (RFC) 1305 

Network Time Protocol (NTP) v3 

(incorporated by reference in § 170.299) 

or RFC 5905 NTPv4 (incorporated by 

reference in § 170.299). 

8. In § 170.300, republish paragraphs 

(a) and (b), revise paragraph (c) and add 

paragraph (d) to read as follows: 

§ 170.300 Applicability. 

(a) The certification criteria adopted 

in this subpart apply to the testing and 

certification of Complete EHRs and EHR 

Modules. 

(b) 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. 

(c) Complete EHRs and EHR Modules 

are not required to be compliant with 

certification criteria or capabilities 

specified within a certification criterion 

that are designated as optional. 

(d) In § 170.314, all certification 

criteria and all capabilities specified 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13881 

within a certification criterion have 

general applicability (i.e., apply to both 

ambulatory and inpatient settings) 

unless designated as ‘‘inpatient setting 

only’’ or ‘‘ambulatory setting only.’’ 

(1) ‘‘Inpatient setting only’’ means that 

the criterion or capability within the 

criterion is only required for 

certification of EHR technology 

designed for use in an inpatient setting. 

(2) ‘‘Ambulatory setting only’’ means 

that the criterion or capability within 

the criterion is only required for 

certification of EHR technology 

designed for use in an ambulatory 

setting. 

9. Add § 170.314 to subpart C to read 

as follows: 

§ 170.314 2014 Edition electronic health 

record certification criteria. 

The Secretary adopts the following 

certification criteria for Complete EHRs 

or EHR Modules. Complete EHRs or 

EHR Modules must include the 

capability to perform the following 

functions electronically, unless 

designated as optional, and in 

accordance with all applicable 

standards and implementation 

specifications adopted in this part: 

(a) Clinical. 

(1) Computerized provider order 

entry. Enable a user to electronically 

record, change, and access the following 

order types, at a minimum: 

(i) Medications; 

(ii) Laboratory; and 

(iii) Radiology/imaging. 

(2) Drug-drug, drug-allergy interaction 

checks. 

(i) Interventions. Before a medication 

order is placed during computerized 

provider order entry (CPOE), 

interventions must automatically and 

electronically indicate to a user at the 

point of care of drug-drug and drugallergy contraindications based on 

medication list and medication allergy 

list. 

(ii) Adjustments. 

(A) Enable the severity level of 

interventions provided for drug-drug 

interaction checks to be adjusted. 

(B) Limit the ability to adjust severity 

levels to an identified set of users or 

available as a system administrative 

function. 

(3) Demographics. 

(i) Enable a user to electronically 

record, change, and access patient 

demographic data including preferred 

language, gender, race, ethnicity, and 

date of birth. 

(A) Enable race and ethnicity to be 

recorded in accordance with the 

standard specified in § 170.207(f) and 

whether a patient declines to specify 

race and/or ethnicity. 

(B) Enable preferred language to be 

recorded in accordance with the 

standard specified in § 170.207(j) and 

whether a patient declines to specify a 

preferred language. 

(ii) Inpatient setting only. Enable a 

user to electronically record, change, 

and access preliminary cause of death in 

the event of a mortality in accordance 

with the standard specified in 

§ 170.207(k). 

(4) Vital signs, body mass index, and 

growth charts. 

(i) Vital signs. Enable a user to 

electronically record and change, and 

access recordings of a patient’s vital 

signs including, at a minimum, 

height/length, weight, and blood 

pressure. 

(ii) Calculate body mass index. 

Automatically calculate and 

electronically display body mass index 

based on a patient’s height and weight. 

(iii) Optional—Plot and display 

growth charts. Plot and electronically 

display, upon request, growth charts for 

patients. 

(5) Problem list. Enable a user to 

electronically record, change, and 

access a patient’s problem list for 

longitudinal care in accordance with, at 

a minimum, the version of the standard 

specified in § 170.207(a)(3). 

(6) Medication list. Enable a user to 

electronically record, change, and 

access a patient’s active medication list 

as well as medication history for 

longitudinal care. 

(7) Medication allergy list. Enable a 

user to electronically record, change, 

and access a patient’s active medication 

allergy list as well as medication allergy 

history for longitudinal care. 

(8) Clinical decision support. 

(i) Evidence-based decision support 

interventions. Enable a user to select (or 

activate) one or more electronic clinical 

decision support interventions (in 

addition to drug-drug and drug-allergy 

contraindication checking) based on the 

data elements included in each one or 

any combination of the following: 

(A) Problem list; 

(B) Medication list; 

(C) Medication allergy list; 

(D) Demographics; 

(E) Laboratory tests and values/ 

results; and 

(F) Vital signs. 

(ii) Linked referential clinical decision 

support. 

(A) Enable a user to retrieve 

diagnostic or therapeutic reference 

information in accordance with the 

standard specified at § 170.204(b)(1). 

(B) Enable a user to access the 

reference information specified in 

paragraph (a)(8)(ii)(A) of this section 

relevant to patient context based on the 

data elements included in each one or 

any combination of the following: 

(1) Problem list; 

(2) Medication list; 

(3) Medication allergy list; 

(4) Demographics; 

(5) Laboratory tests and values/ 

results; and 

(6) Vital signs. 

(iii) Configure clinical decision 

support. 

(A) Enable interventions and 

reference resources specified in 

paragraphs (a)(8)(i) and (ii) of this 

section to be configured by an identified 

set of users (e.g., system administrator) 

based on each one of the following: 

(1) A user’s role; 

(2) Clinical setting; and 

(3) Identified points in the clinical 

workflow. 

(B) Enable interventions to be 

triggered, based on the data elements 

specified in paragraph (a)(8)(i) of this 

section, when a summary care record is 

incorporated pursuant to 

§ 170.314(b)(1). 

(iv) Automatically and electronically 

interact. Interventions selected and 

configured in accordance with 

paragraphs (a)(8)(i) through (iii) of this 

section must automatically and 

electronically occur when a user is 

interacting with EHR technology. 

(v) Source attributes. Enable a user to 

review the attributes for each 

intervention or reference source for all 

clinical decision support resources 

including: 

(A) Bibliographic citation (clinical 

research/guideline) including 

publication; 

(B) Developer of the intervention 

(translation from clinical research/ 

guideline); 

(C) Funding source of intervention 

development technical implementation; 

and 

(D) Release and, if applicable, revision 

date of the intervention. 

(9) Electronic notes. Enable a user to 

electronically record, change, access, 

and search electronic notes. 

(10) Drug-formulary checks. Enable a 

user to electronically check if drugs are 

in a formulary or preferred drug list. 

(11) Smoking status. Enable a user to 

electronically record, change, and 

access the smoking status of a patient in 

accordance with the standard specified 

at § 170.207(l). 

(12) Imaging. Electronically indicate 

to a user the availability of a patient’s 

images and/or narrative interpretations 

(relating to the radiographic or other 

diagnostic test(s)) and enable immediate 

electronic access to such images and 

narrative interpretations. 

(13) Family health history. Enable a 

user to electronically record, change, 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13882 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

and access a patient’s family health 

history. 

(14) Patient lists. 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. 

(15) Ambulatory setting only—patient 

reminders. Enable a user to 

electronically create a patient reminder 

list for preventive or follow-up care 

according to patient preferences based 

on, at a minimum, the data elements 

included in: 

(i) Problem list; 

(ii) Medication list; 

(iii) Medication allergy list; 

(iv) Demographics; and 

(v) Laboratory tests and 

values/results. 

(16) Patient-specific education 

resources. Enable a user to 

electronically identify and provide 

patient-specific education resources 

according to: 

(i) At a minimum, each one of the 

data elements included in the patient’s: 

problem list; medication list; and 

laboratory tests and values/results; and 

(ii) The standard specified at 

§ 170.204(b)(1). 

(17) Inpatient setting only—electronic 

medication administration record. 

(i) In combination with an assistive 

technology that provides automated 

information on the ‘‘rights’’ specified in 

paragraphs (a)(17)(i)(A) through (D) of 

this section, enable a user to 

electronically verify the following 

before administering medication(s): 

(A) Right patient. The patient to 

whom the medication is to be 

administered matches the medication to 

be administered. 

(B) Right medication. The medication 

to be administered matches the 

medication ordered for the patient. 

(C) Right dose. The dose of the 

medication to be administered matches 

the dose of the medication ordered for 

the patient. 

(D) Right route. The route of 

medication delivery matches the route 

specified in the medication order. 

(ii) Right time. Electronically record 

the time and date in accordance with 

the standard specified in § 170.210(g), 

and user identification when a 

medication is administered. 

(18) Inpatient setting only—advance 

directives. Enable a user to 

electronically record whether a patient 

has an advance directive. 

(b) Care coordination. 

(1) Transitions of care—incorporate 

summary care record. Upon receipt of a 

summary care record formatted 

according to the standard adopted at 

§ 170.205(a)(3), electronically 

incorporate, at a minimum, the 

following data elements: Patient name; 

gender; race; ethnicity; preferred 

language; date of birth; smoking status; 

vital signs; medications; medication 

allergies; problems; procedures; 

laboratory tests and values/results; the 

referring or transitioning provider’s 

name and contact information; hospital 

admission and discharge dates and 

locations; discharge instructions; 

reason(s) for hospitalization; care plan, 

including goals and instructions; names 

of providers of care during 

hospitalizations; and names and contact 

information of any additional known 

care team members beyond the referring 

or transitioning provider and the 

receiving provider. 

(2) Transitions of care—create and 

transmit summary care record. 

(i) Enable a user to electronically 

create a summary care record formatted 

according to the standard adopted at 

§ 170.205(a)(3) and that includes, at a 

minimum, the following data elements 

expressed, where applicable, according 

to the specified standard(s): 

(A) Patient name; gender; date of 

birth; medication allergies; vital signs; 

laboratory tests and values/results; the 

referring or transitioning provider’s 

name and contact information; names 

and contact information of any 

additional care team members beyond 

the referring or transitioning provider 

and the receiving provider; care plan, 

including goals and instructions; 

(B) Race and ethnicity. The standard 

specified in § 170.207(f); 

(C) Preferred language. The standard 

specified in § 170.207(j); 

(D) Smoking status. The standard 

specified in § 170.207(1); 

(E) Problems. At a minimum, the 

version of the standard specified in 

§ 170.207(a)(3); 

(F) Encounter diagnoses. The standard 

specified in § 170.207(m); 

(G) Procedures. The standard 

specified in § 170.207(b)(2) or 

§ 170.207(b)(3); 

(H) Laboratory test(s). At a minimum, 

the version of the standard specified in 

§ 170.207(g); 

(I) Laboratory value(s)/result(s). The 

value(s)/results of the laboratory test(s) 

performed; 

(J) Medications. At a minimum, the 

version of the standard specified in 

§ 170.207(h); and 

(K) Inpatient setting only. Hospital 

admission and discharge dates and 

location; names of providers of care 

during hospitalizations; discharge 

instructions; and reason(s) for 

hospitalization. 

(ii) Transmit. Enable a user to 

electronically transmit the summary 

care record created in paragraph (b)(2)(i) 

of this section in accordance with: 

(A) The standards specified in 

§ 170.202(a)(1) and (2). 

(B) Optional. The standard specified 

in § 170.202(a)(3). 

(3) Electronic prescribing. Enable a 

user to electronically create 

prescriptions and prescription-related 

information for electronic transmission 

in accordance with: 

(i) The standard specified in 

§ 170.205(b)(2); and 

(ii) At a minimum, the version of the 

standard specified in § 170.207(h). 

(4) Clinical information 

reconciliation. Enable a user to 

electronically reconcile the data 

elements that represent a patient’s 

active medication, problem, and 

medication allergy list as follows. For 

each list type: 

(i) Electronically display the data 

elements from two or more sources in a 

manner that allows a user to view the 

data elements and their attributes, 

which must include, at a minimum, the 

source and last modification date. 

(ii) Enable a user to merge and remove 

individual data elements. 

(iii) 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 

list. 

(5) Incorporate laboratory tests and 

values/results. 

(i) Receive results. 

(A) Ambulatory setting only. 

(1) Electronically receive clinical 

laboratory tests and values/results in 

accordance with the standard (and 

applicable implementation 

specifications) specified in § 170.205(k) 

and, at a minimum, the version of the 

standard specified in § 170.207(g). 

(2) Electronically display the tests and 

values/results received in human 

readable format. 

(B) Inpatient setting only. 

Electronically receive clinical laboratory 

tests and values/results in a structured 

format and electronically display such 

tests and values/results in human 

readable format. 

(ii) Display test report information. 

Electronically display all the 

information for a test report specified at 

42 CFR 493.1291(c)(1) through (7). 

(iii) Incorporate tests and values/ 

results. Electronically incorporate a 

laboratory test and value/result with a 

laboratory order or patient record. 

(6) Inpatient setting only— 

transmission of electronic laboratory 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13883 

tests and values/results to ambulatory 

providers. Enable a user to 

electronically create laboratory tests and 

values/results for electronic 

transmission in accordance with: 

(i) The standard (and applicable 

implementation specifications) 

specified in § 170.205(k); and 

(ii) At a minimum, the version of the 

standard specified in § 170.207(g). 

(c) Clinical quality measures. 

(1) Clinical quality measures— 

capture and export. 

(i) Capture. Electronically record all 

of the data elements that are represented 

in the standard specified in § 170.204(c). 

(ii) Export. Electronically export a 

data file that includes all of the data 

elements that are represented in the 

standard specified in § 170.204(c). 

(2) Clinical quality measures— 

incorporate and calculate. 

(i) Incorporate. Electronically 

incorporate all of the data elements 

necessary to calculate each of the 

clinical quality measures that are 

included in the EHR technology. 

(ii) Calculate. Electronically calculate 

each clinical quality measure that is 

included in the EHR technology. 

(3) Clinical quality measures— 

reporting. Enable a user to electronically 

create for transmission clinical quality 

measurement results in a data file 

defined by CMS. 

(d) Privacy and security. 

(1) Authentication, access control, 

and authorization. 

(i) Verify against a unique identifier(s) 

(e.g., username or number) that a person 

seeking access to electronic health 

information is the one claimed; and 

(ii) Establish the type of access to 

electronic health information a user is 

permitted based on the unique 

identifier(s) provided in paragraph 

(d)(1)(i) of this section, and the actions 

the user is permitted to perform with 

the EHR technology. 

(2) Auditable events and tamperresistance. 

(i) Enabled by default. The capability 

specified in paragraph (d)(2)(ii) of this 

section must be enabled by default (i.e., 

turned on) and must only be permitted 

to be disabled (and re-enabled) by a 

limited set of identified users. 

(ii) Record actions. Record actions 

related to electronic health information, 

audit log status and, as applicable, 

encryption of end-user devices in 

accordance with the standard specified 

in § 170.210(e). 

(iii) Audit log protection. Actions 

recorded in accordance with paragraph 

(d)(2)(ii) must not be capable of being 

changed, overwritten, or deleted. 

(iv) Detection. Detect the alteration of 

audit logs. 

(3) Audit report(s). 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 standard at § 170.210(e). 

(4) Amendments. 

(i) Enable a user to electronically 

amend a patient’s health record to: 

(A) Replace existing information in a 

way that preserves the original 

information; and 

(B) Append patient supplied 

information, in free text or scanned, 

directly to a patient’s health record or 

by embedding an electronic link to the 

location of the content of the 

amendment. 

(ii) Enable a user to electronically 

append a response to patient supplied 

information in a patient’s health record. 

(5) Automatic log-off. Terminate an 

electronic session after a predetermined 

time of inactivity. 

(6) Emergency access. Permit an 

identified set of users to access 

electronic health information during an 

emergency. 

(7) Encryption of data at rest. 

Paragraph (d)(7)(i) or (ii) of this section 

must be met to satisfy this certification 

criterion. 

(i) If EHR technology manages 

electronic health information on an enduser device and the electronic health 

information remains stored on the 

device after use of the EHR technology 

on that device has stopped, the 

electronic health information must be 

encrypted in accordance with the 

standard specified in § 170.210(a)(1). 

This capability must be enabled by 

default (i.e., turned on) and must only 

be permitted to be disabled (and reenabled) by a limited set of identified 

users. 

(ii) Electronic health information 

managed by EHR technology never 

remains stored on end-user devices after 

use of the EHR technology on those 

devices has stopped. 

(8) Integrity. 

(i) Create a message digest in 

accordance with the standard specified 

in § 170.210(c). 

(ii) Verify in accordance with the 

standard specified in § 170.210(c) upon 

receipt of electronically exchanged 

health information that such 

information has not been altered. 

(9) Optional—accounting of 

disclosures. Record disclosures made for 

treatment, payment, and health care 

operations in accordance with the 

standard specified in § 170.210(d). 

(e) Patient engagement. 

(1) View, download, and transmit to 

3rd party. 

(i) Enable a user to provide patients 

(and their authorized representatives) 

with online access to do all of the 

following: 

(A) View. Electronically view in 

accordance with the standard adopted at 

§ 170.204(a), at a minimum, the 

following data elements: 

(1) Patient name; gender; date of birth; 

race; ethnicity; preferred language; 

smoking status; problem list; medication 

list; medication allergy list; procedures; 

vital signs; laboratory tests and values/ 

results; provider’s name and contact 

information; names and contact 

information of any additional care team 

members beyond the referring or 

transitioning provider and the receiving 

provider; and care plan, including goals 

and instructions. 

(2) Inpatient setting only. Admission 

and discharge dates and locations; 

reason(s) for hospitalization; names of 

providers of care during hospitalization; 

laboratory tests and values/results 

(available at time of discharge); and 

discharge instructions for patient. 

(B) Download. Electronically 

download: 

(1) A file in human readable format 

that includes, at a minimum: 

(i) Ambulatory setting only. All of the 

data elements specified in paragraph 

(e)(1)(i)(A)(1) of this section. 

(ii) Inpatient setting only. All of the 

data elements specified in paragraphs 

(e)(1)(i)(A)(1) and (2) of this section. 

(2) A summary care record formatted 

according to the standards adopted at 

§ 170.205(a)(3) and that includes, at a 

minimum, the following data elements 

expressed, where applicable, according 

to the specified standard(s): 

(i) Patient name; gender; date of birth; 

medication allergies; vital signs; the 

provider’s name and contact 

information; names and contact 

information of any additional care team 

members beyond the referring or 

transitioning provider and the receiving 

provider; care plan, including goals and 

instructions; 

(ii) Race and ethnicity. The standard 

specified in § 170.207(f); 

(iii) Preferred language. The standard 

specified in § 170.207(j); 

(iv) Smoking status. The standard 

specified in § 170.207(l); 

(v) Problems. At a minimum, the 

version of the standard specified in 

§ 170.207(a)(3); 

(vi) Encounter diagnoses. The 

standard specified in § 170.207(m); 

(vii) Procedures. The standard 

specified in § 170.207(b)(2) or 

§ 170.207(b)(3); 

(viii) Laboratory test(s). At a 

minimum, the version of the standard 

specified in § 170.207(g); 

(ix) Laboratory value(s)/result(s). The 

value(s)/results of the laboratory test(s) 

performed; 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
13884 Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 

(x) Medications. At a minimum, the 

version of the standard specified in 

§ 170.207(h); and 

(xi) Inpatient setting only. The data 

elements specified in paragraph 

(e)(1)(i)(A)(2) of this section. 

(3) Images formatted according to the 

standard adopted at § 170.205(j). 

(C) Transmit to third party. 

Electronically transmit the summary 

care record created in paragraph 

(e)(1)(i)(B)(2) of this section and images 

available to download in paragraph 

(e)(1)(i)(B)(3) of this section in 

accordance with: 

(1) The standard specified in 

§ 170.202(a)(1); and 

(2) The standard specified in 

§ 170.202(a)(2). 

(ii) Patient accessible log. 

(A) When electronic health 

information is viewed, downloaded, or 

transmitted to a third-party using the 

capabilities included in paragraphs 

(e)(1)(i)(A) through (C) of this section, 

the following information must be 

recorded and made accessible to the 

patient: 

(1) The electronic health information 

affected by the action(s); 

(2) The date and time each action 

occurs in accordance with the standard 

specified at § 170.210(g); 

(3) The action(s) that occurred; and 

(4) User identification. 

(B) EHR technology presented for 

certification may demonstrate 

compliance with paragraph (e)(1)(ii)(A) 

of this section if it is also certified to the 

certification criterion adopted at 

§ 170.314(d)(2) and the information 

required to be recorded in paragraph 

(e)(1)(ii)(A) is accessible by the patient. 

(2) Ambulatory setting only—clinical 

summaries. Enable a user to provide 

clinical summaries to patients for each 

office visit that include, at a minimum, 

the following data elements: Provider’s 

name and office contact information; 

date and location of visit; reason for 

visit; patient’s name; gender; race; 

ethnicity; date of birth; preferred 

language; smoking status; vital signs and 

any updates; problem list and any 

updates; medication list and any 

updates; medication allergy list and any 

updates; immunizations and/or 

medications administered during the 

visit; procedures performed during the 

visit; laboratory tests and values/results, 

including any tests and value/results 

pending; clinical instructions; care plan, 

including goals and instructions; 

recommended patient decision aids (if 

applicable to the visit); future scheduled 

tests; future appointments; and referrals 

to other providers. If the clinical 

summary is provided electronically, it 

must be: 

(i) Provided in human readable 

format; and 

(ii) Provided in a summary care 

record formatted according to the 

standard adopted at § 170.205(a)(3) with 

the following data elements expressed, 

where applicable, according to the 

specified standard(s): 

(A) Race and ethnicity. The standard 

specified in § 170.207(f); 

(B) Preferred language. The standard 

specified in § 170.207(j); 

(C) Smoking status. The standard 

specified in § 170.207(l); 

(D) Problems. At a minimum, the 

version of the standard specified in 

§ 170.207(a)(3); 

(E) Encounter diagnoses. The 

standard specified in § 170.207(m); 

(F) Procedures. The standard 

specified in § 170.207(b)(2) or 

§ 170.207(b)(3); 

(G) Laboratory test(s). At a minimum, 

the version of the standard specified in 

§ 170.207(g); 

(H) Laboratory value(s)/result(s). The 

value(s)/results of the laboratory test(s) 

performed; and 

(I) Medications. At a minimum, the 

version of the standard specified in 

§ 170.207(h). 

(3) Ambulatory setting only—secure 

messaging. Enable a user to 

electronically send messages to, and 

receive messages from, a patient in a 

manner that ensures: 

(i) Both the patient and EHR 

technology are authenticated; and 

(ii) The message content is encrypted 

and integrity-protected in accordance 

with the standard for encryption and 

hashing algorithms specified at 

§ 170.210(f). 

(f) Public health. 

(1) Immunization information. Enable 

a user to electronically record, change, 

and access immunization information. 

(2) Transmission to immunization 

registries. Enable a user to electronically 

create immunization information for 

electronic transmission in accordance 

with: 

(i) The standard and applicable 

implementation specifications specified 

in § 170.205(e)(3); and 

(ii) At a minimum, the version of the 

standard specified in § 170.207(i). 

(3) Public health surveillance. Enable 

a user to electronically record, change, 

and access syndrome-based public 

health surveillance information. 

(4) Transmission to public health 

agencies. Enable a user to electronically 

create syndrome-based public health 

surveillance information for electronic 

transmission in accordance with: 

(i) Ambulatory setting only. 

(A) The standard specified in 

§ 170.205(d)(2). 

(B) Optional. The standard (and 

applicable implementation 

specifications) specified in 

§ 170.205(d)(3). 

(ii) Inpatient setting only. The 

standard (and applicable 

implementation specifications) 

specified in § 170.205(d)(3). 

(5) Inpatient setting only—reportable 

laboratory tests and values/results. 

Enable a user to electronically record, 

change, and access reportable clinical 

laboratory tests and values/results. 

(6) Inpatient setting only— 

transmission of reportable laboratory 

tests and values/results. Enable a user to 

electronically create reportable 

laboratory tests and values/results for 

electronic transmission in accordance 

with: 

(i) The standard (and applicable 

implementation specifications) 

specified in § 170.205(g); and 

(ii) At a minimum, the versions of the 

standards specified in § 170.207(a)(3) 

and (g). 

(7) Ambulatory setting only—cancer 

case information. Enable a user to 

electronically record, change, and 

access cancer case information. 

(8) Ambulatory setting only— 

transmission to cancer registries. Enable 

a user to electronically create cancer 

case information for electronic 

transmission in accordance with: 

(i) The standard (and applicable 

implementation specifications) 

specified in § 170.205(i); and 

(ii) At a minimum, the versions of the 

standards specified in § 170.207(a)(3) 

and (g). 

(g) Utilization. 

(1) Automated numerator recording. 

For each meaningful use objective with 

a percentage-based measure, 

electronically record the numerator. 

(2) Automated measure calculation. 

For each meaningful use objective with 

a percentage-based measure that is 

supported by a capability included in an 

EHR technology, electronically record 

the numerator and denominator and 

create a report including the numerator, 

denominator, and resulting percentage 

associated with each applicable 

meaningful use measure. 

(3) Non-percentage-based measure 

use report. 

(i) For each capability included in 

EHR technology that is also associated 

with a meaningful use objective and 

measure that is not percentage based, 

electronically record the date and time 

in accordance with the standard 

specified at § 170.210(g) when the 

capability was enabled, disabled, and/or 

executed. 

(ii) Enable a user to electronically 

create a report of the information 


tkelley on DSK3SPTVN1PROD with PROPOSALS3
Federal Register / Vol. 77, No. 45 / Wednesday, March 7, 2012 / Proposed Rules 13885 

recorded as part of paragraph (g)(3)(i) of 

this section. 

(4) Safety-enhanced design. Usercentered design processes must be 

applied to each capability an EHR 

technology includes that is specified in 

the following certification criteria: 

§ 170.314(a)(1); § 170.314(a)(2); 

§ 170.314(a)(6); § 170.314(a)(7); 

§ 170.314(a)(8); § 170.314(a)(17); 

§ 170.314(b)(3); and § 170.314(b)(4). 

§§ 170.500 through 170.599 [Amended] 

10. 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. 

11. Amend § 170.502 by revising the 

definition of ‘‘providing or provide an 

updated certification’’ to read as 

follows: 

§ 170.502 Definitions. 

* * * * * 

Providing or provide an updated 

certification means 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 are applicable to the EHR 

Module(s). 

* * * * * 

12. In § 170.523, republish the 

introductory text, add paragraph (f)(8), 

and revise paragraph (k)(1)(i) to read as 

follows: 

§ 170.523 Principles of proper conduct for 

ONC–ACBs. 

An ONC–ACB shall: 

* * * * * 

(f) * * * 

(8) A hyperlink to the test results used 

to certify the Complete EHRs and/or 

EHR Modules that can be accessed by 

the public. 

* * * * * 

(k) * * * 

(1) * * * 

(i) ‘‘This [Complete EHR or EHR 

Module] is [specify Edition of EHR 

certification criteria] compliant and has 

been certified by an ONC–ACB in 

accordance with the applicable 

certification criteria adopted by the 

Secretary of Health and Human 

Services. This certification does not 

represent an endorsement by the U.S. 

Department of Health and Human 

Services.’’; and 

* * * * * 

13. In § 170.550, revise paragraph (e), 

redesignate paragraph (f) as paragraph 

(g), and add a new paragraph (f) to read 

as follows: 

§ 170.550 EHR Module certification. 

* * * * * 

(e) Privacy and security certification. 

For certification to the 2011 Edition 

EHR certification criteria, EHR 

Module(s) shall be certified to all 

privacy and security certification 

criteria adopted by the Secretary, unless 

the EHR Module(s) is presented for 

certification in one of the following 

manners: 

(1) The EHR Modules are presented 

for certification as a pre-coordinated, 

integrated bundle of EHR Modules, 

which would otherwise meet the 

definition of and constitute a Complete 

EHR, and one or more of the constituent 

EHR Modules is demonstrably 

responsible for providing all of the 

privacy and security capabilities for the 

entire bundle of EHR Modules; or 

(2) An EHR Module is presented for 

certification, and the presenter can 

demonstrate and provide 

documentation to the ONC–ACB that a 

privacy and security certification 

criterion is inapplicable or that it would 

be technically infeasible for the EHR 

Module to be certified in accordance 

with such certification criterion. 

(f) When certifying an EHR Module to 

the 2014 Edition EHR certification 

criteria, an ONC–ACB must certify the 

EHR Module in accordance with the 

certification criteria at: 

(1) Section 170.314(g)(1) if the EHR 

Module has capabilities presented for 

certification that would support a 

meaningful use objective with a 

percentage-based measure; 

(2) Section 170.314(g)(3) if the EHR 

Module has capabilities presented for 

certification that would support a 

meaningful use objective with a nonpercentage-based measure; and 

(3) Section 170.314(g)(4) if the EHR 

Module is presented for certification to 

one or more listed certification criteria 

in § 170.314(g)(4). 

* * * * * 

14. Revise § 170.555 to read as 

follows: 

§ 170.555 Certification to newer versions 

of certain standards. 

(a) ONC–ACBs may certify Complete 

EHRs and/or EHR Module(s) to a newer 

version of certain identified minimum 

standards specified at subpart B of this 

part, unless the Secretary prohibits the 

use of a newer version for certification. 

(b) Applicability of a newer version of 

a minimum standard. (1) ONC–ACBs 

are not required to certify Complete 

EHRs and/or EHR Module(s) according 

to newer versions of standards 

identified as minimum standards in 

subpart B of this part, unless and until 

the incorporation by reference of a 

standard is updated in the Federal 

Register with a newer version. 

(2) A certified Complete EHR or 

certified EHR Module may be upgraded 

to comply with newer versions of 

standards identified as minimum 

standards in subpart B of this part 

without adversely affecting its 

certification status, unless the Secretary 

prohibits the use of a newer version for 

certification. 

Dated: February 21, 2012. 

Kathleen Sebelius, 

Secretary. 

[FR Doc. 2012–4430 Filed 2–24–12; 4:15 pm] 

BILLING CODE 4150–45–P 


tkelley on DSK3SPTVN1PROD with PROPOSALS3