Migrating existing condition data captured via the emrapi module

Hello everyone,

We desire to migrate the existing condition data captured via the emrapi module to the new condition table as contained in the core data model which supports Encounter Diagnoses as shown here. There are differences in the two condition tables as can be seen here. For the new condition table, verification_status and clinical_status fields are not nullable.

  • How do migrate the data putting into consideration that the new table has some nullable fields?

  • Do we make those fields nullable?

  • Do we assign a default value when migrating the data?

What are your suggestions please?

cc @dkayiwa

Please note that there are two different things that need to be migrated from the emrapi module to the new model, encounter diagnoses (which are stored as obs groups) and conditions (which have their own table).

  • According to https://issues.openmrs.org/browse/TRUNK-5015 Condition.verificationStatus should be optional, so if it’s not in the old model it should just be blank in the new model.

  • The new Condition.clinicalStatus should map exactly to the old Condition.status (it has exactly the same values).

  • The old concept_id should map to the new condition_coded.

  • condition_coded_name is a completely new thing and should have no default value

It’s interesting that we’re losing end_reason. I wonder if that’s an oversight. @sanjayap can you share what sorts of values Possible is storing in the end_reason column for conditions in the emrapi module?

1 Like

It is interesting and well noted that the Condition.verificationStatus is optional. We are effecting the change right away. This solves the challenge. We are eagerly anticipating more clarifications on end_reason field. @darius @sanjayap

1 Like

Hi @darius / @paradise,

I had actually replied earlier in this thread but now I wonder how my reply got omitted from here . may be due to internet connectivity that day, it was not posted.

Anyways , my update regarding the mentioned field. I checked in our(Possible’s) productions environment and I find Condition. end_reason is storing just null values only.

cc: @sanjayap

1 Like

@paradise have you seen this? It looks like in the first implementation to adopt conditions from the emrapi modules is not using condition.end_reason.

(@burke, @jteich, in our many design discussions about conditions, did we intend not have an “end reason”? I certainly understand that in real life doctors would be extremely unlikely to fill this out with any regularity, but the Bahmni/Possible implementation of condition lists does include a coded endReason in the data model. FHIR does have a Condition.abatement, though not exactly the same…)

1 Like

@darius Based on this information, leaving out condition.end_reason would not out of place in this implementation.

1 Like

Yes, you should proceed without that field. (But I’m still curious to hear from others if we should reassess.)