Stream: implementers
Topic: Observation.related target
Bob Milius (May 31 2016 at 20:32):
I'm trying to understand how to group Observations. From what I can tell, there are three ways: Diagnostic Report, Observation.component, and Observation.related. The Observation.related target can be either Observation or QuestionaireResponse. Can it be a Profile of Observation with extensions? e.g., the Observation for Genetics Profile?
Rob Hausam (May 31 2016 at 22:23):
Bob, yes, that's the situation (I don't believe there's anything else)
and there shouldn't be a problem with using a profile of Observation with extensions - I think the Observation for Genetics profile should be fine (haven't actually looked at it myself yet)
Eric Haas (Jun 01 2016 at 04:21):
Explained here in some detail http://hl7-fhir.github.io/observation.html#4.31.4.1
Eric Haas (Jun 01 2016 at 04:22):
In general ordered stuff (lab , imaging ) is grouped at the Diagnostic Order.
Bob Milius (Jun 02 2016 at 13:43):
thanks @Rob Hausam and @Eric Haas
Simone Heckmann (Jun 02 2016 at 13:46):
Concerning Observation.related, please check GF#9970:
The use of a "code + reference" pattern is discouraged, particularly where the number of relationships is low. The rationale is as follows: - it creates more complex instances - it requires slicing to apply constraints to what relationships are supported, what cardinalities are allowed, which resource types are permitted, etc. - it creates the possibility of ambiguity as to what's in core. Relationships that aren't part of core shouldn't be included as part of core whether explicit relationships or the code+reference approach is used code + reference is appropriate if the number of "core" relationship types is large (>~5) and the referenced type choices make sense for all of the relationship types. Should ideally be consistent across resources from the same "families" as per QA rules.
Bob Milius (Jun 02 2016 at 14:26):
@Simone Heckmann so the “code + reference” pattern for Observation.related would be type = code and target = reference? Sorry, I'm still fairly new to this.
Eric Haas (Jun 02 2016 at 14:46):
@Simone Heckmann OO will need to review the type codes before we can agree to change this structure. I have created a separate tracker item.
Joel Schneider (Jun 02 2016 at 16:14):
For data involving genetic sequencing, one possible use of Observation.related would involve a derived-from relationship between an interpretation (e.g. a coded Observation indicating a biomarker such as BRCA1, or an HLA type, or a predicted ABO blood type) and primary data (genetic sequence(s)).
Would this be considered a "code + reference" pattern? Is there some disagreement about whether use of Observation.related is appropriate for this type of thing?
Lloyd McKenzie (Jun 03 2016 at 01:51):
The proposal that OO is considering would eliminate Observation.related and instead add Observation.component and a few others, as well as some extensions.
Eric Haas (Jun 05 2016 at 01:57):
Lloyd is partially correct. We already have Observation.component. There are many possible ways to express an interpretation including and inline interpretation code element in Observation, or simply grouping an interpretation observation along with the others within a diagnostic report kind of like is done in V2 messaging. 'derived-from' is can also be to say that the interpretation value was deduced or infered from the target Observation(s).
I don't know what direction the WG is going to go on this, but I think if we choose to inline with the related we would have a .member and .
derivedFrom elements.
Joel Schneider (Jun 05 2016 at 06:37):
If I'm understanding correctly, for our use case it wouldn’t be appropriate to inline the (primary) sequence data with its initial interpretation.
In short, the primary data is immortal, but its interpration is not.
One of our motivations for storing the primary data is so it can be reinterpreted later.
Shweta Katdare (Jun 07 2016 at 13:28):
Can someone point me to a multi-component Observation resource example ? I want to see all patient vitals into one Observation which will be a part of a Bundle
Eric Haas (Jun 07 2016 at 22:57):
@Shweta Katdare
Some observations can have multiple components that can only be interpreted when taken together. In most cases Observation.component is not intended as simply a mechanism for grouping observations and SHOULD NOT be used to group results that can be reasonably interpreted independently. Your use case should be handled using and a vitals " panel" Observation reference the individual vitals using the .related element.
an example of component is http://hl7-fhir.github.io/observation-example-bloodpressure.html
an example of a vitals panel is here: http://argonautwiki.hl7.org/index.php?title=Vital_Signs_Panel_Example
Eric Haas (Jun 07 2016 at 22:59):
@Joel Schneider when I say inline I mean a proposal to create an new element 'derived-from" of type reference to replace the proposed structure using .related. The sequence data would still be a separate stand alone resource.
Joel Schneider (Jun 07 2016 at 23:09):
@Eric Haas Ok, that seems reasonable; having a 'derived-from' reference to a stand-alone sequence instead of using .related, that is.
Shweta Katdare (Jun 08 2016 at 14:35):
Thank you @Eric Haas . I will look into those examples.
Last updated: Apr 12 2022 at 19:14 UTC
