Bahmni Patient Tagging Module (Outreachy 2018)

[smartyrad (Smarita Sharma)]

Hi everyone! I’m working on the patient-tagging module for Bahmni as part of the Outreachy ‘18 project. The highlights of my discussion with my mentors so far are:

1. Trello Board
2. Design Mockup
3. Data Model

This is the link to the Trello Board for the Bahmni-patient-tagging-module.

I’ve created a user story to walk you through the design mockup for the project and have also made the data model for the same. Click on this link to view the document.

Kindly go through it and drop in your valuable suggestions.

CC : @arjun , @vinay , @danfuterman , @darius

[ssmusoke (Stephen Senkomago Musoke)]

@smartyrad is this going to be a brand new module or an extension of the Generic tagging module?

If a new module what are the reasons for going brand new and not building upon what exists?

[mksd (Dimitri R)]

Looks like @smartyrad was investigating this, see here. @smartyrad what are the findings so far?

As a general matter of fact reusing/expanding modules should be preferred over starting anything from scratch (see here for my comments on another case like this with unintended dramatic consequences for a low-resource setting). Especially when it comes to creating a REST/Java API, there is just no reason for such APIs to not be reusable across the whole OpenMRS spectrum (Ref App vs Bahmni… etc etc).

I have not been through all the Trello cards (I can’t comment on them btw, for reference my user is mks_d on Trello) but I would suggest the usual approach:

• OWA for the front-end.
• Shared REST API for the backend, hopefully the Generic Tagging module.

[smartyrad (Smarita Sharma)]

Hi @ssmusoke, @mksd, Thank you for your suggestions! On giving it a thought, I decided to compare the generic tagging module with what I aim to build, and came up with a few observations that I would like to discuss here.

Kindly go through this link and let me know your thoughts on the limitations and the reusable part of the API that I have listed here.

Thank you for your time

CC: @arjun , @vinay

[arjun (Arjun Khandelwal)]

@ssmusoke @mksd and others interested, i am completely inline with your thoughts around trying to leverage and build upon existing work rather than doing stuff for scratch. We (I, @vinay and @smartyrad) already had the plan to review the generic tagging module and have done that.

The findings from a spike @smartyrad did are already shared by her.
While its designed keeping in mind how the tagging functionality generally is used on blogs, etc, that is type any string against an entity and it would be tagged with that, its not inline with the usecase and how we have thought the functionality as (usecase detailed in this openmrs talk thread). Like it doesn’t have the ability to have predefined tags or user-scoping of tags, etc. The difference in use-cases also makes me think if we should call this “lists” instead of “tags” but that’s a minor change. While the existing module can act as a good starting point and can definitely be modified and extended to meet these use-cases, i am not sure if everyone and the owner of the module (if there is one) would be open to that as there might be some divergence as well from existing behaviour.

How do you guys suggest moving forward? While we have decided to fork the project and proceed for now, shall we discuss this in the Bahmni PAT call this Wednesday? Its done part of a internship project, so we have limited time at hand.

[ssmusoke (Stephen Senkomago Musoke)]

@arjun

While its designed keeping in mind how the tagging functionality generally is used on blogs, etc, that is type any string against an entity and it would be tagged with that, its not inline with the usecase and how we have thought the functionality as (usecase detailed in this openmrs talk thread). Like it doesn’t have the ability to have predefined tags or user-scoping of tags, etc. The difference in use-cases also makes me think if we should call this “lists” instead of “tags” but that’s a minor change.

The idea is to tag patients, then what you do with the tags is another matter. Usually we create lists of out of tags which may be better placed in the cohort builder OWA/module which creates lists of patients

[mksd (Dimitri R)]

Thanks @smartyrad, that’s really helpful. About the limitations that you spotted:

1. Inability to create a standalone tag where patients can be added later.
2. Missing ability to attach a visibility (public/private) status to a tag.
3. Inability to associate multiple entities to a single tag.

To be brainstormed of course but on the surface I’m not too concerned about 1 and 2.

@wyclif, how would you go about 3 (see here). Typically what is desired is to set the same tag to a group a patients such as described here by @pramidat:

@pramidat

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.

[wyclif (Wyclif Luyima)]

@mksd based on the current implementation of the module, same tag means a tag with the same name and not really the same tag object, it’s still possible to look up patients with the same tag even though the referenced tag object might be different.

[mksd (Dimitri R)]

I wonder if we should

• Simply do that (but It doesn’t feel quite right).
• Go down the road of an ad-hoc implementation specific to Patient.
• Try to expand the module so that tags could be reused multiple times for all entities (sounds a bit out of scope…)

Others, thoughts? @darius?