[emrapi] Add patient program uuid to Encounter Transaction

This is regarding the BaseEncounterMatcher functionality of emrapi. The BaseEncounterMatcher interface allows implementations to plugin custom logic that determines the encounter that a specific encounterTransaction needs to be part of. The relevant method in the interface takes in two parameters - visit and EncounterParameters. Implementations can then implement their own version of EncounterMatcher that determines the right encounter.

In Bahmni, we are building the ability to create different encounters based on the patient program that a user has selected on the UI. This means that our implementation of BaseEncounterMatcher needs to distinguish encounters based on the context of the currently selected patient program. One good way I can think of doing this is to change the contract of EncounterTransaction to add patient program uuid, and to use this when constructing EncounterParameters within EmrEncounterService.

Does this look sensible?

It sounds like the implication of that is to say that the EncounterTransaction happens for (optionally) one program enrollment. This seems reasonable for the 80% use case, but I do wonder what happens about encounters that (in real life) “belong to” more than one program enrollment?

Shouldn’t we consider implementing this based on Episode Of Care?

I am thinking that EncounterTransaction should support both program enrollment as well as episode of care. However, emrapi or openmrs does not understand episodes right now.

We have slotted work to move the current rudimentary implementation of episodes of care from bahmni-core to a new module. Once this is done, we can discuss the design, make changes as necessary. When the design is finalized, we will incorporate episodes into encounterTransaction.

I’d prefer we avoid hardcoding relationships between these resources (programs, visits, encounters, and episodes of care) into the resources themselves. I’d also prefer we allow many-to-many relationships, since it’s much easier to implement a 1-to-many relationship in a system that supports many-to-many than vice versa. So, I’d favor externalized relationships (like program_encounter_map ) over adding foreign keys to each other directly on the domain objects.

Understood. Just to be clear, the new variable I am proposing will be extra metadata that can potentially be used by pluggable hooks. It will not change behaviour of the resource.

@vinay and I chatted directly and decided to approach this as adding additional “context” to the submitted encountertransaction (and allowing the Encounter Matcher to access this).

The work is done here: