BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Transforming the Healthcare Industry through API Marketplaces

Transforming the Healthcare Industry through API Marketplaces

Leia em Português

Bookmarks

Key Takeaways

  • The healthcare industry collects a huge amount of data related to personal health, but the collected data sit in silos, which are hard to use for everyone’s benefit. 
  • Data privacy is a major concern when sharing health information across a wide audience. Enforcing proper security measures across the board is essential in any platform built around health information. 
  • Building a platform which connects all the stakeholders within the healthcare industry improves the efficiency of the entire care process. Events which connect different stakeholders play a major role in building an effective healthcare marketplace. 
  • Patient-centric APIs are essential to improving the mortality of the human race. The existing raw data which reside in EHR/EMR systems needs to be transformed and aggregated into more patient-centric APIs which will help modern application developers build innovative healthcare products and applications. 
  • Selecting a technology partner for building an effective healthcare platform is a task which needs a lot of understanding and attention to detail. There are many technology vendors who can support the requirements of a healthcare marketplace, and the final choice should be based on an individual organization’s technical, financial and cultural alignments.

Why does healthcare need API marketplaces?

The healthcare industry is one of the pioneers in technology adoption. This has brought its stakeholders closer to the data, thereby allowing a faster decision-making process and creating a gradual improvement in life expectancy and population health. It is becoming evident that the quality and availability of data plays a major role in building a transparent, patient-centric healthcare industry. According to the Stanford Medicine 2017 Health Trends Report, the amount of data captured in the healthcare industry has grown significantly over the past decade. This is due to many reasons such as governments taking policy initiatives like “meaningful use”, wide availability of electronic medical record (EMR) platforms, digitization of medical records directly from devices (X-Ray, MRI, CT, etc.), and ubiquitousness of personal health/fitness monitors (Fitbit, Apple Watch, etc.).

A key problem in the healthcare industry is that valuable data points are hidden and siloed. Although these data points are generated by the population, they are either not accessible by the population or haven’t been put forth to use for the benefit of the population in an effective manner. Individual providers and healthcare institutions are the custodians of this data today and it is sitting in databases with few employed use cases.

This article discusses the use of API marketplaces as a solution for this problem. Through an API marketplace, we can expose these data points securely and make them accessible by healthcare industry stakeholders and citizens alike, improving efficiency in the industry and enabling innovation in population health technologies.  

The problem of too much data

Having an overwhelming amount of data is a good problem. In many cases, industries suffer from a lack of data points for any meaningful analysis. The healthcare industry is ahead of the curve in that sense. Today, many providers and healthcare institutions around the world record, summarize and make decisions with patient data. This data often resides in one or more EMR systems, depending on how big the care organization is, and is often siloed within that institution, or worse, within an application. We don’t see any general availability of this data in any consumable form. If we try to unpack this problem statement bit more, we can see a couple of related issues. First, health applications and institutions do not prioritize data sharing beyond its known scope. Second, population health data as-is is not consumable.

Looking at the healthcare application landscape, we see a high level of specialization, such as the domain-specific EMR platforms used in provider institutions for cancer care, diabetics, cardiology, or pediatrics. For this reason, a consolidated, patient-centric view is of great importance.

The issue of not being able to share data as-is is largely a result of protective public policies. Because of valid privacy concerns, a majority of countries have policy directives (such as HIPAA) to protect personally identifiable health records. Hence, raw data from the EMRs cannot and should not be exposed. Unintentionally, this has lead to healthcare data being jailed within healthcare organizations and specialized healthcare applications.

A positive indicator today is that modern EMR platforms are API-driven, adhering to healthcare industry standards like HL7 and FHIR when exposing clinical data. Although these initiatives standardize data access, they do not address the problem of data availability for open access. 

Another opportunity that’s been mostly overlooked is the potential of crowdsourcing in the healthcare industry. We don’t see many healthcare startups focusing on population health because the barrier to entry is high, or more importantly, the barrier for data access is too steep. If health data is more democratized and exposed in a consumable fashion, that will lead to widespread innovation benefiting all stakeholders of the industry.     

API marketplaces as a solution

APIs are seen as the digital connectors in today’s platform-centric business world. Organizations across industries have an API-first systems development approach, and we see this in healthcare too. Standards such as FHIR are embraced in almost all data-centric clinical platforms for data access. However, the key missing piece is the availability of API marketplaces and the API gateway-based ecosystem around them. An API marketplace specifically solves the discoverability problem of health data, and it will socialize the APIs with stakeholders, empowering them to innovate. A marketplace will encourage health organizations to think about how they can expose and organize their custodian data, making health data available through open API initiatives.

In a practical sense, a healthcare API marketplace primarily will connect healthcare data consumers with the producers. The vision of this solution is to have a multi-marketplace-based, healthcare exchanges-driven economy. The solution also discusses a comprehensive API management platform that fuels the marketplace concept. That platform enables provider organizations to design, publish, and manage APIs, while enforcing security, applying governance and harvesting analytics.  

The solution specifically highlights the API management capabilities as it can address some of the issues around healthcare data. Capabilities like data entitlement at a gateway can provide assurances to provider organizations that their data are securely transferred for the consumer with the correct scope. These capabilities are discussed at length at healthcare API types providing better context.

Figure 1: Solution Architecture

 

Elaborating the solution, we can look at the stakeholders of healthcare IT domain. There are engineers and business leaders owning platforms that standardize and govern data access channels. There are stakeholders that produce data needing to be published, so they reach an interested party. There are stakeholders who build value channels for an end user; these stakeholders aggregate multiple data feeds and create value-based product offerings. Then there are end users who consume the data feeds and arrive at conclusions or make decisions.

Stakeholders of the API marketplace

Figure 2: Stakeholder analysis

 

API Producers encapsulate designers, architects, healthcare product developers and API testers who design, develop, expose and test healthcare APIs. This group is responsible in defining the API scope (Internal, external, restrictions & entitlements). In a large healthcare API exchange, the producers can be from different healthcare organizations.

The Platform Owners keep the lights-on in an API marketplace. They maintain the components and facilitate collaboration between API consumers and provide consumer feedback to API providers. They take up the tasks such as platform evangelism, platform support and community building around the API exchange.

API Consumers are the application development community. They are the innovators who are willing to make use of healthcare data and derive value out of it. These can be population health-driven initiatives, healthcare startups, care organizations, hospital groups and governments who are keen on improving the multi-faceted healthcare landscape.

Components of a healthcare API marketplace

There are three aspects for a successful healthcare API marketplace:

  1. API management
  2. The developer portal
  3. Activities

Figure 3: Components of Healthcare API marketplace

 

API Management is the nuts and bolts of the platform and addresses cross-cutting architectural concerns. It encapsulates the runtime (the gateway), the security layer, the governance layer, the analytics layer and the consent management layer.

The API gateway runtime acts as the entry point for the platform which eventually connects with the actual data backend EHR systems. It seamlessly integrates with the security layer, providing token-based security and policy-based entitlement.

Given the sensitive nature of the data exposed through these APIs, it is crucial that the API marketplace provide strong governance over the API development, publishing, and maintenance life cycle. Controlling the operational characteristics of how the APIs are exposed, the person-driven governance models, policy management, and dependency analysis are maintained through API governance layer.

After developers publish the APIs, they should have the capability to monitor, measure, and manage the published APIs. This functionality is provided by the API analytics component. In addition to batch-based analytics, this layer can create alerts on scenarios such as failures in API invocations, a sudden increase in response times, or a change in the pattern of API resource access.

The consent management layer implements workflows that make sure necessary consents are in place for data sharing, storage and consumption. This is policy-driven, and at times relies on either machine-based decisions or human involvement.

The Developer portal advertises the APIs for consumption. It enables all interested parties to discover available data streams and learn how to consume them. The developer portal addresses the health data visibility problem of healthcare platforms. All specialized healthcare systems can index the APIs in a central developer portal maintained by the provider organization, a hospital, or a public healthcare exchange.    

Building a great API marketplace with technical components is only a part of the overall process. Towards building a successful healthcare API market, the platform owners can engage in activities like the following: 

  • Workshops - Workshops provide an educational platform for the API consumer, and can address some of the concerns for getting started. Topics should include: How to consume data within healthcare regulatory boundaries? What are the security protocols and policies to employ? How does consent management work?
  • Incentivized hackathons - One of the main objectives of building a marketplace is to enable innovation in the healthcare domain. Incentivized hackathons are considered a nudge in this direction. The platform owners can host hackathons and enable idea generation via health data.
  • Evangelization - Internal and external evangelism to make the platform popular.
  • Leaderboards and analytics dashboards - Showcase the innovative projects, startup products and provide visibility to API usage patterns.

Healthcare API products

The APIs in a marketplace can be categorized as products based on their consumption patterns. In the healthcare domain, common patterns include patient registration, scheduling, finances & billing, insurance, clinical, ancillary, public health, and IOT.

Registration API product

Registration APIs manage the registration functions involved with EMR systems. By means of these registration APIs, developers will get an opportunity to develop interfaces which integrate with different EMR systems to manage patient-specific data exchanges. Authentication and authorization are key requirements of these APIs since they provide the entry to all the subsequent activities related to consumer data. The API management layer in the API marketplace can provide key security constructs for these API activities.  

Scheduling API product

Schedule an appointment, deliver appointment reminder alerts, check open slots for appointments, update, cancel, or reschedule appointments are some of the functionalities of the scheduling API product. Scheduling is one of the heavily used functionalities within a healthcare marketplace, and integrates with various systems including billing, messaging, and notifications. The API gateway runtime, along with an integration layer, can provide the required bridging between these systems for a hassle-free scheduling experience for the patient.

Financial API product

The financial APIs will manage the money transactions between the care provider organizations and the respective parties. These financial APIs can be further narrowed down as billing APIs, claims APIs, etc. Health insurance plays an important part in the financial sector of the healthcare industry. Claim management systems facilitate checking the claim status, scrubbing and adjudication, as well as automated payment posting. This claim management system exposed APIs give the ability to connect the payers to the partner systems. Security is one of the critical requirements for these APIs, where strong authentication and authorization is highlighted. Having a proper API management platform which can interact with external identity providers (IdPs) is required to support some of these requirements.

Clinical API product

Clinical APIs will manage clinical data exchange through EHR/EMR systems via different standards such as HL7v2, HL7v3, and FHIR. A mature API platform has capabilities for data format transformations, so that it can connect to multiple systems and provide data feeds as requested by the consumer. These systems include data streams such as patient medication data, treatment plans, immunization details, and family medical history. The physician uses this data to make decisions on the patient’s health. Through API-driven, patient-centric applications, patients can view their medication, diagnosis and medical history. This encourages patients to be more involved in their personal health diagnosis which is also in line with public healthcare policies like “meaningful use”.

Ancillary API product

Ancillary APIs manage the information related to systems which are separate from core clinical functions, such as pharmacy, laboratory, radiology, etc. Some examples include communication with external pharmacies on medical prescriptions and refill requests, data exchange of laboratory results with different information systems, and managing dietary orders with external nutrition systems. Connecting with external systems via secure channels (B2B) is a critical requirement for these APIs. An API management system which supports various security protocols like OAuth2, SAML, OIDC will facilitate connecting securely with these third-party systems.

Public Health API product

Exchange of reportable clinical data to the public, federal, or professional registries to track public health is guided by public health APIs. These APIs enable the utilization of data needed for public health surveillance. Public health APIs provide clinical health data that are stored in electronic medical records (EMRs) to government and other research organizations and capture the data received from these agencies in order to enrich local clinical records. Both of these transactions are carried out under given standards to ensure the privacy of the health data. When providing such data streams, the API runtime can cleanse and de-identify the records so the streams are anonymized. That’s one of many utilities of a mature API runtime.

IoT/Activity trackers API product

In recent years, there has been exponential growth in wearable health/activity monitoring devices. These data streams unlock a new dimension in personal health monitoring. Exposing these stream through a consumable platform can accelerate innovation in patient-centric health applications.

Technology options

In the proposed solution we see systems integration and API management as two distinct implementation components requiring thoughtful analysis. An integration component should fulfill the task of integrating with different healthcare systems over disparate protocols and message formats. It then needs to convert and canonicalize the data providing a unified interface. The integration layer should clean and anonymize the data where necessary based on policies. There are multiple technology stacks and frameworks available to perform this task. Some of the leading open source products are  Apache Camel, Apache Synapse, Apache ServiceMix, Spring integration and Ballerina.

The API management component is a collection of features that are comprised of a high-performance gateway, a key server for authentication, an event processor for throttling and analytics, a developer portal for API listing, and a workflow engine for consent management.  Some popular open source products that encapsulate these features are WSO2 API Manager, Kong API Gateway and Tyk API Gateway.

Reference implementation

For a proof of concept, a reference implementation shows where each of these technology options can be used. It is biased towards open source platforms and frameworks as they provide great flexibility for customization for an evolving platform. 

Figure 4: Implementation architecture with technology selection

 

In this implementation, the API manager addresses the full API lifecycle management capabilities, including API implementation, management, monetization, securing and routing API traffic. The API request from the exposed API is then routed to the integration component through the API gateway.

The reference implementation takes into consideration the lifecycle of the API–once an API is published, the previous version must be deprecated, and the subscribers must be notified. The API management solution handles this through life cycle executors, so each API lifecycle stage can be associated with an action to be taken, as shown in Figure 5.

Figure 5: An example API lifecycle view

 

API security is also a primary consideration. While authentication and authorization are done through tokens, fine-grained entitlements are applied via OAuth token scopes. The scopes can be the validation of user groups, or a set of attributes about the healthcare data consumer, such as device, location, etc.

Figure 6: An example of applying entitlement OAuth scopes for API operations

 

The API platform can control how it exposes the data to the third party, allowing either unlimited access or restricted by a throttling policy. The throttling engine of the API management platform defines and enforces rules regarding the number of requests allowed and the rate at which data is consumed.

Figure 7: An example view of how throttling policies are applied to API subscriptions

 

The developer portal of the API management component provides a central hub where all APIs can be discovered, tried out and subscribed. The developer portal gives a platform for innovation. It documents what can be consumed from each of the APIs and how to consume that data. The developer portal categorizes the API products described in this article, allowing interested parties to subscribe to a product and integrate it into their application.

Figure 8: An example view of a developer portal with Patient/Provider FHIR APIs

 

API manager analytics provide a view of which APIs are accessed most frequently and how they are used, providing useful insights for multiple audiences. For platform maintainers, this can inform decisions regarding technical capacity planning. API consumers want to understand health data availability, and API providers can learn where to explore more on data acquisition.

Figure 9: An example Healthcare API analytics view

 

Once the API call delegates the request to the integration layer of the solution, a framework like Apache Synapse, Camel, Spring Integration or Ballerina can carry out the integration functionality. Once the request is received by the integration framework, it checks with a local registry entry to identify which EHR system the hospital belongs to. The values can be stored as a text string, XML code, or a URL. This can also be implemented as a file or a database lookup

Figure 10: System lookup from user attributes

 

Once checked with the local entry, the validation is carried out using a message filter construct to check if the hospital name is saved within the local registry entry. If no hospital is found, then a fault message is sent back to the API as an error message referring to the unavailability of the hospital.

Figure 11: Filter/Validation process

 

<inSequence>
<!--Obtain the value for the respected hospitalName parameter from the local registry-->
        <property expression="get-property($url:hospitalName)" name="ehrSystem" scope="default" type="STRING" xmlns:ns="http://org.apache.synapse/xsd"/>

<!--Check if the hospital-Name is located in the local registry entry-->
       <filter xpath="boolean(get-property('ehrSystem'))">
              <then>
              ...
	          </then>		 	 	 	
              <else>
                      <log description="Fault" level="custom" separator=",">
                               <property name="STATUS" value="Invoke fault "/>
                      </log>
                      <payloadFactory media-type="json">
                             <format>{ "Error":{      "errorType":"InvalidParameter","details":"The Hospital-Name parameter is invalid" } }
                             </format>
                             <args/>
                      </payloadFactory>
                      <property name="HTTP_SC" scope="axis2" type="STRING" value="400"/>
                      <respond/>
              </else>
     </filter>
</inSequence>

Code block 1: Hospital Name validation with Apache Synapse

 

The integration framework uses one or more connectors to access data from different EHR platforms, thereby allowing the user to interact with third-party health vendors such as Epic, Cerner, etc. Based on the EHR system, the integrator will determine where to route the request, calling either the Cerner connector or the Epic connector to fetch data from the respective EHR system.

Figure 12: Routing the request

 

The following synapse configuration (XML) is used to initialize the Epic and Cerner connectors and fetch the diagnostic report data.

<switch source="$ctx:ehrSystem">
<case regex="Cerner">
	<!--Initialize the Cerner Connector-->	 	 	
<cerner.init>
<base>https://fhir-open.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca</base>
</cerner.init>

<!--Search DiagnosticReport Operation→
<cerner.searchDiagnosticReport>
		<patient>{$ctx:patient}</patient>
<subject>{$ctx:subject}</subject>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
<count>{$ctx:count}</count>
</cerner.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<case regex="Epic">
<!--Initialize the Epic Connector--> 	 	 	
<epic.init>
		<base>https://open-ic.epic.com/FHIR/api/FHIR/DSTU2</base>
</epic.init>

<!--Search DiagnosticReport Operation→
<epic.searchDiagnosticReport>
		<id>{$ctx:id}</id>
<patient>{$ctx:patient}</patient>
<startDate>{$ctx:startDate}</startDate>
<endDate>{$ctx:endDate}</endDate>
</epic.searchDiagnosticReport>	 	 	 	
<respond/>
</case>
<default/>
</switch>
Code block 2: Routing to the respective EHR system with Apache Synapse

 

The response retrieved based on the EHR system is sent to the API as a response via the API Gateway.

Future Improvements

The reference implementation which we have discussed in the previous section considered a simple scenario to showcase the practical usage of a healthcare API marketplace. This implementation can be improved to support a wide range of requirements in the healthcare industry including:

  • Integrating with personal digital health devices
  • Connecting with third-party healthcare service providers
  • Building patient-centric mobile applications
  • Connecting with healthcare research institutes to provide valuable data

As health care services and technology evolves, healthcare API marketplaces will play a leading role in the digital healthcare industry.

About the Authors

Nuwan Bandara is a solutions architect working closely with Fortune 1000 global enterprises on integration and messaging software projects. He is a Director at WSO2 and is leading solutions engineering teams in North America. Nuwan has worked on interesting projects in healthcare, government, and financial industries in making systems integration simple. He is a programmer, a speaker, and author.

Chanaka Fernando is a solutions architect at WSO2. In his role, he works closely with enterprise customers across various domains like financial, education, healthcare, and telecommunication, to name a few. He worked as a technical lead and product lead in the integration platform team of WSO2 for the longest of his career.

Sachini Samson is a third-year software engineering student at Informatics Institute of Technology, Sri Lanka and currently undergoing the Software Engineering Internship at WSO2. Samson is the core developer of the reference implementation of the solution that has been discussed in this article.

 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT