This publication includes IP covered under the following statements.
BfArM 1994 - 2024 - Die Erstellung erfolgt unter Verwendung der maschinenlesbaren Fassung des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM)
IEEE maintains copyright on all content from IEEE 11073 standards. All rights reserved. Implementers should obtain official copies of all applicable standards documents directly from IEEE. The inclusion of IEEE 11073 terminology codes and definitions in HL7 messages and related implementation guides is permitted under existing agreements. For permission regarding any other usage, please contact IEEE at copyrights@ieee.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
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
.
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7. ( src
)
Total rate of breaths or inspiratory gas flow comprised of unassisted (P), supported (S), assisted (A), synchronized assisted (Z) and controlled (C) breath types. ( src
)
{ "code" : "152490", "display" : "Total rate of breaths or inspiratory gas flow comprised of unassisted (P), supported (S), assisted (A), synchronized assisted (Z) and controlled (C) breath types."} ( 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 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).
Der QA-Report listet weiterhin eine erhebliche Zahl an Errors. Alle sind triagiert, keiner ist ein inhaltlicher Defekt dieses Moduls
— dominierende Ursachen sind ein IG-Publisher-Bug in der Batch-Terminologie-Validierung (Upstream-Fix offen: org.hl7.fhir.core#2460
), in Profil-Patterns gepinnte Display-Texte, die von den offiziellen Terminologie-Displays abweichen ( #79
), sowie die Terminologieserver-Semantik bei versionierten SNOMED-CT-Codings ( #83
). Vollständige Aufschlüsselung: Seite Examples
, Abschnitt „Bekannte Validierungsbefunde".
Der QA-Report listet weiterhin eine erhebliche Zahl an Errors. Alle sind triagiert, keiner ist ein inhaltlicher Defekt dieses Moduls
— dominierende Ursachen sind ein IG-Publisher-Bug in der Batch-Terminologie-Validierung (Upstream-Fix offen: org.hl7.fhir.core#2460
), in Profil-Patterns gepinnte Display-Texte, die von den offiziellen Terminologie-Displays abweichen ( #79
), sowie die Terminologieserver-Semantik bei versionierten SNOMED-CT-Codings ( #83
). Vollständige Aufschlüsselung: Seite Examples
, Abschnitt „Bekannte Validierungsbefunde".
Der QA-Report listet weiterhin eine erhebliche Zahl an Errors. Alle sind triagiert, keiner ist ein inhaltlicher Defekt dieses Moduls
— dominierende Ursachen sind ein IG-Publisher-Bug in der Batch-Terminologie-Validierung (Upstream-Fix offen: org.hl7.fhir.core#2460
), in Profil-Patterns gepinnte Display-Texte, die von den offiziellen Terminologie-Displays abweichen ( #79
), sowie die Terminologieserver-Semantik bei versionierten SNOMED-CT-Codings ( #83
). Vollständige Aufschlüsselung: Seite Examples
, Abschnitt „Bekannte Validierungsbefunde".
Die Profile pinnen in patternCoding
Display-Texte, die von den offiziellen Terminologie-Displays abweichen. Lösung ist eine Profil-Entscheidung (Displays aus den Patterns entfernen) — siehe #79
Für das nationale Covid-19-Dashboard
(ein Projekt des Netzwerks Universitätsmedizin und der Medizininformatik-Initiative) steht bereits Tooling
zu Verfügung, welches unter anderem unter Verwendung der im KDS-Modul Intensivmedizin enthaltenen Profile zu Beatmung und extrakorporalen Verfahren das Versorgungsniveau (Normalstation, Intensivstation, Intensivstation mit Beatmung, Intensivstation mit extrakorporaler Membranoxygenierung) von SARS-CoV-2-Patienten auswertet und darstellt.
Für das nationale Covid-19-Dashboard
(ein Projekt des Netzwerks Universitätsmedizin und der Medizininformatik-Initiative) steht bereits Tooling
zu Verfügung, welches unter anderem unter Verwendung der im KDS-Modul Intensivmedizin enthaltenen Profile zu Beatmung und extrakorporalen Verfahren das Versorgungsniveau (Normalstation, Intensivstation, Intensivstation mit Beatmung, Intensivstation mit extrakorporaler Membranoxygenierung) von SARS-CoV-2-Patienten auswertet und darstellt.
Die ASIC-App
verwendet intensivmedizinische Daten (Beatmungsdauer, Horovitz-Quotient endexspiratorischer Beatmungsdruck) zur frühzeitigen Erkennung und leitliniengerechten Therapie des akuten Lungenversagens. Bei der Entwicklung der interoperablen Schnittstellen zwischen den Patientendatenmanagementsystemen und dem Backend der App sollen zunehmend die entsprechenden Profile des KDS-Modul Intensivmedizin eingesezt werden.
IEEE 11073-10207 – IEEE Health informatics – Point-of-care medical device communication Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication. Siehe OR.NET e.V.
.
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 is a pulsatile pressure. In addition to the properties of the generic profile for Monitoring and vital data
, the special features described on the page of the profile for blood pressure (observation)
also apply to this. See there for more detailed information regarding explanations of the items or reference of the entries in the FHIR resource to the Logical Model.
The QA report still lists a substantial number of errors. All of them are triaged and none is a content defect of this module
— the dominant causes are an IG-Publisher bug in batch terminology validation (upstream fix pending: org.hl7.fhir.core#2460
), display texts pinned in profile patterns that differ from the official terminology displays ( #79
), and terminology-server semantics for version-stamped SNOMED CT codings ( #83
). Full breakdown: Examples
page, section "Known validation issues".
The QA report still lists a substantial number of errors. All of them are triaged and none is a content defect of this module
— the dominant causes are an IG-Publisher bug in batch terminology validation (upstream fix pending: org.hl7.fhir.core#2460
), display texts pinned in profile patterns that differ from the official terminology displays ( #79
), and terminology-server semantics for version-stamped SNOMED CT codings ( #83
). Full breakdown: Examples
page, section "Known validation issues".
The QA report still lists a substantial number of errors. All of them are triaged and none is a content defect of this module
— the dominant causes are an IG-Publisher bug in batch terminology validation (upstream fix pending: org.hl7.fhir.core#2460
), display texts pinned in profile patterns that differ from the official terminology displays ( #79
), and terminology-server semantics for version-stamped SNOMED CT codings ( #83
). Full breakdown: Examples
page, section "Known validation issues".
The profiles pin display texts in patternCoding
that differ from the official terminology displays. Resolution is a profile decision (drop displays from patterns) — see #79
Tooling
is already available for the national Covid-19-dashboard
(a project of the University Medicine Network and the Medical Informatics Initiative), which evaluates and displays the level of care (normal ward, intensive care unit, intensive care unit with ventilation, intensive care unit with extracorporeal membrane oxygenation) of SARS-CoV-2 patients using the profiles on ventilation and extracorporeal procedures contained in the core dataset module intensive care.
Tooling
is already available for the national Covid-19-dashboard
(a project of the University Medicine Network and the Medical Informatics Initiative), which evaluates and displays the level of care (normal ward, intensive care unit, intensive care unit with ventilation, intensive care unit with extracorporeal membrane oxygenation) of SARS-CoV-2 patients using the profiles on ventilation and extracorporeal procedures contained in the core dataset module intensive care.
The ASIC-app
uses intensive care data (ventilation duration, Horovitz quotient, end-expiratory ventilation pressure) for the early detection and guideline-compliant treatment of acute respiratory failure. When developing the interoperable interfaces between the patient data management systems and the backend of the app, the corresponding profiles of the core dataset module intensive care will increasingly be used.
IEEE 11073-10207 - IEEE Health informatics - Point-of-care medical device communication Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication. See OR.NET e.V.
.
The official and approved version of the information model for the PERSON module can be found on ART-DECOR
. To standardize the representation, the information model was also mapped as a FHIR Logical Model:
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.
