Start a FHIR® in 60 minutes with Microsoft® Azure API

In our recent blog, we discussed how Microsoft has taken a radically different approach as compared to Amazon and Google for their FHIR® offerings. Late last year Microsoft announced an open source project for FHIR that could be used by developers to quickly integrate a FHIR server into their own applications. Around the time the open source project was announced, we were approached by a client that wanted to develop a highly customized FHIR based research solution that would help them meet MIPS requirements for their provider members in addition to supporting their research activities. We decided to use the Microsoft open source project as our base FHIR server. Although the project is still in process, we have been able to implement all the customization requirements while keeping in sync with the latest Microsoft updates. Yesterday, Microsoft announced a new Azure service called Azure API for FHIR. This new service uses the same code from the open source project to provide a “managed service” for creating and managing FHIR instances on Azure. Having worked so closely with the backend code, we were really curious to compare it with the open source version. So, we decided to give it a try.

HL7® and FHIR® are registered trademarks of Health Level Seven International .  "Blue Button" is a registered service mark owned by the U.S. Department of Health and Human Services.

HL7® and FHIR® are registered trademarks of Health Level Seven International. "Blue Button" is a registered service mark owned by the U.S. Department of Health and Human Services.


We started with the 5-Minutes QuickStarts documentation. Exactly 4 minutes 50 seconds later, we had a FHIR server running and we could hit the metadata endpoint (the Hello World of FHIR) from any browser. The hours that we had spent forking the open source repository, setting up the resources and then deploying the FHIR server suddenly seemed too long. However, we soon started seeing the trade-offs between the 2 options. One of the main customization we had to do for our open source implementation was integration with an existing identity system to manage the users and roles. The Azure API for FHIR only supports Azure Active Directory as the identity provider. In order to start adding any data to the new FHIR server, we had to complete the steps for integration with an Active Directory. As we were planning to use this with one of our existing solutions (described below) behind an API, we decided to just register a service client based on the documentation. About 30 minutes later, we were able to hit and create our first patient using Postman.


Although the postman test verified that we have a fully working FHIR server now, we decided to test it with a real use case scenario. We have developed an app called BlueButtonPRO that allows Medicare beneficiaries to download, view and share their Medicare Part A, B and D data for the last 4 years using CMS Blue Button 2.0 API. The application is currently in beta and scheduled for release later this month. As discussed in detail in the previous blog, this data is available in FHIR format. BlueButtonPRO uses a process called DOPU (Drop Off/ Pick Up) as a very simple but secure way to share FHIR based data. I will be discussing the details in a follow up blog but at a high level, the app creates a FHIR bundle that can be “dropped off” (uploaded) to a shared FHIR server. It can then be “picked up” by the recipient with correct permissions and the FHIR data in the bundle can be directly imported into the recipient’s FHIR server or converted to non FHIR format to store in the EHR. Using the sample data made available by CMS, we were able to upload FHIR bundles without any issues to the new FHIR server through the BlueButtonPRO app.


It is really amazing that we were able to create a “PHI Ready” FHIR server and start receiving data from an external app in around 60 minutes. As we continue to explore the new service, we did find some other issues due to which we still can’t use this for our FHIR based research server. However, I am really excited about new opportunities created by this new service. I realized later that Microsoft has actually now provided a very simple way to deploy the Open Source project too. We have the option to go with the open source or the managed service on a project by project basis By not having to worry about the FHIR server, we can really put all our focus on developing new apps.  


Our team will be at HIMSS next week. Contact us if you would like to see a live demo of the solution I described above or discuss how you could use Microsoft FHIR API or the open source version to jumpstart your own FHIR projects.