There has been a repeated feature request from doctors for them to be able to mark patients of their special interest (or favourite patients) and view their records quickly, say in a separate queue.
I think the idea is very similar to chrome bookmarks.
With some quick research and analysis, i think this feature is about user-scoped tagging of patients with following functions
- Ability for users to create/update/delete tags. e.g. “My TB thesis”, “Saturday Lecture”, “To review”
- Ability for users to mark a patient with one of these tags from patient dashboard
- Ability for users to see patients grouped under these tags. (Jumping to solution : For consistency and simplicity sake i imagine a screen/queue similar to the Bahmni inpatient wards list page)
I see a significant overlap with Feature request of tagging in Bahmni to show indicators , the difference being the usecases and scope of tags. The showing of indicator can be a good to have for the user scope tags as well with ability for users to choose it to do or not to avoid overcrowding of tags as was cautioned in other thread.
I see similarity with an existing Patients Flags module in openmrs. Haven’t used it but probably it can be used/developed further for this?
Probably the other features like ability for users to mark forms, orders, drugs favourites can use the same generic tags model and api under the hood. May be even the tags in bedmanagement could be merged.
IMO, we don’t need to think of all tagging features (tagging forms, bed managment) all onto same solution.
e.g. bed -management has a specific table for tags, user preference for meds can just be a favorite grouped under a “tag”. The “tag” really means different things in different places.
Take the “tagging patients” for example. Thinking in terms of “tag” is misleading, because this is more of a “state” of patient under a particular visit/treatment-plan. There might be rules/scenarios under which such labels get resolved and I don’t think removing a “label”/“tag” is the right way to do so.
My suggestion will be not to look at every labelling as “tagging”. I think we need to think of the use cases beyond organization of information (Tags/labels), but more of how these labels provide information relevant to the care - notification, alerts/messaging, actions and reporting etc. Like if doctor marks a patient to be “high risk”, then what does it mean - does the care team get notified when a lab results comes up? Does the patient get preferential service etc etc
Thanks for the inputs.
Like i clarified on a call yesterday:
The group of use-cases i am considering here for this feature are simpler and around identifying a group of patients and showing them grouped by labels in a dedicated page or showing label against patients at various places. additionally it could help in exporting data for these specific marked patients (say in research usecase) or have a notification rule around them.
Currently an implementation is using programs for marking such patients and exporting data (because a Bahmni report exists with program filter) but thats an overkill.
Again, these scenarios are not at all about a state of a patient under a particular treatment. And so this feature is not for usecases to be served by much richer features like care-plan, programs or ordersets.
Regarding tags, we began thinking as just a star like in chrome bookmarks but that restricts to putting the patient under only one group/folder which is not desirable. Thinking as tags allows to have patients marked with multiple of those.
A user will create her own tags, and will be responsible to mark and unmark patients under those tags.
Even the other entities (drugs, orders) where we are considering the favourite feature seemed to me to be very similar (mainly ability for user to mark and then view for quick access) The idea was system could have a pre-defined tag called ‘favourite’, a tag service can be used to store and retrieve entities marked favourite using this particular tag and the app layer at different places will know how to make use of it. But if this feels oversimplification or complication, we can keep the scope of this limited to patients for now.
i will try to put up in a writeup some of the implementation details we discussed and share.
thanks for the clarification. Maybe you can put up a doc on the proposed solution?
Also, I am not sure about favourite drugs flow is as useful. What takes time is filling up the dosage and durations etc! By fav drugs, we wanted to store the drug along with its dosage and duration instructions as well.
Note that enabling such favourites action (like clicking on my fav “ESR” test) would require subsequent actions to be taken as well - and for that we should find a extension within the “clinical” module. Like - when a fav test is clicked, the observers of “fav test” are notified, which does the internal API invocation to add the test to the order list. However, I would say that exclude such extensions and actions out of the scope for now (which means exclude tests and drugs or other orders)
we had put some thoughts here. Please add your comments on the doc itself or in this thread
This feature request is being worked upon by @smartyrad as part of Outreachy internship project. You can follow the progress, discussions, etc on this openmrs talk thread.
One of the requirements we heard from one of the implementations is to tag patients as special care patients. User should be able to get appointments for special care patients so that they can follow up with those patients. User should be able to visually differentiate appointments for special care patients. A patient will not always be a special care patient. So, a provider should be able to mark/unmark a patient as special care patient.