The RefApp 2.x openmrs-module-patient-flags module is not worthy of integrating into OMRS 3.x.
This is ideally because the Uganda EMR team reported that the RefApp 2.x version of this module is slow. This is because the patient-flags-module defines a mechanism which evaluates flags live. When a patient is brought up, the system runs scripts against the patient’s data to determine the flags. However, this system may not be scalable as it may be too slow to display more than one or two flags.
Solution
The FHIR Flag resource can be used to store data related to flags. The data stored should include, at least, the data in the FHIR flag model. This would allow us to build out how patient flags are created in different mechanisms. The patient flags are already created as part of the CDS scripts in SQL, so importing those flags is ideal. The flag module should store only unexpired flags.
I proposed this as a project for GSOC 2023 so that a GSOC student can update this module.
Wow, this is a good project, I would love to work on this project alongside anyone contributing to it. A IDI and soldev Team, We envision enhancing patient flags in call for life systems across different implementations in Africa, However, we realized that capturing flags using FlagEndpoints, It was not something the community embraced. Being that, we can discuss further how we can achieve this. cc @pwargulak
It’s an interesting project. In Connect for Life, we are using patient flags in one of the implementations, in productive environment and we did notice the performance issues @jnsereko mentions - we have flag which takes couple of seconds to calculate.
@jnsereko how about evaluating these flags in some sort of background daemon thread and storing the precomputed results. That way, the patient dashboard loads the already stored computed results. We would then need to keep it in sync with the obs or any other data which could potentially affect the computed results. To give an example, we could for instance spawn a background thread to recompute for a patient (or a group of patients depending on the type of flags), on form submission. Or simply do this as AOP around the ObsService or any other relevant services, for data submitted outside of forms. This can be refined further, but just wanted to start by throwing in some rough ideas on the possible next steps.
Thanks @dkayiwa. I would personally go with option 1, spawn a background thread to recompute...
I think we shall need to;
Enable asynchronous processing in the 2.x patient flags module
Modify the existing a service class that handles flag evaluation by adding an asynchronous function that accepts a patient or group of patient as parameters and paste Flag revaluation logic there.
In the controllers, we shall just call that asynchronous function and pass the desired patient or group of patients.