An Instant OpenHIE

Jembi Health Systems NPC and IntraHealth International Inc collaboration

Table of Contents

Overview 2

2 Sentence overview: 2

Executive Summary 2

Consortium Team (2-3 paragraphs) 3

Project Description 4

User Stories: 7

Digital Health Technologies 8

Community Feedback 9

Self-Assessment on the Global Goods Maturity Model: 10

Digital Health Atlas 10

Work Plan and Schedule: 10

Project Deliverables 13

Tagging 14

Physical Address Tokai on Main Office Park, Units 3b, 5a-5c, Main Road, Tokai 7945,                           Cape Town Postal Postnet Suite 280, Private Bag X26, Tokai 7966, South Africa Tel +27 (0)21 701 0939 Fax +27 (0)21 701 1979 E-mail info@jembi.org Website www.jembi.org  Jembi Health Systems NPC   (Reg#: 2009/018985/08) a not-for-profit company registered in South Africa  (NPO#: 054-906-NPO) (PBO#: 930034124) (VAT#: 4480259243) Directors: S Reid (Chair), D Moodley (Vice-Chair), CJ Seebregts (CEO), A Gray, N Gasa, D Morkel 

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.

2 Sentence overview:

An 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.

The funding of Instant OpenHIE will be going towards investing time in the configuring of existing tools and components to work together and making the outputs available to others so that they don’t have to do this again. 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 (2-3 paragraphs)

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.

We are interested in partnering with other groups providing their tools as compliant to the OpenHIE workflows and as reference technologies.

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 manifests for Public cloud Kubernetes,

Kubernetes 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.

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:

● OpenHIM (MPL v2 License) [http://www.openhim.org] ○ Associated workflow mediators

● Hearth FHIR Server (BSD 3-Clause) [http://www.github.com/jembi/hearth] ● OpenInfoMan (Apache License 2.0) [https://github.com/openhie/openinfoman] ● ApelonDTS (Apache License 2.0) [http://www.apelondts.org/]

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 The project has been registered here:

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

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

- Work within the tools x x

community to update or create standard deployment approaches

tools community documentation / website links to solutions within each tool's space

- 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

a) Updated documentation on OpenHIE wiki b) 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

Desktop Datacenter Public cloud

Docker, APT, Ansible and similar

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.

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