Decisions to take
In italic, decisions proposed by bluesquare, still open point are in boldCaption
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 (
...
- Migrationnot 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 (frontendfront end, back ends)
- by business domain
- 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 differentiated
- 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)
- with MSSQL; rational fields
- If aligned with an existing FHIR resources
- 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)
- Localisation 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
- FHIR for external communication with OpenHIE components and configured to route through OpenHIM
- 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
- 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 )
- see also https://wiki.ihe.net/index.php/Add_RESTful_Query_to_ATNA for work in progress/just finished on adding RE
- 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
...