27 May, 2022 | 3 min read

FHIR and Interoperability in Digital Health Care - Part 2

  • Mifan Careem
  • Vice President - Global Head of Solution Architecture - WSO2

Photo by Anna Shvets on Pexels

First published on The New Stack.

In our previous article, we highlighted the need for health care organizations to modernize their offerings, introduced health care integration platforms and examined challenges associated with keeping data in the hands of patients outside organizational boundaries.

This post will discuss how APIs help health care organizations transform their offerings, bring in consent management, address security and implement best practices.

API Management Solutions

Organizations invest in API management solutions for many reasons, like to develop new partnerships, to abstract backend systems so that health care companies can modernize much faster and to expose intellectual property to external parties.

Another core reason is that API gateways enable best practices. API management provides security models, quality of service and control over what should be exposed when and where. This segregation allows business teams to rapidly innovate by building consumer-facing services and apps or by encouraging external stakeholders to participate.

Figure 1: API integration platforms enable information sharing across providers.

In Figure 1, the provider organization has an API management system or an API gateway. Consisting of integration capabilities, this layer connects to, transforms and consolidates data from multiple systems of records, such as electronic health record (EHR) systems. The payor also has an API gateway, which abstracts information from systems of record such as claim management systems.

Information that is shared by these custodians of data are made available to internal applications such as member portals, or external applications, and users such as third-party app developers. The data via these APIs are now part of the wider digital health care supply chain. 

Network Effects

One added advantage of API platforms is that they provide network effects. This is a mechanism that exposes information so that multiple parties can consume data. These parties can then expose it to their users, creating a platform network effect. This compounds information availability across the network, creating a network of value.

Figure 2 shows an example of an API platform deployed at a customer, and it showcases CMS Patient Access APIs in Fast Healthcare Interoperability Resources (FHIR) format. These are public APIs, and application developers as well as other payor and provider organizations can consume these APIs to build applications that better serve patients.

Figure 2: Example of an API platform

Figure 3 now shows the explosion of consumers due to the availability of information via APIs from the custodians of the data (the payors and providers who are exposing data).

Figure 3: Introducing APIs to the health care supply chain results in more consumers and apps

At this level, the health care provider has exposed APIs, and the company can build its own applications like telemedicine or virtual care, which can then be consumed by its patients, or it can expose these APIs in a selective manner to third-party aggregators as part of an aggregator network. These aggregators can serve their set of patients or general patients as well. In short, the digital supply chain keeps evolving, increasing, and adding links and nodes with the help of various technologies.

Digital Supply Chain Security

While networks of value bring immense potential, they also introduce risk. Supply chains are only as strong as its weakest link. That means health care providers must overcome vulnerabilities, both within and outside their network.

The past two years have seen several security concerns at different levels in the health care security space. A white paper from Alissa Knight of Knight Ink, LLC, found that health care FHIR APIs are subject to vulnerabilities with the implementation of apps and by third-party FHIR aggregators.

If data resides in EHRs, it is secure but doesn’t facilitate modernization. For true innovation and modernization, data must leave backend systems and go into the hands of consumers so that companies can start building creative applications out of it.

That means organizations need to have the right controls in place. Simply put, it needs to get the data out of the EHRs and into applications, aggregators and other providers. But that means there could be vulnerabilities at different levels.

Best Practices

Getting into the data in an EHR is not as easy as getting to the data at an aggregator. Additionally, if the aggregator stores the data, that may open up a different can of worms. Luckily there are tools and best practices to avoid this. Open Web Application Security Project (OWASP) principles talk about security best practices. OpenID Connect and Substitutable Medical Applications and Reusable Technologies (SMART) on FHIR® give best practices for applications. API gateways themselves perform rate limiting, throttling, quality of service and API security mechanisms. Organizations can have peace of mind knowing that security best practices exist for data at rest and data in motion.

Consent Management

There are multiple security best practices that need to be followed, as with any digital supply chain. It’s not just about keeping data in one place. It’s about moving data, which means companies need to have controls in place and required consent management. This deals with the ownership of data and the ability to provide permission to use that data. This is a long-forgotten concept of health care because the real data ownership is with the patient, even though the health care provider might be the custodian of such data. Consumers of data should only do so with explicit consent from the owner, the patient.

Therefore, we can add a consent management layer, as shown in Figure 4.

Figure 4: Consent management documents permission to use data across stakeholders.

When data is moving from a provider into an aggregator, a user or patient must provide consent for that. Similarly, if the data is moving from the aggregator to the patient, the user must provide consent for this. If data is moving from a health record system to a provider, a payer or an application, the patient must provide consent for these too. Consent can be at a granular level. For instance, the patient may simply give access to use his/her first name and last name.

We hope this post helps readers to understand more about FHIR and interoperability in the digital health care supply chain and how this enables health care providers to develop customer-centric solutions. To learn more, please visit our solution page on