Notice C

Promoting the collaborative development of proposals for investments in digital health global goods

An Instant OpenHIE

Notice C Opportunity: 
Announcement C0: Global Good Software Development and Support
Proposal Status: 
Approved - Partially Funded

Overview

Instant OpenHIE will radically reduce the costs and skills required for software developers to rapidly deploy OpenHIE architecture for quicker initial solution testing and faster production implementations. Instant OpenHIE will be a simple way for technical persons to install and see a complex system working for a real use case. It will allow technical persons to illustrate how interoperability will work to solve health challenges and show how a national interoperability architecture could be created with open source tools.

Digital Square funding will produce a preconfigured version of the OpenHIE architecture and reference technologies, optimized for LMIC workflows, in hosted demonstration environment. Particularly it will be going to fund time to invest in installation options, rapid configuration scripts and in creating needed mediators to meet the project needs.

Executive Summary

The OpenHIE community and architecture has grown in popularity and so has the demand for both an example of the instantiated architecture as well as a deployable option for new implementers to engage with. OpenHIE maintains a stance of being technology neutral and encourages each community to source examples of reference applications for each of the components.

Therefore there isn’t a preconfigured example of OpenHIE, and each implementer has to go through an audrigious process of setup and configuration for each solution, and its interoperability layer, before they can begin to test OpenHIE architecture, much less deploy a suite its components.

Instant OpenHIE seeks to bridge this gap and work with community partners to create a framework and deployment approach that will allow implementers to rapidly deploy a set of software tools that represent the OpenHIE architecture, complete with basic configurations to allow for quick initial testing and faster production implementations.

Instant OpenHIE will create a packaged version of OpenHIE architecture that is comprised of a set of the reference technologies and other appropriate tools. The packaged version will also have a published set of workflows available and be preconfigured to a particular use case, such as HIV case based surveillance, to allow implementers to engage with the solutions and test their applicability. This is also a starting point for implementers to customise and extend OpenHIE architecture for future country implementations.

Consortium Team

Jembi will coordinate and lead the consortium and in an agile manner work with partners to align work streams and deliverables to match the overall solution goal and plans.

Jembi Health Systems NPC (Jembi)

Jembi is an African non-profit company, headquartered in South Africa, and specialising in digital health and open source software development and implementation. Jembi has a successful track record developing and implementing open source software in the health sector including a number of African countries. It has contributed to many open source software development projects, including OpenMRS, OpenHIM and OpenHIE. Jembi curates the reference technology for the interoperability layer of the OpenHIE - OpenHIM (www.openhim.org) and related reference profiles like Hearth (https://github.com/jembi/hearth).

  • Carl Fourie, Senior Program Manager, has 10 years experience with the architectural teams, providing insight and guidance, and currently leads Jembi's OpenHIE activities.

  • Pierre Dane, Director of Technology, has over 15 years of technical experience and leads Jembi’s technical division with a strong focus on systems development and interoperability

IntraHealth International

IntraHealth International is a global health NGO with a long history in developing successful data tools for digital health applications. From mobile apps to management software to multilanguage interactive voice response, IntraHealth offers health workers and managers the tools and technology they need to do their very best work. As the developers and core contributors of the iHRIS workforce management solutions, the OpenInfoMan reference product for CSD and Interlinked Registry, as well as the mCSD profile for the FHIR specification, the IntraHealth team brings a passion for open source and open standards. The following IntraHealth staff will be the organizational leads for this project:

  • Richard Stanley, Senior Technical Advisor, has over 20 years of experience in information and communication technologies, including high-quality research and rapid data analytics for monitoring and evaluations in Somalia, South Sudan, Uganda, Egypt, and Sudan. He holds a PhD from the University of Oxford, UK.

  • Luke Duncan, Digital Health Assistant Director, has over 20 years experience in software development, including leading the developing of iHIRS, the flagship human resources solution for global health, and multiple data interoperability standards and reference designs to connect iHRIS, DHIS2, and OpenMRS.

  • Emily Nicholson, Technical Advisor, has over 10 years of experience leading and supporting digital health solutions including mHero, iHRIS, OpenHIE, DHIS2, and OpenMRS.

Project Description

Background

OpenHIE (https://ohie.org/) aims to improve the health of the underserved through the open collaborative development and support of country driven, large scale health information sharing architectures. The OpenHIE architecture and approach to Health Information Exchange design has grown in popularity over the past few years with many countries adopting the model and base architecture as a guiding principle for the foundations of national health information exchanges. The OpenHIE architecture is modelled around a component based approach with there being distinct architectural components that are responsible for key functional areas.

Figure: OpenHIE Architecture

Each component is represented by a community with curated reference technologies. Each community aims to be open and have multiple options of tools and technologies that are supporting the component. OpenHIE is first and foremost an architecture and an approach to health information exchange solutions and this is a message that the broader OpenHIE community has worked hard to bring to the forefront.

Problem

As OpenHIE has grown in popularity so has the demand for both an example of the instantiated architecture, i.e software that works as the OpenHIE architecture and workflows describes, as well as a deployable option for new implementers to engage with. While each community maintains the options of reference technologies there is not an available package of tools that will allow users to see OpenHIE architecture in action and test the system to understand its applicability.

Each implementer has to go through an audrigious process of setup and configuration for each solution, and the underlying interoperability layer, before they can begin to test OpenHIE architecture, much less deploy a suite its components. Both Jembi and IntraHealth have faced this issue first hand as they work with OpenHIE architecture in their respective programs, and have heard frequent complaints form the wider OpenHIE community that there should be an easier way to implement the framework so implementers can test and deploy the architecture while they still remember why they’re interested in OpenHIE functionality

Solution

This project aims to create a deployable version of the OpenHIE architecture that is preconfigured to work together and provide a demonstrable instantiation of the OpenHIE architecture. The project team will canvas the OpenHIE community, review existing components and their configurations, and create a viable deployable selection of OpenHIE technologies.

The Instant OpenHIE project is segmented into the following areas that are interrelated and build into each other and off of each other.

Step 1: Architecture and workflows

Working with the OpenHIE architecture community the team will review the OpenHIE workflows and identify a popular use case with wide applicability. At this point, the project team is proposing to take guidance from a generic HIV Case Based Surveillance set of requirements to ground the instantiation in a real world setting. The team may realign the case should an implementation partner wish to engage alongside the project. Then we will develop the set of workflows required of OpenHIE architecture to execute the chosen use case.

Step 2: Packaging and containerisation

The team will review OpenHIE component functionality and identify a minimum set that are required to meet the established workflows. The team will review existing deployment options of each tool and other existing works such as the SEDISH work undertaken by the I-TECH Haiti and SolDevelo teams where some of the OpenHIE components have been dockerized already.

Through this phase the team will engage with the tools and align the deployment strategies as well as configuration options and mechanisms to allow an easier implementation and instantiation of the OpenHIE architecture.

Outputs

Instant OpenHIE outputs include an instantiation of the OpenHIE architecture using a combination of reference technologies and updated workflows. The outputs will allow the OpenHIE community to point to an instantiation of the architecture in a set of tools that are easily deployable for implementers to engage with.

An additional output is a version of the architecture in hosted demo environment for the OpenHIE community that can form the basis for compliance testing of new components and interoperability.

Another critical set of outputs will be workflows based on the OpenHIE stacks, to include those common in LMIC contexts like a linked health worker and a facility registry (interlinked registry), connecting patient records to the RapidPro communications engine, and case-based patient tracking.

Table of Outputs

Name/Type

Description of outputs

Targeted environment

Technology stack

Packaging, image hosting, and documentation

  • Updated containerization and VM-oriented packaging for OpenHIM, OpenInfoMan, FHIR servers, mediators, OIM libraries. (Mediators are not containerized while prototypes exist for others.)

  • Hosting of container images (e.g. Docker Hub) and other artifacts.

  • Open source build files for anyone to reproduce

  • Documentation

  • Governance of image hosting and other repositories established and transitioned.

Desktop Datacenter Public cloud

Docker, APT, Ansible and similar

Provisioning  with Docker compose and stack

  • Easy stack deployment for an HIE ecosystem using docker-compose and docker stack.

  • Documentation.

Desktop Datacenter Public cloud

Docker compose Docker stack, Shell

Provisioning with Kubernetes

  • Kubernetes manifests for deployments, services, ingress, secrets, and configmaps.

  • Code for public cloud deployment on one public cloud.

  • Documentation on deploying prototype on desktop and how to deploy to public clouds.

Public cloud

Kubernetes, Shell

Provisioning of underlying servers

  • VM or VM with Docker provisioning tools.

  • Documentation

Desktop Datacenter Public cloud

Vagrant, Terraform, Ansible, Shell

Configured workflow: RapidPro for patient reminders

  • Ready to use and reproducible tools to send reminders to patients in SHR or OpenMRS through RapidPro.

  • End-to-end test harnesses to demonstrate the workflow.

  • Documentation

Desktop Datacenter Public cloud

Shell

Configured workflow: Case-based patient tracking

  • Ready to use and reproducible tools to send track patients.

  • End-to-end test harnesses to demonstrate the workflow.

  • Documentation

Desktop Datacenter Public cloud

Shell


The development of packaged and deployable point of service or edge systems are out of scope of this project.

User Stories

The Instant OpenHIE project aims to address the primary needs of (i) allowing implementers to engage with a preconfigured HIE solution and running tools (based on the architecture) and test their applicability and functionality with a real health context problem; and (ii) having a packaged version of OpenHIE architecture that is comprised of a set of the reference technologies and other appropriate tools that form the building blocks of the HIE to be configured for particular use cases.

Below outlines the user stories:

Understanding OpenHIE Architecture

Sarah is part of a working group and project team that are responsible for investigating how to address a countries national health information system needs. Through their engagement they have highlighted a few key starting clinical areas that are covering many of the cross domain areas of work and data; such as human resources, facility information and identifying persons to name a few. Their working group has come across the OpenHIE architecture and workflows and would like to investigate it further. Sarah has been nominated to investigate the architecture and provide a review and technical demonstration of OpenHIE in action. While Sarah reaches out to other countries for opportunities to understand how OpenHIE has been implemented she also engages with the Instant OpenHIE deliverables. Sarah is able to provision a demonstration version of an OpenHIE architecture that is already configured to showcase a clinical workflow such as Case Based Surveillance.

Sarah is able to leverage the CBS Instant OpenHIE as a starting point for her implementation team, lead by Simon, to prototype and create a proof of concept solution that is contextualised to their setting and could be extended to meet the product need in future.

Testing OpenHIE Architecture

Sarah’s demonstration and implementation prototype has been successful and the working group has actioned a full scale implementation of the OpenHIE architectural solution for CBS for the country. Simon, team leader, is well aware that scale require innovative thinking around data centres and deployment architecture that is broader than “does the software do X”. Simon turns to the instant OpenHIE deliverables and leverages the packaged components and deploys them to the custom data centre architecture with the redundant services and load balancers required to maintain operations at scale. While the demo system covered the basics and the fundamentals Simon has extrapolated the learnings and configurations, identifying the pre-configurations that are not relevant to their deployment and which will be excluded from the live deployment, and engages with the clean deployment to customise the implementation and training materials to meet their needs. Simon works with Jeremiah (the technical and development lead) to ensure that any development changes are well understood and documented and changes are managed in the local implementations repositories (where the changes are not able to be contributed back to the core).

Digital Health Technologies

The project will leverage the OpenHIE architecture as the foundational architecture of the project and leverage the selected workflows from the OpenHIE workflows [https://wiki.ohie.org/display/documents/OpenHIE+Workflows]. The team will work with the architecture group and align to some of the workflows and emerging workflows that implementers have shown a strong interest in and the associated standards such as FHIR (http://fhir.hl7.org).

We are envisioning that the initial set of technologies under investigation will include, but are not limited to, the following tools:

The project team will investigate other tools and solutions for the architectural components during the course of the project.

Community Feedback:

The OpenHIE community currently has a strong set of communities around each of the components of the architecture as well as a strong architecture community. The team will continue our engagement in these communities as well as leveraging the OpenHIE devops community to support the work direction and ideas that are being used.

The team will provide regular updates and assessment reports on the calls and use the teams and members of the communities to guide and affirm decisions and directions. A full list of OpenHIE communities are found here: https://wiki.ohie.org/display/SUB/Home

In addition to the core OpenHIE communities Jembi and IntraHealth will work with the teams in each of our own organisations and partners who are engaging with OpenHIE core components and workflows to have their needs and inputs form part of the end solution.

It is envisaged that the OpenHIE DevOps space would be the best space to convene this project’s discussions and inputs.

Self-Assessment on the Global Goods Maturity Model:

The following review is for the OpenHIE architecture:

Digital Health Atlas

Below is a link to the registered project on the Digital Health Atlas

http://digitalhealthatlas.org/project/ZA548b7c72

Work Plan and Schedule:

Activity

Deliverables

M 1-2

M 3-4

M 5-6

M 7-8

M 9-10

M 11-12

Architectural Review and Tool Selection

An Instant OpenHIE Technical Architecture document: Documented HIE architecture, component technologies and workflows selected to be instantiated

Ongoing community engagement with OpenHIE DevOps community: community minutes

      
 

- Review architecture and tools

x

     
 

- Select tools to meet core architectural components

x

     
 

- Identify and select key workflows

x

     

Containerisation and deployment strategies

Document outlining:For each tool an updated containerised (or appropriate) instantiation methodology

The "containerisation" is committed back to the community

Updated documentation on the tools community documentation / website

links to solutions within each tool's space

      
 

- For each tool review and identify the appropriate container/deployment approach

 

x

x

   
 

- Work within the tools community to update or create standard deployment approaches

 

x

x

   
 

- Update tool's documentation and advocate for community uptake for ongoing maintenance

 

x

x

   

HIE configuration and workflow instantiation

Repository of configuration scripts:

- contains all configuration scripts required

- links to the documentation on how to utilise scripts

      
 

- Identify base configuration needs for each component and script the configuration options

  

x

   
 

- Identify workflow interactions and mediator, HIM and component requirements

  

x

x

  
 

- Create HIE workflow configuration scripting

  

x

x

  
 

- Create workflow integration test scripts

  

x

x

  

HIE instantiation and testing

Hosted Demo HIE set of services that are "stood up" and "refreshed" at selected intervals

      
 

- Action continuous deployment and "tear down" scripting to stand up HIE in hosted environment

   

x

  
 

- Test deployment scripting on local machines

   

x

  
 

- create documentation for cloud and local deployment

   

x

  

Use Case Configuration

Documented use case configuration needs

Updated repository with use case configuration scripts

Hosted HIE demo space with the use case demonstrated.

      
 

- work with use case subcommittees within OpenHIE to identify the configuration requirements

   

x

x

 
 

- create component configuration scripts to update "base" configuration to meet use case needs

   

x

x

 
 

- update integration scripts and test scripts to demonstrate the use case in action

    

x

x

 

- deploy updated scripts and documentation to repository and openHIE wiki for use

    

x

x

As the two teams leading on the work areas Jembi and IntraHealth will jointly address the work areas allocating work to each group as appropriate. Initially the work areas are envisaged to be allocated as follows:


Jembi

IntraHealth

An Instant OpenHIE Technical Architecture document

Both teams will create an agreed architecture and workflow design document that outlines the components selected and workflows to instantiate

Containerisation and Deployment Solutions:

Jembi will lead in the developing of solutions for:

  • Interoperability Layers

  • Shared Health Record

  • Client Registry

  • Facility Registry and DHIS (jointly work on this with IntraHealth)

IntraHealth will lead in developing of solutions for:

  • Health Worker Registry

  • ILR

  • ?Terminology Services?

  • Facility Registry and DHIS (jointly work on this with Jembi)

Workflow selection and configuration scripts

Teams will jointly select core workflows and allocate component configuration scripts as best suited to each organisation.

Initial component configuration scripts responsibilities are:

  • Interoperability Layers

  • Shared Health Record

  • Client Registry

  • Facility Registry and DHIS (jointly work on this with IntraHealth)

Initial component configuration scripts responsibilities are:

  • Interoperability Layers

  • Shared Health Record

  • Client Registry

  • Facility Registry and DHIS (jointly work on this with IntraHealth

HIE instantiation and testing

Responsible for hosting solutions

Responsible for kubernetes and instantiation scripting

Allocation of testing and integration scripts for workflows

Allocation of testing and integration scripts for workflows

Use Case Configuration

Document Use case requirements and configuration document

Contribute to use  case documentation

Update core component configuration scripts as allocated previously

Update core component configuration scripts as allocated previously

Develop integration tests for selected workflows

Develop integration tests for selected workflows



Project Deliverables:

The project will deliver the following high level outputs:

  1. A documented and deployable solution that is based on the OpenHIE architecture. This includes

    1. Updated documentation on OpenHIE wiki

    2. Updates to core components code and project site of appropriate install solutions (see table for types)

  2. Configuration scripts and solution to have the Instant OpenHIE meet the needs of a clinical use case (such as case based surveillance).


Deliverables

Timeframe

An Instant OpenHIE Technical Architecture document: Documented HIE architecture, component technologies and workflows selected to be instantiated

Month 1 - 2

Updated deployment and installation options for selected components

Month 5 - 6

Configuration scripts for each of the Instant OpenHIE components in a shared space/repository

Month 7 - 8

Hosted Demo HIE set of services that are "stood up" and "refreshed" at selected intervals

Month 7 - 8

Instant OpenHIE configured for particular clinical use case such as Case Based Surveillance

Month 11 - 12


Table of Outputs

Name/Type

Description of outputs

Targeted environment

Technology stack

Packaging, image hosting, and documentation

  • Updated containerization and VM-oriented packaging for OpenHIM, OpenInfoMan, FHIR servers, mediators, OIM libraries. (Mediators are not containerized while prototypes exist for others.)

  • Hosting of container images (e.g. Docker Hub) and other artifacts.

  • Open source build files for anyone to reproduce

  • Documentation

  • Governance of image hosting and other repositories established and transitioned.

Desktop Datacenter Public cloud

Docker, APT, Ansible and similar

Provisioning  with Docker compose and stack

  • Easy stack deployment for an HIE ecosystem using docker-compose and docker stack.

  • Documentation.

Desktop Datacenter Public cloud

Docker compose Docker stack, Shell

Provisioning with Kubernetes

  • Kubernetes manifests for deployments, services, ingress, secrets, and configmaps.

  • Code for public cloud deployment on one public cloud.

  • Documentation on deploying prototype on desktop and how to deploy to public clouds.

Public cloud

Kubernetes, Shell

Provisioning of underlying servers

  • VM or VM with Docker provisioning tools.

  • Documentation

Desktop Datacenter Public cloud

Vagrant, Terraform, Ansible, Shell

Configured workflow: RapidPro for patient reminders

  • Ready to use and reproducible tools to send reminders to patients in SHR or OpenMRS through RapidPro.

  • End-to-end test harnesses to demonstrate the workflow.

  • Documentation

Desktop Datacenter Public cloud

Shell

Configured workflow: Case-based patient tracking

  • Ready to use and reproducible tools to send track patients.

  • End-to-end test harnesses to demonstrate the workflow.

  • Documentation

Desktop Datacenter Public cloud

Shell


The development of packaged and deployable point of service or edge systems are out of scope of this project.

Tagging:

  1. Data interchange interoperability and accessibility

  2. Facility management information systems

  3. Health management information system (HMIS)

  4. Human resource information system

  5. Identification registries and directories

  6. Public health and disease surveillance system

  7. Shared Health Record and health information repository

  8. OpenHIE

  9. Architecture

  10. Packaging and deployment


Comments

Sounds like this could also generate documentation / best practices for OpenHIE components that have not yet adopted container technologies.

Will this work consider taking steps towards creating an official repository of containerized apps for the OpenHIE community?

Thank you for your concept note and we look forward to the full proposal. Please build in any reference to OHIE18 as appropriate as you finalize your proposal.  Please also specify how you anticipate harnessing the OpenHIE community and wiki to support this activity including hosting any final ouputs.

Thanks for your proposal! 

Since there are a number of technology choices (e.g. Docker, Kubernetes), we would suggest an assessment/community input activity to ensure concensus around the choices and a (brief) landscape of what openhie tools have been packaged using which tech.

As the proposal packaging would be reflective of different use cases/domains - how would these different packages relate to each other/how will dependencies be described?

What documentation or support will be provided for onboarding new tools/domains into the packaging system? How will you handle cases when there are more than one component that can play the same role in the architecture? For example in Debian packaging, there is a "Provides" feature. Are there any thoughts on how this packaging can be used to scale?

It seems like the Lorem Ipsum proposal should leverage this setup - perhaps combine the proposals and include Lorem Ipsum as a specific workpackage in this proposal. There are some potential opportunities for collaboration with the following poposals: https://proposals.digitalsquare.io/50, https://proposals.digitalsquare.io/85 and https://proposals.digitalsquare.io/70 as they may benefit from some productization.

We like this proposal and are trying to connect with this team as per our thread /discussion here re openHIM.
https://proposals.digitalsquare.io/54
Please let us know how we can help each other by collaborating on this.
Thanks
Tony

This proposal has the potential to enable multiple OpenHIE use cases. The proposed use case around HIV case-based surveillance is a high visibility / high impact activity in many settings given UNAIDS and WHO guidance on this topic, but itself depends on multiple other functions that are also still complex to configure. The proposed workplan implements the use case in the final two months, but more basic use cases can be identified along-the-way as well.

In a clinical (or health services delivery) workflow, robust capabilities for patient identification (e.g. probabilistic matching and biometric identifiers) would be an enabler. With an infrastructure/deployment perspective, technologies that allow integration of relatively simple facility based systems but with varying quality-of-service environments for connectivity and bandwidth may also be a critical enabler.    Please also include system wide concepts such as security and privacy considerations into account in options to configure a deployable instant HIE.