Stream: Orders and Observation WG
Topic: Observation onset
Bob Freimuth (Oct 30 2020 at 04:58):
The Condition resource supports a structure to capture information about onset, but a similar structure is not part of Observation. I have not been able to find guidance on how to represent onset for an Observation. Could someone please point me to documentation or at least a summary of discussions?
Thanks!
Jean Duteau (Oct 30 2020 at 05:16):
why would you need an onset for an Observation? Observation.effective[x] is the clinically relevant time/period for the observation and that seems all you would need? If you want to say when something you observed started, wouldn't you just set the effectivePeriod.start to be that date/time?
Lloyd McKenzie (Oct 30 2020 at 06:12):
Observations don't deal with the evolution of something - they just deal with "what is, now" or "what was, for a specific period" or, very rarely "what is expected to be, when". If you care about evolution over time, you have to use Condition
Shahim Essaid (Oct 30 2020 at 07:17):
To follow up on @Bob Freimuth question, let's assume Observation is the right resource, how can we capture that Observation.code 's onset was at X age, let's say at age 10? We don't have information for how this age can be placed in time (so we can't set a start date/time, etc. because we don't know a birthdate or some other time reference) but we do know a quantity of time at which the observation started.
In discussing this with Bob I thought that it might be appropriate to capture this Quantity of time that represents the onset of observation as a component of the Observation. Is that a good option? We have examples where age related values are represented in the form of Quantity and /or Coding/CodableConcept and Condition.onset[x] at least allows the former. If using Observation.component is an option, it will allow us to address both cases. This still leaves us unable to capture a Condition's onset value when the values are coded. See this hierarchy as an example of "onset" codes: https://hpo.jax.org/app/browse/term/HP:0003674
Bob Freimuth (Oct 30 2020 at 14:17):
@Jean Duteau The description for Observation.effective seems to indicate it is used to capture the timing of the Observation itself, not of the thing which is observed. For example, I could use that to express that I observed something last week, but I did not think I could use that to express the thing I observed started 3 weeks ago (onset).
Bob Freimuth (Oct 30 2020 at 14:26):
@Lloyd McKenzie The use case isn't really evolution of the observed thing over time, it is simply placing a time on when that thing started. I understand that Observation is used to capture clinical assessments made during and encounter (for example), but what if we wanted to refer to a date of onset that occurred prior to the observation itself? It is unlikely that a phenotype will arise during the encounter itself.
I'd like clarification on "what was, for a specific period", because I didn't interpret that from the docs.
Example: Today at 3 pm Dr. X observed that patient Y has a rash that began Z weeks ago.
Would we use Observation to capture "Z weeks" if it was taken from a clinical note? If "Z weeks" is patient-reported, is that modeled differently? I am wondering if derivedFrom DocRef or Obs might be the solution here.
Jean Duteau (Oct 30 2020 at 14:50):
I would set the Observation.effective to be Z weeks ago because that is the clinically relevant time. The "today at 3pm" is just when it was recorded and that's captured in the lastUpdateTime or even in the referenced Encounter. I might be wrong though so we'll see what others say.
Vassil Peytchev (Oct 30 2020 at 14:53):
Observation: There is a rash at this moment
Condition: The patient has a rash with onset of Z weeks ago.
Condition.evidence.detail then references the Observation.
Shahim Essaid (Oct 30 2020 at 18:08):
But isn't Condition meant for things that need medical attention? As far as I understand it, that is one of the main criteria for deciding if a Condition should be instantiated, not just to further qualify an Observation. The use case where we need to capture an age representation along with an observation is when we need to create a phenotypic profile for a patient and we don't have any time references, we only have a Quantity of time that stands for their age. The "started 3 weeks ago" approach doesn't work. We don't have a DOB, and encounter date, etc. but it is still necessary to capture the temporality of the observations. There are also cases where the quantity of time is represented with a set of codes and that's where the onset needs a CodableConcept to capture that.
To further clarify, this is not occurring during a clinical encounter. We have a set of phenotypes per patient in some database, and various temporal encodings for the age at which those phenotypes started (but no points in/at time), and we'd like to instantiate Observation to stand for that data. This is why we need a richer way to capture the temporal sense of the onset. So far we need Quantity or a subtype of it, and CodableConcept, and we're trying to avoid capturing that as additional Observation instances over these observations to hold that information. One ideas we had is to embed this temporal information as a component.
Vassil Peytchev (Oct 30 2020 at 18:48):
Based on the definition of the Condition resource, its scope seems to appropriately cover your use case.
Shahim Essaid (Oct 30 2020 at 18:52):
@Vassil Peytchev thanks! If we use Condition instead of Observation, the next issue we need to resolve is not being able to capture onsetCodableConcept. We can create an extension but we're looking for any better or existing ways for doing this. We will be using onsetAge and onsetRange but we also need the onsetCodableConcept option.
Lloyd McKenzie (Oct 30 2020 at 19:15):
If you want to capture Observation + age, you would capture the age as an Observation.component (because it's qualifying the Observation). That's not as useful as capturing Observation.effectiveTime though because most systems won't support it and you won't be able to search on it as well
Lloyd McKenzie (Oct 30 2020 at 19:16):
Condition is used for any ongoing state of the patient where there's an expected need to monitor over time. It doesn't necessarily need medical/clinical attention.
Lloyd McKenzie (Oct 30 2020 at 19:17):
Note that whether using Observation or Condition, you'll need to link it to the Patient resource - and in most cases Patient will have a birthDate.
Shahim Essaid (Oct 30 2020 at 22:32):
@Lloyd McKenzie thanks! These issues/use cases are coming form a research perspective where data is deidentified. Sometimes they shift all dates and other times they remove dates and just give quantities from some a non specific point in time, like 5 years old, as a Quantity (value 5 and unit Year) or as a Coding. This is another example of an age representation: "P25Y3M2D". This means 25 years, 3 months, and 2 days. For this example, we're thinking about dealing with it as you can see here: https://github.com/phenopackets/domain-analysis/issues/22 but this approach will be turned into the component entry, not a separate observation.
Just wanted to share some additional background. Sorry for the noise if this is too much sharing here. I'm new to the chat community here and not sure how much to share on these threads.
Vassil Peytchev (Oct 30 2020 at 22:43):
There is Condition.onsetAge that sounds close to what you need. Is it possible to add an extension for a onsetAgeCode?
Shahim Essaid (Oct 30 2020 at 22:47):
An extension is an option if that's the best way to go. We're trying to avoid extensions if there is a better option. So far we're biased towards using Observation and embedding the age as a component but we'd like to do things the way the rest of the community does this if someone has already adopted a patter. There are other reasons for us needing to add components to an Observation. Here is an example of that (at the bottom of the page): https://phenopackets-analysis.readthedocs.io/en/latest/domain-entities/clinical-findings.html
Lloyd McKenzie (Oct 30 2020 at 23:17):
Embedding age in an Observation is fine - if the data you're capturing is an Observation. However, if you're capturing a Procedure or something like that, there may be little choice other than to use extensions. (Note that P25Y3M2D would normally be expressed as just an age in days. Software can worry about rendering it in separate components, but for exchange and math, a simple integer duration is best.
Last updated: Apr 12 2022 at 19:14 UTC
