Rubber glove time! Microsoft flings open gates to its very own Azure FHIR health data fest

SQL support and Release 4 arrives in cloudy open source service

doctor

Feeling a bit poorly? Good news! Microsoft has added SQL to its FHIR Server for Azure, so your symptoms can now be flung even further.

The Fast Healthcare Interoperability Resources (FHIR) framework is aimed at getting healthcare professionals – who have had a great deal of difficulty shedding their love of paper – to exchange data between often incompatible systems. It was mooted back in 2014 by Health Level Seven International (HL7) and currently stands at Release 4, published on 27 December 2018.

Microsoft has also slipped the fact that it now supports R4 into its SQL trumpeting. Release 4 is a big one for FHIR, adding in nearly 3,000 change proposals to the specification, including 339 labelled "non-compatible" according to the organisation. For its part, Microsoft was delighted to see a number of the most mature definitions become normative, meaning backwards-compatibility should be a thing in the future.

As well as Release 4 goodness, the addition of SQL to the existing Azure Cosmos DB support will be welcomed by developers implementing the technology, since, frankly, there are some use cases within FHIR that aren't a great fit for Cosmos DB right now. Microsoft cited SQL's relational chops as handy for queries, and said atomic transactions were useful for treating a set of changes as a single entity.

FHIR itself, of course, requires persistent storage for its resources and Microsoft first plugged it into Azure in November last year. Developed as open source, the Microsoft's FHIR Server includes a hosting layer, RESTful API, an implementation of the core FHIR logic and, of course, a persistence layer that can now make use of SQL as well as Cosmos DB.

The normally twitchy clinical auditors will be delighted to know that Microsoft claims compliance with Protected Health Information for all the Azure services it uses. So there's no need to worry about stashing all that data in the company's cloud. No, really.

Scripts are also available to map to Azure Active Directory and enable role-based access control.

Unlike certain other more document-centric standards, FHIR exposes data elements (such as patients and treatments) as services. Work has, however, been done to show that FHIR structures can be mapped to the likes of the venerable CDISC formats (PDF) for purposes such as the population of Electronic Case Report Forms (ECRF).

Certainly, setting up a FHIR implementation to shunt data between systems is considerably simpler than earlier, often bespoke, attempts.

Microsoft is not the only game in town. Apple fans enjoy FHIR as part of the firm's Health app to pull down data such as lab results from institutions that have got cuddly with the fruity firm. IOS developers can get at the JSON data directly via HealthKit, so long as the user gives permission for each record type.

Google also has an implementation in the form of its Cloud Healthcare API, currently in beta, which allows developers to spin up a FHIR Server hosted on the Google Cloud Platform. Google's take is, however, for now based on Release 3, the current Standard for Trial Use (STU).

Microsoft's approach, however, is a little different. With an open source project backed by an in-house engineering team, the gang has been able to add features at an impressive rate.

Getting buy-in from the usually highly conservative healthcare and clinical research industry will, however, continue to present a challenge. ®

Sponsored: Technical Overview: Exasol Peek Under the Hood

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER




Biting the hand that feeds IT © 1998–2019