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.