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.
I would think that if there patient-specific (rather than provider specific), then they are definitely patient flags in the sense that module implements.
@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
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.