|
Type
|
Reference
|
Content
|
|
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.medizininformatik-initiative.de
|
IG © 2022+ Medizininformatik Initiative
.
Package de.medizininformatikinitiative.kerndatensatz.symptom#2027.0.0-ballot basiert auf FHIR 4.0.1
.
Erstellt 2026-09-11
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
|
www.iso.org
|
ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
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
|
snomed.info
|
SNOMED CT Concept Domain Binding
|
|
web
|
ig.fhir.de
|
Siehe dazu auch Diagnosesicherheit in den FHIR Basisprofilen
und im MII Modul Diagnose
.
|
|
web
|
medizininformatik-initiative.github.io
|
Siehe dazu auch Diagnosesicherheit in den FHIR Basisprofilen
und im MII Modul Diagnose
.
|
|
web
|
keepachangelog.com
|
Diese Seite hält die Änderungen zwischen den veröffentlichten Versionen des
Moduls Symptom
fest, die neueste Version zuerst. Sie folgt
Keep a Changelog
und dem
KDS-CalVer-Schema, das die Seite Versionierung
beschreibt.
|
|
web
|
medizininformatik-initiative.github.io
|
Die Zuordnung von Symptomen/Phänotypen zu einem Patienten bzw. einer Patientin
erfolgt über Referenzen vom Modul Symptome/klinischer Phänotyp zum MODUL
PERSON
.
|
|
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
|
Formale Abhängigkeiten
dieses Moduls (siehe dependencies
in sushi-config.yaml
): das
Meta-Modul
( 2027.0.0-ballot
), die
Deutschen Basisprofile
( 1.6.0
)
und HL7 Europe Base
( 2.0.0
). Die fachlichen
Bezüge zu den Modulen Diagnose, Labor und Person beschreibt die
Anleitung für Implementierende
.
|
|
web
|
ig.fhir.de
|
Formale Abhängigkeiten
dieses Moduls (siehe dependencies
in sushi-config.yaml
): das
Meta-Modul
( 2027.0.0-ballot
), die
Deutschen Basisprofile
( 1.6.0
)
und HL7 Europe Base
( 2.0.0
). Die fachlichen
Bezüge zu den Modulen Diagnose, Labor und Person beschreibt die
Anleitung für Implementierende
.
|
|
web
|
github.com
|
Weitere FHIR-Implementierungsleitfäden finden Sie im offiziellen
FHIR IG Registry
(Quelle:
FHIR/ig-registry
).
|
|
web
|
github.com
|
Anmerkungen und Kritik werden in Form von Issues
auf
GitHub
stets gern entgegengenommen.
|
|
web
|
creativecommons.org
|
Der Inhalt dieser Spezifikation ist öffentlich. Die Nachnutzungs- bzw.
Veröffentlichungsansprüche sind nicht beschränkt. Dieses Werk ist lizenziert
unter der
Creative Commons Namensnennung 4.0 International Lizenz (CC BY 4.0)
.
|
|
web
|
art-decor.org
|
Die offizielle und abgenommene Version des Informationsmodells für das Modul
Symptome/klinischer Phänotyp findet sich auf
ArtDecor
. Zur
Vereinheitlichung der Repräsentation wurde das Informationsmodell zusätzlich
als FHIR Logical Model abgebildet:
|
|
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.medizininformatik-initiative.de
|
IG © 2022+ Medizininformatik Initiative
.
Package de.medizininformatikinitiative.kerndatensatz.symptom#2027.0.0-ballot based on FHIR 4.0.1
.
Generated 2026-09-11
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
|
ig.fhir.de
|
See also diagnostic certainty in the
FHIR base profiles
and in the MII Diagnosis module
.
|
|
web
|
medizininformatik-initiative.github.io
|
See also diagnostic certainty in the
FHIR base profiles
and in the MII Diagnosis module
.
|
|
web
|
keepachangelog.com
|
This page records the changes between the released versions of the
Symptom
module, newest version first. It follows
Keep a Changelog
and the KDS calendar
versioning scheme described on the Versioning
page.
|
|
web
|
medizininformatik-initiative.github.io
|
The assignment of symptoms/phenotypes to a patient is made via references
from the Symptom/clinical phenotype module to the MODULE
PERSON
.
|
|
web
|
github.com
|
Conformance
— the KDS-wide conformance rules (requirement language,
must-support, handling of missing data) are maintained centrally by the
Meta module
;
the module-specific aspects of
Security and Privacy
are part of this guide.
|
|
web
|
www.medizininformatik-initiative.de
|
This module is part of the MII core data set; the other KDS modules and their
dependencies are described at
medizininformatik-initiative.de
.
|
|
web
|
github.com
|
Formal dependencies of
this module (see dependencies
in sushi-config.yaml
): the
Meta module
( 2027.0.0-ballot
), the
German base profiles
( 1.6.0
)
and HL7 Europe Base
( 2.0.0
). The subject-matter
relationships to the Diagnosis, Laboratory and Person modules are described
in the Guidance for Implementers
.
|
|
web
|
ig.fhir.de
|
Formal dependencies of
this module (see dependencies
in sushi-config.yaml
): the
Meta module
( 2027.0.0-ballot
), the
German base profiles
( 1.6.0
)
and HL7 Europe Base
( 2.0.0
). The subject-matter
relationships to the Diagnosis, Laboratory and Person modules are described
in the Guidance for Implementers
.
|
|
web
|
github.com
|
Further FHIR implementation guides can be found in the official
FHIR IG Registry
(source:
FHIR/ig-registry
).
|
|
web
|
github.com
|
Comments and criticism are always welcome as issues
on
GitHub
.
|
|
web
|
creativecommons.org
|
The content of this specification is public. Reuse and publication claims are
not restricted. This work is licensed under the
Creative Commons Attribution 4.0 International License (CC BY 4.0)
.
|
|
web
|
art-decor.org
|
The official and approved version of the information model for the
Symptoms/clinical phenotype module can be found on
ArtDecor
. To unify
the representation, the information model was additionally mapped as a FHIR
Logical Model:
|
|
web
|
ig.fhir.de
|
Wherever possible, the work on the core data set specifications is based on
international standards and terminologies. The
International Patient Summary
deserves particular mention here. Adaptation to the general conditions of the
German health care system is achieved by using the
German base profiles
of
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.
|
