2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities,…
Federal Information & News Dispatch, Inc. |
2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange
Final rule.
CFR Part: "45 CFR Part 170"
RIN Number: "RIN 0991-AB92"
Citation: "79 FR 54430"
Page Number: "54430"
"Rules and Regulations"
SUMMARY: This final rule introduces regulatory flexibilities and general improvements for certification to the 2014 Edition EHR certification criteria (2014 Edition). It also codifies a few revisions and updates to the ONC HIT Certification Program for certification to the 2014 Edition and future editions of certification criteria as well as makes administrative updates to the Code of Federal Regulations.
EFFECTIVE DATE: This rule is effective
The incorporation by reference of certain publications listed in the rule is approved by the Director of the
FOR FURTHER INFORMATION CONTACT:
SUPPLEMENTARY INFORMATION:
Commonly Used Acronyms
CDA Clinical Document Architecture
CDS Clinical Decision Support
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health Information Technology Product List
CLIA Clinical Laboratory Improvement Amendments
CQM Clinical Quality Measure
CY Calendar Year
EHR Electronic Health Record
EP Eligible Professional
FY Fiscal Year
HIT Health Information Technology
HITECH Health Information Technology for
HITSC HIT Standards Committee
HL7 Health Level Seven
IG Implementation Guide
IHE Integrating the Healthcare Enterprise(R)
LOINC(R) Logical Observation Identifiers Names and Codes
MU Meaningful Use
PHSA Public Health Service Act
SNOMED CT(R) Systematized Nomenclature of Medicine Clinical Terms
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
1. New Approach
2.
B. Summary of Major Provisions
1. Overview of the 2014 Edition Release 2 EHR Certification Criteria
2. ONC HIT Certification Program
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification Criteria
2. HIT Certification Programs
B. Regulatory History
1. Standards, Implementation Specifications, and Certification Criteria Rules
2. ONC HIT Certification Programs Rules
III. Adopted Proposals
A. 2014 Edition Release 2 EHR Certification Criteria
1. National Technology Transfer and Advancement Act (NTTAA) of 1995
2. Certification Criteria
3. Gap Certification Eligibility Table for 2014 Edition Release 2
4. Base EHR Definition
B. ONC HIT Certification Program
1. Discontinuation of the Complete EHR
2. Applicability
3. ONC Regulations FAQ 28
4. Patient List Creation Certification Criteria
5. ISO/IEC 17065
6. ONC Certification Mark
C. Removal of the 2011 Edition EHR Certification Criteria From the CFR
D. Removal of the Temporary Certification Program From the CFR
IV. Not Adopted Proposals
A. Not Adopted EHR Certification Criteria and Certification Criteria Proposals
B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
C. HIT Definitions
1. CEHRT
2. Common MU Data Set
C. ONC HIT Certification Program
1. Non-MU EHR Technology Certification
2. "Certification Packages" for EHR Modules
V. Comments Beyond the Scope of This Final Rule
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
I. Executive Summary
A. Purpose of Regulatory Action
1. New Approach
In the notice of proposed rulemaking titled "Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements; Proposed Rule" (79 FR 10880) (the "Proposed Rule"), we gave many reasons for the adoption of the proposed "2015 Edition EHR certification criteria" or "2015 Edition" (henceforth the "Proposed Voluntary Edition" (79 FR 10880)). /1/ We still believe that many of these reasons remain valid. However, upon consideration of public comment, further reflection of ONC goals and timelines, and a desire to adhere to the administration's principles embodied in Executive Order (EO) 13563, we have not adopted the Proposed Voluntary Edition. Rather, we have adopted a small subset of our original proposals in the Proposed Voluntary Edition as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria (also referred to as the "2014 Edition Release 2" or "2014 Edition Release 2 EHR certification criteria") that provide flexibility, clarity, and enhance health information exchange; and administrative proposals (i.e., removal of regulatory text from the Code of Federal Regulations) and proposals for the ONC HIT Certification Program that provide improvements. The certification criteria we have adopted in this final rule are consistent with the principles and instructions for retrospective review of regulations embodied in EO 13563 to make our program more effective and less burdensome in achieving regulatory objectives. This final rule introduces multiple means to reduce regulatory burden, increase regulatory flexibility for stakeholders, and promote further innovation.
FOOTNOTE 1 79 FR 10881-82. END FOOTNOTE
We note that EHR technology developers do not have to update and recertify their products to the 2014 Edition Release 2 nor do eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) have to upgrade to EHR technology certified to the 2014 Edition Release 2. However, we encourage EHR technology developers and the EPs, EHs, and CAHs that they support to consider whether the 2014 Edition Release 2 offers any opportunities that they might want to pursue.
2. Naming Conventions
In the Proposed Rule, we proposed to call the Proposed Voluntary Edition the "2015 Edition." /2/
FOOTNOTE 2 79 FR 10885. END FOOTNOTE
Comments. Commenters indicated that attributing years to the certification criteria editions creates unrealistic expectations for providers and other potential "users" of the certification program that vendors will develop products ready to be used by the designated edition year.
Response. In the
These two years "2011" and "2014" were purposefully chosen because they coincided with the first year in which compliance with that edition of EHR certification criteria would be required for use under the
FOOTNOTE 3 CMS final rule "Medicare Program; Physicians' Referrals to Health Care Entities With Which They Have Financial Relationships: Exception for Certain Electronic Health Records Arrangements" (78 FR 78751).
We and CMS recently issued a final rule (79 FR 52910) that demonstrated linking a certification criteria edition's year to any other program's compliance date could confuse the original intent of the edition's year selection (due to the final rule pushing back the compliance requirement of using EHR technology certified only to the 2014 Edition to fiscal year (FY) and calendar year (CY) 2015 for EPs, EHs, and CAHs). Accordingly, we believe that a simpler approach will be for future certification criteria editions to be named by the year in which the final rule is published, and other rulemakings like this final rule (which include additional criteria or alternatives to previously adopted certification criteria) would be added to the most current edition of certification criteria. To further clarify, a rulemaking like this one that does not adopt an edition of certification criteria would be referred to as "[current edition year] Release #X."
For example, we expect that the final rule for the next edition of certification criteria we adopt will be an edition of certification criteria and will be published in 2015. Thus, that edition of certification criteria would be called the "2015 Edition" because it will be an edition of certification criteria and its final rule would be published in 2015. If we were to subsequently issue a final rule in 2016 with seven certification criteria to support another HHS program or to make revisions to the adopted 2015 Edition certification criteria, we would refer to that rulemaking as the "2015 Edition Release 2" rulemaking and ultimately make modifications to the 2015 Edition certification criteria at its CFR location and regulation text.
Importantly, this provides stakeholders with a consistent and predictable naming approach for future editions and also supports ONC's broader interests to have the ONC HIT Certification Program be generally accessible to other programs either within or outside government. Stakeholders that seek to leverage the ONC HIT Certification Program would then be able to choose which edition of certification criteria (or subset of criteria within an edition) is most relevant and appropriate for their program needs.
B. Summary of Major Provisions
1. Overview of the 2014 Edition Release 2 EHR Certification Criteria
The 2014 Edition Release 2 EHR certification criteria we have adopted in this final rule include ten optional and two revised certification criteria for inclusion in the 2014 Edition. /4/ Each of these certification criteria originate with the current 2014 Edition. The optional certification criteria include the splitting of the "computerized provider order entry" (CPOE) criterion into three certification criteria based on capabilities (medications, laboratory, and diagnostic imaging); a "transitions of care" (ToC) certification criterion that is decoupled from the transport method; three separate transport method certification criteria (corresponding to the three transport standards found in
FOOTNOTE 4 As we explained in the Proposed Rule (79 FR 10918), the designation of "optional" for certification criteria (in this case, the 2014 Edition) was developed to accommodate the Complete EHR definition. If a certification criterion is not designated "optional," an EHR technology designed for the ambulatory setting or inpatient setting would need to be certified to the criterion in order to satisfy the Complete EHR definition and be issued a Complete EHR certification. END FOOTNOTE
The two revised certification criterion include a revised "view, download, and transmit to 3rd party" (VDT) certification criterion (
Table 1 below specifies the 2014 Edition Release 2 EHR certification criteria.
Table 1--2014 Edition Release 2 EHR Certification Criteria Optional certification criteria Regulation Title of regulation Revised Regulation section section paragraph certification criteria S. 170.314(a)(18) Optional-- S. 170.314(e)(1) View, download, and computerized transmit to 3rd provider order party. entry--medications S. 170.314(a)(19) Optional-- S. 170.314(g)(3) Safety-enhanced computerized design. provider order entry--laboratory S. 170.314(a)(20) Optional-- computerized provider order entry--diagnostic imaging. S. 170.314(b)(8) Optional-- transitions of care. S. 170.314(b)(9) Optional--clinical information reconciliation and incorporation. S. 170.314(f)(7) Optional-- ambulatory setting only--Transmission to public health agencies--syndromic surveillance. S. 170.314(g)(1) Optional--automated numerator recording. S. 170.314(h)(1) Optional-- Applicability Statement for Secure Health Transport. S. 170.314(h)(2) Optional-- Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging. S. 170.314(h)(3) Optional--SOAP Transport and Security Specification and XDR/XDM for Direct Messaging.
2. ONC HIT Certification Program
We proposed several modifications to the ONC HIT Certification Program, some of which we have finalized in this final rule. We are discontinuing the "Complete EHR" certification concept, including the definition, starting with the next certification criteria edition that we adopt in a subsequent final rule. This decision has no effect on certification to the 2014 Edition. We have adopted an updated standard (ISO/IEC 17065) for the accreditation of ONC-Authorized Certification Bodies (ACBs) to maintain alignment with industry practices. We have adopted the "ONC Certified HIT" certification and design mark for required use by ONC-ACBs, which we believe will provide clarity for the market as it relates to EHR technology certified under the program. We have designated the 2014 Edition "automated numerator recording" certification criterion (
C. Costs and Benefits
Our estimates indicate that this final rule is not an economically significant rule as its overall costs are significantly below
Table 2--Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)--Totals Rounded Year Ratio Total low Total Total (percent) cost high average estimate cost cost ( $M) estimate estimate ( $M) ( $M) 2014 50$1.46 $2.90 $2.19 2015 50 1.46 2.90 2.19 2-Year Totals 2.92 5.80 4.38
While we believe only a small number of EHR technology developers and other HIT developers will seek testing and certification to the optional and revised 2014 Edition certification criteria adopted in the final rule, the regulatory flexibility these certification criteria provide will offer several significant benefits to patients, health care providers, and HIT developers. The 2014 Edition Release 2 incorporates stakeholder feedback on particular 2014 Edition issues identified as impacting innovation and causing undue burden. The 2014 Edition Release 2 also seeks to continue to improve EHR technology's interoperability and electronic health information exchange. Specifically, the separating out of the "content" and "transport" capabilities in the optional 2014 Edition ToC certification criterion we have adopted in this final rule (compared to the 2014 Edition ToC certification criteria adopted at
II. Background
A. Statutory Basis
The Health Information Technology for
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two new federal advisory committees, the
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
Section 3004(b)(3) of the PHSA titled "Subsequent Standards Activity" provides that the "Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent" with the schedule published by the HITSC. We consider this provision in the broader context of the HITECH Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITSC and endorsed by the National Coordinator, as well as other appropriate and necessary HIT standards, implementation specifications, and certification criteria. Throughout this process, the Secretary intends to continue to seek the insights and recommendations of the HITSC.
2. HIT Certification Programs
Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of HIT. Specifically, section 3001(c)(5)(A) specifies that the "National Coordinator, in consultation with the Director of the
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
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,
The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2011 Edition Final Rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs under the
The Secretary issued a notice of proposed rulemaking with request for comments titled "Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the
On
On
On
On
2. ONC HIT Certification Program Rules
On
On
The 2014 Edition Final Rule made changes to the permanent certification program. The final rule adopted a proposal to change the Permanent Certification Program's name to the "ONC HIT Certification Program," revised the process for permitting the use of newer versions of "minimum standard" code sets, modified the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria, and reduced regulatory burden by eliminating the certification requirement that every EHR Module be certified to the "privacy and security" certification criteria.
The Proposed Rule included proposals that focused on improving regulatory clarity, simplifying the certification of EHR Modules that are designed for purposes other than achieving MU, and discontinuing the use of the Complete EHR definition starting with the "Proposed Voluntary Edition."
III. Adopted Proposals
A. 2014 Edition Release 2 EHR Certification Criteria
We proposed to adopt the Proposed Voluntary Edition, which included a full set of certification criteria (57 certification criteria) for the ambulatory and inpatient settings.
Comments. We received both positive and negative comments on the Proposed Voluntary Edition. Commenters that supported the Proposed Voluntary Edition stated that it was responsive to stakeholder feedback, permitted certification to new functionality and standards in a timely manner, and appropriately raised the bar on interoperability. Commenters that did not support the Proposed Voluntary Edition stated that the scope was too large, some standards were too immature for adoption, additional certification would be too costly (after just preparing EHR technology for certification to the 2014 Edition), and that it set an unrealistic expectation among providers and patients that EHR technology developers could have products certified to the Proposed Voluntary Edition in a timely manner (shortly after the 2014 Edition and while preparing for the next edition that would directly support MU Stage 3).
Response. We thank commenters for their support of the Proposed Voluntary Edition. We also appreciate the constructive feedback offered by other commenters. As stated in the Executive Summary, we have only adopted a small subset of our original proposals in the Proposed Voluntary Edition as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria (also referred to as the "2014 Edition Release 2" or "2014 Edition Release 2 EHR certification criteria") that provide flexibility, clarity and enhance health information exchange. While we believe there are many valid reasons for the adoption of the Proposed Voluntary Edition, including those mentioned by commenters, we believe that our approach in this final rule is the most appropriate at this time. This approach addresses commenters' concerns and introduces multiple means to reduce regulatory burden, increase regulatory flexibility for stakeholders, and promote further innovation.
1. National Technology Transfer and Advancement Act (NTTAA) of 1995
The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the
FOOTNOTE 5 http://www.whitehouse.gov/omb/circulars_a119. END FOOTNOTE
FOOTNOTE 6 http://www.healthit.gov/policy-researchers-implementers/direct-project. END FOOTNOTE
FOOTNOTE 7 http://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework. END FOOTNOTE
2. Certification Criteria
Computerized Provider Order Entry
Section 3000 of the PHSA, as added by section 13101 of the HITECH Act, requires that computerized provider order entry (CPOE) capabilities be included in CEHRT. We included CPOE capabilities in the Base EHR definition, which is part of the CEHRT definition, under 45 CFR 170.102. Within the 2011 and 2014 Editions, we adopted CPOE certification criteria that require EHR technology to be capable of performing CPOE for medication, laboratory, and radiology/imaging orders. In the Proposed Rule, we stated that based on stakeholder feedback since the 2014 Edition Final Rule, we understood that this approach can prevent EHR technology developers from creating more efficient, provider-specific "adaptations" of EHR technology that support CPOE. /8/ For example, a mobile adaptation of CPOE currently must include all of the capabilities listed in the 2014 Edition CPOE certification criterion (i.e., the adaptation must be capable of performing CPOE for each of the three types of orders (medication, laboratory and radiology/imaging)) even though the EHR technology developer's customers may only wish to use the mobile adaptation to enter medication orders away from the office.
FOOTNOTE 8 Please see 77 FR 54267-68 for a discussion of adaptations. END FOOTNOTE
Similarly, we noted that some providers could interpret our approach to CPOE certification as inconsistent with the flexibility provided in the FY/CY 2014 CEHRT definition under
For the reasons above, we proposed to split the CPOE certification criterion for the Proposed Voluntary Edition into three separate certification criteria with each criterion focused on one of the three order types, reasoning that certification criteria focused on each order type would permit EHR technology developers to develop order-specific CPOE adaptations and provide EPs, EHs, and CAHs with significantly more implementation flexibility.
In the Proposed Rule, we also stated that the proposed "CPOE" certification criteria would omit the "at a minimum" language included in the 2014 Edition and 2011 Edition CPOE certification criteria. We noted that the "at a minimum" language was included in prior editions to indicate that EHR technology developers could include capabilities that support other types of orders. We stated that this language is extraneous because we have consistently maintained that certification criteria (and certification in general) serve as minimum requirements or a baseline.
Comments. We received universal support for adopting three separate CPOE certification criteria based on medications, laboratory, and radiology/imaging orders. We also received support for the elimination of the "at a minimum" language found in the 2011 and 2014 Edition criteria with commenters stating that elimination of the language would remove redundancy from the criteria and reduce confusion.
Response. We have adopted these three certification criteria as 2014 Edition optional certification criteria based on stakeholder feedback and for the reasons we cited in the Proposed Rule. We clarify and emphasize that there are no standards included in the optional certification criteria, unlike the proposed CPOE--laboratory certification criterion. We have also omitted the "at a minimum" language in these certification criteria for the reasons proposed and supported by commenters.
We have changed the title of the certification criterion that supports CPOE for "radiology/imaging" (
We have adopted the optional certification criteria at
FOOTNOTE 9 Please see the 2014 Edition Final Rule (77 FR 54187) for a discussion of the capabilities and certification criteria that we believe present a risk to patient safety and thus are included in the SED certification criterion. END FOOTNOTE
As we noted in the Proposed Rule (79 FR 10886), we caution that this additional flexibility comes with potential risk for EPs who expect to qualify for one or more of the exclusions from the CPOE measures, but do not ultimately satisfy the exclusion criteria based on the number of orders written during an EHR reporting period. EPs who choose to possess EHR technology that is not certified for each of the three types of orders may risk not having EHR technology that meets the CEHRT definition if they ultimately fail to meet one or more MU exclusions. Therefore, we emphasize that EHR technology developers need to be aware that this additional certification flexibility and subsequent certification decisions could have corresponding impacts on EPs who are ultimately responsible for ensuring that their EHR technology meets the CEHRT definition.
We note that we discuss comments received on each of the three proposed CPOE certification criteria that suggested changes to the criteria under section IV.A "Not Adopted EHR Certification Criteria and Certification Criteria Proposals." This includes a discussion of our reasons for not adopting the HL7 Laboratory Orders Interface (LOI) standard and the Clinical Laboratory Improvement Amendments (CLIA)-related requirements for the proposed "CPOE--laboratory" certification criterion.
Transitions of Care
We proposed to make several changes to the "transitions of care" (ToC) certification criterion, including decoupling content and transport capabilities, the inclusion of the Direct Edge Protocols IG Version 1.0, and shifting the "incorporation" requirements into an updated "clinical information reconciliation and incorporation" (CIRI). We included several other proposals in the ToC certification criterion that we have not finalized. These proposals are discussed in section IV.A of this preamble.
"Decoupling" Content and Transport
In the Proposed Rule, we recited specific stakeholder feedback stating that the "binding" of transport and content capabilities within the scope of a single certification criterion could impede innovation and limit EPs', EHs', and CAHs' market choices for electronic health information exchange. We also recited stakeholder feedback indicating that we had incorrectly imposed the coupling of technical capabilities that can be adequately performed by two different systems. More specifically, stakeholders stated that content capabilities and transport capabilities should be separately tested and certified as the standard that supports one may change over time while the other remains the same. In this regard, we illustrated how the "binding" of the transport and content capabilities within the scope of a single criterion has led, in some cases, to the intertwining of EHR and health information service provider (HISP) functionality (i.e., HISP functionality being built into an EHR or EHR functionality being built into a HISP) solely for the purposes of certification. As a result, we proposed to decouple content and transport capabilities and adopt a single ToC criterion that focused on content capabilities and EHR technology's capability to connect to a service that is conformant with the primary
Comments. We received significant public comment on this proposal from associations representing providers, consumers, and HIT developers as well as comments from numerous HIT developers. The vast majority of the commenters supported decoupling content and transport capabilities, with some voicing concerns about the proposed Edge Protocol IG Version 1.0. Specifically, commenters noted that the decoupling represented a much-needed flexibility for HIT developers and a workflow update that reflected implementations already widely used. One commenter, an ONC-ACB, noted that ToC and HISP functionality was already separated for most EHRs across different systems. Other commenters voiced concerns that the decoupling would create a greater burden on providers and hospitals as they assemble their certified systems. Finally, comments from the EHR technology developer community stated that the change was proposed too late to provide flexibility, noting that they had already complied with the 2014 Edition requirements and combined the functionality.
Response. We have decided to finalize our proposal to decouple content and transport capabilities. We have also decided to adopt an updated version of the Direct Edge Protocols IG, which we discuss in more detail below. We appreciate the support for this proposal and agree with commenters that the decoupling will achieve much needed flexibility and allow for continued innovation in the market. While this flexibility may be considered too late by some stakeholders, we believe that the potential benefits of its availability for the 2015 EHR reporting period outweigh the negatives. Accordingly, we have adopted an optional ToC certification criterion at
Edge Protocol for EHR to HISP Connectivity for Direct Transmissions
Comments. Commenters voiced support for decoupling the content and transport requirements under the ToC criterion, however, many voiced concern about the Direct Edge Protocols IG Version 1.0 ("Version 1.0"). Commenters stated the protocol optionality in Version 1.0 provided the potential for interoperability incompatibilities. Commenters also noted that this level of optionality would require technology developers to support all four protocols in Version 1.0 in order to support the variety of valid protocol implementations in ToC. Commenters recommended ONC choose a minimum set of edge protocols that would be mandatory, instead of allowing all four. Other commenters noted that Version 1.0 was never intended to be part of a regulatory framework. Commenters also voiced concern that Version 1.0 did not have widespread development and implementation experience and it that it was premature to adopt it. Finally, commenters noted that the Direct Edge Protocols IG Version 1.1 ("Version 1.1") would be finalized shortly and urged us to include that version instead of Version 1.0 if we decided to adopt the Direct Edge Protocol IG.
Response. We appreciate the diverse and specific feedback on our proposal to adopt the Version 1.0. In addition to the comments we received on the Proposed Rule, stakeholders who helped develop Version 1.0 provided feedback (through the IG development process) that the edge protocol specifications and message tracking guidance needed to be clarified and refined based upon their experiences in the field. We agree that some of the ambiguities in Version 1.0 could introduce interoperability and implementation challenges for technology developers. Version 1.0 represented a first attempt toward a consistent and uniform approach for HISPs and EHR technology (and other so-called "edge" systems in the IG) to implement the most common protocols (described as "edge protocols" in the IG) between these systems.
In response to feedback, the stakeholder community (comprised of several HISPs and EHR technology developers) released an updated version of the IG for Direct Edge Protocols, Version 1.1 through the stakeholder lead
FOOTNOTE 10 http://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf. END FOOTNOTE
As outlined in the Proposed Rule, we believe it is important to adopt a Direct Edge Protocols IG in order to support the separation of content and transport related to ToC. If we were to not adopt a Direct Edge Protocols IG, HIT developers would likely first implement inconsistent approaches to edge protocols and then need to spend additional resources later to reconcile those inconsistencies. Providing for certification to Version 1.1 can enable greater certainty and assurance to HIT developers that products certified to this IG have implemented the IG's edge protocol(s) in a consistent manner. The availability of certification should also enhance HIT developers' ability to reliably connect their products without the need for customized interfaces and, ultimately, enable health care providers a greater ability to choose or switch HISP services.
Therefore, in consideration of public comments and our proposal to permit content and transport capabilities to be separately tested and certified, we have decided to adopt Version 1.1 as part of this optional ToC certification criterion. EHR technology presented for certification to the criterion adopted at
The following explains the context and reasons for our decision to adopt Version 1.1 as a standard at
Version 1.1 includes two key improvements upon Version 1.0:
* Version 1.1 clarifies the permissible combinations of edge protocols and their applicability within the scope of the IG. For example, two of the edge protocols within the IG (Post Office Protocol (POP) and Internet Message Access Protocol (IMAP)) are unidirectional, meaning they must be paired with another protocol to enable two-way communication between an "edge system" and its HISP. Version 1.0 did not clearly specify what the other protocols should be paired with POP and IMAP. Thus, implementers found this guidance incomplete and unclear. Version 1.1 addresses that ambiguity and instructs Edge systems to pair POP and IMAP with Simple Mail Transfer Protocol (SMTP).
* Version 1.1 clarifies technical constraints for
Version 1.1 references the same four edge protocols that were referenced in Version 1.0:
1. Integrating the Healthcare Enterprise (IHE) XDR profile for Limited Metadata Document Sources;
2.
3. Internet Message Access Protocol version 4rev1 (IMAP4); and
4. Post Office Protocol version 3 (POP3).
However, with respect to the edge system specifications identified in Version 1.1, such edge systems are expected to support either the "IHE XDR profile for Limited Metadata Document Sources" edge protocol or an
For this final rule, we evaluated whether to adopt a single edge protocol (of the four available) and decided to conduct fact finding with several HISPs and EHR technology developers to understand what edge protocol(s) they had implemented in the absence of any specific edge protocol requirements as part of the 2014 Edition. Our fact finding identified that EHR technology developers (for the ambulatory and inpatient settings) have already started implementing the two edge protocol approaches identified in Version 1.1 and used either an IHE XDR-based or
Overall, we believe that the adoption of Version 1.1 will further support efforts already underway by the community by enabling EHR technology developers to demonstrate through testing and certification that they have implemented an edge protocol in a manner consistent with Version 1.1. Without this consistency, interoperability could be impacted and make it difficult for any specific EHR technology to reliably connect to any HISP. It could also lead to greater costs to providers for continued customized interfaces for the edge connectivity to a HISP and, thus, make it more likely that the provider would be "locked-in" to that HISP instead of being able to pair with/subscribe to a HISP of their choosing.
Shifting "Incorporation" From ToC to Clinical Information Reconciliation
In response to stakeholder feedback indicating that the inclusion of "incorporation" capabilities in the 2014 Edition ToC criterion (
Comments. We received comments from several EHR developers on this proposal. Commenters overwhelmingly supported including the incorporation functionality in a CIRI criterion instead of a ToC criterion. Commenters stated that this was a better fit for the capabilities and more appropriate for clinical workflow. One commenter stated that we should change the language in the CIRI criterion to clarify ambiguities around the "extract" term and its associated requirements.
Response. Given the comments in support, we have finalized our proposal to "move" the incorporation requirements into an updated CIRI criterion as proposed. We have adopted the updated CIRI criterion as an optional 2014 Edition certification criterion at
Clinical Information Reconciliation and Incorporation
We proposed a CIRI certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. As discussed in more detail under the ToC certification criterion above, we proposed a CIRI criterion that included the same type of incorporation capabilities that we previously adopted as part of the ToC certification criterion at
Comments. As noted in the ToC certification criterion above, we received widespread support for "moving" the incorporation capabilities into a CIRI certification criterion. One commenter suggested that we make this certification criterion eligible for gap certification.
Response. We have adopted a new optional 2014 Edition CIRI certification criterion that includes the incorporation capability. We appreciate the comments in support of this proposal and believe it will more align with clinical workflow. This certification criterion is not eligible for gap certification because the change in capabilities required to meet this optional CIRI certification criterion make it a "revised" certification criterion as compared to the current 2014 Edition "clinical information reconciliation" (CIR) certification criterion and thus ineligible for gap certification.
We have also revised the SED certification criterion at
FOOTNOTE 11 Please see the 2014 Edition Final Rule (77 FR 54187) for a discussion of the capabilities and certification criteria that we believe presented a risk to patient safety and thus included in the SED certification criterion. END FOOTNOTE
View, Download, and Transmit to 3rd Party (VDT)
The Proposed Rule summary in this section only summarizes and includes the "comments" and "response" for the proposal that we have adopted as part of this final rule. We included several other proposals in the proposed VDT certification criterion that we have not finalized. These proposals are discussed in section IV.A of this preamble.
For the reasons we provided in the Proposed Rule for the separation of content capabilities and transport capabilities (79 FR 10896-97, 10906) and recited under the ToC certification criterion discussed previously in this preamble section, we proposed to "decouple" the transport and content capabilities of the VDT certification criterion. We noted that similar to the proposed ToC revisions, the certification criterion would focus on content requirements and EHR technology's ability to demonstrate conformance with the Direct Edge Protocols IG Version 1.0 and enable a successful transmission. We further specified that this would require EHR technology to enable a patient to accomplish a transmission that conforms to the Direct Edge Protocols IG Version 1.0 and is used by a service that has implemented the primary
We clarified that "accomplish" was intended to convey our expectation and that our anticipated approach through testing would be to assess whether the transmitted Consolidated Clinical Document Architecture (CDA) arrived at its destination. We emphasized that under this proposed revision EHR technology developers seeking testing and certification would be permitted to demonstrate compliance with the transport requirement without having to be a HISP (or be bound to a single HISP through certification). However, we indicated that demonstrating this outcome could be expedited if the EHR technology developer uses a service that is certified to enable health information to be electronically transmitted (sent and received) in accordance with the primary
Comments. Given the parallels between this proposal and the proposal we made for the ToC criterion, the vast majority of commenters expressed the same general support for the "decoupling." Commenters also expressed similar concerns about the proposed Edge Protocol IG Version 1.0 interoperability incompatibilities and the need for HIT developers to support all four protocols in order to support the variety of valid protocol implementations. In general, commenters stated that the decoupling of content and transport represented a much-needed flexibility for developers and a workflow update that reflected implementations already widely used.
Response. For the same reasons we provide in response to the ToC certification criterion related to the decoupling of content and transport as well as the Direct Edge Protocols IG Version 1.1, we have adopted Version 1.1 for the purposes of the VDT certification criterion. In light of our overall approach for this final rule's scope, we have determined that the best and simplest approach to include this new flexibility is to modify the existing VDT certification criterion at
FOOTNOTE 12 77 FR 54182. END FOOTNOTE
Transmission to Public Health Agencies--Syndromic Surveillance
We proposed to revise the 2014 Edition "syndromic surveillance" certification criterion and adopt a parallel "syndromic surveillance" certification criterion for the Proposed Voluntary Edition.
For both MU Stages 1 and 2, EPs may choose the "electronic syndromic surveillance data" objective under the menu set. In the MU Stage 2 final rule, CMS stated that very few public health agencies were accepting syndromic surveillance data from ambulatory, non-hospital providers, and there was no corresponding HL7 2.5.1 IG available at the time of the final rule's publication (77 FR 54025). CMS also noted, however, that the CDC was working with the syndromic surveillance community to develop a new IG for ambulatory reporting of syndromic surveillance data, which was expected to be published in spring 2013.
We stated in the Proposed Rule that only a few public health agencies are currently accepting syndromic surveillance data from the ambulatory setting using HL7 2.5.1. We stated that due to lack of demand, the CDC no longer planned to develop an HL7 2.5.1 IG for ambulatory reporting of syndromic surveillance data and that without such an IG most public health agencies would not have enough specific guidance to build systems to receive syndromic surveillance data from the ambulatory setting formatted to HL7 2.5.1. Further, we noted that the MU Stage 2 final rule permits an EP, EH, or CAH to claim an exclusion if the public health agency does not have the capacity to accept reporting (77 FR 54021) and, therefore, many EPs may qualify for an exclusion for this objective and associated measure and, as a result, would need to choose another objective from the menu set on which to report.
Given the lack of an ambulatory IG for HL7 2.5.1, we proposed to revise the current 2014 Edition certification criterion to allow EHR technology designed for the ambulatory setting to be certified to alternative standards that support other modes of electronic syndromic surveillance data submission. In this regard, we indicated that syndromic surveillance data was being sent to public health agencies through new query-based models, including the QueryHealth initiative. /13/ Query-based models take patient level data, de-identify it, and aggregate it for population health use. In the Proposed Rule, we also noted that we understood that the query-based models use HL7 CDA and QRDA Category III ("QRDA III") standards, and did not necessarily use the HL7 2.5.1 standard. Further, we stated that CDA and QRDA III standards were adopted and referenced by 2014 Edition certification criteria and, as a result, had become more widely implemented.
FOOTNOTE 13 http://wiki.siframework.org/Query+Health. END FOOTNOTE
In light of the potential that many EPs may qualify for an exclusion for the MU objective and associated measure with which this certification criterion correlates, we noted that we sought to make available additional electronic syndromic surveillance submission capabilities in order to better support their opportunity to receive credit for the syndromic surveillance MU objective. Therefore, we proposed to specifically revise the 2014 Edition "syndromic surveillance" certification criterion at
For EHR technology certification to the inpatient setting, we proposed to revise the 2014 Edition certification criterion by replacing the adopted version of the HL7 2.5.1 IG with a newer version of the IG that incorporates an addendum clarifying conformance guidance (PHIN Messaging Guide for Syndromic Surveillance:
We proposed the same ambulatory and inpatient setting requirements in a parallel "syndromic surveillance" certification criterion for the Proposed Voluntary Edition.
We solicited comment on whether public health agencies are using the QRDA Category I standard to receive query-based syndromic surveillance data, and whether we should consider adopting the standard for the ambulatory setting.
Comments. We received a range of comments on the use of the CDA and QRDA III standards in addition to the HL7 2.5.1 standard for ambulatory setting certification. Some commenters stated that the added flexibility of allowing alternate standards would increase the exchange of syndromic surveillance data. Commenters stated that the lack of a HL7 2.5.1 IG for the ambulatory setting has led to variation across EHRs. Other commenters opined that the absence of an HL7 2.5.1 IG for the ambulatory setting has also resulted in reluctance from EHR developers to build custom interfaces to enable public health agencies to receive ambulatory syndromic surveillance. One public health agency commented that they have built the infrastructure to receive CDA and QRDA III through their HIE and related partners. This public health agency stated that CDA and QRDA III standards could represent significant advances for timely and efficient ambulatory syndromic surveillance data collection and supported the proposal to allow alternate standards for certification.
Commenters in opposition to the proposal to allow use of CDA and QRDA III standards for certification stated that ONC should promote a single standard for ambulatory syndromic surveillance rather than allow multiple standards. Others commented that despite the proposed regulation text permitting use of HL7 2.5.1, CDA, "or" QRDA III standards, the "or" would really be implemented as an "and" if the EHR technology developer's customers want to use CDA or QRDA III because an EHR developer would have to offer any and all options desired by their customers. Some commenters expressed concern that public health agencies are not ready to develop the infrastructure to receive CDA and QRDA III data if they had not previously done so. Commenters noted that, without specific IGs for the use of CDA and QRDA III for ambulatory syndromic surveillance, the standards are not constrained enough to reach uniform submission of the data. Likewise, commenters indicated that the CDA and QRDA III standards have not been piloted or tested for syndromic surveillance purposes.
The majority of commenters supported adoption of the proposed updated IG for inpatient certification. However, many commenters stated that since the IG Release 1.9 publication numerous errors have been identified with Release 1.9. For example, many commenters pointed to the report issued by the
FOOTNOTE 14 The ISDS Issue Report is available at https://docs.google.com/spreadsheet/ccc?key=0AlhELG407-6OdFVPa0ZjZXFjYnNVd0tPSHRCRGF0WXc&usp=sharing. END FOOTNOTE
A few commenters stated that QRDA Category I is not being used for query-based syndromic surveillance in ambulatory settings and opined that Category I is not appropriate as it includes patient-level results rather than aggregate results which are more suitable for syndromic surveillance.
Response. We proposed revisions to the 2014 Edition version of this criterion and a "syndromic surveillance" certification criterion for the Proposed Voluntary Edition to permit alternate standards for the transmission of ambulatory syndromic surveillance data as a means of providing additional flexibility for EHR technology certification and for EPs attempting to meet the syndromic surveillance MU objective and measure. Since publication of the Proposed Rule we have heard from the CDC that some public health agencies have requested that the CDC reconsider developing an IG for HL7 2.5.1 as the HL7 2.5.1 standard is used by some public health agencies.
With consideration of the request to CDC, our overall approach to this final rule as described in the Executive Summary, and to provide the most clarity for certification as possible, we are not removing or revising the current 2014 Edition "syndromic surveillance" certification criterion (
FOOTNOTE 15 MU2 Measure: Successful ongoing submission of electronic syndromic surveillance data from certified EHR technology to a public health agency for the entire EHR reporting period. END FOOTNOTE
We agree with commenters that without specific IGs for the use of CDA and QRDA III for the transmission of ambulatory syndromic surveillance data, the standards are not constrained enough on their own to enable interoperable submissions. However, even before publication of the Proposed Rule, query-based standards were piloted and demonstrated in a few cases for ambulatory syndromic surveillance data, including through the QueryHealth initiative. These efforts and the use of query-based models continue and we expect the use of query-based models to grow among public health agencies. Therefore, we concluded that the best approach at this time was to adopt an optional "syndromic surveillance" certification criterion that permits EHR technology designed for the ambulatory setting to simply demonstrate that it can electronically create syndrome-based public health surveillance information for electronic submission (using any method or standard) to be certified to this criterion. This provides certification flexibility and potential EP flexibility as mentioned above, while also providing a path forward as described below.
Because there is no current IG that supports ambulatory syndromic surveillance data submission using query-based standards, we have also included an optional set of data elements within this optional certification criterion to provide some additional specificity and to which EHR technology developers may choose to have their EHR technology certified. These data elements are: Patient demographics, provider specialty, provider address, problem list, vital signs, laboratory results, procedures, medications, and insurance. While the aforementioned data elements are optional for the purposes of demonstrating compliance to this certification criterion, if an EHR technology developer wishes to certify its EHR technology to this criterion as a whole, including the optional data set, the EHR technology would need to demonstrate that it can electronically produce syndromic surveillance information that contains all of the data elements. In other words, an EHR technology that could only produce half of the data elements would not be able to be certified to this optional portion of the criterion. The public health agencies and stakeholders that have piloted and continue to pilot query-based models for transmitting ambulatory syndromic surveillance data send all of the data elements identified above. Therefore, by identifying these data elements for certification, EHR technology developers will have clarity as to the data elements they should focus on for creating syndrome-based public health information submissions and will need to include to support query-based models now and in the future, including any potential certification requirements introduced through future rulemaking.
The use of the QRDA III standard represents the response portion of a query-response model, but there currently are no mature standards for the query portion of the model of which we are aware. We intend to continue working with stakeholders on standards for both the query and response portions to support the electronic transmission of ambulatory syndromic surveillance data. We intend to gather more information regarding the implementation guidance provided by stakeholders that are currently piloting or using CDA or constrained QRDA III for ambulatory syndromic surveillance data transmissions to inform our consideration of what standards to propose in the future. This work will include confirming which data elements are commonly transmitted through these and other query-based models, such as the ones identified above and any other data elements that may also be typically sent using query-based approaches.
Given our approach to this final rule as stated in the Executive Summary, we have not adopted the IG Release 1.9 for inpatient certification to either the current "syndromic surveillance" certification criterion or the optional "syndromic surveillance" certification criterion we have adopted in this final rule. We agree with comments that any issues or errors identified in Release 1.9 should be remedied before requiring the IG for adoption. We also recognize that the industry is working on Release 2.0 of the IG. Therefore, we will consider this feedback for future rulemaking concerning a "syndromic surveillance" certification criterion.
We also thank commenters for the input on the usefulness of QRDA Category I for query-based ambulatory syndromic surveillance and will consider this feedback for future rulemaking.
Transport Methods (Formerly "Transmission") Certification Criteria
As a result of our proposal to decouple content and transport capabilities from the ToC certification criteria and VDT certification criterion, we proposed to adopt three separate transport certification criteria. These three proposed transport certification criteria mirrored the specific transport capabilities identified within the 2014 Edition ToC certification criteria at
Comments. Commenters generally supported the separation of content and transport (as outlined in more detail under the ToC certification criterion above) and the inclusion of independent transport certification criteria in order to support our overall approach to decoupling content and transport capabilities. Some commenters believed the first three transport criteria (i.e., Direct, Direct and XDR/XDM for Direct Messaging, and SOAP RTM and XDR/XDM for Direct Messaging) should be eligible for gap certification because each capability could be tested as part of the 2014 Edition ToC criteria. One commenter asked for clarification regarding the grouping of the proposed certification criteria. Specifically, the commenter asked if the transport criteria were separate and could be individually tested and certified.
Response. We have revised the title of this category of certification criteria for clarity. We now refer to this category of certification criteria (
We appreciate the widespread support and feedback regarding the decoupling of content and transport requirements. We believe finalizing three, independent transport criteria will allow technology developers to build in the transport capabilities suited to their customers' needs. Therefore, consistent with our earlier discussion related to the optional ToC certification criterion (
As noted in the following section (III.A.3 "Gap Certification Eligibility Table for 2014 Edition Release 2"), the certification criteria for Direct, Direct and XDR/XDM for Direct Messaging, and SOAP RTM and XDR/XDM for Direct Messaging are eligible for gap certification. We discuss each certification criterion in more detail in the following comments and responses.
Comments. Some commenters asked that we identify one transport criterion as the minimum required for transport. The commenters noted that if one method of transmission were not required, vendors would be forced to support all transport methods.
Response. As we explained in the preamble of the Proposed Rule, we seek to maintain the same policy we included in the 2014 Edition Final Rule--that in order for EPs, EHs, and CAHs to have EHR technology that met the CEHRT definition they would need to have EHR technology capable of performing transmissions in accordance with the primary
Applicability Statement for
Comments. Commenters widely supported the adoption of this certification criterion. One commenter noted that in the case of immunization information, Direct is a suboptimal transport method.
Response. We appreciate the comments received on this certification criterion and have adopted this criterion as a new optional certification criterion at
Applicability Statement for
Comments. We did not receive any comments suggesting we not adopt this specific criterion.
Response. We have adopted this criterion as a new optional certification criterion at
Comments. Commenters supported the adoption of this certification criterion. One commenter noted that this criterion would best support immunization information transmissions.
Response. We appreciate the comments we received on this criterion and have adopted this criterion as a new optional certification criterion at
3. Gap Certification Eligibility Table for 2014 Edition Release 2
"Gap certification" is defined at 45 CFR 170.502 as "the certification of a previously certified Complete EHR or EHR Module(s) to: (1) [a]ll applicable new and/or revised certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results of a NVLAP-accredited testing laboratory; and (2) [a]ll other applicable certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results used to previously certify the Complete EHR or EHR Module(s)" (for further explanation, see 76 FR 1307-1308). Our gap certification policy focuses on the differences between certification criteria that are adopted through rulemaking at different points in time. Under our gap certification policy, "unchanged" criteria (see 77 FR 54248 for further explanation) are eligible for gap certification, and each ONC-ACB has discretion over whether it will provide the option of gap certification.
In the Proposed Rule, we included a table (79 FR 10916) that provided a crosswalk of unchanged Proposed Voluntary Edition EHR certification criteria to the corresponding 2014 Edition EHR certification criteria. We provided corrections to this table in a notice published in the
Table 3--Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria 2014 edition release 2 2014 Edition n Regulation Title of Regulation Title of section regulation section regulation paragraph paragraph S. 170.314(a)(18) Optional-- computerized physician order entry--medications S. 170.314(a)(19) Optional-- S. 170.314(a)(1) Computerized computerized physician order physician order entry entry--laboratory. S. 170.314(a)(20) Optional-- computerized physician order entry--diagnostic imaging. S. 170.314(f)(7) * Optional-- S. 170.314(f)(3) Transmission to ambulatory setting public health only--transmission agencies--syndromic to public health surveillance agencies--syndromic (ambulatory setting surveillance only) S. 170.314(h)(1) Optional-- S. 170.314(b)(1) Transitions of Applicability (i)(A) and care--receive, Statement for S. 170.314(b)(2) display, and Secure Health (ii)(A). incorporate transition of care/referral summaries.Transitio ns of care--create and transmit transition of care/referral summaries. S. 170.314(h)(2) Optional-- S. 170.314(b)(1) Transitions of Applicability (i)(B) and care--receive, Statement for S. 170.314(b)(2) display, and Secure Health (ii)(B). incorporate Transport and transition of XDR/XDM for Direct care/referral Messaging summaries Transitions of care--create and transmit transition of care/referral summaries. S. 170.314(h)(3) Optional--SOAP S. 170.314(b)(1) Transitions of Transport and (i)(C) and care--create and Security S. 170.314(b)(2) transmit transition Specification and (ii)(C). of care/referral XDR/XDM for Direct summaries Messaging
Table 3--Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria 2014 edition release 2 *2*2011 Edition Regulation Title of Regulation section Title of section regulation regulation paragraph paragraph S. 170.314(a)(18) Optional-- computerized physician order entry--medications S. 170.314(a)(19) Optional-- S. 170.304(a); Computerized computerized S. 170.306(a) physician order physician order entry. entry--laboratory. S. 170.314(a)(20) Optional-- computerized physician order entry--diagnostic imaging. S. 170.314(f)(7) * Optional-- S. 170.302(1) Public health ambulatory setting surveillance only--transmission (ambulatory setting to public health only). agencies--syndromic surveillance S. 170.314(h)(1) Optional-- Not applicable Not applicable. Applicability Statement for Secure Health S. 170.314(h)(2) Optional-- Not applicable Not applicable. Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging S. 170.314(h)(3) Optional--SOAP Not applicable Not applicable. Transport and Security Specification and XDR/XDM for Direct Messaging * Gap certification does not apply for the optional data elements listed in S. 170.314(f)(7).
4. Base EHR Definition
We proposed to include in the Base EHR definition (a foundational part of the CEHRT definition) the Proposed Voluntary Edition EHR certification criteria that corresponded to the 2014 Edition EHR certification criteria already specified in the Base EHR definition (i.e., CPOE, demographics, problem list, medication list, medication allergy list, clinical decision support (CDS), CQMs, transitions of care, data portability, and privacy and security).
Comments. We received a comment that supported the inclusion of the proposed CPOE certification criteria in the Base EHR definition because it would provide the potential for more flexibility and less burden for EPs, EHs, and CAHs in meeting the Base EHR definition.
Response. We have not revised the Base EHR definition as proposed. However, we have revised the Base EHR definition to include the optional CPOE, ToC, and the Direct transport (
B. ONC HIT Certification Program
1. Discontinuation of the Complete EHR
We proposed to discontinue use of the Complete EHR definition as a regulatory concept and the certification of Complete EHRs beginning with the Proposed Voluntary Edition. As an alternative to the proposal, if we were to keep the Complete EHR concept and definition for editions of certification criteria beyond the 2014 Edition, we proposed to either continue the same policy of adopting an edition-specific Complete EHR (e.g., "2015 Edition" Complete EHR) or define a Complete EHR as "EHR technology that has been developed to meet, at a minimum, all mandatory certification criteria of an edition of EHR certification criteria adopted by the Secretary for either an ambulatory setting or inpatient setting and meets the Base EHR definition." For the latter, we noted that ONC-ACBs would be responsible for issuing Complete EHR certifications that specify the edition the Complete EHR was certified to and that the information would be evident through listing on the Certified HIT Product List (CHPL).
Comments. We received many comments from associations representing providers, consumers, and HIT developers as well as comments from numerous HIT developers. The overwhelming majority supported our proposal to discontinue the Complete EHR definition and Complete EHR certification for the reasons we specified in the Proposed Rule (recited below in the response). One association was neither for nor against our proposal, but was more concerned that providers have a clear understanding of what they are purchasing. In particular, the association stated that information outlining the product's criteria should be readily apparent when purchasing the product and also available on ONC's Web site. A few commenters suggested that we retain Complete EHR certification as an option for EHR technology developer and consumer purchasing. One of these commenters recommended that we tailor a Complete EHR certification by the MU Stage it would be associated with, while another suggested calling it a "Comprehensive EHR."
Response. We have finalized our proposal to discontinue the Complete EHR definition and Complete EHR certification. While we have not adopted the Proposed Voluntary Edition, this approach will apply for all future adopted editions of certification criteria as specified in
In the Proposed Rule (79 FR 10917-10918), we explained our rationale for discontinuing the Complete EHR definition. We are reciting our rationale again here as we still believe these reasons hold true. Following the recitation of these reasons, with minor modifications due to the MU Flexibility Final Rule (79 FR 52910), we offer further rationale and responses to comments.
(1) The Complete EHR definition initially was intended to support the original CEHRT definition established in the 2011 Edition Final Rule under
(2) Since publication of the 2014 Edition Final Rule, we have received stakeholder feedback through email questions and during educational presentations and other outreach that demonstrates confusion about the interplay between the CEHRT definition, the Base EHR definition (adopted as part of the 2014 Edition Final Rule), and the Complete EHR definition. Stakeholders have correctly concluded that a certified 2014 Edition Complete EHR could be used to meet the CEHRT definition. However, some stakeholders believe incorrectly that their only regulatory option to meet the CEHRT definition is to adopt a certified Complete EHR when, under the CEHRT definition for FY/CY 2014 and subsequent years in
(3) A Complete EHR is not necessarily "complete" or sufficient when it comes to an EP's, EH's, or CAH's attempt to achieve MU. For example, based on the "Complete EHR, 2014 Edition" definition, it may not be certified to particular CQMs on which an EP intends to report and it may not have been certified to capabilities included in optional certification criteria that an EP needs for MU, such as the 2014 Edition cancer reporting certification criteria (
(4) Stakeholder feedback to us since the 2014 Edition Final Rule (via conference and webinar question and answer sessions, public meetings, and emails) and the data currently available on the CHPL indicates that some EHR technology developers have continued to seek only a 2014 Edition Complete EHR certification and, thus, only plan to offer a certified Complete EHR as a solution to customers. While we recognize EHR technology developers may choose to pursue various approaches for designing and marketing their products, we are in a position to modify our policy so that it does not encourage EHR technology developers to offer only a single certified solution. In general, we believe the decision to seek certification only for a Complete EHR serves to defeat the flexibility provided by the 2014 Edition CEHRT definition. Consequently, by discontinuing the availability of the Complete EHR certification, the EHR technology market could be driven by EHR technology developers competing on the capabilities included in their EHR technology rather than on the type of certification issued (Complete EHR or EHR Module).
(5) The discrepancy between what any single EP, EH, or CAH needs to achieve MU and the Complete EHR definition will likely only grow more disparate when we adopt certification criteria in a new edition to support MU Stage 3. At that time, there may be EPs, EHs, and CAHs attempting to achieve each of the three stages of MU, but a Complete EHR following the structure of the 2014 Edition Complete EHR definition would likely include capabilities that support core and menu objectives and measures for all MU stages.
(6) Discontinuing the use of the Complete EHR concept would be consistent with the instruction of Executive Order 13563 to identify and consider approaches that make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives. To illustrate, we would not need to designate EHR certification criteria as mandatory or optional in our regulation text as these categories were specifically developed to accommodate the Complete EHR definition (i.e., cases where EHR technology would otherwise have to be certified to a criterion solely because it is required in order to satisfy the Complete EHR certification).
As stated in the Proposed Rule, discontinuation of Complete EHR definition and certification does not affect EHR Module certification. In fact, as it stands now with 2014 Edition certification, an EHR Module certificate can be issued to an EHR technology that includes every certification criterion that is included in a Complete EHR certificate issued to an EHR technology (and even with the EHR Module certificate, the capabilities can be integrated in the same manner), /16/ but would not be given the "Complete EHR" designation. The discontinuation of the Complete EHR definition and certification will also help to address commenters' concerns about clearly knowing what certification criteria an EHR technology is certified to because, unlike Complete EHR developers for their Complete EHRs, an EHR Module developer is required by regulation to specifically list in communications and marketing materials all the certification criteria to which the EHR technology was certified and for which it was issued an EHR Module certificate. Therefore, with only EHR Module certificates on the market, we believe it will be easier to know and compare the certification criteria to which they have been certified. Last, while we do not believe the use of the terms "Complete" or "Comprehensive" are appropriate for "labeling" EHR technology going forward, we will consider for our next rulemaking whether any other "labeling" for certified technologies could continue to make the scope of certification clearer.
FOOTNOTE 16 To note, the ONC HIT Certification Program does not include integration testing and certification of Complete EHRs or EHR Modules as that is left to the EHR technology developer and its customers. END FOOTNOTE
2. Applicability
We proposed to revise the "applicability" section (
Comments. We received two comments expressing agreement with our proposal.
Response. We have finalized our proposal consistent with our decision to finalize the proposals to discontinue use of the Complete EHR concept and Complete EHR certification for any subsequent adopted edition of certification criteria. We have, however, finalized this proposal in a manner that accounts for our decision not to adopt the Proposed Voluntary Edition. Specifically, we have revised
3. ONC Regulations FAQ 28
In ONC regulations FAQ 28, /17/ we provide guidance on the application of
FOOTNOTE 17 http://www.healthit.gov/policy-researchers-implementers/28-question-11-12-028. END FOOTNOTE
To provide regulatory clarity, we proposed to revise
We proposed to revise
We proposed that if were to retain the Complete EHR concept for the Proposed Voluntary Edition, we would take the same approach for Complete EHRs as specified in FAQ 28 and in our proposed regulatory changes to
Comments. We received a few comments supporting the continued requirement for Complete EHRs to be certified to the "automated measure calculation" certification criterion (
Response. We have not finalized the proposals related to the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. We have, however, finalized the proposals related to the 2014 Edition. We have designated the "automated numerator recording" certification criterion at
We also maintain our clarification and guidance included in the Proposed Rule related to an EHR Module being able to be certified to only the "automated measure calculation" certification criterion (
4. Patient List Creation Certification Criteria
In the Proposed Rule, we discussed how the 2014 Edition (and Proposed Voluntary Edition) "patient list creation" certification criterion includes capabilities that support two MU objectives, one with a percentage-based measure and one without (i.e., "use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care and send these patients the reminders, per patient preference" ("patient reminders") /18/ and "generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, or outreach," respectively). We clarified that in situations where EHR technology is presented for certification to the 2014 Edition (and Proposed Voluntary Edition) "patient list creation" certification criterion and does not include a capability to support "patient reminders," it would not need to be certified to the "automated numerator recording" certification criterion (
FOOTNOTE 18 The MU measure for this objective is: More than 10 percent of all unique patients who have had 2 or more office visits with the EP within the 24 months before the beginning of the EHR reporting period were sent a reminder, per patient preference when available. END FOOTNOTE
Comments. We received a few comments supporting our clarification and guidance. An ONC-ACB further noted that, in its experience, there are only a "handful" of EHR technologies presented for certification for which this type of scenario would be applicable.
Response. We appreciate commenters' support and agreement with our clarification and guidance. While we have not adopted the proposed "patient list creation" certification criterion, our clarification and guidance remains applicable for the certification of EHR technology to the 2014 Edition "patient list creation" certification criterion (
5. ISO/IEC 17065
Section 170.503(b)(1) requires applicants for ONC-Approved Accreditor (ONC-AA) status to provide a detailed description of their experience evaluating the conformance of certification bodies to
FOOTNOTE 19 http://www.iso.org/iso/catalogue_detail.htm?csnumber=46568. ISO slide presentation on 17065: http://www.iso.org/iso/ppt_presentation_17065.ppt. END FOOTNOTE
Because ISO has replaced Guide 65 with ISO/IEC 17065, we proposed to revise
FOOTNOTE 20
We also proposed to revise our references to ISO/IEC standards 17011, 17065 and Guide 65 in
Comments. We received comments from the ONC-AA and ONC-ACBs. The comments from these organizations specifically supported our proposals transition from Guide 65 to ISO 17065 and to remove the date reference for each standard.
Response. We appreciate the comments of support for our proposals and also note that, as anticipated, an accreditation organization (ANSI) was selected to serve as the ONC-AA for a 3-year term that began in
FOOTNOTE 21 http://www.hhs.gov/news/press/2014pres/05/20140513c.html. END FOOTNOTE
6. ONC Certification Mark
ONC has developed and administers the "ONC Certified HIT" certification and design mark (the "Mark"). /22/ The Mark, as used by an authorized user, certifies that a particular HIT product (Complete EHR, EHR Module, or other types of HIT for which the Secretary of HHS adopts applicable certification criteria, See 45 CFR 170.510) has been tested in accordance with test procedures approved by the National Coordinator; has been certified in accordance with the certification criteria adopted by the Secretary at 45 CFR part 170, Subpart C; and has met all other required conditions of the ONC HIT Certification Program at 45 CFR part 170, Subpart E.
FOOTNOTE 22 http://www.healthit.gov/policy-researchers-implementers/onc-hit-certification-program. END FOOTNOTE
We proposed to require ONC-ACBs to use the Mark in connection with HIT they certify under the ONC HIT Certification Program. More specifically, we proposed to revise
FOOTNOTE 23 http://www.healthit.gov/sites/default/files/hit_certificationterms_of_use_final.pdf. END FOOTNOTE
Comments. Commenters expressed agreement with our proposals citing to the consistency and clarity that a standard mark would provide in terms of identifying HIT certified under the ONC HIT Certification Program. One commenter requested clarification as to whether ONC-ACBs may also use their own mark in conjunction with the Mark, while another commenter requested clarity as to whether a HIT developer would be required to use the Mark.
Response. We thank commenters for their support. We have finalized the revisions to
C. Removal of the 2011 Edition EHR Certification Criteria From the CFR
We proposed to remove the 2011 Edition EHR Certification Criteria and related standards, terms, and requirements from the CFR. Specifically, we proposed to remove 45 CFR 170.302, 170.304, and 170.306. We also proposed to remove the standards and implementation specifications found in 45 CFR 170.205, 170.207, 170.210, and 170.299 that are only referenced in the 2011 Edition EHR certification criteria. In regard to terms, we proposed to retire the definitions found in 45 CFR 170.102 related to the 2011 Edition, including "2011 Edition EHR certification criteria" and "Complete EHR, 2011 Edition." In regard to requirements, we proposed to remove
Comments. We received one comment supporting this "administrative update."
Response. In the Proposed Rule, we stated that EHR technology certified to 2011 Edition no longer meets the CEHRT definition. We also referenced recent rulemakings by the
FOOTNOTE 24 CMS final rule "Medicare Program; Physicians' Referrals to Health Care Entities With Which They Have Financial Relationships: Exception for Certain Electronic Health Records Arrangements" (78 FR 78751).
Since publication of our Proposed Rule, we and CMS jointly issued a final rule entitled "
D. Removal of the Temporary Certification Program From the CFR
The temporary certification program sunset on
Comments. We received no comments on this proposal.
Response. We are removing the temporary certification program regulations from the CFR on the effective date of this final rule.
IV. Not Adopted Proposals
This section of the preamble discusses proposals from the Proposed Rule that we have not adopted, including comments received on those proposals and our response to those comments. As noted in the Executive Summary, we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange; and administrative proposals (i.e., removal of regulatory text from the CFR) and proposals for the ONC HIT Certification Program that provide improvements.
A. Not Adopted EHR Certification Criteria and Certification Criteria Proposals Applicability--
Section 170.300 establishes the applicability of subpart C--Certification Criteria for Health Information Technology. We proposed to revise paragraph (d) of
Comments. We did not receive any comments on this specific proposal.
Response. As noted in the Executive Summary, we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. Therefore, we have not revised paragraph (d) of
Computerized Provider Order Entry--Medications
We proposed to adopt for the Proposed Voluntary Edition a CPOE certification criterion specific to medication ordering. The proposed criterion was structured substantially similar to the 2014 Edition CPOE certification criterion, except it did not reference laboratory and radiology/imaging orders. We did not request any specific public comments on this certification criterion.
Comments. One commenter recommended that we add functionality that would allow health care providers to electronically report adverse events related to medications directly to manufacturers and the
Response. We appreciate these comments, but they are outside the scope of the proposed criterion. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion.
Computerized Provider Order Entry--Laboratory
We proposed to adopt for the Proposed Voluntary Edition a CPOE certification criterion specific to laboratory ordering. We proposed to adopt, for the ambulatory setting, the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1-US Realm, Draft Standard for Trial Use,
FOOTNOTE 25 http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922. END FOOTNOTE
Comments. Commenters were generally supportive of adoption of interoperable laboratory standards, particularly the LOI IG, and aligning requirements with
Response. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion. We first note that we did not propose to adopt the eDOS IG because it was our understanding that the eDOS IG was still undergoing revisions at the time the Proposed Rule was being drafted. We also understood that the LOI IG was fairly new and we appreciate the stakeholder feedback on potential concerns with the LOI IG. We also thank commenters for their insight related to the use of LOINC(R) for all laboratory orders. While we have not adopted the LOI IG at this time, we plan to reconsider it for adoption in our next rulemaking along with the eDOS IG. We believe the time between now and our next final rule will permit many of the concerns with these IGs to be sufficiently addressed. Overall, the work towards laboratory interoperability and electronic exchange shows great promise, including the work on the Lab Results Interface (LRI) IG, Electronic Laboratory Reporting to Public Health (ELR) IG and harmonization of all laboratory IGs. The adoption of these standards for the ONC HIT Certification Program could help facilitate laboratory interoperability and electronic exchange among providers, assist laboratories with
Computerized Provider Order Entry--Radiology/Imaging
We proposed to adopt for the Proposed Voluntary Edition a CPOE certification criterion specific to radiology/imaging. The proposed criterion was structured substantially similar to the 2014 Edition CPOE certification criterion, except it did not reference medications and laboratory orders. We did not request any specific public comments on this certification criterion.
Comments. A few commenters questioned the value of this certification criterion as is, while other commenters suggested that an appropriate IG be developed and adopted for this certification criterion.
Response. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion. We will consider comments on the value of the certification criterion without any associated standards or IGs and whether there are any appropriate standards or IGs to adopt as part of future rulemaking.
Drug-Drug, Drug-Allergy Interaction Checks
We proposed a "drug-drug, drug-allergy interaction checks" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited comment on whether drug-drug interaction (DDI) or drug-allergy interaction (DAI) checks-capable EHR technology should be able to track health professionals' responses to the DDI/DAI checks that are performed, and whether such a capability should track if and when the health professional viewed, accepted, declined, ignored, overrode, or otherwise commented on the product of a DDI/DAI check. We also sought comment on who should be permitted to review the data collected by the DDI/DAI check tracking capability, who should be able to adjust its configuration settings, whether the data tracked should be limited in scope or specificity, and whether EHR technology should be able to track when an adverse event occurs for which a DDI/DAI check was missed or ignored. In addition, we sought comment on whether a DDI/DAI tracking capability should only track inaction or responses related to certain drug-drug and drug-allergy reactions, such as only tracking DDI/DAI alerts that if missed or ignored would cause severe reactions in patients. Last, we sought comment on what factors, definitions, standards, and existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe.
Comments. Responses from commenters varied. Some commenters expressed strong support for response tracking for DDI and DAI, and suggested that a certification criterion also include response tracking for other interactions, such as drug/lab, drug/diagnosis, food allergy, drug-gene, therapeutic duplication, and environmental allergy interactions. One commenter suggested that response tracking certification exist for CDS interventions in general.
Of those commenters that opposed the inclusion of response tracking as a certification criterion, several themes surfaced. Some commenters noted that response tracking would be burdensome, require significant time and investment, and could conflict with existing system configuration settings already designed for tracking DDI/DAI provider responses. Other commenters noted that response tracking functionality should not be included in a certification criterion and should be developed in the private sector according to the needs of individual providers and their health IT developers. A few commenters noted that response tracking could add an additional layer of alerting and impact provider workflow. A few others noted that response tracking should apply specifically to active alerts and should not apply to passive alerts.
A few commenters noted that response tracking is not appropriate for an EHR system and that such information is stored and tracked within Risk Management Information Systems (RMIS) for liability purposes and for analysis related to efforts to minimize the risk of future adverse events.
We received a number of specific comments on the scope of response tracking. Commenters who supported response tracking noted the value such tracking provides to quality measurement, the improved usefulness of a DDI/DAI alert criterion that would result from response tracking, and the importance of such tracking being automated. One commenter noted that response tracking should track whether the DAI/DAI alert is "displayed" and not whether it is "viewed," which the commenter suggested would impact the provider workflow by requiring provider action. Others noted that in addition to tracking the response of a provider, the factors that may have impacted a provider response would be important to track--such as relevant patient factors or system construction factors that can influence a provider's reaction to a specific alert. A similar concern was raised by another commenter who stated that provider response only provides part of the information needed, and noted that whether the provider is a seasoned health care professional or less experienced is an example of corollary information that could impact whether an ignored DDI/DAI alert is a concern.
We received a variety of comments on who should be able to review the responses of providers and who should be able to adjust tracking configuration. Some commenters noted that in order for this proposal to be operational and, if not already part of existing security protocols, EHR vendors may need to implement new security classes to control viewing privileges related to alerts. Some commenters noted that adjustment of the tracking configuration should be done by the care team and members of the ordering team, while other commenters noted that the ability to adjust configuration or review the response tracking results should be limited to a select few. Many commenters stated that the decision on who should be able to adjust the tracking configuration should be determined by the provider or the organization. One commenter stated that EHR systems also should allow an administrator to modify the workflow that a provider must take when certain DDI/DAI alerts appear.
As part of the request for comment, we asked whether EHR systems should be able to track when an adverse event occurs for a DDI/DAI alert that is ignored. Many commenters expressed concern regarding adverse event tracking. Some commenters stated that significant development would be required to enable this capability in EHR systems. Other commenters stated that the number of factors that can contribute to an adverse event would inhibit the usefulness of such a criterion. Conversely, we heard from several commenters that adverse event reporting related to DDI/DAI alerts plays an important role. Some commenters noted that providers should be able to make reports directly to manufacturers and the
Regarding what factors, definitions, standards, and existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe, some commenters noted that standard vocabularies should be used for exchanging drug-allergy information and that the DDI/DAI terminology should be standardized. Other commenters opposed limiting tracking to only DDI/DAI that are considered severe and suggested that the proposed tracking should apply to all DDI/DAI because there is little consensus on what characterizes a severe reaction. Another commenter stated that in lieu of defining the term "severe," the EHR technology developer or DDI/DAI content provider should define the term. Another commenter stated that any life threatening interaction should be considered severe.
A few commenters stated that in the case of medication allergies, an assessment of severity would not be appropriate. Rather, a "criticality assessment" should be used.
We also received several comments on how to improve any future response tracking certification criterion. One commenter stated that we should consider how to leverage patient-generated health data to inform drug interaction and intolerance-related notifications (including over-the-counter medications). Another commenter suggested that compendia information should be updated monthly to ensure the efficacy of DDI/DAI alerts, which the commenter suggested would help ensure that providers are accessing up-to-date information about allergies and warnings, and would ensure that the list of
A few commenters stated that pharmacists can play an important role in DDI/DAI functionality. These commenters stated that pharmacists should be able to review data collected by DDI/DAI response tracking, noting that pharmacists can help improve the DDI/DAI alert workflow by minimizing provider alert fatigue as well as mitigate against future adverse events through review of adverse outcomes. One commenter stated that pharmacy standards development organizations should be involved in the development of standards for any future response tracking certification criterion.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "drug-drug interaction, drug-allergy interaction" certification criterion. We will, however, consider all comments regarding response tracking of DDI/DAI alerts for future rulemaking concerning a "drug-drug interaction, drug-allergy interaction" certification criterion.
Demographics
We proposed a "demographics" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. The criterion included a requirement that EHR technology designed for the inpatient setting be capable of enabling a user to electronically record, change, and access the "date of death." We previously included the capability to access the date of death as part of the 2011 Edition "demographics" certification criterion and inadvertently omitted it from the 2014 Edition. We also proposed to adopt a new preferred language standard because our constrained approach to the use of ISO 639-2 unintentionally excluded multiple languages that are currently in use, such as sign language and Hmong. Additionally, we noted that ISO 639-2 is meant to support written languages, which may not be the language with which patients instinctively respond when asked for their preferred language. To improve this situation, we proposed three options for which we solicited public comments: The full ISO 639-2, ISO 639-3, or Request for Comments (RFC) 5646 to be the preferred language standard for the proposed "demographics" certification criterion. To implement this proposal, we proposed to modify the regulatory text hierarchy in
Comments. We received a few comments on our proposal related to "date of death" stating that there was value in such information, but that commenters were unaware of any EHR technology developers certified to the 2011 Edition who removed this capability. We received comments on the preferred language for the "demographics" certification criterion advocating for: No change in the standard, the full ISO 639-2, ISO 639-3, and RFC 5646. Commenters representing consumer groups and patients advocated for the inclusion of a standard that covered all languages and dialects. A commenter noted that, in
Response. We have not adopted a "demographics" certification criterion. The insightful comments we received on the preferred language standard necessitate further evaluation of whether the preferred language standard should be changed, including assessment of the compatibility and alignment of alternative standards with already adopted standards and additional cost-benefit analysis of any potential change in the adopted preferred language standard. Further, based on comments, there appears to be no need to adopt a revised "demographics" certification criterion that simply includes the "date of death" functionality. In future rulemaking that may address the "demographics" certification criterion, we will reconsider the need for specifically including functionality related to "date of death." We will also consider comments we received on preferred language standards and our subsequent research on the matter.
Vital Signs, Body Mass Index (BMI), and Growth Charts
We proposed a "vital signs, body mass index, and growth charts" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited comment on whether to require EHR technology to record vital signs in standardized vocabularies (e.g., LOINC(R), Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT(R)), and The Unified Code of Units of Measure (UCUM)). We also solicited comments on two approaches if EHR technology were to be required to record vital signs in standardized vocabularies:
Option 1: Require EHR technology to record vital signs in standardized vocabularies natively within the EHR;
Option 2: Require EHR technology to record vital signs in standardized vocabularies only when data was exchanged.
Comments. The majority of commenters supported leaving this certification criterion unchanged and suggested waiting until the next edition to propose any changes. A commenter recommended linking weight information to drug formularies in order to assist licensed clinicians in selecting the appropriate dosage. Commenters also suggested that the calculation for creatinine clearance should appear in the header along with the BMI for the purposes of patient safety and proper dosing of medications. Another commenter recommended standardizing the use of international BMI as risk of health conditions may vary by race or ethnicity.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "vital signs, body mass index, and growth charts" certification criterion. We will, however, consider comments regarding support for medication dosing and use of international BMI references for future rulemaking concerning a "vital signs, body mass index, and growth charts" certification criterion. We clarify that the comment solicitation regarding standardized vocabularies and options for recording vital signs within the EHR was intended to inform a future edition of certification criteria, not the Proposed Voluntary Edition. Therefore, we will also consider the comments received on this topic as we develop proposals for future rulemaking.
Problem List
We proposed a "problem list" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. A few commenters stated that they support the use of SNOMED CT(R) coding for this criterion and not the use of International Classification of Diseases-10 (ICD-10) as an additional coding system because its use would require more mappings and added complexity when using the Consolidated CDA templates. One commenter recommended adopting the most recent releases of SNOMED CT(R) (International
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "problem list" certification criterion. We will, however, consider feedback suggesting that this criterion is unnecessary in of itself for future rulemaking.
In regard to comments on ICD-10, as we stated in the 2014 Edition Final Rule, we believe SNOMED CT(R) is more appropriate than ICD-10 for clinical purposes and provides greater clinical accuracy (77 FR 54210). Therefore, it was adopted for the 2014 Edition "problem list" certification criterion.
We confirm that the 2014 Edition "problem list" certification criterion requires the use of the SNOMED CT(R)
Medication List
We proposed a "medication list" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. A few commenters stated that medications can come from a number of sources, including over-the-counter, samples, and alternative medicines. These commenters recommended that a medication list include the most complete list possible to help minimize patient safety risks.
One commenter stated that the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "medication list" certification criterion. We will consider feedback suggesting that this criterion is unnecessary in of itself for future rulemaking. We will also consider comments regarding the
Medication Allergy List
We proposed a "medication allergy list" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. Many commenters recommended that the medication allergy list should include other types of allergies and intolerances, including food and environmental allergies.
One commenter stated that the
One commenter recommended the development of an "idealized" interoperable allergy value set that would encompass the same terminology code base and support documenting patient allergies and drug sensitivities. This commenter was concerned that currently active patient medication allergy and drug sensitivities are dominated by the use of multiple proprietary code sets. The commenter stated that codified allergy and drug sensitivity information is commonly exchanged as free-text or when converted to interoperable code sets, the original meaning of the documented allergy is lost. The commenter stated that the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "medication allergy list" certification criterion. We will consider feedback suggesting that this criterion is unnecessary in of itself and comments regarding the
Clinical Decision Support (CDS)
We proposed a "clinical decision support" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion in several ways. First, we proposed to incorporate the guidance we provided in FAQ 39 /26/ that EHR technology certified to the CDS criterion must demonstrate the capability to use at least one of the more specific data categories included in the "demographics" certification criterion (
FOOTNOTE 26 http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039. END FOOTNOTE
FOOTNOTE 27 http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034. END FOOTNOTE
We proposed to include and adopt the HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1,
We proposed to adopt two new IGs from the Health eDecisions (HeD) S&I Framework initiative that support shareable CDS. The first IG defines requirements for the contents of "CDS Knowledge Artifacts" /28/ for event condition action rules, order sets, and documentation templates (HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (
FOOTNOTE 28 A CDS Knowledge Artifact is the encoding of structured CDS content as a rule to support clinical decision making in many areas of the health care system, including quality and utilization measures, disease outbreaks, comparative effectiveness analysis, efficacy of drug treatments, and monitoring health trends. END FOOTNOTE
To supplement the HeD proposals, we solicited comment on what we should focus on for testing and certification of CDS Knowledge Artifacts, decision support services, and user experience to-date with implementing the HeD standards.
Comments. Commenters overwhelmingly supported our proposed approach in FAQ 39 to require that EHR technology certified to a CDS criterion must demonstrate the capability to use at least one of the more specific data categories included in the "demographics" certification criterion (
Commenters also overwhelmingly supported the proposed approach in FAQ 34 to not require adherence to the Infobutton standard for medication allergies or vital signs. They also supported our proposal to not require adherence to the Infobutton standard for laboratory test values/results. A few commenters indicated that a more recent version of the Infobutton standard (Release 4 of the HL7 Infobutton URL-based Implementation Guide) does support laboratory test values/results.
We received support to adopt the updated HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1,
We received mixed feedback on the proposals to adopt the HeD standards for the two use cases. Some commenters supported adoption of the HeD standards in the Proposed Voluntary Edition, while others cautioned that the standards are immature and not well-tested. Those in support of adoption contended that providers and patients would benefit from standardized CDS that could help providers make informed decisions about their patients' care. Commenters also stated that adopting a standard would lessen the implementation burden on providers as CDS has normally been customized for each EHR system. A few organizations commented that they have already successfully piloted the HeD standards and are in production with a number of groups. Thus, they stated that the standards were mature and tested enough to require as part of voluntary certification.
A few commenters suggested further development of diagnostic imaging CDS and alignment with clinical recommendations for immunization-based CDS. One commenter recommended that providers be able to view the HIT developer, bibliographic citation, source of funding, and release/revision date of a CDS rule for full transparency. Other commenters noted that the regulation text language of the proposed CDS certification criterion was unclear and that the regulation text could be improved with more specificity.
The majority of commenters who opposed the HeD proposals expressed concern about the HeD standards immaturity and lack of testing. Some also argued that the standards would still be too immature to propose for the next edition of certification criteria. To support their claim, many pointed to the work of the S&I Clinical Quality Framework (CQF) initiative to harmonize and update HeD with standards for CQMs (e.g., the Health Quality Measures Format standard (HQMF)). Commenters were concerned that EHR technology developers would have to significantly upgrade their systems once the harmonized HeD and HQMF standards become available and that the amount of rework was not worth the short-term benefit. Some commenters stated that market demand should drive the standards and technology for shareable CDS rather than regulation. One commenter suggested that the two HeD use cases should be evaluated separately and not lumped together as the user experience to date may be different between the two.
For testing and certification, many commenters recommended a focus on a few simple and/or high impact or high clinical value Knowledge Artifacts and decision support services to simplify the development, testing, and certification processes. For example, one commenter recommended focusing testing for the first use case on event action condition rules as the commenter thought these are the most common type of Knowledge Artifact and most tested. A few commenters recommended that we and CMS consider allowing successful pilot testing of the HeD standards to count toward meeting MU requirements. Last, some commenters noted at least one case where an EHR accesses a CDS service based on the HeD standards outside of the EHR and recommended allowing the CDS service to be external to the EHR.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange.
We agree with commenters that our issued FAQs have addressed earlier concerns and that most EHR developers have already implemented the policy clarifications offered by the FAQs. Therefore, there is no added value in codifying the FAQs at this point in time. There is also no substantial value in adopting a criterion solely with an updated Service-Oriented Architecture IG when, as commenters noted, there is a new URL-based IG that we should also consider for adoption. We will consider the comments regarding the updated Infobutton Service-Oriented Architecture IG and updated Infobutton URL-Based IG for future rulemaking activities and appreciate the detailed responses commenters provided. To clarify, we did not propose to remove the Infobutton URL-Based IG (at
Electronic Notes
We proposed an "electronic notes" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We included in the proposed certification criterion a capability to search for information across separate notes within EHR technology rather than just within one particular note. We stated that this expanded requirement was intended to reduce the time providers spend looking for specific patient information and noted that the requirement to search across notes was not limited to a specific method. In addition to this proposal, we requested comments regarding: Whether the proposed functionality should extend to all patient electronic notes stored in the EHR or just to a specific patient's electronic notes or specific types of patient notes; whether we should wait to include the proposed functionality in a future edition of certification criteria; and whether additional metadata should be required as part of electronic notes (such as the HL7 R2 header). We also asked for health care provider opinions on whether the availability of the proposed functionality (either searching across a specific patient's electronic notes stored in the EHR or all patients' electronic notes stored in an EHR) is so widespread that it would be unnecessary to require it as a condition of certification.
Comments. We received comments, including those from provider organizations, expressing support for expanding the search functionality both across a patient's notes and across all patients' notes in the EHR as a means of improving provider usability. We also received comments recommending that we not expand the search capability. These commenters argued that the functionality is not required for participation in a particular government program (e.g., the EHR Incentive Programs), it could stifle innovation, and market-driven approaches are sufficient to determine if additional search capabilities are essential or not. Some commenters supported including enhanced search functionality in the proposed certification criterion, while others thought we should wait for a future edition. A few comments supported metadata inclusion with the electronic note, while most comments saw no value in mandating the inclusion of metadata.
Response. We have not adopted the proposed certification criterion. Based on comments, we believe further evaluation is necessary as to whether an enhanced search capability should be included in an "electronic notes" certification criterion and for what purpose the certification of any enhanced search capability would serve. We will consider the comments received in developing proposals future rulemaking.
Drug Formulary Checks
We proposed a "drug formulary checks" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited public comment on whether we should leave the criterion as-is (flexible and without reference to a standard) or if it would be appropriate for us to adopt a standard in the Proposed Voluntary Edition certification criterion for which compliance would be required. In the 2014 Edition Final Rule, we stated it was necessary to require the use of a particular standard for certification as our certification criterion was flexible and permitted EHR technology to access and store external drug formularies in support of MU. As described in more detail in the Proposed Rule (79 FR 10892), CMS recently finalized a proposal to recognize NDPDP Formulary and Benefit Standard v3.0 as a backwards compatible version of NCPDP Formulary and Benefit Standard 1.0 for the period of
FOOTNOTE 29 CMS originally proposed retiring version 1.0 on
We also noted the NCPDP Formulary and Benefit Standard v.4.0's /30/ potential limitations as discussed by the HITSC, including that the version does not support expanded use cases such as real-time benefit checks. /31/ Thus, we also solicited comment on whether there are other standards or solutions (e.g., NCPDP Telecommunication Standard) that could be used in conjunction with or in place of the NCPDP Formulary and Benefit Standard to address the potential limitations or expanded use cases identified by the HITSC.
FOOTNOTE 30 V.4.0 has minor changes compared to v.3.0, including removal of values from an unused diagnosis code, typographical changes, and a change to the standard length of the name field. CMS has adopted v.3.0 (77 FR 74787-74789), which includes substantive changes from previous versions. END FOOTNOTE
FOOTNOTE 31 The HITSC has discussed these potential limitations. Please refer to Clinical Operations Workgroup Update to the HITSC on
Comments. We received mixed comments regarding the proposal to adopt a standard (namely the NCPDP Formulary and Benefit Standard v3.0) for the proposed certification criterion. Some commenters supported adopting the NCPDP Formulary and Benefit Standard v3.0 ("v3.0") in this rule, but most of these commenters recommended its adoption for the next edition of certification criteria. Those in support of adopting v3.0 noted the potential to reduce file sizes, which is beneficial when checking thousands of drug formularies on a daily basis. Many recommended that we should also accept test results from the current
Some commenters were concerned about known problems with v3.0, and pointed to the NCPDP Formulary and Benefit Standard v4.0 ("v4.0"), which may fix some of these known problems. Other commenters were concerned about rework if we required v3.0 in the proposed certification criterion followed by requiring v4.0 in the next edition. One commenter stated that v4.0 is too unstable to require for certification at this point. Some commenters also stated that the industry should determine the EHR's drug formulary features and that we should not be prescriptive in naming a particular standard for adherence.
One ONC-ACB noted that, in their experience, the current drug-formulary check criterion is considered an "easy" pass during the certification process. The test procedure requires EHRs to simply show formulary query results, and therefore the commenter recommended that we consider expanding the test procedure to capture more of the real-world setup of the formulary at the patient or practice level. However, the ONC-ACB noted that this capability may be working fine and may not need further changes as they have never received any surveillance complaints regarding formulary features of certified EHR technologies.
Most commenters were in support of the expanded use case for real-time, patient-level formulary benefit checking. However, we received mixed opinions on the appropriateness of leveraging the NCPDP Telecommunication Standard in conjunction with the NCPDP Formulary and Benefit Standard v3.0 for this expanded use case. One commenter stated that some of the issues found with the NCPDP Formulary and Benefit Standard are due to payer implementations rather than issues with the standard itself. The commenter recommended that we review an NCPDP-authored white paper describing how payers and vendors should implement the Formulary and Benefit Standard for maximum benefit. /32/
FOOTNOTE 32 http://www.ncpdp.org/Education/Whitepaper "Challenges and Opportunities for Stakeholders Regarding ePrescribing Technologies and Formulary Compliance". END FOOTNOTE
Some commenters stated that it was inappropriate to use the NCPDP Telecommunication Standard for real-time, patient-level benefit checking as it was not developed with that use case in mind. Rather, it was developed to respond with coverage information for a pre-selected medication, not a complete range of treatment options. Additionally, commenters opined that use of the NCPDP Telecommunication Standard could result in delays, workflow issues during provider ordering, and additional EHR performance issues because the standard can take several minutes to return a response. In addition to the NCPDP Telecommunication Standard, commenters suggested that we consider the pros and cons of additional standards that could be leveraged for real-time benefit checking. These standards include the ASC X12/005010X279 Health Care Eligibility Benefit Inquiry and Response (270/271) standard and the Proposed Real Time Benefit Check (RTBC) transaction based on a previous version of NCPDP SCRIPT standard (also referred to by some commenters as the Surescripts Real-Time Benefit Check standard). Commenters also referred to different versions of the NCPDP Telecommunications Standard (e.g., B1 (Billing), D1 (Pre-termination of Benefits), D.0).
One commenter recommended that as we evaluate alternative standards for real-time benefit checking, we should also consider protections to ensure that direct communication between pharmacy benefit managers and providers does not lead to unwanted advertising or pop-up messaging intended to influence the prescription decision of a health care professional at the point of care. A few commenters also recommended that we consider proposals for automated electronic prior authorization of medications to allow a prescriber to initiate prior authorization electronically as part of future rulemaking.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider comments regarding the pros and cons and maturity of the NCPDP Formulary and Benefit Standard v3.0 and v4.0 for future rulemaking. We will also examine whether we can learn from and/or leverage the processes of existing certification programs as well as improve the test procedure for this certification criterion as part of future rulemaking.
We thank commenters for their detailed responses about specific standards for the expanded use case of real-time, patient-level formulary and benefit checking, and will continue to examine the pros and cons of each to inform our future rulemaking. We will consider these comments and comments encouraging adoption of standards for electronic prior authorization for future rulemaking. Additionally, as part of our continued work, we will seek to understand the differences among the versions of the NCPDP Telecommunication Standard and between the RTBC transaction with the Surescripts Real-Time Benefit Check standard. As to the comment suggesting that we prohibit unwanted advertising or pop-up messaging in communications between providers and pharmacy benefit managers, we believe this request falls outside the scope of the ONC HIT Certification Program.
Smoking Status
We proposed a "smoking status" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. We received comments expressing support for this certification criterion as unchanged. A few commenters noted that there is misalignment with the code sets adopted for the 2014 Edition and proposed "smoking status" certification criteria and the Consolidated CDA Release 2.0 and e-clinical quality measures (eCQMs). A few commenters also suggested that we consider requiring the capture of additional forms of tobacco use, such as smokeless tobacco and betel nut use.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "smoking status" certification criterion. We note that we have also not adopted the proposed Consolidated CDA Release 2.0 as discussed under the ToC certification criterion in this section (IV.A). We will, however, take the comments about expansion of the smoking code set and alignment with the Consolidated CDA Release 2.0 and eCQMs under consideration for future rulemaking concerning a "smoking status" certification criterion and the Consolidated CDA standard.
Image Results
We proposed an "image results" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. We received a small number of comments on this proposed unchanged criterion. A majority of the comments received on this proposal simply indicated their support for keeping this certification criterion as-is. However, some commenters offered additional suggestions, including one that suggested we remove this certification criterion in the next edition. This commenter did not believe the functionality expressed in the certification criterion would be relevant until a quality or incentive program existed that defined clear objectives for its use as well as the requirement of consistent vocabulary and interoperability support through common standards. Another commenter recommended that images be of diagnostic quality. Other commenters suggested that we incorporate the adoption of the Digital Imaging and Communication in Medicine (DICOM) standards in future editions. One commenter suggested that future editions should go beyond the "accessibility" of images to focus on the transmission of images. Commenters also stated that the interoperability of imaging among different EHR systems must be supported through standards.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "image results" certification criterion. The 2014 Edition certification criterion was expressly adopted to support the correlated MU objective and associated measure, which focuses on the accessibility of electronic imaging results through CEHRT. We point readers to the 2014 Edition Final Rule (77 FR 54173) in which we concluded "that the adoption of the
Family Health History
We proposed a "family health history" (FHH) certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to adopt the HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1 and to include only the HL7 Pedigree standard and the new IG in this certification criterion, and no longer permit demonstrating the use of only SNOMED CT(R) to code family health history as a means of meeting this certification criterion.
Comments. Some commenters expressed general agreement with the proposal, noting that the proposed approach should improve interoperability by moving to one standard and patient care through use of a more comprehensive standard. Many commenters were against moving solely to the HL7 Pedigree standard. Commenters argued that there was a high burden in shifting to HL7 Pedigree, particularly after just adopting SNOMED CT(R) for FHH. Commenters also expressed concern about Consolidated CDA compatibility and, as they described it, HL7 Pedigree's nominal benefit in terms of genomics. Commenters also recommended identifying an appropriate use case for moving solely to HL7 Pedigree, noting that HL7 Pedigree relies on SNOMED CT(R) for coding problems and problems is the predominate use case for coding FHH among most providers.
Response. We have not adopted the proposed FHH certification criterion. The comments received suggest further evaluation is needed as to whether moving to solely the HL7 Pedigree standard for FHH serves an appropriate use case for certification and whether the benefits exceed any potential costs and burden for developers and providers.
Patient List Creation
We proposed a "patient list creation" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include text in the proposed "patient list creation" certification criterion clarifying that EHR technology must demonstrate its capability to use at least one of the more specific data categories included in the proposed "demographics" certification criterion (e.g., sex or date of birth), which incorporated the guidance provided in FAQ 39. /33/
FOOTNOTE 33 http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039. END FOOTNOTE
Comments. We received only a few comments on this proposal. Commenters expressed support for this proposal. Commenters also stated that the certification criterion was essentially the "same" as the 2014 Edition by incorporating FAQ 39 because the FAQ applies for certification to the 2014 Edition certification criterion. One commenter suggested that instead of requiring the use of "at least one" demographic data element in the creation of patient lists that we require "at least two" demographic data elements.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would simply incorporate guidance that EHR technology developers are already following for certification to the 2014 Edition "patient list creation" certification criterion.
The required use of a minimum of two demographic elements was not proposed. Therefore, we have insufficient stakeholder feedback on the potential requirement's benefit versus its burden. We will, however, consider this suggestion in relation to future rulemaking activity concerning a "patient list creation" certification criterion.
Patient-Specific Education Resources
We proposed a "patient-specific education resources" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to adopt this certification without the requirement that EHR technology be capable of electronically identifying patient-specific education resources based on "laboratory values/results" due to stakeholder feedback indicating that the Infobutton standard does not support this level of data specificity. We proposed to adopt the HL7 Implementation Guide: Service-Oriented Architecture (SOA) Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1,
We proposed to revise the regulation text to be more consistent with the intent and interpretation of the 2014 Edition certification criterion regulation text that we expressed in the 2014 Edition Final Rule. /34/ We noted that the text of the proposed certification criterion made clear that the EHR technology must demonstrate the capability to electronically identify patient-specific education resources using Infobutton and an alternative method that does not rely on Infobutton. We also noted that the guidance we provided in FAQ 40 /35/ would still be applicable to the proposed "patient-specific education resources" certification criterion.
FOOTNOTE 34 77 FR 54216. END FOOTNOTE
FOOTNOTE 35 http://www.healthit.gov/policy-researchers-implementers/40-question-04-13-040. END FOOTNOTE
We requested comment on whether we should adopt a different approach related to the methods EHR technology uses to electronically identify patient-specific education resources for the proposed certification criterion, a potential future "patient-specific education resources" certification criterion, or both. The 2014 Edition and proposed certification criterion require EHR technology to demonstrate the capability to electronically identify for a user patient-specific education resources using Infobutton and an alternative method. We sought comment on whether we should: (1) Maintain this approach; (2) require EHR technology to demonstrate only the use of Infobutton, but permit EHR technology to be certified to other methods upon an EHR technology developer's request for the purpose of an EP, EH, or CAH being able to use the alternative certified method for MU (to count such use toward meeting the measure); or (3) certify only the use of Infobutton and consult with CMS regarding a meaningful use policy change that would permit the use of any method (certified or not) to electronically identify patient-specific education resources, provided that the EP, EH, or CAH has EHR technology certified to perform the Infobutton capability.
We also sought comment on whether we should require that EHR technology be capable of providing patient-specific education resources in a patient's preferred language in the proposed certification criterion, in a potential future certification criterion, or in both.
Comments. We received comments supporting removal of the laboratory values/results data element, adoption of the updated SOA IG, and the proposed clarifying regulation text. We received comments supporting both options (1) and (3) related to the methods EHR technology must demonstrate for providing patient-specific education resources. Most commenters preferred option (3). No commenters expressed support for option (2). Consumer and patient advocacy groups supported providing patient-specific education resources in a patient's preferred language, while EHR technology developers did not support this proposal due to the burden they stated it would create because of the great number of potential languages and the lack of content resources for all potential languages. These commenters also noted that burden would far exceed the benefits (e.g., the number of patients requesting patient-specific education resources in a preferred language).
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider the comments on the specific proposed changes to the certification criterion as well as the comments on the methods EHR technology must demonstrate for providing patient-specific education resources and the use of preferred language in providing those resources for future rulemaking concerning a "patient-specific education resources" certification criterion.
Electronic Medication Administration Record
We proposed an "electronic medication administration record" (eMAR) certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because the market drove availability and adoption of this functionality before it was introduced in the 2014 Edition. This commenter also opined that the functionality could be better improved as part of or in the context of the CDS criterion. Another commenter stated that CDS at the point of medication administration would serve as an additional quality check. A commenter stated that a bar code administration process is needed to fulfill this requirement. A commenter also suggested that a distinction be made for data models that include pro re nata (PRN) medications that are prescribed "as needed" and may not actually be given on a regular basis. The commenter stated that these medications may be included in the denominator even though they may never be included in the numerator, and thus the commenter opined that PRN medications should be treated differently than other medications.
enter stated that the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider, in regards to future rulemaking, feedback that this criterion is unnecessary in of itself, comments regarding the
Advance Directives
We proposed an "advance directives" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters expressed support for the proposed unchanged certification criterion. Some commenters suggested, however, that this certification criterion be further enhanced by requiring HIT certified to this certification criterion to be able to record the electronic location of an advance directive, provide a link or instructions to the location of an advance directive, provide the content of an advance directive, and include other care planning documents such as a Physicians Order for Life-Sustaining Treatment (POLST).
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "advance directives" certification criterion. We will, however, consider whether this certification criterion should be enhanced in any of the ways mentioned by commenters as part of future rulemaking activity concerning an "advance directive" certification criterion.
Implantable Device List
July 2, 2013 HHS Health Information Technology Patient Safety Action and Surveillance Plan. /37/ We also provided a short summary of the
FOOTNOTE 36 A UDI is a unique numeric or alphanumeric code that consists of two parts: (1) A device identifier (DI), a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device, and (2) a production identifier (PI), a conditional, variable portion of a UDI that identifies one or more of the following when included on the label of a device: The lot or batch number within which a device was manufactured; the serial number of a specific device; the expiration date of a specific device; the date a specific device was manufactured; the distinct identification code required by 21 CFR 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/. END FOOTNOTE
FOOTNOTE 37 http://www.healthit.gov/sites/default/files/safety_plan_master.pdf END FOOTNOTE
In our proposal, we explained our belief that EHR technology will play a key role in the widespread adoption and utilization of UDIs and that EHRs' use of UDIs can help reduce device-related medical errors and provide other significant patient safety, health care quality, and public health benefits. For example, EHR technology could be leveraged in conjunction with automated identification and data capture (AIDC) technology or other technologies to streamline the capture and exchange of UDIs and associated device data in clinical and administrative workflows. We also noted that patients' UDI data in EHR technology could pave the way for new CDS and help health care providers more rapidly and accurately identify a patient's devices and key information about the safe and effective use of such devices.
As part of our proposal, we recognized that additional standards and technical specifications would be required to support the full range of contemplated capabilities and uses, and that efforts to identify or develop these standards are already underway. Nevertheless, we stated our belief that specifying some baseline functionality as part of a certification criterion would be important in order for EHR technology developers to consider the functionality necessary to capture, store, and retrieve UDIs and other contextually relevant information associated with a patient's medical devices, specifically implantable devices.
Our proposal focused on a certification criterion that would assess an EHR technology's ability to record UDI information about implantable devices. More specifically, we proposed that EHR technology would have to show that it could enable a user to electronically record the UDI of an implantable device and other relevant information (such as a procedure note or additional information about the device) as part of a patient's "implantable device list." We also proposed that EHR technology would need to allow a user to electronically access and view a patient's list of UDIs and other relevant information associated with a patient's implantable devices. Our last proposal focused on an EHR technology's ability to parse the UDI in order to extract and allow a user to view the "device identifier" and "production identifier" portions of the UDI.
Combined with this specific certification criterion's proposal, we also proposed that the UDI would need to be included as part of a Consolidated CDA in each of the following proposed criteria:
*
*
*
*
Finally, we proposed to modify
Comments. Many commenters supported the overall intent behind the proposed certification criterion. These commenters recognized its potential benefits to patient safety and supported the adoption of a certification criterion focused on implantable device list functionality. Some commenters (including those that conceptually supported the proposed criterion) contended that the proposed certification criterion was complex, included new workflow considerations and, from a timing perspective, that it would be premature to adopt a certification criterion including the proposed functionality in this final rule. Instead, they suggested that we wait for the next rulemaking (the rulemaking we expressed our intention to issue with CMS to accompany policy updates to the EHR Incentive Programs) as that would provide EHR technology developers more time to design their systems as well as time for the
Other commenters, mostly EHR technology developers, suggested that the proposed criterion would not be applicable or relevant to the ambulatory setting (due to where implantable device UDI data would be most routinely captured in the inpatient setting) and requested that we scope this criterion to be specific to the inpatient setting. A few commenters suggested that this certification criterion might be ill-suited for both the ambulatory and inpatient settings because the capture of implantable device identifiers would take place in surgical HIT systems. Additionally, some commenters suggested limiting the scope of the certification criterion to focus just on storing only the UDI number as structured data and include the criterion in a future edition of certification criteria without any of the added functional requirements proposed in the Proposed Rule. Another commenter suggested expanding the scope of the certification criterion to include all devices as opposed to the implantable device scope we had included in our proposal, as greater alignment should exist between EHR technology and other technologies used to support supply chain management.
Commenters stated that we had not clearly identified specific use cases that the proposed certification criterion was meant to support. They requested greater clarity in order to better understand how the UDI data was to be used. In that regard, some commenters expressed concern that including the UDI data as part of information exchange transactions (specifically in the Consolidated CDA only) would be premature and suggested that we work with other standards development organizations (such as HL7, NCPDP, and X12) to clarify when and to whom the UDI would need to be communicated. Along different lines, one commenter suggested that we modify the proposal to "electronically record the UDI" to focus on the EHR technology recording the UDI in its complete and parsed state and similarly presented to users in an understandable manner. Another commenter suggested that EHR technology have the capability to generate patient lists by a particular device.
Several commenters requested that we require as part of the certification criterion the use of AIDC technology, while another commenter acknowledged that the system behavior for EHR technology could be similar to that described in the 2014 Edition eMAR certification criterion. These commenters reasoned that an EHR user should not have to manually enter the UDI as it would be inefficient and that the UDI's length could increase the risk of harm due to inaccurate data entry. At least one commenter indicated that financial constraints surrounding AIDC technology could hamper investments in such technology and cause its use to be delayed.
Response. We have not adopted this certification criterion. We believe additional work is necessary to further refine our proposal based on public comments. We very much appreciate the detailed comments submitted, including those that pointed to areas where we need to provide additional detail and clarity. We believe that our next rulemaking can provide such detail and clarity, and intend to propose a UDI-focused certification criterion that reflects the input provided.
Transitions of Care
We proposed to make several changes to the ToC certification criterion, including adopting an updated version of the Consolidated CDA, certain data quality constraints on the creation of Consolidated CDAs to improve patient matching, a proposed "performance standard" that would have required EHR technology to successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time, and the inclusion of UDI information.
Updated Consolidated CDA Standard
We proposed to incorporate an updated version of the Consolidated CDA Standard, HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (U.S. Realm), Draft Standard for Trial Use, Release 2.0 ("Release 2.0"), which was balloted in the summer of 2013. We proposed to include Release 2.0 in four certification criteria: ToC, VDT, clinical summary, and data portability.
Comments. We received many comments on this proposal. The majority of commenters, especially those from EHR technology developers, developer associations, and certification bodies, did not support this proposal. Commenters voiced concerns that Release 2.0 was so new that many stakeholders had not had the chance to review it and it had not been sufficiently piloted. In addition, commenters pointed out a technical problem with the update, known as "bilateral asynchronous cutover" wherein Release 2.0 is not backwards compatible with previous versions of the Consolidated CDA and therefore a provider with a 2014 Edition certified product could not receive a document conformant to the Release 2.0 standard. These commenters supported considering Release 2.0 for future editions of our certification rules. Consumer advocacy groups supported the proposal, noting that the additional functionality included in Release 2.0 such as new structural elements for care plans, patient goals, and health outcomes were important to longitudinal health and care planning and therefore should be included.
Response. We have not adopted Release 2.0 for any certification criteria in this final rule. We appreciate the detailed feedback we received from the developer community and agree that more work remains to address some of the challenges expressed by stakeholders. We remain interested in moving to Release 2.0 and acknowledge that pilot testing is occurring. We will continue to monitor the pilot testing and any other developments concerning Release 2.0 and will consider them in determining whether to include Release 2.0 in a future rulemaking.
ToC Interoperability and MU Stage 2 "Cross-Vendor" Exchange
We proposed to create a new "cross-vendor" exchange requirement. We proposed to require EHR technology certified to the ToC certification criterion to demonstrate that it can successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time.
Comments. We received many comments on this proposal. Overall, commenters did not support our proposal. Commenters voiced concerns about the testability of this requirement. Commenters also questioned the likelihood that the proper set of testing documents could be collected, which would prevent efficient testing and development. Commenters questioned how we determined the 95% threshold and requested we provide evidence supporting that limit. Commenters stated that the 95% threshold would be impractical, time consuming, and expensive to implement, given the wide variation in Consolidated CDA implementation. Commenters also noted that the proposal was vague and confusing, and sought additional information about various portions of the proposal, including what it means to "electronically process." Commenters supported constraining the Consolidated CDA as a better way to achieve our stated goals.
Response. Given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we have not finalized this proposal. We agree that a more constrained Consolidated CDA is an equally implementable approach to reducing the implementation ambiguity and flexibility afforded in the current Consolidated CDA. We encourage industry stakeholders to take such steps. We will re-consider this proposal and the comments received for future rulemaking.
"Create" and Patient Matching Data Quality
We proposed to include a limited set of standardized data (79 FR 10900) as a part of the "create" portion of the Proposed Voluntary Edition ToC criterion to improve the quality of the data included in outbound summary care records. We also sought comment on additional data to include and other constraints that could be applied to this data to improve its quality.
Comments. Overall, the vast majority of commenters supported the policy that standardized patient identifying attributes should be required and captured by certified EHR technology for use in relevant exchange transactions. Commenters overwhelmingly supported the inclusion of the proposed constrained specifications for last name/family name, suffix, first/given name, middle/second name, date of birth, current address and historical address, phone number, and sex in support of patient matching.
We received an especially large amount of feedback regarding the address proposal. Commenters suggested that we delay support for international standards for address until future editions of certification criteria. Commenters also provided feedback that the
Commenters noted that some of the proposed data elements would come from practice management systems that EHRs do not control, including maiden name, historical address and phone number (including multiple phone numbers), and recommended these fields be made optional. Some commenters stated that the proposed standardization was premature, raising usability and privacy concerns and urging us to do further analysis.
Response. Given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we have not adopted this proposal. We will consider comments regarding patient matching functionality for future rulemaking.
Unique Device Identifier Information
We proposed to include UDIs for a patient's implantable device within a created Consolidated CDA formatted document.
Comments. As noted in the UDI section, commenters stated that it was premature to include implantable device information in Consolidated CDA formatted documents and raised questions about the Consolidated CDA's ability to support such information.
Response. We have not finalized our proposal to include the UDI information in a Consolidated CDA formatted document given our decision not to adopt a UDI certification criterion at this time. We appreciate the comments from stakeholders and will consider them for future rulemakings.
Electronic Prescribing (e-prescribing)
We proposed an "e-prescribing" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested merging this criterion with the CPOE--medications certification criterion. Multiple commenters recommended that we adopt the NCPDP "SCRIPT Implementation Recommendations" guidance document that provides clarity on how to populate e-prescribing transactions. /38/ One commenter endorsed the inclusion of RxNorm drug identifiers to provide quality controls for drug identification and promote interoperable exchange of medication information. This commenter recommended use of RxNorm in place of a representative National Drug Code (NDC). One commenter suggested that we consider requiring transmission of in-language prescription labels to prevent inappropriate misuse of prescriptions.
FOOTNOTE 38 The most recent version of this document is Version 1.26 May 2014. END FOOTNOTE
A commenter noted that the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider comments including those on vocabularies, the NCDPD SCRIPT implementation guidance, prescription labeling, and the
Incorporate Laboratory Tests and Values/Results
We proposed an "incorporate laboratory tests and values/results" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. Specifically, we proposed to include in the criterion the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (U.S. Realm) (S&I Framework LRI) with Errata. /39/ We also proposed more specific requirements for how EHR technology must be capable of electronically displaying the information included in a test report. As stated in the Proposed Rule, this specificity would improve the consistency with how laboratory tests and values/results are displayed, which would also assist laboratories with
FOOTNOTE 39 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279. END FOOTNOTE
Comments. Commenters were generally supportive of adoption of interoperable laboratory standards, particularly the LRI IG with errata, and with aligning requirements with
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We believe, however, that there is great promise and value in the LRI IG in terms of improving the interoperability of laboratory test results/values, the electronic exchange of laboratory test results/values, and compliance with
Transmission of Electronic Laboratory Tests and Values/Results to Ambulatory Providers
We proposed a "transmission of electronic laboratory tests and values/results to ambulatory providers" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. Specifically, we proposed to include in the criterion the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (U.S. Realm) (S&I Framework LRI) with Errata. /40/ We also proposed to include new functionality that would improve the consistency with how laboratory tests and values/results are sent, received, and displayed. As stated in the Proposed Rule, this would assist laboratories with
FOOTNOTE 40 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279. END FOOTNOTE
To make the CFR easier to follow for readers, we proposed to adopt the updated S&I Framework LRI at
Comments. The comments we received on this proposed certification criterion were substantially similar to the comments we received on the "incorporate laboratory tests and values/results" certification criterion discussed above. We refer readers to those comments.
Response. We have not adopted this certification criterion. Our rationale for not adopting this certification criterion is the same as that provided for the "incorporate laboratory tests and values/results" certification criterion discussed above. We refer readers to that response.
Data Portability
We proposed a "data portability" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in the certification criterion the Consolidated CDA Release 2.0 and UDIs for a patient's implantable device within a created Consolidated CDA formatted document.
Comments. The comments we received regarding the Consolidated CDA Release 2.0 in response to this criterion were similar to those received on the other four criteria that we proposed to incorporate it within. The majority of commenters thought it was premature to adopt Release 2.0 and that Release 2.0 would create backwards compatibility issues with previous versions of the Consolidated CDA, thus preventing the receipt of the new version. Commenters recommended we do not include it in the data portability certification criterion at this time. Commenters also stated that it was premature to include patient implantable device information (i.e., UDIs) in Consolidated CDA formatted documents.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under the ToC certification criterion in this section (IV.A) of the preamble, we have not adopted the Consolidated CDA Release 2.0. As discussed under the "implantable device list" certification criterion in this section (IV.A) of the preamble, we have not adopted that proposed certification criterion. We will, however, in relation to future rulemaking activity, consider the comments received concerning a "data portability" certification criterion, the Consolidated CDA Release 2.0, and a patient's implantable device list and associated UDIs.
Clinical Quality Measures--Capture and Export
We proposed a "clinical quality measures--capture and export" certification criterion as part of the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit public comment on the potential usefulness of broadening the export requirement to include a QRDA Category II formatted data file.
Comments. We received a few comments that the immunization CQMs do not match well with the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "clinical quality measures--capture and export" certification criterion. Our request for comment on the potential usefulness of broadening the export requirement to also include a QRDA Category II formatted data file was to inform our decision-making for future rulemaking. We will take comments received on this topic into consideration with the comments received regarding clinical recommendations, standards maturity, and the current eCQM process for future rulemaking concerning CQMs.
Clinical Quality Measures--Import and Calculate
We proposed a "clinical quality measures--import and calculate" certification criterion as part of the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. One commenter stated that this criterion requires a level of patient matching that does not currently exist. This commenter encouraged the creation of a national patient identification number.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "clinical quality measures--import and calculate" certification criterion. We thank commenters and understand the importance of matching clinical quality data with the right patient. We note that we solicited comments on patient matching in the Proposed Rule and discuss this topic in more detail under the "ToC" certification criterion in this section (IV.A) of the preamble. However, we note that we have not adopted patient matching requirements in this final rule given our rulemaking approach and will consider comments on the topic for future rulemaking.
Clinical Quality Measures--Electronic Submission
We proposed a "clinical quality measures--electronic submission" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. A few commenters noted the discrepancies between the QRDA Category I and III standards referenced in the 2014 Edition and the subsequently issued CMS QRDA Category I and III IGs dictating the "form and manner" of eCQM submission to CMS, as required for participation in the Physician Quality Reporting System and Inpatient Prospective Payment System programs. Commenters noted that the CMS QRDA IGs issued in 2013 had some conflicts with the base QRDA Category I and III standards named in the 2014 Edition. Commenters also stated that the CMS QRDA IG publication dates (
Two commenters recommended that we not adopt standards that are in draft standard for trial use (DSTU) form and wait until they become normalized standards. These commenters noted that the QRDA Category I and III standards adopted in the 2014 Edition are still DSTUs. One commenter added that no regulatory action has been taken to incorporate the errata to the QRDA Category I and III standards since their release in 2013. Another commenter stated that the QRDA Category I and III standards are not widely used to transmit data.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "clinical quality measures--electronic submission" certification criterion. We will consider comments received on this criterion regarding QRDA standards maturity and program-specific QRDA IGs for future rulemaking concerning CQMs.
Clinical Quality Measures--Patient Population Filtering
We proposed a new "clinical quality measures--patient population filtering" certification criterion for the Proposed Voluntary Edition that would require filtering of CQMs by patient population characteristics. Certain CMS reporting programs such as the Comprehensive Primary Care initiative and
* Practice site and address;
* Tax Identification Number (TIN), National Provider Identifier (NPI), and TIN/NPI combination;
* Diagnosis (e.g., by SNOMED CT code);
* Primary and secondary health insurance, including identification of
* Demographics including age, sex, preferred language, education level, and socioeconomic status (SES).
To inform our proposal, we solicited comment on whether current CQM standards (e.g., QRDA Category I and Category III) can collect metadata for the characteristics listed above, and filter and create a CQM report for a particular characteristic or combination of characteristics. We also solicited comment on vocabulary standards that could be used to record the characteristics proposed above.
Comments. We received mixed comments on the proposal to adopt a new certification criterion to support filtering of CQMs by patient characteristics. Those commenters in support of the proposal stated that the added functionality included in the certification criterion would help address health disparities and social determinants of health. Some commenters believed that collecting the data in a structured way would allow data to be filtered. One commenter pointed to the
FOOTNOTE 41 http://www.qualityforum.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=75398. END FOOTNOTE
A few commenters pointed out that race and ethnicity were not included in the proposed list of characteristics and strongly urged us to consider including race and ethnicity. Commenters also suggested the inclusion of practice type, practice specialty, sexual orientation and gender identity, and disability status in the list of characteristics required for filtering. Some commenters suggested that we perform a full inventory of the possible data elements that CQMs could be filtered by before proposing a list.
We also received comments expressing concern about the level of work required to build the proposed functionality into EHRs. Commenters pointed out that some of the proposed data elements are typically found within administrative systems (e.g., practice address and insurance data) while other data is found within clinical systems such as the EHR. Commenters opined that while some systems can easily merge administrative and clinical data, not all systems currently have this capability and thus the ability to support this proposed criterion varies. Many commenters noted that proposed characteristics, such as age, sex, diagnosis, NPI, and TIN, are being collected in standardized ways within EHRs, but that there are not standard vocabularies or definitions for other data elements such as education and SES. One commenter recommended using a standard for collecting education based on the standard used by the
Regarding standards for quality measurement, some commenters remarked that the QRDA standards can currently capture the data elements needed to filter CQMs by certain patient population characteristics, although not all data elements in standardized form as noted above. Commenters stated that the HQMF standard can currently support filtering by patient characteristics but not by other provider or location variables such as address, TIN, and NPI. Additionally, a commenter stated that HQMF does not have the ability to indicate the level at which a measure needs to be evaluated and summarized. The commenter contended that this could affect whether patients are identified in the initial patient population for group reporting or not, and would impact whether the patient is filtered or not.
Response. Given the feedback we received, we believe additional work is needed to further refine our proposal. Therefore, we have not adopted this certification criterion. We clarify that we envision two types of uses for this functionality: 1) Filtering of CQM results to support the identification of health disparities, to help providers identify gaps in quality, and to support a provider in delivering more effective care to sub-groups of their patient populations, and 2) to support administrative and group/ACO reporting of CQMs where the unit of measurement is not the individual provider. We are considering whether this functionality could be a standalone certification criterion or an additional functionality included in a new version of the "clinical quality measures--import and calculate" certification criterion at
We agree with commenters that there are standardized vocabularies to collect some of the data elements we proposed, but not all. We recognize that more work is needed to identify standards for other data elements we proposed. We also recognize that the list we proposed is not a complete set, and that there are additional data elements the stakeholders may wish to filter by. We appreciate the comments regarding standards for quality reporting (e.g., QRDA and HQMF), and will use this feedback to inform our future rulemaking. We will also take into consideration comments on the level of filtering and summarization of CQMs for group and ACO reporting.
Authentication, Access Control, and Authorization
We proposed an "authentication, access control, and authorization" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit comments on the issue of two-factor authentication to support two use cases: E-prescribing of controlled substances; and remote provider access. In 2010, the
(1) Should we adopt a general two-factor authentication requirement for certification?
(2) Were the HITPC's recommendations appropriate and actionable?
Comments. All commenters supported the certification criterion as unchanged. Commenters did not support a broad two-factor authentication requirement for certification. The majority of the commenters did, however, support the inclusion of two-factor authentication functionality for the specific purpose of e-prescribing controlled substances. Some commenters noted that the DEA's requirements were more complex than basic two-factor authentication and urged us to consult with the DEA before creating a criterion to support this use case. Commenters were divided in their support for requiring two-factor authentication for remote access for providers. Commenters agreed that the HITPC's recommendations regarding remote access for providers were actionable. However, comments varied with regard to whether the recommendation was appropriate for remote access. Specifically, commenters were concerned that differences in EHR systems (i.e., cloud-based versus practice-installed) created ambiguity as to when the requirement would apply and sought clarity in the term "remote access." In addition, commenters voiced concern about the potential criterion becoming too prescriptive, with many commenters urging us to propose a criterion that required EHRs to support these use cases without describing how they did so. Commenters further noted concern about the ability to test two-factor authentication.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "authentication, access control, and authorization" certification criterion. We will consider comments regarding the use of two-factor authentication to support e-prescribing of controlled substances and remote access for providers in future rulemaking concerning an "authentication, access control, and authorization" certification criterion.
Auditable Events and Tamper-Resistance
We proposed an "auditable events and tamper-resistance" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed this certification criterion in response to a report by the
FOOTNOTE 42 https://oig.hhs.gov/oei/reports/oei01-11-00570.pdf. END FOOTNOTE
Comments. The majority of commenters, including EHR technology developers, EHR developer associations, and the HITSC, did not support preventing all users from being able to disable the audit log. Commenters stressed that there were valid and important reasons for users to disable the audit log, including allowing a system administrator to disable the audit log for performance fixes, stability, disaster recovery, and system updates or allowing a system administrator to disable it when there is rapid server space loss which is hindering a provider from accessing needed clinical information in a timely manner. Commenters stated that the majority of EHR developers do not currently allow audit logs to be disabled. Commenters also stated that preventing the disabling of the audit log was a best practice, but should not be included in the certification criterion because of cases of emergency or disaster that would necessitate disabling of the audit log. Other commenters, including providers, provider associations, consumer advocates, and EHR technology developers, supported the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. Additionally, in response to the significant and detailed feedback we received recommending that we do not finalize our proposal, we will further evaluate whether it is appropriate to implement the
Audit Report(s)
We proposed an "audit report(s)" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion as part of the Proposed Voluntary Edition.
Comments. Commenters supported the proposed certification criterion as unchanged.
Response. We thank commenters for their support of this proposed unchanged certification criterion. We have not, however, adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "audit report(s)" certification criterion.
Amendments
We proposed an "amendments" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion as unchanged. Some commenters noted the importance of this certification criterion and recommended records tag patient-generated amendments to denote the appropriate provenance.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "amendments" certification criterion. We will, however, consider the comments about data provenance of amendments for future rulemaking activity concerning an "amendments" certification criterion.
Automatic Log-Off
We proposed an "automatic log-off" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion as unchanged.
Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "automatic log-off" certification criterion.
Emergency Access
We proposed an "emergency access" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion as unchanged. One commenter expressed concerns that untrained users could make a mistake in a complex EHR system related to access.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "emergency access" certification criterion. In response to the comment on "untrained" users, we note that the 2014 Edition certification criterion (and the proposed "emergency access" criterion) requires EHR technology to be able to designate a "set of users." A provider would determine appropriate users and access to their system in conjunction with the EHR technology developer, which is not part of the certification process under the ONC HIT Certification Program.
End-User Device Encryption
We proposed an "end-user device encryption" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion as unchanged.
Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "end-user device encryption" certification criterion.
Integrity
We proposed an "integrity" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion as unchanged.
Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "integrity" certification criterion.
Accounting of Disclosures
We proposed an "accounting of disclosures" certification criterion for the Proposed Voluntary Edition that was unchanged substantively as compared to the 2014 Edition certification criterion. We did, however, propose to remove the "optional" designation from this certification criterion for the Proposed Voluntary Edition because such a designation would no longer be necessary with the proposed discontinuation of the Complete EHR concept.
Comments. All of the comments received supported leaving the certification criterion unchanged. Commenters overwhelmingly recommended that we do not remove the optional designation regardless of other proposed changes. Commenters suggested removing the optional designation would create confusion in the marketplace and require significant additional development work.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We note that commenters apparently misunderstand the purpose of designating certification criteria as optional. As we explained in the Proposed Rule (79 FR 10918), the designation of "optional" for certification criteria was developed to accommodate the Complete EHR definition (i.e., cases where EHR technology would otherwise have to be certified to a criterion solely because it is required in order to satisfy the Complete EHR definition and certification). Complete EHR certification is still permitted to the 2014 Edition. Therefore, as proposed, it would make no sense to adopt this certification criterion as part of the 2014 Edition as it is substantively the same as the current 2014 Edition "accounting of disclosures" certification criterion and, without the optional designation, it would directly contradict the current 2014 Edition "accounting of disclosures" certification criterion and EHR technology would be required to certify to it for a Complete EHR certification.
View, Download, and Transmit to 3rd Party
The summary of the proposals in the Proposed Rule recited in this section only summarize and include the "comments" and "response" for the proposals that we have not adopted in this final rule. For the VDT proposal made in the Proposed Rule and adopted in this final rule, including a summary of what was proposed for that proposal, please see section III.A.2 of this preamble.
We proposed to revise the VDT criterion in a number of ways, including: Clarifying introductory text in order to clearly specify that this criterion expressed patient facing capabilities for patient use; decoupling the content and transport requirements and in tandem proposing a revision that would more clearly express EHR technology's ability to support a patient's ability to choose the destination or to whom they wanted to send their health information; updating the Consolidated CDA version with the corresponding inclusion of UDI information; increasing the Web Content Accessibility Guidelines (WCAG) level to level AA; and revising the activity history log requirement to record two additional data elements (the addressee to whom an ambulatory summary or inpatient summary was transmitted and whether that transmission was successful).
Comments. Commenters generally supported clarifying the introductory text of VDT. Commenters stressed the importance of allowing authorized representatives the ability to perform the VDT functionality. Some EHR technology developers opposed revisions related to the clarification around a patient's ability to "download" a human readable file, a Consolidated CDA file, or both. A commenter representative of the majority of EHR technology developers indicated that the revised criterion is overly prescriptive and not in sync with actual software development. The commenter stated that EHR technology developers enable users to download the XML version and the style sheet together, since the style sheet is applied to the XML to provide the human-readable information. The commenter concluded that most patients would find making a choice confusing and did not believe that patients would benefit from this proposal.
With respect to our proposal for EHR technology to enable a patient to choose the destination or whom they wanted to send their health information via Direct, many commenters opposed or raised concerns about this proposal. Most of these commenters were EHR technology developers who identified a number of technical concerns with the proposal. They stated that:
* EHR technology cannot guarantee that any message sent to a Direct address specified for transmission will reach the endpoint. Each HISP has rules beyond the EHR's control specifying their exchange with other HISPs.
* The ability of a patient to enter a third party destination of their choice (i.e., initiate a direct exchange using a valid direct exchange address) would imply that the EHR technology has the ability to determine if the address entered is valid. When a patient enters an address, the EHR technology would not know if it is valid and with the separation of content from transport, the EHR technology would no longer control the Domain Name System/Lightweight Directory Access Protocol (DNS/LDAP) look up to ensure that the certificate is valid and included within the sender's HISP trust circle.
* Patients have not, and will not any time soon, be given Direct addresses because it is too great an expense.
We received many comments on our proposal to update the Consolidated CDA version to Release 2.0. The majority of commenters, especially those from EHR technology developers, HIT developer associations, and certification bodies, did not support this proposal. Commenters voiced concerns that Release 2.0 was so new that many stakeholders had not had the chance to review it and it had not been sufficiently piloted. In addition, commenters pointed out a technical problem with the update, known as "bilateral asynchronous cutover" wherein Release 2.0 is not backwards compatible with previous versions of the Consolidated CDA and therefore a provider with a 2014 Edition certified product could not receive a document conformant to the updated Consolidated CDA standard. These commenters supported considering Release 2.0 for future editions of our certification criteria. Consumer advocacy groups supported the proposal, noting that the additional functionality included in Release 2.0, such as new structural elements for care plans, patient goals, and health outcomes, were important to consumers and care planning.
We received mixed comments on our proposal to move to WCAG Level AA, including many from EHR technology developers. Some opposed the increased level citing the cost and burden to reach Level AA. Conversely, other EHR technology developers supported the move and offered no concerns. In both cases, EHR technology developers noted that WCAG conformance tools are somewhat sparse and that they have had difficulty finding viable tools. Of the few comments on whether a hybrid of Level A and Level AA would be preferred, the comments opposed this type of approach because it would lead to variability and inconsistency.
Most commenters supported the inclusion of the intended recipient in the activity history log. Commenters voiced concern about requiring a history log to record whether the transmission was successful, noting that EHRs do not have information on what happens to a message once it leaves the EHR and is processed by the HISP. Commenters stated that prior to being able to make this information patient accessible, standards development would be necessary to support this use case. Some commenters agreed that activity history logs should record and include both new data points and stated that this transaction history provides important information about care coordination that patients should be able to access.
Response. We appreciate the detailed feedback we received on many of the VDT proposals. While we are not revising the 2014 Edition VDT to include the proposed clarifying regulation text, we note for commenters that the requirement to provide patients with the ability to download a human readable version, a Consolidated CDA version, or both, already exists within the 2014 Edition VDT certification criterion. As discussed in the Proposed Rule, the clarification was not a modification of existing policy. Rather, it was an attempt at more clearly articulating existing policy to avoid any confusion. As EHR technology developers indicated, we have long-standing policy that permits them to satisfy this approach through the use of a style sheet, which would be an acceptable approach because it would give a patient both human readable and Consolidated CDA versions.
We have also decided to leave the 2014 Edition certification criterion unmodified with respect to our proposal to enable a patient to choose the destination or whom they wanted to send their health information via Direct. We will consider the technical challenges raised by EHR technology developers. In the case of the Consolidated CDA update, we have already discussed our decision not to adopt this proposal in the discussion on the ToC criterion (Section IV.A) and do not adopt it for the VDT certification criterion for the same reasons. In response to comments, we will continue to evaluate the WCAG level and suitable testing approaches. Last, we will continue to evaluate comments on our proposal to expand the activity history log and its connection to some of the technical challenges identified by comments.
Overall, given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we have not adopted any of the proposals discussed in this section.
Clinical Summary
We proposed a "clinical summary" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to reflect the clarifications we provided in FAQ 33 /43/ (i.e., require the use of LOINC(R) for diagnostic tests pending and future scheduled tests to the degree such test could be coded in LOINC(R)), to require the use of CVX codes for immunizations, and reference the Consolidated CDA Release 2.0 (including UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document) in the proposed certification criterion. We requested comment on whether LOINC(R) can be used to represent all possible diagnostic tests pending and future scheduled tests.
FOOTNOTE 43 http://www.healthit.gov/policy-researchers-implementers/33-question-12-12-033. END FOOTNOTE
We also reiterated the situational dependency (office visit-dependent) of certain data that the EHR technology must be able to provide, and limit, in the clinical summary to meet the proposed certification criterion as well as the 2014 Edition "clinical summary" certification criterion. We stated that although the regulation text for medications, diagnostic tests pending, and future scheduled tests may seem redundant with the Common MU Data Set, this data along with immunizations is specified separately because EHR technology must have the capability to limit this data in a clinical summary it creates to only those medications and immunizations administered during the visit and/or the diagnostic tests pending and future scheduled tests after the visit. We clarified that in terms of customization of the clinical summary, this permits the user to limit this data in the clinical summary if so desired. We further clarified that while providing historical data for medications, immunizations, and diagnostic tests in the clinical summary may be of benefit in certain instances, EHR technology is not required to have these capabilities to meet the certification criterion. Last, we noted that this certification criterion, like the 2014 Edition "clinical summary" certification criterion, was designed to support the associated MU objective and measure that seeks to provide a patient with a record of the office visit and specific lab tests or specific follow-up actions and treatment related to the office visit.
Comments. We received many comments supporting the required use of CVX and LOINC(R). A few commenters opposed the use of LOINC(R) codes, while others suggested the use be required "where applicable" because LOINC(R) cannot currently cover all possible tests. We received comments for and against the use of the Consolidated CDA Release 2.0 and the inclusion of UDI(s). Commenters also expressed varying opinions on the data that should be included in a clinical summary. Some commenters suggested that EHR technology allow for complete customization of the data. Others commenters recommended not including historical information or code sets in the clinical summary (which they claimed were confusing to patients).
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We also note that we have not adopted the proposed Consolidated CDA Release 2.0 as discussed under the ToC certification criterion and the "implantable device list" certification criterion in this section of the preamble (IV.A). We expect EHR technology developers to follow FAQ 33 for certification to the 2014 Edition "clinical summary" certification criterion and we continue to encourage, but not require, the use of CVX codes for immunizations. The data element requirements for certification to the 2014 Edition "clinical summary" certification criterion remain the same as does the "situational dependency" guidance we provided in the Proposed Rule and have recited above. We will, however, take into consideration the comments we received about the data that should be in a clinical summary and how it should be expressed for future rulemaking activity concerning a "clinical summary" certification criterion.
Secure Messaging
We proposed a "secure messaging" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported adopting this certification criterion as unchanged. However, a few commenters recommended that we take steps to allow a patient's authorized representative to send and receive secure messages on the patient's behalf as part of the Proposed Voluntary Edition. In addition, one commenter suggested that this criterion should utilize the same "decoupling" of content and transport requirements as was proposed for the ToC certification criterion.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "secure messaging" certification criterion. We also note that the comment about decoupling is unclear. This certification criterion does not establish message content requirements so we are not certain about what the commenter thinks should be decoupled. Further, any method of transport that meets the security requirements of the proposed criterion would have been permitted, as it is currently permitted with the 2014 Edition "secure messaging" certification criterion.
Public Health Certification Criteria
We received comments related to the public health certification criteria, but not specific to the proposed criteria or our proposals. We summarize and respond to these comments below.
Comments. We received a comment in favor of bidirectional exchange between EHRs and clinical registries. The commenter encouraged us to consider certification requirements to promote bidirectional data exchange and data standardization between EHRs and clinical data registries, such as certification of clinical data registries. The commenter stated that this would assist physicians and health care systems as well as align with payment programs that utilize clinical data registries (e.g., PQRS). The commenter also suggested that we consider utilizing existing national standards being used for EHRs.
Response. We appreciate the feedback and will consider the suggestions on standards and to require certification of clinical data registries for future rulemaking.
Immunization Information
We proposed an "immunization information" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested that we not adopt this criterion, or similar criteria in future editions, because the "transmission to immunization registries" criteria sufficiently addressed the interoperability aspects of the immunization information.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "immunization information" certification criterion. We appreciate the feedback suggesting that this criterion is unnecessary as the "transmission to immunization registries" certification criterion addresses the functionality required by this criterion. We will consider this feedback for future rulemaking concerning an "immunization information" certification criterion.
Transmission to Immunization Registries
We proposed a "transmission to immunization registries" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion the updated IG for immunization messaging: HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, Release 1.5. The updated IG focuses on known issues from the previous release and revises certain HL7 message elements to reduce differences between states and jurisdictions for recording specific data elements.
Comments. The majority of commenters supported adoption of the updated IG for immunization messaging. These commenters stated that the updated IG provides additional clarification and guidance for better interoperability between EHRs and immunization registries. Commenters in opposition to adopting the updated IG were concerned about needing to support two versions of an IG at the same time. Some commenters were also concerned about backwards compatibility with the version currently required in the 2014 Edition. Commenters who were generally opposed to the proposed voluntary and more incremental rulemaking approach also contended that the updated IG did not offer much value for the work that would be required to update systems.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We appreciate the feedback commenters provided regarding the updated IG and will consider the comments received for future rulemaking concerning a "transmission to immunization registries" certification criterion.
Transmission of Reportable Laboratory Tests and Values/Results
We proposed a "transmission of reportable laboratory tests and values/results" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion the updated IG for reporting laboratory tests and values/results to public health agencies (HL7 Version 2.5.1: HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release 2 (US Realm), 2013). The updated IG addresses technical corrections and clarifications for interoperability with laboratory orders and other laboratory domain IGs. To properly codify this proposal in regulation, we proposed to modify the regulatory text hierarchy in
Comments. We received mixed feedback on the proposal to adopt the updated IG for reporting laboratory tests and values/results to public health agencies. Some commenters were in favor of adopting the updated IG. Other commenters stated that many state public health agencies and EHR technology developers are still working to implement the version we adopted in the 2014 Edition, and thus contended it is too early to require compliance with an updated IG.
A few commenters supported SNOMED-encoded observations values, where applicable, because of the potential value add to reportable laboratory results for public health. Two commenters stated that we incorrectly referenced the author of the updated IG in the preamble of the Proposed Rule. These commenters recommended that we correct the author reference from CDC to the
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange.
We agree with the correction of the author of the updated IG and believe that the CDC worked in conjunction with the HL7 Public Health Emergency Response Workgroup to develop the updated IG. For future rulemaking, we will consider the comments received regarding the maturity and version/naming of the updated IG. Regarding the comments recommending that we adopt the updated LOINC(R) and SNOMED CT(R) standards, we will reassess whether newer versions of the minimum standards should be adopted in future rulemaking. As we stated in the 2014 Edition Final Rule, based on our experience, newer versions of the "minimum standards" code sets that we have adopted are issued more frequently than our current process can reasonably accommodate. We do not believe that permitting EHR technology to be upgraded and certified to newer versions of these code sets would normally pose an interoperability risk, and therefore we allow use of a newer version voluntarily for certification without adversely affecting the EHR technology's certified status unless the Secretary specifically prohibits the use of a newer version (77 FR 54268). Thus, EHRs may be certified to newer versions of LOINC(R) and SNOMED CT(R).
Cancer Case Information
We proposed a "cancer case information" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because they recommend a focus on privacy and security, interoperability, and quality reporting, and thus contended that this criterion is not necessary. Another commenter recommended that we consider privacy issues so that patients are not inappropriately penalized by insurance companies or employers for having cancer or a preexisting condition.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "cancer case information" certification criterion. We will consider the feedback regarding the necessity of this criterion and privacy concerns for future rulemaking concerning a "cancer case information" certification criterion.
Transmission to Cancer Registries
We proposed a "transmission to cancer registries" certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion an updated IG (Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.1,
FOOTNOTE 44 Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in
Comments. We received mixed feedback on the proposal to adopt the updated cancer transmission IG. Some commenters supported adopting the updated IG and also commented that they look forward to more generalizable CDA-based case reporting in the future. Other commenters were concerned about the differences in state requirements that lead to custom interface development before achieving bidirectional exchange. Some suggested we wait until the next edition to propose adopting the updated IG because there has not been sufficient time for implementation experience.
Some commenters stated that, in their experience, the adoption of the cancer transmission IG required in the 2014 Edition is low, and therefore they did not foresee that many would adopt an updated version. One commenter noted that there is a proposed HL7 project to more closely align the CDA-based cancer reporting IG with the Consolidated CDA standard. We also received comments stating that we should consult with existing registries for guidance on the appropriate standards to adopt. One commenter recommended that the updated IG should include data elements for transmission of grade and pathological TNM Stage, /45/ as it is difficult to report to state cancer agencies if cancer synoptics are not in a structured data format and can be prone to manual data entry errors.
FOOTNOTE 45 The TNM Classification of Malignant Tumours (TNM) is a cancer staging system that describes the extent of a person's cancer. END FOOTNOTE
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We agree that we should evaluate the maturity of the updated IG, its required data elements, efforts to move to the Consolidated CDA standard, and standards used by current registries to inform our future rulemaking concerning a "transmission to cancer registries" certification criterion.
Automated Numerator Recording
We proposed to adopt an unchanged "automated numerator recording" certification criterion as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters expressed support for the proposed unchanged certification criterion. Commenters also expressed concern over the burden involved in meeting MU measurement requirements (e.g., time consuming and affects efforts to improving clinical functionality and usability). One commenter suggested that this criterion either be removed or be made more granular and defined sufficiently. In terms of more granularity, the commenter suggested that each numerator recording requirement for a capability (e.g., CPOE or VDT) should be specified in the "automated numerator recording" certification criterion.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "automated numerator recording" certification criterion. We will, however, consider whether additional specificity is appropriate for the "automated numerator recording" certification criterion and further evaluate the costs and benefits of this certification requirement for future rulemaking activity concerning an "automated numerator recording" certification criterion.
Automated Measure Calculation
We proposed to adopt an unchanged "automated numerator recording" certification criterion as compared to the 2014 Edition certification criterion. We proposed to apply guidance for certification to the 2014 Edition "automated measure calculation" certification criterion included in the 2014 Edition Final Rule to the proposed certification criterion (79 FR 10911). We also proposed that the interpretation of the 2014 Edition "automated measure calculation" certification criterion in FAQ 32 /46/ would apply to the proposed certification criterion. We did not request any specific public comments on this certification criterion.
FOOTNOTE 46 http://healthit.gov/policy-researchers-implementers/32-question-11-12-032. END FOOTNOTE
Comments. Commenters expressed support for the proposed certification criterion as unchanged. A couple of commenters stated this certification criterion helped providers and lessened their MU reporting burden. EHR technology developers stated that this criterion represents one of the largest areas of development investment of all of the MU certification requirements. The commenters noted that it is common to invest more effort in measuring a particular MU requirement than developing the associated capability. One commenter suggested that this criterion be made more granular. The commenter suggested that each measure requirement for a capability (e.g., CPOE or VDT) should be specified in the "automated measure calculation" certification criterion. Another commenter recommended making available different testing methods for this certification criterion, including scenario-based testing options.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "automated measure calculation" certification criterion. We will, however, consider whether additional specificity is appropriate for "automated measure calculation" certification criteria, further evaluate the development effort associated with this certification criterion, and consider any potential alternative testing methods now and in relation to future rulemaking activity concerning an "automated measure calculation" certification criterion.
Safety-Enhanced Design
We proposed a "safety-enhanced design" (SED) certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit public comment regarding whether we should modify the certification criterion. Specifically, we requested comment regarding whether:
* The scope of SED should be expanded to include additional certification criteria;
* Formative usability tests should be explicitly required, or used as substitutes for summative testing;
* There are explicit usability tests that should be required in addition to summative testing; and
* There should be a minimum number of test subjects explicitly required for usability testing.
Comments. We received many comments in response to our request for comments. Commenters suggested expanding the certification criteria covered in this criterion to criteria covering laboratory exchange, problems, and other areas. Conversely, other commenters recommended not expanding the certification criteria covered by the SED criterion. Commenters were both for and against using actual formative usability tests with some suggesting testing to certain usability standards. Some commenters also suggested that there be a minimum number of test subjects, with a few commenters emphasizing that the test subjects and process should be objective.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "safety-enhanced design" certification criterion. We will, however, consider all the thoughtful comments we received regarding expanding the scope and testing of the SED certification criterion in relation to future rulemaking activity concerning a SED certification criterion.
We note that we have revised the 2014 Edition SED certification criterion (
Quality Management System
We proposed a "quality management system" certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion.
Comments. Commenters expressed support for the proposed certification criterion as unchanged. One commenter suggested that we remove this certification criterion for the proposed edition and any future editions until the Food and Drug Administration Safety and Innovation Act (FDASIA) health care IT regulatory framework has been established and implemented.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition "quality management system" certification criterion. As with all stakeholder feedback, we appreciate the comments submitted, including the recommendation to remove this certification criterion from future editions. We will consider the FDASIA Health IT Report, /47/ including a published final report, in future rulemaking activity concerning a "quality management system" certification criterion.
FOOTNOTE 47 http://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf. END FOOTNOTE
Non-Percentage-Based Measures Report
We proposed a new "non-percentage-based measures report" certification criterion for the Proposed Voluntary Edition. Specifically, we proposed to adopt a new certification criterion that would apply to EHR technology presented for certification that includes certain "non-percentage-based capabilities" (i.e., capabilities that support MU objectives for which the corresponding MU measure is not percentage-based). In the 2014 Edition NPRM (77 FR 13842), we proposed a certification criterion for "non-percentage-based measure use report," but subsequently did not adopt the criterion in the 2014 Edition Final Rule based on commenters' concerns that additional specificity would be needed to make the proposed criterion more effective. In the Proposed Rule, we stated that we continue to believe that EPs, EHs and CAHs could benefit from EHR technology that could electronically report non-percentage-based MU objectives and measures, and we have also received feedback from
FOOTNOTE 48 The Request for Comments is available at: http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf. END FOOTNOTE
Therefore, we proposed a new criterion that is more specific than the one proposed in the 2014 Edition NPRM and recognizes that certain aspects of "use" associated with non-percentage-based measures will occur in different ways based on the particular EHR capability involved. The proposed certification criterion would require that an EHR technology presented for certification be capable of electronically generating a report that shows a user had used (or interacted with) the EHR technology capability associated with a non-percentage-based MU measure during an EHR reporting period. This means that, at a minimum, the EHR technology would need to be capable of determining an EHR reporting period (date range) and be able to record some evidence of use (e.g., transaction, user action, intervention/reminder) during the reporting period. We requested public comment on whether we should make the regulatory text for this certification criterion more specific or if we should maintain the word "evidence" and use this final rule's preamble to provide more examples of what evidence would be acceptable. If we were to make the regulatory text more specific, we proposed two options, but also solicited comment on other potential language that would make satisfying this criterion clearer.
* Option 1: Require the EHR technology to record evidence of use each time a particular capability was used during the reporting period.
* Option 2: Require the EHR technology to record evidence of use at the beginning, during, and end of the reporting period.
We believe the proposed criterion provides EHR technology developers with substantial flexibility to create innovative approaches to document evidence of use. The proposed criterion would apply to only those non-percentage-based measures for which this pertinent information would be available to the EHR technology based on the nature of the capabilities and the ways in which a user could be expected to interact with them. To illustrate which certification criteria support one or more non-percentage-based measures, we provided a table (79 FR 10912) in the Proposed Rule. As described in the Proposed Rule, we also proposed not to include the proposed "drug-formulary checks" and ToC certification criteria within the scope of this criterion because the corresponding MU measures already provide evidence of use. We also proposed that all the proposed privacy and security certification criteria of the Proposed Voluntary Edition should not be included within the scope of this certification criterion because EHR technology would not be able to capture that a security risk analysis was performed by an EP, EH, or CAH except through a manual entry by the EP, EH, or CAH affirming the completion of the risk analysis.
Consistent with the way in which we have previously implemented certification policy that more generally applies to EHR technology, an ONC-ACB would need to have new certification responsibilities if we were to adopt this proposed criterion. As a result, we also proposed to revise
Comments. We received mixed comments regarding the proposal to adopt a new certification criterion to generate reports for non-percentage-based EHR capabilities. Some commenters supported the new criterion for all of the seven certification criteria we presented in the table (79 FR 10912). /49/ However, some commenters stated that this requirement would only be feasible or preferable for a subset of the proposed certification criteria. One commenter opined that this functionality was feasible for drug-drug, drug-allergy interaction checks and CDS, but for the rest of the certification criteria, it would be difficult to build this functionality on a user-level. Another commenter recommended adopting this functionality only to support CDS. One commenter recommended the requirement be that EHRs be able to perform this function for three out of the six proposed certification criteria to lessen the administrative burden.
FOOTNOTE 49 Drug-drug, drug-allergy interaction checks; clinical decision support; patient list creation; transmission to immunization registries; transmission of syndromic surveillance data to public health agencies; transmission of reportable lab tests and values/results to public health agencies; and transmission to cancer registries. END FOOTNOTE
Commenters that opposed adopting the proposed criterion expressed that the reason for not adopting this criterion in the 2014 Edition still holds (i.e., additional specificity is needed to make the proposed criterion more effective). Many commenters stated that providers can, and currently do, attest to the non-percentage-based MU objectives without the EHR having to monitor or "police" the provider's interactions with the EHR. Commenters were also concerned that building this functionality will be a major development undertaking and will have to be custom-built for each certification criterion. Commenters provided specific examples of the challenges in building this functionality for certain certification criteria. For example:
* For CDS interventions, EHR systems vary in their configurations that determine how often interventions are seen. EHR developers who currently track this information note that the data volumes can be very large, and that retention of large volumes of data over extended periods of time can have performance and hardware implications.
* For the public health certification criteria, it is possible that an EHR user is connected and submitting appropriate information but may not have submissions within a particular reporting period. Multiple transport methods and methodologies can introduce challenges to implementing this functionality in a standard way. What is defined as "ongoing submission" can vary and human judgment is required to make the determination (e.g., data is sent using different procedures like real-time or periodic uploads).
Thus, some commenters were concerned that an auditor could review the "non-percentage-based measures report" and incorrectly conclude that the EP, EH, or CAH failed the CDS objective if none of the implemented CDS rules/interventions were triggered during the reporting period.
Another commenter recommended changing the regulatory text that as proposed would require an EHR to "electronically record evidence that a user used or interacted with the capability . . ." The commenter stated that the use of the word "evidence" implies too strong of a legal ramification and that the EHR can only indicate when different features or options were triggered or activated within the EHR, but not that a user did or did not properly act upon the MU-related feature.
A few commenters were opposed to Option 1, which would require EHR technology to record evidence of use each time a particular capability was used during the reporting period. One commenter stated that there are no standards to support reporting of this type of information. Another commenter suggested that Option 1 would result in large amounts of data that would require additional storage space. One commenter supported Option 2 and agreed with the need to show that certain functionalities were enabled in the system during the reporting period.
Response. There was mixed feedback on which certification criteria this functionality would be required to support. We agree with comments stating that this functionality would vary in support of different certification criteria, and believe that more work is needed to further refine our proposal. Since the overall scope of this final rule focuses on the adoption of a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and includes revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we do not believe it is appropriate to adopt this new certification criterion at this time. Our experience with the certification of EHR technology to the 2014 Edition suggests that EHR technology developers have already implemented or are in the process of implementing their certified software with providers and hospitals, and it is unlikely that EHRs would be updated with this new functionality in time to positively affect reporting for non-percentage-based functions. Thus, we will consider the comments received on feasibility, implementation, the regulatory text, and frequency of recording data on use of particular capabilities for future rulemaking concerning a "non-percentage-based measures report" certification criterion.
Applicability Statement for
We proposed to adopt a new certification criterion for electronic sending and receiving that would enable EHR technology to be tested and certified solely to perform "transmissions" in accordance with the Applicability Statement for
FOOTNOTE 50 http://wiki.directproject.org/file/view/Implementation+Guide+for+Delivery+Notification+in+Direct+v1.0.pdf. END FOOTNOTE
Comments. Some commenters supported the goal of acknowledging receipt of the documents by the intended recipient. Commenters also voiced concern that this was a new area of certification that lacked HIT developer feedback and recommended that we further consider this certification criterion before finalizing it. Other commenters stated that the depth of information required to be reported to the sender of information would cause significant burden on HIT developers to create the functionality and providers and health care organizations to use the functionality. One commenter noted that, as the market matured, demand for this kind of functionality would increase and HIT developers would design these functions without the need of a certification criterion.
Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will, however, consider comments regarding the Delivery Notification IG capabilities, the concerns expressed by commenters, and evaluate whether the market demand for this capability would moot the benefit that certification could provide for proof of a consistent implementation according to the IG as part of future rulemaking.
B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
In the Proposed Rule, we provided an "equivalency table" (79 FR 10915-16) that identified the Proposed Voluntary Edition EHR certification criteria that were equivalent to the 2014 Edition certification criteria for the purposes of meeting the CEHRT definition. There is no longer a need for an "equivalency table" because we have not adopted the Proposed Voluntary Edition in this final rule. Therefore, we have not included an "equivalency table" in this final rule.
C. HIT Definitions
1. CEHRT
We proposed to revise the CEHRT definition for FY/CY 2014 and subsequent years to include reference to the Proposed Voluntary Edition as a means of giving EPs, EHs, and CAHs the flexibility to use EHR technology that has been certified to either the 2014 Edition or the Proposed Voluntary Edition, or a combination of both editions, to meet the CEHRT definition for FY/CY 2014 and subsequent years.
Comments. We received many comments recommending that we do not adopt the Proposed Voluntary Edition.
Response. We have not revised the CEHRT definition. In response to comments recommending that we not adopt the Proposed Voluntary Edition and for the other reasons discussed earlier in this preamble, we have not adopted the full Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As such, no revisions are necessary to the CEHRT definition to account for the additional optional 2014 Edition EHR certification criteria.
2. Common MU Data Set
We proposed to revise the Common MU Data Set definition in
Comments. We received comments recommending that we not adopt a new preferred language standard as well as comments on each of the standards we proposed as the potential new preferred language standard.
Response. We have not adopted a revised or new demographics certification criterion or a new preferred language standard consistent with our reasons for not adopting the Proposed Voluntary Edition and for the reasons discussed in more detail under the "demographics" certification criterion in section IV.A. Accordingly, we have not finalized our proposal to revise the Common MU Data Set definition.
C. ONC HIT Certification Program
1. Non-MU EHR Technology Certification
We proposed to establish an "MU EHR Module" definition and a "non-MU EHR Module" definition under the main "EHR Module" definition at
We stated that these proposals would ensure that EHR technology designed for MU purposes and certified to certification criteria that include capabilities that support percentage-based and/or non-percentage-based MU measures are capable of electronically performing the associated recording and calculation of measure activities for MU purposes, while permitting EHR technology that is designed for non-MU purposes (e.g., broad electronic health information exchange or behavioral health settings staffed mainly by MU ineligibles) to be certified without having to include capabilities that support percentage-based and/or non-percentage-based MU measures. These proposals were based on our belief that EHR technology developers who design EHR technology for non-MU purposes and settings find that the MU measurement certification criteria requirements are unnecessary burdens and resource investments (i.e., to have to program MU-specific rules into their software just to get certified). Similarly, we noted that because of the specific ways in which MU measures are structured non-MU health care providers would find little benefit in receiving EHR utilization reports showing MU performance. In the Proposed Rule, we specifically requested comment on these assumptions and on how best to implement our proposed approach if we were to adopt it in this final rule (e.g., requested comments on what processes we should use for testing and certification and distinguishing MU and non-MU EHR Modules on the CHPL) (79 FR 10919-20).
Overall, as stated in the Proposed Rule, we saw these proposals as a first step towards the expansion of the ONC HIT Certification Program to accommodate other types of HIT (79 FR 10930). To note, as stated in the Proposed Rule, we did not propose to apply the certification concept of MU EHR Module and non-MU EHR Module to the 2014 Edition because of the inconsistency and potential confusion it would create regarding EHR Modules that have already been certified and, more importantly, because it would be infeasible to implement for the purposes of establishing a distinction on the CHPL in a timely manner to avoid such potential confusion.
Comments. We received comments supporting our proposal not to require "non-MU" technologies to be certified to certification criteria designed to support MU measurement. We also received a significant number of comments expressing concern that our proposals would cause confusion. Commenters suggested that designations and concepts such as "MU," "non-MU," and "beyond MU purposes" would add complexity and confusion to an already strained marketplace. A few commenters stated that we need to also account for non-EHR technologies. Another commenter suggested that we not rely on assumptions about the differences in technology needs between providers that are eligible for MU incentive payments and those that are ineligible. As an example, the commenter suggested that the numerator and denominator calculations may, in fact, be useful to providers that are not eligible for MU incentive payments for patient safety tracking and other purposes.
Response. In consideration of comments and our overall goal to expand the ONC HIT Certification Program to accommodate other types of HIT, we have decided not to adopt any of these proposals. Upon further reflection, we believe these proposals may not clearly and appropriately move us away from a certification program currently focused on MU. By using terminology such as "MU" and "non-MU," we only reinforce the MU-aspect of the ONC HIT Certification Program. Further, as noted by commenters, our proposals could confuse providers and may not be based on sound assumptions such as MU-ineligible providers not finding value in some of the capabilities that support MU measurement as noted by a commenter. Accordingly, with consideration of comments that supported our stated goal and recommended that we address non-EHR technologies, we will further consider how best to restructure the ONC HIT Certification Program to move it beyond MU in preparation for our next rulemaking. To reaffirm, as our request for comment indicated in the Proposed Rule (79 FR 10929-30), we intend to propose changes to the ONC HIT Certification Program that will permit the certification of other types of HIT and the certification of HIT for other specific types of health care settings (i.e., beyond the general ambulatory and general inpatient settings). For now, we direct stakeholders to our guidance for EHR technology developers serving providers ineligible for the EHR Incentive Programs titled "Certification Guidance for EHR Technology Developers Serving Health Care Providers Ineligible for
FOOTNOTE 51 http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf. END FOOTNOTE
2. "Certification Packages" for EHR Modules
We proposed to establish the concept of predefined "certification packages" that would reflect groupings of certification criteria. We stated that our proposal was intended to improve the ease with which our regulatory concepts could be communicated to the general public and to EHR Module purchasers. More specifically, we stated that this concept would make it easier for stakeholders to communicate and understand the functionality an EHR Module includes and the certification criteria to which it is certified.
We proposed to define "certification package" in
We also clarified that if an EHR Module were certified to the certification criteria included in a proposed certification package definition, then the EHR Module developer would be able to indicate this fact without the need for any additional determination to be made by the ONC-ACB. However, to ensure that certification packages would be represented accurately to potential purchasers and users of EHR Modules, we proposed to modify
Comments. We received only three comments that supported our proposals. However, the commenters submitting these comments misconstrued our proposals as either a new required type of certification for EHR Modules to the Proposed Voluntary Edition or as an additional requirement beyond initial certification, such as specifically requiring additional functionality for "care coordination." All other commenters did not support our proposals. These commenters disagreed with our rationale that our approach would provide clarity for stakeholders. Rather, commenters stated that our approach would cause more confusion than it would solve. Commenters noted that one individual's definition of "care coordination" may not be the same as another, which could lead to misunderstandings about what is or is not included in the EHR technology. Commenters also noted that there are a large number of possible combinations of certification criteria and associated capabilities that could plausibly be called "care coordination" (e.g., inclusion of lab exchange certification criteria and capabilities) and patient engagement (e.g., inclusion of the "clinical summary" certification criterion). The commenters opined that the certification criteria included in the proposed packages seemed arbitrary and not applicable to all providers. Commenters suggested that we focus on educating providers, particularly those ineligible for the EHR Incentive Programs, as to what types of certified capabilities providers should look for in a certified technology. In this regard, one commenter suggested that we rely on and educate more providers on our guidance titled "Certification Guidance for EHR Technology Developers Serving Health Care Providers Ineligible for
FOOTNOTE 52 http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf. END FOOTNOTE
Response. We have not finalized our proposals for the "care coordination" and "patient engagement" packages.
We clarify that our "certification packages" proposals did not require a new type of certification or additional functionality for EHR Modules. Under the proposals, an EHR Module would not have been required to be certified to the certification criteria specified in a certification package, and an EHR Module could have been certified to more certification criteria than were included in a certification package. Our proposal was designed such that an EHR Module developer could assert (e.g., for communications and marketing purposes) that its EHR Module met a certification package if the EHR Module had been certified to all of the certification criteria included in a certification package without any additional determination made by an ONC-ACB. However, given the comments received from commenters that clearly understood our proposals, we have not adopted "certification package" as a concept and definition in
V. Comments Beyond the Scope of This Final Rule
In response to the Proposed Rule, some commenters chose to raise issues that are beyond the scope of our proposals such as encouraging us to amend our certification criteria to include EHR accessibility for users with disabilities. We do not summarize or respond to those comments in this final rule. However, we will review the comments and consider whether other actions may be necessary, such as addressing the comments in future rulemakings.
VI. Collection of Information Requirements
This final rule contains no new collections of information under the Paperwork Reduction Act nor does it revise any current collection of information approved by OMB.
VII. Regulatory Impact Statement
A. Statement of Need
Consistent with EO 13563, we have completed a retrospective review of our 2014 Edition Final Rule and the certification criteria we adopted in that final rule. Further, consistent with EO 13563, we have only adopted the proposed certification criteria as part of the 2014 Edition that provide regulatory flexibility and reduce regulatory burden for stakeholders.
B. Overall Impact
We have examined the impact of this final rule as required by EO 12866 on Regulatory Planning and Review (
1. Executive Orders 12866 and 13563--Regulatory Planning and Review Analysis
EOs 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects (
a. Costs
This final rule adopts new optional certification criteria and revised certification criteria as part of the 2014 Edition. Our analysis focuses on the direct effects of the provisions of this final rule--the costs incurred by EHR technology developers to develop and prepare EHR technology to be tested and certified in accordance with the certification criteria (and the standards and implementation specifications they include) adopted by the Secretary. That is, we focus on the technological development and preparation costs necessary for EHR technology already certified to the 2014 Edition to certify to the new optional certification criteria and revised certification criteria and for developing new EHR technology to meet the new optional certification criteria and revised certification criteria. The costs for testing and certification of EHR technologies to the certification criteria adopted in this final rule were captured in the RIA of the Permanent Certification Program final rule as we discuss in more detail below (VI.B.1.a.ii "Testing and Certification Costs for the 2014 Edition Release 2"). The costs that EPs, EHs, and CAHs will incur in adopting and implementing EHR technology certified to the certification criteria adopted in this final rule are not within the scope of this final rule.
i. Development and Preparation Costs for the 2014 Edition Release 2
In the Proposed Rule (79 FR 10932-36), we estimated the development and preparation costs for the Proposed Voluntary Edition. We categorized proposed certification criteria based on their gap certification status (i.e., new, revised, and unchanged). We used the total number of unique /53/ 2011 Edition Complete EHRs and EHR Modules that were used for MU Stage 1 attestation as reported at the end of FY 2013. /54/ Using the unique number of 2011 Edition EHR technologies used for MU Stage 1 attestation we established a range of between 20% and 40% of unique EHR technologies used for MU Stage 1 that we believed would be developed and prepared to meet each of the certification criteria of the Proposed Voluntary Edition. This range accounted for potential new entrants to the market as well as those EHR technologies used for MU Stage 1 attestation that may no longer be brought forth for certification because of such factors as corporate re-organizations (e.g., mergers and acquisitions) as well as the loss of market share for some EHR technologies. The range also took into account any potential non-MU-focused EHR technologies that will be developed and prepared to meet the Proposed Voluntary Edition, but not designed for MU purposes. We identified three levels of effort to associate with the development and preparation of EHR technology to meet the requirements of the Proposed Voluntary Edition. /55/ We based the effort levels on the hours necessary for a software developer to develop and prepare the EHR technology for testing and certification and calculated the average software developer's wage with benefits at
FOOTNOTE 53 We attempted to discern how many Complete EHRs and EHR Modules were used that would not constitute a newer version of the same EHR technology. END FOOTNOTE
FOOTNOTE 54 For the Proposed Voluntary Edition certification criteria that did not have equivalent 2011 Edition EHR certification criteria, we used the unique number for the equivalent 2014 Edition EHR certification criteria as identified and used for the 2014 Edition Final Rule regulatory impact analysis. END FOOTNOTE
FOOTNOTE 55 79 FR 10932-33. END FOOTNOTE
FOOTNOTE 56 79 FR 10933. END FOOTNOTE
FOOTNOTE 57 79 FR 10933-36. END FOOTNOTE
Comments. We received very limited comments on our proposed impact analysis, all of which came from EHR technology developers and reiterated the detailed comment that came from the
Response. We appreciate the detailed response provided by the EHR technology developer community. In reviewing the provided comments, it became clear that the way in which we were presenting the calculation of our impacts in the preamble and the way in which EHR technology developers think about the impacts were different. In other words, our approach in the Proposed Rule was to assign burden hours to each certified product listed on the CHPL by certification criterion and we never provided a "per EHR technology developer" estimate. However, in contrast, the EHRA estimates were burden hours by EHR technology developer for each certification criterion.
On face value, for example, if one were to compare the "Level 2 range" we included in the Proposed Rule of 100-300 hours without multiplying by the number of products on the CHPL attributable to a particular EHR technology developer it would appear that we did significantly underestimate the burden. However, if one were to multiply that 100-300 hour range by the number of products attributable to a particular EHR technology developer and that were certified to the certification criterion in question a potentially narrower gap in the estimates could result.
After considering these comments, we believe that a more direct way for this final rule and for future rulemakings to identify burden will be to identify hourly burden estimates for each certification criterion by EHR technology developer. Given the reduced scope of this final rule, we do not include hourly cost estimates for certification criteria that we are not finalizing. Table 4 indicates only the regulatory changes we have finalized for the adopted certification criteria and our hourly burden estimate range for each of the changes by EHR technology developer.
We also include an estimated number of EHR technology developers that we believe will seek certification to these certification criteria (and built into this assumption is that they would be presenting on average 3 products for certification, similar to EHRA's number). To arrive at this estimate, we analyzed available CHPL data from mid-May of this year for 2014 Edition certifications. From this data, we determined how many EHR technology developers had at least one product certified to the adopted 2014 Edition. From the group of EHR technology developers with a product certified to the 2014 Edition, we estimate that no more than 20% of those developers will seek certification because of the reduced and specific scope of this final rule. We also believe that for some certification criteria the 20% estimate could be a substantial overestimation. We provide a more detailed criterion-by-criterion explanation of our estimates below in Table 4.
Additionally, despite the specificity included in the EHRA estimates, we have found from past experience that at times EHR technology developers have misinterpreted what we have proposed. The EHRA's comments noted this kind of discrepancy by stating for certain certification criteria that some of its members interpreted the burden to be reasonably low while others very high. Given that we have no other comments by which to compare the EHRA estimates, we have generally used the EHRA estimate as our "high average" rounded up or down to the nearest hundred hours.
Table 4--Development and Preparation Costs for EHR Technology Developers for Adopted Certification Criteria Item # CFR Text Certification Number of Hourly development criterion name EHR effort by EHR developers developer who develop product(s) Low avg High avg for certi- fication to criterion 1 S. 170.314(a)(18) CPOE-- 33 0 100 medications 2 S. 170.314(a)(19) CPOE-- 33 0 100 laboratory 3 S. 170.314(a)(20) CPOE-- 33 0 100 diagnostic imaging 4 S. 170.314(b)(8) Transitions of 29 400 600 care 5 S. 170.314(b)(9) Clinical 27 0 100 information reconciliation and incorporation 6 S. 170.314(e)(1) View, download, 33 400 600 and transmit to 3rd party 7 S. 170.314(f)(7) Transmission to 25 0 100 public health agencies-- syndromic surveillance 8 S. 170.314(g)(1) Automated N/A N/A N/A numerator recording 9 S. 170.314(g)(3) Safety-enhanced 77 0 100 design 10 S. 170.314(h)(1) Applicability 33 300 500 Statement for Secure Health Transport 11 S. 170.314(h)(2) Applicability 33 200 300 Statement for Secure Health Transport & XDR/XDM for Direct Messaging 12 S. 170.314(h)(3) SOAP Transport 33 200 300 and Security Specification & XDR/XDM for Direct Messaging
* Items #1 through #3: With the exception of splitting out the three CPOE order type functionalities, there are no new requirements as part of any of these three certification criteria in this final rule. As a result, we provided a low range estimate.
* Item #4: For this certification criterion, the only substantial new development change between it and the 2014 Edition certification criteria at
* Item #5: The EHRA did not provide any hourly estimate for new development, nor does this criterion substantively differ from already required capabilities in the 2014 Edition. As a result, we provided a low estimate.
* Item #6: For this certification criterion, the only substantial new development change between it and the original 2014 Edition version is the addition of the IG for Direct Edge Protocols. As a result, our estimates are the same as for Item #4.
* Item #7: Given the adoption of this more general certification criterion, we have provided a low estimate.
* Item # 8: This certification criterion was simply changed to an "optional" designation to provide regulatory clarity for Complete EHR certification to the 2014 Edition. There should be no new cost estimates related to certification as this regulatory change simply implements ONC Regulation FAQ 28 as discussed in section III.B.3 of the preamble.
* Item # 9: This certification criterion now includes the adopted optional CPOE and CIRI certification criteria. We have estimated a low cost range because we anticipate that EHR technology developers will use the same SED practices they used for certification to the CPOE (
* Items #10-12: We provide estimates reasonably close to the EHRA estimates.
Table 5 includes an overall 2-year cost estimate for each criterion. We retain the 2-year cost estimate period (CY 2014 and CY 2015) for the reason provided in the Proposed Rule as they would similarly apply to the adopted optional and revised 2014 Edition certification criteria. Additionally, we retain and use the estimate of
Table 5--Distributed Total Development and Preparation Costs for EHR Technology Developers (Two-Year Period)--Totals Rounded Item # CFR Text Certification criterion Total low Total Total name cost high cost average estimate estimate cost ( $M) ( $M) estimate ( $M) 1 S. CPOE--medications$0 $.2 $.1 170.314(a)(18) 2 S. CPOE--laboratory 0 .2 .1 170.314(a)(19) 3 S. CPOE--diagnostic 0 .2 .1 170.314(a)(20) imaging 4 S. Transitions of care .71 1.0 .89 170.314(b)(8) 5 S. Clinical information 0 .16 .081 170.314(b)(9) reconciliation and incorporation 6 S. View, download, and .81 1.22 1.0 170.314(e)(1) transmit to 3rd party 7 S. Transmission to public 0 .15 .077 170.314(f)(7) health agencies--syndromic surveillance 8 S. Automated numerator N/A N/A N/A 170.314(g)(1) recording 9 S. Safety-enhanced design 0 .47 .235 170.314(g)(3) 10 S. Applicability Statement .6 1.0 .8 170.314(h)(1) forSecure Health Transport 11 S. Applicability Statement .4 .6 .5 170.314(h)(2) forSecure Health</org> Transport & XDR/XDM for Direct Messaging 12 S. SOAP Transport and .4 .6 .5 170.314(h)(3) Security Specification & XDR/XDM for Direct Messaging 2-Year 2.92 5.80 4.38 Total 2014 1.46 2.90 2.19 total (50%) 2015 1.46 2.90 2.19 total (50%)
iii. Testing and Certification Costs for the 2014 Edition Release 2
In the RIA of the Permanent Certification Program final rule, we estimated the costs for testing and certification of EHR technologies that would be used for providers to attempt to achieve MU Stages 1-3. /58/ These costs were based on a two-year rulemaking cycle for the CEHRT definition and each MU stage. We believe the costs we attributed to testing and certification of EHR technologies in support of MU Stage 2 in the Permanent Certification Program final rule would encompass the actual testing and certification of EHR technologies to both the 2014 Edition and the certification criteria we have adopted as part of the 2014 Edition Release 2. This assessment is based on the number of EHR technologies currently certified to the 2014 Edition and our projections for the number of EHR technology developers that would likely have their EHR technologies tested and certified to the optional and revised 2014 Edition certification criteria adopted in this final rule. Further, we note that the estimated costs in the Permanent Certification Program final rule included costs for surveillance of EHR technologies and also estimated the costs for testing and certification above what we understand are the cost ranges charged by ONC-ACBs today.
FOOTNOTE 58 76 FR 1318. END FOOTNOTE
b. Benefits
The regulatory flexibility the 2014 Edition Release 2 certification criteria provide will offer several significant benefits to patients, health care providers, and HIT developers. The 2014 Edition Release 2 incorporates stakeholder feedback on particular 2014 Edition issues identified as unnecessarily impeding innovation and causing undue burden. The 2014 Edition Release 2 also seeks to continue to improve EHR technology's interoperability and electronic health information exchange. Specifically, the separating out of the "content" and "transport" capabilities in the optional 2014 Edition ToC certification criterion (compared to the 2014 Edition ToC certification criteria adopted at SEC 170.314(b)(1) and (2)) and adoption of the Edge Protocol IG is aimed at improving the market availability of electronic health information exchange services. The new certification flexibilities offered by the optional "CPOE" and optional "syndromic surveillance" certification criteria are designed to enhance innovation and offer providers enhanced functionality and options for meeting applicable MU measures. The new flexibility in the VDT certification criterion is designed to further facilitate the exchange of patient health information between provider and patient. The optional CIRI criterion is designed to align better with clinical workflows and reduce regulatory burden found in certification to the current ToC certification criterion at SEC 170.314(b)(1).
2. Regulatory Flexibility Act (RFA)
The RFA requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities.
The Small Business Administration (SBA) establishes the size of small businesses for federal government programs based on average annual receipts or the average employment of a firm. While EHR technology developers that pursue certification under the ONC HIT Certification Program represent a small segment of the overall information technology industry, we believe that the entities impacted by this final rule most likely fall under the North American Industry Classification System (NAICS) code 541511 "Custom Computer Programming Services" specified at 13 CFR 121.201 where the SBA publishes "Small Business Size Standards by NAICS Industry." The SBA size standard associated with this NAICS code is set at
FOOTNOTE 59 The SBA references that annual receipts means "total income" (or in the case of a sole proprietorship, "gross income") plus "cost of goods sold" as these terms are defined and reported on Internal Revenue Service tax return forms. http://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf. END FOOTNOTE
Based on our analysis, we believe that there is enough data generally available to establish that between 75% and 90% of entities that are categorized under the NAICS code 541511 are under the SBA size standard, but note that the available data does not show how many of these entities will develop a EHR product that will be certified to the optional 2014 Edition Release 2 certification criteria under the ONC HIT Certification Program. We also note that with the exception of aggregate business information available through the
We estimate that this final rule would have effects on EHR technology developers that are likely to pursue certification under the ONC HIT Certification Program, some of which may be small entities. However, we believe that we have proposed the minimum amount of requirements necessary to accomplish our policy goals, including a reduction in regulatory burden and additional flexibility for the regulated community, and that no additional appropriate regulatory alternatives could be developed to lessen the compliance burden associated with this final rule. We note that this final rule does not impose the costs cited in the RIA as compliance costs, but rather as investments which these EHR technology developers voluntarily take on and expect to recover with an appropriate rate of return. Accordingly, we do not find that this final rule will create a significant impact on a substantial number of small entities. Additionally, the Secretary certifies that this final rule will not have a significant impact on a substantial number of small entities.
3. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. Nothing in this final rule imposes substantial direct compliance costs on state and local governments, preempts state law or otherwise has federalism implications. We are not aware of any state laws or regulations that are contradicted or impeded by any of the certification criteria or other proposals we have adopted in this final rule.
4. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any one year of
Regulation Text
List of Subjects in 45 CFR Part 170
Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Health care, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and recordkeeping requirements, Public health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, part 170, is amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 552.
2. Section 170.102 is amended by revising the definition for "Base EHR" to read as follows:
SEC 170.102 Definitions.
* * * * *
Base EHR means an electronic record of health-related information on an individual that:
(1) Includes patient demographic and clinical health information, such as medical history and problem lists;
(2) Has the capacity:
(i) To provide clinical decision support;
(ii) To support physician order entry;
(iii) To capture and query information relevant to health care quality;
(iv) To exchange electronic health information with, and integrate such information from other sources;
(v) To protect the confidentiality, integrity, and availability of health information stored and exchanged; and
(3) Has been certified to the certification criteria adopted by the Secretary:
(i) For at least one of the four criteria adopted at SEC 170.314(a)(1), (a)(18), (a)(19), or (a)(20);
(ii) At SEC 170.314(a)(3);
(iii) At SEC 170.314(a)(5) through SEC 170.314(a)(8);
(iv) Both SEC 170.314(b)(1) and (2); or, both SEC 170.314(b)(8) and SEC 170.314(h)(1); or SEC 170.314(b)(1) and (2) combined with either SEC 170.314(b)(8) or SEC 170.314(h)(1), or both SEC 170.314(b)(8) and SEC 170.314(h)(1);
(v) At SEC 170.314(b)(7);
(vi) At SEC 170.314(c)(1) through SEC 170.314(c)(3);
(vii) At SEC 170.314(d)(1) through SEC 170.314(d)(8);
(4) Has been certified to the certification criteria at SEC 170.314(c)(1) and (2):
(i) For no fewer than 9 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible professionals, including at least 6 clinical quality measures from the recommended core set identified by CMS; or
(ii) For no fewer than 16 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible hospitals and critical access hospitals.
* * * * *
SEC 170.102 [Amended]
3. Section 170.102 is further amended, effective
4. Section 170.202 is amended by adding paragraph (d) to read as follows:
SEC 170.202 Transport standards.
* * * * *
(d) Standard. ONC Implementation Guide for Direct Edge Protocols (incorporated by reference in SEC 170.299).
SEC 170.205 [Amended]
5. Section 170.205 is amended, effective
SEC 170.207 [Amended]
6. Section 170.207 is amended, effective
SEC 170.210 [Amended]
7. Section 170.210 is amended, effective
8. Section 170.299 is amended by adding paragraph (k)(4) to read as follows:
SEC 170.299 Incorporation by reference.
* * * * *
(k) * * *
(4) ONC Implementation Guide for Direct Edge Protocols, Version 1.1,
* * * * *
SEC 170.302 [Removed and Reserved]
9. Section 170.302 is removed and reserved, effective
SEC 170.304 [Removed and Reserved]
10. Section 170.304 is removed and reserved, effective
SEC 170.306 [Removed and Reserved]
11. Section 170.306 is removed and reserved, effective
12. Section 170.314 is amended by:
a. Revising paragraph (a)(1)(iii);
b. Adding paragraphs (a)(18) through (20) and (b)(8) and (9);
c. Revising paragraphs (e)(1)(i)(C)( 1) and (2);
d. Adding paragraph (f)(7);
e. Revising paragraphs (g)(1) and (3); and
f. Adding paragraph (h).
The revisions and additions read as follows:
SEC 170.314 2014 Edition electronic health record certification criteria.
* * * * *
(a) * * *
(1) * * *
(iii) Diagnostic imaging.
* * * * *
(18) Optional--computerized provider order entry--medications. Enable a user to electronically record, change, and access medication orders.
(19) Optional--computerized provider order entry--laboratory. Enable a user to electronically record, change, and access laboratory orders.
(20) Optional--computerized provider order entry--diagnostic imaging. Enable a user to electronically record, change, and access diagnostic imaging orders.
(b) * * *
(8) Optional--Transitions of care. (i) Send and receive via edge protocol. EHR technology must be able to electronically:
(A) Send transitions of care/referral summaries through a method that conforms to the standard specified at SEC 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in SEC 170.202(a); and
(B) Receive transitions of care/referral summaries through a method that conforms to the standard specified at SEC 170.202(d) from a service that has implemented the standard specified in SEC 170.202(a).
(ii)(A) Display. EHR technology must be able to electronically display in human readable format the data included in transition of care/referral summaries received and formatted according to any of the following standards (and applicable implementation specifications) specified in: SEC 170.205(a)(1) through (3).
(B) Section views. Extract and allow for individual display each additional section or sections (and the accompanying document header information) that were included in a transition of care/referral summary received and formatted in accordance with the standard adopted at SEC 170.205(a)(3).
(iii) Create. Enable a user to electronically create a transition of care/referral summary formatted according to the standard adopted at SEC 170.205(a)(3) that includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s):
(A) Encounter diagnoses. The standard specified in SEC 170.207(i) or, at a minimum, the version of the standard specified SEC 170.207(a)(3);
(B) Immunizations. The standard specified in SEC 170.207(e)(2);
(C) Cognitive status;
(D) Functional status;
(E) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; and
(F) Inpatient setting only. Discharge instructions.
(9) Optional--clinical information reconciliation and incorporation --(i) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at SEC 170.205(a)(3), EHR technology must be able to demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient.
(ii) Reconciliation. Enable a user to electronically reconcile the data that represent a patient's active medication, problem, and medication allergy list as follows. For each list type:
(A) Electronically and simultaneously display (i.e., in a single view) the data from at least two list sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date;
(B) Enable a user to create a single reconciled list of medications, medication allergies, or problems;
(C) Enable a user to review and validate the accuracy of a final set of data; and
(D) Upon a user's confirmation, automatically update the list, and electronically incorporate the following data expressed according to the specified standard(s):
( 1) Medications. At a minimum, the version of the standard specified in SEC 170.207(d)(2);
( 2) Problems. At a minimum, the version of the standard specified in SEC 170.207(a)(3);
( 3) Medication allergies. At a minimum, the version of the standard specified in SEC 170.207(d)(2).
* * * * *
(e) * * *
(1) * * *
(i) * * *
(C) * * *
( 1) Electronically transmit the ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) created in paragraph (e)(1)(i)(B)( 1) of this section in accordance with at least one of the following:
( i) The standard specified in SEC 170.202(a).
( ii) Through a method that conforms to the standard specified at SEC 170.202(d) and that leads to such summary being processed by a service that has implemented the standard specified in SEC 170.202(a).
( 2) Inpatient setting only. Electronically transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with at least one of the following:
Ii) The standard specified in SEC 170.202(a).
( ii) Through a method that conforms to the standard specified at SEC 170.202(d) and that leads to such summary being processed by a service that has implemented the standard specified in SEC 170.202(a).
* * * * *
(f) * * *
(7) Optional--Ambulatory setting only--Transmission to public health agencies--syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission.
(i) Optional. That contains the following data:
(A) Patient demographics;
(B) Provider specialty;
(C) Provider address;
(D) Problem list;
(E) Vital signs;
(F) Laboratory test values/results;
(G) Procedures;
(H) Medication list; and
(I) Insurance.
(ii) [Reserved]
(g) * * *
(1) Optional--Automated numerator recording. For each meaningful use objective with a percentage-based measure, EHR technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage.
* * * * *
(3) Safety-enhanced design. User-centered design processes must be applied to each capability an EHR technology includes that is specified in the following certification criteria: SEC 170.314(a)(1), (2), (6) through (8), (16) and (18) through (20) and (b)(3), (4), and (9).
* * * * *
(h) Transport methods --(1) Optional--Applicability Statement for
(2) Optional--Applicability Statement for
(3) Optional--
Subpart D--[Removed and Reserved]
13. Remove and reserve subpart D, consisting of SUBSEC 170.400 through 170.499.
14. Section 170.501 is amended by designating the existing text as paragraph (a) and by adding paragraph (b) to read as follows:
SEC 170.501 Applicability.
* * * * *
(b) References to the term Complete EHR and Complete EHR certification throughout this subpart do not apply to certification in accordance with any edition of certification criteria that is adopted by the Secretary under subpart C after the 2014 Edition EHR certification criteria.
15. Section 170.503 is amended by revising paragraphs (b)(1) and (e)(1) and (2) to read as follows:
SEC 170.503 Requests for ONC-AA status and ONC-AA ongoing responsibilities.
* * * * *
(b) * * *
(1) A detailed description of the accreditation organization's conformance to ISO/IEC17011 (incorporated by reference in SEC 170.599) and experience evaluating the conformance of certification bodies to ISO/IEC 17065 (incorporated by reference in SEC 170.599).
* * * * *
(e) * * *
(1) Maintain conformance with ISO/IEC 17011 (incorporated by reference in SEC 170.599);
(2) Verify that the certification bodies it accredits and ONC-ACBs conform to, at a minimum:
(i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated by reference in SEC 170.599); and
(ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065 (incorporated by reference in SEC 170.599).
* * * * *
16. Section 170.523 is amended by adding paragraph (l) to read as follows:
SEC 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(l) Display the ONC Certified HIT Certification and Design Mark on all certifications issued under the ONC HIT Certification Program in a manner that complies with the Criteria and Terms of Use for the ONC Certified HIT Certification and Design Mark, and ensure that use of the mark by HIT developers whose products are certified under the ONC HIT Certification Program is compliant with the Criteria and Terms of Use for the ONC Certified HIT Certification and Design Mark.
17. Section 170.550 is amended by revising paragraph (f)(1) to read as follows:
SEC 170.550 EHR Module certification.
* * * * *
(f) * * *
(1) Section 170.314(g)(1) or (2) if the EHR Module has capabilities presented for certification that would support a meaningful use objective with a percentage-based measure;
* * * * *
SEC 170.550 [Amended]
18. Section 170.550 is further amended, effective
19. Section 170.599 is amended by revising paragraphs (b)(1) and (2) and adding paragraph (b)(3) to read as follows:
SEC 170.599 Incorporation by reference.
* * * * *
(b) * * *
(1) ISO/IEC 17011:2004 Conformity Assessment--General Requirements for Accreditation Bodies Accrediting Conformity Assessment Bodies (Corrected Version),
(2) ISO/IEC GUIDE 65:1996--General Requirements for Bodies Operating Product Certification Systems (First Edition), 1996, "ISO/IEC Guide 65," IBR approved for SEC 170.503.
(3) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for bodies certifying products, processes and services (First Edition), 2012, "ISO/IEC 17065," IBR approved for SEC 170.503.
Dated:
Sylvia M. Burwell,
Secretary.
[FR Doc. 2014-21633 Filed 9-10-14;
BILLING CODE 4150-45-P
Copyright: | (c) 2014 Federal Information & News Dispatch, Inc. |
Wordcount: | 52304 |
Advisor News
Annuity News
Health/Employee Benefits News
Life Insurance News