Folge #170 – Forschungsdatenportal für Gesundheit

Einen wunderschönen guten Morgen und herzlich willkommen zu einer weiteren Ausgabe des eHealth-Podcast. Wir sind angekommen bei Folge 170 und wollen heute sprechen über FDPG. Nein, keine Angst, es geht nicht um die FDP, sondern um das Forschungsdatenportal für Gesundheit als zentralen Anlaufpunkt für Wissenschaftlerinnen und Wissenschaftler. Und was es damit auf sich hat und vielleicht auch wie der Zusammenhang zur Medizininformatik-Initiative ist. Das mache ich mal wieder nicht alleine, sondern habe mir einen Gast eingeladen, der sich damit sehr, sehr gut auskennt. Und das ist heute der Julian Gründner. Herzlich willkommen, Julian. 

Guten Morgen. Morgen. 

Vielleicht zum Start der klassische Ablauf. Wer bist du? Was machst du? Warum haben wir dich eingeladen zum Thema FDPG? Julian Gründner, ich bin aus Erlangen im Moment, bin hier an der Universität und habe ursprünglich vor Jahren in Schottland Management, Psychologie und Finanzwirtschaft studiert. Und später aber dann in Erlangen, den Doktor, bzw. Erst mal in Deutschland Informatik gemacht und dann Doktor in Medizinischer Informatik. 

Das Ganze hat eine große Bedeutung im Rahmen der Medizininformatik-Initiative. Da soll eben eine Forschungsdateninfrastruktur zwischen den beteiligten Zentren aufgebaut werden. Wir hatten zur MII schon eine Folge mit Uli Prokosch und Thomas Ganzland. Also wer da noch mal zurückhören möchte, verlinken wir gerne noch mal in den Show Notes. Und heute soll es eben um das Thema Forschungsdatenportal gehen und was das genau ist, was es damit auf sich hat. Ich stelle mal ganz kurz die Agenda vor. Also wir wollen uns anschauen, was ist denn dieses FDPG überhaupt? Was sind wesentliche Funktionen? Wer nutzt es aktuell und wie sieht auch der zukünftige Plan der Nutzung auf? Welche Szenarien sind da geplant? Und natürlich so ein bisschen, weil du ja auch ein bisschen von der technischen Seite kommst. Der Blick hinter die Kulissen, was musst du eigentlich technisch passieren, damit es alles so läuft? Wie ist das mit den Daten, wo werden die gespeichert? Da gibt es auch viele Sorgen und Ängste vielleicht können wir dann ein bisschen transparent schaffen und ein bisschen aufklären. 

Starten wir mit dem Thema Forschungsdatenportal für Gesundheit. Was ist das in kurzen wenigen Sätzen? Wie wird es sich immer mehr klären? Das FDPG, das Forschungsdatenportal für Gesundheit, soll es Forschern ermöglichen, Zugang auf Routinedaten über Deutschland in Deutschland zu bekommen. Und dabei soll der Forschende auf dem kompletten Weg begleitet werden von ganzem Anfang bis zum Ende. Das heißt von der ersten Idee, ich möchte eine bestimmte medizinische Fragestellung untersuchen. Bis ich bekomme über verschiedene beteiligte Krankenhäuser unikliniken Zentren diese Daten in entsprechend rechtlich sauberer anonymisierter Form zugestellt. Genau, also wie gesagt, der komplette Weg ist eine zentrale Stelle, so dass der Forschende nicht zu 37 in unserem Fall jetzt unikliniken, die wir angebunden haben, hingehen muss. Aber man hat eine zentrale Stelle, bei der sich sozusagen seine Forschungsfrage einstellt, beziehungsweise den Antrag stellt. Und eben auch rausfinden kann über seine Anfrage, ob wir gleich noch zu überhaupt möglich ist oder ob die Daten überhaupt zur Verfügung stellen. So genannte Machbarkeitsanfragen und Zugriff zu diesen Daten dann noch zu bekommen. Vorausgesetzt ist es für die rechtlichen Rahmenbedingungen. Und wenn die in Datenschutzdähen sprechen für die wahlige Forschungsfrage notwendig ist. 

Und was sind jetzt die wesentlichen Funktionen, die dieses Forschungsdatenportal bereitstellt? Genau, also wir begleiten den kompletten Prozess und mit dem kompletten Prozess, meine ich natürlich auch den kompletten Prozess. Das heißt, es geht los mit der Forschungsfrage, Forscher überlegt sich was, das liegt praktisch noch nicht bei uns, das macht der Forschern natürlich selbst. Und wenn der Forscher seine Forschungsfrage sich ausgedacht hat, dann ist der erste Schritt eigentlich mal erstmal zu sagen, gibt es überhaupt genug Daten, wo meine Forschungsfrage durchzuführen. Eine Machbarkeitsanfrage, also um rauszufinden, habe ich genug Patienten von meiner Forschung stellen zu können. Brauche eine Definition von meiner Kohorte. Also ich muss irgendwie beschreiben, wie meine Patienten aussehen. Und das ist bei uns die sogenannte Kohortendefinition. Das heißt, Forschungsfrage, dann kommt die Kohortendefinition, Beschreibung der Patienten, dann wird eine Machbarkeitsanfrage gemacht. Und bei dieser Machbarkeitsanfrage finde ich eben raus, habe ich genug Patienten von meinen Fragestellung ja oder nein. Wenn ja, dann kann der Forschende einen Antrag stellen, auch im Portal. Und dann, wenn der Antrag entsprechend genehmigt wurde, also der Antrag wird dann verteilt an die verschiedenen Datenintegrationszentren. Die müssen dann dem Antrag erst mal zustimmen, die prüfen den auf rechtliche, ethische Datenschutzrahmenbedingungen. Und wenn der Forschende das gemacht hat, kann er zusätzlich noch basierend auf der Kohortendefinitionen, Datenselektion und Datenextraktion definieren. Und mit dieser Datenextraktion, die quasi ganz gezielt und spezifisch für die entsprechende Forschungsfrage ist, können wir dann ein Datensatz auch extra hier in einem sogenannten Data-Use-Projekt-Datensatz. Also das ist ein Datensatz, der für diese Forschungsfrage aufbereitet wird. Das gibt ja eine Menge an Daten über die Uni-Kliniken und der Forschende interessiert sich oder braucht auch. Es gibt ja auch darum, dass man die Daten minimalisiert, also wirklich auf die Forschungsfrage zuschneidet und nicht den Forschenden einfach sämtliche Daten gibt. Und deswegen eben diese Data Use-Project-Daten-Sätze, die dann eben bereitgestellt werden. 

Vielleicht steigt man noch mal ganz vorne, noch mal kurz ein. 

Wir haben jetzt ja so ein bisschen die Schwierigkeit im Podcast, einen Prozess zu erklären, ohne die entsprechenden Übersichten in dem Webformulat zu sehen, wie das Ganze vonstatten geht, das erst mal eben diese Kohortendefinition, damit sich die Hörerinnen und Hörer das vorstellen können. 

Wie läuft das ab? Ich sitze als Forscher vor meinem Bürofenster und mache was. Also ich krieg dann zusammen, wie mein Patienten kollektiv aussehen soll, was ich untersuchen möchte. 

Im Prinzip genau das, also man kann nicht das so vorstellen, ein Patient hat Eigenschaft. Und ich bestimme eine Kombination dieser Eigenschaften, die meine Patienten erfüllen müssen, damit sie für meine Studie gebraucht werden oder damit sie für meine Studie passen. Zum Beispiel, ich suche nach weiblichen Diabetes-Patienten, denen Hemoglobinwert haben und älter als 60 sind. Und das basiert sozusagen auf der Basis von demografischen Daten, Stammdaten, Diagnosen, Prozeduren, Laborwerk. Wie kann ich bestimmt, was da alles dazugehört, was ich in meiner Abfrage mit reinnehmen kann? Wird das durch die MIE festgelegt oder gibt es sozusagen ein Basiskriterien-Satz, den ihr zur Verfügung stellt über das Portal? Wir haben einen Datensatz, der quasi durch die MIE definiert wird. Also wir basieren auf Daten, die vorher aufbereitet werden. Die sind definiert, die sind auch klar definiert, wie diese Daten auszusehen haben. Im sogenannten Kerndatensatz der MIE, da gibt es zwei Dinge, die man machen muss, einmal die semantische Interoperabilität auf der einen Seite und auf der anderen Seite auch diesen taktischer Interoperabilität. Wenn man sich das so überlegt, dann muss ich, wenn ich meinen Datensatz über verschiedene Krankenhäuser verteilt habe, muss ich natürlich einmal sicherstellen alle Sprechen vom gleichen. Das ist die semantische Interoperabilität und ich will es natürlich auch in der gleichen Stelle wiederfinden. Und wenn ich nach irgendwas suche, zum Beispiel nach einem Kot, bei einem Labor-Welt, dann will ich den natürlich auch in einer Stelle finden und nicht für jedes Krankenhaus einzelne definieren müssen. Und dafür gibt es eben einen Datensatz, der klar definiert wurde, der sogenannte Kerndatensatz, auf den wir dann zugreifen. So dass wir sobald Dinge im Kerndatensatz aufgenommen werden und einen ursprünglichen Fragezbaren fordern, dann auch diese Daten im FDPG an müssen. 

Also ich habe den Kerndatensatz, der definiert, was machbar ist. Da setze ich mich jetzt also an den Brauser und klickt mir eine Patienten-Kororte zusammen, macht diese sogenannte Machbarkeitsanalyse. Und wenn daraus kommt, ja, das ist machbar, da haben wir ausreichend Daten in den Beteiligten uniklidigen. Dann war der nächste Schritt der Patientenselektion? 

Der nächste Schritt ist dann eigentlich erst mal der Antrag. Also das ist ein bisschen so die Frage, was kommt zuerst? Das hänge-I-Problem, ich kann natürlich eine Machbarkeitsanfrage erstmal nur machen, wenn ich bei den Portal angemeldet bin. Also es kann nicht jeder einfach eine Machbarkeitsanfrage machen, dass es auch aus Datenschutz tründen. Wenn man so was natürlich, die, die sagt mal den Andres weg dominimieren. Das heißt, nicht jeder kann einfach Machbarkeitsanfragen machen. Aber wenn ein Forscher-Frei geschaltet wurde, kann er Machbarkeitsanfragen in einem gewissen Rahmen natürlich stellen. Und jetzt kommt es natürlich darauf an. Manchmal bängt er an mit seinem Antrag, geht dann zurück zu Machbarkeitsanfragen. Aber die Idee ist eigentlich, ich stelle erstmal die Machbarkeitsanfrage um zu gucken, macht es überhaupt Sinn weiter zu machen. Also vorausgünstig bin ich schon ein Portal angemeldet. Und dann würde ich aber das nächste Schritt eigentlich meinen Antrag verfassen. Wichtig an der Stelle dieser Antrag-Prozess, der ist auch vollständig über das Portal unterstützt. Und in diesem Antrags Portal wird der Forschende komplett durch diesen Prozess geführt. Das heißt, er stellt den Antrag, er kann dann die Machbarkeitsanfrage an den Antrag anhängen, stopp ihn ganz, ganz wichtiger Punkt. Damit man eben auch zeigen kann, ja es gibt genug Patienten und die Verwaltung des Antrags Tools kann sozusagen dann die Datenintegrationszentren kontaktieren, um anzufragen, ob sie bei einem bestimmten Antrag teilnehmen möchten oder nicht. Die bekommt dann die positive Rückmeldung und an diesen Antrag wird die Machbarkeitsanfrage angehängt. Und dann eben der zweite Teil, der sozusagen während des Antrags auch entsteht. Die gehörten Definition und Datenselektion, womit ich dann bestimmte, welche Daten nicht eigentlich haben möchte oder mit welchen Daten nicht arbeiten möchte. 

Ist das schon gesagt, welche ich haben möchte und mit welchen ich arbeiten möchte? Bekomme ich die Daten zu mir oder ist es so, dass ich letztendlich die Fragestellung reingebe und irgendwie nur ein Ergebnis bekomme? Das betrifft irgendwie so und so viele Patienten oder… Ich denke, wichtig an der Stelle ist vor allen Dingen zu sagen, dass das FDPG zu keinem Zeitpunkt die eigentlich Patienten Daten hat. Das heißt, ihr seid eher die administrative Schnittstelle, die koordiniert, die Prozesse zusammenführt und den Forscher mit den verschiedenen Unikliniken verbindet, ohne einen eigenen Speicher oder zwischen Speicher oder sowas aufzubauen sollen. Genau, und das ist auch ein ganz ganz wichtiger Punkt, weil da entstehen noch viele Missverständnisse, also wir haben die Daten zu keinem Zeitpunkt, was wir bekommen, zum Beispiel bei einer Machbarkeitsanfrage oder der Forschende, in dem Sinne dann bekommt. Und natürlich dann die Plattform auch verarbeitet, in dem Sinne sind die aggregierte Informationen zu Patienten Mengen. Also bei einer Machbarkeitsanfrage gehen wir zurück zu unserer Diabetespatient, weiblichen Diabetespatienten über 60. Also in dem Fall bekomme ich eine Zahl zurück, über alle Kliniken hinweg, wie viele Patientinnen sind Teil meiner Kohorte. Wichtig an der Stelle ist auch, dass diese Informationen auch verschleiert werden. Also ich bekomme keine genaue Zahl, war einfach gesagt, dass es noch ein bisschen kompliziert hat, aber im Vereinfach gesagt runden wir auf den nächsten 10er, so dass man nicht auf den einzelnen Patienten Rückschlüsse ziehen kann. Bei der Koart und Definition und Datenselektion, da kann man im Portal nur die Kohorte definieren und die Datenselektion, da kommt ein Objekt raus oder was eigentlich mal Maschinen lesbar ist, was wir verschicken an die Standorte. Und dann wird der Datensatz am Standort extrachiert, also auch ganz wichtiger an der Stelle ist ein verteiltes System und die Daten werden an den Standorten und nicht eben zentral erst mal verarbeitet. 

Gibt es ein bestimmtes Datenformat, indem ihr das verschickt, also wenn der Forscher seine Anfrage zusammenbastet und ihr diese Anfrage dann an die beteiligten uniklinigen Schickt ist, dass dann schon ein standardisiertes Datenformat oder ist das was proprietäres? 

Das ist was proprietäres tatsächlich, als wir damit angefangen haben, das zu definieren. Diese Koart und Definition aber auch die Daten extrach und Datenselektion, gab es nichts auf dem Markt, was man, also Open Source, was man so hätte jetzt direkt nehmen können für unsere Zwecke, was die Funktion erfüllt hat, die wir brauchen. Es gibt auch einen wissenschaftlichen Paper dazu, dass man sich natürlich gerne durchlesen kann, warum das notwendig ist und was das entsprechend bedeutet. Wichtig dieses Format ist proprietär, aber eben Open Source, also nicht irgendwas, was wir uns selber ausgedacht haben, aber ganz klar beschreibt, wie so eine Machbarkeit zum Frage aussieht und jemand der technisches Verständnis hat oder grob mit technischen Objekten, in dem Fall ist es ein JSON-Format, umgehen kann, der kann die quasi fast lesen, also es ist sehr nah an dem dran, wie es auch in der Oberfläche und das wird dann entsprechend übersetzt an den Standorten, in die entsprechenden Anfragesprachen der Datenspeicher. Das ist dann sozusagen Aufgabe der medizinischen Datenintegrationszentren sozusagen, also der Ditz. Sie machen alles wie, aber im Prinzip ist es so, dass der Forschende seine Machbarkeitsanfrage oder seine Koart und Definition definiert, in unserem Format und dieses Format wird dann automatisch in die entsprechende Anfrage sprache übersetzt. Im Moment ist es so, dass es eben der große Vorteil bei Datenintegrationszentren, dass die alle einen Standard haben, eben diesen FHIR-Standard, der verwendet wird, um Patienteninformationen darzustellen und wir dann auf diesen Standard zugreifen können. Jetzt könnte man natürlich sagen, ja gut, es ist ein Standard, dann muss es ja genau eine Anfragesprachen geben. Es gibt aber de facto Momente, zwei, die wir unterstützen. Wie bei vielen Standards ist es so, dass man dann verschiedene Produkte oder Teile erweitert, dazu spezifiziert und bei Feier ist es eben auch so, dass es verschiedene Möglichkeiten gibt, diese Anzufragen, die vor Nachteile haben oder deswegen unterstützen wir im Moment in zwei. Wir können aber durch dieses Set-up, wie wir es erstellt haben, auch beliebige Anfragen sprachen, natürlich eine Stützung vorausgesetzt. Man macht die Arbeit dafür, um das in die entsprechende Anfragesprachen zu versetzen, aber die Machbarkeitsanfragen die zentral gebaut wird vom Forschenden. Die ist immer gleich und die kann dem dann, dass es schöner in diesem System, wie wir es erstellt haben, in die verschiedenen Anfragen sprachen übersetzt werden. 

Der Forscher klickt sich was zusammenvereinfach gesagt, daraus macht ihr ein proprietäres JSON-Format, was aber frei verfügbar ist und das wird dann aktuell in zwei verschiedene Feier-Dialekte, sag ich mal, übersetzt um verschiedene Datenintegrationszentren ansprechen zu können. Genau, also das beschreibt es eigentlich ganz gut, würde ich sagen. 

Also angenommen, die Anfrage ist jetzt raus und kommt jetzt im richtigen Feier-Dialekt an dem Datenintegrationszentrum an. Wie geht es dann da weiter? Erstmal passiert manuell gar nicht, sondern es ist alles voll automatisiert sozusagen. Und die Anfrage würde ankommen am Standort, in dem entsprechenden ersetzten Format, ob würde automatisch ausgeführt werden, wenn es einen Machbarkeitsanfrage ist am Standort, dann haben wir dort Programmen laufen, so zu sein, die diese Ausführung durchführen und dann aber eben noch eine Verschleierung auf die Antwort, die daraus kommen, ist am Standort schon machen. Also die Verschleierung ganz wichtig, es sieht nicht zentral, sondern dezentral am Standort schon, sodass wir dann die Daten dort verschleiert werden dort automatisch verschleiert und werden dann zurückgesendet an das FDPG. Das heißt, das ist auch so mit Dein Drop, genau diese Kommunikationswege zu etablieren, zu sagen, also wie sende ich in welchem Format Daten vom FDPG an die Standorte und wie verarbeitet das, was das alles zurückkommt, um es dann den User an der Oaffläche anzuzeigen oder zum Download oder sowas zur Verfügung zu stellen. Das ist auch erstmal ganz einfach, aber wenn man ins Detail geht, dann ist es tatsächlich recht kompliziert. Was sind die größten Hörden da an der Stelle oder was war die größte Herausforderung? Ich meine, das Ding läuft ja jetzt, funktioniert ja in der Basisversion, soll natürlich noch zig Sachen erweitert werden, aber was war bis jetzt die größte Herausforderung? 

Ich würde es vielleicht um das noch mal zu erklären, noch mal darauf eingehen, was dann im Hintergrund eigentlich tatsächlich passiert. Ich habe auch ein kleines Beispiel mitgebracht, was man eigentlich tun muss, was alles passieren muss, damit man einen einfachen Laborwert abzragen kann. Und Beispiel klingt immer gut. Dann würde ich da einfach mal darauf eingehen, dass der erste Punkt ist ja, also wir wollen ja eigentlich nur Machbarkeit und Daten-Exaktion machen. Das klingt erstmal einfach. Ich habe Menge an Daten und dann kann ich den Forschenden dazugriff geben und dann soll er da sein. Das ist natürlich nicht, weil wir auf der einen Seite den Forschenden nicht direkt Zugriff zu den Daten geben können, aus Datenschutzrechtlichen Runden. Weil eben eine verteidete Infrastruktur haben. Und auf der anderen Seite muss man das Ganze natürlich auch aufbereiten, weil man nicht von jedem Forschenden erwarten kann, dass er sich mit den medizinischen Datenkommunikationsstandards auskennt. Und dementsprechend muss man diese Komplexität, die eben in so einem planischen System vorhanden ist, irgendwie aufbereiten. Und das erste, was eben für uns ist, ist dieser Kerndatensatz, der quasi beschreibt, wie sollen die Daten aussehen, beschreibt diese mantische Interoperabilität eben, dass jeder Standort genau das Gleiche meint, komme ich gleich darauf, was es genau bedeutet. Und die sind praktisch, dass die Daten eben identisch aussehen, also die Tabellen, einen Anführungszeichen, wenn man sich das als Tabelle vorstellen wollen, würde Feier als kein Tabellen, war mal daran, muss wäre eins, dass alle die gleiche Tabelle haben, um nicht jeder eine andere. So kann man sich das grob vorstellen. Und wichtiger an der Stelle ist, dass wir eben auf Daten aufbauen, die schon standardisiert und harmonisiert sind. Bis zum gewissen Grad. Also da gibt es auch Sachen, die uns manchmal vor die Füße fallen, wo man merkt, okay, ist das zwar standardisiert. Und eigentlich alle das Gleiche, aber vielleicht doch nicht genau das Gleiche. Stichwort Einheiten bei Laborwerken, da gibt es eben Unterschiede, wie Laborwerte, in welchen Einheiten diskutiert werden, obwohl alle quasi Feier machen und obwohl alle den gleichen Laborwert nehmen, eine andere Einheiten. Der Forschende soll seine Machbarkeit beschreiben können oder seine Kohorte und diese, diese einzelnen Kriterien von dem wir vorm gesprochen haben, soll er verrunden und verordern können und jetzt würde ich einmal kurz darauf eingehen, was da eigentlich passieren muss, wenn man sich jetzt nur einen kleinen Teil davon anguckt. Und zwar stellen wir uns vor, oder der Forschende hat eine Krothie definiert und als Teil dieser Krothie interessiert sich für ein Laborwert. Und wir nehmen jetzt mal den Laborthemo-Glubien, dann geht er ins Portal und sagt, okay, ich will einen Chemoglubienwert. Wenn er sich tatsächlich ins Portal einlockt und ergibt, Chemoglubien ein, findet er 599 Treffer für Chemoglubien. Das ist natürlich eine ganze Menge und davon sind auch nicht alle zwingend Laborwert. Das heißt, das erste, was man verstehen muss, ist, dass ein Wort Chemoglubien in verschiedensten Farben, Varianten und Formen vorkommen kann. Und eben nicht nur Laborwert ist, sondern auch bodezellen Prozeduren in Diagnose. 

Wo kommt diese Liste her, diese 501 Trege? Das nutzt ihr dann eine Terminologie oder noch ein Klatur im Hintergrund? Irgendwo müssen die natürlich herkommen. Klar, das ist ein guter Punkt. Dafür haben wir Terminologie-Server. Wir haben einen extra Team, sozusagen in der MII, die sich hauptsächlich um Terminologien kümmern. Und diese Terminologien werden dann in Server geladen und wir greifen auf diesen Server zu und laden uns bekannte, sag ich mal, weit verbreitete, medizinische Terminologien runter. Und erstellen daraus, was wir ontologienen. Es ist keine ontologie im klassischen Sinne. Aber sagen wir mal eine herarische Anordnung von Kriterien, die einen forschen wir auswählen kann. Und dafür verwenden wir eben diese Terminologien, wie z. B. LOINC, Belabor, SNOMED CT, ist relativ bekannt, was ja ein bisschen alles macht, Alpha-ID, ECDC. Also was wir noch ebenso kennt, es gibt verschiedene Terminologien, die eben hier gezogen werden und aus denen dann letztendlich auch diese Kriterien kreiert werden. Weil es muss natürlich klar definiert sein, was so ein Kriterium ist. Weil einfach zu sagen, Chemoglubien, wie ich ja schon gesagt habe, 579 Treffer, Chemoglubien ist nicht gleich Chemoglubien. Kann dem Blut gemessen werden, im Serum gemessen werden, kann in unterschiedlichen Einheiten gemessen werden, genau unter. Würde ich jetzt genau spezifizieren, welchen Chemoglubien werde ich denn haben möchte. Also ich hätte jetzt hier z. B. Angenommen, ich entscheide mich jetzt vor allem, dass es mein LieblingsHämoglobin wird, warum weiß ich nicht genau. Aber angenommen, ich entscheide mich für die 718-7. Das ist einfach einer der relativ häufig vorkommt und den ich ganz gut kennt und das ist Hämoglobin-Masse-Provolumen. Dann habe ich eben diesen Chemoglubienwert ausgewählt und jetzt könnte man eigentlich mal nah gut, dann bin ich ja eigentlich fertig. Ich habe mein Chemoglubienwert ausgewählt, die 718-7 und dann schick ich das weg und jeder Standort kann das beantworten. Jetzt ist aber so der Grund, warum jeder Standort das beantworten kann, ist weil die Datenintegrationsdämter und DMAE eben schon im Vorhinein waren, wenn ich viel Arbeit geleistet hat, damit jedes Krankenhaus die 718-7 auch bei sich in den entsprechenden Daten speicher stehen hat. Weil was passiert in klassischen Primärsystemen, wenn jedes Krankenhaus hat eine Laborsysteme und wir haben 37 Standorte stellen wir uns mal vor, wir picken zwei raus. Also wir suchen uns zwei dieser Standorte raus und gucken in deren Tabelle und stellen fest Standort 1 hat Chemoglubien codiert, also die 718-7 hat der codiert als Chemoglubien 1,2,3. Und dieses Chemoglubien 1,2,3 steht in der spalte Code von Tabelle 1 in Standort 1, also Chemoglubien 1,3 Code Tabelle 1. Und im anderen Standort hat der Standort hat es nicht als 718-7 codiert, sondern Chemoglubien 4,5,6. In der spalte klinische Bezeichnung Tabelle 5. Dann ist es natürlich wahnsinnig schwierig, für uns eine Auffrage zu machen, wenn wir eigentlich nur die 718-7 vom Forschenden haben, aber wir müssen das praktisch zuordnen können auf die entsprechenden Tabellen und Spalten in den Primärsystemen. Das könnte man natürlich sagen, kein Problem machen wir an dem Standort, die das Standort macht es bei sich für sich, on the fly und übersetzt es dann in die entsprechenden Spalten und Tabellen in dem eigenen Systemen. Und damit machen wir es aber andersrum, das heißt, die Standorte gehen vorher, bevor die Anfrage kommt hin und laden sich die Daten aus ihren Primärsystemen und harmonisieren die. Das heißt, wir harmonisieren die und für diese manchenden Tababilität kommen eben diese Code-Systeme zum Einsatz, die Themen logien. Dass jeder Standort wirklich die 718-7 auch als 718-7 bei sich drinstehen hat und zusätzlich die syntaktischen Taberabilität, dass alle das FHIR-Format haben. Das heißt, am Ende hat jeder die gleiche Tabelle oder das gleiche Datenobjekt, wie gesagt, Feier ist keine Tabellenstruktur, aber das gleiche Jasonobjekt nennt wir es jetzt mal, also ein Objekt. Das heißt, dieses Feld-Code steht an der gleichen Stelle oder der Code steht an der gleichen Stelle, nämlich im Feld-Code, im gleichen Datenobjekt mit der gleichen Bezeichnung. Und das ist eigentlich das tolle an der MEI oder. Das heißt, viel Arbeit passiert schon in den Datenintegrationszentren, die die Daten schon so aufbereitet haben, dass die auch die entsprechenden MEI-Terminologie-Dienste nutzen. Und dass man dann eben tatsächlich so eine Anfrage 718-7 direkt an die Zentren schicken kann und die schon eine Aufbereitung haben und nicht noch einen Mapping our flyerfolgen. Genau. Und das ist wirklich auch ein wichtiger Punkt, dass man versteht, was MEI hier auch geleistet hat, dass eben 37 Standorte im Moment sich so koordiniert haben und so auf einen Format und eine semanischende Obität geeinigt haben, dass man eben solche Anfragen überhaupt stellen kann. 

Und dann machen wir weiter im Beispiel. Das heißt, jetzt geht diese Anfrage raus. Das heißt, wir haben an den beiden Standorten tatsächlich die 718-7 als semantische Bezug drin und die Anfrage kann somit verarbeitet werden. Wie geht es dann weiter? Fast. Also man, erst nachher die Anfrage des Vorschenden, das haben wir ja vorhin gesagt. Und jetzt ist es aber so, dass der eine Standort vielleicht nur den einen Dialekt spricht. Also FHIR Search werden wir vorhin von den Anfragen gesprochen und der andere Standort der kann nur SQL. Das heißt, das müssen wir machen. Wir müssen erst mal das sind beide Anfragen gesprochen übersetzen. Also FHIR Search und SQL. Und dann müssen wir natürlich dafür sorgen, dass jeder Standort auch das bekommt, was er verarbeiten kann. Und wenn das passiert ist, dann kann der Standort das auch ausführen. Wenn man zum Beispiel Daten verarbeitet, dann wäre das bei FHIR Search und Date. Da würde man einfach eine Anfrage machen, wo man sagt, Datum ist gleich oder Date ist gleich. Und bei SQL wärs effektiv ist gleich, bei Labor werden jetzt. Und das ist eben was, was wir auch als Teil des FDP geben, dann generieren. Okay, und jetzt haben wir das soweit gemacht. Das heißt, wir haben diese Übersetzung in den Dialekt und zum Beispiel FHIR Search. Und jetzt kommt das beim Ditz an und die Senden jetzt was zurück. Genau, also der Restput passiert dann eben automatisch. Das hat wir ja vorhin auch schon mal kurz gezählt. Also dann sind wir eigentlich mit den komplexen Sachen wie Zuhörtenung, Mapping, Ausführen der Anfrage, Sprache. Also muss natürlich auch dafür sorgen, dass diese Anfrage richtig übersetzt wird. Und wenn man das gemacht hat, dann kriegt man bei der Machbarkeit einen Fall der Machbarkeit eine Zahl zurück, die dann eben verschleiert wird. Und dann wird diese Anfrage eben zurückgeschickt an das FDPG. Und man sieht sie hier, wir haben jetzt hier ein sehr einfaches Beispiel. Und trotzdem hat man so viele Schritte von erstellen einer Anfrage für ein einzigen Wert. Jetzt habe ich hier quasi nur hier nur Glubinen, sieben ein Tag sieben skizziert. Und wir haben noch über ganz viele andere Dinge nicht gesprochen, die das Portal auch können und leisten muss. Jeder einzelne Punkt oder jeder, jeder Feature, jede Fähigkeit, die dieses Portal hat, kann man sich ähnlich komplex tatsächlich vorstellen. Und alle Sachen, die wir tun, die ziehen sich immer von vorne bis hinten durch. Das heißt, ich kann nicht einfach sagen, ich will den Datumabfragen, wenn sich es im Datenspeicher gar nicht vorhanden ist oder im Kerndatensatz nicht entsprechend spezifiziert wurde. Das heißt, man hat immer eine sehr komplizierte Zusammenarbeit auch um teilweise vermeintlich einfache Dinge umzusetzen. Umzusetzen und eher zur Verfügung zu stellen. Ja, jetzt hast du es an einem einfachen Beispiel vermeintlich einfachen Beispiel, Hemo-Gubinen beschrieben. Was macht das jetzt so kompliziert? Warum ist das so ein Großprojekt an dem mehrere Leute arbeiten, dass jetzt eben auch von technischer Seite sehr intensiv begleitet werden muss? Vielleicht kannst du da nochmal kurz auf eingehen. 

Wir haben jetzt ja schon relativ lang gesprochen, deswegen versuche ich mich relativ kurz zu halten. 

Ich würde es einfach mal ein paar Stichpunktelisten, was wir mit, was wir uns so alles beschäftigen. Unter anderem müssen wir natürlich übertragen, sicherstellen. Das machen wir mit dem Data Sharing Framework. Das wurde auch innerhalb der Medizininformatik-Initiative entwickelt, um die Daten sicher… Und die Anfragen sicher zu verteilen und die Antworten sicher zurück ans FDPG zu führen. Wir haben eine Verschleierung der Antworten. Das hatte ich ja auch schon kurz geziert. Das heißt, da muss man auch eben sicherstellen, dass der Datenschutz gewährleistet ist. Wir haben weitere Felder, wir haben jetzt uns nur Kot angeguckt, aber man kann sich auch vorstellen, dass man Datumfelder abfragen will. Oder weitere Attribute. Oder auch die Kombination davon. Das heißt, innerhalb eines Kriteriums kann es Kriterium wieder mehr Attribute haben, die dann natürlich auch zusammen spielen. Wir haben Ausnahmen, das heißt, nicht jedes, nicht jede Ressource, nicht alles, was im Feier-Server ist, kann gleich behandelt werden. Denn Labor-Wert ist nicht genauso wie eine Diagnose, weil vielleicht andere Felder. Wir haben sehr große Terminologien. Ich habe gestern mal geguckt aus Syrux und Dollar rein, einfach mal gucken, wie viele Kriterien wir eigentlich haben. Wir haben ein Moment über 400.000 Kriterien, die man im Portal auswählen kann, nachdem man suchen kann. Was aber nicht heißt, dass die auf den Datenintegrationszentren alle auch belegt sind, aber prinzipiell wäre das, dass das Spektrum, was man rein theoretisch abfragen, könnte 350.000 Nr. Konzepte plus Lowing und X. Und tatsächlich ist das auch ein Problem, weil es natürlich jetzt sein kann, dass ich biete 400.000 Kriterien an. Und davon hat vielleicht von den 400.000 haben Standorte vielleicht 100.000. Ich will natürlich trotzdem die Kriterien anbieten, weil ich ihm zeigen möchte, was theoretisch möglich ist. Und deswegen haben wir dann angefangen, jetzt auch die Verfügbarkeit auf Kriterien eben darzustellen, damit der Forschende relativ früh weiß, lohnt sich die Anfrage überhaupt. Oder weiß ich eigentlich schon, bevor ich die Anfrage stelle, dass da nix rauskommen kann, weil es eben kein Standort hat. Und das sind Dinge, die einem dann gerade erst auffallen, wenn man das, wenn man das Portal sich genauer anguckt und eben solche Sachen dazu fallen zu fühlen. 

Es ist weit fortgeschritten in der Zeit, deswegen würde ich gerne einfach zum Schluss kommen und sagt nochmal ganz lieben Dank Julian, dass du da warst und es da ein Einblick gegeben hast. 

Ja gerne, also hat mir auf jeden Fall viele Freude bereitet. Es ist ein spannendes Thema, kann ich nur jedem empfehlen und zu studieren und sich damit zu beschäftigen.