Hello, everyone, and welcome to this month's ACMG Genomics Case Conference. My name is Dr. John Burnett. I'm a member of the ACMG Education Committee, and it's my pleasure today to introduce today's conference, the broadcast of the 2020 digital edition of the Genetics Counselors Luncheon and Forum on Requesting and Working with Raw Genomic Data. This activity is intended for educational purposes only. Our presenters today on the broadcast, we have Casey Genetti, a genetic counselor from Boston Children's Hospital, Dr. Jesse Walsh, an informatics specialist from the Mayo Clinic, and Dr. Matthew Lebo, chief laboratory director of the Laboratory for Molecular Medicine with Partners Personalized Medicine. Following the broadcast, we'll have a live question and answer period, but moderated by the session organizers, Dr. Charisse Marcoux, the co-director of the Genomics Laboratory at Mayo Clinic, and Marissa Ellingson, a genetic counselor at Mayo Clinic. All the presenters have no disclosures. And these are the disclosures for the planning committee members. This session is approved for one CME. Following the session, we ask that everyone evaluate the session by completing a form by visiting the ACMG Genetics Academy. And these are the learning objectives for today's session. To submit a question for the live Q&A that'll follow the presentation, please use the Q&A function within our platform. The chat function should only be used to contact ACMG staff for any technical issues. And you can prioritize a question or upvote it by clicking the thumbs up button. And with this, we'll begin the presentation. Hi everyone, my name is Casey Trinetti and I'm a research genetic counselor at Boston Children's Hospital working with the Manton Center for Orphan Disease Research. And the title of my talk today is the raw data request process. So I'm going to start off this panel talking a lot about the logistics involved with obtaining raw data. And I have nothing to disclose. So to start off with the goals of this presentation, we want to start with a general understanding of genomic raw data and why we might want to access it. We'll then spend some time talking about the logistics that are involved with obtaining, storing, and utilizing that data. We'll touch briefly on the risks and benefits for both the patient and the providers. And we'll finally consider the current limitations and needs for improving this process. So what is raw data? In its simplest terms, it's the primary data files that are generated from next-generation sequencing. The next-gen sequencing that I'll be referring to mostly in this presentation is whole genome sequencing and whole exome sequencing. But this also does include panels. I'll touch briefly on panels a little bit later, but given the more limited scope of panels compared to whole exome or whole genome, the underlying data itself may also be limited as well. Following this presentation, you're going to hear a lot more detail about the actual specific raw data file types and more details about those. But I just want to familiarize you with those names for the rest of this talk. So we'll be talking about FASTQ, BAM or CRAM files, and variant call files or VCS. And those are going in order from most raw to most process. So for the potential uses of raw data, one of the biggest uses that I work with now and what many of you might encounter as well would be the need for reanalysis of a previously non-diagnostic exome. So used for hopefully future diagnosis. Other uses for next-gen raw data would be for new gene discovery research, potentially some persistent medicine uses. Maybe from a patient perspective, you may hear that they want to access their raw data for future use or just for general curiosity. And those uses may grow over time as well. So I'm calling this figure the raw data life cycle, just to help kind of run through the process and different steps that a genetic counselor or other health care provider may encounter. It all does start with that request, then followed by whatever paperwork a laboratory may require for data release. Then we move on to storage, so where will it be kept and how will it be stored, the analysis of that raw data itself, and then ultimately the return back to the particular patient or health care provider. So as I touched on briefly, the requests for raw data may originate from a variety of sources. In my experience, there are basically three main parties. The clinicians, health care providers who ordered that testing, or other health care providers that might be involved in a patient's care and interested in their genetic testing, the patient or family themselves, as well as research teams. And while these may be three separate entities, there is certainly a lot of overlap here when we're talking about the actual use of the raw data. So an example of that may be a particular provider who has a negative exome for one of their patients coming from a clinical lab, and they may have the desire to have that data reanalyzed or reinterpreted to look to see if there could be particular changes in a novel gene that may not have been reported, or perhaps the exome itself was done several years ago, and they're hoping to have that reinterpreted. Just as we know, the analysis pipelines are constantly being improved over time, and we're learning about new genes every month. So they may reach out to a research team, either at their institution or somewhere else, who may have experience with exome reanalysis or interpretation. And so there, it kind of involves all three parties, both the patient, the provider, as well as the research team. Understanding not only who wants the data requested, but what the ultimate use is, is really important to our next step, which is actually determining the correct paperwork for requesting that data. So is that data going to be used and stored solely by the providers who are taking care of that patient, so kind of keeping it in the clinical realm? Or is it going to be utilized by a researcher or a research platform that may have some other underlying requirements there in terms of how that data is released? So the first step, after determining who actually wants the data, is to identify the laboratory in question and determine what their data release policies are. So things that are important to ask are what files are available for release? Does the laboratory prefer to release the FASTQ or the most raw data? Do they release their data in the form of a BAM or a CRAM, which is a condensed form of that BAM file? Or are they only releasing the variant call file? How long will that be available? Is it something that the laboratory keeps for an indefinite amount of time or however long they have to due to their particular storage standards? Or is it something that there's a finite amount of time where an individual or a provider can request that data? And then the next question is what type of paperwork is required? Who needs to sign that paperwork? Are there multiple forms? Is there a fee for release of that data? How is the data going to come to you? Etc. So there's a lot of questions that can be asked to a particular laboratory. And one thing I should note is that every single laboratory is going to have different paperwork and different processes for how they're going to release that data. Right now we don't have a set of guidelines or standard way that laboratories are handling this. And so they're kind of forced to make up those policies on their own. And it's conversations that involve legal teams and customer service and bioinformatics teams and platforms. So each laboratory has a different way of doing things. And so it's important that as a genetic counselor who may be helping to really organize this whole process, that you're pretty much reaching out to these laboratories every so often. Especially if you're dealing with them over time to determine if paperwork has changed. This is a static process for the laboratories as well. So they may be updating paperwork and you don't want to waste your time filling out paperwork that may now be obsolete. So there should definitely be a back-and-forth conversation with whatever laboratory you're working on. That paperwork as well, the preparation for signing that paperwork and getting it sent out is going to be different based on who is requesting that data release. So just to start off with the provider. So if it's one of the clinical health care providers, some laboratories may have a policy that they can release directly to that ordering provider without any additional signatures. Many laboratories do allow data to go right back to the provider, but they may also require that all sequenced individuals also sign a release. So that means, you know, not just one signature from the parent for the release of the trio. That's both parents and then a signature on behalf of the proband as well. And same goes for if the patient themselves would like to have the data released or their family. The provider is actually not typically required in these instances. Many individuals may request the data from the laboratory themselves and this is typically released to them kind of under the HIPAA guidances. But laboratories again may require or typically require that all sequenced individuals are consenting to this release. They may have additional requirements as well in talking to some of these laboratories. I've seen the request for verification of identity, so needing to send a copy of a driver's license or something like that. Now all of these kind of factoids here are just a compilation of what I've learned from talking to a variety of different laboratories in preparation for this presentation, both academic and commercial labs. Every lab is going to, you know, have their different specific policies, but through those conversations, these are some of the main points that I came across that some shared. And then there's also release to research. So if a patient is enrolled in a research study, whether that's on their own or through one of their healthcare providers, it is possible to release the data directly to research. Some laboratories require a separate consent for that process. Others require the same consent that they use for a release to a provider. Again, often requiring the signatures of the patients themselves. More laboratories these days are allowing the release of data given a research, an actual signed research consent. That is certainly something that's worth, if you're part of a research study that's looking to request data on a fairly regular basis, it's worth a conversation with the laboratory to see if your actual research consent has the appropriate language for them to be able to release data to you, or if you could add some language into a consent form that would allow for that, just to save on paperwork. So the storage itself. This is oftentimes something that is most intimidating, at least from my point of view, about how to store that data. It may come back from the laboratory in a variety of forms, on a physical flash drive or hard drive, through a secure file transfer portal, or some other form of portal set up by the laboratory. So it's important to determine how that's going to be and who is going to be responsible for downloading that information. Once you have it, how will it be stored? Obviously security is important here, and it's oftentimes an important conversation, perhaps with the IT department at your hospital, as to where the best place to store this information is. Is there a secure server that can handle it? Is there cloud storage that might be available for genomic data? Where are you going to store an actual hard drive if you receive it? So physical storage is an important aspect as well, as well as backup storage. And with all of these things, there's a question of security. Will the data be labeled with PHI, or will it be de-identified? And what is the size that you're going to be dealing with, and what are the size allowances for whatever platform you might be using at your given institution? All right, so once we have that data requested from a laboratory and stored on a given server or cloud or platform, there is the all-important step of analysis. A couple talks from now, you're going to hear about a lot more detail of the various tools and pipelines that are available for variant analysis. So I'm not going to go into detail here, but as someone who might be organizing this process at your own given clinic or research study or institution, it's important to remember that there are various tools and pipelines out there available to the public space, but your institution itself or local research teams may also have additional resources. So that's some advice that I have would be to kind of reach out to others, maybe on your team or an adjacent team, who may be able to help as well with different areas of analysis. It's also important to distinguish between clinical and research. So if this is part of a research study or a clinician would like a research team to assist in the analysis of raw data, there's definitely additional considerations that need to be made about patient consent and whether an IRB protocol might be required. And anytime you're dealing with a research study who's going to be interpreting this data or even just the clinical team, it's important to remember what types of results the patient is expecting and what they consented for. So did they consent for those incidental findings or not? And there should be a plan of how you will handle those. And we'll talk about the return process as well. And then finally there's timeline. It can be really important to have a realistic communication with either the other providers or the patients themselves on what the timeline for reanalysis might look like, you know, who's going to be doing it, how often might it happen. These are all things to kind of take into consideration when we're thinking about working with raw data. And then finally the return. So once the raw data is released from the laboratory, they are no longer responsible for what might be identified in that data. That's a really important disclaimer that you'll see on a lot of laboratory paperwork. A variant call file that's coming from a lab may show many, many, many, many variants that are picked up in that data, but those are not confirmed variants. The only genetic changes that should be considered confirmed for a laboratory are the ones that they actually reported on that clinical report. Those are the ones that have been vetted by their team, they have been potentially confirmed by an orthogonal method. The rest of the variants on the VCF file are not, and therefore there being maybe false positives or, you know, many benign variants as we all know. So the raw data itself shouldn't be considered as CLIA certified. Once it leaves a laboratory, it is no longer a CLIA piece of data, and so the results that someone may uncover or new variants should be discussed with a relevant provider and confirmed by a clinical laboratory. So a new finding shouldn't just be returned to a patient and placed in the medical record, it should still go through that process of being confirmed by a clinical lab. And clinical labs will offer a variety of methods for reporting such variants, and again it's a conversation that can be had back with the lab that did the initial testing. They may offer a full whole exome or whole genome sequencing reanalysis where they may pay particular attention to the variant that you're calling to their attention. They may be able to do just a directed look back at their data for the particular variant that you have in question, or they may ask that you actually order a variant for specific confirmation. So potentially just a separate Sanger sequencing test for them to be able to then go through their CLIA process and issue a new report. So I know we've touched on a lot of things pretty briefly, but some important considerations overall. When we think about this raw data requesting process, especially as genetic counselors who may be the first individuals who are talking to a family or patient about this, we want to make sure we're respecting patient autonomy while also being transparent about limitations. So we may find ourselves talking to families who are very eager to obtain that data themselves, and even without maybe particular plans to use it. And so we want to make sure we're respecting that as their right to have access to the data, but also guiding their understanding of what this data is, how it can be used, and what are the different pipelines and storage and things to talk about with them that they may not really have a lot of familiarity with. We want to be limiting false positive results. Again, that goes back to this confirmation process, making sure that any new variants that are found in the data interpretation are fully vetted before they're utilized in someone's health care. We want to assure proper consent, whether that is consent to a research study that may be using the data, or just individual consent for that actual release of the data, making sure that all individuals are understanding what's going on and have provided their proper consent for the release. And in general, as you can see, a lot of this presentation was about considerations and questions that you should ask yourself when dealing with raw data. And there's not a lot of guidelines out there. So there's really a need here for consensus guidelines, both to help laboratories with how they should be handling these requests and releasing this data, but also clinicians to learn about, you know, what they have available to them, what they should be doing if they've interpreted data and found a variant themselves, and also for researchers. And with this whole process, the line between research and the clinic can become blurred. And so having guidelines to really direct us with raw data use, I think would be something that's very helpful for this community. So I hope that this was a kind of helpful speed run through the raw data request process. And I think in the following presentations, you're going to learn a lot more about the data itself and what to do with it. But I just want to say a quick thank you to my team at the Manton Center, who has taught me a lot about this request process and is doing a lot of great work with reanalysis of negative exomes. I'd also like to thank at Boston Children's Hospital, our research computing center, who's been really fantastic and helping us work through a lot of these struggles with genomic data storage and analysis, as well as the wonderful laboratory colleagues who spoke to me on the phone and talked to me about all of their policies and help put this together. So thank you very much. Hi, my name is Jesse Walsh, and I'm here to talk about the raw data file types associated with the next generation sequencing assay. First, I would like to declare that I do not have any financial disclosures to make. With that out of the way, let us begin. As a brief overview, I have several goals I would like to touch on during this talk. First, I will introduce the typical NGS variant discovery workflow and the major data types produced for each run. These data are stored as computer files. I will discuss FASTQ files, SAM, BAM, and CRAM files, as well as VCF and VCF files. By the end of my talk, I hope you were able to answer the following questions. First, how can these files vary by lab? Looking specifically at variations for each file type and how these can affect usage and interpretation. Second, in what situations would each file type be most appropriate? Third, I will briefly discuss considerations for the reproducibility of results. And finally, I will talk a bit about some of the supporting file types you might encounter when working with NGS data. One thing you'll hear constantly when working with NGS data is that the data files themselves can become very large. One of the easiest ways to mitigate this problem is through file compression. If you've ever heard of zipping a file, then you already know what I'm talking about. Compression doesn't change the contents of a file, it just encodes it in a way that causes it to take up less space on a hard drive. One very common compression tool, gzip, works generally well in many file types. We know when a file has been gzipped with the .gz file extension. For example, when a FASTQ is gzipped, it becomes a FASTQ.gz file. Some file types have specialized compression formats available which work better than the generic gzip tool, but only for that specific file type. For example, SAM files can be compressed to become BAM files. A newer tool can compress the SAM file even smaller into what we call a cram file. These cram files can be up to 75 percent smaller than even a BAM file without losing any information. Similarly, a VCF can be compressed to a VCF, although you'll often see VCF files compressed with the generic gzip tool to make a vcf.gzip file. You can consider the compressed and uncompressed versions of these files essentially equivalent and interchangeable. As you know, the goal of clinical sequencing is to read a person's DNA and hopefully find mutations that explain a phenotype and inform actionable treatment plans. The process involves many people and specialities, but for today I'm just going to ignore the chemistry and the sequencing steps so that I can focus on only the bioinformatics portion of the workflow. There are many competing tools and pipelines that can be used in the workflow, but broadly speaking, the typical NGS workflow will take read data as input and produce a set of variant calls as output. Let's consider GATK, one of the gold standards in DNA small variant calling, as our example. You can see marked in light gray some of the file types that are generated during this process. For the moment, don't worry too much about all the steps in the workflow. We'll come back to that in a minute. I just want you to take note that the workflow begins with a FASTQ in the top left box and ends with a VCF in the bottom right box. FASTQ files contain read data, where each read represents a small piece of the DNA sequence of an individual. Paired end sequencing is usually represented using a separate file for each end of the read. Each read in a FASTQ has an ID line that starts with an at symbol. The next line is the familiar ACTG nucleotides of the read, followed by a spacer line, and finally, the encoded base quality scores produced by the sequencing machine. Each base in the sequence line has an associated quality score on the quality line. Notice that at this point, all we have are unmapped read fragments. We don't yet know what part of the genome these reads map to. We don't even know which reads will be useful for our future analysis. This is why we consider FASTQ files raw data, in the sense that very little processing has been applied. Something to note when working with FASTQ files is that you may have one or more FASTQ files per sample, typically two files for every lane on the sequencing flow cell. If you have paired end data, it is important not to lose track of which two files represent a paired read, which is usually represented in the names of the file. BAM files take the reads from a FASTQ file and map them to a location on the reference genome. BAM files have a complex format with many options, so it's certainly likely that the exact information here will vary between labs and will depend on the tools used to produce the BAM file. But at a high level, you can think of a BAM file as essentially the same read and quality information as a FASTQ file, but with the position information and alignment information added in. Be aware that alignment is dependent on a specific reference, such as the HG37 or HG38 reference genome. In this very simplified example, you can see that BAM files require a header to describe the contents of the file. You can also see how the read information from the FASTQ file still exists in the BAM file. One reason this is important is that it means you can extract the original FASTQ back out of the BAM file in case you want to realign the reads to, say, a different version of the human reference genome. It also means that the BAM files will be roughly equivalent in size to the FASTQ, although this can vary with compression efficiency. A VCF file is used to store variant calls that were generated by the NGS pipeline. Like the BAM file, the VCF format is complex and has many options that will likely vary by lab and reflect the tools used to create the file. A VCF file is essentially a list of chromosomes and positions followed by a description of the variant call using the reference and alt columns. The genotype column gives the predicted genotype of an individual for this particular variant. Note that multiple individuals can be combined into a single multi-sample VCF. The info and format columns are often used to annotate the variant and summarize the read information that supported this variant call. But notice, we no longer have any read or alignment information. The VCF format keeps the decision, i.e. the variant calls, and some summary statistics, but discards all the evidence, i.e. the reads, that were used to make this call. If you want to keep the read data, you would need to keep a copy of either the FASTQ or BAM files used to generate this VCF. I have already alluded to ways in which BAM and VCF files can vary due to their complex formats. But here's where it's worth taking a closer look at that workflow diagram. Notice that several versions of the BAM and VCF files are listed in this example. And this is because there are various filtering and processing steps performed on these files in order to improve results. And it can be very hard for an outsider, even with bioinformatics expertise, to know exactly what steps are involved in creating a particular file. FASTQ files may be filtered or trimmed. BAM files may have recalibrated quality scores. VCF files may have applied hard filters or other cutoffs. And often, the only way to know is to ask. If it is so difficult to know exactly how a file is processed, then how can we know which file type will be most useful to us? But here, I think the answer is actually fairly straightforward. If you understand what files represent, then you likely already know what you're looking for. The basic principle is that files that are more raw, such as FASTQs, tend to be more flexible and allow you the option to perform your own analysis. The downside is that raw data requires significant bioinformatics resources to process. While files that are more processed, such as the VCF, provide more value in the sense that the expertise and computational resources to generate high-quality variant calls have already been done. But of course, the downside is that a lot of assumptions have already been made, such as which reference genome to align to or what cutoffs to use when reporting variants. If you disagree with these built-in assumptions, your only option is to rerun the analysis. I wanted to step back from the high-minded concerns about value and flexibility for a moment to address the very practical concern of dealing with large file sizes. Here, I provide some anecdotal values for the sizes of FASTQ, BAM, and VCF files for whole XM and whole genome data. Obviously, these values are highly dependent on sequencing depth and compression, but they should serve to give you a rough sense of scale. Especially for whole genome data, file sizes can be prohibitively large. Just to pick on a more extreme example, consider a request for both FASTQ and BAM data for a whole genome sequencing run. If we are talking about a family trio and each member of the family has 100 gigabytes of FASTQ files, 120 gigabytes of BAM files, this could take six 120-gigabyte flash drives. I mean, if each one of these is $18 and you need six of them for a consumer model, that's a lot of data. On the other hand, if you're only requesting a VCF file, which is maybe less than one gigabyte for a whole trio, that's comparatively trivial in size. Now, you might say that requesting both FASTQ and BAM files is redundant and wasteful, why bother? And in general, I agree with you, but that does bring me to another concern I'd like to address, and that's reproducibility. The problem with reproducibility is that we can often assume that workflows are deterministic. If you put the same FASTQ in, you'll get the same answer every time. And while that may be true, in some cases, it's not. Sometimes you can put the same FASTQ in with a different workflow, you'll get a different answer. Same FASTQ with different parameters in the same workflow, you get a different answer. You modify the FASTQ even slightly, not changing the data, but just the order of the data in the same workflow, sometimes you get a different answer. And it can be very difficult to explain these differences. This is a study in which the authors compared eight different aligners using eight different simulated FASTQ sets. And because these FASTQ sets are simulated, they know exactly where the reads came from and what the alignment should have been. And you can see on the x-axis, we have our eight different FASTQ sets. On the y-axis is the number of misaligned reads in thousands. And there's a pretty obvious difference in the performance. Different tools are giving different answers even though it's the same data. And this is just one example of how differences in tooling and different assumptions can change the output. And it may be that these differences aren't terribly interesting. They might just be difficult regions to map and the aligners are slightly off in their alignments. But there again, as my point, it's very hard to tell how relevant these differences are. In the previous example, we showed how different aligners can give different answers. But just to give a more holistic example, this is an unpublished study where we compared two different aligners, GWAMM versus NovaLine. NovaLine used three different parameter sets. So we had four different alignments. And you can see in the lower table how using these four different aligners, we got four different answers, four different numbers for the number of SNP calls. And the difference between them is relatively small. It's only about 400 SNPs between the highest and the lowest. But again, we know why this happened. We used different aligners, but it's very hard to know how significant this is. And it very well might be that none of those would have been clinically significant in this case. It's just hard to know. But this is one argument for why you might be more interested in the more processed data sets. So if you're requesting raw data and you ask for the VCF, you're probably looking at the same thing that was analyzed in the original assay. Whereas if you try to redo the analysis yourself from BASC-Q, unless you choose everything exactly the same way that it was originally done, you will probably get a different answer. And that might be insignificant clinically, but it's really hard to know. It's really hard to understand why you got that different answer. The last thing I wanted to talk to you about today are secondary files. Now you may encounter these when you're working with other NGS data types. And they're not actually NGS data, they're just supporting files performing some function or another. So the first file type is a checksum file, which is often a .md5 file. And this serves as a fingerprint. It lets you know if the file that was sent to you is the exact same file that you have currently. And you know this by comparing the checksum file that the sender has to the checksum that you have. If you get the same checksum, the files are exactly identical with no differences at all. Index files are another file you might encounter. These come in different extensions, but they're essentially just files that help tools process NGS data more quickly. They're convenient, but they're easily replaced, so they're not very important. But these include things like .bai files for the index of a BAM or .idx or .tbi files, which would be the index of a VCF or VCF.gz respectively. I'd just like to take a minute to acknowledge my colleagues at Mayo Clinic, the Clinical West team, Drs. Marteau, Drs. Kearney, the Bioinformatics team, Dr. Klee, Dr. McClellan, and so many others. They've been very helpful and very supportive of my work. And I'd like to thank them all. Thank you. Thank you for listening today. My name is Matt Lebo from Mass General Brigham Personalized Medicine. I'm gonna be giving an overview for genetic counselors and other providers on tools and tips for analyzing raw genetic data from clinical genomic testing and lab tours. Hopefully you've already had a chance to listen to the wonderful prior talks in this session. I'm Cassie Gianetti and Jesse Walsh. And this session is really gonna be expanding beyond what they had already mentioned. So first of all, I have nothing to disclose. The objectives of the talks really are to learn about some of the software tools available for analyzing raw genomic data. We wanna understand some of the caveats, issues, pitfalls, et cetera, that one may encounter when reviewing raw genomic data outside of a clinically validated environment. This is important because oftentimes what labs give you back, as you have heard, is raw genomic data and has its own caveats and considerations. Finally, we wanna be able to assess, access, and use the most relevant tools for staying up to date with genomic information, and really giving some of the most critical tools, I think, that are out there today for really understanding variant interpretation and understanding the genomics from your patient. So considerations before you even start analyzing raw genomic data. So very critical in doing this is understanding the genomic build that the data was generated or mapped against. So for NGS data, you end up mapping and aligning your raw reads to particular genome builds. Most clinical labs are still using Build 37, but many research applications actually default to Build 38. And so it's actually very important and critical to understand which set of tools you're using and then how your data is provided to you by the laboratory because the coordinates for each individual variant will be different and you will not be able to map them appropriately. Second consideration is transcript level. So most clinical labs are using RefSeq, many research labs are using Ensembl, research applications are using Ensembl. So really understanding the differences between RefSeq and Ensembl is critical in understanding when one maps to one transcript versus another one can have important considerations as well. It's also very important to know different standardizations that are out there. So for nomenclature, you have HEVS. HEVS is a great resource for really trying to define exactly how you should refer to a variance, make sure there's consistency between different laboratories, different groups, different publications, whatever it may be. You also have much more current work going on the transcript level. So Maine is a tool between Ensembl and NCBI, really trying to provide primary transcripts for RefSeq and Ensembl and things that match and are consistent between the two of them. And finally, for gene names, you have resources like Hugo. Gene names, unfortunately, change more often than you would like. And so making sure that you actually have the current gene name is oftentimes critical to do. And again, I sort of mentioned this already, but it's important to remember that raw data is raw data. So the data that you're getting will include false positive variant calls and low quality sequencing reads and regions. You need to be aware of this and sort of considering that some of the data that you may be getting that maybe look interesting when you're first identifying, it may actually not be real and therefore not relevant for your individual patient. So some first steps to do when receiving raw data. So depending on the file type you get, whether it's a FASQ or VAM or CRAM file, a VCF, potentially VCF and a VAM or CRAM file, you may have different paths that you should do. So really, if you're getting a FASQ or just a VAM or CRAM file, you really should call it bioinformatician. And I don't necessarily mean it's a joke. I think it's really important to realize that there's not that much useful information you can get just out of a VAM file or a FASQ file. The reason is there's a lot of computational tools that are necessary here. And most of the resources that you have don't actually accept these as inputs unless you're sort of buying a system that is used within one of these clinical laboratories. Most often the tools that you're gonna be looking at and interpreting are really variant based. And so therefore, if you're getting back a VCF file, the next step really is to do is annotate and potentially filter on that VCF file. So these are some software tools for annotating, filtering these variants. So most of them we'll take in the VCF file. Some of them, the bottom three here are really ones that you would download and run yourself. And so having some sort of my repetition help may be useful there. The top ones are ones that you can run online. And I think some of them you actually can download. The important consideration for running things online is you need to make sure that the patient actually consented for you to be able to do this because these things are not HIPAA compliant. So I'm just gonna use the first one, VEP, to take you through sort of what you might see in some of these tools as you're running them, some of the settings that you may wanna be considering selecting. So first one, again, critical is to ensure that you're using the right genome build. So here, making sure that you're actually pointing to build 37, VEP actually defaults to build 38. So the data you're getting is build 37. You need to actively make sure you're switching to the build 37 website. You also have the ability to select which transcripts you're returning. And so you may wanna just write RefSeq. You can do RefSeq and Ensembl. There's different ones that you may be able to do, but it's important to remember to select the one that you actually is most critical for here. And again, since most clinical labs, at least in the US, are using RefSeq, that's an important one to consider grabbing. Also, you wanna make sure that you're actually getting the HEVS nomenclature out of these tools. And so sometimes there's an option that you need to select. Sometimes it comes by default, but it really is important to make sure you're selecting the proper things. And again, gene symbol, transcript version, that sort of thing is important as well. Some tools may oftentimes actually provide these sort of functional pathogenesis predictors and silico tools, whatever you might wanna call them. Most clinical labs do not rely on them heavily or weigh them heavily when they're interpreting variants. They have some utility in sort of prioritizing variants potentially, but just be aware that it may just add a lot of superfluous information that is hard to interpret. So you may or may not wanna include them. A lot of the tools also allow you to do some filtering. So you only get out variants that they think are interesting or variants that meet a certain frequency threshold. Sometimes this can be important and interesting. One of the most useful ones is to sort of maybe remove anything that is really common in the population. So you don't actually get a lot of variants that you have to look at. So it does filter down the set of variants you're looking at to a much smaller set. So some of the caveats in annotation filtration, I had mentioned some of these already. One, again, they're not clinically validated. And so you have to be aware that these really are research applications. And so you do need to sort of take some of them with a grain of salt. They may get updated frequently, especially using the web-based ones and some bugs may get introduced, but just be aware that there may be some nuances around that. Also, as I mentioned, for tools that run via a website and not ones that you're running internally, do you need to be aware of sort of patient consent and deposition of data and sort of what you have, the ability to upload a patient VCF file into these tools. Phenotype filtration or prioritization, they're not perfect. A lot of these tools will allow you to do it by phenotype. But again, this is sort of not necessarily been validated and it may have its own issues. You also want to be aware of sort of hard filtering versus prioritization. So hard filtering removes the variants, you don't even get to see them. But prioritizing based on phenotype will just bubble up the ones that they think are relevant to the phenotypic features that you put in. There's also, I mentioned computational prediction tools are not necessarily clinically validated either and don't necessarily work great. You should use more of a guide. I will say they predict benign variation much better than pathogenic variation. And so if you want to sort of use it to maybe downgrade something, it may be better doing it that and sort of upgrade. And variant nomenclature isn't always standard. So even the reports back in HCBS, it may have some discrepancies, maybe using an older version of HCBS. So if you really want to make sure you're using the most up-to-date version of HCBS, you should use a tool like Mutalizer, which is a great resource for sort of doing HCBS checking. You can do it based upon genomic coordinates, based upon a VCF file, based upon the outputs that you get from one of these tools and it will sort of map it to what the current HCBS nomenclature is. Finally, again, you're including raw data here. And so these tools are assuming every variant you're giving it is real and don't necessarily do filtering on varying quality. So it may include some of these false positive calls that you got from raw data. And so one thing that we oftentimes do or people may oftentimes do is sort of visualize, try to visualize the reads here. So if you happen to get back the BAM files, you can use a tool like Integrated Genomics Viewer to actually look at the read level information. IGV is a great resource for looking at the raw NGS reads. You can run it on the website or download it and run it on the computer. It actually works very great running it locally on your computer. The variants information will be colored by default and there are additional settings provided to color and sort reads to help spot potential issues. So this is an example of what I was saying. Here's the variant calls on the left. You see the C change. About half the reads have the C, half the reads have the wild type. This is indicative probably of potentially a true call. You can see that the allelic fraction is 50-50, especially when we're looking at germline variants, you're expecting it to be a 50-50 or a 100% variant. You'll see there's some other additional variants here that actually don't have that sort of allelic fraction up here or that are sort of seem really skewed. And actually in IGV, if you hover over up here, you can actually see a little bit more information on the variant. Here, and I apologize for this being so small, but you may be able to see that these reads or these variants are actually called at a very low allelic fraction, where only 12% of the reads have the variant. In the germline world, again, you're expecting this to be closer to 50-50. So this is one thing that you sort of may be suspicious of. And one thing we oftentimes do is you may want to actually take a step back and zoom out a little bit. And when you do that, you'll look at the same region, and this is sort of the variants that we're looking at. You'll see there's many, many more variant calls within this region, many more than you may be able to expect. This is actually indicative of potentially a false positive region, region that has difficulty mapping, might have a pseudogene issue. Another way to look at sort of variants that may be false positives, you'll actually see maybe a spike in coverage. Well, this could be due to an insertion event or something like that. Oftentimes, especially in conjunction with all these variant calls, is potentially due to sort of a pseudogene issue. So once you've sort of reviewed technical variants, you want to get into assessing those variants. So one of the first resources that people oftentimes look at is sort of a population frequency estimate of the variants. How common is the variant in the population? Variants that are more common in the population are obviously less likely to impact for disease. So one of the tools that we use, and that I think a lot of labs uses is NOMAD. So NOMAD is a large data set of excellent genome data, especially for population frequency. The population frequency is also available by ethnicity. And they're now providing lots of additional annotation tools that are useful at both the gene and the variant level. First thing about NOMAD, you need to make sure you know which genome version you're using. So they just recently launched one that's based on BILT38, which is version three. Version two and prior are based on BILT37. So you really want to, if you're using BILT37, make sure you're selecting the BILT37 transcript. They also provide, like I said, some tools such as constraint for determining how sort of functionally constrained different variant types are. But if you are not seeing loss of function or missense variants in your protein, it may be indicative of them actually having a pathogenic role. And they recently added some expression level at the exon level. So you can identify exons that seem to be much more poorly expressed. And finding a variant in one of these exons maybe would indicate that they're not necessarily potentially as relevant as a variant in a more highly expressed exon. They also provide information at the variant level. One important thing is you'll see there's flags for variants that are passing or potentially failing. This is actually the variant that we were looking at before that have really high pseudogene issues, especially in the genome data. You'll see that there is discrepancies in the allelic frequency between the exons and the genomes because this is a variant that actually has issues on the genome side of things. Additionally, you'll see the additional population level frequency information down below. Other resources to sort of understand sort of the pathogenicity of variants, the main tool that a lot of people use today would be ClinVar. ClinVar is a repository of classification from different sources, typically from clinical laboratories, research laboratories, some expert panels, and some sort of more publication-level evidence. Because these are all individual submissions, they actually can have conflicts, and they actually provide different levels of detail. One thing ClinVar does, though, is sort of provide an overall interpretation based on the individual classifications. In this instance, you'll see that there is conflicting interpretations for pathogenicity, with some labs calling it likely benign, some calling it pathogenic, and some calling it variant of uncertain significance. But you have the ability to actually dive down and see the individual laboratory data. And you can see, again, that some labs provide much more level of detail and evidence than other laboratories do, and really provide the rationale for why they classify this variant. And those are the ones that you may oftentimes end up reading through, because they really provide the literature support behind why they classify that variant. ClinVar also provides additional filters that are useful from the search criteria. So if you're searching for a specific gene, you'll get a list of variants that come out. You can then do different things, like filter out molecular consequence by pulling out the only frameshift or nonsense variants. You can make sure that you're only looking for variants in a single gene. So a lot of these you'll see as CNVs, and you really might want them to be a certain gene. You can also do it based upon the clinical significance, or whether it's reviewed by an expert panel. So these allow sort of quick filters at the gene level to sort of get down to what types of variants are typically seen or classified as pathogenic in genes. So in addition to ClinVar, ClinGen is another resource for providing interpretation tools. One of them is the allele registry, which provides unique representation of variants, helps avoid ambiguities. So if you're really concerned about whether your variants are the same as in other literature, this is a resource to make sure that all variants are mapping to a single record. And so you actually can understand that two different variances that may look different actually are the same variants, and it gives you sort of added confidence if you're looking and reviewing this. Potentially even more important is their pathogenicity calculator, which allows for evidence gathering. So really it allows an individual to apply the ACMGM guidelines, to understand working through these guidelines, how you add literature, how you add sort of the different changes and nuances that are happening here. And so this is a great tool for actually evaluating and interpreting specific variants, but to identify variants of interest that you may want to go further with and evaluate. Finally, it is a lot of work, obviously, to do this, to sort of review individual variants. This is why sort of clinical laboratories are doing this. So one of the things that is also important to consider is sort of doing this in a more of a community-based setting. And one of the ways to potentially do this is something like matchmaker exchange. So this is a resource for sharing phenotypes and genotypes, which aid in discovery. So you can have multiple connected nodes from different institutions that sort of are doing searching within the nodes, but also across the nodes to identify people that either have similar phenotypes or similar underlying genomics or potentially both. And really what it does is allow for identification of matching visuals for ultra-rare diseases and really identify if you have a patient that has a really unique phenotype, there's not really many things to say about it. In the lab, there's no genes sort of annotated against it. It's really much more of a variant discovery that you can identify other individuals that are like your individual for seeing if there's underlying similar genetic variants that are potentially underlying the disease. All right, some final thoughts. They're, again, varying quality in terms of the tools and resources and how often these tools are kept up to date. Tools that we're talking about today are not clinically validated and may not be, are usually not HIPAA compliant. And so, again, you need to make sure you have the proper consent for using some of them, especially if they're online. There are other tools out there that I did not mention that are used to analyze and interpret direct-to-consumer data that will take an exome and genome BCS, but often these use information that is less clinical useful, even if it looks pretty. It may have less clinical validity. They are definitely not well vetted and may contain a lot of false information from the resources that they're pulling in, and so really should be taken with a grain of salt. But the most important thing may be that labs do offer reanalyses and variant reinterpretations, and the provider here can use these resources that I've talked about to sort of track interpretations versus vicious variants using things like ClinVar or MathMaker Exchange, and then communicate to the lab when a finding may be relevant. And really, this should be a joint effort between the lab and the provider and the GC or clinician. So with that, I'd like to thank everyone for listening today. I want to acknowledge some of the other geneticists within our lab who helped review the slides and think through them. I met other individuals at the lab for micro-medicine. And again, thank you so much, and I hope you enjoyed the session. Hi again, this is Casey Giannetti, and we will now be presenting you with a couple of case vignettes to finish up our panel here, collected from various sites from our panel. And the first case we'll talk about today is a nine-year-old male. His main phenotype was global developmental delay, microcephaly, a collection of dysmorphic features, strabismus, a history of aspiration and muscular hypotonia, gastro reflex, and hypersomnia. And so for testing, he had a clinical trio whole exome sequencing in 2015, which came back as negative with no candidates. So his providers decided to enroll him in a research study for a reanalysis of that data, and the trio was reanalyzed through a research pipeline in 2018. Now the reanalysis result came up with a de novo frameshift variant in the gene PPMID, and that was associated with Janssen-DeVries syndrome, which the phenotype associated is global developmental delay, ID, hypotonia, a collection of dysmorphic features, gastrointestinal difficulties, myopia, and strabismus. So when this was found by the team, obviously this clinical description of Janssen-DeVries fits very well with what we knew of the child's presentation. And looking a little bit further into the variant itself, here we have a depiction of NOMAD, and you can see on the bottom right there is a collection of ClinVar pathogenic variants that are all located towards the end of the gene, and our variant fell right here in between that collection or hotspot. Now why was this gene missed previously? It was actually not reported until April of 2017, meaning when this exome was initially done in 2015, it would not have been a gene that showed up as a disease-causing gene in OMIM. And so this just kind of highlights the importance of reanalyzing data, particularly cases that were resulted probably prior to when labs were more consistently reporting out candidate genes or genes of uncertain significance. And so here we were able to identify this particular variant, and that was a very close fit with the patient's presentation, and then ultimately have his clinical team weigh in and be able to confirm that in return. For our second case, we have another example of a good use of reanalysis of raw data. This is a 12-year-old female with contractures, joint pain, arthritis, corneal clouding, and a valvular heart defect. The differential diagnosis for this case was lysosomal storage disease, skeletal dysplasia, mucolipidosis, and peripheral neuropathy syndrome. And the patient underwent clinical trio whole exome sequencing in 2017. And a heterozygous variant was reported in the ARSB gene. It was a BUS, and that gene is associated with autosomal recessive mucopolysaccharidosis type 6, or maritolame syndrome. And the patient had, of note, reportedly negative biochemical testing that would have ruled that disorder out. Additionally, a heterozygous variant of uncertain significance was reported in the CHST6 gene, which is associated with autosomal recessive macular corneal dystrophy. And given that there was no second hit in either of these genes, the case was considered to be unsolved. So this case was also referred to research for reanalysis. And the patient's BAM file was reviewed by the clinical team, and it was discovered that the patient, in fact, had a second variant in the ARSB gene. The second variant had not been called and was not part of the VCF file that had been used for the patient's clinical whole exome test. And although the newly identified ARSB variant was also classified as a BUS, this now meant that the patient had compound heterozygous variants, and the suspicion for a diagnosis of maritolame really increased greatly. The research finding was reported to the clinical laboratory, who performed Sanger sequencing to confirm the variant and amended the whole exome report. And the new results were then reported to the ordering provider who could do repeat the biochemical testing, which then supported the diagnosis of maritolame. The patient was subsequently started on enzyme replacement therapy, and her symptoms improved. Further inquiry into why the second variant was not called on the original VCF revealed that the calling.bed file did not include all exomes of this gene, and this resulted in gaps in the coverage of the coding sequence. And this is an example that exemplifies the importance of understanding the regions that the exome is covered in each laboratory's testing algorithm, and also the utility of reviewing the raw data, the BAM file, not just the VCF. And in this case, it resulted not only in solving the case, but also in identifying a treatment for the patient. So we hope that both of these case examples give you all a little bit more context into the utility of reanalyzing exome data, whether that is due to potential shortcomings in what the laboratory is able to see, as well as the changes over time that can be really helpful in analyzing data. All right, so I'll invite our presenters and panelists to turn their cameras on, and as we're assembling, I'll just reintroduce everyone. We're joined with Casey Gennetti, Genetic Counselor from Boston Children's Hospital, Dr. Jesse Walsh from Mayo Clinic, and Dr. Matthew Lebo from Partners Personalized Medicine, as well as our session organizers, Dr. Charisse Marcoux from Mayo Clinic and Marissa Ellenson from Mayo Clinic. So I'll turn the Q&A over to Dr. Marcoux and Marissa. Thank you, Dr. Burnett. The first question that we have in the Q&A looks like it's for Dr. Walsh. Why would the VCF file size from WESS or even WGS be so much lighter than the BAM or the FASTQ file size? Okay, so the VCF file does not contain the read information, and it's really that read information that's making the other file types so much larger. So if you're thinking you have 151 base pairs per read and millions to hundreds of millions of reads, that adds up quite a bit. The VCF only contains the variant calls, and that's why it's smaller. Perfect, thank you. And the second question I believe is also for you, Dr. Walsh. Could you advise on the application of BED files and how to produce them? That's an interesting question, and it could get fairly complex. So a BED file in its very basic form is a description of regions. So it's three columns, it's a chromosome, a start, and a stop. These can be used for many different reasons. For example, you might want to filter variant calls to only the exon region and a small padding around that. As far as creating them, these BED tools is probably your best friend, but they can be created in a simple spreadsheet. It's just chromosome, tab, start, tab, stop. Okay, great, thank you. Our next question is for Casey. When surveying the various labs, what file types are they releasing? It's multi-part. Are there labs that are only releasing certain types of files, and did you get a sense for how different labs interpreted what is included in the designated record set under HIPAA? That's a great question. That's a great question. So it really did vary from lab to lab. I'd say most commonly, it seems like labs are releasing the BAM or CRAM files and the VCFs. There are certain labs who would also release the FASTQ. I did not encounter many labs that are only releasing the VCF, at least here in the US. There are some international labs I'm aware of where their default is the VCF. There may also be differences, though, in terms of what their default release is and then what they're willing to release if someone were to request, say, a FASTQ when the default is the BAM and the VCF. I didn't end up touching on the laboratory's definitions of that designated record set, so it's an excellent question, but I'm not sure the answer there. Thanks, Casey. The next question is for Jesse. Thoughts on storing UBAMs instead of FASTQ? Sorry. UBAMs versus FASTQ. I'm less familiar with the UBAM format, although I know that is not always available. I believe it's probably one or the other. All right. Thank you, Jesse. Okay, and then the next question that just came in, do you have advice about the ideal timing of a reanalysis, thinking about the first case scenario where the gene of interest was published two years after the initial sequence? Casey, I think I'll direct that one to you, or Dr. Lebo, if you'd like to chime in on that as well. Sure. I'm happy to start with that one. Generally speaking, it's helpful to do that reanalysis a little ways out. However, that doesn't mean that the data can't be requested sooner. The data files themselves aren't going to change. It's just that analysis process that might be more beneficial once more time has passed. It's more about just understanding those limitations, but maybe Matt can comment on the actual request of maybe having a clinical lab do a reanalysis and how long you might suggest to wait there. Yeah. It really depends upon how emergent the gene or the phenotype might be. The lab would need to have enough time to find new evidence, either with other laboratories in the literature or in places like ClinVar for it to really be useful. I think, as I mentioned in the talk, when you go use tools like Matchmaker Exchange, and you actually have additional information that you may be able to even present to the lab about new findings, I think that's one area where it might be more useful to do it sooner. Then the other one is, as Cassie presented, when you have a single finding and maybe the other finding is a CNV or something like that, that you have a way to look at that, or the lab has new methods to look for CNVs, that might be another reason to do it a little bit more sooner than normal. I definitely wouldn't recommend sooner than a year, and even that is probably not going to find much in most instances. Perfect. Thank you. One more question that just came in here. I had a family request the raw data from their exome, but when provided with BAMs, they were dismayed they couldn't open the files. I recommended that they partner with a researcher for reanalysis. What would you recommend in this scenario? Dr. Lebo, I'm thinking maybe you're the right person for this one. Yeah. That would be my answer as well. I think it's important, if you're doing this, to really have an understanding of what the patient or yourself might be able to do with the data. Most times, you need to have some level of expertise to still either even just look at the files or do any of the downstream analyses and more interpret them. It's oftentimes useful to have some research collaborator or a fellow who's interested in diving in deeper, or someone like that who has some bandwidth to do it and some interest or some expertise in doing it. Otherwise, it just might sit there and collect dust. I think it is helpful to have that lined up, if possible, or to have resources where they can point to for people who might be able to help them. Another question came in. This is for Dr. Walsh. In your presentation, you mentioned multi-sample VCFs. How does that complicate returning raw data if an individual does not consent to release? Do you recommend that labs provide this information up front, depending on the file types they are agreeing to return? That's a great question. As a reminder, a VCF file can contain the variant calls for multiple individuals. It is possible to split the VCF file into separate parts so that each file only has a single individual, but you do lose some information in the process of doing that. It's obviously easiest if you can get consent from everyone who's involved, and then you can provide the entire file in its complete form. Whether or not you're willing to do the splitting and release individual files, I think, would be up to specific labs, but certainly be careful about maybe any cross-contamination of that information that might be left residual in the headers and such. Thank you. Another question that just came in. Can you talk about copy number variants a little bit? What databases are available to check against for known pathogenic variants? I think that's one for maybe Dr. Lebo. Sure. We don't do as many C&D-level analyses, but there are definitely new guidelines that have come out from ClinGen and ACMG looking at how to interpret C&Vs, and I think those are great guidelines to look at and do touch on a lot of the resources that you would use. But there are things like Decipher that sort of is a good resource. ClinVar actually has a lot more information on C&Vs now. It's a little hard to find them, but they do because they list like every gene and not necessarily the breakpoints, but that also is a good resource that labs are starting to put more C&V information into. And then ClinGen does have information on some C&V stuff, especially around the capital insufficiency and that type of information at the gene level. Thank you. Okay. We've got one more question here. I'm not sure who to direct this, so anyone who knows the answer, feel free to jump in here. Is it the ACMG guidelines that we have to rerun the VCF files after two years? Does anyone know? Is we in reference to clinical laboratories, or is that? I think so. Not sure. Yeah, I'm not, I should, if that's probably directed to me, I probably should know if I actually don't know. I mean, I think it's a, it might be a suggestion. It's not like a mandate, but we can, we can follow up on that one though, for sure. Sounds good. I'll look into it. All right. I think I want to thank all of our panelists, presenters, and moderators here for the excellent discussion today and just have a few quick closing slides here. So to remind everyone, the call for abstracts for the 2021 ACMG Annual Clinical Genetics Meeting is now open. You can go to www.acmgmeeting.net. The next edition of the Grand Rounds for the Undiagnosed Diseases Network will be held on January 14th, and you can register for this at udnconnect.org slash Grand Rounds. And thank you again to all the panelists, and thank you for attending today's Genomics Case Conference.

raw genomic data

next-generation sequencing

reanalysis

gene discovery

patient access

consent

analysis tools

variant interpretation

visualizing raw reads

collaboration