Decisions to take
In italic, decisions proposed by bluesquare, still open point are in bold
Out of scope
- Iterative approach was already validated for new OpenIMIS
- Mobile development
- presentation management
- synchronization
Strategy (iterative approach)
- 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)
- Unidirectional dependencies
- module name shouldn't be already used
- Open for extension but close for modifications
- 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
- Level of customization (data source, logic , parameters, ....
- Unit testing: SonarQube
- database abstraction (ORM) Avoid as much a possible direct SQL
- table name convention modulename_itemname (always in singular)
- Automatic testing : SonarQube
- Business requirement: Gerchin
- regression testing must be done for any database changes
- Version management:
- Manage the version modules (Major, Minor, LTS)
- Keep compatibility matrix up to date
- Internalization
- Keep drop down translation in database
- Enforce Internalization in a single place (label + dropdown)
- Localisation support
- Currencies
- Time formats
- 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 ?
- What action modules should be able to trigger on other module:
- Should we have Business process management
- Should we use only event (dynamic) or contributions (static)
Tools
- 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
- 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
- HIM
- SSO; to be check what sso are available in django
- External application (i.e. OpenMRS) authorisation to access the API
- API/OPEN HIM credential management (node based not user based)
- Audits
- 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
- Unit testing: enzym / jest
- Back end:
- Language : Python
- Framework : REST Django + Celery and RabbitMQ
- Country specific devs are based on configuration files (and modules)
- Code coverage tool: https://github.com/codecov/codecov-python
- 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
- If FHIR ressources
- 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 for the rest
- What module should be part of Tender 1:
- Name
- Boundaries