In a recent ICTworks article, Karamagi et al. describe digital health as in a state of e-Chaos. They demand digital health projects “stop further duplication, [and instead] encourage interventions that holistically strengthen the health systems.”
Digital health works exactly as it was designed and that’s the problem!
Despite remarkable progress in digital health, we believe the industry faces significant obstacles to greater impact if we continue with business as usual — and instead propose a holistic solution built around the FHIR standard.
What’s broken with digital health?
In digital health’s long history of projects, technical and implementation choices have been pragmatic, guided by:
- Available technology,
- Implementation-specific requirements such as “must work offline”,
- Per-project funding.
While some projects have successfully solved important problems and created measurable impact, nice-to-have goals such as interoperability and reusable content were unfulfilled and health challenges remained unsolved at a health systems level.
Several of our projects worked like this: a group focusing on improving childhood immunizations through community health workers wants a mobile app. However, in practice, immunizations were discovered to be covered by several other touchpoints such as health facilities and campaigns from special interest NGOs, with each group using their own software. Unsurprisingly, we would be asked to send and receive data from these other systems and these requests would be treated as “integration features” — just another requirement added during the development process.
Sound familiar?
This common scenario means maintaining interoperability requires each new system to integrate with every existing system, leading to an exponential increase in effort and cost, which makes large-scale interoperability infeasible. To combat this, the digital health community has coalesced around two solutions: hubs and monoliths.
Hubs and Monoliths
Figure 1: each column represents a different digital health program. Traditional digital health architecture is siloed and requires custom adapters that are often never built.
Integration hubs are platforms meant to connect different systems. Tools such as OpenHIM address this specifically for health, while data integration tools like Airbyte, Beam, NiFi, and OpenFN are for generic use cases. Instead of integrating one program’s solution to another’s, they both integrate with the hub, which is an improvement but comes with its own challenges.
Each program-to-hub integration still requires additional integration work, and for other solutions to benefit, they must also integrate to the same hub. Hubs also face a “cold start problem.” If no other program has connected to the integration hub, why bother connecting this program. Since future benefits are unknown and there is no immediate payoff, this is usually the first type of scope to be cut.
Monolithic interoperability is the approach of using a single platform (often with a proprietary data and workflow format) for every app and system component. This works for single projects in isolation, however because of the myriad of features required to scale – from supply chain to civil registration – you cannot build a health system on a single application.
Even still, having two programs run the same platform does not ensure they are integrated, leading again to siloed and overlapping systems. Figure 1 below shows the siloed health system architectures that we end up with today using direct integration, the hub, or the monolith approach.
FHIR = better than hubs and monoliths
Figure 2: a standards-based digital health architecture combines reusable building blocks based on a common standard.
Hub and monolith architectures have led to digital health solutions that are not designed to address health challenges from a health systems standpoint, which makes sense since they were designed to solve problems from a project-perspective. What is missing is not to add an integration feature, an integration hub, or a monolithic solution, but to have integration between facility and the community apps be unavoidable, out-of-the-box, and by default without additional effort or cost. Sounds impossible?
Thankfully the global health standards community has already done a lot of the work. To break down the silos and move forward we need to use platforms and tools that build around a common architecture where integration is not something to be added but a given — built into the system itself. The FHIR standard provides that architecture.
HL7 FHIR, the globally recognized health data and workflow standard, provides the opportunity to create a new generation of digital health systems that overcome traditional interoperability challenges. FHIR can represent both the app’s logic and underlying data model. With recently added mobile support, through Google’s Open Health Stack, FHIR provides a fundamentally new type of architecture built around a common shared data model that puts interoperability at its core.
Interventions can create reusable FHIR content to describe the healthcare workers, healthcare workflows, and their connections, and contribute to an evolving ecosystem of innovation that does not depend on the specific organization or tools used in the implementation. Any platform that understands FHIR can load that intervention and its generated data, integrate it with other FHIR data or systems, and execute it.
FHIR: coordination by default
Figure 3: a facility app used by a nurse, and a community app used by a community health worker, are alternative ways to view, manage, and contribute to the same set of shared health records.
While hubs and monoliths have led to “unintentional and extreme duplication of digital tools which implies a lack of a coordinated approach and weak partnerships” (Karamgi et al.), FHIR avoids this by making standards-based interoperability a prerequisite.
Consider a ministry of health working with partner organizations to implement a program for the prevention of mother to child HIV transmission. One organization may have an app for maternal health, such as antenatal care visits, while a second organization has their own app for HIV management. To limit the risk of mother to child transmission these apps need to work together. Let’s take a look at how to integrate this data under the 3 solutions we’ve discussed:
- With the hub approach, an integration hub is set up that both programs have to be aware of and have access to; then these programs must create or implement connections to that hub. The programs must also agree on a common language for the information they want to share.
- In the monolith approach, the programs use the same proprietary platform, and then they must either integrate the data of one program completely with the other or write an integration that continuously synchronizes data between the two systems. To have a useful integration they will still need to ensure that both systems represent information in the same way.
- With a standards-based approach, where both programs store their data in FHIR, the different programs are alternative ways to view and manage the same underlying shared health records. There’s one FHIR server set up and both programs can query and push data into it.
One way to think of a FHIR health systems architecture is as a set of interlocking tiles that connect because of, not in spite of, their structure. Like Lego pieces, they are built to be interoperable with each other. Programs and countries that are adopting FHIR-native platforms can add on new modules over time, and be confident that their data integrates with other FHIR tools.
Packaging FHIR for sustainable impact
By transitioning to digital health architectures built around standard based systems that can store a shared health record for each client that interacts with the healthcare system, programs and countries open the door to standard packages of reusable content. For example, the SMART Immunization Guidelines created by the WHO, or the Antenatal Care SMART Guidelines implemented in OpenSRP, are computable – or “machine readable” — healthcare guidelines that can be run on any application that can interpret and execute FHIR, as depicted below in Figure 4.
Figure 4: the SMART Guidelines provide a standards-based common language for building reusable healthcare workflows that can be combined like Lego pieces.
Organizations running digital health programs, and the countries implementing them contribute to the growing set of computable health packages, all defined in the same FHIR-based format. These packages are plug-and-play. If a program is running a FHIR-based electronic immunization register in their primary healthcare facilities, when they want to expand it to community outreach they don’t need to transfer any data, they simply point their FHIR-native community app at the same shared health records they are using in their primary healthcare facilities.
There are many challenges leading to the current “e-Chaos” holding back digital health interventions. However, with FHIR, the SMART Guidelines, and community-driven global goods, we have all the tools, concepts, and architectures we need to reduce that chaos. The critical next step in this journey is to move beyond digitizing health apps to digitizing the health systems that those apps exist within.
Comment below if you are excited to learn more about how Ona and OpenSRP can help your projects and teams in this journey.
By Peter Lubell-Doughtie of ONA and originally published as From e-Chaos to sustainable health impact with FHIR
My experience is the technical aspect of standards based interoperability is seldom the issue, governance is. Ideally interoperability should happen at national level at a minimum. Unless there’s national policy and national buy-in to build and maintain some sort of health information exchange, interoperability becomes the task of individual organizations and projects which doesn’t solve the problem. The question will always be: why should organization X spend their budget to integrate with a system developed by organization Y and how does that reflect on their SOW, budget and deliverables. If it’s a national requirement and the HIE exists centrally, then it’s written into the SOW and budget for almost all new projects from the start.
My experience echoes what Ed Robinson has said. That standards based interoperability is part of the solution to the many problems faced by the public Ministries of Health in Africa and elsewhere (I am in some ways less interested in the challenges faced by the eHealth industry which are often more characterised by pursuit of their own survival and growth than improving health outcomes).
A lot of this article seems to be overly simplistic which presents a view of FHIR as a silver bullet or abstract solution to what are the really difficult problems described in the very good and thought provoking eChaos article by Karamagi: eg how to build sustainable systems; how to build systems which are oriented towards meaningful data use rather than meaningless data mining etc.
I have seen no evidence from anywhere in the world, in Africa or elsewhere, that bear out the claim made here that a standards-based approach, implies that both programs store their data in FHIR. This is misleading and in some ways is a reduction to the same monolith approach described in the article. The real value of FHIR (in the real world) is as a common exchange format and API which enables interoperability between disparate systems, particularly those which are already providing proven and sustained value to the health system. The promotion of FHIR for interoperability and driving standardization of terminologies and data dictionaries is where true value potentially lies.
Again as Ed says, this requires significant investment in governance and infrastructure at the national level. Driving simplistic narratives doesn’t help that effort.