Status of Patient Flags Module and steps forward

@craigappl excellent news as this looks to be a solution to my need Patient Status Values on the Patient Dashboard

Would creating a dashboard widget like https://wiki.openmrs.org/display/docs/Patient+Summary+Widget+Documentation help for adding it to the patient dashbaord?

@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 opened a pull request for flags:

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, Paweł

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.

Thanks for working on this, Mike

@mseaton, @burke, @dkayiwa, @darius

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?

Thanks, Craig

@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.

FYI @pgesek

I’m fine with dropping support for 1.7 and 1.8 to simplify matters.

Regards, Paweł

I’m also fine with dropping 1.7 and 1.8, and with the new module “openmrs-module-patientflagsui”.

Yes, please do it. Also, @ssmusoke, also mentioned that we may want to bump the version to 1.4.0-SNAPSHOT before your work is merged.

@ssmusoke, @dkayiwa, or @mogoodrich can you kick off a release for the patient flags module? (I don’t know how to do this.)

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.

Mike

I would also be find with including the new UI in the exisitng patient flags module for the reasons Mike notes.

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. :slight_smile:

Thanks everyone for your input!

@pgesek, let’s proceed with putting the UI fragment in the patientflags module.

I’ve dropped support for 1.8 and 1.9 and updated the current version of the module to 2.0.0-SNAPSHOT.

Regards, Paweł

Hello everyone,

The pull request now also introduces the UI widget for flags and fixes for running on OpenMRS 2.0.

Regards, Paweł

Hi Everyone,

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?

Thanks, Craig

Hi Again,

Here’s a screenshot as an example:

High Priority Style: color: white;background: #ff6666;padding: 2px 5px; border-radius: 3px; font-size: 0.8em; Medium Priority Style: color: #ffa000;background: #fffdf0;padding: 2px 5px; border: 1px solid; border-color: #ffa000;border-radius: 3px; font-size: 0.8em;

Craig

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

  1. Flag evaluations working for patients and not person especially for obs - https://issues.openmrs.org/browse/FLAG-20
  2. Custom messages in Flag messages https://issues.openmrs.org/browse/FLAG-23
  3. Query Evaluation for a single patient - https://issues.openmrs.org/browse/FLAG-28

A couple of additional thoughts for the future:

  1. 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?
  2. Ability to use Reporting Cohorts or Reporting REST for cohorts - @mseaton?

Hi @ssmusoke,

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.

Sincerely, Craig