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)
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