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 Wabitsch1 Prof. Dr. Gabriele Nagel2 Jannik Schaaf, M.Sc.3聽Dr. Julia von Schnurbein1聽

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

2 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 鈥渓ocations鈥). 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, 鈥淚m-
    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 鈥渄ecentralized 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鈥檚 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鈥檚 informed explicit consent (see section 6.1, 鈥淚nformation 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-鈥渁nonymized鈥 via a non-traceable export pseudonym, since particularly in the area of rare diseases one cannot preclude the possibility of tracing the patient鈥檚 identity from the medical data. An inquiry to networked ECLip registry via 鈥渄ecentralized 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鈥檚 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鈥檚 entry mask integrated into the OSSE registries鈥 user interface. The returned pseudonym, 鈥淧SNOSSE鈥 (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鈥檚 first and last name and which ensure that the correlation between PSNOSSE and the patient鈥檚 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
o Can see and change all data and even combine IDAT and MDAT if necessary
o Can merge and delete patients
o Can create new users and appoint or change roles for them
o Can enable physicians from other institutions to view data set from an institution asking for a second opinion from this physician
o Can upload new registrations and updates to the registry聽

  • Curator
    o Can see and correct MDAT and institution who entered the data once data is marked as reported聽

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

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

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

✓ Research user
o Can post a manual search



✓ Patient user
o 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 鈥淚T 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, 鈥淒ata 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 鈥渟hare 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鈥檚 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鈥檚 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鈥檚 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鈥檚 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 鈥渄ata 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鈥檚 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鈥檚 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鈥檚 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, 鈥淚nformational Separation of Powers鈥). The different parties are shortly described here. For more detail please refer to 鈥淥rganization 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, 鈥濧uthorization 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鈥檚 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 researchers2 (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鈥檚 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.聽


(2 I.e. individuals not affiliated with any of the ECLip registry locations.
3 Usually, this should already have happened in the context of the individual鈥檚 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鈥檚 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鈥檚 administrator has access to 鈥渉is/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鈥檚 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鈥檚 or component鈥檚 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鈥檚 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鈥檚 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 鈥渞easonable鈥4 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.5 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鈥檚 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.6 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.聽


(4 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.
5 搂20 German Federal Data Protection Act聽

6 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鈥檚 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