This page is part of the MII Implementation Guide Consent (v2027.0.0-ballot: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Security and Privacy

This page includes translations from the original source language in which the guide was authored. Information on these translations and instructions on how to provide feedback on the translations can be found [here](translationinfo.html).

This section is addressed to security and privacy professionals. General requirements are covered in the FHIR core specification — the Security & Privacy Module and the security checklist. This page does not repeat them; it links the overarching data protection framework and states what is specific to this module.

1. The overarching data protection concept

The overarching data protection concept of the Medical Informatics Initiative governs how patient data may be processed for research across the network of Data Integration Centers: the legal basis (the MII Broad Consent), the roles of the Data Integration Centers and the Use & Access Committees, as well as the cross-site application scenarios (feasibility queries, distributed analyses, provision of data and biosamples). Everything this module specifies stays within this framework — this guide adds no processing purpose of its own.

2. De-Identification, Minimisation, and Pseudonymisation (DIMP)

How data leaving a Data Integration Center is de-identified in practice is specified by DIMP (De-Identification — Minimisation — Pseudonymisation) in the Data Portal documentation: direct identifiers are removed, data elements not needed by the approved project are dropped, and identifying values are replaced with project-specific pseudonyms (FHIR Pseudonymizer configuration). The profiles of this module describe the data before DIMP is applied; which elements reach a concrete data delivery is decided per project by the DIMP configuration, not by this guide.

3. Module-specific aspects

Since the FHIR Consent resource likewise contains no person-identifying information about the consenting person, the pseudonymous person reference should be established via appropriate pseudonymous identifiers. Any person-identifying information (e.g. date of birth, gender, address) as well as references, e.g. to (clear-text) patient profiles, should be suitably replaced before data are exported.

Technically, Patient resources and derived profiles can be used, such as the profiles of the AG Einwilligungsmanagement or the MII. Independently of this, in order to be able to distinguish pseudonyms, case numbers, etc., a categorisation of the identifier used is required via patient.identifier.type.

The FHIR Consent resource contains no document scans and/or signatures. If transmission is required for a given use case, separate resources must be created in accordance with the specifications of the AG Einwilligungsmanagement (Consent Bundles).