FHIR is a data standard evolved from HL7, which pioneered the field of health data exchange. Importantly, since its introduction a decade ago, it has become the globally accepted standard describing how to represent and exchange health data.
1. Data accessibility and interoperability
A core tenant in FHIR’s design is its support for data accessibility. FHIR follows a modern web app architecture in which all data is accessible and updatable via a standardized REST API. In FHIR, each aspect of a patient’s health data is represented in standardized documents (serializable in JSON and other formats) called resources that are accessible through a standardized URL with a unique identifier for each resource. If a health application makes its data available via a FHIR API, this makes it easy for other applications (if they have permission) to access and integrate with it. Compared to EMRs that make their data available via a proprietary formats, the standardization of FHIR significantly lowers the barrier to data sharing and facilitates data accessibility. Data accessibility promotes interoperability between systems, making it possible for a patient’s data to be accessed and updated across the patient’s different care providers leading to improved care coordination. FHIR — which also powers data accessibility behind the scenes on the Apple Watch — is key to making it easier to ensure patients have access to their own health records in a portable format that they can bring to a provider when seeking care.
2. Shared data model and a structured way to think about health
Perhaps more importantly, by establishing a standardized data model, FHIR provides a common language in which to think about health. When you are designing a health solution, or figuring out how to integrate with an external platform, 9 times out of 10 FHIR’s data model will provide a way to support the outcome you want. This reflects that the core philosophy behind FHIR is to build a base set of resources that, either by themselves or when combined, satisfy the majority of common use cases encountered in health informatics. This includes representing all the components needed for health system administration, clinical care, diagnostics, medications, workflow, and financial management
In the cases where FHIR does not support your needs, FHIR provides a set of built-in mechanisms to extend resources in order to support storing the content needed. FHIR governance is conducted through a robust balloting process that allows community members to propose additions or changes to the FHIR spec. These additions go through a number of phases, including a series of trial phases, before being adopted into the normative standard where strict rules limit future changes.
3. Structured data capture
If you want to build a data collection app on top of FHIR, FHIR provides clear guidance on how this can be achieved through FHIR’s Structured Data Capture (SDC) implementation guide. In FHIR, data is collected in forms called Questionnaires that provide a user-friendly format for capturing user-entered data. Similar to the XForms and XLSForms made popular by platforms like Open Data Kit (ODK), Questionnaires use advanced data validation rules, skip logic, and calculations. Form elements can also be linked to terminologies like ICD11 or SNOMED, tying the data to official health ontologies.
Using SDC, it is possible to define how the output of questionnaires (these are stored in the FHIR QuestionnairesResponse resources) can be extracted and transformed into other FHIR resources. Data extraction is particularly powerful as it allows you to derive semantically coded data, say a clinical observation like a patient’s weight, from a visit form. You can then use this coded data to, for example, easily plot a patient’s weight over time by filtering the weights from the Observation resources that were extracted and stored for that patient, as opposed to parsing uncoded content in the visit form. This also allows you to limit access to only the specific resources needed for this visualization, as opposed to any data that was captured during the visit.
It is perhaps not surprising that one of the initial focuses of Google’s Android FHIR SDK is support for SDC. This allows an app developer to use Questionnaires to define mobile forms whose QuestionnaireResponse outputs can be extracted on device in order to create different associated FHIR resources. A standards based approach to define forms that output structured, semantically coded data to defined resources represents a huge opportunity to build upon.
4. Standards promote specialization which creates software ecosystems
With FHIR it is possible to decouple the different functionalities needed in a digital health solution (e.g. data collection, storage, analytics) into different specialized tools and platforms, while still maintaining adherence to the standard. Since all FHIR stores support a common API, it is possible to connect your mobile health app to different mature services, like HAPI, SmileCDR, Google Health API, Azure Health Data Service, or FHIR Works on AWS, with minimal adaptation. In the case of OpenSRP converting to FHIR, this means we no longer have to build out and maintain a backend – a massive savings in engineering effort.
While the tools that support the FHIR ecosystem are still somewhat nascent, the rapid adoption of FHIR has coincided with increasing investments in FHIR tooling and the FHIR ecosystem. In analytics, Google is making large investments to simplify the process of FHIR data analysis using tools like Big Query. The Norwegian Health Institute, Helsenorge, has created an amazing web based questionnaire builder and we (Ona) are contributing a web based interface for administering FHIR based digital health solutions, called FHIR Web. The ability to build solutions that seamlessly integrate these different tools, leveraging what they excel at as opposed to building out all functionality in a monolithic solution, will allow groups to move much farther and faster, achieving better outcomes for the fraction of the cost. For Ona, this has given us the ability to largely replace a platform we spent over 8 years building with a significantly better solution (inspired by all our learnings from the previous platform) in under 2 years time.
5. AI and analytics
By defining how data is collected in a more standardized and semantic format, FHIR apps will output data that is well labeled, structured, and linked to defined schemas. This will allow for the development of specialized algorithms that can work across different apps and implementations. Data standardization is also critical to creating machine learning based AI models that rely on large amounts of training data.
Having a correctly labeled ground truth dataset opens up opportunities to use machine learning to generate synthetic data representative of common healthcare scenarios but not tied to personally identifiable information (PII) or protected health information (PHI). FHIR also enables methods of aggregating data for regional and international disease and health monitoring while respecting national data sovereignty. FHIR, as a technical standard, serves as an investment in common data analysis pipelines, AI modeling, and data visualizations that are built around FHIR.
6. Tasking and coordination of care
FHIR provides important standards to define workflows in health, such as tasking and patient healthcare planning. A model built on the creation and assignment of tasks allows you to determine which providers in the system should complete which activities in what time frames, and to reassign tasks when there are unforeseen circumstances. By defining plans of care generically in FHIR, and then using FHIR’s tools to automatically map those plans to particular patients, health system planners can codify how care should be provided to an individual based on their profile and the care they have already received.
This model also creates valuable healthcare worker performance data by surfacing information on the numbers and timeframes of completed tasks. We have been using FHIR tasks to develop our new task-centered app for CHWs and their supervisors. We have also been using FHIR to support campaign-based workflows for malaria eradication programs.
The ability to see across a health system and use analytics and tasking to coordinate a mother’s care plan across providers is incredibly exciting and will only be enabled through the widespread adoption of FHIR.
7. Local ownership favors standards over platforms
When rolling out digital health systems, countries have to make the difficult decision of what healthcare platform to adopt. Instead countries should focus on a standards based approach and design their data architecture around FHIR. Once this has been established, countries will have meaningful flexibility by being able to plug different platforms into their FHIR architecture and change platforms without having to change their content or data format. While this will take time, and require a significant investment towards building in-country capacity around FHIR, the investments made in defining the logic of their health apps can be owned and managed by the government themselves, even as they move between or use multiple software platforms and providers. While the emergence of “academies” to promote the adoption of specific platforms undoubtedly has numerous benefits, it is hard not to get excited by the idea of creating FHIR academies where, instead of worrying about a specific platform, the focus is on building for a standard.
8. WHO’s SMART Guidelines
One of the WHO’s key mandates is to develop, validate, and publish evidence-based clinical recommendations for countries seeking to improve the health of their people. When it comes to translating these recommendations into digital tools, WHO has found these processes to generally be “unsystematic, slow, prone to error, and indifferent to technical standards” resulting in poor transparency. The consequence of this has been a multitude of applications with unverified health content, which undermines government and donor confidence, impedes country localization, and further obstructs interoperability.
To address this, the WHO has created the SMART Guidelines which use a combination of FHIR and the Clinical Quality Language (CQL) to represent WHO guidelines, including data models and clinical logic, in a machine readable format that can be executed in a FHIR native app. Building on top of Google’s FHIR SDK, we along with a few other groups, are working to build the first generation of digital platforms that will allow countries to take the WHO Smart Guidelines then quickly and accurately adapt them for use in their countries.
What’s next for FHIR?
This is one of the most exciting times to be involved in digital health. The emergence of SMART Guidelines and FHIR based web apps, mobile apps, data stores, and platforms coincides with a broader realization of the massive opportunity for impact we have through improving global healthcare with digital tools. Digital health is essential to continuing the global reduction of child mortality, improving livelihoods through personal healthcare, and preventing the next pandemic.
We are working on these challenges in collaboration with incredible teams at the Bill & Melinda Gates Foundation, Google, the WHO, and many other partners. If you are a program manager, healthcare professional, technical implementer, investor, or other stakeholder looking to modernize your healthcare infrastructure we would love to get in touch and discuss the benefits of building on standards. Reach out to us at firstname.lastname@example.org, on Twitter @onadata and LinkedIn.