Stream: genomics
Topic: Observation Searching + returning groupers
Hayden Bader (Mar 15 2021 at 14:34):
After some additional discussion, I'm thinking that instead of groupers organized by variant, I think what I really should be asking for is that groupers be organized to represent a single result. The goal and benefits to doing this would still be the same - it should help organize the various Observation profiles into something that I think would be easier to parse.
I also want to go a step further. For each genomics result, could we return only the grouper? In other words, on a Diagnostic Report, I feel the result element should be populated with one grouper for each result and not the many observations that would be members of the grouper. By extension, I also feel that if a search over Observations is intended to grab information about genomic results, it should just return groupers. I'd think that searching on observation.category = genetics would meet this condition.
Can we do that?
@Jamie Jones @Kevin Power Any initial thoughts?
@Daniel Rutz @Rachel Kutner
Kevin Power (Mar 15 2021 at 17:10):
Hayden Bader said:
After some additional discussion, I'm thinking that instead of groupers organized by variant, I think what I really should be asking for is that groupers be organized to represent a single result. The goal and benefits to doing this would still be the same - it should help organize the various Observation profiles into something that I think would be easier to parse.
@Hayden Bader - Sorry if I am missing something obvious, but can you expand a bit on what you mean by 'a single result'?
Kevin Power (Mar 15 2021 at 17:15):
Hayden Bader said:
I also want to go a step further. For each genomics result, could we return only the grouper? In other words, on a Diagnostic Report, I feel the result element should be populated with one grouper for each result and not the many observations that would be members of the grouper. By extension, I also feel that if a search over Observations is intended to grab information about genomic results, it should just return groupers. I'd think that searching on observation.category = genetics would meet this condition.
We did discuss something similar early on. From my recollection, the intention of DiagnosticReport.result[] was to include a reference to all results that are part of the report. The definition of DR.result[] does leave some room for interpretation:
http://build.fhir.org/diagnosticreport-definitions.html#DiagnosticReport.result
Definition
Observations that are part of this diagnostic report.
Requirements
Need to support individual results, or groups of results, where the result grouping is arbitrary, but meaningful.
Comments
Observations can contain observations.
The WG (at least so far) has not been willing to make the Groupers a required part of the spec as you are hinting. Not to say we can't, but it would come with its own set of challenges.
Hayden Bader (Mar 15 2021 at 18:30):
@Kevin Power To your DiagostiReport.result comment - it looks to me like we don't really obey that in some of our current examples. http://build.fhir.org/ig/HL7/genomics-reporting/Bundle-oncologyexamples-r4.html - (DiagnosticReport at the bottom only refers to groupers - not also the pieces that make up the groupers).
What I'm envisioning is the same structure but a different purpose behind the grouper - essentially where each piece is intended to relate to the others logically. For example, a grouper be used to help organize information pertaining to Warfarin sensitivity in a PGx context. There might be a therapuetic implications + some of the observed DNA changes represented as a haplotype / variant / several variants / etc.
To put it in more concrete terms - I think what I mean by a single result might be something like a single variant obervation + a single clinical implication which together inform a clinician about a patient's health within a specific context. Now, I wouldn't want the grouper to BE the result - it would just need to group the pieces of information that logically make up that concept. Notably, this makes the assumption that the implication is inherently linked to the variant observation. Which kind of assumes a situation where "This implication was observed..." with nothing else backing it up actually doesn't mean anything at all (it needs a context).
It sounds like philosophically that idea is something FHIR also wants a better handle on. (It sounds like there may be some review of this in O&O's next Monday meeting).
Kevin Power (Mar 15 2021 at 19:35):
Hayden Bader said:
Kevin Power To your DiagostiReport.result comment - it looks to me like we don't really obey that in some of our current examples. http://build.fhir.org/ig/HL7/genomics-reporting/Bundle-oncologyexamples-r4.html - (DiagnosticReport at the bottom only refers to groupers - not also the pieces that make up the groupers).
Yea, I wish I could say all of our examples are right on. But it is also possible I am overstating the DR.result[] requirement. As I noted, the actual definition seems to leave some room. And of course, our DR profile says everything can be referenced but is probably silent on what SHOULD be referenced.
Thanks for you other comments, I certainly see where you are going. I do think O&O should guide us in that space.
Bret H (Apr 01 2021 at 12:59):
@Hayden Bader @Kevin Power see "derived from" to provide context to Therapeutic Implications. We already have Therapeutic Implication to relate genetic findings that refer to warfarin sensitivity using derived from. As an example of how relating variant findings to results can be accomplished and searchable without grouper.
Bret H (Apr 01 2021 at 13:01):
additionally what would you do with: Risk Assessment?
Hayden Bader (Apr 01 2021 at 14:32):
@Bret H
I don't have a great feel on Risk Assessment - it really hasn't come up in my other discussions.
@Rachel Kutner @Daniel Rutz any ideas about how Risk Assessment might fall into the modeling we've talked about?
I also think we're talking about "results" slightly differently. From the perspective of a test that informs on what variants a patient has a "test result" might be that we saw variant X and that means Therapeutic Implication Y.
Those could be two Observations that can be represented in FHIR separately (with Y being derivedFrom X to hold onto that meaning), but maybe should not be separated clinically - as both would typically be considered when looking at the context of a patient's health. However, it may be that others think these are separable or could be modeled that way - which I think would be closer to what you're talking about here.
Bret H (Apr 01 2021 at 14:48):
That is the test result. However, the theraputic implication and variants observed are distinct. You can reuse the variant observed (germline variants anyway) but the Therapeutic implication has a time-of-life due to the ever changing nature of knowledge.
Hayden Bader (Apr 01 2021 at 14:52):
That's fair, but I would think it even more useful in that case to have something that more organizes/represents "this is what I found because of this variant" as opposed to "there was a therapuetic implication associated with a variant"
Bret H (Apr 01 2021 at 14:54):
I like the discussion. Hope I am clarifying, the variant is the top level in the current design but you would rather the critical clinical communication be the top level?
Hayden Bader (Apr 01 2021 at 15:02):
My interpretation so far of the current design is that any Observation can be top level right now - no matter how important. This might usually be variant, but from this conversation sounds like it would really have been a Therapuetic Implication. But I would rather that a more structured approach be top level - which would essentially be the critical clinical communication at the top level.
Bret H (Apr 02 2021 at 01:55):
And that's where conversations get complicated. Some experts want it all, some say they just want the variant, some ignore the lab regurgitation of information from knowledge bases knowing that they can always look it up. The FHIR structure is not necessarily about interpreting importance but about consistently organizing information in a reasonable model, or so I tell myself.
Lloyd McKenzie (Apr 05 2021 at 15:16):
We can only standardize what we can get industry consensus on. Can we get universal agreement on what's "important"? Will that be consistent across the various use-cases for sharing genomic information? If not, then we can't really dictate how organization will occur. Keep in mind that groupers aren't necessarily strictly hierarchical. The same observation can appear beneath multiple groupers. You can also have groupers that group other groupers...
Hayden Bader (Apr 05 2021 at 16:43):
Sorry, let me rephrase that. I think I used "important" poorly here. I think I also got a little off track.
In our use case, the minimum viable amount of information in a result would be a Variant Observation and a Diagnostic/Therapeutic Implication Observation. On a DiagnosticReport, these could be represented in a "flat style" where each individual Observation is a "DiagnosticReport.result", but is not as easy to map which Observations are related without digging into each one, which impacts performance and scalability.
Now, groupers aren't supposed to convey meaning on their own, but if we recommend people organize the data this way it will make relating the relevant Observations to each other easier. This has the additional benefit of being more intuitive to human users, but I think the most important benefit is the one to scalability.
Lloyd McKenzie (Apr 05 2021 at 17:11):
Unless we can dictate what labs do here, it seems unlikely we could get consistency, which means you're going to have to write code to handle navigation without he groupings being in place - or at least without them being organized the way you might wish.)
Arthur Hermann (Apr 05 2021 at 19:52):
@Jamie Jones @Kevin Power @Patrick Werner ..this is an important discussion. Can we bring it into one of our meetings in the near future?
Last updated: Apr 12 2022 at 19:14 UTC
