In a previous blog, I discussed how Apple is leveraging FHIR® as part of the Health App. The app allows users to download and view their healthcare data from connected healthcare organizations to their iPhone in FHIR format. The app also provides access to the actual FHIR data for other app developers to use in their own apps. While it is a great initiative by Apple to get healthcare consumer directly involved with FHIR®, there are some serious limitations in this approach:

•  The only way to add data is to import from the organizations that Apple has approved and integrated with. There is currently no way for a user directly or through another app to add new FHIR data. Even CMS Blue Button 2.0 is not currently integrated with the App.

• Apple is currently only supporting 8 resources, compared to over 100 resources that are currently available under FHIR.

• The app is available only on iPhone. There is no sync mechanism to share that data across other devices even within the Apple ecosystem like iPad or Mac.

• There is currently no way to manage records for multiple people. If you need to manage health records for your parents or your kids, you basically need to buy them each a separate iPhone. 

The FHIR module (referred to as “Health Records” by Apple) is one of the components in Apple’s Health App. In other words, Apple opened an API to store FHIR based records along with other data of the app. It still stores the rest of the healthcare data in other formats This basically means that app developers have to understand Apple’s HealthKit standards to work with that data. In my opinion, this is against the very spirit of “democratization of healthcare IT development” that FHIR strives for.

I am sure Apple is aware of these limitations and might already be working to address some of these in upcoming updates. However, I will like to discuss an approach that we have taken in our BlueButtonPRO App to address these limitations while trying to achieve the same end goal i.e. empowering healthcare consumer with access to their healthcare data.  

BlueButtonPRO Approach: Personal FHIR Record(PFR)  

Before discussing the actual implementation, let me describe the basic concept of a Personal FHIR Record (PFR) that we used as the basis for our implementation. A PFR is a FHIR server that manages the healthcare data for a single person. Just like an email address, a person has a FHIR address such as https://johnsmith.bluebuttonpro.com/fhir. The PFR works just like a regular FHIR server except that it validates all the incoming records to make sure that they belong to the person for whom the FHIR server was created. A single user may manage one or more PFRs. Similarly, a PFR might be managed by one or more users. To clarify, I can create an account and create a separate PFR for myself, for my parents and for my son. After my son turns 18, he can create his own account and migrate his PFR to his own account. This portability of PFR allows the data to follow the person, thus ensuring continuity of the record and putting the consumer truly in control of their data.  

Update: ONC has proposed a new certification criteria today that would require EHR vendors to support FHIR based APIs similar to PFR concept described above. Read more about the proposed rule here.

Implementing and managing a single FHIR server is not an easy task. To create FHIR servers on the fly and then manage all the security in a scalable way can be daunting. Healthcare consumers expect to have access data to their data for free. Although the theoretical concept sounds great, we had to come up with a cost-effective way to implement it. Leveraging the open source Microsoft FHIR Server code and a lot of support from the Microsoft FHIR server team, we were able to implement a fully working prototype in less than 4 weeks. Here is how it works.

Creating Personal FHIR Account 

After the users download the BlueButtonPRO app and sign in, they can create their first PFR by completing a simple form. In addition to the basic demographics, a user has to chose a domain (similar to a username for email) and relationship to the person that they are creating the PFR for (see attached screenshot). When the user clicks on the “Create Your Personal FHIR Account”, the app provisions a full working FHIR server based on the sub-domain selected by the user in under 30 seconds.  

How does it work behind the scenes ?

Glad you asked. As described in detail on Github, Microsoft FHIR Server uses Azure Cosmos DB as it’s data persistence layer. Azure Cosmos DB uses a concept of containers to store the actual data. When the user clicks on the create button above, BlueButtonPRO provisions a new container in the Azure Cosmos DB. The Azure Cosmos DB sits behind a load-balanced instance of the Microsoft FHIR Server. When a FHIR end point is hit, we extract the domain from the incoming URL to find the PHR that the user is trying to access. After validating that the user has access to that PHR, the FHIR instance redirects the request to that container. The data for a single user remains isolated to a unique container in the database which enables the portability of PFR that I described above. However, we are able to leverage a single instance of the FHIR server to support infinite PFRs. Microsoft  recently announced an update that allows all the containers in a Azure Cosmos DB database to share throughput. In other words, we are only paying for the underlying database usage and data transfer. This allows us to scale very easily to keep creating containers on the fly without much addition to the actual cost.  

But Wait, There’s More. The PFR works like any other FHIR server and allows the user to connect with any app that support FHIR. However, we wanted to make sure that the user can actually exchange data as simple as receiving an email while still maintaining the security of each account. Again, we were able to do this by modifying the open-source code to implement a process called DOPU (Drop Off/ Pick Up). Although each FHIR instance is secured by OAuth 2.0 and is controlled by the user, it does allow other users to “post” to the Bundle endpoint. A patient can share their PHR address (e.g. https://johnsmith.bluebuttonpro.com/fhir) with any provider. The provider can then post a copy of the patient record as a FHIR bundle to the endpoint (https://johnsmith.bluebuttonpro.com/fhir/bundle). The server detects that the user does not have access to the PFR and “Drops Off” the bundle in a shared area. The patient receives an alert and is able to import (“Pick Up”) the data into their own PHR. No exchange of certificates or complicated integration is required.

If you are developing FHIR-based patient-facing apps, contact us to get an early access to a developer account. If you are a provider or a research organization, contact us to learn how you could get your own FHIR server in under 60 minutes using Azure API  and start exchanging data with patients today. If you are at HIMSS and interested in seeing a live demo of the app, get in touch with us.