/
Compliance Evaluation: openIMIS

Compliance Evaluation: openIMIS

Content

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

https://openimis.atlassian.net/wiki/spaces/OP/pages/3896836097/Release+2024-10

Tool Attributes

Logo

Name

openIMIS

Web

https://openimis.org/

Docs

https://openimis.atlassian.net/wiki/spaces/OP/pages/147390465/Documentation

Download

https://openimis.atlassian.net/wiki/spaces/OP/pages/368508929/Sources

BBs

Digital Registries

Email

contact@openimis.org

Installation Guide

https://openimis.atlassian.net/wiki/spaces/OP/pages/786104344/Installation+Guide

Container

https://github.com/openimis/openimis-dist_dkr

Β 

Β 

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

Status

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

II

Packaged as a container (Docker/Docker Compose/OCI)

https://github.com/openimis/openimis-dist_dkr

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

https://github.com/openimis/openimis-dist_dkr

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 https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/JBSmT2AWJq3vAm7orbdX/6-functional-requirements

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.

  1. API related field properties:

  2. 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

/