BfArM 1994 - 2024 - Die Erstellung erfolgt unter Verwendung der maschinenlesbaren Fassung des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM)
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
WHO, BfArM 1994 - 2024 - Die Erstellung erfolgt unter Verwendung der maschinenlesbaren Fassung des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM)
Ein ISiK Akteur darf sinnvolle Limits für die Einschränkung der Ergebnismenge definieren, wie die Forcierung von Pagination über den Parameter _count
oder die Einschränkung des Zeitraums der zurückgegebenen Ressourcen über den Parameter _since
. Hierbei sollten die Hinweise und vorgaben der ISiK-Spezifikation zu Performance
beachtet werden.
Beispiel: GET [base]/ValueSet?context-type-value=http://terminology.hl7.org/CodeSystem/usage-context-type|focus$http://hl7.org/fhir/resource-types|Encounter Anwendungshinweis:
Mit dieser Abfrage können hausinterne Kataloge anhand des Ressource-Typs ermittelt werden. Diese Informationen sind u.a. relevant im Kontext von:
* Hausinternen Prozeduren/Diagnosen-Codes
* Kodierung von Encounter-Informationen (z.B. Wahlleistungen, Orttypen)
Use Cases im Zusammenhang:
(A) Zur Konfigurationszeit können passende ValueSets von einem Server spezifisch für einen Ressourcentyp abgerufen und vorbereitend auf eine Systemintegration begutachtet
bzw. in Client-Systeme eingebunden werden. In diesem Sinne wird die Abfrage im Kontext der Terminvereinbarung durch einen Termin-Requestor
genutzt.
(B) Zur Laufzeit können spezifische ValueSets synchronisiert bzw. direkt in die Eingabemasken von Clients eingebunden werden.
Weitere Details siehe FHIR-Kernspezifikation
.
Bei ambulanten Fällen spielen noch weitere Informationen eine Rolle, wie z.B. EBM-Ziffern. Da das ISiK-Basismodul allerdings kein Abrechnungsmodul ist, wurden diese Informationen bewusst nicht abgebildet. Für EBM-Ziffern verweisen wir auf die Profilierung eines ChargeItem in den deutschen Basisprofilen: ChargeItem für EBM-Ziffer als Abrechnungsposition
.
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.
Daher hat der Gesetzgeber im Patientendaten-Schutzgesetz (PDSG) der gematik den Auftrag erteilt, offene und standardisierte Schnittstellen zu spezifizieren, die über den reaktiven Datenaustausch hinaus einen bedarfsgerechten Datenaustausch ermöglichen. Die Einhaltung dieser Spezifikation wird in dem ISiK Bestätigungsverfahren geprüft. Die Beschreibung des Bestätigungsverfahrens ist nicht Inhalt dieses Implementierungsleitfadens und ist im Fachportal der gematik beschrieben ( https://fachportal.gematik.de/informationen-fuer/isik/bestaetigungsverfahren-isik
).
1. SMART-App-Launch
: Wenn der Aufruf des Clients im Rahmen von ISiK-Connect erfolgt, kennt der Client bereits beim Start den aktuellen Patienten- und ggf. den Encounterkontext. Dabei wählt ein Anwender im Primärsystem (Server) einen Patienten und Fall aus und startet in diesem Kontext den Client. Referenzen auf Patient und Encounter werden im Zuge der Autorisierung vom Server an Client übermittelt. (Siehe Modul Connect - Launch Context und Scopes
).
2. Bekannte Fallnummer
: Der Client kennt die (Abrechnungs-)Fallnummer (z.B. durch das Einscannen eines Barcodes, oder beim Mapping von V2 auf FHIR aus dem Feldinhalt von PV1.#19
). Anhand dieser kann der Client die im Modul Basis beschriebenen Suchfunktionen für die Encounter-Ressource verwenden, um passende Aufenthalte zu identifizieren ( [base]/Encounter?account:identifier=<Fallnummer>
). Da unter einer Abrechnungs-Fallnummer mehrere Encounter (Besuche) zusammengefasst werden können (z.B. vorstationär + stationär + nachstationär), sollte als zusätzliches Suchkriterium entweder ein Datum/Zeitraum oder eine Selektion auf Encounter.status
verwendet werden. Wenn ein zutreffender Encounter gefunden wurde, kann der Patientenkontext aus der subject-Referenz des Encounters entnommen werden. (Siehe Modul Basis - Encounter Interkationen
4. Manuelle Auswahl
. Nach dem Start des Clients verwendet der Benutzer eine Suchmaske, in der anhand von Patientennummer oder anderer demografischer Daten gesucht werden kann. Der Client verwendet die Patient-Interaktionen des ISiK-Basismoduls
, um auf dem Server nach zutreffenden Patienten zu suchen. Der Anwender wählt den gesuchten Patienten aus der Liste der Suchtreffer aus. Im Anschluss listet der Client, mithilfe der Encounter-Interaktionen des ISiK-Basismoduls
, die relevanten Besuche des ausgewählten Patienten auf. (Anm.: Welche Besuche als “relevant” erachtet werden, liegt im Ermessen des Clients. Es könnte z.B. anhand von Encounter.period
, Encounter.class
und/oder Encounter.status
gefiltert werden). Der Anwender wählt den zutreffenden Encounter aus.
4. Manuelle Auswahl
. Nach dem Start des Clients verwendet der Benutzer eine Suchmaske, in der anhand von Patientennummer oder anderer demografischer Daten gesucht werden kann. Der Client verwendet die Patient-Interaktionen des ISiK-Basismoduls
, um auf dem Server nach zutreffenden Patienten zu suchen. Der Anwender wählt den gesuchten Patienten aus der Liste der Suchtreffer aus. Im Anschluss listet der Client, mithilfe der Encounter-Interaktionen des ISiK-Basismoduls
, die relevanten Besuche des ausgewählten Patienten auf. (Anm.: Welche Besuche als “relevant” erachtet werden, liegt im Ermessen des Clients. Es könnte z.B. anhand von Encounter.period
, Encounter.class
und/oder Encounter.status
gefiltert werden). Der Anwender wählt den zutreffenden Encounter aus.
improve
Performance und Paging-Anforderungen in den übergreifenden Festlegungen eingebracht (gilt für alle Module) https://github.com/gematik/spec-ISiK-Basismodul/pull/1068 - siehe auch ADR im commit
improve
Die Profile ISiKPatient
, ÌSiKOrganization
, sowie ISiKPersonImGesundheitsberuf
enthalten nun eine “impose-Profile”-Extension um die Kompatibilität mit den entsprechenden TI-Commons-Profile
zu dokumentieren.
Begründung Pflichtfeld:
Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKPatient
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Hier sind verschiedene im ambulanten Kontext vorkommende Identifier denkbar. Zur Orientierung wird im ISiK Kontext auf die Identifier einer KBV Base Organization
verwiesen, da diese bereits die relevanten Identifier für die ambulante Versorgung enthält.
Begründung MS:
Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKPatient
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Begründung MS:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
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
.
Begründung Pflichtfeld:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer:
Die Zuordnung MUSS auf einen Encounter der Ebene "Abteilungskontakt" (siehe hierzu Basismodul > UseCases > Abbildung des Konstruktes "Fall") erfolgen.
Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)"Fallnummer" (hier: Encounter.account
) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Begründung Pflichtfeld:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
WICHTIGER Hinweis für Implementierer:
Die Zuordnung MUSS auf einen Encounter der Ebene “Abteilungskontakt” (siehe hierzu Basismodul > UseCases > Abbildung des Konstruktes “Fall”) erfolgen.
Bei der Auswahl des Encounters ist zu beachten, dass unter einer (Abrechnungs-)”Fallnummer” (hier: Encounter.account
) unter Umständen mehrere Encounter gruppiert sein können (z.B. stationärer Besuch mit mehreren vor- und nachstationären Aufenthalten.)
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Bedeutung:
Version des CodeSystems Hinweise:
Jede Änderung des CodeSystems MUSS eine Änderung in der Version des CodeSystems und gebundenen ValueSets nach sich ziehen. Die Versionierung SOLLTE auf dem Konzept von Semantic Versioning
basieren.
Bedeutung:
Version des CodeSystems Hinweise:
Jede Änderung des CodeSystems MUSS eine Änderung in der Version des CodeSystems und gebundenen ValueSets nach sich ziehen. Die Versionierung SOLLTE auf dem Konzept von Semantic Versioning
basieren.
Begründung MS:
Auch in Stufe 4 sind keine (client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen
(siehe CapabilityStatement). Das heißt, entweder führen KISe entsprechende Informationen und exponieren diese,
oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen.
Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen,
erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen. Einschränkung der übergreifenden MS-Definition:
Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur
zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden.
Das System MUSS jedoch clinicalStatus
befüllen, sofern die entsprechende Information verfügbar ist. Hinweis:
Für Diagnosen aus der ambulanten
Versorgung können die Werte für clinicalStatus
und verificationStatus
aus dem
ICD-10-Zusatzkennzeichen für die Diagnosesicherheit
abgeleitet werden.
Das entsprechende Mapping kann den Deutschen Basisprofilen
entnommen werden.
Im Kontext des Allingments mit dem EHDS und den damit verbundenen Spezifikationen von HL7 Europe wurde diese Extenion hinzugefügt. Es besteht aber noch keine Must-Support Anforderung, da die Abbildung der Lateralität noch in der Diskussion ist und somit keine klare Vorgabe für die Nutzung der Extension gegeben werden kann. Sobald dies geklärt ist, wird die Anforderung entsprechend angepasst. Eine referenzierte BodyStructure-Ressource sollte valide gegen bodyStructure-eu-core
sein.
Begründung MS:
Auch in Stufe 4 sind keine (client-seitigen) schreibenden Operationen für das Erstellen einer Condition-Ressource vorgesehen
(siehe CapabilityStatement). Das heißt, entweder führen KISe entsprechende Informationen und exponieren diese,
oder es gibt keinen pragmatischen Mechanismus (im ISIK-Kontext), um den Use Case einer zusätzlichen Annotation mittels Client zu erfüllen.
Da alle KIS-Hersteller, die sich zu Wort gemeldet haben, eine Befüllung von Condition.clinicalStatus NICHT unterstützen,
erscheint das MS nach übergreifender Definition und ein verpflichtender Testfall nicht angemessen. Einschränkung der übergreifenden MS-Definition:
Verfügt ein bestätigungsrelevantes System nicht über die Datenstruktur
zur Hinterlegung des Status einer Diagnose, so MUSS dieses System die Information NICHT abbilden.
Das System MUSS jedoch clinicalStatus
befüllen, sofern die entsprechende Information verfügbar ist. Hinweis:
Für Diagnosen aus der ambulanten
Versorgung können die Werte für clinicalStatus
und verificationStatus
aus dem
ICD-10-Zusatzkennzeichen für die Diagnosesicherheit
abgeleitet werden.
Das entsprechende Mapping kann den Deutschen Basisprofilen
entnommen werden.
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.
Simple Extension with the type Reference: 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.
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
.
Dieses und untergeordnete Elemente KÖNNEN bei einem erfolgten Patient merge entsprechend der Festlegungen unter Patient-merge
befüllt werden.
Da das Element der Unterstützung der Patient merge Notification dient,
MUSS es im Rahmen des Bestätigungsverfahrens NICHT unterstützt werden (Stand: Stufe 4).
Profil EPAPatient der gematik
: In ISiK ist die Angabe einer KVNR nicht verpflichtend, da in vielen Use Cases bereits eine PID ausreichend ist. Außerdem ist in ISiK keine verpflichtende Versionierung über meta.versionId vorgesehen.
Dieses und untergeordnete Elemente KÖNNEN bei einem erfolgten Patient merge entsprechend der Festlegungen unter Patient-merge
befüllt werden.
Da das Element der Unterstützung der Patient merge Notification dient,
MUSS es im Rahmen des Bestätigungsverfahrens NICHT unterstützt werden (Stand: Stufe 4).
Im Krankenhaus ist die lebenslange Arztnummer der Ärzte bekannt und MUSS zur eindeutigen Identifikation eines Arztes bereitgestellt werden.
Hinweise:
Siehe Beschreibung der Deutschen Basisprofile
Während die Deutschen Basisprofile hier die Abkürzung LANR verwenden, ist im KBV-Kontext das Akronym ANR gebräuchlich. Die Bezeichnung des Slices hat jedoch keinerlei Auswirkungen auf die Kompatibilität.
Die Kategorisierung erfolgt vorzugsweise auf Basis von SNOMED CT. Für OPS-codierte Prozeduren MUSS die Kategorie angegeben werden: Sie kann ermittelt werden,
indem das erste Zeichen des OPS-Codes mit Hilfe einer ConceptMap
auf die zutreffende SNOMED-Kategorie gemappt wird.
Begründung Pflichtfeld:
Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.
Im ISik Kontext MUSS die referenzierte Ressource konform zu ISiKKontaktGesundheitseinrichtung
sein.
Jenseits von ISiK KÖNNEN weitere Instanzen mit anderen Profilen referenziert werden.
Die Kategorisierung erfolgt vorzugsweise auf Basis von SNOMED CT. Für OPS-codierte Prozeduren MUSS die Kategorie angegeben werden: Sie kann ermittelt werden,
indem das erste Zeichen des OPS-Codes mit Hilfe einer ConceptMap
auf die zutreffende SNOMED-Kategorie gemappt wird.
Für das Profil ISiKStandort wurde bis zum Zeitpunkt der Veröffentlichung kein Abgleich der
Kompatibilität zu anderen Profilen (der KBV und der Medizininformatik-Initiative) durchgeführt.
Hinweise zu Inkompatibilitäten können über die Portalseite
gemeldet werden.
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.
Das Profil ISiKVersicherungsverhaeltnisGesetzlich basiert auf dem GKV-Profil der deutschen Basisprofile
.
Instanzen, die gegen ISiKVersicherungsverhaeltnisGesetzlich valide sind, sind auch valide gegen
Das Profil ISiKVersicherungsverhaeltnisSelbstzahler basiert auf dem Selbstzahler-Profil der deutschen Basisprofile
.
Instanzen, die gegen ISiKVersicherungsverhaeltnisSelbstzahler valide sind, sind auch valide gegen
Softwareherstellern steht es frei, über die hier spezifizierten Profiltypen hinaus weitere FHIR-Profile zu nutzen, zu implementieren oder zu spezifizieren und über eine API bereitzustellen. Wir bitten in solchen Fällen jedoch um eine Meldung entsprechender Bedarfe über das ISiK Anfrageportal
, damit wir über mögliche Leerstellen der ISiK-Spezifikation in grundlegenden API-Funktionalitäten zur Abdeckung spezifischer Workflows informiert werden.
Die Antwortzeit bezeichnet dabei einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier
definiert. Dabei wird hier zusätzlich eine Antwortzeit ohne signifikante Lasteinwirkung angenommen.
Die Antwortzeit dabei bezeichnet einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier
definiert.
Die Antwortzeit bezeichnet einen Request/Reply-Zyklus zwischen einem Client und einem Server, der die Zeitspanne von der Absendung einer Anfrage durch den Client bis zum vollständigen Empfang der Antwort durch den Client in der Test-Umgebung umfasst /und deckt sich damit weitgehend mit dem Konzept der Bearbeitungszeit wie hier
definiert.
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.
Die gematik wurde vom Gesetzgeber beauftragt, im Benehmen mit der Deutschen Krankenhausgesellschaft (DKG) und den maßgeblichen Bundesverbänden der Industrie im Gesundheitswesen, verbindliche Standards für den Austausch von Gesundheitsdaten mit Informationssystemen im Krankenhaus zu erarbeiten. Dieser FHIR ImplementationGuide (IG) beschreibt die für diesen Zweck entwickelten FHIR Profile und das REST
-basierte Application Programming Interface (API). Die REST-API wird im Wesentlichen vom FHIR Standard vorgegeben
. Dieser Leitfaden konkretisiert die ISiK-relevanten Funktionen der Standard-REST-API und trifft inhaltliche Festlegungen zu den ISiK-relevanten Ressourcen in Form von Ressourcen-Profilen.
Hinweis: Sowohl für die Implementierung der ISiK-Spezifikation als auch für den Betrieb eines Produktes, das die ISiK-Spezifikation implementiert, ist eine SNOMED-CT-Lizenz notwendig. Diese kann beim National Release Center für SNOMED CT in Deutschland
beantragt werden.
