AMTS ISiK Implementierungsleitfaden
Version 6.0.0-rc1 - ballot

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

CapabilityStatement für Rolle ISiKCapabilityStatementGesundheitsstatusRolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

CapabilityStatement für Rolle ISiKCapabilityStatementKlinischeRolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

CapabilityStatement für Rolle LeistungserbringerRolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

CapabilityStatement für Rolle StammdatenRolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement AMTS Akteur

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten ‘SHALL’ (=MUSS) ‘SHOULD’ (=SOLL) ‘MAY’ (=KANN) ‘SHOULD-NOT’ (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden. Die mindestens zu implementierenden Profile für einen Akteur und Interaktionen entsprechen daher den aggregierten Anforderungen der einzelnen Rolle (per ‘imports’). In den CapabilityStatements zu den Rollen sind die Anforderungen tabellarisch gelistet und weisen so die zu implementierenden Profile aus.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

ISiK CapabilityStatement AMTS Akteur (Expanded)

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten ‘SHALL’ (=MUSS) ‘SHOULD’ (=SOLL) ‘MAY’ (=KANN) ‘SHOULD-NOT’ (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden. Die mindestens zu implementierenden Profile für einen Akteur und Interaktionen entsprechen daher den aggregierten Anforderungen der einzelnen Rolle (per ‘imports’). In den CapabilityStatements zu den Rollen sind die Anforderungen tabellarisch gelistet und weisen so die zu implementierenden Profile aus.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

ISiK CapabilityStatement AMTS Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement AMTS WRITE Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Labor Minimal Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikament WRITE Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement MedikamentRolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikation Server - Medikationsinformation

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikationsinformation WRITE Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikationsverabreichung Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikationsverabreichung WRITE Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikationsverordnung Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

ISiK CapabilityStatement Medikationsverordnung WRITE Rolle

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Behavior: Search Parameters

These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.

DateStart

The actual start date of the Encounter (Backport from R5). The parameter cannot repeat or have multiple values.

EndDate

The actual end date of the Encounter (Backport from R5). The parameter cannot repeat or have multiple values.

Structures: Abstract Profiles

These are profiles on resources or data types that describe patterns used by other profiles, but cannot be instantiated directly. I.e. instances can conform to profiles based on these abstract profiles, but do not declare conformance to the abstract profiles themselves.

ISiKLebensZustand

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:

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

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

ISiK AMTS-Bewertung

Dieses Profil ermöglicht die Abbildung von Informationen zur Risikobeurteilung im Rahmen der Arzneimitteltherapiesicherheit (AMTS).

ISiK Alkohol Abusus

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

ISiK Medikationsliste

Dieses Profil ermöglicht die Zusammenführung einzelner MedikationsInformationen eines Patienten in ISiK Szenarien.

Die Medikationsliste 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.

Die Wahl von ‘List.mode’ richtet sich danach, ob die Liste als dokumentierter Zustand oder als Arbeitsgrundlage verwendet wird. Pro Patient und fachlichem Kontext (z. B. Behandlungskontext) sollte in der Regel nur eine aktiv gepflegte Medikationsliste (‘List.mode = working’ und ‘List.status = current’) geführt werden.
Dies dient der Vermeidung konkurrierender Listen und stellt eine eindeutige fachliche Referenz sicher. Mehrere parallele Listen können in unterschiedlichen Kontexten oder für unterschiedliche Zwecke existieren, sollten jedoch klar voneinander abgegrenzt sein.

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.

ISiK Raucherstatus

Dieses Profil dient der Abbildung des Raucherstatus von Patienten.

ISiK Schwangerschaft - Erwarteter Entbindungstermin

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

ISiK Schwangerschaftsstatus

Dieses Profil bildet den Schwangerschaftsstatus einer Patientin ab.

ISiKAllergieUnvertraeglichkeit

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:

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

ISiKDiagnose

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:

ISiKKoerpergewicht

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.

ISiKKoerpergroesse

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.

ISiKKontaktGesundheitseinrichtung

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:

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

ISiKLaboruntersuchung

Dieses Profil ermöglicht die Abbildung von Informationen zur Laboruntersuchungen eines Patienten in ISiK Szenarien. Es dient primär als Vorlage, von der spezifische Laboruntersuchungs-Profile abgeleitet werden, kann aber grundsätzlich auch zur Repräsentation von nicht weiter ausspezifizierten Laboruntersuchungen genutzt werden.

Viele medizinischen Entscheidungen benötigen Informationen zu den Laboruntersuchungen eines Patienten. Hierzu gehören z.B. aktuelle Nierenfunktionswerte, Leberwerte, Blutbildwerte oder Hormone aus Schilddrüse. Jede dieser Untersuchungen wird durch bestimmte [[https://loinc.org/ LOINC]] oder [[http://snomed.info/sct SNOMED CT]] Codes bezeichnet. Der angegebene Wert ist durch genaue Einheitenangaben in [[http://unitsofmeasure.org UCUM]] zu konkretitiseren. Motivierender Use-Case zur Einführung dieser Profile ist die Arzneitmitteltherapiesicherheit im Krankenhaus - AMTS.

In FHIR werden Untersuchungen, bzw. Beobachtungen als Observation-Ressource repräsentiert. Zugehörige Codes und Einheiten sind den entsprechenden Valuessets zu entnehmen.

ISiKLaboruntersuchungCRP

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung des C-reaktiven Proteins (CRP) eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungGFR

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung der Glomerulären Filtrationsrate (GFR) eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungHb

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung des Hämoglobin-Wertes (Hb) eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungPCT

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung des Procalcitonin (PCT) eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungSerumkreatinin

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung Serumkreatinin eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungSerumnatrium

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung Serumnatrium eines Patienten in ISiK Szenarien. Das Profil wird u. A. im Use Case zur Unterstützung von Transplantationsbeauftragten bei der Organspendeerkennung eingesetzt; besonders in diesem Kontext muss es auch Werte abbilden, die im Rahmen von Messungen mittels Point-of-Care-Testing erhoben wurden. Das Profil ist auch geeignet, um Serumnatrium Werte abzubilden, die mittels Laboruntersuchung erhoben wurden.

Eine eindeutige Kennzeichnung für die Differenzierung hinsichtlich der Erhebungsmethode ist derzeit über dieses Profil nicht vorgesehen. Es kann jedoch das Element .method verwendet werden. Die Differenzierung aufgrund der Methode kann unter Umständen sinnvoll sein, wenn im Falle einer Laboruntersuchung ein Arzt die Werte zuerst sichten und bestätigen müsste, bevor sie im PDMS als ‘final’ für den Patienten hinterlegt werden.

ISiKLaboruntersuchungTSH

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung des Thyreoidea-stimulierenden Hormons (TSH) eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungThrombozyten

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung Thrombozyten eines Patienten in ISiK Szenarien.

ISiKLaboruntersuchungTroponin

Dieses Profil ermöglicht die Abbildung der Laboruntersuchung Troponin eines Patienten in ISiK Szenarien.

ISiKMedikament

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.

Hinweise zur Verwendung von Medication.amount

Medication.amount beschreibt in FHIR R4 die Menge des Arzneimittels im verpackten Produkt bzw. Behältnis. Das Element ist nicht zur Abbildung der Wirkstoffstärke vorgesehen; diese wird über Medication.ingredient.strength dokumentiert.

Beispiel: Enthält ein Infusionsbeutel 100 ml Paracetamol-Infusionslösung mit einer Wirkstoffkonzentration von 10 mg/ml, beschreibt Medication.amount die Füllmenge des Behältnisses, also 100 ml / 1 Beutel. Die Wirkstoffkonzentration wird separat über Medication.ingredient.strength als 10 mg / 1 ml angegeben.

Medication.amount ist insbesondere dann relevant, wenn der Arzneimittelcode allein die konkrete Packungsgröße, Füllmenge oder Menge je Verpackungseinheit nicht eindeutig ausdrückt.

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.

ISiKMedikationsInformation

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

ISiKMedikationsVerabreichung

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

ISiKMedikationsVerordnung

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

ISiKPatient

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:

Gegen folgende Profile ist das Profil ISiKPatient unmittelbar kompatibel:

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

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:

Gegen folgende Profile ist das Profil ISiKPersonImGesundheitsberuf unmittelbar kompatibel:

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

ISiKProzedur

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:

ISiKRolleImKrankenhaus

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

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

Structures: Data Type Profiles

These define constraints on FHIR data types for systems conforming to this implementation guide.

ISiKASKCoding

Data Type profile for ASK Codings in ISiK

ISiKATCCoding

Data Type profile for ATC Codings in ISiK

ISiKCoding

Data Type profile for Codings in ISiK

ISiKICD10GMCoding

Data Type profile for ICD10-GM Codings in ISiK

ISiKLoincCoding

Data Type profile for LOINC Codings in ISiK

ISiKPZNCoding

Data Type profile for ATC Codings in ISiK

ISiKSnomedCTCoding

Data Type profile for Snomed-CT Codings in ISiK

Medication Quantity

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.

Medication Quantity Dose Form

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

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

Dosage AsNeededFor

R5 Backport-Extension zur Angabe einer oder mehrerer Bedingungen, unter denen eine Bedarfsmedikation angewendet werden soll.

ExtensionISiKRehaEntlassung

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.

ISiK Accepted Risk

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.

ISiK Behandlungsziel

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.

ISiK CapabilityStatement Imports Expectation

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.

ISiK Medikationsart

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.

ISiK Selbstmedikation

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.

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Current Smoking Status - IPS

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.

DiagnosesSCT

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

ISiK Labor Methode

SNOMED-CT-Codes für Untersuchungsmethoden im Labor (alle Konzepte unterhalb von #272394005 ‘Technique (qualifier value)’).

ISiK Laborbereich

LOINC-Codes zur Kategorisierung von Laboruntersuchungen nach Fachbereichen.

ISiKBehandlungsergebnisRehaVS

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.

ISiKBesondereBehandlungsformRehaVS

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

ISiKEncounterClassDE

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.

ISiKEncounterTypeErweiterungVS

ISiK vereint hierbei das ValueSet KontaktArtDe aus dem deutschen Basisprofil und die übergangsweise hinzugefügten Codes für den ambulanten Kontakt im Krankenhaus. Dieses ValueSet ist als Übergangslösung zu verstehen, da die Inhalte beim TC Terminologien von HL7 eingebracht sind und sobald sie dort publiziert sind, wird eine Migration auf die dortigen Codes erfolgen.

ISiKEntlassformRehaVS

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

ISiKMedikationsartVS

ISiK Therapiearten für Medikation

ISiKUnterbrechungRehaVS

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

Medikationslisten-Modes

Erlaubte ListModes der ISiK MedikationsListe

ObservationCodesCRP

Enthält LOINC-Codes für die Observation CRP

ObservationCodesGFR

Enthält LOINC-Codes für die Observation GFR

ObservationCodesHb

Enthält LOINC-Codes für die Observation Hb

ObservationCodesPCT

Enthält LOINC-Codes für die Observation PCT

ObservationCodesSerumkreatinin

Enthält LOINC-Codes für die Observation Serumkreatinin

ObservationCodesSerumnatrium

Enthält LOINC-Codes für die Observation Serumnatrium

ObservationCodesTSH

Enthält LOINC-Codes für die Observation TSH

ObservationCodesThrombozyten

Enthält LOINC-Codes für die Observation Thrombozyten

ObservationCodesTroponin

Enthält LOINC-Codes für die Observation Troponin

ObservationUnitsCRP

Enthält UCUM-Einheiten für die Observation CRP

ObservationUnitsGFR

Enthält UCUM-Einheiten für die Observation GFR

ObservationUnitsHb

Enthält UCUM-Einheiten für die Observation Hb

ObservationUnitsPCT

Enthält UCUM-Einheiten für die Observation PCT

ObservationUnitsSerumkreatinin

Enthält UCUM-Einheiten für die Observation Serumkreatinin

ObservationUnitsSerumnatrium

Enthält UCUM-Einheiten für die Observation Serumnatrium

ObservationUnitsTSH

Enthält UCUM-Einheiten für die Observation TSH

ObservationUnitsThrombozyten

Enthält UCUM-Einheiten für die Observation Thrombozyten

ObservationUnitsTroponin

Enthält UCUM-Einheiten für die Observation Troponin

ProzedurenCodesSCT

Enthaelt alle SNOMED Procedure Codes

ProzedurenKategorieSCT

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

Schwangerschaft Erwarteter Entbindungstermin Methode

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

Schwangerschaftsstatus Valueset

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

SctRouteOfAdministration

Enthaelt alle SNOMED CT Administrationsarten

Stillstatus LOINC Antwortoptionen

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

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

Erweiterung von Encounter.type in ISiK

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 Medikationsart

ISiK Therapiearten für Medikation

ISiKBehandlungsergebnisReha

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.

ISiKBesondereBehandlungsformReha

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

ISiKEntlassformReha

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

ISiKUnterbrechungReha

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

Other

These are resources that are used within this implementation guide that do not fit into one of the other categories.

AkuteInfektionDerOberenAtemwege
AltersbedingteKreislaufstoerung
Appendektomie
BehandlungsDiagnoseFreitext
DorisQuelle
DorisZiel
Example-condition-ausrufezeichen-primaer
Example-condition-ausrufezeichen-sekundaer
Example-condition-kreuz-stern-primaer
Example-condition-kreuz-stern-sekundaer
ExampleISiKAMTSBewertung1
ExampleISiKLaboruntersuchungCRP1
ExampleISiKLaboruntersuchungGFR1
ExampleISiKLaboruntersuchungHb1
ExampleISiKLaboruntersuchungMaximal
ExampleISiKLaboruntersuchungPCT1
ExampleISiKLaboruntersuchungSerumkreatinin1
ExampleISiKLaboruntersuchungSerumnatrium1
ExampleISiKLaboruntersuchungTSH1
ExampleISiKLaboruntersuchungThrombozyten1
ExampleISiKLaboruntersuchungTroponin1
ExampleISiKMedikament1
ExampleISiKMedikament2
ExampleISiKMedikament3
ExampleISiKMedikament4
ExampleISiKMedikament5
ExampleISiKMedikament6
ExampleISiKMedikament7
ExampleISiKMedikament8
ExampleISiKMedikament9
ExampleISiKMedikationsInformation1
ExampleISiKMedikationsInformation2
ExampleISiKMedikationsInformation3
ExampleISiKMedikationsInformation4
ExampleISiKMedikationsInformation5
ExampleISiKMedikationsInformation6
ExampleISiKMedikationsInformationParkinson1
ExampleISiKMedikationsInformationParkinson2
ExampleISiKMedikationsInformationParkinson3
ExampleISiKMedikationsInformationParkinson4
ExampleISiKMedikationsInformationParkinson5
ExampleISiKMedikationsListe
ExampleISiKMedikationsListeParkinson
ExampleISiKMedikationsVerabreichung
ExampleISiKMedikationsVerabreichung2
ExampleISiKMedikationsVerabreichung3
ExampleISiKMedikationsVerabreichung4
ExampleISiKMedikationsVerordnung
ExampleISiKMedikationsVerordnung2
ExampleISiKMedikationsVerordnungBedarfsmedikation
ExampleOrganSerumNatrium202003110104
ExampleOrganSerumNatrium202003110159
ExampleOrganSerumNatrium202003110306
ExtractedObservationKoerpergewicht
ExtractedObservationKoerpergroesse
Fachabteilungskontakt
FachabteilungskontaktBettenverlegung
FachabteilungskontaktEntlassung
FachabteilungskontaktFachbereichswechsel1
FachabteilungskontaktFachbereichswechsel2
FachabteilungskontaktMinimal2
FachabteilungskontaktNormal
FachabteilungskontaktStationaereAufnahme
FachabteilungskontaktStationswechsel1
FachabteilungskontaktStationswechsel2
ISiKAlkoholAbususBeispiel
ISiKAllergieUnvertraeglichkeitBeispiel1
ISiKKoerpergewichtExample
ISiKKoerpergewichtMaxExample
ISiKKoerpergewichtMinExample
ISiKKoerpergroesseExample
ISiKKoerpergroesseMaxExample
ISiKKoerpergroesseMinExample
ISiKRaucherStatusBeispiel
ISiKSchwangerschaftErwarteterEntbindungsterminBeispiel
ISiKSchwangerschaftsstatusBeispiel
ISiKStillstatusBeispiel
IsikPatientTemplate
ParacetamolInfusion
PatientinMinimal
PatientinMusterfrau
PatientinNormal
PractitionerWalterArzt
PrimaereGonarthroseMinimal
PrimaereGonarthroseNormal
RolleImKrankenhausAllgemeinchirurgieBeispiel
RolleImKrankenhausInnereMedizinBeispiel
SZ1Nachstationaer
SZ1Patient
SZ1Stationaer
SZ1Vorstationaer
SZ2Encounter
SZ2Patient
SZ2Primaerdiagnose
SZ2Sekundaerdiagnose
exp-params
isik-encounter-Sternenfall
isik-patient-156722