Conditions List for Bahmni

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.

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

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

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.

The status “History-Of” depicts the importance of an inactive condition. A condition that is clinically inactive but can have an impact on the clinical decision making. The patient is not actually suffering from that condition anymore but the doctor has to know that the patient suffered from this condition some time ago.

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.

Verification status can still be implemented. As for our implementation, we are only allowing “Confirmed” diagnoses to be added to the conditions list. We want to put this restriction because if a diagnosis is “Presumed”, it might turn out to be not the correct diagnosis after investigation results are made available to the doctor and generally, whatever is on the conditions list, is assumed to be true. But we will not put this restriction in the design. So other implementations of OpenMRS will not have to live with this restriction.

I believe you’re confusing clinical status (relevance to clinical decision making) with physiologic status (the state of a condition whether or not it is clinically relevant). We need the former to manage conditions. Accurate & timely collection of the latter is theoretical and not realistic in real life.

And it’s not a matter of deciding whether or not to create pre-coordinated concepts for physiologic status. CIEL dictionary is already full of them.

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

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

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.

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

FYI - To track the status of this feature please refer to this Trello Card on Bahmni wall: https://trello.com/c/oI90NhOs/50-support-for-conditions-in-bahmni

We should clone for every change we make. However, for status change, we should not void the previous condition (as discussed above). If we make any changes other than the status change (which will mainly include change of start date or attach a note), we can void the previous condition.

Just to be precise, can we look at the specific cases?

My uneducated guess is:

  1. Change from Active Stroke to History Of Stroke => new row in the condition table:
  • (1) status=active, concept=Stroke, onsetDate=stroke-date, endDate=today
  • (2) status=history-of, concept=Stroke, onsetDate=stroke-date?, previousCondition=(1)
  1. Change onsetDate, additionalDetails, endDate, endReason => edit these in-place, no clone or audit trail
  2. Change concept or conditionNonCoded => new row in the condition table
  • (1) status=active, concept=Myocardial Infarction, onsetDate=stroke-date, endDate=today
  • (2) status=active, concept=Coronary Artery Disease, onsetDate=today?, previousCondition=(1)

@darius I suggest we keep audit trail for everything and keep the logic simple. An audit trail also comes handy in certain circumstances like medico-legal cases, erroneous diagnosis and (potentially) settling false insurance claims.

I was referring to EncounterDiagnosis, which could have a foreign key to the condition list entry when the relationship was explicit. The reason being that someone could single click add a condition from the condition list and we’d explicitly capture the relationship rather than infer it. When someone manually added an encounter diagnosis that matches an active condition list entry, we could ask them if this is the same condition or not and make the explicit link if they say yes. This would allow for encounter diagnoses for repeated or concurrent occurrences to be recorded and not be implicitly linked as referring to the same thing. If we are going to enforce that active conditions in the condition list and conditions in encounter diagnoses cannot contain duplicates, then we can survive without an explicit link… but make implicit links may still come back and bite us for episodic non-related conditions (tb, pregnancy, etc.)

There is a ticket for this in openmrs-core, but it hasn’t been done yet (it’s not even ready-for-dev), and it’s not in our current workplan.

I think we’ll go ahead an implement this feature in the simpler way, knowing that it’s less than ideal. As long as there aren’t two active conditions with the same concept at the same time, then there’s no data loss. (And we may have to deal with a data migration task when condition and encounter_diagnosis actually make it into openmrs-core.)

(@akhilmalhotra let’s make sure to include in the story that we shouldn’t allow you to add another active condition with the same concept or non-coded-text as an existing one.)

@darius, @burke It is already included.

Do Inactive, and History Of for in clinical status align to FHIR’s values of remission and resolved, respectively?

I’m still trying to understand how clinically irrelevant conditions will be hidden or removed from the list, Are we planning on introducing Past Medical History (PMH) separately in the future? That would allow non-clinically relevant conditions to be moved off the condition list without being lost. The main point I’m trying to get across is whether or not a condition is clinically relevant (should be shown in the condition list) is not always determined by whether the condition is active, inactive, or historic. I just want to make sure we aren’t assuming that a clinical status field can single-handedly reflect “truth” of the condition’s state and determine whether or not an entry shows by default in the condition list.

I’m hoping that @jteich can also weigh in on the topic…

The model we plan to follow (I think largely advised by Jonathan) is that we’ll have “current conditions” as well as a historical view. Conditions with status of ACTIVE or HISTORY_OF are displayed in the “current conditions” view, and INACTIVE are only displayed in the history view and you have to do one more click to see them.

@burke I think you’re suggesting that we should have an additional boolean status field to indicate whether or not the entry is shown in the condition list (a.k.a. “is clinically relevant”). I don’t see this in FHIR. (Unless you think it maps to clinicalStatus?

I was actually suggesting we use clinicalStatus to indicate clinical relevance rather than assuming it will somehow always reflect physiological truth. We’re far more likely to have reliable clinical relevance, because users will want to control what is on their list. The idea that someone will be dutifully recording when a stroke becomes a history of stroke (physiologically) is unrealistic.

If we conflate clinical relevance (do I want to see it in the main list) with physiological status (is this condition actually active or not in the patient’s body), they will be at odds at times. Example: I want History Of Stroke and Heroes in Remission on the condition list, but I want the patient’s ongoing Halitosis (bad breath), which is physiologically “active” in their medical history but not cluttering up my condition list (because it isn’t clinically relevant right now).

While, we could make a separate flag for clincallyRelevantStatus, that suggests that someone will be maintaining clinicalStatus, which I think is unlikely. People will just toggle off clinicallyRelevantStatus and leave clinicalStatus untouched (forcing the API to guess if the condition just went from active to inactive or active to history of).

One of the benefits of using clinicalStatus for active & inactive/resolved to manage what should or should not be shown by default is it saves you from having to worry about this problem. It’s perfectly acceptable for a doctor to have a “History of stroke” as an active item on the list and, when the patient presents with a new stroke, add a new “Stroke” concept to the condition list as active. When the acute stroke has been treated, the doctor clicks an “X” to remove it from the list and we market as inactive/resolved. “History of Stroke” remains active on the list.

The system doesn’t have to know or track the relationship between “History of stroke” and “stroke” to support this.

I don’t understand how the halitosis example is relevant, because FHIR’s clinicalStatus does not have a solution for it either. The clinicalStatus options are active | relapse | remission | resolved. Which one of these indicates “active Halitosis that is not clinically relevant”?

One key point: the client specifically requested the ability to mark a condition as historical. So we need to support this.

Our solution is to have two different buttons on the condition list, one for “make this historical” and the other for “remove this from the list”. One will set the status to HISTORY_OF, and the other will set the status to INACTIVE.

I’m not sure I understand how you’re

I understand/infer that your proposal is: (1) rename Condition.status column to Condition.clinicalStatus, for alignment with FHIR (2) rename the INACTIVE enum value to instead be RESOLVED, for alignment with FHIR

and then either: (3a) redo the concept dictionary for this implementation to have separate concepts for “stroke” and “history of stroke” (3b) rename the HISTORY_OF enum value to instead be REMISSION, for alignment with FHIR (but we can choose to display this in the UI as “History Of”)

You agree that there’s only one status/clinicalStatus column, so I assume you agree it’s appropriate to display by default all conditions whose status is ACTIVE or HISTORY_OF, but not INACTIVE (aka whose clinicalStatus is ACTIVE or REMISSION, but not RESOLVED).

Is that right, or are you proposing something different?

Option 3a is absolutely impossible in this case. Existing implementations that want this feature cannot redo their whole concept dictionaries.

I think that “remission” is going to be confusing for people who will be generating reports from looking at the database. Maybe the right solution is that the API should support the statuses:

  • ACTIVE
  • RELAPSE (won’t be used in the Bahmni UI for now)
  • REMISSION (won’t be used in the Bahmni UI for now)
  • RESOLVED (instead of INACTIVE)
  • HISTORY_OF (plus document that it’s recommended to not use this but instead have precoordinated concepts)

Halitosis would be marked as resolved/inactive, reflecting it is not clinically relevant. The system would not be able to distinguish between Halitosis that was resolved vs Halitosis that remains physiologically active but is no longer clinically relevant, but nobody is going to be collecting or maintaining that granularity of data even if we supported it.

Those sites using CIEL likely already have these concepts. If not, there’s no requirement to have them. Setting clinicalStatus for “Stroke” to remission/history would be effectively the same as having “History of stroke” marked as active or remission/history of. For those concepts without a “History of x” concept, you just would have the option of having both “Stroke” (i.e., acute stroke) and “History of stroke” in the condition list simultaneously when a patient comes in with their third stroke. But using “History of x” concepts or not is left to an implementation decision (similar to choosing the name to use in the UI for remission/history of or resolved/inactive).

Yes. That’s right. The key point is that clinicalStatus is being used to record clinical relevance, not physiological truth. In other words, the semantics of marking something active, remission/history of, or resolved/inactive reflects the state of the condition’s clinical relevance. Most of the time, this will align with physiology – i.e., when the Pneumonia is resolved, it’s actually resolved. But when clinical relevance and physiological state of a condition do not align, clinical relevance wins – e.g., if the patient still has constipation, but it has been clinically stable for 10 years and the provider wants it off her list, its clinicalStatus becomes resolved/inactive even if the patient is still taking the stool softener he’s taken for the past 10 years for his constipation. If we leave this ambiguous and half the people using the API are using clinicalStatus to have manageable condition lists and the other half are assuming that clinicalStatus must reflect “truth” (physiology), the two will eventually hit an impass like two Zax.

A couple of points to get out of the way, mostly agreeing with the above threads, before getting to the big topic about active/inactive and major/minor, which will be the next reply:

The main purpose of a condition list (as opposed to an encounter diagnosis) is primarily to provide a summary overview of the patient, and secondarily to possibly enforce consistency over several encounters for the same thing. With that in mind:

  1. Remission – unfortunate choice on FHIR’s part. Mainly only applies to cancer and even where you can kind of use it for other conditions (like asthma), most people will not understand it or properly use it anyway because that word isn’t used much except for cancer. I agree that we should avoid surfacing it in the UI; if I had my druthers, I wouldn’t use it as a status at all.
  2. Relapse – slightly more understandable, but not necessary for condition list. If a patient has had acute HIV, then it got better for awhile, then it got worse, what I want to see on the condition list summary is just “HIV”. I can follow the improvements and worsenings by looking at the history. So, I also wouldn’t bring this up to the UI.
  3. Pre-coordinated conditions and duplicate conditions – while I suppose this may be up to a specific site, I’d hope we can do everything possible to avoid precoordinated conditions that duplicate another condition. It isn’t clinically useful for the list to have both “stroke” and “history of stroke” on the list for the same patient – that’s all one grouping of history and data. When I look at the list, I just want to see if there was a stroke or not in the past. If we ever do tie visits or data to conditions, I don’t want to have some of the relevant stroke data (like a carotid study, or thrombolysis treatment) associated only with one of these and hidden from someone reviewing the other. a. Note that a stroke, like an MI and other things, is really an instantaneous event anyway; it’s history the moment after it occurs. If I have a stroke in October and another one in January, then a few weeks later my condition list should just say “history of stroke” (or simply just “stroke”)
  4. Audit log entry vs delete/add new – in past work we audit-trailed every time any field changed. That may or may not be OpenMRS standard operation. But in any event, the only time I would inactivate one problem and start up a new one is when the main concept [name] changed.

So, everyone seems to agree that we need to distinguish current/past conditions and major/minor conditions. However we set it up, I maintain that those are two independent fields.

A. Here are some use cases:

Active (Current):

  • condition is getting current attention over the last few encounters

Inactive but important enough to show in the major-conditions list

  • acute condition is over but worth knowing for general care [broken hip, stroke], or
  • chronic condition has not been a problem for some time but worth knowing for general care [COPD, childhood asthma]
  • includes conditions in the distant past [congenital heart defect that had surgery]

Inactive and not important enough to show in the major-problems list

  • Stable minor chronic condition [halitosis]
  • Resolved minor acute condition [broken arm, strep throat]

B. What I think the user wants:

From a user perspective, the user would first see all the major problems, with a column showing whether they are currently active or inactive/past (includes “resolved” and “remission”). A button at the top of the table would include minor problems in the displayed list. This is the same UI we use for active meds vs. all meds.

C .A proposal for handling the transitions – trying to keep clicks to one, or nearly so:

  1. When a problem is first entered, it is active and a major problem, i.e., it shows up on the first-seen list.
  2. When the problem isn’t active anymore and the user wishes to keep it important, the user changes its status from active to inactive (or “current” to “past”, and you’re welcome to put “history”, “resolved” or anything else you like here) but otherwise keeps it at the same importance level. I suppose this same option could let the user delete it altogether, merge it into another condition, mark it as an error or whatever.
  3. When the user wants to render the condition minor – i.e., take it off the first-shown list, a button lets the user make it a minor condition. (When viewing the full list, there can be a Major/Minor column which can be toggled.)

Hopefully this helps address both issues of active-ness and importance, and provides a default (problems are major and active/current when first entered, and if you don’t change anything they just stay that way)

@jteich, I find this framing very convincing.

I agree that the main criteria users will want to see and control is major/minor (aka primary/secondary or active/hidden). In addition, optionally, the user can set a clinical status on the condition.

@akhilmalhotra, I would recommend that we approach things as Jonathan suggested (with a required relevance=major/minor field, and an optional clinicalStatus=active/relapse/remission/resolved/history).

@burke, you’re saying we should have a single status field matching FHIR’s clinical status, but use it to capture “clinical relevance”. However the FHIR clinicalStatus values (active/relapse/remission/resolved) clearly do not align with relevant/irrelevant, and it’s a mismatch to say active=relevant and resolved=irrelevant. We’re better off introducing a separate field to indicate clinical relevance, with values matching the actual meaning, and letting clinicalStatus represent the actual status (even if it’s not consistently filled – we can default it to Active on export).