Notice E1 Client Registries

Notice E for promoting investments in digital health global goods

Under Notice E1, Digital square is accepting applications for investments in support of a fully functional, open-source and standards-compliant client registry that supports "Registration as a Service" and is designed to support longitudinal management of patient data in low- to middle-income countries (LMICs).  

The OpenHIE Architecture Specification frames a Client Registry as a solution to allow for accurate and efficient unique identification of patients. This is an essential function for a fully realized digital health architecture. A client registry (CR) is designed to support patient identity management and enables identities from disparate point-of-service applications to be linked to a unique Health Enterprise (HE) identity for each patient. 

Proposed solution must address and encompass the following technical and engagement scope: 

Functional and Interoperable requirements: the proposed solution must be compliant to all existing interoperable specifications as laid out in the OpenHIE Specification in relation to a client registry and allow it to operate within a health information exchange (HIE) environment as a client registry. The proposed functional requirements must meet all stated requirements of the OpenHIE Specification for a client registry. In addition, the solution must account for engaging with stakeholders and the OpenHIE Client Registry community to refine functional specifications and additional required functionality as well as aligning the interoperability functionality to meet the relevant Fast Healthcare Interoperability Resources (FHIR) profiles. 

Proposed solution may leverage existing works, software, tools, or products that provide the functionality of a client registry. The proposed solution’s technical designs must: 

  • show consideration for the development of the solution for scale and use at country level in low resource settings; 

  • make use of best practices to allow the solution to be used in low resource settings. 

  • Meet the functionality outlined in the OpenHIE Specification and cater to industry expected functionality for an MPI. 

Key features expected in the solution include: 

  • the ability to set matching algorithms and have bulk matching options;  

  • logging and full audit trails of all changes to both configurations as well as entities within the tool by users;  

  • have a functioning UI for administration of the system;  

  • have the ability to bulk import and export patients; 

  • have ability to merge and split patients as required. 

The proposal is expected to describe the key functionalities of the proposed solution. Applicants are expected to draw on their experiences to identify the depth of requirements and provide clear indication of these in the final submitted proposal. 

Installation and Deployment: the proposed solution should not only follow international conventions to support industry and enterprise installation and deployment patterns, but also must support the Instant OpenHIE deployment and configuration requirements to form part of the large infrastructure. This is inclusive of harmonized containerization approaches with the project, as well as scripted configurations and data sets (as required) to showcase the functionality of base use cases. The proposed solution must ensure alignment to emerging guidelines such as the DevOps and Cloud-Services guidelines.  

In addition, the solution must be built to support the installation quality aspects of implementation and ensure that functionality and documentation exist that allow implementers to validate that the initial installation of the tool is as per expected. Functionalities and artifacts could include documented “expected” state of successful installation, installation reports validating all services are operational, and initial system check tests to support successful and correct installation. 

Quality Assurance and Testing: the proposal must provide activities that encompass strong and empirical evidence of well thought out quality assurance patterns to validate functionality and provide a sustained and consistent base of evidence that the software both meets the functional requirements or feature sets but also is built as expected. The solution must strive towards having a documented testing strategy that outlining any major risk areas/business critical functions and strategies of testing to mitigate failure in these areas. This testing strategy should be operationalized in a testing framework that is applied against the tool in a repeatable manner and the QA plans and reports as well as available indicators outlining the level and coverage of testing should be available for review. At a minimum the solution is expected to work with the OpenHIE DevOps community and contribute and develop test in line with the conformance and testing framework of OpenHIE to showcase that the solution meets the interoperability and functional requirements (these tests are to be contributed to back to the OpenHIE community too). 

Product Information and Documentation: The solution must include the development of product information and documentation artifacts and cater to the required audiences.  

Key areas of documentation are: 

Product information: an outline in a summary form the key functions and value proposition of the tool and serve as a “quick access” document for decision makers to understand the value proposition and value gained from the tool (e.g., a brochure).  

Product Documentation: is inclusive of all aspects to support an effective and safe implementation and ongoing operations of the tool in the field. Documentation is inclusive of, but not limited to: 

  • Developer documentation (software design, patterns, etc.)  

  • Implementer documentation (installation guides, architectural implementation patterns for scale, implementation validation checks, etc.) 

  • Administrator guides (configuration option and descriptions of all features and options, etc.) 

  • User guides and operation manuals (outlining the functionality of the system as well as how it operates). 

Examples of investments that will be made available through this call for Applications include (but are not limited to): 

  • the development of new, or extension of existing solutions to meet the requirements laid out;  

  • engagement within the OpenHIE Client Registry community to refine the requirements and specifications that will drive the feature development that will be in the tool; 

  • development and identification of tests to validate the interoperability workflows as per the OpenHIE Specification;  

  • development of appropriate documentation to support the tool in use. 


Click here to access RFA #2020-020: Notice E1 "Client Registries"


Watch this Notice D video tutorial on how to create an account and upload a concept note

  • April 20-May 8:Concept note development 

    Digital Square issues a call for applications, and applicants upload concept notes to Digital Square's public-facing open application platform. In the first few weeks, as outlined by the solicitation, applicants will submit concept notes.  

    Applicants must use the concept note template

  • May 11-May 22: Concept note review

    In the few weeks following the concept note submission deadline, other applicants and/or other stakeholders in the community may provide feedback, comments, and suggestions, as well as identify potential areas for collaboration. 

  • May 25-June 5: Digital Square review of concept notes

    Following the concept note review, Digital Square assesses concept notes to ensure alignment with the initiative vision and funding objectives identified in the Notice. Digital Square eliminates concept notes that are not strategically aligned with the above. 

    Digital Square identifies a set of short-listed concept notes based on the Notice criteria and emails applicants who are eligible to advance to the application phase. 

  • June 8-June 19: Preliminary technical application co-creation 

    Using feedback received in the Concept Note Phase, applicants will begin preliminary application development. 

    Applicants must use the technical application template and post an application iteration on the open application platform in the first 2 weeks. 

    At the conclusion of this step, Digital Square will close the ability to upload new content to open application platform

  • June 22-July 3: Preliminary technical application comment period

    During this time, other applicants and other stakeholders in the community should provide feedback, comments, and suggestions.

  • July 6-July 24: Application finalization

    Using feedback during the preliminary technical application comment period, applicants revise the technical application, develop a budget and budget narrative, and submit these to the Digital Square open application platform. Applicants must use the provided technical application, budget, and budget narrative templates

    The budget and budget narrative are not shared publicly on the platform. Commenters see only the high-level summary budget provided in the technical application

  • July 27-August 14: Peer Review Committee (PRC) review 

    Digital Square groups applications for PRC scoring and technical feedback. Three PRC members will review each application. 

    The PRC reviews applications according to the Prioritization Framework, notice scope of work technical requirements and evaluates applications as green-, amber-, or red-lit per the PRC Membership Policy. Green-lit applications are recommended for funding immediately; amber-lit applications are recommended for future funding or further exploration; red-lit applications do not fully meet the selection standards/criteria. 

    The PRC sees only the high-level summary budget. Proprietary information including salaries, indirect rates, or other factors are not shared with anyone outside of the funder and Digital Square. 

  • August 17-28: Digital Square recommendation 

    Digital Square compiles the evaluation provided by the PRC by clustering the applications according to the Prioritization Framework for Governing Board Investment Review Committee (IRC) review. 

    Digital Square creates an investment package recommendation of the highly scored applications for the Governing Board Investment Review Committee based on the funding round objectives, donor priorities, and Digital Square vision. 

  • Per schedule: Investment Review Committee (IRC) review

    Digital Square presents the applications, high-level budget summary, PRC feedback within the Prioritization Framework, and Digital Square recommendation to the IRC 

    The IRC evaluates whether to approve the investment packages and reserves the right to modify the recommendation at their discretion.

  • September 2020: Award Phase

    Digital Square shares the investment decisions approved by the IRC with applicants. Upon applicant request, PRC feedback shall be shared with applicant. 

    Digital Square notifies the Governing Board of the IRC evaluation and investment decision. This step will occur during routine Governing Board communications. 

    Investment decisions are contingent on funder approval. 

Applications (5 total)

Displaying 1 - 5

CareCR (Afya Client Registry)

Two-sentence overview: 

The goal of the project is to develop Care client registry with online/offline capabilities while leveraging functionalities from existing open source tools like Medic CR, which is an open source tool Rasello has experience using and obtained an understanding to now cover gaps of function for a reliable open source client registry version as Care CR, noted gaps include but not limited to advanced configuration of matching attributes – extending from the list in Medic CR which will consequently improve deterministic matching. 

Rasello’s expertise in open source tools and technologies, application of principles of digital development and adherence to Open HIE guidelines will ensure to achieve effective and efficient functioning of Care CR, globally beneficial to in countries with limited health interventions.

Application Status: 
Not Approved

Client Registry Investment for the Government of Zimbabwe

Primary Author: Robert Gongora
Two-sentence overview: 

This work will concretely advance Zimbabwe’s vision for a unified, country-wide, patient-level data system by building on the Impilo platform (the Zimbabwean-designed and built national EHR platform) to create a central client registry (CR) for the Ministry of Health and Child Care (MoHCC) as well as package and distribute the improved CR as an open-source global good to benefit all. The MoHCC and Vital Wave will achieve this through an iterative and collaborative process by drawing on their existing partnership, complementary skills and expertise, and coordination with the broader digital health community. 

Application Status: 
Not Approved

openIMIS-based Client Registry

Two-sentence overview: 

The goal of this project is to increase the scope of the open-source Insurance Management Information System (openIMIS) by extending the beneficiary management module, which already deals with insurees’ personal and identification information, to respond to Client Registry’s (CR) requirements and standards, to be self-sufficient and, at the same time, compatible with the largest open-source programs for healthcare providers through the existing but yet to be extended openIMIS FHIR module. The team composed by Swiss Tropical and Public Health Institute (Swiss TPH), the designer and developer of the legacy openIMIS version, implemented in five countries, and experienced with Civil Registration and Vital Statistics (CRVS) systems, and SolDevelo, the developer of the openIMIS FHIR module and with experience in integrating health systems, will join their expertise to respond to OpenHIE project requirements in general and to OpenHIE Client Registry Community’s requirements and expectations. 

Application Status: 
Not Approved

Patient Registration and Identity Management Services for Health Information Exchanges

Two-sentence overview: 

IntraHealth’s new Open Client Registry (OpenCR) represents a foundational global good supporting identity management needs in low resource countries using leading technologies, including the powerful ElasticSearch engine and the reference standards-based HAPI FHIR server. Building on its successful real-world pilot, IntraHealth and partners Regenstrief Institute (an affiliate of Indiana University), Ona, and IntelliSOFT seek to expand OpenCR into a robust, high-value global good and field test it with select ministries of health through a consortium that includes unparalleled international design and deployment expertise in client registry and identity management as well as leadership within the OpenHIE architecture and client registry communities.

Application Status: 
Not Approved

SantéMPI Client Registry

Two-sentence overview: 

This project seeks to improve several key areas of SantéMPI, a robust and proven online/offline capable Client Registry (CR) solution with a rich global history, to strengthen the ability of Low and Middle Income Countries (LMIC) to adopt, sustain, evolve and scale this technology as a global good by: improving installation and configuration processes including localization, enhancing tooling for end-users to more easily customize deployments, upgrading standards support from FHIR R3 to R4, improving operational support through analytics and expanding community documentation.

Our organization and partners will contribute to achieving these goals by leveraging and applying decades of deep expertise and experience in open source digital health software including: software innovation, development, large-scale implementation, support and capacity building; development and use of open standards such as FHIR, IHE and OpenHIE; along with our in-depth experience developing and implementing the original MEDIC CR solution and evolving it into the next generation SantéMPI CR.

Application Status: 
Approved - fully funded