2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications

Federal RegisterOct 16, 2015

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

2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications

AGENCY:

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

ACTION:

Final rule.

SUMMARY:

This final rule finalizes a new edition of certification criteria (the 2015 Edition health IT certification criteria or “2015 Edition”) and a new 2015 Edition Base Electronic Health Record (EHR) definition, while also modifying the ONC Health IT Certification Program to make it open and accessible to more types of health IT and health IT that supports various care and practice settings. The 2015 Edition establishes the capabilities and specifies the related standards and implementation specifications that Certified Electronic Health Record Technology (CEHRT) would need to include to, at a minimum, support the achievement of meaningful use by eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) when such edition is required for use under these programs.

DATES:

These regulations are effective January 14, 2016, except for § 170.523(m) and (n), which are effective on April 1, 2016.

The incorporation by reference of certain publications listed in the rule is approved by the Director of the

Federal Register

as of January 14, 2016.

FOR FURTHER INFORMATION CONTACT:

Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION:

Commonly Used Acronyms

API Application Programming Interface

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 IT Product List

CLIA Clinical Laboratory Improvement Amendments

CMS Centers for Medicare & Medicaid Services

CQM Clinical Quality Measure

EHR Electronic Health Record

FDA Food and Drug Administration

HHS Department of Health and Human Services

HISP Health Information Service Providers

HIT Health Information Technology

HITPC HIT Policy Committee

HITSC HIT Standards Committee

HL7 Health Level Seven

IG Implementation Guide

LOINC® Logical Observation Identifiers Names and Codes

NIST National Institute of Standards and Technology

ONC Office of the National Coordinator for Health Information Technology

SDO Standards Developing Organization

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 Health IT Certification Criteria

2. Health IT Definitions

3. The ONC Health IT Certification Program and Health IT Module

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. HIT Certification Programs

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

2. Medicare and Medicaid EHR Incentive Programs Rules

3. ONC Health IT Certification Programs Rules

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

A. 2015 Edition Health IT Certification Criteria

1. Applicability

2. Standards and Implementation Specifications

3. Adopted Certification Criteria

4. 2015 Edition Gap Certification Eligibility Table

5. Not Adopted Certification Criteria

B. Health IT Definitions

1. Base EHR Definitions

2. Certified EHR Technology Definition

3. Common Clinical Data Set Definition

4. Cross-Referenced FDA Definitions

IV. Provisions of the Proposed Rule Affecting the ONC Health IT Certification Program

A. Subpart E—ONC Health IT Certification Program

B. Modifications to the ONC Health IT Certification Program

1. Health IT Modules

2. “Removal” of Meaningful Use Measurement Certification Requirements

3. Types of Care and Practice Settings

4. Referencing the ONC Health IT Certification Program

C. Health IT Module Certification Requirements

1. Privacy and Security

2. Design and Performance (§ 170.315(g))

D. Principles of Proper Conduct for ONC-ACBs

1. “In-the-Field” Surveillance and Maintenance of Certification

2. Transparency and Disclosure Requirements

3. Open Data Certified Health IT Product List (CHPL)

4. Records Retention

5. Complaints Reporting

6. Adaptations and Updates of Certified Health IT

E. “Decertification” of Health IT—Request for Comments

V. Incorporation by Reference

VI. Collection of Information Requirements

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

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

Building on past rulemakings, we issued a proposed rule (“Proposed Rule”) (80 FR 16804) that identified how health IT certification to the proposed 2015 Edition health IT certification criteria could support the establishment of an interoperable nationwide health information infrastructure. The Proposed Rule reflected stakeholder feedback received through various outreach initiatives, including the regulatory process, and was designed to broadly support the health care continuum through the use of certified health IT. This final rule, taking into account public comments received on the Proposed Rule, continues to focus on the establishment of an interoperable nationwide health information infrastructure, through the same means identified in the Proposed Rule and recited below, but with an additional focus on reducing health IT developer and provider burden as compared to the Proposed Rule. To this end, this final rule will:

• Improve interoperability for specific purposes by adopting new and updated vocabulary and content standards for the structured recording and exchange of health information, including a Common Clinical Data Set composed primarily of data expressed using adopted standards; and rigorously testing an identified content exchange

standard (Consolidated Clinical Document Architecture (C-CDA));

• Facilitate the accessibility and exchange of data by including enhanced data export, transitions of care, and application programming interface (API) capabilities in the 2015 Edition Base Electronic Health Record (EHR) definition;

• Establish a framework that makes the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program open and accessible to more types of health IT, health IT that supports a variety of care and practice settings, various HHS programs, and public and private interests;

• Support the Centers for Medicare & Medicaid Services (CMS) Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) through the adoption of a set of certification criteria that align with proposals for Stage 3;

• Address health disparities by providing certification: to standards for more granular capture of race and ethnicity; the collection of sexual orientation, gender identity, social, psychological, and behavioral data; for the exchange of sensitive health information (Data Segmentation for Privacy); and for the accessibility of health IT;

• Ensure all health IT presented for certification possess the relevant privacy and security capabilities;

• Improve patient safety by: applying enhanced user-centered design principles to health IT, enhancing patient matching, requiring health IT to be capable of exchanging relevant patient information (

e.g.

, Unique Device Identifiers), improving the surveillance of certified health IT, and making more information about certified products publicly available and accessible;

• Increase the reliability and transparency of certified health IT through surveillance and disclosure requirements; and

• Provide health IT developers with more flexibility, opportunities, and

time

for development and certification of health IT that supports interoperability, usability, and innovation.

B. Summary of Major Provisions

1. Overview of the 2015 Edition Health IT Certification Criteria

The 2015 Edition health IT certification criteria (“2015 Edition” or “2015 Edition certification criteria”) facilitates greater interoperability for several clinical health information purposes and enables health information exchange through new and enhanced certification criteria, standards, and implementation specifications. It incorporates changes that are designed to spur innovation, open new market opportunities, and provide more choices to providers when it comes to electronic health information exchange. To achieve these goals, new “application access” (also known as “API”) certification criteria have been adopted that will require the demonstration of an API that responds to data requests for any one category of the data referenced in the Common Clinical Data Set as well as for all of the data referenced in the Common Clinical Data Set. We note that in response to comments, we have separated this criterion into 3 criteria to provide health IT developers and providers more flexibility. To further validate the continued interoperability of certified health IT and the ability to exchange electronic health information with health IT certified to the 2014 Edition, 2015 Edition, and potentially future editions, a new “transitions of care” certification criterion will rigorously assess a product's ability to create and receive an interoperable C-CDA. We have also adopted certification criteria that both support interoperability and other settings and use cases, such as the “Common Clinical Data Set summary record,” “data segmentation for privacy,” and “care plan” certification criteria.

We refer readers to section III.A for an overview table (Table 2) of certification criteria adopted in this final rule as compared to the certification criteria proposed in the Proposed Rule and the adopted 2014 Edition. We also refer readers to sections III.A.3 and III.A.5 of this preamble for full discussions of certification criteria adopted as part of the 2015 Edition in this final rule (III.A.3) and the proposed certification criteria not adopted in this final rule (III.A.5).

2. Health IT Definitions

a. Base EHR Definitions

This final rule adopts a Base EHR definition specific to the 2015 Edition (

i.e.,

a 2015 Edition Base EHR definition) at § 170.102 and renames the current Base EHR definition at § 170.102 as the 2014 Edition Base EHR definition. The 2015 Edition Base EHR definition differs from the 2014 Edition Base EHR definition in the following ways:

• It does not include privacy and security capabilities and certification criteria.

• It only includes capabilities to record and export clinical quality measure (CQM) data (§ 170.315(c)(1)) and not other CQM capabilities such as import, calculate, and “report to CMS.”

• It includes the 2015 Edition “smoking status” certification criterion as patient demographic and clinical health information data consistent with statutory requirements.

A Base EHR is the regulatory term we have given to what the HITECH Act defines as a “qualified EHR.” Our Base EHR definition(s) include all capabilities found in the “qualified EHR.” Please see the 2014 Edition final rule (77 FR 54262) for further explanation.

• It includes the 2015 Edition “implantable device list” certification criterion as patient demographic and clinical health information data consistent with statutory requirements.

A capability included in the Base EHR definition, which originates from the “qualified EHR” definition found in the HITECH Act.

• It includes the 2015 Edition “API” certification criteria as capabilities that support both the capture and query of information relevant to health care quality and exchange electronic health information with, and integrate such information from other sources.

These are capabilities included in the Base EHR definition, which originate from the “qualified EHR” definition found in the HITECH Act.

• It includes the proposed 2015 Edition certification criteria that correspond to the remaining 2014 Edition certification criteria referenced in the “2014 Edition” Base EHR definition (

i.e.

, CPOE, demographics, problem list, medication list, medication allergy list, CDS, transitions of care, data portability, and relevant transport certification criteria). For the transport certification criteria, we include the “Direct Project” criterion (§ 170.315(h)(1)) as well as the “Direct Project, Edge Protocol and XDR/XDM” criterion (§ 170.315(h)(2)) as equivalent alternative means for meeting the 2015 Edition Base EHR definition.

We refer readers to section III.B.1 of this preamble for a more detailed discussion of the 2015 Edition Base EHR definition and to section III.A.3 of this preamble for a full discussion of the criteria that have been included in the Base EHR definition. Of note, the “demographics” certification criterion (§ 170.315(a)(5)) now includes sexual orientation and gender identity as data elements, the “smoking status” certification criterion (§ 170.315(a)(11)) is now only a functional requirement, the “API” criterion has been separated into 3 distinct criteria as mentioned above, and the Direct-related criteria have been updated from “unchanged” to “revised” to incorporate updated and necessary interoperability standards.

As discussed in more detail under the “privacy and security” heading in section IV.C.1 of this preamble, Health

IT Modules presented for certification to criteria listed in the 2015 Base EHR definition and other 2015 Edition certification criteria

will be

subject to the applicable privacy and security criteria for the purposes of certification.

The CQM capabilities noted above as not included in the 2015 Edition Base EHR definition have, however, been included the Certified EHR Technology (CEHRT) definition under the EHR Incentive Programs. We refer readers to the next section (“b. CEHRT definition”) for further information and guidance on the relationship of the 2015 Edition Base EHR definition and the 2015 Edition certification criteria with the CEHRT definition. We also refer readers to the CEHRT definition finalized in the EHR Incentive Programs Stage 3 and Modifications final rule published elsewhere in this issue of the

Federal Register

as the authoritative source for the requirements to meet the CEHRT definition.

b. CEHRT Definition

This final rule removes the CEHRT definition from § 170.102 for the following reasons. The CEHRT definition has always been defined in a manner that supports the EHR Incentive Programs. As such, the CEHRT definition more appropriately resides solely within the EHR Incentive Programs regulations. This is also consistent with our approach in this final rule to make the ONC Health IT Certification Program more open and accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond those included in the EHR Incentive Programs. Further, this adds administrative simplicity in that regulatory provisions, which EHR Incentive Programs participants must meet (

e.g.

, the CEHRT definition), are defined within the context of rulemakings for those programs.

We note that the CEHRT definition finalized by CMS continues to include the Base EHR definition(s) defined by ONC, including the 2015 Edition Base EHR definition adopted in this final rule. We also refer readers to Table 4 (“2015 Edition Health IT Certification Criteria Associated with the EHR Incentive Programs Stage 3”) found in section III.A.3 of this preamble. Table 4 crosswalks 2015 Edition certification criteria with the finalized CEHRT definition and EHR Incentive Programs Stage 3 objectives. It also identifies mandatory and conditional certification requirements (

i.e.

, the application of certain certification criteria to Health IT Modules) that Health IT Modules presented for certification must meet regardless of the setting or program the Health IT Module is designed to support.

For the full requirements to meet the CEHRT definition under the EHR Incentive Programs, including for years before 2018 and for 2018 and subsequent years, we refer readers to the EHR Incentive Programs Stage 3 and Modifications final rule published elsewhere in this issue of the

Federal Register

c. Common Clinical Data Set

We revised the “Common MU Data Set” definition in § 170.102. We changed the name to “Common Clinical Data Set,” which aligns with our approach throughout this final rule to make the ONC Health IT Certification Program more open and accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond those included in the EHR Incentive Programs. We also changed references to the “Common MU Data Set” in the 2014 Edition (§ 170.314) to “Common Clinical Data Set.”

We revised the definition to account for the new and updated standards and code sets we have adopted in this final rule for the 2015 Edition that will improve and advance interoperability through the exchange of the Common Clinical Data Set. We also revised the definition to support patient safety and improve care through clearly referenced data elements (“care plan data”) and the inclusion of new patient data (

e.g.

, Unique Device Identifiers (UDIs) and immunizations (with standards)). These revisions will

not

change the standards, codes sets, and data requirements specified in the Common Clinical Data Set for 2014 Edition certification, which remain unchanged. They only apply to health IT certified to the 2015 Edition certification criteria that reference the Common Clinical Data Set.

We refer readers to section III.B.3 of this preamble for a detailed discussion of the Common Clinical Data Set and a table listing the data and standards included in the Common Clinical Data Set for both the 2014 and 2015 Editions.

3. The ONC Health IT Certification Program and Health IT Module

We have changed the name of the ONC HIT Certification Program to the “ONC Health IT Certification Program.” We have also modified the ONC Health IT Certification Program in ways that will make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings. These modifications will also serve to support other public and private programs that may reference the use of health IT certified under the ONC Health IT Certification Program. When we established the certification program (76 FR 1262),

we stated our initial focus would be on EHR technology and supporting the EHR Incentive Programs, which at the time, focused on the ambulatory setting and inpatient setting (76 FR 1294).

Please see section II.B.3 of this preamble for a regulatory history of the ONC Health IT Certification Program, including changes to the program's name.

This final rule permits other types of health IT, such as technology implemented by health information service providers (HISPs) and health information exchanges (HIEs), to receive appropriate attribution and not be referenced by a certificate with “EHR” included in it. This final rule also supports health IT certification for other care and practice settings, such as long-term post-acute care (LTPAC), behavioral health, and pediatrics. Further, this final rule will make it simpler for certification criteria and certified health IT to be referenced by other HHS programs (

e.g.

, Medicare and Medicaid payment programs and various grant programs), other public programs, and private entities and associations.

a. Program Alignment Changes

As part of our approach to evolve the ONC Health IT Certification Program, we have replaced prior rulemaking use of “EHR” and “EHR technology” with “health IT.” The term health IT is reflective of the scope of ONC's authority under the Public Health Service Act (§ 3000(5) as “health information technology” is so defined), and represents a broad range of technology, including EHR technology. It also more properly represents some of the technology, as noted above, that has been previously certified to editions of certification criteria under the ONC Health IT Certification Program and may be certified to the 2015 Edition. Similarly, to make the ONC Health IT Certification Program more open and accessible, we have renamed the EHR Module as “Health IT Module.”

b. “Meaningful Use Measurement”

We have adopted our proposed approach in that we will not require ONC-Authorized Certification Bodies (ONC-ACBs) to certify Health IT Modules to the 2015 Edition “meaningful use measurement” certification criteria. We note, however, that

CMS has included

the 2015 Edition

“meaningful use measurement” certification criteria in the CEHRT definition as a program requirement for the EHR Incentive Programs. Accordingly, we encourage health IT developers supporting providers participating in the EHR Incentive Programs or providers' quality improvement needs to seek certification to these criteria as appropriate for their Health IT Modules (

e.g.

, a Health IT Module is presented for certification to a criterion that supports a Stage 3 objective with a percentage-based measure and the Health IT Module can meet the “automated numerator recording” criterion or “automated measure calculation” criterion).

c. Privacy and Security Certification Framework

We have adopted a new, simpler, straight-forward approach to privacy and security certification requirements for Health IT Modules certified to the 2015 Edition. In sum, the privacy and security certification criteria applicable to a Health IT Module presented for certification is based on the other capabilities included in the Health IT Module and for which certification is sought. Under the 2015 Edition privacy and security certification framework, a health IT developer will know exactly what it needs to do in order to get its Health IT Module certified and a purchaser of a Health IT Module will know exactly what privacy and security functionality against which the Health IT Module had to be tested in order to be certified.

d. Principles of Proper Conduct (PoPC) for ONC-ACBs

We have adopted new and revised PoPC for ONC-ACBs. ONC-ACBs are now required to report an expanded set of information to ONC for inclusion in the open data file that would make up the Certified Health IT Product List (CHPL). ONC-ACBs must ensure that health IT developers provide more meaningful disclosure of certain types of costs and limitations that could interfere with the ability of users to implement certified health IT in a manner consistent with its certification. ONC-ACBs must retain records for a period of time that will support HHS program needs. ONC-ACBs must also obtain a record of all adaptations and updates affecting “safety-enhanced design” criteria on a quarterly basis each calendar year. ONC-ACBs must also report to the National Coordinator complaints received on certified health IT. We have also adopted new requirements for “in-the-field” surveillance under the ONC Health IT Certification Program that clarify and expand ONC-ACBs' existing surveillance responsibilities by specifying requirements and procedures for in-the-field surveillance. We believe these new and revised PoPC promote greater transparency and accountability for the ONC Health IT Certification Program.

C. Costs and Benefits

Our estimates indicate that this final rule is an economically significant rule as its overall costs for health IT developers may be greater than $100 million in at least one year. We have, therefore, projected the costs and benefits of the final rule. The estimated costs expected to be incurred by health IT developers to develop and prepare health IT to be tested and certified in accordance with the 2015 Edition certification criteria (and the standards and implementation specifications they include) are represented in monetary terms in Table 1 below. We note that this final rule does not impose the costs cited as compliance costs, but rather as investments which health IT developers voluntarily take on and may expect to recover with an appropriate rate of return. We further note that, based on the estimates provided by a health IT developer association in response to the Proposed Rule, we have reduced the estimated burden of the 2015 Edition by over 40,000 burden hours per health IT developer by not adopting certain proposed certification criteria, functionality and standards.

The dollar amounts expressed in Table 1 are expressed in 2014 dollars.

Table 1—Distributed Total 2015 Edition Development and Preparation Costs for Health IT Developers (4-year period)—Totals Rounded

Year

Ratio

(%)

Total low cost estimate

($M)

Total high cost estimate

($M)

Total average cost estimate

($M)

2015

39.07

60.48

49.77

2016

91.15

141.12

116.14

2017

91.15

141.12

116.14

2018

39.07

60.48

49.77

4-Year Totals

260.44

403.19

331.82

As noted above, we expect that health IT developers will recover an appropriate rate of return for their investments in developing and preparing their health IT for certification to the 2015 Edition certification criteria adopted in this final rule. However, we do not have data available to quantify these benefits or other benefits that will likely arise from health IT developers certifying their health IT to the 2015 Edition.

We believe that there will be several significant benefits that may arise from this final rule for patients, health care providers, and health IT developers. The 2015 Edition continues to improve health IT interoperability through the adoption of new and updated standards and implementation specifications. For example, many proposed certification criteria include standards and implementation specifications for interoperability that directly support the EHR Incentive Programs, which include objectives and measures for the interoperable exchange of health information and for providing patients electronic access to their health information in structured formats. In addition, the adopted certification criteria that support the collection of patient data that could be used to address health disparities would not only benefit patients, but the entire health care delivery system through improved quality of care. The 2015 Edition also supports usability and patient safety through new and enhanced certification requirements for health IT.

This final rule also makes the ONC Health IT Certification Program open and accessible to more types of health IT and for health IT that supports a variety of care and practice settings. This should benefit health IT developers, providers practicing in

other care/practice settings, and consumers through the availability and use of certified health IT that includes capabilities that promote interoperability and enhanced functionality.

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 Health IT Policy Committee (HITPC) and the Health IT 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 health IT standards, implementation specifications, and certification criteria.

2. Health IT 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 health IT. Specifically, section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), 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 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 the 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 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 the EHR Incentive Programs 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 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 EHR Incentive Programs Stage 1 by eligible professionals (EPs), eligible hospitals, and critical access hospitals (CAHs) under the Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule (75 FR 44314) (the “EHR Incentive Programs Stage 1 final rule”).

The Secretary issued a proposed rule 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 proposed rule”), which proposed new and revised standards, implementation specifications, and certification criteria. After consideration of the comments received on the 2014 Edition proposed rule, 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

the EHR Incentive Programs Stage 2, as well as 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”). 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 the EHR Incentive Programs Stage 2 by EPs, eligible hospitals, and CAHs under the Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 2 final rule ( 77 FR 53968) (the “EHR Incentive Programs Stage 2 final rule”).

On December 7, 2012, an interim final rule with a request for comment was jointly issued and published by ONC and CMS to update certain standards that had been previously adopted in the 2014 Edition final rule. The interim final rule also revised the EHR Incentive Programs by adding an alternative measure for the Stage 2 objective for hospitals to provide structured electronic laboratory results to ambulatory providers, corrected the regulation text for the measures associated with the objective for hospitals to provide patients the ability to view online, download, and transmit information about a hospital admission, and made the case number threshold exemption policy for clinical quality measure (CQM) reporting applicable for eligible hospitals and CAHs beginning with FY 2013. In addition, the interim final rule provided notice of CMS's intent to issue technical corrections to the electronic specifications for CQMs released on October 25, 2012 (77 FR 72985). On September 4, 2014, a final rule (Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record (EHR) Incentive Program for 2014 and Other Changes to the EHR Incentive Program; and Health Information Technology: Revisions to the Certified EHR Technology Definition and EHR Certification Changes Related to Standards; Final Rule) (79 FR 52910) was published adopting these proposals.

On November 4, 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.

On February 26, 2014, the Secretary published a proposed rule titled “Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements” (79 FR 10880) (“Voluntary Edition proposed rule”). The proposed rule proposed a voluntary edition of certification criteria that was designed to enhance interoperability, promote innovation, and incorporate “bug fixes” to improve upon the 2014 Edition. A correction notice was published for the Voluntary Edition proposed rule on March 19, 2014, entitled “Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements; Correction” (79 FR 15282). This correction notice corrected the preamble text and gap certification table for four certification criteria that were omitted from the list of certification criteria eligible for gap certification for the 2015 Edition EHR certification criteria. On September 11, 2014, a final rule was published titled “2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange” (79 FR 54430) (“2014 Edition Release 2 final rule”). The final rule adopted a small subset of the original proposals in the Voluntary Edition proposed rule as optional and revised 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. It also finalized administrative proposals (i.e., removal of regulatory text from the Code of Federal Regulations (CFR)) and proposals for the ONC HIT Certification Program that provide improvements.

On May 23, 2014, CMS and ONC jointly published the “Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record Incentive Programs for 2014; and Health Information Technology: Revisions to the Certified EHR Technology Definition” proposed rule (79 FR 29732). The rule proposed to update the EHR Incentive Programs Stage 2 and Stage 3 participation timeline. It proposed to revise the CEHRT definition to permit the use of EHR technology certified to the 2011 Edition to meet the CEHRT definition for FY/CY 2014. It also proposed to allow EPs, eligible hospitals, and CAHs that could not fully implement EHR technology certified to the 2014 Edition for an EHR reporting period in 2014 due to delays in the availability of such technology to continue to use EHR technology certified to the 2011 Edition or a combination of EHR technology certified to the 2011 Edition and 2014 Edition for the EHR reporting periods in CY 2014 and FY 2014. On September 4, 2014, a final rule (“CEHRT Flexibility final rule”) was published (79 FR 52910) adopting these proposals.

On March 30, 2015, the Secretary published a proposed rule titled “2015 Edition Health Information Technology (Health IT) Certification Criteria; 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 16804) (“2015 Edition Proposed Rule” or “Proposed Rule”). The Proposed Rule proposed an edition of certification criteria that was designed to enhance interoperability and is the subject of this final rule.

2. Medicare and Medicaid EHR Incentive Programs Rules

On January 13, 2010, CMS published the Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Proposed Rule (75 FR 1844). The rule proposed the criteria for Stage 1 of the EHR Incentive Programs 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 Stage 1 of 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, eligible hospitals, and CAHs must satisfy to meet Stage 1.

On March 7, 2012, CMS published the Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 2; Proposed Rule (77 FR 13698). Subsequently, CMS published a final rule (77 FR 53968) for the EHR Incentive Programs on September 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, eligible hospitals, and CAHs must satisfy to meet Stage 2. It also revised some Stage 1 requirements.

As described above in Section II.B.1, ONC and CMS jointly issued an interim final rule with a request for comment that was published on December 7, 2012 and a final rule that was published on

September 4, 2014. Also, as described above in Section II.B.1, ONC and CMS jointly issued proposed and final rules that were published on May 23, 2014 and September 4, 2014, respectively.

On March 30, 2015, CMS published the Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 3; Proposed Rule (80 FR 16732) (“EHR Incentive Programs Stage 3 proposed rule”) outlining objectives, associated measures, and other requirements that EPs, eligible hospitals, and CAHs would need to meet to participate in Stage 3 of the EHR Incentives Programs.

On April 15, 2015, CMS published the Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Modifications to Meaningful Use in 2015 Through 2017; Proposed Rule (80 FR 20346) (“EHR Incentive Programs Modifications proposed rule”) proposing modifications to the EHR Incentive Programs for the EHR reporting periods and meaningful use measures in 2015 through 2017.

3. ONC Health IT 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) (“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-ACBs need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria, and eliminated the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria.

The Voluntary Edition proposed rule included proposals that focused on improving regulatory clarity, simplifying the certification of EHR Modules that are designed for purposes other than meeting requirements of the EHR Incentive Programs, and discontinuing the use of the Complete EHR definition. As noted above, we issued the 2014 Edition Release 2 final rule to complete the rulemaking for the Voluntary Edition proposed rule. The 2014 Edition Release 2 final rule discontinued the “Complete EHR” certification concept beginning with the proposed 2015 Edition, adopted an updated standard (ISO/IEC 17065) for the accreditation of ONC-ACBs, and adopted the “ONC Certified HIT” certification and design mark for required use by ONC-ACBs under the ONC Health IT Certification Program.

As noted above, on March 30, 2015, the Secretary published the Proposed Rule which, in addition to proposing the 2015 Edition, proposed revisions to the ONC Health IT Certification Program.

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

A. 2015 Edition Health IT Certification Criteria

This rule finalizes new, revised, and unchanged certification criteria that establish the capabilities and related standards and implementation specifications for the certification of health IT, including EHR technology. We refer to these new, revised, and unchanged certification criteria as the “2015 Edition health IT certification criteria” and have added this term and its definition to § 170.102. As noted in the Executive Summary, we also refer to these criteria as the “2015 Edition” in this preamble. We codified the 2015 Edition in § 170.315 to set them apart from other editions of certification criteria and make it easier for stakeholders to quickly determine the certification criteria included in the 2015 Edition.

In the Proposed Rule, we identified the 2015 Edition certification criteria as new, revised, or unchanged in comparison to the 2014 Edition. In the 2014 Edition final rule we gave meaning to the terms “new,” “revised,” and “unchanged” to both describe the differences between the 2014 Edition certification criteria and the 2011 Edition certification criteria, as well as establish what certification criteria in the 2014 Edition were eligible for gap certification (see 77 FR 54171, 54202, and 54248). Given that beginning with the 2015 Edition, “Complete EHR” certifications will no longer be issued (see also 79 FR 54443-45) and that we proposed to make the ONC Health IT Certification Program more open and accessible to other health care/practice settings, we also proposed to give new meaning to these terms for the purpose of a gap certification analysis as so specified:

• “

New

” certification criteria are those that as a whole only include capabilities never referenced in previously adopted certification criteria editions and to which a Health IT Module presented for certification to the 2015 Edition could have never previously been certified. As a counter example, the splitting of a 2014 Edition certification criterion into two criteria as part of the 2015 Edition would not make those certification criteria “new” for the purposes of a gap certification eligibility analysis.

• “

Revised

” certification criteria are those that include within them capabilities referenced in a previously adopted edition of certification criteria as well as changed or additional new capabilities; and to which a Health IT Module presented for certification to the 2015 Edition could

not

have been previously certified to all of the included capabilities.

• “

Unchanged

” certification criteria are those that include the same capabilities as compared to prior certification criteria of adopted editions; and to which a Health IT Module presented for certification to the 2015 Edition could have been previously certified to all of the included capabilities.

Comments.

While we received no specific comments on these terms, we received comments both supporting and opposing the adoption of certification

criteria that go beyond specifically supporting an objective and measure under the EHR Incentive Programs.

Response.

We continue to maintain the same meanings for the terms “new,” “revised,” and “unchanged” as described in the Proposed Rule with a slight modification to the meaning of “unchanged” to state that “unchanged” certification criteria are certification criteria that include the same

or less

of the same capabilities as compared to prior certification criteria of adopted editions. We refer readers to section III.A.4 (“2015 Edition Gap Certification Eligibility Table”) of this preamble for a complete description of gap certification and the identification of 2015 Edition certification criteria eligible for gap certification. In sum, “unchanged” criteria are eligible for gap certification. For health IT previously certified to the 2011 or 2014 Edition certification criteria, this permits, where applicable, the use of prior test results for certification to the 2015 certification criteria. This creates efficiencies and substantially reduces burden.

As described in the Proposed Rule and Executive Summary of this final rule as well as discussed in more detail in section IV.B of this preamble, we believe the availability and use of certified health IT for other use cases and health care settings beyond the EHR Incentive Programs has significant value. Therefore, we have adopted certification criteria that support those purposes. Table 2 below provides an overview of certification criteria adopted in this final rule as compared to the certification criteria proposed in the Proposed Rule and the adopted 2014 Edition.

Table 2—2015 Edition Health IT Certification Criteria

Not Adopted Proposed Criteria (14)

Vital Signs

Image Results

Family Health History—Pedigree

Patient List Creation

Electronic Medication Administration Record

Decision Support—Knowledge Artifact

Decision Support—Service

Incorporate Laboratory Tests and Values/Results

Transmission of Laboratory Test Reports

Accessibility Technology

SOAP Transport and Security Specification and XDR/XDM for Direct Messaging

Healthcare Provider Directory—Query Request

Healthcare Provider Directory—Query Response

Electronic Submission of Medical Documentation

Unchanged Criteria as Compared to the 2014 Edition (Gap Certification Eligible) (16)

Computerized Provider Order Entry (CPOE)—Medications

CPOE—Laboratory

CPOE—Diagnostic Imaging

Drug-Drug, Drug-Allergy Interaction Checks for CPOE

Medication List

Medication Allergy List

Drug-Formulary and Preferred Drug List Checks

Smoking Status

Authentication, Access Control, Authorization

Audit Report(s)

Amendments

Automatic Access Time-Out

Emergency Access

End-User Device Encryption

Accounting of Disclosures

Transmission to Public Health Agencies—Reportable Laboratory Tests and Values/Results

Revised Criteria as Compared to the 2014 Edition (25)

Demographics

Problem List

Clinical Decision Support

Family Health History

Patient-Specific Education Resources

Transitions of Care

Clinical Information Reconciliation and Incorporation

Electronic Prescribing

Data Export

Clinical Quality Measures—Record and Export

Clinical Quality Measures—Import and Calculate

Clinical Quality Measures—Report

View, Download, and Transmit to

3rd

Party

Transmission to Immunization Registries

Transmission to Public Health Agencies—Syndromic Surveillance

Transmission to Cancer Registries

Automated Numerator Recording

Automated Measure Calculation

Safety-enhanced Design

Quality Management System

Auditable Events and Tamper-Resistance*

Integrity*

Secure Messaging*

Direct Project*

Direct Project, Edge Protocol, and XDR/XDM*

New Criteria as Compared to the 2014 Edition (19)

Implantable Device List

Social, Psychological, and Behavioral Data

Data Segmentation for Privacy—Send

Data Segmentation for Privacy—Receive

Care Plan

Common Clinical Data Set Summary Record—Create

New criteria based on request for comment in the Proposed Rule.

Common Clinical Data Set Summary Record—Receive

Clinical Quality Measures—Filter

Trusted Connection

New for privacy and security certification framework and API approach.

Auditing Actions on Health Information

New for privacy and security certification framework and API approach.

Patient Health Information Capture.

Transmission to Public Health Agencies—Electronic Case Reporting.

Transmission to Public Health Agencies—Antimicrobial Use and Resistance Reporting.

Transmission to Public Health Agencies—Health Care Surveys.

Consolidated CDA Creation Performance.

Application Access—Patient Selection

Split the proposed API criterion into three criteria based on public comments.

Application Access—Data Category Request.

Application Access—All Data Request

Accessibility—centered Design.

* The criterion was proposed as unchanged, but has been adopted as revised in this final rule.

We proposed that readers should interpret the following terms used in the 2015 Edition with the same meanings we adopted in the 2014 Edition final rule (77 FR 54168-54169), in response to comment: “User,” “record,” “change,” “access,” “incorporate,” “create,” and “transmit,” but apply to all health IT, not just “EHR technology.” For the term “incorporate,” we also proposed that readers should interpret the term as we further explained it under the “transitions of care” certification criterion (77 FR 54218) in the 2014 Edition final rule and in the Voluntary Edition proposed rule (79 FR 10898). We proposed that the scope of a 2015 Edition certification criterion was 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 the 2015 Edition 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 proposed 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 2015 Edition certification criteria (

i.e.,

“export summary,” “transition of care/referral summary,” “ambulatory summary,” and “inpatient summary.”)

We received no specific comments on these proposals and have adopted these meanings and approaches for certification to the 2015 Edition.

As with the adoption of the 2011 and 2014 editions of certification criteria (see the introductory text to §§ 170.302, 170.304, 170.306, and 170.314), all capabilities mentioned in certification criteria are expected to be performed electronically, unless otherwise noted. Therefore, we no longer include “electronically” in conjunction with each capability included in a certification criterion under § 170.315 because the introductory text to § 170.315 (which covers all the certification criteria included in the section) clearly states that health IT must be able to

electronically

perform the following capabilities in accordance with all applicable standards and implementation specifications adopted in the part.

Health IT certified to the 2015 Edition certification criteria and associated standards and implementation specifications can be implemented as part of an EP's, eligible hospital's, or CAH's CEHRT and used to demonstrate meaningful use (as identified in Table 4 of section III.A.3 below). We note that Table 4 also identifies certification criteria that are mandatory and conditional certification requirements for Health IT Modules, such as safety-enhanced design (conditional), and quality management system (mandatory), accessibility-centered design (mandatory), and privacy and security certification criteria (conditional). To note, we use the term mandatory to mean that all Health IT Modules must be certified to the certification criterion (see also § 170.550(g)(2) and (3)). Conditional means that certification to the certification criterion (e.g., the “Consolidated CDA creation performance,” “safety-enhanced design,” “automatic access timeout,” or “integrity” certification criterion) depends on what other certification criteria a Health IT Module is presented for certification to (see § 170.550(g)(1) and (4) and § 170.550(f)). For more information on “conditional” certification related to privacy and security, we also refer readers to section IV.C.1 (“Privacy and Security”) of this preamble.

Health IT certified to the 2015 Edition certification criteria and associated standards and implementation specifications can also be used to meet other HHS program requirements (

e.g.,

Medicare chronic care management services) or private sector requirements (

e.g.,

The Joint Commission performance measurement initiative (“ORYX” vendor)). We refer readers to section IV.B.4 of this preamble for further programs that reference the use of certified health IT.

1. Applicability

Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. We proposed to revise paragraph (d) of § 170.300 to add in a reference to § 170.315 and revise the parenthetical in the paragraph to say “

i.e.,

apply to any health care setting” instead of “

i.e.,

apply to both ambulatory and inpatient settings.”

We received no comments on these specific proposed revisions and have adopted the proposed revisions. As noted in the Proposed Rule, these revisions clarify which specific capabilities

within

a certification criterion included in § 170.315 have general applicability (

i.e.,

apply to any health care setting) or apply only to an inpatient setting or an ambulatory setting. The revision to change the language of the parenthetical aligns with our approach to make the ONC Health IT Certification Program more agnostic to health care settings and accessible to health IT that supports care and practice settings beyond the ambulatory and inpatient settings. We refer readers to section IV.B of this preamble for a detailed discussion of modifications to the ONC Health IT Certification Program responses to public comments received on the proposed modifications.

We note that, with the 2015 Edition, we no longer label an entire certification criterion as either optional or ambulatory/inpatient (at the second paragraph level of § 170.315). For example, the 2015 Edition certification criterion for transmission to cancer registries is simply “transmission to cancer registries” instead of “optional—ambulatory setting only—transmission to cancer registries.” Similarly, the 2015 Edition certification criterion for “accounting of disclosures” is simply “accounting of disclosures” instead of “optional—accounting of disclosures.” These simplifications are possible given that, beginning with the 2015 Edition certification criteria, “Complete EHR” certifications will no longer be issued (see 79 FR 54443-45). Therefore, there is no longer a need to designate an entire certification criterion in this manner. Again, this approach also supports our goal to make the ONC Health IT Certification Program more agnostic to health care settings and accessible to health IT that supports care and practice settings beyond the ambulatory and inpatient settings. We note that we still use “optional,” “inpatient setting only,” and “ambulatory setting only” designations within certification criteria to provide flexibility and reduce burden where feasible and appropriate.

We proposed to replace the term “EHR technology” in paragraphs (d)(1) and (d)(2) of § 170.300 with “health IT” to align with our approach to make the ONC Health IT Certification Program more clearly open to the certification of all types of health IT. We received no comments on this specific proposal and have replaced “EHR technology” with “health IT” in the referenced paragraphs. Again, we refer readers to section IV.B of this preamble for a detailed discussion of modifications to the ONC Health IT Certification Program and responses to public comments received on the proposed modifications.

2. Standards and Implementation Specifications

a. National Technology Transfer and Advancement Act

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

require the use of, 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 final rule, we refer to voluntary consensus standards, except for:

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

• The standards adopted in § 170.202. (These industry standards were developed by groups of industry stakeholders committed to advancing the Direct Project,

which included initiatives under the Standards and Interoperability (S&I) Framework.

These groups used consensus processes similar to those used by voluntary consensus standards bodies.);

• The standards adopted at § 170.205(d)(4) and (e)(4) for reporting of syndromic surveillance and immunization information to public health agencies, respectively (These standards go through a process similar within the public health community to those used by other industry stakeholders and voluntary consensus standards bodies.);

• The standard adopted at § 170.207(f)(2) for race and ethnicity; and

• Certain standards related to the protection of electronic health information adopted in § 170.210.

http://www.healthit.gov/policy-researchers-implementers/direct-project.

http://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework.

We are aware of no voluntary consensus standard that would serve as an alternative to these standards for the purposes that we have identified in this final rule.

b. Compliance With Adopted Standards and Implementation Specifications

In accordance with Office of the

Federal Register

regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and/or implementation specifications in a final rule, the entire standard or implementation specification document is deemed published in the

Federal Register

when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and implementation specification includes the entire document unless we specify otherwise. For example, for the Health Level Seven (HL7) Implementation Guide (IG) for CDA Release 2: National Health Care Surveys (NHCS), Release 1 adopted in this final rule, health IT certified to the certification criterion referencing this IG will need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it will remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text preempts the permissiveness of the IG.

c. “Reasonably Available” to Interested Parties

The Office of the Federal Register has established new requirements for materials (

e.g.,

standards and implementation specifications) that agencies incorporate by reference in the

Federal Register

(79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section V (“Incorporation by Reference”) of this

preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we have adopted and incorporated by reference in the

Federal Register

. To note, we also provide relevant information about these standards and implementation specifications throughout this section of the preamble (section III), including URLs.

“Minimum Standards” Code Sets

In the Proposed Rule, we proposed to adopt newer versions of four previously adopted minimum standards code sets for the 2015 Edition. The code sets proposed were: The September 2014 Release of the U.S. Edition of SNOMED CT®, LOINC® version 2.50, the February 2, 2015 monthly version of RxNorm, and the February 2, 2015 version of the CVX code set. We also proposed to adopt two new minimum standards code sets (the National Drug Codes (NDC)—Vaccine Codes, updates through January 15, 2015 and the “Race & Ethnicity—CDC” code system in the PHIN Vocabulary Access and Distribution System (VADS) Release 3.3.9 (June 17, 2011)). We reiterated, as we have previously articulated (77 FR 54170), the adoption of newer versions improve interoperability and health IT implementation, while creating little additional burden through the inclusion of new codes. We further stated that, as many of these minimum standards code sets are updated frequently throughout the year, we would consider whether it may be more appropriate to adopt a version of a minimum standards code set that is issued before we publish a final rule for the Proposed Rule.

Comments.

A number of commenters were supportive of the proposal to adopt more recent versions of the U.S. Edition of SNOMED CT®, LOINC®, RxNorm, and the CVX code set. Commenters supported adoption of NDC codes for vaccines, but also recommended we adopt the MVX codes for vaccine manufacturer as part of this list. One commenter requested identification of the steward for the PHIN VADS “Race & Ethnicity—CDC” code system, noting that it did not appear to have been updated since 2007. This commenter also requested verification that the code set has been reviewed on a regular basis.

A few commenters suggested that we do not specify an exact version and release of a standard (

e.g.,

allow for adoption of version/release 1.x of the HL7 Implementation Guide for CDA Release 2: National Health Care Surveys (NHCS) where “x” could be any version/release within the version/release 1 family). Another commenter suggested that we consider adopting a “rolling” upgrade cycle for all standardized code systems and value sets. Specifically, the commenter recommended that a certified Health IT Module should not be more than two versions behind the most currently released version of the code system or value set. Commenters also suggested that the vocabulary code set versions in the Proposed Rule are now outdated and have since been updated per a regular update cycle. Commenters suggested we adopt these more recent versions of these vocabulary code sets as they provide the most up-to-date clinical information for clinical relevance and interoperability.

Response.

As many of the proposed minimum standards code sets are updated frequently throughout the year, we considered whether it was more appropriate to adopt versions of minimum standards code sets that were issued after the Proposed Rule and before we published this final rule. In making such determination, as we have done with prior finalized versions of minimum standards code sets, we gave consideration to whether these newer versions included any new substantive requirements and their effects on interoperability. We have found no negative effects on interoperability with the newer versions we have adopted as compared to the proposed versions. Rather, these newer versions will further support and improve the structured recording of data. To note, the adopted newer version of a minimum standards code set will serve as the baseline for certification. As with all adopted minimum standards code sets, health IT can be certified to newer versions of the adopted baseline version minimum standards code sets for purposes of certification, unless the Secretary specifically prohibits the use of a newer version (see § 170.555 and 77 FR 54268).

We have adopted newer versions of four 2014 Edition minimum standards code sets in this final rule for the 2015 Edition. These code sets are the September 2015 Release of the U.S. Edition of SNOMED CT®, LOINC® version 2.52, the September 8, 2015 monthly version of RxNorm, and the August 17, 2015 version of the CVX code set. We have also adopted three new minimum standards code sets. These code sets are the National Drug Codes (NDC)—Vaccine NDC Linker, updates through August 17, 2015; the CDC Race and Ethnicity Code Set Version 1.0 (March 2000);

and the Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015.

We have more specifically identified the CDC Race and Ethnicity code set as compared to the identification in the Proposed Rule. We note this code set remains part of the PHIN Vocabulary Access and Distribution System (VADS) Release 3.3.9.

http://www.cdc.gov/phin/resources/vocabulary/index.html.

We have not adopted MVX codes for vaccine manufacturers as detailed further in the discussion on the “transmission to immunization registries” certification criterion in section III.A.3 of the preamble. Therefore, we do not see a need to include MVX codes in this list of code sets.

We confirm that CDC continues to steward the CDC Race and Ethnicity Code Set, Version 1.0 (March 2000). We also confirm that we have reviewed this version and believe it is appropriate to adopt it as the minimum standard code set for race and ethnicity. Any updates to the code set, including the issuance of newer versions, are within the oversight of the CDC.

As we stated in the 2014 Edition final rule (77 FR 54169-54170), the Office of the Federal Register regulations related to “incorporation by reference” are limited to a specific version that is approved rather than future versions or revisions of a given publication. Thus, we do not include regulation language that refers to a version/release as, for example “Version/Release 1.X” when “X” remains variable. Further, to remain in compliance with the Administrative Procedure Act and address any potential interoperability concerns, we would need to issue regulations to adopt a newer version minimum standards code set as a “baseline” standard and cannot

require

health IT developers to upgrade on a rolling basis.

e. Object Identifiers (OIDs) for Certain Code Systems

We are providing the following table (Table 3) of OIDs for certain code systems to assist health IT developers in the proper identification and exchange of health information coded to the vocabulary standards referenced in this final rule.

Table 3—Code System Object Identifiers (OIDs)

Code system OID

Code system name

2.16.840.1.113883.6.96

IHTSDO SNOMED CT®.

2.16.840.1.113883.6.1

LOINC®.

2.16.840.1.113883.6.88

RxNorm.

2.16.840.1.113883.12.292

HL7 Standard Code Set CVX-Vaccines Administered.

2.16.840.1.113883.6.69

National Drug Code Directory.

2.16.840.1.113883.6.8

Unified Code of Units of Measure (UCUM

2.16.840.1.113883.6.13

Code on Dental Procedures and Nomenclature (CDT).

2.16.840.1.113883.6.4

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

2.16.840.1.113883.6.238

CDC Race and Ethnicity Code Set Version 1.0 (March 2000).

2.16.840.1.113883.6.316

Tags for Identifying Languages—Request for Comment (RFC) 5646 (preferred language).

2.16.840.1.113883.6.101

Healthcare Provider Taxonomy.

f. Subpart

B—Standards and Implementation Specifications for Health Information Technology

We proposed to remove the term “EHR Modules” from § 170.200 and add in its place “Health IT Modules” We proposed to remove the term “EHR technology” from § 170.210 and add in its place “health IT.” We noted that these proposals were consistent with our overall approach to this rulemaking as discussed in the Proposed Rule Executive Summary and recited in this final rule's Executive Summary. We received no comments on these specific proposals and have adopted these proposals. We refer readers to section IV.B of this preamble for a detailed discussion of modifications to the ONC Health IT Certification Program and responses to public comments received on the proposed modifications.

3. Adopted Certification Criteria

We discuss the certification criteria that we have adopted as part of the 2015 Edition in this section. We discuss each certification criterion in the chronological order in which it would appear in the CFR. In other words, the preamble that follows discusses the adopted certification criteria in § 170.315(a) first, then § 170.315(b), and so on through section (h). Due to certain proposed certification criteria not being adopted as well as further consideration of proper categorization of criteria, the designation of some criteria within § 170.315 has changed in comparison to the Proposed Rule (

e.g.,

the 2015 Edition “smoking status” criterion has been codified in § 170.315(a)(11) instead of proposed (a)(12) and the 2015 Edition “patient health information capture” criterion has been codified in § 170.315(e)(3) instead of proposed (a)(19)).

We note that we have restructured the regulatory text of certification criteria to remove the use of “or” in many places where it was proposed to indicate certification optionality. We have replaced it with language that we believe will better convey that same optionality. This restructuring of the regulatory text will provide further clarity regarding when a health IT developer has flexibility to select one of two or more options for certifying its Health IT Module as compared to when it is expected that the Health IT Module demonstrate all listed methods for certification. This restructuring, by itself, did not alter any of the proposed certification criteria requirements.

Table 4 below identifies the 2015 Edition certification criteria associated with the EHR Incentive Programs Stage 3 as finalized in EHR Incentive Programs Stage 3 and Modifications final rule published elsewhere in this issue of the

Federal Register

. While these certification criteria can be used to support other use cases and health care settings beyond the EHR Incentive Programs, we have also adopted additional 2015 health IT certification criteria that support other specific use cases and health care settings. These criteria were listed in Table 2 and are discussed in this section of the preamble.

ER16OC15.000

ER16OC15.001

ER16OC15.002

•

Computerized Provider Order Entry

We proposed to adopt three separate 2015 computerized provider order entry (CPOE) certification criteria based on the clinical purpose (

i.e.

, medications, laboratory, and diagnostic imaging), which was consistent with the 2014 Edition CPOE certification criteria we adopted in the 2014 Edition Release 2 final rule (79 FR 54435-36).

Comments.

We received only a few comments on this proposed approach, all which expressed support for separating the functionality based on clinical purpose.

Response.

We have adopted separate CPOE certification criteria based on clinical purposes that are described in more detail below.

We requested comment on whether we should specify, for the purposes of testing and certification to the 2015 Edition CPOE criteria, certain data elements that a Health IT Module must be able to include in a transmitted order. In particular, we requested comment on whether a Health IT Module should be able to include any or all of the following data elements: secondary diagnosis codes; reason for order; and comment fields entered by the ordering provider, if they are provided to the ordering provider in their order entry screen. We also requested comment on whether there are any other data elements that a Health IT Module should be able to include as part of an order for the purposes of testing and certification.

Comments.

Most commenters opposed the inclusion of specific data elements for certification. These commenters most often cited burden on health IT developers and concern that new data elements might lead to inefficient workflow for the order entry process as reasons for not including additional data elements. Some commenters expressed support for the inclusion of additional data elements mentioned in the Proposed Rule, but varied in their support for the specific data elements that should we included. These commenters did, however, agree that the “reason for order” data element was a data element that should be included with an order.

Response.

We acknowledge the lack of agreement as to what data elements

should be required for certification, but also the support for the “reason for order” data elements. With consideration of commenters concerns about burden and workflow inefficiencies, we have adopted the “reason for order” data element as an optional certification provision in each of the three CPOE certification criteria. We agree with commenters that the reason for an order data element has value. The designation of this provision as optional in all three criteria gives flexibility to health IT developers as they consider certification of their health IT and providers as they consider what certified health IT to purchase.

•

Computerized Provider Order Entry—Medications

2015 Edition Health IT Certification Criterion

§ 170.315(a)(1) (Computerized provider order entry—medications)

We proposed to adopt a 2015 Edition CPOE certification criterion specific to medication ordering that was unchanged in comparison to the 2014 Edition CPOE—medications criterion adopted at § 170.314(a)(18) as well as § 170.314(a)(1)(i). The proposed criterion does not reference any standards or implementation specifications.

Comments.

Commenters overwhelmingly recommended that this criterion remain unchanged. A few commenters requested clarifications regarding the designation of authorized CPOE users and the proper counting of CPOE orders for the purposes of meeting the associated meaningful use objective and measure.

Response.

We thank commenters for their support and have adopted this criterion as unchanged. As noted above, we have, however, adopted the “reason for order” data element as an

optional

provision within this criterion. For questions related to the EHR Incentive Programs (

i.e.,

the designation of authorized CPOE users and the proper counting of CPOE order for the purposes of meeting the associated meaningful use objective and measure), we refer readers to CMS and the EHR Incentive Programs Stage 3 and Modifications final rule published elsewhere in this issue of the

Federal Register

•

Computerized Provider Order Entry—Laboratory

2015 Edition Health IT Certification Criterion

§ 170.315(a)(2) (Computerized provider order entry—laboratory)

We proposed to adopt a 2015 Edition CPOE certification criterion specific to laboratory ordering that was revised in comparison to the CPOE—laboratory criterion adopted at § 170.314(a)(19) as well as § 170.314(a)(1)(ii). For the ambulatory setting, we proposed that this criterion would include the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders (LOI) from EHR, Draft Standard for Trial Use, Release 2—US Realm (“Release 2”). We proposed to adopt the most recent version of the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, (also referred to as the “electronic Directory of Services (eDOS) IG”) for certification to all health care settings. We also proposed to require that a Health IT Module use, at a minimum, version 2.50 of Logical Observation Identifiers Names and Codes (LOINC®) as the vocabulary standard for laboratory orders.

Comments.

Commenters stated that the LOIs and eDOS IGs were not ready for implementations, but acknowledged the significant progress being made in developing standards for laboratory ordering and the harmonizing of laboratory-related IGs.

Response.

With consideration of comments, we have determined not to adopt any standards for this certification criterion. We have, however, adopted the “reason for order” data element as an

optional

provision within this criterion. We have made the determination to keep this criterion “functional” at this time based on a number of factors, including (among other aspects) that the best versions of the IGs that could be associated with this criterion were not sufficiently ready. That being said, we believe that the LOI and eDOS IGs show great promise in improving laboratory interoperability and could potentially result in significant cost savings to the industry at large. Accordingly, we remain committed to continued collaboration with stakeholders to support the widespread adoption of these IGs, including the development of testing tools and pilots where necessary and feasible.

•

Computerized Provider Order Entry—Diagnostic Imaging

2015 Edition Health IT Certification Criterion

§ 170.315(a)(3) (Computerized provider order entry—diagnostic imaging)

We proposed to adopt a 2015 Edition CPOE certification criterion specific to diagnostic imaging ordering that was unchanged in comparison to the 2014 Edition CPOE—diagnostic imaging criterion adopted at § 170.314(a)(20) as well as § 170.314(a)(1)(iii). The proposed criterion does not reference any standards or implementation specifications. We also proposed to adopt the title of “diagnostic imaging,” which is the title we gave to the 2014 Edition version of this certification criterion in the 2014 Edition Release 2 final rule (79 FR 54436).

Comments.

Commenters overwhelmingly recommended that this criterion remain unchanged. A few commenters recommended we add functionality to this criterion, including the required use of a standard such as Digital Imaging and Communications in Medicine (DICOM) to support radiology.

Response.

We thank commenters for their support and have adopted this criterion as unchanged. As noted above, we have, however, adopted the “reason for order” data element as an

optional

provision within this criterion. While we appreciate comments suggesting the inclusion of additional functionality, the recommended functionality is outside the scope of the proposed criterion. Therefore, we have not adopted the recommended functionality in this criterion. We also refer readers to our previous discussion of DICOM (77 FR 54173).

•

Drug-Drug, Drug-Allergy Interaction Checks for CPOE

2015 Edition Health IT Certification Criterion

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

We proposed to adopt a revised 2014 Edition “drug-drug, drug-allergy interaction checks” criterion (§ 170.314(a)(2)) to clarify that the capabilities included in this criterion are focused on CPOE. We proposed that a Health IT Module must record at least one action taken and by whom, and must generate either a human readable display or human readable report of actions taken and by whom in response to drug-drug or drug-allergy interaction checks (DD/DAI). We explained that the benefits of recording user actions for DD/DAI interventions that assist with quality improvement and patient safety outweigh the development burden associated with this functionality. However, to address development concerns, we proposed that a Health IT Module must only record, at a minimum, one user action for DD/DAI checks; and asked for comment on focusing the requirement to record at least one user action taken for DD/DAI interventions on a subset of DD/DAI interventions and what sources we

should consider for defining this subset. We further noted that the proposed criterion does not establish the uses for the “user action” information, who should be able to view the information, or who could adjust the capability. We also sought comment on requiring functionality that would inform a user of new or updated DD/DAI when the medication or medication allergy lists are updated.

Comments.

We received a few comments supporting our proposed clarification that this criterion focused on CPOE, but also suggestions that this functionality could support other use cases, such as when medications are reviewed or medication or medication allergy lists are updated. We received mixed comments in response to the proposed additional “recording user response” functionality for this criterion. While many commenters supported the overall goal of interaction checking for quality improvement and patient safety, including functionality that would inform a user of new or updated DD/DAI, many commenters stated that current systems already provide a wide range of functionality to enable providers to document decisions concerning interaction warnings. These commenters stated that the proposed “recording user response” is not necessary for certification or for providers to satisfy objectives of the EHR Incentive Programs. Commenters requested the criterion remain eligible for gap certification. A few expressed overall agreement with the other functionality specified in this criterion, including the ability to adjust the severity level of interventions (

e.g.,

alerts) for drug-drug interaction checks.

Response.

We have determined, based on public comments, to focus this certification criterion on CPOE and to not adopt the “recording user response” functionality. This approach is responsive to comments and will permit health IT developers to focus their efforts on functionality and requirements that support the goals outlined in the Executive Summary, including supporting the interoperability of health IT. To note, this criterion is eligible for gap certification.

•

Demographics

2015 Edition Health IT Certification Criterion

§ 170.315(a)(5) (Demographics)

We proposed to adopt a revised 2015 Edition “demographics” certification criterion in comparison to the 2014 Edition certification criterion (§ 170.314(a)(3)). We received comments that focused on each of the specific data elements in the certification criterion. We have categorized and responded to these comments in a similar manner.

Sex

We proposed the requirement to record sex in accordance with HL7 Version 3 (“AdministrativeGender”) and a nullFlavor value attributed as follows: male (M); female (F); and unknown (UNK), and noted that HL7 Version 3 for recording sex would be required under the “Common Clinical Data Set” definition for certification to the 2015 Edition. In the Proposed Rule's section III.B.3 (“Common Clinical Data Set”), we stated that this approach would become the method for capturing sex under the “Common Clinical Data Set” definition for certification to the 2015 Edition.

Comments.

Commenters were generally supportive of recording sex in a structured manner. A few commenters suggested that we used other values, such as U or UN for undifferentiated. A few commenters also requested clarification on the proposed use of two different value sets (HL7 AdministrativeGender and NullFlavor).

Response.

We appreciate the support for our proposal. We have adopted the requirement for recording sex as proposed. We clarify that this coding is intended to present birth sex. Therefore, we believe the use of the specified values and value sets is the most appropriate approach. It is also an approach that we believe poses the least burden and most health IT developers are using these values and value sets.

Race and Ethnicity

We proposed the requirement to record each one of a patient's races and ethnicities in accordance with, at a minimum, the “Race & Ethnicity—CDC” code system in the PHIN Vocabulary Access and Distribution System (VADS), Release 3.3.9

and aggregate each one of a patient's races and ethnicities to the categories in the OMB standard for race and ethnicity. We explained that a Health IT Module must be able to record each one of a patient's races and ethnicities using any of the 900 plus concepts in the “Race & Ethnicity—CDC” code system, and noted that health IT developers and health care providers could determine the appropriate user interface implementation in a given setting. The Proposed Rule section III.A.2.d (“Minimum Standards” Code Sets) discussed the adoption of the “Race & Ethnicity—CDC” code system in PHIN VADS as a minimum standards code set and Release 3.3.9, or potentially a newer version if released before this final rule, as the baseline for certification to the 2015 Edition. To note, the Proposed Rule section III.B.3 “Common Clinical Data Set” also discussed adopting the Race & Ethnicity—CDC” code system in PHIN VADS (at a minimum, Release 3.3.9) and the OMB standard as the race and ethnicity standards under the “Common Clinical Data Set” definition for certification to the 2015 Edition.

https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238#.

Comments.

A majority of commenters supported our proposal to require a Health IT Module to be able to capture granular patient race and ethnicity data. Some commenters questioned the necessity for such granular race and ethnicity capture because it was not required for the EHR Incentive Programs or another identified purpose, with one commenter recommending that this be a future certification requirement. Commenters expressed concerns about user interfaces in relation to the over 900 concepts for race and ethnicity in PHIN VADS, including concern over how many concepts should be displayed for users. Similarly, commenters suggested that testing and certification should not be to all 900 concepts. A few commenters requested clarification on whether a health IT Module must be able to capture multiple races or ethnicities for a patient and the appropriate method for capturing when a patient declines to provide race or ethnicity information.

Response.

We thank commenters for their support. We have adopted the race and ethnicity requirements as proposed, including the use of both the OMB and the CDC Race and Ethnicity standards. We believe that the structured granular recording of race and ethnicity can both improve patient care and support the elimination of health disparities whether or not currently required by the EHR Incentives Programs or another HHS program. By adopting these requirements, we ensure certified health IT has these capabilities and can make them available to providers. We clarify four points in response to comments. First, as mentioned in the Proposed Rule, a health IT developer and provider can best determine how the user interface is designed, including how many race and ethnicity values are displayed. Second, as mentioned above and in the Proposed Rule, a Health IT Module must be able to record each one of a patient's races and ethnicities using any of the 900 plus concepts. For testing and certification, a Health IT Module would be tested to any of the 900 plus concepts at the discretion of the testing

body. Third, a Health IT Module would need to be capable of recording multiple races and/or ethnicities for a patient. This approach is consistent with the OMB standard. Fourth, a Health IT Module must be able to demonstrate that it can record whether a patient declined to provide information for all data specified in this certification criterion. We do not, however, specify for the purposes of certification how that data is specifically captured.

Preferred Language

In the Proposed Rule, we proposed to require the use of the Internet Engineering Task Force (IETF) Request for Comments (RFC) 5646

standard for preferred language. We stated that RFC 5646 entitled “Tags for Identifying Languages, September 2009” is the coding system that is commonly used to encode languages on the web. We also noted that this standard is compatible with the C-CDA Release 2.0 (and C-CDA Release 2.1) and that other preferred language standards in use today can be efficiently mapped to it, such as ISO 639-1, 639-2, and 639-3. The Proposed Rule explained that the standard does not determine the way in which health care providers use the capability to record preferred language or the preferred language values they are presented with to select a patient's preferred language. In the Proposed Rule's section III.B.3 (“Common Clinical Data Set”), we stated that RFC 5646 would also become the preferred language standard under the “Common Clinical Data Set” definition for certification to the 2015 Edition.

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

Comments.

Commenters were generally supportive of the adoption of the RFC 5646 standard. Some commenters (health IT developers) expressed opposition to the recording of preferred language in RFC 5646 due to the new burden it would create versus the perceived minimal value. One commenter suggested adopting ISO 639-3 instead of RFC 5646.

Response.

We have adopted RFC 5646 as the preferred language standard for this criterion. As extensively discussed in the Proposed Rule (80 FR 16817), we believe this is the most appropriate standard for capturing a patient's preferred language. It is compatible with the C-CDA Release 2.1 and other preferred language standards can be efficiently mapped to it, including IS0 639-1, 639-2, and 639-3. As mentioned in the Proposed Rule and clarified for other demographics data, a health IT developer and provider can best determine how the user interface is designed, including how many preferred languages are displayed.

Preliminary Cause of Death and Date of Death

In the Proposed Rule, we proposed that, for the inpatient setting, a Health IT Module must include the functionality to record, change, and access the “date of death.” We stated that this functionality would be in addition to the requirement 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.

Comments.

The majority of commenters supported this requirement. A few commenters requested clarification as to whether the preliminary cause of death was to be recorded consistent with either the SNOMED CT® or ICD-10-CM standards.

Response.

We thank commenters for their support and have adopted this requirement as proposed. We clarify that the preliminary cause of death is not required to be recorded in accordance with a standard for the purposes of certification to this criterion as we did not propose such a requirement nor have we adopted one.

Sexual Orientation and Gender Identity (SO/GI)

We did not propose to include a requirement to capture a patient's sexual orientation or gender identity as part of this criterion. Rather, we proposed the capture of SO/GI data as part of the proposed “social, psychological, and behavioral data” certification criterion.

Comments.

We received a significant number of comments from providers, consumers/individuals, and health care coalitions strongly recommending that we consider including sexual orientation and gender identify as a component of the Base EHR definition (

e.g.

, in the demographics certification criterion) or Common Clinical Data Set definition. These commenters suggested that there are mature vocabulary standards for representing SO/GI and there is strong clinical value in having this data to inform decisions about health care and treatment. Commenters indicated that by including SO/GI in the Base EHR or Common Clinical Data Set definitions, providers would be required to possess this functionality for participation in the EHR Incentive Programs, which could have a large impact for evaluating the quality of care provided to lesbian, gay, bisexual, and transgender (LGBT) communities.

Response.

We thank commenters for their feedback. Given this feedback, the clinical relevance of capturing SO/GI, and the readiness of the values and vocabulary codes for representing this information in a structured way, we require that Health IT Modules enable a user to record, change, and access SO/GI to be certified to the 2015 Edition “demographics” certification criterion. By doing so, SO/GI is now included in the 2015 Edition Base EHR definition. The 2015 Edition Base EHR definition is part of the CEHRT definition under the EHR Incentive Programs. Therefore, providers participating in the EHR Incentive Programs will need to have certified health IT with the capability to capture SO/GI to meet the CEHRT definition in 2018 and subsequent years.

We note that like all information in the “demographics” criterion, certification does not require that a provider collect this information, only that certified Health IT Modules enable a user to do so. We believe including SO/GI in the “demographics” criterion represents a crucial first step forward to improving care for LGBT communities.

We have not included it in the Common Clinical Data Set at this time. We refer readers to section III.B.3 of this preamble for further discussion of the Common Clinical Data Set.

Comments.

We received comments from a health care coalition that has partnered with and coordinated industry-development of the appropriate terminology to capture SO/GI for health care settings. The commenters suggested that we revise the proposed terminology for collecting SO/GI to use more appropriate language that reflects up-to-date, non-offensive terminology that will facilitate the goal of providing welcoming and affirming health care to LGBT individuals. As such, the commenters recommended that we retain the proposed SNOMED CT® and HL7 V3 codes but revise the description of some codes to use synonyms which reflect more appropriate language. The commenters noted that they have already submitted revisions to SNOMED CT® to include the synonyms for these terms. The commenters also noted that the core concepts of the codes remain the same.

Response.

We thank the commenters for the suggestion and are proceeding with the recommendation to include use the revised terminology for collecting SO/GI. We refer readers to § 170.207(o)(1) and § 170.207(o)(2) for a full list of the code descriptors and codes for SO/GI, respectively.

Comments.

One commenter recommended we consider including structured and coded questions for

soliciting SO/GI information as part of certification.

Response.

While we thank the commenter for providing this recommendation, we do not believe that the suggested questions have not yet been scientifically validated for use in health care settings and, thus, have not adopted them. We do, however, believe that these questions are being used today in health care settings as “best practices,” and would suggest that health care providers and institutions decide whether to include these questions in the collection of SO/GI information. These “best practice” questions and the answers we have adopted are:

• Do you think of yourself as:

○ Straight or heterosexual;

○ Lesbian, gay, or homosexual;

○ Bisexual;

○ Something else, please describe.

○ Don't know.

• What is your current gender identity? (Check all that apply.)

○ Male;

○ Female;

○ Transgender male/Trans man/Female-to-male;

○ Transgender female/Trans woman/Male-to-female;

○ Genderqueer, neither exclusively male nor female;

○ Additional gender category/(or other), please specify.

○ Decline to answer.

Comments.

One commenter recommended that we add another question and set of answers to collect assigned birth sex.

Response.

We have not adopted this recommendation to collect assigned birth sex as suggested because we already require the capturing of birth sex as described under the “sex” section above.

•

Problem List

2015 Edition Health IT Certification Criterion

§ 170.315(a)(6) (Problem list)

We proposed to adopt a 2015 Edition “problem list” certification criterion that was revised as compared to the 2014 Edition “problem list” certification criterion (§ 170.314(a)(5)) by requiring the September 2014 Release of the U.S. Edition of SNOMED CT® as the baseline version permitted for certification to this criterion. The Proposed Rule's section III.A.2.d (“Minimum Standards” Code Sets) discussed our adoption of SNOMED CT® as a minimum standards code set and the adoption of the September 2014 Release (U.S. Edition),

potentially a newer version if released before this final rule, as the baseline for certification to the 2015 Edition.

Comments.

The majority of commenters supported the proposed certification criterion. A commenter suggested that instead of the full SNOMED CT® code system, the reference should be explicit to a concept and its value set relevant to this criterion, such as the “core” problem list. A commenter recommended requiring certification to the

most current

version of SNOMED CT®. Some commenters recommended that we require the use of the ICD-10-CM code set. These commenters noted that the code set is used for billing purposes and the required use of SNOMED CT® adds burden on providers and their staff due to the required use of two different systems.

A couple of commenters stated that the problem list should not be limited to the duration of a hospitalization because it may be needed when the patient is out of the hospital, suggesting “for the duration of an entire hospitalization” be struck from the criterion. Another commenter suggested that the distinction between inpatient and ambulatory records should be dropped in favor of a “patient” record stating that several major healthcare systems have dropped the distinction and are focusing on a patient problem list where one or more problems on the problem list are addressed in a particular encounter (outpatient visit or inpatient stay).

Commenters suggested that if this criterion was adopted as proposed that health IT developers should have the ability to attest that their health IT previously certified to the 2014 Edition “problem list” criterion meets the newer baseline version of SNOMED CT® for the purposes of testing and certification to this criterion.

Response.

We have adopted this certification criterion as proposed, except that we have adopted a newer baseline version SNOMED CT® (September 2015 Release of the U.S. Edition) for the purposes of certification. We refer readers to section III.A.2.c (“Minimum Standards” Code Sets) for a more detailed discussion of our adoption of the September 2015 Release of the U.S. Edition of SNOMED CT® and for our reasons why we always adopt a baseline version of a vocabulary code set for certification instead of specifying certification must be to the “most current” version. As with the 2014 Edition, testing and certification will focus on a Health IT Module's ability to enable a user to record, change, and access a patient's problem list in accordance with SNOMED CT®. This will enable a provider to choose any available and appropriate code in SNOMED CT® for a patient's problems.

We did not propose as part of this criterion to test and certify a Health IT Module's ability to enable a user to record, change, and access a patient's active problem list and problem history across health care settings as this criterion is focused on the ambulatory and inpatient settings in support of the EHR Incentive Programs. We believe the use of “for the duration of an entire hospitalization” is appropriate for this criterion and refer readers to our detailed discussed of this determination in the 2014 Edition final rule (77 FR 54211-54212).

We agree with commenters that efficient testing and certification processes should be available to Health IT Modules previously certified to the 2014 Edition “problem list” criterion for certification to this criterion. Accordingly, we will consider such options, such as attestation, in developing the test procedure for this criterion and in issuing guidance to the ONC-AA and ONC-ACBs.

•

Medication List

2015 Edition Health IT Certification Criterion

§ 170.315(a)(7) (Medication list)

We proposed to adopt a 2015 Edition “medication list” certification criterion that was unchanged as compared to the 2014 Edition “medication list” certification criterion (§ 170.314(a)(6)). To note, the proposed criterion does not reference any standards or implementation specifications.

Comments.

The majority of commenters expressed support for this certification criterion as proposed. A few commenters suggested additional functionalities for this criterion. These suggestions included functionality to designate or mark medications as confidential or sensitive and include patient-generated data. One commenter recommended requiring that medications be recorded in accordance with RxNorm. A couple of commenters requested clarification and expansion of the medication list to include over-the-counter medications, herbal supplements, medical cannabis, and oxygen. In general, a few commenters suggested that the medication list should be available across encounters and there should not be a distinction between inpatient and ambulatory records. One of these commenters noted that healthcare systems have dropped the distinction and are focusing on a patient medication list. Another commenter stated that the Food and

Drug Administration (FDA) is currently working to implement requirements from the Drug Supply Chain Security Act (DSCSA) regarding standards for the interoperable exchange of information for tracing human, finished and/or prescription drugs. The commenter recommended that we be aware of these efforts and align current and future certification requirements with any future FDA requirements for standards-based identification of prescription drugs.

Response.

We thank commenters for their support and have adopted this criterion as proposed. The other comments summarized above are outside the scope of the proposed criterion. We did not propose additional functionality for this criterion, including structured capture in accordance with RxNorm. We also did not propose as part of this criterion to test and certify a Health IT Module's ability to enable a user to record, change, and access a patient's active medication list and medication history across health care settings as this criterion is focused on the ambulatory and inpatient settings in support of the EHR Incentive Programs (please also see our response to comments for the “problem list” certification criterion above). Further, we do not define “medications” for the purpose of testing and certifying a Health IT Module's ability to enable a user to record, change, and access a patient's active medication list and medication history. We thank the commenter for the information related to FDA's work and will take steps to ensure our work aligns with the relevant work of the FDA.

•

Medication Allergy List

2015 Edition Health IT Certification Criterion

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

We proposed to adopt a 2015 Edition “medication allergy list” certification criterion that was unchanged as compared to the 2014 Edition “medication allergy list” certification criterion (§ 170.314(a)(7)).

Comments.

The majority of commenters supported this criterion as proposed. Multiple commenters recommended adding functionality to support food and environmental allergies as well as other types of allergens, noting that most providers are already recording this information and that such functionality would support patient safety. Some of these same commenters recommended the structured capture of this information in various standards, including RxNorm, UNII, SNOMED CT®, and LOINC®. A couple of commenters recommended additional functionalities such as including time and date for medication allergies entered, edited, and deleted. In general, a few commenters suggested that the medication allergy list should be available across encounters and there should not be a distinction between inpatient and ambulatory records. One of these commenters noted that healthcare systems have dropped the distinction and are focusing on a patient medication allergy list. Another commenter stated that the FDA is currently working to implement requirements from the Drug Supply Chain Security Act (DSCSA) regarding standards for the interoperable exchange of information for tracing human, finished and/or prescription drugs. The commenter recommended that we be aware of these efforts and align current and future certification requirements with any future FDA requirements for standards-based identification of prescription drugs.

Response.

We thank commenters for their support and have adopted this criterion as proposed. The other comments summarized above are outside the scope of the proposed criterion. We did not propose additional functionality for this criterion, including additional allergens and the structured capture of medication allergies. As we noted in the Proposed Rule (80 FR 16820), there are a number of vocabularies and code sets that could support food and environmental allergies as well as medications, but our view is that there is no ready solution for using multiple vocabularies to code allergies that could be adopted for the purposes of certification at this time. We also did not propose as part of this criterion to test and certify a Health IT Module's ability to enable a user to record, change, and access a patient's active medication allergy list and medication allergy history across health care settings as this criterion is focused on the ambulatory and inpatient settings in support of the EHR Incentive Programs (please also see our response to comments for the “problem list” certification criterion above). As noted in our response under the “medication list” certification criterion, we will take steps to ensure our work aligns with the relevant work of the FDA.

•

Clinical Decision Support

2015 Edition Health IT Certification Criterion

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

We proposed to adopt a 2015 Edition “clinical decision support” (CDS) certification criterion that was revised in comparison to the 2014 Edition “CDS” criterion (§ 170.314(a)(8)). We proposed to require a Health IT Module to follow the updated Infobutton standard (Release 2, June 2014)

and one of two updated associated IGs: HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (“SOA Release 1 IG”),

the updated Infobutton URL-based IG (HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4, June 2014) (“URL-based Release 4 IG”).

We proposed to require certification only to the Infobutton standard (and an associated IG) for identifying diagnostic or therapeutic reference information, as we stated this is the best consensus-based standard available to support the use case. We requested comment on requiring that a Health IT Module be able to request patient-specific education resources identified using Infobutton standards based on a patient's preferred language. We proposed to require that a Health IT Module presented for certification to this criterion be able to record at least one action taken and by whom when a CDS intervention is provided to a user, and that a Health IT Module must generate either a human readable display or human readable report of the responses and actions taken and by whom when a CDS intervention is provided. We clarified that the 2015 Edition CDS certification criterion does not use the terms “automatically” and “trigger” as related to CDS interventions so as to reiterate the intent to encompass all types of CDS interventions without being prescriptive on how the interventions are deployed. We proposed cross-reference corrections to the 2014 Edition CDS criterion.

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

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

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

Infobutton Standard and Related IGs

Comments.

A majority of commenters supported the inclusion of the updated Infobutton standard and related IGs. Multiple commenters recommended that there should be more options besides Infobutton for identifying diagnostic or therapeutic reference information. A commenter recommended a requirement for Infobutton to be connected to a reference resource at the end user's choice in cases of inability to use the Infobutton functionality due to

contractual relationships to reference resources. Multiple commenters voiced a need for materials to be tested and vetted to ensure the accuracy and appropriate literacy level of material, in addition to providers being able to provide educational resources from other sources in case the most appropriate material deemed by the physician cannot be identified or is limited by the health IT.

Response.

We thank commenters for their support and have adopted the proposed Infobutton standard and supporting IGs. We clarify for commenters that our certification approach only focuses on capabilities that must be certified to meet this criterion. A health IT developer's product could include other means for identifying diagnostic or therapeutic reference information. Our approach actually reduces burden on health IT developers in that they do not have to have any other means tested and certified. In regard to comments suggesting the certification of the connection to a reference resource and diagnostic or therapeutic reference information obtained, these comments are beyond the scope of our proposal and we have not adopted them.

Preferred Language Request for Comment

Comments.

Commenters expressed support for the capability to identify for a user diagnostic and therapeutic reference information based on a patient's preferred language with the use of Infobutton. Commenters stated that this would support reducing racial and ethnic health disparities by improving literacy and addressing language barriers. Some commenters contended that including such as requirement would increase burden for limited value because resources are often not available in other languages with the exception of three or four of the most commonly spoken languages.

Response.

We appreciate the comments received in response to this request for comment, including those supporting the inclusion of preferred language. We have, however, not included preferred language functionality in this criterion. While this functionality many support reducing health disparities, we believe that when weighing all proposed policies and the accumulated burden they present, this functionality would not provide as much impact in relation to other proposals such as the structured recording of a patient's preferred language and specific race and ethnicity information under the “demographics” criterion. By not adopting this functionality, health IT developers will be able to focus more of their efforts on other adopted functionality and requirements, including those that support the interoperability of health IT.

CDS Intervention Response Documentation

Comments.

We received mixed comments in response to the proposed additional “recording user response” functionality for this criterion. While many commenters supported the overall goal of interaction checking for quality improvement and patient safety, many commenters stated that current systems already provide a wide range of functionality to enable providers to document decisions concerning CDS interventions. These commenters stated that the proposed “recording user response” is not necessary for certification or for providers to satisfy objectives of the EHR Incentive Programs.

Response.

We have not adopted the “recording user response” functionality. This approach is responsive to comments suggesting that this functionality is already included in health IT and is unnecessary to support providers participating in the EHR Incentive Programs. Further, by not adopting this functionality, health IT developers will be able to focus more of their efforts on other adopted functionality and requirements, including those that support the interoperability of health IT.

Clarifying “Automatically” and “Triggered” Regulatory Text

Comments.

Commenters expressed agreement with our proposal to not use the terms “automatically” and “trigger” in the 2015 Edition CDS criterion and that CDS interventions should be limited by how they are deployed.

Response.

We thank commenters for their support. We have not included these terms in the certification criterion to clarify our intent to encompass all types of CDS interventions without being prescriptive on how the interventions are deployed.

Clinical Decision Support Configuration—Laboratory Tests and Values/Results

Comments.

We received a comment seeking clarification on the criterion's reference to laboratory tests and values/results for CDS configuration capabilities related to the incorporation of a transition of care/referral summary. The commenter stated that we should remove reference to laboratory tests and values/results for CDS configuration in relation to the incorporation of a transition of care/referral summary because the proposed 2015 Edition “clinical information reconciliation and incorporation” criterion does not include reconciling laboratory tests and values/results.

Response.

We have removed the references to laboratory tests and values/results from the criterion. The commenter is correct in that the 2015 Edition “clinical information reconciliation and incorporation” criterion does not include reconciling laboratory tests and values/results. Therefore, this data would not necessarily be available for CDS when a patient record is incorporated.

Reordering of Provisions/Regulation Text

We have reordered the provisions of the criterion/regulation text to better align with testing procedures. We have moved the CDS intervention interaction provision to the beginning, followed by the CDS configuration, evidence-based decision support interventions, linked referential CDS, and source attributes. This reordering does not alter the requirements of the criterion in any way.

2014 Edition “Clinical Decision Support” Certification Criterion—Corrections

We received no comments on our proposal to revise the cross-reference in § 170.314(a)(8)(iii)(B)(2) (CDS configuration) to more specifically cross-reference the 2014 “transitions of care” (“ToC”) criterion (§ 170.314(b)(1)(iii)(B)). Accordingly, we have adopted this proposed revision.

•

Drug-Formulary and Preferred Drug List Checks

2015 Edition Health IT Certification Criterion

§ 170.315(a)(10) (Drug-formulary and preferred drug list checks)

In the Proposed Rule, we proposed to adopt a 2015 Edition “drug formulary checks and preferred drug list” certification criterion that was split based on drug formularies and preferred drug lists. We proposed that a Health IT Module must (1) automatically check whether a drug formulary exists for a given patient and medication and (2) receive and incorporate a formulary and benefit file according to the National Council for Prescription Drug Programs (NCPDP) Formulary and Benefit Standard v3.0 (“v3.0”). We proposed that a Health IT Module must automatically check whether a preferred drug list exists for a given patient and medication. For drug formularies and

preferred drug lists, we proposed that a Health IT Module be capable of indicating the last update of a drug formulary or preferred drug list as part of certification to this criterion. We requested comment on more recent versions of the NCPDP Formulary and Benefit Standard to support functionality for receiving and incorporating a formulary and benefit file and sought to understand associated potential development burdens. In addition, we sought comment on a standard for individual-level, real-time formulary benefit checking to address the patient co-pay use case, whether we should offer health IT certification to the standard for this use case, and if this functionality should be a separate criterion from the 2015 Edition “drug formulary and preferred drug list checks” certification criterion.

Comments.

Commenters were supportive of splitting the drug-formulary checks functionality from the preferred drug list functionality. A number of commenters stated that the NCPDP Formulary and Benefit Standard provides static, group-level formulary pricing information that does not indicate individual-level, real-time prescription pricing information. A few commenters stated that these static, group-level formularies are not useful for informing discussions with patients about what medications to prescribe because they do not provide information about the patient's co-pay for a particular drug. Many commenters also suggested that it was not necessary for ONC to offer certification to this functionality because most health IT systems already support NCPDP's Formulary and Benefit Standard v3.0 due to the Medicare Part D e-prescribing requirements under the Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA). Some of these commenters even indicated that they test and certify through Surescripts' certification program to the standard. In terms of a version of the NCPDP Formulary and Benefit Standard, stakeholders preferred ONC adopt v3.0 rather than any subsequent version to align with the Medicare Part D requirements. Commenters also contended that the industry has widely adopted v3.0 and that newer versions are less stable.

Many commenters stated that there is not an industry-wide accepted standard for real-time individual patient-level formulary checking, but recommended ONC adopt certification to a standard once the industry moves to an agreed-upon standard. A few commenters noted that an NCPDP task group is analyzing use cases to support a real-time prescription benefit inquiry and is planning to make recommendations to the NCPDP membership on the creation of a new transaction and/or standard or modification of existing transactions or standards.

Response.

We appreciate the detailed feedback commenters provided. We have determined that it is most appropriate to not adopt a specific standard for this criterion. We agree with commenters that the NCPDP Formulary and Benefit Standard v3.0 is widely implemented today in support of Medicare Part D requirements and that certification to this standard would add unnecessary burden to health IT developers and providers who are already adhering to the standard.

We believe that certification for individual-level, real-time prescription pricing information will provide the most value to inform provider prescribing decisions and discussions between providers and patients on the most appropriate medication options for the patient. However, at this time, there is no real-time patient-level standard with consensus stakeholder support that would be appropriate for certification. Based on the comments received, we strongly urge the industry to accelerate its work on identifying the need to create a new transaction and/or standard or modify existing transactions or standards for real-time prescription benefit inquiries. We intend to continue our participation in this area and will consider proposing certification functionalities for real-time prescription benefit inquiries in future rulemaking.

With consideration of comments supporting our proposed split of functionality between drug formularies and preferred drug lists, we have adopted a 2015 Edition “drug-formulary and preferred drug list checks” criterion that simply separates drug formulary and preferred drug list functionality, but does

not

require any standards or functionality beyond that included in the 2014 Edition “drug-formulary checks” criterion. As such, this certification criterion is eligible for gap certification.

•

Smoking Status

2015 Edition Health IT Certification Criterion

§ 170.315(a)(11) (Smoking status)

We proposed to adopt a 2015 Edition “smoking status” certification criterion that was revised in comparison to the 2014 Edition “smoking status” criterion (§ 170.314(a)(11)) and to include the 2015 Edition certification criterion in the 2015 Edition Base EHR definition. To be certified, we proposed that a Health IT Module must record, change, and access smoking status to any of the September 2014 Release of the U.S. Edition of SNOMED CT® available codes for smoking status, at a minimum. We noted that a Health IT Module certified to certification criteria that reference the Common Clinical Data Set (

i.e.

, the “transitions of care” (“ToC”), “data export” (previously “data portability”), “view, download, and transmit to 3rd party” (VDT), “Consolidated CDA creation performance,” and “application access to the Common Clinical Data Set” certification criteria) would need to be able to code smoking status in only the 8 smoking status codes,

which may mean mapping other smoking status codes to the 8 codes. We explained that we expect Health IT developers to work with health care providers to include the appropriate implementation of smoking status codes in a user interface.

These 8 codes are: current every day smoker, 449868002; current some day smoker, 428041000124106; former smoker, 8517006; never smoker, 266919005; smoker—current status unknown, 77176002; unknown if ever smoked, 266927001; heavy tobacco smoker, 428071000124103; and light tobacco smoker, 428061000124105.

Comments.

Some commenters stated that health IT should not be required to support the full set of smoking status codes within SNOMED CT® as it would cause unnecessary development burden and potential workflow issues for providers. Multiple commenters also expressed concern with the proper mapping all of the available smoking status codes within SNOMED CT® to the specified 8 SNOMED CT® smoking codes in the Common Clinical Data Set and used for exchange of patient health information. We also received comments requesting the inclusion of other substances and routes of administration, including the use of chewing tobacco.

Response.

We have adopted a “smoking status” certification criterion that does not reference a standard. As stated in the Proposed Rule (80 FR 16870), the capture of a patient's smoking status has significant value in assisting providers with addressing the number one cause of preventable death and disease in the United States. We have also included this criterion in the Base EHR definition so that this functionality is available to all providers participating in the EHR Incentive Programs. In consideration of the concerns expressed by commenters regarding development burden and the proper mapping of all available smoking status codes within SNOMED CT® to the specified 8 SNOMED CT® for

exchange, we believe that the best path forward is the adoption of a “smoking status” criterion that would simply require a Health IT Module to demonstrate that it can enable a user to record, change, and access a patient's smoking status. In regard to comments suggesting the inclusion of other substances and routes of administration, these comments are beyond the scope of our proposal and we have not adopted them. In sum, this certification criterion is “unchanged” as compared to the 2014 Edition “smoking status” criterion and is eligible for gap certification.

As discussed in more detail under section III.B.3 of this preamble, we have adopted the 8 specified SNOMED CT® smoking codes as part of the Common Clinical Data Set (and for purposes of exchange). This is a continuation of our approach first adopted with the 2014 Edition.

•

Family Health History

2015 Edition Health IT Certification Criterion

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

We proposed to adopt a 2015 Edition “family health history” (FHH) certification criterion that was revised in comparison to the 2014 Edition FHH certification criterion adopted at § 170.314(a)(13). In particular, we proposed to require a Health IT Module to enable a user to record, change, and access a patient's FHH electronically according to, at a minimum, the concepts or expressions for familial conditions included in the September 2014 Release of the U.S. Edition of SNOMED CT®, which would be a newer baseline version of SNOMED CT® than adopted for the 2014 Edition FHH criterion. The proposed rule's section III.A.2.d (“Minimum Standards” Code Sets) discussed our adoption of SNOMED CT® as a minimum standards code set and the adoption of the September 2014 Release (U.S. Edition), or potentially a newer version if released before a this final rule, as the baseline for certification to the 2015 Edition.

Comments.

Commenters generally supported this certification criterion. Some commenters suggested not adopting this criterion because it does not support a specific meaningful use objective of the proposed EHR Incentive Programs Stage 3. A couple of commenters suggested the recording of FHH is more valuable when it is actually exchanged, with one commenter recommending that we require FFH data be sent using the C-CDA FHH Section with Entries or, minimally, the C-CDA FHH Organizer Entry. Another commenter suggested that the FHH be stored in a question/answer format (LOINC® for “questions” (observations) and SNOMED CT® for “answers” (observation values)), which would also better support electronic exchange of the information. Some commenters suggested that if this criterion was adopted as proposed that health IT developers should have the ability to attest that their Health IT previously certified to the 2014 Edition FHH criterion meets the newer baseline version of SNOMED CT® for the purposes of testing and certification to this criterion.

Response.

We have adopted this certification criterion as proposed, except that we have adopted a newer baseline version SNOMED CT® (September 2015 Release of the U.S. Edition) for the purposes of certification. We refer readers to section III.A.2.c (“Minimum Standards” Code Sets) for a more detailed discussion of our adoption of the September 2015 Release of the U.S. Edition of SNOMED CT®. While not supporting a specific meaningful use objective of Stage 3 of the EHR Incentive Programs, this functionality is included in the CEHRT definition. Furthermore, we believe that the FHH functionality is a functionality that should be available to providers for more comprehensive patient care.

We note that our intent is not to limit the use of LOINC® for associated FHH “questions” or the specific SNOMED CT® code that is used to label FHH. Rather, the intent is to capture this information in SNOMED CT® instead of billing terminologies like ICD-10-CM. We also do not intend to prohibit the exchange of this information using the C-CDA 2.1. As we have noted in this and prior rulemakings, certification serves as a baseline. This baseline can be built upon through future regulation or simply through a decision by a health IT developer and/or its customer to include functionality that goes beyond the baseline. As present, we have set the certification baseline for FHH information at recording it in SNOMED CT®.

We agree with commenters that efficient testing and certification processes should be available to Health IT Modules previously certified to the 2014 Edition FHH criterion for certification to this criterion. Accordingly, we will consider such options, such as attestation, in developing the test procedure for this criterion and in issuing guidance to the ONC-AA and ONC-ACBs.

•

Patient-Specific Education Resources

2015 Edition Health IT Certification Criterion

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

In the Proposed Rule, we proposed to adopt a 2015 Edition “patient-specific education resources” certification criterion that was revised in comparison to the 2014 Edition “patient-specific education resources” certification criterion (§ 170.314(a)(15)). We proposed that certification would only focus on the use of Infobutton for this certification criterion instead of Infobutton

and

any means other than Infobutton as required by the 2014 Edition criterion. We stated that there is diminished value in continuing to frame the 2015 Edition certification criterion similarly to the 2014 Edition criterion.

We proposed to adopt the updated Infobutton standard (Release 2 and the associated updated IGs (SOA-based IG and URL-based IG)). We also noted that we would not include a requirement that health IT be capable of electronically identifying patient-specific education resources based on “laboratory values/results” because the Infobutton standard cannot fully support this level of data specificity.

We proposed that a Health IT Module be able to request patient-specific education resources based on a patient's preferred language as this would assist providers in addressing and mitigating certain health disparities. More specifically, we proposed that a Health IT Module must be able to

request

that patient-specific education resources be identified (using Infobutton) in accordance with RFC 5646. We noted that Infobutton only supports a value set of ISO 639-1 for preferred language and, therefore, stated that testing and certification of preferred language for this certification criterion would not go beyond the value set of ISO 639-1. We further noted testing and certification would focus only on the ability of a Health IT Module to make a request using a preferred language and Infobutton because the language of patient education resources returned through Infobutton is dependent on what the source can support.

Comments.

Multiple commenters supported the inclusion of the updated Infobutton standard and supporting IGs. A few commenters expressed concern about limiting certification to only Infobutton and suggested there are other viable options for requesting patient-specific education resources. A commenter requested clarification as to whether providers must only use certified health IT for requesting patient-specific education resources for

the purposes of participating in the EHR Incentive Programs.

Response.

We thank commenters for their support and have adopted the proposed Infobutton standard and supporting IGs. We continue to believe that the Infobutton capability is important to be available to providers to have and use to identify patient-specific education resources. We clarify for commenters that our certification approach only focuses on capabilities that must be certified to meet this criterion. A health IT developer's product could include other means for requesting patient-specific education resources. Our approach actually reduces burden on health IT developers in that they do not have to have any other means tested and certified. For questions related to the EHR Incentive Programs, we refer readers to CMS and the EHR Incentive Programs Stage 3 and Modifications final rule published elsewhere in this issue of the

Federal Register

Comments.

We received a few comments supporting our approach for “laboratory values/results.”

Response.

We have not included “laboratory values/results” as patient data that must be used to identify patient-specific education resources.

Comments.

Commenters expressed strong support for the capability to request patient-specific education materials based on a patient's preferred language with the use of Infobutton. Commenters stated that this would support reducing racial and ethnic health disparities by improving literacy and addressing language barriers. Commenters also expressed a need for materials to be tested and vetted to ensure the accuracy and appropriate literacy level of the materials. Some commenters contended that this requirement would increase burden for limited value because educational resources are often not available in other languages with the exception of three or four of the most commonly spoken languages.

Response.

We thank commenters for their support and feedback. With consideration of the mixed feedback, we have determined to designate the use of preferred language as an optional provision within this criterion. As optional, health IT developers have flexibility to pursue certification if they deem it advantages. With our new open data CHPL (see section IV.D.3 of this preamble), information on whether a Health IT Module was certified to this functionality would be readily available for consumers.

•

Implantable Device List

2015 Edition Health IT Certification Criterion

§ 170.315(a)(14) (Implantable device list)

In the Proposed Rule, we proposed to adopt a new 2015 Edition certification criterion focused on the ability of health IT to exchange, record, and allow a user to access a list of Unique Device Identifiers (UDIs)

associated with a patient's implantable devices. Health IT certified to the proposed criterion would be able to “parse” a UDI into its constituent components (or “identifiers”) and make those accessible to the user. Separately, the health IT would be able to retrieve and provide a user with access to, if available, the optional “Device Description” attribute associated with a UDI in the FDA's Global Unique Device Identification Database (GUDID). Further, to facilitate the exchange of UDIs and increase their availability and reliability in certified health IT, we proposed to include the proposed 2015 Edition implantable device list certification criterion in the 2015 Edition Base EHR definition and to include a patient's UDIs as data within the CCDS definition for certification to the 2015 Edition. We also proposed to modify § 170.102 to include new definitions for “Device Identifier,” “Implantable Device,” “Global Unique Device Identification Database (GUDID),” “Production Identifier,” and “Unique Device Identifier.”

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. 21 CFR 801.3.

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

We explained that the purpose of the proposed implantable device list certification criterion was to enable the baseline functionality necessary to support the exchange and use of UDIs in certified health IT. The need to exchange and have access to this information wherever patients seek care is broadly relevant to all clinical users of health IT, regardless of setting or specialty, so that they may know what devices their patients are using (or have used) and thereby prevent device-related adverse events and deliver safe and effective care.

This need is most acute for implantable devices, which by their nature are difficult to detect and identify in the absence of reliable clinical documentation.

In addition, as UDIs become ubiquitous, UDI capabilities in health IT will support other important benefits, including better surveillance and evaluation of device performance and more effective preventative and corrective action in response to device recalls.

We acknowledged in the Proposed Rule that fully implementing UDIs in health IT will take time and require addressing a number of challenges. Nevertheless, we noted that substantial progress has been made. In particular, we summarized the FDA's regulatory activities and timeline for implementing the Unique Device Identification System and extensive work by public and private sector stakeholders to advance standards and specifications in support of UDI use cases. On the basis of these developments and our own ongoing consideration of these and other issues,

we recognized that while “the path to full implementation is complex, there are relatively straightforward steps” that we could take now to support the electronic exchange and use of UDIs, beginning with UDIs for implantable devices. Our proposed certification criterion focused narrowly on implementing these first steps.

As further context for our proposal, we described our previous consideration of these and other issues related to UDI adoption in a previous rulemaking. 79 FR 10894.

In light of the foregoing and with the revisions discussed below in our analysis of the comments on this proposal, we have finalized a 2015 Edition “implantable device list” certification criterion. We have also finalized our proposals to include this certification criterion in the 2015 Base EHR definition and to include a patient's UDIs as data within the 2015 Common Clinical Data Set definition. Discussion of those proposals can be found elsewhere in this final rule.

Comments.

Most commenters agreed with the central premise of our proposal, that enabling the exchange and use of UDIs in certified health IT is a key initial step towards realizing the substantial patient safety, public health, and other benefits of UDIs and the Unique Device Identification System. Many commenters strongly supported the proposed criterion, including its focus on implantable devices. Commenters stated that the ability to exchange and access identifying information about patients' implantable devices wherever patients seek care would enable clinicians to prevent device-related medical errors and improve the quality of care provided to patients. Commenters also stated that the need to access accurate information

about patients' implantable devices is broadly applicable to primary care physicians, specialists, and other providers to support care coordination and ensure that providers have a complete medical history of their patients.

Many commenters supported the proposed criterion in full and recommended that we finalize it without any substantial revision. A significant number of commenters also urged to expand the scope of this criterion to include additional UDI-related capabilities. In contrast, a significant number of commenters stated that we should not finalize this criterion or should make all or part of it an optional certification criterion for the 2015 Edition. Commenters also offered a variety of suggested revisions and refinements with respect to the capabilities we proposed.

Response.

We have adopted this certification criterion substantially as proposed, subject to certain revisions and clarifications discussed further below in response to the comments we received. We thank commenters for their detailed and thoughtful feedback on our proposal. We reiterate that this certification criterion represents a

first step

towards enabling the widespread exchange and use of UDIs and related capabilities in certified health IT, beginning with implantable devices. Because we recognize that fully implementing UDIs in health IT will take time and require addressing a number of challenges, the certification criterion focuses narrowly on baseline health IT capabilities that developers can feasibly implement today. These capabilities will provide the foundation for broader adoption and more advanced capabilities and use cases. We believe that this approach minimizes the potential burden while maximizing the impact of this criterion for all stakeholders.

Comments.

A significant number of commenters who supported our proposed implantable device list certification criterion also recommended that we adopt additional UDI-related capabilities, either as part of this criterion (which we proposed to reference in the 2015 Edition Base EHR definition) or as a separate, optional certification criterion. Many commenters urged us to include requirements for Automatic Identification and Data Capture (AIDC) of UDIs. Commenters stated that such a requirement would facilitate the accurate and efficient capture of UDIs and align this criterion with the UDI final rule, which requires UDIs to support one or more forms of AIDC. Some commenters also stated that if we did not require—or at least provide the option for—AIDC, users may be forced to manually enter UDIs. They stated that this could discourage them from capturing UDIs, which could lead to incomplete or inaccurate information about patients' implantable devices. Separate from AIDC, several commenters suggested that we adopt other UDI-related capabilities, such as the ability to generate lists of patients with a particular device; to generate notifications to patients in the event of a device recall; and to record and track information about non-implantable devices and medical and surgical supplies that are not regulated as a device.

Response.

We have not adopted any AIDC requirements for UDIs as part of this final rule. While we unequivocally agree with commenters that UDIs should be captured using AIDC and should rarely if ever be manually entered; and while for this reason we strongly urge health IT developers and heath care organizations to implement AIDC capabilities in all settings and systems in which UDIs may be captured; yet for the reasons elaborated below, we believe at this time that certification is neither an effective nor appropriate means to further these policies. As we explained in the Proposed Rule, this criterion is not intended to provide the capability to enter or “capture” UDIs for implantable device, such as during the course of a procedure. The reason for this is that the capture of UDIs currently occurs in a wide variety of “upstream” IT systems and settings that are beyond the scope of the current ONC Health IT Certification Program. Rather than ineffectually trying to address these “upstream” use cases, we have chosen to focus this certification criterion on the baseline functionality necessary to ensure that, once recorded in a patient's electronic health record, UDIs can be exchanged among “downstream” health IT systems (the overwhelming majority of which we do certify) and accessed by clinicians wherever patients seek care.

Some commenters understood our rationale for not requiring AIDC capabilities for all certified health IT and instead recommended we adopt a separate optional AIDC certification criterion that could be leveraged by certified health IT designed for operating rooms and other surgical settings in which devices are implanted or removed. While we appreciate the suggestion, such a certification criterion would be applicable to only a small subset of certified health IT, which in turn represents only a small subset of IT systems used to capture UDIs for implantable devices. Moreover, prescribing specific AIDC requirements for certified health IT may also be unnecessary. Given the obvious convenience, accuracy, and other advantages of AIDC, we anticipate that users of certified health IT designed for surgical settings will expect developers to include AIDC capabilities as a necessary complement to the baseline implantable device list functionality required by this criterion. Allowing developers and their customers to design and implement the most appropriate AIDC solutions for their individual needs is consistent with FDA's policy of permitting flexibility in the use of these technologies and avoids imposing unnecessary requirements and costs on developers, providers, and our testing and certification bodies.

Contrary to the suggestions of some commenters, our decision not to adopt a particular AIDC requirement for implantable devices does not mean that users of certified health IT systems will be forced to manually record UDIs. Again, for the reasons we have stated, this criterion has no bearing on how UDIs are entered or captured in upstream IT systems during a procedure or operation. It is tailored solely to bringing and providing capabilities for UDIs to downstream EHR and health IT systems used in physicians' offices, hospitals, and other places where patients with implantable devices seek care.

Similarly, at this time we believe that it would be premature to include other capabilities suggested by commenters. Some of those capabilities—such as the ability to record information about non-implantable devices—are beyond the scope of the proposal. For other capabilities, greater adoption and use of UDIs in certified health IT is needed before the capabilities will be useful to most health IT users. For example, we recognize that being able to generate a list of patients with a particular device will be necessary to respond to device recalls and analyze device performance and other characteristics. But those benefits cannot materialize until UDIs are more broadly and more readily accessible through interoperable health IT and health information exchange. Likewise, achieving these benefits will first require implementing other baseline functionality included in this criterion, such as the ability to retrieve key device attributes from the GUDID. We think that focusing the requirements of this criterion—and thus the efforts of developers and users of certified health IT—on these essential baseline functionalities is the quickest path to

the adoption of UDIs in health IT and thus to creating demand and opportunities for the more advanced capabilities commenters envision.

Comments.

Some commenters requested clarification as to what constitutes an “implantable device” for purposes of this certification criterion.

Response.

We have adopted new definitions in § 172.102 for “Implantable Device” and several other terms by cross-referencing the definitions for those terms already provided at 21 CFR 801.3. We believe adopting these definitions in our final rule will prevent any interpretative ambiguity and ensure that each phrase's specific meaning reflects the same meaning given to it in the Unique Device Identification System final rule. For further discussion of these new definitions, we refer readers to section III.B.4 of this preamble.

Comment.

A commenter recommended that we use the term “identifier” instead of the term “data element” to refer to the following identifying information that composes the Production Identifier portion of a UDI:

• The lot or batch 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; and

• for an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).

To avoid confusion and align our terminology with the UDI final rule, the commenter recommended we refer to these “data elements” as “identifiers” or “production identifiers.”

Response.

We agree that our use of the term “data elements” was imprecise and could lead to unnecessary confusion. Accordingly, we have revised our terminology as follows to align more closely with the UDI final rule.

In our proposal, we used the term “data elements” to describe two distinct types of information associated with UDIs. First, we said that a Health IT Module certified to our proposed criterion would have to be able to parse certain “data elements from a UDI” and make these accessible to a user. 80 FR 16825. In that context, we were referring to what the UDI final rule describes as the “production identifiers that appear on the label of the device.” 21 CFR 830.310(b)(1). These are the identifiers listed above that compose and are required to be included in the Production Identifier when required to be included on the label of a device. 21 CFR 801.3. Because these identifiers are part of the UDI, health IT should be able to parse these identifiers from the UDI using the issuing agency's specifications. There is no need to query an external database or source, such as the GUDID.

Second, we also used the same term, “data element,” to refer to certain information not included in the UDI itself but that is associated with the UDI and can be retrieved using the GUDID. Specifically, we proposed that health IT be able to retrieve and make accessible the optional “Device Description” attribute associated with the Device Identifier portion of the UDI (assuming the attribute has been populated in the GUDID).

To distinguish these separate concepts and for consistency with the UDI final rule, this preamble and the corresponding regulation at § 170.315(a)(14) use the terms “identifier” and “attribute” to refer to the two distinct types of information described above.

Comments.

Many commenters, including some health IT developers, supported the requirement to parse a UDI and allow a user to access the identifiers that compose the UDI. Other commenters stated that requiring this functionality would be burdensome because UDIs may be issued by different issuing agencies and in different formats. Some commenters suggested we withdraw this proposed requirement until a canonical format is established to harmonize and streamline the process of parsing UDIs issued by different FDA-accredited issuing agencies and in different formats.

A number of commenters pointed out that we had omitted from this requirement the Distinct Identification Code required by 21 CFR 1271.290(c), which is one of the five identifiers that make up the Production Identifier and applies to human cells, tissues, or cellular and tissue-based products (HCT/P) regulated as a device, including certain kinds of implantable devices (

e.g.,

skin grafts and bone matrixes). To ensure the exchange of UDIs for all implantable devices and to avoid misalignment with the UDI final rule, we were urged to include the Distinct Identification Code among the identifiers that technology must be able to parse and make accessible to a user under this criterion.

Response.

The requirement to parse a UDI is reasonable despite the existence of multiple issuing agencies and formats. We disagree that this requirement is burdensome and note that it was supported by several health IT developers. This criterion would require health IT to be able to parse UDIs issued by FDA-accredited issuing agencies. There are currently three FDA-accredited issuing agencies (GS1, HIBCC, and ICCBBA)

and each issuing agency has only one approved UDI format. All three formats are unique and can thus be readily distinguished by health IT and parsed according to the correct format. The formats themselves are described in detail in a single five-page reference document available on the FDA Web site.

Each format has been approved by the FDA, and no changes can be made unless the FDA similarly approves of the changes prior to implementation.

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/UDIIssuingAgencies/default.htm

FDA,

UDI Formats by FDA-Accredited Issuing Agency

(May 7, 2014),

http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/GlobalUDIDatabaseGUDID/UCM396595.doc

. The reference document is one of two technical documents made available by the FDA to assist labelers and other persons to comply with the GUDID Guidance. See

http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/GlobalUDIDatabaseGUDID/ucm416106.htm

We disagree that the requirement to parse a UDI should be postponed until the emergence of a single canonical UDI format. It is unclear at this time when or if such a canonical format will be developed and whether it would support the functionality we are requiring. It is also unclear whether implementing a canonical format would reduce or increase the overall technical complexity and burden of implementing these capabilities for multiple UDI formats. Meanwhile, postponing these capabilities would frustrate the purpose of this certification criterion. Without the ability to parse a UDI, health IT would be unable to provide users with useful information identifying and safety-related information about a device, such as the device's expiration date (which will be parsed from the Production Identifier) or a description of the device (which will be retrieved by parsing and looking up the Device Identifier in the GUDID).

The omission of “Distinct Identification Code required by 21 CFR 1271.290(c)” among th

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.