MII IG ICU
2027.0.0-ballot.3 -
Germany
This page is part of the MII IG ICU (v2027.0.0-ballot.3: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
Modul-eigene Profile — dieses Paket
Generisch: Extrakorporales Verfahren · Eingestellte Gemessene Parameter Extrakorporale Verfahren · Parameter von Extrakorporalen Verfahren
Generisch: Beatmung · Eingestellte Gemessene Parameter Beatmung · Parameter von Beatmung
Generisch: Bilanz
ISiK-gehostete Profile — de.gematik.isik 6.0.0
Von der gematik gehostet und versioniert; dieser Leitfaden listet sie als fachlichen Bestandteil des KDS Intensivmedizin. Aus der gepinnten Paketversion generiert — die Liste ändert sich nur mit einem bewussten Pin-Wechsel. Links öffnen Simplifier.
Written during migration - review before release. Die Profile zu Monitoring und Vitaldaten dieses Moduls sind im ISiK-Paket
de.gematik.isik(6.0.0) alssd-mii-icu-*veroeffentlicht und werden daher von jenem Paket gerendert, nicht von diesem Guide. Der Quell-Guide fuehrte je Profil eine Seite; diese enthielten nur den Verweis auf das generische Profil, der unten einmal erhalten ist, gefolgt von der vollstaendigen Profilliste.
Original-Wortlaut der Quellseiten (je Profil): „Dies ist eine Ausprägung des generischen Profils zu Monitoring und Vitaldaten (Observation). Siehe dort für nähere Informationen hinsichtlich Erklärungen der Items, oder Bezug der Einträge in der FHIR-Ressource zum Logical Model."
Für die pulsatilen Drücke zusätzlich: „Es handelt sich hier um einen pulsatilen Druck. Für diesen gelten neben den Eigenschaften des generischen Profils zu Monitoring und Vitaldaten (Observation) die Eigenschaften des generischen Profils zu Sonstige pulsatile Drücke (Generisch) (Observation)."
Die einzelnen Profile sind Auspraegungen des generischen Profils Monitoring und Vitaldaten (Observation). Siehe dort fuer naehere Informationen zu den Items und zum Bezug auf das Logical Model.
Die FHIR-Profile in diesem Projekt folgen folgendem Ansatz:
Es gibt jeweils mindestens ein generisches Profil für die im Datenmodell definierten "Struktur-Elemente" des KDS-Moduls. Diese Profile enthalten ValueSets und beschreiben die vorgegebene Struktur für Gruppen von Items einer bestimmte intensivmedizinischen Kategorie. Die generischen Profile sind die ersten in einer jeden Gruppe der Baumstruktur dieses Guides, also:
Parameter von extrakorporalen Verfahren: - Extrakorporale Verfahren (Procedure) - Eingestellte und gemessene Parameter (DeviceMetric) - Parameter von extrakorporalen Verfahren (Observation)
Beatmungswerte: - Beatmung (Procedure) - Eingestellte und gemessene Parameter (DeviceMetric) - Parameter von Beatmung (Observation)
Monitoring und Vitaldaten - Monitoring und Vitaldaten (Observation) - Sonstige pulsatile Drücke Generisch (Observation) - Körpertemperatur Generisch (Observation)
Bilanzen - Bilanz (Observation)
Außerdem gibt es **spezifische Profile**, welche jeweils die Code- und Einheiten-Zugehörigkeiten **fixieren**. Diese Spezifischen Ressourcen sind unter anderem als **Handreichung für den Implementierer** gedacht und sollen dabei helfen, die Hürde der korrekten semantischen Annotation zu verringern und die Interoperabilität zu verbessern. Die spezifische Profile sind all jene, die sich innerhalb einer Gruppe an die o.g. generischen Profile anschließen.
Wir betrachten messende sowie eingestellte Geräte (siehe auch Beschreibung Modul). Dies stellt das Mindestmaß an Unterscheidung dar, die wir zur Abbildung der in diesem Modul modellierten Daten benötigen. Die Information, ob der Wert gemessen, oder eingestellt ist, trägt die DeviceMetric. Welches Gerät eingestellt wird bzw. einen Wert misst, beschreibt eine Device-Ressource. Das Device wird aus der DeviceMetric heraus referenziert. Je nach Menge der verfügbaren Informationen bieten sich hier verschiedene Modellierungslevel an:
Für eine Gruppe von Werten, die sich eine gemeinsame Messmethode und ein gemeinsames Messgerät teilen, kann ein gemeinsames solches Paar aus DeviceMetric und Device angelegt werden, welches aus Observation.device heraus referenziert wird. Dies ins insbesondere dann notwendig, wenn keine Geräteinformationen vorhanden sind.
Sofern keine Geräteinformarmationen vorhanden sind, kann man sich pro Kategorie (Vitaldaten, extrakorporale Verfahren, …) auf jeweils zwei DeviceMetrics beschränken, die jeweils aussagen, ob es sich bei einer Observation (genauer Observation.value) um einen eingestellten oder gemessenen Wert handelt.
Zusammenfassend brauchen wir je eine Ressourcen für jede Kombination aus Observation.type und Observation.category.
| Feld | Bedeutung | | — | — | | Observation.type | Enspricht der Observation.category der referenzierenden Observation. Beachte die entsprechenden ValueSets
| Beatmung (siehe MII_VS_Category_Procedure_Beatmung_SNOMED ) |
| Observation.category | gemessen/eingestellt/… |
Entsprechend der beiden mit "optional*" markierten Felder unter 1. kann man außerdem Device-Ressourcen erzeugen. Dies macht insbesondere dann Sinn, wenn man zusätzliche Informationen für Geräteklassen angeben kann, wie bspw. den gleichen Hersteller für alle Beatmungsgeräte.
Sollten zu den messenden und eingestellten Geräten weitere Informationen bekannt sein, oder gar Geräte-IDs kommuniziert werden, so kann für jedes so über eine Geräte-ID identifizierbare Gerät eine eigene Ressource angelegt werden. Obiges Schaubild versucht, die möglichen Beziehungen zu illustrieren. Einerseits kann ein Gerät (DeviceMetric und Device) im Laufe der Zeit Werte für unterschiedliche Patienten erzeugen, andererseits können zur selben Zeit für einen einzelnen Patienten mehrere Geräte Werte liefern.
Beachte: weil ein Device in der gewählten Modellierung immer nur via eine übergeordnete DeviceMetric referenziert werden kann ergibt sich im Umkehrschluss, dass bei dieser detaillierten Implementierung für jede Device-Ressource eine zugehörige DeviceMetric (bzw. ein Pärchen für gemessene und eingestellte Parameter) erzeugt werden muss.