Stream: implementers
Topic: Observation: multiple choice
Alexander Henket (May 22 2019 at 19:11):
Observation.value is 0..1 so it cannot handle multiple answers apparently. Does that mean I should always turn to Questionnaire for those cases? In V3 the Observation/value is 0..*. Was the FHIR limitation a conscious move?
Lloyd McKenzie (May 22 2019 at 19:21):
The expectation is that you're capturing separate Observation instances or you're using a data type like SampledData. Questionnaire is for data capture, but not for analysis/comparison/querying.
Michele Mottini (May 22 2019 at 19:25):
Or use Observation.component
Eric Haas (May 22 2019 at 19:28):
example here for a multiple answer question: http://build.fhir.org/observation-example-alcohol-type.html
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jun 11 2019 at 13:36):
@Alexander Henket the observation should be the result and the observation value should be the value. Where multiple observation values are reported, typically (at lease from a lab perspective) they would be reported on separate results/observations (question and answer pairs is another way to think about the modeling)
Your question also highlights a fundamental aspect of interoperability. If folks are modeling the same types of data differently, inoperability may occur. Will be interesting to see how this evolves for the use cases described.
Diego Bosca (Jul 01 2019 at 12:02):
So @Lloyd McKenzie , how should be interpreted when there are several extensions attached to the same observation? (e.g. genetics)
Should they really be separated Observations?
Lloyd McKenzie (Jul 01 2019 at 14:22):
In the draft genomics reporting IG, most elements of a genetics report are either modeled as distinct Observations or as Observation.component. There are very few places where extensions are needed/appropriate. (You can see the draft IG here: http://build.fhir.org/ig/HL7/genomics-reporting/
Diego Bosca (Jul 01 2019 at 16:19):
But current profile doesn't follow that right? https://www.hl7.org/fhir/observation-genetic.html
Or maybe I'm misunderstanding something...
Anyway, for complex observations the general rule would be to define each minimal observation that can be identified in their own profile and then create references on these observations from... another (upper level) observation profile? or maybe using another resource e.g. inside of sections in a composition?
Lloyd McKenzie (Jul 01 2019 at 17:05):
Right. Which is why there's a notice at the top of the profile noting that it's going to be replaced and pointing to the draft IG as guidance.
Lloyd McKenzie (Jul 01 2019 at 17:07):
The general rule is that anything that can be stated independently in a meaningful way should be a distinct Observation. Anything that's qualifying/describing what was observed should be an Observation.component. Anything that's qualifying the Observation process itself rather than describing what was observed (e.g. who verified the Observation, what the specimen delivery mechanism was, etc.) would be appropriate as an extension.
Last updated: Apr 12 2022 at 19:14 UTC
