Tool decision conclave

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