Compliance Evaluation: openIMIS

Owned by Uwe Wahser
Last updated: Aug 30, 2024
7 min read

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

Release 2024-10

Tool Attributes

Logo

Name

openIMIS

Web

https://openimis.org/

Docs

Documentation

Download

Sources

BBs

Digital Registries

Email

contact@openimis.org

Installation Guide

Installation Guide

Container

GitHub - openimis/openimis-dist_dkr: The "all in one" packaged openIMIS (docker-compose)

 

 

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)

GitHub - openimis/openimis-dist_dkr: The "all in one" packaged openIMIS (docker-compose)

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

GitHub - openimis/openimis-dist_dkr: The "all in one" packaged openIMIS (docker-compose)

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

/

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.