GSOC Project Proposal - HIV Distribution based on WHO Definitions

Continuing the discussion from HIV Core Module:

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

  1. Patient Registration Workflows - address, relationships, an HIV Care identifier, Clinican facing dashboard with attachments
  2. HIV Care Enrolment
  3. HIV Care Follow-up visits
  • with prescription and drug dispensing
  • lab workflows - serum crag, viral load
  • regimen switching & drug substitution
  1. 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)
  1. Transfers to other facilities and incoming transfers
  2. Data Validation rules (of course ;-))
  3. Patient flags - based on WHO specifications
  4. Point of care - this can be an addition on top of the forms
  5. 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


Is UgandaEMR planning to switch to this distribution?

@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

1 Like

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 If the FHIR backend piece becomes a reality, please reach out to me or the FHIR squad. We’d be more than happy to help with this.

1 Like

@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.



And what ever concepts are necessary, including the roll-ups to the PEPFAR indicators should come from CIEL :).

@akanter you can be very sure that all definitions will need to be from CIEL as this is aimed at being a standardised distribution alongside RefApp

Yes. I was just voicing my CIEL support for the effort!

Andrew S. Kanter

@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.

@eddiemu The idea is to make the module as configurable as possible, but there is also a constraint of time and capacity within GSoC

I believe that we shall get there over time - due to the nature of the community

@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

That will help enforce standards. Thanks for this