<encounterDiagnoses></encounterDiagnoses> after <obsGroup></obsGroup> with empty obs throws validation error (obsDateTime cannot be empty or null)

rrameshbtech · February 13, 2020, 6:35am

Hi All,

We are getting exception when we are having with obsGroup & both are filled.

Exception: obsDatetime: Cannot be empty or null

As per our exploration so far, when encounterDiagnosis tries to save encounter it does not check & update each observation’s obsDateTime. But it is done while encounter is saved through FormEntrySession.

References

github.com

openmrs/openmrs-module-coreapps/blob/158b57c112d898e8972393349a4f9aae211e2e53/api-2.2/src/main/java/org/openmrs/module/coreapps/htmlformentry/EncounterDiagnosesElement.java#L328


        diagnosis.setDiagnosis(new CodedOrFreeText(answer.getCodedAnswer(), answer.getSpecificCodedAnswer(), answer.getNonCodedAnswer()));
        diagnosis.setEncounter(formEntrySession.getEncounter());
        diagnosis.setCertainty(certaintyStatus);
        diagnosis.setRank(rank);
        diagnosis.setPatient(formEntrySession.getPatient());


        if (diagnosis.getEncounter().getEncounterType() == null) {
            diagnosis.getEncounter().setEncounterType(formEntrySession.getForm().getEncounterType());
        }
        HtmlFormEntryUtil.removeEmptyObs(formEntrySession.getSubmissionActions().getObsToCreate());
        Context.getEncounterService().saveEncounter(diagnosis.getEncounter());
        Context.getDiagnosisService().save(diagnosis);
    }


}


// Remove Diagnoses that were not resubmitted
Collection<org.openmrs.Diagnosis> diagnosesToVoid = CollectionUtils
        .subtract(existingDiagnoses, resubmittedDiagnoses);


for (org.openmrs.Diagnosis diagnosisToVoid : diagnosesToVoid) {

github.com

openmrs/openmrs-module-htmlformentry/blob/45d3f8522d3e73aa4c0a2c75d6da59147d062754/api/src/main/java/org/openmrs/module/htmlformentry/FormEntrySession.java#L503


        // remove any obs groups that don't contain children

		HtmlFormEntryUtil.removeEmptyObs(submissionActions.getObsToCreate());



        // propagate encounterDatetime to Obs where necessary

        if (submissionActions.getObsToCreate() != null) {

            List<Obs> toCheck = new ArrayList<Obs>();

            toCheck.addAll(submissionActions.getObsToCreate());

            while (toCheck.size() > 0) {

                Obs o = toCheck.remove(toCheck.size() - 1);

                if (o.getObsDatetime() == null && o.getEncounter() != null) {

                    o.setObsDatetime(o.getEncounter().getEncounterDatetime());

                    if (log.isDebugEnabled())

                        log.debug("Set obsDatetime to " + o.getObsDatetime() + " for "

                                + o.getConcept().getName(Context.getLocale()));

                }

                if (o.getLocation() == null && o.getEncounter() != null) {

                    o.setLocation(o.getEncounter().getLocation());

                }

                if (o.hasGroupMembers())

                    toCheck.addAll(o.getGroupMembers());

            }

Please guide us know if this needs to be fixed or are we missing something?

This issue looks similar to below issue which seems to be fixed.

CC: @mksd, @ruhanga, @mddubey, @sukreet, @angshuonline

mksd · February 13, 2020, 8:37am

@ruhanga can you confirm whether a similar fix than the one you did might be needed elsewhere as well?

ruhanga · February 13, 2020, 8:57am

Sure, thanks @rrameshbtech, @mksd. I’m spiking on this.

ruhanga · February 14, 2020, 1:31pm

The <encounterDiagnoses/> tag with openmrs-core 2.2 and above saves diagnoses associated with a given encounter as diagnoses rather than obs. This is currently possible in its handler by first saving the encounter in the middle of handling submissions of the involved tags. Saving an encounter requires some preliminary validations which should be specifically done by the FormEntrySession as shared by @rrameshbtech.

Because of this, it’d be better to save diagnoses in an CustomFormSubmissionAction for the associated <encounterDiagnoses/> handler. I’d think and suppose that EncounterDiagnosesElement extends CustomFormSubmissionAction and registers a <postSubmissionAction/> handler referencing itself. This would help avoid re-validating and re-saving the encounter with respect to the involved HTML-form-entry widgets/tags.

cc: @mogoodrich

mogoodrich · February 14, 2020, 10:56pm

@ruhanga I didn’t look into this too deeply, but conceptually this makes sense to me!

Generally, data should be committed as part of a “form submission action”. So it would make sense to for EncounterDiagnosesElement to register a custom form submission action to support this during that stage in the form submission.

(Actually, if EncounterDiagnosesElement lives in the HFE entry module it would also be find to add submission action directly for FormSubmissionActions, but I don’t think it does… in the original design, FormSubmissionActions weren’t easily extensible, and the CustomFormSubmissionAction was a quick attempt to make it possible to extend… if we ever refactor I would think we could move much of the content of FormSubmissionActions into separate “FormSubmissionActions” so in essence most actions would be “Custom”… but anyway, that’s a tangent… )

Take care, Mark

ruhanga · February 17, 2020, 5:59am

Thanks @mogoodrich. I have created a ticket for this, RA-1705.

cc: @rrameshbtech

ruhanga · February 20, 2020, 6:25am

@rrameshbtech, thanks for reporting this issue. RA-1705 that resolves it has been merged. I hope we are good to depend on coreapps version 1.27.0 (-SNAPSHOT) .