Skip to main content

Instant OpenHIE

Overview

In partnership with Digital Square and FCDO COVIDaction, OpenFn has been investing in its open source integration toolkit to provide robust integration solutions that can connect any digital health system and be rapidly implemented on any server, in any country, by any organization.

OpenFn/microservice is a fully Instant OpenHIE compliant component which can be used to drive workflow, achieve compliance with standards, and integrate components of the OpenHIE stack.

We seek to enhance the value of the Instant OpenHIE project by developing a package that will include OpenFn as an integration pathway for connecting with the OpenHIE architecture.

This package aims to enhance the value of Instant OpenHIE by providing another option for robust information processing, integration, and business process (workflow) automation. When deploying Instant OpenHIE, implementers now have the option to include OpenFn as a component.

OpenFn may also be used as a workflow engine to automate complex business logic alongside OpenHIM and the OpenHIE stack. Individual jobs in OpenFn, sometimes many in a single microservice deployment, may be used as “mediators” (see OpenHIE library of existing mediators) to quickly transform and map data to the OpenHIE architecture.

To demonstrate a real-world use case for how OpenFn might be implemented in the OpenHIE architecture, we met with several community members to identify key use cases for a reference prototype implementation.

Visit the demo repo here.

Use Cases for the Prototype Implementation

We’ve seen that the most common integration use case is that health service delivery providers, especially large community health worker (“CHW”) interventions, need to integrate their data and programming into national eHealth architectures.

User stories

  1. As a community health implementer, I want to integrate my CommCare case management application used by CHWs with the national patient registry, so that I can develop a shared health record and automate reporting pipelines.
  2. As a health services provider, I want to integrate my existing application with the national HIS, but I want to apply the FHIR standard to my data collected before sharing to adhere to compliance and reporting requirements.
  • We therefore decided to build an integration solution that demonstrates how existing CHW applications can be integrated with the national health infrastructure and leverage a simple job on OpenFn as a mediator to apply the FHIR data standard and other data manipulation needed to integrate with HAPI FHIR.

Implementation Design

In sum, the prototype sends patient case registration data from mobile data collection apps (CommCare, KoboToolbox) to OpenFn/microservice. OpenFn then transforms the data and ensures that it adheres to the FHIR patient and encounter data standards, before sending it onwards to a FHIR channel in the OpenHIM. OpenHIM is used as a _“channel”_ here for the OpenHIE architecture to validate requests and forward them onto other systems in the national eHealth architecture. In this case, we forward the case data onwards to register the patients in a HAPI FHIR server.

This implementation design was determined to be the highest value/most in-demand because it leverages the core functionality of OpenHIM (providing a reverse proxy and generating an audit trail) without requiring integrators to build a new mediator—a process that is more complex than configuring a job within an OpenFn project.

This prototype includes the following components:

An Instant OpenHIE instance can be spun up which contains HAPI FHIR, OpenHIM, and a single OpenFn/microservice deployment (a project.yaml file, exported from OpenFn/platform) with 2 different jobs. When data is forwarded to OpenFn/microservice from two distinct form submissions on CommCare and Kobo, it is processed and creates FHIR patient resources via OpenHIM and HAPI FHIR. We’ve opted for a single OpenFn/microservice “project” with two slightly different jobs and triggers to highlight the versatility of OpenFn projects.

Explore the Implementation

Currently, there are two different ways to explore this demo. The first (the more traditional “Instant” way) is by cloning the OpenFn/instant-demo repo. Once inside, users type “yarn setup” to get everything up and running. Running “yarn test” will then demonstrate the Kobo/CommCare to OpenFn to OpenHIM to FHIR flows.

They can explore the various jobs, sample payloads, endpoints, and post data to the various endpoints using either the data forwarding settings in CommCare and Kobo or via CURL (or their HTTP request agent of choice.)

Once running, users can see how standard CommCare and Kobo submissions are transformed by the OpenFn/microservice to adhere to the FHIR specifications for patients and encounters, and then that those subsequent resources are created on the HAPI FHIR server, via a channel on the OpenHIM.

The second (slightly less conventional way) to explore the demo, is via OpenFn.org. Since OpenFn projects can be run in microservice or on the hosted platform, we’ve provided a project instance at OpenFn.org that allows users to explore the configuration required to incorporate OpenFn in an Instant OpenHIE project. There are three jobs which can be accessed with a demo user with username: demo@openfn.org and password:guest123.

The three jobs will show:

It’s our hope that this will provide a valuable entry-point for Instant OpenHIE configuration with OpenFn/microservices.

About the Implementation Setup

Processes

Project Configuration Steps

There are two ways to set up a project.yaml to run as a microservice. The first is to use the OpenFn.org platform, and the second way is to use OpenFn/devtools.

These two methods are detailed below:

  1. Configure a project using the OpenFn.org platform

  2. Configure a project using the OpenFn/devtools

Job writing notes

OpenFn provides two ways of writing jobs:

System Deployment Steps