FHIR Chat · Interpreting Observation.clinicalStatus without any dates · implementers

Stream: implementers

Topic: Interpreting Observation.clinicalStatus without any dates


view this post on Zulip Morten Ernebjerg (Apr 29 2021 at 15:42):

We are looking displaying Condition data in our UI and obviously want to include the clinical status. However, the clinical status seems of limited use unless one knows when it was asserted. However (at least for R4), it is perfectly valid to have a Condition without any date information (i.e. none of onset[x], abatement[x], or recordedDate present). Some IGs profile require recordedDate (e.g. the German medical informatics initiative profile), but e.g. IPS allows "timeless" conditions.

My question is: Are there any guidelines/experience for dealing with Observation.clinicalStatus (especially "active") in the following cases:

  • No time time information whatsoever
  • Only onset[x] provided

(I found a related thread but din't quite find the answers there.)

view this post on Zulip Lloyd McKenzie (Apr 29 2021 at 16:04):

There's a proposed change request to add a "lastVerified" or similar date. However, the reality is that sometimes you'll have a record and have no dates - obviously not as useful as having them, but better to know it's "possibly still relevant" or "happened at some point" than to have no information at all.

view this post on Zulip Morten Ernebjerg (May 01 2021 at 10:32):

Thanks @Lloyd McKenzie - we will find a way.

view this post on Zulip Rob Reynolds (May 01 2021 at 14:18):

I will also add that "happened at some point" is sufficient for a lot of requirements so "limited use" is fairly limited. :)

Not arguing against the proposed change though. Completely agree having the option to have the date would be a good thing.

view this post on Zulip Morten Ernebjerg (May 03 2021 at 14:16):

Out of curiosity: I see that in moving from STU3 to R4, the field assertedDate was replaced by recordedDate (with an associated change of meaning from assertion to recording on system). With the proposed change @Lloyd McKenzie mentions, it seems one would come back to smt. close to the STU3-field. What was the motivation for moving away from it with R4?

view this post on Zulip Eric Haas (May 03 2021 at 15:58):

Assuming we are talkind about Condition and not Observation. I'd say the reason was to align with the workflow patterns which occurred at that time.

view this post on Zulip Lloyd McKenzie (May 03 2021 at 16:27):

Also, the word "asserted" can be a bit misleading in terms of what it means. 'reported' is clearer.

view this post on Zulip Morten Ernebjerg (May 03 2021 at 17:58):

OK, thanks!


Last updated: Apr 12 2022 at 19:14 UTC