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).
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.
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!