/
Modular Architecture [Notes]

Modular Architecture [Notes]

Overview

Module Overview

Result of Deep Dive 2022-09-08

Rework and preparation for follow-up Deep Dive sessions

 

Definitions

Term

Definition

Term

Definition

Module

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

Source: https://en.wikipedia.org/wiki/Modular_programming

(Software) Package

A collection of functions written in a single language bundled with additional content like documentation, unit test, sample data etc.

Source: https://en.wikipedia.org/wiki/Package_development_process

Component

An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data).

Source: https://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component

Sources

Technical source code, structures and definitions of an IT solution

(JLN) Business Process

 

Functional Unit

An interchangeable unit that provides a piece of business functionality

(Software) Repository

A storage location for software packages & other technical sources

Source: https://en.wikipedia.org/wiki/Software_repository

Key Questions

  • How to find a wording which is clear and prevents misunderstanding and allows for a common language between business (implementers) and technical (developer) people?

  • How to achieve an up-to-date documentation of the architecture and it’s features (modules) which satisfies and links the needs of implementers and developers

Key Findings

Many things are called a “Module”, but a clear definition is missing
Repositories/Deployables in Sources Release 2022-10 were called modules before despite covering many aspects (FE, BE, DB, tools, core, assembly/configuration, docker)
Towards non-IT people a module is a unit of functionality covering a business/domain aspect such as a process (Claims, Calculations) or an entity
It is hard to understand what modules are out there and which are optional, configurable, customizable and so on
Documentation of the modules/features is fragmented, outdated and incomplete
Dependencies (repositories) are missing
An overview of modules is missing
Linkage to business processes (e.g. JLN) is missing or incomplete
Link to the technical (code) documentation is missing
History (change log) and linkage to Releases is missing
The software architecture is only documented in Target (modular) Architecture out of the perspective of a future development (Modular Transformation), not as something that exists as part of the product and seemed to be not actively maintained / updated

Findings

Module pages under openIMIS Modules do not share a common structure / content
Use of property tables seems advisable
Overview in openIMIS Modules uses color coding without providing an explanation (types of modules like Core, Interop, Business, ??)
Linkage between “Modules” and Repositories unclear / Dependencies are not documented
Definitions unclear, what is a “Module”?
What is the bare minimum a module must provide? What are the key features? Interfaces, etc.?
What principles are followed to define what is part of one module, but not of an other?
Relationship to “Repositories” and other modules
Are there different types? Which?
Is the module configurable/customizable? On a technical level or from a business perspective?
Is the module optional? Is there a choice of different modules (e.g. FHIR version)?
If a (business) is an abstract bracket around repositories, does it have a version number? How to tell if the “module” is still compatible to the rest of the system?
Sources Release 2022-04 lists repositories as “Components” (renamed from “Module”)
Multiple modules under openIMIS Modules seem to be outdated and incomplete, are not separately documented, but mixed with other “Modules”
Modules under openIMIS Modules are organized in a complex but incoherent structure (e.g. sometimes grouped by business process or other)
Modules under openIMIS Modules do not follow a consistent naming format
Modules under openIMIS Modules are not always described separately, but mixed (failed separation of concerns SoC?)
Some modules under openIMIS Modules do not match to the diagram
Some modules under openIMIS Modules are missing
Some modules under openIMIS Modules contain overly technical (source code, stored procedures) details

Related topics from Developer Committee

  • DC #224 Testing Scenarios

  • DC #288 Implementer Documentation

  • DC #274 Default Module Configuration

  • DC #260 Documentation Platform

  • DC #105 List of modules / JLN Business Process Mapping

Related Sources

Source

Content / Findings

Source

Content / Findings

Describes “Modularity” as

Modularity (and its integration counter-part) is considered at 3 distinct levels:

  • Solution level, considering the solution as a coherent assembly of Software Components, like Client Registry, Shared Health Record system, Universal Health Coverage,...

  • Software Component level, where components are decomposed into (activated or not) modules dedicated to fulfil the expected scope for them  

  • Entity level, where each concept hosted by a Software Component can be particularised to the specific needs of an implementation.

…

Software Component and Entity levels modularity are fully in the scope (controlled by) of openIMIS.

openIMIS is built modular "from the core on": even low level features (like login,...) and central features (like Insurance Scheme management,...) are built as a plugins of a core platform.

The core platform provides generic components (building blocks) to be used by / particularised in the various plugins and is split in 3 layers:

  • Frontend(s) layer

  • Backend layer

  • Database layer

Although openIMIS is an assembly of components (themselves assemblies of plugins), deployments of openIMIS doesn't impose a distributed deployment.

The choice of isolating the various (server-side) components to dedicated infrastructure is taken according to each project's needs.

Within a project, scaling up by distributing components as the load increases is a very standard (and easy) operation:

 

Plugins are documented in openIMIS Modules.

 

openIMIS Modules

In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle.

…

Plugins (can) provide several types of archetypes, dedicated to the various openIMIS layers: openIMIS Mobile FE, openIMIS Web FE, openIMIS Online BE, openIMIS Batch BE,...

openIMIS can be deployed with an extra layer dedicated to implement a FHIR API, based on openIMIS core (base) modules.

 

In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle.

In other words, even the following features are implemented as (interchangeable) modules:

  • Login (authentication)

Beyond these low-level modules, several modules will be dedicated to configuration/administration:

The real business needs will be implemented in dedicated modules:

In addition, the following modules are used for integrating openIMIS with external systems:

Tests cases for the various modules are documented in a separate wiki page.

Plugins (can) provide several types of archetypes, dedicated to the various openIMIS layers: openIMIS Mobile FE, openIMIS Web FE, openIMIS Online BE, openIMIS Batch BE,...

openIMIS can be deployed with an extra layer dedicated to implement a FHIR API, based on openIMIS core (base) modules.

Today the FHIR API is a unique module, but there is an open point on splitting it into separate modules (per FHIR resource?):

Code (static) analysis, as well as unit tests coverage metrics of each module, is automated via travis-ci and codeclimate. You can log into these tools via your GitHub login. If you are registered in openIMIS GitHub, you'll have access to openIMIS build job and code quality metrics.

Detailed Module Documentation

 

 

@Patrick Delcroix in the comments:

Here my point of view on the module list details in 4 groups (core, business...)

The module with * leading are not found in JLN

IT core

  • *Core & security

    • Database access,

    • Logins, user, roles including enrolment office & claim admin,

    • Email

Business

  • Claims Management

    • Claim,

    • Feedback,

    • Review

    • Appeal (not available)

  • Scheme Policy

    • Insurance companies (not available), 

    • provider policies settings,

      • Product

    • Eligibility Requirements,

      • Product

    • Benefit Package Formulary

      • Product

    • provider rates

      • Price lists (Item and services),

    • Funding

  • Premium Collection ,

    • Payer

    • Policy payment

  • Beneficiary Management

    • Insures,

    • Group,

    • Policy,

    • Renewal

 

Register

  • *Locations (regions … )

  • Provider Management

  • *Client registry

  • *Medical item

  • *Medical Service

  • *Diagnosis

 

Reporting

Background - Joint Learning Network for UHC

The JLN Process Matrix

JLN Process - OpenIMIS Mapping

Sources Release 2022-10

  • Single repositories were named “Module” now “Component”

    • Not all repositories contain source code, some are used for databases, package linkage, docker scripts etc.

openIMIS Management Console

  • Refers to frontend and backend “Modules”

https://www.youtube.com/watch?v=JdmsB7CFEhY

  • Explains the modular architecture where backend “modules” contribute to each other to provide functionality

  • Frontend assemblies are following the same modular programming paradigm and are considered “modules” as well in this scope

List of modules under openIMIS Modules

Module

Content / Finding

“Modules” in diagram

Module

Content / Finding

“Modules” in diagram

Claim module scope

Claim

“Beneficiary Enrollment” \ Policies module scope

  • Seems outdated (last change in 2021)

    • Refers to legacy code

    • Refers to functional spec from 2017

    • Refers to Windows service

  • Seems incomplete (contains remarks, questions and/or arbitrary formatting)

  • Top-Level-Content: Business definition of the policy dates, Access Rights, Actors & Rights, Policy Management Features

Policy

“Beneficiary Enrollment” \ Persons & Families module scope (->insuree) ()

  • Seems outdated (last change in 2020)

    • Refers to legacy code

    • Refers to functional spec from 2017

    • Contains old screenshots

  • Seems incomplete (contains remarks, questions and/or arbitrary formatting)

  • Mixes two “Modules”

Persons - Missing in diagram

Families - Missing in diagram

“Beneficiary Enrollment” \ Contributions & Payment module scope

  • Seems outdated (last change in 2020)

    • Refers to legacy code

    • Refers to functional spec from 2017

    • Contains old screenshots

  • Seems incomplete (contains remarks, questions and/or arbitrary formatting)

  • Mixes two “Modules”

Contribution

Payment

“openIMIS Administration Modules” \ Product module pages mockup

  • Does not document the module, but a proposal -> Documentation is missing

Product

“openIMIS Administration Modules” \ Locations & Health Facilities module scope

  • Seems outdated (last change in 2019)

    • Refers to legacy application

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief)

  • Mixes two “Modules” or naming issue?

Location

Health Facilities - Missing in diagram

openIMIS AI-based Claim Adjudication

  • Describes a project

Claim AI - Missing in diagram

openIMIS Management Console

  • Seems outdated (last change in 2019)

  • Unclear scope, not describing a module

 

openIMIS FHIR modules

  • Mixes two “Modules”

FHIR V3

FHIR V4

Invoices (and bills)

  • Mixes multiple “Modules”

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief)

Invoice

Others? (e.g. Contribution Plan ?)

Calculations Module

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Calculations

Contract Module

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Contract

PolicyHolders Module

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Policy Holder

Policy holder portal acceptance criteria

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Policy Holder Portal - Missing in diagram

Bulk CHFID Generator (insuree)

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Bulk CHFID Generator- Missing in diagram

Claim processing up to batch run

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

    • “Under construction”

Claim Batch

https://openimis.atlassian.net/wiki/spaces/OP/pages/3361669121

  • Seems incomplete (contains remarks, questions or arbitrary formatting and / or seems overly brief or overly technical)

Report

Missing modules from diagram

  • Module page is missing (or mixed in)

  • Language Packs

  • Insuree

  • Insuree Batch

  • Core

  • Payer

  • Medical

  • Medical Pricelist

  • Tools / Home

  • Contribution Plan

Missing modules on the diagram?

  • Login is mentioned in openIMIS Modules, but the page is missing

  • User & Roles management is mentioned in openIMIS Modules, but the page is missing

  • “Insurance Products” is mentioned in openIMIS Modules, but the page is missing

 

 

Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/