Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsinformation’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsinformation’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverabreichung’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverabreichung’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverordnung’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverordnung’ zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

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

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden lesenden Interaktionen, die ein ISiK-konformes System unterstützen muss, um Abfragen zum Medikament zu ermöglichen.

HISTORIE:

• change Alle modifizierenden Interaktionen (z.B. update, create) wurden entfernt aus dieser Rolle und ausgelagert in eine dedizierte Rolle.
• 5.0.0
  • refactorals eigene Rolle initiiert

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden modifizierenden Interaktionen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikament’ zu bestehen.

HISTORIE:

• change Initialisierung als eigene Rolle: Alle modifizierenden Interaktionen (z.B. update, create) wurden entfernt aus der Rolle ISiKCapabilityStatementMedikamentRolle und ausgelagert in diese dedizierte Rolle, um eine klarere Trennung der Verantwortlichkeiten zu ermöglichen.
• change Ergänzung der Interaktion transaction, da dies dem Schema der anderen modifizierenden Rollen entspricht und für ISiK-Zwecke als sinnvoll erachtet wird.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden lesenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsinformation’ zu bestehen.

HISTORIE:

• change Alle modifizierenden Interaktionen (z.B. update, create, transaction) wurden entfernt aus dieser Rolle und ausgelagert in eine dedizierte Rolle.
• 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.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden modifizierenden Interaktionen, die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsinformation’ zu bestehen.

HISTORIE:

• change Initialisierung als eigene Rolle: Alle modifizierenden Interaktionen (z.B. update, create, transaction) wurden entfernt aus der Rolle ISiKCapabilityStatementMedikationInformationRolle und ausgelagert in diese dedizierte Rolle, um eine klarere Trennung der Verantwortlichkeiten zu ermöglichen.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden lesenden Interaktionen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverabreichung’ zu bestehen.

HISTORIE:

• change Alle modifizierenden Interaktionen (z.B. update, create, transaction) wurden entfernt aus dieser Rolle und ausgelagert in eine dedizierte Rolle.
• 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.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden modifizierenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverabreichung’ zu bestehen.

HISTORIE:

• change Initialisierung als eigene Rolle: Alle modifizierenden Interaktionen (z.B. update, create, transaction) wurden entfernt aus der Rolle ISiKCapabilityStatementMedikationVerabreichungRolle und ausgelagert in diese dedizierte Rolle, um eine klarere Trennung der Verantwortlichkeiten zu ermöglichen.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden lesenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverordnung’ zu bestehen.

HISTORIE:

• change Alle modifizierenden Interaktionen (z.B. update, create, transaction) wurden entfernt aus dieser Rolle und ausgelagert in eine dedizierte Rolle.
• 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.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen zum Erstellen (CREATE) und Ändern (UPDATE) einer Medikationsverordnung, die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls ‘Medikation’, Bereich ‘Medikationsverordnung’ zu bestehen.

HISTORIE:

• change - 2024-06-19: Erstellung des CapabilityStatements auf Basis der vorliegenden CREATE- und UPDATE-Interaktionen für Medikationsverordnungen.

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

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 ATC Codings in ISiK

Data Type profile for Snomed-CT Codings in ISiK

Quantity Datentyp der die Nutzung von UCUM vorgibt. Bei dimensionslosen Einheiten wie ‘Tablette’ wird ein code von ‘1’ erwartet, ‘Tablette’ kann als String in Unit hinterlegt werden.

Quantity Datentyp für Dosage Informationen, der die Nutzung des VS DosageDoseQuantityDE vorgibt.

Extension zur Dokumentation eines im Rahmen der AMTS bewusst eingegangenen Risikos. In diesem Freitext kann die Begründung und ggf. zu treffende besondere Maßnahmen dokumentiert werden.

Mit dieser Erweiterung kann das mit einer Medikation angestrebte Behandlungsziel ausführlich dokumentiert werden (z. B. Symptomkontrolle, Heilung, Prävention). Dies unterstützt die individuelle Therapieplanung, die Erfolgskontrolle und die Kommunikation zwischen verschiedenen Leistungserbringern.

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 Verlinkung der Medikationsverordnung die ersetzt wurde

Mit dieser Erweiterung kann festgelegt werden, welche vorherige Medikation durch die aktuelle Verordnung ersetzt wird. Sie erleichtert die Nachverfolgung von Therapieänderungen, sorgt für Transparenz im Medikationsprozess.

Diese Erweiterung ermöglicht die genaue Angabe der Art der Medikation, beispielsweise ob es sich um eine Dauermedikation, Bedarfsmedikation oder eine situative Medikation handelt. Dies trägt zur besseren Strukturierung von Medikationsplänen und zur eindeutigen Kommunikation über die Medikation bei.

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.

Mit dieser Erweiterung kann kenntlich gemacht werden, ob ein Arzneimittel als Selbstmedikation (d. h. ohne ärztliche Verordnung) eingenommen wird. Sie trägt zur vollständigen Erfassung der aktuellen Medikation und zur Erhöhung der Therapiesicherheit bei.

Diese Erweiterung dokumentiert das geplante Enddatum bzw. den geplanten Endzeitpunkt eines Encounters. Sie unterstützt die Vorausplanung von Aufenthalten oder Behandlungen, beispielsweise für die Ressourcenplanung, Terminverwaltung und für die Kommunikation mit nachfolgenden Einrichtungen.

Diese Extension dient der Erfassung des geplanten Startzeitpunkts (dateTime) eines Encounters, z. B. einer stationären Aufnahme, Operation oder eines Termins. Sie ermöglicht eine strukturierte Terminplanung, erleichtert die Koordination verschiedener Versorgungsprozesse und verbessert die Kommunikation zwischen Systemen und Leistungserbringern.

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 ermöglicht die Zusammenführung einzelner MedikationsInformationen eines Patienten in ISiK Szenarien.

Die MedicationList verweist auf MedicationStatement-Ressourcen und bildet Medikationen ab, die aktuell eingenommen, im Krankenhaus verabreicht oder aus externen Quellen dokumentiert wurden - etwa durch Patientenangaben, Medikationspläne oder Entlassbriefe. Im Unterschied zum eMP der ePA ist die ISiK-MedikationsListe dynamisch generierbar und systemseitig aktualisierbar. Sie kann auch Informationen enthalten, die außerhalb des eigenen Hauses erfasst wurden – sofern diese dem System strukturiert vorliegen (z.B. durch eMP-Import). Ein Import aus dem eMP ist möglich, aber nicht verpflichtend.

Dieses Profil ermöglicht die Abbildung von patientenunabhängigen Informationen zu Medikamenten in ISiK Szenarien.

Motivation

Die strukturierte Bereitstellung von Informationen zu Medikamenten ist eine zentrale Voraussetzung für eine interoperable Arzneimitteltherapie und unterstützt insbesondere Prozesse im Kontext der Arzneimitteltherapiesicherheit (AMTS) sowie der sektorenübergreifenden Versorgung.

In FHIR werden Medikamente mit der Medication-Ressource repräsentiert.

Kompatibilität

Für das Profil ISiKMedikament wird eine größtmögliche Kompatibilität mit dem Profil epa-medication der gematik angestrebt. Ziel ist insbesondere eine vergleichbare semantische Struktur zur Unterstützung interoperabler Nutzungsszenarien.

Die spezifischen Extensions des epa-medication-Profils werden in diesem Profil jedoch nicht übernommen. Stattdessen erlaubt das Profil die Nutzung von Extensions, um projektspezifische Anforderungen abzubilden.

Es kann nicht sichergestellt werden, dass Instanzen, die gegen ISiKMedikament valide sind, auch valide gegen das epa-medication-Profil sind.

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

Dieses Profil ermöglicht die Abbildung der Verabreichung von Medikamenten für einen Patienten in ISiK Szenarien. Hinweis zur Auswahl des Profils: In Abgrenzung zu ISiKMedikationsInformation (MedicationStatement) wird mittels des vorliegenden Profils die Verabreichung eines Medikaments an einen Patienten mit einer Zeitpunkt-genauen Angabe abgebildet (.effectiveDateTime oder .effectivePeriod auf Sekundenebene gemäß der FHIR-Core Vorgabe). D.h. die lediglich Datums-genaue Angabe ist im vorliegenden Profil nicht erlaubt. Das Profil ISiKMedikationsInformation (MedicationStatement) kann ebenfalls für die Abbildung der Verabreichung von Medikamenten für einen Patienten verwendet werden, wenn keine Zeitpunkt-genauen Angaben zur Verabreichung vorliegen, sondern lediglich Datums-genaue Angaben (einschließlich Granularität Jahr, Monat oder Tag).

Begründung zur Profil- und Nutzungsdifferenzierung: Handelt es sich bei Erfassung um eine medizinische Verabreichungsdokumentation, dann ist ein genauer Zeitstempel zwingend. Die medizinische Verabreichungsdokumentation muss durch medizinisches Personal erfolgen. Angaben von Patienten und Angehörigen sind grundsätzlich keine medizinische Verabreichungsdokumentation und daher als MedicationStament zu erfassen(‘report that such a sequence (or at least a part of it) did take place’).

Hinweis zur Pausierung einer Medikation (Best-Practice):

Für die Abbildung der Pausierung einer Medikation wird empfohlen, mehrere MedicationAdministration-Ressourcen zu verwenden, anstatt eine bestehende zu überschreiben. Dies bringt folgende Vorteile:

• Korrekte Statusabbildung:
  Das status-Feld muss stets aktuell gepflegt werden, um den momentanen Zustand der Medikation systemweit sichtbar und durchsuchbar zu halten.

• Effiziente Abfragen über REST API:
  In Kombination mit effective[x] ermöglicht das status-Feld die gezielte Abfrage aller aktuell gültigen Medikationseinträge über die REST API.
  Wird stattdessen nur das dosage-Element verändert, ist keine zuverlässige Filterung möglich – alle MedicationAdministrations müssten abgerufen und manuell analysiert werden.

• Erhalt von Verlaufsinformationen:
  Wenn z.B. auch ein statusReason (z.B. „pausiert wegen Nebenwirkungen“) dokumentiert wird, ginge diese Information bei einem Update der bestehenden Ressource verloren, sobald die Medikation fortgesetzt wird.
  Durch neue MedicationAdministration-Einträge bleibt die Verlaufshistorie erhalten.
  (Dieser Anwendungsfall ist aktuell nicht gefordert, aber zukünftig denkbar.)

Dieses Profil ermöglicht die Abbildung von Medikationsverordnungen eines Patienten in ISiK Szenarien.

Dieses Profil ermöglicht die Abbildung von Informationen zur Medikation eines Patienten in ISiK Szenarien.

Hinweis zur Auswahl des Profils: In Abgrenzung zu ISiKMedikationsVerabreichung (MedicationAdministration) wird mittels des vorliegenden Profils die Verabreichung eines Medikaments an einen Patienten mit einer lediglich Datums-genauen Angabe abgebildet (einschließlich Granularität Jahr, Monat oder Tag für .effectiveDateTime oder .effectivePeriod auf Datums-Ebene gemäß der FHIR-Core Vorgabe). Zur sekunden-genauen Angabe der Verabreichung eines Medikaments (im Sinne einer medizinischen Verabreichungsdokumentation durch medizinisches Personal) an einen Patienten SOLL das Profil ISiKMedikationsVerabreichung (MedicationAdministration) verwendet werden. Siehe entsprechende Profilseite für weitere Begründung.

Hinweis zur Pausierung einer Medikation (Best-Practice):

Für die Abbildung der Pausierung einer Medikation wird empfohlen, mehrere MedicationStatement-Ressourcen zu verwenden, anstatt eine bestehende zu überschreiben. Dies bringt folgende Vorteile:

• Korrekte Statusabbildung:
  Das status-Feld muss stets aktuell gepflegt werden, um den momentanen Zustand der Medikation systemweit sichtbar und durchsuchbar zu halten.

• Effiziente Abfragen über REST API:
  In Kombination mit effective[x] ermöglicht das status-Feld die gezielte Abfrage aller aktuell gültigen Medikationseinträge über die REST API.
  Wird stattdessen nur das dosage-Element verändert, ist keine zuverlässige Filterung möglich – alle MedicationStatements müssten abgerufen und manuell analysiert werden.

• Erhalt von Verlaufsinformationen:
  Wenn z.B. auch ein statusReason (z.B. „pausiert wegen Nebenwirkungen“) dokumentiert wird, ginge diese Information bei einem Update der bestehenden Ressource verloren, sobald die Medikation fortgesetzt wird.
  Durch neue MedicationStatement-Einträge bleibt die Verlaufshistorie erhalten.
  (Dieser Anwendungsfall ist aktuell nicht gefordert, aber zukünftig denkbar.)

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.

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.

ISiK Therapiearten für Medikation

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

Erlaubte ListModes der ISiK MedikationsListe

Enthaelt alle SNOMED CT Administrationsarten

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 Therapiearten für Medikation

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