Introducing OpenSRP FHIR Core – Why we are going all in on FHIR
When I first heard of HL7 FHIR (Fast Healthcare Interoperability Resource), I think, like most, l understood its application as a data exchange standard with promises of facilitating interoperability.
It wasn’t until I started exploring FHIR resources and was struck by the elegance and thoughtfulness of how FHIR represented health data, however, that I appreciated its potential for something much more. After spending nearly a decade developing strategies to represent data in health apps, I couldn’t help but feel a bit like Salieri in the movie Amadeus, when he is first hit with Amadeus’ true brilliance.
As we at Ona continued to develop OpenSRP and talk with our partners, our team began consulting FHIR for all design decisions related to new functionality. We adopted FHIR’s tasking data model, for example, when we wanted a way to support patient referrals between apps and campaign based workflows for our malaria control interventions. Our default strategy quickly became: see if we can adopt FHIR first before considering any other approach. And as our understanding of FHIR grew, it was apparent that building with FHIR, instead of alongside it, had to be our way forward.
WHO Smart Guidelines
Over the last few years, we have been working with our longtime partners at the WHO to help digitize their health 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 to 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 interoperability1.
It was as our team was beginning to invest in FHIR’s potential, that the WHO shared their vision to develop the WHO Smart Guidelines, with the ultimate goal of using a combination of FHIR and Clinical Query Language (CQL) to make the guidelines computable. By computable, we envisioned a future where you could download these guidelines to an app and they would configure the clinical logic, data mappings and outputs of the app. While we recognized this idea as paradigm-shifting, it sounded very ambitious – at best achievable in 5 years with the right level of investment. As an incumbent app builder, our frame of reference was the time and effort it took for us to achieve what we did with OpenSRP, which made this leap feel borderline impossible.
Enter Android FHIR SDK
In early 2020 just as Covid-19 pandemic was starting, we together with WHO and a team from Google Android met to explore what it would take to achieve WHO’s vision of FHIR configurable apps. As those discussions progressed, it became clear that our ability to leverage preexisting work – libraries like HAPI FHIR and Google FHIR protobufs to represent resources in FHIR and the relationships between them – would make this goal feasible on a much shorter timeline. With the idea now seeming viable, we set out with Google and IPRD to begin to develop a FHIR SDK for Android, which we hope will form the foundation of a next generation of FHIR native digital health apps.
What does this mean for OpenSRP?
Excited and committed to support this effort, we immediately began asking ourselves what this new vision means for OpenSRP. We have made enormous progress in the last five years in developing a platform that allowed us to build health apps optimized for specific frontline health worker use cases. In doing so, we have developed electronic immunization registry apps, facility clinical apps, and CHW apps that are achieving large scale adoption.
But what we also knew is that configurability, to some extent, had been the cost of our focus on the customization needed to support these different models of care delivery. So, while we could quickly adapt an existing module like ANC for a new country, our lack of configurability would somewhat limit the amount of concurrent new opportunities we could support. Having just spent over a year working on WHO’s first reference app for ANC, we realized that simply supporting form configurability was not enough. FHIR’s standards based approach makes it possible to define not only the forms, but also the schedule of visits via a CarePlan, the clinical logic to determine patient risk, and the subsequent workflows to coordinate care between different providers (eg. Nurse midwife and Community Health Worker). Even with major new investments in OpenSRP, we realized we could not achieve this level of configurability, unless we went all in on FHIR.
Exploring FHIR’s advantage
In considering this new technical direction, we began to map out what other strategic advantages it could offer to our partners and the field at large. FHIR, most simply is a standard that defines both the data formats and the elements for exchanging data across health processes. FHIR serves as the industry’s most robust standards-based data model for representing the entities, events and workflows in a health system. And as a direct descendent of HL7, FHIR and HL7 represent the standard for how the vast majority of health data in the world is exchanged. Given this, we see six core areas of value in its adoption.
Structured data capture
One of the most compelling initial uses of the FHIR SDK is its support for structured data capture (SDC). By using FHIR Questionnaires (think ODK/XForms), SDC makes it possible to easily develop data collection forms optimized for health applications. In addition to being able to support complex clinical logic, you can assign definitions and response types with a clinical concept code for each question. You can also define what FHIR resource a question maps to (updates) when the questionnaire is processed.
NIH FHIR Form Builder
There also already exist a number of robust open source web-based tools around SDC, including a web based form builder and web based questionnaire renderer, developed and maintained by the NIH. This means it will one day soon be possible to define an app in FHIR and publish it to both web and Android for use.
An emergent ecosystem
Since we are building from an established standard, we can benefit from tools built for this standard like the NIH form builder referenced above or a number of established FHIR store backends like HAPI. While the tools that support FHIR are nascent, with the recent massive influx into digital health, we expect the investment in tooling to grow rapidly. Correspondingly, we believe being an active member of this movement could open up exciting new exciting market opportunities for our tools.
Data standardization across tools
By defining how data is collected in a more standardized and understood way, FHIR apps will output data in a more standardized way. This will allow for the development of specialized algorithms that can work across different apps and implementations. Data standardization also helps with the development of ML/AI models where large amounts of explainable data is needed. FHIR as a technical standard, serves as an investment in common data analysis pipelines and end data visualizations that are FHIR based.
Worker-based tasking
FHIR provides important standards to define workflows in health such as tasking. A model built on the creation and assignment of tasks allows you to determine which providers in the system should complete which activities and define what the care an individual patient should be provided based on their profile and what care they had already received. This model also provides valuable healthcare worker performance data, by surfacing information on the counts and dates of completed tasks. We have been using FHIR tasks to develop our new task-centered app for CHWs and their supervisors and to support campaign-based workflows for malaria eradication programs.
Example of our task based CHW app
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.
Local ownership
Another key opportunity with FHIR is that it will allow countries to understand, localize, and configure the logic that goes into their apps. While it will take time and significant investment to build in-country capacity in FHIR to do this right, the investments made into defining this logic in a standards based way can truly be owned by the implementer or local government. Since the logic is based on an open standard, if you are not happy, say with OpenSRP, or don’t like dealing with a group like Ona – you can take your logic, while retaining your underlying data model, and implement it somewhere else. In the absence of FHIR, we code our logic using platform specific proprietary standards. While the emergence of “academies” to promote the adoption of a specific platform have undoubtedly numerous broader level benefits, it’s hard not to get excited by the idea of creating FHIR academies where the focus is not on a specific platform but a standard.
Interoperability
Last but certainly not least, is interoperability. If your app can take in and output data in FHIR, FHIR will make it easier to exchange your data with other systems. This is a major priority for our government partners, and understandably so, given the current siloed nature of the health space. If existing platforms join in in the adoption of FHIR, we will be one step closer to the multi-platform interoperable health system that we have all been dreaming of.
We do not feel that just the promise of FHIR interoperability, however, is enough to achieve the future we see. FHIR native platforms that fully leverage all that FHIR has to offer will be needed to push things forward. This is why we are excited to put our stake in the ground and commit to advance this forward.
Introducing OpenSRP FHIR Core
We are now excited to announce that we are committing to build our next generation of OpenSRP on top of the FHIR SDK. To clearly distinguish our next generation of our app, we will be adopting the OpenSRP FHIR Core branding. Our goal with OpenSRP FHIR Core is to be the first Global Good, FHIR native platform to be made available and adopted at scale by Ministries of Health. We hope to be able to begin to achieve this by later in the year. We think this is achievable based on our exciting progress to date and Google’s support for the underlying open source Android FHIR SDK.
For our existing and upcoming deployments of OpenSRP, we remain 100% committed to supporting and improving the apps as always. If we are successful, we hope to explore the opportunity to upgrade these apps to the new FHIR Core when it makes sense for our partners.
Join us!
Our mission as a company is to use data to transform lives in the areas of the world where the need is greatest. Our team is energized by what we believe represents a massive step towards that goal.
If you are interested in being part of this journey please join us. This is a big effort – an Apollo Mission in many ways. We seek both contributors who want to help develop the SDK and technical and implementing partners, who share our excitement for the potential that FHIR holds.