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