Stream: genomics / eMerge Pilot
Topic: Indirect Results
Larry Babb (Apr 02 2019 at 14:13):
I am looking for more of a clarification on the following please.
If I am using observation panels and other observation profiles that aggregate a set of other Observations (results) is it correct to assume that the nested observations do NOT need to be directly linked as "results" to the overarching DiagnosticReport?
Another way to think about it is...
Is the "hasMember" relationship of the Genomics Panel sufficient to assume that all "members" of the genomics panel are lower level "results" for the diagnostic report that sits above?
Lloyd McKenzie (Apr 02 2019 at 14:58):
Membership in a diagnositic report is transitive across the Observation hasMember relationship. (Though perhaps this should be stated explicitly somewhere - @Eric Haas ?)
Eric Haas (Apr 02 2019 at 15:42):
can you clarify what you mean - an example?
Eric M Haas, DVM, MS
Health eData Inc
1183 Mountain View Circle, Napa, CA 94558
Lloyd McKenzie (Apr 02 2019 at 15:48):
If a DiagnosticReport points to Observation A and that ObservationA hasMember ObservationB, is ObservationB considered to be part of the DiagnosticReport or is it necessary to also have the DiagnosticReport point directly to ObservationB as well?
Eric Haas (Apr 02 2019 at 16:43):
its obvious to me that the DiagnosticReport points to a panel would imply that report would include the members of the panel. Otherwise why have a panel grouping mechanism. Saying this explicitly is unneeded in my opinion. The way observations are grouped is already documented in the notes under Observation.
Patrick Werner (Apr 03 2019 at 10:48):
I would be in favor of stating it explicitly, otherwise there could be issues with FHIR Server implementations not resolving these implicit relationships during search queries.
Lloyd McKenzie (Apr 03 2019 at 14:11):
Implicit relationships aren't resolved during search. If you want Observations pointed to by the DiagnosticReport as well as member Observations, you'll have to ask for both.
Bret H (Apr 04 2019 at 14:33):
@Lloyd McKenzie can you expound a bit? Would you say that you would expect the implicit relationship to be resolved by the receiving system at the time of ingesting the report? i.e. the receiving system has the responsibility to store the observations and relationships in a retrievable manner? @Patrick Werner with explicit relationships I can see how the reviving system would have an easier time surfacing the related observations.
Lloyd McKenzie (Apr 04 2019 at 14:53):
When you query a DiagnosticReport you get only the DiagnosticReport instance unless you ask for something else using _include or _revinclude. What gets included is driven by the specific _include or _revincludes you ask for. Alternatively, you can just navigate the links and query additional information as needed. So if you want to grab all associated observations and not all observations are referenced by the DiagnosticReport, you'll need to query like this:
[base]/DiagnosticReport?[some criteria]&_include=DiagnosticReport:result&_include:iterate=Observation:has-member
Bret H (Apr 04 2019 at 15:20):
@Lloyd McKenzie so the FHIR server which ingested the report will need to be able to have tracked the has-member relationships so that they can reconstruct the path to the related observations. You're not expecting that the FHIR server will use the instance of the Diagnostic Report that it received. Right? I am thinking of systems where the FHIR server is only a layer for communication to some non-FHIR architecture on the backend (e.g. a SQL database). In this case the query has to be implemented to follow the relationship. The receiving system will need to have tracked the links in the Diagnostic Report and the links in the observations...Does this sound right? with an incoming diagnostic report, my system could 'store' the reference to the observations. But when my server was queried, I would have to follow the referenced observations (and if I had not already received them from the system which sent me the Diagnostic Report, I would have to request the observations) and follow the references in those observations (again, if I had not received them as part of the transaction that contained the report, I would need to resolve the references by requesting the observations from the original sender). From this, my server would not know about the indirect observations, until trying to return a response to the query, if I only stored the direct references in the Diagnostic Report. Seems to be an implementation consideration.
Bret H (Apr 04 2019 at 15:45):
by implementation consideration, I mean that as an implementer I need to decide what works best for my system. I.e. does my system follow all links when ingesting a Diagnostic Report or only the immediate links in the Diagnostic Report.
Lloyd McKenzie (Apr 04 2019 at 15:57):
Right. That's true with everything in FHIR. When you receive an AllergyIntolerance, do you query the provider who created it or the encounter it was created as part of? When you receive a dispense, do you query the prescription it was based on? The prescription that prescription was a renewal of? The medication dispensed? The RelatedPerson who did the pick-up? Whatever you don't query now, you need to either store the links for or be prepared to re-query and traverse links later if you decide you need to know more.
Mullai Murugan (May 09 2019 at 01:01):
All, this was very helpful and has clarified our implementation path; we will only include the panel observations in the DR and not the members of the panels.
Larry Babb (May 09 2019 at 11:35):
I do have a closely related question to this...
In the same light as above, do Observation.derivedFrom[] items get treated the same way as Observation.hasMember[] items? In other words, are the derivedFrom items in an observation transatively presumed to be "results" of the DR at the top-level of Observation chaining through hasMember(ship)?
If not, then I should I presume that if a single Observation is derivedFrom two other Observations, then the two "derivedFrom" items need to be directly associated as "results" for the overarching DR in which the top level Observation is?
Lloyd McKenzie (May 09 2019 at 15:43):
It's fine to "deriveFrom" Observations that are not part of the same report. As an example, a study done 3 years ago might have identified a variant. Today, you might make an Observation of a pharmacogenomic risk that is "derivedFrom" that original variant Observation as well as new domain knowledge.
Larry Babb (May 13 2019 at 14:23):
Thanks @Lloyd McKenzie , that makes sense in regards to deriving an observation from one that was reported elsewhere. But what if the lower-level results that I'm deriving from are a product of the assay being reported, then do I have to explicitly point the DR at each of these low level observations as "results" on the DR? Do all these sub-observations need to be referenced by a "result" pointer somewhere?
Lloyd McKenzie (May 13 2019 at 14:38):
The DR can be organized as a hierarchy - so if DR points to Observation A and Observation A 'hasMember' Observation B, then the DR is considered to include Observation B.
Larry Babb (Oct 18 2019 at 11:58):
@Lloyd McKenzie I have the following situation...
DR has a result Observation A, which has member Observation B.
Observation B is derivedFrom Observations C and D.
Now Observations A, B, C and D are all outcomes of the tests that were performed to fulfill the serviceRequest that produced the DR. They are all useful bits of information to the ordering physician's system. Observation A is dependent on Observation B directly to provide the additional results needed to complete the larger outcome that Observation A represents. Observations C and D were used to derive the concept and result that is Observation B.
I'm trying to get better clarity on the difference between hasMember and derivedFrom. I'm trying to understand if these are aggregation (whole-part) concepts or are they simple associations. In my example B cannot exist without C and D and it feels like an aggregation (whole-part). This is why I used "derivedFrom". C and D can exist independently like parts in an automobile engine, where B is more representative of the "engine" made up of various engine parts.
On the other hand, Observation A is more of a grouping situation where I want to assert an Observation (A) that "gathers" and "uses" (or depends on maybe?) other Observations (just B in my example, but it could be multiple or none). Observation B (and it's parts C & D) are concrete results from the process of performing the tests associated with the Observation (A) group and the encompassing DR. This is more of an organizational approach.
As you state above, the "results" for DR are both the direct DR.results(Observation) as well as the DR.results(Observation).[hasMembers(Observation)*].
(*repeat for any level of Observation.hasMembers nesting)
So my questions are:
1) Are Observation.derivedFrom references also considered results for the encompassing DR? (my assumption is no, since you stated above that we can derive Observations from Observations in other external sources such as pre-existing DR.results.
1a) If NO to #1 above, should I assume that Observation.hasMembers are NOT allowed to point to Observations that were created outside the scope of the DR (external sources, like other DRs)?
2) Do derivedFrom Observations that are a result of the DR services, need to have some association to DR.results or Observation.hasMembers in order to be properly represented in the FHIR messages and thus properly handled by ingesting EHR systems?
3) If you could compare/contrast derivedFrom with hasMembers associations a bit more to help illustrate how to properly apply them, that would be helpful as well.
Thanks again for the incredible support.
Kevin Power (Oct 18 2019 at 13:47):
I know Lloyd is great source of info, but this might be a better question to direct to #Orders and Observation WG ?
Lloyd McKenzie (Oct 18 2019 at 14:03):
Agree w/ Kevin. However, my interpretation is as follows:
- the same Observation can, in some cases, be a 'memberOf' more than one panel. It doesn't happen often, but it is allowed. Main difference is that derivedFrom only makes sense where the referencing Observation has a value of its own. A "panel" can't be derived from other observations because it doesn't have a value that could be derived. On the other hand, if the Observation does have a value, then typically, you would be asserting that the value is based on the referenced Observation. If instead you want to convey something that didn't directly relate to determining the Observation value but was still performed as part of making the observation (e.g. calibration tests), then you might still use memberOf for an Observation that has a value.
Larry Babb (Oct 29 2019 at 18:00):
Thanks again.
emerge will NOT have direct references from the DR.results to observations that are indirectly linked through the hasMember or derivedFrom associations of any sub-observations that extend down from the primary DR.results.
This is what I gathered from the information you've provided above. If this is not correct please let us know.
Last updated: Apr 12 2022 at 19:14 UTC
