Hey @burke / @grace / @ibacher / @jdick,
Ciarán’s mockups sometimes hint at patient-level notifications, such as this for instance:
Have we given any thoughts on how to handle those? Are those patient flags?
I’m specifically asking about patient flags because I have seen that they seem to be in use, as I saw during the DUC last week. I remember for sure in UgandaEMR but that wasn’t the only distro involving them.
Cc @ddesimone
I would think that if there patient-specific (rather than provider specific), then they are definitely patient flags in the sense that module implements.
Thanks @ibacher.
@ssmusoke in UgandaEMR, how are those flags created? And then what’s the process for clearing a flag?
@mksd We load them via metadata mapping from this file openmrs-module-ugandaemr/Flags.java at master · METS-Programme/openmrs-module-ugandaemr · GitHub along with the rest of the tags, and priorities
The flags are fired on the clinician facing dashboard, however we added the ability to disable some flags as documented here
https://mets-programme.gitbook.io/ugandaemr-documentation/patient-flags
Thanks @ssmusoke, that was useful 
And how does one retire a flag that has been ackowledged/processed?
@mksd That feature does not exist yet, and IMO its a tricky one in multiple aspects
When the data that causes the flag to appear changes - it disappears automatically since it has been processed (not all flags need action - since some are green showing something is coming up)
If the flag acknowledgement is cleared by one service provider, how about others who may need to see the flag? How about the same service provider weeks later?
Currently flags are computed on each display so can be pretty expensive, I wish there was a way to precompute the flags and then recreate them when patient data changes, though some are time based
The basis of this was a suggestion and question I had for clinical decision support thread here Clinical decisions support in OpenMRS
Hi @ssmusoke, all those are very useful points.
At a very broad and high level they clearly indicate that flags can be of very different types: from lightweight non-permanent ones to others that should be subject to a strict process to be cleared from the user experience.
I will read the other thread again, but I needed to bring this up here to the attention of the OpenMRS 3.0 folks since the mockups suggest that there will be notifications.
I remember we have an action item around this probably for OHRI, to start a discussion a way to save computed properties at a patient level, I think some can expire and require computation everyday, or every change of data, while others are more permanent etc
IMO this is the first step for a kind of analytics which helps reduce the reporting pressure - maybe I will raise this in the analytics group
The timing for this discussion is great since one of the next items on Ciaran’s UX deliverables contract (after patient lists) is alerts. (Though I recognize the discussion here is not about engineering not UI.) One of the line items we’re looking at is the different types of alerts, as Dimitri expresses above: There are some that just require being casually seen, and some we want to require confirmation that the user has seen (“Do not pass go, do not collect $200, until you’ve seen this.”)
Adding this as our main agenda item for the TAC call this week.
