The OpenFn Integration Toolkit is used to facilitate data integration and interoperability across secure systems in 40+ countries, but many users still rely on the OpenFn iPaaS (proprietary software that sits on top of the Toolkit) or extend the Toolkit via other software to produce a user-friendly and standards-compliant audit trail interface, a key requirement for many government and iNGO OpenFn implementations.
Through an expansion of our current collaboration with JSI Ethiopia’s team in Addis, the Ethiopia Digital Health Activity (DHA), and the Ethiopian Ministry of Health, we propose to introduce full Audit Trail and Node Authentication (ATNA) compliance to the OpenFn Integration Toolkit so that it’s available out-of-the-box for future implementations of this digital public good.
The OpenFn Integration Toolkit is a digital public good (DPG) that can be used to connect any application (e.g., DHIS2, OpenMRS, OpenHIM, CommCare, custom databases, legacy MoH systems, etc.) and currently automates critical business processes (e.g., sending real-time SMS/email alerts, making case referrals, uploading health indicator results, etc.) for governments and NGOs around the world. Most implementations, however, rely on a combination of the technologies provided by this free and open source software (FOSS) and the OpenFn iPaaS. The latter is proprietary software, built on-top of the Toolkit, which extends its functionality.
What will this investment from Digital Square specifically go toward?
Recently, external investments have significantly strengthened the FOSS-only implementation pathway provided by the Integration Toolkit, but there is work to be done. We are seeking an investment to provide full ATNA compliance as an out-of-the-box feature in the Toolkit, reducing local partner’s reliance on custom logging extensions or proprietary software. Concretely, we will introduce a web-interface and corresponding APIs that make audit trail generation (for both transactions and activities—things like logins, updates to project specifications) and implementation management easier.
What are the goals of the project?
Our goals are to reduce implementation costs related to achieving ATNA compliance with projects that use the Toolkit, to streamline implementation management through a more robust web interface and set of maintenance APIs, and to develop a guide or framework for inter-organizational collaboration on key elements of the Toolkit.
How will the goals be achieved?
We will achieve these goals by grounding and assumption-checking our user stories with actual implementation needs. We have a unique opportunity to collaborate with the team implementing the Ethiopia Digital Health Activity (DHA) and are currently nailing down key integration and interoperability use cases to be delivered over the next 12 months. Leveraging these existing partnerships, our knowledge of the varied use cases that must be implemented in this broader health systems strengthening initiative, and our ability to keep the cycle between product development and implementation very short, we’ll have a significant advantage over “lab only” product development.
How will OFG’s expertise contribute to achieving the project goals?
Open Function Group (OFG) is a team of integration specialists that drives efficiency in the global health sector by helping governments and NGOs achieve real-time, enterprise-grade systems interoperability through integration and automation. We have served as the primary custodians of the OpenFn Integration Toolkit to date, convening and serving alongside members from DIAL, Regenstrief, USAID, UNICEF, and Dimagi on the Toolkit’s steering committee, and have facilitated contributions from external organizations such as Dimagi, Last Mile Health, and the Swiss Tropical and Public Health Institute. We have also implemented the Toolkit at scale with a large number of partners around the world, and our intimate knowledge of the implementation/consulting process required for data integration/interoperability projects drives our product vision.
OFG will lead the consortium, dedicating additional product-development resources alongside the existing project implementation resources that are working on the DHA Ethiopia use cases at the moment. Having gathered significant product roadmap feedback on the Integration Toolkit over the last year, we’ll supplement implementation requirements from the health system strengthening use cases in Ethiopia with these big-picture demands from the sector and maintain open communication between the product and implementation-teams throughout the course of the project.
The Ethiopia DHA team has deep technical expertise and has been working on data integration and interoperability problems in Ethiopia for years. They have experience managing relationships with government ministries, working with additional vendors, and helping to strengthen local capacity to implement national-scale IT projects.
While OFG brings a powerful implementation methodology and unrivaled OpenFn Integration Toolkit expertise to the table, the DHA team brings an enormous wealth of cross-platform technical capacity and years of on-the-ground experience implementing successful IT projects with government ministries in their own country.
Background or problem statement
OFG aims to fundamentally transform the “technology for international development” (ICT4D) sector through integration and automation. Institutions often lack the capacity to design and implement projects that effectively leverage the existing digital ecosystem—blocking access to critical, accurate, and timely information, and encouraging wasteful investment in redundant ICT4D application development. They are often locked into slow, error-prone manual processes or they spend thousands of dollars every time they want to move data between different systems. OFG is creating a new paradigm in which NGOs, governments, and social businesses can automatically, securely, and cost effectively implement integrations between systems in hours or days, not months, no matter their level of technical expertise, compliance requirements, or budgetary constraints.
First released in 2014, OpenFn is an enterprise-grade (S3) integration-platform-as-a-service (iPaaS) on which organizations can connect technologies and automate critical workflows. OpenFn is flexible, scalable, and connects any app. Its configurations can be easily modified, replicated, and re-used—delivering quick, adaptable, and cost-effective integration and automation solutions. OpenFn is used by leading global health organizations worldwide, but it isn’t appropriate for some organizations with particular resource or open source requirements. (OpenFn is “open-core”, but includes proprietary components.) To ensure these organizations can also achieve robust data integration and automation, OFG has significantly strengthened the FOSS-only deployment pathways provided by the OpenFn Integration Toolkit with technologies like OpenFn/core, OpenFn/engine, and OpenFn/microservice.
While the fully-FOSS pathway provided by the Toolkit still saves organizations time and money, it still lacks many features “out-of-the-box” that are required for long-term success in large-scale, high-sensitivity projects. Critically, an existing OpenFn/microservice deployment requires additional work on the part of the implementer to be ATNA compliant. ATNA compliance requires four foundational components: node authentication, access control, event logging (audit), and secure communications. Unless OpenFn/microservice can provide (and prove that it provides) adherence to ATNA out of the box, implementers will be forced to build this compliance on top of the Toolkit or provide it by extending the Toolkit with other software.
Objectives
To provide robust, scalable, secure, and FOSS integration options to all digital health implementers, OFG seeks funding to (1) reduce implementation costs related to achieving ATNA compliance with projects that use the Toolkit, (2) streamline implementation management through a more robust web interface and set of maintenance APIs, and (3) to develop a guide or framework for inter-organizational collaboration on key elements of the Toolkit.
Deliverables & Schedule
To achieve the envisioned outcomes, OFG proposes the following work packages.
|
No. |
Deliverable |
Schedule |
|
WP 1 |
RESTful ATNA Compliance |
8 weeks |
|
1.1 |
Stepping through all 4 foundational components of ATNA, we’ll target RESTful ATNA (https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RESTful-ATNA.pdf) for query and feed support. This will later be used by our own front-end in a UI. |
Weeks 1-8 |
|
WP 2 |
RESTful Project Maintenance |
4-8 weeks |
|
2.1 |
Endpoints for reconfiguring projects on-the-fly (updating project.yaml specifications) must be developed, per feedback on the existing re-deployment/re-configuration options. |
Weeks 8-12 |
|
2.2 |
Additional maintenance APIs may need to be developed as requirements are nailed down across the DHA use cases. |
Weeks 12-16 |
|
WP 3 |
A Web UI for the Integration Toolkit |
6 weeks |
|
3.1 |
Development of a minimal web interface with login, management, and audit trail viewing/exporting capabilities will be shorter as it will consume the APIs developed in WP1 and WP2. |
Weeks 16-22 |
|
WP 4 |
Collaboration Guide |
3 weeks |
|
4.1 |
As this will be the first major external collaboration on the a central product in the Integration Toolkit, we’d like to document the collaboration process and prepare a guide for future contributors with an aim to make contribution to the Toolkit easier and more commonplace. |
ongoing |
Risk Mitigation
By aligning this project with an actual implementation in Ethiopia, we’re hoping to mitigate the risk that what we develop isn’t useful in the near term—that it’s detached from the real end-users requirements. This, however, brings forward an entirely new set of risks related to the balance between long-term goals and short term objectives.
Both OFG and the DHA will need to keep the appropriate amount of separation and autonomy between their implementation teams and product development teams to ensure that neither jeopardizes the success of the other. There will be pressure to deliver more specific features that might have lower long-term reuse value, and we’ll mitigate this risk by maintaining regular communication with our Open Source Steering Committee and the other OpenFn Integration Toolkit users as the user stories emerge, are collected into sprints, and are developed and tested as features.
We aim to measure uptake both within Ethiopia and across other OpenFn implementations as a way to get an indication of the long-term value of the new features.
Comments
Digital Square comments
Suggesting working with DHA Ethiopia to develop an implementation agnostic feature then later customize it for use in Ethiopia and use that as a case study rather than doing the opposite, and this has to be reflected in the full proposal, considering specific implementations are not funded through this mechanism.