I am interested in contributing to this project. I have a few questions and any insights/ ideas from the community would be immensely valuable.
To start with, I have some ideas about how we can approach the performance issues.
At the moment, the fact that flags are evaluated live seems to be the main cause of performance issues, especially when a patient has multiple flags. Here is my suggestion:
Since forms are the primary methods of collecting data in OpenMRS, we can have a background process/thread to (pre)compute the flags when a form is submitted. We would have a table in our database that would keep track of the patient(s), the patient_flag and a flag() to tell whether the patient meets a certain flag.
When a patient dashboard is being created, we can just run a query against this table and act accordingly.This approach of running this background process at form submission takes into account patient data changes(our table can be updated to show these changes) and it can be extended to cater for data changes due to external systems and sources.
@wikumc I need some help with differentiating between a patient flag and a flag, because I think of them as similar in some contexts and totally unrelated in others.
For example, the naming of this function seems to be confusing me public void deletePatientFlagsForFlag
It’s even made worse by the fact that there are tables for both terms in the database.
There is a many-to-many relationship between the Patient and Flag. To normalize this relationship we use the patient_flag table. Simply PatientFlag class is there to represent a relationship between a Patient and a Flag.
Over the past few days, I have been evaluating the idea that I proposed before and trying to think of how we would implement it. Whereas it is a good idea on paper, I am starting to think that it would be quite complex to realise in practice. I think it would involve something to the tune of hooking the form entry modules with the patient-flags module and this alone would introduce unnecessary work given how modules work.
I also thought about what was proposed by jnsereko here, that is, to add asynchronous processing to the module. This is also another interesting approach in my opinion. I have tried to whip up some code as a proof of concept for both ideas and whereas I have not had success with that yet, I feel like this second approach would be much easier and faster to implement.
@wikumc Maybe I am missing something, but I would love to get your opinion on this.
I have also given some thought to the project objective to do with adding support for java 17. Could we use something like multi-release jar/omod files.
The simplest way to do this is to process flags asynchronously. For Java 17 support we need to be able to compile and run the code using Java 8, 11, and 17. Take a look at these pull requests to get an idea:
) to tell whether the patient meets a certain flag.