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