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) 

    • https://docs.google.com/document/d/1daVn-xxxuhQvFzA4sIY2vsDnJxh7AV8DxbB8wkvZNpg/edit#heading=h.49rmeupnjyde
      

  • 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

  • AS IS

  • ATNA: https://wiki.ihe.net/index.php/Audit_Trail_and_Node_Authentication 

    • see also https://wiki.ihe.net/index.php/Add_RESTful_Query_to_ATNA for work in progress/just finished on adding RE
      

    • requirement for some countries (e.g. South Africa see http://www.samed.org.za/Filemanager/userfiles/hnsf-complete-version.pdf )

• 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