O3: Plan for Patient Tags / Flags?

[grace (Grace Potma)]

Question: How can we support Tags/Flags in 3.x?

There is a growing need to align how to add tags or flags to individual patients.

Current Design Examples:

1. In a Header, or on a Patient Summary: The latest design proposed for an HIV Summary from this week’s 3.x Design call (though it can be extrapolated to any condition):

   

2. In a sidepanel UX (eg booking appointments):

   

Historical Examples

This is already being done in a few notable areas:

Exhibit A: 2.x RefApp e.g. here is how/where Patient Flags are shown in the iSantePlus EMR in Haiti:

Exhibit B: Custom Extensions in OHRI For Tags in Patient Header

Exhibit C: Tags in KenyaEMR Patient Header

There’s a clear need to support patient tags in 3.x. So how do folks recommend we approach this? What should we apply from the historic OMRS Patient Flags Module? Or, the old work done on the Generic Tagging Module?

CC @mksd @ibacher @jdick @dkayiwa @eudson @wamz @mksrom @bistenes @mseaton @mogoodrich @ssmusoke @dkibet @dkigen @aojwang @piotr @rony & please CC others who may have helpful knowledge here

[burke (Burke Mamlin)]

At least under the hood, we’ve tried to use the term “tags” within OpenMRS to reference a folksonomy (like Discourse or Wordpress topic tags or Atlassian labels), where the terminology doesn’t have to be pre-defined. So, I wouldn’t recommend using the generic tagging module.

The Patient Flags module is closer to the use case you’re describing for OMRS 3.0. It might be too old to be useful, but it does offer a REST API.

[ssmusoke (Stephen Senkomago Musoke)]

@grace I think patient flags would benefit from the computed concepts approach being designed and thought to by the @OHRI team - as the computations can become pretty expensive slowing down their usage

I would suggest the patient flags GitHub - openmrs/openmrs-module-patientflags: Provides a mechanism for marking patient records with important messages within OpenMRS as the foundation with a push to making the computations less expensive

Additional comments:

1. The tags can become many thus I think the header is not a good place to put them
2. Additional features:

• Hiding the flags by gender, location, clinic service areas
• Ability to cache computations until data changes