Conditions List for Bahmni

[darius (Darius Jazayeri)]

@burke

Calling this clinicalStatus and using values active, remission, and resolved would better align with FHIR Condition’s clinicalStatus

We (@jteich, @akhilmalhotra, and I) looked at FHIR’s clinicalStatus and decided that it’s not what we want for our settings and constraints. (Also, @burke, I’ve been inspired by your repeated comments over the years that the single most important thing about the condition list is that the clinician must be able to remove an entry with a single click and no followup questions.)

In the OpenMRS settings I have seen, nobody would ever take the time in a point-of-care UI to distinguish whether a problem was “resolved” or went into “remission”. (Is remission relevant outside of cancer?) Further, I find this argument by Akhil pretty convincing (about single click vs click + add new + search + confirm):

@akhilmalhotra

Building pre-coordinated concepts will make it difficult to use. For Example: The doctor will have to inactivate Stroke and then add a new “History of Stroke” to the conditions list as compared to just marking Stroke as “History of” which requires only a single click to achieve.

To automate this with precoordinated concepts we would need Bahmni/OpenMRS to automatically know which concept is the pre-coordinated history-of concept for any given symptom/diagnosis. In this particular case, CIEL does say that

Stroke (111103) is Same As SNOMED-CT 230690007 Personal History of Stroke (152512) has Associated Finding SNOMED-NP 230690007

…however (a) this is not done consistently for all symptoms and diagnoses, and (b) the client for whom we are building this feature is not using the CIEL dictionary, so this approach would require us to rework their entire dictionary, which they don’t have the resources to do.

Here’s what I think we do here:

1. The Bahmni UI for this should be written to support a high-level action “Mark {condition X} as History Of”
2. In the API (this is in the emrapi module, as an incremental improvement to this code) we support the statuses Akhil proposed: Active, Inactive, and History Of
3. In the short run we implement “Mark {condition X} as History Of” by just changing the status
4. In the future someone is welcome to write a more sophisticated implementation that uses concept mappings to find a pre-coordinated concept. (Thus if someone writes this code, and maps their dictionary correctly, they will never see the HISTORY_OF status being used.)

@burke

For #3 or #4, I would prefer that we record an explicit link in the encounter diagnosis to the related condition (rather than relying on someone inferring the relationship by comparing concepts).

Actually the original request was to do something like this, but @jteich and I pushed to simplify as much as possible, because in practice knowing the date + concept is sufficient (and even if you theoretically get more granular data than that, it’s unlikely to be reliably captured). Also, to do this we’d need to store a complex obs that points to a condition, and this would be tougher to code against, especially in SQL reports.

@sid

From the ‘audit trail’ perspective, when should we clone the condition and make a new entry in database. At what changes we keep an audit trail?

1. Only when status changes
2. Some other fields along with status changes
3. All the fields

@akhilmalhotra (+/- @jteich) can you follow up on this?