Continuing our series of posts on web protocols, we have been investigating more specialist protocols, in this case, “FHIR”. We have produced a document based on our research, investigations and experience.
How the FHIR started
Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) sparked up in 2011 by HL7, when Resources for Healthcare (RFH) set out to define a granular set of resources specifically for healthcare. These resources, designed to be aggregated and shared, became an open standard defining a comprehensive five-level specification, suitable for mobile apps, cloud communications, and electronic health records (amongst others). The existing HL7 protocols and formats showed their age and became difficult to use for interoperation in modern software.
Now at version 4.0.1 (R4) with R5 at Preview 3, FHIR boasts healthcare provider adoption and an extensive suite of open source and commercial FHIR components and services.
Following everything to move towards a cloud and a service model, several providers have created deployable FHIR APIs at varying maturity levels. We have performed an analysis of the three major providers (AWS FHIR Works, Azure FHIR API, and Google Cloud Healthcare APIs), and combined this with our experience, principles and appropriate architectural patterns.
Please get in touch if you’d like a copy.