Content

1 Content
2 Tool Description
3 Evaluation Status
4 Tool Attributes
5 BB Compliance
- 5.1 Functional Requirements Digital Registries
  - 5.1.1 Key Digital Functionalities Requirements
  - 5.1.2 Cross-Cutting Requirements
6 OLD Integration Readiness
7 BB Compliance
- 7.1 Functional Requirements Digital Registries
  - 7.1.1 User Story 1 - Registry Schema User Interface
  - 7.1.2 User Story 2 - CRUD Data in User Interface
  - 7.1.3 User Story 3 - CRUD Data APIs
  - 7.1.4 User Story 4 - Registry Schema API

Tool Description

openIMIS is a digital public good which powers versatile solutions for the management of health financing and social protection programs. Designed to be interoperable with other information systems, openIMIS draws upon and contributes to Digital Public Infrastructure.

Evaluation Status

Status	CandIDATE
Date	2024-09-30
Reviewer	@Uwe Wahser @Dragos Dobre
Version	Release 2024-10

Tool Attributes

Logo
Name	openIMIS
Web	https://openimis.org/
Docs	Documentation
Download
BBs
Email	contact@openimis.org
Installation Guide
Container

BB Compliance

Functional Requirements Digital Registries

Key Digital Functionalities Requirements

	Requirement	Comment	Fulfillment

	Requirement	Comment	Fulfillment
1	(REQUIRED) Create a new register/database (via API or Web user interface); Go to requirement	feature is on the roadmap for next project phase
2	(REQUIRED) Create and configure the schema of the register (API or Web user interface); Go to requirement
3	(REQUIRED) Change schema configuration and publish the new version of the database and API services (API or Web user interface); Go to requirement
4	(REQUIRED) Enter data to the register (API or Web user interface); Go to requirement
5	(REQUIRED) View data records in the register (API or Web user interface); Go to requirement
6	(REQUIRED) Update data in the register (API or Web user interface); Go to requirement
7	(REQUIRED) Import/export data from/to external files; Go to requirement
8	(REQUIRED) Import/export registry database schema; Go to requirement
9	(REQUIRED) Create API services; Go to requirement
10	(REQUIRED) View statistics (API or Web user interface); Go to requirement
11	(REQUIRED) Inspect transaction log of registry data operations (API or Web user interface); Go to requirement	To validate
12	(REQUIRED) Manage access to registry data. Authorize users to see and edit registry records or data fields (Attribute-Based Access Control management); Go to requirement
13	(REQUIRED) Share data with other users via e-mail, or via a unique and secure Uniform Resource Locator (URL) sharing can be field level or record level. Go to requirement
14	(REQUIRED) Search data from the register; Go to requirement
15	(REQUIRED) Read data from the register; Go to requirement
16	(REQUIRED) Create data in the register; Go to requirement
17	(REQUIRED) Update data in the register; Go to requirement
18	(REQUIRED) Delete data in the register; Go to requirement
19	(REQUIRED) Validate if given content exists in specified register; Go to requirement	To validate
20	(REQUIRED) Read statistics. Go to requirement	To validate

Cross-Cutting Requirements

	Requirement	Comment	Fulfillment

	Requirement	Comment	Fulfillment
1	(RECOMMENDED) Open Cancel mandatory requirement: "Cloud-native, i.e. Docker and Kubernetes". Digital Registries must have also an on-site installation option. Go to requirement
2	(RECOMMENDED) Robust Operates in low-resource environments Cancel mandatory requirement: "Occasional power". In Digital Registries not possible, thus should be optional. This can be solved with backup power resources (UPS) and a generator that keeps the systems running without interruptions. Cancel mandatory requirement: "Low-reliability connectivity". Client-server systems are not reliable in this situation, instead additional hand held connection-less data capturing devices should be used and data reentered/uploaded to the servers when connection is restored (not covered in this version scope). Go to requirement
3	(RECOMMENDED) Databases must not include business logic Cancel mandatory requirement. "no triggers/stored procedures shall be used". Some stored procedures may be needed for database record ID generation. Go to requirement
4	(REQUIRED) Privacy and protection of user data Add mandatory requirement. The following requirement should be added to other Building Blocks' cross-cutting requirements: Each owner of the personal data (e.g. citizen) must be able to see who has looked at their personal data in the registry. All captured personal user data must be marked as “personal data”. Users can make requests to see the information/logs of accessing personal information. API must be available for authenticated users to see their own personal data audit logs. Go to requirement

OLD Integration Readiness

This is an evaluation according to the levels of integration that were defined for the last wire frame proof of concept. (compare attached slide-deck)

Level	Criterion	Status	Comments

Level	Criterion	Comments
I	Authentication, e.g. SAML <-> JWT in HTTP headers
	Filtering and aggregation logic
	Adapter must publish static OpenAPI spec to Information Mediator, including JSON Schemas	openAPI format: FHIR Implementation Guide format:
II	Packaged as a container (Docker/Docker Compose/OCI)
II	Include a complete OpenAPI/Swagger specification to be published to GovStack peers though the information mediator. Must include descriptions of all exposed APIs with schemas for payloads, including examples.
III	Must have an accepted rating as a digital public good
	Web-Hooks
	Docker packages
	GovStack needs to be able to build the package & analyse the source
	GovStack BB specific requirements	see below

BB Compliance

Based on the current version in

Functional Requirements Digital Registries

The specification of the Building Block in its current version are not yet validated against real world relevance. Major changes in the requirements might occur in subsequent versions of the standard. Especially the paradigm of a fully programmable RDBMS without any business logic does not meet real world requirements and would systematically exclude most existing Digital Registry DPGs where the value lies in configurable best practice algorithms for specific registry types e.g. patient registers or social beneficiary registers.

User Story 1 - Registry Schema User Interface

Req-#	Criterion	Status	Comments

Req-#	Criterion	Status	Comments
DRS-1	Analysts must have the option to create a new registry database		feature is on the roadmap for next project phase
DRS-2	Analysts can create multiple databases into one system instance.		feature is on the roadmap for next project phase
DRS-3	Fields of the database must contain at least the following elements: Field name;Field type; Field properties
DRS-4	Analysts must have the option to publish the database. Publishing will reveal the database to users.		feature is on the roadmap for next project phase
DRS-5	Analysts must be able to configure the API services per registry database.
DRS-6	Analyst must have the option to manage user rights of a database and data via API and via UI.
DRS-7	The system must log all data processing in the database.
DRS-8	Personal Data usage. System must automatically store all data read requests and store these in log table.
DRS-9	Analysts must be able to create views of a database	( )	reports
DRS-10	Must have the option export database schema to JSON file		feature is on the roadmap for next project phase
DRS-11	Must have the option to import database schema from JSON/XLS file		feature is on the roadmap for next project phase
DRS-12	Service usage statistics
DRS-13	Analyst must be able to mark a field as PersonalData log object- This field contains personal data.
DRS-14	Analyst must be able to mark a field as PersonalDataID. This is the data owner’s ID.
DRS-15	Analyst must be able to mark a field as secret- This field contains secret data (credit card number).
DRS-16	Analyst must have the option to read database schema in the web UI.		FHIR Implemention Guide
DRS-33	Analyst has capabilities to configure database field properties. API related field properties: UI related field properties:
DRS-34	Analyst must have capabilities to add encryption key per database.
DRS-35	Analyst must have capabilities to automate data exchange between databases internally and externally via API.		this should be a requirement for an information mediator
DRS-36	Analyst may have capabilities to use database schema templates so that the registry creation is faster.		this is redundant to scheme export/import

User Story 2 - CRUD Data in User Interface

Req-#	Criterion	Status	Comments

Req-#	Criterion	Status	Comments
DRS-17	Analysts must have a view to see all data in the registry.
DRS-18	Analysts must have a view to edit data in the registry. Analyst must have option to delete data in the registry.		this should be two distinct requirements with specific conditions for deletion
DRS-19	Analysts can use additional functions to simplify data searching
DRS-20	Import data to the registry. Analyst must have an option to import information to the database. Import formats are: json, csv, xls.
DRS-21	Export data from the registry. Analyst must have an option to export selected/filtered data from a registry to CSV, XLS, Json.
DRS-22	Statistical queries. Produce standard statistical reports Allow the analyst/user to analyze data collected in the system	/	reports are done in openIMIS, but actually this functionality belongs to Analytical & Reporting BBs
DRS-33	Users can share data with other users. Share data with other users via e-mail, or via unique and secure URL.	/

User Story 3 - CRUD Data APIs

Req-#	Criterion	Status	Comments

Req-#	Criterion	Status	Comments
DRS-23	BB must enable client systems to process (CRUD) the database records via Open API services.	/	that’s a general GovStack requirement for all building blocks
DRS-24	BB must have an Open API service list (Swagger) to visualize all API services and API service versions.	/	that’s a general GovStack requirement for all building blocks
DRS-25	System must have an API for PersonalData usage report.
DRS-26	Statistical queries via API.	/ /	we do have / are working on this, but that’s a general GovStack requirement for all building blocks
DRS-27	Using viewing event logs- every data owner has the right to see who has looked at their personal data.

User Story 4 - Registry Schema API

Req-#	Criterion	Status	Comments

Req-#	Criterion	Status	Comments
DRS-28	Developer must have the option to create a new registry database by sending data via API.
DRS-29	Developer can create multiple registry databases into one system instance.
DRS-30	Developer must have the option to publish the database.
DRS-31	Developer must be able to modify API services per registry database.
DRS-32	Developer must have the option to read database schema via API. Developer must have the option to read the list API services available per Database.