FHIR Chat · Select all that apply observations, multiple value · implementers

Stream: implementers

Topic: Select all that apply observations, multiple value


view this post on Zulip Travis Stenerson (Oct 06 2017 at 19:50):

Quick question for you. How does one record multiple value observations? Specifically, I'm looking at an observation in a cancer protocol that asks about body site for tumor invasion to adjacent tissues. Specifically, the protocol asks for the pathologist to "Select all that apply". Is this where one should slice valueCodeableConcept, tag each slice with a code for the bodysite that it represents, and then bind the componentvalue field to a "present, not present" ValueSet? Or would this "select all" question be recorded in FHIR as multiple observations all with the same code and a different valueset*?

*meant to say bodysite

view this post on Zulip Grahame Grieve (Oct 06 2017 at 19:58):

the correct answer is multiple observations

view this post on Zulip Eric Haas (Oct 06 2017 at 23:31):

or components... Which is how I seen or rather heard this type of multiple-choice-question-with-multiple-answers observation has been implemented.

view this post on Zulip Lloyd McKenzie (Oct 07 2017 at 02:19):

Whether component makes sense depends on whether the answers would make sense if captured as separate Observations. If they would, then separate observations should be used. If all of the answers need to be looked at only as a collective, components is the appropriate choice.

view this post on Zulip Travis Stenerson (Oct 07 2017 at 06:14):

Multiple observations would be more appropriate here then. Thank you.

view this post on Zulip Michelle (Moseman) Miller (Oct 09 2017 at 13:29):

There was an invariant in DSTU2 that prevented us from using component, but we got that invariant removed (per GF#9375). As such, we may use component in STU3 (e.g. Alcohol Type with components of Wine, Beer, and Liquor) for the following reasons:

  • Our internal system treats multi-select values/answers as a single observation because they share the same attributes (such as id, performer, effective date, status, comment....).
  • Treating these as independent observations introduces unintended consequences if an app tries to update/modify a "shared" attribute (e.g. effective date, performer, status, comment...) of a single observation -- as it will effectively update all observations (e.g. an app can't modify wine without also modifying beer and liquor).
  • The Observation.comment could have any scope (ranging from a comment about one value or all values together). Exposing each value as an observation would then risk taking the comment out of context (e.g. comment about wine showing up on the observation for beer).

view this post on Zulip Lloyd McKenzie (Oct 09 2017 at 13:53):

This is one of those cases where not all servers will be consistent. The only question I'd have in Michelle's case is whether it's better to use Observation.component or to continue to use related observations, but to have them contained. I think in both cases, you're not necessarily going to get information back consistently if you search presuming separate Observations. Is there any guidance we could give to implementers here?

view this post on Zulip Eric Haas (Oct 09 2017 at 19:14):

It would suggest to me to use component...

view this post on Zulip Travis Stenerson (Oct 10 2017 at 14:04):

Well these observations could be interpreted independently if necessary. I would rather they exist together as it could get messy when a single data entry question is producing any number of observations. However I could picture a situation where a researcher wants to look at all lung tumors that invade the visceral pleura specifically.

My use case actually only depends on the interpretation as a whole of this observation or set of observations (invasion seen or not seen), but this situation has come up a number of times as I'll often use the CAP protocols to suggest how I should profile certain observations and the 'select all that apply' question is very common. Guidance would definitely be appreciated.

view this post on Zulip Michelle (Moseman) Miller (Oct 12 2017 at 13:43):

I just logged GF#14031 asking for the Observation Grouping section (http://build.fhir.org/observation.html#10.1.4.1) to address multi-valued observations (included a link to this thread as well as shared my earlier considerations for using component)


Last updated: Apr 12 2022 at 19:14 UTC