Akteur, der ISiK-konforme Ressourcen verarbeitet und anzeigt (Client-/Konsumenten-Perspektive, u. a. CompositionKonsumentenRolle).

Akteur, der ISiK-konforme Ressourcen bereitstellt (Server-Perspektive der CapabilityStatements, insb. ISiKCapabilityStatementBasisServerAkteur).

Producer, der zusätzlich das ISiK-Modul Terminplanung (ISiKTermin) implementiert. Trägt modulabhängige Obligations, die für einen generischen Producer ohne Terminmodul nicht gelten (z.B. die Verknüpfung eines Kontakts mit einem Termin über Encounter.appointment).

CapabilityStatement für den Akteur ISiKCapabilityStatementBasisServerAkteur. Dieser Akteur aggregiert die Rollen zur Abfrage von Stammdaten, Erweiterte Stammdaten, Aufbau-Struktur, Terminologie, klinischen Daten, Abrechnungsinformationen und Gesundheitsstatus.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen, die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren für das Modul Vitalparameter zu bestehen.

HISTORIE:

Historie: mit der Version 4.0.2 des IG ICU-Normalstation-Workflow wurde das vorliegende CapabilityStatement im Sinne eines eigenständigen Akteurs extrahiert (die Funktionalität bleibt dabei unverändert).

Version 4.0.1

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

CapabilityStatement für die Rolle ISiKCapabilityStatementAmbulanteStammdatenRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf von ISiKAmbulanteStammdaten-Ressourcen.

CapabilityStatement für die Rolle ISiKCapabilityStatementAufbaustrukturRolle. Diese Rolle stellt Interaktionen zur Abfrage von Informationen zur Aufbaustruktur bereit. Die Aufbaustruktur umfasst die Organisationseinheiten, Standorte und deren Zuordnungen.

CapabilityStatement für die Rolle ISiKCapabilityStatementCompositionKonsumentenRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf und der Verarbeitung von ISiKBerichtBundles.

CapabilityStatement für die Rolle ISiKCapabilityStatementErweiterteStammdatenRolle. Diese Rolle stellt erweiterte Interaktionen zur Abfrage von Stammdaten bereit.

CapabilityStatement für die Rolle ISiKCapabilityStatementGesundheitsstatusRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf und der Verarbeitung von ISiKObservation-Ressourcen.

CapabilityStatement für die Rolle ISiKCapabilityStatementImplantatRolle. Diese Rolle stellt Interaktionen zur Abfrage von Informationen zu Implantaten bereit.

CapabilityStatement für die Rolle ISiKCapabilityStatementKlinischeRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf und der Verarbeitung von ISiKProzeduren und ISiKDiagnosen.

CapabilityStatement für die Rolle ISiKCapabilityStatementLeistungserbringerRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf und der Verarbeitung von ISiKPersonen im Gesundheitsberuf.

CapabilityStatement für die Rolle ISiKCapabilityStatementStammdatenRolle. Diese Rolle beschreibt Interaktionen zum Abruf und der Verarbeitung grundlegender Stammdaten.

CapabilityStatement für die Rolle ISiKCapabilityStatementTerminologieRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf und der Verarbeitung von Terminologie-Ressourcen.

CapabilityStatement für die Rolle ISiKCapabilityStatementVersicherungsverhaeltnisRolle. Diese Rolle beschreibt verpflichtende Interaktionen zum Abruf von ISiKVersicherungsverhaeltnis-Ressourcen.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen, die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren für das Modul Vitalparameter zu bestehen.

HISTORIE:

Historie: mit der Version 4.0.2 des IG ICU-Normalstation-Workflow wurde das vorliegende CapabilityStatement im Sinne einer eigenständigen Rolle extrahiert (die Funktionalität bleibt dabei unverändert).

Version 4.0.1

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

Dieses Profil bildet den ambulanten Abrechnungsfall ab (Account mit type = AMB).

Es ist strukturell identisch zum Profil ISiKAbrechnungsfallStationaer und unterscheidet sich nur durch die feste Fallart type = AMB. Die setting-spezifische System-Verantwortung (z.B. Scheinnummer, servicePeriod und owner ambulant; Abrechnungsdiagnose/-prozedur mit Haupt-/Nebendiagnose-Klassifikation stationär) wird über die zugehörigen Obligation-Profile (ISiKAbrechnungsfallAmbulant-obl bzw. ...Stationaer-obl) ausgedrückt.

Motivation und Hintergrund zum Fall-Begriff: siehe ISiKAbrechnungsfallStationaer.

Dieses Profil ermöglicht die Gruppierung von medizinischen Leistungen zu einem gemeinsamen Abrechnungskontext. Zugleich dient es im Kontext von ISiK derzeit im Wesentlichen der Abbildung einer Fallnummer, über die im Krankenhaus unterschiedliche Prozesse - auch administrativer Natur - abgewickelt werden. Das Profil wurde nicht primär zum Zweck der Abbildung von Abrechnungsprozessen definiert.

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 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 gemeldet werden.

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.

In FHIR werden Allergien und Unverträglichkeiten mit der AllergyIntolerance-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
• das Profil EMDAF_PR_AllergyIntolerance der GEVKO
• das Profil AllergyIntolerance-uv-ips der International Patient Summary

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die Darstellung von FHIR-fremden Formaten (z.B. PDFs, Bilder, CDA) in ISiK Szenarien.

Motivation

Für FHIR-fremde Formate werden die Daten base64-codiert in der Binary-Ressource (in XML oder JSON) transportiert oder über die REST-API am Binary-Endpunkt in ihrem nativen Format bereitgestellt. Binary-Ressourcen werden von Attachment-Elementen in DocumentReference-Ressourcen verlinkt und damit in den Kontext anderer FHIR-Ressourcen (z.B. Patient und Encounter) gestellt.

Kompatibilität

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Hinweis

Das ISIK-Binary-Profil ist nicht Bestandteil der Implementierung und des Bestätigungsverfahrens zum ISIK Basismodul. Das Profil ist Teil des ISIK Basismoduls, da es im Modul Dokumentenaustausch implementiert werden muss und ein hohes Potential für die Wiederverwednung in anderen Modulen naheliegt.

Das Document-Bundle dient dem Transport von Berichten zwischen Subsystemen im Krankenhaus. Das Bundle entspricht den Anforderungen an ein FHIR Document Bundle : Alle referenzierten Ressourcen müssen als Einträge im Bundle enthalten sein. Das Bundle unterstützt die Übermittlung einer menschenlesbaren Dokumentation (Narrative) und erlaubt zudem die Übernahme wichtiger Ressourcen (z. B. Diagnosen und Prozeduren), die einem Patienten und Fall (Patient, Encounter) zugeordnet sind.

Dieses Profil beschreibt die maschinenlesbare Repräsentation von system-spezifischen Kodierungen in ISiK-Szenarien.

Motivation

ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus-/System-interne Kodierungen. Das Profil ISiKKatalog (CodeSystem) als Profil erlaubt die Repräsentation der dazugehörigen Codes und Display-Werte.

Eine maschinenlesbare Repräsentation dieser Kodierungen erlaubt es Clients, dazugehörige Anzeigetext und Definitionen zu verarbeiten.

Ein Codesystem eignet sich auch dazu, auf dessen Basis definierte ValueSets zu expandieren (https://hl7.org/fhir/R4/valueset-operation-expand.html). Da ISiKValueSet expandierte Valuesets vorsieht, ist eine dynamische Expansion in der Regel nicht erforderlich. Darüber hinausgehend ist ein Use Case im Kontext der Katalogabfrage folgender: Ein Client möchte eine Expansion neu generieren (z.B. mit anderen Expansionen-Parametern), um das ValueSet beispielsweise in einer anderen Sprache auszugeben.

Dieses Profil ermöglicht die krankenhaus-interne Übermittlung eines Berichtes bestehend aus beliebigen 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 weitere 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 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
• das Profil KBV_PR_Base_Condition_Diagnosis der KBV]
  Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die Darstellung eines gesetzlichen Versicherungsverhältnisses in ISiK Szenarien.

Motivation

ISiK unterstützt Anwendungsszenarien, in denen durch das Krankenhaus erbrachte Leistungen erfasst oder gegenüber Kostenträgern abgerechnet werden. In diesen Anwendungsszenarien wird das Versicherungsverhältnis verwendet, um bspw. den Versicherungsstatus oder die Rechnungsanschrift der Versicherung zu ermitteln.
In FHIR werden Versicherungsverhältnisse mit der Coverage-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKVersicherungsverhaeltnisGesetzlich basiert auf dem GKV-Profil der deutschen Basisprofile. Instanzen, die gegen ISiKVersicherungsverhaeltnisGesetzlich valide sind, sind auch valide gegen

• GKV-Profil der deutschen Basisprofile

Instanzen, die gegen VSDM 2.0 Versicherungsdaten GKV valide sind, sind auch valide gegen dieses Profil

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die Darstellung eines privaten Versicherungsverhältnisses, bzw. eines Selbstzahler-Verhältnisses in ISiK Szenarien.

Motivation:

ISiK unterstützt Anwendungsszenarien, in denen durch das Krankenhaus erbrachte Leistungen erfasst oder gegenüber Kostenträgern abgerechnet werden. In diesen Anwendungsszenarien wird die Coverage-Ressource verwendet, um bspw. den Versicherungsstatus oder die Rechnungsanschrift des Kostenträgers zu ermitteln.

Abgrenzung: Das Selbstzahler-Profil gilt für Szenarien, in denen der Patient selbst (oder eine abweichende natürliche oder juristische Person) als Kostenträger auftritt. Für PKV-Verhältnisse, in denen die Kosten unmittelbar von einer privaten Versicherung übernommen werden (ohne dass der Patient in Vorleistung geht), KANN das Profil Versicherungsdaten PKV aus der jeweils geltenden VSDM 2.0 Spezifikation verwendet werden.

Kompatibilität:

Das Profil ISiKVersicherungsverhaeltnisSelbstzahler basiert auf dem Selbstzahler-Profil der deutschen Basisprofile. Instanzen, die gegen ISiKVersicherungsverhaeltnisSelbstzahler valide sind, sind auch valide gegen

• Selbstzahler-Profil der deutschen Basisprofile

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die Darstellung sonstiger Versicherungsverhältnisses in ISiK Szenarien.

Motivation

ISiK unterstützt Anwendungsszenarien, in denen durch das Krankenhaus erbrachte Leistungen erfasst oder gegenüber Kostenträgern abgerechnet werden, bei denen es sich weder um gesetzliche Versicherungen noch Selbstzahlerverhältnisse handelt. In diesen Anwendungsszenarien wird das Versicherungsverhältnis verwendet, um bspw. den Versicherungsstatus oder die Rechnungsanschrift der Versicherung zu ermitteln.
In FHIR werden Versicherungsverhältnisse mit der Coverage-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKVersicherungsverhaeltnisSonstige basiert auf dem Basis-Coverage-Profil der deutschen Basisprofile.

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die strukturierte Abbildung von Implantaten eines Patienten in ISiK-Szenarien. Implantate stellen dauerhaft oder langfristig im Körper befindliche Medizinprodukte dar und sind häufig von hoher klinischer Relevanz, da sie Diagnostik, Therapieentscheidungen sowie zukünftige Behandlungsmaßnahmen unmittelbar beeinflussen können.

Motivation

Die standardisierte Bereitstellung von Implantatinformationen unterstützt insbesondere:

die eindeutige Identifikation implantierter Medizinprodukte,

die Berücksichtigung implantatspezifischer Besonderheiten bei weiteren diagnostischen oder therapeutischen Maßnahmen,

die Nachverfolgbarkeit im Rahmen von Sicherheitsmeldungen und Rückrufaktionen sowie

die Dokumentation wesentlicher Implantatmerkmale (z. B. Hersteller, Modell, Seriennummer).

Darüber hinaus ermöglicht das Profil eine interoperable und maschinenlesbare Darstellung implantatrelevanter Informationen und trägt zur Verbesserung der Patientensicherheit sowie zur Vermeidung von Risiken und Fehlentscheidungen im Behandlungsprozess bei. Als Bestandteil interoperabler Patientendaten stellt es sicher, dass relevante Implantatvorinformationen systemübergreifend verfügbar sind.

Da Implantate auch im Kontext des EHDS berücksichtigt werden, erscheint eine Aufnahme in ISiK sinnvoll, um die Verfügbarkeit von Implantatinformationen in verschiedenen Anwendungsfällen zu gewährleisten, insbesondere in solchen, die über die Dokumentation in einem Entlassbrief hinausgehen.

Dieses Profil ermöglicht die Abbildung ambulanter Besuche/Kontakte eines Patienten in einer Gesundheitseinrichtung (Encounter mit class = AMB).

Es ist strukturell identisch zum Profil ISiKKontaktGesundheitseinrichtungStationaer und unterscheidet sich nur durch die feste Fallart class = AMB. Die jeweils setting-spezifische System-Verantwortung (z.B. Bettendisposition und Entlassinformationen nur stationär) wird nicht über die Kardinalität, sondern über die zugehörigen Obligation-Profile (ISiKKontaktGesundheitseinrichtungAmbulant-obl bzw. ...Stationaer-obl) ausgedrückt.

Motivation, Kompatibilitätshinweise und Hintergrund zum Fall-Begriff: siehe ISiKKontaktGesundheitseinrichtungStationaer.

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 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

Hinweise zu Inkompatibilitäten können über die Portalseite 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 gemeldet werden.

Dieses Profil dient der strukturierten Erfassung von Bettenstellplätzen (als Standorten) eines Krankenhauses.

Hinweis

Ein einzelnes Bett als Gegenstand kann als FHIR-Ressource ‘Device’ abgebildet werden, das einen Bettenstellplatz referenziert.

Dieses Profil dient der strukturierten Erfassung von Räumen (als Standorten) eines Krankenhauses.

Dieses Profil dient der Abbildung des schädlichen Gebrauchs von Alkohol.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Atemfrequenz eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung der Atemfrequenz ist essenziell für die frühzeitige Erkennung von Gesundheitsveränderungen, die Behandlungsbewertung und die Unterstützung klinischer Entscheidungen.

In FHIR wird die Atemfrequenz mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKAtemfrequenz ist vom Profil VitalSignDE_Atemfrequenz aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Respiratory Rate Profile aus der FHIR R4 Spezifikation.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über den Blutdruck eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung des Blutdrucks ist essenziell für die frühzeitige Erkennung von Gesundheitsveränderungen, die Behandlungsbewertung und die Unterstützung klinischer Entscheidungen.

In FHIR wird der Blutdruck mit der Observation-Ressource repräsentiert, die einzelnen Komponenten des Blutdrucks werden als Component-Elemente abgebildet.

Hinweis: In Fällen, in denen fachlich motiviert ausschließlich ein systolischer Blutdruck erhoben wird (z.B. in der Intensivmedizin), kann für den Slice zur Diastole (DiastolicBP) das Element .dataAbsentReason (mit dem Code ‘not-performed’) verwendet werden.

Kompatibilität

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.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über kurze, relevante EKG-Ausschnitte eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK. Es wurde entwickelt, um spezifische klinische Fragestellungen zu unterstützen, bei denen prägnante und gezielte EKG-Daten im Vordergrund stehen. Für vollständige und längere EKG-Aufzeichnungen sind alternative Formate vorgesehen, die für umfangreiche Daten besser geeignet sind.

Motivation

Die Bereitstellung kurzer EKG-Ausschnitte ermöglicht eine präzise und effiziente Unterstützung bei der Diagnose akuter kardiologischer Fragestellungen, der Überwachung von Arrhythmien oder der Beurteilung bestimmter Ereignisse wie ST-Strecken-Veränderungen. Diese fokussierte Darstellung dient der Optimierung klinischer Entscheidungen und der schnellen Verarbeitung relevanter Daten.

In FHIR wird das EKG durch die Observation-Ressource repräsentiert, wobei spezifische Anforderungen für die Darstellung und Kodierung der Daten in diesem Profil berücksichtigt werden.

Kompatibilität

Das Profil ISiKEKG ist vom Profil EkgDE aus den deutschen Basisprofilen abgeleitet.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über den Glasgow Coma Scale (GCS) Score eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung des Bewusstseinszustands anhand des GCS ist essenziell für die Beurteilung neurologischer Funktionen, die Überwachung von Patienten mit Schädel-Hirn-Trauma oder anderen neurologischen Erkrankungen sowie die Unterstützung klinischer Entscheidungen.

In FHIR wird der GCS-Score mit der Observation-Ressource repräsentiert, wobei die einzelnen Komponenten der Skala - Augenöffnung, verbale Reaktion und motorische Reaktion - als Component-Elemente abgebildet werden.

Kompatibilität

Das Profil ISiKGCS ist vom Profil ScoreDE_GCS aus den deutschen Basisprofilen abgeleitet.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Herzfrequenz eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung der Herzfrequenz ist essenziell für die frühzeitige Erkennung von Herz-Kreislauf-Problemen, die Beurteilung des Gesundheitszustands sowie die Unterstützung klinischer Entscheidungen in der Patientenversorgung.

In FHIR wird die Herzfrequenz mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKHerzfrequenz ist vom Profil VitalSignDE_Herzfrequenz aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Respiratory Rate Profile aus der FHIR R4 Spezifikation.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über das Körpergewicht eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung des Körpergewichts ist essenziell für die Beurteilung des Ernährungszustands, die Überwachung von Veränderungen im Rahmen der Therapie sowie die Unterstützung klinischer Entscheidungen in der Patientenversorgung.

In FHIR wird das Körpergewicht mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKKoerpergewicht ist vom Profil VitalSignDE_Koerpergewicht aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Body Weight Profile aus der FHIR R4 Spezifikation.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Körpergröße eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung der Körpergröße ist essenziell für die Beurteilung von Wachstumsprozessen, die Berechnung wichtiger Indizes wie des Body-Mass-Index (BMI) sowie die Unterstützung klinischer Entscheidungen in der Patientenversorgung.

In FHIR wird die Körpergröße mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKKoerpergroesse ist vom Profil VitalSignDE_Koerpergroesse aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Body Height Profile aus der FHIR R4 Spezifikation.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Körperkerntemperatur eines Patienten im Rahmen der interoperablen Kommunikation gemäß den ISiK Vorgaben.
Dieses Profil repräsentiert sowohl direkte als auch indirekte Messungen der Körperkerntemperatur.

Motivation

Die Erfassung und Überwachung der Körpertemperatur ist essenziell für die frühzeitige Erkennung von Infektionen, die Beurteilung des Gesundheitszustands sowie die Unterstützung klinischer Entscheidungen in der Patientenversorgung. In FHIR wird die Körpertemperatur mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKKoerperkerntemperatur ist vom Profil VitalSignDE_Koerperkerntemperatur aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil OObservation Body Temperature Profile aus der FHIR R4 Spezifikation.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über den Kopfumfang eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung des Kopfumfangs ist essenziell für die Beurteilung von Wachstumsprozessen, insbesondere bei Säuglingen und Kleinkindern, sowie für die frühzeitige Erkennung von Entwicklungsauffälligkeiten oder neurologischen Erkrankungen.

In FHIR wird der Kopfumfang mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKKopfumfang ist vom Profil VitalSignDE_Kopfumfang aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Head Circumference Profile aus der FHIR R4 Spezifikation.

Basisprofil für ISiKLebensZustand Observation

Motivation

Viele medizinischen Entscheidungen benötigen Informationen zu den Lebensumständen eines Patienten. Hierzu gehören eine aktuelle Schwangerschaft, Raucherstatus sowie der Alkoholabususstatus. Motivierender Use-Case zur Einführung dieser Profile ist die Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS.

In FHIR werden Untersuchungen, bzw. Beobachtungen als Observation-Ressource repräsentiert.

Dieses Profil ist eine generische, ISiK-spezifische Observation für die Abbildung von Lebenszuständen.
Die folgenden Profile vom Typ Observation sind spezifische Profile im oben genannten Sinn:

• https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftsstatus
• https://gematik.de/fhir/isik/StructureDefinition/ISiKSchwangerschaftErwarteterEntbindungstermin
• https://gematik.de/fhir/isik/StructureDefinition/ISiKStillstatus
• https://gematik.de/fhir/isik/StructureDefinition/ISiKAlkoholAbusus
• https://gematik.de/fhir/isik/StructureDefinition/ISiKRaucherStatus

Kompatibilität

Für Schwangerschaftsstatus & Erwarteter Geburtstermin wird eine Kompatibilität mit folgenden IPS Profilen angestrebt:

• IPS Resource Profile: Observation - Pregnancy: EDD.
• IPS Resource Profile: Observation - Pregnancy: status

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil dient der Abbildung des Raucherstatus von Patienten.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die arterielle Sauerstoffsättigung eines Patienten im Rahmen der interoperablen Kommunikation gemäß den Vorgaben der ISiK.

Motivation

Die Erfassung und Überwachung der arteriellen Sauerstoffsättigung ist essenziell für die Beurteilung der respiratorischen Funktion, die Überwachung von Patienten mit Atemwegserkrankungen sowie die Unterstützung klinischer Entscheidungen, insbesondere in kritischen Versorgungssituationen.

In FHIR wird die arterielle Sauerstoffsättigung mit der Observation-Ressource repräsentiert.

Kompatibilität

Das Profil ISiKSauerstoffsaettigungArteriell ist vom Profil VitalSignDE_Arterielle_Sauerstoffsaettigung_Pulsoximetrie aus den deutschen Basisprofilen abgeleitet. Es ist kompatibel mit dem Profil Observation Oxygen Saturation Profile aus der FHIR R4 Spezifikation.

Dieses Profil dient der Abbildung des erwarteten Entbindungstermins bei einer Schwangerschaft.

Dieses Profil bildet den Schwangerschaftsstatus einer Patientin ab.

Dieses Profil dient der Abbildung des Stillstatus, d.h ob gestillt/Muttermilch abgepumpt und gefüttert wird.

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

Dieses Profil beschreibt die Organisationseinheit Fachabteilung innerhalb eines Krankenhauses.

Motivation

Die Abbildung der Aufbauorganisation eines Krankenhauses dient der Festlegung von Zuständigkeiten und (Entscheidungs-)Verantwortungen von Organisationseinheiten (z.B. Fachkliniken, Fachabteilungen und -bereichen etc.) in strukturierter Form.

In FHIR wird die Organisation (Organization) vom Standort (Location) eindeutig abgegrenzt.

Die Erfassung der Organisation in strukturierter Form ermöglicht u.a.:

• Zuweisungen von Diensten an bestimmte Bereiche der Aufbauorganisation im Rahmen des Terminmanagements
• Die Raum- und Betten-Belegung in strukturierter Form (interdisziplinär)

Auch die Erfassung des Krankenhauses als Ganzes ist relevant. Entsprechend fokussieren die folgenden Profile zur Organisation auf das Krankenhaus als Ganzes und die Fachabteilung als Organisation.

Kompatibilität

Für das Profil ISiKOrganisationFachabteilung wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen das ISIK Profil valide sind, auch valide sind gegen:

• ​Profil TIOrganization der gematik

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

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
• Profil Patient im International Patient Summary (IPS)
• Profil Patient der MI-Initiative

Gegen folgende Profile ist das Profil ISiKPatient unmittelbar kompatibel:

• ​Profil TIPatient der gematik

Es ist zu beachten, dass das Profil ISiKPatient NICHT unmittelbar kompatibel mit folgenden Profilen ist:

• 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 Profil ermöglicht die Nutzung von in Gesundheitsberufen tätigen Personen in ISiK Szenarien. Motivation: Das Profil ISIKPersonImGesundheitsberuf bildet alle denkbaren medizinischen Leistungserbringer und Fachexperten ab. In den ISiK-FHIR-Profilen können PersonImGesundheitsberuf bspw. als Ausführende einer Prozedur auftreten, im Element performer der Procedure Ressource, oder als die Person, die eine Diagnose stellt, im Element asserter der Condition Ressource.

In FHIR werden PersonImGesundheitsberuf mit der Practitioner-Ressource repräsentiert.
Für das Profil ISIKPersonImGesundheitsberuf wird eine Kompatibilität mit folgenden Profilen angestrebt; allerdings kann nicht sichergestellt werden, dass Instanzen, die gegen ISIKPersonImGesundheitsberuf valide sind, auch valide sind gegen:

• Profil KBV_PR_Base_Practitioner der KBV Basisprofile.
• Profil HiGHmed_IC_Practitioner, MI Initiative - HiGHmed Use Case Infection Control der Medizininformatik Initiative

Gegen folgende Profile ist das Profil ISiKPersonImGesundheitsberuf unmittelbar kompatibel:

• ​Profil TIPractitioner der gematik

Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Informationen über die Rolle eines Leistungserbringers im Rahmen des Bestätigungsverfahrens der gematik.
Motivation Die Rolle von Leistungserbringern innerhalb einer Organisation (z.B. Fachabteilung, Praxis, Krankenhaus) ist eine wichtige Information in Bezug auf die Leistungen, die durch diese Person erbracht werden.

In FHIR wird die Rolle eines Leistungserbringers mit der PractitionerRole-Ressource repräsentiert und wir ausgehend vom PractitionerRole Profil aus dem EHDS in ISiK aufgenommen.

HISTORIE:

• Dieses Profil wird vor dem Hintergrund von FHIR-Profilierungen im Kontext des EHDS in Stufe 6 initial eingebracht.

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 der Medizininformatik Initiative
  Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden.

Dieses Profil ermöglicht die Darstellung von Angehörigen in ISiK Szenarien.

Motivation

Der Angehörige wird vor allem im Zusammenhang mit Anwendungsszenarien verwendet, in denen das Versicherungsverhältnis eine Rolle spielt. Hier können Angehörige, bspw. der hauptversicherte Elternteil eines minderjährigen Kindes, in der Familienversicherung sein. In Selbstzahler-Szenarien können Angehörige die Zahler für eine im Krankenhaus erbrachte Leistung sein. In FHIR werden Angehörige von Patienten mit der RelatedPerson-Ressource repräsentiert.

Kompatibilität

Für das Profil ISiKAngehoeriger 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 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 gemeldet werden.

Obligation-Profil für den ambulanten Abrechnungsfall (type = AMB). Setzt die Producer-Obligations für den generischen Producer. Ambulant-spezifische Elemente (Scheinnummer, servicePeriod, owner, ambulante Abrechnungsdiagnose/-prozedur) tragen hier ihre Obligation.

Obligation-Profil für den stationären Abrechnungsfall (type = IMP). Setzt die Producer-Obligations für den generischen Producer. Die DRG-relevante Klassifikation von Diagnosen/Prozeduren als Haupt-/Nebendiagnose trägt hier ihre Obligation.

Obligation-Profil für ISiKAllergieUnvertraeglichkeit. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKBinary. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKBerichtBundle. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKBerichtSubSysteme. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKDiagnose. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKVersicherungsverhaeltnisGesetzlich. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKVersicherungsverhaeltnisSelbstzahler. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKVersicherungsverhaeltnisSonstige. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKImplantat. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für den ambulanten Kontakt (class = AMB). Setzt die Producer-Obligations für den generischen Producer. Stationär-spezifische Elemente (Aufnahmegrund, hospitalization, Bettendisposition) tragen hier keine Obligation.

Obligation-Profil für den stationären Kontakt (class = IMP). Setzt die Producer-Obligations für den generischen Producer. Stationär-spezifische Elemente (Aufnahmegrund, hospitalization, Bettendisposition/location, Entlassdatum) tragen hier ihre Obligations.

Obligation-Profil für ISiKStandort. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKStandortBettenstellplatz. Leitet vom strukturellen Basis-Profil ab, erbt die gemeinsamen Obligations aus ISiKStandort-obl (inherit-obligations) und ergänzt bettenstellplatzspezifische Obligations.

Obligation-Profil für ISiKStandortRaum. Leitet vom strukturellen Basis-Profil ab, erbt die gemeinsamen Obligations aus ISiKStandort-obl (inherit-obligations) und ergänzt raumspezifische Obligations.

Obligation-Profil für ISiKAlkoholAbusus. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKAtemfrequenz. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKBlutdruckSystemischArteriell. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKEKG. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKGCS. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKHerzfrequenz. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKKoerpergewicht. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKKoerpergroesse. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKKoerperkerntemperatur. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKKopfumfang. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKLebensZustand. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKRaucherStatus. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKSauerstoffsaettigungArteriell. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKSchwangerschaftErwarteterEntbindungstermin. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKSchwangerschaftsstatus. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKStillstatus. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKOrganisation. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKOrganisationFachabteilung. Leitet vom strukturellen Basis-Profil ab, erbt die gemeinsamen Obligations aus ISiKOrganisation-obl (inherit-obligations) und ergänzt fachabteilungsspezifische Obligations.

Obligation-Profil für ISiKPatient. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKPersonImGesundheitsberuf. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKRolleImKrankenhaus. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKProzedur. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Obligation-Profil für ISiKAngehoeriger. Leitet vom strukturellen Basis-Profil ab und setzt akteurspezifische FHIR-Obligations für Producer (Server) und Consumer (Client).

Data Type profile for ASK Codings in ISiK

Data Type profile for ATC Codings in ISiK

Data Type profile for Codings in ISiK

Data Type profile for ICD10-GM Codings in ISiK

Data Type profile for LOINC Codings in ISiK

Data Type profile for ATC Codings in ISiK

Data Type profile for Snomed-CT Codings in ISiK

Defines the level of expectation associated with a given system capability. See the capabilitystatement-prohibited modifier extension to set expectations to not support a feature.

Extension zur Dokumentation von Informationen nach §301 (4 und 4a) SGB V, entsprechend dem ärztliche Reha-Entlassungsbericht. Mit dieser Extension können spezifische Entlassungsinformationen im Kontext einer Rehabilitationsmaßnahme angegeben werden. Dies ist besonders relevant für Einrichtungen, die Leistungen im Bereich Rehabilitation erbringen, und unterstützt die strukturierte Kommunikation im Entlassmanagement.

Ermöglicht es, angelehnt an ExtensionAbrechnungsDiagnoseProzedur, Diagnosen und Prozeduren als abrechnungsrelevant in einem Fallkontext anzugeben — ohne die Verpflichtung, einen Use (Haupt-/Nebendiagnose) anzugeben. Dies ist im ambulanten Kontext nicht üblich.

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.

Enthaelt alle SNOMED DiagnosisSeverity Codes

Enthaelt alle SNOMED Clinical finding, Event und Situation with explicit context codes

Enthaelt alle SNOMED Reason Codes

-

Behandlungsergebnis Reha gemäß §301(4 UND 4A) SGB V. Diagnosenbezogene Bewertung des Behandlungsergebnisses für einen Versicherten/Berechtigten bei Entlassung aus der Reha-Maßnahme bzw. Stellung eines Antrags auf Verlängerung. Vgl. Schlüsseltabelle 2.71 Diagnose - Behandlungsergebnis.

Besondere Behandlungsform der Reha gemäß §301(4 UND 4A) SGB V. Vgl. Schlüsseltabelle 2.51 Besondere Behandlungsformen.

Erweitert das ValueSet EncounterClassDE der Deutschen Basisprofile um die Codes ACUTE, NONAC und OBSENC aus dem HL7 v3 ActCode System zur Harmonisierung mit dem HL7 Europe Hospital Discharge Report (HDR). Ein Issue zur Aufnahme dieser Codes in EncounterClassDE wurde bei den Deutschen Basisprofilen eingereicht.

ISiK vereint hierbei das ValueSet [KontaktArtDe](http://fhir.de/CodeSystem/kontaktart-de) 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.

ISiK Entlassform Reha. Beschreibt Form und ggf. Weiterbehandlung der Entlassung eines Versicherten/Berechtigten aus verwaltungs- und medizinischer Sicht. Vgl. Schlüsseltabelle 2.107 Entlassungsform.

ValueSet der Körperkerntemperatur SnomedCT Konzepte

ValueSet der spezifischen generischen Körperkerntemperatur LOINC Konzepte die nicht dazu dienen eine Körperkerntemperatur zu messen

ValueSet der spezifischen Körperkerntemperatur LOINC Konzepte

ISiK Unterbrechung Reha. Dokumentiert die relevanten Gründe einer Unterbrechung einer Rehabilitationsmaßnahme im Einzelfall. Vgl. Schlüsseltabelle 2.111 Erläuterung zur Unterbrechung.

-

Enthaelt alle SNOMED Procedure Codes

Enthaelt alle SNOMED Codes für ein Mapping der OPS Klassentitel

Enthaelt alle OPS Procedure Codes für Reanimationsmaßnahmen

Enthaelt alle SNOMED Procedure Codes für Reanimationsmaßnahmen

Dieses Valueset enthält die Codes zur Beschreibung der Methode zur Bestimmung des erwarteten Entbindungstermins bei einer Schwangerschaft.

Dieses Valueset enthält die Codes zur Beschreibung des Schwangerschaftsstatus einer Patientin.

Dieses Valueset enthält die Codes zur Beschreibung von Stillstatus LOINC.

HL7 LOINC value set for smoking status. Based on the HL7 Vocab and Structured Doc WG (formerly TC) consensus - per US CDC submission 7/12/2012 for smoking status terms.

-

Behandlungsergebnis Reha gemäß §301(4 UND 4A) SGB V. Diagnosenbezogene Bewertung des Behandlungsergebnisses für einen Versicherten/Berechtigten bei Entlassung aus der Reha-Maßnahme bzw. Stellung eines Antrags auf Verlängerung. Vgl. Schlüsseltabelle 2.71 Diagnose - Behandlungsergebnis.

Besondere Behandlungsform der Reha gemäß §301(4 UND 4A) SGB V. Vgl. Schlüsseltabelle 2.51 Besondere Behandlungsformen.

ISiK definiert an dieser Stelle eigene Encounter Typen. Dieses CodeSystem 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.

ISiK Entlassform Reha. Beschreibt Form und ggf. Weiterbehandlung der Entlassung eines Versicherten/Berechtigten aus verwaltungs- und medizinischer Sicht. Vgl. Schlüsseltabelle 2.107 Entlassungsform.

ISiK definiert an dieser Stelle einen eigene Identifier Typen. Dieses CodeSystem 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.

ISiK Unterbrechung Reha. Dokumentiert die relevanten Gründe einer Unterbrechung einer Rehabilitationsmaßnahme im Einzelfall. Vgl. Schlüsseltabelle 2.111 Erläuterung zur Unterbrechung.

Fragment des CodeSystems urn:ietf:bcp:13 mit den in ISiK relevanten MIME-Typen.

Dieses Profil beschreibt die maschinenlesbare Repräsentation von system-spezifischen Kodierungen in ISiK-Szenarien. **Motivation** ISiK erlaubt in diversen Kontexten die Erweiterung der Kodierung durch Krankenhaus-/System-interne Kodierungen. Das Profil ISiKKatalog (CodeSystem) als Profil erlaubt die Repräsentation der dazugehörigen Codes und Display-Werte. Eine maschinenlesbare Repräsentation dieser Kodierungen erlaubt es Clients, dazugehörige Anzeigetext und Definitionen zu verarbeiten. Ein Codesystem eignet sich auch dazu, auf dessen Basis definierte ValueSets zu expandieren (https://hl7.org/fhir/R4/valueset-operation-expand.html). Da ISiKValueSet expandierte Valuesets vorsieht, ist eine dynamische Expansion in der Regel nicht erforderlich. Darüber hinausgehend ist ein Use Case im Kontext der Katalogabfrage folgender: Ein Client möchte eine Expansion neu generieren (z.B. mit anderen Expansionen-Parametern), um das ValueSet beispielsweise in einer anderen Sprache auszugeben.