BfArM 1994 - 2024 - Die Erstellung erfolgt unter Verwendung der maschinenlesbaren Fassung des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM)
The Sequence Ontology: A tool for the unification of genome annotations. Eilbeck K., Lewis S.E., Mungall C.J., Yandell M., Stein L., Durbin R., Ashburner M. Genome Biology (2005) 6:R44
Please also include the version of SO used.Sequence Ontology data and data products are licensed under the Creative Commons Attribution 4.0 Unported License
.
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
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
Unless otherwise noted, the contents of the FDA website (www.fda.gov) — both text and graphics — are not copyrighted. They are in the public domain and may be republished, reprinted and otherwise used freely by anyone without the need to obtain permission from FDA. Credit to the U.S. Food and Drug Administration as the source is appreciated but not required.
WHO, BfArM 1994 - 2024 - Die Erstellung erfolgt unter Verwendung der maschinenlesbaren Fassung des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM)
Code of Federal Regulation 21CFR§1271.290(c) ( src
)
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7. ( src
)
There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two medication requests would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. ( src
)
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
.
The Sequence Ontology: A tool for the unification of genome annotations. Eilbeck K., Lewis S.E., Mungall C.J., Yandell M., Stein L., Durbin R., Ashburner M. Genome Biology (2005) 6:R44
Please also include the version of SO used.Sequence Ontology data and data products are licensed under the Creative Commons Attribution 4.0 Unported License
.
The Sequence Ontology: A tool for the unification of genome annotations. Eilbeck K., Lewis S.E., Mungall C.J., Yandell M., Stein L., Durbin R., Ashburner M. Genome Biology (2005) 6:R44
Please also include the version of SO used.Sequence Ontology data and data products are licensed under the Creative Commons Attribution 4.0 Unported License
.
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
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).
Secondary findings are genetic test results that provide information about variants in a gene unrelated to the primary purpose for the testing, most often discovered when Whole Exome Sequencing (WES)
or Whole Genome Sequencing (WGS)
is performed. This extension should be used to denote when a genetic finding is being shared as a secondary finding, and ideally refer to a corresponding guideline or policy statement.
Secondary findings are genetic test results that provide information about variants in a gene unrelated to the primary purpose for the testing, most often discovered when Whole Exome Sequencing (WES)
or Whole Genome Sequencing (WGS)
is performed. This extension should be used to denote when a genetic finding is being shared as a secondary finding, and ideally refer to a corresponding guideline or policy statement.
Dieses Profil beschreibt die onkologische Diagnose zum Primärtumor und umfasst die Tumorausbreitung zum Zeitpunkt der Diagnosestellung
sowie der Anmeldung zum Molekularen Tumorboard
. Handeln es sich um einen Tumor des zentralen Nervensystems, kann eine Graduierung nach WHO-Klassifikation
vorgenommen werden.
Sie kombiniert Lokalisations- und morphologische Beschreibungen und gilt damit als besser geeignet für personalisierte Medizin als die weiter verbreitete ICD-O-Klassifikation mit Topographie und Morphologie. Die aktuelle stabile Version wird vom MSKCC herausgegeben
und wird in der OnkoKB-Datenbank
verwendet.
Sie kombiniert Lokalisations- und morphologische Beschreibungen und gilt damit als besser geeignet für personalisierte Medizin als die weiter verbreitete ICD-O-Klassifikation mit Topographie und Morphologie. Die aktuelle stabile Version wird vom MSKCC herausgegeben
und wird in der OnkoKB-Datenbank
verwendet.
Diese Seite hält die Änderungen zwischen den veröffentlichten Versionen des
Moduls Molekulares Tumorboard
fest, die neueste Version zuerst. Sie folgt
Keep a Changelog
und dem
KDS-CalVer-Schema, das die Seite Versionierung
beschreibt.
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/
.
Diese Seite beschreibt die Transformation von DNPM DIP
MTB-Patientenakten in MII KDS-konforme FHIR-Bundles mittels FHIR StructureMaps
und dem Matchbox
FHIR-Server.
Diese Seite beschreibt die Transformation von DNPM DIP
MTB-Patientenakten in MII KDS-konforme FHIR-Bundles mittels FHIR StructureMaps
und dem Matchbox
FHIR-Server.
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.)
Das KDS-Modul Molekulares Tumorboard
basiert maßgeblich auf dem Datenmodell
des Deutschen Netzwerks für Personalisierte Medizin (DNPM)
, welches die
Anforderungen aus dem
Modellvorhaben Genomsequenzierung (MV GenomSeq)
gemäß § 64e SGB V
einbezieht. Die Inhalte sind öffentlich verfügbar:
Das KDS-Modul Molekulares Tumorboard
basiert maßgeblich auf dem Datenmodell
des Deutschen Netzwerks für Personalisierte Medizin (DNPM)
, welches die
Anforderungen aus dem
Modellvorhaben Genomsequenzierung (MV GenomSeq)
gemäß § 64e SGB V
einbezieht. Die Inhalte sind öffentlich verfügbar:
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.
Fragen zu dieser Publikation können im HL7-FHIR-Zulip
chat.fhir.org
im Stream german/mi-initiative
oder im
MII-Zulip mii.zulipchat.com
im Stream
MII-Kerndatensatz
gestellt werden.
Anmerkungen und Kritik werden als Issues
auf
GitHub
entgegengenommen.
Fragen zu dieser Publikation können im HL7-FHIR-Zulip
chat.fhir.org
im Stream german/mi-initiative
oder im
MII-Zulip mii.zulipchat.com
im Stream
MII-Kerndatensatz
gestellt werden.
Anmerkungen und Kritik werden als Issues
auf
GitHub
entgegengenommen.
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.
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.
Overall Survival (OS)
— Zeit von t₀ bis zum Tod jeglicher Ursache.
Todesereignis und -datum kommen aus Patient.deceasedDateTime
(MII-Modul
Person); zusätzlich führt das Modul Person die
Vitalstatus
-Observation
den Vitalstatus je Kontaktdatum, und die
Tod
-Observation
des Onkologie-Moduls dokumentiert Sterbedatum, Todesursache und deren
Tumorbezug — zur Bestätigung des Ereignisses und für ursachenspezifische
Analysen (tumorbedingte Todesfälle). Patienten ohne Todeseintrag werden zum
letzten dokumentierten Kontakt zensiert (jüngste datierte Follow-Up
ClinicalImpression
,
Response-Befund oder Therapiedokumentation).
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.
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.
Übersetzte Seiten liegen unter input/translations/de/pagecontent/
(gleicher
Dateiname wie die englische Seite); Ressourcen-Übersetzungen als .po
-Dateien
unter input/translations/de/
. Details:
docs/recipes/add-translation.md
in diesem Repository.
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.
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.
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).
This profile describes the oncological diagnosis of the primary tumor and covers the tumor spread at the time of diagnosis
as well as at the time of registration for the Molekulares Tumorboard (molecular tumor board)
. If the tumor is a tumor of the central nervous system, a grading according to the WHO classification
can be applied.
It combines localization and morphological descriptions and is therefore considered better suited for personalized medicine than the more widespread ICD-O classification with topography and morphology. The current stable version is published by MSKCC
and is used in the OnkoKB database
.
It combines localization and morphological descriptions and is therefore considered better suited for personalized medicine than the more widespread ICD-O classification with topography and morphology. The current stable version is published by MSKCC
and is used in the OnkoKB database
.
This page records the changes between the released versions of the
Molecular Tumor Board
module, newest version first. It follows
Keep a Changelog
and the KDS calendar
versioning scheme described on the Versioning
page.
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/
.
This page describes the transformation of DNPM DIP
MTB patient records into MII-CDS-conformant FHIR bundles using FHIR StructureMaps
and the Matchbox
FHIR server.
This page describes the transformation of DNPM DIP
MTB patient records into MII-CDS-conformant FHIR bundles using FHIR StructureMaps
and the Matchbox
FHIR server.
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.)
The CDS module Molecular Tumor Board
is largely based on the data model of
the German Network for Personalized Medicine (DNPM)
, which incorporates the
requirements of the
Modellvorhaben Genomsequenzierung (MV GenomSeq)
per § 64e SGB V
. The
content is publicly available:
The CDS module Molecular Tumor Board
is largely based on the data model of
the German Network for Personalized Medicine (DNPM)
, which incorporates the
requirements of the
Modellvorhaben Genomsequenzierung (MV GenomSeq)
per § 64e SGB V
. The
content is publicly available:
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.
Questions about this publication can be asked on the HL7 FHIR Zulip
chat.fhir.org
in the german/mi-initiative
stream, or
on the MII Zulip mii.zulipchat.com
in the
MII-Kerndatensatz
stream.
Comments and issues are welcome as Issues
on
GitHub
.
Questions about this publication can be asked on the HL7 FHIR Zulip
chat.fhir.org
in the german/mi-initiative
stream, or
on the MII Zulip mii.zulipchat.com
in the
MII-Kerndatensatz
stream.
Comments and issues are welcome as Issues
on
GitHub
.
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.
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.
Overall survival (OS)
— time from t₀ to death from any cause.
Death and its date come from Patient.deceasedDateTime
(MII Person module);
in addition, the Person module's
Vitalstatus
observation carries the vital status per contact date, and the Oncology
module's
Tod
observation documents death date, cause of death and its tumor relation —
use them to confirm the event and, for cause-specific analyses, to
distinguish tumor-related deaths. Patients without a death record are
censored at their last documented contact (most recently dated Follow-Up
ClinicalImpression
,
Response-Befund or therapy documentation).
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.
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.
Translated pages live under input/translations/de/pagecontent/
(same file name
as the English page); resource translations are .po
files under
input/translations/de/
. Details:
docs/recipes/add-translation.md
in this repository.
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.
