Confirmation

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.

Dieses Profil ermöglicht die krankenhaus-interne Übermittlung eines Berichtes bestehend aus beliebien strukturierten FHIR-Ressourcen sowie einer textuellen HTML-Repräsentation (Narrative) an einen ISiK-Basis-kompatiblen Server. Motivation In der heterogenen Systemlandschaft im Krankenhaus sind eine Vielzahl spezialisierter Subsysteme im Einsatz. Die Ergebnisse aus diesen Subsystemen sind aktuell jedoch häufig nicht in den Primärsystemen des Krankenhauses verfügbar denn es bestehen folgende Herausforderungen Die Daten in Subsystemen sind sehr heterogen und können hochspezialisiert sein. Bei der Nutzung dieser Subsysteme besteht häufig ein Interesse auf die menschenlesbare Repräsentation der strukturierten Daten einwirken zu können. Künftig ist mit Szenarien zu rechnen bei denen Befunde aus Subsystemen in eine elektronische Patientenakte übertragen werden sollen. Aktuell werden Befunde obwohl diese in den Subsystemen in hochstrukturierter Form vorliegen nur als PDF an das Primärsystem übermittelt. Oft weil kein strukturiertes Format spezifiziert ist das sowohl versendendes Subsystem als auch empfangendes Primärsystem implementiert haben. Der Umfang in dem eine Datenübernahme in ein Primärsystem möglich ist variiert stark zwischen den Systemen oder Installationen z.B. abhängig davon ob ein Modul für Vitalparameter installiert ist. Die ISiK-Spezifikation begegnet diesen Herausforderungen indem sie die Übermittlung von Ergebnissen aus Subsystemen an die Primärsysteme in Form von strukturierten Dokumenten erfordert die über eine menschenlesbare Repräsentation verfügen. Diese strukturierten Dokumente werden im ISiK-Kontext als Berichte bezeichnet. Dabei sind die strukturierten Inhalte der Berichte harmonisiert mit den verbreiteten Formaten für Primärsysteme. (Semi-)Strukturierte Dokumente werden in FHIR mit der `Composition`-Ressource repräsentiert die die Dokumentenmetadaten sowie die textuelle Repräsentation des Dokumentes enthält. Die Composition referenziert auf beliebige weiter FHIR-Ressourcen die die strukturierten Komponenten des Dokumentes darstellen. Für den Transport wird die Composition zusammen mit allen direkt oder indirekt referenzierten Ressourcen in eine `Bundle`-Ressource vom Typ `document` aggregiert. Das Document-Bundle trägt alle Eigenschaften eines Dokumentes Abgeschlossenheit Unveränderbarkeit Signierbarkeit. Es obliegt dem empfangenden System ob dieses Dokument lediglich in seiner Gesamtheit persistiert wird oder ob darüber hinaus einzelne Bestandteile (Ressourcen) als strukturierte Daten automatisch oder auf Veranlassung eines Benutzers in die Patientenakte übernommen werden. In der aktuellen Ausbaustufe von ISiK ist lediglich die Übernahme und Anzeige der Dokument-Metadaten (z.B. Dokumenttyp Dokumentdatum Quelle) und der menschenlesbaren HTML-Repräsentation in die Primärsysteme erforderlich. In weiteren Ausbaustufen von ISiK soll darüber hinaus eine Übernahme der strukturierten Anteile der Dokumente möglich sein die den ISiK-Spezifikationen entsprechen z.B. Diagnosen und Prozeduren. Kompatibilität Hinweise zu Inkompatibilitäten können über die [Portalseite](https service.gematik.de servicedesk customer portal 16) gemeldet werden.