...
- Migration
- Integration of new requirement
- high cost, low event/contribution needs → New,
- high cost, low event/contribution needs → TBD
- low cost → legacy
- API → New
- Integration of new requirement
- Licensing: Can we use the proposed frameworks (i.e. Django) with AGPL v3
- Modularity level
- by business domain
- Coarse or fine grained
- by layer (frontend, back ends)
- by business domain
- What will be an OpenIMIS module:
- Add new feature or change core (How to change core)
- 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 Business logic must be on the backend not on the database
- No stored procedures
- Level of customization (data source, logic , parameters, ....
- Unit testingcode analysis: SonarQube
- database abstraction (ORM) Avoid as much a possible direct SQL
- table name convention modulename_itemname (always in singular)Automatic testing : SonarQube
- Business requirement and integration test: Gerchin Gherkin
- regression testing must be done for any database changeschange
- 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?
- Internalization
- Keep drop down translation in database
- Enforce Internalization in a single place (label + dropdown + master data)
- Localisation 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 (external)
- Database connectors (module internal)
- Current API (intra module)
- Use Django security/ user features
- Do we need to proxy the Open HIE/HIM on the core level ?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 Should we use only (WHEN should it be available)
- use event (dynamic) or contributions (static)
- Guide line required
Tools
- Infrastructure / Packaging:
- Legacy OpenIMIS + Linux Docker for new component
- Windows container for legacy + new module ==> DOES IT WORK 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 ends: 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 and (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 New development:If FHIR ressources
- FHIRbase with MSSQL; rationnal fields with fihr name, jsonB as dedicated column with a 'ressource prefix' FHIRbase with PostgreSQL + JSONB (optional in JSON format
- 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
- Language : Python
- Framework : Django
- recommended task planner: Airflow
- FHIR when there is a matching fhir
- JSON API for the rest
- Name
- Boundariesas default