Stream: genomics
Topic: RNA fusions and additional annotations
Dustin Miller (Nov 10 2021 at 22:15):
Hi. I am new to FHIR and our team is looking to use the FHIR standard for some of our data. The variant reporting guide looks like it follows what would be found in an annotated VCF. However, we have some RNA fusion data as well. I'm wondering if anyone has handled RNA fusions? If so, how have you done that? Would including breakpoint information require extensions? Also, we have more specific annotation information as well that is beyond the Variant reporting implementation guide. How are additional annotations (those that are beyond the variant reporting guide) handled? Any help or guidance would be appreciated.
Bob Dolin (Nov 10 2021 at 22:37):
@Dustin Miller , @May Terry is doing a lot of work on this, but I'll defer to her on where things stand
Bret H (Nov 10 2021 at 22:43):
Take care to make sure that RNA fusion data imparts that the observation is from RNA sequencing. But given that the clinical oncology (not research or business intelligence) use case is typically ephemeral it's perhaps not as critical. Assuming you're talking about RNA fusion data from tumor specimens....
Kevin Power (Nov 11 2021 at 18:10):
Dustin Miller said:
... Would including breakpoint information require extensions? Also, we have more specific annotation information as well that is beyond the Variant reporting implementation guide. How are additional annotations (those that are beyond the variant reporting guide) handled? Any help or guidance would be appreciated.
In short, we deliver most annotations in the Observation.component list. I would certainly recommending reading up on that as you start learning. Our slices (how we constrain and code the annotations) of Observation.component are open, meaning you can deliver additional annotations as components, even if we don't have something in our IG as a placeholder. To deliver additional annotations, you can determine the 'question' by finding an appropriate code use as Observation.component.code, and then deliver the 'answer' in Observation.component.value[x].
If you have anything you can share on those additional annotations you are thinking about, we would welcome the input!
Bret H (Nov 12 2021 at 17:51):
You could even make a branch of the IG and propose a new component....It depends a great deal on how you want to represent the RNA fusion itself. For example, from RNA seq data do you send the composite reads, or specific reads that are used as evidence for the event? Do you just send the identity of the 5' or 3' gene that has been mapped to., or some basic exon references. Frankly, I prefer to think in terms of splicing events when we're talking about RNA fusion data - it will make it easier to extend to representing transcriptional data. The regions expressed in terms of exons. But there are non-spliced RNA species that could someday be needing to be represented as well. So, we can't fully stick with a model that just says Exon5 to Exon 8 but somehow we should indicate something closer to what was actually observed (the read based composite sequence). Perhaps a model that focuses on positional data with molecule type could be used.
if you're interested, this is similar to the approach needed with antibody or probe based method definitions. Each region of a gene has specific function within in a protein - for example look at p53 splice variants, some are more benign then others even when p53 levels overall are up. The antibody or probe target can be described in terms of position (relative to a reference sequence for short-hand) on the specific molecule type.
final comment. RNA data is always ephemeral, subject to conditions at the moment of capture, compared to DNA data. So, please, please do not allow folks to report as genomic (DNA) data - even if in oncology the RNA data is being used to infer evidence of chromosomal changes. This is my biggest worry in some of the terminology I have seen used.
PS RNA editing events are another type of event that will eventually be reported. As well as numerous post-translational modifications on proteins and base modifications on DNA. Maybe we have reached a point where we can't ignore the more esoteric events found in labs. IF we get out ahead of them perhaps it'll give labs a good way to report them that they can adopt when they start reporting?
Dustin Miller (Nov 30 2021 at 21:31):
Thanks for the feedback and recommendations. Sorry I didn't get to your messages sooner (I thought I was going to get emails indicating that people had responded to the thread). I like the idea of using Observation.component. That may help prevent having to create and publish so many extensions. One of the things I'm having issues with is we have a bunch of different information we want to represent. For example, patient identifier information, tumor tissue information, therapy option information (what treatment options are available based on variant info), DNA variant info (ref allele, alt allele, etc.), structural variant data (from RNA, including Fusion info such as breakpoints, # reads supporting fusion, etc.), and CNV information (such as copy number, fold change, etc.). It's just a hodgepodge of information where there doesn't seem to be a great way of representing it all using the FHIR standard. @Kevin Power would you be willing to provide an example of how to implement Observation.component along side other variant information that is already part of the IG?
Kevin Power (Dec 01 2021 at 14:59):
@Dustin Miller I would first say of the data you mentioned, we already have homes for much of it. So I would start with a review of our IG, especially the Variant profile, plus the DiagnosticImplication and TherapeuticImplication profiles. For Variant, we are actively working on some better documentation for how to use Variant, you can read a preview here:
https://build.fhir.org/ig/HL7/genomics-reporting/branches/variant-component-groups/sequencing.html
Regarding examples, we have many so you can start here:
http://build.fhir.org/ig/HL7/genomics-reporting/artifacts.html#9
The description of each is fairly good, so you can review the ones that are Variant observations.
From there, if you have additional values to send as components, you can review the rules set out in the base Observation resource, which you can find by reading this page:
http://hl7.org/fhir/R4/observation.html
Basically, you would just add a new item to the list of components, and at minimum, identify a code and some sort of value.
Feel free to continue asking questions here as you experiment!
Bret H (Dec 01 2021 at 16:28):
Kevin Power said:
Dustin Miller I would first say of the data you mentioned, we already have homes for much of it. So I would start with a review of our IG, especially the Variant profile, plus the DiagnosticImplication and TherapeuticImplication profiles.
fyi the Therapeutic implication is for "therapy option information (what treatment options are available based on variant info)"
the there are CNV components for "CNV information" in the Genomics IG
The current published version is STU1 from 2019 Nov. The CG WG balloted a new version this past year and it should be published early 2022. To find all the versions (not branches) go here: http://hl7.org/fhir/uv/genomics-reporting/history.html
But the new guidance in https://build.fhir.org/ig/HL7/genomics-reporting/branches/variant-component-groups/sequencing.html branch is soon to be incorporated in the version which will be published in 2022.
Up shot, you'll want to use the continuous build to guide your work, but know that the CG WG group will be merging changes over the next couple of months. The changes can be subtle and tend to be about guidance but there are some component changes which are on track for STU2 (the early 2022 release).
Dustin Miller (Dec 01 2021 at 17:52):
Thanks @Kevin Power and @Bret H for pointing me to these useful documents. I'll go through these in more detail and ask questions as they arise.
Arthur Hermann (Dec 01 2021 at 18:02):
Hello @Dustin Miller . Are you able to share with us what organization you are with?
Dustin Miller (Dec 07 2021 at 22:26):
@Arthur Hermann, sure, Intermountain Healthcare.
Last updated: Apr 12 2022 at 19:14 UTC
