Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
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.
| Akteur ISiKCapabilityStatementBasisServerAkteur |
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 Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich. |
| Akteur ISiKCapabilityStatementBasisServerAkteur (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 Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich. |
| CapabilityStatement für Rolle AufbaustrukturRolle |
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 ( |
| CapabilityStatement für Rolle ISiKCapabilityStatementAmbulanteStammdatenRolle |
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 ( |
| CapabilityStatement für Rolle ISiKCapabilityStatementCompositionKonsumentenRolle |
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 ( |
| CapabilityStatement für Rolle ISiKCapabilityStatementErweiterteStammdatenRolle |
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 ( |
| 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 ( |
| 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 ( |
| CapabilityStatement für Rolle ISiKCapabilityStatementTerminologieRolle |
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 ( |
| CapabilityStatement für Rolle ISiKCapabilityStatementVersicherungsverhaeltnisRolle |
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 ( |
| CapabilityStatement für Rolle ImplantatRolle |
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 ( |
| 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 ( |
| 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 ( |
| 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 Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit 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 Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
| 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 ( |
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. |
| characteristic |
Search by physicalType of a Location (e.g. wa = ward). This SearchParameter is defined based on the R6 (build) equivalent (https://build.fhir.org/location-search.html#Location-characteristic). |
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 Dieses Profil ist eine generische, ISiK-spezifische Observation für die Abbildung von Lebenszuständen.
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. |
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 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. |
| 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. |
| ISiKAbrechnungsfall |
Dieses Profil ermöglicht die Gruppierung von medizinischen Leistungen zu einem gemeinsamen Abrechnungskontext. Motivation Komplementär zum Datenobjekt ‘Kontakt - Encounter’ können Fälle, im Sinne einer Gruppierung von medizinischen Leistungen innerhalb eines gemeinsamen Kontextes, zu einem Abrechnungsfall zusammengefasst werden. Ein solcher Abrechnungsfall kann mehrere Kontakte umfassen (z.B. vorstationärer Besuch, stationärer Aufenthalt und nachstationärer Besuch). Gemeinsam mit dem Einrichtungskontakt bildet der Abrechnungsfall einen wichtigen Einstiegspunkt in die Dokumentation der Behandlungsleistungen der Patienten. Als Bindeglied zwischen den Kontakten und dem Versicherungsverhältnis erfolgt eine feingranulare Auflistung, in welchen Zeiträumen ein Behandlungskontext zwischen einer Gesundheitseinrichtung und der Patienten bestand. Zudem werden Diagnosen abschließend / nachträglich dokumentiert, sodass eine Übersicht von relevanten (DRG)-Diagnosen ermöglicht wird, ohne die Gesamtheit aller Kontakte betrachten zu müssen. In FHIR wird der Abrechnungsfall mit der Weitere Hinweise zu den Abgrenzungen der Begrifflichkeiten Fall und Kontakt finden sie unter Fall-Begriff in ISiK. Kompatibilität
Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden. |
| ISiKAbrechnungsfallAmbulant |
Dieses Profil spezifiziert die Anforderungen an die Abbildung von ambulanten Abrechnungsfällen im Krankenhauskontext. Es handelt sich dabei um eine Spezialisierung des ISiK Abrechnungsfall-Profils, das allgemeine Anforderungen an die Abbildung von Abrechnungsfällen definiert. Ambulante-Abrechnungsfall-Angaben unterscheiden sich von stationären im Krankenhaus im Wesentlichen durch die Angabe von:
|
| 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. |
| ISiKAngehoeriger |
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. |
| ISiKBerichtBundle |
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. |
| ISiKBerichtSubSysteme |
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 Für den Transport wird die Composition zusammen mit allen direkt oder indirekt referenzierten Ressourcen in eine 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. |
| ISiKCodeSystem |
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. |
| 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:
|
| ISiKImplantat |
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. MotivationDie standardisierte Bereitstellung von Implantatinformationen unterstützt insbesondere: 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. |
| 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 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 |
| ISiKLaboruntersuchungCRP |
Dieses Profil ermöglicht die Abbildung der Laboruntersuchung CRP eines Patienten in ISiK Szenarien. |
| ISiKLaboruntersuchungGFR |
Dieses Profil ermöglicht die Abbildung der Laboruntersuchung GFR eines Patienten in ISiK Szenarien. |
| ISiKLaboruntersuchungHb |
Dieses Profil ermöglicht die Abbildung der Laboruntersuchung Hb eines Patienten in ISiK Szenarien. |
| ISiKLaboruntersuchungPCT |
Dieses Profil ermöglicht die Abbildung der Laboruntersuchung 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 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. 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
|
| 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
|
| ISiKMedikationsVerordnung |
Dieses Profil ermöglicht die Abbildung von Medikationsverordnungen eines Patienten in ISiK Szenarien. |
| ISiKOrganisation |
Dieses Profil beschreibt die Nutzung von Organisationseinheiten innerhalb eines Krankenhauses oder eines Krankenhauses als ganzem in ISiK-Szenarien. |
| ISiKOrganisationFachabteilung |
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.:
Auch die Erfassung des Krankenhauses als Ganzem 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: Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden. |
| 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. 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:
|
| 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 In FHIR werden PersonImGesundheitsberuf mit der
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. MotivationDie 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:
|
| ISiKStandort |
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:
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. |
| ISiKStandortBettenstellplatz |
Dieses Profil dient der strukturierten Erfassung von Bettenstellplätzen (als Standorten) eines Krankenhauses. HinweisEin einzelnes Bett als Gegenstand kann als FHIR-Ressource ‘Device’ abgebildet werden, das einen Bettenstellplatz referenziert. |
| ISiKStandortRaum |
Dieses Profil dient der strukturierten Erfassung von Räumen (als Standorten) eines Krankenhauses. |
| ISiKStillstatus |
Dieses Profil dient der Abbildung des Stillstatus, d.h ob gestillt/Muttermilch abgepumpt und gefüttert wird. |
| ISiKValueSet |
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. |
| ISiKVersicherungsverhaeltnisGesetzlich |
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. Kompatibilität Das Profil ISiKVersicherungsverhaeltnisGesetzlich basiert auf dem GKV-Profil der deutschen Basisprofile. Instanzen, die gegen ISiKVersicherungsverhaeltnisGesetzlich valide sind, sind auch valide gegen 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. |
| ISiKVersicherungsverhaeltnisSelbstzahler |
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 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 Hinweise zu Inkompatibilitäten können über die Portalseite gemeldet werden. |
| ISiKVersicherungsverhaeltnisSonstige |
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. 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. |
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. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
| 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. |
| Fallbezogene Abrechnungsrelevanz von Diagnosen und Prozeduren |
Diese Extension erlaubt es, angelehnt an die Basisprofil Extension Fallbezogene Abrechnungsrelevanz von Diagnosen und Prozeduren, Diagnosen und Prozeduren als abrechnungsrelevant in einem Fallkontext anzugeben. Allerdings ohne die Verpflichtung, einen Use anzugeben. Dies ist im ambulanten Kontext nicht üblich. |
| 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 MedicationRequestReplaces |
Extension zur Verlinkung der Medikationsverordnung die ersetzt wurde |
| ISiK MedicationStatementReplaces |
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. |
| 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. |
| PlannedEndDate |
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. |
| PlannedStartDate |
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. |
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. |
| TestValueSet |
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. |
| TestKatalog |
These are resources that are used within this implementation guide that do not fit into one of the other categories.