Stream: implementers
Topic: Representing a Comorbidity
Mark Kramer (Oct 05 2020 at 14:39):
I am trying to represent a patient having a comorbidity, and I need some input. Here's the problem:
- Comorbid conditions represent categories of conditions
- The definition of these categories depend on the primary disease of interest. For example, a CDCCovid19UnderlyingNeurologicCondition is not the same as a ElixhauserNeurologicComorbidCondition or a CharlsonNeurologicComorbidCondition.
- It is sometimes possible to represent those categories in terms of value sets, although in general there might be other criteria (such as grade or stage)
- The determination that a patient has or does not have an underlying comorbid condition is derived information
- If the patient has a comorbidity, the practitioner probably want to know what in particular it is
Based on these considerations, I see two possible approaches:
1) Define a profile for each comorbid condition, for example, ElixhauserNeurologicComorbidCondition (there would be a different profile for CDCCovid19UnderlyingNeurologicCondition, since these entail different value sets).
* Should the profiles be based on Condition? If so, where would I capture that this is a comorbid condition according to the Elixhauser definition (noting that the name of a profile is not meaningful)? What Condition.code should be used?
* Or, should the profile be based on Observation, with the (TBD) code representing "Elixhauser neurologic comorbid condition", and the value being yes/no/unknown?
2) Define a questionnaire for the comorbid condition(s) of interest, and create pre-population algorithms, maybe in CQL, for each question. The answers in QuestionnaireResponse would be yes/no/unknown.
In simple terms, is a comorbid condition a Condition, or are we talking about membership in a cohort defined in some semi-arbitrary way?
Lloyd McKenzie (Oct 05 2020 at 14:50):
@Michelle (Moseman) Miller
Michelle (Moseman) Miller (Oct 14 2020 at 15:01):
FYI -- this is on the agenda to discuss with Patient Care Oct 15 at 5pm Eastern
Yunwei Wang (Oct 14 2020 at 15:07):
@Mark Kramer
Mark Kramer (Oct 14 2020 at 15:25):
So noted -- I'll be there
Michelle (Moseman) Miller (Oct 16 2020 at 00:52):
Based on the Patient Care discussion today, we concluded:
- QuestionnaireResponse is the preferred option since comorbidities are often point in time and context-specific
- Observation is a valid consideration -- provided we work through the details of how best to relate the conditions to the observation (Observation.focus was considered, but didn't quite cover the semantics of the relationship where condition A is a comorbidity of condition B).
- Condition is not recommended (since the comorbidities are point in time and context-specific)
Lin Zhang (Oct 16 2020 at 01:06):
A condition and its comborbidity(ies) have mutually overlapping periods.
The resource type name "QuestionnaireResponse"
is not that intuitive.
Rob Dingwell (Oct 16 2020 at 16:13):
I'm curious as to why Observation.focus doesn't capture the semantics? Based on the description, what is being captured is not an actual linkage between discrete Condition resources. Instead, this is capturing an observation as to whether a specific Condition has comorbidities of categories of a condition(s). As such, the code of the Observation should indicate that it is a Comorbid Condition Observation with a focus on the Condition it is capturing the Observation for along with one or more components that represent the class of comorbid condition (Observation.component.code) with the value indicating the yes/no/unk status.
Lloyd McKenzie (Oct 16 2020 at 16:49):
focus is "what is specifically being observed in making the finding". E.g. a specimen, a fetus, etc. If you're capturing a co-morbidity, you're not "observing" the other diagnosis in making that finding.
Vassil Peytchev (Oct 16 2020 at 17:19):
From the definition of Observation.focus:
The focus of an observation could also be an existing condition, an intervention, the subject's diet, another observation of the subject, or a body structure such as tumor or implanted device.
Seems to fit quite well.
Mark Kramer (Oct 16 2020 at 21:04):
Here's what I captured from the PC meeting yesterday:
The consensus was that it does not make sense to either create a new Condition to represent a comorbidity, nor label an existing Condition as a comorbidity (via category or meta.profile). Stephen Chu made the point that comorbidities are point-in-time and context-specific assessments (e.g., comorbids are different if the admit diagnosis is diabetic ketoacidosis versus heart failure). They suggest looking at either an Observation, List, or QuestionnaireResponse as possible representations.
• The concern about Observation was twofold: (1) finding the right Observation.code (almost surely does not exist), and (2) linking the Observation to the Conditions or problem list items (we discussed the possibility of using Observation.focus). NOTE: If we use Observation, the individual comorbidities could be separate Observations or components of one Observation.
• The concern about Questionnaire response is the ability to find and use the information (being "trapped" in the QR). My concern is having the yes/no criteria "buried" in some prepopulation algorithm.
• List was suggested by analogy to Problem list, this could be a comorbidity list. The problem is that List.entry needs to point to another Resource, then the question still, is that item an Observation? the original Condition?
In summary, we made some progress but there are numerous questions yet to tackle.
Lin Zhang (Oct 17 2020 at 02:55):
Comorbidities might look like roles among/between concurrent diseases (relative to each other).
Lin Zhang (Oct 17 2020 at 03:02):
Wikipedia: Comorbidity
In medicine, comorbidity is the presence of one or more additional conditions often co-occurring with a primary condition. Comorbidity describes the effect of all other conditions an individual patient might have other than the primary condition of interest, and can be physiological or psychological. In the context of mental health, comorbidity often refers to disorders that are often coexistent with each other, such as depression and anxiety disorders.
Derek Ritz (Oct 18 2020 at 00:48):
I'm sorry for not knowing the clinical definitions, here... but how does one determine what is the "primary" condition? If I am diabetic and HIV+, who decides what is the morbidity and what is the comorbidity? Could we not look to CarePlan and discern for which conditions someone is actively under care? (and they are all... aren't they... comorbidities to each other?)
Lin Zhang (Oct 18 2020 at 00:58):
There should be clinically/financially recognized criteria for a condition to be the "primary" one. And for a patient, the primary condition may change over time (e.g., during different encounters).
Derek Ritz (Oct 18 2020 at 01:01):
@Lin Zhang Do we "lose" anything by simply (and faithfully) identifying all of the patient's conditions as peers? It seems to me that identifying one as the primary is a bit of a "beauty is in the eye of the beholder" problem. Each clinical specialty will, of course, see all other conditions as comorbidities of the one they are focused on... but that doesn't make it so.
Lin Zhang (Oct 18 2020 at 01:19):
You are right. In deed, beauty is in the eye of the beholder.
Lloyd McKenzie (Oct 18 2020 at 02:29):
My leaning would be to say that co-morbidities are simply relationships. It's entirely possible to have Diabetes pointing to Hypertension as a comorbidity and Hypertension pointing to Diabetes
Derek Ritz (Oct 18 2020 at 03:57):
@Lloyd McKenzie , doesn't that kinda force us into some kind of update flurry if a new diagnosis is made? Every existing diagnosis now has to be pointed at the new one... and it needs to be pointed at all the other ones... and really, what is the benefit? Again, I'm not a clinician, but isn't everything in the current problem list, almost by definition, a co-morbidity? Isn't it of more value to just be able to get the list... as peers (without having to define relationships between them all)?
Lloyd McKenzie (Oct 18 2020 at 04:35):
It only creates a flurry when someone decides that a new diagnosis is specifically relevant to other prior Conditions. And the flurry could easily be a batch that updates the set, so not a lot of calls. Not every condition would be tracked as a co-morbidity of every other condition. The ones that are specifically interrelated that you want to flag, you can flag. Alternatively, you can just have a patient with a bunch of conditions and have client-side logic that determines which ones to highlight as co-morbidities.
Derek Ritz (Oct 18 2020 at 20:45):
@Lloyd McKenzie I like that last option. :smile: :+1:
Lloyd McKenzie (Oct 18 2020 at 21:05):
It'll depend on the needs of the space (and the desires of the clinicians involved). Sometimes explicit declarations are desired/necessary, sometimes not.
Lloyd McKenzie (Oct 18 2020 at 22:42):
We should, however, have a standard way for people to say it when/if systems decide they need to. @Michelle (Moseman) Miller I don't think QuestionnaireResponse is an appropriate way to expose any sort of coded information - there'd be no reliable mechanism to extract it. And Observation doesn't have an obvious way to tie two Conditions together to say that one is a comorbidity of another. Is there a reason why the work group discounted an extension for this purpose?
Michelle (Moseman) Miller (Oct 19 2020 at 15:30):
@Lloyd McKenzie As @Mark Kramer summarized, we did acknowledge the limitations with QuestionnaireResponse extraction.
When you asked if Patient Care discounted an extension....on which resource? Condition or Observation? We did briefly mention that Condition has an extension, http://build.fhir.org/extension-condition-related.html, for relating conditions. However, @Stephen Chu kept stressing that comorbidities are context and time specific, which is what pushed us down the path of QuestionnaireResponse (since it is point and time and the form has context).
Lloyd McKenzie (Oct 19 2020 at 15:47):
Information on Condition is also time-specific. I would expect a Condition to point to its co-morbidities (if some decided they were worth tracking). That list would be updated over time by updating the Condition, just as the severity, management level, etc. would be updated.
Mark Kramer (Oct 20 2020 at 21:29):
Here is a proposal for an extension representing a comorbidity, the approach suggested by @Lloyd McKenzie . It's a complex extension meant to extend Condition, with cardinality 0..*. It has the following elements:
- comorbidityCategory (1..1) -- Represents the type or general category of the reported comorbid condition(s), for example, diabetes, dementia, or prior myocardial infarction.
- isPresent (1..) -- Whether the comorbidity in the specified category is present.
- comorbidConditionCode (0..*) -- A code representing the specific comorbid condition. The condition code must be consistent with the comorbidity category, and should only be provided if isPresent is true.
- comorbidConditionReference (0..*) -- A reference to a Condition resource that is considered to be a comorbidity, consistent with the comorbidity category.
- score (0..1) -- The severity rating or weighting score associated of the reported comorbid condition(s), consistent with the code system of the comorbidity category
For fans of FHIR Shorthand, the file with the proposed implementation is attached.
Some pros and cons:
- Pro -- It is anchored by, and relative to, a specific condition
- Pro -- It allows for different systems of classification of comorbidities (this is captured in the code system of the comorbidityCategory code)
- Con -- Not vanilla FHIR. Extensions always require custom work by implementers.
- Con -- The means of classifying conditions is entirely implicit. For example, what ICD-10 or SNOMED CT codes are included in categories "Drug Abuse" or "Kidney disease, moderate or severe" is nowhere to be found.
Lloyd McKenzie (Oct 20 2020 at 22:02):
I'm not a favor of a complex extension - you seem to be expressing a lot of duplication of information that's already present on the target Condition. Why not just an extension of type Reference?
Mark Kramer (Oct 21 2020 at 13:09):
@Lloyd McKenzie There is no duplicate information. Let me give an example:
- What comorbidity classification system is being used, if any? Charlson
- Is Cerebrovascular disease (as defined in Charlson) present? Yes (yes/no/unknown)
- What specific Cerebrovascular disease(s) is present? I67.5 - Moyamoya disease
- What is the score (contribution to the Charlson comorbidity index) associated with this comorbidity? 1 point
The only information given by the reference is the Condition code of the comorbid condition (question #3). I'm allowing for a code locally in the extension in case there is no condition to reference. It is a common pattern in FHIR to have a choice of a code or a Reference.
The reason for question #2 is to give an explicit negative if the comorbidity isn't present. You can't express that with a Reference, because the non-existence of a negative doesn't mean the condition isn't there (by the open world assumption).
In Charlson, the 4th question can be captured by an external definition, but there are comorbidity systems where the score represents the severity of the condition. That's why the score is there.
Vassil Peytchev (Oct 21 2020 at 13:12):
Doesn't that circumvent the Observation(s) about the Comorbidity?
Mark Kramer (Oct 21 2020 at 13:13):
@Vassil Peytchev I don't understand.
Vassil Peytchev (Oct 21 2020 at 13:26):
I think earlier it was discussed that that the existence of a comorbidity can be described as an observation. At first glance, 1,2, and 4 sound a lot like an observation.
Mark Kramer (Oct 21 2020 at 19:29):
I think Observation is the next possibility to investigate.
Lloyd McKenzie (Oct 21 2020 at 19:45):
I would expect 3 to be he Condition.code for the target. The existence of the association would indicate 'yes', so #2 is sort of redundant. #1 and #4 might be necessary for really sophisticated systems that choose to capture that sort of thing
Mark Kramer (Oct 21 2020 at 20:19):
Actually a lot is missing. If you only have a reference(Condition), you can't specify the category of the comorbidity, which is the most important thing. Furthermore, you can't assert that a type of comorbid condition is not present.
What I mean by category is exemplified by the Charlson categories. (This is just one example, because other systems use different categories):
- #MI "Prior myocardial infarction"
- #CHF "Congestive Heart Failure"
- #PERIVASC "Peripheral Vascular Disease"
- #DEMEN "Dementia"
- #CVD "Cerebrovascular disease"
- #CPD "Chronic pulmonary disease"
- #ARTH "Connective tissue (rheumatologic) disease"
- #ULCER "Peptic ulcer disease"
- #LIV "Chronic liver disease, mild"
- #DM "Diabetes without chronic complications"
- #HMPG "Cerebrovascular (hemiplegia) event"
- #RENL "Kidney disease, moderate or severe"
- #DMCX "Diabetes with chronic complication"
- #LEUK "Leukemia"
- #LYMPH "Lymphoma"
- #LIVSEV "Chronic liver disease, moderate or severe"
- #METS "Metastatic solid tumor"
- #AIDS "Acquired immuno-deficiency syndrome (AIDS)"
Lloyd McKenzie (Oct 21 2020 at 21:10):
Asserting that a comorbidity is not present is a questionnaire type thing. In the actual Condition record, you'd simply capture the things that are present. The 'category' sounds like a condition code to me - it's not "what kind of comorbidity is this?", it's "what kind of condition is the comorbidity?"
Mark Kramer (Oct 21 2020 at 22:03):
Asserting that a comorbidity is not present is a questionnaire type thing.
Or, it could be an Observation whose answer is "present", "absent", or "unknown".
The 'category' sounds like a condition code to me
Actually, it is a taxonomic classification.
Lloyd McKenzie (Oct 22 2020 at 02:34):
A classification is still a code for a condition.
Jim Steel (Oct 22 2020 at 03:38):
Yeah. Its not a great code, but it is a code.
Vassil Peytchev (Oct 22 2020 at 03:55):
I don't get it. There is a patient problem list with condition A, and condition B. Now we have to add condition C to state that condition B is comorbidity to condition A, but keep it off the problem list? Or is it a legitimate third condition?
Doesn't it seem clearer to have Condition A and Condition B, and use an Observation with a new category, comorbidity, focus is condition A, code one of the category codes, method could be whatever categorization was used , and value is present, absent, unknown. Then extension on Condition B is a reference to the Observation of category comorbidity, indicating that condition B is a comorbidity to the focus of the Observation.
Mark Kramer (Oct 22 2020 at 11:46):
@Vassil Peytchev An Observation works quite well, with one exception. There is no place to put a reference to the actual condition(s). It seems like derivedFrom would be ideal, but Condition is not one of the acceptable types. An extension is needed to reference the actual Condition that is judged comorbid.
Here is the FSH code for that profile:
Profile: ComorbidObservation
Parent: Observation
Id: mcode-comorbid-observation
Title: "Comorbid Observation"
Description: "This observation represents a point-in-time clinical judgment that type of comorbidity exists (or does not exist) with respect to another condition (the Observation.focus). A comorbidity refers to one or more diseases or conditions that occur along with another condition in the same person at the same time. The code represents the category of the comorbidity, and the value is present/absent/unknown. "
* category = SCT#398192003 // Co-morbid condition
* focus only Reference(Condition)
* subject only Reference(USCorePatient)
* code from ComorbidityCategoryVS (extensible)
* value[x] only CodeableConcept
* valueCodeableConcept from PresentAbsentUnknownVS (required)
(Value sets omitted)
Derek Ritz (Oct 27 2020 at 17:04):
I agree with @Vassil Peytchev ... but would go even further. By definition... the problem list is a list of comorbidities... isn't it? Every present condition is a co-morbidity of every other present condition. Sorry... but how could it not be so?
Lin Zhang (Oct 27 2020 at 18:26):
A problem in the list might not necessarily be a disease.
Lloyd McKenzie (Oct 27 2020 at 19:46):
"comorbidity" typically refers to "relevant co-morbidity". Someone might have a broken finger and might also be dyslexic. But it would be unusual to capture those as co-morbidities of each other.
Last updated: Apr 12 2022 at 19:14 UTC
