21st Century Cures Act and the Push for REST API Adoption

Summary

The 21st Century Cures Act aims to make health information more sharable among patients, providers, and payers. The recent move by the ONC to advance interoperability includes guidance and real-time compliance deadlines. This includes adoption of HL7® FHIR APIs as a standard to accelerate data exchange across healthcare.

FHIR API

Written by David Navarro, Senior Director of Data Science, Harmony Healthcare IT

In June of 2020, the 21st Century Cures Act (Cures Act) Final Rule became effective. One of the biggest changes, and challenges as a result of the Cures Act is that patients will be entitled to use patient-facing API enabled applications of their choice to download their health data into an application of their choice. An example of an API use is when patients utilize mobile personal health record apps with APIs to gather data from fitness trackers. Now that certified electronic health records (EHRs) are required to provide APIs, patients will be able to connect with these APIs to gather and share health information. For example, they may be able to use an API to electronically share diagnostic information – like blood pressure readings and blood sugar levels – with their doctor in real time.

The ONC outlines the real-world of steps of patients using APIs:

  1. The patient downloads a secure healthcare app and logs in with a username and password.
  2. The patient uses the application to create a secure link between the application and healthcare provider’s EHR.
  3. The application sends a request to the patient’s healthcare provider EHR asking for access to his/her medical records.
  4. The healthcare provider’s EHR validates the request coming through its API and sends the patient’s data back to the application.
  5. The patient accesses health information from the application and can merge this information with other health information from other sources. For example, the patient can gather information from various EHR portals to aggregate data in one place.

Health IT Considerations for APIs

From a healthcare provider’s standpoint, there are many new technologies that need to integrate to enable the true interoperability of health information to comply with the Cures Act requirements. The Final Rule promotes the implementation of HL7 Fast Healthcare Interoperability Resources Application Programming Interfaces (HL7 FHIR APIs), and specifically targets APIs that have the greatest impact on patient care.

To better understand HL7® FHIR® Representational State Transfer (REST) APIs, it is important to define a few key terms:

API Application Programming Interface: A set of rules that allows programs to talk to each other. The developer creates the API on the server and allows the client to talk to it. APIs are increasingly important in healthcare data exchange for data analytics, medical research or creating ways to access the EHR.

Some APIs are rigidly programmed which makes data exchange challenging. For example, a data field cannot accept both “1” and “one” as entries. The adoption of the API criteria was a move to align with industry efforts to promote interoperability through the implementation of API ‘read‘ services leveraging FHIR 4.1. The implementation of FHIR reduces efforts for data integration and makes the sharing of healthcare data easier through the open standard.

RESTRepresentational State Transfer: A set of rules, or an information exchange standard, that developers follow when they create the API. REST is a method of exchanging information using the World Wide Web standard transfer protocol HTTP (Hypertext Transfer Protocol).

HL7®: A framework (and related standards) for the exchange, integration, sharing and retrieval of electronic health information. These standards define how information is packaged and communicated from one party to another. HL7 standards are recognized as some of the most utilized healthcare standards in the world.

HL7 FHIR®: An interoperability standard intended to facilitate the exchange of healthcare information between organizations. It consists of content models in the form of data packages referred to as ‘resources’  which are deployed via web services and open web technologies.

HL7® FHIR® RESTful API: Putting it all together, HL7 FHIR uses REST as the basis for data exchange in its API. Healthcare data types such as medications, observations and patients are represented by their own Resources, which can be requested via a RESTful HTTP command to retrieve precise information. Using the FHIR API, each request would supply the data needed based on the search terms. By using REST architecture, FHIR takes the best of existing health information technology and common internet standards to create a modern method of interoperability.

Where should I begin with HL7 FHIR RESTful API?

First, familiarize yourself with the FHIR specification. FHIR has created the FHIR US Core Implementation Guide which defines a minimum set of constraints on existing FHIR resources. The guide applies to data defined in United States Core Data for Interoperability (USCDI) V1 and provides overall guidance on how to use the defined profiles and transactions. It includes 35 defined resources and numerous examples of implemented transactions in JSON and XML formats.

One important point is to keep all systems current and patched. Security issues, while already top of mind, need even more of a focus as there are more data streams going in and out of the organization. It also is imperative to restrict access from the FHIR gateways by allowing communication to only the minimum necessary ports and protocols to accomplish this task.

What are the relevant timelines for Final Act certification?

  • December 15, 2021 – Real world vendor testing plans demonstrating interoperability and functionality were due to the ONC.
  • April 1, 2022 – First attestation of conditions of certification required.
  • December 31, 2022 – New HL7 FHIR API capability must be made available.

What implementation approach should I use?

All FHIR strategies should be comprised of a gateway to expose FHIR endpoints to external systems. A gateway solution should include support for transaction validation and auditing and include the ability to incorporate authentication and authorization services. For organizations that store data as native FHIR objects, the move to conform to a FHIR data sharing model is most likely part of an existing FHIR gateway solution. Organizations that store data outside of a native FHIR repository have the choice to implement a ‘FHIR as a Façade’ solution or ‘FHIR data aggregation’ model.

In a ‘FHIR as a Façade’ model, a gateway would receive native FHIR API calls and transform the requests into a database call such as SQL. The data returned by the call would be formatted into the FHIR response by the gateway before returning it to the requesting application. This model relies on a suite of tools implemented on the FHIR gateway that enable the mapping of data to and from the FHIR standard.

In a FHIR data aggregation model, programming routines are needed to extract and format data from an existing repository. This data is formatted into FHIR standards and is then pushed to a native FHIR repository where it can be accessed via a FHIR gateway.

All FHIR implementation models require technical planning and an ample amount of time to complete testing. Most organizations will need to invest in upgrading their current platforms or implementing additional modules to implement HL7 FHIR. Organizations should not delay in their design, development and testing in a solution that makes their data interoperable.

Ensure your organization doesn’t end up (unintentionally) blocking information

Media reports say the ONC has received 249 valid information blocking claims submitted through its reporting portal since the regulation took effect in April of 2021. About two-thirds of those issues involve patient complaints of excessive charges or delays in obtaining information. Provider complaints include EHR vendors failing to assist with migrating data to a replacement system. The ONC in a recent blog describes that participants who engage in information blocking practices may face penalties as well as notices of non-conformity which could include certification terminations and bans.

What is Harmony Healthcare IT doing to assist organizations with API data integration?

Legacy data plays an important role in the safety and care of patients. Harmony Healthcare IT is committed to ensuring our legacy data solutions align with interoperability practices defined in the 21st Century Cures Act. Our goal is to provide legacy data in a consumable format that aligns with CCDA and FHIR standards harmonizing technology with the patient care experience.

As a data management firm that moves and stores patient, employee and business records for healthcare organizations, Harmony Healthcare IT can help your team address its lifecycle data management strategy and implementation plans. Whether you are preparing active or legacy patient records for interoperability, our team of data experts may be called upon to assist with the development of your strategy and contemplation of how legacy data will play a role.


Harmony Healthcare IT has blogged about key impacts of the Cures Act as there are major shifts and considerations for those Information Technology (IT), Health Information Management (HIM), Legal, Revenue Cycle, and other provider teams involved in making sure their organizations are compliant. Those recently published blogs include The 2022 ONC Annual Meeting Recap and Understanding TEFCA and its Role in National Interoperability.


As Senior Director of Data Science at Harmony Healthcare IT, David Navarro drives interoperability initiatives and focuses on the curation and accessibility of data in the healthcare ecosystem.

Mar 30 2022

Ready to learn more?

Contact us today to learn more about our healthcare data management solutions.

First Name *
Last Name *
Email *

Healthcare IT tips, guides, news & more delivered to your inbox

Sign me up