In a previous blog, I had discussed how we are leveraging  Azure API for FHIR®  to develop a clinical data registry for a professional association of more than 10,000 providers. In this blog, I would like to share how we are implementing some of the front-end requirements. In addition to supporting MIPS submission for their members, the organization had specific reporting requirements for scientific, clinical, and health policy purposes. After analyzing all the uses cases for the “reporting requirements”, we divided them into three main categories:

1. Predefined reports and dashboards

2. Ability for end users to easily analyze the data in the registry and share insights by creating custom reports and dashboards

3. Ability to easily create and share aggregated reports (no PHI) with members as well as publicly  

The last two are based on the concept of “self-service analytics”. Now, there are a lot of solutions on the market for self-service analytics. The simplest one being Microsoft Excel. However, most of these solutions require the data to be normalized into a simple format (like tables) for the non-technical end-users to perform the analysis. The JSON format for HL7® FHIR® can have values nested multiple levels deep. This makes it really difficult to create simple datasets that end-users can run analysis on. The most common approach to this problem is to develop an ETL process that transfers the data on a regular basis to a data warehouse which then serves as the backend for the end user analytics. While that is okay for most scenarios, we wanted a solution that would allow us to add mappings from JSON fields to new/existing datasets on ongoing basis with minimal code changes . This was really important as we will be migrating to the R4 release sometime soon. After doing some research, we came across a video showing how to convert JSON data to tables using Microsoft Power BI. We decided to give this a try with some of the FHIR® resources. Using just the UI interface of Microsoft Power BI, we were able to convert JSON data for multiple FHIR resources into simple tables within minutes.  

This was promising, but we needed a way to do this with the Azure API for FHIR® Server in a scalable way. It was easier than we imagined. Microsoft Power BI uses a language called M behind the scenes to do all the conversions. As you go through the transformations using the UI, it creates the query in M in the backend. You can view the entire query step-by-step as it is created. By copy-pasting the query for few different resources, we were able to create a quick prototype for a custom data connector for Power BI without having to learn M. We now had a scalable solution to query any FHIR® server and load the data into customized tables on the fly.

We were left with one last challenge – OAuth implementation. We were able to accomplish that within our existing application that is integrated with Azure Active Directory based on the sample code provided by Microsoft team. After packaging everything together, here is what the end user experience looks like in the prototype that we created. 

Open Power BI -> Select the Custom Data Connector -> Login Using AD -> Consent -> [Our Application validates the account and retrieves the Azure API for FHIR® URL] -> Connect to the Data Source -> Start creating reports and dashboards with the simplified datasets.

You can see the entire process demonstrated in a 30 second video clip below. Pretty cool!

Although this shows the integration with Azure API for FHIR®, we will be able to use the data-connector with any FHIR® server. Also, Microsoft Power BI allows us to create dashboards by combining data from other sources with the FHIR® data. That is great, but there is more. We can use the same datasets to create reports to meet the requirements for public reporting and deploy them using Power BI Embedded. Power BI Embedded allows users to embed reports created in Power BI into other applications such as existing website.

Over the next few weeks, we will be developing different datasets based on various use case scenarios. Although this is very exciting, the analytics is only as good as the data we can get into the registry. In my next few blogs, I will share how we are implementing the following features with the Azure API for FHIR®  to solve that problem:

1. Allow providers to share data from any EHR that supports FHIR® API without any direct integration with the EHR

2. Importing data from CCDAs

3. Manual data entry directly into FHIR® format for providers that are not using EHR (yes, there are many)

4. Direct integration with an EHR.

5. Allowing patients to submit their data directly to the registry.

Contact us if you are interested in learning more about our solutions. I am also showing a demo at HIMSS at the Microsoft booth #2300 March 10th - 12th, 2020. I hope to see some of you there.