Stream: genomics
Topic: query variants in a specific region
Patrick Werner (Jun 04 2019 at 15:23):
discussion started in the call:
Bret H (Jun 04 2019 at 15:31):
There was some discussion in Jan's connectathon (i'll try to track down the chats), but essentially this question leads to a discussion of operations and handling of data in implementation of a server. E.g. my server might ingest observations for height in cm but always provide height in mm. Or to put another way, my server might ingest distinct HGVS but be able to provide aggregated variant results. This does require a bioinformatic calculation. I would argue that the calculation is inevitable in genomics and we can use operations to let implementers of FHIR know that they need to consider the bioinformatic calculations when implementing. Thoughts?
Bob Dolin (Jun 04 2019 at 15:36):
We have a PGx use case - upon order entry of a medication that has a drug-gene interaction, we query a genomic data server for variants in the related gene. In the response, if no variants are found, we need to differentiate between [1] region was studied and no variants were found; [2] region wasn't studied. We had been using the region-studied profile, with an observation value of 'negative' for case [1], and 'unknown' for case [2].
Jamie Jones (Jun 04 2019 at 15:46):
We were thinking you could attach an Overall Interpretation with "Inconclusive" on the DiagnosticReport
Bob Dolin (Jun 04 2019 at 15:48):
I suspect we need a more granular approach, for when the queried region covers subregions that were / weren't studied. I was thinking of experimenting with a component of the region-studied profile
Jamie Jones (Jun 04 2019 at 19:05):
Okay, so the idea then would be to return multiple regionstudied profiles classifying the callability of the subregions of the region queried? Would they each 'hasMember' the relevant findings?
Bob Dolin (Jun 04 2019 at 19:08):
I was thinking that inclusion of hasMember links would be too much overhead (and not sure I'd use it). Also, trying to come up with a design that avoids the need for hundreds of regionStudied profiles. One idea might be to have a single regionStudied profile that identifies itself as 'no call regions', and then just include all the no call subregions in some type of compact list structure.
Jamie Jones (Jun 04 2019 at 19:10):
Yeah I worry about hasMember too, but I know Bret was a fan of it in January for the simpler use case...
Bob Dolin (Jun 04 2019 at 19:18):
This thread overlaps with another one: https://chat.fhir.org/#narrow/stream/189875-genomics-.2F.20eMerge.20Pilot/topic/Guidance.20re.20region.20studied. So @Larry Babb and @Mullai Murugan may also be interested. And if I could digress a bit more Jamie, I tend to think of the RegionStudied profile as a swiss army knife that can be used to annotate arbitrary regions - not just to say what was studied, but also to convey, for instance, analytic accuracy annotations. If we were to go with something like a single 'no call' or 'low quality' profile, where we want to include a potentially long list of subregions, I'm not sure whether or not FHIR currently supports any kind of compact list structure to do this?
Jamie Jones (Jun 04 2019 at 19:44):
I don't see many good options for that sort of list structure... besides DocumentRefence to a CSV/etc, which I believe was mentioned on the other thread
Jamie Jones (Jun 04 2019 at 19:51):
The LOINC definition for the code we are using for this profile (53041-0) is "A set of observations which comprise the definition of a contiguous sequence of nucleotides in the genome. This is intended for use in genetic test coverage panels in genetic test reporting."
If we are returning non-contiguous regions some may want us to update that description...
Jamie Jones (Jun 04 2019 at 19:53):
I would love for this profile to be able to annotate arbitrary regions, so we ought to iron it out if we can.
Bob Dolin (Jun 04 2019 at 19:57):
If were were able to that, I think we'd also be able to address Mullai's use case as well. Maybe it's a question for Grahame or Lloyd, whether or not there is something like the SampledData data type (https://www.hl7.org/fhir/datatypes.html#SampledData) that might work here? (I kinda shy away from CSV because you can't really standardize what the columns are).
Jamie Jones (Jun 04 2019 at 20:07):
I think the main issue with using observation.value is that it's not a simple answer to the (implied) question, "what region was studied"
Jamie Jones (Jun 04 2019 at 20:09):
The code is called "DNA region of interest" however, so we may still be able to use it but have to be clear about how and what we are annotating
Jamie Jones (Jun 04 2019 at 20:22):
In particular, I don't see much info for the region coverage component "TBD-RegionCoverage". Could this component do everything you need or do we need an additional component?
Jamie Jones (Jun 04 2019 at 20:28):
Or is RegionCoverage intended to be literal read coverage? I wasn't sure and can't find any other notes on it
Bob Dolin (Jun 04 2019 at 21:05):
Right. That's why I agree with removing observation.value, and was thinking maybe we want to come up with some additional components, that provide different types of annotations on the region in question. I believe RegionCoverage was suggested by Mullai - they have examples of reports that show the percent coverage of different regions. But there are potentially so many non-contiguous subregions, for quality annotations, for no-call regions, etc, that the main blocker in my mind gets back to how to send all these subregions in a compact way.
Larry Babb (Jun 05 2019 at 12:05):
While I agree the aim of being able to "query variants in a specific region" from the data that is shared by a lab to a clinical system is probably one of the top 10 primary use cases that the clinical and research communities hope to achieve someday. I believe this is a stretch at best based on the resources, classes and data types that we are providing to date.
First, using HGVS expressions as a basis for unpacking and computationally identifying precisely what was observed "while tempting and used quite predominantly today" is dangerous and likely a non-starter in a clinical setting (that is my strong opinion). HGVS has a dominant place in helping humans display and communicate with reasonable accuracy one of the many representations of a given variant. So I would caution folks for depending on this approach too broadly. It may work for some use cases but it should be applied with caution and based on lots of available information on the pitfalls that can lead to errors or misrepresentation of the originally observed values.
In terms of the regions studied and variant representations, both of which are critical to get right in order to be able to achieve the aim of this thread's concern, FHIR will need to eventually provide much more precise datatypes to represent Sequences, Locations, Alleles, Haplotypes, Genotypes, etc... in a definitional (non observational) form. The current flexibilities and choices for the variety of ways to represent variants within either within the broadly scoped Observation profiles and MolecularSequence Resource provides an environment to do the same thing in many, many different ways. So we will need implementation guidance merely focused on all the ways to properly and consistently apply these Variant-related Observation Profiles and MolecularSequence resource to help adopters consistently share SNPs, inDels, CNVs, Hapl, Geno, Comp Hets, Structural variants, etc...
The most fundamental issue that should be addressed well before we start solving how to use these super flexible forms of variation is to separate the Observational from the Definitional forms of the data. I would strongly recommend considering how to align with the GA4GH genomic knowledge standards variation representation efforts that are just now piloting a specification and roadmap for the datatypes that could greatly reduce the complexity in FHIR genomics data sharing as well as provide consistency such that computational and precise sharing and use can be achieved.
Sorry I don't have anything to directly contribute to helping solve this region studied and observation.component extension potential plan for providing a fairly fragile architecture for determining how to query variants in specific regions using the existing profiles, extensions and resources in FHIR, but this is precisely the kind of design that begs for better datatypes to represent the definitional components needed to support sound bioinformatics use of the data.
Lloyd McKenzie (Jun 05 2019 at 13:09):
One tool you do have available to you is Operation. If the answer to a question can't be determined from a simple element match but can be determined by the complex interplay of several elements in the target resource, Operation can be used to do that. (The tricky question is how to appropriately index to support implementing the operation...)
Bob Dolin (Jun 05 2019 at 15:15):
@Lloyd McKenzie Just out of curiosity, not saying this is the way to go, but rather thinking through options, is there a way to communicate a list of integer ranges as an observation (or component) value? Some like value="1-10,20-73,114-275"?
Lloyd McKenzie (Jun 05 2019 at 15:24):
As separate components, yes. As a single value, only if you use the sampledData data type.
Bob Dolin (Jun 10 2019 at 21:25):
@James Jones If we were to go forward with a proposal for a set of GACS Operations, it could simplify the representation of 'region wasn't studied' - rather than trying to represent this in the FHIR Genomics report, we could just make it an error response (e.g. 422: Error. No data present for requested region for patient). What do you think?
Jamie Jones (Jun 10 2019 at 21:27):
Yes, I was suggesting an error response at the app level at the WGM. Could also generate an Observation with status "cancelled" (aka aborted) with a dataAbsentReason for context
Jamie Jones (Jun 18 2019 at 16:04):
Anything concrete we think we can say here before publication?
Jamie Jones (Jun 18 2019 at 16:06):
We just passed a tracker to revamp http://build.fhir.org/ig/HL7/genomics-reporting/usecases.html with our latest guidance on querying, so any updates are very appreciated (:
Bob Dolin (Jun 18 2019 at 17:15):
@James Jones I'd like to bring forward a proposal for a set of GACS Operations, after we publish the IG.
Jamie Jones (Jun 18 2019 at 19:22):
We'll be updating the the standard search parameters to R4 on that page shortly, and can mention that the need for advanced operations to meet complex querying use cases.
Bob Dolin (Dec 06 2019 at 21:02):
@Jamie Jones, @Kevin Power I updated tracker https://jira.hl7.org/browse/FHIR-25250 to link to a more detailed proposal for an $extract-simple-variants operation.
Jamie Jones (Dec 06 2019 at 21:04):
That's great! I will get it on the agenda for Monday (I do have a conflict halfway through so may miss covering it)
Bob Dolin (Dec 06 2019 at 21:18):
Thanks Jamie
Kevin Power (Dec 06 2019 at 21:38):
Good stuff @Bob Dolin - I did a quick review and added a few comments on your document.
Bob Dolin (Dec 06 2019 at 21:47):
Thanks @Kevin Power . I think your questions get at some fundamental design decisions worth considering - I can, for instance, define an operation that has a fully locked in response (e.g. just variants that have an exact-start-end, which is therefore a required component), or, I can have a broader operation, which meets more use cases, but which might then need some optionality in the response (e.g. optionally respond back with exact-start-end or inner/outer ranges or copy count, etc). I lean towards a more locked in response, where we'd just have to create other operations to accommodate other use cases.
Jamie Jones (Dec 06 2019 at 22:10):
Great to see it spelled out like this, but I do have similar questions to Kevin's comments in the doc. I'll be looking at other operation definitions to get some more context for my feedback
Kevin Power (Dec 06 2019 at 22:12):
Makes sense, and in that case it feels like we need to be more precise in the definition. Such as indicating to only return Variants when the exact coordinates are within the given range. Maybe describe the desired behavior in edge cases like - what if given range is 10:20, and the variant is a deletion from 19-23? Or an insertion of 3 nucleotides at position 9?
Jamie Jones (Dec 06 2019 at 22:14):
I'd like to keep the ideology of being as broad as possible in what it returns, and based on the reference sequence provided. In your example I would say return the first one as the variant's start position in the reference sequence is within the range, but exclude the second one.
Jamie Jones (Dec 06 2019 at 22:24):
I am also thinking it should have to accommodate the fuzzy ends. We provided 2 ways to give position and this should cover them.
I think this could be easily done by returning variants that don't have exact start-end if their "inner-start" or "inner-end" are in the queried range...
Kevin Power (Dec 06 2019 at 22:41):
The fuzzy ends option could be parameterized allowing the client to decide if they want those or not I suppose
Bob Dolin (Dec 06 2019 at 22:56):
I kinda feel like variants with precise end points should be handled differently from those with imprecise end points (e.g. separate operations). Reason is that there may be other information needed for the latter case.
As for what to return, I'd suggest we adopt conventions common to many of the Broad and GA4GH specifications, where you return variants that overlap the requested region. In other words, in the following picture, any of variants 1-5 would be returned in response to a query for variants in range x..y.
Bob Dolin (Dec 06 2019 at 22:56):
Bob Dolin (Dec 06 2019 at 22:59):
SPDI differentiates variants with / without precise breakpoints. Maybe a better name for this operation is something like $find-precise-variants.
Jamie Jones (Dec 06 2019 at 23:25):
That picture looks perfect to me, do you have a reference link too?
Bob Dolin (Dec 06 2019 at 23:33):
I drew the picture, to confirm my understanding of how tabix indexing works. I'll see if I can find some good references.
Jamie Jones (Dec 06 2019 at 23:33):
I was going to do the same, so that's great!
Are the end points in terms of the refseq??
Bob Dolin (Dec 06 2019 at 23:35):
Yes. start and end positions would both be on the same refSeq
Jamie Jones (Dec 06 2019 at 23:48):
An insertion just before the window may be a good counter example
Bob Dolin (Dec 10 2019 at 01:38):
I did a little analysis, to see the extent that return parameters would need to differ between a $find-precise-variants and $find-imprecise-variants.
First finding is that in some variant representations (e.g. VCF), imprecise variants have confidence intervals around start and end positions, and these are not currently considered in Tabix indexing. For instance, in this picture, variant 6 would not be returned in a call for variants in x..y.
Bob Dolin (Dec 10 2019 at 01:38):
Bob Dolin (Dec 10 2019 at 01:39):
Next, I tried to consider what other Variant components might be needed, and I came up with this list:
1..1 component:dna-chg-type (e.g. inversion)
1..1 component:copy-number
1..1 component:outer-start-end
1..1 component:inner-start-end
1..1 cytogenomic-nomenclature
Bob Dolin (Dec 10 2019 at 01:39):
Finally, I tried to consider some of the more complex structural variants, such as rearrangements with multiple imprecise breakends. Here's an example from VCF 4.3 spec:
Bob Dolin (Dec 10 2019 at 01:39):
Bob Dolin (Dec 10 2019 at 01:39):
Bob Dolin (Dec 10 2019 at 01:39):
Overall, I kinda get the sense that imprecise variants are sufficiently different as to warrant their own service.
Kevin Power (Dec 10 2019 at 01:52):
Thanks Bob - good stuff. I agree with all the principles at this point. Still not sure about the name “precise” though? Maybe it’s ok? What do others think?
Bob Dolin (Dec 10 2019 at 01:56):
If it helps, SPDI also refer to these as variants with known breakpoints. VCF uses Precise and Imprecise.
Jamie Jones (Dec 10 2019 at 02:30):
What fields would be different for $extract-imprecise-variants?
Bob Dolin (Dec 10 2019 at 15:12):
Hi @Jamie Jones . In this picture, the components added for imprecise are in red, and I've also tried to highlite changes to components that are there for precise:
Bob Dolin (Dec 10 2019 at 15:13):
Jamie Jones (Dec 10 2019 at 15:28):
Thanks for your thorough explanation. My main concern with splitting the operation into two is that we already lumped all variants together into one profile, so our approach doesn't feel very consistent...
$extract-known-variants sounds good to me, but would be misleading if we are lacking these outliers.
Kevin Power (Dec 10 2019 at 15:43):
Considering our state, I would still suggest we just go with the name 'find-variants', keep the scope defined for now as "Returning variants with precise and well understood start and end." If we do decide later we need a different operation for 'imprecise' variants, we can reconsider names at that point.
Just my recommendation ...
Jamie Jones (Jan 14 2020 at 20:35):
The first step towards implementing this operation is enumerating the different ways these Observations may be stored in a server to be returned.
(see http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html for latest updates of the proposal)
Before considering deriving new Observations from raw sequencing data, the suggested IN parameters for the operation naively seem to interact with the following fields in FHIR variant Observations that may be present on the server, to see if they match the search criteria:
*subject
*component:genomic-ref-seq
*component:coordinate-system = ‘0-based interval counting’
*component:exact-start-end
My understanding is that these fields could be normalized, so that a variant in the queried range but represented in a 1-based coordinate system or on a different versioned/scoped reference sequence would also be flagged and returned in the bundle.
One may additionally have to look outside of those fields on Variant, since they are all 0..1. This information could be represented via g.HGVS, c.HGVS, variation-code (e.g., clinvar), dbSNP-id. It may even possibly be opened up to variants that are only represented in terms of p.HGVS and/or transcript reference sequences (although we may have trouble determining the required genomic ref_allele and alt_allele in that case, if not populated). There is also the concern that some may use the "Build+chromosome number" approach to identifying a reference sequence.
Best practices seem to include identifying these fields and providing plain language guidance on how to approach normalizing them for the required computation or stating incompatibilities. Any volunteers??
Bob Dolin (Jan 14 2020 at 20:55):
@Jamie Jones The most effective normalization approach I've found so far is to convert everything to canonical SPDI.
Bob Dolin (Jan 14 2020 at 20:58):
Were you thinking that this discussion would go on the page that describes the operation? If so, I can add a section
Jamie Jones (Jan 14 2020 at 21:01):
We don't mention SPDI anywhere in the IG yet so a section here would be very valuable, in my opinion.
Kevin Power (Jan 14 2020 at 23:48):
Two things:
1 - Do we think this is most (only?) relevant in the 'GACS' type scenario? We will have to be careful about how many expectations we put on potential receivers of this data - many won't have the ability to perform normalization type activities. :slight_smile:
2 - I can see adding a new component for SPDI so it has a first class home in our IG.
Bob Dolin (Jan 23 2020 at 22:39):
@Kevin Power Kevin, regarding the find-variants operation [http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html], you made a comment last week in the genomics/committers channel, that by having the RegionStudied observation reflect back the query parameters, we are actually changing the meaning of the range-examined component.
It's a good point, and I wanted to follow up on it. We need to consider targeted testing, WES, and WGS; and we need to consider not only 'here's what I studied', but potentially also 'within the region I studied, these are the uncallable subregions'.
So, I think we should change the OUT parameter from this:
1..1 Observation (RegionStudied)
1..1 component:ranges-examined
1..1 component:coordinate-system = '0-based interval counting'
1..1 component:genomic-ref-seq
To this:
0..1 Observation (RegionStudied)
1..* component:ranges-examined
1..1 component:coordinate-system = '0-based interval counting'
1..1 component:genomic-ref-seq
and add more descriptive text, along the lines of:
"RegionStudied can be used to reflect back those studied regions that overlap with the query range. For WGS, the entire region of the request may have been studied and can be represented as a single component:ranges-examined. For WES, each examined exon overlapping the query range can be represented in its own component:ranges-examined. For targeted panels, each examined region overlapping the query range can be represented in its own component:ranges-examined".
In the future, if we wind up adding some type of 'uncallable-region' component to the RegionStudied profile, we might consider adding an optional IN parameter, something like 'IncludeUncallableRegions' (boolean), to enable finer granularity.
Thoughts?
Kevin Power (Jan 24 2020 at 00:56):
That makes sense to me and I think aligns well with what we are using RegionStudied for.
Jamie Jones (Jan 24 2020 at 16:23):
I think this is a great addition, and would love to see the uncallable regions included as well if we can get a vote on that soon.
Bob Dolin (Jan 24 2020 at 21:11):
Thanks @Kevin Power , @Jamie Jones for feedback. I've updated the site. I think it's ready to be presented to committee, but will follow your lead. Jamie, I'm wondering if it might help to let uncallable region move along at it's own pace, and when and if it gets added, we then propose revisions to the operation?
Kevin Power (Jan 27 2020 at 17:01):
Seems like we all got kicked out of FCC before finalizing the plan. I would propose we do NOT vote tomorrow, have some time to review (time boxed please), plan for @Bob Dolin to do some more work as discussed, then plan to vote on it in the next Tuesday call after the WGM?
Jamie Jones (Jan 27 2020 at 17:03):
Yes, we went back in and highlighted the few feedback points, need to address liftover error and scope for "supporting" this operation. (i.e., make sure we have some text saying servers MAY support this operation, separately from supporting validation of our IG's profiles).
Jamie Jones (Jan 28 2020 at 18:34):
We may want to put some of the normalization info on http://build.fhir.org/ig/HL7/genomics-reporting/sequencing.html
Jamie Jones (Jan 28 2020 at 18:36):
That page could be a lot more helpful in delineating the 4 different ways we support representing variants, and highlight manual queries and the operation there.
Kevin Power (Jan 28 2020 at 20:13):
I would agree, but don't want to hold up the Operations JIRA by working in that change as well. Considering the comments from Clem and @Liz Amos today on the call, it seems this should be something we consider more broadly? I don't know that I can even come up with a JIRA / change request for it now, but it is a topic that comes up enough that we should discuss it in more detail.
Jamie Jones (Jan 28 2020 at 20:16):
my concern here is how we should present/link to the content Bob is creating. currently he has drafted adding 2 pages and a "quick link". I think a section/link from http://build.fhir.org/ig/HL7/genomics-reporting/sequencing.html would be helpful
Kevin Power (Jan 28 2020 at 20:17):
I think it aligns with the core part of the first item in the "STU2 Themes" document: "Definitional and Knowledge versus Observationl", yes? It seems that by asking these questions, we are really asking 'how do we appropriately represent a Variant Definition?'
Kevin Power (Jan 28 2020 at 20:19):
my concern here is how we should present/link to the content Bob is creating. currently he has drafted adding 2 pages and a "quick link". I think a section/link from http://build.fhir.org/ig/HL7/genomics-reporting/sequencing.html would be helpful
It is also linked under the Table of Contents and Artifacts? @Bob Dolin what do you think?
Jamie Jones (Jan 28 2020 at 20:21):
Happy to address the content on the Variants page separately, don't need to bundle it into the proposal
Bob Dolin (Feb 08 2020 at 20:38):
@Bret H I've taken a stab at addressing the issues your raised regarding liftover (http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/find-variants.html). There's no 100% solution to lifting over a variant or a region that I could find. So, it looks like the easiest approach is to have the server lift over the query region (as opposed to expecting the server to normalize all variants against a single build), and just broaden the region a bit in the rare case that lift over fails.
Bret H (Feb 09 2020 at 04:44):
That's great work.
Jamie Jones (Feb 14 2020 at 15:17):
It is great work, thanks @Bob Dolin .
After review my only comment is we ought to provide some convenience links to http://hl7.org/fhir/operations.html and http://hl7.org/fhir/parameters.html in the text near the top, and more clearly state that we are having this operation return a single "Parameters" resource and not a bundle.
I do worry that this page is getting a bit long, and think the comments on normalization and liftover (which I admit to have personally requested) may be better suited to be stated more generally on http://build.fhir.org/ig/HL7/genomics-reporting/branches/fhir_operations/sequencing.html at some point. Happy to consider that as a separate tracker.
Lastly, the example is fantastic but the operation definition would be greatly benefited by a link to an open source implementation/test server that supports it. Is there any hope of getting a roadmap to that?
Kevin Power (Feb 17 2020 at 15:03):
I have updated the JIRA with a proposed resolution, please review.
https://jira.hl7.org/browse/FHIR-25250
Probably can't vote on it this week (sorry I was tardy in getting this update made), but we should be able to next week.
Bob Dolin (Feb 18 2020 at 18:15):
Hi @Jamie Jones , to be sure, did you want additional edits now, or should we wait until voting on pulling this into the main trunk?
Kevin Power (Feb 18 2020 at 21:35):
@Bob Dolin - Considering the still limited activity in master, I think you are ok waiting and making further changes in the branch. Looks like yours will be an easy Pull Request/Merge into master. However, the 'implications' branch will be tougher. :frown:
Last updated: Apr 12 2022 at 19:14 UTC
