Skip to Content

Proposed Rule

21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program

Document Details

Information about this document as published in the Federal Register.

Document Statistics
Document page views are updated periodically throughout the day and are cumulative counts for this document including its time on Public Inspection. Counts are subject to sampling, reprocessing and revision (up or down) throughout the day.
Enhanced Content

Relevant information about this document from Regulations.gov provides additional context. This information is not part of the official Federal Register document.

Published Document

This document has been published in the Federal Register. Use the PDF linked in the document sidebar for the official electronic format.

Start Preamble Start Printed Page 7424

AGENCY:

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

ACTION:

Proposed rule.

SUMMARY:

This proposed rule would implement certain provisions of the 21st Century Cures Act, including conditions and maintenance of certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program), the voluntary certification of health IT for use by pediatric health care providers, and reasonable and necessary activities that do not constitute information blocking. The implementation of these provisions would advance interoperability and support the access, exchange, and use of electronic health information. The proposed rule would also modify the 2015 Edition health IT certification criteria and Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs.

DATES:

To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on May 3, 2019.

ADDRESSES:

You may submit comments, identified by RIN 0955-AA01, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.

  • Federal eRulemaking Portal: Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
  • Regular, Express, or Overnight Mail: Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies.
  • Hand Delivery or Courier: Office of the National Coordinator for Health Information Technology, Attention: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Mary E. Switzer Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.)

Enhancing the Public Comment Experience: To facilitate public comment on this proposed rule, a copy will be made available in Microsoft Word format on ONC's website (http://www.healthit.gov). We believe this version will make it easier for commenters to access and copy portions of the proposed rule for use in their individual comments. Additionally, a separate document (“public comment template”) will also be made available on ONC's website (http://www.healthit.gov) for the public to use in providing comments on the proposed rule. This document is meant to provide the public with a simple and organized way to submit comments on proposals and respond to specific questions posed in the preamble of the proposed rule. While use of this document is entirely voluntary, we encourage commenters to consider using the document in lieu of unstructured comments, or to use it as an addendum to narrative cover pages. We believe that use of the document may facilitate our review and understanding of the comments received. The public comment template will be available shortly after the proposed rule publishes in the Federal Register. This short delay will permit the appropriate citation in the public comment template to pages of the published version of the proposed rule.

Inspection of Public Comments: All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to: A person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at http://www.regulations.gov.

Docket: For access to the docket to read background documents or comments received, go to http://www.regulations.gov or the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection).

Start Further Info

FOR FURTHER INFORMATION CONTACT:

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

End Further Info End Preamble Start Supplemental Information

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Major Provisions and Clarifications

1. Deregulatory Actions for Previous Rulemakings

2. Updates to the 2015 Edition Certification Criteria

a. Adoption of the United States Core Data for Interoperability as a Standard

b. Electronic Prescribing

c. Clinical Quality Measures—Report

d. Electronic Health Information Export

e. Application Programming Interfaces

f. Privacy and Security Transparency Attestations

g. Data Segmentation for Privacy and Consent Management

3. Modifications to the ONC Health IT Certification Program

4. Health IT for the Care Continuum

5. Conditions and Maintenance of Certification

6. Information Blocking

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. Health IT Certification Program(s)

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

2. ONC Health IT Certification Program Rules

III. Deregulatory Actions for Previous Rulemakings

A. Background

1. History of Burden Reduction and Regulatory Flexibility

2. Executive Orders 13771 and 13777Start Printed Page 7425

B. Proposed Deregulatory Actions

1. Removal of Randomized Surveillance Requirements

2. Removal of the 2014 Edition From the Code of Federal Regulations

3. Removal of the ONC-Approved Accreditor From the Program

4. Removal of Certain 2015 Edition Certification Criteria and Standards

a. 2015 Edition Base EHR Definition Certification Criteria

b. Drug-Formulary and Preferred Drug Lists

c. Patient-Specific Education Resources

d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive

e. Secure Messaging

5. Removal of Certain ONC Health IT Certification Program Requirements

a. Limitations Disclosures

b. Transparency and Mandatory Disclosures Requirements

6. Recognition of Food and Drug Administration Processes

a. FDA Software Pre-Certification Pilot Program

b. Development of Similar Independent Program Processes—Request for Information

IV. Updates to the 2015 Edition Certification Criteria

A. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

2. Compliance with Adopted Standards and Implementation Specifications

3. “Reasonably Available” to Interested Parties

B. Revised and New 2015 Edition Criteria

1. The United States Core Data for Interoperability Standard (USCDI)

a. USCDI 2015 Edition Certification Criteria

b. USCDI Standard—Data Classes Included

c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications

d. Clinical Notes C-CDA Implementation Specification

2. Electronic Prescribing Criterion

3. Clinical Quality Measures—Report Criterion

4. Electronic Health Information Export Criterion

a. Patient Access

b. Transitions Between Health IT Systems

c. Scope of EHI

d. Export Format

e. Initial Step to Persistent Access to All of a Patient's EHI

f. Timeframes

g. Replaces the 2015 Edition “Data Export” Criterion in the 2015 Edition Base EHR Definition

5. Standardized API for Patient and Population Services Criterion

6. Privacy and Security Transparency Attestations Criteria

a. Background

b. Encrypt Authentication Credentials

c. Multi-factor Authentication

7. Data Segmentation for Privacy and Consent Management Criteria

a. Implementation With the Consolidated CDA Release 2.1

b. Implementation With FHIR Standard

C. Unchanged 2015 Edition Criteria—Promoting Interoperability Programs Reference Alignment

V. Modifications to the ONC Health IT Certification Program

A. Corrections

1. Auditable Events and Tamper Resistance

2. Amendments

3. View, Download, and Transmit to 3rd Party

4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework

B. Principles of Proper Conduct for ONC-ACBs

1. Records Retention

2. Conformance Methods for Certification Criteria

3. ONC-ACBs to Accept Test Results From Any ONC-ATL in Good Standing

4. Mandatory Disclosures and Certifications

C. Principles of Proper Conduct for ONC-ATLs—Records Retention

VI. Health IT for the Care Continuum

A. Health IT for Pediatric Setting

1. Background and Stakeholder Convening

2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care

a. 2015 Edition Certification Criteria

b. New or Revised Certification Criteria in This Proposed Rule

B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information

1. 2015 Edition Certification Criteria

2. Revised or New 2015 Edition Certification Criteria in This Proposed Rule

3. Emerging Standards and Innovations

4. Additional Comment Areas

VII. Conditions and Maintenance of Certification

A. Implementation

B. Provisions

1. Information Blocking

2. Assurances

a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities

b. Certification to the “Electronic Health Information Export” Criterion

c. Records and Information Retention

d. Trusted Exchange Framework and the Common Agreement—Request for Information

3. Communications

a. Background and Purpose

b. Condition of Certification Requirements

c. Maintenance of Certification Requirements

4. Application Programming Interfaces

a. Statutory Interpretation and API Policy Principles

b. Key Terms

c. Proposed API Standards, Implementation Specifications, and Certification Criterion

d. Condition of Certification Requirements

e. Maintenance of Certification Requirements

f. 2015 Edition Base EHR Definition

5. Real World Testing

6. Attestations

7. EHR Reporting Criteria Submission

C. Compliance

D. Enforcement

1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements

2. Review and Enforcement Only by ONC

3. Review Processes

a. Initiating Review and Health IT Developer Notice

b. Relationship with ONC-ACBs and ONC-ATLs

c. Records Access

d. Corrective Action

e. Certification Ban and Termination

f. Appeal

g. Suspension

h. Proposed Termination

4. Public Listing of Certification Ban and Terminations

5. Effect on Existing Program Requirements and Processes

6. Concurrent Enforcement by the Office of Inspector General

7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers

VIII. Information Blocking

A. Statutory Basis

B. Legislative Background and Policy Considerations

1. Purpose of the Information Blocking Provision

2. Policy Considerations and Approach to the Information Blocking Provisions

C. Relevant Statutory Terms and Provisions

1. “Required by Law”

2. Health Care Providers, Health IT Developers, Exchanges, and Networks

a. Health Care Providers

b. Health IT Developers of Certified Health IT

c. Networks and Exchanges

3. Electronic Health Information

4. Interests Promoted by the Information Blocking Provision

a. Access, Exchange, and Use of EHI

b. Interoperability Elements

5. Practices That May Implicate the Information Blocking Provision

a. Prevention, Material Discouragement, and Other Interference

b. Likelihood of Interference

c. Examples of Practices Likely To Interfere With Access, Exchange, or Use of EHI

6. Applicability of Exceptions

a. Reasonable and Necessary Activities

b. Treatment of Different Types of Actors

c. Establishing That Activities and Practices Meet the Conditions of an Exception

D. Proposed Exceptions to the Information Blocking Provision

1. Preventing Harm

2. Promoting the Privacy of EHI

3. Promoting the Security of EHI

4. Recovering Costs Reasonably Incurred

5. Responding to Requests That Are Infeasible

6. Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms

7. Maintaining and Improving Health IT Performance

E. Additional Exceptions—Request for InformationStart Printed Page 7426

1. Exception for Complying With Common Agreement for Trusted Exchange

2. New Exceptions

F. Complaint Process

G. Disincentives for Health Care Providers—Request for Information

IX. Registries Request for Information

X. Patient Matching Request for Information

XI. Incorporation by Reference

XII. Response to Comments

XIII. Collection of Information Requirements

A. ONC-ACBs

B. Health IT Developers

XIV. Regulatory Impact Analysis

A. Statement of Need

B. Alternatives Considered

C. Overall Impact

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

2. Executive Order 13771—Reducing Regulation and Controlling Regulatory Costs

a. Costs and Benefits

b. Accounting Statement and Table

3. Regulatory Flexibility Act

4. Executive Order 13132—Federalism

5. Unfunded Mandates Reform Act of 1995

6. Executive Order 13771 Reducing Regulation and Controlling Regulatory Costs

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

ONC is responsible for the implementation of key provisions in Title IV of the 21st Century Cures Act (Cures Act) that are designed to advance interoperability; support the access, exchange, and use of electronic health information; and address occurrences of information blocking. This proposed rule would implement certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. In addition, the proposed rule would implement parts of section 4006(a) of the Cures Act to support patient access to their electronic health information (EHI), such as making a patient's EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost. Additionally, the proposed rule would modify the 2015 Edition health IT certification criteria and ONC Health IT Certification Program (Program) in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs.

In addition to fulfilling the Cures Act's requirements, the proposed rule would contribute to fulfilling Executive Order (E.O.) 13813. The President issued E.O. 13813 on October 12, 2017, to promote health care choice and competition across the United States. Section 1(c) of the E.O., in relevant part, states that government rules affecting the United States health care system should re-inject competition into the health care markets by lowering barriers to entry and preventing abuses of market power. Section 1(c) also states that government rules should improve access to and the quality of information that Americans need to make informed health care decisions. For example, as mentioned above, the proposed rule focuses on establishing Application Programming Interfaces (APIs) for several interoperability purposes, including patient access to their health information without special effort. The API approach also supports health care providers having the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology the health care providers have acquired. In addition, the proposed rule provides ONC's interpretation of the information blocking definition as established in the Cures Act and the application of the information blocking provision by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to electronic health information and promoting competition.

B. Summary of Major Provisions and Clarifications

1. Deregulatory Actions for Previous Rulemakings

Since the inception of the Program, we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to “determine whether any [agency] regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined.

ONC has reviewed and evaluated existing regulations to identify ways to administratively reduce burden and implement deregulatory actions through guidance. In this proposed rule, we also propose potential new deregulatory actions that will reduce burden for health IT developers, providers, and other stakeholders. We propose six deregulatory actions in section III.B: (1) Removal of a threshold requirement related to randomized surveillance which allows ONC-Authorized Certification Bodies (ONC-ACBs) more flexibility to identify the right approach for surveillance actions, (2) removal of the 2014 Edition from the Code of Federal Regulations (CFR), (3) removal of the ONC-Approved Accreditor (ONC-AA) from the Program, (4) removal of certain 2015 Edition certification criteria, (5) removal of certain Program requirements, and (6) recognition of relevant Food and Drug Administration certification processes with a request for comment on the potential development of new processes for the Program.

2. Updates to the 2015 Edition Certification Criteria

This rule proposes to update the 2015 Edition by not only proposing criteria for removal, but by proposing to revise and add new certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT.

a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard

As part of ONC's continued efforts to assure the availability of a minimum baseline of data classes that could be commonly available for interoperable exchange, we adopted the 2015 Edition “Common Clinical Data Set” (CCDS) definition and used the CCDS shorthand in several certification criteria. However, the CCDS definition also began to be colloquially used for many different purposes. As the CCDS definition's relevance grew outside of its regulatory context, it became a symbolic and practical limit to the industry's collective interests to go beyond the CCDS data for access, exchange, and use. In addition, as we move further towards value-based care, the need for the inclusion of additional data classes that go beyond clinical data is necessary. In order to advance interoperability, we propose to remove the CCDS definition and its references Start Printed Page 7427from the 2015 Edition and replace it with the “United States Core Data for Interoperability.” We propose to adopt the USCDI as a standard, naming USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299. The USCDI standard, if adopted, would establish a set of data classes and constituent data elements that would be required to be exchanged in support of interoperability nationwide. To achieve the goals set forth in the Cures Act, ONC intends to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. Once the USCDI is adopted in regulation naming USCDI v1, health IT developers would be allowed to take advantage of a flexibility under the Maintenance of Certification real world testing requirements, which we refer to as the “Standards Version Advancement Process” (described in section VII.B.5 of this proposed rule). The Standards Version Advancement Process would permit health IT developers to voluntarily implement and use a new version of an adopted standard, such as the USCDI, so long as the newer version was approved by the National Coordinator through the Standards Version Advancement Process for use in certification.

b. Electronic Prescribing

We propose to update the electronic prescribing (e-Rx) SCRIPT standard in 45 CFR 170.205(b) to NCPDP SCRIPT 2017071, which would result in a new e-Rx standard eventually becoming the baseline for certification. We also propose to adopt a new certification criterion in § 170.315(b)(11) for e-Rx to reflect these updated proposals. ONC and CMS have historically maintained complementary policies of maintaining aligned e-Rx and medical history (MH) standards to ensure that the current standard for certification to the electronic prescribing criterion permits use of the current Part D e-Rx and MH standards. This proposal is made to ensure such alignment as CMS recently finalized its Part D standards to NCPDP SCRIPT 2017071 for e-RX and MH, effective January 1, 2020 (83 FR 16440). In addition to continuing to reference the current transactions included in § 170.315(b)(3), in keeping with CMS' final rule, we also propose to require all of the NCPDP SCRIPT 2017071 standard transactions CMS adopted at 42 CFR 423.160(b)(2)(iv).

c. Clinical Quality Measures—Report

We propose to remove the HL7 Quality Reporting Document Architecture (QRDA) standard requirements from the 2015 Edition “CQMs—report” criterion in § 170.315(c)(3) and, in their place, require Health IT Modules to support the CMS QRDA Implementation Guide (IGs).[1] This would reduce the burden for health IT developers by only having to support one form of the QRDA standard rather than two forms (i.e., the HL7 and CMS forms).

d. Electronic Health Information Export

We propose a new 2015 Edition certification criterion for “electronic health information (EHI) export” in § 170.315(b)(10), which would replace the 2015 Edition “data export” certification criterion (§ 170.315(b)(6)) and become part of the 2015 Edition Base EHR definition. The proposed criterion supports situations in which we believe that all EHI produced and electronically managed by a developer's health IT should be made readily available for export as a standard capability of certified health IT. Specifically, this criterion would: (1) Enable the export of EHI for a single patient upon a valid request from that patient or a user on the patient's behalf, and (2) support the export of EHI when a health care provider chooses to transition or migrate information to another health IT system. This criterion would also require that the export include the data format, made publicly available, to facilitate the receiving health IT system's interpretation and use of the EHI to the extent reasonably practicable using the developer's existing technology.

This criterion provides developers with the ability to create innovative export capabilities according to their systems and data practices. We do not propose that the export must be executed according to any particular standard, but propose to require that the export must be accompanied by the data format, including its structure and syntax, to facilitate interpretation of the EHI therein. Overall, this new criterion is intended to provide patients and health IT users, including providers, a means to efficiently export the entire electronic health record for a single patient or all patients in a computable, electronic format.

e. Application Programming Interfaces (APIs)

We propose to adopt a new API criterion in § 170.315(g)(10), which would replace the “application access—data category request” certification criterion (§ 170.315(g)(8)) and become part of the 2015 Edition Base EHR definition. This new “standardized API for patient and population services” certification criterion would require the use of Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standards [2] and several implementation specifications. The new criterion would focus on supporting two types of API-enabled services: (1) Services for which a single patient's data is the focus and (2) services for which multiple patients' data are the focus.

f. Privacy and Security Transparency Attestations

We propose to adopt two new privacy and security transparency attestation certification criteria, which would identify whether certified health IT supports encrypting authentication credentials and/or multi-factor authentication. In order to be issued a certification, we propose to require that a Health IT Module developer attest to whether the Health IT Module encrypts authentication credentials and whether the Health IT Module supports multi-factor authentication. These criteria are not expected to place additional burden on health IT developers since they do not require net new development or implementation to take place in order to be met. However, certification to these proposed criteria would provide increased transparency and potentially motivate health IT developers to encrypt authentication credentials and support multi- factor authentication, which could help prevent exposure to unauthorized persons/entities.

g. Data Segmentation for Privacy and Consent Management

In the 2015 Edition, we adopted two “data segmentation for privacy” (DS4P) certification criteria, one for creating a summary record according to the DS4P standard and one for receiving a summary record according to the DS4P standard. Certification to the 2015 Edition DS4P criteria focus on data segmentation only at the document level. As noted in the 2015 Edition final rule (80 FR 62646)—and to our knowledge still an accurate assessment—certification to these criteria is currently not required to meet the Certified EHR Technology definition Start Printed Page 7428(CEHRT) or required by any other HHS program. Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. In addition, stakeholders shared with ONC—through public forums, listening sessions, and correspondence—that focusing certification on segmentation to only the document level does not permit providers the flexibility to address more granular segmentation needs. Therefore, we propose to remove the current 2015 Edition DS4P criteria. We propose to replace these two criteria with three new 2015 Edition “DS4P” certification criteria (two for C-CDA and one for a FHIR-based API) that would support a more granular approach to privacy tagging data consent management for health information exchange supported by either the C-CDA- or FHIR-based exchange standards.

3. Modifications to the ONC Health IT Certification Program

We propose to make corrections to the 2015 Edition privacy and security certification framework (80 FR 62705) and relevant regulatory provisions. These corrections have already been incorporated in the relevant Certification Companion Guides (CCGs).

We propose new and revised principles of proper conduct (PoPC) for ONC-Authorized Certification Bodies (ONC-ACBs). We propose to clarify that the records retention provision includes the “life of the edition” as well as after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We also propose to revise the PoPC in § 170.523(h) to clarify the basis for certification, including to permit a certification decision to be based on an evaluation conducted by the ONC-ACB for Health IT Modules' compliance with certification criteria by use of conformity methods approved by the National Coordinator for Health Information Technology (National Coordinator). We also propose to update § 170.523(h) to require ONC-ACBs to accept test results from any ONC-ATL that is in good standing under the Program and is compliant with its ISO 17025 accreditation requirements. We believe these proposed new and revised PoPCs would provide necessary clarifications for ONC-ACBs and would promote stability among the ONC-ACBs. We also propose to update § 170.523(k) to broaden the requirements beyond just the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs (now renamed the Promoting Interoperability Programs) and provide other necessary clarifications.

We propose to revise a PoPC for ONC-ATLs. We propose to clarify that the records retention provision includes the “life of the edition” as well as after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules.

4. Health IT for the Care Continuum

Section 4001(b) of the Cures Act includes two provisions related to supporting health IT across the care continuum. The first instructs the National Coordinator to encourage, keep or recognize through existing authorities, the voluntary certification of health IT for use in medical specialties and sites of service where more technological advancement or integration is needed. The second outlines a provision related to the voluntary certification of health IT for use by pediatric health providers to support the health care of children. These provisions align closely with ONC's core purpose to promote interoperability to support care coordination, patient engagement, and health care quality improvement initiatives. Advancing health IT that promotes and supports patient care when and where it is needed continues to be a primary goal of the Program. This means health IT should support patient populations, specialized care, transitions of care, and practice settings across the care continuum.

ONC has explored how we might work with the health IT industry and with specialty organizations to collaboratively develop and promote health IT that supports medical specialties and sites of service. Over time, ONC has taken steps to make the Program modular, more open and accessible to different types of health IT, and able to advance functionality that is generally applicable to a variety of care and practice settings. Specific to the provisions in the Cures Act to support providers of health care for children, we considered a wide range of factors. These include: The evolution of health IT across the care continuum, the costs and benefits associated with health IT, the potential regulatory burden and compliance timelines, and the need to help advance health IT that benefits multiple medical specialties and sites of service involved in the care of children. In consideration of these factors, and to advance implementation of Sections 4001(b) of the Cures Act specific to pediatric care, we held a listening session where stakeholders could share their clinical knowledge and technical expertise in pediatric care and pediatric sites of service. Through the information learned at this listening session and our analysis of the health IT landscape for pediatric settings, we have identified existing 2015 Edition criteria, as well as new and revised 2015 Edition criteria proposed in this rule, that we believe could benefit providers of pediatric care and pediatric settings. In this proposed rule, we seek comment on our analysis and the correlated certification criteria that we believe would support the health care of children.

We also recognize the significance of the opioid epidemic confronting our nation and the importance of helping to support the health IT needs of health care providers committed to preventing inappropriate access to prescription opioids and to providing safe, appropriate treatment. We believe health IT offers promising strategies to help assist medical specialties and sites of services impacted by the opioid epidemic. Therefore, we request public comment on how our existing Program requirements and the proposals in this rulemaking may support use cases related to Opioid Use Disorder (OUD) prevention and treatment and if there are additional areas that ONC should consider for effective implementation of health IT to help address OUD prevention and treatment.

5. Conditions and Maintenance of Certification

We propose to establish certain Conditions and Maintenance of Certification requirements for health IT developers based on the conditions and maintenance of certification requirements outlined in section 4002 of the Cures Act. We propose an approach whereby the Conditions and Maintenance of Certification express both initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. In this regard, we propose to implement the Cures Act Conditions of Certification with further specificity as it applies to the Program and propose to implement any accompanying Maintenance of Certification requirements as standalone requirements to ensure that not only are the Conditions of Certification met, but that they are continually being met through the Maintenance of Certification requirements. For ease of reference and to distinguish from other conditions, we propose to capitalize “Conditions of Certification” and “Maintenance of Certification” when referring to Conditions and Maintenance Start Printed Page 7429of Certification requirements established under the Cures Act.

Information Blocking

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). We propose to establish this information blocking Condition of Certification in § 170.401. The Condition of Certification would prohibit any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA and proposed in § 171.103.

Assurances

Section 3001(c)(5)(D)(ii) of the Cures Act requires that a health IT developer, as a Condition of Certification under the Program, provide assurances to the Secretary that, unless for legitimate purposes specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of EHI. We propose to implement this provision through several Conditions of Certification and accompanying Maintenance requirements, which are set forth in proposed § 170.402. We also propose to establish more specific Conditions and Maintenance of Certification requirements to provide assurances that a health IT developer does not take any other action that may inhibit the appropriate exchange, access, and use of EHI. These proposed requirements serve to provide further clarity under the Program as to how health IT developers can provide such broad assurances with more specific actions.

Communications

As a Condition and Maintenance of Certification under the Program, the Cures Act requires that health IT developers do not prohibit or restrict communications about certain aspects of the performance of health IT and the developers' related business practices. We propose that developers will be permitted to impose certain kinds of limited prohibitions and restrictions that we believe strike a reasonable balance between the need to promote open communication about health IT and related developer business practices and the need to protect the legitimate interests of health IT developers and other entities. However, certain narrowly-defined types of communications—such as communications required by law, made to a government agency, or made to a defined category of safety organization—would receive “unqualified protection,” meaning that developers would be absolutely prohibited from imposing any prohibitions or restrictions on such protected communications.

We propose that to maintain compliance with this Condition of Certification, a health IT developer must not impose or enforce any contractual requirement or legal right that contravenes this Condition of Certification. Furthermore, we propose that if a health IT developer has contracts/agreements in existence that contravene this condition, the developer must notify all affected customers or other persons or entities that the prohibition or restriction will not be enforced by the health IT developer. Going forward, health IT developers would be required to amend their contracts/agreements to remove or make void the provisions that contravene this Condition of Certification within a reasonable period of time, but not later than two years from the effective date of a subsequent final rule for this proposed rule.

Application Programming Interfaces (APIs)

The Cures Act's API Condition of Certification includes several key phrases (including, for example, “without special effort”) and requirements for health IT developers that indicate the Cures Act's focus on the technical requirements as well as the actions and practices of health IT developers in implementing the certified API. In section VII.B.4 of the preamble, we outline our proposals to implement the Cures Act's API Condition of Certification. These proposals include new standards, new implementation specifications, a new certification criterion, as well as detailed Conditions and Maintenance of Certification requirements.

Real World Testing

The Cures Act adds a new Condition and Maintenance of Certification requirement that health IT developers successfully test the real world use of the technology for interoperability in the type of setting in which such technology would be marketed. In this proposed rule, we outline what successful “real world testing” means for the purpose of this Condition of Certification, as well as proposed Maintenance requirements—including standards updates for widespread and continued interoperability.

We propose to limit the applicability of this Condition of Certification to health IT developers with Health IT Modules certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange specified in section VII.B.5. We propose Maintenance of Certification requirements that would require health IT developers to submit publicly available annual real world testing plans as well as annual real world testing results for certified health IT products focused on interoperability. We also propose a Maintenance of Certification flexibility we have named the Standards Version Advancement Process, under which health IT developers with health IT certified to the criteria specified for interoperability and data exchange would have the option to update their health IT to a more advanced version(s) of the standard(s) or implementation specification(s) included in the criteria once such versions are approved by the National Coordinator through the Standards Version Advancement Process for use in health IT certified under the Program. Similarly, we propose that health IT developers presenting new health IT for certification to one of the criteria specified in Section VII.B.5 would have the option to certify to a National Coordinator-approved more advanced version of the adopted standards or implementation specifications included in the criteria. We propose that health IT developers voluntarily opting to avail themselves of the Standards Version Advancement Process must address their planned and actual timelines for implementation and rollout of standards updates in their annual real world testing plans and real world testing results submissions. We also propose that health IT developers of products with existing certifications who plan to avail themselves of the Standards Version Advancement Process flexibility notify both their ONC-ACB and their affected customers of their intention and plans to update their certified health IT and its anticipated impact on their existing certified health IT and customers, specifically including but not limited to whether, and if so for how long, the health IT developer intends to continue to support the certificate for the health IT certified to the prior version of the standard.

We propose a new PoPC for ONC-ACBs that would require ONC-ACBs to review and confirm that applicable health IT developers submit real world testing plans and real world results in accordance with our proposals. Once Start Printed Page 7430completeness is confirmed, ONC-ACBs would upload the plans and results via hyperlinks to the Certified Health IT Product List (CHPL). We propose to revise the PoPC in § 170.523(m) to require ONC-ACBs to collect, no less than quarterly, all updates successfully made to standards in certified health IT pursuant to the developers having voluntarily opted to avail themselves of the Standards Version Advancement Process flexibility under the real world testing Condition of Certification. We propose in § 170.523(t), a new PoPC for ONC-ACBs requiring them to ensure that developers seeking to take advantage of the Standards Version Advancement Process flexibility in § 170.405(b)(5) comply with the applicable requirements.

Attestations

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, provide to the Secretary an attestation to all the Conditions of Certification specified in the Cures Act, except for the “EHR reporting criteria submission” Condition of Certification. We propose to implement the Cures Act “attestations” Condition of Certification in § 170.406. Health IT developers would attest twice a year to compliance with the Conditions and Maintenance of Certification requirements (except for the EHR reporting criteria requirement, which would be metrics reporting requirements separately implemented through a future rulemaking). The 6-month attestation period we propose in § 170.406(b)(2) would properly balance the need to support appropriate enforcement with the attestation burden placed on health IT developers. In this regard, the proposed rule includes provisions to make the process as simple and efficient for health IT developers as possible (e.g., 14-day grace period, web-based form submissions, and attestation alert reminders).

We propose that attestations would be submitted to ONC-ACBs on behalf of ONC and the Secretary. We propose a new PoPC in § 170.523(q) that an ONC-ACB must review and submit the health IT developers' attestations to ONC. ONC would then make the attestations publicly available through the CHPL.

EHR Reporting Criteria Submission

The Cures Act specifies that health IT developers be required, as a Condition and Maintenance of Certification under the Program, to submit reporting criteria on certified health IT in accordance with the EHR reporting program established under section 3009A of the PHSA, as added by the Cures Act. We have not yet established an EHR reporting program. Once ONC establishes such program, we will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification requirement(s) for health IT developers.

Enforcement

Section 4002 of the Cures Act adds Program requirements aimed at addressing health IT developer actions and business practices through the Conditions and Maintenance of Certification requirements, which expands the current focus of the Program requirements beyond the certified health IT itself. Equally important, section 4002 also provides that the Secretary of HHS may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. We, therefore, propose a general enforcement approach to encourage consistent compliance with the requirements. The proposed rule outlines a corrective action process for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement has not been or is not being met by a health IT developer under the Program. We propose, with minor modifications, to utilize the processes previously established for ONC direct review of certified health IT and codified in §§ 170.580 and 170.581 for the enforcement of the Conditions and Maintenance of Certification requirements. Where noncompliance is identified, our first priority would be to work with the health IT developer to remedy the matter through a corrective action process. However, we propose that, under certain circumstances, ONC may ban a health IT developer from the Program or terminate the certification of one or more of its Health IT Modules.

6. Information Blocking

Section 4004 of the Cures Act added section 3022 of the PHSA (42 U.S.C. 300jj-52, “the information blocking provision”), which defines conduct by health care providers, and health IT developers of certified health IT, exchanges, and networks that constitutes information blocking. Section 3022(a)(1) of the PHSA defines information blocking in broad terms, while section 3022(a)(3) authorizes and charges the Secretary to identify reasonable and necessary activities that do not constitute information blocking (section 3022(a)(3) of the PHSA).

We identify several reasonable and necessary activities as exceptions to the information blocking definition, each of which we propose would not constitute information blocking for purposes of section 3022(a)(1) of the PHSA. The exceptions would extend to certain activities that interfere with the access, exchange, or use of EHI but that may be reasonable and necessary if certain conditions are met.

In developing the proposed exceptions, we were guided by three overarching policy considerations. First, the exceptions would be limited to certain activities that clearly advance the aims of the information blocking provision; promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI, and protecting patient safety; and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, each exception is intended to address a significant risk that regulated individuals and entities (i.e., health care providers, health IT developers of certified health IT, health information networks, and health information exchanges) will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt.

The seven proposed exceptions are set forth in section VIII.D below. The first three exceptions, set forth in VIII.D.1-D.3 address activities that are reasonable and necessary to promote public confidence in the use of health IT and the exchange of EHI. These exceptions are intended to protect patient safety; promote the privacy of EHI; and promote the security of EHI. The next three exceptions, set forth in VIII.D.4-D.6, address activities that are reasonable and necessary to promote competition and consumer welfare. These exceptions would allow for the recovery of costs reasonably incurred; excuse an actor from responding to requests that are infeasible; and permit the licensing of interoperability elements on reasonable and non- discriminatory terms. The last exception, set forth in VIII.D.7, addresses activities that are reasonable and necessary to promote the performance of health IT. This proposed exception recognizes that actors may make health IT temporarily unavailable for maintenance or improvements that Start Printed Page 7431benefit the overall performance and usability of health IT.

To qualify for any of these exceptions, we propose that an individual or entity would, for each relevant practice and at all relevant times, have to satisfy all of the applicable conditions of the exception. Additionally, we propose (in section VIII.C of this preamble) to define or interpret terms that are present in section 3022 of the PHSA (such as the types of individuals and entities covered by the information blocking provision). We also propose certain new terms and definitions that are necessary to implement the information blocking provisions. We propose to codify the proposed exceptions and other information blocking proposals in a new part of title 45 of the Code of Federal Regulations, part 171.

C. Costs and Benefits

Executive Orders 12866 on Regulatory Planning and Review (September 30, 1993) and 13563 on Improving Regulation and Regulatory Review (February 2, 2011) direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). OMB has determined that this proposed rule is an economically significant rule as the potential costs associated with this proposed rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this proposed rule.

We have estimated the potential monetary costs and benefits of this proposed rule for health IT developers, health care providers, patients, ONC-ACBs, ONC-ATLs, and the federal government (i.e., ONC), and have broken those costs and benefits out into the following categories: (1) Deregulatory actions (no associated costs); (2) updates to the updates to the 2015 Edition health IT certification criteria; (3) Conditions and Maintenance of Certification for a health IT developer; (4) oversight for the Conditions and Maintenance of Certification; and (5) information blocking.

We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2016 dollars as it is the most recent data available to address all cost and benefit estimates consistently. We also note that we did not have adequate data to quantify some of the costs and benefits within this RIA. In those situations, we have described the qualitative costs and benefits of our proposals; however, such qualitative costs and benefits have not been accounted for in the monetary cost and benefit totals below.

We estimate that the total annual cost for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would, on average, range from $365 million to $919 million with an average annual cost of $642 million. We estimate that the total perpetual cost for this proposed rule (starting in year two), based on the cost estimates outlined above, would, on average, range from $228 million to $452 million with an average annual cost of $340 million.

We estimate the total annual benefit for this proposed rule would range from $3.08 billion to $9.15 billion with an average annual benefit of $6.1 billion.

We estimate the total annual net benefit for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost and benefit estimates outlined above, would range from $2.7 billion to $8.2 billion with an average net benefit of $5.5 billion. We estimate the total perpetual annual net benefit for this proposed rule (starting in year two), based on the cost-benefit estimates outlined above, would range from $2.9 billion to $8.7 billion with an average net benefit of $5.8 billion.

II. Background

A. Statutory Basis

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

The Cures Act was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act (Title XIII of Division A of Pub. L. 111-5) by modifying or adding certain provisions to the PHSA relating to health IT.

1. Standards, Implementation Specifications, and Certification Criteria

The HITECH Act established two new federal advisory committees, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria.

Section 3002 of the Cures Act amended the PHSA by replacing the HITPC and HITSC with one committee, the Health Information Technology Advisory Committee (HIT Advisory Committee or HITAC). Section 3002(a) establishes that the HITAC shall advise and recommend to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria, relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1)(A) of the PHSA, this includes providing to the National Coordinator recommendations on a policy framework to advance interoperable health IT infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) identifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, the HITAC will develop a schedule for the assessment of policy recommendations for the Secretary to publish in the Federal Register.

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 Start Printed Page 7432determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register.

Section 3004(b)(3) of the PHSA titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria.

2. Health IT Certification Program(s)

Under the HITECH Act, section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of health IT. Specifically, section 3001(c)(5)(A) specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under this subtitle (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA). The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Overall, section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. The HITECH Act also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non-federal laboratories to perform testing.

Section 3001(c)(5) of the PHSA was amended by the Cures Act, which instructs the National Coordinator to encourage, keep, or recognize, through existing authorities, the voluntary certification of health IT under the Program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. Section 3001(c)(5)(C)(iii) identifies that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the care of children, as well as adopt certification criteria under section 3004 to support the voluntary certification of health IT for use by pediatric health providers. The Cures Act further amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which provides the Secretary with the authority, through notice and comment rulemaking, to require conditions and maintenance of certification requirements for the Program.

B. Regulatory History

The Secretary issued an interim final rule with request for comments (75 FR 2014, Jan. 13, 2010), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, ONC published a proposed rule (75 FR 11328) that proposed both a temporary and permanent certification program for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010 (75 FR 36158) and a final rule establishing the permanent certification program was published on January 7, 2011 (76 FR 1262). ONC issued multiple rulemakings since these initial rulemaking to update standards, implementation specifications, and certification criteria and the certification program, a history of which can be found in the final rule titled, “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (Oct. 16, 2015, 80 FR 62602) (“2015 Edition final rule”). A correction notice was published for the 2015 Edition final rule on December 11, 2015 (80 FR 76868) to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers.

The 2015 Edition final rule established a new edition of certification criteria (“2015 Edition health IT certification criteria” or “2015 Edition”) and a new 2015 Edition Base EHR definition. The 2015 Edition established the capabilities and specified the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability Programs) [3] when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The 2015 Edition final rule also made changes to the Program. The final rule adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct (PoPC) for ONC-ACBs.

After issuing a proposed rule on March 2, 2016 (81 FR 11056), ONC published a final rule titled, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 72404) (“EOA final rule”) on October 19, 2016. The final rule finalized modifications and new requirements under the Program, including provisions related to ONC's role in the Program. The final rule created a regulatory framework for ONC's direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also sets forth processes for ONC to authorize and oversee accredited testing laboratories under the Program. In addition, it includes provisions for expanded public availability of certified health IT surveillance results.

III. Deregulatory Actions for Previous Rulemakings

A. Background

1. History of Burden Reduction and Flexibility

Since the inception of the ONC Health IT Certification Program (Program), we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we Start Printed Page 7433have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to “determine whether any [agency] regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined.

For example, in the 2014 Edition final rule (77 FR 54164), we revised the certified electronic health record technology (CEHRT) definition to provide flexibility and create regulatory efficiencies by narrowing required functionality to a core set of capabilities (i.e., the Base EHR definition) plus the additional capabilities each eligible clinician, eligible hospital, and critical access hospital needed to successfully achieve the applicable objective and measures under the EHR Incentive Programs (now referred to as the Promoting Interoperability Programs). ONC has also supported more efficient testing and certification methods and reduced regulatory burden through the adoption of a gap certification policy. As explained in the 2014 Edition final rule (77 FR 54254) and the 2015 Edition final rule (80 FR 62681), where applicable, gap certification allows for the use of a previously certified health IT product's test results to certification criteria identified as unchanged. Developers have been able to use gap certification for the more efficient certification of their health IT when updating from the 2011 Edition to the 2014 Edition and from the 2014 Edition to the 2015 Edition.

ONC introduced further means to reduce regulatory burden, increase regulatory flexibility, and promote innovation in the 2014 Edition Release 2 final rule (79 FR 54430). The 2014 Edition Release 2 final rule established a set of optional 2014 Edition certification criteria that provided flexibility and alternative certification pathways for health IT developers and providers based on their specific circumstances. The 2014 Edition Release 2 final rule also simplified the Program by discontinuing the use of the “Complete EHR” certification concept beginning with the 2015 Edition (79 FR 54443).

In the 2015 Edition final rule, we did not “carry forward” certain 2014 Edition certification criteria into the 2015 Edition, such as the “image results,” “patient list creation,” and “electronic medication administration record” criteria. We determined that these criteria did not advance functionality or support interoperability (80 FR 62682-84). We also did not require all health IT to be certified to the “meaningful use measurement” certification criteria for “automated numerator recording” and “automated measure calculation” (80 FR 62605), which had been previously required for the 2014 Edition. Based on stakeholder feedback and Program administration observations, we also permitted testing efficiencies for the 2015 Edition “automated numerator recording” and “automated measure calculation” criteria by removing the live demonstration requirement of recording data and generating reports. Health IT developers may now self-test their Health IT Modules(s) and submit the resulting reports to the ONC- Authorized Testing Laboratory (ONC-ATL) to verify compliance with the criterion.[4] In order to further reduce burden for health IT developers, we adopted a simpler, straight-forward approach to privacy and security certification requirements, which clarified which requirements are applicable to each criterion within the regulatory functional areas (80 FR 62605).

2. Executive Orders 13771 and 13777

On January 30, 2017, the President issued Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs, which requires agencies to identify deregulatory actions. This order was followed by Executive Order 13777, titled “Enforcing the Regulatory Reform Agenda” (February 24, 2017). Executive Order 13777 provides further direction on implementing regulatory reform by identifying a process by which agencies must review and evaluate existing regulations and make recommendations for repeal or simplification.

In order to implement these regulatory reform initiatives and policies, over the past year ONC reviewed and evaluated existing regulations. During our review, we sought to identify ways to further reduce administrative burden, to implement deregulatory actions through guidance, and to propose potential new deregulatory actions in this proposed rule that will reduce burden for health IT developer, providers, and other stakeholders.

On August 21, 2017, ONC issued Relied Upon Software Program Guidance.[5] Health IT developers are permitted to use “relied upon software” (76 FR 1276) to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C. Historically, in cases where a Health IT Module is paired with multiple “relied upon software” products for the same capability, health IT developers were required to demonstrate compliance for the same certification criterion with each of those “relied upon software” products in order for the products to be listed on the Certified Health IT Product List (CHPL). With the issued guidance, health IT developers may now demonstrate compliance with only one “relied upon software” product for a criterion/capability. Once the health IT developer demonstrates compliance with a minimum of one “relied upon software” product, the developer can have multiple, additional “relied upon software” products for the same criterion/capability listed on the CHPL (https://chpl.healthit.gov/​). This approach reduces burden for health IT developers, ONC-ATLs, and ONC-Authorized Certification Bodies (ONC-ACBs).

On September 21, 2017, ONC reduced the overall burden for testing health IT to the 2015 Edition.[6] ONC reviewed the 2015 Edition test procedures, which identify minimum testing requirements ONC-ATLs must evaluate during testing. ONC changed 30 of the 2015 Edition test procedures to attestation only (i.e., a “yes” self-declaration by the health IT developer that their product has capabilities conformant with those specified in the associated certification criterion/criteria).[7] This deregulatory action reduced burden and costs program-wide, while still maintaining the Program's high level of integrity and assurances. Health IT developers now have reduced preparation and testing costs for testing to these criteria. Specifically, the cost savings for health IT developers have been estimated between $8.34 and $9.26 million. ONC-ATLs also benefit by having more time and resources to focus on tool-based Start Printed Page 7434testing (for interoperability-oriented criteria) and being responsive to any retesting requirements that may arise from ONC-ACB surveillance activities. Furthermore, providers and users of certified health IT do not lose confidence in the Program because this burden reduction effort in no way alters the expectations of conformance and responsibilities of Program participants. Health IT developers are still required to meet certification criteria requirements and maintain their products' conformance to the full scope of the associated criteria, including when implemented in the field and in production use. Similarly, ONC and ONC-ACBs continue to conduct surveillance activities and respond to end-user complaints.

B. Proposed Deregulatory Actions

We propose six deregulatory actions below. We welcome comments on these potential deregulatory actions and any other potential deregulatory actions we should consider. We also refer readers to section XIV (Regulatory Impact Analysis) of this proposed rule for a discussion of the estimated cost savings from these proposed deregulatory actions.

1. Removal of Randomized Surveillance Requirements

ONC-ACBs are required to conduct surveillance of certified health IT under the Program to ensure that health IT continues to conform and function as required by the full scope of the certification requirements. Surveillance is categorized as either reactive surveillance (for example, complaint-based surveillance) or randomized surveillance, which, by regulation, requires ONC-ACBs to proactively surveil 2% of the certificates they issue annually. On September 21, 2017, we exercised enforcement discretion with respect to the implementation of randomized surveillance by ONC-ACBs.[8] Consistent with this exercise of enforcement discretion, we now propose to eliminate certain regulatory randomized surveillance requirements.

We propose to revise §  170.556(c) by changing the requirement that ONC-ACBs must conduct in-the-field, randomized surveillance to specify that ONC-ACBs may conduct in-the- field, randomized surveillance. We further propose to remove §  170.556(c)(2), which specifies that ONC-ACBs must conduct randomized surveillance for a minimum of 2% of certified health IT products per year. We also propose to remove the requirements in § 170.556(c)(5) regarding the exclusion and exhaustion of selected locations for randomized surveillance. Additionally, we propose to remove the requirements in §  170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance. Without these regulatory requirements, ONC-ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, using the methodology identified by ONC with respect to scope (§  170.556(c)(1)), selection method (§  170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§  170.556(c)(4)).

Stakeholders have expressed concern that the benefits of in-the-field, randomized surveillance may not outweigh the time commitment required by providers, particularly if no non-conformities are found. In general, providers have expressed that reactive surveillance (e.g., surveillance based on user complaints) is a more logical and economical approach to surveillance. The removal of randomized surveillance requirements would also give ONC-ACBs the flexibility and time to focus on other priorities, such as the certification of health IT to the 2015 Edition. Therefore, as discussed above, we propose to eliminate certain regulatory randomized surveillance requirements.

2. Removal of the 2014 Edition From the Code of Federal Regulations

We propose to remove the 2014 Edition from the Code of Federal Regulations (CFR). The 2014 Edition was the result of rulemaking completed in 2012 and includes standards and functionality that are now significantly outmoded. Removal of the 2014 Edition would make the 2015 Edition the baseline for health IT certification. The 2015 Edition, including the additional certification criteria, standards, and requirements proposed in this proposed rule, better enables interoperability and the access, exchange, and use of electronic health information. Adoption and implementation of the 2015 Edition, including the proposals in this proposed rule, would also lead to the benefits outlined in the 2015 Edition final rule (80 FR 62602-62603, 62605-62606, 62740) and in this proposed rule (see, for example, the Executive Summary and the “Assurances,” “API”, and “Real World Testing” Conditions and Maintenance of Certification sections). Equally important, adoption and implementation of the 2015 Edition by providers would lead to the estimated costs savings in this proposed rule through improved interoperability supporting the access, exchange, and use of electronic health information.

Removal of the 2014 Edition would eliminate inconsistencies and costs caused by health IT certification and implementation of two different editions with different functionalities and versions of standards. Patient care could improve through the reduced risk of error that comes with the health care system's consistent implementation and use of health IT certified to the 2015 Edition. Innovation could also improve with health IT developers (including third-party software developers) developing to only one set of newer standards and implementation specifications, which would be more predictable and less costly.

Removal of the 2014 Edition would also reduce regulatory burden by no longer requiring the maintenance and support of the 2014 Edition. Maintaining compliance with only the 2015 Edition would reduce the cost and burden for health IT developers, ONC-ACBs, and ONC-ATLs because they would no longer have to support two increasingly distinct sets of requirements as is the case now with certification to both the 2014 and 2015 Editions. More specifically, health IT developers would not have to support two maintenance infrastructures and updating for their customers; nor would ONC-ATLs and ONC-ACBs have to support testing, certification, and surveillance for two separate editions of certified health IT.

As referenced by the HHS Office of Inspector General (OIG) and Centers for Medicare & Medicaid Services (CMS) in their rulemakings regarding donations of EHR items and services, we committed to retiring certification criteria editions that are no longer applicable.[9] We first did this with the removal of the 2011 Edition (79 FR 54447). Accordingly, our proposal to remove the outdated 2014 Edition for the reasons discussed above would also streamline Program compliance requirements and ensure there is no regulatory confusion between ONC's rules and other HHS rules.

To implement the removal of the 2014 Edition from the CFR, we propose to remove the 2014 Edition certification Start Printed Page 7435criteria (§ 170.314) and related standards, terms, and requirements from the CFR. In regard to terms, we propose to retire the 2014 Edition-related definitions found in § 170.102, including the “2014 Edition Base EHR,” “2014 Edition EHR certification criteria,” and “Complete EHR, 2014 Edition.” As explained in the 2015 Edition final rule (80 FR 62719), the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria. Because this concept was discontinued for the 2015 Edition, we propose to remove § 170.545 and any references to Complete EHR from the regulation text in conjunction with the removal of the 2014 Edition. We also propose to remove references to the 2014 Edition from the Common Clinical Data Set (CCDS) definition. However, as discussed later in section IV.B.1 (“United States Core Data for Interoperability”) of this proposed rule, we propose to remove the CCDS definition from the CFR and effectively replace it with a new government-unique standard, the United States Core Data for Interoperability (USCDI), proposing to adopt Version 1 (v1) in § 170.213. The new standard would be applicable to certain 2015 Edition certification criteria that currently reference the CCDS, subject to any of these criteria being removed through this rulemaking).

We propose to remove the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are only referenced in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition would remain. We propose to remove requirements in §  170.550(f) and any other requirements in subpart E, §§  170.500 through 170.599, which are specific to the 2014 Edition and do not apply to the 2015 Edition.

In order to avoid regulatory conflicts, we are taking into consideration the final rule released by CMS on November 2, 2017, which makes payment and policy changes to the second year of the Quality Payment Program (QPP). The CMS's final rule, titled “Medicare Program; CY 2018 Updates to the Quality Payment Program: Extreme and Uncontrollable Circumstance Policy for the Transition Year” (82 FR 53568), permits eligible clinicians to use health IT certified to either the 2014 or 2015 Edition certification criteria, or a combination of the two for the CY 2018 performance period. The QPP final rule also states that the 2015 Edition will be the sole edition permitted to meet the CEHRT definition starting with the CY 2019 program year.

Therefore, we propose that the effective date of removal of the 2014 Edition certification criteria and related standards, terms, and requirements from the CFR would be the effective date of a subsequent final rule for this proposed rule, which we expect will be issued in the latter half of 2019. We note that we will continue to support Medicare and Medicaid program attestations by maintaining an archive on the CHPL allowing the public to access historic information on a product certified to the 2014 Edition.

3. Removal of the ONC-Approved Accreditor From the Program

We propose to remove the ONC-Approved Accreditor (ONC-AA) from the Program. The ONC-AA's role is to accredit certification bodies for the Program and to oversee the ONC-ACBs. However, years of experience and changes with the Program have led ONC to conclude that, in many respects, the role of the ONC-AA to oversee ONC-ACBs is now duplicative of ONC's oversight. More specifically, ONC's experience with administering the Principles of Proper Conduct for ONC-ACBs as well as issuing necessary regulatory changes (e.g., ONC-ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC-ACBs. Therefore, we believe removal of the ONC-AA would reduce the Program's administrative complexity and burden.

To implement this proposed deregulatory action, we propose to remove the definition for “ONC-Approved Accreditor or ONC-AA” found in § 170.502. We also propose to remove processes related to ONC-AAs found in §§  170.501(c), 170.503, and 170.504 regarding requests for ONC-AA status, ONC-AA ongoing responsibilities, and reconsideration for requests for ONC-AA status. Regarding correspondence and communication with ONC, we propose to remove specific references to the “ONC-AA” and “accreditation organizations requesting ONC-AA status” by revising § 170.505. We also propose to remove the final rule titled “Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes” (76 FR 72636) which established a process for addressing instances where the ONC-AA engages in improper conduct or does not perform its responsibilities under the Program. Because this prior final rule relates solely to the role and removal of the ONC-AA, we propose its removal and § 170.575, which codified the final rule in the CFR.

These proposed deregulatory actions would also provide an additional benefit for ONC-ACBs. ONC-ACBs would be able to obtain and maintain accreditation to ISO/IEC 17065, with an appropriate scope, from any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF). Accordingly, we propose to revise the application process for ONC-ACB status in § 170.520(a)(3) to require documentation that confirms that the applicant has been accredited to ISO/IEC 17065, with an appropriate scope, by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF), in place of the ONC-AA accreditation documentation requirements. Similarly, instead of requiring the ONC-AA to evaluate the conformance of ONC-ACBs to ISO/IEC 17065, we propose to revise § 170.523(a) to simply require ONC-ACBs to maintain accreditation in good standing to ISO/IEC 17065 for the Program. This means that ONC-ACBs would need to continue to comply with ISO/IEC 17065 and requirements specific to the ONC Health IT Certification Program scheme.

4. Removal of Certain 2015 Edition Certification Criteria and Standards

We have reviewed and analyzed the 2015 Edition to determine whether there are certification criteria we could remove. We have identified both criteria and standards for removal as proposed below. We believe the removal of these criteria and standards will reduce burden and costs for health IT developers and health care providers by eliminating the need to: Design and meet specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for certified functionalities; and participate in surveillance of certified health IT. To these points, if our proposals are finalized in a subsequent final rule, we would expect any already issued 2015 Edition certificates to be updated to reflect the removal of applicable 2015 Edition certification criteria. We welcome comment on the proposed removal of the identified criteria and standards below and any other 2015 Edition criteria and standards we should consider for removal.Start Printed Page 7436

a. 2015 Edition Base EHR Definition Criteria

We propose the removal of certain certification criteria from the 2015 Edition that are included in the 2015 Edition Base EHR definition. The removal of these criteria would support burden and cost reductions for health IT developers and health care providers as noted above.

i. Problem List

We propose to remove the 2015 Edition “problem list” certification criterion (§ 170.315(a)(6)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording problem list information. In this regard, SNOMED CT® was adopted specifically to support the measure. This 2015 Edition “problem list” criterion remains relatively functionally the same as the 2011 Edition and has exactly the same functionally as the 2014 Edition “problem list” criterion.

We propose to remove this criterion for multiple reasons. First, this criterion no longer supports the “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from health IT systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, representing problems with SNOMED CT® is part of the USCDI and, thus, better supports interoperability through its availability for access and exchange. Accordingly, we propose to remove the “problem list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety-enhanced design” criterion.

ii. Medication List

We propose to remove the 2015 Edition “medication list” certification criterion (§ 170.315(a)(7)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication list information. The criterion does not require use of a vocabulary standard to record medications. This 2015 Edition “medication list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication list” criteria.

We propose to remove this criterion for multiple reasons. First, this criterion no longer supports a “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from EHR systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, this criterion does not even require representation of medications in standardized nomenclature. Fifth, medications are included in the USCDI and must be represented in RxNorm as part of the USCDI. This approach better supports interoperability through medication information being availability for access and exchange in a structured format. Accordingly, we propose to remove the “medications list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety-enhanced design” criterion.

iii. Medication Allergy List

We propose to remove the 2015 Edition “medication allergy list” certification criterion (§ 170.315(a)(8)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording this information. The criterion does not require use of a vocabulary standard to record medication allergies. This 2015 Edition “medication allergy list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication allergy list” criteria.

We propose to remove this criterion for multiple reasons. First, this criterion no longer supports a “recording” objective and measure of the CMS Promoting Interoperability Programs as such objective and measure no longer exist. Second, the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Third, we do not believe this functionality would be removed from EHR systems because of our proposal to remove it from the 2015 Edition Base EHR definition. This functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements. Fourth, this functionality does not directly support interoperability as the capabilities are focused on internally recording EHI. In this regard, this criterion does not even require representation of medication allergies in standardized nomenclature. Fifth, medication allergies are included in the USCDI and must be represented in RxNorm as part of the USCDI. This approach better supports interoperability through medication allergy information being availability for access and exchange in a structured format. Accordingly, we propose to remove the “medication allergy list” criterion from the 2015 Edition, including the 2015 Edition Base EHR definition. We note that once removed from the 2015 Edition, the criterion would also no longer be included in the 2015 Edition “safety- enhanced design” criterion.

iv. Smoking Status

We propose to remove the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)), which would include removing it from the 2015 Edition Base EHR definition. We previously adopted a 2015 Edition “smoking status” certification criterion that does not reference a standard. However, the CCDS definition requires smoking status to be coded in accordance with SNOMED CT®. While we continue to believe that the capture of a patient's smoking status has significant value in assisting providers with addressing the number one cause of preventable death Start Printed Page 7437and disease in the United States, we no longer believe that a criterion that simply ensures this functionality exists in health IT presented for certification is the right focus. As with other 2014 Edition functionality, we believe this functionality is fairly ubiquitous now with the widespread adoption of health IT certified to the 2014 Edition. Further, we continue to believe that, for the purposes of certification, having smoking status available for access and exchange via the USCDI is ultimately the key requirement for supporting interoperability.

Removal of Specific USCDI Smoking Status Code Sets

As mentioned above, we believe having smoking status available for USCDI purposes is fundamentally important for supporting interoperability. We propose, however, to remove the requirement to code smoking status according to the adopted eight smoking status SNOMED CT® codes as referenced in the value set in § 170.207(h). These eight codes reflect an attempt to capture smoking status in a consistent manner. Stakeholder feedback has, however, indicated that these eight codes do not appropriately and accurately capture all applicable patients' smoking statuses. Accordingly, we propose to no longer require use of only the specific eight SNOMED CT® codes for representing smoking status (and remove the standard from § 170.207). Rather, to continue to promote interoperability while also granting providers with flexibility to better support clinical care, we propose that health IT would simply be required to be capable of representing smoking status in SNOMED CT® when such information is exchanged as part of the USCDI.

b. Drug-Formulary and Preferred Drug Lists

We propose to remove the 2015 Edition “drug formulary and preferred drug list checks” criterion in § 170.315(a)(10). We adopted a 2015 Edition “drug-formulary and preferred drug list checks” criterion that separates drug formulary and preferred drug list functionality, but does not require any standards or functionality beyond that included in the 2014 Edition “drug-formulary checks” criterion. First, we believe this functionality is fairly ubiquitous now with the widespread adoption of health IT certified to the 2014 Edition, which included this general functionality. Second, without standards, this criterion does not support or facilitate the critical goal of health IT interoperability. Therefore, removal of this criterion could reduce health IT developer and health care provider burden.

c. Patient-Specific Education Resources

We propose to remove the 2015 Edition “patient-specific education resources” certification criterion (§ 170.315(a)(13)). ONC continues to support patient and provider interaction, and the identification and dissemination of patient-specific educational materials to promote positive health outcomes. However, we no longer believe that certification focused on a health IT's ability to identifying the existence of patient-specific education materials encourages the advancement of this functionality or interoperability. First, this criterion would no longer be associated with an objective or measure under the Promoting Interoperability Programs based on proposals and determinations in recent CMS rulemakings (83 FR 35928; 83 FR 41664). Second, based on the number of health IT products that have been certified for this functionality as part of 2014 Edition certification and already for 2015 Edition certification, we believe that health IT's ability to identify appropriate patient education materials is widespread now among health IT developers and their customers (e.g., health care providers). Third, we have recently seen innovative advancements in this field, including the use of automation and algorithms to provide appropriate educations materials to patients in a timely manner. These advancements help limit clinical workflow interruptions and demonstrate the use and promise of health IT to create efficiencies and improve patient care. As such, removal of this criterion would prevent certification from creating an unnecessary burden for developers and providers and an impediment to innovation.

d. CCDS Summary Record—Create; and CCDS Summary Record—Receive

We assessed the number of products certified to the 2015 Edition “Common Clinical Data Set summary record—create” (§ 170.315(b)(4)) and “Common Clinical Data Set summary record—receive” (§ 170.315(b)(5)) criteria that have not also been certified to the 2015 Edition “transitions of care” criterion (§ 170.315(b)(1)). We did this because the 2015 Edition “CCDS summary record” criteria include the same functionality as the 2015 Edition “transitions of care” criterion, except for Direct-related transport functionality. Based on our findings of only two unique products certified to these criteria at the time of the drafting of this proposed rule, there appears to be little market demand for certification to them. This outcome is likely attributable to the fact mentioned above regarding their relationship to the 2015 Edition “transition of care” criterion, that they are not included in the 2015 Edition Base EHR definition, and that no HHS program specifically requires the use of health IT certified to the criteria. Therefore, we propose to remove these certification criteria from the 2015 Edition.

e. Secure Messaging

We propose to remove the 2015 Edition “secure messaging” criterion (§ 170.315(e)(2)). ONC strongly supports patient and provider communication, as well as protecting the privacy and security of patient information. However, we no longer believe that separate certification focused on a health IT's ability to send and receive secure messages between health care providers and patients is necessary. First, this criterion would no longer be associated with an objective or measure under the Promoting Interoperability Programs based on proposals and determinations in recent CMS rulemakings (83 FR 41664; 83 FR 35929). Second, there are multiple other 2015 Edition certification criteria that support patient engagement, such as the 2015 Edition “view, download, and transmit to 3rd party,” “API,” and “patient health information capture” certification criteria. Third, we have seen developers integrate this functionality as part of other patient engagement features, such as patient portals. With these considerations in mind and the lack of a negative impact on health IT interoperability, we believe that the removal of this criterion will help reduce burden and costs, while also spurring further innovations in patient engagement.

5. Removal of Certain ONC Health IT Certification Program Requirements

We propose to remove certain mandatory disclosure requirements and a related attestation requirement under the Program. We believe removal of these requirements will reduce costs and burden for Program stakeholders, particularly health IT developers and ONC-ACBs. We welcome comment on the proposed removal of these requirements and any other certification or Program requirements we should consider for removal.

a. Limitations Disclosures

We propose to remove § 170.523(k)(1)(iii)(B), which requires ONC-ACBs to ensure that certified Start Printed Page 7438health IT includes a detailed description of all known material information concerning limitations that a user may encounter in the course of implementing and using the certified health IT, whether to meet “meaningful use” objectives and measures or to achieve any other use within the scope of the health IT's certification. We also propose to remove § 170.523(k)(1)(iv)(B) and (C), which state that the types of information required to be disclosed include, but are not limited to: (B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology's certification; or in connection with any data generated in the course of using any capability to which health IT is certified; (C) Limitations, including but not limited to technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified.

These disclosure requirements regarding certified health IT limitations are superseded by the Cures Act information blocking provision and Conditions of Certification, which we are implementing with this proposed rule. In particular, section 3001(c)(5)(D)(ii) of the Cures Act requires that a health IT developer, as a Condition of Certification under the Program, provide assurances to the Secretary that, unless for legitimate purposes specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of electronic health information. These assurances specifically focus on preventing information blocking and promoting appropriate exchange, access, and use of electronic health information. We further propose adding as a complementary Condition of Certification that developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification. Such actions may inhibit the appropriate access, exchange, or use of electronic health information and are therefore contrary to this proposed Condition of Certification and the statutory provision that it implements. Based on these Conditions of Certification, we believe that disclosures of limitations by health IT developers would be unlikely and unnecessary given their prohibition.

b. Transparency and Mandatory Disclosures Requirements

We propose to remove the Principle of Proper Conduct (PoPC) in § 170.523(k)(2), which requires a health IT developer to submit an attestation that it will disclose all of the information in its mandatory disclosures per § 170.523(k)(1) to specified parties (e.g., potential customers or anyone inquiring about a product quote or description of services). We propose that this provision is no longer necessary and that its removal is appropriate to further reduce administrative burden for health IT developers and ONC-ACBs. First, our experience with developer attestations to this requirement is that over 90% of developers with certified health IT have attested that they will provide “transparency information.” Second, the information that developers would be asked to attest to, whether our proposal above to remove certain disclosure requirements is finalized or not, is now readily available on health IT developers' websites as the mandatory disclosure requirements were implemented almost three years ago. Therefore, we believe removal of this requirement is appropriate.

6. Recognition of Food and Drug Administration Processes

Section 618 of the Food and Drug Administration Safety and Innovation Act (FDASIA), Public Law 112-144, required that the Food and Drug Administration (FDA), in consultation with ONC and the Federal Communications Commission (FCC) (collectively referred to as “the Agencies” [10] for this proposal), develop a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication. The FDASIA Health IT Report of April 2014 [11] contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT that promotes innovation, protects patient safety, and avoids regulatory duplication. Public comments, received prior to the report and after,[12] recommended that health IT developers/manufacturers apply a single process that satisfies the requirements of all agencies and that existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT. On July 27, 2017, FDA announced a voluntary Software Precertification (Pre-Cert) Pilot Program as part of a broader Digital Health Innovation Action Plan.[13] It was developed in order to create a tailored approach toward recognizing the unique characteristics of digital technology by looking first at the firm, rather than primarily at each product of the firm, as is currently done for traditional medical products. The FDA plans to explore whether and how pre-certified companies that have demonstrated a culture of quality, patient safety, and organizational excellence could bring certain types of digital health products to market either without FDA premarket review or with a more streamlined FDA premarket review.

a. FDA Software Pre-Certification Pilot Program

ONC believes that health IT developers that hold precertification under the FDA Digital Health Software Precertification Program (FDA Software Precertification Program) when they present health IT for certification under the Program could qualify for, and benefit from, further efficiencies under the Program. Title IV of the Cures Act provides ONC with authority under the Program to oversee health IT developers through Conditions and Maintenance of Certification requirements (see section VII Conditions and Maintenance of Certification of this proposed rule). With this new authority and our authority over health IT developers' health IT certified under the Program, we propose to establish processes that would provide health IT developers that can document holding precertification under the FDA Software Precertification Program with exemptions to the ONC Health IT Certification Program's requirements for testing and certification of its health IT to the 2015 Start Printed Page 7439Edition “quality management systems” criterion (§ 170.315(g)(4)) and the 2015 Edition “safety-enhanced design” criterion (§ 170.315(g)(3)), as these criteria are applicable to the health IT developer's health IT presented for certification. We also believe that such a “recognition” could, depending on the final framework of the FDA Software Precertification Program (e.g., the key performance indicators used to demonstrate performance and outcomes of excellence), be applicable to the functionally-based 2015 Edition “clinical” certification criteria (§ 170.315(a)). More specifically, this could address the “computerized provider order entry (CPOE)” (§ 170.315(a)(1), (2), and (3)), “drug-drug, drug-allergy interaction checks for CPOE” (§ 170.315(a)(4)), “clinical decision support” (§ 170.315(a)(9)), and “implantable device list” (§ 170.315(a)(14)) certification criteria. Such “recognition” could also be appropriate to address any or all of the following functionally-based 2015 Edition criteria in the event their proposed removal is not finalized: “problem list” (§ 170.315(a)(6)), “medication list” (§ 170.315(a)(7)), “medication allergy list” (§ 170.315(a)(8)), “drug-formulary and preferred drug list checks” (§ 170.315(a)(10)),” and “smoking status” (§ 170.315(a)(11)).

Our proposed “recognition” would align with both Executive Orders 13563 and 13771 regarding deregulatory, less burdensome, and more effective initiatives. It would also serve as a regulatory relief for those health IT developers qualifying as small businesses under the Regulatory Flexibility Act (see section XIV.C.3 Regulatory Flexibility Act of this proposed rule). Furthermore, it would closely align with FDASIA's instruction to promote innovation, protect patient safety, and avoid regulatory duplication. However, despite these proffered benefits, there may be reasons not to adopt such a “recognition” approach. For example, stakeholders may not agree that the FDA Software Precertification Program (and/or subsequent finalized program) sufficiently aligns with our Program. Developers and providers may have varying and divergent views about the benefits and detriments of such an approach. Further, while we believe that we could properly operationalize such an approach by ensuring certifications indicate which criteria have been “deemed certified” by ONC (but still subject to ONC-ACB surveillance), stakeholders may have other operational concerns. Accordingly, we welcome comments on these and other aspects of our proposed “recognition” approach, including the 2015 Edition certification criteria that should be eligible for “recognition.”

b. Development of Similar Independent Program Processes—Request for Information

Recognition of the FDA Software Pre-Certification Program for purposes of our Program, as noted above, may eventually be determined to be infeasible or insufficient to meet our goals of reducing burden and promoting innovation. With this in mind, we request comment on whether ONC should establish new regulatory processes tailored towards recognizing the unique characteristics of health IT (e.g., EHR software) by looking first at the health IT developer, rather than primarily at the health IT presented for certification, as is currently done under the Program. For example, ONC could possibly establish Conditions and Maintenance of Certification requirements, through rulemaking, that facilitate the deeming of all of a health IT developer's health IT as “certified” under the Program for certification criteria identified by ONC as solely “functionally-based” criteria (i.e., not essential to interoperability, such as the “CPOE” criteria) or possibly broader in scope. This approach could rely on, but not be limited to, one or a combination of the following: (1) Certain demonstrated health IT developer processes or health IT functionality; (2) prior successful certification of a health IT developer's health IT under the Program; (3) results of real world testing for interoperability as required by the Cures Act and the proposed implementing regulatory Condition of Certification (see section VII.B.5 of this proposed rule); and/or (4) the results of the EHR Reporting Program once implemented (see section VII.B.7 of this proposed rule). No matter the specifics, we are most interested in whether stakeholders believe this is an approach we should pursue in conjunction with, or in lieu of, the proposed approach of recognizing the FDA Software Pre-Certification Pilot Program. We also welcome more specific comments on the health IT developer criteria for such an approach and what the Conditions and/or Maintenance of Certification requirements should be to support such an approach within the framework of the proposed Conditions and Maintenance of Certification requirements discussed in section VII of this proposed rule.

IV. Updates to the 2015 Edition Certification Criteria

This rule proposes to update the 2015 Edition by revising and adding certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT. The updates to the 2015 Edition would enhance interoperability and improve the accessibility of patient records consistent with section 4006(a) of the Cures Act.

A. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A-119 [14] require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to electing only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency's regulatory, procurement or program needs, deliver favorable technical and economic outcomes, and are widely utilized in the marketplace. In this proposed rule, we use voluntary consensus standards except for:

  • The standard we propose to adopt in § 170.213. We propose to remove the Common Clinical Data Set (CCDS) definition and effectively replace it with a government Start Printed Page 7440unique standard, the United States Core Data for Interoperability (USCDI), Version 1(v1);
  • The standard we propose to adopt in § 170.215(a)(2). We propose the government unique API Resource Collection in Health (ARCH) Version 1 implementation specification;
  • The standards we propose to adopt in § 170.215(a)(3) through (5) for application programming interfaces (APIs). These market driven consortia standards have been developed through a streamlined process that does not meet the full definition of voluntary consensus standards development but still includes representation from those interested in the use cases supported by the standards (e.g., health IT developers and health care providers). In the absence of available voluntary consensus standards that would meet our needs, these standards deliver favorable technical and economic outcomes, particularly improved interoperability. Further, some of these standards may eventually proceed through a standards development organization for approval; and
  • The standards we propose to adopt in § 170.205(h)(3) and (k)(3). We propose to replace the current HL7 QRDA standards with government unique standards that more effectively support the associated certification criterion's use case, which is reporting eCQM data to CMS.

2. Compliance With Adopted Standards and Implementation Specifications

In accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow when we adopt proposed standards and/or implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and implementation specification includes the entire document unless we specify otherwise. For example, if we adopted the Argonaut Data Query Implementation Guide (IG) proposed in this proposed rule (see section VII.B.4.b), health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the IG.

3. “Reasonably Available” to Interested Parties

The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(a)). To comply with these requirements, in section XI (“Incorporation by Reference”) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of the proposed rule.

B. Revised and New 2015 Edition Criteria

In order to capture and share patient data efficiently, health care providers need health IT that store data in structured formats. Structured data allows health care providers to easily retrieve and transfer patient information, and use health IT in ways that can aid patient care. We propose to adopt revised and new 2015 Edition certification criteria, including new standards, to support these objectives. Some of these criteria and standards are included in the Certified EHR Technology (CEHRT) definition used for participation in HHS Programs, such as the Promoting Interoperability Programs (formerly the EHR Incentive Programs), some are required to be met for participation in the ONC Health IT Certification Program, and some, though beneficial, are unassociated with the CEHRT definition and not required for participating in any HHS program, including the ONC Health IT Certification Program.

1. The United States Core Data for Interoperability Standard (USCDI)

The initial focus of the Program was to support the Medicare and Medicaid EHR Incentive Programs (76 FR 1294) now referred to as the Promoting Interoperability Programs (and referenced as such hereafter). As such, the 2014 Edition certification criteria mirrored those functions specified by Promoting Interoperability Programs' objectives and measures. In order to improve efficiency and streamline the common data within our Program's certification criteria, we created a single definition for all the required data which could be referenced for all applicable certification criteria. We created the term “Common MU Data Set” to encompass the common set of MU data types/elements (and associated vocabulary standards) for which certification would be required across several certification criteria (77 FR 54170).

The 2015 Edition final rule modified the Program to make it open and accessible to more types of health IT, and health IT that supports various care and practice settings beyond those included in the Promoting Interoperability Programs (80 FR 62604). In comparison to the previous editions, the 2015 Edition focused on identifying health IT components necessary to establish an interoperable nationwide health information infrastructure, fostering innovation and open new market opportunities, and allowing for more health care provider and patient choices in electronic health information access and exchange. In order to align with this approach, we revised the concept of the “Common MU Data Set” definition and changed the name to the “Common Clinical Data Set” (CCDS) definition. The CCDS definition was further revised in the 2015 Edition rulemaking to account for new and updated vocabulary and content standards in order to improve and advance interoperability and health information exchange (80 FR 62604). It further expanded accessibility and availability of data exchanged by updating the definition of Base Electronic Health Record (EHR) (2015 Edition Base EHR definition) to include enhanced data export, transitions of care, and application programming interface (API) capabilities, all of which required that at a minimum the CCDS be available (80 FR 62602-62604).

The regulatory approach to use and reference a “definition” to identify electronic health information, including with associated vocabulary codes, for access, exchange and use has had its drawbacks. While the CCDS definition served its designed purpose, to cut down on repetitive text in each of the certification criteria in which it is referenced, it also began to be colloquially used for many different purposes. As the CCDS definition's relevance grew outside of its regulatory context it became a symbolic and practical limit to the industry's collective interests to go beyond the CCDS data for access, exchange, and use. As we move towards value-based care and the inclusion of data classes that go beyond clinical data, and as part of ONC's continued efforts to evaluate the availability of a minimum baseline of data classes that must be commonly available for interoperable exchange, we acknowledge the need to change and improve our regulatory approach to the CCDS. Therefore, in order to advance interoperability by ensuring compliance with new data and vocabulary codes Start Printed Page 7441sets that support the data, we propose to remove the “Common Clinical Data Set” definition and its references from the 2015 Edition and replace it with the “United States Core Data for Interoperability” (USCDI) standard. The USCDI standard aims to achieve the goals set forth in the Cures Act by specifying a common set of data classes for interoperable exchange.

We propose to adopt the USCDI as a standard as such term is defined in § 170.102. In § 170.102, a “standard” is defined as a “technical, functional, or performance-based rule, condition, requirement, or specification that stipulates instructions, fields, codes, data, materials, characteristics, or actions.” The USCDI standard would comprise data classes, which may be further delineated into groupings of specific data element(s). For example, “patient demographics” is a data class and within that data class there is “patient name,” which is a data element. As noted in section IV.B.1.b, for the overall structure and organization of the USCDI, please consult www.healthIT.gov/​USCDI.

ONC intends to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. Once the Secretary adopts the first version of the USCDI through rulemaking, which we propose in this rulemaking, health IT developers would be allowed to take advantage of the “Standards Version Advancement Process” flexibility. The Standards Version Advancement Process, proposed in Section VII.B.5 (below), would permit health IT developers to voluntarily implement and use a new version of an adopted standard (e.g., the USCDI), subject to certain conditions including a requirement that the new version is approved for use by the National Coordinator.

a. USCDI 2015 Edition Certification Criteria

We propose to adopt the USCDI Version 1 (USCDI v1) in § 170.213.[15] The USCDI is a standardized set of health data classes and constituent data elements that would be required to support nationwide electronic health information exchange. Once adopted in a final rule, health IT developers would be required to update their certified health IT to support the USCDI v1 for all certification criteria affected by this proposed change. We propose to revise the following CCDS dependent 2015 Edition certification criteria to incorporate the USCDI standard:

  • “Transitions of care” (§ 170.315(b)(1));
  • “view, download, and transmit to 3rd party” (§ 170.315(e)(1));
  • “consolidated CDA creation performance” (§ 170.315(g)(6));
  • “transmission to public health agencies—electronic case reporting” (§ 170.315(f)(5)); and
  • “application access—all data request” (§ 170.315(g)(9)).

We note that we did not include the “data export” criterion (§ 170.315(b)(6)) as we are proposing to remove it and adopt instead the “EHI export” criterion (§ 170.315(b)(10)). For similar reasons, we did not include the “application access—data category request” criterion (§ 170.315(g)(8)) because we are proposing to replace it with the API certification criterion (§ 170.315(g)(10)), which derives its data requirements from the USCDI.

We propose, as a Maintenance of Certification requirement for the real world testing Condition of Certification, that health IT developers with health IT certified to the five above-identified certification criteria prior to the effective date of a subsequent final rule would have to update such certified health IT to the proposed revisions. We further propose, as a Maintenance of Certification requirement for the real world testing Condition of Certification, that health IT developers must provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of a final rule for this proposed rule. For the purposes of meeting this compliance timeline, we expect health IT developers to update their certified health IT without new mandatory testing and notify their ONC-ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of this proposed rule. Further, we refer health IT developer to the next section, which describes how the USCDI differs from the current CCDS.

b. USCDI Standard—Data Classes Included

The USCDI Version 1 (USCDI v1) and its constituent data elements account for the public comments we received on the Draft USCDI and Proposed Expansion Process[16] published in January 2018 as well as initial feedback from the Health IT Advisory Committee. The standard as we propose to adopt it in § 170.213 also reflects and acknowledges the burden that rapidly expanding the USCDI v1 beyond the CCDS could cause. As a result, the USCDI v1 is a modest expansion of the CCDS, which we believe most health IT developers already support, were already working toward, or should be capable of updating their health IT to support in a timely manner. The following describes only the delta between the CCDS and the USCDI v1. For the overall structure and organization of the USCDI standard, please consult www.healthIT.gov/​USCDI.

i. Updated Versions of Vocabulary Standard Code Sets

We propose that the USCDI Version 1 (USCDI v1) include the newest versions of the “minimum standard” code sets included in the CCDS available at publication of a subsequent final rule. We request comment on this proposal and on whether this could result in any interoperability concerns. To note, criteria such as the 2015 Edition “family health history” criterion (§ 170.315(a)(12)), the 2015 Edition “transmission to immunization registries” criterion (§ 170.315(f)(1)), and the 2015 Edition “transmission to public health agencies—syndromic surveillance” criterion (§ 170.315(f)(2)) reference “minimum standard” code sets; however, we are considering changing the certification baseline versions of the code set for these criteria from the versions adopted in the 2015 Edition final rule to ensure complete interoperability alignment. We welcome comment on whether we should adopt such an approach.

We also note, for purposes of clarity, that consistent with § 170.555, unless the Secretary prohibits the use of a newer version of an identified minimum standard code set for certification, health IT could continue to be certified or upgraded to a newer version of an identified minimum standard code set than that included in USCDI v1 or the most recent USCDI version that the National Coordinator has approved for use in the Program via the Standards Version Advancement Process.

ii. Address and Phone Number

The USCDI v1 includes new data elements for “address” and “phone number.” The inclusion of “address” (to represent the postal location for the Start Printed Page 7442patient) and “phone number” (to represent the patient's telephone number) would improve the comprehensiveness of health information for patient care. The inclusion of these data elements is also consistent with the list of patient matching data elements already specified in the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)(iii)(G)), which supports the exchange of patient health information between providers of patient care.

iii. Pediatric Vital Signs

The USCDI v1 includes the pediatric vital sign data elements, which are specified as optional health information in the 2015 Edition CCDS definition. Pediatric vital signs include: Head occipital-frontal circumference for children less than 3 years of age, BMI percentile per age and sex for youth 2-20 years of age, weight for age per length and sex for children less than 3 years of age, and the reference range/scale or growth curve, as appropriate. As explained in section VI.A.2 of this proposed rule, the inclusion of pediatric vital sign data elements in the draft USCDI v1 would align with the provisions of the Cures Act related to health IT to support the health care of children. Stakeholders emphasized the value of pediatric vital sign data elements to better support the safety and quality of care delivered to children. We also note that, as discussed in the 2015 Edition proposed rule, the Centers for Disease Control and Prevention (CDC) recommends the use of these pediatric vital signs for settings of care in which pediatric and adolescent patients are seen (80 FR 16818-16819) as part of best practices. The availability of a reference range/scale or growth curve would help with proper interpretation of the measurements for the BMI percentile per age and sex and weight for age per length and sex. Further, the inclusion of this health information in the USCDI v1 is the appropriate next step after first specifying them as optional in the CCDS definition as part of the 2015 Edition rulemaking and as a means of supporting patient access to their EHI in a longitudinal format through certified health IT (see section 3009(e)(2)(A)(i) of the PHSA as amended by the Cures Act). We recognize, however, that certain health IT developers and their customers may not find these capabilities and information useful. Therefore, we request comment on the inclusion of pediatric vital signs in the USCDI v1, including the potential benefits and costs for all stakeholders stemming from its inclusion in the USCDI v1.

iv. Clinical Notes

The USCDI v1 includes a new data class, titled “clinical notes.” “Clinical notes” is included in the USCDI v1 based on significant feedback from the industry since the 2015 Edition final rule. We also received feedback during the Trusted Exchange Framework and Common Agreement (TEFCA) stakeholder sessions and public comment period. It has been identified by stakeholders as highly desirable data for interoperable exchange. The free text portion of the clinical notes was most often relayed by clinicians as the data they sought, but were often missing during electronic health information exchange. Clinical notes can be composed of text generated from structured (pick-list and/or check the box) fields as well as unstructured (free text) data. A clinical note may include the assessment, diagnosis, plan of care and evaluation of plan, patient teaching, and other relevant data points.

We recognize that a number of different clinical notes could be useful for stakeholders. It is our understanding that work is being done in the community to focus on a subset of clinical notes. We considered three options for identifying the different “note types” to adopt in USCDI v1. The first option we considered would allow for the community to offer any and all recommended notes. The second option we considered would set a minimum standard of eight note types. This option was derived from the eight note types identified by the Argonaut Project participants.[17] The third option we identified would look to the eleven HL7 Consolidated Clinical Data Architecture (C-CDA) document types identified in the C-CDA Release 2.1, which also included the note types being identified by the Argonaut Project participants. We ultimately decided to move forward with the second option because it unites public and private interests toward the same goal. The eight selected note types are a minimum bar and, in the future, the USCDI may be updated to include other clinical notes. Specifically, we propose to include the following clinical note types for both inpatient and outpatient (primary care, emergency department, etc.) settings in USCDI v1 as a minimum standard: (1) Discharge Summary note; (2) History & Physical; (3) Progress Note; (4) Consultation Note; (5) Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology Report Narrative; and (8) Procedures Note. We seek comment on whether to include additional note types as part of the USCDI v1.

v. Provenance

The USCDI v1 also includes a new data class, titled “provenance.” “Provenance” has been identified by stakeholders [18] as valuable for interoperable exchange. The provenance of data was also referenced by stakeholders as a fundamental need to improve the trustworthiness and reliability of the data being exchanged. Provenance describes the metadata, or extra information about data, that can help answer questions such as when and who created the data.

The inclusion of “provenance” as a data class in the USCDI v1 would also complement the Cures Act requirement to support the exchange of data through the use of APIs. This approach differs from the exchange of data via the C-CDA. While C-CDAs are often critiqued due to their relative “length,” the C-CDA represents the output of a clinical encounter and includes relevant context. The same will not always be true in an API context. APIs facilitate the granular exchange of data and, as noted in the 2015 Edition final rule, offer the potential to aggregate data from multiple sources in a web or mobile application (80 FR 62675). The inclusion of provenance would help retain the relevant context so the recipient can better understand the origin of the data. As noted in section VII.B.4, we are also proposing to include provenance in our proposed “API Resource Collection in Health” (ARCH) Version 1 implementation specification in § 170.215(a)(2), which would list a set of base Fast Healthcare Interoperability Resources (FHIR®) resources that Health IT Modules certified to the proposed API criterion (§ 170.315(g)(10)) would need to support.

We propose to further delineate the provenance data class into three data elements: “the author,” which represents the person(s) who is responsible for the information; “the author's time stamp,” which indicates the time the information was recorded; and “the author's organization,” which would be the organization the author is associated with at the time they interacted with the data. We have identified these three data elements as fundamental for data recipients to have Start Printed Page 7443available and both are commonly captured and currently available through standards. We request comment on the inclusion of these three data elements and whether any other provenance data elements, such as the identity of the individual or entity the data was obtained from or sent by (sometimes discussed in standards working groups as the provenance of the data's “last hop”), would be essential to include as part of the USCDI v1 standard. We acknowledge that there is currently work to help define provenance in a standard robust manner, and we anticipate adopting the industry consensus once it becomes available.

vi. Unique Device Identifier(s) for a Patient's Implantable Device(s)

We are aware of a recently published implementation guide (IG) within HL7 that provides further guidance on the unique device identifier (UDI) requirements. The IG, Health Level 7 (HL7®) CDA R2 Implementation Guide: C-CDA Supplemental Templates for Unique Device Identification (UDI) for Implantable Medical Devices, Release 1-US Realm,[19] identifies changes needed to the C-CDA to better facilitate the exchange of the individual UDI components in the health care system when devices are implanted in a patient. The UDI components include the Device Identifier (DI) and the following individual production identifiers: The lot or batch number, serial number, manufacturing date, expiration date, and distinct identification code. However, as this new IG has been recently published, we request comment on whether we should add this UDI IG as a requirement for health IT to adopt in order to meet the requirements for UDI USCDI Data Class. In addition, we do not have a reliable basis on which to estimate how much it would cost to meet the requirements outlined in the UDI IG; and, therefore, we request comment on the cost and burden of complying with this proposed requirement.

vii. Medication Data Request for Comment

The USCDI v1 “Medication” data class includes two constituent data elements within it: Medications and Medication Allergies. With respect to the latter, Medication Allergies, we request comment on an alternative approach. This alternative would result in removing the Medication Allergies data element from the Medication data class and creating a new data class titled, “Substance Reactions,” which would be meant to be inclusive of “Medication Allergies.” The new “Substance Reactions” data class would include the following data elements: “Substance” and “Reaction,” and include SNOMED CT as an additional applicable standard for non-medication substances.

c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications

In order to align with our approach to be responsive to the evolution of standards and to facilitate updates to newer versions of standards, the USCDI v1 (§ 170.213) is “content exchange” standard agnostic. It establishes “data policy” and does not directly associate with the content exchange standards and implementation specifications which, given a particular context, may be necessary to exchange the entire USCDI, a USCDI class, or elements within it. To our knowledge, all data classes in the USCDI v1 can be supported by commonly used “content exchange” standards, including HL7 C-CDA Release 2.1 and FHIR®.

d. Clinical Notes C-CDA Implementation Specification

In conjunction with our proposal to adopt the USCDI v1, we propose to adopt the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1 in § 170.205(a)(4)(i) (“C-CDA Companion Guide”). The C-CDA Companion Guide provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1.[20] As noted above, the proposed USCDI v1 includes new data classes, such as “clinical notes,” which are further supported through the C-CDA Companion Guide. For example, the C-CDA Companion Guide provides specifications for clinical notes by indicating that clinical notes should be recorded in “note activity” and requires references to other discrete data, such as “encounters.” The C-CDA Companion Guide also enhances implementation of the 2015 Edition certification criteria that reference the C-CDA Release 2.1 (§ 170.205(a)(4)). As noted by stakeholders, the C-CDA Release 2.1 includes some optionality and ambiguity with respect to data element components, such as the locations and value sets. We attempted to address some of this optionality by clarifying requirements using Certification Companion Guides (CCGs) [21] and by specifying in the CCDS definition where certain data should be placed in the C-CDA Release 2.1 templates (e.g., “goals” in the goals section).[22] The C-CDA Companion Guide, which was released after the 2015 Edition final rule, provides similar, but additional C-CDA implementation structure. For example, race and ethnicity are required data elements in the USCDI (formerly the CCDS) and must be included in C-CDA exchanges if known, or they may be marked with a nullFlavor of UNK (unknown) if not known. The C-CDA Release 2.1 is unclear on the location and value set, but the C-CDA Companion Guide clarifies the location and value set. The adoption of the C-CDA Companion Guide would align with our goal to increase the consistent implementation of standards among health IT developers and improve interoperability. We propose to adopt this C-CDA Companion Guide to support best practice implementation of USCDI v1 data classes and 2015 Edition certification criteria that reference C-CDA Release 2.1 (§ 170.205(a)(4)). The criteria include:

  • “Transitions of care” (§ 170.315(b)(1));
  • “clinical information reconciliation and incorporation” (§ 170.315(b)(2));
  • “care plan” (§ 170.315(b)(9));
  • “view, download, and transmit to 3rd party” (§ 170.315(e)(1));
  • “consolidated CDA creation performance” (§ 170.315(g)(6)); and
  • “application access—all data request” (§ 170.315(g)(9)).

We propose, as a Maintenance of Certification requirement for the real world testing Condition of Certification, that health IT developers with health IT certified to the six above-identified certification criteria prior to the effective date of a subsequent final rule would have to update such certified health IT to the proposed revisions. We further propose, as a Maintenance of Certification requirement for the real world testing Condition of Certification, that health IT developers must provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of a final rule for this proposed rule. For the purposes of meeting this compliance timeline, we expect health IT developers to update their certified health IT without new mandatory testing and notify their Start Printed Page 7444ONC-ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of this proposed rule.

2. Electronic Prescribing Standard and Certification Criterion

We propose to update the electronic prescribing (e-Rx) SCRIPT standard used for “electronic prescribing” in the 2015 Edition to NCPDP SCRIPT 2017071, which would result in a new e-Rx standard becoming the baseline for certification. We propose to adopt this standard in § 170.205(b)(1). ONC and CMS have historically maintained complementary policies of aligning health IT certification criteria and associated standard for e-prescribing with the CMS Medicare Part D e-Rx and MH standards (75 FR 44589; 77 FR 54198). To this end, CMS has retired the current standard (NCPDP SCRIPT version 10.6) for e-RX and MH and adopted NCPDP SCRIPT 2017071 as the standard for Part D e-Rx and MH effective January 1, 2020, conditional on ONC updating the Program to the NCPDP SCRIPT 2017071 standard for its e-Rx certification criterion (see also 42 CFR 423.160(b)(1)(v) and (2)(iv)). In addition, CMS recently sought comment regarding whether the NCPDP SCRIPT 2017071 standard could facilitate future reporting of the proposed Query of Prescription Drug Monitoring Program (PDMP) measure in both the 2019 Physician Fee Schedule proposed rule (83 FR 35923) and Hospital Inpatient Prospective Payment Systems (IPPS) Fiscal Year 2019 proposed rule (83 FR 20528).

As summarized in the IPPS Fiscal Year 2019 final rule (83 FR 41144), CMS received comments supportive of using the NCPDP SCRIPT 2017071 medication history transactions for PDMP queries and responses, as well as comments asking CMS to seek harmonizing of the 2015 Edition e-prescribing certification criterion to the NCPDP SCRIPT 2017071 standard specified in the part D program portions of the recent “Medicare Program; Contract Year 2019 Policy and Technical Changes to the Medicare Advantage, Medicare Cost Plan, Medicare Fee-for-Service, the Medicare Prescription Drug Benefit Programs, and the PACE Program” final rule (83 FR 16440).

In addition to proposing to adopt the NCPDP SCRIPT 2017071 standard for the transactions that are listed in the current “electronic prescribing” criterion (§ 170.315(b)(3)), we propose to adopt and require conformance to all of the NCPDP SCRIPT 2017071 standard transactions CMS adopted at 42 CFR 423.160(b)(2)(iv) for NCPDP SCRIPT 2017071. Therefore, we propose to adopt a new 2015 Edition “electronic prescribing” criterion (§ 170.315(b)(11)) that includes the following transactions:

  • Create new prescriptions (NewRx, NewRxRequest, NewRxResponseDenied)

A NewRx transaction is a new prescription from a prescriber to a pharmacy so that it can be dispensed to a patient. A NewRxRequest is a request from a pharmacy to a prescriber for a new prescription for a patient. A NewRxResponseDenied is a denied response to a previously sent NewRxRequest (if approved, a NewRx would be sent). A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable.

  • Change prescriptions (RxChangeRequest, RxChangeResponse)

An RxChangeRequest transaction originates from a pharmacy to request: A change in the original prescription (new or fillable), validation of prescriber credentials, a prescriber to review the drug requested, or a prior authorization from the payer for the prescription. An RxChangeResponse transaction originates from a prescriber to respond: To a prescription change request from a pharmacy, to a request for a prior authorization from a pharmacy, or to a prescriber credential validation request from a pharmacy.

  • Cancel prescriptions (CancelRx, CancelRxResponse)

A CancelRx transaction is a request from a prescriber to a pharmacy to not fill a previously sent prescription. A CancelRx must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage, form), prescriber, prescription number if available). A CancelRxResponse is a response from a pharmacy to a prescriber to acknowledge a CancelRx, and is used to denote if the cancellation is Approved or Denied.

  • Renew prescriptions (RxRenewalRequest, RxRenewalResponse)

An RxRenewalRequest transaction originates from a pharmacy to request additional refills beyond those originally prescribed. RxRenewalResponse originates from a prescriber to respond to the request.

  • Receive fill status notifications (RxFill, RxFillIndicatorChange)

An RxFill transaction is sent from a pharmacy to a prescriber or a long term or post-acute care (LTPAC) facility indicating the FillStatus (dispensed, partially dispensed, not dispensed or returned to stock, transferred to another pharmacy) of the new, refill, or resupply prescriptions for a patient. RxFillIndicator informs the pharmacy of the prescriber's intent for fill status notifications for a specific patient/medication. An RxFillIndicatorChange is sent by a prescriber to a pharmacy to indicate that the prescriber is changing the types of RxFill transactions that were previously requested, where the prescriber may modify the fill status of transactions previously selected or cancel future RxFill transactions.

  • Request and receive medication history (RxHistoryRequest, RxHistoryResponse)

An RxHistoryRequest transaction is a request from a prescriber for a list of medications that have been prescribed, dispensed, claimed, or indicated by a patient. This request could be sent to a state Prescription Drug Monitoring Program (PDMP). An RxHistoryResponse is a response to an RxHistoryRequest containing a patient's medication history. It includes the medications that were dispensed or obtained within a certain timeframe, and optionally includes the prescriber that prescribed it. RxHistoryRequest and RxHistoryResponse transactions may be sent directly or through an intermediary.

  • Ask the Mailbox if there are any transactions (GetMessage)

This transaction is used by the prescriber or pharmacy asking the mailbox if there are any transactions. It is at the heart of the mechanism used by a pharmacy or prescriber system to receive transactions from each other or from a payer or the REMS Administrator via a Switch, acting as a Mailbox.

  • Relay acceptance of a transaction back to the sender (Status)

This transaction is used to relay acceptance of a transaction back to the sender. A Status in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status in response to GetMessage indicates that no mail is waiting for pickup. A Status cannot be mailboxed and may not contain an error.

  • Respond that there was a problem with the transaction (Error)

This transaction indicates an error has occurred, indicating the request was Start Printed Page 7445terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An error can be mailboxed, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the Mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, and the Status signifies no more mail.

  • Respond that a transaction requesting a return receipt has been received (Verify)

This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications results when a “return receipt requested” flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended) or generate a Status in response to this request, followed subsequently by a free standing Verify. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate answer to the transaction may take place.

  • Request to send an additional supply of medication (Resupply)

This transaction is a request from a Long Term or Post-Acute Care (LTPAC) organization to a pharmacy to send an additional supply of medication for an existing order. An example use case is when a medication supply for a resident is running low (2-3 doses) and a new supply is needed from the pharmacy, the LTPAC organization need a way to notify the pharmacy that an additional supply for the medication is needed.

  • Communicate drug administration events (DrugAdministration)

This transaction communicates drug administration events from a prescriber/care facility to the pharmacy or other entity. It is a notification from a prescriber/care facility to a pharmacy or other entity that a drug administration event has occurred—for example, a medication was suspended or administration was resumed.

  • Transfer one or more prescriptions (RxTransferRequest, RxTransferResponse, RxTransferConfirm)

The RxTransferRequest transaction is used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy. The RxTransferResponse transaction is the response to the RxTransferRequest which includes the prescription(s) being transferred or a rejection of the transfer request. It is sent from the transferring pharmacy to the requesting pharmacy. The RxTransferConfirm transaction is used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete.

  • Recertify the continued administration of a medication order (Recertification)

This transaction is a notification from a facility, on behalf of a prescriber, to a pharmacy recertifying the continued administration of a medication order. An example use is when an existing medication order has been recertified by the prescriber for continued use. Long term or post-acute care use only.

  • Complete Risk Evaluation and Mitigation Strategy (REMS) Transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse)

With CMS' recent adoption of these transactions in their recently issued final rule associated with e-prescribing for Medicare Part D (42 CFR 423.160(b)(2)(iv)(W)-(Z)), we believe that it would be equally beneficial to include these four REMS transactions as part of this proposed certification criterion: REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse.

The Food and Drug Administration Amendments Act (FDAAA) of 2007 (Pub. L. 110-85) enables the Food and Drug Administration (FDA) to require a REMS from a pharmaceutical manufacturer if the FDA determines that a REMS is necessary to ensure the benefits of a drug outweigh the risks associated with the drug. The currently approved REMS programs vary in levels of complexity. Typically a Med Guide and Communication Plan is required, but some also require Elements to Assure Safe Use (ETASU). The large majority of existing REMS programs are for drugs dispensed through specialty pharmacies, clinics, and hospitals, but as REMS become more common they may ultimately have a greater impact on retail-based products.

The impact of REMS is twofold. First, REMS with ETASU may require the pharmacist to verify prescriber, patient, and/or pharmacy enrollment in a registry and, in some cases, verify or check certain information, such as lab results. Second, all REMS, including those without ETASU, must fulfill FDA-approved reporting requirements. Each REMS program must also include a program assessment schedule that examines the program's effectiveness on intervals approved by the FDA as part of the overall REMS program. The results of these assessments are submitted to the FDA as part of the ongoing evaluation of REMS program effectiveness. Accordingly, we propose to include the REMS transactions as part of this proposed certification criterion. We would also note for commenters' benefit that the SCRIPT 2017071 testing tool under development is being designed to support testing these REMS transactions.

We believe that removing the 2015 Edition certification criterion (codified in § 170.315(b)(3)) that references NCPDP SCRIPT version 10.6 and replacing it with an updated e-prescribing criterion (proposed to be codified in § 170.315(b)(11)) would harmonize with relevant CMS program timelines, including Part D e-prescribing requirements and the option for eligible clinicians, hospitals, and CAHs to report on the Query of Prescription Drug Monitoring Program (PDMP) quality measure for Promoting Interoperability Programs. However, should our proposal to adopt the new e-prescribing criterion (§ 170.315(b)(11)) be finalized prior to January 1, 2020, we also propose to permit continued certification to the current 2015 Edition “electronic prescribing” criterion (§ 170.315(b)(3)) for the period of time in which it would continue to be used as a program standard in the CMS Medicare Part D Program or the CMS Promoting Interoperability Programs. Once it is no longer used in those Programs, we would no longer permit certification to that criterion and would remove it from the Code of Federal Regulations. We will consider setting an effective date for such actions in a subsequent final rule based on stakeholder feedback and CMS policies at the time. To this point, we note that the continued acceptability of a Health IT Module certified to the criterion codified in § 170.315(b)(3) for purposes of meeting the CEHRT definition and participating in the CMS Promoting Interoperability Programs would be a matter of CMS policy.

3. Clinical Quality Measures—Report Criterion

In the 2015 Edition final rule, ONC adopted four clinical quality measure (CQM) certification criteria, § 170.315(c)(1) CQMs—record and Start Printed Page 7446export, § 170.315(c)(2) CQMs—import and calculate, § 170.315(c)(3) CQMs—report, and § 170.315(c)(4) CQMs—filter (80 FR 62649-62655). These four criteria were adopted with the intent to support providers' quality improvement activities and in electronically generating CQM reports for reporting with certified health IT to programs such as the EHR Incentive Programs, Quality Payment Program, and Comprehensive Primary Care plus initiative. All four CQM criteria require certified health IT to be capable of generating CQM reports using the HL7 Quality Reporting Document Architecture (QRDA) Category I standard, which provides CQM reports for individual patients. Specifically, we adopted HL7 CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture—Category I (QRDA I); Release 1, Draft Standard for Trial Use (DSTU) Release 3 (US Realm)), Volume 1 (§ 170.205(h)(2)). Two of the CQM criteria, CQMs—report (§ 170.315(c)(3)) and CQMs—filter (§ 170.315(c)(4)), also require certified health IT to be capable of generating CQM reports using the QRDA Category III standard, which provides aggregate CQM reports for a set of patients. More specifically, we adopted QRDA Category III, Implementation Guide for CDA Release 2 (§ 170.205(k)(1)) and the Errata to the HL7 Implementation Guide for CDA® Release 2: QRDA Category III, DSTU Release 1 (US Realm), September 2014 (§ 170.205(k)(2)).

The “CQMs—report” certification criterion (§ 170.315(c)(3)) includes an optional certification provision for demonstrating that the health IT can create QRDA reports in the form and manner required for submission to CMS programs, which is in accordance with CMS' QRDA Implementation Guide (IGs).[23] The CMS QRDA IGs include specific requirements to support providers participating in CMS programs in addition to the HL7 IGs. At the time of the finalization of the 2015 Edition final rule and in response to public comment, we noted that there was mixed feedback on whether this criterion should require adherence to the HL7 QRDA Category I and Category III standards or solely to the CMS QRDA IGs. As such, we adopted an approach that allowed for flexibility and only required that certified health IT support the HL7 QRDA standards, which are program-agnostic and can support a number of use cases for exchanging CQM data. Because the criterion has the optional provision for CMS program- specific certification, developers can also support their end-users who intend to use their certified health IT to report eCQMs to CMS in the “form and manner” CMS requires (i.e., using the format specified in the CMS QRDA IGs) (80 FR 62652).

Since the 2015 Edition final rule was published (October 16, 2015), we have gained additional certification experience and received feedback from the industry that health IT certified to the “CQMs-report” criterion (§ 170.315(c)(3)) are only/primarily being used to submit eCQMs to CMS for participation in CMS programs. Therefore, as a means of reducing burden, we propose to remove the HL7 QRDA standard requirements from the 2015 Edition CQMs—report criterion in § 170.315(c)(3), but require that health IT certified to the criterion support the CMS QRDA IGs. This would directly reduce burden on health IT developers and indirectly providers as they would no longer have to, in practice, develop (health IT developers) and support (both developers and providers) two forms of the QRDA standard (i.e., the HL7 and CMS forms). We note that the Fast Health Interoperability Resources (FHIR) standard offers the potential for supporting quality improvement and reporting needs and promises to be a more efficient, modular, and interoperable standard to develop, implement, and utilize through APIs. However, until the potential benefits of FHIR APIs can be realized for quality improvement and reporting, we believe that solely requiring the CMS QRDA IGs for the “CQMs—report” criterion balances the burden to developers and providers, while still meeting the goal of facilitating quality improvement and reporting to CMS.

To support the proposal, we propose to incorporate by reference the latest annual CMS QRDA IGs, specifically the 2019 CMS QRDA I Implementation Guide for Hospital Quality Reporting [24] and the 2019 CMS QRDA III Implementation Guide for Eligible Professionals (EPs) and Eligible Clinicians.[25] A Health IT Module would need to be certified to both standards to provide flexibility to providers. However, we solicit comment on whether we should consider an approach that permits certification to only one of the standards depending on the care setting for which the product is designed and implemented. We also solicit comment on the future possibility of FHIR-enabled APIs replacing or complementing QRDA reports for quality reporting and improvement.

If we finalize this proposal in a subsequent final rule, we propose to adopt the latest CMS QRDA IGs at the time of final rule publication, as CMS updates their QRDA IGs annually to support the latest eCQM specifications and only accepts eCQM reporting to the latest version.

We note that this approach would also facilitate a means for ONC to permit developers to update its certified health IT to newer versions of the CMS QRDA IGs through the real world testing Maintenance of Certification provision for standards and implementation specification updates in support of ongoing interoperability (see section VII.B.5 of this proposed rule).

4. Electronic Health Information Export

We propose to adopt a new 2015 Edition certification criterion for EHI export in § 170.315(b)(10). This criterion is intended to provide patients and health IT users with a means to efficiently export the entire electronic health record for a single patient or all patients in a computable, electronic format, and facilitate the receiving health IT system's interpretation and use of the EHI, to the extent reasonably practicable using the developer's existing technology.

This outcome would promote access, exchange, and use of EHI and facilitate health care providers' ability to switch health IT systems or to migrate EHI for use in other technologies. Additionally, as discussed in section VII.B.2 of this preamble, certification to this criterion would provide some degree of assurance that a health IT developer supports, and does not inhibit, the access, exchange, and use of EHI for the specific use cases that the criterion addresses.

This proposed criterion supports two specific use cases for which we believe that all EHI produced and electronically managed in a developer's technology should be made readily available for export as a standard capability of certified health IT.

First, we propose that health IT certified to this criterion would have to enable the export of EHI for a single patient upon a valid request from that patient or a user on the patient's behalf. This patient-focused export capability, which is discussed in more detail below, complements other provisions of this proposed rule that support patients' access to their EHI including information that may eventually be Start Printed Page 7447accessible via the APIs described in section VII.B.4 of this preamble. Ultimately, we expect all data to be transferred through APIs or other advanced technologies. EHI export also supports longitudinal data record development, and aligns with section 4006(a) of the Cures Act, which requires [t]he Secretary, in consultation with the National Coordinator, [to] promote policies that ensure that a patient's EHI is accessible to that patient and the patient's designees, in a manner that facilitates communication with the patient's health care providers and other individuals, including researchers, consistent with such patient's consent.

Second, this criterion would support the export of EHI when a health care provider chooses to transition or migrate information to another health IT system. As discussed in section VIII.C.5.c.iii of this preamble, health IT developers are in a unique position to block the export and portability of data for use in competing systems or applications, or to charge rents for access to the basic technical information needed to facilitate the conversion or migration of data for these purposes. By providing at least a baseline capability for exporting EHI in a commercially reasonable format, we believe that this criterion would help to address some of these business practices and enable smoother transitions between health IT systems.

This criterion is intended to further the two use cases outlined above while providing an incremental approach given the known and anticipated health IT landscape when ONC expects certified health IT with this functionality will be widely available in the ecosystem. At the time of this rulemaking, we believe a focused certification criterion that is standards-agnostic will provide a useful first step to enabling patients to request and receive their EHI and for providers to more readily switch or migrate information between health IT systems. Understanding that open, standards-based APIs are an emerging technology and that some health IT developers today have implemented proprietary APIs, this proposed criterion for EHI export provides an initial method for exporting patient health information in these circumstances. Over time, ONC may consider expanding the proposed criterion or replacing it to achieve the goals in § 170.402. It is also possible that in the future, this criterion will no longer be needed once standards-based APIs are widely available in the health IT ecosystem with the ability to facilitate exchange of a wider set of standardized data elements per the predictable, transparent, and collaborative process to expand the USCDI (see the discussion of the API Condition of Certification and the proposed API criterion in § 170.315(g)(10) in VII.B.4 for additional information).

a. Patient Access

As noted above, the export functionality required by this certification criterion would support both a patient's access to their EHI and a provider's ability to switch to another health IT system. In the patient access context, we propose that a user must be able to timely execute the single patient EHI export at any time the user chooses and without subsequent developer assistance to operate. The health IT developer should enable the user to make data requests and receive the export efficiently, without unreasonable burden. For example, the health IT developer should not: Require the user to make a request multiple times for different types of EHI; provide unreasonable delays for the export; or prohibit reasonable user access to the system during the export process.

“Timely” does not mean real-time; however, we stress that any delays in providing the export must be no longer than reasonably necessary to avoid interference with other clinical functions of the health IT system. This is similar to the approach we have taken for export of clinical quality measure data. The export capability does not require that data be received instantaneously. Rather, as we have stated before (80 FR 62650) a non-conformity would exist if surveillance revealed that processing or other delays were likely to substantially interfere with the ability of a provider or health system to view and verify their CQM results for quality improvement on a near real-time basis. Similarly, a non-conformity would exist if delays were causing or contributing to users being presented with data files that no longer contained current, accurate, or valid data. To avoid these implementation issues and ensure that capabilities support all required outcomes, health IT developers should seek to minimize processing times and other delays to the greatest extent possible.[26]

As previously defined under the Program, “user” is a health care professional or his or her office staff; or a software program or service that would interact directly with the certified health IT (80 FR 62611, 77 FR 54168). We typically would expect the “user” in this case to be a provider or his or her office staff who will be performing the request on behalf of the patient given that a request of this nature would likely occur in the context of an individual exercising their right of access under the HIPAA Privacy Rule (45 CFR 164.524). In this regard, the proposed 2015 Edition “EHI export” criterion could facilitate and support the provision of a patient's record in an electronic format. In service to innovative and patient-centric approaches, a health IT developer could develop a method that allows the patient using a technology application (e.g., portal or “app”) to execute the request without needing a provider to do so on their behalf. We seek comment on whether this portion of the criterion should be made more prescriptive to only allow the patient and his or her authorized representative to be the requestor of their EHI, similar to how we have previously scoped such criteria as “view, download, and transmit to 3rd party” (§ 170.315(e)(1)).

Similar to the 2015 Edition “data export” certification criterion (§ 170.315(b)(6)), which we propose for removal below, we acknowledge potential privacy and security concerns may arise when EHI is exported and, therefore, propose that for provider-mediated requests, a developer may design the health IT to limit the type of users that would be able to access and initiate EHI export functions. However, as we previously specified in the 2015 Edition final rule, the ability to “limit” the single patient EHI export functionality is intended to be used by and at the discretion of the provider organization implementing the technology, not a way for health IT developers to implicitly prevent the overarching user-driven aspect of this capability (80 FR 62646).

b. Transitions Between Health IT Systems

In addition to and separate from the patient access use case described above, health IT certified to this criterion would facilitate the migration of EHI to another health IT system. We propose that a health IT developer of health IT certified to this criterion must, at a customer's request, provide a complete export of all EHI that is produced or managed by means of the developer's certified health IT. Health IT developers would have flexibility as to how this outcome is achieved, so long as a customer is able to receive the export in a timely and efficient manner, and in a format that is commercially reasonable. For example, in contrast with the patient export capability, which must be available to a user without subsequent Start Printed Page 7448developer assistance to operate, the “database export” capability of this criterion could require action or support on the part of the health IT developer.

We note that while this criterion focuses on the technical outcomes supported by this capability, developers of health IT certified to this criterion would be required to provide the assurances proposed in § 170.402, which include providing reasonable cooperation and assistance to other persons (including customers, users, and third-party developers) to enable the use of interoperable products and services. Thus, while developers would have flexibility as to how they implement the export functionality for transitions between systems, they would ultimately be responsible for ensuring that the capability is deployed in a way that enables a customer and their third-party contractors to successfully migrate data. Such cooperation and assistance could include, for example, assisting a customer's third-party developer to automate the export of EHI to other systems. We refer readers to section VII.B.2 of the proposed rule for further discussion of a health IT developer's assurances as proposed in § 170.402.

c. Scope of EHI

For both use cases supported by this criterion, EHI export encompasses all the EHI that the health IT system produces and electronically manages for a patient or group of patients. This applies to the health IT's entire database, including but not limited to clinical, administrative, and claims/billing data. It would also include any data that may be stored in separate data warehouses that the system has access to, can produce, and electronically manages. For example, health IT developers may store EHI in these warehouses to prevent performance impacts from data queries that may slow down the “main” health IT system's (e.g., EHR) clinical performance. We clarify that “EHI” also includes the oldest EHI available on that patient to the most recent, no matter the specific electronic format (e.g., PDFs are included). As mentioned above, our intention is that “produces and electronically manages” refers to a health IT product's entire database. However, we seek comment on the terminology used (“produces and electronically manages”) and whether that captures our intent or whether there are any alternatives to the language we should consider to further clarify our intent. Alternative language we considered included “produce and electronically retain” data, which could encompass more data.

The use of the term “electronic health information” (EHI) is deliberate and in alignment with the Cures Act and the proposed definition of this term in § 170.102. Its use supports consistency and the breadth of types of data envisioned by this criterion. Clinical data would encompass imaging information—both images and narrative text about the image—as this is part of the patient's total record; however, we understand that EHRs may not be the standard storage location for images and solicit comment on the feasibility, practicality, and necessity of exporting images and/or imaging information. We request comment on what image elements, at a minimum, should be shared such as image quality, type, and narrative text. It is understandable that developers will not be able to export every existing data element, nor that all possible data elements are necessary for transfer. For finalization in a subsequent final rule, we solicit comment on whether we should require, to support transparency, health IT developers to attest or publish as part of the export format documentation the types of EHI they cannot support for export.

We also propose the following metadata categories that would be excluded from this criterion, and have listed examples for clarity below. We seek comment on these exclusion categories, and request feedback on what metadata elements should remain included for export, or be added to the list of data that would be allowed to be excluded in a subsequent final rule:

  • Metadata present in internal databases used for physically storing the data. Examples include: Internal database table names, field names, schema, constraints, Triggers, Field size (number of bytes), Field type (String, integer, double, long), and Primary keys or object identifiers used internally for querying.
  • Metadata that may not be necessary to interpret EHI export, including information that is typically required for processing of transactions such as encryption keys, internal user roles, ancillary information such as information stored in different formats, local codes for internal use; audit logs, record reviews, or history of change.
  • Metadata that refers to data that is not present in the EHI export, such as links to files and other external attachments that are not part of the export, and information used in conjunction with data from other applications that is not part of the health IT.

We also seek comment, for consideration in finalizing this criterion in a subsequent final rule, on types of EHI that may present challenges for meeting the intent of this proposed criterion.

d. Export Format

The proposed certification criterion does not prescribe a content standard for the EHI export. However, it requires health IT developers to provide the format, such as a data dictionary or export support file, for the exported information to assist the receiving system in processing the EHI without loss of information or its meaning to the extent reasonably practicable using the developer's existing technology. Providing EHI export information is consistent with emerging industry practices and capabilities to offer requestors the ability to access, download, and move their information without unreasonable burden. Companies such as Facebook,[27] Google,[28] and Twitter [29] offer publicly-available links which provide requestors necessary information on how to download their personal information including, in some cases, several download options for requestors alongside their export instructions. Public access to comparable EHI export information would further support third-party companies in this space, as they would have additional information and general knowledge for use of available data. Accordingly, we propose that the developer's export format should be made publicly available via a hyperlink as part of certification to the “EHI export” criterion, including keeping the hyperlink up-to-date with the current export format.

We believe that by making the export format publicly available at the time of certification (and keeping the information current) will stimulate a vibrant, competitive market in which third- party software developers can specialize in processing the data exported from certified health IT products in support of patients and providers. Moreover, we believe this proposal will transform today's current guess-work, one-off processes into something more predictable and transparent such that greater industry efficiencies can be realized. We note and clarify that the export format need not be the same format used internally by the health IT system, and the health IT developer would not need to make public their proprietary data model. The proposed certification criterion also Start Printed Page 7449does not prescribe how the exported EHI is made available to the user, as this may depend on the size and type of information. We would expect that the information be made available to the user or requestor in an acceptable manner without placing unreasonable burden on the user or requestor. Please also generally see our discussion of information blocking in section VIII and particularly section VIII.D.5.

e. Initial Step To Persistent Access to All of a Patient's EHI

We believe that open, standards-based APIs should provide persistent access to patients' EHI over time to achieve the envisioned goals in § 170.404. In the meantime, this proposed criterion in § 170.315(b)(10) will provide an initial step toward achieving those goals. We clarify that “persistent” or “continuous” access to EHI is not required to satisfy this criterion's requirements and that the minimum requirement is for a discrete data export capability. Similarly, while the criterion requires the timely export of all EHI, such export need not occur instantaneously (or in “real-time”). However, health IT developers are encouraged to consider persistent access and real-time approaches as part of the step-wise progression we see towards open, standards-based APIs for a growing number of data elements per the USCDI in the proposed “standardized API for patient and population services” criterion (§ 170.315(g)(10).” Further, we caution that where it is reasonable for a developer to provide persistent or real-time access to electronic health information, the refusal to do so may be inconsistent with the Conditions of Certification in § 170.401 (information blocking) and § 170.402 (assurances related to this capability), as well as the information blocking provision, as to which readers should refer to sections VII and VIII of this proposed rule. Similarly, while this certification criterion would provide a baseline capability for exporting data for the specific use cases described above, health IT developers may need to provide other data export and conversion services or support additional export use cases beyond those encompassed by this criterion to facilitate the appropriate access, exchange, and use of electronic health information and to avoid engaging in information blocking.

f. Timeframes

ONC seeks input on EHI export and timeframes. In particular, beyond exporting all the EHI the health IT system produces and electronically manages, should this criterion include capabilities to permit health care providers to set timeframes for EHI export, such as only the “past two years” or “past month” of EHI?

For discussion of the required timeframe for developers of certified health IT to certify to this proposed criterion and make it available to their customers, please see Section VII.B.2, which addresses a health IT developer's required assurances regarding the availability and provision of this EHI export capability to its customers.

g. Replaces the 2015 Edition “Data Export” Criterion in the 2015 Edition Base EHR Definition

We propose to remove the “data export” criterion (§ 170.315(b)(6)) from the 2015 Edition, including the 2015 Edition Base EHR definition expressed in § 170.102. Correspondingly, we propose to include the proposed “EHI export” criterion (§ 170.315(b)(10)) in the 2015 Edition Base EHR definition, which would affect health care providers' compliance responsibilities when it comes to possessing CEHRT for associated CMS programs. A specific C-CDA data export criterion no longer supports advancements in interoperability in the evolving health IT industry. The proposed “EHI export” certification criterion is standards-agnostic and supports a more open approach to interoperability. More specifically, the proposed “EHI export” criterion differs significantly from the “data export” certification criterion as the latter is limited to clinical data as specified in the C-CDA. Also, the proposed “EHI export” criterion is not limited to just the scope of the certified capabilities in the certified Health IT Module as it applies to all produced and electronically managed EHI. Further, by including this functionality in the 2015 Base EHR definition, we can be assured that health care providers participating in the CMS programs (e.g., Promoting Interoperability Programs) have functionality to both support patient requests for their EHI and switching health IT systems.

We propose to modify the Base EHR definition to include the proposed “EHI export” criterion 24 months from the effective date of the final rule for this proposed rule (which practically speaking would be 25 months because of the 30-day delayed effective date). We believe this is sufficient time for health IT developers to develop, test, certify, and rollout this functionality to health care providers based on the flexible approach offered for meeting this criterion. We also believe this timeframe provides sufficient time for health care providers to adopt and implement the functionality included in the “EHI export” criterion. To note, we refer readers to the “Assurances” Condition and Maintenance of Certification requirements in section VII.B.2, which propose complementary requirements on health IT developers to rollout health IT certified “EHI export” within 24 months of the effective date of a final rule for this proposed rule. We welcome comments on our proposed compliance timeline.

We note that we do not propose a transition period for the “data export” criterion. We propose to remove the criterion from the 2015 Edition upon the effective date of a final rule for this proposed rule. Unlike the “application access—data category request” criterion (which we propose to replace with the new API criterion in this proposed rule), the “data export” criterion does not support an objective or measure under the CMS Promoting Interoperability Programs. Therefore, we do not believe that health IT developers and health care providers need to support the functionality in the “data export” criterion while they transition to the development, adoption, and implementation of the EHI export criterion. This approach should reduce burden and costs for both health IT developers and health care providers. We welcome comments on this approach, including whether this will leave health care providers without an export capability for an inordinate period of time such that we should require health IT developers to support the “data export” functionality for health care providers until the health IT developer attests to providing the new EHI export functionality to all of its customers.

Readers are also referred to the Regulatory Impact Analysis in section XIV of this proposed rule for a discussion of the estimated costs and benefits of this proposed criterion, as well as the impact of the proposed removal of the 2015 Edition “data export” criterion.

5. Standardized API for Patient and Population Services Criterion

To implement the Cures Act, we propose to adopt a new API criterion in § 170.315(g)(10), which would replace the “application access—data category request” certification criterion (§ 170.315(g)(8)) and become part of the 2015 Edition Base EHR definition. This new certification criterion would require the use of FHIR standards, several implementation specifications, and focus on supporting two types of API-enabled services: (1) Services for Start Printed Page 7450which a single patient's data is at focus; and (2) services for which multiple patients' data are at focus. Please refer to the “Application Programming Interfaces” section (VII.B.4) in this preamble for a more detailed discussion of the “API” certification criterion and related Conditions and Maintenance of Certification requirements.

6. Privacy and Security Transparency Attestations

a. Background

In 2015, the HIT Standards Committee (HITSC) recommended the adoption of two new certification criteria for the Program. The National Coordinator endorsed the HITSC recommendations for consideration by the Secretary, and the Secretary determined that it was appropriate to propose adoption of the two new certification criteria through rulemaking (81 FR 10635). To implement the Secretary's determination, we propose to add two new 2015 Edition privacy and security “transparency attestation” certification criteria for: (1) Encrypt authentication credentials; and (2) multi-factor authentication.

In the 2015 Edition final rule, we adopted a new, simpler, and straightforward approach to privacy and security (P&S) certification requirements for Health IT Modules certified to the 2015 Edition, which we refer to as the 2015 Edition privacy and security certification framework (80 FR 62705). In this proposed rule, we propose modifications to the 2015 Edition privacy and security certification framework in § 170.550(h) and propose to add new criteria to which a health IT developer would need to certify pertaining to whether or not its product encrypts authentication credentials (specifically § 170.315(d)(12)) and supports multi-factor authentication (specifically § 170.315(d)(13)). To be clear, we are not proposing to require that health IT have the functionality present to encrypt authentication credentials or support multi-factor authentication. Rather, we propose that a health IT developer indicate whether or not their certified health IT has those capabilities by attesting yes or no.

b. Encrypt Authentication Credentials

We propose to adopt an “encrypt authentication credentials” certification criterion in § 170.315(d)(12) and include it in the P&S certification framework (§ 170.550(h)). We propose to make the encrypt authentication credentials certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification due to the fact that all health IT must meet the “authentication, access control, and authorization” certification criterion adopted in § 170.315(d)(1) as part of current Program requirements. While the 2015 Edition “authentication, access control, and authorization” certification criterion criteria requires that patient information saved on end user devices is encrypted, those same protections are not explicitly required through certification for the authentication credentials used to access that same information. As such, we believe that this proposal would address that gap and encourage health IT developers to take steps to ensure that authentication credentials are protected consistent with industry best practices.

To provide clarity as to what a “yes” attestation for “encrypt authentication credentials” would mean, we provide the following explanation. Encrypting authentication credentials could include password encryption or cryptographic hashing, which is storing only encrypted or cryptographically hashed passwords. If a developer attests that its Health IT Module encrypts authentication credentials, we propose that the attestation would mean that the Health IT Module is capable of cryptographically protecting stored authentication credentials in accordance with standards adopted in § 170.210(a)(2), Annex A: Federal Information Processing Standards (FIPS) Publication 140-2, Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules. We posit that FIPS Publication 140-2 is the seminal, comprehensive, and most appropriate standard. Moreover, in the specified FIPS 140-2 standard, there is an allowance for various approved encryption methods, and health IT developers would have the flexibility to implement any of the approved encryption methods in order to attest yes to this criterion. Health IT developers should keep apprised of these standards as they evolve and are updated to address vulnerabilities identified in the current standard.

We do not believe it is necessary for a Health IT Module to be required to be tested to this criterion, so long as by attesting yes to this criterion, the health IT developer is attesting that if authentication credentials are stored, then the authentication credentials are protected consistent with the requirements above. To be clear, a “no” attestation is a sufficient response to address this certification criterion; however, health IT developers should be aware that this “no” will be made publicly available on the CHPL. Note that if a developer attested to encrypting authentication credentials, a certified Health IT Module would be subject to ONC-ACB surveillance for any potential non-conformity with the requirements of this criterion. Specifically, if the ONC-ACB becomes aware of situations where the developer's health IT is not meeting the developer's affirmative attestation per the criterion's requirements, the ONC-ACB may use its corrective action process to bring the product back into conformance.

We propose that, for health IT certified prior to a subsequent final rule's effective date, the health IT would need to be certified to the “encrypt authentication credentials” certification criterion within six months after the final rule's effective date. For health IT certified for the first time after the final rule's effective date, we propose that the health IT must meet this criterion at the time of certification. This should allow sufficient time for health IT developers to assess their Health IT Modules' capabilities and attest “yes” or “no” to the certification criterion.

For an assessment of this proposal's costs and benefits, please refer to the Regulatory Impact Analysis in section XIV of this preamble. We welcome comments on this assessment and this proposal in general. We also note that some health IT presented for certification is not designed to store authentication credentials. Therefore, we specifically request comment on whether we should include an explicit provision in this criterion to accommodate such health IT. This could be similar to the approach we have taken with the 2015 Edition “end-user device encryption” criterion (§ 170.315(d)(7)(ii)), where we permit the criterion to be met if the health IT developer indicates their technology is designed to prevent electronic health information from being locally stored on end-user devices.

c. Multi-Factor Authentication

We propose to adopt a “multi-factor authentication” (MFA) criterion in § 170.315(d)(13) and include it in the P&S certification framework (§ 170.550(h)). We propose to make the “multi-factor authentication” certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification. Health IT developers have already been implementing MFA to meet the Electronic Prescribing of Controlled Substances (EPCS) requirements set by Drug Enforcement Administration (DEA), and if adopted, this certification criterion would be general in that its Start Printed Page 7451intended outcome would provide more public transparency around the MFA capabilities included in certified health IT.

This proposal supports the Department of Homeland Security (DHS) led initiative “STOP, THINK, CONNECT” which strongly recommends and runs campaigns to promote stronger authentication, typically related to MFA, going beyond a username and password to log in. MFA is also recommended by numerous organizations and groups. In the “Report on Improving Cybersecurity in the Health Care Industry,” [30] the Health Care Industry Cybersecurity Task Force recommended requiring strong authentication to improve identity and access management for health care workers, patients, and medical devices/EHRs. Using a single factor approach to accessing information is particularly prone to cyber-attack because one factor passwords can be weak, stolen, and are vulnerable to external phishing attacks, malware, and social engineering threats. In situations where the provider is accessing a health IT product or health information exchange external to the hospital or clinical environment, the Health Care Industry Cybersecurity Task Force recommended that the health care industry adopt the NIST SP 800-46 guidelines for remote access, including the use of two-factor authentication to ensure a compromised password cannot alone be used to gain access. Promoting the use of MFA and leveraging biometrics, mobile phones, and/or wearables can help to establish a trust relationship with the patient. Additionally, NIST recommends any personal data, whether self-asserted or validated, require MFA.

However, despite the benefits of adopting MFA, we are also aware of some of the challenges. Specifically, in health care, many providers are resistant to adopt MFA because of the inconvenience and loss of time of going through another step to access the patient's EHI. Also, MFA has not been deployed very long in the health care setting, so it is not clear how much it actually addresses the risk. In most MFA implementations, passwords are still present. In addition to having to manage passwords, users also have to manage an additional layer of security. Another usability challenge is that systems often require different types of MFA, which adds to the complexity and also may require providers to keep track of tokens. MFA is often recommended as a solution to password problems, but it is still vulnerable to theft. These alternative forms of authentication have their own set of vulnerability issues. The cost of implementing MFA and ensuring it will be implemented in a way that does not inhibit clinical workflow is also an issue to be considered.

To provide clarity as to what a “yes” attestation for “multi-factor authentication” attestation would mean, we provide the following explanation. MFA requires users to authenticate using multiple means to confirm they are who they claim to be in order to prove one's identity, under the assumption that it is unlikely that an unauthorized individual or entity will be able to succeed when more than one token is required. MFA includes using two or more of these: (i) Something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information. Thus, in order to be issued a certification, we propose to require that a Health IT Module developer attest to whether or not its certified health IT supports MFA consistent with industry recognized standards (e.g., NIST Special Publication 800-63B Digital Authentication Guidelines, ISO 27001).

We propose that, for health IT certified prior to a subsequent final rule's effective date, the health IT would need to be certified to the “multi-factor authentication” certification criterion within six months after the final rule's effective date. For health IT certified for the first time after the final rule's effective date, we propose that the health IT must meet this criterion at the time of certification. This should allow sufficient time for health IT developers to assess their Health IT Modules' capabilities and attest “yes” or “no” to the certification criterion.

We generally seek comment on whether there is value in adopting the proposed “multi- factor authentication” criterion. We also solicit comment on the method of attestation and, if the health IT developer does attest to supporting MFA, whether we should require the health IT developer to explain how they support MFA. For example, should the health IT developer be required to identify the MFA technique(s) used/supported by submitting specific information on how it is implemented, including identifying the purpose(s)/use(s) to which MFA is applied within their Health IT Module (such as where in the clinical workflow it is required), and, as applicable, whether the MFA solution complies with industry standard? This information could enable the health IT developer to highlight their health IT's capabilities to support MFA.

7. Data Segmentation for Privacy and Consent Management Criteria

We adopted two 2015 Edition “data segmentation for privacy” (DS4P) certification criteria in the 2015 Edition final rule. One criterion (“DS4P-send” (§ 170.315(b)(7)) includes capabilities for creating a summary care record formatted to the C-CDA 2.1 standard and document-level tagging as restricted (and subject to restrictions on re-disclosure) according to the DS4P standard. The other criterion (“DS4P-receive” (§ 170.315(b)(8)) includes capabilities for receiving a summary care record formatted to the C-CDA 2.1 standard and document-level tagged as restricted (and subject to restrictions on re-disclosure) according to the DS4P standard. As noted in the 2015 Edition final rule (80 FR 62646)), certification to these criteria is not required to meet the CEHRT definition for CMS EHR Incentive Programs, now referred to as the Promoting Interoperability Programs. The current 2015 Edition DS4P certification criteria specify the technical capabilities that the health IT must have to apply and recognize security labels in a summary document (C-CDA) such that the recipient of a summary document would be able to recognize the existence of sensitive elements within the summary document (80 FR 62646). Security labeling provides a way for computer systems to properly handle data passed among systems, to preserve the condition of security, and to enable access control decisions on the information, so that the information is only accessed by the appropriate entities. The HL7 Healthcare Classification System (HCS) standard provides a common syntax and semantics for interoperable security labels in health care. The DS4P standard makes use of the HCS specification and describes a method for applying security labels to HL7 CDA documents to ensure that privacy policies established at a record's source can be understood and enforced by the recipient of the record.

In the 2015 Edition final rule, we noted that the DS4P standard is not restricted to data subject to the federal regulations governing the Confidentiality of Substance Use Disorder Patient Records (42 CFR part 2) (80 FR 62647). It may be implemented to support other data exchange use cases in which compliance with state or federal legal frameworks require sensitive health information to be tagged Start Printed Page 7452and segmented (80 FR 62647). We further stated that we offered certification to these criteria as an initial step towards the ability of an interoperable health care system to use technical standards to compute and persist security labels to permit access, use, or disclosure of protected health information in accordance with applicable policies and patient preferences. We understood and acknowledged additional challenges surrounding the prevalence of unstructured data, sensitive images, and potential issues around use of sensitive health information by clinical decision support systems. The adoption of document level data segmentation for structured documents would not solve these issues, but we acknowledged it would help move technology in the direction where these issues could be addressed (80 FR 16841).

Adoption of the current 2015 Edition DS4P criteria was also consistent with earlier HIT Policy Committee (HITPC) recommendations on the use of DS4P technology to enable the electronic implementation and management of disclosure policies that originate from the patient, the law, or an organization, in an interoperable manner, so that electronic sensitive health information may be appropriately shared.[31] These HITPC recommendations consisted of a glide path for the exchange of 42 CFR part 2-protected data starting with the inclusion of Level 1 (document level tagging) send and receive functionality. The HITPC also recommended advancing the exchange of 42 CFR part 2-protected data, by outlining additional capabilities in sharing, viewing and incorporating privacy restricted data at a more granular level, as well as managing computable patient consent for the use of restricted data.[32]

Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. As of the beginning of the third quarter of the 2018 CY, only about 20 products (products with multiple certified versions were counted once) were certified to the current 2015 Edition DS4P certification criteria. In addition, stakeholders shared with ONC—through public forums, listening sessions, and correspondence—that focusing certification on segmentation to only the document level does not permit providers the flexibility to address more granular segmentation needs. Stakeholders noted that certain provider types, such as providers of pediatric care and behavioral health care, are currently using a range of burdensome manual workflows in order to meet complex use cases for DS4P which are also impacted by state and local laws. Additionally, stakeholders have expressed interest in ONC exploring health IT standards that work with DS4P to support the management of consent for sharing documents that include security labels such as through the use of an API.

Therefore, in consideration of stakeholder feedback and our stated policy approach to adopt DS4P certification criteria on a glide path, we propose to remove the current 2015 Edition DS4P-send (§ 170.315(b)(7)) and DS4P-receive (§ 170.315(b)(8)) certification criteria. The proposed effective date of removal of these criteria would be the effective date of a subsequent final rule for this proposed rule. We propose to replace these two criteria with three new 2015 Edition DS4P certification criteria (two for C-CDA and one for a FHIR-based API) that would support a more granular approach to privacy tagging data and consent management for health information exchange supported by either the C-CDA- or FHIR-based exchange standards. Our primary purpose for proposing to remove and replace them, in lieu of proposing to revise them, is to provide clarity to stakeholders as to the additional functionality enabled by health IT certified to the new criteria. We note resources released by ONC and OCR, such as the HHS Security Risk Assessment Tool [33] and the Guide to Privacy and Security of Electronic Health Information,[34] as well as the Office for Civil Rights' security risk analysis guidance [35] that entities may employ to make risk-based decisions regarding their implementation of the proposed DS4P criteria. We also note the availability of the Electronic Consent Management Landscape Assessment, Challenges, and Technology report.[36] The report includes suggestions for overcoming barriers associated with implementing electronic consent management, which may be considered for further research and discussion.

a. Implementation With the Consolidated CDA Release 2.1

In place of the removed 2015 Edition DS4P criteria, we propose to adopt new DS4P-send (§  170.315(b)(12)) and DS4P-receive (§  170.315(b)(13)) criteria that would remain based on the C-CDA and the HL7 DS4P standard. These criteria would include capabilities for applying the DS4P standard at the document, section, and entry level. We believe this offers more valuable functionality to providers and patients, especially given the complexities of the landscape of privacy laws for multiple care and specialty settings. We believe health IT certified to these criteria could support multiple practice settings and use cases. For example, in section VI.A.2 of this preamble, we explain how the proposed capabilities included in these criteria could support the pediatric health care setting. We believe this proposal could also reduce burden for providers by leveraging health IT's ability to recognize and manage sensitive data and patient consent directives, rather than relying on case-by-case manual redaction and subsequent workarounds to transmit redacted documents. We emphasize that health care providers already have processes and workflows to address their existing compliance obligations which could be made more efficient and cost effective through the use of health IT. We recognize that more granular privacy markings at the point of data capture would further support existing and future priorities of states for multiple care and specialty settings, including behavioral health and pediatric health care settings.

We welcome public comment on our proposals to replace the current 2015 Edition DS4P criteria and adopt new 2015 Edition DS4P-send (§  170.315(b)(12)) and DS4P-receive (§  170.315(b)(13)) criteria to support improved options for data segmentation for health care providers engaged in complex use cases such as those identified in pediatric care (see also section VI.A) and behavioral health Start Printed Page 7453care, including for opioid use disorder (OUD) (see also section VI.B).

b. Implementation With FHIR Standard

In collaboration with ONC, the Substance Abuse and Mental Health Services Administration (SAMHSA) developed the Consent2Share application to address the specific privacy protections of patients with substance use disorders who are covered by the federal confidentiality regulation, 42 CFR part 2. Consent2Share is an open source application for data segmentation and consent management. It is designed to integrate with existing FHIR systems. SAMHSA created a FHIR implementation guide (the Consent2Share Consent Profile Design, hereafter referred to as “Consent Implementation Guide”) that describes how the Consent2Share (C2S) application and associated access control solution uses the FHIR Consent resource to represent and persist patient consent for treatment, research, or disclosure.[37] The implementation guide provides instructions for using the FHIR Consent resource to capture a record of a health care consumer's privacy preferences.

As discussed in section VII.B.4 of this proposed rule, we are proposing policies related to the implementation of a standardized API to support the exchange of health information between providers and patients and among members of a care team. We anticipate that the proposed 2015 Edition “standardized API for patient and population services” certification criterion (§ 170.315(g)(10)) will result in a proliferation of APIs that will enable a more flexible and less burdensome approach to exchanging EHI. We believe the health care industry can leverage this API infrastructure to share segmented data in a secure and scalable manner. Therefore, we propose to adopt a 2015 Edition certification criterion “consent management for APIs” in § 170.315(g)(11) to support data segmentation and consent management through an API in accordance with the Consent Implementation Guide. Certification to this criterion would be at a health IT developer's discretion and would indicate that a system is capable of responding to requests through an API for patient consent directives that include standards-based security labeling.

We acknowledge that our proposed implementation specification, the Consent Implementation Guide, is based on a different version of the FHIR standard (FHIR Standard for Trial Use 3, also known as FHIR Release 3) than the proposed “standardized API for patient and population services” criteria (§ 170.315(g)(10)) which is proposed to reference just FHIR Release 2. Furthermore, we acknowledge that this discrepancy may result in additional implementation efforts for developers. In ideal circumstances, we would have proposed a data segmentation and consent management standard for APIs that was based on FHIR Release 2 and aligned with the “standardized API for patient and population services” criteria proposed in this proposed rule. However, although SAMHSA also created a consent implementation guide based on FHIR Release 2,[38] the guide used the FHIR “Contract” resource to represent patient consent directives. It is our understanding that an approach based on the “Contract” resource has since been abandoned by the industry in favor of using the “Consent” resource which was introduced in FHIR Release 3. Moreover, the FHIR Release 2 version of the Consent Implementation Guide went through relatively little testing and was never formally implemented because SAMHSA began developing an update to the guide based on the “Consent” resource in FHIR Release 3. Consequently, proposing an implementation specification based on FHIR Release 2 would not have aligned with the more common implementation of FHIR-based consent directives by the health care industry. We do not anticipate that the initial misalignment between the proposed API criterion (§ 170.315(g)(10)) and the proposed third DS4P criterion (§ 170.315(g)(11)) will pose a significant burden on health IT developers. Further, our proposal to permit health IT developers to voluntarily implement and use a new version of an adopted standard or implementation specification so long as such version was approved by the National Coordinator for use in certification through the Standards Version Advancement Process, discussed in section VII.B.5, would enable standards version alignment between these two criteria in the future as the FHIR standard matures.

SAMHSA created the “Consent Implementation Guide” to support developers in implementing the FHIR Consent resource to represent patient consent for treatment, research, and disclosure. The Consent Implementation Guide provides instructions for using the FHIR “Consent” resource to capture a record of a health care consumer's privacy preferences. Implementing an instance of the FHIR Consent resource based on this guide allows for a patient consent to permit or deny identified recipient(s) or recipient role(s) to perform one or more actions, regarding the patient's health information for specific purposes and periods of time. For example the Consent Implementation Guide supports consent management for specific use cases to permit or deny disclosure based on a specific law, regulation, or policy under which the patient consented. The implementation guide uses security labels as a mechanism for specifying a patient's preferences (e.g., permit disclosure of EHI labeled “restricted”). The Consent Implementation Guide provides a much simpler mechanism for representing a patient's consent preferences than the old approach based on FHIR Release 2 and has undergone implementation and pilot testing by SAMHSA's Consent2Share (C2S) application.

Our proposal to adopt the version aligned with FHIR Release 3 and the FHIR Release 3 standard for this criterion reflects stakeholder interests and efforts to support particular use cases. C2S enables data segmentation and consent management for disclosure of several discrete categories of sensitive health data related to conditions and treatments including: Alcohol, tobacco and substance use disorders (including opioid use disorder), behavioral health, HIV/AIDS, and sexuality and reproductive health. These capabilities support multiple use cases in both primary and specialty care, and specifically address priority needs identified by stakeholders to support pediatric care. We emphasize that health care providers already have processes and workflows to address their existing compliance obligations which could be made more efficient and cost effective through the use of health IT. Finally, given that the FHIR standard is modular in nature, and especially since the “Consent” resource did not exist in FHIR Release 2, we anticipate that health IT developers that elect to certify to this criterion would be able to support the Consent Implementation Guide along with the API requirements specified in “standardized API for Start Printed Page 7454patient and population services” (§ 170.315(g)(10)) with modest extra effort.

We welcome comments on this proposal. We specifically seek comment on how the availability of this proposed certification criterion might increase the ability to support multiple care coordination and privacy priorities, including those associated with pediatric care; and whether we should consider other similar API based options and resources as standards for certification criteria. We also seek comment on whether the misalignment between the versions of the FHIR standard used by our proposed “consent management for APIs” and “standardized API for patient and population services” criteria would create excessive burden for developers and implementers. Specifically, we seek comment on if certification to the “consent management for APIs” should only be available in conjunction with the “standardized API for patient and population services” criteria at such a time as the criteria are aligned to one version of the FHIR standard or if the option to certify to the “consent management for APIs” should be allowed for those developers interested in doing so even without current standards alignment. We note that SAMHSA is currently pursuing additional work to expand use cases related to data segmentation for privacy and FHIR compatibility.

C. Unchanged 2015 Edition Criteria—Program Reference Alignment

In the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20516), CMS proposed scoring and measurement policies to move beyond the three stages of meaningful use to a new phase of EHR measurement with an increased focus on interoperability and improving patient access to health information. To reflect this focus, CMS changed the name of the Medicare and Medicaid EHR Incentive Programs, to the Medicare and Medicaid Promoting Interoperability (PI) Programs. To align with the renaming of the EHR Incentive Programs, we propose to remove references to the EHR Incentive Programs and replace them with “Promoting Interoperability Programs” in the 2015 Edition “automated numerator recording” criterion in § 170.315(g)(1) and the “automated measure calculation” criterion in § 170.315(g)(2).

V. Modifications to the ONC Health IT Certification Program

A. Corrections

1. Auditable Events and Tamper Resistance

Currently, § 170.315(d)(2), “auditable events and tamper resistance,” includes a cross- reference to § 170.315(d)(7). However, the cross reference to § 170.315(d)(7), “end-user device encryption,” does not always apply. We propose to revise § 170.550(h)(3) to apply the § 170.315(d)(7) cross reference as appropriate and exempt § 170.315(d)(7) when the certificate scope does not require § 170.315(d)(7) certification (see § 170.315(d)(2)(i)(C)). Paragraph 170.315(d)(2)(i)(C) is not applicable for the privacy and security testing and certification of a Health IT Module required by § 170.550(h)(3)(iii), (v), (vii), and (viii). This specific requirement was intended to be exempted. It would only apply if § 170.315(d)(7) was also required for privacy and security testing and certification, which it is not under the aforementioned paragraphs. For example, a developer that is seeking to certify a Health IT Module to § 170.315(h) will not necessarily have end-user device encryption features (see § 170.315(d)(7)). As such, certification can proceed for the audit log process without the Health IT Module demonstrating that it can record an encryption status as required by § 170.315(d)(2)(i)(C). We have previously identified this error in guidance and now propose to codify the correction in regulation.[39]

2. Amendments

We propose to revise § 170.550(h) to remove the “amendments” criterion's application to certain non-applicable clinical criteria including: “Drug-drug, drug-allergy interaction checks for computerized provider order entry (CPOE)” § 170.315(a)(4); “clinical decision support” § 170.315(a)(9); “drug-formulary and preferred drug list checks” § 170.315(a)(10); and “patient-specific education” § 170.315(a)(13). Health IT Modules presented for certification to these criteria would not have to demonstrate the capabilities required by the 2015 Edition “amendments” certification criterion (§ 170.315(d)(4)), unless the health IT is presented for certification to another criterion that requires certification to the 2015 Edition “amendments” criterion under the P&S certification framework. This has already been incorporated into sub- regulatory guidance, and we propose to codify this clarification in regulation.[40] The revision was made upon further analysis of the P&S certification framework and the applicability of the “amendments” certification criterion § 170.315(d)(4) to health IT capabilities that would not necessarily have any patient data for which a request for an amendment would be relevant.

3. View, Download, and Transmit to 3rd Party

We propose to remove § 170.315(e)(1)(ii)(B) which includes a cross-reference to § 170.315(d)(2). This cross-reference indicates that health IT may demonstrate compliance with activity history log requirements if it is also certified to the 2015 Edition “auditable events and tamper-resistance” certification criterion (§ 170.315(d)(2)). However, we no longer require testing of activity history log when certifying for § 170.315(d)(2). Therefore, this cross-reference is no longer applicable to meet certification requirements for the 2015 Edition “view, download, and transmit to 3rd party” certification criterion (§ 170.315(e)(1)) activity history log requirements.

4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework

Consistent with the 2015 Edition privacy and security certification framework, each certification criterion has a set of appropriate P&S “safeguards” that must be in place. In the 2015 Edition, we required that an ONC-ACB must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text “first level paragraph” category of § 170.315 (e.g., § 170.315(a)) identified below would be certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation). In this proposed rule, we propose to require the new criteria (§ 170.315(d)(12) and (d)(13)) to apply to all § 170.315 certification criteria. Therefore, given these and the other modifications discussed above, we propose to revise the P&S certification framework as Start Printed Page 7455noted in the table below. However, the P&S Certification Framework would need to be further updated depending on finalization of the proposals discussed in section III.B.4, which propose removal of certain 2015 Edition certification criteria.

Table 1—Proposed 2015 Edition Privacy and Security Certification Framework

If the Health IT Module includes capabilities for certification listed under:It will need to be certified to approach 1 or approach 2 for each of the P&S certification criteria listed in the “approach 1” column
Approach 1Approach 2
§ 170.315(a)(1), through (2), (5), through (8), (11), and (12)§ 170.315(d)(1) (authentication, access control, and authorization), (d)(2) (auditable events and tamper resistance), (d)(3) (audit reports), (d)(4) (amendments), (d)(5) (automatic log-off), (d)(6) (emergency access), and (d)(7) (end-user device encryption)For each applicable P&S certification criterion not certified using Approach 1, the health IT developer submits system documentation that is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces for each applicable P&S certification criterion that enable the Health IT Module to access external services necessary to meet the requirements of the P&S certification criterion.
§ 170.315(a)(4), (9), (10), and (13)§ 170.315(d)(1) through (d)(3) and (d)(5) through (d)(7)
§ 170.315(b)§ 170.315(d)(1) through (d)(3) and (d)(5) through (d)(8) (integrity)
§ 170.315(c)§ 170.315(d)(1) through (d)(3) and (d)(5) *
§ 170.315(e)(1)§ 170.315(d)(1) through (d)(3), (d)(5), (d)(7), and (d)(9)(trusted connection)
§ 170.315(e)(2) and (3)§ 170.315(d)(1) through (d)(3), (d)(5), and (d)(9) *
§ 170.315(f)§ 170.315(d)(1) through (d)(3) and (d)(7)
§ 170.315(g)(7) through (g)(11)§ 170.315(d)(1) and (d)(9); and (d)(2) or (d)(10) (auditing actions on health information)
§ 170.315(h)§ 170.315(d)(1) through (d)(3) *
§ 170.315(b)§ 170.315(d)(1) through (d)(3) and (d)(5) through (d)(8) (integrity)
§ 170.315(c)§ 170.315(d)(1) through (d)(3) and (d)(5)
§ 170.315(e)(1)§ 170.315(d)(1) through (d)(3), (d)(5), (d)(7), and (d)(9)(trusted connection)
§ 170.315(e)(2) and (3)§ 170.315(d)(1) through (d)(3), (d)(5), and (d)(9)
§ 170.315(a)-(h) Certification Criterion
§ 170.315(a) through (h) Certification Criterion§ 170.315(d)(12)
§ 170.315(a) through (h) Certification Criterion§ 170.315(d)(13)
An ONC-ACB must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text “first level paragraph” category of § 170.315 (e.g. § 170.315(a)) identified in the table above is certified to either Approach 1 (technically demonstrate) or Approach 2 (systemdocumentation). In addition, we propose that health IT developers seeking certification to any § 170.315 certification criterion for their Health IT Modules attest to whether they encrypt authentication credentials (§ 170.315(d)(12)) and support multi-factor authentication (§ 170.315(d)(13))
We clarify that of the adopted 2015 Edition certification criteria, only the privacy and security criteria specified in § 170.315(g)(1) through (6) are exempt from the 2015 Edition privacy and security certification framework due to the capabilities included in these criteria, which do not implicate privacy and security concerns.
In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion identified as part of Approach 1 or Approach 2 so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification, except for the certification of a Health IT Module to § 170.315(e)(1) “view, download, and transmit to 3rd party” and (e)(2) “secure messaging.” For each of these criteria, a Health IT Module must be separately tested to § 170.315(d)(9) because of the specific capabilities for secure electronic transmission and secure electronic messaging included in each criterion, respectively. We also propose the health IT developers seeking certification to any § 170.315 certification criterion for their Health IT Modules attest to whether they encrypt authentication credentials (§ 170.315(d)(12)) and support multi-factor authentication (§ 170.315(d)(13))
* § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.
Start Printed Page 7456

B. Principles of Proper Conduct for ONC-ACBs

1. Records Retention

We propose to revise the records retention requirement in §  170.523(g) to include the “life of the edition” as well as 3 years after the retirement of an edition related to the certification of Complete EHRs and Health IT Module(s). In the 2015 Edition final rule (80 FR 62602), we adopted a records retention provision that required ONC-ACBs to retain all records related to the certification of Complete EHRs and Health IT Module(s) for the “life of the edition” plus an additional 3 years, and the records would be available to HHS upon request during this period of time. In the 2015 Edition final rule, the “life of the edition” was defined as beginning with the codification of an edition of certification criteria in regulation and ending when the edition is removed from regulation. We now propose to clarify that HHS has the ability to access certification records for the “life of the edition,” which begins with the codification of an edition of certification criteria in the Code of Federal Regulations through a minimum of 3 years from the effective date that removes the applicable edition from the Code of Federal Regulations, not solely during the 3-year period after removal from the CFR.

2. Conformance Methods for Certification Criteria

The Principle of Proper Conduct (PoPC) in § 170.523(h) specifies that ONC-ACBs may only certify health IT that has been tested by ONC-ATLs using tools and test procedures approved by the National Coordinator. We propose to revise this PoPC in three ways. First, we propose to revise this PoPC to additionally permit ONC-ACBs to certify Health IT Modules that they have evaluated for conformance with certification criteria without first passing through an ONC-ATL. However, we propose that such methods to determine conformity must first be approved by the National Coordinator. This proposal provides valuable Program flexibility and market efficiencies for streamlining Health IT Module certification, acknowledging the broad spectrum of evidence of conformance, from laboratory testing with an ONC-ATL to developer self-declaration. This Program flexibility will also allow us to leverage the success we have seen in implementation of our alternative test method process where any entity can submit a test procedure and/or test tool for approval for use under the Program. For example, the National Coordinator may, under this provision, approve a conformance method for certification criteria where evidence of a valid declaration of conformity (e.g., certification) granted under an external program can be submitted directly to an ONC-ACB to meet the requirement of that certification criteria.

Second, we propose to revise the PoPC to clarify that certifications can only be issued to Health IT Modules and not Complete EHRs. We are proposing to remove the 2014 Edition from the CFR (see section II.B.2 of this preamble) and Complete EHR certifications are no longer available for certification to the 2015 Edition (80 FR 62608; 79 FR 54443). We propose to remove the provision that permits the use of test results from National Voluntary Laboratory Accreditation Program (NVLAP)-accredited testing laboratories under the Program because the regulatory transition period from NVLAP-accredited testing laboratories to ONC-ATLs has expired (81 FR 72447).

Third, we propose to remove the provision that permits the certification of health IT previously certified to an edition if the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable because the circumstances that this provision seeks to address are no longer feasible with certification to the 2015 Edition. Any Health IT Module previously certified to the 2014 Edition and presented for certification to the 2015 Edition would have at least one new or revised 2015 Edition certification criteria that would be applicable. For example, the 2015 Edition “accessibility-centered design” criterion (§ 170.315(g)(5)) is applicable to any Health IT Module presented for certification to the 2015 Edition.

3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good Standing

We propose to revise the PoPC for ONC-ACBs in order to address business relationships between ONC-ACBs and ONC-ATLs. To encourage market competition, we propose to require ONC-ACBs to accept test results from any ONC-ATL that is in good standing under the Program and is compliant with its ISO 17025 accreditation requirements. However, if an ONC-ACB has concerns about accepting test results from a certain ONC-ATL, the ONC-ACB would have an opportunity to explain the potential issues to ONC and NVLAP, and on a case-by-case basis, ONC could consider the facts and make the final determination.

ONC-ATLs must be accredited by the NVLAP and seek authorization from ONC to participate in the ONC Health IT Certification Program. ONC-ATLs test products against the ONC-approved test method for the standards and certification criteria identified by the Secretary using ONC-approved test methods. ONC-ACBs make certification determinations and conduct surveillance for health IT originally tested by an ONC-ATL. Based on the process that all ONC-ATLs must undergo, we believe that they are capable of providing accurate test results that should be accepted by any ONC-ACB.

The intent of this proposal is to ensure that ONC-ATLs are not discriminated against and do not suffer injury from ONC-ACBs not accepting their test results if, in fact, they are in good standing. This proposal may also prevent harm to health IT developers, who present their health IT to be tested by ONC-ATLs and ultimately seek certification by ONC-ACBs under the Program. These situations may arise if a health IT developer's ONC-ACB leaves the Program or goes out of business. This proposal may also prevent situations of preferential business arrangements such as when one organization is both an ONC-ATL and ONC-ACB and will not enter into a contract with another organization who is also an ONC-ATL.

4. Mandatory Disclosures and Certifications

We propose to revise the PoPC in § 170.523(k). We propose to remove § 170.523(k) (1)(ii)(B) because certifications can only be issued to Health IT Modules and not Complete EHRs. We are proposing to remove the 2014 Edition from the CFR (see section III.B.2 of this preamble) and Complete EHR certifications are no longer available for certification to the 2015 Edition (80 FR 62608; 79 FR 54443). We also propose to revise § 170.523(k)(1)(iii) to broaden the section beyond just the Medicare and Medicaid EHR Incentive Programs (now referred to as Promoting Interoperability Programs). We propose to revise the section to include a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module's capabilities, whether to meet provisions of HHS programs requiring the use of certified health IT or to achieve any other use within the scope of the health IT's certification.Start Printed Page 7457

We also propose to remove the provision in § 170.523(k)(3) that requires a certification issued to a pre-coordinated, integrated bundle of Health IT Modules to be treated the same as a certification issued to a Complete EHR for the purposes of § 170.523(k)(1), except that the certification must also indicate each Health IT Module that is included in the bundle. We propose to remove this provision because pre-coordinated, integrated bundles are no longer applicable for certification under Program.

We propose to revise § 170.523(k)(4) to clarify that a certification issued to a Health IT Module based solely on the applicable certification criteria adopted by the ONC Health IT Certification Program must be separate and distinct from any other certification(s) based on other criteria or requirements. The intent of this provision, as indicated in the Establishment of the Permanent Certification Program for Health Information Technology final rule (76 FR 1272), is to ensure that any other certifications an ONC-ACB may issue, is separately indicated from the applicable certification criteria adopted by the ONC Health IT Certification Program.

We also propose changes related to transparency attestations and limitations in section III.B.5. of this preamble. Additionally, we propose other new PoPCs for ONC-ACBs in sections VII.B.5 and VII.D of this preamble.

C. Principles of Proper Conduct for ONC-ATLs—Records Retention

We propose to revise the records retention requirement in §  170.524(f) to include the “life of the edition” as well as 3 years after the retirement of an edition related to the certification of Health IT Module(s). The circumstances are the same as in section V.B.1 of this preamble mentioned above, therefore, we propose the same revisions for ONC-ATLs as we did for ONC-ACBs.

VI. Health IT for the Care Continuum

ONC believes health IT should help promote and support patient care when and where it is needed. This means health IT should help support patient populations, specialized care, transitions of care, and practice settings across the care continuum. In the Permanent Certification Program final rule, we clarified that section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a voluntary certification program or programs for other types of health IT beyond those which supported the EHR Incentive Programs (now called the Promoting Interoperability Programs). However, we decided that the initial focus of the Program should be on supporting the EHR Incentive Programs, which focuses on EHR technology for the ambulatory and inpatient settings (76 FR 1294). As the Program evolved and the adoption and use of certified health IT increased significantly, we modified the Program in the 2015 Edition final rule to make it more open and accessible to more types of health IT, including health IT that supports various care and practice settings beyond those included in the EHR Incentive Programs (80 FR 62604). Our goal was then and is now to support the advancement of interoperable health IT and to promote health IT functionality in care and practice settings across the care continuum (see also 80 FR 62604).

ONC's efforts in the 2015 Edition to make the Program more open and accessible to other care settings also aligned with fall 2013 recommendations from the HIT Policy Committee (HITPC). The HITPC examined the extension of the Program to include functionalities that would benefit settings not covered by the EHR Incentive Programs. The HITPC recommended that considerations regarding functionality should focus on whether the functionality would:

  • Advance a national priority or legislative mandate
  • Align with existing federal/state programs
  • Utilize the existing technology pipeline
  • Build on existing stakeholder support
  • Appropriately balance the costs and benefits of a certification program.

Taking into consideration the HITPC recommendations, ONC's 2015 Edition focused on the adoption of certification criteria that are standards-based, applicable to a wide variety of care and practice settings, and that advance the structured recording, access, exchange, and use of health information. ONC has also encouraged users—including specialty groups—to continue to work with developers to innovate, develop, and deploy health IT in specific clinical settings in ways that promote safety, effectiveness, and efficient health care delivery while also reducing burden.

In the 2015 Edition final rule we stated that we did not intend to develop and issue separate regulatory certification “paths” or “tracks” for particular care or practice settings (e.g., a “long-term and post-acute care (LTPAC) certification”) because it would be difficult to independently construct such “paths” or “tracks” in a manner that would align with other relevant programs and specific stakeholder needs. While we never have had intentions to adopt care- or practice-specific certification tracks, or additional voluntary program(s), in parallel to the existing voluntary ONC Health IT Certification Program, we stated that we would welcome the opportunity to work with HHS agencies, other agencies, and provider associations in identifying the appropriate functionality and certification criteria in the Program to support their stakeholders (80 FR 62704). This approach is consistent with the recommendations by the HITPC.

Since the publication of the 2015 Edition final rule, ONC has explored how we might work with the industry and with specialty organizations to collaboratively advance health IT that supports medical specialties and sites of service. As a result, we have gained insight from stakeholders regarding the burdens associated with establishing a specific set of required certification criteria for all users—which may include capabilities not applicable to certain settings of care or specialties. Stakeholders have also noted that the adoption of a set of required criteria without also enabling and incentivizing innovation beyond those criteria may have the unintended consequence of stifling progress for that setting. Stakeholders noted that the timeline for testing and certifying to required criteria and the subsequent deployment of certification criteria in practice settings is not always aligned with standards updates, the emergence of new standards, or technological innovation. Finally, stakeholders have urged ONC to leverage multiple means to advance interoperability standards that are widely applicable, to enable and promote innovation that is supported by these standards, and—in collaboration with stakeholders to monitor and support developments in emerging standards and technologies for specialty use cases.

Section 4001(b)(i) of the Cures Act instructs the National Coordinator to encourage, keep, or recognize, through existing authorities, the voluntary certification of health IT under the Program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. This provision of the Cures Act closely aligns with ONC's ongoing collaborative efforts with both federal partners and stakeholders within the health care and health IT community to encourage and support the advancement of health IT for a wide Start Printed Page 7458range of clinical settings. These initiatives have included projects related to clinical priorities beyond those specifically included in the EHR Incentive Programs (now called the Promoting Interoperability Programs) including efforts in public health, behavioral health, and long-term and post-acute care. We further note that these initiatives often include the development of non-regulatory informational resources to support the specific implementation goal and align with the technical specifications already available in the Program for certification. To advance these efforts, we generally consider a range of factors including: stakeholder input and identification of clinical needs and clinical priorities, the evolution and adoption of health IT across the care continuum, the costs and benefits associated with any policy or implementation strategy related to care settings and sites of service, and potential regulatory burden and compliance timelines. Generally, ONC's approach can be summarized in three parts:

  • First, ONC analyzes existing certification criteria to identify how such criteria may be applicable for medical specialties and sites of service.
  • Second, ONC focuses on the real-time evaluation of existing and emerging standards to determine applicability to medical specialties and sites of service as well as to the broader care continuum, including the evaluation of such standards for inclusion in the ONC Interoperability Standards Advisory (ISA).[41]
  • Third, ONC may work in collaboration with stakeholders to support the development of informational resources for medical specialties and sites of service for which ONC identifies a need to advance the effective implementation of certified health IT.

We believe this approach provides an economical, flexible, and responsive option for both health care providers and the health IT industry, which is also in alignment with the provisions of the Cures Act related to burden reduction and promoting interoperability. We are committed to continuing to work with stakeholders in this manner to encourage and advance the adoption of health IT to support medical specialties and sites of service, and to help ensure that providers have the tools they need to support patients at the point of care and that essential patient health information is available across a care settings.

This section outlines our approach to implement Section 4001(b) of the Cures Act, which requires that the Secretary make recommendations for the voluntary certification of health IT for use by pediatric health providers and to adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children. To be clear, and consistent with past practice, we do not recommend or propose a “pediatric-specific track or program” under the ONC Health IT Certification Program. This proposed rule outlines the certification criteria adopted in the 2015 Edition which we believe support the certification of health IT for pediatric care. Finally, it identifies the new and revised criteria proposed in this rule which we believe further support the voluntary certification of health IT for pediatric care. We have included in the appendix of this proposed rule a set of technical worksheets that can help inform your comments on the recommendations, the new and revised criteria in the Program that would also support pediatric care settings, and the overall approach we have herein described. These worksheets outline the following information:

  • The alignment of each recommendation to the Children's Model EHR Format [42] as identified by stakeholders (see also Section VI.A.1 and 2 for further detail on the Children's Model EHR Format and the recommendations).
  • The alignment of each recommendation to the 2015 Edition certification criteria and new or revised criteria described in this proposed rule (see also section VI.A.2.a and b).
  • Potential supplemental items from the Children's Model EHR Format identified by ONC which relate to the primary recommendation and the related certification criteria.

We invite readers to use these worksheets to inform public comment on the recommendations and criteria described in Section VI.A.2 specifically as they relate to pediatric health care use cases. The comments received on these technical worksheets through this proposed rule will be used to inform the final recommendations for voluntary certification of health IT criteria for use in pediatric care. Furthermore, these comments, and the detailed insights received through stakeholder outreach, may inform the future development of a non-binding informational guide or resource to provide useful information for health IT developers and pediatric care providers seeking to successfully implement these health IT solutions in a clinical setting.

A. Health IT for Pediatric Setting

Section 4001(b)(iii) of the Cures Act—“Health information technology for pediatrics” requires that:

  • First, that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children, and
  • Second, that the Secretary shall adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children.

In this proposed rule, we describe our approach to stakeholder engagement, the analysis used to develop the recommendations, and the specific certification criteria we believe can support each recommendation.

1. Background and Stakeholder Convening

Over the past ten years, a number of initiatives have focused on the availability and use of effective health IT tools and resources for pediatric care. These have included a number of public-private partnerships including efforts between HHS, state agencies, and health systems for innovative projects that range from care coordination enterprise solutions to immunization information systems and to point of care solutions for specialty needs. In order to learn from and build upon these efforts, ONC has engaged with stakeholders in both the public and private sector including other federal, state and local government partners, health care providers engaged in the care of children, standards development organizations, charitable foundations engaged in children's health care research, and health IT developers supporting pediatric care settings.

For example, significant work has been done by the Agency for Healthcare Research and Quality (AHRQ), CMS, the Health Resources and Services Administration (HRSA), and organizations around the Children's Model EHR Format (Children's Format), which is critical to any discussion of the pediatric health IT landscape.[43] The Children's Format was authorized by the 2009 Children's Health Insurance Program Reauthorization Act (CHIPRA) [44] and developed by AHRQ in Start Printed Page 7459close collaboration with CMS. It was developed to bridge the gap between the functionality present in most EHRs currently available and the functionality that could optimally support the care of children. Specifically, the Children's Format provides information to EHR system developers and others about critical functionality and other requirements that are helpful to include in an EHR system to address health care needs specific to the care of children. The final version of the Children's Format,[45] released in 2015, consists of 47 high priority functional requirements in 19 topic areas that focus on improvements that would better support the safety and quality of care delivered to children. The Children's Format was intended as a starting point for developers, users, and purchasers for informing an approach for pediatric voluntary certification. We refer to the Voluntary Edition proposed rule for a description of ONC's prior discussion around the Children's Format (79 FR 10930).

In the summer of 2017, the American Academy of Pediatrics (AAP) reviewed the 2015 Format using a robust analytical process and engagement with their members. The result was a prioritized list of eight clinical priorities to support pediatric health care (“Priority List”). In October 2017, ONC held a technical discussion with stakeholders titled “Health IT for Pediatrics” with the specific purpose of obtaining input from an array of stakeholders in an effort to draw correlations between the pediatric providers' clinical priorities identified in the Priority List with the detailed technical requirements outlined in the Children's Format and the capabilities and standards that could be included in certified health IT. Through this collaborative approach, the meeting participants identified a set of priority needs for health IT to support pediatric care based upon those identified by the Priority List and the primary correlation to the Children's Format.

2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care

To support the first part of Section 4001(b) of the Cures Act, ONC considered the historical efforts on the Children's Model EHR Format, the input from stakeholders, and our own technical analysis and review of health IT capabilities and standards to develop a set of recommendations for voluntary certification for health IT for pediatric care. These include eight recommendations related to the Priority List:

  • Recommendation 1: Use biometric-specific norms for growth curves and support growth charts for children.
  • Recommendation 2: Compute weight-based drug dosage.
  • Recommendation 3: Ability to document all guardians and caregivers.
  • Recommendation 4: Segmented access to information.
  • Recommendation 5: Synchronize immunization histories with registries.
  • Recommendation 6: Age- and weight-specific single-dose range checking.
  • Recommendation 7: Transferrable access authority.
  • Recommendation 8: Associate maternal health information and demographics with newborn.

We also developed two additional recommendations beyond the Priority List which relate to other items within the Children's Format that are considered important to pediatric stakeholders. These additional recommendations, which we believe may be supported by certified health IT, are as follows:

  • Recommendation 9: Track incomplete preventative care opportunities.
  • Recommendation 10: Flag special health care needs.

In order to implement the second part of Section 4001(b) of the Cures Act for the adoption of certification criteria to support the voluntary certification of health IT for use by pediatric health care providers, we have identified both the 2015 Edition certification criteria and the new or revised criteria in this proposed rule that we believe support these 10 recommendations for health IT for pediatric care and sites of service. We direct readers to the appendix of this proposed rule for a set of technical worksheets which include a cross-walk of the various criteria specifically associated with each recommendation. These worksheets outline the following information:

  • The alignment of each recommendation to the primary Children's Format [46] item identified by stakeholders.
  • The alignment of each recommendation to the 2015 Edition certification criteria and new or revised criteria described in this proposed rule.
  • Supplemental items from the Children's Format for each recommendation and the related certification criteria.

We invite readers to use these worksheets to inform public comment on the recommendations, the inclusion of specific items from the Children's Format, and the identified certification criteria as they relate specifically to use cases for pediatric care and sites of service. We also seek comment on the following:

1. Relevant gaps, barriers, safety concerns, and resources (including available best practices, activities, and tools) that may impact or support feasibility of the recommendation in practice.

2. Effective use of health IT itself in support of each recommendation as involves provider training, establishing workflow, and other related safety and usability considerations.

3. If any of the 10 recommendations should not be included in ONC's final recommendations for voluntary certification of health IT for pediatric care.

4. Any certification criteria from the Program that is identified for the 10 recommendations that should not be included to support the specific recommendation.

As stated in the worksheets located in the appendix, commenters are encouraged to reference the specific “recommendation number” (1-10) with the corresponding technical worksheet question number in their response. For example, “Recommendation 1—Question 3”.

a. 2015 Edition Certification Criteria

In order to implement the second part of Section 4001(b) of the Cures Act to adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children, we identified the following 2015 Edition certification criteria that support the recommendations. Within the technical worksheets in the appendix of this proposed rule, these criteria are noted under each recommendation to which they are correlated. The 2015 Edition criteria are as follows:

  • “API functionality” criteria (§ 170.315(g)(7)-(g)(9)) which addresses many of the challenges currently faced by patients and by caregivers such as parents or guardians accessing child's health information, including the “multiple portal” problem, by potentially allowing individuals to aggregate health information from multiple sources in a web or mobile application of their choice.
  • “Care plan” criterion (§ 170.315(b)(9)) which supports Start Printed Page 7460pediatric care by facilitating the documentation of electronic health information in a structured format to improve care coordination (80 FR 62648-62649).
  • “Clinical decision support” (CDS) criterion (§ 170.315(a)(9)) which supports pediatric care by enabling interventions based on the capture of biometric data.
  • “Common Clinical Data Set” (adopted in (§ 170.315(b)(4) and § 170.315(b)(5)) which includes optional pediatric vital sign data elements including as optional the reference range/growth curve for three pediatric vital signs—BMI percent per LOINC identifiers for age per sex, weight per length/sex, and head occipital-frontal circumference for children less than three years of age.
  • “Data segmentation for privacy” send criterion and receive criterion (adopted in § 170.315(b)(7) and § 170.315(b)(8)) which provides the ability to: Create a summary record that is tagged at the document level as restricted and subject to re-disclosure; receive a summary record that is document-level tagged as restricted; separate the document-level tagged document from other documents received; and, view the restricted document without having to incorporate any of the data from the document.
  • “Demographics” criterion (§ 170.315(a)(5)) which supports pediatric care through the capture of values and value sets relevant for the pediatric health care setting as well as allowing for improved patient matching which is a key challenge for pediatric care.
  • “Electronic Prescribing” criterion (adopted in § 170.315(b)(3)) which includes an optional Structured and Codified Sig Format, which has the capability to exchange weight-based dosing calculations within the NCPDP SCRIPT 10.6 standard and limits the ability to prescribe all oral, liquid medications in only metric standard units of mL (i.e., not cc) important for enabling safe prescribing practices for children.
  • “Family health history” criterion (§ 170.315(a)(12)) which supports pediatric care because it leverages concepts or expressions for familial conditions, which are especially clinically relevant when caring for children.
  • “Patient health information capture” criterion (§ 170.315(e)(3)) which supports providers' ability to accept health information from a patient or authorized representative. This criterion could support pediatric care through documentation of decision-making authority of a patient representative.
  • “Social, psychological, and behavioral data” criterion § 170.315(a)(15) which supports integration of behavioral health data into a child's record across the care continuum by enabling a user to record, change, and access a patient's social, psychological, and behavioral data based using SNOMED CT® and LOINC® codes.
  • “Transitions of care” criterion (§ 170.315(b)(1)) which supports structured transition of care summaries and referral summaries that help ensure the coordination and continuity of health care as children transfer between different clinicians at different health care organizations or different levels of care within the same health care organization;
  • “Transmission to immunization registries” criterion (§ 170.315(f)(1)) which supports the safe and effective provision of child health care through immunizations and registry linkages. This criterion also provides the ability to request, access, and display the evaluated immunization history and forecast from an immunization registry for a patient. Immunization forecasting recommendations allow for providers to access the most complete and up-to-date information on a patient's immunization history to inform discussions about what vaccines a patient may need based on nationally recommended immunization recommendations (80 FR 62662-62664).
  • “View, download, and transmit to 3rd party” (VDT) criterion (§ 170.315(e)(1)) which supports transferrable access authority for the pediatric health care setting and provides the ability for patients (and their authorized representatives) [47] to view, download, and transmit their health information to a 3rd party.

We note that some of these criteria may be updated based on proposals contained in this proposed rule; however, we believe that prior to any such updates, technology that is currently available and certified to these 2015 Edition criteria can make a significant impact in supporting providers engaged in the health care of children. We invite readers to use the technical worksheets in the appendix to this proposed rule to inform their public comment on the recommendations, the inclusion of specific items from the Children's Format, and the identified 2015 Edition certification criteria as they relate specifically to use cases for pediatric care and sites of service.

b. New or Revised Certification Criteria in This Proposed Rule

In order to implement the second part of Section 4001(b)(iii) of the Cures Act to adopt certification criteria to support the voluntary certification of health information technology for use by pediatric health providers to support the health care of children, we identified new or revised certification criteria in this proposed rule that support the recommendations. These new or revised criteria and standards in this proposed rule that would support pediatric settings include:

  • New API criterion (§ 170.315(g)(10)) which would serve to implement the Cures Act requirement to permit health information to be accessed, exchanged, and used from APIs without special effort (see section IV.B.5 of this proposed rule).
  • New “DS4P” criteria (two for C-CDA ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) and one for FHIR (§ 170.315(g)(11))) that would support a more granular approach to privacy tagging data for health information exchange supported by either the C-CDA- or FHIR-based exchange standards (see section VI.A for a discussion of this criteria in relation to pediatric settings and section VI.B for discussion of these criteria in relation to Opioid Use Disorder).
  • New electronic prescribing certification criterion (§ 170.315(b)(11)), which would supports improved patient safety and prescription accuracy, workflow efficiencies, and increased configurability of systems including functionality that could support pediatric medication management.
  • USCDI (§ 170.213) which enables the inclusion of pediatric vital sign data elements, including the reference range/scale or growth curve for BMI percentile per age and sex, weight for age per length and sex, and head occipital-frontal circumference (and the criteria that include the USCDI).

Each of these proposed criteria are further described in other sections of this proposed rule; however, in this section of this proposed rule we specifically seek comment on the application of these criteria to pediatric use cases in support of our recommendations for the voluntary certification of health IT for pediatric care.Start Printed Page 7461

For example, our proposal for three new 2015 Edition DS4P certification criteria (two for C-CDA ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) and one for FHIR (§ 170.315(g)(11))) could provide functionality to address the concerns of multiple stakeholders in a range of specialty use cases—including pediatric care settings. In this section of this proposed rule, we seek comment specifically related to the inclusion of these criteria in our recommendations. Specifically, stakeholders have expressed the need to—based on the intended recipient of the data—to restrict granular pediatric health data at production. We believe these criteria could, for example, help enable providers to:

  • Limit the sharing of reproductive and sexual health data from an EHR in order to protect the minor's privacy;
  • Prevent disclosure of an emancipated minor's sensitive health information, while also permitting a parent or legal guardian to provide consent for treatment; and
  • Segment child abuse information based on jurisdictional laws, which may have varying information sharing requirements for parents, guardians, and/or other possible legal representatives.

While health care providers should already have processes and workflows in place to address their existing compliance obligations, we recognize that more granular privacy markings at the point of data capture would further support existing and future priorities of pediatric health providers, as well as for multiple medical specialties and sites of service. We also recognize that such point of data capture markings can reduce administrative burden through efficiencies gained in streamlined compliance workflows.

We invite readers to use the technical worksheets in the appendix of this proposed rule to support public comment on the recommendations, the inclusion of specific items from the Children's Format, and the identified proposed new or revised certification criteria as they relate specifically to use cases for pediatric care and sites of service.

However, as discussed, through our experience and engagement with health care providers and health IT developers, we believe that in some cases information resources can aid in implementation in clinical settings. In the past, ONC has worked collaboratively with federal partners, health IT developers, and the health care community to support the development of non-regulatory informational resources that can provide additional support for health IT implementation (see, for example, the ONC Patient Engagement Playbook). Such a resource could include the recommendations and certification criteria here identified and synthesize these technical recommendations with information outside of the Program related to patient safety, usability, privacy and security, and other key considerations for successful implementation of a health IT system within a clinical setting. We believe that the creation of such a resource, in collaboration with clinical and technical stakeholders, would help support the advancement of health IT solutions for use in pediatric care and pediatric settings. We further include additional information on prior ONC initiatives related to health IT for pediatric settings as available on our website at www.healthit.gov/​pediatrics.

B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information

We have identified a need to explore ways to advance health IT across the care continuum to support efforts to fight the opioid epidemic. To that purpose, we seek comment in this proposed rule on a series of questions related to health IT functionalities and standards to support the effective prevention and treatment of opioid use disorder (OUD) across patient populations and care settings.

We recognize the significance of the opioid epidemic confronting our nation and the importance of helping to support health care providers committed to preventing inappropriate access to prescription opioids and providing safe, appropriate treatment.

HHS has a comprehensive strategy to combat the opioid crisis. It consists of five points that are focused on better: Addiction prevention, treatment, and recovery services; data; pain management; targeting of overdose reversing drugs; and research.[48] In support of this strategy, HHS will improve access to prevention, treatment, and recovery support services; target the availability and distribution of overdose-reversing drugs; strengthen public health data reporting and collection; support cutting-edge research; and advance the practice of pain management. To combat the opioid crisis, in October 2018, Congress passed the Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment (SUPPORT) for Patients and Communities Act. It aims to expand treatment, recovery, and prevention initiatives for substance use disorder and also includes interoperability and health IT tools as a key part of the response to this crisis.

We believe health IT offers promising strategies to help medical specialties and sites of service as they combat opioid use disorder (OUD). For example, health IT has the potential to improve adherence to opioid prescribing guidelines and physician adherence to treatment protocols, to increase the safety of prescribing for controlled substances, to enhance clinician access to PDMPs, and to expand access to addiction treatment and recovery support services. Additionally, through the Program, our goal continues to be to improve access to data from disparate sources and help ensure that key data is consistently available to the right person, at the right place, and at the right time across the care continuum. One component of advancing that goal is through technical standards for exchanging health information that form an essential foundation for interoperability.

ONC has heard from stakeholders including policymakers, implementers, health care providers and patient advocacy groups that additional information is needed to assist in planning for the effective use of health IT in OUD prevention and treatment. We additionally recognize stakeholders' interest in the new opioid measures (Query of PDMP measure and Verify Opioid Treatment Agreement measure) included in CMS's Promoting Interoperability Programs (formerly known as the Medicare and Medicaid EHR Incentive Programs). These two measures support HHS initiatives related to the treatment of opioid and substance use disorders by helping health care providers avoid inappropriate prescriptions, improve coordination of prescribing amongst health care providers, and focus on the advanced use of certified health IT in care coordination for OUD prevention and treatment (83 FR 41644).

In order to support these efforts, in this proposed rule we outline a brief overview of some key areas of health IT implementation that could support OUD prevention and treatment. These include consideration of current health IT certification criteria included in the 2015 Edition, revised or new certification criteria as outlined in this proposed rule, and current health IT initiatives underway in the health care industry or health IT industry which intersect with ONC policy goals. In this section of the proposed rule, we request public comment specifically from the perspective of how our existing Program Start Printed Page 7462requirements and proposals in this rulemaking may support use cases related to OUD prevention and treatment and if there are additional areas that ONC should consider for effective implementation of health IT-enabled OUD prevention and treatment. We seek comment from this perspective on the identification of 2015 Edition certification criteria, the proposals for revised or new certification criteria, and the potential future consideration of emerging technologies described in various initiatives.

1. 2015 Edition Certification Criteria

We seek public comment on how the existing 2015 Edition certification criteria as well as proposals within this proposed rule for revised or new criteria support OUD prevention and treatment. Specifically, we seek comment on certification criteria previously adopted in the 2015 Edition that can support clinical priorities, advance interoperability for OUD (including care coordination and the effective use of health IT for the treatment and prevention of OUD). In this proposed rule, we summarize some of these 2015 Edition certification criteria identified and indicate how they support care coordination, the prevention of OUD and overdose, and the detection of opioid misuse, abuse, and diversion.

We have also below identified the proposals for revised or new 2015 Edition criteria within this proposed rule that we believe can support clinical priorities, advance interoperability for OUD (including care coordination and also the effective use of health IT for the treatment and prevention of OUD). We welcome input from stakeholders specifically on these criteria within the context of OUD prevention and treatment, as well as input on the identification of other criteria included either in the 2015 Edition and/or that are proposed in other parts of this rule that may be considered a clinical and interoperability priority for supporting OUD treatment and prevention.

We have identified several 2015 Edition certification criteria available now for certification in the Program which could support care coordination and the prevention and detection of opioid misuse, abuse, and diversion. They are:

  • The “transitions of care” criterion (§ 170.315(b)(1)) supports structured transition of care summaries and referral summaries that help ensure the coordination and continuity of health care as patients transfer between different clinicians at different health care organizations or different levels of care within the same health care organization. This criteria supports the ability to transmit a summary care record to support an individual with OUD upon discharge from an inpatient setting or from a primary care provider to another setting for their care.
  • The “clinical information reconciliation and incorporation” criterion (§ 170.315(b)(2)) allows clinicians to reconcile and incorporate patient health information sent from external sources to maintain a more accurate and up-to-date patient record. This process could help—for example—reduce opioid related errors regarding patients who use multiple pharmacies, have co-morbidity factors, and visit multiple clinicians.
  • The “electronic prescribing” criterion (§ 170.315(b)(3)) provides a way to write and transmit prescription information electronically. This criterion facilitates appropriate opioid prescribing by simplifying the review of prescription information during follow-up visits or transitions to other clinicians, by allowing prescribers to communicate prescription-related messages to pharmacies electronically and by capturing and transmitting medication histories that are shared with PDMPs. In this proposed rule, we propose to update the existing electronic prescribing certification criterion as described in section IV.B.2 of this proposed rule.
  • The “patient health information capture” (§ 170.315(e)(3)) allows clinicians to incorporate unstructured patient generated health data or data from a non-clinical setting into a patient record. The CMS Promoting Interoperability Programs for eligible hospitals includes a new optional measure which is focused on verifying the existence of a signed Opioid Treatment Agreement for certain patients when a controlled substance is prescribed and incorporating it into the record. In the Hospital Inpatient Prospective Payment Systems final rule, CMS recognized this certification criterion's potential to support this goal within a certified health IT system (83 FR 41654).
  • The “social, psychological, and behavioral data” criterion (§ 170.315(a)(15)) can help to provide a more complete view of a patient's overall health status. This is important to help provide a “whole-patient” approach to the treatment of substance use disorders included as part of Medicated-Assisted Treatment (MAT) that involves the use of FDA-approved medications, in combination with counseling and behavioral therapies, to treat individuals recovering from OUD. This data can help to improve care coordination and lead to the identification of appropriate social supports and community resources.

We seek comment on how these criteria and what additional 2015 Edition certification criteria may be considered a clinical and interoperability priority for supporting OUD treatment and prevention. We also seek comment on the value of developing a potential future non- binding informational guide or resource to provide useful information for OUD providers and sites of service related to specific clinical priorities and use cases of focus.

2. Revised or New 2015 Edition Certification Criteria in This Proposed Rule

This proposed rule contains additional proposals to revise or add new criteria to the Program to better support care across the continuum. We believe these criteria and standards, highlighted below, can also support treatment and prevention of OUD. We seek comment specifically on the applicability of these criteria to the OUD use case. They are:

  • USCDI: As detailed in section IV.B.1, we are proposing to adopt the USCDI as a standard (§ 170.213) which would establish a minimum set of data classes (including structured data fields) that are required to be interoperable nationwide, and is designed to be expanded in an iterative and predictable way over time. The USCDI Version 1 (USCDI v1) builds upon the 2015 Edition CCDS and includes a common set of data classes that can be supported by commonly used standards. It includes the 2015 Edition CCDS data elements, such as medications. It also includes two new data classes, titled “clinical notes” and “provenance,” which would help facilitate interoperable exchange and the trustworthiness of the data being exchanged. These enhancements to the comprehensiveness and reliability of the data being exchanged could help empower physicians in the prevention and detection of opioid misuse, abuse, and diversion.

In addition, because we propose to adopt the USCDI as a standard, health IT developers would be allowed to take advantage of the Maintenance of Certification requirements described in section VII.B.5 of this proposed rule. Therefore, the USCDI would have the potential to further benefit clinical priorities and interoperability for OUD, including safe and appropriate opioid prescribing, through the ability to voluntarily implement and use a new version of an adopted standard or Start Printed Page 7463implementation specification so long as certain conditions are met, including the new version being approved by the National Coordinator for use in certification through the Standards Version Advancement Process. We seek comment on how this proposal would further support the access, exchange, and use of additional and future data classes (including structured data fields) in more care and practice settings specifically as related to the prevention and treatment of OUD.

  • Standardized API: We are proposing new API functionality through the adoption of a new API certification criterion (§ 170.315(g)(10)), which serves to implement the Cures Act requirement to permit health information to be accessed, exchanged, and used from APIs without special effort. This criterion would enable efficient exchange of health information using modern internet technologies and thus enable collaborative, patient-driven, integrated care for individuals recovering from OUD.
  • Data Segmentation for Privacy and Consent Management: As discussed in section IV.B.7, we are also proposing to remove the current 2015 Edition DS4P—send (§ 170.315(b)(7)) and DS4P—receive (§ 170.315(b)(8)) certification criteria. We propose to replace these two criteria with three new 2015 Edition DS4P certification criteria (two for C-CDA ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) and one for FHIR (§ 170.315(g)(11))) that would support a more granular approach to privacy tagging data for health information exchange supported by either the C-CDA- or FHIR-based exchange standards. We believe this proposal would offer functionality that is more valuable to providers and patients, especially given the complexities of the privacy law landscape for multiple care and specialty settings. We also believe this proposal could lead to more complete records, contribute to patient safety, and enhance care coordination. Additionally, we believe this proposal may support a more usable display of OUD information at the request of patients within an EHR and we invite input on best practices, including the processes and methods by which OUD information should be displayed.
  • Electronic Prescribing and PDMPs: As discussed in section IV.B.2, we are proposing to remove the current 2015 Edition electronic prescribing certification criterion (§ 170.315(b)(3)) and replace this criterion with a new electronic prescribing certification criterion (§ 170.315(b)(11)) that would support improved patient safety and prescription accuracy, create workflow efficiencies, reduce testing requirements, and increase configurability of systems. This new proposed criterion includes the addition of Risk Evaluation and Mitigation Strategy (REMS) messages. We believe this proposal would help address challenges discussed in the CMS Hospital Inpatient Prospective Payment Systems final rule (83 FR 41651) and Medicare Physician Fee Schedule proposed rule (83 FR 35704) by strengthening clinical and administrative efficiency, helping move the industry forward by adopting more current standards for electronic prescribing, and harmonizing efforts across federal agencies in the prevention and treatment of OUD. In addition, the FDA has enacted an opioids medications REMS program for opioid analgesics [49] mandating prescriber and patient education to encourage proper patient screening and appropriate monitoring. Adoption of the new proposed criterion also supports the efficient and accurate exchange of medication history transactions between providers and pharmacies, and between pharmacies and state PDMPs.

3. Emerging Standards and Innovations

In addition to the certification criteria established in the 2015 Edition final rule and proposed in this rule, ONC is engaged in a number of health IT and standards initiatives exploring innovation and emerging standards to inform future health IT policy. In some cases, these efforts may not be mature enough or best suited for adoption in the Program; however, we seek comment on the potential consideration of these initiatives for future direction of ONC policy.

  • CDS Hooks: Improving how opioids are prescribed through evidence-based guidelines can ensure patients have access to safer, more effective chronic pain treatment while reducing the risk of opioid misuse, abuse, or overdose from these drugs. In response to the critical need for consistent and current opioid prescribing guidelines, the Centers for Disease Control and Prevention (CDC) released the Guideline for Prescribing Opioids for Chronic Pain.[50] While progress has been made in training prescribers and fostering the adoption of the CDC guideline, the President's Opioid Commission [51] acknowledged that “not all states have adopted the guideline, not all physicians are aware of them, and sound opioid prescribing guidelines are far from universally followed.” Clinical decision support (CDS) Hooks is a health IT specification that has the potential to positively affect prescriber adoption of evidence-based prescribing guidelines by invoking patient-specific clinical support from within the clinician's EHR workflow. ONC is currently collaborating with CDC on a project to translate the CDC guideline into standardized, shareable, computable decision support artifacts using CDS Hooks. We recognize that CDS Hooks is still an emerging technology and seek input on the adoption of the CDS Hooks specification for opioid prescribing and OUD prevention and treatment. We also request public comment on other health IT solutions and effective approaches to improve opioid prescription practices and clinical decision support for OUD.
  • Care Plan FHIR Resource: A shared care plan is a critical concept for managing an individual's health across a continuum that includes both clinical and non-clinical settings [52] and can help enable more informed and useful connections among all the stakeholders engaged in preventing or treating OUD. For those in recovery from OUD, the care plan can enable patients to access their care plan information and coordinate their care with approved community care providers which is critical and part of evidence-based recovery treatment services. In 2015, the ONC HITPC recommended that the National Coordinator accelerate the implementation of dynamic, shared, longitudinal care plans that incorporate information from both clinical and non-clinical services and empower individuals to manage their own health and care.[53] A consideration for HHS as part of this earlier recommendation included looking at the future standards development needed to transition from the static care plan documentation (document template in C-CDA R2.1) to a dynamic shared care plan that supports more robust care coordination.[54] We believe HL7 standards and standardized APIs can elevate care coordination and care management across the continuum, Start Printed Page 7464including for those providers without EHRs, whether for opioid use disorder related treatment, primary health, or other problems. Indeed, numerous efforts are underway within HL7 and other collaborations to standardize “care plans” and their content using FHIR and the C-CDA. From a technical perspective and in the context of the proposals focused on the USCDI standard, the ARCH standard, the new proposed API certification criterion at 170.315(g)(10), and the voluntary Standards Version Advancement Process Maintenance of Certification requirement described in section VII.B.5 of this proposed rule, we can see a future where a (g)(10)-certified API would be capable of supporting care plan data. We request public comment on the current maturity of existing and forthcoming technical specifications to support care plan/care plan data as well as specific information that could be prioritized within a future USCDI data class focused on care plans.

In addition to commenting on the criteria noted in this section, we also encourage stakeholders to participate in the ISA process.[55] The ISA represents the model by which ONC coordinates the identification, assessment, and public awareness of interoperability standards and implementation specifications. ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address and encourages pilot testing and other industry experience adopting standards and implementation specifications identified as “emerging” in the ISA. The web-based version of the ISA documents known limitations, preconditions, and dependencies, and provide suggestions for security best practices in the form of security patterns for referenced standards and implementation specifications when they are used to address a specific clinical health IT interoperability need.

Additionally, through the ISA process, stakeholders are encouraged to comment on the outlined standards and implementation specifications, as ONC updates the ISA regularly. ONC has developed and has plans to develop further ISA content to highlight standards and implementation specifications that support the prevention and treatment of OUD/substance use disorder (SUD). For example, the NCPDP SCRIPT standard allows a prescriber to request a patient's medication history from a state PDMP via the RxHistoryRequest and RxHistoryResponse. ONC is also working to enhance the ISA to make it easier for stakeholders to find standards and implementation specifications related to high-priority use cases, such as OUD/SUD. The ISA has a comment process that occurs each year 56 and we encourage stakeholders to participate in that process to comment on other standards and implementation specifications that currently exist in the ISA or that the industry and its stakeholders feel should be added to the ISA that support OUD/SUD prevention, treatment, monitoring, and care coordination.

4. Additional Comment Areas

We further seek comment on effective approaches for the successful dissemination and adoption of standards including the NCPDP SCRIPT 2017071 standard (see section IV.B.2) that can support the exchange of PDMP data for integration into EHRs and also enable further adoption and use of Electronic Prescribing of Controlled Substances (EPCS). Regarding integration of health IT with PDMPs and EPCS, we believe there are real and perceived challenges and opportunities that involve policy and technical components. As we explore these issues in collaboration with industry and stakeholders, we seek comment on the priority challenges and opportunities for these topics and on any technical and policy distinctions, as appropriate.

We also note that there are many federal initiatives separate from ONC proposed rulemaking and the Program that exist within HHS programs including, but not limited to, CMS Medicaid and Medicare programs. For example, Medicare now provides separate payment for psychiatric collaborative care model/behavioral health integration and chronic care management services (see 81 FR 80233, and 80247), and Medicaid issued guidance on leveraging technology to address the opioid crisis at enhanced funding matches [56] and also includes SUD health IT in standard terms and conditions as part of 1115 waiver requirements.

In addition, CMS sought comment for consideration through separate rulemaking in both the 2019 Physician Fee Schedule proposed rule (83 FR 35923) and Hospital Inpatient Prospective Payment Systems proposed rule (83 FR 20528) regarding whether they should adopt the NCPDP SCRIPT 2017071 standard to facilitate future reporting of the proposed Query of PDMP quality measure. As noted in the Hospital Inpatient Prospective Payment Systems final rule, a few commenters supported the use of NCPDP Script Standard Implementation Guide Version 2017071 medication history transactions for PDMP queries and response. Additionally, CMS encourages advances in standards and their use to deliver innovative, interoperable solutions that will seamlessly integrate PDMP query functionality into clinician-friendly, patient- centered CEHRT-enabled workflows that facilitate safer, more informed prescribing practices and improved patient outcomes (83 FR 41651).

We seek comment on how successful implementation of health IT that supports OUD can aid in the achievement of national and programmatic goals, especially where they may align with initiatives across HHS and with stakeholder and industry led efforts.

Finally, we seek comment on a topic that involves health IT for both pediatric care and OUD prevention and treatment—Neonatal Abstinence Syndrome (or NAS). In its September 2018 report, Facing Addiction in America: The Surgeon General's Spotlight on Opioids, the HHS Office of the Surgeon General describes how the incidence of Neonatal Abstinence Syndrome (or NAS), has increased dramatically in the last decade along with increased opioid misuse. Newborns may experience NAS, a withdrawal syndrome, following exposure to drugs while in the mother's womb. NAS is an expected and treatable condition following repeated maternal substance use and abuse during pregnancy, which may have long-term health consequences for the infant.

Immediate newborn NAS signs include neurological excitability, gastrointestinal dysfunction, and autonomic dysfunction. Newborns with NAS are more likely than other babies to have low birthweight and respiratory complications. ONC believes the pediatric clinical health IT recommendations proposed in this rule (including Priority 8, which includes the linkage of health data in records of the mother and newborn) are important for supporting newborns at birth and as they grow and receive care in various settings. As such, we invite comment on:

  • The effective use of health IT itself in support of the NAS use case as involves provider training, establishing Start Printed Page 7465workflow, and other related safety and usability considerations.
  • Existing and potential tools, such as decision support or clinical quality measurement, for supporting children with NAS and on the specific data elements related to the care of these children and use of these tools in practice.
  • Identification of any related criteria and the respective corresponding proposed pediatric recommendation for the voluntary certification of health IT for use in pediatric care that supports the NAS use case including but not limited to recommendation number 8 noted above.

We welcome public comment on these health IT policies, functionalities and standards to support providers engaged in the treatment and prevention of OUD.

VII. Conditions and Maintenance of Certification

Section 4002 of the Cures Act requires the Secretary of HHS, through notice and comment rulemaking, to establish Conditions and Maintenance of Certification requirements for the Program. Specifically, health IT developers or entities must adhere to certain Conditions and Maintenance of Certification requirements concerning information blocking; appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programming interfaces (APIs); real world testing for interoperability; attestations regarding certain Conditions and Maintenance of Certification requirements; and submission of reporting criteria under the EHR reporting program.

A. Implementation

To implement Section 4002 of the Cures Act, we propose an approach whereby the Conditions and Maintenance of Certification express both initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. If these requirements are not met, then the health IT developer may no longer be able to participate in the Program and/or its certified health IT may have its certification terminated. We propose to implement each Cures Act Condition of Certification with further specificity as it applies to the Program. We also propose to establish the Maintenance of Certification requirements for each Condition of Certification as standalone requirements. This approach would establish clear baseline technical and behavior Conditions of Certification requirements with evidence that the Conditions of Certification are continually being met through the Maintenance of Certification requirements.

B. Provisions

1. Information Blocking

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, not take any action that constitutes “information blocking” as defined in section 3022(a) of the PHSA (see 3001(c)(5)(D)(i) of the PHSA). We propose to establish this information blocking Condition of Certification in § 170.401. The Condition of Certification prohibits any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA and proposed in § 171.103.

We clarify that this proposed “information blocking” Condition of Certification and its requirements would be substantive requirements of the Program and would use the definition of “information blocking” established by section 3022(a) of the PHSA and as also proposed in § 171.103, as it relates to health IT developers of certified health IT. In addition to ONC's statutory authority for this Condition of Certification, the HHS Office of the Inspector General (OIG) has both investigatory and enforcement authority over information blocking and may issue civil money penalties for information blocking conducted by health IT developers of certified health IT, health information networks and health information exchanges. OIG may also investigate health care providers for information blocking for which health care providers could be subject to disincentives.

We refer readers to section VII.D of this proposed rule for additional discussion of ONC's enforcement of this and other proposed Conditions and Maintenance of Certification requirements. We also refer readers to section VIII of this proposed rule for our proposals to implement the information blocking provisions of the Cures Act, including proposed § 171.103.

We do not, at this time, propose any associated Maintenance of Certification requirements for this Condition of Certification.

2. Assurances

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of electronic health information (EHI). We propose to implement this Condition of Certification and accompanying Maintenance of Certification requirements in § 170.402. As a Condition of Certification requirement, a health IT developer must comply with the Condition as recited here and in the Cures Act. We refer readers to section VIII of this proposed rule for the proposed reasonable and necessary activities specified by the Secretary, which constitute the exceptions to the information blocking definition.

We also propose to establish more specific Conditions and Maintenance of Certification requirements for a health IT developer to provide assurances that it does not take any action that may inhibit the appropriate exchange, access, and use of EHI. These proposed requirements serve to provide further clarity under the Program as to how health IT developers can provide such broad assurances with more specific actions.

a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities

We propose, as a Condition of Certification, that a health IT developer must ensure that its health IT certified under the ONC Health IT Certification Program (Program) conforms to the full scope of the certification criteria to which its health IT is certified. This has always been an expectation of ONC and users of certified health IT and, importantly, a requirement of the Program. We believe, however, that by incorporating this expectation and requirement as a Condition of Certification under the Program, there would be assurances, and documentation via the “Attestations” Condition and Maintenance of Certification requirements proposed in § 170.406, that all health IT developers fully understand their responsibilities under the Program, including not to take any action with their certified health IT that may inhibit the appropriate exchange, access, and use of EHI. To this point, certification criteria are designed and issued so that certified health IT can support interoperability and the appropriate exchange, access, and use of electronic health information.Start Printed Page 7466

We propose that, as a complementary Condition of Certification, health IT developers of certified health IT must provide an assurance that they have made certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes. More specifically, developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification. Such actions may inhibit the appropriate access, exchange, or use of EHI and are therefore contrary to this proposed Condition of Certification and the statutory provision that it implements. While such actions are already prohibited under the Program (80 FR 62711), making these existing requirements explicit would ensure that health IT developers are required to attest to them on a regular basis pursuant to the Condition of Certification proposed in § 170.406, which will in turn provide additional assurances to the Secretary that developers of certified health IT support and do not inhibit appropriate access, exchange, or use of EHI.

By way of example, actions that would violate this aspect of the proposed Condition include failing to fully deploy or enable certified capabilities; imposing limitations (including restrictions) on the use of certified capabilities once deployed; or requiring subsequent developer assistance to enable the use of certified capabilities, contrary to the intended uses and outcomes of those capabilities (see 80 FR 62711). The Condition would also be violated were a developer to refuse to provide documentation, support, or other assistance reasonably necessary to enable the use of certified capabilities for their intended purposes (see 80 FR 62711). More generally, any action that would be likely to substantially impair the ability of one or more users (or prospective users) to implement or use certified capabilities for any purpose within the scope of applicable certification criteria would be prohibited by this Condition (see 80 FR 62711). Such actions may include imposing limitations or additional types of costs, especially if these were not disclosed when a customer purchased or licensed the certified health IT (see 80 FR 62711).

b. Certification to the “Electronic Health Information Export” Criterion

We propose, as a Condition of Certification requirement, that a health IT developer that produces and electronically manages EHI must certify health IT to the 2015 Edition “electronic health information export” certification criterion in § 170.315(b)(10). We discuss the proposed “electronic health information (EHI) export” criterion in section IV.B.4 of this proposed rule. Further, as a Maintenance of Certification requirement, we propose that a health IT developer that produces and electronically manages EHI must provide all of its customers of certified health IT with health IT certified to the functionality included in § 170.315(b)(10) within 24 months of a subsequent final rule's effective date or within 12 months of certification for a health IT developer that never previously certified health IT to the 2015 Edition, whichever is longer. Consistent with these proposals, we also propose to amend § 170.550 to require that ONC-ACBs certify health IT to the proposed 2015 Edition “EHI export” when the health IT developer of the health IT presented for certification produces and electronically manages EHI.

As discussed in section IV.C.1 of this proposed rule, the availability of the capabilities in the proposed 2015 Edition “EHI export” certification criterion to providers and patients would promote access, exchange, and use of EHI to facilitate health care providers in switching practices and health IT systems and patients' electronic access to all their health information stored by a provider. As such, health IT developers with health IT certified to the proposed 2015 Edition “EHI export” certification criterion that is made available to its customers provides assurances that the developer is not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI.

c. Records and Information Retention

We propose that, as a Maintenance of Certification requirement, a health IT developer must, for a period of 10 years beginning from the date of certification, retain all records and information necessary that demonstrate initial and ongoing compliance with the requirements of the ONC Health IT Certification Program. In other words, records and information should be retained starting from the date a developer first certifies health IT under the Program and applies separately to each unique Health IT Module (or Complete EHR, as applicable) certified under the Program. This retention of records is necessary to verify health IT developer compliance with Program requirements, including certification criteria and Conditions of Certification. We believe that 10 years is an appropriate period of time given that many users of certified health IT participate in various CMS programs, as well as other programs, that require similar periods of records retention. We also refer readers to section VII.D.3.c of this preamble for additional discussion of records access to information necessary to enforce the Conditions and Maintenance of Certification.

In an effort to reduce administrative burden, we also propose, that in situations where applicable certification criteria are removed from the Code of Federal Regulations before the 10 years have expired, records must only be kept for 3 years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10-year retention period. This “3-year from the date of removal” records retention period also aligns with the records retention requirements for ONC-ACBs and ONC-ATLs under the Program.

We encourage comment on these proposals and whether the proposed requirements can provide adequate assurances that certified health IT developers are demonstrating initial and ongoing compliance with the requirements of the Program; and thereby ensuring that certified health IT can support interoperability, and appropriate exchange, access, and use of EHI.

d. Trusted Exchange Framework and the Common Agreement—Request for Information

The Cures Act added section 3001(c)(9) to the PHSA, which requires the National Coordinator to work with stakeholders with the goal of developing or supporting a Trusted Exchange Framework and a Common Agreement (collectively, “TEFCA”) for the purpose of ensuring full network-to-network exchange of health information. Section 3001(c)(9)(B) outlines a process for establishing a TEFCA between health information networks (HINs)—including provisions for the National Coordinator, in collaboration with the NIST, to provide technical assistance on implementation and pilot testing of the TEFCA. In accordance with section 3001(c)(9)(C), the National Coordinator shall publish the TEFCA on its website and in the Federal Register, as well as annually publish on its website a directory of the HINs that have adopted the Common Agreement and are capable of trusted exchange pursuant to the Common Agreement. The process, application, and construction of the Start Printed Page 7467TEFCA are further outlined in section 3001(c)(9)(D), including requiring that the Secretary shall through notice and comment rulemaking, establish a process for HINs that voluntarily adopt the TEFCA to attest to such adoption. We request comment as to whether certain health IT developers should be required to participate in the TEFCA as a means of providing assurances to their customers and ONC that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI. We would expect that such a requirement, if proposed in a subsequent rulemaking, would apply to health IT developers that have a Health IT Module(s) certified to any of the certification criteria in §§ 170.315(b)(1), (c)(1) and (c)(2), (e)(1), (f), and (g)(9) through (11); and provide services for connection to health information networks (HINs). These services could be routing EHI through a HIN or responding to requests for EHI from a HIN.

We have identified health IT developers that certify health IT to the criteria above because the capabilities included in the criteria support access and exchange of EHI. Therefore, we believe such health IT developers, as opposed to a health IT developer that only supports clinical decision support (§ 170.315(a)(9)) with its certified health IT, would be best suited to participate in the Trusted Exchange Framework and adhere to the Common Agreement. Similarly, we believe that many such health IT developers with the identified certified health IT would be in position, and requested by customers, to provide connection services to HINs. When such criteria are met (certified to the identified criteria above and actually providing connection services), participation in the Trusted Exchange Framework and adherence to the Common Agreement are consistent with this Condition and Maintenance of Certification as specified by the Cures Act, the intent of Congress to establish widespread interoperability and exchange of health information without information blocking, and supports ONC's responsibility, as established by the HITECH Act, to develop and support a nationwide health IT infrastructure that allows for the electronic use and exchange of information. More specifically, by participating in the Trusted Exchange Framework and adhering to the Common Agreement, these health IT developers provide assurances that they are not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of EHI. For more information on the Trusted Exchange Framework and Common Agreement, please visit: https://www.healthit.gov/​topic/​interoperability/​trusted-exchange-framework-and-common-agreement.

In consideration of this request for comment, we welcome comment on the certification criteria we have identified as the basis for health IT developer participation in the Trusted Exchange Framework and adherence to the Common Agreement, other certification criteria that would serve as a basis for health IT developer participation in the Trusted Exchange Framework and adherence to the Common Agreement, and whether the current structure of the Trusted Exchange Framework and Common Agreement are conducive to health IT developer participation and in what manner.

3. Communications

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, does not prohibit or restrict communication regarding the following subjects:

  • The usability of the health information technology;
  • The interoperability of the health information technology;
  • The security of the health information technology;
  • Relevant information regarding users' experiences when using the health information technology;
  • The business practices of developers of health information technology related to exchanging electronic health information; and
  • The manner in which a user of the health information technology has used such technology.

We propose to implement this Condition of Certification and its requirements in § 170.403. The Cures Act placed no limitations on the protection of the communications delineated above (referred to hereafter as “protected communications”). As such, we propose to broadly interpret the subject matter of communications that are protected from developer prohibition or restriction as well as the conduct of developers that implicate the protection afforded to communications by this Condition of Certification and discuss this proposed approach in detail below. While we propose to implement a broad general prohibition against developers imposing prohibitions and restrictions on protected communications, we also recognize that there are circumstances where it is both legitimate and reasonable for developers to limit the sharing of information about their products. As such, we propose to allow developers to impose prohibitions or restrictions on protected communications in certain narrowly defined circumstances. In order for a prohibition or restriction on a protected communication to be permitted, we propose that it must pass a two-part test. First, the communication that is being prohibited or restricted must not fall within a class of communication about which no restriction or prohibition would ever be legitimate or reasonable—such as communications required by law, made to a government agency, or made to a defined category of safety organizations—and which we refer to hereafter as “communications with unqualified protection.” Second, to be permitted, a developer's prohibition or restriction must also fall within a prescribed category of circumstances for which we propose it is both legitimate and reasonable for a developer to limit the sharing of information about its products. This would be because of the nature of the relationship between the developer and the communicator or because of the nature of the information that is, or could be, the subject of the communication (referred to hereafter as “permitted prohibitions and restrictions”). A restriction or prohibition that does not satisfy this two-part test will contravene this Condition of Certification. As discussed in more detail below, we propose that this two-part test strikes a reasonable balance between the need to promote open communication about health IT and related business practices, and the need to protect the legitimate interests of health IT developers and other entities.

a. Background and Purpose

This Condition of Certification addresses industry practices that severely limit the ability and willingness of health IT customers, users, researchers, and other stakeholders who use and work with health IT to openly discuss and share their experiences and other relevant information about the performance of health IT, including the ability of health IT to exchange health information electronically. These practices result in a lack of transparency around health IT that can contribute to and exacerbate patient safety risks, system security vulnerabilities, and product performance issues. As discussed below, these issues have been documented and reported on over a number of years.

The challenges presented by health IT developer actions that prohibit or Start Printed Page 7468restrict communications have been examined for some time. The problem was identified in a 2012 report by the Institute of Medicine of the National Academies (IOM) entitled “Health IT and Patient Safety: Building Safer Systems for Better Care” [57] (IOM Report). The IOM Report stated that health care providers, researchers, consumer groups other health IT users lack information regarding the functionality of health IT.[58] The IOM Report observed, relatedly, that many developers restrict the information that users can communicate about developers' products through nondisclosure clauses, confidentiality clauses, intellectual property protections, hold-harmless clauses, and other boilerplate contract language.[59] Importantly, the IOM Report found that such clauses discourage users from sharing information about patient safety risks related to health IT, which significantly limits the ability of health IT users to understand how health IT impacts patient safety.[60] The report stressed the need for health IT developers to enable the free exchange of information regarding the experience of using their health IT products, including the sharing of screenshots.[61]

Other close observers of health IT have similarly noted that broad restrictions on communications can inhibit the communication of information about errors and adverse events.[62] Concerns have also been raised by researchers of health IT products,[63] who emphasize that confidentiality and intellectual property provisions in contracts often place broad and unclear limits on authorized uses of information related to health IT, which in turn seriously impacts the ability of researchers to conduct and publish their research.[64]

The issue of health IT developers prohibiting or restricting communications about health IT has been the subject of a series of hearings by the Senate Committee on Health, Education, Labor and Pensions (HELP Committee), starting in the spring of 2015. During several hearings, stakeholders emphasized the lack of transparency around the performance of health IT in a live environment, noting that this can undermine a competitive marketplace, hinder innovation, and prevent improvements in the safety and usability of the technology.[65] [66] Additionally, the HELP Committee indicated serious concerns regarding the reported efforts of health IT developers to restrict, by contract and other means, communications regarding user experience, including information relevant to safety and interoperability.[67] When one Senator asked a panel of experts—which included a health IT developer—if there were any reasons for health IT contracts to have confidentiality clauses restricting users of health information technology from discussing their experience of using the health IT, all panel members agreed that such clauses should be prohibited.[68]

Prior to the HELP Committee hearings described above, the issue of developers prohibiting and restricting communications about the performance of their health IT was also addressed in House Energy and Commerce Committee hearings when committee members heard testimony and held discussions related to the Cures Act.[69] Commentary by witnesses at the hearings emphasized the need to ensure that health IT products are safe and encouraged the availability of information around health IT products to improve quality and ensure patient safety.

Developer actions that prohibit or restrict communications about health IT have also been the subject of investigative reporting.[70] A September 2015 report examined eleven contracts between health systems and major health IT developers and found that, with one exception, all of the contracts protected large amounts of information from being disclosed, including information related to safety and performance issues.[71] The report stated that broad confidentiality and intellectual property protection clauses were the greatest barriers to allowing the communication of information regarding potential safety issues and adverse events.[72]

Finally, ONC has itself been made aware of health IT developer contract language that purports to prohibit the disclosure of information about health IT, including even a customer's or user's opinions and conclusions about the performance and other aspects of the technology. Our extensive interactions with health care providers, researchers, and other stakeholders consistently indicate that such terms are not uncommon and that some developers may actively enforce them and engage in other practices to discourage communications regarding developers' health IT products and related business practices.

This proposed Condition of Certification is needed to significantly improve transparency around the functioning of health IT in the field. This will help ensure that the health IT ultimately selected and used by health care providers and others functions as expected, is less likely to have safety issues or implementation difficulties, enables greater interoperability of health information, and more fully allows users to reap the benefits of health IT utilization, including improvements in care and quality, and reductions in costs.

b. Condition of Certification Requirements

i. Protected Communications and Communicators

We propose that the protection afforded to communicators under this Condition of Certification would apply irrespective of the form or medium in which the communication is made. Developers must not prohibit or restrict communications whether written, oral, electronic or by any other method if they concern protected communications, unless permitted otherwise by this Condition of Start Printed Page 7469Certification. Similarly, this Condition of Certification does not impose any limit on the identity of the communicators that are able to benefit from the protection afforded, except that employees and contractors of a health IT developer may be treated differently when making communications that are not afforded unqualified protection under § 170.403(a)(2)(i). This Condition of Certification is not limited to communications by health IT customers (e.g., providers) who have contracts with health IT developers. Entities or individuals who enter into agreements with a developer in connection with the developer's health IT—for example, a data analytics vendor who is required to sign a non-disclosure agreement before being granted access to the developer's health IT—would also be covered by the protection afforded to communicators under this Condition of Certification. Patients, health IT researchers, industry groups, and health information exchanges would be able to make protected communications about the health IT free of impermissible prohibitions or restrictions. Similarly, the Condition of Certification would also extend to potential customers of health IT who are provided with product or software demonstrations, irrespective of whether they proceed with the acquisition of the technology. Examples of other protected communications include, but are not limited to:

  • A post made to an online forum;
  • the sharing of screenshots, subject to certain proposed restrictions on their general publication;
  • an unattributed written review by a health IT user;
  • a quote given by a health care executive to a journalist;
  • a presentation given at a trade show;
  • a social media post;
  • a product review posted on a video-sharing service such as YouTube;
  • the statements and conclusions made in a peer-reviewed journal; and
  • private communications made between health IT customers about the health IT.

ii. Protected Subject Areas

The Cures Act (and § 170.403(a)(1)) identifies a list of subject areas about which developers cannot prohibit or restrict communications. These subject areas address health IT performance and usability, health IT security, and the business practices related to exchanging EHI. For the reasons discussed below, we propose that the terms used to describe the subject areas should be construed broadly, consistent with the scope of communications that Congress specified in the Act. We encourage comment on whether the types of subject matter we identify below are adequate to protect the full range of communications contemplated by the Cures Act.

(A) Usability of Health Information Technology

The term “usability” is not defined in the Cures Act nor in any other relevant statutory provisions. In the National Institute of Standards and Technology (NIST) Usability Initiative, NIST describes “usability” of health IT by referencing the ISO [73] standard, ISO9241: Usability is “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” [74] Separately, HIMSS [75] has recognized the following principles of software usability: Simplicity; Naturalness; Consistency; Forgiveness and Feedback; Effective Use of Language; Efficient Interactions; Effective Information Presentation; Preservation of Context; and Minimize Cognitive Load.[76] As these organizations have expressed, there are a multitude of factors that contribute to any judgment about “usability,” and any assessment about the usability of health IT should appropriately rest on the factors contributing to the effectiveness, efficiency, and performance offered. As such, we propose that the “usability” of health IT be construed broadly to include both an overall judgment on the “usability” of a particular health IT product, as well as any factor that contributes to usability. Factors of usability that could be the subject of protected communications include, but are not limited to: The user interface (i.e., what a user sees on the screen, such as layout, controls, graphics and navigational elements); ease of use (e.g., how many clicks); how the technology supports users' workflows; the organization of information; cognitive burden; cognitive support; error tolerance; clinical decision support; alerts; error handling; customizability; use of templates; mandatory data elements; the use of text fields; and customer support.

(B) Interoperability of Health Information Technology

Section 3000(9) of the PHSA, as amended by the Cures Act, provides a definition of “interoperability” that describes a type of health IT that demonstrates the necessary capabilities to be interoperable. For the purposes of this Condition of Certification, we propose that protected communications regarding the “interoperability of health IT” would include communications about whether a health IT product and associated developer business practices meet the interoperability definition described in section 3000(9) of the PHSA, including communications about aspects of the technology or developer that fall short of the expectations found in that definition. This will include communications about the interoperability capabilities of health IT and the practices of a health IT developer that may inhibit the access, exchange, or use of EHI, including information blocking.

(C) Security of Health IT

The security of health information technology is primarily addressed under the HIPAA Security Rule,[77] which establishes national standards to protect individuals' electronic protected health information (ePHI) that is created, received, maintained, or transmitted by a covered entity or business associate. Covered entities and business associates must ensure the confidentiality, integrity, and availability of all such ePHI; protect against any reasonably anticipated threats or hazards to the security or integrity of such information; and protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the HIPAA Privacy Rule.[78] HIPAA requires that health IT developers, to the extent that they are business associates of HIPAA-covered entities, implement appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and security of ePHI.

We propose that the matters that fall within the topic of health IT security should be broadly construed to include any safeguards, whether or not required by the Security Rule, that may be implemented (or not implemented) by a developer to ensure the confidentiality, Start Printed Page 7470integrity, and security of the wider set of EHI (including ePHI), together with the health IT product's performance regarding security. For example, a developer may not prohibit or restrict a potential communicator from communicating about, without limitation:

  • The approach to security adopted for the health IT at issue (e.g., architectural approach or authentication methodology);
  • the resilience of the health IT;
  • identified security flaws in the developer's health IT; or
  • the response to cyber threats or security breaches by the developer.

(D) User Experiences

The phrase “user experience” is not defined in the Cures Act nor in any other relevant statutory provisions. We propose to afford these terms their ordinary meaning. To qualify as a “user experience,” the experience must be one that is had by a user of health IT. However, beyond this, we do not propose to qualify the types of experiences that would receive protection under the Condition on the basis of the “user experience” subject area. This reflects the great variety of experiences that users may have with health IT and the often subjective nature of such experiences. Thus, we believe that if the user had the experience, the experience is relevant.

To illustrate the breadth of potential user experiences that would be protected by this Condition of Certification, we propose that communications about “relevant information regarding users' experiences when using the health IT” would encompass, for example, communications and information about a person or organization's experience acquiring, implementing, using, or otherwise interacting with health IT. This includes experiences associated with the use of the health IT in the delivery of health care, together with administrative functions performed using the health IT. User experiences would also include the experiences associated with configuring and using the technology throughout implementation, training, and in practice. Further, user experiences would include patients' and consumers' user experiences with consumer apps, patient portals, and other consumer-facing technologies. To be clear, a “relevant user experience” includes any aspect of the health IT user experience that could positively or negatively impact the effectiveness or performance of the health IT.

(E) Manner in Which a User Has Used Health IT

We propose that protected communications regarding the “manner in which a user has used health IT” would encompass any information related to how the health IT has been used in practice. This subject area largely overlaps with the matters covered under the “user experience” subject area but may include additional perspectives or details beyond those experienced by a user of health IT. Types of information that would fall within this subject area include but are not limited to:

  • Information about a work-around implemented to overcome an issue in the health IT;
  • customizations built on top of core health IT functionality;
  • the specific conditions under which a user used the health IT, such as information about constraints imposed on health IT functionality due to implementation decisions; and
  • information about the ways in which health IT could not be used or did not function as was represented by the developer.

(F) Business Practices Related to Exchange

We propose that the subject matter of “developer business practices related to exchanging electronic health information” should be broadly construed to include developer policies and practices that facilitate the exchange of electronic health information, and developer policies and practices that impact the ability of health IT to exchange health information. We further propose That the exchange of electronic health information encompasses the appropriate and timely sharing of electronic health information.

We propose that protected communications include, but are not limited to:

  • The costs charged by a developer for products or services that support the exchange of electronic health information (e.g., interface costs, API licensing fees and royalties, maintenance and subscription fees, transaction or usage-based costs for exchanging information);
  • the timeframes and terms on which developers will or will not enable connections and facilitate exchange with other technologies, individuals, or entities, including other health IT developers, exchanges, and networks;
  • the developer's approach to participation in health information exchanges and/or networks;
  • the developer's licensing practices and terms as it relates to making available APIs and other aspects of its technology that enable the development and deployment of interoperable products and services; and
  • the developer's approach to creating interfaces with third-party products or services, including whether connections are treated as “one off” customizations, or whether similar types of connections can be implemented at a reduced cost.

Importantly, we further propose that information regarding business practices related to exchanging electronic health information would include information about the switching costs imposed by a developer, as we are aware that the cost of switching health IT is a significant factor impacting health care providers adopting the most exchange-friendly health IT products that are available.

iii. Meaning of “Prohibit or Restrict”

The terms “prohibit” and “restrict” are not defined in the Cures Act or in any other relevant statutory provisions. As discussed in detail below, communications can be prohibited or restricted through contractual terms or agreements (e.g., non-disclosure agreements, non-disparagement clauses) as well as through conduct, including punitive or retaliatory business practices that are designed to create powerful disincentives to engaging in communications about developers or their products. Therefore, we propose that this Condition of Certification would not be limited to only formal prohibitions or restrictions (such as by means of contracts or agreements) and would encompass any conduct by a developer that would be likely to restrict a communication or class of communications protected by this Condition, as discussed in detail below.

The conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication. That is, conduct by a developer that may be perceived as intimidating or punitive would not implicate this Condition of Certification unless that conduct was designed to directly or indirectly influence the making of a protected communication. Similarly, health IT contracts may include terms that govern the manner in which the parties conduct themselves, and those terms would not implicate this Condition of Certification unless the operative effect of a term was to restrict or prohibit a protected communication. For abundant clarity, we note that the fact that a customer's health IT product is not performing in the manner the customer expected, or in the manner Start Printed Page 7471that the developer promised, would not, in itself be evidence that the developer is engaging in conduct that restricts or prohibits a protected communication. Rather, a nexus must exist between the alleged poor performance and the making of (or attempting or contemplating to make) a protected communication.

We note that contractual prohibitions or restrictions on communications can, in limited circumstances, be legitimate and serve an important role in protecting proprietary information and intellectual property that are essential for health IT developers to innovate and compete. On this basis, we propose to permit certain types of prohibitions and restrictions, subject to strict conditions to ensure that they are narrowly tailored and do not restrict protected communications. These permitted prohibitions and restrictions are discussed in section VII.B.3.b.v below.

(A) Prohibitions or Restrictions Arising by Way of Contract

The principal way that health IT developers can control the disclosure of information about their health IT is through contractual prohibitions or restrictions. Such prohibitions or restrictions can arise in contractual provisions that address, for example, confidentiality obligations, intellectual property protections, hold-harmless requirements, nondisclosure obligations, non-compete obligations, and publicity rights.

There are different ways that contractual prohibitions or restrictions arise. In some instances a contractual prohibition or restriction will be expressed, and the precise nature and scope of the prohibition or restriction will be explicit from the face of the contract or agreement. For example, a contract will say that the health IT customer must not disclose screenshots of the health IT. However, more often, a contract will impose prohibitions or restrictions in less precise terms. For example, a health IT contract might use broad language when describing the information or materials that customers and users are forbidden from disclosing pursuant to a confidentiality clause, casting a vague net over the developer's “proprietary” information and purporting to cover information that may be neither confidential, secret, nor protected by law. A contract does not need to expressly prohibit or restrict a protected communication in order to have the effect of prohibiting or restricting that protected communication. The use of broad or vague language that obfuscates the types of communications that can and cannot be made may be treated as a prohibition or restriction if it has the effect of restricting legitimate communications about health IT.

Restrictions and prohibitions found in contracts used by developers to sell or license their health IT products can apply to customers directly and can require that the customer “flow-down” obligations onto the customer's employees, contractors, and other individuals or entities that use or work with the developer's health IT. Such contract provisions would not comply with this Condition of Certification if they prohibit or restrict protected communications. Prohibitions or restrictions on communications can also be found in separate nondisclosure agreements (NDAs) that developers require their customers—and in some instances the users of the health IT—to enter into in order to receive or access the health IT. We propose that such agreements are covered by this Condition of Certification. Finally, health IT developers typically may require third-party contractors used by their customers (such as a data analytics vendor engaged by a health care provider to analyze the provider's data) to enter into a NDA with the developer before commencing their contract activities. In some extreme cases, the employees of these third-party contractors are required to sign NDAs in their personal capacities. These NDAs typically include obligations that prohibit or restrict communications about the developer's health IT products, and we propose that any such prohibitions or restrictions within the context of protected communications as defined here would be subject to this Condition of Certification.

(B) Prohibitions or Restrictions That Arise by Way of Conduct

We are aware that some health IT developers engage in conduct that has the effect of prohibiting or restricting protected communications. This conduct may arise despite the developer's contract and/or business associate agreement being silent on, or even expressly permitting, the protected communication. The effect of such conduct can be significant, as health care providers are dependent on their health IT developer in order to receive critical software updates or other maintenance services, and sometimes have little bargaining power. Similarly, a third-party developer is dependent on a health IT developer's authorization in order to perform work in connection with the developer's health IT.

We propose that conduct that has the effect of prohibiting or restricting a protected communication would be subject to this Condition of Certification. We emphasize that, as discussed above, the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication. As such, developer conduct that was alleged to be intimidating, or health IT performance that was perceived to be substandard, would not, in and of itself, implicate this Condition of Certification unless there was some nexus between the conduct or performance issue and the making of (or attempting or threatening to make) a protected communication. Examples of conduct that could implicate this Condition of Certification include, but are not limited to:

  • Taking steps to enforce, including by threatening to enforce, a right arising under contract that contravenes this Condition of Certification.
  • Taking steps to enforce, including by threatening to enforce, a legal right that purports to prohibit or restrict a protected communication. This would include, for example, the making of threats, such as via a cease and desist letter, to a researcher who has made a protected communication.
  • Employing a technological measure (within the meaning of 17 U.S.C. 1201) that a user would have to circumvent in order to make a protected communication, for example, a technological measure that a health IT user would need to circumvent in order to take a screenshot of the developer's health IT.
  • Discouraging the making of protected communications by:

○ Making threats against a health care customer (e.g., by threatening to withhold the latest version of the developer's software) in response to the customer making or attempting to make a protected communication.

○ Taking retaliatory action against a person or entity that has made a protected communication (e.g., withholding support, delaying the provider's adoption of a new software release, or removing a provider from the developer's “preferred customer” list).

  • Having policies that disadvantage persons or entities that make protected communications (e.g., a policy that bars a provider from qualifying for the developer's “preferred customer” list if it shares screenshots in a manner protected by this Condition of Certification).
  • Refusing to publish—or refusing to remove or delete—protected communications made in an online forum that the developer moderates or controls.Start Printed Page 7472
  • Causing the removal or deletion of a protected communication from any publication (e.g., a YouTube Copyright Take-down Notice that does not raise a legitimate copyright claim).

iv. Communications With Unqualified Protection

We propose, and discuss below, a narrow class of communications—consisting of five specific types of communications—that would receive unqualified protection from developer prohibitions or restrictions. With respect to communications with unqualified protection, a developer would be prohibited from imposing any prohibition or restriction. As discussed below, we propose that this narrow class of communications warrants unqualified protection because of the strength of the public policy interest being advanced by the communication and/or the sensitivity with which the identified recipient treats, and implements safeguards to protect the confidentiality and security of, the information received. A developer that imposes a prohibition or restriction on a communication with unqualified protection would fail the first part of the two-part test for allowable prohibitions or restrictions, and as such would contravene the Condition of Certification.

(A) Disclosures Required by Law

We propose that where a communication relates to subject areas enumerated in § 170.403(a)(1) and there are federal, state, or local laws that would require the disclosure of information related to health IT, developers must not prohibit or restrict in any way protected communications made in compliance with those laws. We note that we expect that most health IT contracts would allow for, or at the very least not prohibit or restrict, any communication or disclosure that is required by law, such as responding to a court or Congressional subpoena, or a valid warrant presented by law enforcement. We further propose that if required by law, a potential communicator should not have to delay any protected communication under this Condition of Certification. Furthermore, we propose that the reasonable limitations and prohibitions that are discussed below and permitted by § 170.403(a)(2) do not apply to these types of protected communications.

(B) Communicating Information About Adverse Events, Hazards, and Other Unsafe Conditions to Government Agencies, Health Care Accreditation Organizations, and Patient Safety Organizations

It is well established that there is a strong public interest in allowing open communication of information regarding health care hazards, adverse events, and unsafe conditions. Given the central role played by health IT in the delivery of care, information about health IT is a critical component of any investigation into the cause of hazards, adverse events, or unsafe conditions. On the basis of this public policy interest alone, we propose there is an overwhelming interest in ensuring that all communications about health IT that are necessary to identify patient safety risks, and to make health IT safer, not be encumbered by prohibitions or restrictions imposed by health IT developers that may affect the extent or timeliness of communications. In addition to the public policy interest in promoting uninhibited communications about health IT safety, the recognized communication channels for adverse events, hazards, and unsafe conditions provide protections that help ensure that any disclosures made are appropriately handled and kept confidential and secure. Indeed, the class of recipients to which the information can be communicated under this category of communications with unqualified protection should provide health IT developers with comfort that there is very little risk of such communications prejudicing the developer's intellectual property rights. For example, government agencies impose appropriate controls on information they receive, mitigating any risk that developers may feel arises from the disclosure of information about their health IT. Similarly, accrediting bodies for health care delivery observe strict confidentiality policies for information received or developed during the accreditation process and in connection with complaints received.

Finally, the Patient Safety and Quality Improvement Act of 2005 (PSQIA) [79] provides for privilege and confidentiality protections for information that meets the definition of patient safety work product (PSWP). This means that PSWP may only be disclosed as permitted by the PSQIA and its implementing regulations. We clarify that to the extent activities are conducted in accordance with the PSQIA, its implementing regulation, and section 4005(c) of the Cures Act, no such activities shall be construed as constituting restrictions or prohibitions that contravene this Condition of Certification.

We understand that the nature of the information about health IT that would ordinarily be disclosed by a health care provider when reporting an adverse event, hazard, or unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations, would not ordinarily contain intellectual property or trade secrets. Notwithstanding this, in light of the public policy interest and established reporting mechanisms described above, we do not consider the potential inclusion of intellectual property or trade secrets in the communication should prohibit or restrict a health care provider from making a complete and timely report. For example, proposed § 170.403(a)(2)(ii)(D) permits developers to impose certain restrictions on the general publication of screenshots, but we do not consider that such restrictions should be permitted when the communication is made for one of the purposes, and to one of the recipients, identified in § 170.403(a)(2)(i)(B).

We seek comment on whether the unqualified protection afforded to communications made to a patient safety organizations about adverse events, hazards, and other unsafe conditions should be limited. Specifically, we seek comment on whether the unqualified protection should be limited by the nature of the patient safety organization to which a communication can be made, or the nature of the communication that can made—such as limiting to only material that was created as PSWP.

(C) Communicating Information About Cybersecurity Threats and Incidents to Government Agencies

We propose that if health IT developers were to impose prohibitions or restrictions on the ability of any person or entity to communicate information about cybersecurity threats and incidents to government agencies, such conduct would not comply with this Condition of Certification. Government agencies such as the United States Computer Emergency Readiness Team (US-CERT) respond to and protect both the government and private industry from cyber threats. Their work helps protect the entire health care system from cybersecurity threats and relies on the timely reporting of security issues and vulnerabilities by health care Start Printed Page 7473providers and health IT users. These agencies impose appropriate controls on information they receive, which mitigates any risk that developers may feel arises from the disclosure of information about their health IT. The US-CERT, for example, provides secure forms for such reporting, and we are confident that reporting security incident information to US-CERT and other government agencies would be unlikely to pose any threat to health IT developer intellectual property or trade secrets. Additionally, the information likely reported regarding such an incident would generally not reveal trade secrets. Where circumstances may require collection of more sensitive and confidential information related to a developer's intellectual property, we believe that appropriate protections would likely apply and that the public benefit of thoroughly investigating and addressing cybersecurity issues outweighs any potential harm.

Communications about security issues related to health IT may alert nefarious individuals or entities to the existence of a security vulnerability which could be exploited before a developer has time to fix the vulnerability. However, we propose that this concern must be balanced against the imperative of ensuring that health IT customers are aware of security vulnerabilities so that they can respond by deploying reactive measures independent of the developer, such as ceasing health information exchange with a compromised system. We seek comment on whether it would be reasonable to permit health IT developers to impose limited restrictions on communications about security issues so as to safeguard the confidentiality, integrity, and security of eHI. For example, should health IT developers be permitted to require that health IT users notify the developer about the existence of a security vulnerability prior to, or simultaneously with, any communication about the issue to a government agency?

(D) Communicating Information About Information Blocking and Other Unlawful Practices to a Government Agency

As in the circumstances described above, we believe that the public benefit associated with the communication of information to government agencies on information blocking, or any other unlawful practice, outweighs any concerns developers might have about the disclosure of information about their health IT. We believe that reporting information blocking, as well as other unlawful practices, to a government agency would not cause an undue threat to a health IT developer's intellectual property or trade secrets. Generally speaking, agencies collecting reports would protect all information received and keep it confidential to the extent permitted by law.

(E) Communicating Information About a Health IT Developer's Failure To Comply With a Condition of Certification or Other Program Requirement

We propose that the benefits to the public and to users of health IT of communicating information about a health IT developer's failure to comply with a Condition of Certification or other Program requirement (45 CFR part 170) justify prohibiting developers of health IT from placing any restrictions on such protected communications. Information regarding the failure of a health IT product to meet any Condition of Certification or other Program requirement is vital to the effective performance and integrity of the Program, which certifies that health IT functions consistent with its certification. While the current procedures for reporting issues with certified health IT encourage providers to contact developers in the first instance to address certification issues, users of health IT should not hesitate to contact ONC-Authorized Certification Bodies (ONC-ACBs), or ONC itself, if the developer does not provide an appropriate response, or the matter is of a nature that should be immediately reported to an ONC-ACB or to ONC.

v. Permitted Prohibitions and Restrictions

We propose that, except for communications with unqualified protection discussed above and enumerated in § 170.403(a)(2)(i), health IT developers would be permitted to impose certain narrow kinds of prohibitions and restrictions discussed below and specified in § 170.403(a)(2)(ii). We believe this policy strikes a reasonable balance between the need to promote open communication about health IT and related business practices and the need to protect the legitimate interests of health IT developers and other entities. Specifically, with the exception of communications with unqualified protection, developers would be permitted to prohibit or restrict the following communications, subject to certain conditions:

  • Communications of their own employees;
  • Disclosure of non-user-facing aspects of the software;
  • Certain communications that would infringe the developer's or another person's intellectual property rights;
  • Publication of screenshots in very narrow circumstances; and
  • Communications of information that a person or entity knows only because of their participation in developer-led product development and testing.

As discussed in detail in the sections that follow, the proposed Condition of Certification carefully delineates the circumstances under which these types of prohibitions and restrictions would be permitted, including certain associated conditions that developers would be required to meet. To be clear, any prohibition or restriction not expressly permitted would violate the Condition. Additionally, it would be the developer's burden to demonstrate to the satisfaction of ONC that the developer has met all associated requirements. Further, as an additional safeguard, we propose that where a developer seeks to avail itself of one of the permitted types of prohibitions or restrictions, the developer must ensure that potential communicators are clearly and explicitly notified about the information and material that can be communicated, and that which cannot. We propose this would mean that the language of health IT contracts must be precise and specific. Contractual provisions or public statements that support a permitted prohibition or restriction on communication should be very specific about the rights and obligations of the potential communicator. Contract terms that are vague and cannot be readily understood by a reasonable health IT customer will not benefit from the qualifications to this Condition of Certification outlined below.

(A) Developer Employees and Contractors

We recognize that health IT developer employees, together with the entities and individuals who are contracted by health IT developers to deliver products and/or services (such as consultants), may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties. We also recognize that the proper functioning of a workforce depends, at least in part, on the ability of an employer to regulate how and when the organization communicates information to the public, and that employees owe confidentiality obligations to their employers. We propose that on this basis, developers are permitted to impose prohibitions or restrictions on the communications of employees and Start Printed Page 7474contractors to the extent that those communications fall outside of the class of communications with unqualified protection as discussed above.

(B) Non-User-Facing Aspects of Health IT

The purpose of this Condition of Certification is to ensure that health IT users and other potential communicators are not restrained in their ability to communicate—publicly or privately—about certain protected subject areas. We propose that this purpose can generally be achieved without communicators disclosing information about those parts of health IT that are legally protected trade secrets. As such, we propose this Condition of Certification will permit health IT developers to impose prohibitions and restrictions on communications that are not communications with unqualified protection to the extent necessary to ensure that communications do not disclose “non-user-facing aspects of health IT.”

A “non-user-facing aspect of health IT” is, for the purpose of this Condition of Certification, an aspect of health IT that is not a “user-facing aspect of health IT.” A “user-facing aspect of health IT” means those aspects of health IT that that are disclosed and evident to anyone running, using, or observing the operation of health IT. That is, a user-facing aspect of health IT comprises those aspects of the health IT that are manifest in how the health IT software works. User-facing aspects of health IT include the design concepts and functionality that is readily ascertainable from the health IT's user interface and screen display. They do not include those parts of the health IT that are not exposed to persons running, using, or observing the operation of the health IT. We propose that non-user-facing aspects of health IT would include source and object code, software documentation, design specifications, flowcharts, and file and data formats. We welcome comments on whether these and other aspects of health IT should be treated as not being user-facing.

For clarity, we note that the terminology of “user-facing aspects of health IT” is not intended to afford only health IT users with specific protections against developer prohibitions or restrictions on communications. Rather, the terminology is agnostic as to the identity of the communicator and is instead focused on describing those aspects of health IT that are readily ascertainable from the health IT's user interface and screen display. Numerous other potential communicators will also be exposed to “user-facing aspects of health IT,” such as third-party contractors, health information exchange organizations, recipients of a software demonstration, and trade groups or researchers that observe the operation of health IT in the field.

We propose that this approach reasonably implements the Cures Act, which, in direct response to strict confidentiality obligations, broad intellectual property clauses, and non-disclosure provisions in EHR contracts, identified a list of protected subject areas for disclosure (enumerated at section 3001(c)(5)(D)(iii) of the PHSA) that largely targeted the aspects of health IT that are apparent to, and known by, individuals and entities that use or interact with health IT. We propose that if a health IT user were prohibited from describing the user-facing aspects of their health IT product, they could not sensibly communicate useful information about the usability or interoperability of the product, or their experiences as a health IT user. These subject areas are fundamentally tied to the way that the health IT product works, its design, and its functionality.

Protecting the communication of “user-facing aspects of health IT” is also consistent with the treatment of software products under trade secret law, where the public-facing aspects of software products are not generally considered secret because they are evident to anyone running the software program. Moreover, this approach is appropriate given the manner in which health IT is deployed and used by health IT customers. Unlike software products that are deployed and used in a cloistered setting where access to the software is highly restricted, health IT is typically deployed in a setting in which the operation of the health IT can be readily observed by a wide range of persons. Health IT used in a physician's consulting room can be observed by the patient. Health IT deployed in a hospital can be observed by numerous individuals in addition to those who are “authorized users” of the health IT system, including, for example, the patient, the patient's family, volunteer staff, law enforcement, and clergy. As such, because health IT is of a nature that license terms or nondisclosure obligations do not act as a genuine control over the disclosure of those aspects of the software that are “user-facing,” communications about such aspects should be afforded protection from developer prohibitions and restrictions under this proposed Condition of Certification.

(C) Intellectual Property

Many aspects of health IT—including software and documentation—will contain intellectual property that belongs to the health IT developer (or a third party) and is protected by law. Health IT products may have portions in which copyrighted works exist, or that are subject to patent protection. As in other technology sectors, health IT developers place a high value on their intellectual property and go to significant lengths to protect it, including intellectual property provisions in their health IT contracts.

This Condition of Certification is not intended to operate as a de facto license for health IT users and others to act in any way that might infringe the legitimate intellectual property rights of developers. Indeed, we propose that health IT developers are permitted to prohibit or restrict communications that would infringe their intellectual property rights so long as the communication in question is not a communication with unqualified protection. However, any prohibition and restriction imposed by a developer must be no broader than legally permissible and reasonably necessary to protect the developer's legitimate intellectual property interests. We are aware that some health IT contracts contain broad intellectual property provisions (and related terms, such as nondisclosure provisions) that purport to prevent health IT customers and users from using copyright material in ways that are lawful. On this basis, while we are providing an exception for the protection of intellectual property interests, we want to clarify that under this Condition of Certification health IT developers are not permitted to prohibit or restrict, or purport to prohibit or restrict, communications that would be a “fair use” of any copyright work comprised in the developer's health IT. That is, a developer is not permitted to prohibit or restrict communications under the guise of copyright protection (or under the guise of a confidentiality or non-disclosure obligation) when the communication in question makes a use of the copyright material in a way that would qualify that use as a “fair use.” [80]

We welcome comments on whether an appropriate balance has been struck between protecting legitimate intellectual property rights of developers and ensuring that health IT customers, users, researchers, and other stakeholders who use and work with health IT can openly discuss and share their experiences and other relevant Start Printed Page 7475information about the performance of health IT.

(D) Faithful Reproductions of Health IT Screenshots

We propose that health IT developers generally would not be permitted to prohibit or restrict communications that disclose screenshots of the developer's health IT. We consider screen displays an essential component of health IT performance and usability, and their reproduction may be necessary in order for a health IT user or other health IT stakeholder to properly make communications about the subject matters enumerated in § 170.403(a)(1). We acknowledge that some health IT developers have historically and aggressively sought to prohibit the disclosure of such communications. We consider that developers may benefit from screen displays being faithfully reproduced so that health IT users and other stakeholders can form an objective opinion on any question raised about usability in communications protected by this proposed Condition of Certification. Moreover, we consider that the reproduction of screenshots in connection with the making of a communication protected by this Condition of Certification would ordinarily represent a “fair use” of any copyright subsisting in the screen display, and developers should not impose prohibitions or restrictions that would limit that fair use.

Notwithstanding the above, we propose to permit certain prohibitions and restrictions on the communication of screenshots. Except in connection with communications with unqualified protection, developers would be permitted to impose certain restrictions on the disclosure of screenshots, as described below.

In order to ensure that disclosures of screenshots are reasonable and represent a faithful reproduction of the developer's screen design and health IT, we propose that developers would be permitted to prevent communicators from altering screenshots, other than to annotate the screenshot or to resize it for the purpose of publication. We consider this a reasonable limitation on the disclosure of screenshots and one that would help developers' health IT avoid being misrepresented by communicators seeking to make a communication protected by this proposed Condition of Certification.

We also propose that health IT developers could impose restrictions on the disclosure of a screenshot on the basis that it would infringe third-party intellectual property rights (on their behalf or as required by license). However, to take advantage of this exception, the developer would need to first put all potential communicators on sufficient written notice of those parts of the screen display that contain trade secrets or intellectual property rights and cannot be communicated, and would still need to allow communicators to communicate redacted versions of screenshots that do not reproduce those parts.

Finally, we also recognize that health IT developers may have obligations under HIPAA as a business associate and that it would be reasonable for developers to impose restrictions on the communication of screenshots that contain protected health information, provided that developers permit the communication of screenshots that have been redacted to conceal protected health information, or the relevant individual's consent or authorization had been obtained.

(E) Testing and Development

We are aware that some health IT developers expose aspects of their health IT to health care providers and others for the purpose of testing and development prior to a product's “general availability” release. Such disclosures may relate to beta releases that are shared with certain customers for testing prior to the software being made generally available to the market, or may be made as part of a joint-venture or cooperative development process. In these circumstances, we propose that a health IT developer would be justified in keeping information about its health IT confidential, and we do not intend that the protection afforded to communicators under this Condition of Certification would allow disclosures of this information. This permitted prohibition or restriction would allow developers to seek appropriate intellectual property protection and freely discuss novel, “unreleased” product features with their customer base, which has significant public policy benefits for research and innovation in the health IT industry.

As with the other allowable restrictions listed above, we propose that this permitted restriction would be limited and does not apply to communications which are communications with unqualified protection as described above and specified in § 170.403(a)(2)(i). For example, information that is learned as part of development and testing, such as the hard-coding of test procedure processes that raise serious patient safety concerns, could be communicated for one of the limited purposes specified in § 170.403(a)(2)(i) if the software is certified or released to market. We propose that this permitted restriction would also not apply to communications about the released version of the health IT once the health IT has been released to market or has been certified, provided that the communications otherwise meet all other requirements to be afforded protection under this Condition of Certification and the information communicated could be discovered by any ordinary user of the health IT.

For example, a health IT developer and a large health system enter into an agreement for members of the health IT developer's engineering team to work with members of the health system's clinical team to develop a customization for the system's use of the developer's EHR. In order to properly protect any intellectual property rights, or proprietary information, arising from this work, the developer and health system enter into a contract which imposes on the system and affected members of its clinical team strict nondisclosure related to testing and development of the health IT. This would be reasonable and would not contravene this Condition of Certification, provided that: (1) The nondisclosure obligations were narrowly targeted toward the work product associated with the testing and development; and (2) the obligations ceased immediately upon any resultant software being deployed in the health system, to the extent that the information fell within one of the subject areas enumerated in § 170.403(a)(1) and would be apparent to an ordinary user of the health IT.

To ensure that this permitted prohibition/restriction is not abused, such as by maintaining a product in beta release for an indefinite or lengthy period of time, we request comment on whether we should limit the time this protection would apply for testing purposes. This could be no longer than a year after release of a product or update. We also request comment on whether we should set specific parameters for covered testing. For example, we note above our expectations that a product would be shared with certain customers for testing prior to the software being made generally available to the market. As such, for this permitted prohibition/restriction to apply, should we more specifically limit the extent a product can be distributed to customers for testing purposes?Start Printed Page 7476

c. Maintenance of Certification Requirements

We propose that to maintain compliance with this Condition of Certification a health IT developer must not establish or enforce any contract or agreement provision that contravenes this Condition of Certification. We are aware that some developers currently have in place health IT contracts that contain provisions that contravene this proposed Condition of Certification because they impose impermissible prohibitions or restrictions on communications. In some instances, the provisions in question will be expressly at odds with this Condition, imposing obligations on health IT customers, or creating rights in favor of the developer, that prohibit or restrict communications that are protected. In other instances, a contract will include a provision that contravenes this Condition because it has been drawn in such broad terms—such as an overly-expansive definition of confidential information—that a reasonable reader of the provision would consider the making of a communication protected by this Condition a breach of the contract.

Health IT contracts are typically for a significant duration—e.g., 5 years or more—or include an automatic renewal whereby the then current terms roll over for any renewal period. The implementation of this proposed Condition of Certification cannot therefore wait until health IT contracts that contravene this Condition expire in the ordinary course. As such, we are requiring that health IT developers take immediate steps to become in compliance with this Condition of Certification.

We propose that a health IT developer must notify all customers and those with which it has contracts/agreements, within six months of the effective date of a subsequent final rule for this proposed rule, that any communication or contract/agreement provision that contravenes this Condition of Certification will not be enforced by the health IT developer. Further, we propose that this notice would need to be provided annually up to and until the health IT developer amends the contract or agreement to remove or make void any contractual provision that contravenes this Condition of Certification. We further propose as a Maintenance of Certification requirement in § 170.405(b)(2) that health IT developers must amend their contracts or agreements to remove or make void any provisions that contravene the Condition of Certification within a reasonable period of time, but not later than two years from the effective date of a subsequent final rule for this proposed rule.

We believe this is an appropriate approach as we understand that health IT developers are in regular contact with their customers, and so the provision of a notice that satisfies this requirement should not present an undue burden for a developer. We would also expect that developers have kept good records of nondisclosure agreements that they have entered into with other organizations or individuals, such as third-party developers, and can communicate with those organizations or individuals as necessary to satisfy this requirement. In the event that a health IT developer cannot, despite all reasonable efforts, locate an entity or individual that previously entered into an agreement with the developer that prohibits or restricts communications protected by this Condition, the developer would not be in contravention of this Condition so long as it takes no step to enforce the prohibition or restriction. For clarity, we do not propose that health IT developers be required to furnish to ONC or their ONC-ACB copies of notices made to customers, or copies of contracts or agreements revised, in satisfaction of this Maintenance of Certification requirement, although those communications may be requested by ONC or an ONC-ACB in the usual course of business. To this point, under the “Enforcement” section of this proposed rule (VII.D), we describe our general enforcement approach outlining a corrective action process for ONC to review instances where Conditions and Maintenance of Certification requirements are not being met by a health IT developer under the Program.

We note that another approach we considered proposing would have been to require that developers amend their current health IT contracts immediately. We have, however, relied on the proposed requirement that developers not enforce contractual terms that contravene this proposed Condition of Certification until they can amend their contracts in a reasonable period of time, but not later than two years from the effective date of a subsequent final rule for this proposed rule. We seek comment on whether this is an adequate approach to removing prohibitions and restrictions on protected communications and ensuring that health IT customers, users, researchers, and other stakeholders are aware of their right to engage in such communications notwithstanding existing contracts or agreements to the contrary.

4. Application Programming Interfaces

As a Condition of Certification (and Maintenance thereof) under the Program, the Cures Act requires health IT developers to publish APIs that allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.” The Cures Act's API Condition of Certification also states that a developer must, through an API, “provide access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.”

The Cures Act's API Condition of Certification includes several key phrases and requirements for health IT developers that go beyond just the technical functionality of the products they present for certification. In this section of the preamble we outline our proposals to implement the Cures Act's API Condition of Certification in order to provide compliance clarity for health IT developers.

These proposals include new standards, new implementation specifications, and a new certification criterion as well as detailed Conditions and Maintenance of Certification requirements. We also propose to modify the Base EHR definition. We note that health IT developers should also consider these proposals in the context of what could warrant review from an information blocking perspective in so far as action (or inaction) that would be inconsistent with this proposed rule's API Conditions and Maintenance of Certification requirements.

a. Statutory Interpretation and API Policy Principles

One of the most significant phrases in the Cures Act's API Condition of Certification concerns the deployment and use of APIs “without special effort.” Specifically, the Cures Act requires health IT developers to publish APIs and allow health information from such technology “to be accessed, exchanged, and used without special effort.” In this context, we interpret the “effort” exerted (i.e., by whom) to be focused on the API users, which could include third-party software developers, the health care providers that acquired this API technology, and patients, health care providers, and payers that use apps/services that connect to API technology.

As we considered the meaning and context associated with the phrase “without special effort” and what Start Printed Page 7477would make APIs included in certified health IT truly “open,” we focused on key attributes that could be used to refine our interpretation and guide our proposals. We interpret “without special effort” to require that APIs, and the health care ecosystem in which they are deployed, have three attributes: Standardized, transparent, and pro-competitive. Each of these attributes is briefly described in more detail below and all of our subsequent proposals address one or a combination of these attributes.

  • Standardized—meaning that all health IT developers seeking certification would have to implement the same technical API capabilities in their products (using modern, computing standards such as RESTful interfaces and XML/JSON). Technical consistency and implementation predictability are fundamental to scale API-enabled interoperability and reduce the level of custom development and costs necessary to access, exchange, and use health information. Further, from a regulatory standpoint, health IT developers would gain certainty in regards to pre-certification testing requirements and post-certification “real world testing” expectations. Equally, from an industry standpoint, a consistent and predictable set of API functions would provide the health IT ecosystem with known technical requirements against which “app” developers and other innovative services can be built.
  • Transparent—meaning that all health IT developers seeking certification would need to make the specific business and technical documentation necessary to interact with the APIs in production freely and publicly accessible. Such transparency and openness is commonplace in many other industries and has fueled innovation, growth, and competition.
  • Pro-competitive—meaning that all health IT developers seeking certification would need to abide by business practices that promote the efficient access, exchange, and use of EHI to support a competitive marketplace that enhances consumer value and choice. Moreover, health care providers should have the sole authority and autonomy to unilaterally permit third-party software developers to connect to the API technology they have acquired. In other words, health IT developers must not interfere with a health care provider's use of their acquired API technology in any way, especially ways that would impact its equitable access and use based on (for example) another software developer's size, current client base, or business line. It also means that developers (together with health care providers that deploy APIs) are accountable to patients who, as consumers of health care services, have paid for their care and the information generated from such care. Thus, patients should be able to access their EHI via any API-enabled app they choose without special effort, including without incurring additional costs and without encountering access requirements that impede their ability to access their information in a persistent manner.

b. Key Terms

To clearly convey the stakeholders on which our proposals focus and are meant to support, we propose to use the following terms to reflect these meanings and/or roles:

  • The term “API technology” (with a lowercase “t”) generally refers to the capabilities of certified health IT that fulfill the API-focused certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (g)(11).
  • API Technology Supplier” refers to a health IT developer that creates the API technology that is presented for testing and certification to any of the certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (g)(11). We propose to adopt this term in § 170.102.
  • API Data Provider” refers to the organization that deploys the API technology created by the “API Technology Supplier” and provides access via the API technology to data it produces and electronically manages. In some cases, the API Data Provider may contract with the API Technology Supplier to perform the API deployment service on its behalf. However, in such circumstances, the API Data Provider retains control of what and how information is disclosed and so for the purposes of this definition is considered to be the entity that deploys the API technology. We propose to adopt this term in § 170.102.
  • API User”—refers to persons and entities that use or create software applications that interact with the APIs developed by the “API Technology Supplier” and deployed by the “API Data Provider.” An API User includes, but is not limited to, third-party software developers, developers of software applications used by API Data Providers, patients, health care providers, and payers that use apps/services that connect to API technology. We propose to adopt this term in § 170.102.

We also use:

  • The term “(g)(10)-certified API” for ease of reference throughout the preamble to refer to health IT certified to the certification criterion proposed for adoption in 45 CFR 170.315(g)(10).
  • The term “app” for ease of reference to describe any type of software application that would be designed to interact with the (g)(10)-certified APIs. This generic term is meant to include, but not be limited to, a range of applications from mobile and browser-based to comprehensive business-to-business enterprise applications administered by third parties.

c. Proposed API Standards, Implementation Specifications, and Certification Criterion

APIs can be thought of as a set of commands, functions, protocols, and/or tools published by one software developer (“software developer A”) that enable other software developers (X, Y, and Z) to create programs and applications that interact with A's software without needing to know the “internal” workings of A's software. APIs can facilitate more seamless access to health information and it is important to note for context that ONC adopted three 2015 Edition certification criteria that specified API capabilities for Health IT Modules (criteria adopted in 45 CFR 170.315(g)(7), (g)(8), and (g)(9)). The following sections detail our proposals to adopt standards, implementation specifications, and a new API certification criterion. Together, these proposals account for the technical requirements we propose to associate with the Cures Act's API Condition of Certification and are reinforced through the condition's policy proposals.

i. Proposed Adoption of FHIR DSTU2 Standard

Overall, and on balance, we have structured our standards and implementation specifications proposals to best meet the health IT industry where it is most prepared to comply today. As a result, we propose to adopt the HL7® Fast Healthcare Interoperability Resources (FHIR®) standard as a foundational standard within our suite of proposals. Specifically, we propose to adopt FHIR Draft Standard for Trial Use (DSTU) 2 (hereafter referred to as “FHIR Release 2”) as a baseline standard conformance requirement. In so doing, we can work with industry to support a conformance testing infrastructure for a full suite of proposals focused on one FHIR release (its associated implementation specifications) and complementary Start Printed Page 7478security and app registration protocols, compared to numerous versions.[81]

The 2015 Edition final rule did not include specific standards or implementation specifications to describe the way in which APIs needed to be designed to meet § 170.315(g)(8). Instead, we specified a functional certification criterion and encouraged the industry to coalesce around a standardized specification for its API functionality, such as the FHIR standard. We did, however, require health IT developers to make their technical API documentation publicly available and we subsequently made such information accessible via the CHPL.

Upon reviewing health IT developers certified to § 170.315(g)(8), approximately 32% have published via the CHPL that they are using FHIR, specifically FHIR Release 2, as of mid- September 2018. Additionally, nearly 51% of health IT developers appear to be using a version of FHIR and OAuth 2.0 together. We also note that when viewed from the perspective of how many providers are served by these FHIR implementers, we estimate that approximate 87% of hospitals and 57% of clinicians are served by developers with a FHIR Release 2 API and 87% of hospitals and 69% of clinicians are served by developers with a FHIR API of any version. In the years since the 2015 Edition final rule, industry stakeholders have made rapid progress to advance the FHIR standard. This includes substantial investments in industry pilots, specification development led through the Argonaut Project [82] production deployment of APIs conformant to FHIR Release 2 following the Argonaut specifications, and the support for FHIR Release 2 in Apple's iOS 11.3, which includes a new “health records” app for the iPhone based on these specifications.[83] Therefore, the industry is well prepared and ready to adopt the FHIR standard.

Thus, we propose to adopt FHIR Release 2 as the baseline standard in a new API standards section of our rules at 45 CFR 170.215(a)(1). Additionally, as discussed in further detail below, we reference FHIR Release 2 for use in the new API certification criterion proposed for adoption in § 170.315(g)(10).

Although FHIR Release 3 is published and some health IT developers have included varied support for it in their product(s) at this time, there is limited evidence that its production deployment is as widespread as FHIR Release 2. Thus, we believe that FHIR Release 2 is the most appropriate version to propose to adopt as part of proposed § 170.315(g)(10)'s conformance requirements. This approach would provide a stable and consistent direction in which the industry can go when it comes to deploying (g)(10)-certified APIs that support data access to the USCDI. FHIR Release 2 best reflects the industry's current maturity and implementation readiness, it has been more rigorously tested, and it is largely implemented in most 2015 Edition health IT systems that have and are being deployed in production. Thus, the incremental burden for many health IT developers to get certified to the proposed criterion in § 170.315(g)(10) would be largely limited to the added security and registration conformance requirements we have proposed to include. We recognize, however, that some health IT developers certified to § 170.315(g)(8) chose not to use FHIR and will have more substantial changes to make in order to meet this proposal.

Additionally, FHIR Release 4 has now been published [84] and updated associated implementation specifications are expected to follow. FHIR Release 4 has several key improvements, including certain foundational aspects in the standard and “FHIR resources” designated as “normative” for the first time. This will lead to acycle of more mature US FHIR Core profiles aligned with Release 4 and additional implementation guidance that explicitly specifies how to handle populations of patient data (batch exports) via FHIR to more efficiently enable population and learning health system-oriented services. Likewise, from an industry update trajectory, we believe that FHIR Release 4's normative resources will be compelling from a maturity and stability perspective such that many health IT developers will either rapidly progress to FHIR Release 4 from Release 3 or skip wide-scale production deployment of FHIR Release 3 altogether, making FHIR Release 4 the next de facto version the industry would move toward and coalesce behind.

Given FHIR Release 4's public release and that the industry will begin to implement Release 4 in parallel with this rulemaking, we request comment on the following options we could pursue for a final rule.

Option 1 (proposed in regulation text): Adopt just FHIR Release 2 for reference in proposed § 170.315(g)(10). This option would require health IT developers seeking certification to build, test, and certify systems solely to FHIR Release 2 and its associated implementation specifications. Under this option, if the National Coordinator approved the use of FHIR Release 3 or 4 (pursuant to the Standards Version Advancement Process) it would occur, at the earliest, one year after a final rule was issued. Given that timing, and the compliance deadlines proposed later in this section, it would mean that health IT developers would have no option but to develop to FHIR Release 2 in order to meet the proposed compliance deadlines.

Option 2: Adopt FHIR Release 2 and FHIR Release 3 in order to introduce optionality into how health IT developers are able to demonstrate compliance with proposed § 170.315(g)(10). In other words, by adopting and referencing both FHIR Release 2 and 3 in proposed § 170.315(g)(10) it would permit a health IT developer to use either one to meet the criterion (i.e., both versions would not be required to be supported and demonstrating only one would be needed to meet certification). Similarly, under this option, if the National Coordinator approved the use of FHIR Release 4 (pursuant to the Standards Version Advancement Process) it would occur, at the earliest, one year after a final rule was issued. Given that timing, and the compliance deadlines proposed later in this section, it would mean that health IT developers would have no option but to develop to FHIR Release 2 or Release 3 in order to meet the proposed compliance deadlines.

Option 3: Adopt FHIR Release 2 and FHIR Release 4 in order to introduce flexibility into how health IT developers are able to demonstrate compliance with proposed § 170.315(g)(10). The full implementation of this option would depend on all applicable corresponding FHIR Release 2 implementation specifications also being published in their FHIR Release 4 formats and available prior to the issuance of a final rule. Provided these FHIR Release 4 implementation specifications are published in time for a final rule, this option would appear to be the best near- and long-term option for the industry. We anticipate this being the case because it would let lagging health IT developers catch up to the FHIR Release 2 baseline while at the same time enable leading health IT developers to move directly and immediately to FHIR Release 4 as a means to meet proposed Start Printed Page 7479§ 170.315(g)(10)'s compliance timelines. In other words, unlike Options 1 and 2, the Standards Version Advancement Process would not be necessary and the trajectory of leading health IT developers would be well supported by the certification criterion. We also request comment on a variant of Option 3 that would include a pre-defined cut-over for the permitted use of and certification to FHIR Release 2. We note that if this variant were implemented as part of Option 3, we would likely also need to add a maintenance of certification requirement in the final rule to establish an upgrade timeline to FHIR Release 4 for those health IT developers who originally sought certification for FHIR Release 2. Such a maintenance requirement would seem necessary in order to bring the industry into closer alignment with respect to a more up-to-date national baseline for FHIR.

Option 4: Adopt solely FHIR Release 4 in the final rule for reference in proposed § 170.315(g)(10). This option would require health IT developers seeking certification to build, test, and certify systems solely to FHIR Release 4 and its associated implementation specifications. Again, provided all applicable FHIR Release 4 implementation specifications are published in time for a final rule, this option would appear to be a close preference to Option 3 for industry. We believe this would be the case because by the time a final rule associated with these proposals is issued, it is likely that health IT developers would have close to or over a year's worth of development experience with FHIR Release 4. As a result, many may be poised to introduce their first round of generally available FHIR Release 4 products into production. If ONC were to offer certification to FHIR Release 2 (as in Option 3) this flexibility could unintentionally delay the industry's transition to FHIR Release 4 and slow progress associated with FHIR-based interoperability. The following compliance timeline example attempts to make this point clearer. If, for example, the final rule was effective January 2020, based on other proposals associated with the API Conditions of Certification, health IT developers would have up to 2 years to rollout their (g)(10)-certified API technology, which would mean January 2022. At that point, FHIR Release 4 would have been published for nearly 3 years and FHIR Release 2 would have been published for nearly 6 years. Without a pre-defined cut-over for FHIR Release 2 in Option 3, that certification approach would permit FHIR Release 2 APIs to be deployed in 2022 and used for an indeterminate period of time.

In preparing your comments, please fully review our proposed certification criterion in § 170.315(g)(10) and the accompanying Conditions of Certification attributed to the API-oriented certification criteria. Notably, if we were to adopt another FHIR Release in a final rule as an alternative to FHIR Release 2 for the proposed API criterion in § 170.315(g)(10), then we would also adopt the applicable implementation specifications and FHIR profiles (the US FHIR Core profiles) associated with the FHIR Release in order to support USCDI data access. We highly encourage stakeholders to express their perspective and explicitly note their preferred option in comments.

ii. Proposed Adoption of Associated FHIR Release 2 Implementation Specifications

Our proposal to adopt the FHIR standard alone, however, is insufficient to provide the level of consistent implementation that will be necessary to realize the “without special effort” provision in this Condition of Certification. FHIR, much like other standards that are initially developed to be internationally applicable, requires additional implementation specifications in order to further constrain implementation choices and reflect US-based standards policies (such as the use of RxNorm for representing medications). In FHIR, the additional constraints placed on “base FHIR resources” are expressed through what are called “FHIR profiles.” FHIR Profiles typically provide additional rules about which resource elements must be used and what additional elements have been added that are not part of the base FHIR resource. This can include, but not be limited to, rules about which API features are used and how as well as rules about which terminologies are used in particular elements. The term “profile” is a general term that is used in the FHIR standard to describe either an individual FHIR resource, or an entire implementation specification consisting of multiple FHIR resources. Accordingly, we propose to adopt three implementation specifications that will establish a standardized baseline and further constrain API conformance to help assure that APIs can be used “without special effort.”

We propose to adopt in § 170.215(a)(2) an implementation specification that would list a set of base FHIR resources that Health IT Modules certified to the proposed criterion in § 170.315(g)(10) would need to support. We refer to this proposed initial set of FHIR resources as the “API Resource Collection in Health” or “the ARCH.” The ARCH would align with and be directed by the data policy specified in the proposed US Core Data for Interoperability (USCDI) standard (discussed in section IV.B.1 of this proposed rule).

As a result, we propose to include 15 FHIR resources in the ARCH's first version. Based on prior industry efforts, including the Argonaut Project to map FHIR resources to the previously defined Common Clinical Data Set (CCDS), we know that the following 13 FHIR resources map to and support the equivalent data classes specified in the USCDI: AllergyIntolerance; CarePlan; Condition; Device; DiagnosticReport; Goal; Immunization; Medication; MedicationOrder; MedicationStatement; Observation; Patient; and Procedure. We also propose to include, specifically for the Patient resource that the “Patient.address” and “Patient.telecom” elements must be supported as part of the Patient resource. These elements are neither required in the base FHIR resource or additional implementation specifications; however, they are necessary to align with the USCDI's data requirements. With respect to the Device resource, we propose to require that the “Device.udi” element follow the human readable representation of the unique device identifier (UDI) found in the recommendation, guidance, and conformance requirements section of the “HL7 Version 3 Cross Paradigm Implementation Guide: Medical Devices and Unique Device Identification (UDI) Pattern, Release 1,” a document hosted by HL7.[85] Developers would be held responsible only for the recommendation, guidance, and conformance requirements for HL7 FHIR in the implementation guide and would not be held responsible for other requirements in the implementation guide specific to other standards, including requirements for HL7 Version 2 and HL7 Version 3. For clarity, these proposed requirements are part of the ARCH Version 1 standard.

In addition to these 13 FHIR resources, we have included two additional FHIR resources:

(1) The Provenance resource; and (2) the DocumentReference resource to accommodate clinical notes. These additions would make for a total of 15 FHIR resources to reflect the direction of the USCDI v1. With respect to clinical notes, we understand from our own Start Printed Page 7480analysis and technical discussions within HL7 that the FHIR DocumentReference resource is best capable of handling the exchange of clinical notes. Since the CCDS was defined over two years ago, we have most frequently heard from provider stakeholders that access to “clinical notes” is key, impactful, and highly desirable data that should be accessible via the C-CDAs they exchange as well as via APIs. While we realize the industry may need to develop additional implementation guidance to support clinical notes via FHIR, we believe that including FHIR resources in ARCH Version 1 directly addresses the steady requests we have received from providers to include a focus on the access, exchange, and use of “clinical notes” as part of certification. Thus, we propose to include the FHIR DocumentReference resource in the ARCH to support clinical notes. We also clarify that the clinical note text included in this FHIR resource would need to be represented in its “raw” text form. In other words, it would be unacceptable for the note text to be converted to another file or format (e.g., .docx, PDF) when it is provided as part of an API response. With respect to the Provenance resource, we believe its inclusion in the ARCH is paramount to the long-term success and use of FHIR-based APIs. While C-CDA's are often critiqued due to their relative “length,” the C-CDA often represents the output of a clinical event and includes relevant context. The same will not always be true in an API-context. This is due to the fact that FHIR-based APIs make it significantly easier for apps to request specific data (e.g., just a patient's active medications). Thus, it is equally important over the long-term that the industry not lose sight of the metadata (i.e., the who, what, when, where, why, and how) behind the data that was created. As a result, we believe that this early stage of FHIR deployment is the best time for the industry to build in support for the Provenance resource. Otherwise, if we were to expand the ARCH in future years to include this FHIR resource, we estimate that the developer burden and overall industry impact would be greater than building this support in “from the start.” Specifically, and to remain consistent with the USCDI, we propose to require that the “Provenance.recorded” (for the author's time stamp) and “Provenance.agent.actor” (for the author and author's organization) elements be supported as part of the Provenance resource.

Over time, and as the USCDI is expanded, we also expect to update this implementation specification to expand the ARCH beyond these 15 FHIR resources. Equally, consistent with the Maintenance of Certification requirements described in section VII.B.5 of this proposed rule (the Standards Version Advancement Process proposals), which would permit health IT developers to voluntarily implement and use a new version of an adopted standard or implementation specification so long as certain conditions are met including that the new version is approved by the National Coordinator for use in certification through the Standards Version Advancement Process, health IT developers would be able to update their certified health IT to include (g)(10)-certified API access to a broader set of data once a new version of the ARCH is approved.

The next implementation specification for the FHIR standard we propose to adopt in § 170.215(a)(3) is the Argonaut Data Query Implementation Guide version 1 (Argonaut IG), hosted by HL7.[86] This implementation guide has been pilot tested and is now being implemented for production use by health IT developers. Notably, it specifies FHIR profile constraints for 13 of the associated FHIR resources we propose to include in the ARCH Version 1 and these FHIR profiles support the data included in the USCDI (v1).

The next implementation specification for the FHIR standard we propose the Secretary adopt in § 170.215(a)(4) is the specific portion of the Argonaut IG that refers to the “Argonaut Data Query Implementation Guide Server” conformance requirements. While it could be implied through our proposed adoption of the Argonaut IG that these conformance requirements would be included, we seek to make this an explicit requirement for the API certification criterion proposed in § 170.315(g)(10). Conformance to this implementation specification is essential in order to ensure that all FHIR servers are consistently configured to support the defined data queries and “supported searches” associated with each Argonaut profiled FHIR resource. For clarity, conformance testing would focus on and be limited to the “SHALL” requirements. We also note that the Argonaut Data Query Implementation Guide Server includes conformance requirements for the “DocumentReference Profile,” which defines “how a provider or patient can retrieve a patient's existing clinical document.” This particular specification was produced in support of the 2015 Edition certification criterion adopted in § 170.315(g)(9). As a result, we clarify that this specific portion of the Server IG and conformance requirement would be out of scope for the purposes of proposed § 170.315(g)(10).

We have separately proposed the FHIR standard and each of these implementation specifications so that the National Coordinator may evaluate industry progress and make a unique or combined determination as to the appropriate time to approve for voluntary upgrade pursuant to the standards version advancement process discussed in more detail in section VII.B.5 as well as subsequently go through rulemaking to adopt a new version of: The FHIR standard, the ARCH, implementation specifications that “profile” the resources in the ARCH, and implementation specifications for FHIR server conformance capabilities. While the proposed implementation specifications relate to one another, they can also be updated independently of each other as time goes on. For instance, the National Coordinator could approve a new version of the FHIR standard “Release 5” in the future in accordance with the standards version advancement process. In so doing, the National Coordinator could leave the scope of the ARCH the same and update (necessarily) the implementation specifications for the FHIR profiles and FHIR server conformance requirements accordingly to align with the new FHIR version. As an alternative example, the National Coordinator could leave the FHIR standard version the same and approve a new version of the ARCH to include more FHIR resources.

We note that other federal agencies may be adopting the FHIR standard and additional FHIR implementation guides for their program requirements. We plan to coordinate with such other agencies to focus on strategic alignment among the FHIR standard versions, applicable implementation guides, and use cases.

iii. Proposed Adoption of Standards and Implementation Specifications To Support Persistent User Authentication and App Authorization

To enable and support persistent user authentication and app authorization processes, we propose to adopt a standards and additional implementation specification for the FHIR standard. First, we propose to adopt the “OpenID Connect Core 1.0 Start Printed Page 7481incorporating errata set 1” standard in § 170.215(b) as it complements the SMART Application Launch Framework Implementation Guide Release 1.0.0 [87] (SMART Guide). The OpenID standard is typically paired with OAuth 2.0 implementations and focuses on user authentication. Second, we propose to adopt the SMART Guide in § 170.215(a)(5) as an additional implementation specification associated with the FHIR standard. This guide is referenced by the Argonaut IG and is generally being implemented by the health IT community as a security layer with which FHIR deployment is being combined (from both a FHIR server and FHIR application perspective). Further, while the SMART Guide includes certain mandatory requirements, we believe three specific aspects are necessary to specifically require in order for certification to enable consistent industry-wide implementation.

The SMART Guide specifies the use of “refresh tokens” as optional. We believe that this requirement is necessary in order to enable persistent access by apps, especially in a patient access context. Thus, we propose to make their use mandatory with a minimum refresh token life of 3 months. While this technique would need to be supported for both types of API-enabled services we propose be supported through § 170.315(g)(10), we wish to emphasize that implementing refresh token support is directly intended to enable a patient's “persistent access” to their electronic health information without special effort (i.e., without having to frequently re-authenticate and re-authorize while using their preferred app). This proposal aligns with the industry developed security best practice guidelines for OAuth 2.0 implementations, which require support for a short-lived “access token” and a long-lived “refresh token” that could be subsequently used by the app to obtain a new “access token” after the original “access token” expires. We believe this approach enhances the seamlessness of a patient's data access and reduces the “friction” they would otherwise experience having to re-authenticate and re-authorize. At the same time, because the access token is short lived, this minimizes the risk of a patient's information being accessed by unauthorized users if for some reason the access token is compromised. The technical capabilities that we intend to explicitly test are referenced as part of the proposed API certification criterion in § 170.315(g)(10).

We also propose to require that the “Standalone Launch” and “EHR Launch” requirements specified in the SMART Guide be supported. We believe that requiring API Technology Suppliers to demonstrate both of these capacities will help ensure greater standardization and ease of use among (g)(10)-certified APIs. When a third-party “app” first connects to a FHIR server, it often requires some contextual data to make the app more “user friendly.” This information could include things such as the most recent patient encounter or hospital visit. The contextual information depends on how the “app” is launched.

When an app is launched from “outside of an EHR,” such as from a patient's smartphone or web browser, then the app is considered to be launched in a “Standalone” mode. In this mode, the app has to request that the FHIR server provide appropriate contextual information, which can then be used to customize the app's display for the patient. The SMART Guide has standardized the information that such apps can request from FHIR servers and defined it as “Standalone Launch.”

In other contexts, apps can be launched from “within the EHR.” This is typically the case when a third-party app is integrated as part of an EHR technology. In this case, the app is considered to have been launched in the “EHR” mode. Typically, when such an app is launched from within an EHR, the user (e.g., provider, nurse) has a patient's record “open” or “active” in the EHR and expects the app to directly open the same patient when it is launched. In order for this to happen, the app has to request that the FHIR server provides information about the patient record that is currently “open” in the EHR. The SMART Guide has standardized this interaction and defined it as “EHR Launch.”

iv. Proposed Adoption of a New API Certification Criterion in § 170.315(g)(10)

Proposal Overview

To implement the Cures Act, we propose to adopt a new criterion in § 170.315(g)(10) to replace the certification criterion adopted in § 170.315(g)(8). Currently, the criterion adopted in § 170.315(g)(8) focuses on a Health IT Module's ability to provide API functionality that can respond with data for each of the data categories specified in the Common Clinical Data Set. Moreover, its focus on read-access/response to requests for specific types of data most directly aligns with the API uses envisioned by industry stakeholders and the Cures Act, which is why we believe it is necessary and appropriate to replace § 170.315(g)(8). In contrast, we do not propose that it is necessary to replace the certification criteria adopted in § 170.315(g)(7) and (g)(9) because the former does not prescribe specific technical approaches (and can continue to be met as technology evolves) and the latter supports a discrete use case relative to an API function that responds with a C-CDA.

We propose our approach to adopt a replacement for § 170.315(g)(8) that will provide clear regulatory compliance requirements for stakeholders because: (1) 2015 Edition testing and certification to § 170.315(g)(8) will continue throughout this rulemaking; (2) presuming we adopt this (or a modified version of this) proposal in a final rule, it will be easier for the industry to distinguish compliance requirements between two separate certification criteria compared to a time/context-sensitive “version” of § 170.315(g)(8); and (3) § 170.315(g)(8) is currently specified in the Base EHR definition so its replacement has compliance effects on health care providers participating in every program that requires the use of Certified EHR Technology, which references the Base EHR definition.

At a high-level, we propose that this new API certification criterion would require FHIR servers to support two types of API-enabled services:

  • Services for which a single patient's [88] data is at focus; and
  • services for which multiple patients' data are at focus, which, hereafter, we refer to as “population-level” to convey the grouped and cohort scope on which the data associated with these services would be focused (e.g., a specific provider's patient panel, all of the patients covered by a particular health plan, a group of patients cared for through an alternative payment model).

This proposed certification criterion would only require mandatory support for “read” access for both identified services, though we envision a future version of this certification criterion that could include specific “write” conformance requirements (for example, to aid decision support) once FHIR-based APIs are widely adopted. In all cases, this proposed criterion will require that the two types of API services have appropriate security controls implemented. These controls Start Printed Page 7482would ensure a user fully authenticates to the API-enabled data source to which the request is being made and that the user's software application is appropriately authorized to request specified data.

API services that focus on a single patient would include, but not be limited to, those that interact with software applications controlled and used by a patient to access their data as well as software applications implemented by a provider to enhance their own “internal” clinical care tools and workflow (e.g., a specialized calculation app). Most, if not all, of these types of interactions are typically orchestrated in a synchronous, real to near-real-time mode via APIs.

Conversely, API services that focus on multiple patients would include, but not be limited to, software applications used by a health care provider to manage various internal patient populations as well as external services a health care provider may contract for to support quality improvement, population health management, and cost accountability vis-à-vis the provider's partners (e.g., health plans). Historically, access to this kind of computing has often been cumbersome, opaque, and required one-off scripting and significant engineering labor with no overarching standardized methods. By shifting this paradigm to a FHIR-based API, we anticipate that the market will be able to respond with a new slate of innovative solutions.

Across this spectrum of population-level uses, the scope or quantity of the data may range from a small group to many hundreds or thousands of patients. Moreover, when “external” applications and services are provided access to patient data by the provider, we expect that such access and associated privacy and security protocols would be established consistent with existing legal requirements under the HIPAA Privacy and Security Rules (including business associate agreements), other data use agreements (as applicable), and any other state or federal applicable law. Principally, for the purposes of the proposed certification criterion, we seek to include and ensure through testing and certification that a set of baseline API functionality exists and is deployed for providers to use at their discretion to support their own clinical priorities as well as to use to engage with their partners, such as software developers and developers of third-party applications.

We have explicitly proposed to include support for API services that are population-level focused in this certification criterion because the current certification criterion in § 170.315(g)(8) has largely been tested, certified, and deployed to support the “patient data request” use case. In comparison, population-level focused API services are envisioned to support FHIR-based apps that not only improve clinical workflow and decision support but also help advance a learning health system. In so doing, providers, payers, and other stakeholders will be able to make incrementally better use of FHIR's RESTful API and JSON payload to apply modern computing techniques, including big data analyses and machine learning, to account for, assess, and inform the quality and effectiveness of care delivered. As noted in the proposed API standards section, FHIR Release 4 includes technical specifications to enable standardized population-level services via FHIR-based APIs in a more efficient manner than currently possible. If “Option 3” or “Option 4” is preferred by industry in terms of the FHIR standards options for this certification criterion, these approaches would be demonstrable. Alternatively, if the National Coordinator were to approve FHIR Release 4 for use under this proposed certification criterion (following the Standards Version Advancement Process described in Section VII.B.5 of this preamble) then it would be able to be used to meet these technical expectations.

Lastly, as we considered the necessary oversight responsibilities the Cures Act adds to the Program, we have determined that it would be essential to include a specific population-level API conformance requirement as part of this criterion so that such capabilities could be evaluated post-certification for compliance with (among other requirements) this API Condition of Certification and the information blocking and real world testing Conditions of Certification.

Specific Proposals

In general, we have approached framing § 170.315(g)(10) in the same way we framed § 170.315(g)(8). This new proposed criterion, however, includes some important differences and specificity compared to § 170.315(g)(8). Taken together, the following proposals are designed to establish a consistent set of API implementation requirements aimed at the API Condition of Certification's “without special effort” requirement. We propose that API technology presented by a health IT developer (otherwise considered an API Technology Supplier in this context) for testing and certification to the proposed certification criterion in § 170.315(g)(10) would need to meet the requirements outlined below. We seek comment on all of the following proposals.

Data Response

We propose in § 170.315(g)(10)(i) that the health IT presented for testing and certification must be capable of responding to requests for data on a single patient and multiple patients associated with each of the FHIR resources specified in ARCH Version 1 and consistent with FHIR Release 2 and the Argonaut IG implementation specification. More specifically, we clarify that all data elements indicated as “mandatory” and “must support” by the proposed standards and implementation specifications must be supported and would be in scope for testing. Through this approach, certification will provide for a consistent and predictable starting scope of data from which apps and other services can be developed.

Search Support

We propose to require in § 170.315(g)(10)(ii) that the health IT presented for testing and certification must be capable of responding to all of the “supported searches” specified in the Argonaut Data Query Implementation Guide Server, which as a reminder we have proposed for adoption as an implementation specification in § 170.215(a)(4).[89] Given that there is not yet a consistent, standardized specification for FHIR servers to handle searches for multiple patients, we clarify that a health IT developer would be permitted to approach searches for multiple patients in the manner it deems most efficient to meet this proposed certification criterion. We note, consistent with the implementation specifications current scope, that conformance would focus on search associated with a single patient's data. However, we reiterate the health IT presented for testing and certification and as implemented must support searches for multiple patients independent of a required standard for such searches.

For the DocumentReference and Provenance resources, which are currently present in the base FHIR standard, we request comments on the minimum “search” parameters that would need to be supported.Start Printed Page 7483

App Registration

We propose in § 170.315(g)(10)(iii) that health IT presented for testing and certification must be capable of enabling apps to register with an “authorization server.” This proposed conformance requirement would require an API Technology Supplier to demonstrate its registration process, but would not require that it be done according to a specific standard. We considered proposing the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) standard (“Dynamic Registration”) as the only way to support registration for this certification criterion and request public comment on whether we should require its support as part of a final rule's certification criterion. For clarity, we note that while we have not explicitly required Dynamic Registration as the only way to demonstrate conformance with this specific portion of the certification criterion, API Technology Suppliers would still be allowed to use Dynamic Registration if they so choose.

While requiring Dynamic Registration could create a more consistent registration experience for health IT developers, we did not expressly include this standard because of its relatively low adoption and implementation in the health IT ecosystem. Notably, while the SMART Guide covers a majority of technical steps necessary for an app to connect a FHIR server, it is neutral on the registration process API Technology Suppliers could take. Much like we did with § 170.315(g)(8) in the initial 2015 Edition final rule by not requiring FHIR, we believe that a prudent approach for registration is to require that it be addressed from a functional perspective while the industry reaches consensus on the best techniques to enable registration.

Note, that while this portion of proposed § 170.315(g)(10) focuses on the technical standards conformance, we have also included a specific “maintenance requirement” associated with the API Condition of Certification around the timeliness of this registration process in production settings as applicable to API Technology Suppliers. This proposed requirement will ensure that patients are able to use their apps in a timely manner.

We do not intend to test registration capabilities for apps that would be executed within an API Data Provider's clinical environment. We believe this discretion is warranted as API Technology Suppliers and API Data Providers are best poised to innovate and execute various methods for app registration within a clinical environment. However, we request comment on this perspective.

Secure Connection, Authentication and Authorization

We propose in § 170.315(g)(10)(iv) that the health IT presented for testing and certification must be capable of establishing a secure and trusted connection with an application that requests patient data in accordance with the SMART Guide. In the context of this proposed criterion, this would require that an “authorization server” be deployed and support, at a minimum, “authorize” and “token” endpoints and the publication of the endpoint URLs via FHIR server's metadata as specified in the SMART Guide to enable automated discovery by apps. Again, we note, consistent with this implementation specification's current scope, that initial conformance would focus on the secure connection parameters with a single patient's data in mind. Given that there is not yet a consistent, standardized specification for FHIR servers to handle secure connection parameters for multiple patients, we clarify that a health IT developer would be permitted to approach secure connections for multiple patients in the manner it deems most efficient to meet this proposed certification criterion.

When an application connects to request data for the first time, we propose in § 170.315(g)(10)(v)(A) that health IT presented for testing and certification must be capable of demonstrating support for user authentication according to the OpenID Connect Core 1.0 incorporating errata set 1 [90] standard. It should be noted that the OpenID Connect Standard is agnostic to the actual authentication mechanism used by the health IT while providing a standard way for health IT to exchange the authentication information to the app. The primary benefit being that it lets apps verify the identity of the end-user based on the authentication performed by the Authorization Server without having the apps to take additional responsibility for authenticating the user. We also propose in § 170.315(g)(10)(v)(B) that health IT presented for testing and certification must demonstrate that users can authorize applications (in the appropriate context) to access data in accordance with the SMART Guide. Pursuant to this proposed implementation specification described above, we also intend to test health IT in the “Standalone Launch” and “EHR Launch” modes. Additionally, we clarify that for the purposes of testing and certification, we propose to require that health IT support only a limited set of capabilities related to the OpenID Connect Standard—specifically, only those that are specified in the SMART Guide.

Further, in order to enable patients and providers to get persistent access to health information without having to re-authenticate and re-authorize, we propose to require that a “refresh token” must be provided with an expiration period of at least 3 months from the date issued. The “refresh token” could be subsequently used by the app to obtain a new “access token” after the expiration of the original “access token.” Note the proposed refresh token requirement is different than providing an “access token” with an extended life, which is typically discouraged from a security best practice perspective so as to prevent unauthorized access if for some reason the access token were to be acquired for use by an unauthorized application.

We propose in § 170.315(g)(10)(vi) that health IT presented for testing and certification must demonstrate that it can support subsequent connections by an app and requests data without requiring the user to re-authorize and re-authenticate when a valid refresh token is supplied. Further, we propose that once a valid refresh token has been used to get a new access token that the FHIR server must demonstrate that it can issue a new refresh token to the app, which must be for a new period no shorter than three months. For example, if an application were issued a refresh token that was good for three months upon its first-ever connection and then subsequently connected to the FHIR server one month later, the FHIR server would need to enable that connection to occur without re-authentication and re-authorization, and it would need to issue a new refresh token for a new three-month period from that access date. Again, we intend to test health IT in the “Standalone Launch” and “EHR Launch” contexts pursuant to the SMART Guide.

We have proposed this renewal requirement because industry stakeholders at various meetings and conferences at which we have attended have indicated that a constant need for patients to re-authenticate and re-authorize their apps creates usability challenges and may otherwise contradict the Cures Act's intent associated with the phrase “without special effort.” Further, we are not aware of a standard, consistent Start Printed Page 7484methodology for specifying the lifetime of refresh tokens in published technical specifications. As a result, we believe our approach would improve the current user experience for patients and providers alike. Additionally, authorization servers maintain binding between the refresh token and the application to whom it was issued, and hence can protect against misuse by unauthorized applications.

We believe that the three-month period is a reasonable length given the proposal for the re-issuance of a new refresh token. However, we acknowledge that this same policy outcome we discuss above could be achieved by, for example, having a two-month period. Accordingly, we seek comment on whether there are available specifications we should review as well as whether there should be a reasonable upper bound from a timing perspective (e.g., one year) after which the user should be required to re-authenticate and re-authorize.

For both the first time connection and subsequent connection proposals, we recognize that there is not yet a consistent, standardized specification for FHIR servers to handle data requests for multiple patients. As noted above, we expect that FHIR Release 4 will have such specificity. However, for the purposes of meeting this proposed certification criterion, we clarify that a health IT developer would be permitted to approach requests for multiple patients in the manner it deems most efficient.

Transparency Through the Publication of API Documentation

In the 2015 Edition final rule we included transparent documentation requirements for all three of the API-focused certification criteria adopted in § 170.315(g)(7) through (g)(9). These requirements specified that documentation associated with API syntax (and other technical descriptors), the software components and configurations that would be necessary in order for a deployed API to successfully work, and the terms of use for the API be made publicly available. We continue to believe that such a requirement is important for proposed § 170.315(g)(10), especially in light of the Cures Act's “without special effort” provision. Such transparency and openness is commonplace in many other industries and has fueled innovation, growth, and competition. Further, we believe that full transparency is necessary to ensure that software developers building to a health IT developer's (g)(10)-certified API have a thorough understanding of any requirements against which their software will need to be designed.

In reconciling the 2015 Edition final rule's API documentation requirements with the new expectations set forth by the Cures Act regarding a health IT developer's practices, we have determined that revisions are necessary. Accordingly, we propose to revise the documentation provision in the API certification criteria adopted in § 170.315(g)(7) through (g)(9) as well as reflect the same revision in proposed § 170.315(g)(10) and (11). Specifically, we propose to focus the documentation requirement set forth by the certification criteria on solely the technical documentation associated with the API technology. As a result, we propose to remove the provision in § 170.315(g)(7) through (g)(9) associated with “terms of use” as this type of documentation could be considered more reflective of business practice and better placed with other similar requirements. Consistent with the Cures Act's API Condition of Certification, we have proposed more detailed Condition of Certification requirements associated with a health IT developer's API terms of use in order to address business practices that could interfere with and create special effort on the part of an API User.

With respect to the technical documentation that would need to be made publicly available, we recognize that our proposed formal adoption of the FHIR standard and the associated implementation specifications (for § 170.315(g)(10)) would be consistent across all health IT presented for certification. As a result there may be minimal additional documentation needed for these capabilities beyond what is already documented in these standards and specifications. However, pursuant to the limited mandatory scope proposed for “data response” (for § 170.315(g)(10)), we believe that API Technology Suppliers should disclose any additional data their (g)(10)-certified API supports in the context of FHIR resources referenced in ARCH Version1 and associated implementation specifications. For example, the Argonaut IG “Patient Profile” includes optional elements for marital status, photo, and contact (as in contact person like a guardian or friend). To the degree that a (g)(10)-certified API supports such optional data an API Technology Supplier would be required to convey this support in its published technical documentation. Additionally, we note that other specifications, like the RFC 7591, provide developers some latitude in terms of the information that could be supplied for the purposes of registration.

Thus, we propose in § 170.315(g)(10)(vii) that an API Technology Supplier would need to provide detailed information for all aspects of its (g)(10)-certified API, especially for any unique technical requirements and configurations, such as how the FHIR server handles requests for multiple patients (until such time as there is an approved standardized approach that can be cited) as well as app registration requirements. For aspects that are not unique and are fully specified by the FHIR standard and associated implementation specifications, the developer could include hyperlinks to this information as part of its overall documentation. Further, we propose to include the word “complete” in the documentation provision in order to make this point explicit and link this obligation to the associated transparency conditions proposed as part of the overall Condition of Certification. We note for health IT developers that the documentation published must be of the sort and to the level of specificity, precision, and detail that the health IT developer customarily provides to its own employees, contractors, and/or partners who develop software applications for production environments.

Lastly, we note that all of the documentation referenced by this criterion must be accessible to the public via a hyperlink without additional access requirements, including, without limitation, any form of registration, account creation, “click-through” agreements, or requirement to provide contact details or other information prior to accessing the documentation. It would also require that such documentation needs to be submitted as part of testing for this certification criterion and subsequently to ONC-ACBs for review prior to issuing a certification.

d. Condition of Certification Requirements

To implement the Cures Act, we have designed this API Condition of Certification in a manner that will complement the technical capabilities described in our other proposals, while addressing the broader technology and business landscape in which these API capabilities will be deployed and used.

Consistent with the attributes we have identified for the statutory phrase “without special effort,” our overarching vision for this Condition of Certification is to ensure that (g)(10)- certified APIs, among all API Start Printed Page 7485technology, are deployed in a manner that supports an experience that is as seamless and frictionless as possible. To that end, we seek to promote a standards-based ecosystem that is transparent, scalable, and open to robust competition and innovation.

The specific requirements of this Condition of Certification are discussed in several sections below. These requirements would address certain implementation, maintenance, and business practices for which clear and consistent parameters are needed to ensure that API technology is deployed in a manner that achieves the policy goals we have described. The proposed requirements would also align this Condition of Certification with other requirements and policies of the Cures Act that promote interoperability and deter information blocking, as discussed in more detail in the sections that follow.

i. Scope and Compliance

To start this Condition of Certification, we propose in § 170.404 to apply this Condition of Certification to health IT developers with health IT certified to any of the API-focused certification criteria. These criteria include the proposed “standardized API for patient and population services” (§ 170.315(g)(10)) and “consent management for APIs” (§ 170.315(g)(11)) as well as the current “application access—patient selection” (§ 170.315(g)(7)), “application access—data category request” (§ 170.315(g)(8)), “application access—all data request” (§ 170.315(g)(9)). In other words, this entire Condition of Certification would not apply to health IT developers that do not have technology certified to any of these API-focused certification criteria. Similarly, this condition is solely applicable to these API-focused certification criteria. As a result, the proposed policies for this Condition of Certification would not apply to a health IT developer's practices associated with, for example, the immunization reporting certification criterion adopted in § 170.315(f)(1) because that criterion is not one of the API-focused criteria. However, health IT developers should remain mindful that other proposals in this proposed rule, especially those related to information blocking, could still apply to its practices associated with non-API-focused certification criteria.

Given the proposed applicability of this condition to current API-focused criteria and that health IT developers with products certified to §§ 170.315(g)(7)-(9) would need to meet new compliance requirements associated with such criteria, we also propose certain compliance timelines associated with this Condition of Certification that would need to be met.

ii. Cures Act Condition and Interpretation of Access to “All Data Elements”

First, we propose to adopt the Cures Act's API Condition of Certification in § 170.404(a)(1) to fully incorporate the statute's compliance requirements. Second, strictly for the scope of the API Condition of Certification, we propose to interpret the meaning of the phrase “all data elements of a patient's electronic health record” as follows.

For the reasons discussed above, the proposed § 170.315(g)(10) certification criterion and associated standards and implementation specifications would facilitate API access to a limited set of data elements (i.e., from the FHIR resources that ARCH Version 1). Accordingly, for the purposes of meeting this portion of the Cures Act's API Condition of Certification, we interpret the scope of: The ARCH; its associated implementation specifications; and the policy expressed around the data elements that must be supported by (g)(10)-certified APIs (i.e., FHIR servers) to constitute “all data elements.” Given other proposals related to permitting the use of updated versions of adopted standards and implementation specifications, we expect that (g)(10)-certified APIs will be able to support access to more data over time in response to updates to the USCDI and the ARCH. As these updates occur, the industry would be able to incrementally approach the totality of data that can be electronically accessed, exchanged, and used pursuant to the Cures Act's reference to “all data elements.”

Again, we reiterate that this specific interpretation does not extend beyond the API Condition of Certification and cannot be inferred to reduce the scope or applicability of other Cures Act Conditions of Certification or the information blocking proposals, which necessarily will include a larger scope of data. For example, other Conditions of Certification will apply to health IT developer behaviors associated with data that are not part of the USCDI or ARCH, such as the proposals at 45 CFR 170.402 and the proposals in Part 171, which apply across several stakeholders including health information networks and health care providers.

iii. Transparency Conditions

We propose as part of this Condition of Certification that API Technology Suppliers be required to make specific business and technical documentation freely and publicly accessible. Thus, we propose to adopt several transparency conditions as part of § 170.404(a)(2).

Similar to our policy associated with the API-focused certification criteria, we propose in § 170.404(a)(2)(i) that all published documentation be complete and available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. For example, the API Technology Supplier cannot impose any access requirements, including, without limitation, any form of registration, account creation, “click-through” agreements, or requirement to provide contact details or other information prior to accessing the documentation.

Terms and Conditions Transparency

In addition to technical documentation, we propose in § 170.404(a)(2)(ii)(A) to require API Technology Suppliers to publish all terms and conditions for use of its API technology. We believe that it is important to make this information readily accessible to API Data Providers, API Users, app developers, and other persons. This transparency would ensure that these stakeholders do not experience “special effort” in the form of unnecessary costs or delays to obtain the terms and conditions for API technology. Further, we believe that full transparency is necessary to ensure that app developers have a thorough understanding in advance of any terms or conditions that might apply to them and do not encounter unanticipated hurdles once they have committed to developing software or attempt to implement or deploy such software in production.

We note that this requirement would apply to all terms and conditions that apply to the API technology and its use. As noted above, and for the purposes of this proposal's scope, “API technology” refers to the specified API capabilities for Health IT Modules certified to § 170.315(g)(7) through (11) under the Program. We consider “terms and conditions” to include any fees, restrictions, limitations, obligations, registration process requirements, and other terms or conditions that would be material and needed to:

  • Develop software applications to interact with the API technology;
  • distribute, deploy, and enable the use of software applications in production environments that use the API technology;
  • use software applications, including to access, exchange, and use EHI by means of the API technology;Start Printed Page 7486
  • use any EHI obtained by means of the API technology; and
  • register software applications (as discussed in more below).

In addition, we propose in § 170.404(a)(2)(ii)(B) that any and all permitted fees charged by an API Technology Supplier for the use of its API technology must be published and described in detailed, plain language as part of its publicly available terms and conditions. The description of the fees must include all material information, including, but not limited to, the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee.

For the purposes of the specific transparency conditions proposed in § 170.404(a)(2) and their relationship and applicability to API Technology Suppliers with products already certified to § 170.315(g)(7), (8), or (9), we propose to establish a compliance date of six months from the final rule's effective date (which would give developers approximately eight months from the final rule's publication date) to revise their existing API documentation to come into compliance with the final rule. We also recognize that API Technology Suppliers will need to update the proposed publicly available information from time to time. Thus, for the purposes of and with respect to subsequent updates to this information, we expect API technology suppliers to make clear to the public the timing information applicable to their disclosures (e.g., effective/as of date or last updated date) in order to prevent out of sync discrepancies in what an API Technology Supplier's public documentation states and what it may be communicating directly to its customers (e.g., a change in fees is directly communicated to customers but not reflected at the publicly available hyperlink pursuant to its responsibilities under this proposal). If an API Technology Supplier's actions are out of sync with its publicly provided documentation, the API Technology Supplier would be at risk of violating this Condition of Certification. We request public comment on whether this expectation should be formally specified in regulation text or if these “effective date” approaches for changes to transparency documentation are common place such that it would be a standard practice as part of making this documentation available.

We also note that API Technology Suppliers would be expected to revise and/or construct terms and conditions for its API technology that account for and reflect the proposals associated with this API Condition of Certification and information blocking policies. In so far as an API Technology Supplier would find it necessary to enforce its published terms and conditions, we caution API Technology Suppliers to be mindful of whether such terms and conditions would be acceptable and consistent with the aforementioned policies in the first place—as an impermissible term or condition would be problematic regardless of whether it was actively enforced.

We propose in § 170.404(a)(2)(ii)(C) a final transparency condition associated with API Technology Suppliers' application developer verification processes that takes into account the fact that we did not propose to adopt the Dynamic Registration standard as part of proposed § 170.315(g)(10). Had we proposed requiring Dynamic Registration, we would have also proposed a specific Condition of Certification that would have outright prohibited API Technology Suppliers from identity proofing or verifying authenticity of an app developer when it came to apps that were designed to enable patient access.

On balance, however, we believe that permitting API Technology Suppliers to institute a process to verify the authenticity of application developers will foster additional trust in the growing API ecosystem. We seek comments and recommendations on factors that would enable registration with minimal barriers. For example, permitting API Technology Suppliers to do one- time verification of the app developers (or even rely on centralized vetting by a trusted third party), which would allow the developer's future apps to automatically register without case-by- case checks (or checks for each API Technology Supplier with which the app developer interacts). One risk to consider with Dynamic Registration plus a prohibition on vetting, for instance, is that it would be much easier for a malicious app developer to spoof another legitimate app developer's app. Such an action could ultimately lead to confusion and distrust in the market. However, the Dynamic Registration option would minimize barriers to registration especially for third-party apps designed to enable patient access. We seek comments on options and trade-offs we should consider.

Accordingly, and weighing those concerns with the Cures Act's “without special effort” provision and our proposed information blocking policies, we specifically propose to permit API Technology Suppliers to institute a process to verify the authenticity of application developers so long as such process is completed within five business days [91] of receipt of an application developer's request to register their software application with the API technology's authorization server. To clarify, this verification process would need to focus specifically on the application developer—not its software application(s). We also clarify that API Technology Suppliers would have the discretion to establish their verification process so long as the process is objective and the same for all application developers and it can reasonably be completed within the five business days—otherwise such a process could risk implicating/violating other elements of this proposed API Condition of Certification as well as information blocking behaviors. The following includes a few non-exhaustive examples of verification techniques that could be used by an API Technology Supplier to have additional certainty about the application developer with whom they are interacting: Instituting a “penny verification” process, requiring some form of corporate documentation, or requesting other forms of authenticating documentation or transactions.

We believe that five business days is sufficient time for API Technology Suppliers to weed out malicious developers seeking to deceive the API Technology Supplier, API Data Providers or API Users, but request public comment on other timing considerations. Moreover, we clarify that this proposed Condition of Certification is meant to set the upper bound for a verification process an API Technology Supplier would be permitted to take and should not be interpreted as compelling API Technology Suppliers to institute such a process (i.e., API Technology Suppliers would not be required to institute a verification process). Rather, for those API Technology Suppliers that see it in their (as well as their customers and patients) best interests to institute such a process, we have laid out the rules that we believe meet the Cures Act's without special effort expectations. If an API Technology Supplier chooses not to institute an app developer verification process prior to enabling the production use of an app, it would solely need to meet the Maintenance of Certification Start Printed Page 7487requirement associated with enabling apps for production use discussed in more detail below.

We remind stakeholders that even in the case where an API Technology Supplier chooses not to vet app developers, the apps would not have carte blanche access to a health care provider's data. To the contrary, such apps will still be registered and thus be identifiable and able to have their access deactivated by an API Technology Supplier or health care provider (API Data Provider) if they behave in anomalous or malicious ways (e.g., denial of service attack). And a patient seeking access to their data using the app will need to authenticate themselves (using previously issued credentials by a health care provider or trusted source) and authorize: (1) The app to connect to the FHIR server; and (2) specify the scope of the data the app may access.

As a separate matter, we also recognize that in order to assure health care providers that the apps they use within their health IT will operate appropriately, will fully integrate into workflow, and will not degrade overall system performance, that API Technology Suppliers may establish additional mechanisms to vet app developers. Such mechanisms could fit into the “value-added services” permitted fee and result in the app being acknowledged or listed by the health IT developer in some special manner (e.g., in an “app store,” “verified app” list). While our proposals do not specify any explicit limits to the nature and governance of these approaches, we wish to caution health IT developers that even though such processes have a reasoned basis in providing an added layer of trust above and beyond the basic production-readiness of an app, they can equally be used as a means to prevent, limit, and otherwise frustrate innovation, competition, and access to the market. Such an outcome would be inconsistent with the Cures Act, could directly violate the specific Condition of Certification associated with fees permitted for value-added services, and could constitute information blocking.

iv. Permitted Fees Conditions

General Proposals Involving Fees

As part of this API Condition of Certification, we propose to adopt specific conditions that would set boundaries for the fees API Technology Suppliers would be permitted to charge and to whom those permitted fees could be charged. As a reminder, these proposals would only apply to a health IT developer's business practices associated with its “API technology” (i.e., the capabilities certified to § 170.315(g)(7) through (11)). We seek comment on all of the following proposals.

In § 170.404(a)(3)(i)(A), we propose to establish a general prohibition on API Technology Suppliers imposing fees associated with API technology. This general prohibition is meant to ensure that API Technology Suppliers do not engage in pricing practices that create barriers to entry and competition for apps and API-based services that health care providers seek to use. These outcomes would be inconsistent with the goal of enabling API-based access, exchange, and use of EHI by patients and other stakeholders without special effort.

In establishing this general prohibition, we have been mindful of the need for API Technology Suppliers to recover their costs and to earn a reasonable return on their investments in providing API technology that has been certified under the Program. Accordingly, we have identified categories of “permitted fees” that API Technology Suppliers would be permitted to charge and still be compliant with the Condition of Certification and Program requirements, and discuss these proposals below. We emphasize, however, and propose in detail below, that API Technology Suppliers would not be permitted in any way whatsoever to impose fees on any person in connection with an API Technology Supplier's work to support the use of API technology to facilitate a patient's ability to access, exchange, or use their EHI.

We note that other than for fees charged for “value-added services” (proposed in § 170.404(a)(3)(iv)), the fees permitted under this Condition of Certification must arise between an API Technology Supplier and an API Data Provider. Any fee that arises in connection with an API User's use of API technology would need to exist solely between the API Data Provider and the API User. This policy reinforces the autonomy that we believe API Data Providers should have to establish relationships with API Users. However, as discussed in detail below, API Technology Suppliers would be permitted to charge API Data Providers based on the usage activities of API Users.

We also seek to clarify that while the proposed permitted fees set the boundaries for the fees API Technology Suppliers would be permitted to charge and to whom those permitted fees could be charged, they do not prohibit who may pay the API Technology Supplier's permitted fee. In other words, these conditions limit the party from which an API Technology Supplier may require payment, but they do not speak to who may pay the fee. For example, if through some type of relationship/agreement an API User or other party offered to pay the fee an API Data Provider owed to an API Technology Supplier, that practice would be allowed and unaffected under these conditions. This is an acceptable practice because the fee is first arrived at between the API Technology Supplier and API Data Provider, and then API Technology Supplier receives payment from another party via the API Data Provider or directly on behalf of the API Data Provider. As a general matter, we note that stakeholders should be mindful of other federal and state laws and regulations that could prohibit or limit certain types of relationships involving remuneration.

We note that the proposed “permitted fees conditions” align with the requirements of the information blocking exceptions proposed in 45 CFR 171.204 and 171.206. Any fee that would not be covered by those exceptions, and that would, therefore, be suspect under the information blocking provision, would equally not be permitted by this API Condition of Certification. We strongly encourage readers to review our proposals associated with those exceptions, which are contained in sections VIII.D.4 and VIII.D.6 of this preamble, respectively.

Permitted Fees—General Conditions

We propose in § 170.404(a)(3)(i)(B) general conditions that an API Technology Supplier's fee must satisfy in order for such fee to be expressly permitted and thus not contravene the proposed Condition of Certification. First, we propose in § 170.404(a)(3)(i)(B) (1) that in order to be a permitted fee, a fee imposed by an API Technology Supplier must be based on objective and verifiable criteria that are uniformly applied for all substantially similar or similarly situated classes of persons and requests. This would require an API Technology Supplier to apply fee criteria that, among other things, would lead an API Technology Supplier to come to the same conclusion with respect to the permitted fee's amount each time it interacted with a class of persons or responded to a request. Accordingly, the fee could not be based on the API Technology Supplier's subjective judgment or discretion.

Moreover, in order to be permitted, the fee must not be based in any part on Start Printed Page 7488whether the API User is a competitor or potential competitor, or on whether the API Data Provider or API User will be using the data accessed via the API technology in a way that facilitates competition with the API Technology Supplier. This condition is intended to ensure that any fee charged by an API Technology Supplier does not have the purpose or effect of excluding or creating impediments for competitors, business rivals, or other persons engaged in developing or enabling the use of API technology. We believe these fee limitations are necessary in light of the potential for API Technology Suppliers to use their control over API technology to engage in discriminatory practices that create barriers to API technology. These principles are consistent with the approach described in section VIII of this preamble (“information blocking”).

Second, we propose in § 170.404(a)(3)(i)(B) (2) that in order to be a permitted fee, a fee imposed by an API Technology Supplier must be reasonably related to the API Technology Supplier's costs of supplying and, if applicable, supporting the API technology to, or at the request of, the API Data Provider to whom the fee is charged. For example, the API Technology Supplier would not be permitted to charge a fee when the underlying costs relevant to the supply or service have already been accounted for or recovered through other fees (regardless of whether such fees were charged to the API Data Provider or to other persons). Moreover, an API Technology Supplier that conditioned access to its API technology on revenue-sharing or the entry into a royalty agreement would be at significant risk of imposing a fee that bore no plausible relation to the costs incurred by the API Technology Supplier to develop the API technology or support its use by API Users.

Third, we propose in § 170.404(a)(3)(i)(B) (3) to require that in order to be a permitted fee, the costs of supplying, and if applicable, supporting the API technology upon which the fee is based must be reasonably allocated among all customers to whom the API technology is supplied or for whom it is supported. A reasonable allocation of costs would require that the API Technology Supplier allocate its costs in accordance with criteria that are reasonable and between only those API Data Providers that either cause the costs to be incurred or benefit from the associated supply or support of the API technology. If an API Technology Supplier developed API technology that could be supplied to multiple customers with minimal tailoring, the core costs of developing its API technology should be allocated among those customers when recovered as a fee. The API Technology Supplier would not be permitted to recover the total of its core costs from each customer. Similarly, when an API Technology Supplier uses shared facilities and resources to support the usage of API technology, it would need to ensure that those shared costs were reasonably allocated between all of the customers that benefited from them. However, whenever an API Technology Supplier is required to provide services and incur costs that are unique to a particular customer, it would not need to distribute those costs among other customers that had deployed its API technology.

Last, we propose in § 170.404(a)(3)(i)(B) (4) to require that in order to be a permitted fee, the API Technology Supplier must ensure that fees are not be based in any part on whether the requestor or other person is a competitor, potential competitor, or will be using the API technology in a way that facilitates competition with the API Technology Supplier. The use of such criteria would be suspect because it suggests the fee the API Technology Supplier is charging is not based on its reasonable costs to provide the API technology or services and may have the purpose or effect of excluding or creating impediments for competitors, business rivals, or other persons engaged in developing or enabling the use of API technologies and services.

We request comments on these general conditions for permitted fees and whether commenters believe we have created effective guardrails to ensure that fees do not prevent EHI from being accessed, exchanged, and used through the use of APIs without special effort.

Specific Proposed Permitted Fees

As noted above, we propose that API Technology Suppliers would be prohibited from charging fees associated with API technology unless such fees are expressly permitted. Additionally, as a reminder, the scope of “API technology” subject to these proposals would only include certified health IT that fulfill the API-focused certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (g)(11). Thus, all other API functionality provided by a health IT developer with its product(s) that have no link to these certified capabilities would not be subject to this Condition of Certification.

The following proposals outline the specific circumstances in which an API Technology Supplier would be permitted to charge fees associated with API technology certified under the Program. A fee that satisfies one of the permitted fees in §§ 170.404(a)(3)(ii)-(iv) must also satisfy each of the general conditions in § 170.404(a)(3)(i) in order to be permitted and for its recovery compliant with this Condition of Certification.

Permitted Fee for Developing, Deploying, and Upgrading API Technology

In § 170.404(a)(3)(ii), we propose to permit an API Technology Supplier to charge API Data Providers reasonable fees for developing, deploying, and upgrading API technology. Fees for “developing” API technology comprise the API Technology Supplier's costs of designing, developing, and testing API technology to specifications that fulfill the requirements of the API-focused certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (g)(11). Fees for developing API technology must not include the API Technology Supplier's costs of updating the non-API related capabilities of the API Technology Supplier's existing health IT, including its databases, as part of its development of the API technology. These costs would be connected to past business decisions made by the API Technology Supplier and typically arise due to health IT being designed or implemented in nonstandard ways that unnecessarily increase the complexity, difficulty or burden of accessing, exchanging, or using EHI. The recovery of the costs associated with updating an API Technology Supplier's health IT generally would be inconsistent with the Cures Act requirement that API technology be deployed “without special effort.”

The API Technology Supplier's fees for “deploying” API technology comprise the API Technology Supplier's costs of operationalizing API technology in a production environment. Such fees include, but are not limited to, standing up hosting infrastructure, software installation and configuration, and the creation and maintenance of API Data Provider administrative functions. An API Technology Supplier's fees for “deploying” API technology does not include the costs associated with managing the traffic of API calls that access the API technology, which an API Technology Supplier can only recover under the permitted fee for usage support costs under § 170.404(a)(3)(iii). For clarity, we reiterate that for the purpose of this Condition of Certification, we consider Start Printed Page 7489that API technology is “deployed” by the customer—the API Data Provider—that purchased or licensed it.

The API Technology Supplier's fees for “upgrading” API technology comprise the API Technology Supplier's costs of supplying an API Data Provider with an updated version of API technology. Such costs would include the costs required to bring API technology into conformity with new requirements of the Program, upgrades to implement general software updates (not otherwise covered by development fees or under warranty), or developing and releasing newer versions of the API technology at the request of an API Data Provider.

The nature of the costs that can be charged under this category of permitted fees will depend on the scope of the work to be undertaken by an API Technology Supplier (i.e., how much or how little labor an API Data Provider requires of the API Technology Supplier to deploy and upgrade the API technology being supplied). For example, where an API Data Provider decides to fully outsource the deployment of its API technology to its API Technology Supplier, the API Technology Supplier's costs will include the work associated with the development of the API technology, the work deploying the API technology, and any work upgrading the API technology.

We propose that any fees that an API Technology Supplier charges for developing, deploying, or upgrading API technology must be charged solely to the API Data Provider(s) for whom the capabilities are deployed. We propose this limitation because we believe that these costs should be negotiated between the API Technology Supplier that supplies the capabilities and the API Data Provider (i.e., health care provider) that implements them in its production environment. In our view, it is inappropriate to pass these costs on to API Users as doing so would impose considerable costs on the API Data Provider's current or potential partners, such as those offering third-party applications and services, as well as the end-users of API technology and would amount to the kind of “special effort” that the Cures Act's API Condition of Certification seeks to prevent.

Subject to the general conditions proposed in § 170.404(a)(3)(i) and discussed above, API Technology Suppliers can recover the full range of reasonable costs associated with developing, deploying, and upgrading API technology over time. We believe it is important that API Technology Suppliers be able to recover these costs and earn a reasonable return on their investments so that they have adequate incentives to make continued investments in these technologies. In particular, we anticipate that API Technology Suppliers will need to continually expand the data elements and upgrade the capabilities associated with Certified APIs as the FHIR standard and its implementation specifications mature, and the National Coordinator expands the USCDI and ARCH.

Permitted Fee To Recover Costs of Supporting API Usage for Purposes Other Than Patient Access, Exchange, and Use

In § 170.404(a)(3)(iii) we propose to permit an API Technology Supplier to charge usage-based fees to API Data Providers to the extent that the API technology is used for purposes other than facilitating access, exchange, or use of EHI by patients or their applications, technologies, or services.

We consider “usage-based” fees to be the fees imposed by an API Technology Supplier to recover the costs that would typically be incurred supporting API interactions at increasing volumes and scale within established service levels. That is, “usage-based” fees recover costs incurred by an API Technology Supplier due to the actual use of the API technology once it has been deployed (e.g., costs to support a higher volume of traffic, data, or number of apps via the API technology). We acknowledge that API Technology Suppliers could adopt a range of pricing methodologies when charging for the support of API usage. We expect that API usage support fees would only come into play when the API Technology Supplier acts on behalf of the API Data Provider to deploy its API technology. Thus, the costs recovered under “usage-based” fees would only be able to reflect “post-deployment” costs. As such, “usage-based” fees would not be allowed to include any costs necessary to prepare and “get the API technology up, running, and ready for use,” which are costs that we propose should be recovered as part of the deployment services delivered by the API Technology Supplier if permitted under § 170.404(a)(3)(ii). We believe this Condition of Certification offers the flexibility necessary to accommodate reasonable pricing methodologies and will allow API Technology Suppliers to explore innovative approaches to recovering the costs associated with supporting API use as a permitted fee.

As discussed above, we expect that API usage support fees would only come into play when the API Technology Supplier acts on behalf of the API Data Provider to deploy its API technology. Conversely, in scenarios where the API Data Provider, such as a large hospital system, assumes full responsibility for the technical infrastructure necessary to deploy and host the API technology it has acquired, the volume and scale of its usage would be the API Data Provider's sole responsibility. As a result, in this scenario and under our proposal's structure, an API Technology Supplier would not be permitted to charge usage-based fees. Instead, the API Technology Supplier would be limited to the fees it would be permitted to recover through the “development, deployment, upgrade” permitted fee discussed above.

We reiterate, that “usage-based” fees would need to be settled between an API Technology Supplier and API Data Provider. The API Technology Supplier would have no standing to go around or through the API Data Provider to issue fees to, for example, a population health analytics company engaged by an API Data Provider who accesses the API Data Provider's data via the API technology.

We propose that any usage-based fees associated with API technology be limited to the recovery of the API Technology Supplier's “incremental costs.” An API Technology Supplier's “incremental costs” comprise the API Technology Supplier's costs that are directly attributable to supporting API interactions at increasing volumes and scale within established service levels. We propose than an API Technology Supplier should “price” its costs of supporting access to the API technology by reference to the additional costs that the API Technology Supplier would incur in supporting certain volumes of API use. In practice, we expect that this means that API Technology Suppliers will offer a certain number of “free” API calls based on the fact that, up to a certain threshold, the API Technology Supplier will not incur any material costs in supporting API technology in addition to the costs recovered for deployment services. However, after this threshold is exceeded, we expect that the API Technology Supplier will impose usage-based costs commensurate to the additional costs that the API Technology Supplier must incur to support API technology use at increasing volumes and scale.

We expect that API Technology Suppliers would charge fees that are correlated to the incremental ratchetting up of the cost required to meet increased demand. For example, if, at a certain volume of API calls, the API Technology Supplier needed to deploy Start Printed Page 7490additional server capacity, the associated incremental cost of bringing an additional server online could be passed on to the API Data Provider because the API technology deployed on behalf of the API Data Provider was the subject of the higher usage. Up until the point that the threshold is reached, the additional server capacity was not required and so the API Technology Supplier would not be permitted to recover the cost associated with it. Moreover, the additional server capacity would support ongoing demand up to a certain additional volume, and so the API Technology Supplier would not be permitted to recover the costs of further additional server capacity until the then current capacity was exhausted.

Notwithstanding the above, we note that API Technology Suppliers may choose to charge for their API usage support services on a “pay as you go” basis, such as a fee-per-call pricing structure. This approach could be consistent with the requirement that the API Technology Supplier only impose its incremental costs, and the requirements of this Condition of Certification more generally. However, depending on the amount being charged, this pricing model is open to abuse, with API Data Providers at risk of paying unreasonably high fees if the volume of API use is high and when the API Data Provider does not share in the benefits enjoyed by the API Technology Supplier when delivering a service at scale. As such, the API Technology Supplier would need to be careful to ensure that the total fees paid by an API Data Provider were reasonably related to the API Technology Supplier's costs of supporting the API technology. Where the fees paid over a reasonable measuring period were not reasonably related to the API Technology Supplier's costs, they would not be permitted.

We are also aware that API Technology Suppliers may offer a pricing structure for API usage support based on unlimited API calls. That is, the API Technology Supplier may charge a flat-fee irrespective of the volume of traffic accessing the API technology. Such a pricing model would be allowed under the proposed condition provided that the API Technology Supplier's fee for API usage support was reasonably related to the cost of the services that it had agreed to provide. This would mean that the API Technology Supplier would need to make a realistic estimate of the volume of API calls that it would need to support to fulfill any service level promised, and calculate its fee based on the costs of supporting that call volume. So long as the API Technology Supplier made a realistic estimate of the anticipated volume and support level, the legitimacy of the API Technology Supplier's fees, and its ability to recover them as permitted fees, would be unaffected by API Users making lower than expected use of API technology.

In the context of this proposed permitted fee's scope and the proposed general prohibition on fees, we seek to make clear that API Technology Suppliers would be prohibited from charging (or including in their contracts and agreements with API Data Providers) any usage-based fees for API uses that are associated with the access, exchange, and use of EHI by patients or their applications, technologies, or services. This would include, among other things, API calls or other transactions initiated by or on behalf of a patient, including third parties (e.g., an application or any other technology or service) authorized by the patient or their representative to request data on their behalf.

Usage fees associated with the access, exchange, and use of EHI by patients is a specific example of a prohibited fee that would fit under the general prohibition of a “fee not otherwise permitted” and is based on several considerations. First, such fees between an API Technology Supplier and API Data Provider would likely be passed on directly to patients, creating a significant impediment to their ability to access, exchange, and use their EHI, without special effort, through applications and technologies of their choice. More fundamentally, most of the information contained in a patient's electronic record has been documented during the practice of medicine or has otherwise been captured in the course of providing health care services to patients. In our view, patients have effectively paid for this information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf. Thus, our proposal reflects our belief that it is inappropriate to charge patients additional costs to access this information, whether those costs are charged directly to patients or passed on as a result of fees charged to persons that provide apps, technologies, and services on a patient's behalf.

To be clear, if an API Data Provider sought to employ API technology for the limited purpose of making EHI available to patients and their apps, the API Data Provider's API Technology Supplier would have no legitimate basis to charge the API Data Provider, or any other person, for the “patient access” usage-based costs associated with the API technology.

Any unreasonable fees associated with a patient's access to their EHI may be suspect under the information blocking provision. Such fees may also be inconsistent with an individual's right of access to their PHI under the HIPAA Privacy Rule (45 CFR 164.524).)

In addition to our proposal in § 170.404(a)(3)(iii)(A) and detailed above that this permitted fee would not include any costs incurred by the API Technology Supplier to support uses of the API technology that facilitate a patient's ability to access, exchange, or use their electronic health information, we also propose to explicitly exclude two additional costs from this permitted fee. In § 170.404(a)(3)(iii)(B), we propose that this permitted fee would not include costs associated with intangible assets (including depreciation or loss of value), except the actual development or acquisition costs of such assets. For instance, an API Technology Supplier could not charge an API Data Provider a fee based on the purported “cost” of allowing the API Data Provider to use the API Technology Supplier's patented API technology. As discussed in more detail in section VIII.D.4 (Information Blocking), we believe it would be inappropriate to permit an actor to charge a fee based on these considerations, which are inherently subjective and could invite the kinds of rent-seeking and opportunistic pricing practices that create barriers to access, use, and exchange of EHI and impede interoperability.

In § 170.404(a)(3)(iii)(C), we propose that this permitted fee would not include opportunity costs, except for the reasonable forward-looking cost of capital. These speculative costs could include revenues that an API Technology Supplier could have earned had it not provided the API technology. We clarify that the exclusion of opportunity costs would not preclude an API Technology Supplier from recovering its reasonable forward-looking cost of capital. We believe these costs are relatively concrete and that permitting their recovery will protect incentives for API Technology Suppliers to invest in developing and providing interoperability elements (as described in section VIII.D.4).

Permitted Fee for Value-Added Services

In § 170.404(a)(3)(iv) we propose to permit an API Technology Supplier to charge fees to API Users [92] for value-Start Printed Page 7491added services supplied in connection with software that can interact with the API technology. These “value-added services” would need to be provided in connection with and supplemental to the development, testing, and deployment of software applications that interact with API technology. Critically, fees would not be permitted if they interfere with an API User's ability to efficiently and effectively develop and deploy production-ready software. This means that in order to be permitted, an API User could not be required to incur the fee in order to develop and deploy a production-ready software application that interacts with the API technology acquired by the API Data Provider. Rather, a fee will only be permitted if it relates to a service that a software developer can elect to purchase, but is not required to purchase in order to develop and deploy production-ready apps.

We believe it appropriate to permit this type of fee because API Technology Suppliers may offer a wide-range of market differentiating services to make it attractive for API Users to develop software applications that can interact with the API technology supplied by an API Technology Supplier. Such services could include advanced training, premium development tools and distribution channels, and enhanced compatibility/integration testing assessments. For example, an API Technology Supplier would be permitted to charge fees for value-added services that would be associated with but go beyond the scope set by the (g)(10)-certified API, such as write access, co-branded integration into the API Technology Supplier's product(s) workflow, co-marketing arrangements, and promoted placement in an API Technology Supplier's app store. That said, we caution API Technology Suppliers that value-added services would have to be made available in a manner that complies with other requirements of this Condition of Certification and with the information blocking provision.

To illustrate the scope of the fees permitted under this proposal, we clarify that the permitted value-added services fee would enable an API Technology Supplier to recover certain costs associated with operating an “app store.” However, those fees cannot interfere with an API User's ability to efficiently and effectively develop and deploy production-ready apps without special effort. We are aware that API Technology Suppliers offer services associated with the listing and promotion of apps beyond basic app placement. Such fees would be permitted, so long as the API Technology Supplier ensured that basic access and listing in the app store was provided free of charge if an app developer depended on such listing to efficiently and effectively develop and deploy production-ready apps without special effort. Fees charged for additional/specialized technical support or promotion of the API User's app beyond these basic access and listing services would also be permitted. In contrast, if an API Technology Supplier required, for example, a software developer's app to go through a paid listing process as a dependency/precondition to be able to be deployed (and generally accessible) to the API Technology Supplier's health care provider customers to use, this would not be a permitted fee under this Condition of Certification, would constitute special effort, and could raise information blocking concerns.

Prohibited Fees

As discussed above, we proposed that any API-related fee imposed by an API Technology Supplier that is not expressly permitted is prohibited. This approach is necessary because, as discussed in section VIII.C.5.c of this proposed rule, we continue to receive evidence that some health IT developers are engaging in practices that create special effort when it comes to API technology. These practices include fees that create barriers to entry or competition as well as rent-seeking and other opportunistic behaviors. For example, some health IT developers are conditioning access to technical interoperability documentation on revenue-sharing or royalty agreements that bear no plausible relation to the costs incurred by the health IT developer to provide or enable its use. We are also aware of discriminatory pricing policies that have the purpose or effect of excluding competitors from the use of APIs and other interoperability elements. These practices close off the market to innovative applications and services that could empower patients and enable providers to deliver greater value and choice to health care consumers and additional service providers.

To address these concerns we provide the following non-exhaustive examples of fees for services that API Technology Suppliers would be prohibited from charging:

  • Any fee for access to the documentation that an API Technology Supplier is required to publish or make available under this Condition of Certification.
  • Any fee for access to other types of documentation or information that a software developer may reasonably require to make effective use of API technology for any legally permissible purpose.
  • Any fee in connection with any services that would be essential to a developer or other person's ability to develop and commercially distribute production-ready applications that use API technology. These services could include, for example, access to “test environments” and other resources that an app developer would need to efficiently design and develop apps. The services could also include access to distribution channels if they are necessary to deploy production-ready software and to production resources, such as the information needed to connect to FHIR servers (endpoints) or the ability to dynamically register with an authorization server.

Permitted Fees Request for Comment

We request comment on any additional specific “permitted fees” not addressed above that API Technology Suppliers should be able to recover in order to assure a reasonable return on investment. Furthermore, we request comment on whether it would be prudent to adopt specific, or more granular, cost methodologies for the calculation of the permitted fees. Commenters are encouraged to consider, in particular, whether the approach we have described will be administrable and appropriately balance the need to ensure that patients, providers, app developers, and other stakeholders do not encounter unnecessary costs and other special effort with the need to provide adequate assurance to API Technology Suppliers, investors, and innovators that they will be able to earn a reasonable return on their investments in API technology. We welcome comments on whether the approach adequately balances these concerns or would achieve our stated policy goals, and we welcome comments on potential revisions or alternative approaches. We encourage detailed comments that include, where possible, economic justifications for suggested revisions or alternative approaches.

Record-Keeping Requirements

To provide appropriate accountability, we propose in § 170.404(a)(3)(v) that API Technology Suppliers must keep for inspection Start Printed Page 7492detailed records of all fees charged with respect to API technology and all costs that it claims to have incurred to provide API technology to API Data Providers. To provide assurance that the API Technology Supplier's fees are reasonably related to the API Technology Supplier's costs, the API Technology Supplier would need to document, with the same level of detail, any fees charged and associated costs incurred to provide other services to which any portion of the costs could reasonably be attributed. For example, if the API Technology Supplier charges a fee that reflects its costs for internet servers used to provide the API technology, the API Technology Supplier would need to document the costs of any other internet-based services it provides, as well as any other purposes for which the internet servers are used.

Separately, an API Technology Supplier would need to document the criteria it used to allocate any costs across relevant customers, requestors, or other persons. The criteria must be documented in a level of detail that would enable determination as to whether the API Technology Supplier's cost allocations are objectively reasonable and comply with the cost accountability requirements, including whether fees reflect the API Technology Supplier's actual costs reasonably incurred, were allocated reasonably and between only those API Data Providers that either cause the costs to be incurred or benefit from the associated supply or support of the API technology, and were distributed across customers and other relevant persons in a permissible manner, as described above.

We note that an API Technology Supplier must retain its accounting records consistent with the retention requirement proposed for adoption as part of the Assurances Condition of Certification (proposed for adoption in § 170.402). In the event that a potential violation of this Condition and Maintenance of Certification creates a conformance fact-finding scenario by ONC or information blocking is investigated, we believe that this period of time would provide ONC with appropriate visibility into the API Technology Supplier's business practices.

We request comment on whether these requirements provide adequate traceability and accountability for costs permitted under this API Condition of Certification. We also seek comment on whether to require more detailed accounting records or to prescribe specific accounting standards.

iv. Openness and Pro-Competitive Conditions

We propose that API Technology Suppliers would have to comply with certain requirements to promote an open and competitive marketplace. As a general condition, we propose in § 170.404(a)(4) that API Technology Suppliers must grant API Data Providers (i.e., health care providers who purchase or license API technology) the sole authority and autonomy to permit API Users to interact with the API technology deployed by the API Data Provider. We reinforce this general condition through more specific proposed conditions proposals discussed below that would require API Technology Suppliers to provide equitable access to API technology, which would include granting the rights and providing the cooperation necessary to enable apps to be deployed that use the API technology to access, exchange, and use EHI in production environments.

As important context for these proposals, we note that the API technology required by this Condition of Certification falls squarely within the concept of “essential interoperability elements” described in section VIII.C.4.b of this preamble and, as such, are subject to strict protections under the information blocking provision. As a corollary, to the extent that API Technology Suppliers claim an intellectual property right or other proprietary interest in the API technology, they must take care not to impose any fees, require any license terms, or engage in any other practices that could add unnecessary cost, difficulty, or other burden that could impede the effective use of the API technology for the purpose of enabling or facilitating access, exchange, or use of EHI. Moreover, even apart from these information blocking considerations, we believe that, as developers of technology certified under the Program, API Technology Suppliers owe a special responsibility to patients, providers, and other stakeholders to make API technology available in a manner that is truly “open” and minimizes any costs or other burdens that could result in special effort. The proposed conditions set forth below are intended to provide clear rules and expectations for API Technology Suppliers so that they can meet these obligations.

Non-Discrimination

We propose in § 170.404(a)(4)(i) that an API Technology Supplier must adhere to a strictly non-discriminatory policy regarding the provision of API technology. As a starting point, we propose to require in § 170.404(a)(4)(i)(A) that API Technology Suppliers comply with all of the requirements discussed in section VIII.C.4.b of this proposed rule regarding the non-discriminatory provision of interoperability elements. Accordingly, and consistent with developers' obligations under the Program and our expectation that API technology be truly “open,” we propose to require that API Technology Suppliers must provide API technology to API Data Providers on terms that are no less favorable than they would provide to themselves and their customers, suppliers, partners, and other persons with whom they have a business relationship. This requirement would apply to both price and non-price terms and thus would apply to any fees that the API Technology Supplier is permitted to charge under the “permitted charges conditions” of this Condition of Certification. We believe this requirement would ensure that API Data Providers (i.e., health care providers) who purchase or license API technology have sole authority and autonomy to permit third-party software developers to connect to and use the API technology they have acquired.

Next, we propose in § 170.404(a)(4)(i)(B) that any terms and conditions associated with API technology would have to be based on objective and verifiable criteria that are uniformly applied for all substantially similar or similarly situated classes of persons and requests. For example, if the API Technology Supplier applied an “app store” entry/listing process unequally and added arbitrary criteria based on the use case(s) an app was focused on, such business practices would not comply with this specific condition and could also be in violation of the information blocking provision.

Moreover, we propose in § 170.404(a)(4)(i)(C) that an API Technology Supplier would be prohibited from offering or varying such terms or conditions on the basis of impermissible criteria, such as whether the API User with whom the API Data Provider has a relationship is a competitor, potential competitor, or will be using EHI obtained via the API technology in a way that facilitates competition with the API Technology Supplier. The API Technology Supplier would also be prohibited from taking into consideration the revenue or other value the API User with whom the API Data Provider has a relationship may derive from access, exchange, or use of EHI obtained by means of the API technology. We believe these proposals Start Printed Page 7493will help promote greater equity and competition in market as well as prevent discriminatory business practices by API Technology Suppliers.

Rights To Access and Use API Technology

We propose in § 170.404(a)(4)(ii)(A) that an API Technology Supplier would have to make API technology available in a manner that enables API Data Providers and API Users to develop and deploy apps to access, exchange, and use EHI in production environments. To this end, we propose that an API Technology Supplier must have and, upon request, must grant to API Data Providers and their API Users all rights that may be reasonably necessary to access and use API technology in a production environment. In other words, this proposal is focused on the provision of rights reasonably necessary to access and use API technology and does not extend to other intellectual property maintained by the API Technology Supplier, especially intellectual property that has no nexus with the access and use of API technology. In situations where such a nexus exists, even partially, the API Technology Supplier would have the duty to determine a method to grant the applicable rights reasonably necessary to access and use the API technology. And if practicable, under these partial cases, we note that it would be possible for the API Technology Supplier to exclude the intellectual property that would have no impact on the access and use of the API technology.

Accordingly, following our proposal, API Technology Suppliers would need to grant API Data Providers and their API Users with rights that could include but not be limited to the following in order to sufficiently support the use of the API technology:

  • For the purposes of developing products or services that are designed to be interoperable with the API Technology Supplier's health IT or with health IT under the API Technology Supplier's control.
  • Any marketing, offering, and distribution of interoperable products and services to potential customers and users that would be needed for the API technology to be used in a production environment. Note, API Technology Suppliers, pursuant to the “value-added services” permitted fee, would be able to offer and charge for services such as preferential marketing agreements, co-marketing agreements, and other business arrangements so long as such services are beyond what is necessary for the API technology to be put into use in a production environment.
  • Enabling the use of the interoperable products or services in production environments, including accessing and enabling the exchange and use of electronic health information.

Relatedly, in § 170.404(a)(4)(ii)(B) we propose to prohibit an API Technology Supplier from imposing any collateral terms or agreements that could interfere with or lead to special effort in the use of API technology for any of the above purposes. We note that these collateral terms or agreements may also implicate the information blocking provision for the reasons described in section VIII.D.3.c of this preamble. These specific proposed conditions would expressly prohibit an API Technology Supplier from conditioning any of the rights described above on the requirement that the recipient of the rights do, or agree to do, any of the following:

  • Pay a fee to license the rights described above, including but not limited to a license fee, royalty, or revenue-sharing arrangement.
  • Not compete with the API Technology Supplier in any product, service, or market.
  • Deal exclusively with the API Technology Supplier in any product, service, or market.
  • Obtain additional licenses, products, or services that are not related to or can be unbundled from the API technology.
  • License, grant, assign, or transfer any intellectual property to the API Technology Supplier.
  • Meet additional developer or product certification requirements.
  • Provide the API Technology Supplier or its technology with reciprocal access to application data.

These prohibitions largely mirror those proposed under the exception to the information blocking definition in § 171.206 and reflect the same concerns expressed in that context in section VIII.D.3.c of this preamble. However, we note the following important distinction: Whereas proposed § 171.206 would permit a developer to charge a reasonable royalty to license interoperability elements, this API Condition of Certification would not permit any such royalty, license fee, or other type of fee of any kind whatsoever pursuant to the general fee prohibition proposed in the “permitted charges condition.” This additional limitation reflects the more exacting standards that apply to API Technology Suppliers with respect to the provision of API technology under this Condition of Certification. While we believe that, for the reasons described in section VIII.D.3.c of this preamble, health IT developers should generally be permitted to charge reasonable royalties for the use of their intellectual property, we consider API technology to be a special case. Certified health IT developers (i.e., API Technology Suppliers) are required to provide these capabilities as part of their statutory duty to facilitate the access, exchange, and use of patient health information from EHRs “without special effort.” We believe the language requiring that these capabilities be “open” precludes an API Technology Supplier from conditioning access to API technology on the payment of a royalty or other fee, however “reasonable” the fee might otherwise be.

We clarify that the prohibitions explained above against additional developer or Health IT Module certification requirements and, separately, against requirements for reciprocal access to application data, are within the scope of the collateral terms prohibited by proposed § 171.206 even though these additional API Technology Supplier requirements are not explicitly referenced by that exception because they are not generally applicable to all types of interoperability elements. Nevertheless, permitting an API Technology Supplier to impose these kinds of additional requirements would be inconsistent with the Cures Act's expectation that API technology be made available openly and in a manner that promotes competition. For the same reason such practices may raise information blocking concerns.

API Technology Suppliers—Additional Obligations

To support the use of API technology in production environments, we propose in § 170.404(a)(4)(iii) that an API Technology Supplier must provide all support and other services that are reasonably necessary to enable the effective development, deployment, and use of API technology by API Data Providers and its API Users in production environments. In general, the precise nature of these obligations will depend on the specifics of the API Technology Supplier's technology and the manner in which it is implemented and made available for specific customers. Therefore, with the following exceptions, we do not delineate the API Technology Supplier's specific support obligations and instead propose a general requirement to this effect in § 170.404(a)(4)(iii).Start Printed Page 7494

Changes and Updates to API Technology and Terms and Conditions

We propose to require in § 170.404(a)(4)(iii)(A) that API Technology Suppliers must make reasonable efforts to maintain the compatibility of the API technology they develop and assist API Data Providers to deploy in order to avoid disrupting the use of API technology. Similarly, we propose in § 170.404(a)(4)(iii)(B) that prior to making changes or updates to its API technology or to the terms or conditions thereof, an API Technology Supplier would need to provide notice and a reasonable opportunity for its API Data Provider customers and registered application developers to update their applications to preserve compatibility with its API technology or to comply with any revised terms or conditions. Without this opportunity, clinical and patient applications could be rendered inoperable or operate in unexpected ways unbeknownst to the users or software developers.

Further, we note that this proposal aligns with the exception to the information blocking definition proposed in § 171.206. As explained in section VIII.D.3.c of this preamble, the information blocking definition would be implicated were an API Technology Supplier to make changes to its API technology that “break” compatibility or otherwise degrade the performance or interoperability of the licensee's products or services that incorporate the licensed API technology. We propose these additional safeguards are important in light of the ease with which an API Technology Supplier could make subtle “tweaks” to its technology or related services, which could disrupt the use of the licensee's compatible technologies or services and result in substantial competitive and consumer injury.

We clarify that this requirement would in no way prevent an API Technology Supplier from making improvements to its technology or responding to the needs of its own customers or users. However, the API Technology Supplier would need to demonstrate that whatever actions it took were necessary to accomplish these purposes and that it afforded the licensee a reasonable opportunity under the circumstances to update its technology to maintain interoperability. Relatedly, we recognize that an API Technology Supplier may have to suspend access or make other changes immediately and without prior notice in response to legitimate privacy, security, or patient safety-related exigencies. Such practices would be permitted by this Condition of Certification provided they are tailored and do not unnecessarily interfere with the use of API technology. From an information blocking standpoint, if such practices interfered with access, exchange, or use of EHI, the API Technology Supplier could seek coverage under the exceptions to the information blocking provision described in section VIII.D of this preamble. For instance, if the suspended access was in response to a privacy exigency, the API Technology Supplier may be able to seek coverage under the exception for promoting the privacy of EHI at proposed § 171.202.

e. Maintenance of Certification Requirements

We propose to adopt Maintenance requirements for this Condition of Certification. These maintenance requirements would be duties that we believe the Cures Act expected API Technology Suppliers (i.e., health IT developers) would need to comply with in the course of maintaining their Health IT Module(s)' certification.

i. App Registration Timeliness

In the specific context of application registration, we wish to underscore that to provide a frictionless experience for developers of these applications and individuals that use them, an API Technology Supplier would be required to provide all services and other support necessary to ensure that such apps can be deployed and used in production without any additional assistance or intervention by the API Technology Supplier. For this reason, we propose in § 170.404(b)(1) a specific requirement for API Technology Suppliers that they would need to “register” (in connection with the API technology functionality proposed in § 170.315(g)(10)(iii)) and enable all applications for production use within one business day of completing its verification of an application developer's authenticity as described in proposed § 170.404(a)(2)(ii)(C). We propose this explicit requirement is necessary in order to ensure that a patient's ability to use an app of their choice is not artificially or intentionally slowed by an API Technology Supplier, causing special effort on the part of the patient to gain access to their EHI. We also emphasize that this is specific duty for API Technology Suppliers in the course of maintaining the Health IT Module(s)' certificate to which their API technology is associated. In instances where an API Technology Supplier chooses not to perform app developer verification processes described in proposed § 170.404(a)(2)(ii)(C), it would need to solely meet this one business day requirement from the point of having received a request for registration.

ii. Publication of FHIR Endpoints

In order to interact with a FHIR RESTful API, an app needs to know the “FHIR Service Base URL,” which is often referred to colloquially as a “FHIR server's endpoint.” [93] The public availability and easy accessibility of this information is a central necessity to assuring the use of FHIR-based APIs without special effort, especially for patient access apps. Accordingly, we propose to adopt in § 170.404(b)(2) a specific requirement that an API Technology Supplier must support the publication of Service Base URLs for all of its customers, regardless of those that are centrally managed by the API Technology Supplier or locally deployed, and make such information publicly available (in a computable format) at no charge. In instances where an API Technology Supplier is contracted by an API Data Provider to manage its FHIR server, we expect that this administrative duty will be relatively easy to manage. In instances where an API Data Provider assumes full responsibility to “locally manage” its FHIR server, the API Technology Supplier would be required, pursuant to this proposed maintenance requirement, to obtain this information from its customers. We strongly encourage API Technology Suppliers, health care providers, HINs and patient advocacy organizations to coalesce around the development of a public resource or service from which all stakeholders could benefit. We believe this would help scale and enhance the ease with which Service Base URLs could be obtained and used.

iii. Providing (g)(10)-Certified APIs to API Data Providers

We propose in § 170.404(b)(3) that an API Technology Supplier with API technology previously certified to the certification criterion in § 170.315(g)(8) must provide all API Data Providers with such API technology deployed with API technology certified to the certification criterion in § 170.315(g)(10) within 24 months of this final rule's effective date. We believe this Maintenance of Certification requirement will permit ONC to monitor and facilitate the rollout to health care providers of this important functionality. This is of particular relevance as we propose below to include this functionality in the 2015 Base EHR definition in place of the Start Printed Page 7495current “application access—data category request” certification criterion (§ 170.315(g)(8)), which means health care providers will need this functionality to meet the Certified EHR Technology (CEHRT) for associated Centers for Medicare & Medicaid Services (CMS) programs.

f. 2015 Edition Base EHR Definition

As described in detail above, we have propose to adopt a new certification criterion in § 170.315(g)(10) that would replace the current criterion adopted in § 170.315(g)(8) and as referenced in the 2015 Edition Base EHR definition expressed in § 170.102. This change is necessary to fully implement the Cures Act and ensure that API Technology Suppliers have the requisite incentive to deploy standardized APIs that can be used “without special effort” and API Data Providers have added incentive to adopt such functionality. As result, we propose to create a phase-in for the proposed API certification criterion in § 170.315(g)(10) from the issuance of a subsequent final rule. This phase-in period includes separate and sequential time for API Technology Suppliers and API Data Providers.

Consistent with our proposed compliance timing for the certification criterion proposed for adoption in § 170.315(b)(10), we propose to add compliance timeline language to the 2015 Edition Base EHR definition for the transition from § 170.315(g)(8) to § 170.315(g)(10) that would reflect a total of 24 months from the final rule's effective date (which practically speaking would be 25 months because of the 30-day delayed effective date). We believe this approach is best because it identifies a single, specific date for both API Technology Suppliers and API Data Providers by which upgraded API technology needs to be deployed in production. We also believe that 24 months is sufficient for this upgrade because the scope and nature of our proposals intersect and reflect a large portion of capabilities API Technology Suppliers have already developed and deployed to meet § 170.315(g)(8). Moreover, this single date enables API Technology Suppliers (based on their client base and IT architecture) to determine the most appropriate timeline for development, testing, certification, and product release cycles in comparison to having to meet an arbitrary “must be certified by this date” requirement.

5. Real World Testing

The Cures Act requires, as a Condition and Maintenance of Certification under the Program, that health IT developers have successfully tested the real world use of the technology for interoperability in the type of setting in which such technology would be marketed. The Cures Act defines interoperability as “health information technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user; allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law; and does not constitute information blocking as also defined by the Cures Act.” [94] We propose to codify this interoperability definition in § 170.102. We further note that we propose in section VIII of this proposed rule to codify the definition of information blocking included in the Cures Act in § 171.103.

The Program issues, and will continue to issue under our real world testing approach, certifications to health IT through a process whereby health IT is assessed against the testing requirements established by ONC. Often, this means health IT is tested by an ONC-ATL in a laboratory environment through methods that include a testing proctor's visual inspection of functions, review of developer-provided documentation of functions, and testing tools with simulation test data. An ONC-ACB evaluates the results of testing and makes a determination, based on these test results and an assessment of compliance with other Program requirements, to issue the health IT a certificate. Over the course of the Program's existence, ONC has emphasized the continued conformance of certified health IT products post-certification in real world and clinical settings. For example, ONC expanded the responsibilities of ONC-ACBs in the 2015 Edition final rule to require that they perform in-the-field surveillance. We did this to affirm the Program's long-standing expectations that certified health IT continue to operate in accordance with certification requirements when implemented in the field (80 FR 62707-62719). These efforts are also in line with the Cures Act's real world testing Condition of Certification through their focus on system interoperability and exchange of information as deployed and used in care environments—that is to say, in the “real world.”

The objective of real world testing is to verify the extent to which certified health IT deployed in operational production settings is demonstrating continued compliance to certification criteria and functioning with the intended use cases as part of the overall maintenance of a health IT's certification. Real world testing should ensure certified health IT has the ability to share electronic health information with other systems. Real world testing should assess that the certified health IT is meeting the intended use case(s) of the certification criteria to which it is certified within the workflow, health IT architecture, and care/practice setting in which the health IT is implemented. Accordingly, we propose that successful real world testing means for the purpose of this Condition of Certification that:

  • The certified health IT continues to be compliant to the certification criteria to which it is certified, including the required technical standards and vocabulary codes sets;
  • The certified health IT is exchanging electronic health information in the care and practice settings for which it is intended for use; and
  • Electronic health information is received by and used in the certified health IT.

We propose to limit the applicability of this Condition of Certification to health IT developers with Health IT Modules certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange, which are:

  • The care coordination criteria in § 170.315(b);
  • The clinical quality measures (CQMs) criteria in § 170.315(c)(1) through (c)(3);
  • The “view, download, and transmit to 3rd party” criterion in § 170.315(e)(1);
  • The public health criteria in § 170.315(f);
  • The application programming interface criteria in § 170.315(g)(7) through (g)(11); and
  • The transport methods and other protocols criteria in § 170.315(h).

The 2015 Edition certification criteria that are not included in the proposed list include many functionality-based criteria, administrative criteria, and, overall, criteria that do not focus on interoperability and exchange of data. In particular, we do not propose to include the 2015 Edition paragraph (a) “clinical” certification criteria in this list because they do not focus on interoperability and exchange of data. However, the data in the paragraph (a) criteria largely will be covered through the USCDI as a minimum data set expected for exchange; the USCDI is included in such criteria as “transitions Start Printed Page 7496of care” (§ 170.315(b)(1)), “view, download, and transmit to 3rd party” (§ 170.315(e)(1)), and the API criteria (i.e., § 170.315(g)(9) and (10)).

We solicit comment on whether to include the “patient health information capture” certification criteria in § 170.315(e)(3), including the value of real world testing these functionalities compared to the benefit for interoperability and exchange. We also solicit comment on whether any other 2015 Edition certification criteria should be included or removed from the applicability list for this Condition of Certification.

To fully implement the real world testing Condition of Certification as described above, we propose Maintenance of Certification requirements that would require health IT developers to submit publicly available prospective annual real world testing plans and retrospective annual real world testing results for its certified health IT that include certification criteria focused on interoperability. As we considered the various approaches to implement this Cures Act requirement on health IT developers, we determined that health IT developers would be best positioned to construct how their certified health IT could be tested in the real world. Moreover, by requiring health IT developers to be responsible for facilitating their certified health IT testing in production settings and being held accountable to publicly publish their results, we would balance the respective burden of this statutory requirement with its intended assurances for health care providers. Additionally, ONC is not adequately resourced to centrally administer a real world testing regime among each health IT developer and its customers, nor do we have the specific relationships with health care providers that health IT developers do. Lastly, even if ONC were positioned to support and scale a real world testing regime, we would run the risk of having one-size-fits-all tools that would not necessarily get to the level of detail and granularity necessary and reflective of different health care settings and different scopes of practice that use certified health IT.

Given these considerations, we propose that a health IT developer must submit an annual real world testing plan to its ONC-ACB via a publicly accessible hyperlink no later than December 15, of each calendar year for each of its certified 2015 Edition Health IT Modules that include certification criteria specified for this Condition of Certification. Prior to submission to the ONC-ACB, the plan would need to be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative's contact information. The plan would need to include all health IT certified to the 2015 Edition through August 31 of the preceding year. The plan would also need to address the health IT developer's real world testing for the upcoming calendar year and include, for each of the certification criteria in scope:

  • The testing method(s)/methodology(ies) that will be used to demonstrate real world interoperability, including a mandatory focus on scenario- and use case-focused testing;
  • The care and practice setting(s) that will be tested for real world interoperability, including conformance to certification criteria requirements, and an explanation for the health IT developer's choice of care setting(s) to test; [95]
  • The timeline and plans for voluntary updates to standards and implementation specifications that ONC has approved (further discussed below);
  • A schedule of key real world testing milestones;
  • A description of the expected outcomes of real world testing;
  • At least one measurement/metric associated with the real world testing; and
  • A justification for the health IT developer's real world testing approach.

The intended testing methods/methodologies would need to address testing scenarios, use cases, and workflows associated with interoperability. Testing may occur in the operational setting using real patient data, in an environment that mirrors the clinical setting using synthetic or real patient data, or in the clinical setting with synthetic data intermixed. Note that when Health IT developers who are HIPAA business associates are conducting testing using ePHI, such testing must be conducted consistent with their business associate agreements and other compliance responsibilities. The health IT developer may also partner with other health IT developers to perform real world testing. We would expect developers to consider such factors as the size of the organization that production systems support, the type of organization and setting, the number of patient records and users, system components and integrations, and the volume and types of data exchange in planning for real world testing. We would also expect developers to explain how they will incorporate voluntary standards updates in their real world testing as discussed further below. While we are not proposing a minimum proportion of the customer base that must be covered in real world testing, we highly encourage developers to find ways to ensure, to the extent practical, proportionate coverage of their customer base that balances the goals of real world testing with burden to providers. Health IT developers would not be required to test the certified health IT in each and every setting in which it is intended for use as this would likely not be feasible due to the associated burden; however, developers must address their choice of care and/or practice settings to test and ONC encourages developers test in as many settings as feasible. Additionally, health IT developers would be required to provide a justification for their chosen approach. Because our approach provides great flexibility for health IT developers with respect to demonstrating compliance, we believe it is imperative that they provide a justification to explain their methodology. Through the transparent reporting of their real world testing plans, the public will have an opportunity to consider a health IT developer's chosen approach(es) and whether it is sufficiently comprehensive to provide assurance that the certified health IT has satisfactorily demonstrated its satisfaction of Program requirements including interoperability in real world settings relevant to their needs.

Health IT developers should consider existing testing tools and approaches that may be used to assess real world interoperability. For example, we encourage health IT developers to consider metrics of use and exchange from existing networks, communities, and tools including, but not limited to, Surescripts, Carequality, CommonWell Health Alliance, the C-CDA One-Click Scorecard, and DirectTrust. We do not believe that testing through the ONC-approved test procedures is sufficient to demonstrate real world use as the test procedures developed for initial laboratory testing and certification are generally setting agnostic, focused on standards conformance, and do not always test the full scope of the certification criteria's intended functionality. We also clarify that the Start Printed Page 7497ONC-approved test procedures are not intended for use in in-the-field surveillance or for real world testing. Further, we do not believe connect-a-thons are a valid approach to testing real world use of health IT because they do not necessarily assess interoperability and functionality in live settings, but rather test developer/vendor connectivity in a closed test environment. Health IT developers may consider working with an ONC-ACB to have the ONC-ACB oversee the execution of the health IT developer's real world testing plans, which could include in-the-field surveillance per § 170.556, as an acceptable approach to meet the requirements of the real world testing Condition of Certification.

We propose that health IT developers with multiple certified health IT products that may include the same interoperability-focused certification criteria intended to be implemented in the same settings have the discretion to design their real world testing plans in a way that efficiently tests a combination of products. Likewise, health IT developers may find portions of their real world testing plans are transferrable to their other certified products; thus a health IT developer could choose to submit a real world testing plan that covers multiple certified products as appropriate and as long as there is traceability to the specific certified Health IT Modules. To be clear, developers of health IT products deployed through the cloud who offer their products for multiple types of settings would be required to test the same capability for those different settings. However, we solicit comment on whether we should offer an exemption for services that truly support all of a developer's customers through a single interface/engine and whether this would be sufficient to meet the intent of the real world testing Condition of Certification. Additionally, while the developers' plans must address each of the interoperability-focused certification criteria in their certified health IT, developers can and should design scenario-based test cases that incorporate multiple functionalities as appropriate for the real world workflow and setting.

We propose that a health IT developer would submit annual real world testing results to their ONC-ACBs via a publicly accessible hyperlink no later than January 31, of each calendar year for the preceding calendar year's real world testing. Real world testing results for each interoperability-focused certification criterion must address the elements required in the previous year's testing plan, describe the outcomes of real world testing with any challenges encountered, and provide at least one measurement or metric associated with the real world testing. As noted above, developers are encouraged to use metrics demonstrating real world use from existing networks and communities. We seek comment on whether ONC should require developers submit real world testing results for a minimum “core” set of general metrics/measurements and examples of suggested metrics/measurements. We also invite comment on the proposed annual frequency and timing of required real world testing results reporting.

We acknowledge that a subsequent final rule for this proposed rule may not provide sufficient time for health IT developers to develop and submit plans for a full year of real world testing in 2020. If such a situation comes to fruition, we expect to provide an appropriate period of time for developers to submit their plans and potentially treat 2020 as a “pilot” year for real world testing. We would expect that such pilot testing conform to our proposed real world testing to the extent practical and feasible (e.g., same criteria but for a shorter duration and without the same consequences for non-compliance). We welcome comments on this potential approach.

We clarify, and propose, that even if a health IT developer does not have customers or has not deployed their certified Health IT Module at the time the real world testing plan is due, the health IT developer would still need to submit a plan that addresses its prospective testing for the coming year for any health IT certified prior to August 31 of the preceding calendar year. If a health IT developer does not have customers or has not deployed their certified Health IT Module when the annual real world testing results are due, we propose that the developer would need to report as such to meet the proposed Maintenance of Certification requirement. For further clarity, a developer would not need to report on any health IT certified after August 31, in the preceding year.

Standards Version Advancement Process

As new and more advanced versions [96] become available for adopted standards and implementation specifications applicable to criteria subject to the real world testing Condition and Maintenance of Certification Requirements, we believe that a health IT developer's ability to conduct ongoing maintenance on its certified Health IT Module(s) to incorporate these new versions is essential to support interoperability in the real world. Updated versions of standards reflect insights gained from real-world implementation and use. They also reflect industry stakeholders' interests to improve the capacity, capability, and clarity of such standards to meet new, innovative business needs, which earlier standards versions cannot support. Therefore, as part of the real world testing Condition of Certification, we propose a Maintenance of Certification flexibility that we refer to as the Standards Version Advancement Process. The Standards Version Advancement Process would permit health IT developers to voluntarily use in their certified Health IT Modules newer versions of adopted standards so long as certain conditions are met, not limited to but notably including successful real world testing of the Health IT Module using the new version(s).

We propose to establish the Standards Version Advancement Processnot only to meet the Cures Act's goals for interoperability, but also in response to the continuous stakeholder feedback that ONC has received through prior rulemakings and engagements, which requested that ONC establish a predictable and timely approach within the Program to keep pace with the industry's standards development efforts. Rulemaking has not kept up with the pace of standards development and deployment in the health care market. There is no better evidence of this reality than by example from our 2015 Edition rulemaking finalized approximately three years ago and before the Cures Act added Conditions and Maintenance of Certification provisions to the PHSA. Two version updates of the National Health Care Survey standard (versions 1.1 and 1.2) have been issued since we adopted version 1.0 in the 2015 Edition final rule (October 16, 2015). Health IT developer and health care provider compliance and use of these versions has and will be necessary for submission to Centers for Disease Control and Prevention (CDC) even though the certification criterion adopted in § 170.315(f)(7) continues to require conformance to version 1.0. Similarly, many other adopted standards have seen multiple newer versions introduced to the market since we issued the 2015 Edition final rule, such as for eCQM reporting or e-prescribing. The proposed Standards Start Printed Page 7498Version Advancement Process flexibility gives health IT developers the option to avoid such unnecessary costs and can help reduce market confusion by enabling certified Health IT Modules keep pace with standards advancement and market needs including but not limited to those related to emerging public health concerns.

We have also been informed by stakeholders that, in other cases, ONC's inability to more nimbly identify and incorporate newer versions to standards and implementation specifications that were already adopted by the Secretary into the Program has perversely impacted standards developing organization (SDO) processes. Although SDOs can rapidly iterate version updates to standards and implementation specifications to address ambiguities and implementation challenges reported from the field and to particularly address matters that adversely impact interoperability, the lack of a clear path for that work effort to be timely realized as part of the Program's certification requirements has had a chilling effect on the pace of change. It can also affect the willingness of volunteers at these SDOs to devote their time to make updates that would be outdated by the time ONC goes through a rulemaking, which can be years. Stakeholders have indicated that certified health IT developers, customers and users of certified health IT, and the SDO industry have been technologically restricted and innovation-stunted as a result of our prior regulatory approach, which focused on certification assuring compliance only to the version of a standard adopted in regulation and did not provide an avenue for the Program to accommodate iterative updates to standards during the time between rulemakings. With the passage of the “maintenance of certification” provision in § 4002 of the Cures Act, we believe the approach proposed here is in line with our new statutory authority regarding Conditions of Certification and Maintenance of Certification and would better and more timely support market demands for widespread interoperability.

In supporting more rapid advancement of interoperability, we believe the proposed Standards Version Advancement Process approach will benefit patient care, improve competition, and spur additional engagement in standards development. To this point, currently, if the USCDI v1 were adopted as currently proposed in § 170.213 and then needed to be updated to add just one data class or data element (e.g., a new demographic element), we would need to initiate notice and comment rulemaking to incorporate that USCDI version change into the Program. Likewise, similar updates to standards included in our 2015 Edition final rule are made annually (or more frequently) by SDOs. In order to attempt to keep pace with such updates, which are published at different times of the year, ONC would need to continuously engage in rulemaking cycles, perhaps even more than once per year. We believe that the proposed Standards Version Advancement Process would allow for more advanced versions of standards and implementation specifications to be approved for use under the Program in a more timely and flexible manner that helps to ease the concerns stakeholders have reported. Stakeholder input throughout the Program's existence has informed ONC that updating large groupings of standards' versions while also adopting new standards through rulemakings that only occur about once every three years can create an artificial market impact in a number of ways. Such “all-in-one” updates affect all health IT developers and the vast majority of health care providers at the same time across all sectors rather than enabling a more incremental and market-based upgrade cycle in response to interoperability, business, and clinical needs.

The Standards Version Advancement Process and corresponding proposed revisions to §§ 170.550 and 170.555 would introduce two types of administrative flexibility for health IT developers participating in the Program. First, for those health IT developers with an existing certified Health IT Module, the Health IT Modules would be permitted to be upgraded (in the course of ongoing maintenance) to a new version of an adopted standard within the scope of the certification (without having to retest or recertify) so long as such version was approved by the National Coordinator for use in certification through the Standards Version Advancement Process. Second, for those health IT developers seeking to have a Health IT Module's initial certificate issued, the Health IT Module would be permitted to be presented for certification to a new version of an adopted standard so long as such version was approved by the National Coordinator through the Standards Version Advancement Process. This policy flexibility is similar to the flexibility we introduced several years ago for “minimum standards” code sets, but we would require ONC-ACBs to offer certification under the Standards Version Advancement Process to National-Coordinator-approved newer versions of all standards to which Real World Testing requirements apply.[97]

In order to ensure equitable treatment under the Program and in order for ONC to maintain the Program's overall integrity, each developer that chooses to leverage the proposed Standards Version Advancement Process Maintenance of Certification Program flexibilities would need to satisfy the following.

Health IT Developers Updating Already Certified Health IT

In instances where a health IT developer has certified a Health IT Module, including but not limited to instances where its customers are already using the certified Health IT Module, if the developer intends to update pursuant to the Standards Version Advancement Process election, the developer would be required to provide advance notice to all affected customers and its ONC-ACB: (a) Expressing its intent to update the software to the more advanced version of the standard approved by the National Coordinator through the Standards Version Advancement Process; (b) the developer's expectations for how the update will affect interoperability of the affected Health IT Module as it is used in the real world; and (c) whether the developer intends to continue to support the certificate for the existing Health IT Module version for some period of time and how long, or if the existing version of the Health IT Module certified to prior version(s) of applicable standards will be deprecated (e.g., that the developer will stop supporting the earlier version of the module and request to have the certificate withdrawn). The notice would be required to be provided sufficiently in advance of the developer establishing its planned timeframe for implementation of the upgrade to the more advanced standard(s) version(s) in order to offer customers reasonable opportunity to ask questions and plan for the update. We request public comment on the minimum time prior to an anticipated implementation of an updated standard or implementation Start Printed Page 7499specification version update that should be considered reasonable for purposes of allowing customers, especially health care providers using the Health IT Module in their health care delivery operations, to adequately plan for potential implications of the update for their operations and their exchange relationships. We would also be interested to know if commenters believe that there are specific certification criteria, standards, characteristics of the certified Health IT Module or its implementation (such as locally hosted by the customer using it versus software-as-a-service type of implementation), or specific types or characteristics of customers that could affect the minimum advance notice that should be considered reasonable across variations in these factors.

We anticipate providing ONC-ACBs (and/or health IT developers) with a means to attribute this updated information to the listings on the CHPL for the Health IT Modules the ONC-ACB has certified, and propose to require in the Principles of Proper Conduct for ONC-ACBs that they are ultimately responsible for this information being made publicly available on the CHPL. We request public comment on any additional information about updated standards versions that may be beneficial to have listed with certified Health IT Modules on the CHPL.

We clarify that a health IT developer would be able to choose which of the updated standards versions approved by the National Coordinator for use in certification through the Standards Version Advancement Process the developer seeks to include in its updated certified Health IT Module and would be able to do so on an itemized basis. In other words, if the National Coordinator were to approve for use through the Standards Version Advancement Process several different new versions of adopted standards that affected different certification criteria within the scope of a certified Health IT Module, the developer would be able to just update one certification criterion to one or more of the applicable new standards and would not have to update its Health IT Module to all of the National Coordinator-approved new versions all at once in order to be able to take advantage of this proposed flexibility.

Health IT Developers Presenting a New Health IT Module for Certification and Leveraging the Standards Version Advancement Process

In instances where a health IT developer presents a Health IT Module for certification for which no prior certificate can serve as the basis for using the Standards Version Advancement Process, we propose that the health IT developer would be permitted to use and implement any and all of the newer versions of adopted standards the National Coordinator approves through the Standards Version Advancement Process. We have implemented this proposed policy through necessary adjustments to the way in which ONC-ACBs process certifications in § 170.550. We recognize that this proposed flexibility reflects certain programmatic and policy trade-offs. On one hand, a health IT developer would be permitted to use the most recent version of standards approved by the National Coordinator instead of having to build in potentially “outdated” standards just to get certified. On the other hand, the Program's testing infrastructure (which is now inclusive of government-developed and non-government-developed tools) may experience certain lag times in terms of when updated test tools to support the approved version advancements would be available to test Health IT Modules for certification purposes. As a result, we propose to provide the ability for ONC-ACBs to accept a developer self-declaration of conformity as to the use, implementation, and conformance to a newer version of a standard (including but not limited to implementation specifications) as sufficient demonstration of conformance in circumstances where the National Coordinator has approved a version update of a standard for use in certification through the Standards Version Advancement Process but an associated testing tool is not yet updated to test to the newer version. Again, we clarify that a health IT developer would be able to choose which National Coordinator-approved standard version(s) it seeks to include in a new or updated certified Health IT Module and would be able to do so on an itemized basis.

On balance, we believe that this programmatic flexibility and the potential interoperability improvements from the use of newer versions of standards outweighs the subsequent oversight challenges. Moreover, these oversight challenges can be mitigated by the Standards Version Advancement Process itself (i.e., the National Coordinator not approving a new version if the Program or industry is not ready) and the corresponding Conditions of Certification that continue with the use of National Coordinator-approved new versions of adopted standards. We also believe that this approach will continue to hold developers accountable for, and shift the focus of Health IT Module performance demonstration to, real world testing for interoperability for deployed Health IT Modules. As described above, we understand the limitations of test methods used prior to certification and further emphasize the importance of continued conformance of Health IT Modules in the field. However, we request comment on specific Program impacts we should consider.

General Requirements Associated With Health IT Modules Certified Using the Standards Version Advancement Process

In all cases, regardless of whether a health IT developer is updating an existing certified Health IT Module or presenting a new Health IT Module for certification to new versions of adopted standards approved by the National Coordinator through the Standards Version Advancement Process, it would need to adhere to the following once it elects to takes advantage of this proposed flexibility:

  • The developer would need to ensure its mandatory disclosures in § 170.523(k)(1) appropriately reflect its use of any National Coordinator-approved newer versions of standards.
  • The developer would need to address and adhere to all Conditions of Certification and Maintenance of Certification requirements proposed that are otherwise be applicable to its certified Health IT Modules regardless of whether those Health IT Modules were certified to the exact same versions of adopted standards that are listed in the text of 45 CFR part 170 or National Coordinator-approved newer version(s) of the standard(s). For instance, the developer would need to ensure that its real world testing plan and performance included the National Coordinator-approved standards versions to which it is claiming conformance.

In terms of compliance with the real world testing Condition and Maintenance of Certification requirements, the attestations Condition and Maintenance of Certification requirements proposed in § 170.406, and for the purposes of ONC-ACB surveillance, we note that health IT developers would be accountable for maintaining all applicable certified Health IT Modules in accordance with approved versions of standards and implementation specifications that they voluntarily elect to use in their certified health IT. If, at any point after initial certification or updated certification for Start Printed Page 7500a Health IT Module using the National Coordinator approved advanced versions of standards or implementation specifications, real world testing results do not demonstrate the Health IT Module's conformance to each applicable certification criterion had been achieved and maintained using the National Coordinator approved advanced version update of any applicable standard(s) and implementation specification(s), then the developer would not be allowed to claim or characterize the Health IT Module as conformant to the criterion using such standard version, and the standard or implementation specification version could not be indicated in the health IT Module's CHPL record as supported by any version release of the Health IT Module, until such time as they could demonstrate through ONC-ATL or results of real world testing that they had successfully upgraded the Health IT Module to fully conform to applicable certification criteria while incorporating the more advanced version of the standard. Non-conformities associated with the use of new versions of National Coordinator-approved standards would be found and enforced through the same Program rules just like they would be for non-conformities with the versions of adopted standards that are codified in regulation text. Further, we remind health IT developers that they would be required to make an attestation to their real world testing results, including (though not limited to) those that would be used to support use of new versions of National Coordinator-approved standards.

Advanced Version Approval Approach

Once a standard has been adopted for use in the Program through notice and comment rulemaking, ONC would undertake an annual, open and transparent process, including opportunity for public comment, to timely ascertain whether a more recent version of that standard or implementation specification should be approved for developers' voluntary use. ONC would identify updated versions of previously adopted standards and implementation specifications based on our own monitoring of market trends and interoperability needs, as well as input received from external stakeholders. Such external input may include, but would not be limited to, recommendations made by the Health Information Technology Advisory Committee as well as input received from SDOs.

ONC expects to use an expanded section of the Interoperability Standards Advisory (ISA) web platform to facilitate the public transparency and engagement process. At a particular time of the year (e.g., early fall), ONC would post a list of new versions of adopted standards and implementation specifications that appear timely and appropriate for use within the Program (for the subsequent calendar year) along with accompanying descriptive context (e.g., the types/nature of updates in the new version of a standard). ONC would then widely communicate to all members of the public that the list was available and make a general solicitation of comments to any and all interested parties for a period of 30 to 60 days. We would generally expect to receive comments on a range of issues related to the version of the standard under consideration, including its availability, testing tools, maturity, implementation burden, and overall impact on interoperability. Health IT developers, health information networks (HINs), and the health care organizations that purchase and use health IT are already familiar with the process of commenting through our existing ISA resource and we believe this process is well suited to support widespread engagement by all stakeholders. Similar to the ISA, we would expect to be open to receiving comments on newer versions of adopted standards throughout the year leading up to the formal comment period.

Once the formal comment period closes, ONC would review the comments and consider the potential impacts of a new version an adopted standard or implementation specification. We anticipate approving newer versions of adopted standards and implementation specifications based on several interdependent Program and market factors, such as its ability to enhance interoperability and overall compatibility with other adopted versions, how burdensome it would be to update to the newer version and the scope and scale of the changes, whether the new version would be required for reporting by a corresponding program (e.g., CMS or CDC), the availability of test tools for the new version, and the new version's relationship to other adopted standards and any dependencies. Upon concluding our review and analysis, ONC would publish in this new ISA section a final list of National Coordinator-approved advanced versions that health IT developers could electively use consistent with the Standards Version Advancement Process.

Within this proposed approach, we expect that when it comes to a standard, the National Coordinator would identify version updates to an adopted standard consistent with that standard's name and version track. This method would provide long-term consistency for health IT developers in terms of the overall technical conformance requirements on which they will be focused.

With respect to adopted implementation specifications, we believe that more flexibility about the precise name and version track identifiers would be warranted given that implementation specifications are developed by market-driven industry consortia (e.g., Argonaut project and Direct project stakeholders) as well as traditional SDOs. Similarly, authors of implementation specifications sometimes develop supplemental documents to the “parent” implementation specification or split the implementation specification to form newly titled materials. In any of these cases, the resulting implementation specification may—on its face—initially appear to bear no relation to a previously adopted implementation specification because of changes to its title, version naming, or numbering presentation. In reality, in many of these cases, the implementation specification retains substantially the same purpose(s) and thus represents a versioning update rather than amounting to a novel specification. Accordingly, regardless of its title and author, the National Coordinator would take into account whether any “new” implementation specification under consideration is more accurately characterized as novel to the Program or instead is a derivative work that is substantially a more advanced version of a previously adopted implementation specification(s). Stakeholders would also be able to comment on the same during the advanced version approval process described here.

The public listing of these National Coordinator determinations to approve version updates to already adopted standards and implementation specifications would serve as the single, comprehensive, and authoritative index of the versions of adopted standards and implementation specifications available for use under the Program. We note, however, that certain Program administration steps would need to occur (such as ONC-ACBs expanding the scope of their accreditations) after the National Coordinator has approved newer versions of adopted standards. As a result, there would likely be a temporary delay between the National Coordinator's approval decision and when certification to new standards versions under the Program would start.

We welcome comments on any and all aspects of our proposed standards Start Printed Page 7501version approval process as an option available to developers through maintenance requirements as part of the real world testing Condition and Maintenance of Certification. This includes all aspects of our described approach to standards and implementation specification advanced version approval processes. We also invite comments on our proposal to allow in conjunction with this maintenance flexibility the opportunity for developers to elect to present health IT for initial testing and certification either to more advanced versions or the prior versions included in regulatory text as of the date the technology is presented.

Principle of Proper Conduct for ONC-ACB for All Real World Testing Proposals

We propose to include a new Principle of Proper Conduct for ONC-ACBs in § 170.523(p) that would require ONC-ACBs to review and confirm that applicable health IT developers submit real world testing plans and results in accordance with our proposals. We expect that ONC-ACBs would review the plans for completeness. Once completeness is confirmed, ONC-ACBs would provide the plans to ONC by December 15 and results to ONC by April 1. The December 15 date is the same date as the health IT developer requirement for submission of the real world testing plan. For purposes of the Program, this treats both regulated entities equally and permits them to work out a process that ensures all real world testing plans are submitted to the CHPL by December 15. For example, a health IT developer that is confident in its plan and does not anticipate any further certification, may submit its plan in July of the preceding year.

The submission of results, however, does not present the same dynamic of the potential need to work together to ensure the plan is complete. As such, we have proposed different dates. We would expect the developers to submit their results by January 31. We believe this would provide sufficient time for ONC-ACBs to review all plans and post them to the CHPL by April 1, including notifying ONC when the results were not in compliance with requirements. ONC would make both the plans and results publicly available via the CHPL. We note that ONC-ACBs will continue to be required to perform in-the-field surveillance of certified Health IT Modules and results of real world testing could be considered information to inform ONC-ACB surveillance activities.

Because we are proposing to allow health IT developers to implement National Coordinator-approved advanced versions of standards and implementation specifications in certified Health IT Modules through a developer self-declaration of conformity presented for certification if an associated testing tool is not yet updated to test to the newer version for the standards and implementation specification version updates they have chosen to use in the Program, we propose two requirements to ensure the public and ONC-ACBs have knowledge of the version of a standard that certified health IT meets. First, we propose to revise the Principle of Proper Conduct in § 170.523(m) to require ONC-ACBs to collect, no less than quarterly, all version updates made to standards successfully included in certified health IT per the requirements within the real world testing Condition of Certification Standards Version Advancement Process. This would ensure that ONC-ACBs are aware of the version of a standard that certified health IT meets for the purposes of surveillance and Program administration. Second, we propose (as discussed above), that a developer that chooses to avail itself of the Standards Version Advancement Process flexibility must address in its real world testing plans and results submissions the timeline and rollout of applicable version updates for standards and implementation specifications. This addition to § 170.523(m) along with existing requirements for weekly ONC-ACB CHPL reporting to versions of standards per § 170.523(f)(1)(xvii) would allow for timely updates to Health IT Module certificate information in the CHPL. Together with the requirements (discussed above) for developers' communication with their current and potential customers, we intend to ensure that the public and end-users have transparency into planned and actual standards and implementation specifications updates for their certified health IT.

In complement to the above requirements to ensure transparency for the public and end users, we propose in § 170.523(t) a new Principle of Proper Conduct for ONC-ACBs requiring them to ensure that developers seeking to take advantage of the Standards Version Advancement Process flexibility in § 170.405(b)(5) comply with the applicable requirements, and that the ONC-ACB both retain records of the timing and content of developers' § 170.405(b)(5) notices and timely post each notice's content publicly on the CHPL attributed to the certified Health IT Modules to which it applies.

We seek comment on the proposed additions to the Principles of Proper Conduct for ONC-ACBs. More specifically, we seek comment on whether ONC-ACBs should be required to perform an evaluation beyond a completeness check for the real world testing plans and results and the value versus the burden of such an endeavor.

6. Attestations

The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification under the Program, provide to the Secretary an attestation to all the Conditions of Certification specified in the Cures Act, except for the “EHR reporting criteria submission” Condition of Certification. We propose to implement the Cures Act “attestations” requirements Condition of Certification in § 170.406. We also propose that, as part of the implementation of this statutory provision, health IT developers would attest, as applicable, to compliance with the Conditions and Maintenance of Certification requirements described in this section of the preamble and proposed in §§ 170.401 through 170.405.

We propose that, as a Maintenance of Certification requirement for the “attestations” Condition of Certification, health IT developers must submit their attestations every 6 months (i.e., semiannually). We believe this would provide an appropriate “attestation period” to base any enforcement actions, such as by ONC under the Program or by the Office of the Inspector General under its Cures Act authority. We also believe this 6-month attestation period properly balances the need to support appropriate enforcement actions with the attestation burden placed on developers. We will determine when the first attestation will be due depending on when the final rule is published. We require attestations to be due twice a year, likely in the middle and end of the calendar year.

The process we plan to implement for providing attestations should minimize burden on health IT developers. First, we propose to provide a 14-day attestation period twice a year. For health IT developers presenting health IT for certification for the first time under the Program, we propose that they would be required to submit an attestation at the time of certification and then also comply with the semiannual attestation periods. Second, we would publicize and prompt developers to complete their attestation Start Printed Page 7502during the required attestation periods. Third, we propose to provide a method for health IT developers to indicate their compliance, non-compliance with, or the inapplicability of each Condition and Maintenance of Certification requirement as it applies to all of their health IT certified under the Program for each attestation period. Last, we propose to provide health IT developers the flexibility to specify non-compliance per certified Health IT Module, if necessary. We note, however, that any non-compliance with the proposed Conditions and Maintenance of Certification requirements, including the “attestations” Conditions and Maintenance of Certification requirements, would be subject to ONC direct review, corrective action, and enforcement procedures under the Program. We refer readers to section VII.D of this preamble for discussion of proposed ONC direct review, corrective action, and enforcement procedures for the Conditions and Maintenance of Certification requirements under the Program.

We propose that attestations would be submitted to ONC-ACBs on behalf of ONC and the Secretary. We propose that ONC-ACBs would have two responsibilities related to attestations. One responsibility we propose in § 170.523(q) is that an ONC-ACB must review and submit the health IT developers' attestations to ONC. ONC would then make the attestations publicly available through the CHPL. The other responsibility we propose in § 170.550(l) is that before issuing a certification, an ONC-ACB would need to ensure that the health IT developer of the Health IT Module has met its responsibilities related to the Conditions and Maintenance of Certification requirements as solely evidenced by its attestation. For example, if a health IT developer with an active certification under the Program indicated non-compliant designations in their attestation but is already participating in a corrective action plan under ONC direct review to resolve the non-compliance, certification would be able to proceed while the issue is being resolved.

We welcome comments on the proposed attestations Condition and Maintenance of Certification requirements, including the appropriate frequency and timing of attestations. We also welcome comments on the proposed responsibilities for ONC-ACBs related to the attestations of Condition and Maintenance of Certification requirements.

7. EHR Reporting Criteria Submission

The Cures Act specifies that health IT developers be required, as a Condition and Maintenance of Certification under the Program, to submit reporting criteria on certified health IT in accordance with the EHR reporting program established under section 3009A of the PHSA, as added by the Cures Act. We have not yet established an EHR reporting program. Once ONC establishes such program, we will undertake future rulemaking to propose and implement the associated Condition and Maintenance of Certification requirement(s) for health IT developers.

C. Compliance

The proposed Maintenance of Certification requirements discussed above do not necessarily define all the outcomes necessary to meet the Conditions of Certification. Rather, they provide preliminary or baseline evidence toward measuring whether a Condition is being met. Thus, ONC could determine that a Condition of Certification is not being met through reasons other than the Maintenance of Certification requirements. For example, meeting the proposed Maintenance of Certification requirement that requires a health IT developer to not establish or enforce any contract or agreement that contravenes the Communications Condition of Certification does not excuse a health IT developer from meeting all the requirements specified in the proposed Communications Condition of Certification. This is analogous to clarifications ONC has previously provided about certification criteria requirements whereby testing prior to certification sometimes only tests a subset of the full criterion's intended functions and scope. However, for compliance and surveillance purposes, we have stated that ONC and its ONC-ACBs will examine whether the certified health IT meets the full scope of the certification criterion rather than the subset of functions it was tested against (80 FR 62709-10).

D. Enforcement

The Cures Act affirms ONC's role in using certification to improve health IT's capabilities for the access, use, and exchange of electronic health information. The Cures Act provides this affirmation through expanded certification authority for ONC to establish Conditions and Maintenance of Certification requirements for health IT developers that go beyond the certified health IT itself. The new Conditions and Maintenance of Certification provisions in section 4002 of the Cures Act focus on the actions and business practices of health IT developers (e.g., information blocking and appropriate access, use, and exchange of electronic health information) as well as technical interoperability of health IT (e.g., APIs and real world testing). Furthermore and equally important, section 4002 of the Cures Act provides that the Secretary of HHS may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. As discussed in the 2015 Edition final rule, ONC is not limited to enforcing Program compliance solely through those requirements expressed in certification criteria adopted under the Program (80 FR 62710; see also 81 FR 72412). Certification under the Program also relies on a health IT developer's compliance with Program requirements that ensure the basic integrity and effectiveness of the Program, which is further stressed through the addition of the Conditions and Maintenance of Certification requirements in the Cures Act (referred to jointly as the “Conditions and Maintenance of Certification” in this section of the preamble).

Given these considerations, we propose a general enforcement approach outlining a corrective action process for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement has not been or is not being met by a health IT developer under the Program, including the requirement for a health IT developer to attest to meeting the Conditions and Maintenance of Certification. Table 2 below provides an overview of the proposed approach to ONC enforcement of the Conditions and Maintenance of Certification. We provide more specific proposals following Table 2.Start Printed Page 7503

Table 2—Proposed Approach for Enforcement of the Conditions and Maintenance of Certification

Proposed regulatory textCondition of certificationOpportunity for developer to take corrective actionConsequences of not taking appropriate corrective actionOpportunity for developer to appeal ONC determination to terminate or ban
§ 170.401 § 170.402Information Blocking Assurances.YesCertification ban of all of a developer's certified Health IT ModulesYes.
§ 170.403 § 170.404 § 170.405 § 170.406Communications. APIs. Real World Testing. Attestations.ONC may also consider termination of Health IT Module certificates if there is a nexus between the developer's practices and a certified Health IT Module

1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements

We propose to utilize the processes previously established for ONC direct review of certified health IT in the EOA final rule (81 FR 72404) and codified in §§ 170.580 and 170.581 for the enforcement of the Conditions and Maintenance of Certification. We propose this approach for multiple reasons. First, these processes were established to address non-conformities with Program requirements. Conditions and Maintenance of Certification are proposed to be adopted as Program requirements and, as such, any noncompliance with the Conditions and Maintenance of Certification would constitute a Program non-conformity. Second, health IT developers are familiar with the ONC direct review provisions as they were established in October 2016. Third, §§ 170.580 and 170.581 provide thorough and transparent processes for working with health IT developers through notice and corrective action to remedy Program non-conformities. Last, the direct review framework provides equitable opportunities for health IT developers to respond to ONC actions and appeal certain ONC determinations.

2. Review and Enforcement Only by ONC

We propose to retain use of the term “direct review” as previously adopted in the EOA final rule to continue to distinguish actions ONC takes to directly review certified health IT or health IT developers' actions in comparison to an ONC-ACB's review of certified health IT under surveillance. We propose, however, that ONC would be the sole party responsible for enforcing compliance with the Conditions and Maintenance of Certification. The Conditions and Maintenance of Certification focus on health IT developer behavior and actions in addition to the certified Health IT Module. ONC is more familiar with the behavioral requirements based on its expertise and experience. Conversely, ONC-ACBs are generally more suited, based on their accreditation and current responsibilities, to address non-conformities with technical and other Program requirements. ONC also has the necessary resources and the ability to coordinate with other agencies to enforce the Conditions and Maintenance of Certification, such as with the “information blocking” Condition of Certification (proposed § 170.401). Further, ONC enforcement would provide more predictability and consistency, which would likely benefit stakeholders in matters related to API fees and information blocking. We do, however, discuss below the scope of ONC-ACB surveillance as it relates to ONC's proposed enforcement of the Conditions and Maintenance of Certification.

3. Review Processes

We propose to substantially adopt the processes as they are currently codified in §§ 170.580 and 170.581 for ONC's review and enforcement of the Conditions and Maintenance of Certification, but propose certain revisions and additions to the processes to properly incorporate the proposed Conditions and Maintenance of Certification and effectuate Congressional intent. These revisions and additions include renaming and restructuring headings for clarity, which we do not discuss below.

a. Initiating Review and Health IT Developer Notice

We propose to fully incorporate the review of the Conditions and Maintenance of Certification into the provisions of § 170.580(a) and (b). We propose in § 170.580(a)(iii) that if ONC has a reasonable belief that a health IT developer has not complied with a Condition of Certification, then it may initiate direct review. Similarly, we propose in § 170.580(b)(1) and (2) that ONC may issue the health IT developer a notice of potential non-conformity or notice of non-conformity and provide the health IT developer an opportunity to respond with an explanation and written documentation, including any information ONC requests. These processes, including relevant timeframes, are specified in § 170.580(b).

i. Complaint Resolution

We note and recommend that customers and end-users first work with their health IT developers to resolve any issues of potential non-compliance with the Conditions and Maintenance of Certification as prior Program experience has shown that many issues can be resolved at this step. If the issue cannot be resolved, we then recommend the end-user contact the ONC-ACB. However, as discussed above and in section VII.D.5 below, the ONC-ACB purview for certified health IT generally applies to certified capabilities and limited requirements of developer business practices. If neither of these pathways resolves the issue, end-users may provide feedback to ONC via the Health IT Feedback Form.[98]

ii. Method of Correspondence With Health IT Developers

Section 170.505 states that correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. In the EOA final rule, we signaled our intent to send notices of potential non-conformity, non-conformity, suspension, proposed termination, and termination via certified mail (81 FR 72429). However, in accordance with § 170.505, we propose that email should be the default mode of correspondence for direct review of non-compliance with the Conditions and Maintenance of Certification.Start Printed Page 7504

Under the EOA final rule, ONC can initiate direct review of certified health IT in limited circumstances, namely when there is a reasonable belief that the certified health IT may be causing or contributing to serious risks to public health or safety or suspected non-conformities present practical challenges that may prevent an ONC-ACB from effectively investigating or responding to the suspected non-conformity. In contrast, we propose in this proposed rule to enable ONC to initiate direct review to address a health IT developer's conduct under the Conditions and Maintenance of Certification requirements in addition to non-conformities in certified health IT. This proposal would create an expanded set of circumstances for ONC to conduct direct review. Accordingly, the type and extent of review by ONC could vary significantly based on the complexity and severity of each fact pattern. For instance, ONC may be able to address certain non-conformities under the Conditions and Maintenance of Certification quickly and with minimal effort (e.g., failure to make public a documentation hyperlink), while others may be more complex and require additional time and effort (e.g., violation of API fee prohibitions). Considering this wide range of potential non-conformities under the Conditions and Maintenance of Certification, we believe it is appropriate for ONC to retain discretion to decide, on a case-by-case basis, when to go beyond the provisions of § 170.505 in providing notices and correspondence for non-compliance with the Conditions and Maintenance of Certification.

We solicit comment on the nature and types of non-conformities with the Conditions and Maintenance of Certification requirements that ONC should consider in determining the method of correspondence. We also solicit comment on whether the type of notice should affect the method of correspondence and whether certain types of notices under direct review should be considered more critical than others, thus requiring a specific method of correspondence.

b. Relationship With ONC-ACBs and ONC-ATLs

Section 170.580(a)(3) outlines ONC direct review in relation to the roles of ONC-ACBs and ONC-ATLs, which we propose to revise to incorporate Conditions and Maintenance of Certification. We note that we provide situational examples below in section VII.D.5 “Effect on Existing Program Requirements and Processes” regarding ONC direct review and the role of an ONC-ACB. As finalized in the EOA final rule and per § 170.580(a)(3)(v), we remind readers that ONC may refer the applicable part of its review of certified health IT to the relevant ONC-ACB(s) if ONC determines this would serve the effective administration or oversight of the Program (81 FR 72427-72428).

c. Records Access

We propose to revise § 170.580(b)(3) to ensure that ONC, or third parties acting on its behalf, has access to the information necessary to enforce the Conditions and Maintenance of Certification. As specified in § 170.580(b)(1)(ii)(A)(2), (b)(2)(ii)(A)(2) and (b)(3), in response to a notice of potential non-conformity or notice of non-conformity, ONC must be granted access to, and have the ability to share within HHS, with other federal agencies, and with appropriate entities, all of a health IT developers' records and technology related to the development, testing, certification, implementation, maintenance, and use of a health IT developers' certified health IT; and any complaint records related to the certified health IT. “Complaint records” include, but are not limited to issue logs and help desk tickets (81 FR 72431). We propose to supplement these requirements with a requirement that a health IT developer make available to ONC, and third parties acting on its behalf, records related to marketing and distribution, communications, contracts, and any other information relevant to compliance with any of the Conditions and Maintenance of Certification or other Program requirements. This information would assist in reviewing allegations that a health IT developer violated, for example, the “prohibit and restrict communications” Condition of Certification. Further, it is possible that multiple Conditions and Maintenance of Certification may be implicated under a review, and thus ONC believes it is appropriate to require a developer make available to ONC all records and other relevant information concerning all the Conditions and Maintenance of Certification and Program requirements to which it and its Health IT Modules are subject.

If ONC determined that a health IT developer was not cooperative with the fact-finding process, we propose ONC would have the ability to issue a certification ban and/or terminate a certificate (see proposed § 170.581 discussed below and § 170.580(f)(1)(iii)(A)(1)).

We understand that health IT developers may have concerns regarding the disclosure of proprietary, trade secret, competitively sensitive, or other confidential information. As we stated in the EOA final rule (81 FR 72429), ONC would implement appropriate safeguards to ensure, to the extent permissible with federal law, that any proprietary business information or trade secrets ONC may encounter by accessing the health IT developer's records, other information, or technology, would be kept confidential by ONC or any third parties working on behalf of ONC. However, a health IT developer would not be able to avoid providing ONC access to relevant records by asserting that such access would require it to disclose trade secrets or other proprietary or confidential information. Therefore, health IT developers must clearly mark, as described in HHS Freedom of Information Act regulations at 45 CFR 5.65(c), any information they regard as trade secret or confidential commercial or financial information which they seek to keep confidential prior to disclosing the information to ONC or any third party working on behalf of ONC.

d. Corrective Action

We propose that if ONC determines that a health IT developer is noncompliant with a Condition of Certification (i.e., a non-conformity), ONC would work with the health IT developer to establish a corrective action plan (CAP) to remedy the issue through the processes specified in § 170.580(b)(2)(ii)(A)(4) and (c). We note that a health IT developer may be in noncompliance with more than one Condition of Certification. In such cases, ONC will follow the proposed compliance enforcement process for each Condition of Certification accordingly, but may also require the health IT developer to address all violations in one CAP for efficiency of process. We also propose, as we currently do with CAPs for certified health IT, to list health IT developers under a CAP on ONC's website.

e. Certification Ban and Termination

We propose in § 170.581 that if a health IT developer under ONC direct review for non-compliance with a Condition of Certification failed to work with ONC or was otherwise noncompliant with the requirements of the CAP and/or CAP process, ONC could issue a certification ban for the health IT developer (and its subsidiaries and successors). A certification ban, as it currently does for other matters under § 170.581, would prohibit prospective certification activity by the health IT developer.Start Printed Page 7505

ONC would also consider termination [99] of the certificate(s) of the affected Health IT Module(s) should the health IT developer fail to work with ONC or is otherwise noncompliant with the requirements of the CAP and/or CAP process (see proposed § 170.580(f)(1)(iii)). ONC may consider termination if there is a nexus between the developer's actions or business practices and certified Health IT Module(s) (see proposed § 170.580(f)(1)(iii)). For example, ONC may determine that a health IT developer is violating a Condition of Certification due to a clause in its contracts that prevents its users from sharing or discussing technological impediments to information exchange. In this example, the health IT developer's conduct would violate the “prohibiting or restricting communication” Condition of Certification proposed in § 170.403. If the same conduct were also found to impair the functionality of the certified Health IT Module (such as by preventing the proper use of certified capabilities for the exchange of EHI), ONC may determine that a nexus exists between the developer's business practices and the functionality of the certified Health IT Module, and may consider termination of the certificates of that particular Health IT Module under the proposed approach.

We propose this approach, which allows ONC to initiate a certification ban and/or certificate termination under certain circumstances, to ensure that health IT developers are acting in accordance with the Conditions and Maintenance of Certification. However, we stress that our first and foremost priority is to work with health IT developers to remedy any noncompliance with Conditions and Maintenance of Certification through a corrective action process before taking further action. This emphasizes ONC's desire to promote and support health IT developer compliance with the Conditions and Maintenance of Certification and ensure that certified health IT is compliant with Program requirements in order to foster an environment where EHI is exchanged in an interoperable way.

ONC does not believe that noncompliance with a Condition of Certification should always result in the termination of the certificate of one or more of a developer's Health IT Modules for a few reasons. A violation of a Condition of Certification may relate solely to health IT developer business practices or actions that do not affect the Health IT Module's conformance to the requirements of the certification criteria. In this case, termination of the certification could unfairly and negatively affect a provider's ability to use the Health IT Module for participation in CMS programs that require certification because the Health IT Module itself is functioning in accordance with the technical requirements of its certificate.[100] As such, ONC would carefully consider on a case-by-case basis the appropriateness of termination of a Health IT Module's certification(s) based on the specific circumstances of the noncompliance with the Condition of Certification. The proposed enforcement approach balances the above stated goals and provides an outlined process that can be consistently followed.

In considering whether termination of a Health IT Module's certificate(s) and/or a certification ban is appropriate, ONC will consider factors including, but not limited to: Whether the health IT developer has previously been found in noncompliance with the Conditions and Maintenance of Certification or other Program requirements; the severity and pervasiveness of the noncompliance, including the effect of the noncompliance on widespread interoperability and health information exchange; the extent to which the health IT developer cooperates with ONC to review the noncompliance; the extent of potential negative impact on providers who may seek to use the certified health IT to participate in CMS programs; and whether termination and/or a certification ban is necessary to ensure the integrity of the certification process.

As under § 170.580(f)(2), ONC would provide notice of the termination to the health IT developer, including providing reasons for, and information supporting, the termination and instructions for appealing the termination. We propose to add similar notice provisions to § 170.581 for certification bans issued under ONC direct review for non-compliance with the Conditions and Maintenance of Certification, which would also include instructions for requesting reinstatement. In this regard, we propose to apply the current reinstatement procedures under § 170.581 to Conditions and Maintenance of Certification bans, but with an additional requirement that the health IT developer has resolved the non-compliance with the Condition of Certification. In sum, a health IT developer could seek ONC's approval to re-enter the Program and have the certification ban lifted if it demonstrates it has resolved the noncompliance with the Condition of Certification and ONC is satisfied that all affected customers have been provided appropriate remediation.

For clarity, a health IT developer would have an opportunity to appeal an ONC determination to issue a certification ban and/or termination IT resulting from a non-conformity with a Condition of Certification as discussed below and/or seek reinstatement in the Program and have the certification ban lifted. To note, we propose to make terminations effective consistent with current § 170.580(f)(2)(iii) and similarly for certification bans (see proposed § 170.581(c)). We seek comment on whether ONC should:

  • Impose a minimum certification ban length before a health IT developer can request ONC remove the ban for health IT developers who are noncompliant with a Condition of Certification more than once (e.g., a minimum six months for two instances, a minimum of one year for three instances).
  • Consider additional factors for a certification ban and/or the termination of a health IT developer's certified health IT resulting from a non-conformity with a Condition of Certification.

f. Appeal

We propose to provide a health IT developer an opportunity to appeal an ONC determination to issue a certification ban and/or termination resulting from a non-conformity with a Condition of Certification and would follow the processes specified in § 170.580(g). As such, we propose to revise § 170.580(g) to include ONC direct review of the Conditions and Maintenance of Certification.

g. Suspension

Section 170.580 includes a process for suspending the certification of a Health IT Module at any time if ONC has a reasonable belief that the certified health IT may present a serious risk to public health and safety. While this will Start Printed Page 7506remain the case for certified health IT under ONC direct review (i.e., suspension of certification is always available under ONC direct review when the certified health IT presents a serious risk to public health and safety), we do not believe such circumstances would apply to noncompliance with the Conditions of Certification. Further, we believe the more streamlined processes proposed for addressing noncompliance with Conditions and Maintenance of Certification alleviates the need to proceed through a suspension process. Therefore, we do not propose to apply the suspension processes under § 170.580 to our review of the Conditions of Certification. We welcome comments on this proposal, including reasons for why we should apply suspension processes to the Conditions of Certification as part of a subsequent final rule.

h. Proposed Termination

Section 170.580 includes an intermediate step between a developer failing to take appropriate and timely corrective action and termination of a certified Health IT Module's certificate, called “proposed termination” (see § 170.580(e) and 81 FR 72437)). We propose to not include this step when a health IT developer fails to take appropriate and timely corrective action for noncompliance with a Condition of Certification. Rather, as discussed above, ONC may proceed directly to issuing a certification ban or notice of termination if it determines a certification ban and/or termination are appropriate per the considerations discussed above. The Conditions and Maintenance of Certification include requirements of developer business practices and actions for which, as previously discussed, noncompliance with the Conditions and Maintenance of Certification in these arenas are likely to undermine the integrity of the Program and impede widespread interoperability and information exchange. As such, ONC believes it is appropriate and consistent with the Cures Act to proceed immediately to a certification ban and/or termination of the affected certified Health IT Modules' certificates if a developer does not take appropriate and timely corrective action. A certification ban and/or termination are appropriate disincentives for noncompliance with the Conditions and Maintenance of Certification.

4. Public Listing of Certification Ban and Terminations

We propose to publicly list health IT developers and certified Health IT Modules on ONC's website that are subject to a certification ban and/or have been terminated, respectively, for noncompliance with a Condition of Certification or for reasons already specified in § 170.581. We currently take this same approach for health IT with terminated certifications (see 81 FR 72438). Public listing serves to discourage noncompliance with Conditions and Maintenance of Certification, other Program requirements, remediation of non-conformities, and cooperation with ONC and the ONC-ACBs. It also serves to provide notice to all ONC-ATLs, ONC-ACBs, public and private programs requiring the use of certified health IT, and consumers of certified health IT of the status of certified health IT and health IT developers operating under the Program.

We seek comment on this proposal, including input on the appropriate period of time to list health IT developers and affected certified Health IT Modules on healthit.gov. For example, if a developer sought and received reinstatement under the Program (and lifting of the certification ban), should the health IT developer no longer be listed on the ONC website? Alternatively, should we list health IT developers who have been subject to the certification ban under § 170.581 for a certain period of time beyond the active ban, including indefinitely (e.g., with the timeframe when the ban was active)?

5. Effect on Existing Program Requirements and Processes

The Cures Act introduces new Conditions and Maintenance of Certification that encompass technical and functional requirements of health IT and new actions and business practice requirements for health IT developers, which ONC proposes to adopt in subpart D of Part 170. The pre-Cures Act structure and requirements of the Program provide processes to enforce compliance with technical and functional requirements of certified health IT, and to a more limited extent, requirements for the business practices of health IT developers (see, e.g., 45 CFR 170.523(k)(1)) under subparts C (Certification Criteria for Health Information Technology) and E (ONC Health IT Certification Program) of Part 170. ONC-ACBs are required to perform surveillance on certified Health IT Modules and may investigate reported alleged non-conformities with Program requirements under subparts A, B, C, and E with the ultimate goal to work with the health IT developer to correct the non-conformity. Under certain situations, such as unsafe conditions or impediments to ONC-ACB oversight, ONC may directly review certified health IT to determine whether it conforms to the requirements of the Program (see § 170.580 and the EOA final rule at 81 FR 72404). These avenues for investigating non-conformities with certified Health IT Modules will continue to exist under the Program and generally focus on functionality and performance of certified health IT or more limited requirements of business practices of health IT developers found in subparts A, B, C and E of Part 170, respectively. Thus, there may be instances where one or more Conditions and Maintenance of Certification are not being or have not been met that also relate to certified Health IT Modules non-conformities under subparts A, B, C and E. Under these situations, ONC could in parallel implement both sets of processes—existing processes to investigate Health IT Module non-conformities and the proposed process to enforce compliance with the Conditions and Maintenance of Certification.

We again note that under the proposed enforcement approach, only ONC would have the ability to determine whether a Condition or Maintenance of Certification requirement per subpart D has been or is being met. We propose to delineate the scope of an ONC-ACB's requirements to perform surveillance on certified Health IT Modules as related only to the requirements of subparts A, B, C and E of Part 170. Table 3 below further illustrates the proposed difference in scope of review activities between ONC-ACBs and ONC. Given our proposed approach that would authorize solely ONC to determine whether a Condition or Maintenance of Certification requirement per subpart D has been or is being met, we propose to add a new Principle of Proper Conduct for ONC-ACBs in § 170.523(s) that would require ONC-ACBs to report to ONC, no later than a week after becoming aware, any information that could inform whether ONC should exercise direct review for noncompliance with a Condition of Certification or any matter within the scope of ONC direct review. We believe this is appropriate because ONC-ACBs receive complaints and other information about certified Health IT Modules through their own channels; as this information may relate to potential noncompliance with the Conditions and Maintenance of Certification or other matters within the scope of ONC direct review, ONC should be made aware of this information.Start Printed Page 7507

Table 3—Scope of ONC-ACB Surveillance and ONC Direct Review for Proposed Enforcement Approach for Conditions and Maintenance of Certification

Condition of certificationONC-ACB purview for surveillance per 170.556ONC purview for enforcement per 170.580 and 170.581
170.401: Information BlockingOnly as it relates to Subparts A, B, C and E of Part 170All of 170.401.
170.402: AssurancesOnly as it relates to Subparts A, B, C and E of Part 170, including the certification criterion in § 170.315(b)(10) “EHI export”All of 170.402.
170.403: CommunicationsOnly as it relates to Subparts A, B, C and E of Part 170All of 170.403.
170.404: APIsOnly as it relates to Subparts A, B, C and E of Part 170, including the certification criterion in § 170.315(g)(10)All of 170.404.
170.405: Real World TestingOnly as it relates to Subparts A, B, C and E of Part 170All of 170.405.
170.406: AttestationsOnly as it relates to Subparts A, B, C and E of Part 170All of 170.406.

For example and further illustration purposes, ONC may receive a complaint of information blocking alleging that a health IT developer has limited the ability to receive secure Direct messages from users of a competing developer's EHR. The complaint alleges the certified health IT drops the incoming message without alerting the user that a message was ever received. ONC would consider the information blocking concerns (proposed § 170.401) as well as the potential safety concerns presented by dropped messages associated with certified functionality of the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)) and standards for the secure Direct messaging in its review. For the potential safety concerns, ONC would be exercising its authority to review certified health IT that may be causing or contributing to conditions that present a serious risk to public health or safety under § 170.580(a)(2)(i). In contrast, the ONC-ACB would not be responsible for reviewing the information blocking or safety concerns directly, but it would be responsible for assessing whether surveillance needs to be performed on the certified health IT for the functionality in the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)) and the 2015 Edition “Direct Project” certification criterion (§ 170.315(h)(1)), as these requirements are found within subpart C of Part 170 and could be implicated based on the complaint.

To provide another example, an ONC-ACB could receive complaints from users that a developer's certified health IT does not support the FHIR DSTU 2 standard and associated API resource collection in health (ARCH Version 1) as required in the proposed new 2015 Edition certification criterion § 170.315(g)(10) (proposed under subparts B and C).The respective ONC-ACB(s) responsible for the certification of the certified health IT could surveil this health IT under the requirements of § 170.556 (under subpart E). Additionally, ONC could follow the CAP process under § 170.580(c) to enforce the associated “API” Condition of Certification proposed in § 170.404(a)(2). During the course of the ONC-ACB surveillance, the ONC-ACB subsequently discovers the developer has implemented the FHIR DSTU 2 standard and associated resources in such as a way that the patient's historical medications are being accessed, but not the patient's current medications. The ONC-ACB would notify ONC of its findings as it relates to a Condition of Certification under subpart D and pursue its own corrective action process under the surveillance requirements of § 170.556. Once ONC receives information regarding the complaints from the ONC-ACB, we could consider the potential safety risks for providers using the developer's API to access new or referred patients' medical information for diagnostic and treatment purposes. In this example, ONC could review both the certified health IT and the developer action under § 170.580, which is proposed to be expanded to account for developer actions under the Conditions and Maintenance of Certification (see proposed § 170.580(a)(2)(iii)) in addition to ONC's direct investigation of certified health IT for potential safety risks (see § 170.580(a)(2)(i)).

6. Concurrent Enforcement by the Office of Inspector General

We clarify that the enforcement approach described in this proposal would apply to ONC's administration of the Conditions and Maintenance of Certification and other requirements under the Program but would not apply to other agencies or offices that have independent authority to investigate and take enforcement action against a health IT developer of certified health IT. Notably, section 3022(b)(1)(A)(ii) of the PHSA, as added by the Cures Act, authorizes the OIG to investigate claims that a health IT developer of certified health IT has engaged in information blocking, which is defined by section 3022(a)(1) of the PHSA subject to reasonable and necessary activities identified by the Secretary as exceptions to the definition as proposed at part 171 (see section VIII. of this proposed rule). Additionally, section 3022(b)(1)(A)(i) authorizes OIG to investigate claims that a health IT developer of certified health IT has submitted a false attestation under the Condition of Certification described at section 3001(c)(5)(D)(vii). We emphasize that ONC's and OIG's respective authorities under the Cures Act (and in general) are independent and that either or both offices may exercise those authorities at any time.

We anticipate, however, that ONC and OIG may coordinate their respective enforcement activities, as appropriate, such as by sharing information about claims or suggestions of possible information blocking or false attestations (including violations of Conditions and Maintenance of Certification that may indicate that a developer has falsely attested to meeting a condition). Therefore, we propose that we may coordinate our review of a claim of information blocking with the OIG or defer to the OIG to lead a review of a claim of information blocking. In addition, we propose that we may rely on OIG findings to form the basis of a direct review action.

7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers

The final rule establishing ONC's Permanent Certification Program, “Establishment of the Permanent Certification for Health Information” (76 FR 1261), addresses self-developers. The language in the final rule describes the concept of “self-developed” as referring to a Complete EHR or EHR Module designed, created, or modified by an entity that assumed the total costs for Start Printed Page 7508testing and certification and that will be the primary user of the health IT (76 FR 1300). Therefore, self-developers differ from other health IT developers in that their products are not made commercially available and they do not have customers. While we propose that all general Conditions and Maintenance of Certification requirements apply to such developers, we also seek comment on which aspects of the Conditions and Maintenance of Certification requirements may not be applicable to self-developers. For example, when considering the Communications Condition of Certification, a self-developer of health IT may not have customer contracts, but could have other agreements in place, such as NDAs, that would be subject to the Condition of Certification.

VIII. Information Blocking

A. Statutory Basis

Section 4004 of the Cures Act added section 3022 of the PHSA (42 U.S.C. 300jj-52, “the information blocking provision”). Section 3022(a)(1) of the PHSA defines practices that constitute information blocking when engaged in by a health care provider, or a health information technology developer, exchange, or network. Section 3022(a)(3) authorizes the Secretary to identify, through notice and comment rulemaking, reasonable and necessary activities that do not constitute information blocking for purposes of the definition set forth in section 3022(a)(1). We propose to establish seven exceptions to the information blocking definition, each of which would define certain activities that would not constitute information blocking for purposes of section 3022(a)(1) of the PHSA because they are reasonable and necessary to further the ultimate policy goals of the information blocking provision. We also propose to interpret or define certain statutory terms and concepts that are ambiguous, incomplete, or provide the Secretary with discretion, and that we believe are necessary to carry out the Secretary's rulemaking responsibilities under section 3022(a)(3).

B. Legislative Background and Policy Considerations

In this section, we outline the purpose of the information blocking provision and related policy and practical considerations that we considered in identifying the reasonable and necessary activities that are proposed as exceptions to the definition of information blocking described subsequently in section VIII.D of this preamble.

1. Purpose of the Information Blocking Provision

The information blocking provision was enacted in response to concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes. These practices undermine public and private sector investments in the nation's health IT infrastructure and frustrate efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers.

The nature and extent of information blocking has come into sharp focus in recent years. In 2015, at the request of Congress, we submitted a Report on Health Information Blocking [101] (“Information Blocking Congressional Report”), in which we commented on the then current state of technology and of health IT and health care markets. Notably, we observed that prevailing market conditions create incentives for some individuals and entities to exercise their control over EHI in ways that limit its availability and use.

Since that time, we have continued to receive complaints and reports of information blocking from patients, clinicians, health care executives, payers, app developers and other technology companies, registries and health information exchanges, professional and trade associations, and many other stakeholders. ONC has listened to and reviewed these complaints and reports, consulted with stakeholders, and solicited input from our federal partners in order to inform our proposed information blocking policies. Stakeholders described discriminatory pricing policies that have the obvious purpose and effect of excluding competitors from the use of interoperability elements. Many of the industry stakeholders who shared their perspectives with us in listening sessions, including several health IT developers of certified health IT, condemned these practices and urged us to swiftly address them. Our engagement with stakeholders confirms that, despite significant public and private sector efforts to improve interoperability and data accessibility, adverse incentives remain and continue to undermine progress toward a more connected health system.

Based on these economic realities and our first-hand experience working with the health IT industry and stakeholders, in the Information Blocking Congressional Report, we concluded that information blocking is a serious problem and recommended that Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices.

Recent empirical and economic research further underscores the intractability of this problem and its harmful effects. In a national survey of health information organizations, half of respondents reported that EHR developers routinely engage in information blocking, and a quarter of respondents reported that hospitals and health systems routinely do so. The survey reported that perceived motivations for such conduct included, for EHR vendors, maximizing short-term revenue and competing for new clients, and for hospitals and health systems, strengthening their competitive position relative to other hospitals and health systems.[102] Other research suggests that these practices weaken competition among health care providers by limiting patient mobility, encouraging consolidation, and creating barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of clinical data to improve population health and the patient experience.[103]

The information blocking provision provides a comprehensive response to these concerns. The information blocking provision defines and creates possible penalties and disincentives for Start Printed Page 7509information blocking in broad terms, while working to deter the entire spectrum of practices that unnecessarily impede the flow of EHI or its use to improve health and the delivery of care. The information blocking provision applies to the conduct of health care providers, and to health IT developers of certified health IT, exchanges, and networks, and seeks to deter it with substantial penalties, including civil money penalties, and disincentives for violations. Additionally, developers of health IT certified under the Program are prohibited from information blocking under 3001(c)(5)(D)(i) of the PHSA. To promote effective enforcement, the information blocking provision empowers the HHS Office of Inspector General (OIG) to investigate claims of information blocking and provides referral processes to facilitate coordination with other relevant agencies, including ONC, the HHS Office for Civil Rights (OCR), and the Federal Trade Commission (FTC). The information blocking provision also provides for a complaint process and corresponding confidentiality protections to encourage and facilitate the reporting of information blocking. Enforcement of the information blocking provision is buttressed by section 3001(c)(5)(D)(i) and (vi) of the PHSA, which prohibits information blocking by developers of certified health IT as a Condition and Maintenance of Certification requirement under the Program and requires them to attest that they have not engaged in such practices.

2. Policy Considerations and Approach to the Information Blocking Provision

To ensure that individuals and entities that engage in information blocking are held accountable, the information blocking provision encompasses a relatively broad range of potential practices. For example, it is possible that some activities that are innocuous, or even beneficial, could technically implicate the information blocking provision. Given the possibility of these practices, Congress authorized the Secretary to identify reasonable and necessary activities that do not constitute information blocking (see section 3022(a)(3) of the PHSA) (in this proposed rule, we refer to such reasonable and necessary activities identified by the Secretary as “exceptions” to the information blocking provision). The information blocking provision also excludes from the definition of information blocking practices that are required by law (section 3022(a)(1) of the PHSA) and clarifies certain other practices that would not be penalized (sections 3022(a)(6) and (7) of the PHSA).

In considering potential exceptions to the information blocking provision, we must balance a number of policy and practical considerations. To minimize compliance and other burdens for stakeholders, we seek to promote policies that are clear, predictable, and administrable. In addition, we seek to implement the information blocking provision in a way that is sensitive to legitimate practical challenges that may prevent access, exchange, or use of EHI in certain situations. We must also accommodate practices that, while they may inhibit access, exchange, or use of EHI, are reasonable and necessary to advance other compelling policy interests, such as preventing harm to patients and others, promoting the privacy and security of EHI, and promoting competition and consumer welfare.

At the same time, while pursuing these objectives, we must adhere to Congress's plainly expressed intent to provide a comprehensive response to the information blocking problem. Information blocking can occur through a variety of business, technical, and organizational practices that can be difficult to detect and that are constantly changing as technology and industry conditions evolve. The statute responds to these challenges by defining information blocking broadly and in a manner that allows for careful consideration of relevant facts and circumstances in individual cases.

Accordingly, we propose to establish certain defined exceptions to the information blocking provision. These exceptions would be subject to strict conditions that balance the considerations described above. Based on those considerations, in developing the proposed exceptions, we applied three overarching policy criteria. First, each exception would be limited to certain activities that are both reasonable and necessary to advance the aims of the information blocking provision. These reasonable and necessary activities include: Promoting public confidence in the health IT infrastructure by supporting the privacy and security of EHI, and protecting patient safety; and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, we believe that each exception addresses a significant risk that regulated individuals and entities will not engage in these reasonable and necessary activities because of uncertainty regarding the breadth or applicability of the information blocking provision. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to protect and does not extend protection to other activities or practices that could raise information blocking concerns.

We discuss these policy considerations in more detail in the context of each of the exceptions proposed in section VIII.D of this preamble.

C. Relevant Statutory Terms and Provisions

In this section of the preamble, we discuss how we propose to interpret certain aspects of the information blocking provision that we believe are ambiguous, incomplete, or that provide the Secretary with discretion. We propose to define or interpret certain terms or concepts that are present in the statute and, in a few instances, to establish new regulatory terms or definitions that we believe are necessary to implement the Secretary's authority under section 3022(a)(3) to identify reasonable and necessary activities that do not constitute information blocking. Our goal in interpreting the statute and defining relevant terms is to provide greater clarity concerning the types of practices that could implicate the information blocking provision and, relatedly, to more effectively communicate the applicability and scope of the proposed exceptions outlined in this proposed rule. We believe that these proposals will provide a more meaningful opportunity for the public to comment on the proposed exceptions and our overall approach to interpreting and administering the information blocking provision. Additionally, we believe additional interpretive clarity will assist regulated actors to comply with the requirements of the information blocking provision.

1. “Required by Law”

With regard to the statute's exclusion of practices that are “required by law” from the definition of information blocking, we emphasize that “required by law” refers specifically to interferences with access, exchange, or use of EHI that are explicitly required by state or federal law. By carving out practices that are “required by law,” the statute acknowledged that there are state and federal laws that advance important policy interests and objectives by restricting access, exchange, and use of their EHI, and that practices that follow such laws should not be considered information blocking.Start Printed Page 7510

We note that for the purpose of developing an exception for reasonable and necessary privacy-protective practices, we have distinguished between interferences that are “required by law” and those engaged in pursuant to a privacy law, but which are not “required by law.” The former does not fall within the definition of information blocking, but the latter may implicate the information blocking provision and an exception may be necessary. For a detailed discussion of this topic, please see section VIII.D.2 of this preamble.

2. Health Care Providers, Health IT Developers, Exchanges, and Networks

Section 3022(a)(1) of the PHSA, in defining information blocking, refers to four classes of individuals and entities that may engage in information blocking and which include: Health care providers, health IT developers of certified health IT, networks, and exchanges. We propose to adopt definitions of these terms to provide clarity regarding the types of individuals and entities to whom the information blocking provision applies. We note that, for convenience and to avoid repetition in this preamble, we typically refer to these individuals and entities covered by the information blocking provision as “actors” unless it is relevant or useful to refer to the specific type of individual or entity. That is, when the term “actor” appears in this preamble, it means an individual or entity that is a health care provider, health IT developer, exchange, or network. For the same reasons, we propose to define “actor” in § 171.102.

a. Health Care Providers

The term “health care provider” is defined in section 3000(3) of the PHSA. We propose to adopt this definition for purposes of section 3022 of the PHSA when defining “health care provider” in § 171.102. We note that this definition is different from the definition of “health care provider” under the HIPAA Privacy and Security Rules. We are considering adjusting the information blocking definition of “health care provider” to cover all individuals and entities covered by the HIPAA “health care provider” definition. We seek comment on whether this approach would be justified, and commenters are encouraged to specify reasons why doing so might be necessary to ensure that the information blocking provision applies to all health care providers that might engage in information blocking.

b. Health IT Developers of Certified Health IT

Section 3022(a)(1)(B) of the PHSA defines information blocking, in part, by reference to the conduct of “health information technology developers.” Because title XXX of the PHSA does not define “health information technology developer,” we interpret section 3022(a)(1)(B) in light of the specific authority provided to OIG in section 3022(b)(1)(A) and (b)(2). Section 3022(b)(2) discusses developers, networks, and exchanges in terms of an “individual or entity,” specifically cross-referencing section 3022(b)(1)(A). Sections 3002(b)(1) and (b)(1)(A) state, in relevant part, that the OIG may investigate information blocking claims regarding a health information technology developer of certified health information technology or other entity offering certified health information technology. Together, these sections make clear that the information blocking provisions and OIG's authority extend to individuals or entities that develop or offer certified health IT. That the individual or entity must develop or offer certified health IT is further supported by section 3022(a)(7) of the PHSA—which refers to developers' responsibilities to meet the requirements of certification—and section 4002 of the Cures Act—which identifies information blocking as a Condition of Certification.

Notwithstanding this, the Cures Act does not prescribe that conduct that may implicate the information blocking provisions be limited to practices related to only certified health IT. Rather, the information blocking provisions would be implicated by any practice engaged in by an individual or entity that develops or offers certified health IT that is likely to interfere with the access, exchange, or use of EHI, including practices associated with any of the developer or offeror's health IT products that have not been certified under the Program. This interpretation is based primarily on section 3022(b)(1) of the PHSA. If Congress had intended that the enforcement of the information blocking provisions were limited to practices connected to certified health IT, we believe the Cures Act would have included language that tied enforcement to the operation or performance of a product certified under the Program. Rather, the description of the practices that OIG can investigate in section 3022(b)(1)(A)(ii) of the PHSA are not tied to the certification status of the health IT at issue, omitting any express reference to a health IT developer's practice needing to be related to “certified health information technology.” That the scope of the information blocking provision should not be limited to practices that involve only certified health IT is further evidenced by no such limitation applying to health care providers, health information exchanges (HIEs), and health information networks (HINs) as listed in sections 3022(b)(1) of the PHSA.

Additionally, the “practice described” in section 3022(a)(2) of the PHSA refers to “certified health information technologies” when illustrating practices that restrict authorized access, exchange, or use of EHI under applicable state or federal laws (section 3022(a)(2)(A) of the PHSA), but omits any reference to certification when describing “health information technology” in the practices described in sections 3022(a)(2)(B) and (C) of the PHSA. Importantly, sections 3022(a)(2)(B) and (C) of the PHSA address practices that are particularly relevant to health IT developers and offerors, although they could be engaged in by other types of actors. We interpret this drafting as a deliberate decision not to link the information blocking provisions with only the performance or use of certified health IT.

Finally, we note that the Cures Act does not impose a temporal nexus that would require that information blocking be carried out at a time when an individual or entity had health IT certified under the Program. Ostensibly, then, once an individual or entity has health IT certified, or otherwise maintains the certification of health IT, the individual or entity becomes forever subject to the information blocking provision. We do not believe that, understood in context, the Cures Act supports such a broad interpretation. Noting the above discussion concerning OIG's scope of authority under section 3022(b)(1)(A) and (b)(2) of the PHSA, we believe that to make developers and offerors of certified health IT subject to the information blocking provision in perpetuity would be inconsistent with the voluntary nature of the Program. However, we also believe that the Cures Act does not provide any basis for interpreting the information blocking provision so narrowly that a developer or offeror of certified health IT could escape penalty as a consequence of having its certification terminated or by withdrawing all of its extant certifications.

We consider that in the circumstances where a health IT developer has its certification terminated, or withdraws its certification, such that it no longer has any health IT certified under the Start Printed Page 7511Program, it should nonetheless be subject to penalties for information blocking engaged in during the time that it did have health IT certified under the Program. Accordingly, we propose to adopt a definition of “heath information technology (IT) developer of certified health IT” for the purposes of interpretation and enforcement of the information blocking provisions, including those regulatory provisions proposed under Title 45, part 171, of the Code of Federal Regulations, that would capture such developers or offerors. We propose, in § 171.102, that “health IT developer of certified health IT” means an individual or entity that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which had, at the time it engaged in a practice that is the subject of an information blocking claim, health IT (one or more) certified under the Program. To note, we propose that the term “information blocking claim” within this definition should be read broadly to encompass any statement of information blocking or potential information blocking. “Claims” of information blocking within this definition would not be limited, in any way, to a specific form, format, or submission approach or process.

We are also considering additional approaches to help ensure that developers and offerors of certified health IT remain subject to the information blocking provision for an appropriate period of time after leaving the Program. The rationale for this approach would be that a developer or offeror of certified health IT should be subject to penalties if, following the termination or withdrawal of certification, it refused to provide its customers with access to the EHI stored in the decertified health IT, provided that such interference was not required by law and did not qualify for one of the information blocking exceptions. Adopting this broader approach would help avoid the risk that a developer would be able to engage in the practices described in section 3022(a)(2) of the PHSA in respect to EHI that was collected on behalf of a health care provider when that health care provider would reasonably expect that the information blocking provision would protect against unreasonable and unnecessary interferences with that EHI. If the information blocking provision did not extend to capture such conduct, the protection afforded by the information blocking provision could become illusory, and providers would need to consider securing contractual rights to prevent interference, which we are aware they typically have great difficulty doing.[104]

One way that this could be achieved would be to define “health IT developer of certified health IT” as including developers and offerors of certified health IT that continue to store EHI that was previously stored in health IT certified in the Program. Alternatively, we are considering whether developers and offerors of certified health IT should remain subject to the information blocking provision for an appropriate period of time after leaving the Program. Namely, that the information blocking provision should apply for a specific time period, say one year, after the developer or offeror no longer has any health IT certified in the Program. This second approach has the attraction of providing a more certain basis for understanding which developers are subject to the information blocking provision. However, it also potentially captures developers and offerors who have fully removed themselves from the Program and, for example, no longer exercise control over EHI that was stored in their certified health IT.

We seek comment on which of these two models best achieves our policy goal of ensuring that health IT developers of certified health IT will face consequences under the information blocking provision if they engage in information blocking in connection with EHI that was stored or controlled by the developer or offeror whilst they were participating in the program. Commenters are also encouraged to identify alternative models and approaches for identifying when a developer or offeror should, and should no longer, be subject to the information blocking provision.

We note that a developer or offeror of a single health IT product that has had its certification suspended would be considered to have certified health IT for the purpose of the definition. We also note that we interpret the requirement that the health IT developer of certified health IT “exercise control” over EHI broadly. A developer would not necessarily need to have access to the EHI in order to exercise control. For example, a developer that implemented a “kill-switch” for a decertified software product that was locally hosted by a health care provider, preventing that provider from accessing its records, would be exercising control over the EHI for the purpose of this definition.

We clarify that we interpret “individual or entity that develops the certified health IT” as the individual or entity that is legally responsible for the certification status of the health IT, which would be the individual or entity that entered into a binding agreement that resulted in the certification status of the health IT under the Program or, if such rights are transferred, the individual or entity that holds the rights to the certified health IT. We also clarify that an “individual or entity that offers certified health IT” would include an individual or entity that under any arrangement makes certified health IT available for purchase or license. We seek comment on both of our interpretations. More specifically, we seek comment on whether there are particular types of arrangements under which certified health IT is “offered” in which the offeror should not be considered a “health IT developer of certified health IT” for the purposes of the information blocking provisions.

We also clarify that the proposed definition of “health IT developer of certified health IT” and our interpretation of the use of “health information technology developer” applies to Part 171 only and does not apply to the implementation of any other section of the PHSA or the Cures Act, including section 4005(c)(1) of the Cures Act.

We clarify that API Technology Suppliers, as described in section VII.4 of this preamble and defined in § 170.102, would be considered health IT developers of certified health IT subject to the conditions described above.

Last, we clarify that a “self-developer” of certified health IT, as the term has been used in the ONC Health IT Certification Program (Program) and described in this rulemaking (section VII.D.7) and previous rulemaking,[105] would be treated as a health care provider for the purposes of information blocking. This is because of our description of a self-developer for Program purposes [106] would essentially mean that such developers would not be supplying or offering their certified health IT to other entities. To be clear, self-developers would still be subject to the proposed Conditions and Start Printed Page 7512Maintenance of Certification requirements because they have health IT certified under the Program (see also section VII.D.7). We welcome comments on our determination regarding “self-developers” for information blocking purposes and whether there are other factors we should consider in how we treat “self-developers” of certified health IT for the purposes of information blocking.

We also seek comment generally on the definition proposed for “health IT developer of certified health IT.”

c. Networks and Exchanges

The terms “network” and “exchange” are not defined in the information blocking provision or in any other relevant statutory provisions. We propose to define these terms so that these individuals and entities that are covered by the information blocking provision understand that they must comply with its provisions. In accordance with the meaning and intent of the information blocking provision, we believe it is necessary to define these terms in a way that does not assume the application or use of certain technologies and is flexible enough to apply to the full range and diversity of exchanges and networks that exist today and may arise in the future. We note that in the past few years alone many new types of exchanges and networks that transmit EHI have emerged, and we expect this trend to accelerate with continued advancements in technology and renewed efforts to advance trusted exchange among networks and other entities under the trusted exchange framework and common agreement provided for by section 4003(b) of the Cures Act.

In considering the most appropriate way to define these terms, we examined how they are used throughout the Cures Act and the HITECH Act. Additionally, we considered dictionary and industry definitions of “network” and “exchange.” While these terms have varied usage and meaning in different industry contexts, certain concepts are common and have been incorporated into the proposed definitions below.

i. Health Information Network

We propose a functional definition of “health information network” (HIN) that focuses on the role of these actors in the health information ecosystem. We believe the defining attribute of a HIN is that it enables, facilitates, or controls the movement of information between or among different individuals or entities that are unaffiliated. For this purpose, we propose that two parties are affiliated if one has the power to control the other, or if both parties are under the common control or ownership of a common owner. We note that a significant implication of this definition is that a health care provider or other entity that enables, facilitates, or controls the movement of EHI within its own organization, or between or among its affiliated entities, is not a HIN in connection with that movement of information for the purposes of this proposed rule.

More affirmatively, we propose that an actor could be considered a HIN if it performs any or any combination of the following activities. First, the actor would be a HIN if it were to determine, oversee, administer, control, or substantially influence policies or agreements that define the business, operational, technical, or other conditions or requirements that enable or facilitate the access, exchange, or use of EHI between or among two or more unaffiliated individuals or entities. Second, an actor would be a HIN if it were to provide, manage, control, or substantially influence any technology or service that enables or facilitates the access, exchange, or use of EHI between or among two or more unaffiliated individuals or entities.

Typically, a HIN will influence the sharing of EHI between many unaffiliated individuals or entities. However, we do not propose to establish any minimum number of parties or “nodes” beyond the requirement that there be some actual or contemplated access, exchange, or use of information between or among at least two unaffiliated individuals or entities that is enabled, facilitated, or controlled by the HIN. We believe such a limitation would be artificial and would not capture the full range of entities that should be considered networks under the information blocking provision. To be clear, any individual or entity that enables, facilitates, or controls the access, exchange, or use of EHI between or among only itself and another unaffiliated individual or entity would not be considered a HIN in connection with the movement of that EHI (although that movement of EHI may still be regulated under the information blocking provision on the basis that the individual or entity is a health care provider or health IT developer of certified health IT). To be a HIN, the individual or entity would need to be enabling, facilitating, or controlling the access, exchange, or use of EHI between or among two or more other individuals or entities that were not affiliated with it.

To illustrate how the proposed definition would operate, we note the following examples. An entity is established within a state for the purpose of improving the movement of EHI between the health care providers operating in that state. The entity identifies standards relating to security and offers terms and conditions to be entered into by health care providers wishing to participate in the network. The entity offering (and then overseeing and administering) the terms and conditions for participation in the network would be considered a HIN for the purpose of the information blocking provision. We note that there is no need for a separate entity to be created in order that an entity be considered a HIN. For instance, a health system that administers business and operational agreements for facilitating the exchange of EHI that are adhered to by unaffiliated family practices and specialist clinicians in order to streamline referrals between those practices and specialists would likely be considered a HIN.

We note that the proposed definition would also encompass an individual or entity that does not directly enable, facilitate, or control the movement of information, but nonetheless exercises control or substantial influence over the policies, technology, or services of a network. In particular, there may be an individual or entity that relies on another entity—such as an entity specifically created for the purpose of managing a network—for policies and technology, but nevertheless dictates the movement of EHI over that network. For example, a large health care provider may decide to lead an effort to establish a network that facilitates the movement of EHI between a group of smaller health care providers (as well as the large health care provider) and through the technology of health IT developers. To achieve this outcome, the large health care provider, together with some of the participants, creates a new entity that administers the network's policies and technology. In this scenario, the large health care provider would come within the functional definition of a HIN and could be held accountable for the conduct of the network if the large health care provider used its control or substantial influence over the new entity—either in a legal sense, such as via its control over the governance or management of the entity, or in a less formal sense, such as if the large health care provider prescribed a policy to be adopted—to interfere with the access, exchange, or use of EHI. We note that the large health care provider in this example would be treated as a health care provider when utilizing the Start Printed Page 7513network to move EHI via the network's policies, technology, or services, but would be considered a HIN in connection with the practices of the network over which the large health care provider exercises control or substantial influence.

We seek comment on the proposed definition of a HIN. In particular, we request comment on whether the proposed definition is broad enough (or too broad) to cover the full range of individuals and entities that could be considered health information networks within the meaning of the information blocking provision. Additionally, we specifically request comment on whether the proposed definition would effectuate our policy goal of defining this term in a way that does not assume particular technologies or arrangements and is flexible enough to accommodate changes in these and other conditions.

ii. Health Information Exchange

We propose to define a “health information exchange” (HIE) as an individual or entity that enables access, exchange, or use of EHI primarily between or among a particular class of individuals or entities or for a limited set of purposes. Our research and experience in working with exchanges drove the proposed definition of this term. HIEs include but are not limited to regional health information organizations (RHIOs), state health information exchanges (state HIEs), and other types of organizations, entities, or arrangements that enable EHI to be accessed, exchanged, or used between or among particular types of parties or for particular purposes. For example, an HIE might facilitate or enable the access, exchange, or use of EHI exclusively within a regional area (such as a RHIO), or for a limited scope of participants and purposes (such as a clinical data registry or an exchange established by a hospital-physician organization to facilitate Admission, Discharge, and Transfer (ADT) alerting). We note that HIEs may be established under federal or state laws or regulations but may also be established for specific health care or business purposes or use cases. Additionally, we note that if an HIE facilitates the access, exchange, or use of EHI for more than a narrowly defined set of purposes, then it may be both an HIE and a HIN.

We seek comment on this proposed definition of an HIE. Again, we encourage commenters to consider whether this proposed definition is broad enough (or too broad) to cover the full range of individuals and entities that could be considered exchanges within the meaning of the information blocking provision, and whether the proposed definition is sufficiently flexible to accommodate changing technological and other conditions.

3. Electronic Health Information

The definition of information blocking applies to electronic health information (EHI) (section 3022(a)(1) of the PHSA). While section 3000(4) of the PHSA by reference to section 1171(4) of the Social Security Act defines “health information,” EHI is not specifically defined in the Cures Act, HITECH Act, or other relevant statutes. We propose to define EHI to mean:

(i) Electronic protected health information; and

(ii) any other information that—

  • is transmitted by or maintained in electronic media, as defined in 45 CFR 160.103;
  • identifies the individual, or with respect to which there is a reasonable basis to believe the information can be used to identify the individual; and
  • relates to the past, present, or future health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.

This definition of EHI includes, but is not limited to, electronic protected health information and health information that is created or received by a health care provider and those operating on their behalf; health plan; health care clearinghouse; public health authority; employer; life insurer; school; or university. In addition, we clarify that under our proposed definition, EHI includes, but is not limited to, electronic protected health information (ePHI) as defined in 45 CFR 160.103. In particular, unlike ePHI and health information, EHI is not limited to information that is created or received by a health care provider, health plan, health care clearinghouse, public health authority, employer, life insurer, school, or university. EHI may be provided, directly from an individual, or from technology that the individual has elected to use, to an actor covered by the information blocking provisions. We propose that EHI does not include health information that is de-identified consistent with the requirements of 45 CFR 164.514(b). We generally request comment on this proposed definition as well as on whether the exclusion of health information that is de-identified is consistent with the requirements of 45 CFR 164.514(b).

To be clear, this definition provides for an expansive set of EHI, which could include information on an individual's health insurance eligibility and benefits, billing for health care services, and payment information for services to be provided or already provided, which may include price information.

Price Information

The fragmented and complex nature of pricing within the health care system has decreased the efficiency of the health care system and has had negative impacts on patients, health care providers, health systems, plans, plan sponsors and other key health care stakeholders. Patients and plan sponsors have trouble anticipating or planning for costs, are not sure how they can lower their costs, are not able to compare costs, and have no practical way to measure the quality of the care or coverage they receive relative to the price they pay. Pricing information continues to grow in importance with the increase of high deductible health plans and surprise billing, which have resulted in an increase in out-of-pocket health care spending. Transparency in the price and cost of health care would help address the concerns outlined above by empowering patients to make informed health care decisions. Further, the availability of price information could help increase competition that is based on the quality and value of the services patients receive. Consistent with its statutory authority, the Department is considering subsequent rulemaking to expand access to price information for the public, prospective patients, plan sponsors, and health care providers.

Increased consumer demand, aligned incentives, more accessible and digestible information, and the evolution of price transparency tools are critical components to moving to a health care system that pays for value. However, the complex and decentralized nature of how price information is created, structured, formatted, and stored presents many challenges to achieving price transparency. To this point, pricing within health care demands a market-based approach whereby, for example, platforms are created that utilize raw data to provide consumers with digestible price information through their preferred medium.

ONC has a unique role in setting the stage for such future actions by establishing the framework to prevent the blocking of price information. Given that price information impacts the ability of patients to shop for and make decisions about their care, we seek comment on the parameters and implications of including price information within the scope of EHI for purposes of information blocking. In Start Printed Page 7514addition, the overall Department seeks comment on the technical, operational, legal, cultural, environmental and other challenges to creating price transparency within health care.

  • Should prices that are included in EHI:

○ Reflect the amount to be charged to and paid for by the patient's health plan (if the patient is insured) and the amount to be charged to and collected from the patient (as permitted by the provider's agreement with the patient's health plan), including for drugs or medical devices;

○ Include various pricing information such as charge master price, negotiated prices, pricing based on CPT codes or DRGs, bundled prices, and price to payer;

○ Be reasonably available in advance and at the point of sale;

○ Reflect all out-of-pocket costs such as deductibles, copayments and coinsurance (for insured patients); and/or

○ Include a reference price as a comparison tool such as the Medicare rate and, if so, what is the most meaningful reference?

  • For the purpose of informing referrals for additional care and prescriptions, should future rulemaking by the Department require health IT developers to include in their platforms a mechanism for patients to see price information, and for health care providers to have access to price information, tailored to an individual patient, integrated into the practice or clinical workflow through APIs?
  • To the extent that patients have a right to price information within a reasonable time in advance of care, how would such reasonableness be defined for:

○ Scheduled care, including how far in advance should such pricing be available for patients still shopping for care, in addition to those who have already scheduled care;

○ Emergency care, including how and when transparent prices should be disclosed to patients and what sort of exceptions might be appropriate, such as for patients in need of immediate stabilization;

○ Ambulance services, including air ambulance services; and

○ Unscheduled inpatient care, such as admissions subsequent to an emergency visit?

  • How would price information vary based on the type of health insurance and/or payment structure being utilized, and what, if any, challenges would such variation create to identifying the price information that should be made available for access, exchange, or use?
  • Are there electronic mechanisms/processes available for providing price information to patients who are not registered (i.e., not in the provider system) when they try to get price information?
  • Should price information be made available on public websites so that patients can shop for care without having to contact individual providers, and if so, who should be responsible for posting such information? Additionally, how would the public posting of pricing information through API technology help advance market competition and the ability of patients to shop for care?
  • If price information that includes a provider's negotiated rates for all plans and the rates for the uninsured were to be required to be posted on a public website, is there technology currently available or that could be easily developed to translate that data into a useful format for individuals? Are there existing standards and code sets that would facilitate such transmission and translation? To the extent that some data standards are lacking in this regard, could developers make use of unstandardized data?
  • What technical standards currently exist or may be needed to represent price information electronically for purposes of access, exchange, and use?
  • Are there technical impediments experienced by stakeholders regarding price information flowing electronically?
  • Would updates to the CMS-managed HIPAA transactions standards and code sets be necessary to address the movement of price information in a standardized way?
  • How can price transparency be achieved for care delivered through value based arrangements, including at accountable care organizations, demonstrations and other risk-sharing arrangements?
  • What future requirements should the Department consider regarding the inclusion of price information in a patient's EHI, particularly as it relates to the amount paid to a health care provider by a patient (or on behalf of a patient) as well as payment calculations for the future provision of health care to such patient?
  • If price information is included in EHI, could that information be useful in subsequent rulemaking that the Department may consider in order to reduce or prevent surprise medical billing, such as requirements relating to:

○ The provision of a single bill that includes all health care providers involved in a health care service, including their network status;

○ The provision of a binding quote reasonably in advance of scheduled care (that is, non-emergent care) or some subset of scheduled care, such as for the most “shoppable” services;

○ Ensuring that all health care providers in an in-network facility charge the in-network rate; and

○ Notification of billing policies such as timely invoice dates for all providers and facilities, notwithstanding network status, due date for invoice payments by the prospective patient's payers and out-of-pocket obligations, date when unpaid balances are referred for collections, and appeals rights and procedures for patients wishing to contest an invoice?

4. Interests Promoted by the Information Blocking Provision

a. Access, Exchange, and Use of EHI

The information blocking provision promotes the ability to access, exchange, and use EHI, consistent with the requirements of applicable law. We interpret the terms “access,” “exchange,” and “use” broadly, consistent with their generally understood meaning in the health IT industry and their function and context in the information blocking provision.

The concepts of access, exchange, and use are closely related: EHI cannot be used unless it can be accessed, and this often requires that the EHI be exchanged among different individuals or entities and through various technological means. Moreover, the technological and other means necessary to facilitate appropriate access and exchange of EHI vary significantly depending on the purpose for which the information will be used. For example, the technologies and services that support a payer's access to EHI to assess clinical value will likely differ from those that support a patient's access to EHI via a smartphone app. That is, to deter information blocking in these and many other potential uses of EHI—and, by extension, the many and diverse means of access and exchange that support such uses.

This is consistent with the way these terms are employed in the information blocking provision and in other relevant statutory provisions. For example, section 3022(a)(2) of the PHSA contemplates a broad range of purposes for which EHI may be accessed, exchanged, and used—from treatment, care delivery, and other permitted purposes, to exporting complete information sets and transitioning between health IT systems, to supporting innovations and advancements in health information access, exchange, and use. Separately, Start Printed Page 7515the Cures Act and the HITECH Act contemplate many different purposes for and means of accessing, exchanging, and using EHI, which include, but are not limited to, quality improvement, guiding medical decisions at the time and place of care, reducing medical errors and health disparities, delivering patient-centered care, and supporting public health and clinical research activities.[107]

In addition to these statutory provisions, we have considered how the terms access, exchange, and use have been defined or used in existing regulations and other relevant health IT industry contexts. While those definitions have specialized meanings and are not controlling here, they are instructive insofar as they illustrate the breadth with which these terms have been understood in other contexts. For example, the HIPAA Privacy Rule defines an individual's right of access to include the right to have a copy of all or part of their PHI transmitted directly to them or any person or entity he or she designates, in any form and format (including electronically) that the individual requests and that the covered entity holding the information can readily produce (45 CFR 164.524). In a different context, the HIPAA Security Rule defines “access” as the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource (45 CFR 164.304). The HIPAA Rules also define the term “use,” which includes the sharing, employment, application, utilization, examination, or analysis of individually identifiable health information within an entity that maintains the information (45 CFR 160.103).

As the examples and discussion above demonstrate, the concepts of access, exchange, and use are used in a variety of contexts to refer to a broad spectrum of activities. We believe that the types of access, exchange, and use described above would be promoted under the information blocking provision, as would other types of access, exchange, or use not specifically contemplated in these or other regulations. Further, we note that the information blocking provision would also extend to innovations and advancements in health information access, exchange, and use that may occur in the future (see section 3022(a)(2) of the PHSA).

Consistent with the above, and to convey the full breadth of activities that may implicate the information blocking provision, we propose definitions of access, exchange, and use in § 171.102. We emphasize the interrelated nature of the definitions. For example, the definition of “use” includes the ability to read, write, modify, manipulate, or apply EHI to accomplish a desired outcome or to achieve a desired purpose, while “access” is defined as the ability or means necessary to make EHI available for use. As such, interference with “access” would include, for example, an interference that prevented a health care provider from writing EHI to its health IT or from modifying EHI stored in health IT, whether by the provider itself or by, or via, a third-party app. We encourage comment on these definitions. In particular, commenters may wish to consider whether these definitions are broad enough to cover all of the potential purposes for which EHI may be needed and ways in which it could conceivably be used, now and in the future.

b. Interoperability Elements

In this proposed rule, we use the term “interoperability element” to refer to any means by which EHI can be accessed, exchanged, or used. We clarify that the means of accessing, exchanging, and using EHI are not limited to functional elements and technical information but also encompass technologies, services, policies, and other conditions [108] necessary to support the many potential uses of EHI as described above. Because of the evolving nature of technology and the diversity of privacy laws and regulations, institutional arrangements, and policies that govern the sharing of EHI, we will not provide an exhaustive list of interoperability elements. However, we believe that it is useful to define this term, both because of its importance for analyzing the likelihood of interference under the information blocking provision, and because some of the proposed exceptions to the provision contain conditions concerning the availability and provision of interoperability elements. Therefore, we propose to define “interoperability element” in § 171.102. As noted, our intent is to capture all of the potential means by which EHI may be accessed, exchanged, or used for any relevant purposes; both now and as technology and other conditions evolve. We seek comment on whether the proposed definition realizes that intent and, if not, any changes we should consider.

5. Practices That May Implicate the Information Blocking Provision

To meet the definition of information blocking, a practice must be likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI. In this section and elsewhere in this preamble, we discuss various types of hypothetical practices that could implicate the provision. We do this to illustrate the scope of the information blocking provision and to explain our interpretation of various statutory concepts. However, we stress that the types of practices discussed in this preamble are illustrative, not exhaustive, and that many other types of practices could also implicate the provision. Nor does the fact that we have not identified or discussed a particular type of practice imply that it is less serious than those that are discussed in this preamble. Indeed, because information blocking may take many forms, it is not possible—and we do not attempt—to anticipate or catalog the many potential types of practices that may raise information blocking concerns.

We emphasize that any analysis of information blocking necessarily requires a careful consideration of the individual facts and circumstances, including whether the practice was required by law, whether the actor had the requisite statutory knowledge, and whether an exception applies. When we state that a practice would implicate the provision or could violate the provision, we are expressing a conclusion that the type of practice is one that would be likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI, and that further analysis of these and other statutory elements would therefore be warranted to determine whether a violation has occurred. We highlight this distinction because to implicate the information blocking provision is not necessarily to violate it, and that each case will turn on its own unique facts. For example, a practice that seemingly meets the statutory definition of information blocking would not be information blocking if it was required by law, if one or more elements of the definition were not met, or if was covered by one of the proposed exceptions.

We propose in section VIII.D of this preamble to establish seven exceptions to the information blocking provision for certain reasonable and necessary activities. If an actor can establish that an exception applies to each practice for which a claim of information blocking Start Printed Page 7516has been made, including that the actor satisfied all applicable conditions of the exception at all relevant times, then the practice would not constitute information blocking.

Based on early discussions with stakeholders during the development of this proposed rule, we are aware that the generality with which the information blocking provision describes practices that are likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI may leave some uncertainty as to the scope of the information blocking provision and the types of practices that will implicate enforcement by ONC and/or OIG. To provide additional clarity on this point, we elaborate our understanding of these important statutory concepts below.

a. Prevention, Material Discouragement, and Other Interference

The information blocking provision and its enforcement subsection do not define the terms “interfere with,” “prevent,” and “materially discourage,” and use these terms collectively and without differentiation. Based on our interpretation of the information blocking provision and the ordinary meanings of these terms in the context of EHI, we do not believe they are mutually exclusive, but that prevention and material discouragement are best understood as types of interference, and that use of these terms in the statute to define information blocking illustrates the desire to reach all practices that an actor knows, or should know, are likely to prevent, materially discourage, or otherwise interfere with the access, exchange, or use of EHI. Consistent with this understanding, in this preamble to the proposed rule, we use the terms “interfere with” and “interference” as inclusive of prevention, material discouragement, and other forms of interference that implicate the information blocking provision.

We believe that interference could take many forms. In addition to the prevention or material discouragement of access, exchange, or use, we propose that interference could include practices that increase the cost, complexity, or other burden associated with accessing, exchanging, or using EHI. Additionally, interference could include practices that limit the utility, efficacy, or value of EHI that is accessed, exchanged, or used, such as by diminishing the integrity, quality, completeness, or timeliness of the data. We refer readers to section VIII.C.5.c of this preamble below for a discussion of these and other potential practices that could interfere with access, exchange, or use and thereby implicate the information blocking provision.

Relatedly, to avoid potential ambiguity and clearly communicate the full range of potential practices that could implicate the information blocking provision, we propose to codify a definition of “interfere with” in § 171.102, consistent with our interpretation set forth above.

b. Likelihood of Interference

The information blocking provision is preventative in nature. That is, the information blocking provision proscribes practices that are likely to interfere with (including preventing or materially discouraging) access, exchange, or use of EHI—whether or not such harm actually materializes. By including both the likely and the actual effects of a practice, the information blocking provision encourages individuals and entities to avoid engaging in practices that undermine interoperability, and to proactively promote access, exchange, and use of EHI.

We believe that a practice would satisfy the information blocking provision's “likelihood” requirement if, under the circumstances, there is a reasonably foreseeable risk that the practice will interfere with access, exchange, or use of EHI. For example, where an actor refuses to share EHI or to provide access to certain interoperability elements, it is reasonably foreseeable that such actions will interfere with access, exchange, or use of EHI. As another example, it is reasonably foreseeable that a health care provider may need to access information recorded in a patient's electronic record that could be relevant to the treatment of that patient. For this reason, a policy or practice that limits timely access to such information in an appropriate electronic format creates a reasonably foreseeable likelihood of interfering with the use of the information for these treatment purposes.

Whether the risk of interference is reasonably foreseeable will depend on the particular facts and circumstances attending the practice or practices at issue. Because of the number and diversity of potential practices, and the fact that different practices will present varying risks of interfering with access, exchange, or use of EHI, we do not attempt to anticipate all of the potential ways in which the information blocking provision could be implicated. Nevertheless, to assist with compliance, we clarify certain circumstances in which, based on our experience, a practice will almost always be likely to interfere with access, exchange, or use of EHI. We caution that these situations are not exhaustive and that other circumstances may also give rise to a very high likelihood of interference under the information blocking provision. In each case, ONC will consider the totality of the circumstances in evaluating whether a practice is likely to implicate the statute and to give rise to a violation.

i. Observational Health Information

Although the information blocking provision applies to all EHI, we believe that information blocking concerns are especially pronounced when the conduct at issue has the potential to interfere with the access, exchange, or use of EHI that is created or maintained during the practice of medicine or the delivery of health care services to patients. We refer to such information in this section of the preamble collectively as “observational health information.” Such information includes, but is not limited to, health information about a patient that could be captured in a patient record within an EHR and other clinical information management systems; as well as information maintained in administrative and other IT systems when the information is clinically relevant, directly supports patient care, or facilitates the delivery of health care services to consumers. We note that there is a special need for timely, electronic access to this information and that, moreover, the clinical and operational utility of this information is often highly dependent on multiple actors exercising varying forms and degrees of control over the information itself or the technological, contractual, or other means by which it can be accessed, exchanged, and used. Against these indications, practices that adversely impact the access, exchange, or use of observational health information will almost always implicate the information blocking provision.

We note that observational health information may be technically structured or unstructured (such as “free text”). Therefore, in general, clinicians' notes would constitute observational health information, at least insofar as the notes contain observations or conclusions about a patient or the patient's care. In contrast, we believe certain types of EHI are qualitatively distinct from observational health information, such as EHI that is created through aggregation, algorithms, and other techniques that transform observational health information into fundamentally new data or insights that are not obvious from the observational Start Printed Page 7517information alone. This could include, for example, population-level trends, predictive analytics, risk scores, and EHI used for comparisons and benchmarking activities. Similarly, internally developed quality measures and care protocols are generally distinct from observational health information. In general, we believe that practices that pertain solely to the creation or use of these transformative data and insights would not usually present the very high likelihood of interference described above. However, we emphasize that, depending on the specific facts at issue, practices related to electronic non-observational health information (a type of EHI), such as price information, could still be subject to the information blocking provision. We seek comment on this proposed approach and encourage commenters to identify potential practices related to non-observational health information that could raise information blocking concerns.

Finally, we clarify that merely collecting, organizing, formatting, or processing observational health information maintained in EHRs and other source systems does not change the fundamental nature of that EHI or obligations under the information blocking provisions. Likewise, the mere fact that EHI is stored in a proprietary format or has been combined with confidential or proprietary information does not alter the actor's obligations under the information blocking provisions to facilitate access, exchange, and use of the EHI in response to a request. For example, the information blocking provision would be implicated if an actor were to assert proprietary rights in medical vocabularies or code sets in a way that was likely to interfere with the access, exchange, or use of observational health information stored in such formats. However, as noted in section VIII.D.6 of this preamble, under the exception for licensing of interoperability elements on reasonable and non-discriminatory terms, an actor could charge a royalty for access to proprietary data or data coded in a proprietary manner so long as that royalty were offered on reasonable and non-discriminatory terms pursuant to the conditions outlined in the exception.

ii. Purposes for Which Information May be Needed

We believe the information blocking provision will almost always be implicated when a practice interferes with access, exchange, or use of EHI for certain purposes, including but not limited to:

  • Providing patients with access to their EHI and the ability to exchange and use it without special effort (see section VII.B.4).
  • Ensuring that health care professionals, care givers, and other authorized persons have the EHI they need, when and where they need it, to make treatment decisions and effectively coordinate and manage patient care and can use the EHI they may receive from other sources.
  • Ensuring that payers and other entities that purchase health care services can obtain the information they need to effectively assess clinical value and promote transparency concerning the quality and costs of health care services.
  • Ensuring that health care providers can access, exchange, and use EHI for quality improvement and population health management activities.
  • Supporting access, exchange, and use of EHI for patient safety and public health purposes.

The need to ensure that EHI is readily available and usable for these purposes is paramount. Therefore, practices that increase the cost, difficulty, or other burden of accessing, exchanging, or using EHI for these purposes would almost always implicate the information blocking provision. Individuals and entities that develop health IT or have a role in making these technologies and services available should consider the impact of their actions and take steps to support interoperability and avoid impeding the availability or use of EHI.

iii. Control Over Essential Interoperability Elements; Other Circumstances of Reliance or Dependence

An actor may have substantial control over one or more interoperability elements that provide the only reasonable means of accessing, exchanging, or using EHI for a particular purpose. In these circumstances, any practice by the actor that could impede the use of the interoperability elements—or that could unnecessarily increase the cost or other burden of using the elements—would almost always implicate the information blocking provision.

The situation described above is most likely when customers or users are dependent on an actor's technology or services, which can occur for any number of reasons. For example, technological dependence may arise from legal or commercial relations, such as a health care provider's reliance on its EHR developer to ensure that EHI managed on its behalf is accessible and usable when it is needed. Relatedly, most EHI is currently stored in EHRs and other source systems that use proprietary data models or formats. Knowledge of the data models, formats, or other relevant technical information (e.g., proprietary APIs) is necessary to understand the data and make efficient use of it in other applications and technologies. Because this information is routinely treated as confidential or proprietary, the developer's cooperation is required to enable uses of the EHI that go beyond the capabilities provided by the developer's technology. This includes the capability to export complete information sets and to migrate data in the event that a user decides to switch to a different technology.

Separate from these contractual and intellectual property issues, users may become “locked in” to a particular technology, HIE, or HIN for financial or business reasons. For example, many health care providers have invested significant resources to adopt EHR technologies—including costs for deployment, customization, data migration, and training—and have tightly integrated these technologies into their information management strategies, clinical workflows, and business operations. As a result, they may be reluctant to switch to other technologies due to the significant cost and disruption this would entail.

Another important driver of technological dependence is the “network effects” of health IT adoption, which are amplified by a reliance on technologies and approaches that are not standardized and do not enable seamless interoperability. Consequently, health care providers and other health IT users may gravitate towards and become reliant on the proprietary technologies, HIEs, or HINs that have been adopted by other individuals and entities with whom they have the greatest need to exchange EHI. These effects may be especially pronounced within particular product or geographic areas. For example, a HIN that facilitates certain types of exchange or transactions may be so widely adopted that it is a de facto industry standard. A similar phenomenon may occur within a particular geographic area once a critical mass of hospitals, physicians, or other providers adopt a particular EHR technology, HIE, or HIN.

In these and other analogous circumstances of reliance or dependence, there is a heightened risk that an actor's conduct will interfere with access, exchange, or use of EHI. To assist with compliance, we highlight the following common scenarios, based on our outreach to stakeholders, in which Start Printed Page 7518actors exercise control over key interoperability elements.[109]

  • Health IT developers of certified health IT that provide EHR systems or other technologies used to capture EHI at the point of care are in a unique position to control subsequent access to and use of that information.
  • HINs and HIEs may be in a unique position to control the flow of information among particular persons or for particular purposes, especially if the HIN or HIE has achieved significant adoption in a particular geographic area or for a particular type of health information use case.
  • Similar control over EHI may be exercised by other entities, such as health IT developers of certified health IT, that supply or control proprietary technologies, platforms, or services that are widely adopted by a class of users or that are a “de facto standard” for certain types of EHI exchanges or transactions.
  • Health care providers within health systems and other entities that provide health IT platforms, infrastructure, or information sharing policies may have a degree of control over interoperability or the movement of data within a geographic area that is functionally equivalent to the control exercised by a dominant health IT developer, HIN, or HIE.

To avoid violating the information blocking provision, actors with control over interoperability elements should be careful not to engage in practices that exclude persons from the use of those elements or create artificial costs or other impediments to their use.

We encourage comment on these and other circumstances that may present an especially high likelihood that a practice will interfere with access, exchange, or use of EHI within the meaning of the information blocking provision.

c. Examples of Practices Likely To Interfere With Access, Exchange, or Use of EHI

To further clarify the scope of the information blocking provision, below we describe several types of practices that would be likely to interfere with access, exchange, or use of EHI. These examples clarify and expand on those set forth in section 3022(a)(2) of the PHSA.

Because information blocking can take many forms, we emphasize that the categories of practices described below are illustrative only and do not provide an exhaustive list or comprehensive description of practices that may implicate the information blocking provision and its penalties. We also reiterate that to implicate the provision is not necessarily to violate it, and that each case will turn on its own unique facts. For instance, a practice that seemingly meets the statutory definition of information blocking would not be information blocking if it was required by law, if one or more elements of the definition were not met, or if it was covered by one of the proposed exceptions for certain reasonable and necessary activities detailed in section VIII.D of this preamble. For the purposes of the following discussion, we do not consider the applicability of any exceptions proposed in section VIII.D of this preamble; we therefore strongly encourage readers to review that section in conjunction with the discussion of practices in this section below.

i. Restrictions on Access, Exchange, or Use

The information blocking provision establishes penalties, including civil monetary penalties, or requires appropriate disincentives, for practices that restrict access, exchange, or use of EHI for permissible purposes. For example, section 3022(a)(2)(A) of the PHSA states that information blocking may include practices that restrict authorized access, exchange, or use for treatment and other permitted purposes under applicable law. Section 3022(a)(2)(C)(i) of the PHSA states that information blocking may include implementing health IT in ways that are likely to restrict the access, exchange, or use of EHI with respect to exporting complete information sets or in transitioning between health IT systems.

One means by which actors may restrict access, exchange, or use of EHI is through formal restrictions. These may be expressed in contract or license terms, EHI sharing policies, organizational policies or procedures, or other instruments or documents that set forth requirements related to EHI or health IT. Additionally, in the absence of an express contractual restriction, an actor may achieve the same result by exercising intellectual property or other rights in ways that restrict access, exchange, or use. As an illustration, the following non-exhaustive examples illustrate types of formal restrictions that would likely implicate the information blocking provision. As stated above, the examples throughout this section VIII.C.5.c. are presented without consideration to whether a proposed exception applies, and readers are encouraged to familiarize themselves with section VIII.D of this preamble.

  • A health system's internal policies or procedures require staff to obtain an individual's written consent before sharing any of a patient's EHI with unaffiliated providers for treatment purposes even though obtaining an individual's consent is not required by state or federal law.
  • An EHR developer's software license agreement prohibits a customer from disclosing to its IT contractors certain technical interoperability information without which the customer and its IT contractors cannot efficiently export and convert EHI for use in other applications.
  • A HIN's participation agreement prohibits entities that receive EHI through the HIN from transmitting that EHI to entities who are not participants of the HIN.
  • An EHR developer sues to prevent a clinical data registry from providing interfaces to physicians who use the developer's EHR technology and wish to submit EHI to the registry. The EHR developer claims that the registry is infringing the developer's copyright in its database because the interface incorporates data mapping that references the table headings and rows of the EHR database in which the EHI is stored.

Access, exchange, or use of EHI can also be restricted in less formal ways. The information blocking provision would be implicated, for example, where an actor simply refuses to exchange or to facilitate the access or use of EHI, either as a general practice or in isolated instances. The refusal may be expressly stated, or it may be implied from the actor's conduct, as where the actor ignores requests to share EHI or provide interoperability elements; gives implausible reasons for not doing so; or insists on terms or conditions that are so objectively unreasonable that they amount to a refusal to provide access, exchange, or use of the EHI. Some examples of informal restrictions include, but are not limited to:

  • A health IT developer of certified health IT refuses to license interoperability elements that are reasonably necessary for the developer's customers, their IT contractors, and other health IT developers to develop and deploy software that will work with the certified health IT.
  • A health system incorrectly claims that the HIPAA Rules or other legal requirements preclude it from exchanging EHI with unaffiliated providers.Start Printed Page 7519
  • An EHR developer ostensibly allows third-party developers to deploy apps that are interoperable with its EHR system. However, as a condition of doing so, the third-party developers must provide their source code and grant the EHR developer the right to use it for its own purposes—terms that almost no developer would willingly accept.
  • A provider notifies its EHR developer of its intent to switch to another EHR system and requests a complete export of its EHI. The developer will provide only the EHI in a PDF format, even though it already can and does produce the data in a commercially reasonable structured format.

We emphasize that restrictions on access, exchange, or use that are required by law would not implicate the information blocking provision. Moreover, we recognize that some restrictions, while not required by law, may be reasonable and necessary for the privacy and security of individuals' EHI; such practices may qualify for protection under the exceptions proposed in section VIII.D.2 and 3 of this preamble.

ii. Limiting or Restricting the Interoperability of Health IT

The information blocking provision includes practices that restrict the access, exchange, or use of EHI in various ways (see section 3022(a)(2) of the PHSA). These practices could include, for example, disabling or restricting the use of a capability that enables users to share EHI with users of other systems or to provide access to EHI to certain types of persons or for certain purposes that are legally permissible. In addition, the information blocking provision would be implicated where an actor configures or otherwise implements technology in ways that limit the types of data elements that can be exported or used from the technology. Other practices that would be suspect include configuring capabilities in a way that removes important context, structure, or meaning from the EHI, or that makes the data less accurate, complete, or usable for important purposes for which it may be needed. Likewise, implementing capabilities in ways that create unnecessary delays or response times, or that otherwise limit the timeliness of EHI accessed or exchanged, would interfere with the access, exchange, and use of that information and would therefore implicate the information blocking provision. We note that any conclusions regarding such interference would be based on fact-finding specific to each case and would need to consider the applicability of an exception.

We propose that the information blocking provision would be implicated if an actor were to deploy technological measures that limit or restrict the ability to reverse engineer the functional aspects of technology in order to develop means for extracting and using EHI maintained in the technology. This may include, for example, employing technological protection measures that, if circumvented, would trigger liability under the Digital Millennium Copyright Act (see 17 U.S.C. 1201) or other laws.

The following hypothetical situations illustrate some (though not all) of the types of practices described above and which would implicate the information blocking provision.

  • A health system implements locally-hosted EHR technology certified to proposed § 170.315(g)(10) (the health system acts as an API Data Provider as defined by § 170.102). As required by proposed § 170.404(b)(2), the technology developer provides the health system with the capability to automatically publish its production endpoints (i.e., the internet servers that an app must “call” and interact with in order to request and exchange patient data). The health system chooses not to enable this capability, however, and provides the production endpoint information only to apps it specifically approves. This prevents other applications—and patients that use them—from accessing data that should be made readily accessible via standardized APIs.
  • A hospital directs its EHR developer to configure its technology so that users cannot easily send electronic patient referrals and associated EHI to unaffiliated providers, even when the user knows the Direct address and/or identity (i.e., National Provider Identifier) of the unaffiliated provider.
  • An EHR developer that prevents (such as by way of imposing exorbitant fees unrelated to the developer's costs, or by some technological means) a third-party clinical decision support (CDS) app from writing EHI to the records maintained by the EHR developer on behalf of a health care provider (despite the provider authorizing the third-party app developer's use of EHI) because the EHR developer: (1) Offers a competing CDS software to the third-party app; and (2) includes functionality (e.g., APIs) in its health IT that would provide the third party with the technical capability to modify those records as desired by the health care provider.
  • Although an EHR developer's patient portal offers the capability for patients to directly transmit or request for direct transmission of their EHI to a third party, the developer's customers (e.g., health care providers) choose not to enable this capability.
  • A health care provider has the capability to provide same-day access to EHI in a form and format requested by a patient or a patient's health care provider, but takes several days to respond.