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
.
Ein ISiK Akteur darf sinnvolle Limits für die Einschränkung der Ergebnismenge definieren, wie die Forcierung von Pagination über den Parameter _count
oder die Einschränkung des Zeitraums der zurückgegebenen Ressourcen über den Parameter _since
. Hierbei sollten die Hinweise und vorgaben der ISiK-Spezifikation zu Performance
beachtet werden.
Profile wie Körpergewicht und -größe aus dem Modul Vitalparameter kommen gegebenenfalls auch bei der Umsetzung des übergreifenden Use Case “AMTS” in dem Modul Medikation zum Einsatz.
Für weitere Informationen: Arzneimitteltherapiesicherheit im Krankenhaus - AMTS
.
Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen.
Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation
unterstützt werden.
Der MODE
-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar ( kind = requirements
).
Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN,
wird die CapabilityStatement-Imports-Expectation-Extension
mit den möglichen Werten ‘SHALL’ (=MUSS) ‘SHOULD’ (=SOLL) ‘MAY’ (=KANN) ‘SHOULD-NOT’ (=SOLL NICHT) verwendet.
Dies geht jedoch über den Kontext des vorliegenden Implementierungsleitfadens hinaus und ist in einem eigenen Implementierungsleitfaden ICU-Normalstation Workflow
abgebildet. Dort sind Anwendungsfälle rund um den bidirektionalen Überleitungsprozess zwischen einer Intensiv- und einer Normalstation innerhalb eines Krankenhauses berücksichtigt, respektive die bidirektionale Kommunikation von Vitalparametern und Körpermaßen zwischen einem KIS und einem PDMS.
In Bezug auf den Lesenden Zugriff gilt daher: Alle bestätigungsrelevanten Systeme in diesem Modul MÜSSEN nach QEDm die Rolle der Data Source
einnehmen können (für mehr Informationen siehe Basismodul - Abschnitt QEDm
).
Die Interaktionen auf den Observation-Ressourcen, die in diesem Modul festgelegt werden, entsprechen jenen der “Simple Observation Option” im IHE-Profil
QEDm (Query for Existing Data for mobile)
.
Die Profilierung von Signaldaten liegt außerhalb der Zielsetzung des ISiK Vitalparameter Moduls, allerdings besteht durch Profile wie dem ISiK EKG eine undefinierte Nähe zu dieser Art Daten. An dieser Stelle wird daher ausdrücklich auf die Empfehlung der deutschen Basisprofile zur Profilierung von Signaldaten
weiter verwiesen.
Motivation MS:
Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKPatient
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Begründung Pflichtfeld:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer:
Die Zuordnung MUSS auf einen Encounter der Ebene "Abteilungskontakt" (siehe hierzu Basismodul > UseCases > Abbildung des Konstruktes "Fall") erfolgen.
Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)"Fallnummer" (hier: Encounter.account
) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Begründung Pflichtfeld:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer:
Die Zuordnung MUSS auf einen Encounter der Ebene “Abteilungskontakt” (siehe hierzu Basismodul > UseCases > Abbildung des Konstruktes “Fall”) erfolgen.
Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)”Fallnummer” (hier: Encounter.account
) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Das Profil ISiKBlutdruckSystemischArteriell ist vom Profil VitalSignDE_Blutdruck
aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Blood Pressure Profile
aus der FHIR R4 Spezifikation.
Begründung MS:
Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKPatient
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Begründung MS:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Viele medizinischen Entscheidungen benötigen Informationen zu den Laboruntersuchungen eines Patienten. Hierzu gehören z.B. aktuelle Nierenfunktionswerte, Leberwerte, Blutbildwerte oder Hormone aus Schilddrüse.
Jede dieser Untersuchungen wird durch bestimmte [[https://loinc.org/ LOINC]] oder [[http://snomed.info/sct SNOMED CT]] Codes bezeichnet. Der angegebene Wert ist durch genaue Einheitenangaben in [[http://unitsofmeasure.org UCUM]] zu konkretitiseren.
Motivierender Use-Case zur Einführung dieser Profile ist die Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS
.
Dieses und untergeordnete Elemente KÖNNEN bei einem erfolgten Patient merge entsprechend der Festlegungen unter Patient-merge
befüllt werden.
Da das Element der Unterstützung der Patient merge Notification dient,
MUSS es im Rahmen des Bestätigungsverfahrens NICHT unterstützt werden (Stand: Stufe 4).
Profil EPAPatient der gematik
: In ISiK ist die Angabe einer KVNR nicht verpflichtend, da in vielen Use Cases bereits eine PID ausreichend ist. Außerdem ist in ISiK keine verpflichtende Versionierung über meta.versionId vorgesehen.
Dieses und untergeordnete Elemente KÖNNEN bei einem erfolgten Patient merge entsprechend der Festlegungen unter Patient-merge
befüllt werden.
Da das Element der Unterstützung der Patient merge Notification dient,
MUSS es im Rahmen des Bestätigungsverfahrens NICHT unterstützt werden (Stand: Stufe 4).
ISiK vereint hierbei das ValueSet KontaktArtDe
aus dem deutschen Basisprofil und die übergangsweise hinzugefügten Codes für den ambulanten Kontakt im Krankenhaus. Dieses ValueSet ist als Übergangslösung zu verstehen, da die Inhalte beim TC Terminologien von HL7 eingebracht sind und sobald sie dort publiziert sind, wird eine Migration auf die dortigen Codes erfolgen.
Softwareherstellern steht es frei, über die hier spezifizierten Profiltypen hinaus weitere FHIR-Profile zu nutzen, zu implementieren oder zu spezifizieren und über eine API bereitzustellen. Wir bitten in solchen Fällen jedoch um eine Meldung entsprechender Bedarfe über das ISiK Anfrageportal
, damit wir über mögliche Leerstellen der ISiK-Spezifikation in grundlegenden API-Funktionalitäten zur Abdeckung spezifischer Workflows informiert werden.
Die gematik wurde vom Gesetzgeber beauftragt, im Benehmen mit der Deutschen Krankenhausgesellschaft (DKG) und den maßgeblichen Bundesverbänden der Industrie im Gesundheitswesen verbindliche Standards für den Austausch von Gesundheitsdaten mit Informationssystemen im Krankenhaus zu erarbeiten. Dieser FHIR ImplementationGuide (IG) beschreibt die für diesen Zweck entwickelten FHIR Profile und das REST
-basierte Application Programming Interface (API). Die REST-API wird im Wesentlichen vom FHIR Standard vorgegeben
. Dieser Leitfaden konkretisiert die ISiK-relevanten Funktionen der Standard-REST-API und trifft inhaltliche Festlegungen zu den ISiK-relevanten Ressourcen in Form von Ressourcen-Profilen.
Hinweis: Sowohl für die Implementierung der ISiK-Spezifikation als auch für den Betrieb eines Produktes, das die ISiK-Spezifikation implementiert, ist eine SNOMED-CT-Lizenz notwendig. Diese kann beim National Release Center für SNOMED CT in Deutschland
beantragt werden.
(
extensible
)
