Conditon List: Proposed Changes to saveCondition API

Hello all… we just had a design call where we were in favor of making changes to the saveCondition API/method (stripping out a lot of business logic that we feel is incorrect).

Changes proposed:

  1. Currently, when updating a condition it clones the condition, (ie instead of updating an existing row in the DB, it creates a new row in the DB that links back to the first row in the DB). If the the clinical status is not changed, it voids the existing row, but if the status is changed, it doesn’t void the existing row. We propose always voiding the existing row. Therefore, you have an audit trail of changes, but there’s always a single non-voided row containing the “most current” information about a condition.

  2. Currently, when updating a condition, if you change the “clinical status”, the end date of the existing row is set to the onset state of the new version of the condition. Additionally, if the updated condition does not have an onset date, the date is set to today. We propose removing this. The saveCondition method should not alter the dates in any way.

Making these changes should help us fix a lot of bugginess in the current Ref App Condition UI, but my main concern is that this may break code others have written around Conditions. Specifically, we’d like to confirm if Bahmni would be affected by the change? This would also make the Condition logic in OpenMRS Core divergence from the Condition functionality EMR-API (where the core functionality was originally harvested from).

Thanks to everyone that joined the call today!

fyi @dkayiwa @jteich @gcliff @ibacher @mksd @burke


Thanks @mogoodrich.

About Bahmni. It runs on Core 2.1.x + EMR API 1.24.x, meaning that it uses this, hence suffering from the exact same business logic.

I agree with your conclusions. Is it correct to say that basically conditions should behave as observations do? ‘Updating’ means voiding the old one and creating a new one with the updated data?

I would personally advocate for a move to OpenMRS 3.0’s conditions widget, where CRUD operations would be handled by FHIR2 with the usual update flow that you described.

Thanks @mksd… so we could change the functionality in Core 2.4 or Core 2.5 without breaking Bahmni, as long as by the time Bahmni upgrades to Core 2.4 or 2.5 it has migrated to the 3.0 condition widget and not the “Bahmni Condition UI” (which may rely on the “bad” business logic)?

Fundamentally, yes. But that’s with some ifs and whens :wink:

i can’t speak on behalf of the Bahmni Coalition, I stated what we think is the way to go at Mekom.

Thanks @mksd!

Is there a proper way reach out to the Bahmni Coalition? Cross-post on the Bahmni channel?

ticketed here:

1 Like