How to Prepare for the API Requirements of the Cures Act
FHIR APIs expand realm of clinical queries
As of April 5, 2021, the U.S. ONC Cures Act Final Rule Compliance Timeframe is in effect. Healthcare providers, Health IT developers, Health Information Exchanges (HIEs), and Health Information Networks (HINs) will have until October 6, 2022, to provide patients with access to all their Electronic Health Information (EHI). There are several requirements that providers, developers, and exchanges must adhere to. Among them are Conditions and Maintenance of Certification requirements for Information Blocking, Communications, and Application Programming Interfaces (APIs).
To help you navigate this compliance timeframe, we've asked our J P System's HL7 FHIR® expert, Jay Lyle, what does one need to know about APIs and data standards. Jay has been co-chair of the HL7 Patient Care Work Group for 8 years and is an expert in HL7 data standards development and APIs.
Question: What are HL7 data standards and why are they so important?
Answer - Jay Lyle: Data standards allow healthcare providers to share important clinical information with each other. If we all used the exact same data formats for patient records, we wouldn't need a message standard to transmit clinical data, but we live in a world that uses many different Electronic Health records systems, therefore we need standards to communicate with people outside our health systems.
If you need a lab test, prescription, or an x-ray, your general practitioner needs to communicate with other providers whose systems probably don't look the same. Data standards allow a patient's local provider or general practitioner to expand the kind of services they can offer by coordinating with other service providers. This is in addition to more obvious things like allowing a patient to see another provider in another state or hospital.
Q: What are APIs, and how are they connected to data standards?
Jay Lyle: When you (the client) use an application on your device, the application connects to the Internet and sends a query to a server. The server then retrieves that data, interprets it, performs the necessary actions and sends a response back to your device. The application then interprets that data and presents you with the information you wanted in a readable way.
APIs are a type of computer specification that documents how to access data components via a public interface, thus giving anyone who uses them a viewing window into a particular set of data files on a server. If you and I both write software (an app), and my program needs a few pieces of data from yours, we could together design a list of data fields (and their expected contents) for a query of the data. However, if a lot of people need something from your app, you might not be able to sit down with all of them and design a unique list of possible field contents for what they want. You would instead document a general set of procedures for getting needed data and publish it where your business partners can see it.
That interface documentation, and the procedures it describes, are the Application Program Interface (API). Therefore, the documentation an APIs' interface description provides is a way for anyone to get information out of your app and publish it so that people can get whatever they need, whenever they need it.
If you write and publish an API, you've basically written a standard interface to your software; everyone can talk to your software program (app) in the same way. If you align your API with an existing standard, like HL7 FHIR, then you suddenly have a great deal more potential computing power at your disposal. Now other people can leverage your applications' capabilities in their application. So, if you adopt FHIR as a communal standard for an API, that allows your app to communicate with any other app that has a similar alignment with FHIR.
Q: The Cures Act requires providers to comply with ONC criteria starting April 5, which includes abiding by API requirements. How can providers and developers prepare?
Jay Lyle: Providers shouldn't have to make any technical or design decisions about FHIR or APIs. Their vendors and software developers and partners should be the ones doing that. However, providers do need to be educated about what the API requirements are so that they can adopt the right contract language. When they purchase software or hire a vendor, they need to be able to verify that the vendor is in compliance with this new legislation. Any contract engagement should stipulate that the vendor or contractor support the requirements as specified by the Cures Act.
Note: Some API requirements include:
- Health IT developers are required to publish APIs that allow providers and patients to exchange or access health information within Electronic Health Records systems (EHRs) through those APIs while abiding by HIPAA and other privacy laws.
- CMS-regulated payers must implement and maintain a secure API that allows patients to easily access their claims and encounter information, including costs, as well as a defined subset of their information through third-party applications of their choice. They must make provider directory information available through a standards-based API.
To review these and other Cures Act Requirements, visit ONC's site or read the regulations in the Federal registrar.
Q: How can providers and developers prepare for other Cures Act requirements?
Jay Lyle: Providers, health networks, and developers should keep in mind that:
- Information blocking is prohibited. Hospitals and patients must have access to their clinical data.
- A data standard will be required to make data accessible.
- Some applications are not in compliance with HIPAA. They should learn which ones aren't and understand the risks of using them.
The Cures Act directs ONC to establish guidance. The main way to establish guidance is through a trust exchange, which subscribes to rules (and thus standards) that organizations and networks agree upon.
Providers need to understand how they can influence both the ONC Cures Act requirements to meet their needs and the Trust Exchange stakeholders to recognize requirements and establish standards and guidance to meet their needs. Informed input from the clinical community is imperative to maturing the Cures Act correctly so that it's useful, safe, and effective.
This post was originally published in the JPSys blog. It is reprinted by Open Health News with permission. The original post can be found here.
- Tags:
- Application Programming Interfaces (APIs)
- clinical data
- clinical queries
- Conditions and Maintenance of Certification requirements Information Blocking
- Cures Act
- data interoperability
- data standards
- electronic health information (EHI)
- electronic medical records (EMRs)
- Fast Health Interoperability Resources (FHIR)
- FHIR APIs
- health information exchanges (HIEs)
- Health Information Networks (HINs)
- Health IT
- Health IT developers
- healthcare providers
- HIPAA compliance
- HL7 data standards
- HL7 data standards development
- HL7 FHIR
- HL7 Patient Care Work Group
- HL7 standards
- information blocking
- Information blocking is prohibited
- interoperability
- J P Systems
- Jay Lyle
- JPSYS.com
- message standard to transmit clinical data
- ONC criteria
- ONC Cures Act Final Rule Compliance Timeframe
- patient centric
- patient records
- provider directory information
- standards-based API
- Trust Exchange
- Login to post comments