Thoughts on behaviour of diagnosis edit [EMRAPI]

preethi.s · October 17, 2016, 6:45pm

Emrapi stores diagnosis internally as obs group with actual diagnoses, order and certainty as group members. The UI which we use in Bahmni:

Behaviour before Openmrs 2.0: Whenever we edit some properties of diagnosis like order or certainty in the same encounter as which it is created, we just void and recreate the obs of that property. For example: When we change certainty of the diagnosis, we void the certainty of the diagnosis and recreate it. And the date in which it is edited is set as obsdatetime of top level obs. Whereas when we edit the diagnosis in different encounter, we recreate a new hierarchy of the diagnosis but not void the old hierarchy since the diagnosis was correct for that timeframe.

Behaviour since Openmrs 2.0: Since 2.0, whenever we edit the diagnosis in the same encounter, the whole obs hierarchy is recreated since obsdatetime is changed in the top level obs (the parent obs becomes dirty and whole hierarchy is recreated).

Wanted to bring up this topic here to hear some thoughts on the behaviour, whether the change is acceptable?

darius · October 25, 2016, 9:57am

Is this behavior coming from Bahmni, from emrapi, or from openmrs-core?

This is the intended behavior in OpenMRS Platform 2.0+. If you edit a parent obs in any way it is voided-and-recreated (and so are its children).

I think what we’re doing in Bahmni in the edit-in-same-encounter scenario is wrong from a domain modeling perspective. (Though I see how we ended up there, given the way we’re using encounter transactions…) Is this an edge case, or is it the an expected use case?

If I made a data entry error and accidentally clicked Presumed instead of Confirmed, and I switch this, it should be a void-and-recreate of the certainty obs, but it should not change the date of the parent obs group. If I change the certainty from Presumed to Confirmed because I have gotten back new info like a lab result, this should be a new obs group (just like in the “different encounter” scenario you describe). But really OpenMRS doesn’t intend for you to capture both of these in a single encounter.

If this is just an edge case, I think the new 2.0+ behavior is fine. If it’s an expected case…the 2.0+ behavior is not worse than what we were doing before, data model-wise.

preethi.s · October 25, 2016, 11:04am

The behaviour of setting the diagnosisDateTime as obsDateTime for the top level group comes from emrapi.

github.com

Bahmni/openmrs-module-emrapi/blob/master/api/src/main/java/org/openmrs/module/emrapi/encounter/EncounterObservationServiceHelper.java#L72


      
                      Obs obsFound = this.obsMapper.getMatchingObservation(existingObservations,observationData.getUuid());
                      encounter.addObs(this.obsMapper.transformEtObs(encounter,obsFound, observationData));
                  }
          }
          
          public void updateDiagnoses(Encounter encounter, List<EncounterTransaction.Diagnosis> diagnoses) {
              for (EncounterTransaction.Diagnosis diagnosisRequest : diagnoses) {
                  org.openmrs.module.emrapi.diagnosis.Diagnosis diagnosis = createDiagnosis(diagnosisRequest);
                  Obs obs = emrApiProperties.getDiagnosisMetadata().buildDiagnosisObsGroup(diagnosis);
                  Date diagnosisDateTime = getCurrentDateIfNull(diagnosisRequest.getDiagnosisDateTime());
                  obs.setObsDatetime(diagnosisDateTime);
                  if (diagnosisRequest.isVoided()) {
                      voidDiagnosisObservation(diagnosisRequest, obs);
                  }
                  encounter.addObs(obs);
              }
          }
          
          private void voidDiagnosisObservation(EncounterTransaction.Diagnosis diagnosisRequest, Obs obs) {
              obs.setVoided(diagnosisRequest.isVoided());
              obs.setVoidReason(diagnosisRequest.getVoidReason());

The behaviour of editing the diagnosis in the same encounter is expected only due to data error. @vinay @bharatak can comment more.

darius · October 26, 2016, 6:00am

Okay, if this is expected only when fixing data entry error, then I think Bahmni has generally been doing the right thing.

From the code snippet you include, I think you’re talking about the scenario where we get the current date because diagnosisRequest.getDiagnosisDateTime() == null. If you are editing an existing diagnosis, shouldn’t we set the datetime as part of https://github.com/Bahmni/openmrs-module-emrapi/blob/master/api/src/main/java/org/openmrs/module/emrapi/encounter/EncounterObservationServiceHelper.java#L89 ?