Healthcare APIs and Release of Information

Bi-directional APIs give healthcare providers maximum data visibility and control. Here’s how they’re shaping the future of release of information.

In recent years, a fire has been lit under healthcare’s use of application programming interfaces (APIs). Actually, it has been a FHIR [Fast Healthcare Interoperability Resources] as regulations encourage electronic medical record (EMR) vendors to continue to build its standards into their systems, expanding functionality and improving usability. But that does not mean the road to digitization and interoperability has been seamless, particularly as it relates to release of information (ROI).

For a range of requestors and providers, getting access to information continues to require solving challenges like standardization, efficiency, and security. To keep up with increasing requests, providers in value-based care contracts with health plans are faced with the choice of either allowing the health plans to have on-demand access to data or ramping up staff to handle the additional volume. The downside to existing one-way retrieval tools designed by requestors is that providers surrender a level of transparency and control over their patients’ information.

Enabling bi-directional APIs is one way to offer speed, efficiency and security while preserving the most necessary components of human intervention. These closed-loop data retrieval processes will shape the future of ROI in healthcare for higher quality and faster intake and fulfillment.

Paper, lingering technologies meet APIs

The release of information environment in healthcare has been overwhelmingly manual in nature over the past three to four decades. ROI involves many people processing scores of paper charts—now mixed with digital—that require facsimile transmission, image scanning processes, and access to various systems warehouses and storage facilities. Archives retrieval is messy, especially as providers and requestors integrate digital records from disparate systems.

APIs provide the simple function of enabling different applications to “talk” to each other over the internet. This method of communication is a welcome addition to HL7 type interfaces and other types of legacy system connections that require custom-built interfaces and dozens of hours to build. APIs are becoming widespread in the healthcare environment at the ideal time: the amount of data that’s been requested by various entities—including researchers, health plans, auditors, and clinicians—is increasing at a significant rate. It’s become a top priority for all stakeholders to get access to data very quickly while also maintaining security. As demands for visibility, transparency and control over ROI in healthcare expands, APIs are offering the means to safeguard the required data and track its path to requestors in a seamless, fast, and sustainable way.

EMRs: the source of truth using bidirectional APIs

As EMR vendors integrate FHIR standards into their solutions, APIs can enable retrieval of specific data sets. Take, for example, a health plan that requires a specific request with 20 different data elements. On the EMR side, we have access to populated data sets and can call one data set that has 10 data elements with one API for retrieval, and use another API for an additional box of data. Neither we nor the provider is required to do any customization from a configuration standpoint. Furthermore, the provider has the trust and confidence in the defined process we have established with the EMR vendor to know the solution was not created in a vacuum; the API is vetted and approved by the vendor after configuration through their specific protocols and build requirements.

The increase in data demands have forced many health plans to either partner or build a record retrieval tool.  While these retrieval tools are efficient, providers must understand the implications of enabling one-way data pulls via their EMR or behind a firewall. By agreeing to installation, the provider has relinquished control to the requestor with on-demand access to the data and limited visibility of what’s being pulled or by whom. Bi-directional APIs, like those used by Ciox, not only retrieve data from the EMRs, but also update the EMR with authorization & request letters in real time so that the EMR is always the source of truth. This closed-loop data retrieval process affords providers an increased level of control than is currently common in the ROI industry, enabling automation to deliver visibility and trust to the request and retrieve processes.

This ROI process using bidirectional APIs significantly reduces the administrative burdens on providers. Commonplace methods requiring frequent purchasing and procuring of new EMR logins among various resources in the ROI environment are tedious and threaten overall data security. Information retrieval methods that rely on the health plan’s customized solution, again, take data control out of the hands of the provider. If the data is funneled through our bidirectional API, the provider and requestor maintain complete visibility on the requesting of EMR data and receives benefits of real-time status updates, too.

Data demands are increasing across multiple departments in the health system – from HIM to Managed Care to IT – and sometimes technologies are implemented without all groups having visibility or input to the solution.  A solution that works well for a managed care contract might not make sense for Release of Information, and vice versa. At Ciox, we believe there’s a more effective solution: one bidirectional API for all requestors and providers. Innovation in healthcare’s request for information sector is critical, highlighting the need for security, speed, and control in one manageable solution.


Learn how APIs mitigate risks and address staffing woes in this blog post from Terese Masterson.


This blog originally appeared in Healthcare IT Today.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.