Stream: implementers
Topic: Condition's Priority
Yunwei Wang (May 30 2016 at 16:10):
I am working on a example mapping a list of conditions from CDA observation-condition to FHIR condition. One of the condition has priorityCode primary, others are non-primary. How do I say the same in FHIR?
Grahame Grieve (May 30 2016 at 19:12):
what's the definition of 'primary'?
Yunwei Wang (May 30 2016 at 19:30):
I am doing an example for China FHIR group from one of their CDA document. The value in the priorityCode is, translated as, primary diagnosis (or major diagnosis). And other conditions have the value of "other diagnosis".
Lloyd McKenzie (May 30 2016 at 20:10):
This is usually in the context of an encounter, episode of care or claim. All of those should allow (either in core or via extension) the ability to assign a sequence to the condition. Standing outside the context of one of those things, I've never seen a use case for any particular condition being "primary" for the patient overall, regardless of what practitioner/individual is looking at the data.
Grahame Grieve (May 30 2016 at 20:33):
both Encounter and EpisodeOfCare allow you reference conditions, but not to indicate primary/secondary/complicating. But that differentiation exists in all CDA document problem lists I've ever found
Grahame Grieve (May 30 2016 at 20:34):
it's not clear to me that this isn't Condition.category
Lloyd McKenzie (May 30 2016 at 20:40):
Condition.category is a very different thing. It allows you to differentiate symptoms from diagnoses, etc. Encounter has an extension to allow indication of the "primary" diagnosis - http://hl7-fhir.github.io/extension-encounter-primarydiagnosis.html. EpisodeOfCare doesn't yet, but I think it's definitely reasonable to ask for one.
Michelle (Moseman) Miller (May 31 2016 at 13:01):
There is an extension available to indicate primary diagnosis in context of an encounter (e.g. http://hl7-fhir.github.io/extension-encounter-primarydiagnosis.html), but I would personally prefer to have this (as well as http://hl7-fhir.github.io/extension-encounter-relatedcondition.html) be an element of the condition. While I agree that these classifications are in context of an encounter, there is a condition.encounter element that specifies the encounter-specific context for that specific condition.
Yunwei Wang (May 31 2016 at 13:03):
FHIR China also had a similar discussion this morning if the extension should be in Encounter or Condition.
Lin Zhang (May 31 2016 at 15:25):
Example definition:
Primary diagnosis ICD code
Identifies diagnosis for which the patient is receiving care and its ICD-9-CM code. The primary diagnosis should be the condition that is the chief reason for providing care.
Related LOINC Code: 46511-2 Primary diagnosis ICD code [OASIS]
Source: Regenstrief LOINC
Michelle (Moseman) Miller (May 31 2016 at 17:07):
To complicate things, "chief compliant" could be communicated via http://hl7-fhir.github.io/extension-encounter-relatedcondition.html whereas "primary diagnosis" or priority/rank = 1 could be communicated via http://hl7-fhir.github.io/extension-encounter-primarydiagnosis.html. Our system treats both of these (role and rank) as attributes of the condition (more specifically, attributes for the subset of conditions that have a category of diagnosis, which is often billed in context of an encounter)
Chris Moesel (May 31 2016 at 18:27):
We've seen these indicators (primary or principal) used fairly often in quality measures. While I can understand the desire to put such a tag on the Condition itself, I agree with @Lloyd McKenzie that it's fairly meaningless outside of the context of the encounter to which it pertains. It also becomes a bit troublesome when working with chronic conditions. For example, consider a Condition for diabetes that had an onset 5 years ago. The patient has had 20 encounters since then. If the condition is flagged as primary, which encounter (or encounters) was it the primary for? Flagging the Condition only works if you're going to create a separate Condition entry for every encounter in which it is addressed (which you might do, but I don't think we should force people to do it just to support this particular use case).
Michelle (Moseman) Miller (May 31 2016 at 19:26):
@Chris Moesel , in the example of a chronic condition that was treated in context of 20 encounters, we would have 21 condition instances. A single condition instance #1 for the chronic condition with category = problem, and no encounter specified. Condition instances #2 through #21 would each have a category = diagnosis and a specific Condition.encounter populated. Condition.encounter has a cardinality of 0..1, so there shouldn't be any question about which encounter the Condition.role/rank (if supported) applies to.
Michelle (Moseman) Miller (May 31 2016 at 19:29):
Per the usage note on Condition.encounter..... "This record indicates the encounter this particular record is associated with. In the case of a "new" diagnosis reflecting ongoing/revised information about the condition, this might be distinct from the first encounter in which the underlying condition was first known." Thus, Condition.encounter is NOT constrained to the onset encounter when the chronic condition was first diagnosed.
Chris Moesel (May 31 2016 at 19:50):
Thanks for the info, @Michelle (Moseman) Miller. I wondered if something like that might be the case, but was confused by the fact that the "preferred" value set for Condition.category does not have any problem code. It has only complaint, symptom, finding, and diagnosis. So using the preferred value set, there isn't as obvious a way to distinguish between the longitudinal problem and the encounter diagnosis. There also isn't a good way to tie the encounter diagnoses to the longitudinal problem so that it's clear they are all referencing the same underlying problem.
Chris Moesel (May 31 2016 at 19:53):
That said, I'm not surprised that it works as you described -- as that seems to be a better match to how current systems and workflows do it today (despite any shortcomings).
Michelle (Moseman) Miller (May 31 2016 at 19:53):
Albeit a work in progress, the current Argonaut (US-based) IG includes an additional Condition.category code for problem (and concern) per http://argonautwiki.hl7.org/index.php?title=Problems_and_Health_Concerns#Mandatory_Data_Elements
Michelle (Moseman) Miller (May 31 2016 at 19:58):
Regarding the consequence of representing all billed diagnoses as a single 'chronic' Condition might trigger the question of what the Condition.code should be? For example, problems (in the US) are most often SNOMED, but diagnoses are ICD. When we discussed the possibility of "translating" SNOMED to ICD-X codes, we intentionally didn't do that because the ICD code could add inaccurate information—like initial encounter -- which isn't relevant to all billed diagnoses across all encounters.
Chris Moesel (May 31 2016 at 20:10):
Good points on all. The difference in coding systems does make that problematic, doesn't it? When something happens, like the condition resolves, are all of the individual diagnosis records updated? I would guess that is not the case, but then it makes the tail end of this guidance on abatementDate less relevant: "If there is no abatement element, it is unknown whether the condition has resolved or entered remission; applications and users should generally assume that the condition is still valid". Modeling health info is tough stuff!
Yunwei Wang (May 31 2016 at 20:19):
@Michelle (Moseman) Miller Condition.encounter is reference type. Do you add extension http://hl7-fhir.github.io/extension-encounter-relatedcondition.html into that encounter reference?
Michelle (Moseman) Miller (May 31 2016 at 20:55):
I agree @Chris Moesel -- there are a subset of Condition attributes that are either more or less applicable depending on whether it is a diagnosis or problem (abatement being a representative example of an attribute we only maintain/populate for problems, not diagnosis)
Michelle (Moseman) Miller (May 31 2016 at 21:03):
@Yunwei Wang -- we haven't actually implemented the encounter extensions yet.
Lloyd McKenzie (Jun 01 2016 at 01:46):
@Michelle (Moseman) Miller If we're talking about multiple records of the same Condition, I think the priority belongs on something like Linkage - so that the context of the priority is clear.
Jingdong(JD) Li (Jun 01 2016 at 02:08):
Hi all. In China FHIR community, we just had an extensive discussion regarding how to properly represent multiple conditions using FHIR, and there is no clear answer.
The use case is that one system (SysA) needs to send a patient's active problem list to another system (SysB) for whatever reasons. The patient has AMI, Hypertension, and Diabetes. Of whcih, AMI is the primary diagnosis (a.k.a the key condition) and is the main reason of current hospital stay and care service. During FHIR data exchange, SysA needs to specifically tell sysB that the AMI is primary diagnosis(key-condition) and the rest diagnosis are none-key-conditions .
To make it more complex, each diagnosis (AMI, Hypertension, Diabetes) has additional flag to indicate whether the diagnosis was confirmed when patient was first admitted. (1 = confirmed, 2 = not sure, 3=unknown, 4=no ).
hopfully I clearly explained the use case. The question is: does FHIR has a clear way to express above information? Thanks.
JD
Erich Schulz (Jun 01 2016 at 02:15):
@Jingdong(JD) Li - I think you provide a good example of a common real world situation that FHIR condition.verificationStatus is not currently able to deal with. The current values being provisional | differential | confirmed | refuted | entered-in-error | unknown.
Erich Schulz (Jun 01 2016 at 02:18):
The problem is that for any given problem there maybe a provisional and a set of differential diagnoses. But often patients have a set of "possible" co-morbidites that are important but yet to be confirmed.
Erich Schulz (Jun 01 2016 at 02:19):
It seems to me that the provisional | differential pair really belong in clinical impression
Erich Schulz (Jun 01 2016 at 02:21):
and that condition.verificationStatus should include possible
Yunwei Wang (Jun 01 2016 at 02:31):
In @Chris Moesel 's example, should that be 1 condition instance with 20 history version or 20 condition instances ?
Grahame Grieve (Jun 01 2016 at 03:01):
what's the relationship between a patient's problem list, and their ongoing encounters? The scenario from JD above, that's an encounter specific perspective on the problem list, yes?
Jingdong(JD) Li (Jun 01 2016 at 07:40):
@Grahame Grieve The patient's problem list is based on a specific encounter. Within an encounter, can FHIR reprensent the multiple problems with different clinical priority?
Grahame Grieve (Jun 01 2016 at 07:43):
there are 2 relevant extensions defined by the spec itself: primaryDiagnosis and relatedCondition.
Erich Schulz (Jun 01 2016 at 07:56):
what about the additional flag that @Jingdong(JD) Li mentioned? ie " (1 = confirmed, 2 = not sure, 3=unknown, 4=no )"
Grahame Grieve (Jun 01 2016 at 09:08):
There's no extension for those, no. That's make you own up space, then. or make a task and see what the committee thinks about it
Grahame Grieve (Jun 01 2016 at 09:08):
or both
Erich Schulz (Jun 01 2016 at 09:26):
yes sorry - agree i must stop rambling and attempt to be productive (note to self)
Michelle (Moseman) Miller (Jun 01 2016 at 12:48):
@Lloyd McKenzie can you elaborate on why Linkage is preferred? In the example mentioned earlier, we could have one condition with Condition.category = problem and no Condition.encounter. We would have 20 more conditions with Condition.category = diagnosis, each with a distinct Condition.encounter. I can see Linkage being used to link all 21 diabetes-related conditions together, but using Linkage to represent priority is where you lost me. I didn't think the scope of Linkage was encouraging links between different types of resources (e.g. Encounter and Condition). Additionally, the priority/rank/primary is still within the context of a single encounter (meaning all 20 diabetes diagnoses could all have a priority/rank/primary = 1), so I'm not sure why the Linkage resource is preferable to the encounter extension (even though I still wish it were an extension on condition instead of encounter)?
Yunwei Wang (Jun 01 2016 at 13:51):
@Michelle (Moseman) Miller I agree. If the purpose of using Linkage is to link all records for the same chronic condition, it can be also achieved by search Condition?code=xxx&clinicalStatus=xxx. Back to the topic, since priority is still within context of a specific encounter, I think the extension should be on Encounter.indication. If you need to know the priority of in a specific encounter, you can either go through Condition.encounter reference link to Encounter.indication.
Lloyd McKenzie (Jun 01 2016 at 17:12):
@Michelle (Moseman) Miller My understanding of what you were describing was linking multiple instances of the same condition together, but distinguishing one as primary. Linkage lets you do that. If you want to distinguish primary vs. secondary for different diagnoses, that has to be done in the context of an Encounter, EpisodeOfCare, Claim or something else.
Michelle (Moseman) Miller (Jun 01 2016 at 17:55):
We're creating different conditions (each with their own Condition.id) to represent each billed diagnosis for 'diabetes' at different points in time (encounter). Each encounter would have its own primary/principal diagnosis, such that each condition could be primary for its encounter.
By contrast, we aren't creating a single diabetes condition to represent both the billed diagnosis (ICD code) and chronic problem (SNOMED) on the problem list.
Looking forward to Health Concerns, I could see Linkage being valuable when linking all of the diabetes-related conditions together.
Erich Schulz (Jun 02 2016 at 00:04):
this is possibly ok - but it omits coping with uncertainty in the background problem list
Erich Schulz (Jun 02 2016 at 00:04):
the fundemental issue is that Condition.verificationStatus uses these "provisional/differential" notions that are intwined with implied meaning (ie a mutally excluse set of options to explain a focus issue)
Erich Schulz (Jun 02 2016 at 00:04):
a "problem list" rolls from one encounter to another - although everyone will have a slightly different take on it
Erich Schulz (Jun 02 2016 at 00:04):
the notion of a conditions priority for a given encounter is often very arbitrary - they often dont let doctors choose these but delegate to specialist coders who can choose the best one based on which code will be most lucrative for the hospital
Erich Schulz (Jun 02 2016 at 00:04):
@Grahame Grieve I think @Jingdong(JD) Li 's requirement applies to all problem lists
Jingdong(JD) Li (Jun 02 2016 at 01:50):
@Erich Schulz You are right. The use case I gave is a common realworld scenario, it applies to all problem lists.
Erich Schulz (Jun 02 2016 at 03:51):
@Jingdong(JD) Li, @Grahame Grieve has indicated that getting the "possible" added to the Condition.verificationStatus needs a case opened in the issue tracker. It is on my todo list - but it sounds like your need is more urgent than mine (I mainly have an academic interest)
Yunwei Wang (Jun 02 2016 at 04:03):
@Erich Schulz I don't get why the priority is related to Condition.verificationStatus.
Aleksandra Pavlyshina (Sep 06 2016 at 10:27):
Lloyd McKenzie: Encounter has an extension to allow indication of the "primary" diagnosis - http://hl7-fhir.github.io/extension-encounter-primarydiagnosis.html. EpisodeOfCare doesn't yet, but I think it's definitely reasonable to ask for one.
GF#10578 'Summary: Add an extension for primary diagnosis in the context of EpisodeOfCare' has been logged
Last updated: Apr 12 2022 at 19:14 UTC
