Condition List - Clinical Status

Development
1

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

3 Likes
2

From what I see in the specs, FHIR suggests this approach:

Eventually, it would be great to also support a user-specific sort-weight (or high/medium/low priority) property for a patient’s condition (presumably through a FHIR extension), so providers could manually sort a patient’s condition list… but we can save this feature for after we get clinical status properly “sorted.” :slight_smile:

3

Thanks @burke. I had thought that Condition.category was meant to distinguish a “condition list item” from an “encounter-diagnosis”, both of which are modeled by FHIR as Conditions. So I’m not sure that it would be able to be used to determine if a condition-list item is actually shown. I’m trying to determine how, in a UI, one might allow a user to distinguish between “active, but stop showing it to me” vs. “no longer active”.

4

I suppose if there are situations where you want to arbitrarily grab any condition associated with a patient through any mechanism, you could use category that way; however, I think you could still use category = condition-list-item only for items that a provider has selected to be in the condition list. Conditions that are past medical history (not wanted in the condition list) could either have a blank category or use category = past-medical-history (if our FHIR colleagues thought that was a valid use).

I would expect a far more common use case would be to ask for the patient’s conditions, which wouldn’t include encounter diagnoses. In this common use case, setting category = condition-list-item on every entry would make category useless.

5

From a pure-FHIR perspective, the model would probably suggest that whether a condition is part of a specific problem list is not a specific feature of the Condition itself, but whether it was actually included in a List resource representing the problem list that a particular clinician is interested in (in other words, this implies having a clinician-specific list of “problems being managed”).

On the other hand, the Condition.category field has an Extensible binding rather than a Required binding. This usually indicates that, from the perspective of the specification authors, the value set covers real-world uses-cases, but isn’t exhaustive, so, using it to indicate whether something is clinically relevant seems valid. I think, though, that this implies that we’re adding another field to the Condition data model either to specifically track category or at least to track whether a condition is “clinically relevant”.

6

A patient’s condition list (aka “problem list”) is specific to the patient, not to individual providers. While we clinicians would like to have personalized condition lists, it is better for patients (safety-wise, for decision support, etc) to have one condition list and one med list that all providers see (within a care setting).

Correct. For Condition.clinicalStatus to be used to indicate physiologic status (whether a condition is active for the patient), we need another way to distinguish whether conditions should be displayed on the patient’s condition list or on the patients past medical history list (independent of whether the condition is physiologically active). This property would belong to a patient’s condition and would not be user/provider-specific. For example, adding a “category” attribute to condition would make us more closely aligned with FHIR and solve the problem @mseaton is trying to address.

7

Great discussion, gave me a chance to review the (six?) past vigorous discussions on this – I think that reflects lots of fuzziness of definition, but I think there are possibilities.

My points –

  1. I like staying close to FHIR.

  2. Regarding the physiologic status: HISTORY_OF can be replaced by INACTIVE or RESOLVED, and most clinicians viewing those will treat them similarly for decision making (or add their own judgment), and they won’t be entered consistently anyway, especially for short-term events like strokes.

  3. FHIR really has no indication that a condition is major/minor or relevant/irrelevant (unworthy of being displayed); and this thread wishes we had one. See next two items.

  4. I would not use the clinicalStatus field for relevance because it overloads it – it gives it two dimensions of meaning, they’re not mutually exclusive

  5. Also, as @mseaton said, Category clearly is meant to separate encounter-diagnosis vs problem list (condition list) item, two distinct workflows – one is specific to a particular encounter and one’s an enduring status. I wouldn’t want to overload that field either. If we added a category meaning “problem list but unimportant” we’d breed lots of compatibility issues.

  6. The UX could conceivably separate out Inactive or Resolved conditions into a lower-class status (bottom of the list, hidden, etc.). An okay but not too-satisfactory resolution, similar to what @mseaton listed at the top of this thread.

  7. My conclusion: If we want to separate out relevant and irrelevant, we need a separate field to do just that, and a UX that lets someone move an item from one to another (default = relevant).

  8. Is it actually necessary? Bear in mind that one clinician’s relevant will be another one’s irrelevant (think dentists, as @akhilmalhotra did in a prior discussion). This clinician, at least, has become accustomed to and content with scanning the whole list of conditions – a clinician learns to quickly determine whether they care about any one of them.

8

The primary goal isn’t to tag conditions as relevant vs not relevant; rather, it’s to distinguish conditions that should be shown on the condition list vs within the past medical history. This is why I think we can simply mark those items that we want to show in the condition list (aka problem list) as a problem-list-item (using FHIR’s category). Any patient conditions that are not wanted on the condition list would not be put in this category, so would show in the past medical history.

9

great discussion. my thoughts

  1. we should just have a single model. In the new condition model, we should provide more means of capturing onset
  2. In FHIR, condition.category (problem-list) can be used in combination with condition.clinicalStatus (active, inactive). Could HISTORY_OF be captured as “Inactive” + “problem-list”?
  3. Bahmni’s userbase, often marks a past “encounter-diagnosis” as “condition” (as problem-list). We could effectively “move” from encounter-diagnosis to problem-list but I am not exactly sure how we could model that with a single model.
10

The original intent for OpenMRS was to support a problem list (more recently renamed to condition list) and past medical history. The problem list contains the conditions (whether still ongoing) that are clinically relevant for treating the patient and providers need to have in mind when making treatment decisions. The past medical history provides conditions that either significant historically or may even still be ongoing but are less clinically relevant for medical decision-making or not requiring/influencing any active treatments.

image
image868Ă—468 36.1 KB

The intent was for patient conditions to go in the conditions table. Those with a status of “active” would show in the condition list and those with a status of “inactive” would be in the past medical history. Diagnoses entered into an encounter may or may not be drawn from the condition list – i.e., when selecting diagnoses for an encounter, the provider can pick from the patient’s condition list or add a diagnosis that isn’t on the patient’s condition list.

image
image982Ă—362 50.2 KB

As the condition’s status got conflated with physiologic status (i.e., in some cases being used to discriminate which list – condition list vs. past medical history – it belonged and in other cases being used to indicate whether or not the problem was physically ongoing or not for the patient), things got confusing. FHIR settled the debate by defining condition status (i.e., clinicalStatus) as a physiologic status (i.e., whether or not problem is ongoing for the patient). So, we need another place to discriminate between condition list vs. past medical history (what has been referred to sometimes as whether it’s “clinically relevant”).

From what I see, this is exactly what FHIR’s condition category can do for us:

image
image760Ă—360 39.5 KB

Yes. My example above is “History of Stroke”. Note that there exist terms that are pre-coordinated with “History of …” (or “H/O …” or “Hx …”), since these are sometimes preferable on a condition list, since the physiologic status is often not reliably recorded or displayed.

Where are we storing encounter diagnoses? Are these being stored as observations, in an encounter_diagnosis table, or (hopefully not) in the conditions table? These would ideally be in a table like encounter_diagnosis with properties to discriminate primary from secondary diagnoses and, for those cases where an encounter diagnosis is drawn from the condition list, optionally linked to a condition on the patients’ condition list. While providers selecting diagnoses for an encounter can surely pick from the patient’s condition list for convenience and there are times when a provider will want to add diagnoses made during an encounter to the patient’s condition list , encounter diagnoses are data about an encounter and, while they might be optionally linked to conditions, don’t belong in the conditions table, IMHO.

1 Like
11

I should have been clear: In Bahmni, user can add an “encounter-diagnosis” to condition list - at that point, we just create an entry in the condition table.

Bahmni uses the emr API model, which basically stores encounter diagnosis as obs structure. :frowning: I would have loved a “encounter_diagnosis” table in the past! But I am wondering whether this is really needed; why not use the “condition” table itself - with category as “encounter-diagnosis” and with a ref to “encounter”. one single “condition” table with suffice for both categories!

This can also help Bahmni resolve in the FHIR /condition resource (fhir2) - which only operates on condition (problem-list) and never returns “encounter-diagnosis”

12

The way I had thought that I read the earlier threads on this is that FHIR represents both encounter diagnoses and conditions using the Condition resource, but OpenMRS has these as separate constructs - EncounterDiagnosis and Condition - and so we would need to use the FHIR “category” as a discriminator to map from the single FHIR condition resource to one or the other OpenMRS domain object and back. If Condition were only given a “category” of condition-list when it was something to keep on the List, this seems in conflict with using it as a discriminator value. But maybe I’m misunderstanding? Would be interested in hearing @ibacher on this. It doesn’t look like our FHIR module is currently including mapping EncounterDiagnosis to Condition in FHIR as @angshuonline says, but probably it should?

13

At the time when we built things out, I couldn’t find a distro using the 2.2-style Diagnoses instead of Obs, so, no, it doesn’t currently support it, but probably should.

One way to handle that discrimination would be to treat resources without a category of encounter-diagnosis as OpenMRS-style conditions would which free us up to use a couple of values there.

14

I’m not excited about merging encounter diagnoses into the condition list. While putting encounter diagnoses into the condition table doesn’t mean they have to ever show up in the condition list or PMH for users, it feels like putting patient addresses into the location table because they too are locations.

It’s a constant challenge to get providers to maintain meaningful condition lists, since items tend to get added to the list and, unless you make it a single click to take something off the list, people don’t take the time to take old items off the list.

Clinically, the condition list is meant to contain the short list of diagnoses that clinically define the patient’s condition. People frequently show up for encounters for incidental reasons (toothache, a laceration, cold or flu, etc) that have no bearing on a patient’s longitudinal care. There are also encounter diagnoses like admitting diagnoses that are presumptive and not infrequently wrong (later disproved) so would not only add noise to the patient’s conditions, but be misleading.

This is why we approached encounter diagnoses as distinct from the condition list. Diagnoses during an encounter can be taken from or added to the condition list, but there are plenty of cases where encounter diagnoses have nothing to do with the condition list other than being a diagnosis concept. If FHIR uses the Condition resource to represent an encounter diagnosis, because they are both symptoms/findings, fine. But conflating the two feels like a mistake to me.

15

@ibacher - are you saying/suggesting that if a FHIR condition has category = null, then it is a Condition (not on the list), if category = “condition-list”, then it is a Condition (on the list), and if it has a category of “encounter-diagnosis” then it is not an OpenMRS Condition but an OpenMRS EncounterDiagnosis?

@burke - thoughts on this? Your last post didn’t address the question here about overloading category as both a discriminator to distinguish between an EncounterDiagnosis and Condition with respect to FHIR, as well as a means to determine whether a given Condition is on the list or off the list.

16

I might be more inclined to implement things so that Conditions without a category are rejected, since we need the category to distinguish the underlying OpenMRS type, but then, that would allow us to use, e.g., condition-list to indicate a condition on a list, encounter-diagnosis to indicate an encounter and some other code to indicate “condition not on a list”. (This is also in keeping with FHIR where, in general, missing data is not treated as semantically meaningful in itself (missing data combined with an extension explaining why it is missing is).

I’m not either, but FHIR has made the decision to map both these concepts to a single FHIR Resource, so from the perspective of mapping between OpenMRS and FHIR we should support them through the same endpoint. That doesn’t mean we need to store them in the same underlying table or change the OpenMRS data model to use the same domain object for both of them.

17

I want to clarify that I’m not personally pushing for the need of a “list status” for Conditions. I am simply trying to understand the existing Conditions API and UI/UX in OpenMRS so that I can confirm whether the behaviors I am seeing are valid. In the historical threads that I originally linked to, there was considerable air time given to this need for a “list status”, in a way that seems inconsistent with the current implementation, hence my questions.

It may be that looking at some of this from the UI perspective may be helpful. I’m using the 2.x reference application condition list implementation here (provided by the coreapps module). This UI separates out conditions into “ACTIVE” or “INACTIVE” tabs, which correspond directly with the assigned statuses (second-level statuses of RECURRANCE, RELAPSE, REMISSION, and RESOLVED, which were added in OpenMRS 2.6.0 are not considered/displayed at all, nor is the pre-existing HISTORY_OF status).

Consider an entry in the ACTIVE tab:

image
image1002Ă—262 15.8 KB

Here, I’m given 3 available actions that I can take:

  • I can open a page to edit the condition ( pencil icon )
  • I can remove the condition with a single click ( x icon ). This voids the condition.
  • I can set the condition to inactive with a single click ( Set inactive ). This voids the condition and then creates a new condition with status = INACTIVE.

The question is - when a user takes one of the one-click actions, what is their intent?

  • If they click the “x” are they really intending to void the condition? Or are they trying to indicate that this is not something they want visible on the list? Or that it is no longer physiologically true?

  • If they click the “Set Inactive” are they intending to say that this is no longer physiologically true? Or are they intending to say they don’t want it to appear on the list anymore?

Consider similarly the existing INACTIVE tab:

image
image1002Ă—291 19 KB

  • If they click the “x” are they really intending to void this out entirely, removing all indication that the user ever had this condition?

  • If they click “Set Active”, are they really intending to void and recreate as an active condition? Or are they trying to indicate that this is a relapse or recurrence of a condition in their previous medical history?

My experience so far with using the Condition list feature is that what users think they are doing in the UI is often very different from what is actually happening and stored in the database.

18

I’m advocating that we migrate our UI away from a list of conditions split into “active” and “inactive” tabs and toward two lists: (1) a condition list & (2) a past medical history (PMH) list, since this was the original intent and the most useful clinically.

As for encounter diagnoses, can’t we say that requesting patient Conditions from the API would return or search the condition list & PMH and one would search within/beneath encounters to find encounter diagnoses (even if the encounter diagnoses are returned using the Condition resource schema)?

19

Thanks @burke . Is the following on the right track?

  • Add a new category property to Condition (an enum), with initial values of CONDITION_LIST, PAST_MEDICAL_HISTORY

  • The existing clinicalStatus property is independent of this. Something can have a clinicalStatus of ACTIVE with a category of PAST_MEDICAL_HISTORY, or a clinicalStatus of INACTIVE with a category of CONDITION_LIST

  • Change the Condition List tab and the Past Medical History tab to display the clinicalStatus along with the condition

  • When converting between OpenMRS ↔ FHIR, an OpenMRS CONDITION_LIST category maps to a FHIR problem-list-item category. An OpenMRS PAST_MEDICAL_HISTORY status map to a new OpenMRS FHIR extension. Practically this means that data incoming from FHIR that is not aware of the OpenMRS FHIR extension will be on the condition list by default.

  • In the UI shown above, the simplest changes in the short term would be:

    • Change the name of the tabs from “ACTIVE” and “INACTIVE” to “CONDITION LIST” and “PAST MEDICAL HISTORY”
    • Change the “Set Inactive” button to “Move to Past Medical History”
    • Change the “Set Active” button to “Move to Condition List”, or potentially a better option would be to have buttons for “Add recurrence to Condition List” and “Add relapse to Condition List”, which would keep the condition on the PMH and add a new Condition instance to the Condition List
    • Move the “X” (delete) button into the edit page, or add a modal confirmation popup, to discourage use to quickly remove conditions from the list

  • Support viewing / setting the full set of possible clinicalStatus values (recurrance, relapse, remission, resolved) in order to ensure accurate representation of any incoming data from FHIR. Could make it configurable as to which statuses the “Add Condition” screen should include.

  • Deprecate / change API method ConditionService#getActiveConditions

    • Ensure methods to “getActiveConditions” consider active, recurrence, and relapse statuses
    • Ensure methods to “getConditionList” and “getPastMedicalHistory” are supported by services (eg. query on category, not on clinicalStatus)

  • I’d also be interested in reviewing when Conditions should be voided and recreated on edit. Currently this is happening for any type of change (adding an onset date to an existing condition, for example). It would be good to review if all such changes should result in an audit history or only certain changes.

1 Like
20
  1. what you would return for API /fhir/condition?subject=patient-uuid?
  • imo, it should return both “encounter-diagnosis” and “problem-list-item” (condition.category)
  • question is - how would you order them? I can imagine that programmatically we will have to fetch both from two different tables, and then sort? How would it work in case of paged search result set? I can see this getting unnecessarily complicated.
  1. the same API should also handle POST /Conditions for encounter-diagnosis and problem-list-item