EncounterDiagnosesElement.java contains hard-coded encounter type

The openmrs-module-coreapps api-2.2 version of EncounterDiagnosesElement.java uses a hardcoded encounter type when saving a diagnosis, what is the purpose of this, and can it be removed?

@pluwum, @dkayiwa, @mogoodrich

Thanks, Dominic

@dsurrao what do you think would be the best way of handling this?

On my local instance, I removed lines 277 and 278 and was able to save a diagnosis (the DB did not have the value VISIT_NOTE_ENCOUNTER_TYPE_UUID).

But I’m trying to understand the intention of those two lines in the first place, do you know?

Thanks.

@dkayiwa, I agree with @dsurrao… our opinion is that these two lines can just be removed, but we were wondering if we were missing something. Why is this element trying to change the encounter type of the HFE encounter?

@dkayiwa… a ping here… do you think there is any reason not to remove lines 277 and 278? Thanks!

@dsurrao which version of the OpenMRS platform are you running?

@dkayiwa 2.2.0-SNAPSHOT of openmrs-core

And how are you saving diagnosis via the user interface?

Is this sufficient? https://github.com/openmrs/openmrs-module-coreapps/commit/79318e740f6757259fa80016d1457d9be1127a38

@dkayiwa maybe I’m missing something, but although this would work, I still think your commit above is redundant?

This element would only be used to save a diagnosis via an HTML Form.

@mogoodrich yes you are correct to say that this element is used for saving diagnosis via html forms. When that line is commented out, the diagnosis’s encounter does not have an encounter type and trying to save it results into a validation exception. Could there be something am missing that leads to the encounter type being null?

@dkayiwa where are you seeing this behavior (encounter type being null)? Currently, Html Forms are always in the context of an encounter, so the encounter type should come from the tag within the form… are we trying to handle a case when we use the tag without specifying an encounter type?

Per your commit, what I’m saying is is that this line seems redundant/meaningless:

… based on the previous line here:

(and if we aren’t changing the encounter, we don’t need this line):

@mogoodrich am seeing this behaviour when i enter a visit note in the reference application running on platform 2.2

Thanks @dkayiwa… sorry, can you point me to the underlying HTML Form that visit note uses? I’m not 100% familiar with where forms live within the reference app.

After the change to lines 277 did you confirm that the issue is still resolved?

Take care, Mark

This is the visit note form https://github.com/openmrs/openmrs-module-referenceapplication/blob/master/omod/src/main/webapp/resources/htmlforms/simpleVisitNote.xml

The last commit was not addressing any error. It was just addressing your comment of not hardcoding an encounter type. But without those reported lines, you cannot save any visit notes from the refapp on platform 2.2

Thanks @dkayiwa!

I just meant, I wanted to confirm that after your change you are still able to save a visit note…

Ah, okay @dkayiwa, I have to run to a meeting but I think I understand now, will follow up shortly…

So @dkayiwa I think the issue in order to persist the diagnosis, the encounter needs to be persisted been first. Ideally instead of saving the diagnosis directly within the EncounterDiagnosisElement it would happen in the apply actions section of HFE:

But since we aren’t doing that, we need to make sure we save the encounter within the encounter diagnosis element… and we need to manually set the encounter type since in HFE the encounter type associated with the form isn’t set on the encounter until the encounter is saved:

So I’ll try to take a quick look to see if it would be easy to create a submission action to create a diagnosis, but otherwise I think the current implementation with your change makes sense. Thanks!

Take care, Mark

You are spot on! :slight_smile: