As a follow-up from the OpenMRS conference in Maputo, I would like to propose an an additional distribution built on top of the Reference Application with a well defined use case to illustrate the possibilities and help drive implementations 80% of which are HIV anyway
Being dogmatic, this module would be metadata only with the rest of the features being implemented downstream. So would have
Patient Registration Workflows - address, relationships, an HIV Care identifier, Clinican facing dashboard with attachments
HIV Care Enrolment
HIV Care Follow-up visits
with prescription and drug dispensing
lab workflows - serum crag, viral load
regimen switching & drug substitution
Reporting
WHO, UNAIDS, PEPFAR indicators (finer age disaggregations)
facility level reports: due for appointment, due for VL, overdue for VL
Automated submission to DHIS2 instance (there are modules & a JSON approach from UgandaEMR)
Transfers to other facilities and incoming transfers
Data Validation rules (of course ;-))
Patient flags - based on WHO specifications
Point of care - this can be an addition on top of the forms
Additional wild ideas (which may not happen now):
FHIR based backend
Single SPA front end
I have also checked within the GSoC program and its possible to have more than one student work on independent pieces of this module as long as each part has a dedicated mentor
@dkayiwa not switch however we can leverage alot of the work done to make this distribution… Would also provide a great stepping stone for identifying and finding future funding
I want to support Mr. Stephen proposal, this will improve the features in OpenMRS couple with proposed decouplement of FHIR within OpenMRS, this will improve the flexibility of OpenMRS forms to the end users.
I will also want to see an improve functionality of Point of Care (POC) to be part of downloadable OpenMRS.
This looks like severally module been integrated together. I want to be part of this…but I also want us to analyse it carefully and weigh its pros and cons
@ssmusoke, this is our (AMPATH) number one priority for the next 6 months. We are actively working with @aojwang and the Palladium team on producing a microfrontended HIV set of features. We would be very excited work on this with you collaboratively. @gschmidt has been working on initial designs and is looking to develop a collective process to build out the various features that each implementation will need. I believe the team at PIH (@mseaton@mogoodrich) is also interested in building out an HIV specific set of features.
@ssmusoke, great suggestion. I would add that making the modules as configurable as possible should be considered, more so because we have cases where a country’s MOH policy on something may differ with PEPFAR. While most MOH’s will go with WHO standard, PEPFAR may have variations that occasionally cause a conflict that impact reporting and patient management (many implementing partners typically prioritize their reporting to the funder). A case in point, PEPFAR modified the Lost To Follow Up cut-off to 30 days while the MOH in Kenya uses 90 days. In such a case, we would want the cut off days for LTFU to be configurable to accommodate such variations.
@ssmusoke this is a great idea to leverage the summer of code for this work and we support this effort, and agree with the idea to make the modules highly configurable