Open Health Stack: Building interoperable health apps using FHIR profiles

Jing Tang
Open Health Stack
Published in
4 min readDec 2, 2023

--

Jing Tang (Staff Software Enginner, Google Health), Bryn Rhodes (Director of Standards Strategy, Smile Digital Health)

Healthcare standards, such as HL7® FHIR®, enable technologists to create more interoperable health apps. Using a standardised approach, developers can utilise common data models (e.g. FHIR’s patient resource), terminologies (e.g. LOINC, ICD or SNOMED CT codes), operations (e.g. FHIR’s RESTful API), and existing tools and infrastructure (such as Open Health Stack) to build health apps that are fast, secure, and interoperable with less time and effort.

However, adopting standards on a country level or local level is a nontrivial task, due to the variability in healthcare practices, languages, regulations, etc. The standardised approach cannot work practically unless there is adaptation and customisation that allow localised requirements to be met. For example, whilst the FHIR Patient resource is a powerful way to exchange patient data, states and administrative regions might require additional data elements to be recorded for a patient or for specific validations on existing data elements.

To account for this, FHIR profiles can be used to provide the necessary customisation of FHIR resources. By leveraging FHIR profiles, typically published as part of FHIR implementation guides, developers are able to enjoy the benefits of the standardised approach to healthcare data whilst meeting local requirements. For example, whilst the base FHIR Patient Resource does not have any requirement of a mandatory identifier, a patient profile authored for a state might require a national insurance ID to be present for every patient. Similarly, in the US Core IG, a Patient resource must contain ethnicity. This is achieved by creating an extension in the Patient resource for a new field with a paired ValueSet for ethnicity.

Figure 1: FHIR profiles augment base FHIR resources
Figure 1: FHIR profiles augment base FHIR resources

Earlier this year we launched Open Health Stack, a suite of open-source components for building secure, offline-capable, and data-driven healthcare solutions conforming to interoperability standards. With the help of Open Health Stack components, a number of our partners have created end-to-end solutions that include capabilities of patient data collection, patient screening, two-way data sync between mobile client and server, and standards based clinical decision support.

To help developers build better localised and customised solutions, we are building Open Health Stack components to be FHIR profile aware. For example, with the newly created Knowledge Manager library, developers can create Android applications capable of downloading and storing implementation guides from a given end point using a simple API. Through the integration between the FHIR Engine library and the Knowledge Manager library, developers can validate FHIR resources — for example at time of saving — to make sure they are compliant to the requirements stipulated by the profile author. Together, this makes it easier for developers everywhere to build interoperable solutions for different use cases.

Figure 2: Creating compliant patients from a patient profile
Figure 2: Creating compliant patients from a patient profile

Case study: Ayushman Bharat Digital Mission (ABDM)

Take India’s Ayushman Bharat Digital Mission (ABDM) as an example. The ABDM implementation guide defines FHIR profiles that define the minimum mandatory elements and terminology requirements for India’s national digital health ecosystem.

Through a simple API call in the Knowledge Manager library, developers using Android FHIR SDK will be able to download resources in the ABDM implementation guide to the Android device.

knowledgeManager.install("https://www.nrces.in/ndhm/fhir/r4")

The other libraries in Android FHIR SDK will coordinate with the Knowledge Manager library to ensure compliance with the loaded implementation guide over any resource marked with the profile. For example, the FHIR Engine library will validate FHIR resources according to the ABDM profile:

val patient = Patient().apply {
// Indicates that this patient should conform to the ABDM profile.
addProfile("https://nrces.in/ndhm/fhir/r4/StructureDefinition/Patient")

// However, the patient does not have the required identifier
// in the ABDM patient profile
}

// Stores the patient in the local database to be synced to the FHIR server.
// However, this will fail since the patient does not conform to the ABDM profile.
fhirEngine.create(patient)

Beyond profiles: supporting FHIR implementation guides

A FHIR implementation guide is a set of rules about how FHIR resources should be used in a particular context. FHIR profiles (in the form of FHIR StructureDefinitions) are one of many types of definitional FHIR resources that can be included in implementation guides. As summarised in the table below, different Android FHIR SDK libraries use such resources to fulfill different requirements.

Table 1: Resources included in a FHIR Implementation Guide used in Android FHIR SDK libraries
Table 1: Resources included in a FHIR Implementation Guide used in Android FHIR SDK libraries

For example, the Structured Data Capture library uses FHIR questionnaires included in implementation guides to generate Android UI for data collection. As another example, the Workflow library can generate care plans for patients using PlanDefinitions packaged in implementation guides. With ongoing integration between the Knowledge Manager library and other Android FHIR SDK libraries, developers can take advantage of FHIR implementation guides more easily.

Standardisation through localisation

The standardised approach to healthcare cannot scale to meet the requirements of healthcare systems in different contexts without adaptation, customisation and localisation. Open Health Stack bridges the implementation gaps for developers, making it easier for developers to work with FHIR profiles and implementation guides, and allowing everyone in the ecosystem to reap the benefits of healthcare interoperability.

--

--