i. Background & Problem statement

Working in the digital apps for frontline health worker space for nearly a decade, Ona has experienced, first hand, how difficult, time consuming, and frustrating it is to have to reinvent the wheel when adapting existing digital health apps. Adaptation could include adding new health verticals, or adding nuances of the use-case in a specific geography, or adding healthcare worker roles in a specific healthcare setting. We are firm believers that the community is better served by building atop the knowledge accumulated through decades of digital health learning.

Through HL7 FHIR, the global community of healthcare and health information technologists laid the foundations to structure and replicate health workflows. In collaboration with WHO and other partners we began to define healthcare use cases in FHIR and load these OpenSRP. However, the underlying storage in OpenSRP’s existing mobile application and (to our knowledge) in all digital health mobile app global goods, does not store operate directly on FHIR resources, i.e. it is not “FHIR native”, leading to a ad-hoc non-standard transformations to and from FHIR standard data and workflows. In 2019 we partnered with WHO and Google to address this by:

• defining WHO global health standards in FHIR,
• creating an Android library to operate directly on FHIR, and
• creating a reference implementation to load and run FHIR based health protocols.

Since then there is now a health guidelines authoring and implementer community built around the WHO SMART Guidelines with multiple weekly calls led by the WHO, and a developer community around the Android FHIR SDK library and FHIR Core reference application with multiple weekly calls and contributing partners from organizations around the globe. We at Ona have a dedicated team of around 10 engineers, architects, project managers contributing to creating the first (as far as we are aware) FHIR native Android app for frontline health workers.

The software is currently in the deployment and testing phase with a commitment to be in production use at a national scale in at least one country in the middle of 2021, and in regional use in several others. In the shelf readiness framework and global good maturity model, the FHIR Core smartphone, web app, and HAPI extensions have been introduced and embraced by the OpenSRP community. OpenSRP is at the high level of maturity on two thirds of the criteria and normal on the remaining third.

The gaps in shelf readiness relate to bundling definitions of app content and configuration, web interfaces to control this content and view collected data, and a having a FHIR-based framework for limiting access to data. By addressing these gaps we will address the problem of having to either use non-standards based information in digital health applications, or create a new application for different digital health projects. These features will give the community a single application that is configured through FHIR resources persisted on a FHIR API compatible server and managed through a server and app agnostic FHIR web interface.

 

ii. Objectives and Activities  

Below we describe 4 possible work packages, which we can choose amongst in collaboration with PATH and Digital Square based on the Global Goods community’s shared priorities.

 

Work Package 1: Load FHIR Implementation Guides to define Dynamic App Configurations

We use IGs to define a health app through the FHIR resources they contain and conventions dictating how those resources are interpreted by a FHIR smartphone app. This work package productizes the existing infrastructure for those capabilities by

• Extending the FHIR Web interface to allow users to create, read, update, and delete implementation guides (IGs) as a bundle or as individual FHIR resources via FHIR APIs (e.g. HAPI).

• Document how the resources in an app IG are interpreted by the FHIR Core smartphone app.

 

Work Package 2: Using PlanDefinition resources for FHIR based scheduling

Scheduling and task management are key functionality in healthcare mobile apps. These are well supported by FHIR, however the connection between the definition in FHIR and the workflow in-app needs to be clearly defined and documented. This work package expands scheduling functionality to less technically inclined health program managers through

• Syncing and workflows for PlanDefinition resource to define schedules using $apply to convert a tuple of PlanDefinition and Patient resources into the derived patient specific CarePlans and Tasks. Including the ability to view the CarePlans, Tasks, and update the Tasks’ statuses in the FHIR Core app.

• Logic and computation based scheduling encodes and more complex scheduling use cases, such as dependencies between vaccines and revised delivery or vaccine types due to missing vaccines. We can ideally encode these complexities using PlanDefinitions but expect there will be cases where we must use the more expressive CQL to 1) derive pre-requisite data to be processed by a PlanDefinition and 2) to the embed in a PlanDefinition as the schedule algorithm. We will extend existing workflow steps and document how to execute computation based schedules using CQL executed before and during the application of a PlanDefinition.

• Provide a scheduling example encoded as a PlanDefinition based on the routine childhood immunization under five programs we have partnered on with UNICEF and the WHO. This will demonstrate PlanDefinition scheduling with and without CQL, provide narrative documentation, and include video demos. The example will include the schedule of visits, touch-points, vaccines, and follow-up that is associated and defined in the PlanDefinition and its generated Patient CarePlan.

 

Work Package 3: FHIR Web Questionnaire resource and data management

The vision of FHIR Web is to enable local partners to define, edit, and manage health projects using FHIR. Essential to this is an interface for authoring and automatically extracting data from Questionnaires, which are the main driver of case based data collection in FHIR apps. This goes hand-in-hand with viewing the responses to those Questionnaires, the Patients generate from them, and exporting subsets of data for analysis, inspection, and integration. This work package addresses these extensions to the FHIR Web interface through:

• Integrated Questionnaire authoring, loading, display by documenting how to create Questionnaires with the open source form designer tool, allowing web based submission of Questionnaire data and generation of QuestionnaireResponse resources, and pre-populating Questionnaires with their QuestionnaireResponse data for viewing.

• Add support for executing data extraction from QuestionnaireResponse resources using in-line, data definitions, and structure maps extraction. This will include support to re-execute extraction when a QuestionnaireResponse is edited and re-submitted by using duplicate IDs, auto deleted-at setting, or another method as advised by the FHIR community. So that it can be run offline, the preferred implementation is in JavaScript (or a language that it compiles to) so that it can run offline on device, however we note that an on-line only server based version would require less effort to implement.

• Extending the FHIR data view to support filtering and grouping FHIR resources. For example, filter Patient resources to only view children without up to date vaccines, or only those ANC clients that have missed visits. This would also support grouping to only show Patient or Observations resources linked to a certain location or assigned to a certain team.

• Bulk exporting of FHIR resources in common data formats, such as CSV and JSON. We will design this to work with all FHIR resources and support exports of filtered data. We will verify and document through use-cases exports for the commonly used Patient and QuestionnaireResponse resources.

 

Work Package 4: Role-based access control managed by KeyCloak and FHIR APIs

Different members of the healthcare system have different access and roles for the clients they interact with. This is outside the scope of the FHIR API specification but essential to implementing a digital health system on FHIR. We have implemented user management and Authentication (AuthN) in FHIR Core and need to further expand this to limit access and roles through supporting Authorization (AuthZ) or role-based access controls (RBAC).  Deliverables under this work package will include:

• System design and community outreach for the “RBAC on FHIR” proof of concept.

• Implementing the roles on all FHIR endpoints. This will include a specification document for application to closed FHIR APIs (e.g. Google Cloud Healthcare and Azure Healthcare) as well as server-side code development, to demonstrate implementation as an extension of the open source FHIR server HAPI.

• Extend the FHIR Core mobile application and the FHIR Web application to interpret the FHIR RBAC data to limit access to patient data based on the provider’s assigned role.

iii. Deliverables and schedule

Ona is proposing a 12 month timeframe for this work that is made up as follows (we are only listing the estimated active development timelines now):

• Work Package 1: Dynamic App configuration (complete +2 months of active dev time);
• Work Package 2: Adding Scheduling to the FHIR Core App (complete +6 months of active dev time)
• Work Package 3: FHIR Web Enhancements (complete +8 months of active dev time)
• Work Package 4: Keycloak Support (complete + 12 months of active dev time)

 

iv. Risks and Mitigation

We are the first group, as far as we are aware, to create and deploy a FHIR native app that runs all computation and data storage in FHIR, on Android. With this pioneering role comes  risks around dependence  on other open source software, specifically the Android FHIR SDK and HAPI. These risks become more pronounced if we require a feature that is not currently implemented in that software. We will mitigate this risk through a primary strategy of continued close collaboration with Google’s Android FHIR SDK and SmileCDR’s HAPI software development teams. Our secondary strategy is to be able to extend these tools to add missing functionality in external libraries both as an interim solution when a more coherent integrated solution is preferred, or as a long-term solution when there is a stable interface between the existing software and our extension. We have successfully pursued both strategies over the past year of collaboration with Google, SmileCDR, and other partners, such as Alphora.

There is a further risk in that the novelty of this work leads to increased unknowns around timeline (often related to dependencies on external collaborators) and scope definition. For example, supporting peer-to-peer data transfer in the FHIR Core reference app required meaningful architecture changes to the Android FHIR SDK’s data access and storage interface, however this was only apparent after developing proof of concept code for a thoroughly discussed and community debated implementation plan. We will mitigate this through rapid iteration, scoping before and after writing proof of concept code, and proactive communication with all stakeholders. We will also use additional funding when out-of-scope issues arise that are relevant to related project needs.