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.
Screenshot:
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:
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
Questions
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?
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.
@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.
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.
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: https://github.com/esaude/openmrs-module-patientflags.rest
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.
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.
@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.
@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:
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).
PatientFlagsModuleActivator should be upgraded to extend BaseModuleActivator and not the old, deprecated Activator interface
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.
All of the test classes belong in api and not omod, as far as I can tell
Most of the resources in the omod project belong in api. These include the hibernate mapping files, sqldiff.xml, liquibase.xml, and messages.properties. 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.
@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 webservices.rest, 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?
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.
