Conditions List for Bahmni

[burke (Burke Mamlin)]

@akhilmalhotra

• Modified org.openmrs.Condition to have the following statuses‘ACTIVE’, ‘IN_ACTIVE’, ‘HISTORY_OF’

Calling this clinicalStatus and using values active, remission, and resolved would better align with FHIR Condition’s clinicalStatus and leave room for verificationStatus (presumed vs. confirmed), which is needed when conditions are used in as an EncounterDiagnosis.

I’m not a fan of the term “HISTORY_OF” for clinical status, because:

• Whether of not something is historic does not always correlate with it being clinically active. For example, a History of Stroke condition may be historic, yet its clinical status is active, because a history of stroke is relevant to clinical decision being made today. On the other hand, a condition of [Halitosis] (https://openconceptlab.org/orgs/CIEL/sources/CIEL/concepts/146926/) may be an ongoing condition, but have a clinical status of inactive, because it has no relevance to medical decision making.
• “History of” is often pre-coordinated into concepts.

@darius

On status change, a new condition shall be created with a link to the previous condition with the modified status. The previous condition before status change shall be voided.

I agree that we need to define precisely how this is going to work. I would expect that when you modify a condition’s properties, the old one is not voided but just “closed” in some way, because it was true data up until the modification date.

One approach is to use Condition.endDate for this. Another is to split the status into two different fields: one for CURRENT vs HISTORY OF, the other for ACTIVE vs INACTIVE.

I’d favor not void & insert for every property change (e.g., changing the onset date, adding an end date, editing details). If someone is explicitly updating the concept for a condition (presumably refining it), then setting the end date on the old entry should suffice. I agree with @darius that voiding would mean we are invalidating the previous condition (which isn’t the case).

@akhilmalhotra

• While creating a condition, the concept_id in Condition table shall be mapped to the concept linked to diagnosis which has been added as a diagnosis.

At the API level, we intend to support all of these:

1. Add condition to condition list independent of encounter diagnoses.
2. Add encounter diagnoses (condition) without adding the condition to the condition list.
3. Add condition from condition list to encounter diagnoses.
4. Add encounter diagnosis to condition list.

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

@akhilmalhotra

• For free text condition, the condition shall contain concept_id mapped to “Non-coded Condition” and the field “condition_non_coded” shall contain the free text value.

Support for free text conditions aligns with our plans for use of Condition in EncounterDiagnoses. I assume for most CIEL-based implementations the “Non-coded condition” you are referring to would be Diagnosis or problem, non-coded.