Episodes Of Care: Coordinating Bahmni & eSaude needs & work

Hi all, especially @bharatak, @janflowers, @pascal, @burke, @jteich ,

I understand that Bahmni has a time-critical need to implement Episodes of Care, and that eSaude (Mozambique) also has a strong need for this feature (a bit less urgently), and is thinking about the design now to work on in the coming months. And both groups would intend that whatever they implement gets adopted in OpenMRS core.

Jan and I spoke, and it seems like it should be possible to coordinate this effectively (though we havenā€™t spoken directly with the people who will be doing the actual work, so please say whether this seems feasible or not given real-world constraints)ā€¦

  1. There is a baseline proposed design on the Episodes of Care wiki page.
  • Both Bahmni and Moz teams want episode and episode_encounter_map but donā€™t care about episode_visit_map.
  • @bharatak is proposing to add two columns to the proposed episode table: episode_type and episode_entity_uuid, e.g. to indicate ā€œthis episode is tied to a program enrollment, and that program enrollmentā€™s UUID is xyz.ā€
    • This seems correct to me, given the conversations we have had (e.g. another implementation might use these same columns to link to an OrderGroup representing a hypertension management protocol. I donā€™t like episode_entity_uuid as a column name though, and would prefer something like episode_linked_to episode_link_ref. (Now that I type those, I donā€™t like those so much either.)
    • @burke, is this approach good enough for you to satisfy what youā€™re getting at in this comment? Otherwise Iā€™m concerned that ā€œa resource above them to create flexible relationships between themā€ is not something that weā€™re going to be able to design out on a reasonable timeframe.
  • @bharatak, you also seem to be proposing we drop the start_date, end_date, and episode_topic columns. I expect that @burke will want to see those when this gets into openmrs-core for the broader use case (and I think I agree with that), so my recommendation would be:
    • add start_date and end_date to the DB as optional columns when we implement this, and just donā€™t use them.
    • add episode_topic to the DB as a required field, and in Bahmniā€™s use just populate this with the value of patientProgram.program.concept
  • I suggest doing this in a new module called episodesofcare (rather than putting it in bahmnicore, or in an eSaude module). Whoever starts coding first will drive the work.
  • @pascal is probably available to help do this work (and South Africa and India are in compatible time zones)
  • one approach could be that @pascal could help implement the OpenMRS module piece of this, or perhaps the REST side of it
  • another approach is that while Bahmni is building a data model for episodes of care to work with Programs, Pascal could test this out to ensure it also works when you link episodes to orders/order sets.

Basically, it seems at first glance like this can be built in a way that takes no extra work from anyone, and gets it ready for openmrs-core even sooner. So let me know what you all think about this.

2 Likes

Hopefully, the use cases across the groups and individuals who are interested will be the actual drivers of the work! :slightly_smiling:

Hi Darius, Thanks for bringing this up. We would love to coordinate on the effort and get it done. Currently we are on a very strict schedule and we want this feature (not a full blown one though) for our next release of Bahmni which is scheduled on March 03, 2016. We will definitely collaborate on this once we have the minimal functionality that we have for our usecase. We will keep you posted on our status in next few days on how this is implemented and how do we take it from there. Thank you.

Important thread here. I missed the Jan. 27 call but the notes look good. Perhaps after Bahmni finishes the current urgent job we can get together again and see if anything needs tweaking / what else is needed to have a consistent structure.

1 Like

Hi @bharatak - is there a document somewhere that talks about your use case and the approach youā€™re taking? Weā€™d like to see if it aligns with the work we are doing in Moz so that we arenā€™t duplicating efforts here.

Hi We are still in the process of spiking and initial analysis. We will share our inputs in a week or two.

This is a critical clinical use case and functionality. I agree with Jonathanā€™s perspective about the need for a consistent structure in this topic area ( as it will impact care plans and other future clinical work). Will be good to look at the analysis.

1 Like

Apologies for being really late on this thread. We had not separated this out into a different module when we started, and pressures of delivery pushed the separation out quite a bit.

A first version of episodes of care is currently available here. We can discuss further on how to take this forward. Please take a look. We are open to suggestions, and are interested in collaborating to create a generic solution for broader use cases.

1 Like

Hi @vinay - thanks for sharing this. Is there documentation around what the module is doing? For example, can you share the use case that you built it upon, functional and technical specs, the data model that is implemented, or etc? Thanks!

Peeking at the code I see the model is that an Episode is a grouper that may point to (some of) a patientā€™s encounters and program enrollments. It looks like:

Episode {
    id
    encounters // list of encounters that belong to this episode
    patientPrograms // list of program enrollments that belong to this episode
    // standard audit fields
}

I guess this is used in the endTB system to capture the fact that a single patient might have multiple treatments over time, right? Can you elaborate (a bit) on this use case? (And, how does this tie to program enrollments? Offhand I canā€™t think of a use case for having multiple program enrollments for a single episode.)

Perhaps we should schedule to discuss this on some future design call?

1 Like

@janflowers - The module is just a simple service that exposes the ability to create episodes, and link them to either programs or encounters. We can add episodes, and link them to either program enrollments or encounters. What can be done with episodes is upto the consumer.

The first usecase we implemented was in the endTB system for MDR-TB treatment. When a patient gets enrolled to a TB treatment program, we create an episode for the patient. All further encounters created in this program context are then linked to this encounter. This helps us view all encounters that are tied to an episode.

Before encounters, we tried to rely on the program start and end dates. However, this turned out to be the wrong choice. There could be encounters within the program start and end dates that are not related to TB treatment. There could also be encounters that happen outside the program start and end dates (both before program enrollment and after program has ended), and they still are relevant for patient treatment. This was the primary reason to introduce the concept of episodes.

As @darius mentioned, we designed episodes to be a loose grouping of both encounters and program enrollments (close to the proposed design, but with some differences). We currently do not have a need to have multiple program enrollments tied to the same episode. One usecase of multiple program enrollments could be for a child with stunted growth enrolled in a regular mid-day meal program and an intensive nutrition program (both managed by different groups, but observations made in both are relevant to a provider). Or just two bouts of enrollment to the same time-bound program, when the first one was not sufficient.

We can discuss on a future design call if others are interested.

1 Like

Current datamodel looks like this.

Like @darius, I pictured episodes as having a ā€œsubjectā€ ā€“ i.e., the ā€œtopicā€ for the episodeā€¦ is this an episode about pregnancy? an episode of TB treatment? etc.). Currently, the obvious candidates for the subject of an episode are (1) a condition and (2) a program.

Looking at FHIRā€™s EpisodeOfCare, they actually allow for multiple (1ā€¦āˆž) conditions for an episode (which we should support). So, it would make sense to allow an episode to reference multiple programs too.

For both conditions and programs, the relationship would be many-to-many. So, the service method

Episode getEpisodeForPatientProgram(PatientProgram patientProgram);

could return multiple Episodes, so should probably be:

Set<Episode> getEpisodesForPatientProgram(PatientProgram patientProgram);

Iā€™d still like to eventually be able to link an episode to a visit instead of having to link to every encounter in the visit. FHIR already does this, since they use their Encounter to represent both visits and encounters. We could do this by adding Set<Visit> visits as a property on Episode and adding a convenience method like boolean isEncounterInEpisode(Encounter) that would return true if the episode is linked directly to the given encounter or linked indirectly through a visit that contains that encounter.

The changes make sense. @jthomas Shall we have a design call to take this forward?

Hi @vinay there is space on Wednesday, May 11 (6-7pm UTC) or Monday, May 16 (4-5pm UTC) for design forum discussion. Would one of these dates/times work for you? Are there others you would like to make sure attend this discussion?

Since @vinay is in India, I would think it needs to be a Monday call, not a Wednesday one.

Thank @darius Iā€™ll wait to see if May 16th works for him.

(I clicked send too early on that last one)

@jthomas, this call also needs to have @burke, @janflowers, and perhaps the appropriate person from eSaude (Jan can say who)