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

The Office of the National Coordinator for Health IT (ONC) has recently released a proposed rule which aims to implement certain provisions of the 21st Century Cures Act and Executive Orders 13771, 13777 and 13813, including new conditions for maintenance of certification for HIT software (ONC 2015 Certification), the voluntary certification of health IT for use by pediatric health providers (new certification criteria), outlining activities termed as information blocking and exceptions to these activities, and to promote health care choice and competition.

This proposed rule also lays out the groundwork to support patient access to their electronic health information (EHI), such as making a patient’s EHI more accessible through adoption of standards and new 2015 edition certification criteria (including use of FHIR APIs) and the implementation of information blocking policies.

Summary of Changes

Based on our interpretation of the rule, we have identified six major titles under which changes have been proposed.

Change 1: Deregulatory Actions for Previous Regulations

ONC recognizes the overarching regulatory framework currently in place and has proposed six changes to reduce the regulatory burden. These changes are:

1. Removal of Randomized Surveillance: Traditionally, ONC required ONC- Accredited Certification Bodies (ACB) to proactively surveil 2% of the total certifications. This has been removed along with several other provisions related to randomized surveillance. ACBs can still undertake randomized surveillance, although it will not be mandated by ONC.
2. Removal of ONC 2014 Edition: The standards and technologies proposed in the 2014 edition certification are believed to be outdated and have been completely removed for all certification, and support purposes leaving 2015 Edition as the new baseline. This will also seek to remove the inconsistencies caused by two different certifications with often conflicting or redundant requirements.
3. Removal of ONC Approved Accreditor (AA): The ONC AA used to certify ACB on ONC’s behalf. However, ONC feels that the efforts are duplicative and ONC on its own has the capacity to provide the appropriate oversight of ONC-ACB. Considering these changes, ONC- ACBs can obtain and maintain accreditation to ISO/IEC 17065 from any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF).
4. Removal of some ONC 2015 Edition Criteria: ONC has proposed the removal of certain certification criteria from the 2015 Edition Base EHR definition. These are “Problem List”, “Medication List”, “Medication Allergy List”, “Smoking Status”, “Drug-Formulary and Preferred Drug Lists”, “Patient-Specific Education Resources”, “CCDS Summary Record – Create; and CCDS Summary Record – Receive” and “Secure Messaging”. ONC believes some of these are covered in other existing and new aspects of its certification program and would reduce redundancies and complexity.
5. Removal of certain ONC program requirements: ONC proposed to remove certain mandatory disclosure requirements and attestation requirement under the program. These disclosure requirements regarding certified health IT limitations are superseded by the Cures Act information blocking provision and Conditions of Certification, which are being implemented by ONC.
6. Recognition of FDA Processes: ONC is working 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 Edition “quality management systems” criterion and the 2015 Edition “safety-enhanced design” criterion.

Change 2: Updates to the ONC 2015 Certification Criteria

ONC has proposed seven key changes in the ONC 2015 Certification Criteria to reduce complexity for Health IT developers and establish next generation Health IT capabilities.

1. New United States Core Data for Interoperability (USCDI) Standard: ONC proposes to remove the Common Clinical Data Set (CCDS) definition and replace it with the USCDI standard which holds essential data classes and constituent data elements necessary to exchange in support of nationwide interoperability. The data elements to be reported under USCDI have been published as USCDI v1 and include new data fields related to clinical notes, some demographics fields, provenance of the data (author) and pediatrics vital signs. See the data set here: USCDI V1
2. Update to e-Prescribing (eRx) standard: ONC proposes to update the electronic prescribing (e-Rx) SCRIPT standard to NCPDP SCRIPT 2017071 (finalized by CMS in its Part D standards) and a new certification criterion 170.315(b)(11) to support these changes.
3. Reducing QRDA requirements: ONC 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 requires Health IT Modules to support the CMS QRDA Implementation Guide reducing the burden of having to support 2 QRDA formats (HL7 and CMS)
4. Updates to the Export Criterion: ONC proposes a new 2015 Edition certification criterion for “electronic health information (EHI) export” in 170.315(b)(10), replacing the 2015 Edition “data export” certification criterion 170.315(b)(6) under the 2015 Base EHR definition. This criterion would enable export of EHI data for a patient during normal workflows or Health IT migration. This criterion would also require the export to include the data format (including its structure and syntax) and make it publicly available, to facilitate the receiving health IT system’s interpretation. However, no specific format has been specified by ONC except for the above conditions.
5. Use of FHIR Application Programming Interfaces (API): ONC proposes a new criterion 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’s Fast Healthcare Interoperability Resources (FHIR) standards and several implementation specifications. The full details of the certification requirements have been published here: FHIR API Certification Requirements
6. New Privacy and Security Transparency Attestations: ONC proposes to require that a Health IT Module developer attest to two additional attestations for certifications which are: whether the Health IT Module encrypts authentication credentials and whether the Health IT Module supports multi-factor authentication.
7. New Data Segmentation for Privacy and Consent Management (DS4P) criteria: ONC proposes to remove two criteria proposed in the 2015 Edition final rules related to creating and receiving a summary record according to DS4P standard and instead replace them with three new 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.

Change 3: Modifications to the ONC Health IT Certification Program

ONC proposes to make corrections to the 2015 Edition privacy and security certification framework and relevant regulatory provisions and has already incorporated these changes in the Certification Companion Guides (CCGs). The proposals are:

1. New and revised principles of proper conduct (PoPC) for ONC-Authorized Certification Bodies (ONC-ACBs).
2. Records retention provision includes the “life of the edition” and after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules.
3. ONC-ACBs can accept test results from any ONC-ATL that is in good standing under the program and is compliant with its ISO 17025 accreditation requirements.

The proposal also includes several other clarifications and notes including broadening the scope beyond the CMS Promoting Interoperability Programs.

Change 4: Inclusion of Pediatrics Care and Opioid Abuse Provisions

ONC have identified existing 2015 edition criteria, as well as new and revised 2015 edition criteria proposed in this rule that could benefit providers of pediatric care and pediatric settings and have ten recommendations for the voluntary certification of health IT for Pediatric care. ONC also seeks public comments on existing Program requirements and the proposals in this rule may support use case 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.

Change 5: Maintenance of ONC Certifications

ONC proposed to establish 6 (+1 in the future) Conditions and Maintenance of Certification requirements for health IT developers to maintain their ONC Health IT certifications.

Condition 1 (Information Blocking): Health IT developer will not take any action that constitutes information blocking as defined by ONC in 170.401 and by section 3022(a) of the Public Health Service Act (PHSA). However, ONC also specifies 7 exceptions where information blocking is acceptable which are:

• • Preventing Harm: Information can be blocked if it will result in physical harm to an individual
  • EHI Privacy: Information can be blocked if it means violation HIPAA Privacy Controls or is for improper or self-interested purpose
  • EHI Security: Information can be blocked if it violates security practices or conflicts the Confidentiality, Integrity or availability of EHI
  • Recovery of Costs: An EHI provider/health IT developer can expect a reasonable fee for making EHI available (technology development etc.) if its non-discriminatory and related to costs of providing access, exchange, or use of EHI
  • Infeasible requests: Information can be blocked if it’d mean a substantial burden (actor size, available resources etc.) The actor must however respond to the request and work towards an alternate method
  • Protecting IP: An actor controlling technology or other interoperability elements that are necessary to enable access to EHI will not be information blocking so long as it licenses such elements on reasonable and non-discriminatory terms
  • Maintenance of Health IT: An actor may make health IT temporarily unavailable in order to perform maintenance or improvements activities, which must be time-bound and reasonable
  • Condition 2 (Assurances): Health IT developer must 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. This will include:
  • Compliance with the full scope of the certification criteria
  • Certification to the “Electronic Health Information (EHI) Export” Criterion
  • Records and information retention
  • Required Participation with Trusted Exchange Framework for certain certification modules (ONC has requested comments on this)

Condition 3 (Communications): Requires that Requires that a health IT developer does not prohibit or restrict communication regarding the Usability, Interoperability, Security, User Experience and Business Practices of the health IT. A health IT developer must not impose or enforce any contractual requirement or legal right that contravenes this Condition of Certification. 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.

Condition 4 (Application Programming Interfaces or APIs): Requires health IT developers to publish APIs and allow EHI (all elements of the USCDI) to be accessed, exchanged, and used without special effort. API Technology Supplier must Support the publication of "Service Base URLs" (i.e., FHIR server endpoints) for all its customers and make this information public.

Condition 5 (Real World Testing): Requires that health IT developers have successfully tested the real-world use of the technology in their respective market areas. Health IT developers must submit publicly available prospective annual real-world testing plans and retrospective annual real-world testing results.

Condition 6 (Attestations): A health IT developer must provide an attestation to compliance with all the Conditions and Maintenance of Certification every 6 months.

Future Condition 7 (EHR Reporting Criteria Submission): ONC hasn’t yet established an EHR reporting program and will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification subsequently.

Change 6: Standards Version Advancement Process

The Standards Version Advancement Process would permit health IT developer 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. This flexibility to choose among NC-approved versions of standards and implementation specifications would be available when developers seek initial certification or to maintain certification of a Heath IT Module.

Key Takeaways

Future Interoperability Framework: With this proposed rule ONC has attempted to set up a future framework for interoperability in health IT. With several provisions such as the use of API, participation in the Trusted Exchange Framework and penalties for information blocking, ONC is trying to ensure seamless interoperability across all healthcare devices in the future. This regulation will be the backbone for any health IT requirement proposed by CMS or any other agency.

FHIR gets ONC backing: The HL7 FHIR standard has been around for a while but lacked the regulatory push. While CMS alluded to FHIR in their own Quality Payment Program (QPP/MACRA) they stopped short of recommending it and allowed the developers to use any API of their choice. With this regulation ONC has officially adopted the FHIR standard as the base choice for certification API. This would eventually mean FHIR gaining widespread acceptance in line with HL7 v2 and CDA.

Common Clinical Data Sets are retired: The Common Clinical Data Set were a set of 20 mandatory and optional data fields and data standards which must constitute any clinical information document exported from Health IT. The CCDS requirement was first established through 2014 edition EHR (where it was called the common MU data set) and paved the way for standardizing information sharing. Now, ONC has included additional fields in this set – including Pediatric vitals, clinical notes and data provenance, and is now known as the U.S. Core Data for Interoperability (USCDI) v1. Additionally, ONC aims to update this standard annually, in line with the rapidly evolving tech and use cases.

Voluntary adoption is encouraged: ONC now encourages developers to self-adopt new standards as part of their Standards Version Advancement Process, where Health IT developers can choose to adopt any new standard without waiting for subsequent rulemaking.

Certifications are more dynamic: Earlier the certification process was static with ACB granting certification and Health IT maintaining that certification for their lifecycle. Now, even with ONC relaxing the randomized surveillance requirements, Health IT still must comply with new conditions to “keep on maintaining” their certification status or risk getting decertified. This keeps developers on their toes and ensures that ONC goals of information blocking and interoperability are always at the forefront of any product strategy. ONC also establishes a collaborative enforcement approach wherein they would like to work with the developers in case of any noncompliance and before taking any adverse actions.

A Health IT “Internet” is possible: With ONC establishing criteria for public publishing of FHIR APIs and service endpoints, along with the information on data structure and format used, the health IT devices would effectively be able to “see” each other and communicate in a controlled and secure way. This effectively means that clinical information can transgress geographical boundaries and devices can truly be “interoperable”. Additionally, ONC has also published a Request for Information (RFI) on how a standards-based API can improve information exchange with registries in support of public health reporting, quality reporting, and care quality improvement.