There are several threads with great discussions around Condition List in the Talk archives. I wanted to use this thread focus on the clinical status field.
In 2017, there was an initial design thread around adding Conditions to OpenMRS. In this thread, there was a particularly vigorous discussion about the nature of the clinicalStatus field. The Bahmni team was arguing for a simplified model, which included status fields of ACTIVE, INACTIVE, and HISTORY_OF. This model ultimately won out. @burke made considerable arguments against this, in favor of a model that more closely tracked with FHIR.
The biggest question ultimately seemed to revolve around the fact that the design had a single clinicalStatus field, and we needed this to capture 2 distinct values - the first being the physiological status (whether the patient still suffers from the condition) and the other being the clinical “relevancy” (eg. whether it is important enough to appear in the list in the UI).
In the end, my read is that a compromise of sorts was reached such that the single field was planned to be used as such:
|Physiologically active||Physiologically inactive|
|Clinically Relevant (On active list)||ACTIVE||HISTORY_OF|
|Not Clinically Relevant (Not on active list)||INACTIVE||INACTIVE|
Clearly, this loses the distinction between whether a condition is actually no longer physiological inactive, or whether it is just not considered clinically relevant.
This model has persisted through today, and presumably the Bahmni application uses this effectively. However, in core (recently fixed in the API) and in the 2.x reference application (not yet fixed in coreapps), Condition List has been plagued with bugs and issues, and this confusion around what clinical status represents feels like a big cause of confusion that has led to many of the underlying issues. When I read other threads around condition list here and here, I feel like I read all sorts of contradictory statements which further confirms that this is something that bears fixing. @burke warned against this here:
Further complicating the current situation, an independent effort from within the last year changed the ConditionClinicalStatus enum from the simplified model of ACTIVE, INACTIVE, and HISTORY_OF to more closely track with FHIR (including deprecating the HISTORY_OF status). That effort was driven from this ticket (which was about Diagnoses, incidentally), and stemmed from this Talk thread. So this means that as of OpenMRS 2.6.0, the options available for setting clinicalStatus for Condition more closely aligns to the full FHIR model that @burke had originally advocated for.
I’d like to resurrect this discussion - @jteich , @angshuonline , @burke , FYI - to validate that what I write above is accurate and to gain consensus on the best way forward with regards to representing clinical relevancy and physiological status on Conditions.
With the change to ConditionClinicalStatus in 2.6.0 to align with FHIR, it seems to me that this field is representing physiological status. And there is no way in the data model to indicate a distinct “list status” for clinical relevency.
One possible option would be to allow implementations to configure whether a given ConditionClinicalStatus represents something that is clinically relevant or not. For example, an implementation could choose to show all conditions in the active list unless the condition has status = RESOLVED. (eg. INACTIVE = no longer experiencing the condition, but keep on the list, RESOLVED = no longer experiencing the condition and take off the list). Alternatively, a new, additional status field might make the most sense.
Interested to hear everyone’s thoughts. @ibacher / @dkayiwa FYI