registries


As a service to fellow ePag members I have tried to make a ePag version of the complex proposal for a ITHACA registry.
Gerritjan


In the spirit of the EU Council Recommendation on Rare Diseases (2009) and on the EUCERD recommendations on patient registration (2013), the European Commission has decided to support European Reference Networks in setting up patient registries

A registry is a database in which information about individuals is kept. In the case of a patient registry it concerns (medical) data of patients. Examples of such data are: age, diagnose or medical indication, treatment followed, stage of development of the disease, etc.

The usefulness of registries

Patient registries, for example, can provide insight into:

  • The number of patients with a condition
  • The course of the disease and its differences between patients
  • Effects of a medicine
  • The quality of care in different hospitals
    For rare diseases, registries are believed to be important. A registry bundles the limited amount of information there is about the condition. This creates more insight and knowledge to improve patient care. It is important that the correct information is collected, including patient-generated data, and that patient involvement in the registry is guaranteed. 

For the complex rare diseases as seen in Ithaca context the heterogeneity of the rare disease makes it important to see these variations, a registry across country boundaries gives a better insight in this.

Money for rare diseases is hard to get, a registry could help in showing the decision makers the importance of investing in Rare diseases.

Ithaca's plan

  • Create a 'umbrella' registry 
  • Links existing registries to the umbrella
  • Push Information into European Rare Disease Registry Infrastructure EDRI for working together with other ERN's.

Ithaca considers itself to be probably the most complex to implement in a registry because of:

  • the huge number of diseases and 
  • the complexity of each disease.

The name for the Ithaca registry is proposed as ILIAD help

The main contributors are : 
HCP's help (Centre of expertise, University centre's) that are full or affiliated members of ITHACA
The development is together with ERN Skin and ERN CRANIO
The intended users of ILIAD are:
all clinical and research practitioners
ILIAD aims to interoperate with:
relevant data sources in and outside ITHACA.

Planning

  1. Set up a central ERN ITHACA registry
  2. Set up a local version of the registry software that could be used by HCPs
  3. Governance of ILIAD registry
  4. Obtain patient records from several HCPs
  5. Connect with other ERN registries
  6. Establish interoperability of Central ITHACA Registry with at least one RD registry outside of the ERN network

3. Stakeholders

  1. Affected people (including those with no diagnosis) represented by ePag Council, that will will be involved in the monitoring and development of the registry and more specifically in the connection of patient-based registries to the Central ERN registry.
  2. Healthcare providers and researchers, The 38 European centres approved in ERN-ITHACA. Professionals in the ITHACA network will work together to develop and implement registry information
    1. collaborative and statistically valid clinical and fundamental research in the field of developmental anomalies
    2. information on the factors involved in the disease process and the demographics of patients
    3. improve the quality of the guidelines or expert recommendations produced to address the needs of these patients
  3. Health Policy Makers, valuable for the elaboration of policy decisions that impact RD patients in general and ITHACA patients in particular. 
  4. Industrial stakeholders

4. Relevance

 

  • Following EU recommendations
  • Added Value;
    • contribute to the general knowledge about RDs
    • overcomes the fragmentation of patient populations across the 28 states of the EU
    • elucidate or refine EU wide health policies in the field of developmental disorders
    • strengthen networking activities within and across ERNs
  • Added value in terms of care
    • integrating professionals from (smaller) countries without extended knowledge about a specific rare disease
    • and promoting best practice guidelines individualized by disorder.

Geographic coverage

  • 38 HCPs from 14 of the 28 Member States
  • applications for affiliated member status from around 7 other countries
  • for HCP's not allowed to use WEB access a special tool will be developper so these countries can also participate

Context

  • Compliance with EU Regulation 2016/679 and Directive 2016/680 on the processing and free movement of personal data, as well as with all pertinent national laws and regulations in the member states
  • (it is stated that Rare diseases ar more in need (having more problems) as general population)
  • Ethical aspects are of extreme importance, in which the Patient Council will have a strong involvement, is foreseen in this application

5. Methods and Means

It describes, with all kind of Information buzz-words, that it will be state of the art Registry based on MOLGENIS. It will be constructed by a team in University of Groningen lead by Pr. Morris Swertz of the Genomics Coordination Center (GCC), hosted by the Department of Genetics of the University Medical Center Groningen in the Netherlands.

General Information overview

Core
  • Minimal amount of Clinical data that is not Age dependent (it always stays the same)
  • Type 1: Genetically-defined patients
  • Type 2: Clinically defined patients
  • Type 3: Undiagnosed patients
Data fields Module 1 dataset and ERN identification
  1. Pseudonym
  2. Personal information
    1. Date of Birth
    2. Sexe
  3. Patient Status
    1. Patient alive or dead
    2. Date of Death
  4. Care pathway, Date of first contact with specialist centre
  5. Disease history
    1. Age at which symptoms/signs first appeared
    2. Age at which diagnosis was made
  6. Diagnosis
    1. Diagnosis of the rare disease
    2. Genetic diagnosis
    3. Undiagnosed case
    4. Variant description
    5. Sign/symptom
  7. Research
    1. Agreement to be contacted for research purposes
    2. Consent for the reuse of data
    3. Biological sample
    4. Link to a biobank
  8. Disability classification
Data fields Module 2, supplementary fields for multi-ERN registration and historization
  1. Research
    1. Date of agreement to be contacted for research purposes
    2. Date of consent for the reuse of data
    3. Date of consent for the reuse of a  biological sample for research
  2. ERN
    1. ERN
    2. Affiliation of the clinician who is responsible for the patient
    3. Physician
Data fields of module 3 are not defined in detail, meaning they can extend to any depth?
Chromosomal anomalies are extremely complex and no universal classification system is available
It is proposed to use best available 'interesting' items for both: coding a genetic variant and a  genomic variant

Developing a registry network for ITHACA

Satellites of ILIAD
The idea is to make ILIAD (the registry) available to organizations that do not allow for full connectivity (because of national laws or institution rules).
This is done via so-called Satellites of Illiad that can be downloaded into these organizations and even allow for NOT UPLOADING information (keeping their segment private)
Connecting ILAD to a range of other registries or systems
  • other ERN registries
  • CPMS, which is primarily used in ITHACA to discuss unknown cases and not patients with a known diagnosis
  • French RD registry BAMARA/BNDMR
  • Patient driven:
  • RETT syndrome registry
  • other diagnosis-based registries

6. Expected Outcomes And Benefits of the Project

  • enabling a new wave of research possibilities from translational to epidemiological research to clinical trials and medico-social issues, as patient cohorts can be identified and baseline dataset is available 
  • unique opportunity to connect patient driven registries to clinical research in Europe
  • reduction of variation in clinical care across countries

7. Work Packages

  1. WP.1 Coordination of the project
  2. WP.2 Dissemination of the project
  3. WP.3 Evaluation of the project
  4. WP.4 IT development: core database and portable registry softwares
  5. WP.5 Connecting core and satellite registries: regulatory aspects
  6. WP.6 Core registry monitoring: activity, e-surveillance of data access and usage
  7. WP.7 Interaction with other registries and biobanks
  8. WP.8 Patients, parents & Ethics
WP.1 Coordination of the project
ensure a good understanding between the 3 main project teams: 
  • the coordination group and the ERN coordinator, 
  • the IT development group and 
  • the registry WG, responsible for the management of the registry and its extension to other non-ERN registries.
WP.2 Dissemination of the project
ensure that the target groups know about and systematically use the registry, making it an indispensable tool and justifying its continuation in the future.
  • the clinical members of the ERN’s HCPs and collaborating ERNs
  • The Patient Council will contribute to dissemination and drive use by specialists in their countries by informing the various ePAGs of the developments of this project and encouraging patients or their families to contribute to patient-fed registries
Evaluation of the project
ensure that these objectives are met according to the schedule planned, and measure their impact on the target groups
WP4: IT development: core database and portable registry softwares
Amongst others specifically relevant to ePag is:
In collaboration with the Registry WG coordinated by the Siena team, the Groningen team will establish an interface to interact with patient databases, registries and biobanks that wish to join the ITHACA central registry. This will require reglementary expertise and audits. Hopefully, these tasks will be shared among ERNs to reduce workload and duplicate processes.
In collaboration with the WG ID coordinated by Nijmegen and Dusseldorf, the Groningen team will establish the basis for interoperability with the Genida registry.
 Is this not also done via WP.7?
WP.5 Connecting core and satellite registries: regulatory aspects
solve regulatory issues related to national legislations of the Member States, and the constrains imposed by the GDPR legislation
WP.6 Core registry monitoring: activity, e-surveillance of data access and usage
the monitoring of the usage of the registry
WP.7 Interaction with other registries and biobanks
federate individual registries in a network whose centre will be ITHACA’s registry, which will be able to integrate queries encompassing these external registries
WP.8 Patients, parents & Ethics
to establish the final rules for data sharing, data access

8. Deliverables

  1. Yearly report
  2. Newsletter
  3. Core registry
  4. Portable registry
  5. Regulatory aspects between HCP
  6. Registry steering Committee
    1. Activity report
    2. Interoperability with one external registry
  7. Registry contacts
    1. Registry interactions
  8. Ethics
    1. Usage

Administrative Deliverables (ADs) & Mandatory Deliverables (MDs)

  1. Leaflet 
  2. Layman version of the final report 
  3. Website 

9. Project management

9.2.4 Role of the PAGs
Almost entirely a direct copy of the text in proposal.
The role of PAGs is to facilitate the involvement of patients (those with “lived experience”), family members, caregivers, and organizations that are representative for patients with congenital anomalies and ID from the design of the registry to the implementation of it. Including ePAGs as partners in the discussion on data content and collection approach can improve the outcomes of the registry in addressing patients needs.  

The main contribution of ePAGs in registry will be in defining the minimum dataset to be collected, the content of   consent form, information regarding the use of data, the level of access and facilitation of the patient’s involvement.  
More generally, including ePAGs as part of the registry team can also help in providing greater transparency.  There is a need of continuous communication among all the stakeholders in order to build trust.
ePAGs can also support the registry team to develop charters or memorandum of understanding (MOUs) in a collaborative manner to help communicate clear roles and responsibilities to assure there is a clear understanding of how all parties will be involved in the registry life cycle. They can also support the initial assessment to determine if training is needed for the registry team to enhance collaboration and communication and put professionals and patients on a more common footing, to engage patients in the team in a meaningful way, and to make sure that they are well prepared to fully contribute to the team’s discussions and decisions. Also they should identify which aspects of the registry will most need patient input.
The registry should have ongoing advisory and governance roles for ePAGs to ensure that the patient perspective is considered. They can also assist in the development of materials that are more appropriate for patients and specifically address questions of interest to patients, to make sure there is linguistic validation and cognitive understanding (materials are written in language that effectively communicates information to the patients).

9.2.5 Access to database:
There are a number of categories of (potential) users defined:
  • ERN HCP members – clinicians and researchers 
  • RD experts not belonging to ERN HCPs
  • RD researchers 
  • patients and families 
  • ePAGs  
  • Member State representatives/policy makers 
  • others...

10. Budget

Max 200.000 € of EU funds (= 60% of total) – requires 133.000 € of co-funding (40% of total) including 23.000 € (7%) of indirect costs to beneficiaries

Over de inhoud van de website:

 

Alle informatie die u hier vindt is ter informatie, geen medisch advies! De plaats voor het vinden van specifieke medische adviezen, diagnoses en de behandeling is uw arts. Gebruik van deze site is strikt op eigen risico. Als u vindt dat iets onjuist is, verduidelijking behoeft, verbeterd kan worden, doe dan mee, meld uzelf aan op onze website en stel een verbetering voor. Mocht u dit liever per email doen dan kan dat ook!

Stuur een email: wiki@waihonapedia.org