16417 results for "Cheap fc 26 coins Buyfc26coins.com is EA Sports official for FC 26 coins Easy process to get fast coins..JPBo"

in 20.02 milliseconds.

• How to upload GPG files

  Uploading files Users that holds an ega-box-XXX account can upload files using either INBOX or FTP. Users who have a Submitter role associated with their email will only be able to upload files using INBOX. Before uploading your files please make sure that any files that will be uploaded to EGA do not use special characters in their naming convention such as # ? ( ) [ ] / \ = + < > : ; " ' , * ^ | &. This can cause issues with the archiving process, leading to problems for end users. The EGA is a shared, public service with limited storage. In order to manage the available resources, we enforce a limit of 10Tb per submission account at any one time. Please do not exceed this limit. INBOX FTP The FTP is only compatible with files encrypted using the EGACryptor tool Before uploading Once your submission files have been prepared using the EGAryptor, the resulting encrypted files and associated md5sum files can be uploaded to your submission account using Aspera or FTP. The EGA is a shared, public service with limited resources. In order to manage the available resources, EGA submission boxes should not exceed 8Tb in size, and cannot exceed 12Tb. If you are approaching this limit please contact contact EGA Helpdesk so that we can advise on how to register the associated metadata and trigger the archiving of files, so that you can continue with your submission. If we note that your submission account increases above 10Tb on a consistent base your password will be changed until metadata is associated. Aspera Download Aspera Using Aspera FTP FTP windows FTP Linux / Unix FTP client (Filezilla) FTP and TLS Troubleshooting Troubleshooting Aspera Download Aspera is a commercial file transfer protocol that may provide faster transfer speeds than ftp especially over longer distances. The Aspera ascp command line client. Please select Aspera Connect. The ascp command line client is distributed as part of the aspera connect highperformance transfer browser plugin and is free to use, without registration. The minimum required version of the IBM Aspera Cli is V4. Further instructions. Using the Aspera ascp command line program The location of the ascp program in the filesystem: Mac: on the desktop go cd /Applications/Aspera\ Connect.app/Contents/Resources/ there you'll see the command line utilities where you're going to use ascp. Windows: the downloaded files are a bit hidden. For instance, in Windows 7 the ascp.exe is located in the users home directory in: AppData\Local\Programs\Aspera\Aspera Connect\bin\ascp.exe Linux: should be in your user's home directory, cd /home/username/.aspera/connect/bin/ there you'll see the command line utilities where you're going to use ascp. Your command should look similar to this: ascp -P33001 -O33001 -QT -l300M -L- /path/file ega-box-N@fasp.ega.ebi.ac.uk:/path If you wish to upload several files without being requested the password, please use the below command : ASPERA_SCP_PASS=ega-box-password ascp -P33001 -O33001 -QT -l300M /path/file ega-box-N@fasp.ega.ebi.ac.uk:/path/ Explanation of parameters l300M option sets the upload speed limit to 30MB/s. You may wish to lower this value to increase the reliability of the transfer. L option is for printing logs out while transferring files to upload can be a file mask (e.g. '/homes/submitter/*.srf) or a list of files. ega-box-N is your submission account login. Add k2 switch for transfer restarts Check the command line transfer usage for more configuration details. Using FTP to upload your prepared files Use your preferred ftp client. For example, lftp is a popular choice for Linux and Mac users. Use binary mode for file transfers. Use ftp.ega.ebi.ac.uk as the target host. Login with your ega-box username and password. Upload files to your private ega-box upload area. Depending on your network setting you might wish to start FTP in passive or active mode. Using default FTP command line client in Windows Start the command line interpreter: press WinR, type cmd, hit enter Enter ftp ftp.ega.ebi.ac.uk Enter your submission username Enter your submission password Type binary to enter binary mode for transfer To see a list of available ftp commands type help. Type ls command to check the content of your submission account. Type prompt to switch off confirmation for each file uploaded. Use mput command to upload files: mput *.bam* Use bye command to exit the ftp client. Use exit command to exit the command line interpreter. Using default FTP command line client in Linux / Unix Open a terminal and type ftp ftp.ega.ebi.ac.uk Enter your submission username Enter your submission password Type binary to enter binary mode for transfer To see a list of available ftp commands type help. Type ls command to check the content of your submission account. Type prompt to switch off confirmation for each file uploaded. Use mput command to upload files: mput *.bam* Use bye command to exit the ftp client. Using FTP client FileZilla We recommend the use of FileZilla, a free FTP client . FileZilla is open source software distributed free of charge under the terms of the GNU General Public License. Use the following connection details (File - Site Manager) and add yoursubmission account username and password: Using FTP client FileZilla Select the files you wish to upload and then select upload: Using FTP client Filezilla Using LFTP with TLS We recommend the following to force the use of a secure connection. lftp > set ftp:ssl-force yes We also recommend setting the following for not encrypting the bulk data itself for performance reasons (theauthentication will still be encrypted): lftp > ftp:ssl-protect-data no In order to verify the certificate,the recommended way would be to use the CA certificates from your machine. To do that use this command in lftp adjusting the path to your ca-certificates location. lftp > ssl:ca-file "/etc/ssl/certs/ca-certificates.crt" If that is not possible or certificates are old and you can't update them, you can download the certificates needed from Quo Vadis Digital Repository The two certificates to download in PEM format are: QuoVadis Root CA2 G3 QuoVadis EV SSL ICA G3 Then you can concatenate them in a file one after the other and save it as lftp-certificates.pem Once this is done you have to point the ssl:ca-file variable to the path lftp > set ssl:ca-file "/path/to/lftp-certificates.pem" Also note that you can save this configuration at ~/.lftp/rc Another option is to download the certificates and add them to the ca-certificates of your machine. For example: In RHEL7 and cenots and others box the process to add the certificates globally is: Download the two certificates (in PEM or DER format, doesn't matter) and save them to "/etc/pki/ca-trust/source/anchors/" Run "update-ca-trust extract" Another less secure option is to turn off certificate verification with the following command: lftp > set ssl:verify-certificate false Troubleshooting If you are having problems with Aspera connection timeouts, it can be down to either one of the following. Transfers cannot start the connection fails instantly. Ensure that TCP traffic on port 33001 is allowed (open) for outbound connections through your computer's firewall and network's firewall. The connection is made, transfers are started, but 0 bytes (0%) are uploaded for each file. Ensure that UDP traffic on port 33001 is allowed (open) for outbound connections through your computer's firewall and network's firewal

  Documentation submission/data/uploading-files/ftp

• DAC Portal documentation

  DAC Portal Welcome to the DAC Portal documentation! If you are involved in governance or legal aspects, technical or operational aspects, or serving as a data steward, this page will be helpful for you. By exploring these materials, you can define your own Data Access Committee (DAC) and policies, understand the minimal requirements for a DAC and a policy object, and comprehend how the EGA data access requests are managed. DAC Portal Index Setting up your account DACs and Policies Pending Request table Manage Data Requests History page Audit your DACs, policies, and datasets Deprecation User Preferences DAC API - A programmatic approach Setting up your account Register yourself as an EGA user. The Helpdesk team will validate your account (this could take up to 48 hours). After validation, you will receive an email with a link to verify your email - Make sure you click on the link to verify your account! If you don’t receive the email, please check your spam folder. Once your account is active you can login to the DAC Portal. We recommend you to check out the Take The Tour! DACs and Policies Create a DAC Click on Create a DAC Add the title and description to your DAC. Once ready, click on the ‘Create’ button. You will have to wait until the Helpdesk Team validates the creation of your DAC. Once approved by Helpdesk, your DAC will be assigned with a persistent identifier (EGAC). Edit a DAC Once your DAC is registered and approved, you can edit it and add contacts. Remember, you can add as many contacts as needed. And, you can also remove/add contacts anytime. To add a contact, you must write the username or email of a registered EGA user in the Members field. Once you have typed the whole username or email, a drop-down menu will appear where you can select the contact. Select a contact from the drop-down menu. Make sure you write the full username or email of the contact so it appears as an option. Make sure that you select one main contact. Set up the role you want to grant to the new contact of the DAC. We recommend you to check out the FAQ to learn more about the different roles! After adding all the necessary contacts and assigning roles, click on Update. This will send an email notification to the new DAC member, letting them know about the invitation to managing the DAC. Once they log into the DAC Portal, they will be able to either accept or turn down the invitation. Create a policy First, please note that all information registered in a policy metadata object will be publicly available on the EGA website. For each released dataset, all users will be able to read the policy under the “Data Access” tab. Select Create a Policy from the Policies tab. Select the DAC that you want your policy to depend on. Add the title and terms and conditions for accessing and using your data. If you already have an external website for data access requests, you can add the URL directly here (see example here). You can find a template of a Data Access Agreement (DAA) document in our Policy documentation page. The DAA template is provided for guidance only and should be adapted to suit your own purpose depending on the security policies, terms for publication or embargoes, and restrictions on data use or sharing. You can also add Data Use Ontologies (DUO) to your policy. These DUO codes are used to semantically tag the terms and conditions of using the data linked to the policy (example). For more information, you can refer to the Data Uso Ontology documentation. Once completed, make sure to click the Create button in order to register your policy. A persistent identifier (EGAP) will be assigned automatically. Edit a policy Please, note that you will not be able to edit the policy if it shows in orange. Meaning that you are a member of the DAC linked to that policy. Members don’t have edit rights. Only admins can edit objects. You can check your registered policies on My policies, available at the menu in the top-right corner. Select your policy. It will then display the information of that policy, allowing you to edit the information. Once you are done with the modifications, click Update. Pending Requests Table Table Settings Upon selecting a specific DAC, you will be presented with a customisable table showcasing all pending data access requests. This table allows you to tailor the displayed information according to your preferences by selecting desired columns. Available Columns (Displayed with the Eye Icon): Date: The date when the data access request was submitted. Full Name: Name and surname of the user submitting the request. Email: Email address associated with the user's request. Username: The username linked to the EGA account of the user submitting the request. Organisation: Affiliated organisation of the user submitting the request. Dataset: EGA accession ID for the requested EGA dataset. Dataset Title: Title of the requested dataset. DAC Comment: Space provided for internal comments related to the request. Expiration: Option to specify an expiration date for granted permissions. Check more information on the pending request table here! Table Filters By default, all data access requests are displayed. However, you have the option to apply filters to refine your view. Follow these steps to apply filters: Click on the More button. This action will reveal the different columns available for applying filters. As you select columns, the checked fields will be displayed at the top of the request table. Choose the specific values within the selected columns that you want to filter for. Click the Search button to apply the selected filters. Do you find yourself frequently applying the same filters? You can save multiple combinations of filters for easy access at any time! Here's how: Click the Save button. Provide a descriptive name for the filter combination. Click Save to confirm. To load saved filters, simply select the saved filter from the dropdown menu to apply it automatically. Check more information on filters here! Advanced Search For users requiring more granular control over their data access requests, the DAC Portal offers an Advanced Search feature using JIRA Query Language (JQL). With JQL, you can craft precise and complex queries to filter and retrieve specific data access requests based on various criteria such as date, user details, dataset attributes, and more. Using JQL's flexibility, you can create custom queries to meet your specific needs, allowing for advanced filtering options beyond the standard filters provided. You can find the Advanced Search feature following these steps: Click the … button Select Advanced To view the allowed fields for filtering and explore all available options, simply click on the info icon. Once you have written the filtering values, click the Search button to apply. Check more information on filters here! Manage Data Requests Upon logging into the DAC Portal, you'll notice a sand clock icon next to the DAC ID, indicating the number of pending requests. Click on the DAC to review these requests. Accept requests Click on the right side of the toggle button to grant access to the user. You can manage other requests before proceeding to the next step. After managing the requests, click on the Apply button. A confirmation box will appear summarising the options to be applied. Click on Yes, Confirm to proceed with granting permissions. Deny requests Click on the left side of the toggle button to deny access to the user. Provide a reason for the denial. Note that the user will receive an email with this reason. Click on the Done button. You can manage other requests before proceeding to the next step. After managing the requests, click on the Apply button. A confirmation box will appear summarising the options to be applied. Click on Yes, Confirm to proceed with denying permissions. Tips! Apply a filter to view all requests to be managed at once. Use the toggle in the row with column names to grant or deny permissions for multiple requests simultaneously. You can grant and deny permissions in the same action, simplifying the process. The confirmation box will provide a summary of all actions, including grants, denials, DAC comments, and expiration dates. History Page The History page serves as a dedicated space to view information regarding all requests managed by all DAC members. Here, you can review active permissions and revoke them as needed. Go to the History page by clicking on the "HISTORY" button from a DAC page in the DAC Portal. Here are the different row types you may find: Current permissions: row in green with a toggle button to revoke permissions on the right. Approved requests: row in green, with no toggle button. Request denied: row in red with “request denied” on the right. Permission revoked: row in red with “permission revoked” on the right. Distinctions to Note! Between Request Denied and Permission Revoked: Request Denied: Refers to requests that were rejected from the outset, indicating that access to the dataset was never granted. Permission Revoked: Indicates that permissions were previously granted but have since been revoked. Users with permissions revoked have previously accessed the dataset. Between Approved Request and Current Permissions: Approved Request: Represents an entry when a data access request has been approved in the past. Current Permissions: Denotes ongoing permissions where a user has present access to the dataset. An approved request may now appear as Permission Revoked in the present. By observing these different rows, users can gain insight into the complete history of a user's interactions and permissions regarding a dataset over time. To revoke access to a specific user for a dataset, follow these steps: Go to History page Look for the row with the specific permissions. You can use the filters! Click on the toggle button to revoke access. Add a denial reason. Bear in mind that the requester will receive the denial reason! Click on the Apply button. Check more information on the Hisotry page here! Audit your metadata objects In the DAC Portal, you can efficiently manage and audit various metadata objects pertinent to your role as a Data Controller. Upon accessing the DAC Portal, you will encounter three primary tabs on the homepage: DAC: Contains information about Data Access Committees (DACs). Policies: Provides insights into linked policies. Datasets: Displays datasets and relevant details. Within each tab, you'll find a comprehensive list of the objects you manage, these being grouped by type (DAC, Policies, Datasets), as well as by your role (member/admin). Whilst the lists give you a quick look, to check how things are connected, we've added a table at the bottom DACs and policies. DACs Let’s check which policies are linked to a specific DAC: Go to "My DACs." Select a DAC. Click on "EDIT" to see more details. You are now on this page: Scroll down to see the linked policies. Click on “List of linked policies of this DAC” and you will see a list of all policies linked to your selected DAC. Policies Do you want to view a list of datasets connected to a particular policy? Follow the same steps mentioned earlier, but head to the policy tab this time. In the policy tab, you'll find a list of all your policies. Here, you may notice two different icons next to the policy ID (EGAP): DAC Icon (): This represents the DAC. Hover your mouse over the icon to see the DAC ID. Dataset icon (): This indicates datasets falling under that policy. The number next to the icon tells you how many datasets are linked to the policy. For example, if you see "2" next to the icon, it means there are two datasets linked to that policy. If you want to check the linked datasets and their relevant information, simply click on a specific policy. You'll then find the "List of linked datasets of this policy" at the bottom of the page. Datasets Finally, in the dataset tab, by default you will see a list of all the datasets you can manage with all your DACs and policies. Yet, we've included two handy ways to organise them: DAC vs. policy: You can group by datasets, either by DAC or policy. Released vs. unreleased: You can sort out datasets based on their release status. Feel free to experiment with both options! For instance, if you want to see which DACs have unreleased datasets, simply select DAC and unreleased, and you'll get the details you need! Deprecation Do you have a bunch of metadata objects like DACs and policies that you don’t need anymore? This section shows you how to get rid of them! But what does "deprecation" mean for EGA? It's basically changing the status of a metadata object to "deprecated," which means we won't be using it in the future. In simple terms, it's like saying these objects are no longer useful. However, because we believe in making metadata FAIR, once an object has a persistent identifier, we can't just delete it. So, instead of deleting, we deprecate it. Here's a helpful tip! If you want to make a metadata object disappear from the DAC Portal, deprecate it. You won’t see it in the portal anymore! Let’s say you want to deprecate a DAC. Let’s do it! Go to "My DACs." Select a DAC. Click "EDIT" to see more details. You are now in this page: Click on the Deprecate button It will then appear a message. There are two options here: Your DAC is not linked to any policy, hence it’s ready to be deprecated. Click on “Yes. Confirm” to deprecate your DAC object! Your DAC is linked to at least one policy, and you need to either: Deprecate the linked policy first, or Link the policy to a different DAC Now, let’s say you don’t want to get rid of the policy altogether, but you want to change the DAC it’s linked to. Here's how: Go to the policy tab. Find the policy you want to change (for example, EGAP50000000019). Choose a new DAC to link it to. Click on Update. See the Edit Policy section for more details. After ensuring that the DAC we want to deprecate isn’t linked to any policy, return to the "My DACs" section and follow the steps outlined previously. This will lead you to a confirmation message. You can only deprecate DACs and Policies. To deprecate a dataset, please contact our Helpdesk team. Check more information on how deprecation works here! User Preferences We have implemented email notifications in the DAC Portal. Here’s the complete list: DACs: Pending requests Approved by Helpdesk Rejected by Helpdesk DAC Invitation Requesters: Data access request approved Data access request denied Permissions revoked Upcoming expiration date As a DAC member, you will be able to decide whether you want to receive the DAC notifications or not. For that, go to the top-right corner menu, select User Preference. You will be able to decide whether you want to receive notifications for: Approved by Helpdesk Rejected by Helpdesk DAC Invitation For pending requests, you will be able to select how often do you want to receive the notification: Daily Weekly Fortnightly As a DAC member, you are responsible for managing data access requests. Consequently, you will receive notifications for pending requests. If you prefer not to manage these requests, please arrange to be removed as a contact for your DAC. Here's a tip! Do you have a pending request that you don’t want to receive a notification? Add a DAC comment! The EGA understands that a request resolution can take some time, for this reason, if you add a comment (make sure you save it by clicking the APPLY button!) we will filter those requests at the time of sending the notification! DAC API - A programmatic approach In addition to the new DAC Portal, we are excited to announce the release of the DAC API. This enables users to programmatically manage permissions. If you are interested in learning more about the technical specifications, you can click the button below. Check out the DAC API specification!

  Documentation access/data-access-committee/dac-portal

• Bulk-tissue RNA-sequencing paired nuclear and cytoplasmic fractions of anterior prefrontal cortex, cerebellar cortex and putamen tissues from 4 post-mortem neuropathologically-confirmed control individuals ( anterior prefrontal cortex &amp; cerebellar cortex – 4 individuals, putamen- 3 individuals)

  Profiling of paired nuclear and cytoplasmic fractions of anterior prefrontal cortex, cerebellar cortex and putamen samples by bulk-tissue RNA-sequencing. Samples were derived from 4 post-mortem neuropathologically-confirmed control individuals ( anterior prefrontal cortex – 4 individuals, cerebellar cortex – 4 individuals, putamen- 3 individuals). Paired-end FASTQ files for each of the human samples are provided. Fastp (v 0.20.0), a fast all-in-one FASTQ pre-processor, was used for adapter trimming, read filtering and base correction. Fastp default settings were used for quality filtering and base correction. Further details on parameters used are available here: https://github.com/RHReynolds/RNAseqProcessing .

  Dataset EGAD00001009264

• Mutational bias in spermatogonia impacts the anatomy of regulatory sites in the human genome

  Mutation in the germline is the ultimate source of genetic variation, but little is known about the influence of germline chromatin structure on mutational processes. Using ATAC-seq, we profile the open chromatin landscape of human spermatogonia, the most proliferative cell-type of the germline, identifying transcription factor binding sites (TFBSs) and PRDM9-binding sites, a subset of which will initiate meiotic recombination. We observe an increase in rare structural variant (SV) breakpoints at PRDM9-bound sites, implicating meiotic recombination in the generation of structural variation. Many germline TFBSs, such as NRF, are also associated with increased rates of SV breakpoints, apparently independent of recombination. Singleton short insertions (&gt;=5 bp) are highly enriched at TFBSs, particularly at sites bound by testis active TFs, and their rates correlate with those of structural variant breakpoints. Short insertions often duplicate the TFBS motif, leading to clustering of motif sites near regulatory regions in this male-driven evolutionary process. Increased mutation loads at germline TFBSs disproportionately affect neural enhancers with activity in spermatogonia, potentially altering neurodevelopmental regulatory architecture. Local chromatin structure in spermatogonia is thus pervasive in shaping both evolution and disease.

  Study EGAS00001005366

• DLK1 Distinguishes Subsets of NF1-Associated Malignant Peripheral Nerve Sheath Tumors with Divergent Molecular Signatures

  Study Design and Aims We aimed to investigate the molecular mechanisms underlying the malignant transformation of pre-existing neurofibromas (PNST) to malignant peripheral nerve sheath tumors (MPNST) in individuals with neurofibromatosis type 1 (NF1). Our primary focus was on the role of DLK1 in this transformation process and its potential as a biomarker for diagnosis, risk assessment, and therapeutic stratification. Population InformationThis study consisted of a case set of peripheral nerve sheath tumor specimens, including plexiform neurofibromas, atypical neurofibromas, and MPNSTs, acquired under IRB approval at our institution. The majority of the subjects had neurofibromatosis type 1. Principal Findings DLK1 Overexpression: The study found that DLK1 is significantly increased in MPNST compared to non-malignant neurofibromas.Early Marker: DLK1 overexpression may precede histological changes indicative of malignancy.Serum Levels: Higher serum levels of DLK1 were observed in both mice and humans with MPNST.Molecular Stratification: Divergent levels of DLK1 expression identified distinct MPNST subsets with unique molecular characteristics and potential therapeutic targets.Clinical Implications: Overexpression of DLK1 was associated with the reactivation of embryonic signatures, an immunosuppressive microenvironment, and poorer overall survival in NF1-MPNST patients. Data Availability Whole exome sequencing, bulk RNA sequencing, and single-cell RNA sequencing data from this study will be made available through the database of Genotypes and Phenotypes (dbGaP) to support further research and validation studies.

  Study phs003835

• A_study_of_the_genetic_basis_of_evation_by_Acute_Myeloid_Leukaemia_of_Graft_vs_Leukaemia_effects_after_allogeneic_bone_marrow_transplantation

  Acute myeloid leukaemia (AML) is an aggressive and molecularly diverse disease with a poor overall survival of 20-25%. With an annual incidence of 2.9 per 100,000, AML is currently the commonest myeloid malignancy in Europe, yet the two main therapeutic options for this disease, anthracyclines and purine analogues, have remained unchanged for over 20 years. Currently patients are stratified at diagnosis according to a series of clinicopathological parameters (e.g. age, white cell count and presence/absence of previous clonal haematological disease) and molecular markers (e.g. chromosomal translocations/deletions, aneuploidy and mutations in genes such as FLT3 and NPM1). Patients with adverse prognostic features, whose prognosis is particularly poor (e.g. &lt;15% long-term survival) are offered treatment with allogeneic bone marrow transplantation (allo-BMT) if a sibling or unrelated donor is available. This can significantly improve survival (e.g. up to 40% long-term survival in some contexts), albeit at the expense of significant toxicity and transplant-related mortality (TRM). Allo-BMT is thought to work in part by allowing the delivery of large doses of chemotherapy followed by haemopoietic "rescue" with donor haemopoietic stem cells (haemopoietic failure would otherwise ensue). However, potentially the most potent effect of allo-BMT is the cytotoxic effect of donor lymphocytes against AML blasts, a phenomenon known as graft-vs-leukaemia (GVL) effect. Increasingly, transplants using reduced chemotherapy intensity (mini-allografts) are being used that partially circumvent the toxicity from chemotherapy and rely on GVL to effect cure. Nevertheless, AML relapse after allo-BMT still occurs at a significant rate of up to 80% depending on the type of transplant. There is accumulating evidence that genetic events in residual leukaemic cells enable them to evade immunodetection and therefore survive the GVL effect and expand to cause relapse. The most striking example of this is the loss of HLA antigens after transplants in which donor and recipient are not fully HLA-matched. In these cases, the leukaemia "deletes" the genomic region containing the disparate HLA antigen which was preferentially targeted as "foreign" by the GVL effect. However, the genetic basis of immune evasion in the majority of transplants, which are fully HLA matched, is not known. One possibility is that loss of genes coding for antigens outside the HLA locus but which are also targets of GVL may operate, alternatively genetic events that affect processes downstream of immunological cytotoxicity may be responsible.The identification of genetic events that mediate immune evasion would not only facilitate the understanding of this process but can help plan therapeutic interventions that improve the outcomes of allogeneic transplantation for AML and other disorders. We intend to study this by conducting exome sequencing on 6 cases of AMLs from patients that attend my clinic at Addenbrooke's hospital and have relapsed after allogeneic transplantation. Samples from AML diagnosis, remission/normal and AML relapse (total n=18) will be studied to identify somatic mutations in the primary AML and those acquired by the relapsed clone. The 18 samples will also be studied by array CGH to detect regions of genomic amplification or deletion.

  Study EGAS00001000145

• UK10K RARE COLOBOMA

  In the UK10K project we propose a series of complementary genetic approaches to find new low frequency/rare variants contributing to disease phenotypes. These will be based on obtaining the genome wide sequence of 4000 samples from the TwinsUK and ALSPAC cohorts (at 6x sequence coverage), and the exome sequence (protein coding regions and related conserved sequence) of 6000 samples selected for extreme phenotypes. Our studies will focus primarily on cardiovascular-related quantitative traits, obesity and related metabolic traits, neurodevelopmental disorders and a limited number of extreme clinical phenotypes that will provide proof-of-concept for future familial trait sequencing. We will analyse directly quantitative traits in the cohorts and the selected traits in the extreme samples, and also use imputation down to 0.1% allele frequency to extend the analyses to further sample sets with genome wide genotype data. In each case we will investigate indels and larger structural variants as well as SNPs, and use statistical methods that combine rare variants in a locus or pathway as well as single-variant approaches. Ocular coloboma is the most common significant developmental eye defect with an incidence of ~1 in 5,000 live births. It results from failure of optic fissure closure during embryogenesis. The position and extent of the fusion failure dictates the clinical appearance and functional effect. ~30% of coloboma cases are associated with other systemic malformations. These UK10K samples will mostly comprise isolated coloboma cases without systemic involvement (aka non-syndromal coloboma). There is strong evidence from family studies that coloboma has a major genetic component with autosomal dominance being the most common pattern of inheritance. However, many cases are isolated or show complex patterns of familial clustering. The genes responsible for isolated coloboma are largely unknown, but in a small number of families mutations in SHH, CHX10, and PAX6 have been identified indicating marked genetic heterogeneity. Thus in addition to the clinical benefits of achieving a molecular diagnosis there are also major scientific advantages to identifying coloboma genes, as these are likely to provide insights into the complex process of optic fissure closure, that is critical to normal eye development. In the longer term, understanding the molecular basis of the disease may provide clues to therapeutic strategies.For further information with regard to this cohort please contact David Fitzpatrick (david.fitzpatrick@ed.ac.uk).

  Study EGAS00001000127

• FEGA and European GDI: working together to improve human health

  The Federated EGA is a global resource for discovery of and access to sensitive human omics and associated data consented for secondary use, through a network of human data repositories to accelerate biomedical research and improve human health. The Federated EGA network was launched in September 2022 with five inaugural nodes, and since 2023 seven operational nodes can share data across national borders in adherence to European and national laws. A few weeks after FEGA's official launch, in November 2022, the European Genomic Data Infrastructure (GDI) project was kicked-off . This European Commission co-funded project, coordinated by ELIXIR, is aimed to deliver federated, sustainable and secure data infrastructure to access genomic and related phenotypic and clinical data across Europe. This project supports the aim of the 1+MG initiative (25 EU countries, Norway and UK) to enable personalised medicine and health through a shared framework and infrastructure for securely accessing and integrating high quality genomic data and other health data across borders.1+MG will be an integral component of the European Health Data Space (EHDS) for secondary use (Healthdata@EU) as an authorised participant. How are Federated EGA and GDI similar? Given their shared visions, the Federated EGA and European GDI networks have a lot in common. To begin, they share the same overall goal of establishing networks of “nodes” that host sensitive human data within a jurisdiction and connecting these nodes in a global network to support data discovery and promote human genome data access for research and healthcare. FEGA and GDI are both initially focused on enabling access to human genomic data, while FEGA ambition is to expand the scope to clinical research data and other omics data in the future. FEGA and GDI are both built on open and interoperable software solutions, a subset of which are based on the LocalEGA components. FEGA and GDI implementation solutions are based on international community standards, for example those developed by the Global Alliance for Genomics and Health, which contributes to making them interoperable. Both FEGA and GDI allow for the nodes to make use of any solution that is fully compatible. As illustrated in Figure 1, a final key point is the significant overlap of institutions involved in envisioning and operating FEGA and GDI nodes, with the clear wish to keep them interoperable in the future. What distinguishes Federated EGA from GDI? Despite being largely similar, there are some differences between the FEGA and GDI networks, which we aim to clarify in this post. The first difference is the governance model that the nodes will operate to comply with national laws and GDPR. In the FEGA network, nodes have taken inspiration from the EGA data access model, where the infrastructure is a data processor of the hosted data and data controllership remains with the originating Data Access Committees (i.e. Data controllers) for each dataset. On the other hand, in the GDI network the controllership of datasets will be transferred to a 1+MG European Digital Infrastructure Consortium (EDIC) legal entity created by the Member States (MS), who will make data access decisions, with data holders having veto powers for their datasets. Importantly, FEGA nodes have the flexibility to choose another model to fit with their data protection framework, including becoming data controllers for their datasets. The second difference is the inclusion criteria for data. While FEGA nodes are designed to accept almost any type of omics data in need of control access (e.g. genomics, transcriptomics, genotyping, single cells sequencing, patient-tracked metagenomics), GDI nodes are initially, but not only, focused on accepting whole genome and exome sequencing data and affiliated data from sources such as (i) the Genome of Europe use case of the 1+MG initiative which specifically aims to fulfil the mission of building “a European network of national genomic reference cohorts of at least 500,000 citizens”) (ii) data collection of other types of genomic data identified by countries through the 1+MG dashboard and (iii) genomic data coming from data holders which would need to fulfil EHDS requirements. The third difference is the maturity of the software stacks. The FEGA network provides a set of software for data and metadata submission, storage, permissions management, and file distribution (the LocalEGA package). GDI is building a complete set of open source reference for the five functionalities covering the full data life cycle (a few more compared to the LocalEGA) including federated processing (analytics, AI/ML), which is still under active development. Notably, one of the GDI functionalities - storage and interfaces - can be satisfied by using the LocalEGA storage solution, highlighting the ability of FEGA and GDI to be interoperable. In both FEGA and GDI, nodes are allowed to use alternative solutions as long as they are fully interoperable with the networks. Figure 1 provides a simple overview of these described commonalities and differences. Figure1: schematic overview of the main commonalities and difference among a FEGA and a GDI node Can the same institute run a FEGA and a GDI node at the same time? The answer is Yes! We believe this is entirely possible and encouraged. As long as 1+MG requirements are continuously fulfilled in the implementation. The same trained personnel could operate the infrastructure and leverage the same national funding to run a FEGA and a GDI node. Several European nodes, especially GDI vanguard nodes like Norway, Sweden, Finland and Spain are following this model. The idea is that a lot of the work can be reused, given the overlapping scope and the interoperable technology. Thus, the hosted datasets can be discovered via the two catalogues, perhaps accessible under the same or different governance models. From a FEGA node perspective, the GDI datasets could simply be a subset of the datasets hosted in the FEGA node, which have their specific governance as any other. What's next? So, the amazing teams of people building the Federated EGA network and the European GDI network are working together to create infrastructures able to provide secure access to human genomic and associated data around Europe. Because we all know how much human genomics can improve healthcare and precision medicine. And we all want to collaborate to make it happen. This article has been reviewed collectively by members of the EGA and the GDI coordination team.

  Blog fega-and-gdi

• National Human Genome Research Institute (NHGRI) GENEVA Genome-Wide Association Study of Venous Thrombosis (GWAS of VTE)

  Overview: Our overall long-term goal is to determine risk factors for the complex (multifactorial) disease, venous thromboembolism (VTE), that will allow physicians to stratify individual patient risk and target VTE prophylaxis to those who would benefit most. In this genome-wide association case-control study (1300 cases and 1300 controls) we hope to identify susceptibility variants for VTE. Mutations within genes encoding for important components of the anticoagulant, procoagulant, fibrinolytic, and innate immunity pathways are risk factors for VTE. We hypothesize that other genes within these four pathways or within other pathways also are VTE disease-susceptibility genes. Therefore, we performed a genome wide association (GWA) screen and analysis using the Illumina 660W platform to identify SNPs within 1,300 clinic-based, non-cancer VTE cases primarily from Minnesota and the upper Midwest USA, and 1300 clinic-based, unrelated controls frequency-matched on patient age, gender, myocardial infarction/stroke status and state of residence. This is a subset of a slightly larger candidate gene study using 1500 case-control pairs to identify haplotype-tagging SNPs (ht-SNPs) in a large set of candidate genes (n~750) within the anticoagulant, procoagulant, fibrinolytic, and innate immunity pathways. Study Populations. Cases. VTE cases were consecutive Mayo Clinic outpatients with objectively-diagnosed deep vein thrombosis (DVT) and/or pulmonary embolism (PE) residing in the upper Midwest and referred by Mayo Clinic physician to the Mayo Clinic Special Coagulation Laboratory for clinical diagnostic testing to evaluate for an acquired or inherited thrombophilia, or to the Mayo Clinic Thrombophilia Center. Any person contacted to be a control but discovered to have had a VTE was evaluated for inclusion as a case. Cases were primarily residents from Minnesota, Wisconsin, Iowa, Michigan, Illinois, North or South Dakota, Nebraska, Kansas, Missouri and Indiana. A DVT or PE was categorized as objectively diagnosed when (a) confirmed by venography or pulmonary angiography, or pathology examination of thrombus removed at surgery, or (b) if at least one non-invasive test (compression duplex ultrasonography, lung scan, computed tomography scan, magnetic resonance imaging) was positive. A VTE was defined as: Proximal leg deep vein thrombosis (DVT), which includes the common iliac, internal iliac, external iliac, common femoral, superficial [now termed "femoral"] femoral, deep femoral [sometimes referred to as "profunda" femoral] and/or popliteal veins. (Note: greater and lesser saphenous veins, or other superficial or perforator veins, were not included as proximal or distal leg DVT). Distal leg DVT (or "isolated calf DVT"), which includes the anterior tibial, posterior tibial and/or peroneal veins. (Note: gastrocnemius, soleal and/or sural [e.g., "deep muscular veins" of the calf] vein thrombosis was not included as distal leg DVT). Arm DVT, which includes the axillary, subclavian and/or innominate (brachiocephalic) veins. (Note: jugular [internal or external], cephalic and brachial vein thrombosis was not included in "arm DVT"). Hepatic, portal, splenic, superior or inferior mesenteric, and/or renal vein thrombosis. (Note: ovarian, testicular, peri-prostatic and/or pelvic vein thrombosis was not included). Cerebral vein thrombosis (includes cerebral or dural sinus or vein, saggital sinus or vein, and/or transverse sinus or vein thrombosis). Inferior vena cava (IVC) thrombosis Superior vena cava (SVC) thrombosis Pulmonary embolism Patients with VTE related to active cancer, antiphospholipid syndrome, inflammatory bowel disease, vasculitis, a rheumatoid or other autoimmune disorder, a vascular anomaly (e.g., Klippel-Tr&#233;naunay syndrome, etc.), heparin-induced thrombocytopenia, or a mechanical cause for DVT (e.g., arm DVT or SVC thrombosis related to a central venous catheter or transvenous pacemaker, portal and/or splenic vein thrombosis related to liver cirrhosis, IVC thrombosis related to retroperitoneal fibrosis, etc.), with hemodialysis arteriovenous fistula thrombosis, or with prior liver or bone marrow transplantation were excluded. Controls. A Mayo Clinic outpatient control group was prospectively recruited for this study. Controls were frequency-matched on the age group (18-29, 30-39, 40-49, 50-59, 60-69, 70-79, and 80+ years), sex, myocardial infarction/stroke status, and state of residence distribution of the cases. We selected clinic-based controls using a controls&#39; database of persons undergoing general medical examinations in the Mayo Clinic Departments of General Internal Medicine or Primary Care Internal Medicine. Additionally persons undergoing evaluation at the Mayo Clinic Sports Medicine Center, and the Department of Family Medicine were screened for inclusion as controls. This study is part of the Gene Environment Association Studies initiative (GENEVA, http://www.genevastudy.org) funded by the trans-NIH Genes, Environment, and Health Initiative (GEI). The overarching goal is to identify novel genetic factors that contribute to venous thrombosis through large-scale genome-wide association studies of 1,300 clinic-based, VTE cases and 1300 clinic-based, unrelated controls. Genotyping was performed at the Johns Hopkins University Center for Inherited Disease Research (CIDR). Data cleaning and harmonization were done at the GEI-funded GENEVA Coordinating Center at the University of Washington.

  Study phs000289

• FIGHT-207: Anonymized Genomic Alterations and Clinical Responses

  Background: FIGHT-207 was a phase 2 study of the FGFR1-FGFR3 inhibitor pemigatinib in patients with previously treated, locally advanced/metastatic or unresectable solid tumor malignancies harboring activating fibroblast growth factor receptor (FGFR) gene alterations. Population information: 107 patients were divided into 3 cohorts: FGFR1&#8211;FGFR3 fusions/rearrangements; n=49 Activating FGFR1&#8211;FGFR3 non-kinase domain single nucleotide variants (SNVs); n=32 FGFR1&#8211;FGFR3 kinase domain mutations or variants of unknown significance (VUS) with potential pathogenicity; n=26 Participants on study had tumors that were grouped into the following histologies based on &#8805; 5 patients: Cholangiocarcinoma, gynecologic cancers (cervical, endometrial, uterine), central nervous system (glioblastoma, low-grade pediatric glioma, astrocytoma), pancreatic cancer, breast cancer, urothelial tract/bladder cancer, non-small cell lung cancer, and other (adrenal cancer, anal cancer, cancer of unknown primary origin, colorectal cancer, gastric/gastroesophageal cancer, gallbladder cancer, giant cell bone tumor, head and neck cancer, lung neuroendocrine cancer, nasopharyngeal cancer, ovarian cancer, prostate cancer, renal cell cancer, sarcoma, solitary fibrous tumor). Among the efficacy-evaluable participants, 99 had both independent review committee (IRC) central best overall response (BOR) and tissue NGS- data; 2 additional patients had Not Evaluable (NE) as central BOR Baseline tissue targeted NGS data (F1CDx, Foundation Medicine Inc.) of genomic alterations are reported for N=101 participants Baseline plasma targeted NGS analysis (PredicineCare, Predicine Inc.) of genomic data are reported for N=83 participants; data at disease-progression are reported for N=78 participants. Principal Findings: The FIGHT-207 study provided evidence of clinical benefit of pemigatinib in multiple histologies, explored the clinical actionability of various FGFR1-FGFR3 gene alterations, and leveraged the depth of translational data from targeted NGS analysis of baseline samples and plasma samples obtained at baseline and end of treatment to provide key insights into the biology of FGFR inhibition and the clinical utility of FGFR inhibitors. The FIGHT-207 article (pending in Nat.Med. NMED-A128973B) reports evidence suggesting clinical acquired resistance to FGFR inhibition via secondary FGFR mutations as well as emerging co-mutations in other oncogenic and tumor suppressor pathways. This study also provides evidence of acquired resistance to FGFR inhibition in multiple histologies beyond cholangiocarcinoma and urothelial cancers in a systemic correlative analysis of post-progression ctDNA in a trial. Data available through dbGaP: Anonymized information for 101 participants with both IRC central BOR evaluation (including 2 patients with NE as BOR) and tissue NGS data, including tumor histology, enrollable FGFR alteration, and outcome. Genomic alterations determined by baseline tissue NGS (F1CDx, Foundation Medicine Inc.) Genomic alterations determined by plasma NGS analysis (PredicineCare, Predicine Inc.) of ctDNA analysis at baseline (n=83) and at end of treatment/ disease progression (n=78) including genomic alterations that were not assessed to be Germline SNPs.

  Study phs003590