Project Discussion: Allow healthcare providers to subscribe to notifications about their "favorite" patients

Hello everyone. I am an engineering student from India interested in working with Bahmni for outreachy . Ideas have always excited me. The fact that we could dream something and bring it to life fascinates me. My goal is to bring new ideas to table and deliver a user-centric project for welfare of people.

Please guide me. I want to contribute to this project

Thanks and Regards

Thanks for your interest in this project @manmeet!

Generally speaking you should follow the steps outlined by the Outreachy program itself, as well as the steps we describe here: Applying for an internship? (RGSoC, GSoC, Outreachy, etc)

If you have specific thoughts, questions, or proposals about the favorite patients project, then you can post them in this thread.

@darius @danfuterman @vinay Please guide me:-

  1. healthcare providers are only doctors here or there exist another users also for these feature.

  2. When users will use it. If they use the results of feature while staying in hospital only ?

  3. How they will use? Can they select a patient as favorite but not want any notification. I mean user want to have quick access to a patient but do not want any notification.

  4. With how many types of notifications we should go? This feature should allow user to go for their desired type of notifications or not?

This functionality is generally useful, so I expect that other users will want to use it for other reasons. But we do not know all the ways this will happen ahead of time. (And for this project I would suggest focusing on the one well-known use case.)

In different hospitals, this may be used in different ways. I think that usually the doctor will still be in the hospital when the result comes back, but it’s also possible that the doctor is somewhere else (e.g. they work at different hospitals on different days, or the result comes back when they are at home).

Some possible scenarios (but there are more):

  • (1) doctor sees the patient and orders a lab test, (2) patient goes back to the waiting room, (3) doctor continues seeing more patients out of the queue (i.e. still at hospital in the same consult room, sitting by the computer), (4) lab result is ready, and doctor gets notified, (5) doctor sees the original patient next, before returning to the queue.
  • (1) doctor sees patient in outpatient clinic in the morning, and orders some lab tests, (2) in the afternoon doctor is rounding in the inpatient wards (i.e. still at the hospital, but somewhere else, not in front of a computer), (3) lab result is ready, and doctor gets notified, (4) doctor advises nurse on what action to take
  • (1) doctor sees patient, and orders a lab test that takes days to complete, (2) patient goes home, (3) result is ready, doctor is notified, (4) doctor works with registration clerk to track down patient.

This is a good question. I think you’re right that it makes sense to separate “favorite patient” and “notifications of new results/activity” into two separate functions. Also that will make it easier to build in an agile way. I.e. first you build the ability to favorite patients, and to view your favorites. Later you build the notification on top of this. @arjun might have ideas to share.

In the long run, we would like to support multiple kinds of notifications, and the user sets their preferences. But in the scope of this outreachy project I would do only one kind of notification. This should be a type that is easy to implement (for the sysadmin) and doesn’t impose any costs on the hospital (e.g. probably not SMS).

I also agree. It makes perfect sense to consider and build these as two separate functions. Later on some clubbing can happen. In first iteration the notification be just about having notification rules defined by “searching a patient → selecting an event → selecting a notification type” and getting notifications. In the second step a convenience can be added where a user can choose to define these notification rules by choosing a set of patients/favourite patients. I will create a separate talk thread to discuss the feature about favouriting patients. We could limit this thread to discuss about the notification feature.

  • I’m a big fan of the dotadiw, so would favor a module focused on providing a favorite patients service (notifications in a separate module) – focus on presenting the favorite patients service via a REST API and adding hooks into the UI to add the “stars” in the most convenient places to favorite a patient. This approach would allow it to be used in any distribution (not just Bahmni).

  • Doctors would be more likely to use notifications for results (though not exclusively). On the other hand, any provider could benefit from being able to favorite a patient.

  • For a “favorite patients” module, think it would be most powerful if this module would leverage cohorts – i.e., create a dynamic cohort of favorite patients. This would allow any other feature (reporting, cohort builder, etc.) to reference a provider’s favorited patients.

  • When I proposed a favoriting feature for our local EMR, I envisioned a favorite star icon in a split button dropdown that would allow a provider to optionally specify their relationship with the patient (e.g., “Primary provider” vs. “Consultant”). I suppose a similar approach could be used to allow a provider to choose between default (just click the star) vs. alternative options for notification

  • In my personal experience with notifications:

    • Centrally manage notification preferences for favorited patients (i.e., notify me whenever a “favorite” patient is admitted or discharged)
    • Most notifications of results would go into a inbox (preferably one shared with a care team so there isn’t a single point of failure)
    • Tag specific tests to notify me (e.g., text me when this patient’s potassium level comes back because I’m worried about it)
1 Like

Have created this thread to discuss about the ‘favourite patients’ feature : Ability for providers to mark/tag patients of special interest