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?
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-5015Condition.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?
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
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.
@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…)