Stream: implementers
Topic: Type of Condition
Christian Kamann (May 22 2019 at 11:32):
Hey all,
just a quick question. Whats the best way to differentiate between main diagnosis and secondary diagnoses in a condition resource? I am currently mapping real anonymized patient data to FHIR resources and could not find this particular differentiation in the specification. Thanks in advance!
Lloyd McKenzie (May 22 2019 at 14:34):
The notion of "main" vs. "secondary" is contextual and thus lives outside of Condition. (The same Condition might be the 'primary' diagnosis for one encounter or claim and 'secondary' for another.) Ordering is thus handled in the relationship from Encounter, Claim or some other contextual resource to the Condition.
Yunwei Wang (May 22 2019 at 14:45):
In R4, you can use EpisodeOfCare.diagnosis. So EpisodeOfCare.diagnosis.condition references to Condition resource and EpisodeOfCare.diangosis.rank assigns priority (in you case, you can set rank = 1 for main, rank = 2 for secondary)
natus (Jul 08 2019 at 19:40):
The same Condition might be the 'primary' diagnosis for one encounter or claim and 'secondary' for another.
@Lloyd McKenzie this does not make sense since a condition is bound to 0..1 encounter. The rank should be a condition element
Lloyd McKenzie (Jul 08 2019 at 21:04):
That's the encounter that defined the Condition. Numerous encounters can point to the same Condition as an admitting or discharge diagnosis.
natus (Jul 09 2019 at 09:34):
this is suprizing to store condition/procedure and related information within the encounter.diagnosis. As a result, the encounter resource is quite fat and the implementation of something efficient challenging. This does not reflect how things works in france: conditions are independant and repeated over time and encounters (ICD10)
Jose Costa Teixeira (Jul 09 2019 at 10:45):
the same diagnostic can be repeated/kept over encounters, but this is a code, so we are just indicating it, not defining it. so i don't see why this makes Encounter fat.
Jose Costa Teixeira (Jul 09 2019 at 10:47):
With procedure, i don't see the issue. Why is that also making Encounter fat? in the odd cases that you have one encounter derived from many procedures, this would be a couple of references but otherwise the Encounter contains at most one procedure.
Jose Costa Teixeira (Jul 09 2019 at 10:59):
Perhaps I am missing something. Are you intending to include in the Encounter resource instance the procedures performed during that encounter? That would be fat, but not a good implementation.
Jose Costa Teixeira (Jul 09 2019 at 10:59):
@Nicolas Paris ?
natus (Jul 09 2019 at 11:01):
Are you intending to include in the Encounter resource instance the procedures performed during that encounter? That would be fat, but not a good implementation.
This is what the spec ask for. Since the rank information is only there. If I do not want to lose the rank information, I have to
Jose Costa Teixeira (Jul 09 2019 at 11:01):
The Procedure and encounter have references to each other, and these should be to different procedures; one for the procedure that was performed during the encounter (stored in Procedure.encounter), and another for cases where an encounter is a result of another procedure (stored in Encounter.indication) such as a follow-up encounter to resolve complications from an earlier procedure.
Jose Costa Teixeira (Jul 09 2019 at 11:02):
This means: if you are in a hospital with a broken leg, and have an xRay and a wound care under a procedure, they are not in encounter.condition.
Jose Costa Teixeira (Jul 09 2019 at 11:02):
you have encounter 1, possibly encounter.condition not pointing to a procedure. Possibly encounter.condition can say "broken leg"
Jose Costa Teixeira (Jul 09 2019 at 11:03):
and then you have procedure1 and procedure2, both with procedure.encounter pointing at encounter1
natus (Jul 09 2019 at 11:05):
this may be how care works in the US. This is not applicable for France.
natus (Jul 09 2019 at 11:05):
a condition is not shared, and each condition has a rank
natus (Jul 09 2019 at 11:06):
Primary Condition, Secondary Condition and so on
Jose Costa Teixeira (Jul 09 2019 at 11:06):
this may be how care works in the US. This is not applicable for France.
I am far from basing this on how US healthcare works :)
natus (Jul 09 2019 at 11:07):
Right now the only way to do this information is to build a fat encounter. What about using the category ?
natus (Jul 09 2019 at 11:07):
encounter-diagnosis, encounter-primary-diagnosis, encounter-secondary-diagnosis for the condition.category ?
Jose Costa Teixeira (Jul 09 2019 at 11:08):
This is how the spec defines the links, and also works for Europe. Encounter.condition is when the procedure is the reason for the encounter, not the outcome of the encounter.
natus (Jul 09 2019 at 11:09):
ok, so what about extending the category to store the information ?
Jose Costa Teixeira (Jul 09 2019 at 11:09):
Can you give an example of what you want to exchange?
natus (Jul 09 2019 at 11:11):
well during the encounter, several icd10 condition code have been associated, and there is one primary, 2 associated and some other tagged condition.
natus (Jul 09 2019 at 11:11):
maybe a condition extention for french makes sense for this specific
use case
Jose Costa Teixeira (Jul 09 2019 at 11:11):
are those conditions the reason for the encounter, or are they found during the encounter?
natus (Jul 09 2019 at 11:12):
they are found during
Jose Costa Teixeira (Jul 09 2019 at 11:12):
then that is an outcome. Observation
natus (Jul 09 2019 at 11:12):
observation ?
natus (Jul 09 2019 at 11:13):
the same would apply for outcome procedure?
Jose Costa Teixeira (Jul 09 2019 at 11:14):
bien sur :)
natus (Jul 09 2019 at 11:14):
icd9 condition in the US are shared thought observation ?
Jose Costa Teixeira (Jul 09 2019 at 11:15):
this is the generic guidance - resources that represent findings are created and linked to the existing resources, we don't update resources with "oh and by the way we also found this". But in Encounter, the definition is not clear - let another European chime in @Alexander Henket ? should we clarify that encounter.condition is not intended to contain the conditions or procedures that may be found /performed during an encounter?
natus (Jul 09 2019 at 11:16):
I would prefer to store the condition into the condition resource, and the procedure into the procedure resource than into the observation.
natus (Jul 09 2019 at 11:17):
this is extremely counter intuitive
Jose Costa Teixeira (Jul 09 2019 at 11:17):
sorry, you are correct
Jose Costa Teixeira (Jul 09 2019 at 11:17):
condition, not observation
Jose Costa Teixeira (Jul 09 2019 at 11:17):
procedure is procedure
Jose Costa Teixeira (Jul 09 2019 at 11:18):
observation is if you need to make some tests and then from which you say "this means the patient has TB". but if you just say "patient has TB", this is condition
natus (Jul 09 2019 at 11:19):
Ok. So I have 2 options to store the primary/secondary details of the condition:
1. use the condition.category
2. add a dedicated french extension
Jose Costa Teixeira (Jul 09 2019 at 11:19):
Let's see what others say. The point was that we do not accumulate findings on the Encounter
natus (Jul 09 2019 at 11:19):
ok let s see
Jose Costa Teixeira (Jul 09 2019 at 11:20):
doesn't Rank suffice to say "this is primary, this is secondary"?
Jose Costa Teixeira (Jul 09 2019 at 11:21):
perhaps you would need an extension, but from this not on encounter (that was my point) but rather on condition
Alexander Henket (Jul 09 2019 at 11:23):
@Jose Costa Teixeira I've not yet thought about that, but after a brief look in the resource and without having read everything here, my first thought is "Gosh, what's the different between Encounter.reasonReference(Condition) and Encounter.diagnosis.condition"? Both read something like
Reason the encounter takes place,
If anything, that would be up in my list for clarification
Jose Costa Teixeira (Jul 09 2019 at 11:26):
agree, did not see that. in this chat we were clarifying (please check) that encounter.diagnosis is NOT for the diagnoses found during the encounter. Those would be other resource instances.
Jose Costa Teixeira (Jul 09 2019 at 11:27):
btw, descriptions of those elements (also encounter.condition.rank) could be improved...
natus (Jul 09 2019 at 12:03):
Jose Costa Teixeira: doesn't Rank suffice to say "this is primary, this is secondary"?
Jose Costa Teixeira: perhaps you would need an extension, but from this not on encounter (that was my point) but rather on condition
True. rank would be sufficient. However rank is an Encounter element.
Alexander Henket (Jul 09 2019 at 12:56):
The definition for Encounter.diagnosis.condition is more precise/clear than the shortname which looks misleading to me.
shortname: The diagnosis or procedure relevant to the encounter
definition: Reason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure.
Alexander Henket (Jul 09 2019 at 12:58):
So in short: I share your analysis that Encounter.diagnosis is not a diagnosis found during an Encounter, but something that led up to the Encounter.
Alexander Henket (Jul 09 2019 at 13:00):
A task to clarify Encounter.reasonReference versus Encounter.diagnosis and a task to clarify the Encounter.diagnosis.condition shortname versus its definition would probably be a good thing
Alexander Henket (Jul 09 2019 at 13:08):
Finally: I don't think I understand why a diagnosis and/or a condition element should be able to point to a Procedure. You would think that this makes more sense:
Encounter.reasonReference reference(...)
Encounter.reason 0..* The list of reasons leading up to this encounter
.reasonReference Reason the encounter takes place (reference)
Reference(Condition | Procedure | Observation | ImmunizationRecommendation)
.use
.rank
Alexander Henket (Jul 09 2019 at 13:13):
Or even more bold, move Encounter.reasonCode too
Encounter.reasonCode CodeableConcept
Encounter.reasonReference reference(...)
Encounter.reason 0..* The list of reasons leading up to this encounter
.reasonCode Reason the encounter takes place (codeableconcept)
.reasonReference Reason the encounter takes place (reference)
Reference(Condition | Procedure | Observation | ImmunizationRecommendation)
.use
.rank
Jose Costa Teixeira (Jul 09 2019 at 14:55):
A task to clarify Encounter.reasonReference versus Encounter.diagnosis and a task to clarify the Encounter.diagnosis.condition shortname versus its definition would probably be a good thing
Can I do the honors?
Jose Costa Teixeira (Jul 09 2019 at 14:57):
I don't get the "Finally" part- are you saying that condition can be subsumed under reason?
Jose Costa Teixeira (Jul 09 2019 at 14:59):
That does not seem bad in itself, I wonder if there was a reason for making that separation explicit.
I know there is a big difference between "they come because they had a surgery that went wrong" and "they come because they are anxious which is because of the surgery that went wrong".
Alexander Henket (Jul 09 2019 at 17:03):
Can I do the honors?
Certainly, please do. Phrased right you could make the WG think about the reason/diagnosis thing and let it decide for itself whether or not they should have been one thing.
natus (Jul 09 2019 at 19:28):
Can I do the honors?
and BTW, please moove the rank from encounter to condition. :blush:
Lloyd McKenzie (Jul 10 2019 at 00:54):
Rank is always in the context of an encounter or claim. Therefore it must live on one of those resources. Conditions can span numerous encounters.
Brian Postlethwaite (Jul 10 2019 at 12:14):
There are a few trackers that are current, and some still to be applied.
The workgroup does want feedback on this too. Thoughts @Cooper Thompson @Simone Heckmann ?
Cooper Thompson (Jul 10 2019 at 13:15):
If I remember, we haven't really nailed down exactly what changes we wanted to make to Encounter.condition, but I think the most recent thoughts are summarized in our May 2019 WGM meeting minutes.
Simone Heckmann (Jul 11 2019 at 06:19):
@Christian Kamann We have discussed this in the German community, but didn't come round to adding it to the German Base Profiles yet. Please feel free to open a topic in the German Stream, so we can discuss this in particular. From the top of my head, I'd say it's a property of Encounter, not Condition, as stated above...
Simone Heckmann (Jul 11 2019 at 06:26):
We have discussed "Haupt-/Nebendiagnose" in part [here](stream:german+(d-a-ch) topic:MI-I-Kerndatensatz)
...sorry, that thread was a bit of a mess with multiple topics being discussed at the same time...
But as I said, feel free to bring it back up! As we are currently working on upgrading our base profiles to R4, now is a good time to add new stuff!
Simone Heckmann (Jul 11 2019 at 06:35):
@Brian Postlethwaite We have had a similar discussion about the ambiguity of Encounter.reason and Encounter.diagnosis and have added GF#22764 for this. The proposal is basically, to make Encounter.reason more verbose so you can use it for both reasons for admission/discharge and also give details like "admission from/ discharge to facility x because of reason y " or "discharge because of death" etc.
TBH we have always interpreted the Encounter.diagnosis as referencing diagnosis that have been established during the Encounter and are relevant for billing (aka: "Primary/Secondary" Diagnosis). We'd therefore support the GF#19285 to move Encounter.diagnosis to Account.diagnosis
Last updated: Apr 12 2022 at 19:14 UTC
