AELIP

Asociación AELIP

Top of Page
Menu
Español English Deutsch Francaise

DATA PROTECTION

Data Protection Concept 

OSSE Registry for Lipodystrophy 

Prof. Dr. Martin WabitschProf. Dr. Gabriele NagelJannik Schaaf, M.Sc.Dr. Julia von Schnurbein

Division of Pediatric Endocrinology and Diabetes Department of Pediatrics and Adolescent Medicine University Medical Center, University of Ulm 

Institute of Epidemiology and Medical Biometry, University of Ulm 

3University Hospital Frankfurt, Medical Informatics Group 

Agreed upon by the preliminary Registry Board of the ECLIP registry, consisting of 


Martin Wabitsch
Gabriele Nagel
Jannik Schaaf
Julia von Schnurbein
David Araujo-Vilar
Camille Vater 

Marie-Christine Vantyghem 

Giovanni Ceccarini


1. Introduction 

1.1. Objective 

Given the lack of knowledge on lipodystrophies, the medical and social responsibility for the persons affected by it calls for the monitoring of the progression over long periods of time. 

Sensible clinical and basic research into rare diseases such as lipodystrophy is only possible in multi-location net- works with sufficient case numbers. Also, reliable information on the incidence of certain manifestation patterns, health status, etc. is of utmost importance for health care and health policy. 

The European Consortium of Lipodystrophies (ECLip) has launched a registry (OSSE) for lipodystrophies which is committed to help to improve the research conditions by consolidating this kind of information in one place. 

To this end, data on patients with lipodystrophy will be collected on an international level. In addition, the ECLip registry can be linked to other (e.g. local) registries for lipodystrophies or mortality registries in an IT infrastructure that particularly facilitates the determination of case numbers across registries, but also the recruitment of subjects for clinical studies or the exchange of available data for evaluations to be used in specific research questions. To make these data usable for research, the ECLip registry provides a search interface which makes it possible to 

  •  evaluate whether a sufficient number of subjects with the characteristics required for a given research project is available in the ECLip registry 
  • determine which institutions are currently treating or have treated suitable patients, and 
  • make inquiries concerning the use of these patients’ medical data and biomaterial samples for research 
    purposes. 
  • In doing so, the ECLip registry ensures that data sovereignty remains with the persons in charge of the registry and that data can only be exchanged in a way that precludes the identification of individual patients by choosing appropriate pseudonyms. 

1.2. Data Processing Overview 

The ECLip registry collects and processes data of patients treated in the participating hospitals (also called “locations”). The data are recorded in the following way: 

  • manually via the web-based OSSE user interface. 


The following data are collected: 

  •  Identifying data (IDAT): this includes demographic data (e.g. name, date of birth, sex) that allow for the definitive identification of the patient. They are not stored in the registry but in a separate patient list.
  • Medical data (MDAT): this includes all data on the disease and its course that are recorded in the registry.
  • Data on biomaterial samples: the ECLip registry also contains data on biomaterial samples (see 3.3, “Im- 
    porting Biomaterial Data”).


More detailed information on the data scope can be found in the appendix under 7.3, 

All data fields stored in the registry are registered and described in a metadata repository operated centrally for all registries. The registry structure (master and longitudinal data forms) is defined dynamically by means of a registry editor (see section 7.3, Data Sets- Registry Definition) 

IDAT are stored by the ECLip registry ID management system run by the Institute for Epidemiology and Medical Biometry (server on different site) of the University of Ulm. 

Data in the ECLip registry are exported for analysis with non-traceable export pseudonyms. Data evaluation can be performed within the ECLip registry alone or by joining data from different registries in a so called “decentralized search,” an infrastructure for inquiries that allows networked OSSE registries to be searched for specified cases. In the decentralized search, an electronic inquiry consisting of an exposé of the question, the inquirer’s contact information, and the search criteria, is automatically presented electronically to the registry board together with the results. In case of a data evaluation within the ECLip registry only, this request is handed manually to the board leader. The board then has the option to check the inquiry for content criteria and legal legitimacy and, provided both are positive, to manually answer the inquiry and transmit the data sets if applicable. To facilitate comparability and targeted inquiries for data content in different data sources, the data schema of an OSSE registry is linked to a formal definition of all data fields registered as metadata in the central metadata repository (MDR). 

Sections 2 and 3 provide a detailed description of the components and processes. 


1.3. Legal Basis 

The patient’s informed explicit consent (see section 6.1, “Information and Consent”) constitutes the legal basis of data processing. It explicitly mentions the institutions and persons allowed to process and use specified data. It also considers the sharing of data for research purposes which are quasi-“anonymized” via a non-traceable export pseudonym, since particularly in the area of rare diseases one cannot preclude the possibility of tracing the patient’s identity from the medical data. An inquiry to networked ECLip registry via “decentralized search” is not relevant concerning data protection provisions, as it only yields aggregated data (e.g. number of specified cases) and results are not transmitted automatically. Data transfer requires consent. 


1.4. Governing Body 

The governing body is the Ulm University. 


2. Data Processing Components 

2.1. OSSE Registry 

Components and Features 

The OSSE registry software serves the recording and storage of master and longitudinal medical data of patients affected by lipodystrophy. Data fields and forms are externally registered and described in a metadata repository or form repository, respectively, and can be modified and supplemented even after the beginning of the project. 

Data entry is done at the individual locations via the web-based user interface; additionally, data can also be collected via data import interfaces. All data are stored in a versioned way, i.e. changed and deleted values remain available in the database and can be shown if necessary (This excludes deletions as per a patient’s request; see comments on the right of withdrawal in section 6.3)

Identifying data are not recorded into the OSSE registry but directly into the identity management system. Communication between the identity management and the OSSE registry happens via a web browser. The user sees the ID management’s entry mask integrated into the OSSE registries’ user interface. The returned pseudonym, “PSNOSSE“ (see section 2.2), is stored with the MDAT, but not shown, so that is impossible to correlate IDAT and PSNOSSE outside the ID management system even manually. However, since medical data are recorded locally close to the time of treatment, IDAT and MDAT can be shown in the browser together. This is done by way of temporary identifiers via which the browser retrieves e.g. a patient’s first and last name and which ensure that the correlation between PSNOSSE and the patient’s IDAT does not become known outside the ID management. 


Workflow 

Medical data are recorded into forms (master and longitudinal data forms) that can take on the following status values during data processing: 

The configuration contains a preconfigured workflow through which each form can receive one of the following status values: 

 ✓  Open: the form is being edited 

 ✓  Reported: editing of the form is complete 

 ✓ Validate: the entries were checked and considered valid by the curator 
The following status transitions are possible: Open -> reported, reported -> validated, validated -> open 


Users, Roles, and Rights 
Access rights are granted based on roles. Depending on his/her position, each user has one or several roles with which he/she logs in. To define access rights, data are classified particularly concerning their attribution to the informational unit in which they were collected. The following roles are available for ECLip registry according to the declaration of consent, participating locations, and organizational requirements: 

✓ IT administrator
Can see and change all data and even combine IDAT and MDAT if necessary
Can merge and delete patients
Can create new users and appoint or change roles for them
Can enable physicians from other institutions to view data set from an institution asking for a second opinion from this physician
Can upload new registrations and updates to the registry 


✓ Curator

Can see and correct MDAT and institution who entered the data once data is marked as reported 

 Can give feedback to the centers if MDAT does not seem correct
Is the only person who can validate entries 


✓ Board leader
Receives all research inquiries including manual search enquiries by external researchers 


✓ Clinical user
Can enter new patients or new data
Can view all patients data from his/her institution 


✓ Research user
Can post a manual search 


✓ Patient user
Can view his/her own data without being able to change it 


Each user can also request to become a research user in addition to his/her other role. Each access is recorded (see section 5.3 “IT Infrastructure Provisions”). 


2.2. Identity Management 

Pseudonymization is a necessary measure to keep a high level of data protection in order to protect the patient from reverse identification. His/her identifying data (IDAT) are substituted by pseudonyms. When a pseudonym is requested, the data set is checked for correspondence with existing data sets (record linkage). Depending on the degree of IDAT correspondence and on the threshold values set, a new data set is created or an existing one returned. 


Pseudonyms 

For pseudonymization, ECLip registry uses an instance of a pseudonymization tool (the Mainzelliste run by Institute of Medical Biometry Ulm University. It creates a unique identifier (PID) and a second-level pseudonym) (PSNOSSE(#)) for each patient. 


Manual Linking 

An interface allows a person to check and, if necessary, correct the results of automated matching, i.e. to merge duplicates or separate falsely merged data sets. To do so, the match weights (reference values to compare the individual attributes of patients to be checked) are shown and it is possible to draw on medical data to make a decision. 


2.3. Biobank 

The ECLip registry does not set up a biobank database. Existing samples (will) may be stored locally and organizational data attached to this will be entered manually into the registry (see section 3.3). For specific research pur- poses, a temporary sample collection point can be set up. A specific additional patient approval for this purpose might be applicable according to the regulations of each local ethic committee. 


2.4. Metadata Repository 

The Metadata Repository (MDR) stores the meaning (semantics) of all (reference) data elements used in the ECLip registry. It offers a controlled vocabulary (syntax) and can provide machine-readable, structured information on data elements, e.g. conceptual domains or value ranges. Furthermore, it defines the fields of the registry forms specified in this concept (see section 7.3, “Data Sets”). Since the MDR does not process personal data, it will not be treated in more detail here. 


3. Data Processing Procedures 

3.1. Manual Data Entry
Creating a Patient Record 

 1)  The user enters the IDAT into the Mainzelliste entry form integrated into the OSSE registry. 

 2)  The OSSE registry receives a pseudonym (see section 3.2 for further detail) that is stored together with the data set. The user does not receive feedback on whether the patient record is already present in the Mainzelliste or a new record was created. 


Selection of Patients, Data Entry 

The user receives a list of patients (with real names) depending on his/her access rights. After selecting a patient, he/she can edit forms, and the browser window shows IDAT of the selected patient. 


Manual Sharing of Data Sets 

In justified cases, e.g. when requesting second opinions, data sets can be shared with defined persons and roles. The share includes individual forms or complete cases (all forms of a patient at the respective location). The user performing the share must be explicitly authorized to do so. A share is valid only for a limited period. The user selects a patient data set for sharing. In the dialog window “share data set”, he/she determines the user or role to be authorized and the validity period. The data share has to be covered by the access rights and purposes described in the patient informed consent. 


3.2. Pseudonymization 

Pseudonymization is part of any kind of data collection into the OSSE registry – manual data entry and automated data import.

 

Manual Patient Registration 

For both the registration of a new and the retrieval of an existing patient data set, the user enters identifying data into a pseudonymization tool (the Mainzelliste) entry form displayed in the OSSE GUI browser window. The identifying data have to be entered completely, since drop down lists familiar e.g. from clinical workspace systems cannot be displayed here upon entering name parts. A record algorithm checks whether the patient has already been registered in the Mainzelliste. If not, a new patient record is created by storing the IDAT and producing a non- speaking PID as well as the PSNOSSE as a second-level pseudonym. The user is then automatically redirected to a website of the OSSE registry where MDAT for the newly created or selected patient record can be entered. In doing so, the browser and the OSSE registry communicate by way of temporary identifiers. The PSNOSSE does not become visible for the user, i.e. it does not appear in the HTML code of the forms displayed or in the browser’s HTTP inquiries either. This procedure ensures that PSNOSSE and IDAT cannot be correlated outside the Mainzelliste at any point. 

During MDAT entry into the OSSE registry, which takes place locally and close to the time of treatment, the patient’s identifying data are shown in the browser. These are correlated to the MDAT only in the browser, so that the OSSE registry does not get access to IDAT at any point. For that purpose, the registry software retrieves a session-based temporary ID for each PSNOSSE from the Mainzelliste, with which the browser then receives the corresponding IDAT from the Mainzelliste. 

The pseudonyms stored in the OSSE registry are never displayed or released, so that they cannot be assigned to a patient either at data entry in the treatment context or by merging exported data. Re-identification (de-pseudony- mization) can only be performed in a controlled manner by means of the Mainzelliste. 


3.3. Importing Biomaterial Data 

When biomaterial samples exists, they will be stored locally together with the respective data (IDAT, LabID, further characteristics of the sample). When a patient’s data is entered into the ECLip registry, information on the existence and number of samples as well as sample characteristics (whole blood, serum, etc) is also entered. This will enable researches the identification of those patients in the registry that are suitable for a particular research project. 

When a centralized evaluation of a certain set of samples is planned, a temporary sample collection point can be formed for this purpose. A specific additional patient approval for this purpose might be applicable according to the regulations of each local ethic committee. To create such collection point the following steps apply: 


  1.  The local treatment center requests an encrypted OSSE pseudonym (PSNOSSE)tr from the IT administrator 
  2.  The sample is sent to the sample collection point together with 

 a. the address label containing the (PSNOSSE)tr, and the locally created LabID 

 b. all necessary sample data (date of sample taking, sample processing, etc). 

 3)   The sample is registered in the sample collection module: the sample collection module stores 
 a. LabID 

 b. all necessary sample data (date of sample taking, sample processing, etc). 


 4)  At the sample collection point, the LabID will be changed into a LabIDtr through a cryptographic process, in order to avoid direct correlation of the patient and sample. The correlation of (PSNOSSE)tr and LabIDtr 
is stored temporarily. 

 5)  The sample collection point enters into the OSSE registry a data set consisting of 

 a. (PSNOSSE)tr, 

 b. LabIDtr 

 c. further information on the sample (see above) 

 6)  After successful transfer, the link between (PSNOSSE)tr and LabIDtr is deleted in the sample collection point. 


3.4. Data Export 

Data can be exported for analysis. For this purpose, the OSSE registry’s internal pseudonym is substituted by an export pseudonym during export. 

If data from different registries are brought together in the context of decentralized search, uniform non-traceable export pseudonyms are queried with the local ID management upon export. These facilitate consistent updates of the combined data sets, but identical patients from different registries are not recognized. The export takes place in the following steps: 

 . 1)  OSSE sends the internal pseudonym PSNOSSE(#) to the ID management along with a project identifier. 

 . 2)  The ID management returns a project-specific export pseudonym (PSNProjekt). 

 . 3)  The data set is exported with the PSNProjekt. 

Particularly in diseases with low case numbers, if the course of disease or additional data are known, medical data can be related to specific patients even without knowing the identifying data. Even the use of non-traceable export pseudonyms cannot always guarantee factual anonymity. 

For this reason, the export of pseudonymized data and the purpose of their use are considered in the patient informed consent. 


3.5. Data Search 

When researchers (external or internal) want to perform a research project with data of the ECLip registry, formal requests based on the so called “data evaluation form” including the respective data elements will be handed in to the board leader. After official decision on this request (according to the Data usage SOP) and contract signing, the IT administrator will search the databases of the ECLip registry in order to find data and samples potentially relevant to a research project. The IT administrator will use the export function to filter data elements by preset values or free-text search. Several search attributes can be combined at will via logical operators. The person from the regis- try board, assigned to be the contact person for this specific research project will than view the data sets found and subsequently contact the inquiring researcher to arrange a potential data transfer. This process and the data protection issues associated with it, e.g. the necessity to obtain further consent, have to be clarified for each individual case by the participating parties. Data transfer happens in a controlled way outside the OSSE registry. 

If more than one OSSE register is to be searched, the search can be combined in a so-called decentralized search. Through decentralized search, external researchers can search the databases of OSSE registries or bridgeheads in order to find registries containing data and samples potentially relevant to a research project. The search broker provides a web-based search form to record the inquiries that filter data elements by preset values or free-text search. Several search attributes can be combined at will via logical operators. The search form also transmits an abstract of the intended research project and the inquiring researcher’s contact information. 

In a first step, the inquiry is saved and the external researchers receives a corresponding notification. The participating registries’ share clients fetch new inquiries from the search broker at regular intervals and determine which data sets in the OSSE registry match the search criteria. For each registry, an authorized person can view the inquiry’s content (in case of the ECLip registry this is the curator) and the data sets found and subsequently contact the inquiring researcher to arrange a potential data or sample transfer. This process and the data protection issues associated with it, e.g. the necessity to obtain further consent, have to be clarified for each individual case by the participating parties. Data transfer happens in a controlled way outside the OSSE registry. 


3.6. Uploading Information to the Registry of Registries 

Information on the OSSE Registry Lipodystrophy (new registrations and updates) can be uploaded to the registry of registries through a menu feature executed by an authorized user. The scope of information to be uploaded can be set in the registry configuration. This does not apply to registry content data (see section 1.1). 


4. Organizational Framework 

4.1. Operation of Components 

The ECLip registry is operated by Ulm University. Data recording locations for the registry will be listed in the appendix. This list will grow as new members will join the registry. 

Operation of the ECLip registry central components is managed by selected institutions appointed upon agreement with the registry’s registry board. For the purpose of the informational separation of powers, the organizational framework ensures independent operation of ID management and OSSE registry (see section 5.1, “Informational Separation of Powers”). The different parties are shortly described here. For more detail please refer to “Organization of the ECLip Registry”. 


4.2. Participating Researchers 

Participating Researchers are individuals who can place inquiries to the board leader. Generally, all members of the registry locations can use ECLip registry as participating researchers, with each location deciding by itself which of its members are granted access (see also section 5.2, „Authorization and Authentication“. 


4.3. ECLip Registry Members 

Any clinician/participating researcher sharing their data in the ECLip registry can apply to become Registry Member. Each institute with at least one Registry member participates in the registry’s members poll with one vote. Among others, the duties of the Registry Members include: 

  •  Review and approval of requests to use the ECLip registry by external researchers(decentralized search) 
  • Review and approval of requests to export medical data for external research projects 
  • Elect the Registry Board 

4.4. Registry Board 

The registry board is elected by the ECLip registry members to manage the registry’s business. Among others its duties include: 

 ✓ Control and support of governing body of registry.

 ✓ Appoint, control and support local operating group 

 ✓ Vote on research proposals from Registry Members 

 ✓ Consider research proposal from third parties and put a suggestion to the Registry Members

 ✓ Review and approval of requests to notify affected patients of research results 


The Registry Board is staffed in a way that some of the ECLip registry locations are represented. Whenever possible it should also include: 

 ✓  A doctor mainly working with affected patients 

 ✓  A scientist researching with the data administered in the ECLip registry (or similar data) 

 ✓  A representative of the LOG (see below) 


4.5. Local Operating Group (LOG) 

The ECLip registry board appoints a local operating group in charge of the following duties, among others: 

 ✓  first point of contact for data protection issues 

 ✓  Maintenance of the medical data set 

A representative of the ECLip registry developer team can be consulted to provide advisory support. 


4.6. Access by System Administrators 

Generally, the data stored in ECLip registry can be viewed by the administrators of the IT infrastructure used. Administrators may only access the data if it is essential to performing their duties. The data access procedure is regulated as follows: Administrators use only functions for the administration of the data capture forms, data elements and user rights. Administrator do not get an overview of the patient and medical data viewing area. All administrators have to be instructed accordingly and agree to maintain confidentiality3


(I.e. individuals not affiliated with any of the ECLip registry locations.
Usually, this should already have happened in the context of the individual’s work contract with the institution in charge.) 


5. Data Protection Provisions 

5.1. Informational Separation of Powers 

ID management is operated separately (logically, physically, and organizationally) from all components storing MDAT or data on biomaterial samples. The institution in charge of ID management (the Institute for Medical Biometry of the Ulm University) operates its own legal responsibility and is not subject to the directives of the registry management. This ensures that individuals with access to clinical or biomaterial data in the ECLip registry outside the treatment context are not able to correlate the data to real patients. 

5.2. Authorization and Authentication 

User Authorization 

User authorization (assigning defined roles to users) in the OSSE registry is done by the IT administrator working at Ulm University 

Authorization of Components 

Mutual access between IT components is defined in the respective configuration. To do so, the accessing system’s IP address and a password are recorded. 

User Authentication 

User Authentication for the ECLip registry is done via a username and password. 

Authentication of Components 

Mutual access between IT components via the internet takes place only upon successful authentication. Authentication happens on the server side via server certificates and on the client side (depending on technical options) via IP address and username/password or via client certificates. 


5.3. IT Infrastructure Provisions 

Security of Stored Data 

All data collected in the central components of the ECLip registry are stored on encrypted hard drive partitions. The corresponding key is located on a separate medium each per server (e.g. paper, USB stick). This medium is only required during mounting or booting and stored securely otherwise. Only the respective server’s administrator has access to “his/her” key medium. All servers are located in data centers only accessible for authorized individuals. 


Security of Communication 

Confidentiality of communication between components is ensured by the following measures: 

 ✓  Communication between components generally occurs via encrypted connections (HTTPS). The keys and certificates used for this purpose must be generated in a way that corresponds to the current recognized requirements (e.g. key length). Current requirements can be found in the manuals for basic IT security of the German Federal Office for Information Security (https://www.bsi.bund.de/DE/Themen/ITGrund- schutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html). 

 ✓  Firewalls ensure that the servers running the central components can only be reached via those protocols and ports that are required for the communication with users or other components (usually HTTPS connec- tions). Administrative access is restricted to the managing institution’s intranet and the OSSE team. 


Logging 

Access by researchers to components as well as access between components is logged. The record contains at least: 

 ✓  The accessing person’s or component’s identity 

 ✓  Access date and time 

 ✓  Access content (transmitted data, in aggregated form if necessary) or information from which the content can be reconstructed (e.g. reference to a database entry or similar) 
The record is stored together with the respective server’s payload for a period of one to six months. The recorded data must only be viewed for technical administration (particularly for troubleshooting) and in order to track abuse. 


6. Observing the Rights of Affected Individuals 

6.1. Information and Consent 

The patient informed consent (see appendix for full text) provides the legal basis for data processing. With it, the patient particularly agrees that 

 ✓  his/her identifying data are transferred to ID management and stored there, 

 ✓  Medical data and data on biomaterial samples are recorded in the OSSE registry according to the registry 
definition, 

 ✓ Researchers of the ECLip registry can analyze these data locally and search them via decentralized search, 

 ✓  The patient’s medical data and data on biomaterial samples can be exported from the OSSE registry via a non-traceable export pseudonym and transferred to external researchers for those research purposes as specified in the informed consent. 
The patient is informed of his right to information and revocation upon obtaining consent. 


6.2. Information on Stored Data 

Patients recorded in the ECLip registry have the right to receive information on the data stored in the registry. The information request has to be placed in writing and addressed to the treating hospital. The hospital requests a data export via the interface and receives an export pseudonym for the patient. The registry administrator carries out the export and produces a human-readable printout of the data, which he seals, marks with the export pseudonym and sends to the hospital in charge, where it can be handed over to the patient. If the data contain genetic results, it is mandatory that they be handed over in the context of a consultation by a treating doctor. On request, a patient can also be granted direct access to his/her medical data. 


6.3. Revocation, Deletion, Anonymization 

Patients have the right to revoke their agreement on the processing of their data in the ECLip registry. The revoca- tion has to be placed in writing and addressed to the treating hospital, which passes it on to the registry board. Together with the revocation, the patient concerned can request the complete deletion of his/her data. If the latter request is missing, and if the data base allows for a factual anonymization, the data are anonymized. If “reasonable”anonymization is not possible due to low case numbers and specific characteristics, the data are deleted. This procedure excludes data that already form the basis of a published or already ongoing study.These data are then protected in a special way (e.g. archived separately) and access to them is denied. 

After reviewing the revocation, the registry board decides on the request to deletion. In case of deletion, all data sets associated with the patient are deleted from the Mainzelliste and the OSSE registry. In case of anonymization, the data sets are deleted from the central patient list and the patient’s PSNOSSE is substituted with a random pseudonym. If data have been archived, this procedure is repeated for the archived data sets as well. The algorithm creating the pseudonyms ensures that the pseudonyms of a deleted/anonymized patient record are not used for new patient records. 

The deletion or anonymization has to be carried out by the registry managers in charge promptly, no later than 14 workdays after the request was placed.The patient is informed of the completed deletion or anonymization in writing. 


6.4. Storage Period 

The collected data will be stored in the OSSE registry as long as they can sensibly be used within the limits of the patient informed consent. In case the data can no longer be used as intended, the registry board reviews whether there are legal grounds for a different use of the data, in anonymized form if applicable. If this review turns out negative, the data must be deleted. 


(Anonymization has to result in a minimum number of cases with the same characteristics so that patients cannot be identified based on their medical data. This is achieved e.g. through coarsening the characteristics into categories (e.g. age cohorts). Such coarsening only makes sense, though, if the original goal of the data processing can still be reached.
§20 German Federal Data Protection Act 

The usually impracticable deletion or anonymization in data backups can be foregone if the backups can only be viewed by the system administrator in charge and old backups are deleted regularly.) 



7. Appendix
7.1. OSSE Registry Patient Informed Consent 

An adult patient consent form in English language as a master form is provided. In addition, each center will develop adapted consent forms according to the demands of each local ethic committee. 


7.2. List of institution entering data into the ECLip registry 

The list of data recording locations for the registry will grow as new members will join the registry. In general, any institution caring for patients with lipodystrophy can apply at the registry board to be included: 


  •  Complexo Hospitalario Universitario de Santiago de Compostela, Division of Endocrinology and Nutrition, Unit of Lipodystrophies, Santiago de Compostela, Spain 
  •  Biologie et Génétique Moléculaires et Endocrinologie, Hôpital Saint-Antoine, INSERM UMR_S 938, Paris, France 
  •  Lille University Hospital, Service d'Endocrinologie et Métabolisme, INSERM U859, CHRU de Lille , Lille, France 
  • University Hospital of Pisa, Division of Endocrinology, Pisa, Italy 
  •   IMS MRL; University of Cambridge, UK 
  • University of Leipzig, Division of Endocrinology, Leipzig IFB Lipodystrophy Centre, Leipzig, Germany 
  •  IGM-CNR, Unit of Bologna c/o IOR, Bologna, Italy 
  •  Endocrinology Unit, Dept. of Clinical Medicine, S. Orsola-Malpighi Hospital, , Bologna, Italy 
  •   Lab of Medical Genetics, Tor Vergata University – Policlinico of Tor Vergata, Rome, Italy 
  •   Department of Pediatrics H7-236, Academic Medical Center, University of Amsterdam,Amsterdam, Netherland 
  •   Department of Metabolic Diseases, Jagiellonian University, Medical College, Krakow, Poland. 
  •   Sechenov First Moscow State Medical University, Endocrinology Department & Federal Scientific Centre of Endocrinology, Moscow, Russia 
  •  Department of Medical Genetics, Children’s hospital la Timone, INSERM UMR_S 910, Marseille, France
  •  Klinik für Transplantationsmedizin, Universitätsklinikum Münster, Münster, Germany 
  •   Dokuz Eylul University School of Medicine, Dept Internal Medicine, Div Endocrinology, Turkey 
  •   Serviço de Endocrinologia do Centro Hospital São João, Universidade do Porto, Porto, Portugal 
  •   Ulm University, Division of Pediatric Endocrinology, Diabetes and Obesity Unit, Germany 


 
Este sitio web utiliza cookies para facilitar y mejorar la navegación. Si continúas navegando, consideramos que aceptas su uso. POLITICA DE COOKIES