Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements

Federal RegisterFeb 26, 2014

Ask Donna

What actually matters in this document.

Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB92

Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements

AGENCY:

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

ACTION:

Notice of proposed rulemaking with comment period.

SUMMARY:

This notice of proposed rulemaking introduces the beginning of the Office of National Coordinator for Health Information Technology's (ONC's) more frequent approach to health information technology certification regulations. Under this approach ONC intends to update certification criteria editions every 12 to 18 months in order to provide smaller, more incremental regulatory changes and policy proposals. This approach gives stakeholders greater and earlier visibility into our regulatory direction before compliance is required, provides more time for public input on policy proposals under consideration for future rulemakings, and enables our certification processes to more quickly adopt newer industry standards that can enhance interoperability.

The 2015 Edition EHR certification criteria proposed in this rule would be voluntary.

EHR technology developer who has certified its EHR technology to the 2014 Edition would need to recertify to the 2015 Edition in order for its customers to participate in the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs). Furthermore, eligible professionals, eligible hospitals, and critical access hospitals that participate in the EHR Incentive Programs

would not

need to “upgrade” to EHR technology certified to 2015 Edition in order to have EHR technology that meets the Certified EHR Technology (CEHRT) definition. Instead, the 2015 Edition EHR certification criteria would accomplish three policy objectives: 1) They would enable a more efficient and effective response to stakeholder feedback; 2) they would incorporate “bug fixes” to improve on 2014 Edition EHR certification criteria in ways designed to make our rules clearer and easier to implement; and 3) they reference newer standards and implementation specifications that reflect our commitment to promoting innovation and enhancing interoperability.

Specific revisions to the ONC HIT Certification Program are also included in this proposed rule. These proposals focus on: Improving regulatory clarity; simplifying the certification of EHR Modules that are designed for purposes other than achieving meaningful use; and discontinuing the use of the Complete EHR definition starting with the 2015 Edition.

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 April 28, 2014.

ADDRESSES:

You may submit comments, identified by RIN 0991-AB92, 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: 2015 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: 2015 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, 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. Roughly 30% of the public comments submitted to our 2014 Edition notice of proposed rulemaking used the provided template, which greatly assisted in our ability to rapidly process and more accurately categorize public comments. 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://www.healthit.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

CDC Centers for Disease Control and Prevention

CDS Clinical Decision Support

CEHRT Certified Electronic Health Record Technology

CFR Code of Federal Regulations

CHPL Certified Health Information Technology Product List

CLIA Clinical Laboratory Improvement Amendments

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

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

IG Implementation Guide

IHE Integrating the Healthcare Enterprise®

LOINC® Logical Observation Identifiers Names and Codes

MU Meaningful Use

OMB Office of Management and Budget

ONC Office of the National Coordinator for 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

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Major Provisions

1. Overview of the 2015 Edition EHR Certification Criteria

2. 2017 Edition Rulemaking

3. ONC HIT Certification Program

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. HIT Certification Programs

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

2. Medicare and Medicaid EHR Incentive Programs Rules

3. ONC HIT Certification Programs Rules

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

A. 2015 Edition EHR Certification Criteria

B. 2014 Edition to 2015 Edition Equivalency Table

C. Gap Certification Eligibility Table for 2015 Edition EHR Certification Criteria

D. HIT Definitions

1. CEHRT and Base EHR Definitions

2. Complete EHR

3. Common MU Data Set

4. Cross-Referenced FDA Definitions

IV. Provisions of the Proposed Rule Affecting the ONC HIT Certification Program

A. Applicability

B. Non-MU EHR Technology Certification

C. ONC Regulations FAQ 28

1. MU EHR Modules

2. Complete EHRs

D. Patient List Creation Certification Criteria

E. ISO/IEC 17065

F. ONC Certification Mark

G. “Certification Packages” for EHR Modules

V. Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking

A. Additional Patient Data Collection

B. Medication Allergy Coding

C. Certification Policy for EHR Modules and Privacy and Security Certification Criteria

D. Provider Directories

E. Oral Liquid Medication Dosing

F. Medication History

G. Blue Button +

H. 2D Barcoding

I. Duplicate Patient Records

J. Disaster Preparedness

K. Certification of Other Types of HIT and for Specific Types of Health Care Settings

1. Other Types of HIT

2. Specific Types of Health Care Settings

VI. Removal of the 2011 Edition EHR Certification Criteria and Related Standards, Terms, and Requirements and the Temporary Certification Program

A. 2011 Edition EHR Certification Criteria

B. Temporary Certification Program

VII. Response to Comments

VIII. Collection of Information Requirements

IX. Regulatory Impact Statement

A. Statement of Need

B. Overall Impact

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

2. Regulatory Flexibility Act

3. Executive Order 13132—Federalism

4. Unfunded Mandates Reform Act of 1995

C. Request for Comments on 2017 Impact Analysis Methods

I. Executive Summary

A. Purpose of Regulatory Action

On December 6, 2013, CMS announced its intention

to pursue rulemaking to modify the start date of meaningful use (MU) Stage 3 for some eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs). As part of this announcement, CMS and ONC also expressed an expectation that our joint rulemaking processes to establish Stage 3 policy and supporting EHR certification criteria would result in published proposed rules in late fall 2014. Given the new (and later than originally planned) regulatory timeline, we (ONC) determined that initiating a more frequent rulemaking approach for the adoption of certification criteria would provide an opportunity to respond to stakeholder concerns regarding our prior rulemakings. Along these lines, we believe a more frequent rulemaking approach would help address both the amount of time that it takes to publish updates to our certification regulations and the corresponding impact that the infrequent, long-cycle approach has had on EHR technology development and deployment.

http://www.cms.gov/eHealth/ListServ_Stage3Implementation.html

In the past, ONC has issued certification (program and criteria) regulations solely to support the EHR Incentive Programs. As a result, we have gained five years of process experience and stakeholder feedback. We have learned that as health information technology (HIT or health IT) continues to evolve, a two to three-year regulatory cycle is sub-optimal. Moreover, because these rulemakings have been less frequent, our regulations have had to take into account one to two years' worth of industry effort prior to the rulemaking and established policy that anticipates industry readiness one to two years post-rulemaking. This approach has created cycles of significant peaks and valleys from a health IT development standpoint; resulted in missed opportunities to improve interoperability and programmatic alignment because of mismatched regulatory and standards balloting cycle timelines; and adversely affected EHR technology developers' ability to strategically plan their development and product rollout processes due to uncertain regulatory timelines.

To address these challenges, we believe that a more incremental, frequent, and scheduled approach to publishing proposed and final rules (that is, every 12 to 18 months) would benefit the industry. We anticipate, similar to this 2015 Edition rulemaking, that some of these incremental rules would be voluntary in an effort to intentionally give EHR technology developers more time to plan, develop, and implement updated EHR technology for their customers. Overall,

we believe this approach will enable ONC to:

(A) Adapt our regulations to more effectively and efficiently respond to stakeholder feedback and to support HHS healthcare delivery reform and transformation programs that may seek to leverage health IT certification;

(B) Better our regulations by making “bug fixes” and other regulatory improvements as part of a more frequent rulemaking cycle;

(C) Chart a course toward enhanced interoperability, information exchange, quality improvement, patient engagement, and patient safety that gives health IT developers more ability to predict ONC's potential next steps; and

(D) Deliver smaller, incremental regulatory requirements that are easier to integrate into software development cycles.

The 2015 Edition rulemaking begins ONC's new regulatory approach. The proposals for the 2015 Edition in this proposed rule improve on the 2014 Edition EHR certification criteria in numerous ways. Moreover, the proposed 2015 Edition EHR certification criteria would be voluntary. In other words,

EHR technology developer who has certified its EHR technology to the 2014 Edition would need to recertify to the 2015 Edition in order for its customers to participate in the EHR Incentive Programs. Correspondingly, eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) that participate in the EHR Incentive Programs

would not

need to “upgrade” to EHR technology certified to 2015 Edition in order to have EHR technology that meets the Certified EHR Technology definition nor to standards or implementation specifications included in the 2015 Edition.

As a result, EHR technology developers and EPs, EHs, and CAHs would have the opportunity to move ahead to the 2015 Edition at their own pace and on their own terms.

Proposed new capabilities, standards-based requirements, and public comment solicitations on potential future certification criteria also provide EHR technology developers with advance visibility and time to react to the potential requirements ONC is considering for our next planned rulemaking—the 2017 Edition certification criteria (which would be proposed to support meaningful use Stage 3 proposals).

We believe the benefits of moving to the 2015 Edition for EHR technology developers and EPs, EHs, and CAHs would be three-fold:

(1) The 2015 Edition EHR certification criteria (as proposed) include updated capabilities, standards, and implementation guides (IGs) designed to enhance interoperability;

(2) Certain certification criteria changes in the 2015 Edition (as compared to the 2014 Edition and discussed in greater detail later) are designed to spur innovation, open new market opportunities, and provide more choices to EPs, EHs, and CAHs when it comes to electronic health information exchange.

(3) EHR technology developers would be able to implement regulatory updates earlier than if we would have otherwise waited another year to propose them under the new rulemaking timeline for the 2017 Edition/MU Stage 3. Along those lines, EHR technology developers that seek 2015 Edition certifications for some or all capabilities may be able to seek “gap certification” for those capabilities if they remain unchanged as part of the eventual 2017 Edition. Thus, EHR technology developer resources and time investments could be more spread out and lead to greater efficiency and time saved through the certification process later on. We note, however, the availability and scope of gap certification for 2015 Edition certified products to the 2017 Edition is contingent both on the outcome of the 2017 Edition rulemaking and the discretion of ONC-ACBs. For further explanation and discussion of gap certification, please see section III.C. “Gap Certification Eligibility Table for 2015 Edition EHR Certification Criteria” of the preamble.

B. Summary of Major Provisions

1. Overview of the 2015 Edition EHR Certification Criteria

The proposed 2015 Edition EHR certification criteria include many improvements over the 2014 Edition EHR certification criteria (

note:

hereafter, all certification criteria editions will simply be referred to by the edition year (e.g., 2015 Edition). Yet, they do not entirely overhaul the full suite of certification criteria. From a 2014 Edition perspective, we are proposing to adopt roughly 60% of the 2014 Edition EHR certification criteria without change as part of the 2015 Edition. The remaining certification criteria proposals for the 2015 Edition generally fall into four general categories:

(1)

Clarifying revisions

—consisting of clarifying regulatory text revisions. These include updating a certification criterion to reflect guidance in an already-issued frequently asked question (FAQ);

(2)

Standards updates

—to have a certification criterion reference a new standard or IG that has been published since the Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology final rule (“2014 Edition Final Rule”) was published in September 2012 (77 FR 54163 Sept. 4, 2012).

In these instances, we have considered the proposed standards consistent with the requirements of the National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et. seq.) and the Office of Management and Budget (OMB) Circular A-119,

to use, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. In this proposed rule, we have proposed to adopt or refer to voluntary consensus standards, except for the following government-unique standards: The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity; the transport standards proposed in § 170.202; the standard that identifies the data elements referenced by clinical quality measures (§ 170.204(c)); and certain standards related to the protection of electronic health information identified in § 170.210. We are aware of no voluntary consensus standards that would serve as alternatives to these standards for the purposes that we have identified;

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

(3)

Restructuring

—to make the certification criteria clearer and to improve market opportunities for diverse stakeholders to get EHR technology certified.

(4)

New certification criteria proposals

—consisting of a few new certification criteria that represent new functionality when compared to the 2014 Edition as well as some new certification criteria that are the result of splitting certain 2014 Edition certification criteria.

2. 2017 Edition Rulemaking

To give the industry advance notice of potential proposals under consideration for future certification criteria editions and regulations (e.g., 2017 Edition), we solicit public comment on revisions we are considering to many existing certification criteria. That is, certification criteria that have been adopted as part of the 2014 Edition and proposed as part of the 2015 Edition. We include a separate preamble section that discusses and requests public comments on potential functionality and requirements for the 2017 Edition (“V. Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking”). However, please note that although we will consider the comments we receive on these issues as we develop proposals for future rulemaking, we do not plan to respond to those comments in the final rule for the 2015 Edition that we expect will follow this proposed rule.

3. ONC HIT Certification Program

We propose several modifications to the ONC HIT Certification Program's policies. We also solicit public comment on several important future program policy issues we intend to consider for our 2017 Edition rulemaking. We are proposing to simplify the certification of EHR Modules that are designed for purposes other than achieving meaningful use and to discontinue the “Complete EHR” certification concept, which would begin with the 2015 Edition. Every additional ONC HIT Certification Program proposal we have included focuses on clarifying regulatory text, updating existing program polices, and providing clarity for the market as it relates to EHR technology certified under the program.

C. Costs and Benefits

Our estimates indicate that this proposed rule is not an economically significant rule as its overall costs would be less than $100 million in any one 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 to be tested and certified in accordance with the 2015 Edition EHR certification criteria (and the standards and implementation specifications they include) are represented in monetary terms in Table 1 below. Because the 2015 Edition is not the baseline certification criteria edition required by the CEHRT definition (as the 2014 Edition is), and because we expect our next rulemaking to adopt a 2017 Edition would commence in late calendar year 2014 and conclude in 2015, we do not believe that a large number of EHR technology developers would seek to be tested and certified to the 2015 Edition. We estimate that development and preparation efforts to the 2015 Edition would be split evenly over calendar years 2014 and 2015 and would be confined to these years because, as noted, we expect to issue a 2017 Edition final rule in 2015 and expect that the majority of EHR development and preparation efforts at that time would shift towards meeting the 2017 Edition. The dollar amounts expressed in Table 1 are expressed in 2014 dollars.

While we do not expect a majority of EHR technology developers to seek testing and certification to the 2015 Edition, it would still provide several significant benefits to patients, health care providers, and EHR technology developers. Our proposals incorporate stakeholder feedback on particular 2014 Edition issues identified as unnecessarily impeding innovation. Our proposed revisions also seek to continue to improve EHR technology's interoperability through the adoption of updated standards and implementation specifications. Furthermore, our proposal to separate the “content” and “transport” capabilities in the 2015 Edition “transitions of care” certification criterion (compared to the 2014 Edition version of that certification criterion) is aimed at significantly improving the market availability of electronic health information exchange services. Our proposed 2015 Edition “view, download, transmit to 3rd party” certification criterion includes a greater focus on enabling a patient to choose where they want to send their health information. We believe these proposed revisions would open new market opportunities for EPs, EHs, and CAHs to select best of breed products as well as reduce EHR technology developer burdens related to certification. Our proposals and requests for comment in this proposed rule also signal to the industry the future direction we hope to go in with our certification criteria and certification program. This advanced visibility can better assist EHR technology developers plan for the future.

Table 1—Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)—Totals Rounded

Year

Ratio

(percent)

Total low cost estimate

($M)

Total high cost estimate

($M)

Total average cost estimate

($M)

2014

9.82

46.63

28.23

2015

9.82

46.63

28.23

2-Year Totals

19.65

93.26

56.46

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 Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of HIT and electronic health information exchange.

1. Standards, Implementation Specifications, and Certification Criteria

The HITECH Act established two new Federal advisory committees, 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 for Health Information Technology (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. Main

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

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

The Secretary issued an interim final rule with request for comments titled, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014, Jan. 13, 2010) (the “S&CC January 2010 interim final rule”), which adopted an initial set of standards, implementation specifications, and certification criteria. After consideration of the public comments received on the S&CC January 2010 interim final rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for meaningful use (MU) Stage 1 (formally titled: 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) and referred to as the “2011 Edition Final Rule”). The 2011 Edition Final Rule also established the first version of the Certified EHR Technology (CEHRT) definition. Subsequent to the 2011 Edition Final Rule (October 13, 2010), we issued an interim final rule with a request for comment to remove certain implementation specifications related to public health surveillance that had been previously adopted in the 2011 Edition Final Rule (75 FR 62686).

The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2011 Edition 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).

Subsequently, the Secretary issued a notice of proposed rulemaking with request for comments titled “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” (77 FR 13832, March 7, 2012) (the “2014 Edition NPRM”), which proposed new and revised standards, implementation specifications, and certification criteria. After consideration of the public comments received on the 2014 Edition NPRM, a final rule was issued to adopt the 2014 Edition set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for MU Stage 2 as well as MU Stage 1 revisions (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; (77 FR 54163 Sept. 4, 2012) (the “2014 Edition Final Rule”). On December 7, 2012, an interim final rule with a request for comment was jointly issued by ONC and CMS to update certain standards that had been previously adopted in the 2014 Edition final rule, as well as add an alternative measure for MU Stage 2, correct the regulation text, and modify the case number threshold exemption policy for clinical quality measure reporting under the EHR Incentive Program (77 FR 72985).

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

On November 4th, 2013 the Secretary published an interim final rule with a request for comment, 2014 Edition Electronic Health Record Certification

Criteria: Revision to the Definition of “Common Meaningful Use (MU) Data Set” (78 FR 65884), to make a minor revision to the Common MU Data Set definition. This revision was intended to allow more flexibility with respect to the representation of dental procedures data for EHR technology testing and certification.

2. Medicare and Medicaid EHR Incentive Programs Rules

On January 13, 2010, CMS published the EHR Incentive Programs Stage 1 proposed rule (75 FR 1844). The rule proposed the criteria for Stage 1 of MU 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 2011 Edition 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.

On March 7, 2012, CMS published the EHR Incentive Programs Stage 2 proposed rule (77 FR 13698). Subsequently, CMS published a final rule (77 FR 53968) for the EHR Incentive Programs on Sept. 4, 2012, simultaneously with the publication of the 2014 Edition final rule. The EHR Incentive Programs Stage 2 final rule established the objectives, associated measures, and other requirements that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 2 as well as revised MU Stage 1.

As described above in Section II.B.1, ONC and CMS jointly issued an interim final rule with a request for comment on December 7, 2012 (77 FR 72985). The interim final rule updates certain standards that had been previously adopted in the 2014 Edition final rule, adds an alternative measure for MU Stage 2, corrects the regulation text, and modifies the case number threshold exemption policy for clinical quality measure reporting under the EHR Incentive Program.

3. ONC HIT Certification Program Rules

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

On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled “Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes.” The rule proposed a process for addressing instances where the ONC-Approved Accreditor (ONC-AA) engaged in improper conduct or did not perform its responsibilities under the permanent certification program, addressed the status of ONC-Authorized Certification Bodies in instances where there may be a change in the accreditation organization serving as the ONC-AA, and clarified the responsibilities of the new ONC-AA. All these proposals were finalized in a final rule published on November 25, 2011 (76 FR 72636).

The 2014 Edition Final Rule made changes to the permanent certification program. The final rule adopted a proposal to change the Permanent Certification Program's name to the “ONC HIT Certification Program,” revised the process for permitting the use of newer versions of “minimum standard” code sets, modified the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria, and reduced regulatory burden by eliminating the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria.

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

A. 2015 Edition EHR Certification Criteria

General Context

This rule proposes new, revised, and unchanged certification criteria that would establish the technical capabilities and related standards and implementation specifications that could be implemented as part of an EP, EH, or CAH's CEHRT and their demonstration of either MU Stage 1 or MU Stage 2. We refer to these new, revised, and unchanged certification criteria as the “2015 Edition EHR certification criteria” or “2015 Edition” and propose to add this term and its definition to § 170.102. Additionally, we propose to codify the 2015 Edition EHR certification criteria in section 170.315 to set them apart and make it easier for stakeholders to quickly determine the certification criteria the 2015 Edition includes.

We discuss the new, revised, and unchanged certification criteria that we propose to adopt as the 2015 Edition EHR certification criteria below. We specify where the proposed certification criteria would be included in § 170.315. We also propose a substantive revision to the 2014 Edition syndromic surveillance certification criterion adopted at § 170.314(f)(3).

As we have in prior rulemakings, we include a table at the beginning of the discussion of each certification criterion or criteria that specifies the MU objective the proposed 2015 Edition EHR certification criterion or criteria supports. We also indicate in the table whether the criterion is “eligible” or “ineligible” for “gap certification” between the 2014 Edition and 2015 Edition under the ONC HIT Certification Program depending on whether it would be considered “unchanged” between editions. We provide accompanying rationale for the proposed certification criteria, including citing the recommendations of the HITPC and HITSC, where appropriate.

In contrast to our prior rulemakings, we discuss each certification criterion in the chronological order in which it would appear in the Code of Federal Regulations. In other words, the preamble that follows will discuss the proposed certification criteria in § 170.315(a) first, then § 170.315(b), and so on. This approach is designed to improve the preamble's readability and the ease with which commenters can reference back to sections of the proposed rule's preamble when necessary.

We propose, and readers should interpret, that the following terms used in proposed 2015 Edition EHR certification criteria have the same meanings we adopted in the 2014 Edition Final Rule (77 FR 54168-54169), in response to public comment: “user,” “record,” “change,” “access,” “incorporate,” “create,” “transmit.” Similarly, we propose that the scope of a 2015 Edition certification criterion is the same as the scope previously assigned to a 2014 Edition certification criterion (for further explanation, see the discussion at 77 FR 54168). That is,

certification to proposed 2015 Edition EHR certification criteria at § 170.315 would occur at the second paragraph level of the regulatory section and encompass all paragraph levels below the second paragraph level. We also propose to continue to use the same specific descriptions for the different types of “data summaries” established in the 2014 Edition Final Rule (77 FR 54170-54171) for the proposed 2015 Edition EHR certification criteria (i.e., “export summary,” “transition of care/referral summary,” “ambulatory summary,” “inpatient summary,” and “clinical summary.”

Applicability—§ 170.300

Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. We propose to revise paragraph (d) of § 170.300 to add in a reference to § 170.315, which would clarify which specific capabilities within a certification criterion included in § 170.315 have general applicability (i.e., apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting.

•

Computerized Provider Order Entry

Section 3000 of the Public Health Service Act, as added by section 13101 of the HITECH Act, requires that computerized provider order entry (CPOE) capabilities be included in CEHRT. We included CPOE capabilities in the Base EHR definition, which is part of the CEHRT definition, under 45 CFR § 170.102. Within the 2011 and 2014 Editions, we adopted CPOE certification criteria that require EHR technology to be capable of performing CPOE for medication, laboratory, and radiology/imaging orders. Based on stakeholder feedback since the 2014 Edition Final Rule, we understand that this approach can prevent EHR technology developers from creating more efficient, provider-specific “adaptations” of EHR technology that support CPOE.

For example, a mobile adaptation of CPOE currently must include all of the capabilities listed in the 2014 Edition CPOE certification criterion (i.e., the adaptation must be capable of performing CPOE for each of the three types of orders (medication, laboratory and radiology/imaging)) even though the EHR technology developer's customers may only wish to use the mobile adaptation to enter medication orders away from the office.

Please see 77 FR 54267-68 for a discussion of adaptations.

Similarly, we can understand why our approach to CPOE certification can be interpreted by some providers as inconsistent with the flexibility provided in the FY/CY 2014 CEHRT definition under § 170.102. For example, the MU Stage 2 CPOE objective for EPs includes three associated measures (one measure for each of the three types of orders) and exclusions for each of those three measures. An EP who could potentially meet an exclusion for one or two of the measures would still need to possess EHR technology certified to the 2014 Edition CPOE certification criterion (that is, CEHRT that includes CPOE capabilities for each of the three types of orders). Additionally, the MU Stage 1 CPOE objective for EPs does not include measures for laboratory and radiology orders, which means EPs attempting this objective also do not necessarily require these additional certified CPOE capabilities. For these reasons, we propose for the 2015 Edition to split the “computerized provider order entry” certification criterion into three separate certification criteria with each criterion focused on one of the three order types. Certification criteria focused on each order type would permit EHR technology developers to develop order-specific CPOE adaptations and provide EPs, EHs, and CAHs with significantly more implementation flexibility. If an EP expects to meet the MU exclusion for one or two of the MU measures (i.e., writing fewer than 100 of each order type during an EHR reporting period), they could choose to adopt EHR technology certified only to the 2015 Edition CPOE certification criterion for the order types reflected in the measure(s) they expect to demonstrate for MU. This approach would permit an EP to meet the Base EHR definition requirements and CEHRT definition without having to adopt EHR technology that includes certified CPOE capabilities they would not expect to use for MU.

We caution, however, that the additional flexibility that this proposed approach enables also comes with potential risk for EPs who expect to qualify for one or more of the exclusions from the CPOE measures discussed above, but do not ultimately satisfy the exclusion criteria based on the number of orders written during an EHR reporting period. EPs who choose to possess EHR technology that is not certified for each of the three types of orders may risk not having EHR technology that meets the CEHRT definition if they ultimately fail to meet one or more MU exclusions. In most cases, we expect that EPs' scope of practice and the MU measures they need to meet will inform their decision (and corresponding responsibility) to adopt EHR technology certified to the now separately proposed CPOE capabilities. For example, a chiropractor may never or rarely place medication and laboratory orders and, thus, would not necessarily need EHR technology certified to the specific proposed CPOE certification criteria for those order capabilities. Conversely, an EP practicing obstetrics and gynecology may need EHR technology certified for all three CPOE order types. Overall, we emphasize that EHR technology developers need to be aware that this additional certification flexibility and subsequent certification decisions could have corresponding impacts on EPs who are ultimately responsible for ensuring that their EHR technology meets the CEHRT definition.

The 2015 Edition “CPOE” certification criteria omit the “at a minimum” language included in the 2014 Edition and 2011 Edition CPOE certification criteria. This language was included in prior editions to indicate that EHR technology developers could include capabilities that support other types of orders. We believe this language is extraneous because we have consistently maintained that certification criteria (and certification in general) serve as minimum requirements or a baseline. As has always been the case, EHR technology developers may include capabilities in their EHR technology that go beyond all certification requirements.

•

Computerized Provider Order Entry—Medications

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.

2015 Edition EHR Certification Criterion

§ 170.315(a)(1) (Computerized physician order entry—medications).

Gap Certification Status

Eligible.

As discussed above, we propose to adopt a 2015 Edition CPOE certification criterion specific to medication ordering. This proposed criterion is structured substantially similar to the 2014 Edition version, except it does not reference laboratory and radiology/imaging orders.

•

Computerized Provider Order Entry—Laboratory

MU Objective

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

2015 Edition EHR Certification Criterion

§ 170.315(a)(2) (Computerized physician order entry—laboratory).

Gap Certification Status

Ineligible.

The Clinical Laboratory Improvement Amendments (CLIA) of 1988 amended the Public Health Service Act and revised the federal program for certification and oversight of clinical laboratory testing. CLIA applies to all clinical laboratories in the United States (in addition to some international laboratories that receive specimens from the United States for specialized testing not available in the United States) that perform examinations of materials derived from the human body for the purpose of providing information for the diagnosis, prevention, or treatment of any disease or impairment of, or the assessment of the health of human beings. Certain CLIA requirements focus on the communication and receipt of test orders (under pre-analytic systems) and test results (under post-analytic systems) between an ordering provider and a clinical laboratory. Since the implementing regulations for CLIA were established at a time when paper was the dominant method of communication for laboratory orders and results (test requisitions and patient reports), the CLIA regulations governing these activities require each laboratory to establish and follow written policies and procedures for an ongoing mechanism to monitor, assess, and, when indicated, correct identified problems.

As electronic methods for ordering and reporting clinical laboratory information become more prevalent and commonplace it is important to ensure that the intent of the CLIA regulations can be fully supported by EHR technology. This is especially important with regard to patient safety, the accurate, reliable ordering of clinical laboratory testing, and the accurate, reliable, and timely reporting of clinical laboratory test results. In light of the accelerating movement toward the electronic exchange of clinical information (including the transmission of laboratory orders and results), CMS issued guidance

to clarify specific sections of the CLIA regulations. This guidance specified that clinical laboratories should test and verify the accuracy and reliability of each interface to an EHR technology. Since there are thousands of EHR technologies implemented across provider organizations and each likely has more than one laboratory interface, the task of testing both orders and reporting interfaces can be expensive, labor intensive, and time consuming. Additionally, CLIA requires periodic review of these interfaces so this is not a one-time procedure.

http://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/SurveyCertificationGenInfo/Downloads/SCLetter10-12.pdf.

As a step toward addressing these issues, we propose to expand (compared to the 2014 Edition versions) the 2015 Edition certification criteria focused on the exchange of laboratory orders and results (§§ 170.315(a)(2) and (b)(4) and (5)). These revised 2015 Edition certification criteria propose certain CLIA-specific requirements and include updated laboratory exchange standards. CLIA-specific requirements have been included in the “electronic incorporation of lab results” standard at § 170.205(j)(2) and the “laboratory orders” standard at § 170.205(l)(1) and we reference these standards in the appropriate proposed certification criteria. Inclusion of CLIA-specific requirements and updated standards will allow for a more comprehensive evaluation of EHR technology's capabilities in regards to supporting compliance with the CLIA regulations. We believe, upon adoption of the 2015 Edition, it would be possible for CMS to issue additional guidance to further clarify how CLIA requirements related to ongoing interface testing could be met if EHR technology were to be certified to these more comprehensive 2015 Edition certification criteria. Accordingly, we propose a “CPOE—laboratory” certification criterion as well as “incorporate laboratory tests and values/results,” and “transmission of electronic laboratory tests and values/results to ambulatory providers” certification criteria (discussed later in this preamble) to include more comprehensive capabilities focused on ensuring EHR technology's ability to perform capabilities consistent with corresponding CLIA regulatory requirements.

For the 2015 Edition “CPOE—laboratory” certification criterion, we propose to adopt, for the ambulatory setting, the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1-US Realm, Draft Standard for Trial Use, November 2013 (S&I Framework LOI).

Due to the absence of a consensus standard for the purpose of sending laboratory orders from EHRs to labs, this standard was developed in conjunction with laboratories representative of the industry, EHR technology developers, and provider stakeholders through an open consensus-based process under the Standards and Interoperability Framework (S&I Framework) and was balloted and approved through HL7, a standards development organization. We propose to adopt the S&I Framework LOI standard at § 170.205(l)(1). We also propose to require the use of, at a minimum, the version of Logical Observation Identifiers Names and Codes (LOINC®) adopted at § 170.207(c)(2) (version 2.40) as the vocabulary standard for laboratory orders. Last, we propose that laboratory orders must include all the information for a test requisition as specified at 42 CFR 493.1241(c)(1) through (c)(8). The use of these standards and compliance with these requirements should greatly improve the interoperability of laboratory orders sent from ambulatory EHR technology to a laboratory and laboratory compliance with CLIA.

http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922.

•

Computerized Provider Order Entry—Radiology/Imaging

MU Objective

2015 Edition EHR Certification Criterion

§ 170.315(a)(3) (Computerized physician order entry—radiology/imaging).

Gap Certification Status

Eligible.

As discussed above, we propose to adopt a 2015 Edition CPOE certification criterion specific to radiology/imaging ordering. This proposed criterion is structured substantially similar to the 2014 Edition version, except it does not reference laboratory and medication orders.

•

Drug-Drug, Drug-Allergy Interaction Checks

MU Objective

Implement drug-drug and drug-allergy interaction checks.

2015 Edition EHR Certification Criterion

§ 170.315(a)(4) (Drug-drug, drug-allergy interaction checks).

Gap Certification Status

Eligible.

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we do solicit public comment on several related issues.

The 2014 Edition Drug-Drug, Drug-Allergy Interaction Checks certification criterion (45 CFR 170.314(a)(2)) requires EHR technology to be able to automatically and electronically indicate to a user any drug-drug and drug-allergy contraindications (“DDI/DAI”), where such contraindications are based on a patient's medication list and medication allergy list. The criterion further requires that such checks occur before a medication order is completed and acted upon during computerized provider order entry (CPOE). The criterion also requires that EHR technology certified to this criterion be able to adjust severity levels for drug-drug interaction checks and that such ability be limited to an identified set of users or available as a system administrative function.

Because DDI/DAI checks are intended to identify potential medical errors before they occur, these checks can be valuable tools for improving patient safety and for improving overall health outcomes. In order for DDI/DAI checks to be effective, however, action must be taken in response to a notification. When health care providers ignore a notification for DDI/DAI, the very benefit that such checks provide is eliminated.

Given the positive impact we believe DDI/DAI checks can have on patient safety, we are considering whether a future certification criterion edition could require DDI/DAI capable EHR technology to track user responses to DDI/DAI notifications (“response tracking”) and whether commenters believe this would be a positive potential step toward improving user experience with DDI/DAI checking. The purpose of including this type of capability in a certification criterion would be to equip health care providers with response data that they could use to improve their own performance and the safe use of their EHR technology. With such response tracking data, health professionals could analyze the notifications that are often ignored or missed and could work with clinicians to learn why they ignored or missed them. Understanding clinician decisions related to DDI/DAI notifications also can help health professionals make such notifications more effective, and potentially eliminate ineffective notification methods. This information also may be helpful for EHR technology developers as they design DDI/DAI checks and notifications.

We therefore seek comment on whether we should consider adopting a certification criterion as part of a future edition of certification criteria that would require EHR technology to be able to track health professionals' responses to the DDI/DAI checks that are performed and whether such a capability should track if and when the health professional viewed, accepted, declined, ignored, overrode, or otherwise commented on the product of a DDI/DAI check. We also seek comment on who should be permitted to review the data collected by the DDI/DAI check tracking capability, who should be able to adjust its configuration settings, whether the data tracked should be limited in scope or specificity, and whether EHR technology should be able to track when an adverse event occurs for which a DDI/DAI check was missed or ignored.

Last, we seek comment on whether a DDI/DAI tracking capability should only track inaction or responses related to certain drug-drug and drug-allergy reactions, such as only tracking DDI/DAI alerts that if missed or ignored would cause severe reactions in patients. We also seek comment on what factors, definitions, standards, or existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe.

•

Demographics

MU Objective

Record the following demographics: preferred language; sex; 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.

2015 Edition EHR Certification Criterion

§ 170.315(a)(5) (Demographics)

Gap Certification Status

Ineligible.

We propose to adopt a 2015 Edition “demographics” certification criterion that revises the 2014 Edition version. Our two proposals for the 2015 Edition criterion address a new standard for recording preferred language and that EHR technology must be capable of enabling a user to electronically record, change, and access the date of death and the preliminary cause of death.

Preliminary Cause of Death and Date of Death

We propose to include in the 2015 Edition the capability to enable a user to electronically record, change, and access the “date of death” as a required capability that EHR technology designed for the inpatient setting must demonstrate. We previously included this capability as part of the 2011 Edition “demographics” certification criterion and inadvertently omitted it from the 2014 Edition. Thus, this change would more accurately track the data required by the meaningful use criteria. To note, this functionality would be in addition to the inclusion in the 2015 Edition “demographics” certification criterion of the same capability to enable a user to electronically record, change, and access “preliminary cause of death” in case of mortality as is included in the 2014 Edition “demographics” certification criterion.

Preferred Language

Based on specific HITSC recommendations, we adopted ISO 639-2 constrained by ISO 639-1 for recording preferred language in the 2014 Edition “demographics” certification criterion. More specifically, this means that EHR technology is required to be capable of using the alpha-3 codes of ISO 639-2 to represent the corresponding alpha-2 code in ISO-639-1. To provide further clarity, we issued FAQ 27

in which we stated that where both a bibliographic code and terminology code are present for a required ISO 639-2 language, EHR technology is expected to be capable of representing the language in accordance with the (T) terminology codes (ISO 639-2/T) for the purposes of certification.

http://www.healthit.gov/policy-researchers-implementers/27-question-10-12-027.

After we issued FAQ 27, we issued FAQ 43

in which we acknowledge that our constrained approach to the use of ISO 639-2 unintentionally excluded multiple languages that are currently in use, such as sign language and Hmong. Additionally, ISO 639-2 is meant to support written languages, which may not be the language with which patients instinctively respond when asked for their preferred language. To improve this situation, we propose to adopt one of the following three options for the 2015 Edition “demographics” certification criterion:

http://www.healthit.gov/policy-researchers-implementers/43-question-11-13-043.

Option 1:

Adopt ISO 639-2

codes—in full—as part of certification to the 2015 Edition “demographics” certification criterion. We note, however, that as mentioned in FAQ 43, the ISO-639-2 standard was “intended for written languages primarily.” For instance, “Chinese” is represented by its official language, Mandarin, in the code list. This would not account for the commonly spoken Cantonese language/dialect or other spoken Chinese languages/dialects. As a result, EHR technology developers may find that particular spoken languages are not in all cases sufficiently supported by the constrained standard we adopted for 2014 Edition certification. We have proposed this option in our regulatory text and propose to adopt the full ISO-639-2 codes at § 170.207(g)(2). Note, to implement this proposal, we would have to modify the regulatory text hierarchy in § 170.207(g) to designate the standard referenced by the 2014 Edition version of this certification criterion at § 170.207(g) to be at § 170.207(g)(1).

http://www.loc.gov/standards/iso639-2/iso639-2ra.html

Option 2:

Adopt ISO 639-3.

We chose not to adopt ISO 639-3 as part of the 2014 Edition “demographics” certification criterion in response to one comment on our proposed 2014 Edition criterion because we believed it exceeded the baseline necessary for certification and we had insufficient stakeholder feedback. ISO 639-3 is a code set that aims to define three-letter identifiers for all known human languages. ISO 639-3 attempts to provide as complete an enumeration of languages as possible, including living, extinct, ancient, and constructed languages, whether major or minor, written or unwritten. We seek comment on its appropriateness as the baseline standard for recording preferred language as part of the 2015 Edition “demographics” certification criterion.

http://www-01.sil.org/iso639-3/

Option 3:

Adopt Request for Comments (RFC) 5646.

RFC 5646 entitled “Tags for Identifying Languages, September 2009” is the coding system that is commonly used to encode languages on the web and is the most current RFC for this purpose and listed as a “best current practice.” The first part of the code relies on the shortest ISO-639 code for the language. That means a 2-character code if the language is specified in ISO 639-1 or a 3-character code from ISO 639-2 or -3, if the language is only listed in one of those two ISO codes. We are also aware that RFC 5646 supports dialects.

http://www.rfc-editor.org/info/rfc5646

We welcome comments on which standard should be required for recording preferred language as part of the 2015 Edition “demographics” certification criterion. Additionally, we propose in a later section of this rule that the chosen standard would also become the preferred language standard for the “Common MU Data Set” definition. Please see section III.D.3 “Common MU Data Set” of this preamble for further discussion of this associated proposal.

•

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.

2015 Edition EHR Certification Criterion

§ 170.315(a)(6) (Vital signs, body mass index, and growth charts)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we solicit public comment on the following issues. In the 2014 Edition Final Rule (77 FR 54203), we declined to revise the certification criterion at § 170.314(a)(4) in response to comments that recommended we require EHR technology to record vital signs in standardized vocabularies (e.g., LOINC, SNOMED CT, and UCUM). At the time, we believed that it was too complex and burdensome for technology developers to map workflows, templates, and forms used to capture vital signs to standardized vocabularies. We also expressed concern that such a requirement could cause EHR technology developers to map vital signs to a standardized terminology in one workflow but perhaps not others. We were concerned that such an approach could cause providers to be forced to use a given workflow, form, or template to achieve MU that is inconsistent with optimal workflow and usability. However, we noted that EHR technology developers would not be precluded from using standardized vocabularies to meet this 2014 Edition EHR certification criterion.

We have continued to receive stakeholder feedback that we should consider adopting standardized vocabularies for recording vital signs (e.g., LOINC for observations). However, we have also received feedback that we should continue to allow flexibility in how vital signs are recorded. As a result, we solicit comment on whether we should adopt standardized vocabularies for recording vital signs (specifically, whether we should adopt LOINC (for observations), SNOMED CT (for qualitative results), and UCUM (for units of measure)) in this certification criterion for the 2017 Edition. In addition to these vocabularies, we also solicit comment on whether other vocabularies would be better for recording vital signs.

In the 2014 Edition Final Rule, we stated that we intended to require that EHR technology be able to record all vital signs according to standardized technologies in the next EHR certification criteria edition (77 FR 54203). This was intended to be an incremental step toward interoperability at a more granular level. At the time of publication, we anticipated that the next certification criteria edition would be published with the MU Stage 3 rulemaking. However, given our modified approach to the rulemaking timeline discussed at the beginning of the preamble, we are using this intermediate 2015 Edition rulemaking to solicit more detailed comment on this issue to inform our policy decisions for the 2017 Edition.

For recording vital signs, we are considering two different approaches:

•

Option 1

would be to require that EHR technology be able to record vital signs data natively using the aforementioned standards as part of the vital signs certification criterion. For the majority of our 2014 Edition certification criteria, we only require vocabulary standard(s) be used as part of a transmission rather than natively within the EHR. While it is not the norm, we have already set precedent for certain 2014 Edition certification criteria (e.g., smoking status) to require EHR technology to demonstrate the ability to natively record data in a particular standard as opposed to only having to apply that standard when data is exchanged. One potential benefit of this approach is that the standardized vocabularies are applied to the data as it is collected (e.g., to provide contextual information about the data to assist with interpretation). A downside, however, is that it could require more upfront work on the part of providers to capture the data in a standardized way and that certain local approaches to data collection may need to be discontinued.

•

Option 2

would be to require that EHR technology be able to represent such data in the aforementioned standards in any certification criterion

that references vital signs

when such data would be exchanged

. For example, when exchanging a summary care record, the EHR technology would need to ensure blood pressure is represented in the CCDA formatted summary care record in the appropriate standard. Presumably, this option would be less burdensome on providers. It would also continue to allow them to collect vitals in local and non-standardized ways within their own EHR technology. However, it could also result in lost precision regarding the context associated with the vitals recorded.

Last, additional feedback we have received from stakeholders indicated that if we were to pursue option 2, we would be best served to require EHR technology to record additional metadata related to the context around how the vital signs were collected. Stakeholders indicated that this additional information would provide context and comparability for the data if a standard vocabulary is not used when the data is recorded. For recording vitals, it is our understanding that unless particular contextual information associated with data collection is captured locally, data may be misinterpreted by a receiving party.

Without certain kinds of contextual information, vitals data cannot be cross-walked or coded correctly. For example, a single blood pressure measurement may not represent a patient's true blood pressure. In older patients, the American Heart Association (AHA)

recommends taking the patient's blood pressure twice while standing, recording the average of the two, and then taking the patient's blood pressure twice while sitting and using the sitting average as the final reading. The standing average is to be used as a reference point only. If this information (e.g., whether the patient was sitting or standing, if the measure is the first, second, or average) is not recorded in the EHR along with the blood pressure measurement itself, the readings may not be correctly understood by a receiving party, such as another provider or caregiver. Therefore, we are also soliciting comment on whether we should prioritize our attention toward making sure EHR technology can capture this kind of contextual information or other metadata and what kinds of data would be best or most helpful for EHR technology certification to require. Please note we are not proposing that blood pressure must be recorded according to the AHA's recommendations. Rather, we use their recommendations to illustrate how contextual information about vital signs may be important to prevent misinterpretation. Finally, we solicit comments on whether vocabularies (and other metadata) are sufficient for the reuse of more granular data elements and whether continued work through initiatives (e.g., the Clinical Information Modeling Initiative (CIMI), Fast Health Interoperable Resources (FHIR)) to support capturing clinical entity models or other approaches for representing more granular data elements is needed.

New AHA Recommendations for Blood Pressure Measurement.

Am Fam Physician.

2005 Oct 1;72(7):1391-1398.

• Problem List

MU Objective

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

2015 Edition EHR Certification Criterion

§ 170.315(a)(7) (Problem list)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Medication List

MU Objective

Maintain active medication list.

2015 Edition EHR Certification Criterion

§ 170.315(a)(8) (Medication list)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition EHR certification criterion that is the same as the 2014 Edition version.

• Medication Allergy List

MU Objective

Maintain active medication allergy list.

2015 Edition EHR Certification Criterion

§ 170.315(a)(9) (Medication allergy list)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Clinical Decision Support

MU Objective

Use clinical decision support to improve performance on high-priority health conditions.

2015 Edition EHR Certification Criterion

§ 170.315(a)(10) (Clinical decision support)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version in several ways. The 2014 Edition EHR certification criterion for CDS (§ 170.314(a)(8)) requires EHR technology to perform certain capabilities based on “demographics” data. Since the 2014 Edition Final Rule's publication, we have received many clarifying questions on whether EHR technology presented for certification must demonstrate the capability to use more than one of the demographics data categories listed in the “Demographics” certification criterion adopted at § 170.314(a)(3). Similar to the proposed 2015 Edition “Patient List Creation” certification criterion's modification of the 2014 Edition version, we are also proposing to adopt a 2015 Edition CDS certification criterion that incorporates the guidance we provided in FAQ 39.

Specifically, the text of the 2015 Edition “CDS” certification criterion provides that EHR technology must demonstrate the capability to use at least one of the more specific data categories included in the “demographics” certification criterion (45 CFR 170.315(a)(5)) (e.g., sex or date of birth).

http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.

The 2014 Edition EHR certification criterion for CDS also requires EHR technology to provide Infobutton

-enabled diagnostic and therapeutic reference information (§ 170.314(a)(8)(ii)(2)) in accordance with one of the Infobutton implementation specifications at § 170.204(b)(1) or § 170.204(b)(2). Since the 2014 Edition Final Rule's publication, we received clarifying feedback that the Infobutton standard does not support vital signs and medication allergies data for linked referential CDS and subsequently issued FAQ 34

to clarify how 2014 Edition testing and certification would handle this limitation.

As a result, we propose that the 2015 Edition CDS certification criterion will not require compliance with the Infobutton-enabled capability for vital signs nor medication allergies data. We also propose to discontinue referencing “laboratory values/results” data as we understand from stakeholder feedback that the Infobutton standard cannot support this specific data. Further, we propose to adopt the HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (at § 170.204(b)(3)) in

place of the older version referenced by the 2014 Edition certification criterion.

“Infobutton” is typically the shorthand name used to refer to the formal standard's name: HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton).

http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034.

Health eDecisions Proposal

Launched in June 2012, an ONC Standards & Interoperability Framework initiative known as Health eDecisions (HeD) focused on defining and harmonizing standards that could facilitate the emergence of systems and services for shareable CDS. Since that time, the HeD Working Group has developed two use cases with functional requirements, defined and balloted relevant standards, developed IGs, and is in the process of conducting pilots and performing data collection for analysis.

HeD use case (UC) 1 defines the functional requirements needed to build a standard schema for the contents of three “CDS Knowledge Artifact”

types: event condition action (ECA) rules, order sets, and documentation templates.

UC 1 is based on the scenario of a “CDS Knowledge Artifact supplier” making a computable CDS Knowledge Artifact available to a “CDS Artifact integrator.” The HeD Working Group created the HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”)

as a companion document for the CDS Knowledge Artifact schema (described in the HeD standard IG). The HeD standard includes additional background, contextual information, and detailed documentation and guidance to support schema implementation.

Overall, implementation of the HeD standard would greatly assist the industry in producing and sharing machine readable files for representations of clinical guidance.

A CDS Knowledge Artifact is the encoding of structured CDS content as a rule to support clinical decision making in many areas of the health care system, including quality and utilization measures, disease outbreaks, comparative effectiveness analysis, efficacy of drug treatments, and monitoring health trends.

HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”).

http://wiki.siframework.org/file/detail/implementation_guide_working_final_042413_lse_uploaded-1.docx.

Background documents and implementation guides can be found at

http://wiki.siframework.org/Health+eDecisions+Homepage.

HeD UC 2 defines the interface requirements needed to send patient data and receive CDS guidance based on one scenario: a request for clinical guidance made to a CDS guidance supplier.

The HeD Working Group considered the following interactions with a CDS guidance supplier: drug dosing calculation; immunization forecasting; disease management; quality measure evaluation; transition of care support; prediction rule evaluation (e.g., APACHE score, AHRQ Pneumonia Severity Index); and severity of illness assessment (e.g., Charlson Index). The HeD Working Group created the HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013)

, which defines SOAP and REST Web service interfaces for CDS guidance services. The implementation of this IG would promote systems whereby a health care provider can send a question about a patient to a CDS guidance supplier and receive CDS guidance back in near real-time.

HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013).

http://wiki.siframework.org/file/view/20130830_DSS_IG_R1_for_201309_ballot.zip/448259852/20130830_DSS_IG_R1_for_201309_ballot.zip.

The functionality discussed above could significantly enhance the scalability and time to market of new clinical knowledge and improve care. We also believe, with the progress made by the HeD initiative since its launch, that this proposed rule serves as an opportunity to propose the HeD standard for testing and certification. Further, its proposal as part of the 2015 Edition permits EHR technology developers and other interested stakeholders to provide feedback on its readiness for inclusion in the 2017 Edition.

We therefore propose to adopt the HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”) as a standard at § 170.204(d) and to require that EHR technology be able to electronically process a CDS artifact formatted in the HeD standard. We also propose to adopt the HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013) as a standard at § 170.204(e) and to require that EHR technology demonstrate the ability to make an information request, send patient data, and receive CDS guidance according to the interface requirements defined in the Decision Support Service IG. To supplement our proposals, we solicit comment on:

• What specifically ONC should focus on when it comes to testing and certification for acceptance and incorporation of CDS Knowledge Artifacts;

• The feasibility of implementing the interface requirements defined in the Decision Support Service IG to make an information request, send patient data, and receive CDS guidance in near real-time;

• The ease with which EHR technology could be developed to consume CDS Knowledge Artifacts;

• Whether we should work to distinguish between

complex

CDS Knowledge Artifacts and

simple

Knowledge Artifacts and to require only acceptance and incorporation of simple Knowledge Artifacts in the 2015 Edition, with increasing expectations of more complex capabilities in future editions;

• The ability to store and auto-configure a CDS Knowledge Artifact in EHR technology; and

• The ability to map the CDS Knowledge Artifact standard to data within the EHR technology (including medications, laboratory, and allergies information).

• Electronic Notes

MU Objective

Record electronic notes in patient records.

2015 Edition EHR Certification Criterion

§ 170.315(a)(11) (Electronic notes)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. We propose a 2015 Edition “electronic notes” certification criterion that would include one new requirement compared to the 2014 Edition “electronic notes” certification criterion. Specifically, for the 2015 Edition certification criterion, we propose that EHR technology have the capability to search for information across separate notes within the EHR technology rather than just within one particular note. This expanded requirement is intended to reduce the time providers spend looking for specific patient information. The requirement to search across notes is

not limited to a specific method

. Instead, we are primarily concerned that the outcome expressed is demonstrated. We expect and encourage EHR technology developers to create innovative ways to achieve this functionality. As with the 2014 Edition “electronic notes” certification criterion, “search” continues to mean the ability to search free text and data fields of electronic notes.

While we propose to adopt the “search across notes” capability for the 2015 Edition, we request comment on the following:

• Whether this functionality should extend to all patient electronic notes stored in the EHR or just to a specific patient's electronic notes or specific types of patient notes;

• Whether we should require this functionality in the 2015 Edition or wait to include it in a potential 2017 Edition “electronic notes” certification criterion; and

•

Health care provider

opinions on whether the availability of such functionality (either searching across a specific patient's electronic notes stored in the EHR or all patients' electronic notes stored in an EHR) is so widespread that it would be unnecessary to require it as a condition of certification. We note that the “electronic notes” objective and measure for MU Stage 2 requires that notes be text searchable, but does not require searching across electronic notes.

• Whether additional metadata should be required as part of electronic notes (such as the HL7 R2 header) to assist in both searching of notes, but also to make exporting electronic notes for patient data portability easier.

• Drug Formulary Checks

MU Objective

Implement drug formulary checks.

2015 Edition EHR Certification Criterion

§ 170.315(a)(12) (Drug formulary checks)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we solicit public comment on the following issues. In the 2014 Edition EHR certification criteria final rule, we strongly encouraged EHR technology developers to use the updated Medicare Part D e-prescribing standards, including a new version of the NCPDP Formulary and Benefit standard (NCPDP Formulary and Benefit Standard 3.0), if or when it was finalized as an official Part D E-Prescribing standard (77 FR 45022). At the time, we did not believe it was necessary to require the use of the NCPDP Formulary and Benefit Standard 3.0 if/when it became the official Part D E-Prescribing standard as a condition of certification because our certification criterion was flexible and permitted EHR technology to access and store external drug formularies in support of meaningful use.

CMS agreed with comments on the CY 2013 Physician Fee Schedule proposed rule that suggested the adoption of the NCPDP Formulary and Benefit Standard 3.0 as the official Part D E-Prescribing standard should be delayed until after July 1, 2014, which was expected to be the “sunset date” when NCPDP would cease to support version 1.0 (77 FR 68892). Furthermore, CMS determined that it should also delay recognition of the NCPDP Formulary and Benefit Standard 3.0 as a backward compatible version of NCPDP Formulary and Benefits Standard 1.0 because it did not believe that two versions of a standard should be used over an extended period of time (77 FR 68892). Having come within a year of the originally proposed sunset date, CMS recently re-proposed and finalized a proposal to recognize NCPDP Formulary and Benefit Standard v.3.0 as a backward compatible version of NCPDP Formulary and Benefit Standard 1.0 for the period of July 1, 2014 through February 28, 2015, and to retire version 1.0 and adopt version 3.0 as the official Part D E-Prescribing standard on March 1, 2015 (77 FR 74787-74789).

CMS originally proposed retiring V1.0 on July 1, 2014, but subsequently decided to postpone the retirement date to March 1, 2015, in response to comments to allow the industry adequate time to implement the necessary changes and testing to implement v3.0 (78 FR 74789).

The NCPDP Formulary and Benefit Standard 3.0 includes updates based on industry feedback and new or modified business needs. For a full discussion of the changes that were made to previous versions of the NCPDP Formulary and Benefit Standard that NCPDP ultimately developed toward NCPDP Formulary and Benefit Standard 3.0, see 77 FR 45023-45024).

The HITSC has discussed the current structure of the NCPDP Formulary and Benefit Standard v.4.0

and has noted potential limitations. These include:

V.4.0 has minor changes compared to v.3.0, including removal of values from an unused diagnosis code, typographical changes, and a change to the standard length of the name field. CMS has proposed adopting v.3.0 (CY2014 Physician Fee Schedule proposed rule), which includes the substantive changes from previous versions.

Clinical Operations Workgroup Update to the HITSC on June 19, 2013.

http://www.healthit.gov/FACAS/sites/faca/files/clinical_operations_wg_update_062013_0.pdf.

• That large files are needed to provide the formulary and benefit data;

• that the data are submitted in batch rather than in real-time;

• the provider cannot see patient-specific variations in drug-specific benefits;

• an assumption that the patient's current drug plan is identified through a successful eligibility check based on a five-point identifier rather than the actual pharmacy data;

• the inability to detect differences in primary and secondary prescription benefit coverage;

• that the provider must manually pull updated formulary and benefit data rather than being pushed the updates.

In order to resolve the limitations of NCPDP Formulary and Benefit Standard v.4.0, the HITSC has discussed that a new or updated standard or transaction is needed for EHRs to develop the functionality to run patient-specific formulary checks against the patient's actual drug benefit for a specific drug and dose in a timely manner. However, this is a long-term potential suggestion. Despite the NCPDP Formulary and Benefit Standard v.4.0's limitations, it does support providers' ability to know what drugs are included in the formulary, which can assist them in helping patients make decisions about their care. In the meantime, the NCPDP Formulary and Benefit Standard v.3.0 appears to be the best standard available for this particular use case. As described above, CMS has recently finalized a proposal to recognize NCPDP Formulary and Benefit Standard v.3.0 as a backward compatible version of NCPDP Formulary and Benefit Standard 1.0 starting on July 1, 2014, and v.4.0 includes minor changes compared to v.3.0.

For a long-term potential solution, the NCPDP Telecommunications Standard used for pharmacy-to-payer transactions may offer some solutions when used in conjunction with the NCPDP Formulary and Benefit Standard v.4.0, specifically for certifying patient-level eligibility and prescription drug benefits with detailed information defining reimbursement or denial of compensation with explanations. However, to date, the NCPDP Telecommunications Standard has been used mostly for real-time billing of pharmacy transactions.

In light of these circumstances and challenges, we solicit comment on whether we should leave this certification criterion as-is (in its flexible form) as we consider 2017 Edition policy or if it would be advantageous for us to adopt a standard in this 2015 Edition certification criterion for which compliance would be required. We also solicit comment on:

• The appropriateness of using the NCPDP Telecommunications Standard in conjunction with the NCPDP Formulary and Benefit Standard v.3.0 or v.4.0 to support expanded use cases such as real-time benefit checks; and

• Whether there are other standards or solutions that can address the potential limitations identified by HITSC and the use case of real-time benefit checks.

• Smoking Status

MU Objective

Record smoking status for patients 13 years old or older.

2015 Edition EHR Certification Criterion

§ 170.315(a)(13) (Smoking status)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Image Results

MU Objective

Imaging results and information are accessible through Certified EHR Technology.

2015 Edition EHR Certification Criterion

§ 170.315(a)(14) (Image results)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Family Health History

MU Objective

Record patient family health history as structured data.

2015 Edition EHR Certification Criterion

§ 170.315(a)(15) (Family health history)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. The 2014 Edition “family health history” certification criterion requires EHR technology to demonstrate that it is capable of enabling a user to electronically record, change, and access a patient's family health history according to certain standards. In support of the MU Stage 2 requirement that family health history be captured in structured data, we adopted two standards for recording family health history: Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT®) terms for familial conditions and the HL7 Pedigree standard. In adopting SNOMED CT®, we acknowledged that HL7 Pedigree was a relatively new standard and that an implementation guide had not yet been published.

As such, we stated that the use of SNOMED CT® was perhaps the best intermediate step for coding family health history in structured data if one was not to use the HL7 Pedigree standard.

77 FR 54174 (September 4, 2012).

In April 2013, an HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1,

was published. With the publication of this IG, we propose to adopt a 2015 Edition “family health history” certification criterion that requires solely the recording of family health history according to the HL7 Pedigree standard and the HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1 (i.e., it omits SNOMED CT® as an option). We believe that convergence to this single standard and IG will ensure more precise electronic recording of family health history data and, more importantly, improve the interoperability of family health history information. As part of the 2014 Edition Final Rule, we incorrectly assigned the HL7 Pedigree standard to § 170.207 where we adopt “vocabulary” standards. Accordingly, for the 2015 Edition proposal we have placed the HL7 Pedigree standard and its IG in § 170.205(m)(1) to more accurately place it in the “content” exchange standards section.

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=301.

• Patient List Creation

MU Objective

Use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care.

2015 Edition EHR Certification Criterion

§ 170.315(a)(16) (Patient list creation)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition “patient list creation” certification criterion that revises the 2014 Edition version to incorporate our guidance provided in FAQ 39.

Specifically, the text of the 2015 Edition “patient list creation” certification criterion provides that EHR technology must demonstrate its capability to use at least one of the more specific data categories included in the “demographics” certification criterion (45 CFR 170.315(a)(5)) (e.g., sex or date of birth).

http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.

For a potential 2017 Edition “patient list creation” certification criterion, we request comment on four issues for EHR technology certification:

(1) Whether patient communication preferences should be a requirement for the inpatient setting;

(2) Whether a minimum list of patient communication preferences should be more specifically defined in order to require that EHR technology be capable of creating patient reminder lists based on a patient's preferred communication medium (e.g., electronically through secure email or a patient portal, paper/regular mail, or phone);

(3) Whether EHR technology should be able to use a patient's preferred language as a filter; and

(4) Because this certification criterion also supports the meaningful use objective and measure related to “patient reminders,” whether we should include within this certification criterion or adopt a new certification criterion that would require EHR technology be able to provide patient reminders according to identified patient preferences and preferred language (for example, if the patient preference for a reminder was “email” and preferred language was English, the EHR technology would have to demonstrate that it could send reminders in English via email).

• Patient-Specific Education Resources

MU Objective

Use clinically relevant information from Certified EHR Technology to identify patient-specific education resources and provide those resources to the patient.

2015 Edition EHR Certification Criterion

§ 170.315(a)(17) (Patient-specific education resources)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition “patient-specific education resources” certification criterion that revises the 2014 Edition version in three ways. Our first proposal is to adopt this certification without the requirement that EHR technology be capable of electronically identifying patient-specific education resources based on “laboratory values/results.” We understand from stakeholder feedback on the 2014 Edition version of this criterion that the Infobutton standard cannot support this level of data specificity, and we do not expect EHR technology developers to develop an alternative method that could electronically identify patient-specific education resources based on laboratory values/results. Our second proposal is to adopt the HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013. This is the updated IG of the Draft Standard for Trial Use (DSTU) version we adopted for the 2014 Edition “patient-specific education resources” certification criterion. To clearly distinguish this IG in the regulation text from the DSTU version, we propose a technical amendment to § 170.204(b)(2) to note that the version is the DSTU version. Finally, our third proposal is to revise the regulation text to be more consistent with the intent and interpretation of the 2014 Edition certification criterion regulation text we expressed in the 2014

Edition final rule.

The text of the 2015 Edition certification criterion makes clear that the EHR technology must demonstrate the capability to electronically identify patient-specific education resources using Infobutton and an alternative method that does not rely on Infobutton. To note, we propose that the guidance we provided in FAQ 40

would still be applicable to the 2015 Edition “patient-specific education resources” certification criterion.

77 FR 54216

http://www.healthit.gov/policy-researchers-implementers/40-question-04-13-040.

We request comment on whether we should adopt a different approach related to the methods EHR technology uses to electronically identify patient-specific education resources for the 2015 Edition, a potential 2017 Edition “patient-specific education resources” certification criterion, or both. The 2014 Edition and the proposed 2015 Edition EHR certification criteria require EHR technology to demonstrate the capability to electronically identify for a user patient-specific education resources using Infobutton

and an alternative method.

We seek comment on whether we should: (1) Maintain this approach; (2) require EHR technology to demonstrate only the use of Infobutton, but permit EHR technology to be certified to other methods upon an EHR technology developer's request for the purpose of an EP, EH, or CAH being able to use the alternative certified method for MU (to count such use toward meeting the measure); or (3) certify only the use of Infobutton and consult with CMS regarding a meaningful use policy change that would permit the use of any method (certified or not) to electronically identify patient-specific education resources, provided that the EP, EH, or CAH has EHR technology certified to perform the Infobutton capability.

We also seek comment on whether we should require that EHR technology be capable of providing patient-specific education resources in a patient's preferred language in the 2015 Edition, in a potential 2017 Edition certification criterion, or in both.

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

2015 Edition EHR Certification Criterion

§ 170.315(a)(18) (Inpatient setting only—electronic medication administration record)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Advance Directives

MU Objective

Record whether a patient 65 years old or older has an advance directive.

2015 Edition EHR Certification Criterion

§ 170.315(a)(19) (Inpatient setting only—advance directives)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Implantable Device List

MU Objective

N/A

2015 Edition EHR Certification Criterion

§ 170.315(a)(20) (Implantable Device List)

Gap Certification Status

Ineligible

We propose to adopt a new 2015 Edition certification criterion that would require EHR technology to be able to record and display a unique device identifier (UDI)

and other information about a patient's implantable devices. This proposed certification criterion represents a first step towards enabling EHR technology to facilitate the widespread capture and use of UDI data to prevent device-related medical errors, improve the ability of hospitals and clinicians to respond to device recalls and device-related patient safety information, and achieve other important patient safety and public health benefits consistent with the fundamental aims of the HITECH Act

and the July 2, 2013 HHS Health Information Technology Patient Safety Action and Surveillance Plan.

A UDI is a unique numeric or alphanumeric code that consists of two parts: (1) A device identifier (DI), a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device, and (2) a production identifier (PI), a conditional, variable portion of a UDI that identifies one or more of the following when included on the label of a device: The lot or batch number within which a device was manufactured; the serial number of a specific device; the expiration date of a specific device; the date a specific device was manufactured; the distinct identification code required by 21 CFR § 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device.

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/

Specifically, the certification criteria supports the National Coordinator's responsibility under the HITECH Act to ensure that the nation's health IT infrastructure supports activities that “reduce[] medical errors,” “improve[] health care quality,” “improve[] public health activities,” and “facilitate[] the early identification and rapid response to public health threats and emergencies . . . .” 42 U.S.C. § 300jj-11(b)(2) & (7).

Available at

http://www.healthit.gov/policy-researchers-implementers/health-it-and-patient-safety.

The first objective of the Health IT Patient Safety Plan is to “use health IT to make care safer.”

See id.

at 7. The Plan specifically contemplates that ONC will update its standards and certification criteria to improve safety-related capabilities and add new capabilities that enhance patient safety.

FDA issued the Unique Device Identification System Final Rule on September 24, 2013.

This FDA rule implements a statutory directive to establish a “unique device identification system” for medical devices that will enable adequate identification of devices through distribution and use.

It accomplishes this objective by requiring that a UDI be included on the label of most medical devices distributed in the United States. In addition, for each device with a UDI, a standard set of identifying elements will be publicly available through the FDA's Global Unique Device Identification Database (GUDID).

FDA is scheduled to fully implement the UDI system for devices that are implantable, life-saving, and life sustaining by September 2015.

78 FR 58786.

21 U.S.C. § 360i(f).

The FDA's draft guidance on the GUDID is available at

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/

Pursuant to 21 U.S.C. § 360i(f), FDA must implement the Unique Device Identification System Final Rule with respect to devices that are implantable, life-saving, and life sustaining not later than two years after the rule was finalized. Other implementation and compliance dates are detailed in the final rule.

We believe that EHR technology will play a key role in the widespread adoption and utilization of UDIs and that its use of UDIs can help reduce device-related medical errors and provide other significant patient safety, health care quality, and public health benefits. Specifically, EHR technology could be leveraged in conjunction with automated identification and data capture (AIDC) technology or other technologies to streamline the capture and exchange of UDIs and associated device data in clinical and administrative workflows. Moreover, patients' UDI data in EHR technology could pave the way for new CDS and help health care providers more rapidly and accurately identify a patient's devices and key information about the safe and effective use of such devices. Further, EHR technology could facilitate better and more accurate reporting of adverse events and other information to reporting systems and registries and

enable more effective corrective and preventative action in response to device recalls and alerts and other device-related information related to patient safety.

These and other potential benefits of UDIs and the UDI system established by FDA are described in detail in the Unique Device Identification System Notice of Proposed Rulemaking, 77 FR 40736.

We recognize that additional standards and technical specifications will be required to support the full range of capabilities contemplated above. Indeed, efforts to identify or develop these standards are already underway.

Nevertheless, we believe that it is both feasible and important for EHR technology developers to begin implementing at least the baseline functionality necessary to capture, store, and retrieve UDIs and other contextually relevant information associated with a patient's medical devices, specifically implantable devices. By their nature, these devices cannot be inspected with the naked eye and are more susceptible to misidentification, which can result in patient harm. Moreover, once a device is implanted, it is separated from its UDI, which is attached only to the device's labeling and not directly marked on the device itself. Under the FDA's accelerated implementation timeline, UDIs will be available for all implantable devices no later than September 2015.

For example, the HL7 Technical Steering Committee has initiated a UDI Task Force to ensure that UDI is implemented in a consistent and interoperable manner across the suite of HL7 standards. See

http://hl7tsc.org/wiki/index.php?title=TSC_Minutes_and_Agendas

. FDA is collaborating with the Engelberg Center for Health Care Reform at the Brookings Institute to develop a roadmap for the successful adoption and implementation of UDI throughout the healthcare system. See

http://www.brookings.edu/about/centers/health/projects/development-and-use-of-medical-devices/udi

. AHRQ has incorporated UDI and associated data attributes in its Common Formats for adverse event reporting. See

http://www.pso.ahrq.gov/formats/brochurecmnfmt.htm . Also

see AHRQ Data Dictionary, Common Formats Hospital Version 1.2, at 87, available at

https://www.psoppc.org/c/document_library/get_file?p_l_id=375680&folderId=431263&name=DLFE-15061.pdf

. Through an S&I Framework Structured Data Capture Initiative, ONC, FDA, and other stakeholders are pursuing the inclusion of UDI data in FDA adverse event reporting. See

http://wiki.siframework.org/Structured+Data+Capture+Initiative.

The inclusion of UDI data in FDA adverse event reporting is being pursued through an ONC S&I Framework Structured Data Capture Initiative, see

http://wiki.siframework.org/Structured+Data+Capture+Initiative

We propose to adopt a 2015 Edition certification criterion focused on EHR technology's ability to record UDI information about implantable devices. More specifically, EHR technology would have to enable a user to electronically record the UDI of an implantable device and other relevant information (such as a procedure note or additional information about the device) as part of a patient's “implantable device list.” EHR technology would also be required to allow a user to electronically access and view a patient's list of UDIs and other relevant information associated with a patient's implantable devices. In addition, the EHR technology would need to be able to parse the UDI in order to extract and allow a user to view the “device identifier” and “production identifier” portions of the UDI. The purpose of this requirement is to ensure that a user will be able to use the device identifier to manually retrieve associated data elements from an authoritative source based on the GUDID, once available and, similarly, to ensure that a user will be able to manually use the production identifier in the event of a device recall. We expect that EHR technology would be able to automate these processes once appropriate standards and technical specifications are developed.

As previously indicated, we believe EHR technology should also facilitate the UDI's exchange in order to increase the overall availability and reliability of information about patients' implants and other devices. Thus, we propose to reference “the UDI(s) for a patient's implantable device(s)” in the following proposed 2015 Edition EHR certification criteria which also propose the adoption of the newest version of the Consolidated CDA.

We understand that this data can already be accommodated in the current Consolidated CDA version and is best placed in the “Product Instance” data element which is part of the Procedures template (see section 5.65 of the current Consolidated CDA version adopted at 45 CFR 170.205(a)(3) and incorporated by reference at 45 CFR 170.299(f)(8)). We seek comment from Consolidated CDA experts on whether there is a better location to place this information so that we may provide updated guidance in a final rule or FAQ. For clarity and context purposes each impacted proposed certification criterion will include a reminder about our proposal here. However, to reduce redundancy, this proposal and its rationale serves as the basis for the UDI's inclusion in each of those criteria.

This version is Release 2 of the Draft Standard for Trial Use, which is discussed in further detail under the 2015 Edition “transitions of care” certification criterion.

• 170.315(b)(1)—Transitions of care.

• 170.315(b)(6)—Data portability.

• 170.315(e)(1)—View, download, and transmit to third party.

• 170.315(e)(2)—Clinical summary.

We have also proposed elsewhere in this Proposed Rule to modify § 170.102 to include new definitions for “implantable device,” “unique device identifier,” “device identifier,” and “production identifier.” This will prevent any interpretation ambiguity and ensure that each term's specific meaning reflects the same meaning given to them in the Unique Device Identification System Final Rule and in 21 CFR 801.3.

We seek public comment on additional EHR technology capabilities we are considering including as part of the 2017 Edition rulemaking. Based on stakeholder input and in consultation with FDA, we believe that the following EHR technology capabilities could help achieve our stated objectives:

• Record a minimum set of data elements for each UDI in a patient's implantable device list, including:

○ Labeler Name (Manufacturer);

○ Brand Name;

○ Version or Model;

○ Global Medical Device Nomenclature Name;

○ Single Use indicator;

○ Labeled as containing natural rubber latex or dry natural rubber; and

○ MRI Safety Status.

• Accept electronic UDI data via automatic identification and data capture (AIDC) or other assistive technologies used in health care systems (e.g., bar code scanners and radio frequency identification).

• Use the device identifier portion of the UDI to obtain and incorporate GUDID device identification attributes in the patient's implantable device list.

• Use the device identifier or production identifier portions of the UDI to generate lists of patients with a particular implantable device.

• Make a UDI and its associated identification attributes accessible to the EHR technology for reporting purposes (e.g., adverse event reporting, registry population, recalls).

• Exchange a UDI and UDI data with procedure reporting systems (including adverse event incident reporting systems and medical specialty reporting systems) and other systems that associate a patient with a device.

• Expand these and other capabilities to additional types of devices used by patients.

We solicit comment on whether to propose these capabilities (or a subset thereof) for adoption in a subsequent rulemaking. We also request comment on other standards, capabilities, or certification criteria that we have not

identified but that would further our stated aims. Finally, we specifically seek input on the list of data elements that we have identified and whether we should propose these or other data elements in connection with this criterion.

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

2015 Edition EHR Certification Criteria

§ 170.315(b)(1) (Transitions of care)

Gap Certification Status

Ineligible

We propose to adopt a single 2015 Edition certification criterion for “transitions of care” (ToC). This proposed criterion would include significant modifications when compared to the two related 2014 Edition criteria adopted in the 2014 Edition Final Rule. This proposed criterion also reflects corresponding structural and clarifying changes that we have made to the proposed 2015 Edition “clinical information reconciliation and incorporation” certification criterion (discussed right after this criterion) and to the “view, download, transmit to third party (VDT)” certification criterion.

Our overall rationale for these proposed modifications is three-fold: 1) to further improve interoperability for ToC; 2) to improve the market availability of certified electronic exchange services for transport (and, thus, increase EPs, EHs, and CAHs' abilities to choose such services to demonstrate MU) by decoupling the 2014 Edition's ToC requirement to demonstrate both “content” and “transport” capabilities together in order to meet the two ToC certification criteria; and 3) to make the work-flow sequence we had in mind when we drafted the 2014 Edition criterion (at 45 CFR 170.314(b)(1)) clearer.

Interoperability for ToC is one of ONC's top priorities. ONC follows the definition of “interoperability” provided by the Institute for Electrical and Electronics Engineering Computer Dictionary which defines interoperability to mean: “

the ability of two or more systems or components to exchange information and to use the information that has been exchanged.”

With the adoption of a single content standard (Consolidated CDA) and “transport”/transmission standards as part of the 2014 Edition ToC certification criteria as well as the requirement that all EHR technology be certified to support transmissions in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification),

we made significant strides toward this definition.

See IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries (New York, NY: 1990).

http://wiki.directproject.org/file/view/Applicability+Statement+for+Secure+Health+Transport+v1.1.pdf.

With that in mind, the 2014 Edition certification criteria and corresponding MU Stage 2 measures have generated a significant amount of questions, requests for clarifications, and feedback related to how the ToC certification requirements could be improved in light of on-the-ground experience and challenges. We have reviewed and considered all of this feedback since the 2014 Edition Final Rule and now propose a suite of changes that we believe will address stakeholder concerns as well as enhance interoperability for this priority use case.

“Decoupling” Content and Transport

In the 2014 Edition Final Rule, we adopted two ToC certification criteria. The first, § 170.314(b)(1), requires EHR technology to be able to “receive, display, and incorporate” transition of care/referral summaries. The second, § 170.314(b)(2), requires EHR technology to be able to “create and transmit” transition of care/referral summaries.

These two 2014 Edition certification criteria require that EHR technology be able to “receive” and “transmit” a Consolidated CDA (“transition of care/referral summary”) in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification). Beyond the required transport standard (the primary Direct Project specification), we also included the option for EHR technology to be tested and certified to two other transport capabilities (i.e., Direct +XDR/XDM and SOAP + XDR/XDM).

As we indicated at the beginning of the preamble, the “scope” of a certification criterion begins at the second paragraph level of the regulatory section and encompasses all paragraph levels below the second paragraph level. Therefore, all capabilities under § 170.314(b)(1) and (b)(2)—including the transmission capabilities—must be demonstrated to meet each criterion as a whole. This means that under the 2014 Edition there is no way for EHR technology to be certified solely to perform the transport capabilities specified in each criterion.

Since the 2014 Edition Final Rule's publication, ONC has received specific feedback that this constraint or the “binding” of transport and content capabilities within the scope of a single certification criterion could impede innovation and limit EPs, EHs, and CAHs' market choices for electronic health information exchange services. Stakeholders also indicated that we had incorrectly imposed the coupling of technical capabilities that can be adequately performed by two different systems. They stated that content capabilities and transport capabilities should be separately tested and certified as the standard that supports one may change over time while the other remains the same.

This issue is best illustrated by the requirement in both 2014 Edition ToC criteria that EHR technology demonstrate its conformance to the primary Direct Project specification. As shown in the figure below, the primary Direct Project specification is not an “end-to-end” specification. Rather, the primary Direct Project specification is applicable to capabilities that are typically performed by what are called Health Information Service Providers or

HISPs. At times, an EHR technology may be designed with fully integrated HISP functions, but it is equally likely that third-party intermediaries will perform these capabilities. As a result, our 2014 Edition ToC criteria have resulted in HISP functionality being built into EHR technology (or, conversely, EHR functionality being built into a HISP solely for the HISP to meet the certification criteria).

• Figure 1: The primary Direct Project specification's applicability.

EP26FE14.000

We agree with stakeholder feedback that we should enable transport capabilities to be tested and certified separately from content capabilities. We also believe that permitting separate testing and certification for these capabilities would enable more transport-specific services to be certified as EHR Modules and, thus, would provide EPs, EHs, and CAHs with more choices in terms of the electronic health information exchange services they can use to demonstrate MU. Accordingly, we propose to adopt a single 2015 ToC certification criterion that focuses on content capabilities (create, receive, and display) and an EHR technology's ability to connect to a service that is conformant with the primary Direct Project specification through the use of a newly developed, “ONC Implementation Guide for Direct Edge Protocols, Version 1.0, January 10, 2014” (IG for Direct Edge Protocols),

which we propose to adopt at § 170.202(e). This proposal, in addition to our proposed revisions to the Base EHR definition to reference the 2015 Edition, continues to maintain and reinforce our overall policy that Certified EHR Technology must be able to perform transmissions in accordance with the primary Direct Project specification. The difference is that it enables transport capabilities to be separately tested and certified and separately implemented by EPs, EHs, and CAHs as a means to meet the Certified EHR Technology definition. We discuss our specific “transmission” certification criteria later in the preamble and our proposal to include them in a new regulatory paragraph “(h)” within § 170.315.

http://wiki.directproject.org/file/detail/Implementation+Guide+for+Direct+Edge+Protocols+v1.0.pdf.

Edge Protocol for EHR to HISP Connectivity for “Direct” Transmissions

As illustrated by Figure 1 and the arrows labeled with “edge,” the primary Direct Project specification focuses on HISP-to-HISP transactions and not on EHR-to-HISP transactions. Since the 2014 Edition Final Rule, the stakeholder community that participates in the Direct Project has produced a new implementation guide to clarify for EHR technology developers the standardized protocols that should be used to connect to a HISP (i.e., EHR-to-HISP).

This new implementation guide specifies that both a “Direct Edge System” (i.e., EHR technology) and a “Direct HISP System” must support at least one of the following protocols: IMAP4, POP3, SMTP, or IHE XDR.

While we propose a separate certification criterion for conformance to the primary Direct Project specification, we seek to maintain the same policy outcome we set in the 2014 Edition (i.e., that every EHR technology certified to ToC is capable of performing transmissions in accordance with the primary Direct Project specification). As a result, we propose that the 2015 Edition ToC certification criterion specify that EHR technology demonstrate it can send and receive transition of care/referral summaries in a transmission—that conforms to the IG for Direct Edge Protocols—which is used by a service that has implemented the primary Direct Project specification.

In other words, testing and certification to this portion of proposed 2015 Edition ToC certification criterion would require that EHR technology be able connect to a HISP following the IG for Direct Edge Protocols and enable that HISP to subsequently transmit the transition of care/referral summary using the primary Direct Project specification to a recipient. We emphasize that while the standard adopted at § 170.202(a) is still referenced in this proposed criterion, its reference is to solely express the technical outcome we expect to be demonstrated by EHR technology—that a transmission from EHR-to-HISP is successful in that the HISP can subsequently transmit the transition of care/referral summary. Again, these proposed revisions are to make clear that as a result of our proposal, we would no longer require testing and certification to the primary Direct Project specification as a condition of meeting this certification criterion.

Updated Consolidated CDA Standard

As expressed in the 2014 Edition Final Rule, the Consolidated CDA standard is now the single standard permitted for certification and the representation of summary care records. It is referenced in four proposed 2015 Edition certification criteria (ToC, VDT, Clinical Summary, Data Portability). Industry stakeholders have continued to work to improve and refine the Consolidated CDA standard since the 2014 Edition Final Rule.

An updated version, HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.0,

was balloted in August and September 2013. A reconciliation of comments received during balloting will be completed prior to the issuance of a final rule for this proposed rule. The currently balloted version includes the following changes which we believe provide important clarifications and enhancements:

http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2.

Access to the standard can be found at the following link, which requires the creation of an HL7 account:

http://www.hl7.org/documentcenter/public/ballots/2013SEP/downloads/CDAR2_IG_CCDA_CLINNOTES_DSTUR2_D1_2013SEP.zip.

• Addition of new structural elements: new document sections and data entry templates:

○ New Document Templates for: Care Plan; Referral Note; Transfer Summary.

○ New Sections for: Goals; Health Concerns; Health Status Evaluation/Outcomes; Mental Status; Nutrition; Physical Findings of Skin.

○ New organizers and many new entries (e.g. Wound Observation).

• Some sections/entries were deprecated (i.e., not in use any longer).

• Updates to (versioning of) template/section/entry object identifiers (OIDs).

○ This includes new chapter describing HL7's approach to template versioning.

• Tighter data constraints/requirements.

○ For example, some data elements with a “MAY” requirement now have a “SHOULD” requirement. Likewise, some with a “SHOULD” requirement now have a “MUST” requirement.

• Updated Vocabulary/Value Set constraints.

○ For example: two SNOMED CT codes were added to Current Smoking Status value set and Tobacco Use value set to support the 2014 Edition vocabulary requirements for patient smoking status.

○ NLM's VSAC was named as reference for Value Sets used in CCDA.

Accordingly, we propose to adopt the updated Consolidated CDA standard in § 170.205(a)(4) and we propose to reference its use in the proposed 2015 Edition ToC certification criterion as well as the three other certification criteria previously mentioned. We also propose to require (for reasons already provided as part our proposal for the “implantable device list” certification criterion) that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document.

Shifting “Incorporation” From ToC to Clinical Information Reconciliation

The 2014 Edition ToC certification criterion at § 170.314(b)(1)(A) and (B) requires EHR technology to demonstrate “[u]pon receipt of a transition of care/referral summary formatted according to the standard adopted at § 170.205(a)(3)” that it can properly match the transition of care/referral summary received to the correct patient; and electronically incorporate medications, problems, and medication allergy data. At the beginning of the 2014 Edition Final Rule we responded to comments on our proposed description for “incorporate” (77 FR 54168-54169) and stated that, “[w]e had revised our description of incorporation to reflect the common interpretation commenters stated they assigned to the term. Thus, when the term incorporate is used within a certification criterion it is intended to mean

to electronically process structured information from another source such that it is combined (in structured form) with information maintained by EHR technology and is subsequently available for use within the EHR technology by a user.”

We also responded to comments on this issue at 77 FR 54218 and offered a more nuanced response in the context of the 2014 Edition ToC certification criterion at § 170.314(b)(1) and the clinical information reconciliation certification criterion at § 170.314(b)(4):

[A]s we clarified in the beginning of this final rule, we intended for the term “incorporate” to mean that EHR technology would be able to process the structured data contained in those three Consolidated CDA sections (medications, problems, medication allergies) such that it could be combined (in structured form) with data already maintained by EHR technology and would subsequently be available for use, such as to be used as part of the clinical information reconciliation capabilities (expressed in the certification criterion adopted at (§ 170.314(b)(4)).

Stakeholders have indicated confusion regarding this preamble explanation and questioned the workflow assumption we had in mind when placing the “incorporation” capability in the ToC certification criterion. They indicated that in a typical workflow, inbound data is first reconciled and then incorporated (which makes it subsequently available for use within the EHR technology). Thus, our explanation that incorporated information as part of the ToC certification criterion would “subsequently be available for use, such as to be used as part of the clinical information reconciliation capabilities” misstated the workflow.

To avoid future confusion, the proposed 2015 Edition ToC certification no longer references the 2014 Edition's “incorporation” capabilities at § 170.314(b)(1)(A) and (B) and instead, we propose to place those capabilities in the proposed 2015 Edition “clinical information reconciliation and incorporation” certification criterion. We believe this revision will clarify the interplay between these two certification criteria and will clear up any misconceptions about the anticipated workflow. The specific capabilities for “section views” expressed at § 170.314(b)(1)(C) would continue to remain as part of our proposed 2015 Edition ToC criterion because they focus on content capabilities.

ToC Interoperability and MU Stage 2 “Cross-Vendor” Exchange Proposals

As part of the EHR Incentive Programs Stage 2 proposed rule, CMS proposed a new measure for its “Transitions of Care objective” that would have limited the new measure's numerator to only permit electronic transmissions to count if they were made to recipients that were: “(1) Not within the organization of the transmitting provider; and (2) did not have Certified EHR Technology from the same EHR vendor” (77 FR 13724). This proposal sought to use the EHR Incentive Programs to reward this outcome and, by virtue of setting this outcome, give EPs, EHs, and CAHs as well as EHR technology developers an explicit reason to implement solutions that promote interoperable electronic health information exchange.

Public comment on these proposals raised numerous concerns, including (among other issues) geographic market share constraints and undue burden because both limitations would be hard to do determine in an automated way. In response, CMS ultimately decided not to retain either of the proposed numerator limitations (77 FR 54019). CMS did, however, adopt a third ToC measure for MU Stage 2 that requires EPs, EHs, and CAHs to “conduct one or more successful electronic exchanges of a summary of care document, which is counted in measure 2 with a recipient who has EHR technology designed by a different EHR technology developer than the sender's EHR technology certified to 45 CFR 170.314(b)(2); or conduct one or more successful tests with the CMS designated test EHR during the EHR reporting period.”

While the measurement burden associated with the “cross vendor” numerator limitation proved too difficult a concept to implement, we have continued to consider ways to reach this same outcome. First, we keep in mind that the proposed cross-vendor numerator limitation was imposed on the “sender.” The sender, upon transmission of a summary care record, would need to know if the recipient had a different EHR technology developer's product than they did in order to determine whether that transmission could be counted in the numerator. Second, we considered solutions. One theoretical solution we considered would be to automate the sender's measurement. This would require EHR technology (through certification) to send an acknowledgement with the EHR technology developer's name or other identifier upon receipt of a summary care record. This “solution,” however, would require modifications to existing technical standards and would be insufficient (and really a partial solution) because EPs, EHs, and CAHs, can (today) electronically transmit summary care records to non-MU providers for ToC and count such transmissions in their numerator. Thus, health care providers who have no incentive to adopt CEHRT would not necessarily have the capability to

respond with this kind of acknowledgement and there would still be situations where EPs, EHs, and CAHs would have to manually count transmissions.

As we took a step back to assess this proposal's viability, we realized its purpose would be to solve a measurement problem and not an interoperability problem. Thus, we reassessed the true “problem” we (ONC) were trying to solve—interoperability—and, more specifically, the “use” aspect of the interoperability definition we follow. Given that our 2014 Edition ToC certification criteria require EHR technology to be able to receive and transmit Consolidated CDAs in accordance with the primary Direct Project specification, EPs, EHs, and CAHs will have the ability to “exchange” with any other EHR technology. However, it remains unclear whether each individual EP, EH, or CAH will be able to effectively use the Consolidated CDA it receives. While the Consolidated CDA is the only standard we permit for summary care record creation, its specifications permit a certain level of optionality and variability. As a result, while two different certified EHR technologies can accomplish “exchange” with a validly implemented Consolidated CDA, the recipient may be unable to correctly or accurately parse a part or all of the Consolidated CDA. Early feedback from a handful of stakeholders has indicated that such events do occur.

We believe that EHR technology certification can improve this aspect of interoperability and, in turn, get us closer to the ultimate outcome that was intended by the original MU Stage 2 proposal—which is that an EP, EH, or CAH could both exchange a Consolidated CDA with any other EHR technology and be able to subsequently use the Consolidated CDA it receives. This is a fundamental capability needed beyond MU and will be critical to help advance delivery reform goals. Achieving this interoperability goal also closes a gap that meaningful use policy is not well positioned to impact (i.e., the capabilities of a recipient of electronically transmitted health information).

To do this, we propose to adopt a “performance standard” that would require EHR technology to successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time. Note that this creates different capability requirements for certification within this criterion for “receive” than it does for the capabilities associated with creation of a Consolidated CDA for transmission. In other words, for certification, EHR technology would be permitted to create a Consolidated CDA that conformed to a particular and acceptable variation of the Consolidated CDA standard (given the optionality in the standard). However, for receipt of Consolidated CDAs, EHR technology would need to be able to receive no less than 95% of all of the possible variations that could be implemented under the standard. We also clarify that this performance standard's scope would be limited to the Consolidated CDAs' implementation of the data we require in this certification criterion (i.e., testing for the performance standard would not go beyond the header requirements and specific data required by the certification criterion). This proposed outcome has the effect of requiring EHR technology to be resilient when it comes to receiving Consolidated CDAs that have been configured differently (i.e., able to handle differently formatted Consolidated CDA without failing). While it is not unreasonable (from a user's perspective) to expect their EHR technology to perform with 99% or greater accuracy when it comes to processing Consolidated CDAs, we believe that 95% would be an appropriate initial performance threshold to adopt while still ensuring that users are not adversely impacted by poor performance. As discussed in the S&CC January 2010 interim final rule (75 FR 2021), we defined the term

“standard”

in 45 CFR 170.102 and stated, “[w]e believe the types of standards envisioned by Congress in the HITECH Act that would be most applicable to HIT are standards that are technical, functional, or performance-based.”

Accordingly, we propose to adopt this new performance standard in section 212 of part 170 entitled “Performance Standards for Health Information Technology.” Further, we propose to reference this performance standard in the proposed 2015 Edition ToC certification criterion as a capability that must be demonstrated to meet the certification criterion.

We seek comment on whether the performance level should be set to 95% and request that commenters provide accompanying rationale for why it should be lower or higher. Further, our early thoughts around the testing approach for this part of the certification criterion are that it would involve EHR technology receiving some number of Consolidated CDAs (e.g., 100 to 1000) each formatted slightly (but validly) differently, or produced by different EHR technologies previously through testing, or both. Given that testing could be conducted in numerous different ways, we seek input on and suggestions on the best way(s) to test this proposal. We also seek input from industry stakeholders on the best ways to identify additional guidance for the Consolidated CDA that will further reduce its implementation variability and, ultimately, make achieving this performance standard simply a byproduct of implementing a tightly specified implementation guide.

While there is still a risk that EHR technology developers could deploy electronic transmission capabilities in ways that continue to make it difficult for EPs, EHs, and CAHs to exchange Consolidated CDAs with EHR technologies designed by different EHR technology developers, we believe that this proposal in combination with potential future proposals in MU to increase electronic exchange requirements can achieve the overall outcome EPs, EHs, and CAHs expect—that they will be able to exchange summary care records and upon receipt be able to use them without additional burden.

“Create” and Patient Matching Data Quality

In 2011, both the HITPC and HITSC made recommendations to ONC on patient matching. The HITPC made recommendations in the following five categories: Standardized formats for demographic data fields, internally evaluating matching accuracy, accountability, developing, promoting and disseminating best practices, and supporting the role of the individual/patient.

The HITSC made four recommendations: Detailing patient attributes that could be used for matching (in order to understand the standards that are needed), data quality, formats for these data elements, and what data are returned from a match request.

The standards recommended by the HITSC are as follows:

http://www.healthit.gov/sites/default/files/hitpc-transmittal-letter-priv-sectigerteam-020211.pdf

http://www.healthit.gov/FACAS/sites/default/files/standards-certification/8_17_2011Transmittal_HITSC_Patient_Matching.pdf

•

Basic Attributes:

Given Name; Last Name; Date of Birth; Administrative Gender.

Despite its inclusion of the word “gender,” “Administrative Gender” is generally used in standards to represent a patient's “sex” as male, female, or undifferentiated. See:

http://ushik.ahrq.gov/ViewItemDetails?system=hitsp&itemKey=83680000

•

Other Attributes:

Insurance Policy Number; Medical Record Number; Social Security Number (or last 4 digits); Street Address; Telephone Number; Zip Code.

•

Potential Attributes:

Email Address; Voluntary Identifiers; Facial Images; Other Biometrics.

In July 2013, ONC launched an initiative to reinvigorate public discussion around patient matching, to perform a more detailed analysis of patient matching practices, and to identify the standards, services, and policies that would be needed to implement the HITPC and HITSC's recommendations. Although this initiative's first phase focused on a common set of patient attributes that could be leveraged from current data and standards referenced in our certification criteria, we recognize that additional, broader industry needs exist when it comes to methods related to patient matching and the attributes with which matching is performed. Some of these broader needs include the ability to link patient data across time for a longitudinal record, linking across different data sources in a health information exchange organization/network, and linking administrative data to clinical data for outcomes research. Additionally, new matching techniques that are beginning to leverage novel and large data sources suggest that now is the right time to review patient matching needs across the industry at large and how EHR technology can be one part of the solution.

Given these initial findings, we propose to include a limited set of standardized data as a part of the “Create” portion of the ToC criterion to improve the quality of the data included in outbound summary care records. We seek comment on additional data to include and other constraints that could be applied to this data to improve its quality. To be clear, this proposal does

not

require EHR technology to capture the data upon data entry, but rather at the point when the data is exchanged (an approach commonly used for matching in HL7 transactions, IHE specifications,

Consolidated CDA (C-CDA) specification, and the eHealth Exchange). The proposed standardized data include: First name, last name, middle name (or middle initial in cases where only it exists/is used), suffix, date of birth, place of birth, maiden name, current address, historical address, phone number, and sex. Additional feedback we have received suggests that use of data elements that do not change over time (e.g., place of birth, maiden name) could improve the patient matching results. In the bulleted list below, we identify more constrained specifications for some of the standardized data we propose. Based on our own research, we do not believe that the proposed constraints to these data conflict with the Consolidated CDA. That being said, some proposed constraints may further restrict the variability as permitted by existing specifications and others may create new restrictions that do not currently exist within the Consolidated CDA. We propose that:

http://www.ihe.net/Technical_Frameworks/

• For “last name/family name” the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0

(which addresses whether suffix is included in the last name field) be followed.

http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf

• For “suffix,” that the suffix should follow the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D., ESQ)

and that if no suffix exists, the field should be marked as null.

http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf

• For “date of birth,” that the year, month and date of birth should be required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in the latter local time is assumed. If date of birth is unknown, the field should be marked as null.

• For “current address” and “historical address,” be represented in United States Postal Service (USPS)

format. And, if a historical address is unavailable, that the value should be entered as null.

http://pe.usps.com/text/pub28/

• For “phone numbers,” the ITU format specified in ITU-T E.123

and ITU-T E.164

be followed and that the capture of home, business, and cell phone numbers be allowed.

Further, that if multiple phone numbers are present in the patient's record, all should be included in the Consolidated CDA and transmitted.

http://www.itu.int/rec/T-REC-E.123-200102-I/e

http://www.itu.int/rec/T-REC-E.164-201011-I/en

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186

• For “sex” we propose to require developers to follow the HL7 Version 3 Value Set for Administrative Gender, which includes M (Male), (Female) and UN (Undifferentiated) as options.

http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.1.11.1

We seek comment on the proposed standardized data to improve patient matching, including whether other data or constraints on proposed data should be modified to better support patient matching practices and work flow. For example, stakeholders have suggested that using the United States Postal Service (USPS) “Address Information” application program interface (API) that standardizes addresses as a way to ensure addresses are formatted in a consistent manner. While we believe this idea has merit, the USPS terms and conditions

currently appear to exclude this API's use for this purpose because it only permits users to “use the USPS Web site, APIs and USPS data to facilitate USPS shipping transactions only.” Similarly, we request comment on how to best handle or anticipate changes to the way in which data may be represented in other rapidly evolving standards approaches. For instance, we are aware that V2 and V3 HL7 standards use an identical format for date of birth, but the more recent Fast Health Interoperable Resources (FHIR) standards framework uses a different format. Others have suggested that we need to adopt international standards for address, for military purposes or for patients who live outside of the U.S., but have health care delivered within the U.S. More specifically, USPS expects

numbers

for ZIP code. Thus, we would be interested in stakeholder feedback regarding what standards could best support international addresses (for example, ISO 19160-4

which appears on a trajectory to reference/include to Universal Postal Union (UPU) S42).

https://secure.shippingapis.com/registration/

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64242

http://www.upu.int/uploads/tx_sbdownloader/sheetAddressingS42InternationalAddressingStandardsFactSheetEn.pdf

In addition, we seek comment on approaches to address other recommendations from the HITSC. For example, data quality is an important aspect of patient matching success. We seek comment on methods that leverage the certification program, ways to test and measure data quality, and approaches to sharing best practices for improving data quality.

Finally, we seek comment on additional findings from the 2013 Patient Matching Initiative that include studying non-traditional attributes to understand the potential for matching improvement, developing open source algorithms for testing purposes or use by EHR technology developers, the development of a formalized structure for establishing best practices, advancing consumer engagement with and access to their demographic data

and attributes for correction or approval, and developing and/or disseminating options and training materials that improve data quality.

• Clinical Information Reconciliation and Incorporation

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.

2015 Edition EHR Certification Criterion

§ 170.315(b)(2) (Clinical information reconciliation and incorporation)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. As discussed in more detail directly above in the 2015 Edition ToC certification criterion section

Shifting “Incorporation” From ToC to Clinical Information Reconciliation

“reconciliation” and “incorporation” capabilities were referenced in two separate 2014 Edition certification criteria. For the reasons discussed in the 2015 Edition ToC section above, we propose that the 2015 Edition “clinical information reconciliation and incorporation” certification criterion include the capabilities that are part of the 2014 Edition ToC certification criterion at § 170.314(b)(1)(A) and (B). Again, we believe that this change will make the workflow designed to meet this certification criterion clearer.

We also solicit comment on whether for our 2017 Edition rulemaking we should broaden the data that this certification criterion requires to be reconciled beyond medications, medication allergies, and problems and, if so, what other data we should consider referencing. Additionally, we solicit comment on whether EHR technology should be required to retain the outside/external data source's provenance as part of the incorporation process.

• Electronic Prescribing

MU Objective

Generate and transmit permissible prescriptions electronically (eRx).

2015 Edition EHR Certification Criterion

§ 170.315(b)(3) (Electronic prescribing)

Gap Certification Status

Eligible

We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version.

• Incorporate Laboratory Tests and Values/Results

MU Objective

Incorporate clinical laboratory test results into Certified EHR Technology as structured data.

2015 Edition EHR Certification Criterion

§ 170.315(b)(4) (Incorporate laboratory tests and values/results)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition that includes the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata

in the 2015 Edition “transmission of electronic laboratory tests and values/results to ambulatory providers” certification criterion. This IG is the same guide adopted for the equivalent 2014 Edition certification criteria, but with the errata. The errata address technical corrections and clarifications for interoperability with the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, DSTU Release 1, US Realm, 2013

and other laboratory domain IGs.

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279

We have proposed to adopt this implementation guide for the 2015 Edition “CPOE for laboratory orders” certification criterion.

As compared to the 2014 Edition certification criterion, we also propose more specific requirements for how EHR technology must be capable of electronically displaying the information included in a test report. This specificity would improve the consistency with how laboratory tests and values/results are displayed, which would also assist with laboratory compliance with CLIA as we discuss in more detail earlier in this section (III.A) of the preamble under the “

Computerized Provider Order Entry—Laboratory.”

This functionality would require EHR technology to be capable of displaying the following information included in laboratory test reports it receives: (1) The information for a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); the information related to reference values as specified in 42 CFR 493.1291(d); the information for alerts and delays as specified in 42 CFR 493.1291(g) and (h); and the information for corrected reports as specified in 42 CFR 493.1291(k)(2).

We propose to adopt the updated S&I Framework LRI at § 170.205(j)(2), which requires the modification of the regulatory text hierarchy in § 170.205(j) to designate the standard referenced by the 2014 Edition version of this certification criterion at § 170.205(j) to be at § 170.205(j)(1). This regulatory structuring of the IGs would make the CFR easier for readers to follow.

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

MU Objective

Provide structured electronic laboratory results to eligible professionals.

2015 Edition EHR Certification Criterion

§ 170.315(b)(5) (Inpatient setting only—transmission of electronic laboratory tests and values/results to ambulatory providers)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition certification criterion that includes the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata

and other laboratory domain IGs.

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279

We have proposed to adopt this implementation guide for the 2015 Edition “CPOE for laboratory orders” certification criterion.

As compared to the 2014 Edition certification criterion, we also propose to include new functionality that would improve the consistency with how laboratory tests and values/results are sent, received, and displayed. This would also assist with laboratory compliance with CLIA as we discuss in more detail earlier in this section (III.A) of the preamble under the “

Computerized Provider Order Entry—Laboratory.”

This new functionality would require EHR technology to be capable of including in the laboratory test reports it creates for electronic transmission: (1) The information for a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); the information related to reference values as specified in 42 CFR 493.1291(d); the information for alerts and delays as specified in 42 CFR 493.1291(g) and (h); and the information for corrected reports as specified in 42 CFR 493.1291(k)(2).

• Data Portability

MU Objective

N/A

2015 Edition EHR Certification Criterion

§ 170.315(b)(6) (Data portability)

Gap Certification Status

Ineligible

We propose to adopt a 2015 Edition “data portability” certification criterion that revises the 2014 Edition version. Our first proposal, for consistency across other certification criteria revisions, is to also have this certification criterion reference the updated Consolidated CDA (Draft Standard for Trial Use, Release 2.0) standard we discuss in more detail in the ToC certification criterion portion of this preamble. Our second proposal (for reasons already provided as part our proposal for the “implantable device list” certification criterion) is that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document.

We also solicit public comment on the following:

(1) Whether we should rename this certification criterion “data migration.” Given that the “view, download, transmit to 3rd party” certification criterion addresses data availability from a patient's perspective, this certification criterion has always been more focused on data availability from a health care provider's perspective. We believe that a more precise label for this certification criterion could prevent confusion as to its focus.

(2) Whether we should consider adding more requirements for the 2017 Edition version of this certification criterion that we would propose in a future rulemaking and what those requirements should be. For example, should this criterion focus on an expanded time boundary to allow for more longitudinal data to be exported and should it reference more data? Can additional electronic notes be included in a data portability requirement with the addition of header metadata to support export/import functions?

(3) Whether we should change this certification criterion as part of a 2017 Edition proposal to promote a broader range of use cases, including: (1) Local access/query (i.e., a provider's ability to access their own data through, for example, an API); (2) targeted access/inter-organizational query (i.e., a provider's ability to query data from another provider or specific location, such as when one provider performs a “targeted query” to obtain a patient's information from another provider); and (3) distributed, multi-source access/query (i.e., a provider's ability to disseminate queries to multiple organizations). This change could result in multiple use case specific certification criteria if appropriate.

• Clinical Quality Measures

Electronically Processing eMeasures

None of our prior rulemakings have included a proposal to adopt standards and EH

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.