Stream: implementers
Topic: Condition.clinicalStatus recurrence vs active
Sadiq Saleh (Apr 03 2017 at 17:12):
I have a question about the use of the recurrence vs active codes for Condition.clinicalStatus. Is it assumed that a Condition with clinicalStatus=recurrence is also inherently clinicalStatus=active?
If this is true, then a tumor that has recurred twice would have gone through the following clinicalStatus changes:
active -> remission -> recurrence -> remission -> recurrence
Is this logic correct?
Michelle (Moseman) Miller (Apr 04 2017 at 00:42):
In the current published STU3, that is correct. In the value set, recurrence is a child of active.
However, going forward, Patient Care approved a change (GF#13025) to support both recurrence and relapse as children of active. That changes your example to be active > remission > relapse > remission > relapse
Sadiq Saleh (Apr 04 2017 at 13:18):
Thanks @Michelle (Moseman) Miller
Sadiq Saleh (Apr 04 2017 at 15:08):
Just a follow up, what is the approximate timeline for this change? It says the target release is version 2.0.6, is this supposed to read 3.0.6 now that this version of FHIR started with 3.0.0?
Sadiq Saleh (Apr 05 2017 at 14:15):
As a follow up question, how does it work to link ProcedureRequests, etc. with a specific instance of a recurring/relapsed tumor? For example would I be able to say I want to have ProcedureRequest.reasonReference point to "tumor relapse 1" and be able to distinguish this from ProcedureRequest.reasonReference(s) that point to "tumor relapse 2"
Lloyd McKenzie (Apr 05 2017 at 14:33):
You can make your references version-specific (e.g. [base]/Condition/57/_history17). References to Condition will often be version-specific because the condition record will often evolve and the linkage will need to be to a point-in-time snapshot of it.
Michelle (Moseman) Miller (Apr 05 2017 at 15:29):
@Sadiq Saleh Where are you seeing the target release? The GF#13025 has a target release of None at the moment, but it will likely get applied to the current build (i.e. http://build.fhir.org/condition.html) in the coming weeks. We have/had a brief substantive freeze after release 3 was published, so I have been waiting until the dust settles to start applying changes which would roll into the next release (R4).
Sadiq Saleh (Apr 05 2017 at 15:53):
Thanks @Lloyd McKenzie. As far as I understood it that is how the versions should be used. However we were unsure how you would be able to differentiate a version update due to an update for clerical error for example (in which case the references should be maintained) vs an update to change clinicalStatus? How would a system be able to differentiate between the two?
Sadiq Saleh (Apr 05 2017 at 15:55):
@Michelle (Moseman) Miller it is on the tracker page for 13025:
pasted image
Lloyd McKenzie (Apr 05 2017 at 16:37):
When you create a reference, you just point to the version you were looking at when you decided to assert the relationship. There's no real need to know what particular change brought about the new version
Lloyd McKenzie (Apr 05 2017 at 16:39):
The target release you're seeing is totally bogus and I have no idea where it's coming from. I see that too when I'm not logged in. There's no such thing as a 2.0.6 release. I've passed it on to gForge support.
Sadiq Saleh (Apr 05 2017 at 17:03):
Can this not cause an issue in the following example case where Condition.verificationStatus goes from Differential -> Confirmed. In this case you would still want the references from procedureReqeuests to still point to the now confirmed diagnosis.
This made us think that maybe a relapsed tumor should instead be treated as a new instance of the disease e.g. Condition/57 for primary and Condition/212 for relapse with Condition/212 having a reference field that points to Condition/57 as the primary
Lloyd McKenzie (Apr 05 2017 at 17:12):
Your reference points to the differential diagnosis. If someone wants to see what the current state of the condition is, they can always query for the current version. At the time you made the decision/captured the link, it as a differential diagnosis. And the fact it was a differential, not a confirmed might well have been relevant to the decision made.
Sadiq Saleh (Apr 05 2017 at 19:36):
Thanks for answering my follow up questions.
Just to clarify that I understand, if I want to know all decisions related to the patient while the tumor was relapse and differentiate this from decisions related to while the tumor was active, I should look for any references to the condition with clinicalStatus="relapse" irrespective of version?
Lloyd McKenzie (Apr 05 2017 at 19:41):
If you do a chained search, most servers will respect the version as part of the chaining, but, at the moment, that's not guaranteed by the spec.
Sadiq Saleh (Apr 05 2017 at 21:00):
Thanks again
Last updated: Apr 12 2022 at 19:14 UTC
