Setting EncounterRole in EncounterTransaction

[mogoodrich (Mark Goodrich)]

Hello all–

We’ve started to use the EncounterTransaction functionality provided by the EMR API module within our new Visit Note. So far it has been working well. However, we’d like to be able to set the encounter role of providers, and currently, if I’m reading the code correctly, EncounterTransactions only support setting an encounter role of UNKNOWN ROLE. (I think the relevant code is: EncounterProviderServiceHelper:39).

Two questions:

1. Am I wrong about this, and is there a way to set the Encounter Role when associating a provider with an encounter via an EncounterTransaction?

2. If not, would people be opposed if we added this functionality? Ideally, you could modify an Encounter Transaction to allow one to pass in an Encounter Role with a provider, those for our case it might be sufficient to create a new global property “Default Encounter Transaction Encounter Role”, that, if present, is used instead of the role set in the “Unknown Role” GP.

Thoughts? @darius @vsingh

Thanks! Mark

[darius (Darius Jazayeri)]

I agree that the REST API should allow you to specify what provider + encounter role you are currently submitting data for. And I also agree that this should be optional and configurable, as many UIs won’t want to bother with this.

I would presume that if you submit an encounter transaction explicitly saying provider = Alice, encounterRole = Clinician, then this should only match an existing encounter that has Alice in the Clinician role, but if you submit without saying what encounter role, then it should match any encounter with Alice as a provider. (In practice the distinction is a very small use case.)

[mogoodrich (Mark Goodrich)]

fyi, I’ve added a ticket EA-90 and started working on this.

I wasn’t planning on touching the “matching” logic, at least in the first pass.

I’m currently blocked on testing due to:

EMR-API OMOD module tests aren't being run

I’ve been working on adding some new tests to EmrEncounterController_1_111_Test (while working on EA-90). When I tried to run the EmrEncounterController tests via junit/Intellij I got various application context errors. Rather than trying to debug, I simply ran “mvn clean install” to execute the tests via maven. When (after adding my new tests) “mvn clean install” passed without error I was suspicious (tests never pass the first time!). I probed deeper and confirmed that none of the tests in…

[mogoodrich (Mark Goodrich)]

For the basic use case, if you attempt to add provider “Alice” with role “Surgeon” to an encounter that has “Alice” with a role “Doctor” should you:

1. Make no changes, leave “Alice-Doctor” as the provider

2. Add a second Encounter Provider, so you have “Alice-Surgeon” and “Alice-Doctor”

3. Change the EncounterRole of the existing EncounterProvider from “Doctor” to “Surgeon”?

[darius (Darius Jazayeri)]

I think “2) Add a second Encounter Provider” is the only option that makes any sense.

Thinking more, and stepping back, I guess I would expect the default behavior to match an existing encounter based on same encounterType + compatible location + compatible datetime.

If you’ve matched a specific encounter, you should “add a new EncounterTransaction to the encounter.” Today this is conceptual, and means adding more obs, orders, and providers to the encounter. (Someday in the future the core API will support this natively, and we’ll need to change the web service to leverage that.)

[mogoodrich (Mark Goodrich)]

This makes sense @darius. I will implement that way.

fwiw, I’m not touching (nor have I looked deeply into) the matching behavior. I’m (mainly) touching the EncounterProviderServiceHelper “update” method, which, given an Encounter and a Set<EncounterTransaction.Provider>, updates the encounter accordingly.

Mark