Wissen

FHIR R4 und ISiK
in der Onkologie.

Was ISiK-Konformität für die Anbindung einer ePRO-Anwendung an das Krankenhausinformationssystem (KIS) bedeutet, welche FHIR-Ressourcen dabei zum Einsatz kommen, welche Module seit wann verbindlich sind und welche Fragen eine Klinik ihrem KIS-Hersteller vor der Beschaffung stellen sollte.

Fachliche Information für Klinik-IT, Behandlungsteams und Versorgungsforschung. Angaben zu Spezifikationen und Fristen geben den Stand vom 22.09.2026 wieder; maßgeblich sind die jeweils aktuellen Veröffentlichungen der gematik. Dieser Beitrag ist keine Rechtsberatung.

Das Wichtigste in Kürze

FHIR R4 (Fast Healthcare Interoperability Resources, Release 4) ist das Austauschformat, ISiK (Informationstechnische Systeme in Krankenhäusern) ist die deutsche Festlegung, welchen Teil davon die informationstechnischen Systeme eines Krankenhauses verbindlich beherrschen müssen. Rechtsgrundlage ist § 371 Abs. 1 SGB V für die Pflicht, offene und standardisierte Schnittstellen in diese Systeme zu integrieren, und § 373 SGB V für den Auftrag, diese Schnittstellen für Krankenhäuser zu spezifizieren.1

Die ISiK-Spezifikationen sind stufenweise aufgebaut. Stufe 3 ist seit dem 01.07.2025 verbindlich, Stufe 5 wurde zum 01.07.2025 veröffentlicht, ihre verbindliche Festlegung läuft.2

Für eine Anwendung, die patientenberichtete Angaben elektronisch erfasst (ePRO, electronic Patient-Reported Outcomes: Angaben von Patientinnen und Patienten zu Beschwerden und Befinden), ist die praktisch wichtigste Erkenntnis, dass ISiK primär den lesenden Zugriff auf Stammdaten, Fälle, Diagnosen, Medikation und Termine standardisiert. Gemeint ist, wie eine Anwendung diese Daten aus dem KIS abruft. Das Zurückschreiben strukturierter Fragebogenergebnisse in das KIS, also als einzelne, auswertbare Werte statt nur als Dokument, ist über das Formular-Modul und den internationalen Standard SDC (Structured Data Capture) beschrieben,3 4 dieses Modul ist in Stufe 5 aber nicht bestätigungsrelevant, das heißt, Hersteller müssen es für die ISiK-Bestätigung nicht umsetzen.5 Es kann also nicht vorausgesetzt werden, dass ein ISiK-bestätigtes KIS es unterstützt. Das sollte die Klinik beim Hersteller gezielt erfragen.

Warum die Schnittstelle über Erfolg oder Misserfolg entscheidet

Ein Ländervergleich der Bertelsmann Stiftung zur Nutzung patientenberichteter Daten in der onkologischen Routineversorgung benennt in seinen Schlussfolgerungen für Deutschland aus Sicht der befragten Fachleute als zentrale Herausforderung, diese Daten in den Klinikalltag zu integrieren: technisch, in bestehende IT-Infrastrukturen, und organisatorisch, weil die Erhebung zusätzlichen Arbeitsaufwand bedeutet und die Leistungserbringer vom Nutzen überzeugt sein müssen.6

Der Grund ist banal und hartnäckig zugleich. Eine Anwendung, die ihre Daten nur in einer eigenen Oberfläche vorhält, erzeugt ein zweites Dokumentationssilo. Das Behandlungsteam muss sich zusätzlich anmelden, Werte manuell übertragen und bei jeder Rückfrage zwischen zwei Systemen wechseln. Was als Entlastung eingeführt wurde, wird so zu Mehrarbeit. Umgekehrt wird eine Anbindung, die für jede Klinik neu programmiert werden muss, schnell teuer. Genau diese Lücke soll ISiK schließen.

FHIR in fünf Begriffen

FHIR ist ein Standard von HL7 International (Health Level Seven) für den Austausch von Gesundheitsdaten. R4 wurde Ende 2018 veröffentlicht, maßgeblich ist die technisch korrigierte Fassung 4.0.1 vom Oktober 2019.7 Die ISiK-Module bauen auf FHIR R4 auf.8 Fünf Begriffe genügen, um Ausschreibungsunterlagen und Herstellerangaben zu lesen.

Ressource: Der kleinste austauschbare Baustein, etwa Patient, Condition (Diagnose) oder Observation (Beobachtung, Messwert). Jede Ressource hat eine feste Struktur und eine eigene Adresse.
Profil: Eine nationale oder projektbezogene Einschränkung einer Ressource: welche Felder Pflicht sind, welche Kodierungen zulässig sind. Ohne Profile wäre FHIR zu offen, um Interoperabilität zu erzwingen.
Implementation Guide (IG): Das Dokument, das eine Menge von Profilen, Beispielen und Regeln zu einem Anwendungsfall zusammenfasst. Die ISiK-Spezifikationen sind genau solche IGs.5
REST-API: Der Zugriffsweg über gewöhnliche Web-Anfragen: Ressourcen werden über URLs gelesen, gesucht und geschrieben. Die REST-API wird im Wesentlichen vom FHIR-Standard selbst vorgegeben,5 ISiK legt unter anderem fest, welche Suchkriterien ein Server unterstützen muss.8
Terminologie: Die kodierten Wertelisten, mit denen Inhalte eindeutig werden, vor allem SNOMED CT und LOINC. Für die Implementierung der ISiK-Spezifikation und für den Betrieb eines Produkts, das sie umsetzt, ist laut gematik eine SNOMED-CT-Lizenz notwendig.9 In Deutschland ist das eine Affiliate-Lizenz, die über das Portal MLDS (Member Licensing and Distribution Service) von SNOMED International beantragt wird. Sie ist kostenfrei, gilt nur für die Nutzung in Deutschland und verlangt eine jährliche Nutzungserklärung; zuständig ist das National Release Center beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM).10

Die Ressourcen, die für ePRO in der Onkologie zählen

Eine ePRO-Anwendung braucht nicht den gesamten Standard, sondern einen überschaubaren Ausschnitt. Die folgende Übersicht ordnet die Ressourcen der Aufgabe zu, die sie in der ambulanten Tumortherapie erfüllen.

FHIR-Ressourcen und ihre Bedeutung für eine ePRO-Anwendung
FHIR-Ressource	Wofür sie steht	Bedeutung für eine ePRO-Anwendung
Patient	Stammdaten und Identifikatoren der Person.	Grundlage jeder Zuordnung. Ohne eindeutigen Bezug zur Fallnummer oder Patienten-ID entsteht keine verlässliche Verknüpfung mit der Akte.
Encounter	Der Kontakt oder Fall, ambulant oder stationär.	Verknüpft eine Symptomerhebung mit dem Behandlungszusammenhang, in dem sie stattgefunden hat.
Condition	Diagnosen, kodiert nach ICD-10-GM.	Erlaubt, Symptomsets am Krankheitsbild auszurichten, statt allen dieselben Fragen zu stellen.
MedicationRequest / MedicationAdministration / MedicationStatement	Verordnung, Verabreichung und bekannte Medikation.	Voraussetzung für einen Medikationsplan mit Zykluslogik und für Symptomsets, die zum Toxizitätsprofil des Regimes passen. Besonders relevant bei oraler Tumortherapie.
Questionnaire	Die Definition eines Fragebogens: Fragen, Antworttypen, Verzweigungen.	Macht ein Symptomset maschinenlesbar, statt es in jedem System neu nachzubauen.
QuestionnaireResponse	Die ausgefüllte Antwort einer Person auf einen Questionnaire.	Das eigentliche Ergebnis der Erhebung, in strukturierter Form. Ziel jeder Rückschreibung ins KIS.
Observation	Eine einzelne Beobachtung oder ein Messwert mit Zeitpunkt und Kodierung.	Wandelt einzelne Fragebogenwerte in auswertbare Verlaufsgrößen um, etwa den Schweregrad eines Symptoms über die Zeit.
Appointment	Termine.	Ermöglicht, Befragungen an den Therapierhythmus zu koppeln, etwa drei Tage nach Applikation oder zwei Tage vor dem nächsten Termin.
DocumentReference	Verweis auf ein Dokument, etwa einen Bericht als PDF.	Der pragmatische Weg, eine Verlaufsübersicht in die Akte zu bringen, wenn strukturiertes Zurückschreiben nicht möglich ist.
Consent	Einwilligung.	Relevant, wo Einwilligungen digital abgebildet und im Verbund nachvollziehbar sein müssen.
Subscription	Benachrichtigung bei Datenänderungen.	Erlaubt ereignisgesteuertes Arbeiten statt regelmäßigem Abfragen. Im ISiK-Kontext als eigenes, nicht bestätigungsrelevantes Modul beschrieben.5

ISiK: was es ist und was es verbindlich macht

ISiK steht für Informationstechnische Systeme in Krankenhäusern.11 Das bei der gematik eingerichtete Kompetenzzentrum für Interoperabilität im Gesundheitswesen hat vom Gesetzgeber den Auftrag, die Spezifikationen der offenen und standardisierten Schnittstellen für die informationstechnischen Systeme zugelassener Krankenhäuser zu erstellen.1 Die rechtlichen Grundlagen bauen aufeinander auf:

§ 371 Abs. 1 SGB V schreibt vor, dass in informationstechnische Systeme der vertragsärztlichen und vertragszahnärztlichen Versorgung sowie in Krankenhäusern, die zur Verarbeitung personenbezogener Patientendaten eingesetzt werden, offene und standardisierte Schnittstellen integriert werden. Nach § 371 Abs. 3 SGB V muss das binnen der Frist aus der Rechtsverordnung nach § 385 SGB V geschehen, nachdem die Spezifikationen erstellt und verbindlich festgelegt sind.1
§ 373 SGB V beauftragt das Kompetenzzentrum für Interoperabilität im Gesundheitswesen, diese Schnittstellen für die in zugelassenen Krankenhäusern eingesetzten Systeme zu spezifizieren. Das Ergebnis sind die ISiK-Implementierungsleitfäden. Welche Subsysteme eines Krankenhauses die Schnittstellen integrieren müssen, definiert nach § 373 Abs. 2 SGB V die Deutsche Krankenhausgesellschaft im Einvernehmen mit dem Kompetenzzentrum. Für die vertragsärztliche und vertragszahnärztliche Versorgung legen nach § 372 SGB V die Kassenärztlichen Bundesvereinigungen die Spezifikationen fest.1
§ 385 SGB V ist die Grundlage dafür, dass das Bundesministerium für Gesundheit (BMG) die Spezifikationen in der Anlage zu einer Rechtsverordnung verbindlich festlegt, der Gesundheits-IT-Interoperabilitäts-Governance-Verordnung (GIGV).1 5
§§ 387 und 388 SGB V regeln die Konformitätsbewertung durch das Kompetenzzentrum oder akkreditierte Stellen und knüpfen das Inverkehrbringen von Systemen, für die verbindliche Festlegungen gelten, an ein entsprechendes Zertifikat.1 Nach der IOP-Anforderung der gematik zu Stufe 5 (IOP steht für Interoperabilität) mündet das ISiK-Bestätigungsverfahren ab Stufe 5 in das Konformitätsbewertungsverfahren nach § 387 SGB V, und zwar durch die Aufnahme der IOP-Anforderungen in die Anlage 1 der GIGV.5 Nach § 373 Abs. 5 SGB V ist der Einsatz von Systemen, die ein solches Konformitätsbewertungsverfahren erfolgreich durchlaufen haben, für zugelassene Krankenhäuser verpflichtend.1

Bis dahin weisen Hersteller die Umsetzung im gebührenpflichtigen Bestätigungsverfahren der gematik nach, das nach deren Angaben gemäß § 373 SGB V für Softwareprodukte verpflichtend ist, die in Krankenhäusern eingesetzt werden.12

Einfach erklärt: Das Gesetz schreibt vor, dass in die Software von Krankenhäusern einheitliche, offene Schnittstellen eingebaut werden, damit Systeme verschiedener Hersteller Daten austauschen können (§ 371 SGB V). Wie diese Schnittstellen aussehen müssen, beschreibt die gematik in den ISiK-Leitfäden (§ 373 SGB V). Das Bundesministerium für Gesundheit macht diese Beschreibungen per Rechtsverordnung verbindlich (§ 385 SGB V). Danach wird geprüft, ob ein System die Vorgaben erfüllt, und Krankenhäuser müssen geprüfte Systeme einsetzen (§§ 387, 388 und § 373 Abs. 5 SGB V). Bis es so weit ist, weisen Hersteller die Umsetzung im Bestätigungsverfahren der gematik nach.

Wichtig für die Lektüre von Herstellerangaben: ISiK richtet sich an die Hersteller von Krankenhausinformationssystemen und Subsystemen, welche die Schnittstelle nach § 371 SGB V umsetzen.5 Nach der Definition der gematik sind bestätigungsrelevante Systeme stets Softwaresysteme, die versorgungsrelevante Daten verarbeiten oder dauerhaft speichern; umgekehrt ist nicht jedes solche System bestätigungsrelevant. Welche Systeme es im Einzelnen sind, legt die gematik je Modul und Akteur fest. Bestätigungsrelevant sind vor allem Server-Rollen, etwa ein System, das als primärer, dauerhafter Speicherort der Daten dient; angebundene, korrespondierende Systeme werden als Clients definiert und sind nicht bestätigungsrelevant.8

Stand der Stufen

Die Spezifikationen sind stufenweise aufgebaut, in jeder Stufe kommen Module hinzu oder werden aktualisiert.5 Die folgende Übersicht gibt die Angaben des gematik-Fachportals wieder.2

Stand der ISiK-Stufen
Stufe	Status	Anmerkung
Stufe 1 und 2	abgekündigt	Stufe 1 (Basis) zum 01.07.2024, Stufe 2 überwiegend zum 01.07.2025; das Modul Dokumentenaustausch der Stufe 2 bereits zum 01.02.2023.
Stufe 3	verbindlich seit 01.07.2025	Veröffentlicht am 01.07.2023. Umfasst die Module Basis, Dokumentenaustausch, Medikation, Terminplanung sowie Vitalparameter und Körpermaße; das Modul Sicherheit ist nicht normativ festgelegt.
Stufe 4	abgekündigt	Veröffentlicht am 01.07.2024, abgekündigt zum 01.07.2025.
Stufe 5	veröffentlicht 01.07.2025, Verbindlichkeit in Festlegung	Die IOP-Anforderung liegt seit dem 06.11.2025 in der finalen Fassung 1.0.0 vor.5 Hersteller mit gültiger Stufe-3-Bestätigung erhalten eine Verlängerungsbescheinigung, sobald das Zieldatum für Stufe 5 feststeht, und müssen sich nicht erneut bestätigen lassen.2

Die Module der Stufe 5

Für Stufe 5 sind zehn Anwendungsfälle als eigene Module abgebildet. Die Unterscheidung zwischen bestätigungsrelevant und nicht bestätigungsrelevant ist für die Beschaffung die praktisch wichtigste Information, weil nur bestätigungsrelevante Systeme das Bestätigungs- beziehungsweise Konformitätsbewertungsverfahren durchlaufen.5 Die Einstufung je Modul und Akteur zeigt die folgende Tabelle.5 8

Module der ISiK-Stufe 5
Modul	Bestätigungsrelevant	Was es abdeckt
Basisprofil	ja (Basis-Server)	Grundlegende administrative und klinische Daten, darunter Patient, Encounter, Account, Condition, Procedure, AllergyIntolerance, Coverage, RelatedPerson, Practitioner, Organization und Location.9
Dokumentenaustausch	ja (Dokumenten-Server)	Entgegennahme, Speicherung und Abruf von Dokumenten.
Vitalparameter und Körpermaße	ja (Vitalparameter-Server)	Strukturierte Messwerte wie Herzfrequenz, Blutdruck, Größe und Gewicht.
Terminplanung	ja (Termin-Repository)	Verfügbare Termineinheiten und vereinbarte Termine abfragen und verwalten.
Medikation	ja (Medikations-Server für Verordnung, Information und Verabreichung; AMTS Data Provider)	Verordnung, Abgabe und Verabreichung von Medikamenten sowie Daten zur Arzneimitteltherapiesicherheit (AMTS), etwa Schwangerschafts-, Still- und Raucherstatus.
ICU-Normalstation	ja (ICU Source Minimal und Extended)	Austausch intensivmedizinisch relevanter Vitalparameter zwischen Normal- und Intensivstation.
Connect	ja (Ressourcen-Server)	Einbettung externer Anwendungen über SMART on FHIR. Autorisierungs-Server, App Launcher und SMART App sind dabei selbst nicht bestätigungsrelevant.
Formular	nein (in Stufe 5 informativ)	Standardisierter Austausch von Formularen und Fragebögen auf Basis des internationalen SDC-Standards, einschließlich automatischer Vorbefüllung und Extraktion von Formulardaten in FHIR-Ressourcen.3
Subscription	nein	Benachrichtigung bei Datenänderungen statt regelmäßiger Abfrage.
Labor	nein	Support-Modul: stellt Profile bereit, die im Kontext anderer Module bestätigungsrelevant sein können, ist als Modul selbst aber nicht bestätigungsrelevant.

Was das konkret heißt. Eine Klinik kann von einem ISiK-bestätigten KIS erwarten, dass sich die Daten der Module, für die eine Bestätigung vorliegt, standardisiert lesen lassen, etwa Stammdaten, Fälle und Diagnosen über das Basismodul. Sie kann daraus nicht ableiten, dass sich ein ausgefüllter Symptomfragebogen strukturiert zurückschreiben lässt. Diese Frage gehört ausdrücklich in die Ausschreibung.

Was ISiK für eine ePRO-Anwendung praktisch bedeutet

Die ePRO-Anwendung ist in der Regel Client, nicht Server

In der ISiK-Systematik ist das KIS in der Regel der Server, der Ressourcen bereitstellt, und die angebundene Anwendung der Client, der sie abruft. Für Clients bestehen in den ISiK-Modulen überwiegend keine gesonderten Anforderungen, und sie sind nicht bestätigungsrelevant.8 Anders kann es sein, wenn eine Anwendung selbst der primäre, dauerhafte Speicherort für Termine oder Medikationsdaten ist. Die gematik nennt als mögliche Termin-Repositories auch Patientenportale, sofern sie selbst terminführend sind, und als mögliche Medikations-Server unter anderem Software für digitales Medikationsmanagement und E-Therapieplan-Systeme für die Zytostatika-Behandlung.8 Eine pauschale Aussage wie „unsere Anwendung ist ISiK-zertifiziert“ ist deshalb missverständlich: Bestätigt werden Systeme je Modul in den festgelegten Server-Rollen, in der Regel die Primärsysteme. Für eine Anwendung in der Client-Rolle ist die Aussage sinnvoll formuliert, dass sie die ISiK-Schnittstelle eines KIS nutzt und die dort definierten Profile verarbeitet.

Lesen ist der gelöste Teil

Für die Einrichtung einer ePRO-Begleitung ist der lesende Zugriff der wichtigere. Er beantwortet die Fragen, wer überhaupt in Behandlung ist, unter welchem Regime, mit welcher Diagnose und wann der nächste Termin ansteht. Genau dieser Teil ist über Basisprofil, Medikation und Terminplanung standardisiert, und diese Module sind bestätigungsrelevant. Welche davon ein bestimmtes KIS bereitstellt, zeigt seine Bestätigung je Modul.

Zurückschreiben ist der offene Teil

Für das Ergebnis der Befragung gibt es drei Wege, in absteigender Güte:

Strukturiert über QuestionnaireResponse und Observation. Die Werte stehen als auswertbare Größen in der Akte und lassen sich im Verlauf darstellen. Das ist der angestrebte Zustand, setzt aber voraus, dass das KIS das Formular-Modul oder einen vergleichbaren Schreibzugriff unterstützt, was wegen fehlender Bestätigungsrelevanz nicht vorausgesetzt werden kann.
Als Dokument über DocumentReference. Eine Verlaufsübersicht wird als Bericht in die Akte eingestellt. Für die Dokumentationspflicht ausreichend, für die maschinelle Auswertung nicht.
Über die klassische HL7-v2-Schnittstelle (Health Level Seven, Version 2). In vielen Häusern der praktikable Weg, weil die Strecke bereits steht und betrieben wird. Fachlich älter, im Betrieb aber häufig der schnellste Start.

Naheliegend ist eine Kombination: Lesen über FHIR, Zurückschreiben zunächst als Dokument oder über HL7 v2, strukturiertes Zurückschreiben, sobald das Haus es unterstützt.

Einbettung in die Oberfläche

Damit das Behandlungsteam nicht zwischen Systemen wechselt, ist die Einbettung in das KIS entscheidend. Das ISiK-Modul Connect beschreibt dafür SMART on FHIR, also den Start einer externen Anwendung aus dem KIS heraus, mit Übergabe des Patienten- oder Fallkontextes und einer Autorisierung über Sicherheits-Token eines Autorisierungs-Servers. Der Ressourcen-Server ist dabei bestätigungsrelevant, die übrigen Akteure nicht.8

Was ISiK nicht löst

Vier Bereiche werden regelmäßig mit ISiK verwechselt und sind davon getrennt zu betrachten.

Tumordokumentation und Krebsregistermeldung. Die Meldung an die klinischen Krebsregister erfolgt über den bundeseinheitlichen onkologischen Basisdatensatz (oBDS) nach § 65c SGB V. Festgelegt und gepflegt wird er von der Arbeitsgemeinschaft Deutscher Tumorzentren (ADT) und den Deutschen Krebsregistern (DKR), in denen die Gesellschaft der epidemiologischen Krebsregister in Deutschland (GEKID) aufgegangen ist, gemeinsam mit der Plattform § 65c; technisch dient eine bundesweit einheitliche XML-Schnittstelle. Deren Version 3.0.5 wurde am 24.10.2025 veröffentlicht, die Landeskrebsregister planten, sie ab dem 01.03.2026 anzunehmen.13 Das ist ein eigener Weg, nicht Teil von ISiK.
Forschungsdatennutzung. Für die Übernahme onkologischer Behandlungsdaten in die Datenintegrationszentren der Medizininformatik-Initiative (MII) existiert das Kerndatensatz-Modul Onkologie, das auf dem oBDS aufsetzt und als FHIR-Implementierungsleitfaden spezifiziert ist.14 Es adressiert die Sekundärnutzung, nicht die Versorgungsschnittstelle.
Onkologische Fachlogik. ISiK standardisiert den Transport, nicht die Bedeutung. Zykluslogik, Dosisreduktionen, Toxizitätsgrade und Therapielinien sind in den ISiK-Profilen nicht fachspezifisch abgebildet und müssen in der jeweiligen Anwendung modelliert werden.
Terminologiepflege. SNOMED CT und LOINC lösen die Eindeutigkeit, verlangen aber eine Lizenz (bei SNOMED CT), Versionspflege und eine Zuordnung der hauseigenen Kataloge. Dieser Aufwand fällt unabhängig von der Schnittstelle an.

Datenschutz und Betrieb

Patientenberichtete Daten sind Gesundheitsdaten nach Artikel 9 der Datenschutz-Grundverordnung. In der üblichen Konstellation ist die Klinik Verantwortliche und der Anbieter Auftragsverarbeiter nach Artikel 28. Das setzt einen Vertrag zur Auftragsverarbeitung, ein technisches und organisatorisches Sicherheitskonzept und geklärte Löschfristen voraus. Ein Informationssicherheits-Managementsystem nach ISO/IEC 27001 und eine Prüfung nach dem Kriterienkatalog C5 (Cloud Computing Compliance Criteria Catalogue) des Bundesamts für Sicherheit in der Informationstechnik (BSI) werden in Klinikausschreibungen häufig verlangt.

Technisch kommen zwei Punkte hinzu, die in Datenschutzkonzepten oft zu spät auftauchen: die Frage, welche Daten die angebundene Anwendung tatsächlich abrufen darf (Umfang der Autorisierung, nicht nur deren Vorhandensein), und die Frage, wo die Verarbeitung stattfindet, wenn Teile der Strecke über Dienstleister laufen.

Was Kliniken ihren KIS-Hersteller fragen sollten

Acht Fragen, die vor der Beschaffung einer ePRO-Anwendung geklärt sein sollten und die sich ohne technisches Spezialwissen stellen lassen.

Für welche ISiK-Stufe und welche Module liegt eine gültige Bestätigung vor, und bis wann gilt sie?
Ist die ISiK-Schnittstelle in unserer Installation aktiviert, oder ist sie lizenziert und erst zu aktivieren? Entstehen dafür zusätzliche Kosten?
Welche Suchparameter unterstützt der Basis-Server tatsächlich, etwa die Suche nach allen ambulanten Fällen einer Abteilung in einem Zeitraum?
Wird das Modul Medikation im vollen Umfang bereitgestellt, einschließlich Verabreichung, oder nur die Verordnung?
Unterstützt das System das Zurückschreiben von QuestionnaireResponse oder Observation? Wenn nein, über welchen Weg gelangen Ergebnisse strukturiert in die Akte?
Steht das Modul Connect für die Einbettung externer Anwendungen über SMART on FHIR zur Verfügung, und wie wird die Autorisierung betrieben?
Wie werden Aktualisierungen der Spezifikation eingespielt, in welchem Rhythmus, und mit welcher Vorlaufzeit für angebundene Systeme?
Welche Testumgebung steht für die Anbindung bereit, und mit welchen Daten?

OnkoPass im Überblick

OnkoPass ist eine digitale Begleitung für die ambulante Tumortherapie, die Kliniken für ihre Patientinnen und Patienten lizenzieren. Die Anbindung an bestehende Krankenhausinformationssysteme erfolgt über FHIR R4 und HL7 v2. Symptomabfragen werden strukturiert zwischen den ambulanten Terminen ausgespielt und im Klinik-Portal zusammengeführt, auffällige Verläufe werden hervorgehoben. Für die orale Tumortherapie kommen ein Medikationsplan mit Zykluslogik sowie Erinnerungen an Termine und offene Aufgaben hinzu.

Die Bewertung klinischer Angaben verbleibt beim Behandlungsteam. OnkoPass ist kein Medizinprodukt im Sinne der EU-Verordnung 2017/745 (MDR) und trifft keine medizinischen Entscheidungen. Mehr dazu auf den Seiten Für Behandlungsteams und Datenschutz und Sicherheit.

Häufige Fragen

Was ist der Unterschied zwischen FHIR und ISiK?

FHIR ist der internationale Standard von HL7 für den Austausch von Gesundheitsdaten. ISiK ist die deutsche Festlegung, welcher Ausschnitt davon in den informationstechnischen Systemen eines Krankenhauses verbindlich vorhanden sein muss, und in welcher Ausprägung. ISiK besteht technisch aus FHIR-Implementation-Guides.

Kann eine ePRO-Anwendung ISiK-zertifiziert sein?

In der Regel nicht im Sinne des Bestätigungsverfahrens. Bestätigt werden Systeme, die in einem Modul eine festgelegte Server-Rolle übernehmen, meist die Primärsysteme und bestimmte Subsysteme. Eine angebundene Anwendung tritt in der ISiK-Systematik in der Regel als Client auf, für den keine bestätigungsrelevanten Anforderungen bestehen. Anders kann es sein, wenn die Anwendung selbst der primäre, dauerhafte Speicherort etwa für Termine oder Medikationsdaten ist; dann ist im Einzelfall zu prüfen, ob sie eine bestätigungsrelevante Server-Rolle einnimmt.8 Für eine Anwendung in der Client-Rolle lautet die zutreffende Aussage, dass sie die ISiK-Schnittstelle nutzt und die dort definierten Profile verarbeitet.

Was bedeutet „bestätigungsrelevant“ im ISiK-Kontext?

Bestätigungsrelevant sind Systeme, die für ein Modul die dort festgelegte Server-Rolle übernehmen, in der Regel die Primärsysteme, etwa als Basis-Server, Medikations-Server oder Termin-Repository. Für sie ist die Konformitätsbewertung beziehungsweise das Bestätigungsverfahren verpflichtend. Angebundene Client-Systeme sind davon in der Regel ausgenommen.8

Reicht ISiK aus, um Fragebogenergebnisse ins KIS zu schreiben?

Nicht automatisch. Der Austausch von Formularen und Fragebögen ist im ISiK-Modul Formular auf Basis des SDC-Standards beschrieben, dieses Modul ist in Stufe 5 aber nicht bestätigungsrelevant. Ob ein bestimmtes KIS es unterstützt, muss beim Hersteller erfragt werden.

Brauchen wir HL7 v2 noch?

In den meisten Häusern ja. Etablierte Schnittstellen zu Labor- und Subsystemen laufen darüber und werden auf absehbare Zeit weiterbestehen. Für den Start einer Anbindung ist HL7 v2 häufig der schnellere Weg, weil die Strecke bereits betrieben wird.

Ist ISiK für alle Krankenhäuser verpflichtend?

§ 371 Abs. 1 SGB V verlangt, dass offene und standardisierte Schnittstellen in die informationstechnischen Systeme von Krankenhäusern sowie der vertragsärztlichen und vertragszahnärztlichen Versorgung integriert werden.1 Umgesetzt wird das von den Herstellern der Systeme, für Krankenhäuser ist es durch ISiK spezifiziert. Nach § 373 Abs. 5 SGB V ist der Einsatz von Systemen, die eine Konformitätsbewertung nach § 387 SGB V erfolgreich durchlaufen haben, für zugelassene Krankenhäuser verpflichtend. In Praxen und MVZ gilt ISiK nicht, dort gelten die Festlegungen der Kassenärztlichen Bundesvereinigungen nach § 372 SGB V.1 Eine ISiK-Bestätigung kann außerdem bei der Vorabprüfung von Förderkriterien nach der Fördermittelrichtlinie gemäß § 21 Abs. 2 der Krankenhausstrukturfonds-Verordnung (KHSFV) unterstützen.2

Was hat ISiK mit der Krebsregistermeldung zu tun?

Nichts unmittelbar. Die Meldung an die klinischen Krebsregister läuft über den onkologischen Basisdatensatz nach § 65c SGB V und dessen XML-Schnittstelle. ISiK regelt die Schnittstellen der informationstechnischen Systeme im Krankenhaus, nicht die Meldung an Register.

Quellen

Sozialgesetzbuch Fünftes Buch (SGB V), §§ 371, 372, 373, 385, 387 und 388. gesetze-im-internet.de/sgb_5 (abgerufen am 22.09.2026) ↩
gematik. Fachportal, Informationen zu ISiK (Stufenübersicht, abgekündigte Module, aktuelle Hinweise). fachportal.gematik.de/informationen-fuer/isik (abgerufen am 22.09.2026) ↩
gematik. Implementierungsleitfaden ISiK-Formular-Modul, Stufe 5 (Version 5.0.0). simplifier.net/guide/isik-formular-stufe-5 ↩
HL7 International. Structured Data Capture (SDC) Implementation Guide. hl7.org/fhir/uv/sdc ↩
gematik, Kompetenzzentrum für Interoperabilität im Gesundheitswesen. IOP-Anforderungen gemäß § 385 SGB V im Rahmen der Schnittstellen für informationstechnische Systeme in Krankenhäusern (ISiK Stufe 5). Version 1.0.0, Stand 06.11.2025. ina.gematik.de ↩
Amelung V, Arnold M, Altendorf M, Borgmann LS. Patient-Reported Outcomes (PROs) in der Routineversorgung bei Krebserkrankungen: Anwendungsbeispiele aus ausgewählten Ländern. Gütersloh: Bertelsmann Stiftung; 2024. doi:doi:10.11586/2024019 ↩
HL7 International. FHIR Release 4 (R4), Version 4.0.1, und Versionshistorie. hl7.org/fhir/R4 und hl7.org/fhir/R4/history.html (abgerufen am 22.09.2026) ↩
gematik. Bestätigungsrelevante Systeme, ISiK Stufe 5. Dateistand 13.06.2025. github.com/gematik/spec-ISiK-Basismodul (Material/Basis), verlinkt vom gematik-Fachportal ↩
gematik. Implementierungsleitfaden ISiK-Basismodul, Stufe 5 (Version 5.0.0). simplifier.net/guide/isik-basis-stufe-5 ↩
Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM). Eine SNOMED-CT-Lizenz beantragen und MLDS nutzen. bfarm.de/DE/Kodiersysteme/Terminologien/SNOMED-CT/Lizenz (abgerufen am 22.09.2026) ↩
gematik. ISiK. gematik.de/anwendungen/isik (abgerufen am 22.09.2026) ↩
gematik. Bestätigungsverfahren ISiK. fachportal.gematik.de/zielgruppen/primaersystemhersteller/isik/bestaetigungsverfahren-isik (abgerufen am 22.09.2026) ↩
Arbeitsgemeinschaft Deutscher Tumorzentren (ADT), Deutsche Krebsregister (DKR), Plattform § 65c. Bundeseinheitlicher onkologischer Basisdatensatz (Startseite) sowie XML-Schnittstelle zum einheitlichen onkologischen Basisdatensatz, Version 3.0.5 vom 24.10.2025. basisdatensatz.de und basisdatensatz.de/xml (abgerufen am 23.09.2026) ↩
Medizininformatik-Initiative. Meldung „MII-Kerndatensatzmodule Onkologie und Befunde bildgebender Verfahren veröffentlicht“ (17.01.2025) sowie Implementierungsleitfaden Kerndatensatz-Modul Onkologie, Version 2026.0.0 (19.12.2025). medizininformatik-initiative.de ↩
Angaben zu ISiK-Stufen, Modulen und Bestätigungsrelevanz wurden am 22.09.2026 gegen die Veröffentlichungen der gematik geprüft, insbesondere gegen das gematik-Fachportal, das Dokument „IOP-Anforderungen gemäß § 385 SGB V im Rahmen der Schnittstellen für informationstechnische Systeme in Krankenhäusern“ in der Fassung 1.0.0 vom 06.11.2025 und das Dokument „Bestätigungsrelevante Systeme“ zu Stufe 5. Gesetzesangaben folgen dem Wortlaut auf gesetze-im-internet.de. Das Zieldatum für die Verbindlichkeit der Stufe 5 stand zu diesem Zeitpunkt noch nicht fest und ist vor Veröffentlichung erneut zu prüfen.

Zuletzt aktualisiert am 29. September 2026. Fachlich geprüft von der JustHealth GmbH, München. Weiter zu allen Beiträgen im Wissensbereich oder zum Beitrag ePRO in der Onkologie.

Anbindung an Ihr
KIS?

In einer 30-minütigen Demo zeigen wir, wie OnkoPass über FHIR R4 und HL7 v2 an bestehende Systeme andockt. Antworten auf die häufigsten Fragen finden Sie vorab.

Demo anfragen → Datenschutz und Sicherheit

FHIR R4 und ISiKin der Onkologie.