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"
- April 20-May 8:Concept note development
- 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.
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
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 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
- September 2020: Award Phase
Investment decisions are contingent on funder approval.