Search Results - EGA European Genome-Phenome Archive

Addressing common questions about Federated EGA (FEGA) Affiliates and providing answers. FEGA Affiliates have recently been defined as the third tier within the newly approved “Federated EGA Structure and Organisation” document, alongside Central EGA (CEGA) and the FEGA Nodes. In this blog post, we aim to answer the questions that may arise on this topic. For more general information about FEGA Affiliates, you can refer to this blog post. Let's now start with the questions and answers! What is the difference between a FEGA Affiliate and a FEGA Node? FEGA Nodes A FEGA Node is a national-level service that accepts submissions and provides archiving and access services within a single country's jurisdiction. Nodes provide end-to-end services for submitters in that jurisdiction, including submission support, processing, permissions management, and distribution. FEGA Affiliates A FEGA Affiliate is not a national submission service. Instead, it archives data from its own legal entity and/or selected partner institutions (for example, consortium partners). Affiliates are designed for organisations and consortia that need to keep data stewardship and access decisions within their own governance model, while still enabling discovery through the broader FEGA ecosystem. What do Affiliates commit to? Here is a practical checklist of the core expectations for a FEGA Affiliate. FEGA Affiliate checklist Discovery and metadata Submit non-personal metadata to CEGA to obtain EGA accessions and enable discovery (with metadata validation handled by the CEGA Helpdesk). Operations and resilience Maintain a data storage system and a defined backup/recovery approach. Ensure operational capacity (personnel and infrastructure) to deliver Affiliate services. Maintain systems and practices that support local data security and align with EGA best-practices. Access and user support Provide data distribution or access (e.g in a trusted research environment) to authorised users to datasets hosted at the Affiliate. Provide permissions management for datasets archived by the Affiliate (the CEGA DAC (Data Access Committee) Portal is always at your disposal to use). Provide a minimal helpdesk with sufficient capacity to support relevant DACs and approved users. Membership term Commit to a minimum membership term of four years. Governance and participation (lightweight by design) Affiliates integrate into the FEGA network operationally, but without the committee obligations associated with Nodes. When is becoming an Affiliate the right fit? Consider the Affiliate tier if: You host (or plan to host) controlled-access datasets that must be managed under your organisation’s or consortium’s governance, you want studies to be discoverable through EGA, but need access control and/or distribution to remain local, and you are not aiming to operate a national submission service tier.. What if a FEGA Node already exists in my jurisdiction? We encourage any potential Affiliate to reach out to their national FEGA Node to explore collaboration at the national level. Why? Federated models within a country already exist in FEGA, where a national Node operates like a Central EGA for their country. FEGA Nodes can also represent the interests of any Affiliates within their jurisdiction at the FEGA Committees. FEGA Nodes have experience and can support you on your FEGA journey. Ready to join as a FEGA Affiliate? We’re excited to open this formally defined pathway for organisations and consortia to participate in the federation. If you think the FEGA Affiliate tier fits your needs, start by assessing: Your scope (organisation/consortium-held data rather than public external submissions), Your ability to provide the core services (permissions, distribution/access, helpdesk, monitoring), and Your readiness to submit non-personal metadata to CEGA for accessioning and discovery. To express interest, please contact us here, and we'll help you understand the onboarding steps and how Affiliates integrate into the FEGA network.

Blog fega-affiliates-q&a

Best Practices for DACs

Best Practices Data access committees (DACs) are institutional safeguards responsible for ensuring a balance between data protection and accessibility. However, there are no procedural standards that apply across DACs, which can lead to inconsistencies in their reviews and compromise their quality and effectiveness. Standardising DAC processes can foster trust and mutual recognition, paving the way for greater coordination, collaboration, and delegation between DACs and other oversight bodies to improve the efficiency of data access without sacrificing protection. To provide guidance, the following are suggestions for actions a DAC might take upon receiving a data access request: Aim to respond to all initial requests in less than 2 weeks. Failure to do so may result in follow-up emails from the EGA, journals, and ultimately dataset withdrawal. First, check that the data/EGAD number is consistent with your data submission. In other words, ensure that the requester has contacted the correct DAC. Verify that the user will be using the data within the terms of consent by asking them to sign up to the terms within the DAA. Ensure that data users who are granted access to the data comply with the terms of a Data Access Agreement (DAA) and to use the data only in approved ways. Look for an institutional email address for the requester. Search for evidence that the requester is "appropriately qualified/bona fide" for using the data, for example on PubMed, Research Gate, LinkedIn, etc. Confirm that the affiliated organisation is real and that the requester still works there. Inquire with the requester about who should have accounts created at the EGA under the terms of the agreement. If a negative decision is made, promptly communicate it to the requester and support it with the terms of the Data Access Policy that the requester has not met or cannot meet. Keep the information in the DAC up to date. If you leave your institution and are unable to manage data access requests on their behalf, you should add your replacement as a new contact in the DAC. Assist with data access requests for any further questions related to your data. The EGA can only check information that has been deposited in the repository. If the user has a specific question that the EGA cannot answer, we will redirect the user to the DAC. All the EGA studies and datasets referenced in a publication under your DAC must be publicly searchable on the EGA website before the paper is released. If possible, describe the permitted purposes for subsequent research projects, including associated limits and conditions, for all resources hosted in a repository using a common ontology, such as the GA4GH Data Use Ontology (DUO). It is considered best practice to try and release data only to those with an institutional email address. This gives reassurance to the EGA, research participants, and the general public that an appropriate individual is accessing and using the data. To prevent potential data breaches and ensure adherence to GDPR regulations, it is essential that the European Genome-Phenome Archive (EGA) is informed via the Helpdesk team of any changes to the Data Access Committee (DAC). This should be done in addition to any changes being made on the DAC portal. Data Controllers (as per the definition in the DPA) are also responsible for notifying the previous DAC of any modifications. Without proper notification, changes might not be automatically updated in our system, leading to the risk of incorrect permissions being applied and potential data access issues. Therefore, it is imperative that all Data Controllers follow this protocol to maintain data integrity and security.

Documentation access/data-access-committee/best-practices