GSOC 24 : Validating and re-writing openmrs patient flag module - project updates

Hi everyone,

I’ve been selected for google summer of code 2024 to work on project : validating and rewriting openmrs patient flag module. I will use this thread to share the project updated and for general communication purposes.

Project details:

Project objectives:

  • Identify and optimize areas of the module that contribute to performance issues

  • add support for java 17 without removing java 8

  • Revamp the module code base and update modern openmrs standards

  • Introduce a new functionality to facilitate the translation of patient flags between the Flag — FHIR v5.0.0 Resource and the OMRS Flag model

Resources:

cc : @jayasanka @piumal1999

3 Likes

Hi,

Here’s my latest blog post about my first week in the GSOC journey. A big thank you to @jayasanka and @grace for conducting such an amazing orientation session.

2 Likes
3 Likes

what is the different between (patient page) http://localhost:8080/openmrs/patientDashboard.form?patientId=9 and (patient dashboard) http://localhost:8080/openmrs/coreapps/clinicianfacing/patient.page?patientId=9?

this is a screenshot of patient page, in here patient flags are not loading, what could be the issue? but in patient dashboard, flags are showing.

CC: @wikumc @dkayiwa

These two pages are the O2 UI and the legacy UI. Currently, OpenMRS does not display pages on the O2 display for some reason. I suggest you to look into that after doing the upgrade.

1 Like

Project Updates | Community Bonding Period | 2024-05-06T18:30:00Z2024-05-25T18:30:00Z

  • I had a call with my mentors on 2024-05-15T18:30:00Z, we mainly discussed about the project plans.

    • How we evaluate the performance of the current module and refactor version ?

      • Suggest to use easiest way ( JMeter, Java profiler and JMH )
    • How to add testing data to local openmrs development server ?

      • suggested Import omrs demo data or create some records manually for testing
  • I started working on the improve performance of flag evaluation task and raised a draft PR.

  • created a JIRA Epic

1 Like

current module contains few methods, there are multiple database calls being made inside a loop as following code,


for (Flag flag : flags) {
			List<String> flgs = (List<String>)context.get(patient.getPatientId());
			if (flgs != null) {
				for (String flg : flgs) {
					service.savePatientFlag(new PatientFlag(patient, flag, flg));
				}
			}
			else {
				service.savePatientFlag(new PatientFlag(patient, flag, flag.evalMessage(patient.getPatientId())));
			}
		}

Each iteration potentially results in multiple savePatientFlag calls, which can lead to performance issues by increasing load on the database.

To optimize this, I propose refactoring the code to use batch saving. This would involve collecting all PatientFlag objects in a list and then performing a single batch save operation. This approach should reduce the number of database calls and improve overall performance.

The refactored code might look something like this:

List<PatientFlag> patientFlags = new ArrayList<>();

for (Flag flag : flags) {
    List<String> flgs = (List<String>)context.get(patient.getPatientId());
    if (flgs != null) {
        for (String flg : flgs) {
            patientFlags.add(new PatientFlag(patient, flag, flg));
        }
    }
    else {
        patientFlags.add(new PatientFlag(patient, flag, flag.evalMessage(patient.getPatientId())));
    }
}

service.savePatientFlags(patientFlags);

I would appreciate your thoughts on this approach

CC: @wikumc @dkayiwa

This sounds promising. Can you test both methods and calculate the average time for each?

I tested the both methods and calculate average time in milliseconds.

current module without batch saving : 79.9 milliseconds

current module with batch saving : 42.4 milliseconds

feel free to create a ticket and a PR for this.