Confirmation

ABGEKÜNDIGT - Basis-Modul der Informationstechnischen Systeme im Krankenhaus Ausbaustufe 4

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von administrativen Patientendaten im Rahmen des Bestätigungsverfahrens der gematik. Motivation Der Austausch administrativer Patientendaten ist eine der grundlegenden Funktionalitäten beim Datenaustausch in der klinischen Versorgung. In FHIR werden sämtliche klinischen Ressourcen durch Verlinkung auf die Ressource 'Patient' in einen Patientenkontext gestellt. Die Herstellung des korrekten Patientenkontextes durch Suchen der Patientenressource anhand von Eigenschaften wie Aufnahmenummer Name oder Geburtsdatum die Anzeige der zutreffenden Suchergebnisse und der Auswahl bzw. Bestätigung des richtigen Datensatzes durch den Anwender steht am Beginn der meisten klinischen Workflows. Kompatibilität Für das Profil ISIKPatient wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden dass Instanzen die gegen ISIKPatient valide sind auch valide sind gegen * [Profil KBV_PR_Base_Patient der KBV Basisprofile](https fhir.kbv.de StructureDefinition KBV_PR_Base_Patient) * [Profil Patient im International Patient Summary (IPS)](https hl7.org fhir uv ips StructureDefinition-Patient-uv-ips.html) * [Profil Patient der MI-Initiative](https www.medizininformatik-initiative.de fhir core modul-person StructureDefinition Patient) Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil ermöglicht die Gruppierung von medizinischen Leistungen zu einem gemeinsamen Abrechnungskontext. Motivation Komplementär zum Datenobjekt "Kontakt - Encounter" können Fälle im Sinne einer Gruppierung von medizinischen Leistungen innerhalb eines gemeinsamen Kontextes zu einem Abrechnungsfall zusammengefasst werden. Ein solcher Abrechnungsfall kann mehrere Kontakte umfassen (z.B. vorstationärer Besuch stationärer Aufenthalt und nachstationärer Besuch). Gemeinsam mit dem Einrichtungskontakt bildet der Abrechnungsfall einen wichtigen Einstiegspunkt in die Dokumentation der Behandlungsleistungen der Patienten. Als Bindeglied zwischen den Kontakten und dem Versicherungsverhältnis erfolgt eine feingranulare Auflistung in welchen Zeiträumen ein Behandlungskontext zwischen einer Gesundheitseinrichtung und der Patienten bestand. Zudem werden Diagnosen abschließend nachträglich dokumentiert sodass eine Übersicht von relevanten (DRG)-Diagnosen ermöglicht wird ohne die Gesamtheit aller Kontakte betrachten zu müssen. In FHIR wird der Abrechnungsfall mit der `Account`-Ressource repräsentiert. Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter pagelink Fall text Fall-Begriff in ISiK . Kompatibilität * zum Zeitpunkt der Veröffentlichung sind keine abweichenden Modellierungen der Account-Ressource bekannt. Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Diagnosen eines Patienten im Rahmen des Bestätigungsverfahrens der gematik. Motivation Die Möglichkeit auf eine Übersicht der Diagnosen eines Patienten zuzugreifen Patienten anhand ihrer Diagnose zu suchen oder zu prüfen ob eine konkrete Diagnose bei einem Patienten vorliegt sind wichtige Funktionen im klinischen Behandlungsablauf. In FHIR werden Diagnosen mit der Condition-Ressource repräsentiert. Da die Diagnosen in klinischen Primärsystemen in der Regel in ICD-10-codierter Form vorliegen fordert ISiK in erster Linie diese Form des Austausches. Falls eine Diagnose zwar dokumentiert aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt) ist alternativ eine Repräsentation als Freitext-Diagnose möglich. Kompatibilität Für das Profil ISiKDiagnose wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden dass Instanzen die gegen ISiKDiagnose valide sind auch valide sind gegen * das [Profil ProfileConditionDiagnose der Medizininformatik-Initative](https www.medizininformatik-initiative.de fhir core modul-diagnose StructureDefinition Diagnose) * das [Profil KBV_PR_Base_Condition_Diagnosis der KBV](https fhir.kbv.de StructureDefinition KBV_PR_Base_Condition_Diagnosis)] Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil beschreibt die Nutzung von Organisationseinheiten innerhalb eines Krankenhauses oder eines Krankenhauses als ganzem in ISiK-Szenarien.

Diese Profil ermöglicht die Dokumentation von Allergien und Unverträglichkeiten in ISiK Szenarien. Motivation Die Möglichkeit auf eine Übersicht der Allergien und Unverträglichkeiten eines Patienten zuzugreifen ist eine wichtige Funktion im klinischen Behandlungsablauf. Dies gilt insbesondere aber nicht ausschließlich im Bereich der Arzneimitteltherapiesicherheit. Motivierender Use-Case zur Einführung dieser Profile ist die [Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS](https simplifier.net guide isik-medikation-v4 ImplementationGuide-markdown-UebergreifendeUseCases-AMTS). In FHIR werden Allergien und Unverträglichkeiten mit der [AllergyIntolerance](https hl7.org fhir R4 allergyintolerance.html)-Ressource repräsentiert. Kompatibilität Für das Profil ISiKAllergieUnvertraeglichkeit wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden dass Instanzen die gegen ISiKAllergieUnvertraeglichkeit valide sind auch valide sind gegen * [das Profil KBV_PR_Base_AllergyIntolerance der KBV](https fhir.kbv.de StructureDefinition KBV_PR_Base_AllergyIntolerance) * [das Profil EMDAF_PR_AllergyIntolerance der GEVKO](https fhir.gevko.de StructureDefinition EMDAF_PR_AllergyIntolerance) * [das Profil AllergyIntolerance-uv-ips der International Patient Summary](http hl7.org fhir uv ips StructureDefinition AllergyIntolerance-uv-ips) Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil ermöglicht die Abbildung von Besuchen Aufenthalten eines Patienten in einer Gesundheitseinrichtung. Motivation Informationen über die Besuche des Patienten entlang seines Behandlungspfades im Krankenhaus sind ein wichtiger Bestandteil des einrichtungsinternen Datenaustausches. Sie ermöglichen die Unterscheidung von stationären und ambulanten sowie aufgenommenen und entlassenen Patienten. Weiterhin ist aus den Besuchsinformationen der aktuelle Aufenthaltsort des Patienten (Fachabteilung Station Bettplatz) ermittelbar. Klinische Ressourcen werden in FHIR durch Verlinkung auf die Encounter-Ressource in einen Kontext zum Besuch gestellt. Dieser Kontext ist wichtig für die Steuerung von Zugriffsberechtigungen und Abrechnungsprozessen. Zu Beginn der meisten klinischen Workflows steht die Auswahl des Besuchskontextes. Dies geschieht bspw. durch das Suchen der Encounter-Ressource anhand von Eigenschaften wie Aufnahmenummer Fallart oder Aufnahmedatum. Daraufhin werden die zutreffenden Suchergebnisse angezeigt und der gewünschte Besuch ausgewählt. In FHIR werden Besuche Aufenthalte aber auch virtuelle Kontakte mit der `Encounter`-Ressource repräsentiert. Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter pagelink Fall text Fall-Begriff in ISiK Kompatibilität Für das Profil ISiKKontaktGesundheitseinrichtung wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden dass Instanzen die gegen ISiKKontaktGesundheitseinrichtung valide sind auch valide sind gegen * Profil [Kontakt mit einer Gesundheitseinrichtung der Medizininformatik-Initiative](https www.medizininformatik-initiative.de fhir core modul-fall StructureDefinition KontaktGesundheitseinrichtung) Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil dient der strukturierten Erfassung von Standortangaben eines Krankenhauses oder von Organisationseinheiten innerhalb eines Krankenhauses in ISiK-Szenarien. Motivation In FHIR wird die Organisation (Organization) vom Standort (Location) eindeutig abgegrenzt. Die Abbildung von Standorten in einem Krankenhaus unterstützt u.a. die Raum- und Bettenbelegung in strukturierter Form. Die Erfassung des Standortes in strukturierter Form soll u.a. ermöglichen - Zuweisungen von Diensten an bestimmte Standorte im Rahmen des Terminmanagements - Die Raum- und Betten-Belegung in strukturierter Form (interdisziplinär) - u.a. für - Patientenportale im Rahmen der Terminbuchung z.B. um den Wunsch nach Einzelbett bzw. 1 oder 2 Betten abzubilden - KIS und weitere Subsysteme - zur Patientenabholung und Information für den Transportdienst - Abbildung der Verfügbarkeit eines spezifischen Bettenstellplatzes (z.B. mit spezifischem Monitoring-Device) - Im Rahmen der Versorgung kann eine der folgenden Beispiel-Fragen beantworten werden - Handelt es sich um ein Isolationszimmer? - Gibt es bestimmte Ausstattung z.B. Beatmungsgeräte? - etc. Dafür werden Standort-Profile in unterschiedlicher Granularität definiert. Kompatibilität Für das Profil ISiKStandort wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt. Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Behandlungen Prozeduren eines Patienten im Rahmen des Bestätigungsverfahrens der gematik. Motivation Die Möglichkeit auf eine Übersicht der Prozeduren eines Patienten zuzugreifen Patienten anhand durchgeführter oder geplanter Prozeduren zu suchen oder zu prüfen ob eine konkrete Prozedur bei einem Patienten durchgeführt wurde sind wichtige Funktionen im klinischen Behandlungsablauf. In FHIR werden Prozeduren mit der Procedure-Ressource repräsentiert. Da die Prozeduren in klinischen Primärsystemen in der Regel in OPS-codierter Form vorliegen fordert ISiK in erster Linie diese Form des Austausches. Falls eine Prozedur zwar dokumentiert aber noch nicht codiert wurde (z.B. wenn die Kodierung erst nach der Entlassung erfolgt) ist alternativ eine Repräsentation als Freitext-Prozedur möglich. Kompatibilität Für das Profil ISIKProzedur wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden dass Instanzen die gegen ISIKProzedur valide sind auch valide sind gegen * [Profil Prozedur](https www.medizininformatik-initiative.de fhir core modul-prozedur StructureDefinition Procedure) der Medizininformatik Initiative Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.

Dieses Profil beschreibt die maschinenlesbare Auswahl von Codes für die Kodierung spezifischer FHIR-Elemente in ISiK-Szenarien. Motivation ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus- System-interne Kodierungen. Mittels der Veröffentlichung von ValueSets können Auswahllisten für externe Clients bereitgestellt werden sodass diese entsprechende Kodierungen ebenfalls anbieten können. Kompatibilität Für das Profil ISiKValueSet wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt. Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.