Status of Patient Flags Module and steps forward

Hi Everyone,

We’re reviewing the patient flags module and planning to build on it for the reference application distribution (v2.5). I’d like to summarize what we have found about the module and ask for help moving forward. The goal of this work is to expose a fragment on the clinician facing dashboard that alerts providers for important clinical decisions. This is a sample screenshot showing that a test result is abnormal.


Current Status The patient flags module currently works with OpenMRS platform versions up to 1.10. The omod directory depends on the logic module, which was removed as a core module in platform v1.10. Additionally, the groovy dependency was moved into openmrs-core in v1.10.

Work to be completed It looks like the following work needs to be done on the module to get it working on OpenMRS platform 2.0:

  • Switch the dependency on the logic module to the calculation module as suggested in the ticket
  • Create a profile in the pom for OpenMRS platform 2.0 (Also 1.11.x?)
  • Make sure the groovy dependency matches the version in openmrs-core
  • Make sure everything builds against Java 8
  • GSOC: @pascal advised @ch3ck to create a REST API for the module, but the code the status of this work isn’t clear.

After that, we need to create the UI in the reference application. Our I-TECH team in Haiti is ready to do this work. We need to create a module for the UI that depends on the patient flags module with the following characteristics:

  • Fragment that adds to the clinician facing dashboard
  • Update the CSS for errors to match the reference app styleguide


  • Is anyone else working on integrating the patient flags module in the reference application before the 2.6 release? If so, could we share the work?
  • We have the UI built for Reference application 2.3 (Java 7), but our team is having trouble with the upgrade to OpenMRS platform 2.0. Does anyone have time to help triage or work on the upgrade?
  • How far backwards should we keep compatibility in this module? Are these changes breaking changes? For example, the GSOC commit removed all of the profiles for OpenMRS 1.6 - 1.10. Should we do the same?

Tagging people who have worked on this before: @janflowers @pascal @eddiemu @dkayiwa @jmaxy @nathaelf @ch3ck @steliomo @mogoodrich


I can help guide the one who is having trouble making the module run on platform 2.x

I am very interested in this topic. I wanted to implement the patient’s flag in 1.9.7 but it was not stable. Sometimes it worked but other times it threw an error. We plan to upgrade our OpenMRS to possibly the Reference App in the next 3 or so months so I can help with testing this.

As the original developer of Patient Flags, I’m happy to see the module moved forward and incorporated into the reference app.

For what’s it’s worth, we don’t currently use the module, so I’m not particularly worried about backwards compatibility. If it is easy enough to keep it compatible with 1.10.x, I would vote for doing that, since that is the version of the platform we are currently on. If it’s a lot of work, may not be worth it though.

Unfortunately, as we are still on 1.10, I don’t have any experience upgrading to 2.x platform.

Take care, Mark

Thanks Mark. Is there an alternative approach to raising clinician facing alerts in the reference application UI? Are you guys doing this at PIH?


This could be helpful in improving it

@craigappl not that I know of… we don’t currently have clinician alerts in our system.


@pascal @ningosi @valvijo @steliomo Can either of you expand on the work we did with the patient flags module? If I recall correctly, we improved the API’s in the module, correct?

@craigappl we built an angularJS front end for our POC, so we did clinical alerting through that interface but using the patient flags module on the backend.

Thanks Jan,

Is the angularJS repo available for review?


Of course - we do everything publicly:

The errors on the omod tests are due to the dependency on the logic module. Could we remove all references to the logic module and just stop supporting logic based calculations in the patient flags module? Our core use case focuses on supporting SQL query based patient flags.

We would have to remove the UI element, the logic module evaluator, and the logic based functional tests.

I don’t have a problem dropping logic flags. Don’t know if any others are using them.

However, it may be as simple as switching out the logic module with the calculation module? I think calculation replaces logic?

Take care, Mark

Hi @janflowers and @craigappl,

Actually we didn’t change the patient flags module. We created a rest WS module to expose the patient flags to our AngularJS UI application. The source code of the module is in:

1 Like

Hi @dkayiwa and @mogoodrich,

I took a stab at removing the logic evaluator from the patientflags module. I was able to get it to build successfully on OpenMRS 1.10. I created an openmrs-1.11 profile and am now getting a failing test in the groovy evaluator because there is a privileges error in my unit test setup. There are a few pieces I don’t understand and hope you can have a look.

Here’s the link to my branch where I’m doing this work.

I’m building the module with openjdk-7-jdk on unbuntu using “mvn clean install -Popenmrs-1.11”

When it runs the omod unit tests I get these errors:

Tests in error: 
  validate_shouldAcceptValidGroovyCriteria(org.openmrs.module.patientflags.FlagTest): Unable to evaluate Groovy Flag Groovy Sample, error.privilegesRequired
  validate_shouldRejectInvalidGroovyCriteria(org.openmrs.module.patientflags.FlagTest): Unable to evaluate Groovy Flag Invalid Groovy Sample, error.privilegesRequired
  eval_groovyShouldReturnFalseForTestPatient(org.openmrs.module.patientflags.FlagTest): Unable to evaluate Groovy Flag Groovy Sample, error.privilegesRequired

I think the flagTest is going to the GroovyFlagEvaluator and failing when it’s trying to get the user permissions because the test environment doesn’t have any user permissions setup.

I’m not sure if this is related…when I see the test-hibernate.cfg.xml file, there’s a handlebar ${hbmConfig} notation that I don’t see set anywhere. There’s another one in the omod/src/main/resources/config.xml.

This is getting beyond my experience and I really appreciate your help.

Thanks, Craig

FYI @jmaxy

@craigappl i have just pulled changes in this pull request and compiled them on Java 7 using mvn clean install -Popenmrs-1.11. All seems well. Did i miss something?

@craigappl, I can reproduce your error. I believe the issue is caused by the fact that permission names were updated, and permissions formerly named “View XYZ” are now named “Get XYZ”.

In FlagServiceImpl, line 474, where it currently has:

Context.addProxyPrivilege(“View Users”);

Try either modifying this to read “Get Users”, or add an additional duplicate call in the next line adding the “Get Users” proxy privilege.

Make sure you also clean these up consistently in the finally block further down in the method.

Let me know how that works for you… Mike

@craigappl and @jmaxy , from a quick perusal of the codebase, and based on some of your earlier questions, I’d also make a few recommendations:

  1. We should set up profiles in the pom for all versions we aim to support, with the primary version (i.e. the one that will run if one does not explicitly specify a profile), being either the lowest supported version (this is typically my preference, as it naturally forces more backwards-compatibility), or alternatively a version that primary consumers can agree on (i.e. if PIH writes a module and supports it as a public good, and the we upgrade our platforms, we might bump up the primary version, even if we support older versions for other groups to leverage).

  2. PatientFlagsModuleActivator should be upgraded to extend BaseModuleActivator and not the old, deprecated Activator interface

  3. There is a random flagtest-dataset.xml in src/main/java that should probably be removed from the api module. In omod, we can likely get rid of anything pre-1.9, at least.

  4. All of the test classes belong in api and not omod, as far as I can tell

  5. Most of the resources in the omod project belong in api. These include the hibernate mapping files, sqldiff.xml, liquibase.xml, and config.xml needs to stay in omod. moduleApplicationContext.xml should be moved to api, but there should also exist a file in the omod resources called webModuleApplicationContext.xml that has only the controllers and other omod-only components.

This is all fairly typical when a module has been around a while, was written in the OpenMRS 1.6 days, and then relatively neglected (er, stable) in the years that followed. If you are planning on spending some time polishing this thing up and making it hum, it’d be great to take care of this technical debt along the way.

Thanks! Mike

@craigappl we created to help us expose the flags via REST so that we can access them like and display our poc app. Ideally, all flags are created using patient flag module(mostly sql statements), then be read by the module for our case.

@ningosi, thanks for posting this. I’d love to see us move these web services into the patientflags module directly in the future. Nowadays, there is no reason for modules not to depend on, as it is a core part of the platform, and it is now the defacto way of interacting with the api from the web. There are actually only a few classes to port over from what I can tell. @craigappl - are you interested in doing this?

Hi Everyone,

SolDevelo is working on this over the coming week and we want to notify you of a few updates:

  • We expect there will be a PR on the patient flags module that fixes the failing tests, updates the core dependencies and supports a REST API.
  • We need to create a UI fragment for the reference app clinician facing dashboard. At this moment, we are planning on creating a new module called openmrs-module-patientflagsui that will contain the OMOD and app.json to expose the flag. @dkayiwa, @darius, & @mseaton this seems to be the trend as I see with the appointment scheduling UI and reportingui modules. Please let me know if we should but these files in coreapps or in the patient flags module (this may cause ref app dependencies that legacy implementers wouldn’t be interested in)
  • If we create a new module, could someone create this in the OpenMRS GitHub organization? SolDevelo and I-TECH fork and pull instead of getting access to the OpenMRS org.

Thanks, Craig

FYI @pgesek, @nathaelf