MII Implementation Guide Consent
2027.0.0-ballot -
Germany
MII Implementation Guide Consent
2027.0.0-ballot -
Germany
MII Implementation Guide Consent - Downloaded Version 2027.0.0-ballot See the Directory of published versions
This page bundles the implementation-related sections of the original guide: the technical implementation, the context within the overall project, the references, and the recommendations for practical use.
This section describes the syntactic and semantic requirements for implementing the Consent module.
Furthermore, search parameters are defined that must be implemented by the respective systems when using the FHIR RESTful API. In general, logical AND and OR combinations of the FHIR search are supported, cf. https://www.hl7.org/fhir/search.html .
Fundamentals and further details on search and on the FHIR RESTful API are, at the time this implementation guide was created, being developed within the scope of the base modules and may supplement the specifications made here at a later point in time. If necessary, a new version of this guide will then also be published.
The Consent module serves to support cross-site data use requests based on the patient's current consent status at the respective site.
To establish the relation between person and consent, the consent is assigned at least one unique person identifier (base module: Person). As a rule, this is a pseudonymous identifier.
In version V1 of the guidance document on the patient information & declaration of participation for the "Modellvorhaben Genomsequenzierung bei seltenen und bei onkologischen Erkrankungen" pursuant to § 64e SGB, chapter 2.1.4 Research Consent recommends using the MII Broad Consent from version 1.6d onwards, which in the legal sense corresponds at least to the base version without additional modules.
The modelling of the data set for the Consent module contains references to the following projects:
In addition, the core specification of HL7 FHIR, including the corresponding resource Consent, and the previous work on the German base profiles in STU3 and R4 were taken into account.
The present specification was designed on the basis of the description of the MII core data set in the version dated 10.3.2017 (PDF), as well as the data set description in ART-DECOR.
The significance of the ResultType parameter is explained comprehensively in the IG of the HL7-D AG Einwilligungsmanagement and the corresponding publication.
Particular attention should be drawn here to the codes consent-status and document. Further details and interrelations are described here.
In practice, concrete mandatory project requirements for the use of the ResultType search parameter are only of limited benefit due to the heterogeneous technical conditions at the MII sites. The technical realisation of the requirements depends on the concrete implementation.
The consent management system gICS constitutes the current reference implementation of the HL7-D FHIR standard for consent management (version 2.0).
All implementations should support at least the following variants. The cardinality of Consent.category is defined as 2..* and enables the necessary backwards compatibility.
| ResultType | Meaning for the Consent resource | Aggregation of information |
|---|---|---|
document |
The Consent resource refers to one (!) completed document (QuestionnaireResponse). This should be the default in an (MII) FHIR server. | no |
consent-status |
The Consent resource takes into account all relevant consent and withdrawal documents in the context of the MII for one (!) patient . The Consent resource with ResultType consent-status always refers to one patient and contains the current consent status. This should ideally be supported by the (MII) FHIR server. |
Yes, computed by appropriate business logic at the time of the query or for a specific period. |
Ideally, the FHIR server should always hold only one Consent resource per patient containing the current aggregated consent information (ResultType consent-status).
If this is not possible for other reasons, a document-specific export should be enabled at least per completed document (consent, updated consent, partial withdrawal, complete withdrawal) (ResultType document). In this case, it remains the responsibility of the site to provide this information in the form required by the FDPG.
The data integration centres provide the information required to determine core-data-set-specific metrics for the DIZ Dashboard. On the DIZ Dashboard side, the determination of the metrics is triggered by corresponding calls to the sites, including for the MII KDS Consent module.
Sites using the gICS consent management system should follow the precise vendor recommendations for metrics determination as well as when providing the Consent resources for the FDPG.