@raff I know this is blind-siding you, however do you have any advice on adding dashboard widgets to other modules, I remember there was restricting use within coreapps
I’ve taken the work done by Craig and fixed the test issue (permissions were also required by GroovyFlagEvaluatorThread). I’ve also done the refactors from the post by @mseaton - I dropped the OpenMRS 1.6 profile because that version did not support the BaseModuleActivator.
Thanks @pgesek, looks good to me at first glance - thanks for doing all of that necessary refactoring work! I didn’t pore over this too closely, but one quick question- what is the minimum openmrs version this supports? I see references to 1.7 and 1.8 OpenMRS profiles. I also see a comment:
<!-- include groovy, but mark as provided since it is included with openmrs-core v1.10+--
Generally I think we should make this module support 1.9+ (it may be required by the mdrtb module, which is on 1.9). It’s possible though that this isn’t even a requirement and we could go higher. If we change the minimum version in config.xml, we might as well get rid of the older OpenMRS profiles for testing as well.
We are planning on making a UI for exposing the patient flags fragment in the reference application clinician facing dashboard. We would like to create a module named openmrs-module-patientflagsui and have it be supported by the community along with the improved patient flags module.
Is this alright with everyone? If so, can someone create a new repo on the OpenMRS GitHub org?
@ssmusoke, the patient flags work will provide a dashboard fragment with the flags that are evaluated when the patient page is loaded as is supported by the original module. Here’s the link to the spec written to improve the module. You’ll have to see if this spec meets your needs. Most importantly, we need to determine how the flags are calculated in the database and with what frequency. Our implementation is considering a simple ETL that runs on a regular basis and evaluates flags for each patient, so the query results in a binary value as to whether to display the flag for that patient.
The UI is scheduled to be tested and delivered in the next two weeks. At that point, it would be appropriate for you to pick up and see how it can be extended.
I guess i’m fine with a new module for the patient flags ui, under the openmrs org, if it is the only way. I really wish we didn’t have to do this however. I honestly don’t know what implementations use patient flags that are also not running the reference application platform modules that would enable us to just put the display logic there. I also wonder if it would be possible to add this conditionally to patient flags to be loaded iff uiframework is started. Or build this out as a web component that does not require any specific dependency on uiframework. The proliferation of modules can get a bit unwieldy.
I would vote for putting the UI in the existing patient flags module because am not aware of anyone who simply uses its API without the UI. Later on, if we find that the UI really needs to be in a separate module, we can always move it. But many times, this requirement never happens.
I just tested the PR and the module is working as intended. Our team is about to get started creating the flags that are exposed in the UI. I reviewed the OpenMRS RA Style Guide on the demo and found that there are notification items and toast messages. These standards are for user alerts in the UI. I’m thinking of using those same coloring scheme to create a high (white on red) and medium (dark yellow on yellow) flags in a similar color scheme to the notification message. Is there a more appropriate visual language to use for these flags within the RA UI?
At a glance I’m concerned these are a bit tough to read (especially the
medium priority example). I would play around with the colors and font
weights to find something that’s consistent with the style guide look and
feel, but is more legible.
@craigappl we are looking to leverage the patient flags module in UgandaEMR as it provides some quick wins with showing patient status values. However i am running into a number of issues so I was wondering if you have available resources to support some tickets that are becoming blockers as we move along
Leverage lucene instead of the Hibernate cache to store the results of executing the flags to improve performance especially for large data sets and how cache invalidation can be managed as the data changes. @raff thoughts?
Ability to use Reporting Cohorts or Reporting REST for cohorts - @mseaton?
We do not currently have the resources to contribute to patient flags. It’s a lower priority on our iSantéPlus roadmap. We do have a work item in the February and March timeframe that will include opening a popup alert based on computed medication adherence. This work will likely expose a patient flag, but it’s too early for me to tell if we will run in to these same blockers.