Page Comparison

...

• 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: 
  • all modules under OpenImis account or other account allowed 
  • module uner the 
  module repository : both front/back or differentiatedBlue 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

...