gms | German Medical Science

Im Rahmen des Krebsfrüherkennungs- und -registergesetzes (KFRG) wurden im Jahr 2013 die gesetzliche Grundlage zur Einrichtung klinischer Krebsregister sowie einheitliche Vorgaben zur Gestaltung organisierter Krebsfrüherkennungsprogramme (oKFE) geschaffen. In diesem Rahmen wurde auch die Verwendung der Krebsregisterdaten durch den Gemeinsamen Bundesausschuss (G-BA) für die Qualitätssicherung und Verbesserung der onkologischen Versorgung etabliert. Durch das KFRG wurden die §§ 25a und 65c in das Sozialgesetzbuch Fünftes Buch (SGB V) eingefügt und durch Landeskrebsregistergesetze und Landesdatenschutzgesetze föderalistisch konkretisiert. Die Aufgabe der klinischen Krebsregistrierung wurde in einigen Ländern von den etablierten epidemiologischen Krebsregistern übernommen, in anderen Ländern wurden klinische Krebsregister als eigenständige Institutionen etabliert. Die epidemiologischen Krebsregister übermitteln gemäß Bundeskrebsregisterdatengesetz (BKRG) ihre Daten zur Erstellung länderübergreifender Auswertungen und als Datengrundlage für die wissenschaftliche Forschung an das Zentrum für Krebsregisterdaten (ZfKD) am Robert Koch-Institut (RKI). Aufgrund der hohen Relevanz klinischer Tumordaten für Wissenschaft und Forschung erfolgt derzeit eine Novellierung des BKRG [1]. Die Vorgaben werden um die Möglichkeiten der Nutzung der klinischen Krebsregisterdaten durch das ZfKD ergänzt und es werden Rahmenbedingungen für die Nutzung dieser Daten durch Dritte festgelegt. Eine im Kontext dieses Forschungsprojekts relevante Ergänzung in dem Gesetzesentwurf ist die Vorgabe zur „Festlegung einer technisch, semantisch, syntaktisch und organisatorisch interoperablen Erfassung und Verarbeitung“ der Tumordaten. Zur Erhöhung der Vollständigkeit und Vollzähligkeit der Tumordaten erfolgt in regelmäßigen Intervallen ein Datenabgleich mit Gesundheitsämtern, Mortalitäts- und Melderegistern und zwischen den Krebsregistern. Die epidemiologischen und klinischen Krebsregister werten ihre Daten landesbezogen aus und stellen diese auch für Forschungsvorhaben zur Verfügung. Die Beziehung zwischen den beteiligten Institutionen ist in Abbildung 1 [Abb. 1] dargestellt.

Im Rahmen der Konzeptstudie für ein mögliches Qualitätssicherungsverfahren „Lokal begrenztes Prostatakarzinom“ [2] hat das Institut für Qualitätssicherung und Transparenz im Gesundheitswesen (IQTIG) die Notwendigkeit der Nutzung von Krebsregisterdaten für die Durchführung der verpflichtenden Qualitätssicherung des G-BA herausgestellt. Daraufhin hat der G-BA das IQTIG im Jahr 2018 beauftragt eine konkrete Projektplanung zu erarbeiten, die zur Entwicklung der technischen Rahmenbedingungen (Spezifikation) für eine Zusammenarbeit mit den klinischen Krebsregistern (KKR) notwendig ist [3]. In diesem Kontext wurde die Nutzung des internationalen Standards Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR^®) als mögliche Option mitgedacht. Hierbei wurde durch das IQTIG der mögliche Einsatz von HL7 FHIR^® Ressourcen geprüft und ein entsprechendes Informationsmodell und Datenmodell erstellt. Die Arbeit erfolgte anhand der vorläufigen medizinischen Erkenntnisse (Qualitätsaspekte), die aus der veröffentlichten Konzeptstudie „Lokal begrenztes Prostatakarzinom“ gewonnen werden konnten. Beratend unterstützt wurde die Arbeit vom Klinischen Krebsregister Niedersachsen.

Die Kommunikation zwischen den an der Krebsregistrierung beteiligten und deren Daten nutzenden Institutionen erfolgt aktuell über unterschiedliche technische Standards. Diese Standards erfüllen nicht die Anforderungen an Internationalität oder Interoperabilität, wie dies bspw. im BKRG gefordert wird. Das Ziel dieser Arbeit ist die Entwicklung eines Kommunikationsstandards basierend auf dem internationalen und interoperablen Standard HL7 FHIR^®. Im ersten Schritt soll dieser Standard für die Kommunikation zwischen dem IQTIG und den klinischen Krebsregistern zum Einsatz kommen. Im weiteren Verlauf ist eine Ausweitung der Nutzung durch andere Institutionen im Umfeld der Krebsregistrierung angestrebt.

Die Kommunikation zwischen den in Abbildung 1 [Abb. 1] skizzierten Institutionen erfolgt mittels vieler unterschiedlicher Formate. Daten für Wissenschaft und Forschung werden in der Regel je nach Anforderung als individuelle csv-Exporte bereitgestellt. Für die Übermittlung der Daten von den öffentlichen Stellen sind auch unterschiedliche Formate im Einsatz. Für eine Vereinheitlichung der Meldeamtsdaten steht XMeld als bundeseinheitliches Datenaustauschformat zur Verfügung, was nach und nach immer häufiger auch für die Übermittlung der Daten an die Krebsregister zum Einsatz kommt.

Einheitlicher geht es bei der Übermittlung der Daten von den Meldern an die Krebsregister zu. Hier kommt ein bundesweit einheitliches XML-Schema zum Einsatz, mit dem die Items des einheitlichen onkologischen Basisdatensatzes und die dazugehörigen organspezifischen Module zu den verschiedenen Meldeanlässen übermittelt werden. Das Schema wurde ursprünglich von einer gemeinsamen Arbeitsgruppe der Arbeitsgemeinschaft deutscher Tumorzentren e.V. (ADT) und der Gesellschaft der epidemiologischen Krebsregister in Deutschland e.V. (GEKID) vorgegeben. Diese haben auch den Datensatz inhaltlich maßgeblich entwickelt, weswegen man auch vom ADT-GEKID-Basisdatensatz und ADT-GEKID-XML-Schema spricht [4].

Mittlerweile wird die Weiterentwicklung des XML-Schemas vom IT-Netzwerk der Plattform § 65c vorgenommen, welches sich aus den IT-Verantwortlichen der klinischen Krebsregister zusammensetzt. Da das zugrundeliegende XML-Schema dem Nutzer aufgrund von Freitextfeldern, der Nutzung von Zeichenfolgen (Strings) ohne weitergehende Prüfung (z.B. durch reguläre Ausdrücke) und wenigen verpflichtenden Elementen hohe Freiheitsgrade ermöglicht, wurde ein Umsetzungsleitfaden vom IT-Netzwerk zusammengestellt und Interessierten, die die Schnittstelle umsetzen, auf Nachfrage zur Verfügung gestellt, um eine einheitliche Nutzung und größere Interoperabilität zu gewährleisten. Die Freiheitsgrade sind bewusst so getroffen worden, um das XML-Schema für verschiedene Use Cases einsetzen zu können. In einigen Ländern ist derzeit auch zusätzlich noch eine Meldung von Tumordaten in Papierform möglich. Dies wird jedoch aufgrund der gesetzlichen Vorgaben in Zukunft nicht mehr möglich sein.

Für den Datenaustausch unter den Krebsregistern kommt das etablierte ADT-GEKID-XML in leicht angepasster Form zum Einsatz.

Die Übermittlung von Daten der Krebsregister an das ZfKD erfolgte bei den epidemiologischen Krebsregistern bisher als csv-Export. Die dazu vom RKI und GEKID definierte Spezifikation orientierte sich an den Exporten der Internationalen Agentur für Krebsforschung (IARC).

In welchem Format und unter welchen Bedingungen die Daten von den Krebsregistern zukünftig an das ZfKD, an die Auswertungsstelle oKFE und an die Bundesauswertungsstelle (IQTIG) übermittelt werden, ist noch offen.

Die Spezifikationen des IQTIGs geben vor, welche Daten beim Leistungserbringer oder den Krankenkassen erhoben werden sollen, in welchen Datenstrukturen diese exportiert werden und wie diese von der Datenquelle über Zwischenstationen auf Landesebene und eine zentrale Vertrauensstelle an das IQTIG übermittelt werden müssen. Der zentrale Baustein der Spezifikation ist eine Microsoft Access-Datenbank, in der Datenstrukturen, Filterkriterien, medizinische Kodelisten und Plausibilitätsregeln hinterlegt sind. Ergänzt wird die Datenbank durch XML-Schemata, eine technische Dokumentation sowie ein Datenprüfprogramm. Eine Erhebung von Freitexten ist nicht vorgesehen, alle Werte werden durch spezifische Datenfelddefinitionen, reguläre Ausdrücke und feldübergreifende Plausibilitätsregeln eineindeutig erhoben und geprüft. Die Spezifikation ist ein etabliertes Instrument in der verpflichtenden Qualitätssicherung des G-BA [5], basiert jedoch auf einem proprietären und nicht interoperablen Format.

FHIR als neuer Standard für den Datenaustausch im Gesundheitswesen HL7 FHIR^® ist ein international anerkannter und offener Standard und wird bereits von der Kassenärztlichen Bundesvereinigung (KBV) in unterschiedlichen, gesetzlich verpflichtenden Schnittstellenspezifikationen wie z.B. der Archiv- und Wechselschnittstelle [4] oder der eTerminservice-Schnittstelle [5] eingesetzt. Im Bereich der Onkologie gibt es auch Bestrebungen unterschiedlicher Initiativen, die Vorgaben des ADT-GEKID-Basisdatensatzes in HL7 FHIR^® zu modellieren. Unter anderem können hier die Projekte oncology des Deutschen Konsortiums für Translationale Krebsforschung (DKTK) und der Onkologischen Spitzenzentren [6], Cancer Care Record on FHIR der Uniklinik Köln [7], Minimal Common Oncology Data Elements (mCODE) [8] und Prostate Cancer Structured Reporting Protocol [9] genannt werden. Aufgrund der Relevanz der IQTIG-Spezifikation im Rahmen der Entwicklung medizinischer Softwareprodukte wurden bereits in 2018 von Frank Oemig und Bernd Blobel erste Ansätze präsentiert, um die Vorgaben des IQTIG nach HL7 FHIR^® zu portieren [10].

In dieser Arbeit wird die grundsätzliche Eignung von HL7 FHIR^® als technischer Standard für eine Spezifikation zur Übermittlung von Tumordaten der klinischen Krebsregister an das IQTIG im Rahmen eines zukünftigen QS-Verfahrens „Lokal begrenztes Prostatakarzinom“ als Proof of Concept untersucht. Zur Gewährleistung der Interoperabilität in der technischen Umsetzung wird HL7 FHIR^® genutzt. Folgende Fragen sollen hierbei geklärt werden:

• Wie muss ein Informationsmodell zur Übermittlung von Informationen zu Patienten mit lokal begrenztem Prostatakarzinom modelliert werden, um den Anforderungen an ein zukünftiges QS-Verfahren des G-BA zu genügen?
• Ist HL7 FHIR^® als Spezifikation zur Kommunikation zwischen klinischen Krebsregistern und dem IQTIG geeignet?
• Welche Projekte zur Modellierung von Tumordaten in HL7 FHIR^® existieren bereits und können diese als Basis für diese Arbeit genutzt werden?
• Wie muss ein HL7 FHIR^®-Datenmodell auf Basis des Informationsmodells modelliert werden?

Das Ziel dieser Arbeit ist die Entwicklung eines Informationsmodells und eines daraus abgeleiteten HL7 FHIR^®-Datenmodells zur Übermittlung von Tumordaten für den Use Case der Qualitätssicherung der Behandlung von Patienten mit lokal begrenztem Prostatakarzinom.

Das methodische Vorgehen gliedert sich in die im Folgenden dargestellten Bereiche.

Im ersten Schritt wird die Konzeptstudie des IQTIG zu einem möglichen Qualitätssicherungsverfahren „Lokal begrenztes Prostatakarzinom“ [2] im Hinblick auf die medizinisch/fachlichen Anforderungen analysiert und die Informationen strukturiert aufgearbeitet, die für eine technische Umsetzung relevant sind.

Anschließend werden basierend auf den fachlichen Informationen mögliche Datenfelder des einheitlichen onkologischen Basisdatensatz sowie des organspezifischen Moduls Prostatakarzinom ermittelt, die voraussichtlich für eine spätere Berechnung von Qualitätsindikatoren benötigt werden könnten. Die semantischen Zusammenhänge der ausgewählten Datenitems werden in einem Informationsmodell modelliert (siehe Abbildung 2 [Abb. 2]).

Die weitere Modellierung erfolgt auf Meldungsebene. Die Meldung stellt die Datenübermittlung eines Leistungserbringers zu den jeweiligen Meldeanlässen (Diagnose, Therapie und Verlauf) an das klinische Krebsregister dar. In der Weiterentwicklung würden die Informationen des Best-of-Datensatzes und nicht der Einzelmeldung herangezogen werden, dies war zum Zeitpunkt der Durchführung des Projekts jedoch noch nicht bekannt.

Basierend auf dem Informationsmodell (siehe Abbildung 2 [Abb. 2]) wird ein konkretes Datenmodell in HL7 FHIR^® umgesetzt (siehe Abbildung 3 [Abb. 3]).

Die Konzeptstudie des IQTIG zu einem zukünftigen Qualitätssicherungsverfahren „Lokal begrenztes Prostatakarzinom“ [2] hat 10 patientenrelevante Qualitätsaspekte entwickelt, von denen die folgenden 5 Qualitätsaspekte unter Nutzung der Daten der klinischen Krebsregister als umsetzbar eingeschätzt wurden:

• Aufklärung zur und Durchführung der Diagnostik
• Indikationsstellung zur Therapie
• Durchführung und Ergebnisse der radikalen Prostatektomie
• Durchführung und Ergebnisse der perkutanen Strahlentherapie/Brachytherapie
• Durchführung und Ergebnisse der Aktiven Überwachung

Als Datenbasis diente der einheitliche onkologische Basisdatensatz und das organspezifische Modul Prostatakarzinom. Neben den medizinischen Angaben werden für die Verknüpfung der Daten mit anderen Datenquellen auch personenbezogene Angaben benötigt. Hierzu wird der lebenslang unveränderliche Teil der Krankenversichertennummer (eGK) des Patienten benötigt. Die eGK-Versichertennummer liegt im Element Patienten_Stammdaten vor. Zur Aggregation der Daten auf Leistungserbringerebene wird für den stationären Bereich das Institutskennzeichen des Krankenhauses (IKNR) sowie das Standortkennzeichen gemäß § 293 Absatz 6 SGB V bzw. für den ambulanten Bereich die Betriebsstättennummer des Vertragsarztes (BSNR) benötigt. Das Standortkennzeichen von Krankenhäusern wird im Rahmen der Krebsregistrierung nicht verwendet und ist in deren Daten nicht enthalten. Inwiefern das Standortkennzeichen erhalten werden kann, ist nicht Bestandteil dieser Arbeit. IKNR und BSNR liegen in den Krebsregistern vor und werden im ADT-GEKID-XML-Element Melder vorgehalten.

Basierend auf den fünf oben genannten Qualitätsaspekten werden medizinische Daten aus den Bereichen

• Diagnose
• Operation
• Strahlentherapie
• systemische Therapie
• Verlauf

herangezogen. Die einzelnen Datenfelder sind im Informationsmodell dargestellt. Das Informationsmodell wurde als UML-Klassendiagramm modelliert (siehe Abbildung 2 [Abb. 2]).

In dem Informationsmodell wurden die Informationen farblich unterschieden, um deutlich zu machen, welche Institution diese Daten verarbeiten wird. Im klinischen Krebsregister werden die Daten gemäß den Vorgaben des G-BA vor dem Versand unterschiedlich verschlüsselt, um dem Datenschutz Rechnung zu tragen. Die rot markierte Klasse enthält die Krankenversichertennummer des Patienten, die für die Zusammenführung verschiedener Daten an die Vertrauensstelle des G-BA getrennt von den anderen Daten übermittelt wird. In blau dargestellt sind die leistungserbringeridentifizierenden Daten. Diese werden durch eine auf Landesebene benannte Stelle pseudonymisiert und anschließend derart verschlüsselt, dass diese durch die Vertrauensstelle nicht eingesehen werden können. Die gelb markierten Informationen sind die medizinischen Daten. Diese werden im klinischen Krebsregister mit dem öffentlichen Schlüssel des IQTIG verschlüsselt und sind nur für die Auswertungsstelle als pseudonymisierter Datensatz einsehbar. Eine praktische Umsetzung bzw. Erprobung der Verschlüsselung erfolgte im Rahmen dieses Projekts nicht.

Ausgehend vom Patienten steht die Diagnose in dem Informationsmodell im Zentrum, da diese ausschlaggebend für alle weiteren Behandlungsoptionen ist. Ausgehend von der Bestimmung des PSA-Wertes (prostataspezifisches Antigen) und dem Verdacht auf ein Prostatakarzinom (ICD-Code C61) erfolgt eine Diagnosesicherung mittels Prostatastanzbiopsie (histopathologischer Befund inklusive Bestimmung des Gleason-Score und des klinischen Tumorstadiums, Nodalstatus sowie vorliegender Metastasen). Die TNM-Klassifikation kann anhand des Prostatastanzbiopsats im Rahmen der Diagnostik und nach einem operativen Eingriff anhand des Prostatektomiepräparats bestimmt und an das Krebsregister gemeldet werden. Aus diesem Grund ist die Klasse TNM-Klassifikation in Anlehnung an das ADT-GEKID-XML-Schema mit beiden Klassen (Diagnose, Operation) verbunden. Nach Durchführung der Diagnostik stehen dem Patienten in der Regel drei Therapieoptionen zur Verfügung (Prostatektomie, Strahlentherapie, Aktive Überwachung). Die Aktive Überwachung ist im ADT-GEKID-XML-Schema der systemischen Therapie zugeordnet, wurde jedoch für diesen Anwendungsfall unabhängig davon modelliert, um das Modell auf wesentliche Aspekte bei der Behandlung von Prostatakarzinomen zu reduzieren. Verschiedene Klassen, u.a. der Residualstatus, können nach Abschluss jeder Therapieform dokumentiert werden und sind aus diesem Grund mit unterschiedlichen Klassen verknüpft.

Die Überführung des Informationsmodells in das Datenmodell erforderte ein medizinisches Verständnis der Sachverhalte im Informationsmodell sowie technisch/ fachliche Kenntnisse über die Eigenschaften und den intendierten Nutzungszweck der unterschiedlichen FHIR^®-Ressourcen. Die Überführung erfolgte durch intensives Studium der FHIR^®-Ressourcenbeschreibungen und durch die Unterstützung der Community im FHIR^®-Chat. Die technische Umsetzung des Datenmodells erfolgte auf dem zu diesem Zeitpunkt aktuellen Release v.4.0.0 von HL7 FHIR^® unter Nutzung der Online-FHIR^®-Registry Simplifier und der Software Forge zur Erstellung der FHIR^®-Profile [11]. Das Datenmodell ist in Abbildung 3 [Abb. 3] skizziert. Die Farbgebung der FHIR^®-Ressourcen entspricht der Farbgebung im Informationsmodell. Die Abbildung zeigt die Unterschiede bei der Modellierung zwischen dem UML-Informationsmodell und dem FHIR^®-Datenmodell. Die Verknüpfung erfolgt auf Basis von Referenzen, die durch die jeweilige Ressource vordefiniert sind. Beispielsweise wird die Diagnose durch die Referenz subject mit dem Patienten verknüpft. Die Verknüpfung einer Strahlentherapie mit einer Diagnose erfolgt hingegen mit einer reasonReference. Aufgrund der Vorgaben von HL7 FHIR^® nimmt der Patient im Datenmodell die zentrale Position ein. Der im Informationsmodell modellierte Behandlungsprozess ist im Datenmodell nicht mehr eindeutig ersichtlich.

Die Umsetzung des Informationsmodells in HL7 FHIR^® erfolgte durch die Modellierung von FHIR^®-Profilen, für jede Klasse des Informationsmodells wurde ein eigenes FHIR^®-Profil erstellt. Eine Orientierung gaben dabei existierende FHIR^®-Modellierungen zur Tumordatenübertragung sowie Empfehlungen der FHIR^®-Community. Um alle Inhalte des Informationsmodells abbilden zu können, war die Einbindung von Extensions notwendig. Eine entsprechende Übersicht der Modellierungen ist in Tabelle 1 [Tab. 1] dargestellt. In der linken Spalte werden die FHIR^®-Ressourcentypen und in der rechten Spalte die daraus abgeleiteten Profile gezeigt, die anschließend im Datenmodell verwendet wurden. Ebenfalls wurden Codesysteme und Valuesets auf Grundlage der Vorgaben des ADT-GEKID-XML-Schema erzeugt und entsprechend in die Profile eingebunden.

Die modellierten FHIR^®-Profile wurden genutzt, um Beispiele von Patientendatensätzen zu generieren. Es wurden 2 Patienten modelliert und unterschiedliche Clinical Impressions, Conditions, Observations, Procedures und Organizations. Jede Ressource bildet einen Ausschnitt aus einem fiktiven Behandlungsprozess ab. In einem praktischen Szenario wird eine Kombination aus Patientendaten, Leistungserbringerdaten und Behandlungsdaten benötigt. Diese lässt sich in HL7 FHIR^® mit Hilfe eines Bundles abbilden. Es wurden 13 Bundles erstellt, die jeweils unterschiedliche Informationen enthielten.

Die Plattform Simplifier ermöglicht die Validierung aller FHIR^®-Objekte und Beispiele. Die Profile, Codesyteme und Valuesets, die für das Datenmodell entwickelt wurden, wurden zur Validierung auf Simplifier hochgeladen. Simplifier nutzt die erstellten Profile und validiert die Beispieldaten gegen diese.

Die Ergebnisse des Proof of Concepts zeigen, dass sich FHIR^® mit seinen üblichen Tools und Modellierungen durchaus als sinnvolle Alternative für die Erstellung einer Spezifikation zur einheitlichen Übermittlung von Daten anbietet und sich daher eine intensivere Beschäftigung mit diesem Ansatz lohnt.

Im Besonderen erscheint die Erstellung von und Auseinandersetzung mit einem Informationsmodell als sehr gewinnbringend, da damit effektiv ermöglicht wird, dass beteiligte Akteure den Prozess und die Zusammenhänge besser verstehen und es weniger Interpretationsspielraum gibt [12].

Das Ziel bei der Entwicklung des Informationsmodells war es, die patienten- und leistungserbringeridentifizierenden und medizinischen Daten derart zu modellieren, dass sowohl die klinischen Krebsregister effizient die entsprechenden Informationen in ihren Datenbanken selektieren und exportieren und die entsprechenden Auswertestellen diese entgegennehmen, verstehen und sinnvoll weiterverarbeiten können. Die bereits bestehenden Informationsmodelle dienten zwar als Vorbild, wurden jedoch im Rahmen der Arbeit nicht systematisch verglichen und analysiert. Das Informationsmodell des einheitlichen onkologischen Basisdatensatzes, welches in dem Beitrag der HL7 Mitteilungen dargestellt ist [13], stellt sehr umfangreich die semantischen Zusammenhänge in der Onkologie dar und geht damit weiter als das, was im Rahmen dieser Arbeit für den speziellen Use Case betrachtet wurde. Eine nähere Auseinandersetzung und ein näherer Abgleich mit den hier dargestellten Ergebnissen wäre sicherlich sinnvoll.

Da die Qualitätsindikatoren, die im Rahmen dieses QS-Verfahrens genutzt werden sollen, noch in der Entwicklung sind, konnten nur die bereits bekannten Qualitätsaspekte berücksichtigt werden. Qualitätsaspekte stellen noch keine operationalisierten Qualitätsindikatoren dar, d.h. es existieren noch keine Rechenregeln zur Berechnung der Qualitätsindikatoren und somit auch noch keine exakte Definition der Datenfelder, die benötigt werden. Sobald die Entwicklung des QS-Verfahren abgeschlossen ist, sollten die tatsächlich zum Einsatz gebrachten Datenelemente noch einmal abgeglichen werden.

In den klinischen Krebsregistern werden Einzelmeldungen geprüft und zu einem Best-of-Datensatz des Patienten zusammengeführt. Es ist möglich, dass derselbe Sachverhalt in mehreren Meldungen enthalten ist und sich die Angaben durchaus unterscheiden oder sogar widersprechen können. Mit der Generierung eines Best-Of-Datensatzes mittels möglichst einheitlicher Regeln wird versucht, die validesten Informationen zu einem Patienten zusammenzustellen. Im Rahmen dieser Arbeit wurde die Modellierung auf Meldungsebene und nicht auf Best-Of-Ebene vorgesehen, da auf Meldungsebene die Vorgaben der ADT-GEKID-XML-Datei mit den zugehörigen Meldeanlässen berücksichtigt werden konnten.

Der G-BA legt die Zweckbindung der zu erhebenden Daten für jedes QS-Verfahren in seinen Richtlinien fest und folgt dabei den Grundsätzen der Datensparsamkeit. Aus diesem Grund wurden in dieser Arbeit nur die Datenfelder betrachtet, die für das zukünftige QS-Verfahren „Lokal begrenztes Prostatakarzinom“ unmittelbar von Bedeutung sind.

Die Erstellung des Informationsmodells gestaltete sich anfangs schwierig, wurde mit der Zeit jedoch klarer und verständlicher. Einfach gestaltete sich die Modellierung der FHIR^®-Profile. Um den gesamten Use Case abzudecken, musste häufig auf Extensions zurückgegriffen werden. Eine Einbindung bestehender Profile aus anderen Projekten war leider nicht möglich, da die Zielstellungen dieser Projekte von dem Ziel dieser Arbeit zu stark abwichen. Hilfreich waren bestehende FHIR^®-Projekte zur Tumordokumentation dennoch, insbesondere, um ein Verständnis für die unterschiedlichen Möglichkeiten der Modellierungen von Ressourcen, z.B. bei der Nutzung der korrekten Referenzbeziehungen zwischen den Profilen herzustellen. Bei der Entwicklung der FHIR^®-Profile wurde auf das Tool Forge zurückgegriffen, dies stellte eine enorme Erleichterung bei der Entwicklung der Profile dar. Ebenfalls hilfreich war die Plattform Simplifier, welche die Validierung der entwickelten FHIR^®-Objekte unterstützte. Zukünftig sollte zusätzlich der HL7 FHIR^® Validator genutzt werden, da mit ihm wesentlich genauere Ergebnisse erzielt werden können. Nachdem die Modellierung des Informationsmodells mit HL7 FHIR^® abgeschlossen war, konnte das Datenmodell erstellt werden. Zusätzlich zum Datenmodell wurden unterschiedliche Testdateien zum Testen des gesamten Projekts generiert.

Es konnte gezeigt werden, dass das entwickelte Datenmodell fehlerfrei modelliert wurde und die Beispiele valide sind.

Die semantische Verknüpfung der einzelnen Informationseinheiten in einem Informationsmodell und die Herstellung eines gemeinsamen, von einer technischen Umsetzung abstrahierten Verständnisses der Prozesse und Zusammenhänge bildet einen wichtigen Schritt zur Schaffung von Interoperabilität [13], [14]. Dies wird insbesondere im Vergleich des Informationsmodells mit dem FHIR^®-Datenmodell ersichtlich. Die Stärken des Informationsmodells liegen in der Beschreibung eines Prozesses und der Darstellung logischer Zusammenhänge zwischen unterschiedlichen Informationsentitäten. Ein Datenmodell ist streng an die zugrundeliegende Technologie gekoppelt, so dass fachlich-organisatorische Eigenschaften in den Hintergrund treten können.

Die in dieser Arbeit geschaffenen Grundlagen stellen einen wichtigen Schritt für die Nutzung eines internationalen Standards zur Spezifizierung einer Übermittlung von Tumordaten zwischen klinischen Krebsregistern und dem IQTIG als Bundesauswertungsstelle der verpflichtenden Qualitätssicherung des G-BA im Kontext eines Qualitätssicherungsverfahrens als Proof of Concept dar. In einem Folgeprojekt sollten die theoretischen Vorgaben in einem realen Umfeld praktisch umgesetzt werden. Dies ist im Rahmen einer weiteren Abschlussarbeit in Zusammenarbeit zwischen dem klinischen Krebsregister Niedersachsen und dem IQTIG bereits geplant.

Mittel- bis langfristig ist eine Harmonisierung der unterschiedlichen existierenden Projekte zur Modellierung von Krebsregisterdaten anzustreben. Denkbar wäre die Entwicklung gemeinsamer medizinischer Informationsobjekte (MIOs) in HL7 FHIR^®. Spezifikationen mit einem unterschiedlichen Use Case können von den MIOs als zentrale Elemente die notwendigen Ressourcen für die jeweiligen Datenmodelle ableiten. Die Einbindung von Integrating the Healthcare Enterprise (IHE) als international tätige Organisation zur Entwicklung medizinischer Use Cases und Erarbeitung von Empfehlungen zur technischen Umsetzung stellt einen weiteren wichtigen Schritt in Richtung eines internationalen Standards dar. Auch eine Beratung des Themas in nationalen Konsortien, wie z.B. dem Interoperabilitätsforum, ist Gegenstand weiterer Arbeiten.

Die Autoren erklären, dass sie keine Interessenkonflikte in Zusammenhang mit diesem Artikel haben.