Notice F2: Shelf readiness with a focus on building local capacity and new teams.

Closing the loop in digital health content with FHIR native apps for deploying SMART Guidelines content

Primary Author: Peter Lubell-Doughtie
Two-sentence Overview: 

Our goal is to make our FHIR native mobile and web application plug-and-play, through application and content configurations described through compatible FHIR implementation guides (IGs), based on the WHO SMART Guidelines. We will achieve these goals by building on our ongoing work in partnership with the WHO and Google to develop reference apps (based on existing WHO guidelines, the SMART Guidelines, and the Android FHIR SDK) that execute FHIR native content on smartphones.

Executive Summary: 

This Digital Square investment will go towards extending the FHIR Core mobile application, the FHIR Web web application, and a library of HAPI FHIR extensions to support essential use-cases for digital health deployments. This investment will advance the shelf-readiness of the FHIR Core global good by adding app definition and loading through:

  1. FHIR Implementation Guides (IGs)
  2. Simple and complex scheduling and examples through FHIR PlanDefinition resources
  3. FHIR data management on the web, and
  4. FHIR data access controls based on role.

Each of these four work packages will include documentation, co-design and cross-collaboration with the Android FHIR and SMART Guidelines community, as well as narrative use case demonstration videos.

The goal of the project is to close the gap between the critical features for production digital health apps and existing FHIR native apps, using the OpenSRP FHIR Core, FHIR Web and HAPI extensions as the reference. We will achieve this goal by extending our existing proof of concept FHIR native applications and deploying them to the field with local health implementing partners. In our development process we will collaborate with the SMART Guidelines and FHIR communities to follow existing best practices and add new standards when encountering use-cases that are not already addressed by the FHIR standard.

As co-architects of the WHO SMART Guidelines approach, the Android FHIR SDK, and the technical lead for OpenSRP, Ona has established a track record of being able to move standards from the round table to the field in a manner that empowers local technical teams and the health implementers they partner with. Our expertise in open source community building, health systems technical architecture from last mile to facility, code quality, documentation, and open systems infrastructure management are the critical factors in making this work a success. Furthermore, the work packages we have designed are accretive with our existing and ongoing project and partner priorities and in direct alignment with the established work plans for the OpenSRP community of partner organizations.

Consortium team: 

Ona is a technical social enterprise focused on global health and data solutions, based in Nairobi, Kenya, and Burlington Vermont. Ona has over 70 employees and extensive experience designing, developing and implementing health information systems that are used at national scale and integrate with existing government health information systems and open standards. Ona has developed numerous open source tools and libraries that are used by mobile teams to add functionality to their existing technologies. Ona serves as the technical lead for OpenSRP, having co-created the platform with the World Health Organization and other partners. For these proposed four work-packages, we will collaborate with the existing Android FHIR SDK and SMART Guidelines communities. If we have a need for additional support we will reach out to partners in those networks as well as in the OpenSRP community.

Ona has developed close working relationships with an expanding network of local technical partners. This includes BlueCode in Zambia, 1000Hills Solutions LTD in Rwanda, mPower Social in Bangladesh, VentureDrive in Pakistan, Softmed and D-Tree International in Tanzania, HISP, Jembi Health Systems and Compelling Works in Malawi. All of these parnters have successfully developed and supported the roll out of OpenSRP implementations in their respective countries.  While all will not be directly involved in this initial effort, they are all committed to working with us to adopt FHIR Core on projects moving forward.

We are also partnering with Google and Alphora to architect Android interfaces for FHIR operations and CQL that follow health standards while meeting technical implementer’s needs.

Project Description: 

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.

Application Status: 
In Scope

Comments

Kindly find herewith Ona's submission for Notice F2 - Shelf Readiness

Thank you

Thank you for the application. For the full technical application, in addition to general recommendations per the email, please:

-Ensure potential dependencies on outside groups are clearly identified with mitigation plans, where needed, as well as dependencies across work items/sequencing of work.

-Ensure activities to identify user needs, acceptance criteria, to design with users, etc. are clearly identified in deliverables/the schedule. (For work that's already been done, this can be noted as inputs to the work.)

-Ensure it's also clear how this work is expanding local capacity and adding new teams, beyond what would already likely be happening.