FHIR API: Should I Use Azure or Google?

Page Contents

Attention: The following article was published over 2 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

Data interoperability is one of the hardest problems in Healthcare IT. The most popular approach is to exchange HL7v2 messages between systems. These pipe-delimited messages are difficult to read by a human and often need additional customizations between implementations.

The next major paradigm shift is towards FHIR (Fast Healthcare Interoperability Resources), a JSON-based standard that is evolving ahead of the needs of the industry. Cloud vendors like Microsoft, Amazon, and Google are trying to lay their claim to be the one-stop shop for healthcare on the cloud.

This blog is part of a 4 part series diving into an actual use case I recently encountered while working with a client. I had to stand up an FHIR repository/API for 2+ million patients that could be used by hundreds of users every day, as well as countless background processes.

In this first part, we’ll talk about the background of this project. We’ll also discuss two major offerings, Google and Azure. I’ll walk you through the pros and cons and will finish by explaining our decision.

Motivation

We currently store all of our patients and the corresponding documentation in an on-prem Microsoft SQL Server instance. We have bespoke APIs on top of it, as well as a suite of SSIS jobs to provide a comprehensive data warehouse outside of our operational database. This allows us to satisfy various use cases and offer up APIs that can be called on demand, as well as the data warehouse for a SQL view of our data.

As of now, we currently lack the ability to provide this data in a standards-friendly manner. The patient concept in our application is ad hoc and doesn’t conform to any well-documented standards that other groups might already have support for via common integration engines.

Furthermore, our application doesn’t have an easy way to support an event stream when the data for patients or their documents change. The current approach does not allow the ability to do a fuzzy, free-text search over all of the data in the application and quickly retrieve a list of search results.

The type of data stored in the application ranges from common population health use cases (e.g. notes, med recs, assessments) to types of data more sensitive and confidential (e.g. SAMSHA, HIV status). Any solution that we’d use to address these limitations needs to offer the ability to provision the type of data that the requestor has access to.

Candidates

The two options available to use (i.e. cloud vendors that the client has BAAs signed with) are the Azure and GCP FHIR Repository APIs. Though both of these vendors offer essentially the same thing, there are drastic differences in terms of setup, features, and cost. Let’s discuss both options.

Azure API for FHIR

The Azure FHIR API is a hosted solution for an FHIR repository. There doesn’t appear to be a way to configure ACL (access control lists) or any analogous offering that can restrict specific types of data based on what role the currently logged-in user can/should see. There is the potential to copy the data from the FHIR repository so that SQL queries, as well as an event stream, are created via Azure Synapse Analytics.

The lack of native access controls would require an intermediary API that clients call, which then calls the Azure API for FHIR on the client’s behalf, evaluates the response, removes any data that the client should not see, and returns the mutated response. This overhead is not ideal, especially at scale. Additionally, the tool that’s used to stream the data to Synapse (FHIR to Synapse Sync Agent) is not covered by the SLA for Azure services. For these reasons, we chose to not implement our solution with Azure API for FHIR.

GCP FHIR Cloud Healthcare API

GCP also offers a hosted solution for a FHIR repository. On top of everything Azure’s offering brings, it has native support for BigQuery and Pub/Sub. BigQuery allows for free text searches and SQL-like querying. Pub/Sub allows subscribers to receive events when the underlying data changes, allowing them to develop a NRT (Near Real Time) solution.

The benefits of using the Cloud Healthcare API make it the clear choice to use for this particular use case. One implication of this choice is a slightly higher barrier to entry than its competitor. The Azure API for FHIR can be created within a matter of minutes from a single page of documentation whereas the GCP FHIR Cloud Healthcare API takes much longer and requires reviewing multiple pieces of documentation. This initial hurdle is not a significant impediment for use, only a consideration to take into account.

Prior to using an IaC (Infrastructure as Code) deployment, it’s important to first run through the creation of the cloud resource manually. This allows the DevSecOps team the opportunity to thoroughly understand all of the options that can be selected when creating the resource and develop a mental model for how all of the pieces come together to support the solution.

Wrapping Up

Perhaps it goes without saying, but we chose to take advantage of GCP FHIR Cloud Healthcare API, so that’s what we’ll be focussing on for the remainder of this blog series.

Next time, we will begin walking through the actual implementation, creating the Cloud Healthcare API from the GCP Console. I’ll take a very hands-on approach, talking you through all the steps it takes in detail.

See you soon!