|
Type
|
Reference
|
Content
|
|
web
|
example.com
|
https://example.com/fhir/Binary/document
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
|
|
web
|
github.com
|
Konformität
|
|
web
|
github.com
|
Konformität
|
|
web
|
github.com
|
Allgemeine Anforderungen
|
|
web
|
github.com
|
Must-Support
|
|
web
|
github.com
|
Umgang mit fehlenden Daten
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
IG © 2024+ NUM-DIZ
.
Package de.medizininformatikinitiative.kerndatensatz.studie#2027.0.0-ballot basiert auf FHIR 4.0.1
.
Erstellt 2026-09-14
Links: Inhaltsverzeichnis |
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.medizininformatik-initiative.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
github.com
|
Woher die Versionen kommen.
Jedes Paket der Tabelle ist direkt in
sushi-config.yaml
( dependencies:
) gepinnt — auch hl7.terminology.r4
(THO) und
hl7.fhir.uv.extensions.r4
, und diese beiden mit Bedacht: Die
Automatik des IG Publishers
liest ausschließlich die eigene
Abhängigkeitsliste dieses Leitfadens;
ohne direkten Pin würde jeder Build stillschweigend das jeweils aktuellste
THO-/Extensions-Release injizieren — eine allein im MII-Meta-Paket gepinnte
Version kann den Build nicht steuern (verifiziert im Publisher-Quellcode des
gepinnten Release). Eine wöchentliche Prüfung warnt, wenn diese beiden Pins
von den Vorgaben des gepinnten Meta-Pakets abweichen; die von einem
konkreten Build verwendeten Versionen stehen in dessen qa-versions.json
.
|
|
web
|
ucum.org
|
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Show Usage
|
|
web
|
github.com
|
Expansionsparameter sind Query-Parameter, die an eine ValueSet
-
$expand
-Operation übergeben werden können, um zu steuern, wie das ValueSet
expandiert wird — also wie die vollständige Liste der Codes aus der
ValueSet-Definition erzeugt wird. Die für diesen IG verwendeten
IG-Parameter
sind in
sushi-config.yaml
( parameters:
) deklariert. Ein Modul, das seine Expansionsparameter über ein
CRMI-Manifest pinnt, verlinkt hier zusätzlich die generierte
Parameters
-Ressource (siehe die auskommentierten Manifest-Blöcke in
sushi-config.yaml
und die Seite Metadata Overview, sofern das Modul sie
behält).
|
|
web
|
www.omg.org
|
ServD
|
|
web
|
ihe.net
|
XDS metadata equivalent
|
|
web
|
siframework.org
|
Quality Improvement and Clinical Knowledge (QUICK)
|
|
web
|
keepachangelog.com
|
Diese Seite hält die Änderungen zwischen den veröffentlichten Versionen des
Moduls Medizinisches Forschungsvorhaben
fest, die neueste Version zuerst. Sie folgt
Keep a Changelog
und dem
KDS-CalVer-Schema, das die Seite Versionierung
beschreibt.
|
|
web
|
mii-termserv.de
|
Wichtig:
CodeSystem-Ressourcen externer Terminologien (z. B. ICD-10-GM, OPS,
SNOMED CT) werden in diesem Modul nicht
publiziert, sondern über den
zentralen KDS-Terminologieserver (SU-TermServ) bezogen:
https://mii-termserv.de/
.
|
|
web
|
github.com
|
Datensätze und Beschreibungen
— die Datenelemente
des Moduls, beschrieben als logische Modelle. (Dieser Eintrag teilt sein Ziel
mit Artefakte → Logische Modelle
; keiner der Anker der Artefakt-Übersicht
ist als Linkziel nutzbar — siehe
docs/page-structure.md
in diesem Repository.)
|
|
web
|
github.com
|
Für die KDS-weiten Konformitätsanforderungen siehe die
Konformitätsregeln des Meta-Moduls
;
für die technischen Artefakte siehe Profile
.
|
|
web
|
forschen-fuer-gesundheit.de
|
Die vorliegende Version wurde zusammen mit Vertretern des Deutschen Forschungsdatenportals Gesundheit
(FDPG) diskutiert.
Der vorliegende Entwurf wurde zusammen mit Vertretern der Nationalen Forschungsdateninfrastruktur für personenbezogene Gesundheitsdaten
(NFDI4Health) diskutiert.
Der vorliegende Entwurf wurde zusammen mit Vertretern aus anderen öffentlich geförderten Netzwerken und Industriepartnern erstellt. Es wurde auf die sich daraus möglicherweise ergebenden Interessenkonflikte geachtet.
|
|
web
|
www.nfdi4health.de
|
Die vorliegende Version wurde zusammen mit Vertretern des Deutschen Forschungsdatenportals Gesundheit
(FDPG) diskutiert.
Der vorliegende Entwurf wurde zusammen mit Vertretern der Nationalen Forschungsdateninfrastruktur für personenbezogene Gesundheitsdaten
(NFDI4Health) diskutiert.
Der vorliegende Entwurf wurde zusammen mit Vertretern aus anderen öffentlich geförderten Netzwerken und Industriepartnern erstellt. Es wurde auf die sich daraus möglicherweise ergebenden Interessenkonflikte geachtet.
|
|
web
|
www.medizininformatik-initiative.de
|
Den ersten Release finden Sie unter 2025.0.0
|
|
web
|
www.medizininformatik-initiative.de
|
Das MII KDS Modul Medizinisches Forschungsvorhaben ist als Modul des Kerndatensatzes (KDS) der Medizininformatik-Initiative (MII)
entstanden.
|
|
web
|
github.com
|
Konformität
— die KDS-weiten Konformitätsregeln (Anforderungssprache,
Must-Support, Umgang mit fehlenden Daten) pflegt zentral das
Meta-Modul
;
die modul-spezifischen Aspekte zu
Sicherheit und Datenschutz
sind Teil dieses
Leitfadens.
|
|
web
|
www.medizininformatik-initiative.de
|
Dieses Modul ist Teil des MII-Kerndatensatzes; die weiteren KDS-Module und ihre
Abhängigkeiten sind unter
medizininformatik-initiative.de
beschrieben.
|
|
web
|
github.com
|
Weitere FHIR-Implementierungsleitfäden finden Sie im offiziellen
FHIR IG Registry
(Quelle:
FHIR/ig-registry
).
|
|
web
|
github.com
|
Anmerkungen und Kritik wird in Form von 'Issues' im GitHub-Repository
gern entgegengenommen.
|
|
web
|
creativecommons.org
|
© 2019+ TMF e. V., Charlottenstraße 42, 10117 Berlin.
Dieses Werk ist lizenziert unter der
Creative Commons Namensnennung 4.0 International Lizenz
.
|
|
web
|
creativecommons.org
|
|
|
img
|
licensebuttons.net
|
|
|
web
|
github.com
|
Die folgenden CRMI-Metadaten werden in
sushi-config.yaml
gesetzt und landen in der erzeugten ImplementationGuide
-Ressource.
|
|
web
|
github.com
|
Veröffentlicht ein Modul CodeSystem-Supplements, ist zu beachten: Das
CRMI-Profil ShareableCodeSystem
verlangt CodeSystem.caseSensitive
, während
die FHIR-Validierung warnt, dass ein Supplement caseSensitive
nicht erneut
angeben sollte, weil das dem ergänzten CodeSystem widersprechen könnte.
kerndatensatz-basis
beansprucht deshalb bei Supplements nur das Publishable
-CRMI-Profil und lässt
das Shareable-Profil weg.
|
|
web
|
www.go-fair.org
|
Die FAIR-Prinzipien
beschreiben
Ziele dafür, digitale Objekte auffindbar (Findable), zugänglich (Accessible),
interoperabel (Interoperable) und wiederverwendbar (Reusable) zu machen. Dieser
Abschnitt ist eine informative Selbsteinschätzung, wie die CRMI-Metadaten dieses
Leitfadens eine FAIR-konforme Veröffentlichung von FHIR-Spezifikationsartefakten
unterstützen.
|
|
web
|
ig.fhir.de
|
Die Arbeiten der Kerndatensatzspezifikationen basieren, wo möglich, auf internationalen Standards und Terminologien. Insbesondere sei hier die International Patient Summary
hervorgehoben. Eine Anpassung an die allgemeinen Gegebenheiten des deutschen Gesundheitswesens erfolgt durch die Verwendung der Deutschen Basisprofile
von HL7 Deutschland.
|
|
web
|
www.medizininformatik-initiative.de
|
Das
übergreifende Datenschutzkonzept der Medizininformatik-Initiative
regelt, wie Patientendaten über das Netz der Datenintegrationszentren hinweg
für die Forschung verarbeitet werden
dürfen: die Rechtsgrundlage (der Broad Consent der MII), die Rollen der
Datenintegrationszentren und der Use-&-Access-Committees sowie die
standortübergreifenden Anwendungsszenarien (Machbarkeitsanfragen, verteilte
Analysen, Daten- und Bioproben-Bereitstellung). Alles, was dieses Modul
spezifiziert, bewegt sich innerhalb dieses Rahmens — dieser Leitfaden fügt
keinen eigenen Verarbeitungszweck hinzu.
|
|
web
|
medizininformatik-initiative.github.io
|
Wie Daten, die ein Datenintegrationszentrum verlassen, praktisch
de-identifiziert werden, spezifiziert
DIMP (De-Identification — Minimisation — Pseudonymisation)
in der Dokumentation des Datenportals: direkte Identifikatoren werden
entfernt, vom genehmigten Projekt nicht benötigte Datenelemente entfallen, und
identifizierende Werte werden durch projektspezifische Pseudonyme ersetzt
(FHIR-Pseudonymizer-Konfiguration). Die Profile dieses Moduls beschreiben die
Daten vor
Anwendung von DIMP; welche Elemente eine konkrete
Datenbereitstellung erreicht, entscheidet je Projekt die DIMP-Konfiguration,
nicht dieser Leitfaden.
|
|
web
|
github.com
|
Releases folgen dem
Module Release Workflow
:
Die Version wird im Release-Branch angehoben, der Changelog-Eintrag geschrieben,
die Validierungs-Workflows laufen auf dem Release-Pull-Request, und nach dem
Merge wird das Release getaggt.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
|
|
web
|
github.com
|
Conformance
|
|
web
|
github.com
|
Conformance
|
|
web
|
github.com
|
General Requirements
|
|
web
|
github.com
|
Must Support
|
|
web
|
github.com
|
Handling Missing Data
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
IG © 2024+ NUM-DIZ
.
Package de.medizininformatikinitiative.kerndatensatz.studie#2027.0.0-ballot based on FHIR 4.0.1
.
Generated 2026-09-14
Links: Table of Contents |
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.medizininformatik-initiative.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
github.com
|
Where the versions come from.
Every package in the table is pinned
directly in
sushi-config.yaml
( dependencies:
) — including hl7.terminology.r4
(THO) and
hl7.fhir.uv.extensions.r4
, and those two deliberately so: the IG
Publisher's
automatic-packages rule
consults only this guide's own
dependency list, so without a direct pin
every build would silently inject the latest THO/extensions release — a
version pinned by the MII meta package alone cannot control the build
(verified in the publisher source at the pinned release). A weekly check
warns when these two pins drift from what the pinned meta package ships,
and the exact versions a concrete build used are recorded in its
qa-versions.json
output.
|
|
web
|
github.com
|
Expansion parameters are query parameters that can be passed to a ValueSet
$expand
operation to control how the ValueSet is expanded — that is, how the
full list of codes is generated from the ValueSet definition. The
IG Parameters
used for this IG are declared in
sushi-config.yaml
( parameters:
). A module that pins its expansion parameters through a CRMI
manifest additionally links the generated Parameters
resource from here (see
the commented manifest blocks in sushi-config.yaml
and the Metadata Overview
page, if the module keeps it).
|
|
web
|
keepachangelog.com
|
This page records the changes between the released versions of the
Medizinisches Forschungsvorhaben
module, newest version first. It follows
Keep a Changelog
and the KDS calendar
versioning scheme described on the Versioning
page.
|
|
web
|
mii-termserv.de
|
Important:
CodeSystem resources of external terminologies (e.g. ICD-10-GM,
OPS, SNOMED CT) are not
published in this module; they are obtained from the
central KDS terminology service (SU-TermServ):
https://mii-termserv.de/
.
|
|
web
|
github.com
|
Datasets and Descriptions
— the module's data
elements, described as logical models. (This entry shares its target with
Artifacts → Logical Models
; neither Artifacts-Summary anchor is usable as
a link target — see
docs/page-structure.md
in this repository.)
|
|
web
|
github.com
|
For the KDS-wide conformance requirements see the
Conformance rules of the Meta module
;
for the technical artifacts see Profiles
.
|
|
web
|
forschen-fuer-gesundheit.de
|
This version was discussed together with representatives of the German Research Data Portal for Health
(FDPG).
This draft was discussed together with representatives of the National Research Data Infrastructure for Personal Health Data
(NFDI4Health).
This draft was created together with representatives from other publicly funded networks and industry partners. Attention was paid to the potential conflicts of interest that may arise from this.
|
|
web
|
www.nfdi4health.de
|
This version was discussed together with representatives of the German Research Data Portal for Health
(FDPG).
This draft was discussed together with representatives of the National Research Data Infrastructure for Personal Health Data
(NFDI4Health).
This draft was created together with representatives from other publicly funded networks and industry partners. Attention was paid to the potential conflicts of interest that may arise from this.
|
|
web
|
www.medizininformatik-initiative.de
|
You can find the first release at 2025.0.0
|
|
web
|
www.medizininformatik-initiative.de
|
The MII KDS Module Medical Research Project was developed as a module of the Core Data Set (KDS) of the Medical Informatics Initiative (MII)
.
|
|
web
|
github.com
|
Conformance
— the KDS-wide conformance rules (requirements language,
Must Support, handling missing data) are maintained centrally by the
Meta module
;
the module-specific Security and Privacy
considerations are part of this guide.
|
|
web
|
www.medizininformatik-initiative.de
|
This module is part of the MII Core Dataset; the other KDS modules and their
dependencies are described at
medizininformatik-initiative.de
.
|
|
web
|
github.com
|
More FHIR implementation guides can be found in the official
FHIR IG Registry
(source:
FHIR/ig-registry
).
|
|
web
|
github.com
|
Comments and criticism are welcome in the form of 'Issues' in the GitHub repository
.
|
|
web
|
creativecommons.org
|
© 2019+ TMF e. V., Charlottenstraße 42, 10117 Berlin.
This work is licensed under the
Creative Commons Attribution 4.0 International License
.
|
|
web
|
github.com
|
The following CRMI-related metadata is set in
sushi-config.yaml
and ends up in the generated ImplementationGuide
resource.
|
|
web
|
github.com
|
Where a module publishes CodeSystem supplements, note that the CRMI
ShareableCodeSystem
profile requires CodeSystem.caseSensitive
, while FHIR
validation warns that a supplement should not restate caseSensitive
because
that could contradict the supplemented code system.
kerndatensatz-basis
therefore claims only the publishable
CRMI profile on supplements and omits
the shareable one.
|
|
web
|
www.go-fair.org
|
The FAIR principles
describe goals
for making digital objects Findable, Accessible, Interoperable and Reusable.
This section is an informative self-assessment of how the CRMI-based metadata of
this guide supports FAIR-aligned publication of FHIR specification artifacts.
|
|
web
|
ig.fhir.de
|
The work on the core data set specifications is based, wherever possible, on international standards and terminologies. In particular, the International Patient Summary
should be highlighted here. Adaptation to the general conditions of the German healthcare system is achieved through the use of the German base profiles
from HL7 Germany.
|
|
web
|
www.medizininformatik-initiative.de
|
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: it
covers the legal basis (the MII Broad Consent), the roles of the Data
Integration Centers and Use & Access Committees, and the cross-site application
scenarios (feasibility queries, distributed analyses, data and biosample
provision). Everything this module specifies operates inside that framework —
this guide adds no processing purpose of its own.
|
|
web
|
medizininformatik-initiative.github.io
|
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 by project-specific pseudonyms (FHIR Pseudonymizer
configuration). The profiles of this module describe data before
DIMP is
applied; which elements survive a concrete data release is decided per project
by the DIMP configuration, not by this guide.
|
|
web
|
github.com
|
Releases follow the
Module Release Workflow
:
the version is raised in the release branch, the changelog entry is written, the
validation workflows run on the release pull request, and the release is tagged
after the merge.
|
