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.

Project update | Coding Period | 2024-05-26T18:30:00Z2024-06-20T18:30:00Z

It’s been almost a month since I shared last update on the project with the community. In past month I worked on ticket related to patient flag module.

FLAG-69 : Improve the performance of patient flag evaluation

I refactored the patient flag evaluation process to run in parallel instead of evaluating in sequentially. This approach could significantly improve the module’s performance.

  • Improve the performance of patient flag evaluation : #59

Test & Evaluation Results

parallel process → 7.6.5.8,7,7,6,7,8,6 => avg 6.7 milliseconds

current module → 8,7,7,6,8,7,7,7,8,6 => avg 7.1 milliseconds

flags count < 5 - current module perform better than this implementations

flags count < 10 - both are perform in same way

flags count = 17 - this implementation perform better than current module

when the flag count is increased, the prell process performs better than the current module.

  • Improve the performance of the evaluating all flags : #60

Test & Evaluation Results

parallel process → 74, 58 , 63 . 47 , 79, 40 , 101, 121 , 58 => avg 64.1 milliseconds

current module → 258, 230, 215, 208, 207, 208, 204, 196,202, 198 => avg 212.6 milliseconds

FLAG-75: Refactor the methods using lambda expressions and stream API

  • Refactoring methods using lambda expressions and the Stream API simplifies code by making it more readable PR’s : #63 #64 #65 #66 #67 #68 #69

FLAG-74 : add java 17 support

I updated the patient flag module to support Java 17, while retaining compatibility with Java 8. As a result, the module now works with Java 8, Java 11, and Java 17.

In addition to these objectives, I worked on the following tickets:

  • Unit tests not triggering in mvn build - FLAG-77
  • Implement batch saving functionality for saving patient flags - FLAG-76
  • Update the unit test with some actual flag data - FLAG-78

The guidance from @wikumc and @dkayiwa has been incredibly supportive throughout this process. Their assistance were instrumental in overcoming challenges and implementing the necessary changes efficiently.

project wikipage

Thank you for reading this updates.

CC : @jayasanka @piumal1999

2 Likes

Project update | Coding Period | 2024-06-21T18:30:00Z2024-08-01T18:30:00Z

FM2-640 : added FHIR Flag resource

I implemented the mapping between openmrs flag model and FHIR flag resource.

PR : #80

Here is how it look likes when openMRS patient flag mapped to FHIR flag resource

{
    "resourceType": "Flag",
    "id": "3c202af2-4b12-4314-82d8-4b01032cbb0c",
    "text": {
        "status": "generated"
    },
    "identifier": [
        {
            "value": "4"
        }
    ],
    "status": "active",
    "category": [
        {
            "coding": [
                {
                    "code": "02680e18-ee33-4667-809b-cc145fca3a69",
                    "display": "Allergy"
                }
            ],
            "text": "Allergy"
        }
    ],
    "code": {
        "coding": [
            {
                "display": "Allergy"
            }
        ]
       "Text" : "Allergy"
    },
    "subject": {
        "reference": "Patient/5d3fbbb5-917d-4aa8-9101-1706feb1867c",
        "type": "Patient",
        "display": "Manoj Lakshan Rathnapriya (OpenMRS ID: 10000X)"
    },
    "period": {
        "start": "2024-07-13T16:11:32+05:30"
    }
}

I implemented fhir search functionality that allows us to search flags based on various criteria,

  • Patient ( patient ID (UUID), Identifier, Name ( given, Family, name))
  • Flag Category
  • Flag Message
  • Date

other than the fhir implementation, I improve the unit test coverage in patient flag module and fix two ui issues.

added tests for flag filters : #90

added test for groovy flag evaluator : #89

added test for slq flag evaluator :87

added test PatinetTask clas : #85

Fix the UI issue on get flagged patient based on tags : #84

fixed the patient flag showing issue on patient dashboard : #82