Multiple implementations of EncounterService, is that something possible?

Hi everyone!

I’d like to have a the saveEncounter() method to ensure there is an active visit for this patient before saving an encounter.

To do so, maybe I could bring my own implementation of EncounterService and somehow find a way to override the current EncounterServiceImpl#saveEncounter() method (in openmrs-core). Just add one check, ie, has active visit, and then fallback to the core implementation.

Is it something possible within Spring and OpenMRS framework?

Or am I getting this totally wrong? :confused:

The aim is to override the default behavior through the whole app so I don’t rewrite code of any other module…


Short answer to your specific question: we support using AOP to override any service method (or to add pre- or post- advice).

But if I’m understanding your actual goal right, you should be able to do this by setting the EncounterVisitHandler. This is supposed to be a pluggable mechanism to control which visit an encounter gets assigned to, and it’s allowed to create that visit. (There’s a global property that controls this. There are a couple implementations in openmrs-core, and I think another one in the emrapi module which may be used by the reference application.)


Thanks @darius,

Let’s talk about option 2 first: EncounterVisitHandler

If I understand correctly, we can set the visits.assignmentHandler property to define our own VisitAssignmentHandler class, in which we can code the beforeCreateEncounter() method.

Emr-api already sets the visits.assignmentHandler global property to use its own EmrApiVisitAssignmentHandler, so I guess I should override the property value with my own.

Q: How can I be sure that my value will be prevalent over the one set by Emr-api?

About your second point:

Could you tell me more on how to achieve that? (Or just point me to an example)

See the Technical Overview and OpenMRS AOP wiki pages for more information and examples.

In the short term, if you make your module depend on emrapi it will be started afterwards, so you can set the value in the activator.

A better fix is that we should not be setting this in emrapi itself, but in the reference application module, because it’s really a function of the distribution. (Though this won’t change what you have to do because you’re building on the reference application.)

-Darius (by phone)

I think you can achieve the same with a custom EncounterSaveHandler that does the same thing


Thanks @pascal for useful the links.

Good to know. I’ll check that too.