Connecting Patients With FHIR® Based Clinical Data Registry

In the previous blog, I discussed how we are implementing a clinical data registry based on Azure API for FHIR®. As outlined in the blog, we are implementing multiple ways for the registry to accept data from various sources. In this blog, I will share how we will be enabling patients to share their data directly with a Azure API for FHIR® registry in a simple and very secure way.

Step 1: Implementing A Personal FHIR® Data Repository

Before a patient can share data, they need to have access to the data themselves and be able to control it. This data should preferably be in HL7® FHIR® format. Unfortunately, there aren’t many patient portals or PHRs that support FHIR® today. As we started working on the patient connect module, we needed a way to enable the patients to collect their data from multiple sources in a FHIR® format. To solve this, we created a concept of Personal FHIR® Record (PFR). We defined a PFR as a FHIR® server that manages the healthcare data for a single person. Just like an email address, we implemented a domain system for assigning FHIR® addresses to individuals - https://myhealth.bluebuttonpro.com/johnsmith.

The PFR works just like a regular FHIR® server except for two things:

• It contains one and only one patient resource, which has to be the first resource created in the FHIR® server

• All the other resources in the FHIR® server reference the single patient in the PFR

We allow an infinite number of identifiers to be added to that one patient resource based on different source systems. We implemented the logic to validate that all post and put requests for any of the resources match to that one patient resource.   

Portability of Personal FHIR® Record (PFR)

A single user can 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 the PFR allows the data to follow the person, thus ensuring continuity of the record and putting the consumer truly in control of their data. 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. We had to come up with a cost-effective way to implement it. Leveraging the open source Microsoft FHIR Server code and with a lot of support from the Microsoft FHIR Server team, we were able to implement a fully working PFR model in less than 4 weeks. I discussed the details of the implementation in a previous blog.

Step 2: Getting Data in The PFR

So now comes the tough part. How does a patient start to import data in their PFR? We have started with a Blue Button pilot that enables Medicare patients to import their Medicare data. We are also in the process of implementing integration with Apple Health. However, most of the data is still locked in the EHRs. Unfortunately, it is really not possible today for a patient to “pull” their data from most EHRs. While this would(hopefully) be possible after the new ONC and CMS proposals for interoperability are approved, we wanted to implement a process that would allow an EHR to share data with a patient based on the current 2015 Certified EHR capabilities. We implemented this through a process called DOPU (Drop Off - Pick Up).  

HL7®, FHIR®, and the Flame Design are registered trademarks of Health Level Seven International.

DOPU: Drop Off - Pick Up

Here is how DOPU works at a high level: All EHRs at a minimum support exporting patient data in the CCDA format. We have implemented a very simple API endpoint that accepts a post request with two parameters. The first parameter is an email address. The second parameter can be a CCDA document or a FHIR® bundle as an attachment. An EHR can easily embed a call to this endpoint with the patient workflow. If that is not possible, the provider can export the CCDAs to a folder using the EHR’s existing certified process. Using a standalone application provided by us, the CCDAs can be uploaded as a batch to the API endpoint. Whether directly through the EHR or through the standalone app, the provider can post (“Drop Off”) a healthcare package to the endpoint. The package is validated and converted to a FHIR® Bundle. At the same time, an email is sent to the patient. The patient is then able to import (“Pick Up”) the package into their own PFR. The “Pick Up” process basically is similar to posting a transactional bundle to a FHIR® server with one difference -the patient resource is processed as the first resource(as a batch) before all the other resources. If the patient doesn’t already have a PFR, the server automatically takes them through the process to select a domain and setup of a new PFR.

Now, there is a chance that the person posting (dropping) the package in the EHR or the standalone app had a typo in the email and the package could end up with the wrong person. Therefore, we require a security code that needs to be entered by the patient at the time of picking up the bundle. This security code can be automated to be set to the patient’s SSN or date of birth in the EHR.

It is important to mention that the PFR is just like any other FHIR® server and it is possible to post data directly to the PFR. Although we implemented DOPU to accelerate the adoption, the patients can use an app provided by the EHR or any other third party to directly import data from providers to their PFR.

Step 3: Patient Sharing Data With The Registry

OK, so now to the main part. We have a patient who has the data in a PFR. How does the patient send the data to the registry? Well, the same DOPU process works here too. The patient can select the data that they want to share and post it (“drop off”) to the same endpoint. There are three ways this is different from the DOPU process for an EHR sharing data with the patient:

• The data is now already in the FHIR® format.

• Instead entering an email, the patient is provided with a drop-down directory of organizations that have signed up with us to receive packages. The patient selects the organization with which they want to share their data.

• The registry user will be importing the data into a single FHIR® server that is based on Azure API for FHIR®.

A user in the registry with the right permission is now able to go and import (pick up) the bundle into their registry based on Azure API for FHIR. Unlike the PFR scenario, the user is presented with an option to import the data to an existing patient (if a matching patient identifier is found) or create a new patient from the FHIR bundle. The import process can be automated to import all incoming packages as a batch process.

That’s it. A very secure and simple way to share data with no exchange of certificates or complicated integration required. That is the FHIR power

In the next blog, I will discuss how we are implementing integration with an EHR to allow providers to share data directly with a registry. I am really excited to share that we are working on a pilot project with NextGen Office to demonstrate this implementation. Once completed, NextGen Office clients will be able to share data with registries directly from their EHR to meet the Promoting Interoperability requirements for registry submission and also track their MIPS performance through the MyMipsScore™ app. Stay tuned for more.

I am doing a session on Wednesday at HL7® FHIR® DevDays next week where I will be discussing this in further detail. I hope to see some of you there. Contact us if you are interested to see a demo of the whole scenario.