The FAIRification board game aims to give a visual and succinct representation of the FAIRification steps followed by the ERNs registries to make their data more findable, accessible, interoperable and reusable. The player starts the game on the top left corner of the board and moves around clockwise one tile at a time. Scroll down for more information on each game tile.. A detailed FAIRification guidance document is beyond the scope of this simplified visual representation. Such a guidance is currently being developed and will be provided in a near future.
- Requests for guidance can be sent via https://www.ejprarediseases.org/our-actions-and-services/central-helpdesk/
- ERNs can directly contact their assigned FAIRification Steward
- Human resources are the most important part of the FAIRification process. Having a team with the right skillset will play an important role in achieving your FAIRification goals.
- Essential roles for interdisciplinary ‘three-party collaboration’:
- ERN registry steward (managing the registry)
- Registry software provider (implements the software behind the registry observing FAIR principles)
- EJP-RD FAIRification stewards (guidance regarding FAIR standards, technologies, and use-cases guiding the FAIRification steps)
- Recommended additional roles:
- Project manager (highly recommended, organiser role)
- Part-time advisors for expertise on (i) the domain (e.g., a medical doctor), (ii) international FAIR standards (e.g., an outsourced senior FAIR expert), (iii) implementation of FAIR software.
- Data scientist dedicated to exploiting the added value of FAIR, machine readable data.
- Rich community of FAIRification experts from various domains that can help navigate this process
- EJP RD partners and ERNs: FAIR Convergence Initiative [ https://ejprd.sharepoint.com/sites/FAIR-Initiatives-Convergence]
- The EJP RD coffee rounds and workshops can be found at https://ejprd.sharepoint.com/sites/EJPRD-ERN-EVENTS (Sign up is required if you do not have already access: https://forms.office.com/r/LJESET5aKQ).
- Your FAIRification steward can also point you out to other resources or experts should you need more specific training.
- The most important step in FAIRification of your rare disease registry is to identify the goals of FAIRification. Well-defined FAIRification goals will help guide the process and make it more efficient.
- Goals can be short term or long term and might include, but are not limited to, the following examples:
- Making the registry interoperable – For this you will need standardised and machine-readable data
- Allow the identification of patient cohorts for clinical trials – This requires you to collect standardised data and be able to reuse it
- Create a RD research ecosystem – This requires the data to be completely FAIR so that information can be queried at the source by the EJP RD Virtual Platform
- Identify what metadata is already being collected by your registry (e.g., provenance, creation date, file type and size, timestamp). The result of this step will support defining the metadata model of your registry. Also, check if your metadata is already being collected using standardized vocabularies.
- Usually, terms from upper ontologies can be used to describe metadata. For example, use dcat:Dataset from Data Catalog Vocabulary (DCAT) to describe the type of any rare disease dataset and dct:creator from DCMI Metadata Terms (DCT) to indicate the relationship between a dataset and its creator.
- Tip: EJPRD Metadata Model and DCAT are good standards to start with.
ERDRI.dor is a catalogue of Rare Disease registries. It provides an overview of participating registries with their characteristics and descriptions. The portal registers metadata in 38 attributes, out of which 23 are compulsory. All information is imputed by the registry owners.
ERDRI.dor can be accessed through https://eu-rd-platform.jrc.ec.europa.eu/erdridor/
ERDRI.mdr is a database of the data elements used by Rare Disease registries. Its main goal is to ease integration between registries. ERDRI.mdr contains metadata that specifies the data elements that are used by registries (including their definition and accepted units of measurement). All the information on ERDRI.mdr is imputed by the registry owners.
The Joint Research Centre have defined Common Data Elements to be collected by all RD registries and collecting them will improve interoperability with other ERN registries that are obligated to collect these data items
- This step aims at a mutual decision within your registry on what information should be exchangeable. To understand “semantics”, data values (i.e., meaning of data elements), data representation (format), and structure information (i.e., hierarchy of that data in the underlying data model) should be analysed.
- The deliverable should be a set of data elements whose semantics should be clear and unambiguous to reflect the information you want to be exchanged.
- In the EJP RD, an initial set of such minimal information has been determined by the Joint Research Centre and is described as Common Data Elements (CDEs). A new registry is advised to collect these CDEs while an existing registry should identify local data elements that semantically align with these CDEs.
- EJP RD has defined a semantic model for the CDEs. The data consists of the Common data elements tagged with ontologies and with the relationships between each data element also defined by ontologies.
- The model can be automatically implemented via the CDE in a box The expert level here may involve knowledge of GIT and Docker images. CDE in a box is a collection of software applications which enables creation, storing and publishing of “Common Data Elements” according to the CDE semantic model.
- This step aims at assigning machine-readable terms from existing ontologies to metadata and CDEs. Uniform Resource Identifiers (URIs) should be used to identify and refer to each term without ambiguity.
- Domain ontologies are used to describe data that is specific to a particular domain. For example, use ncit:sex from National Cancer Institute Thesaurus (NCIT) to describe the “sex” data element, and ncit:male to describe the “male” value of “sex” element.
- The deliverable should be documented bindings of appropriate terms to metadata and data elements so that their semantics can be expressed in a machine-readable fashion.
- In the EJP RD, there is a list of recommended ontologies built specifically for the CDEs but can cater to various purposes. A selection of terms binding to CDEs are determined in the semantic CDE model. So, a new registry or an existing one is advised to follow the choices made in that model, otherwise ontology mapping is needed.
- Tip: By implementing the EJP RD CDE Semantic Model, the standard ontologies used in it are also implemented.
- Pseudonymisation aims to facilitate the secondary use of healthcare data by avoiding creation of a transparent universal ID for each patient. The same patient will be attributed different pseudonyms in different contexts. The link between the different pseudonyms of the same patient is handled by the pseudonymisation software chosen, in a way that preserves the possibility to re-identify the patient for trusted third parties.
- The JRC is developing a tool for this purpose.
- Data collection is a crucial step for a patient registry, make sure to discuss with your team and define the clinical implementation workflow including roles assignment.
- Aim for integrations between Electronic Patient Records and Electronic Data Capture Systems or the Registry System, to avoid manual data insertion.
- This step aims at implementing the semantic model for data through an automatic tool, and the metadata model for metadata. The metadata and data that are structured with ontologies and follow standard schemas make it easier for other resources such as the EJP RD Virtual Platform to find your registry metadata and understand its data.
- Tip: EJPRD developed a metadata model, it may require a developer to implement it in your registry source code.
- Conditions to get access to the data are set up by the Data Access Committee (DAC) and are described in the data access policy. Templates prepared by the EWGs in ERICA can be used for this purpose (e.g., ERN Data Access Policy Template and ERN Data Sharing Agreement)
- EJPRD Generic ICF for patient level decision on data access
- Data Access Policy at registry level should be defined to serve as unbiased criteria for the ERN Data Access Committee. EJP RD experts are working on Common Consent Elements (CCEs) based on DUC (complies ICO and DUO ontologies) and a semantic model for the CCEs. Both resources should reflect the ERN’s Data Access Policy. Stay tuned!
- The Virtual Platform (VP) aims to bring together data from Rare Diseases resources, which is by nature scattered, scarce, and usually isn’t connected to other data sources. The VP is a federated ecosystem, meaning that resources are made available through multiple query points that allow for the answering of questions that require information from various data sources. This way, it makes the data more FAIR while respecting privacy, consent, and access conditions, since the data stays at source level, but can be queried through the VP.
- It is envisioned that each registry will constitute a node in the EJP RD VP network. It will be possible to send queries to all the nodes in the network via the VP. Each node stays in control to who can access the data and in which format (yes/no answers, aggregated, anonymised, pseudonymised).
- Tip: The first version of the Virtual Platform Specifications (VIPS) is out! Please contact us via EJP RD helpdesk if you have any questions.
- As a task under the objectives of the EJP RD, we created a set of software packages – The FAIR Evaluator – that coded each Metric into an automatable software-based test, and created an engine that could automatically apply these tests to the metadata of any dataset, generating an objective, quantitative score for the ‘FAIRness’ of that resource, together with advice on what caused any failures (https://www.nature.com/articles/s41597-019-0184-5). With this information, a data owner would be able to create a strategy to improve their FAIRness by focusing on “priority failures”. The public version of The FAIR Evaluator (https://w3id.org/AmIFAIR) has been used to assess >5500 datasets. Within the domain of rare disease registries, a recent publication about the VASCA registry shows how the Evaluator was used to track their progress towards FAIRness (https://www.medrxiv.org/content/10.1101/2021.03.04.21250752v1.full.pdf). To date, no resource – public or private – has ever passed all 22 tests, showing that FAIR assessment is able to provide guidance to even highly-FAIR resources.
- The FAIR evaluation results can serve as a pointer to where your FAIRness can be improved.
- Toward effective, interoperable rare disease registries, in collaboration with the EJP-RD: https://www.ejprarediseases.org/wp-content/uploads/2019/09/EJPRD-Pillar2-proposal-for-ERN-registries.pdf
- A generic workflow for the data FAIRification process: https://doi.org/10.1162/dint_a_00028
- The de novo FAIRification process of a registry for vascular anomalies: https://doi.org/10.1186/s13023-021-02004-y
- The “A” of FAIR – as open as possible, as closed as necessary: https://doi.org/10.1162/dint_a_00027
- Making FAIR Easy with FAIR Tools: From Creolization to convergence: https://doi.org/10.1162/dint_a_00031
- De-novo FAIRification via an Electronic Data Capture system by automated transformation of filled electronic Case Report Forms into machine-readable data: https://doi.org/10.1016/j.jbi.2021.103897
- Semantic modelling of Common Data Elements for Rare Disease registries, and a prototype workflow for their deployment over registry data: https://doi.org/10.1101/2021.07.27.21261169
- Introducing Domain-specific Common Data Elements for Rare Disease Registration: A Joint Initiative towards improving Semantic Interoperability in Rare Disease Research: https://preprints.jmir.org/preprint/32158