Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Caption

in blue are the point still open

in green are the point where an agreement was reached

Out of scope

  • Iterative approach was already validated for new OpenIMIS

  • Mobile development

    • presentation management

    • synchronization

Strategy

  • Migration (not discussed) Integration of new requirement

    • high cost, low event/contribution needs → New,

    • high cost, low event/contribution needs → TBD

    • low cost → legacy

    • API → New

  • Licensing: Can we use the proposed frameworks (i.e. Django) with AGPL v3

  • Modularity level

    • by business domain

      • Coarse or fine grained

    • by layer (front end, back ends)

  • What will be an OpenIMIS module:

    • Add new feature or change core (How to change core)

    • Repositories and owner:  Blue square will propose an approach

    • skeleton module

    • codingStyle_needs__to_be.determined

    • Unidirectional dependencies (event  and contribution)

    • module name shouldn't be already used (module list on wiki)

    • Open for extension but close for modifications (avoid fork)

    • Loose coupling:  can be plug or unplug at will but it is costly and not easy to learn 

    • No stored procedures

    • Level of customization (data source, logic , parameters, ....

    • code analysis: SonarQube

    • database abstraction (ORM) Avoid as much a possible direct SQL 

    • table name convention modulename_itemname (always in singular)

    • Business requirement and integration test: Gherkin

    • regression testing must be done for any change

    • Continuous integration : Travis-ci

    • New entity:

      • If aligned with an existing FHIR resources

        • with MSSQL; rational fields

        • FHIRbase with PostgreSQL + JSONB  (optional in JSON format)

    • Version management:

      • Semantic versions - Manage the version modules (Major, Minor, LTS)

      • Keep compatibility matrix up to date : need to determine package dependency management 

        • how do we manage dependencies between front-end vs back-end modules?

    • Demo dataset generation tool (part of Fhirbase) - https://synthetichealth.github.io/synthea/ 

  • Internalization

    • Keep drop down translation in database

    • Enforce Internalization in a single place (label + dropdown + master data)

  • Localization support 

    • Currencies (rounding, size of input fields depends on choice of currencies)

    • Time formats

    • Right To Left (Arabic) and LTR languages

  • What standards need to be used to retrieve and publish data

    • FHIR for external communication with OpenHIE components and configured to route through OpenHIM

      • maybe also use for UI and mobile apps - need to assess existing available FHIR UIs

    • Need to document data workflows

  • What action modules should be able to trigger on other module:

    • Should we have Business process management (WHEN should it be available)

    •  use event (dynamic)  or contributions (static)

      • Guide line required

Tools

  • Development issue queue

    • Do we need to have different issue queue per Jira project 

  • Infrastructure / Packaging:

    • Legacy OpenIMIS + Linux Docker for new component

    • Windows container for legacy + new module ==> DOES IT WORK? 

    • Open question: how to upgrade with Docker without overwriting the country specific developments? Should / How to integrate the country specific devs into docker?

    • Deployment along OpenHIE - should align with Instant OpenHIE (Docker/Kubernetes) 

    • Offline infrastructure Sync

    • Reference assembly file is not as-is part of the core but can be used to start a country specific implementation

  • Authentication: 

    • Django 

    • SSO; to be check what sso are available in django - should take discussion to OpenHIE community for consensus

    • External application (i.e. OpenMRS) authorisation to access the API API/OPEN HIM credential management (node based not user based)

  • Audits

  • Front end: GUI

    • Language : Javascript

    • Framework : React(static) / redux (event, inter-module communication)

    • Caching and bad connectivity resilience: progressive approach possible.

    • Translation: use React best practice

      • link to https://translations.launchpad.net/using  .po / .pot file for crowd-source translations of the UI

      • need to think about translations of metadata that is international (e.g. ICD-10 terms are translated to key languages) and local (e.g. metadata in bilingual countries)

    • Unit testing: enzym / jest

    • Possibility to change the date display

    • Extension point / Contributions extension model

  • Back end

    • Language : Python

    • Framework : REST Django + Celery (RabbitMQ for worker)

    • Country specific devs are based on configuration files (and modules)

    • unit test handled by Django

    • Code coverage tool: https://github.com/codecov/codecov-python 

    • hook custom date calculation - needs more detail on requirements

  • Database :

    • Legacy To-be PostgreSQL 

    • Database independence >> to be review when the database migration is done

      • Fexilibity needs JSONB

      • FHIR is simpler with JSONB (ie. FHIR database)

      • Other database License already bought : Implementer to check: OpenIMIS needs to go to PostGeSQL, how easy will be for your country to comply

  • Batches :  recurrent jobs to updates records / workflows

    • Language : Python

    • Framework : Django

    • recommended task planner: Airflow

  • Standard for new API

    • FHIR when there is a matching fhir

    • JSON API as default