Folge #154 – Unispital Basel und neue KIS- und Krankenhaus-IT-Architektur

Haben auch heute wieder jemanden zu Besuch, und zwar ist das Dr. Amanda Herbrand, wird einem deutschen Namen am Unispital in Basel. Wir werden also heute bis hin uns in der Schweiz umtreiben. Das Thema wird heute sein. Wir hören was zur Digitalisierungsstrategie vom Unispital Basel, auch deswegen spannend, weil jetzt in Zukunft ihr Kiss ausschreiben wollen und weil sie dort ein anderen Weg gehen werden, nicht mehr eine, sagen, verteilte Datenbasis bei den unterschiedlichen Systemen, sondern einen zentralen Datenspeicher. Und das ist das Revier von ihr als Podcast, uns auch die Zukunft eigentlich vorstellen, deswegen freue ich mich sehr, dass du heute da bist. 

Beginn wir, indem du dich erstmal kurz vorstellt, und auch das Unispital in Basel. Vielen Dank, Christian. Ich freue mich total hier zu sein. Habt auch schon ein Vorschein ein bisschen eingehört, ein neuer Podcast für einen super, was ihr dann macht. Kurz zu mir, ich bin Ärztin vom Hintergrund her, halbe Angiologin. Den Schach hat ich nicht fertig gemacht, von an mich entschlossen vorher in die IT abzubiegen. Wenn jetzt Zeit, genau, ungefähr ziemlich genau fünf Jahren in Basel. Ein Großteil davon im Unispital und jetzt seit über einem Jahr in die IT. Zum Unispital Basel eins von den fünf Universitätsspitälern in der Schweiz. Da waren das Kleinste. Allerdings der größte Versorge in der Nordwestschweiz, circa 8000 Mitarbeiter, knapp 800 Betten, also so, und den Träter, damit man das etwas genannt hat. Genau, und das für die Schweiz ist schon echt groß 800 Betten, das ist eigentlich eine Hausnummer. Haben natürlich auch einen Einzugsgebiet hier im Dreilandeg, ein bisschen Deutschland, ein bisschen von Frankreiches auch mit dabei. Das natürlich auch immer, auch immer spannend, wenn dann wie Auslinder ins Spital kommen von Abrechnung über vielleicht andere Medikamente oder was, was nicht was. Absolut. Das sind auch um eine Herausforderung. An der Sprache, wenn französisch ist, sehr eingeschränkt. Bei mir nicht existent, aber ja, kommen wir direkt zum Casus Knaxus. Wir kennen uns übrigens von der DMEA für die Zuhörerin und Zuhörer. Da haben Berner durch eine Session moderiert zum Thema Digitalisierungsstrategie und da hat am Ende einen ganz hervorragenden Vortrag gehalten, genau zu den Themen, die wir gleich auch ansprechen werden. Da ging es dann eben um die Digitalisierungsstrategie. Deswegen am Ende magst du das mal kurz vorstellen, was ihr da so vorhabt und warum ihr vielleicht auch deswegen dann das Kist neu ausschrauben wollt oder müsst. 

Das ist ein sehr gutes Thema. Muss man, glaube ich, fast ein bisschen weiter ausholen. Digitalisierungsstrategie wurde am Unispitalbaser, ich glaube 2019, 2024 im Bauffleben, im Hinblick auf die ganzen Challenges, die jetzt auf die Spitäler aus gesundheitswesen zukommen. Und dann kam erst mal COVID, dann ist erst mal nichts passiert und unabhängig davon ist uns dann unser eigenes Kiss ein bisschen auf die Füße gefallen. Dort gab es eine Entwicklungsstopp, der dann das digital dazu gebracht hat, neue Überlegungen zu müssen, was wir dann jetzt machen mit anderen Systemlandschaften. Und dann gab es verschiedene Strömungen. Das eine war die Top-down-Strömung, die sich ganz vor mal angucken musste, wie geht es jetzt weiter, welches Kist gibt es dann überhaupt auf dem Markt, wenn welche Richtung wollen wir ausschreiben. Und dann gab es die Bottom-up-Strömung, die aus dem Forschungsbereich haben in der IT, also wir haben eine eigene Forschungs- und Analyseabteilung in der IT, die sich dann damit auseinander gesetzt hat. Was machen wir denn, wenn wir gar nicht von den Applikationen kommen wollen, sondern von den Daten. Also sprich wir hatten ein bisschen den Standgrund, dass wir eigentlich uns keine Lösungen für unsere Probleme einkaufen können, sondern dass selber lösen müssen und zwar ausgehen von da. Gute Ansatz, genau. 

Das reift langsam auch in den anderen Häusern. Das, wenn man die ganzen Daten dokumentiert, erfasst, dass man die natürlich dann auch für seine Zwecke eigentlich nutzen sollen könnte. 

Das heißt okay, das war sozusagen der Weggrund, dass da auch die Forschung stärker eingebunden ist und was ist dann rausgekommen. Du wolltest ja ein bisschen weiter ausholen. Wie sieht dann jetzt die Digitalisierungsstrategie aus? Also die Forschung meint ich nicht, dass das mit sich so vorstellt, wir machen Statistiken mit unseren Daten, sondern wirklich wie Forschen auch um die Daten selbst herum. Also sprich wir haben zum Spindelter, wir haben das aufgebaut in dieser Forschungsabteilung. Darum ging es eher in der Digitalisierungsstrategie selbst, stehen Schlaudingen, denn wie das Digital kompetent sein wollen, dass wir die Daten hoheit haben wollen, über unsere Daten, unsere Mitarbeiter Mitarbeiterinnen auch unterstützen wollen, mit Digitalisierten Prozessionen, automatisierten Prozessionen und auch, dass das wohl der Patienten damit werden wollen. So in der Nacht schauen, sind einige der Kanos haben wir Digitalisierungsstrategie, auch dass wir Partnerschaften eingehen wollen, Innovationen, die schaffen wollen, fördern wollen und auch das Wort statt form steht da irgendwo sehr lose formuliert auch mitten. Und was wir dann im Zugen von dieser Station, das hat man bottom-up-Forschungslastigenstrategie gemacht haben, ist uns ausgehend von der Digitalisierungsstrategie zu überlegen, bekannte dann so eine Architektur aussehen, die Digitalisierungsstrategie mit der Spiegelton-Operationalisierung. Wir haben da ein bisschen die Brainstorm und das rausgekommen ist letztendlich, dass wir uns vorgestellt haben, dass wir einen zentrales Data Repository haben, das ist weil die Kernkomponent ist, in der alle Daten drin sitzen, dort zentral abgespeichert sind und von den Abtikationen, das hat man bespielt werden und bzw. Die Abtikationen auf ihre Daten aus diesem Repository beziehen. Das heißt, das war der erste zentrale Kernpunkt und der zweite zentrale Kernpunkt, weil wir wollten einen Metadatenkatalog, weil wir wollten ein zentrales Element, in dem alle Daten-Element, die bei uns verwendet werden, ruptural und semantisch ausdefiniert sind, die seit Metadatenkatalog sollte, die Definition vorgeben, sowohl für die Applikationen als auch für das Daten-Repository, also allem faszinend komplette Definitionen sein muss. 

Klingt einfach, ne? Ja, das… Nee, klingt nicht, weiß ich nicht, klingt nach einer krassen Aufgabe, muss ich sagen. Wir haben jetzt ja viele Zuerinnen und Zuerinnen, die jetzt nicht täglich genau mit diesen Dingen umgehen. Deswegen fast sich das manchmal noch mal gar nicht besser zusammen, sondern einfach mit anderen Worten. In der offenen, dass es damit man zweimal hat, vielleicht klarer wird. Ihr wollt in Zukunft, also sowas wie Clinical Data Repository einsetzen, haben wir auch schon eine eigene Folge dazu gemacht, wo dann tatsächlich die medizinischen Daten weiter gespeichert werden, von allen Systemen, die dann auch medizinisch weiter relevant sind, also irgendwie eine vergangenen Personal-Einsatzplanung oder sowas die gehört dann natürlich nicht rein, sondern nur das, worauf man später medizinisch dann auch noch analysen oder Auswertungen oder Entscheidungen trifft, dass das eine, das heißt, wo die Bewegungsdaten, so nennt man das sozusagen drin, sind welche Diagnosen, welche befunde, welche Operationen etc. Und das zweite ist, du hast es gerade gesagt, Data Dictionary, oder yes, wie welche bekomme ich mit, was du beglutzte Metadatenkatalog genau. Das eine CDR sind da eben die Bewegungsdaten und das andere Metadatenkatalog wird beschrieben, was es überhaupt für Informationen gibt, in welcher Form, und so, dass alle Systeme sich dann halten können, und ich glaube, der Klassiker ist da immer der Blutdruck oder, dass da einem Metadatenkatalog drinsteht, also es gibt einen Blutdruck und der besteht aus einer Systhole, eine Diastole, vom Yersgrenzwerte oben unten, klassischerweise in Millimeter Quecksilbersäule über Säule oder sowas gemessen und so ist dann klar, was es für Daten bei euch in Basel überhaupt gibt und wie die Strukturiert sind. Diese beiden Sachen, wo ihr zentral haben, das heißt, jetzt normierte Daten und ihr habt die Aller an einer Stelle und seitlich angewiesen hat darauf, dass ihr das vom Hersteller an vier, fünf unterschiedlichen Systemen zusammensuchen lassen, müsst, wenn ihr immer auf die da anzugreifen wollt. Ganz genau. 

Sehr cool, ich glaube, so da gezinnen, so sollte man und so, muss man das eigentlich machen, wenn man größeres Hauses und sich mit der Digitalisierungsstrategie beschäftigt. 

Ist jetzt aber auch ein Paradigmenwechsel, ich erinnere mich, als du die Folie gezeigt hast in Berlin auf der DMEA dieses Architekturbild. Da war in der Mitte dieses CDR, also diese eine Datenhaltung, wo man alle relevanten Daten drin sind und dann gab es oben unterschiedliche Babbles, die dann Daten entweder da einspeichert oder rausnehmen und der Stand nehmen im PDMS und einem Archiv oder etwas, was ich was stand da auch, das Kiss und der ging ein kleines Raunen und durch das Plenum, weil das ja ein bisschen entmachtet sozusagen, magst du dazu was sagen. 

Entmachten, ja, insofern, als dass wir in unsere Vision, den Kiss ein bisschen die Möglichkeit wecken nehmen, die Daten Geisel zu halten. Also sprich, ein Kiss darf nicht mehr, dadurch in allerlei Stil aus Merkmal halten, dass es die Daten irgendwie in der Black Box unter Verschluss hält und man nur mit viel bitte, bitte, bitte dann ankommt, wenn überhaupt, sondern dass es sich einzurahen hat in alle anderen Applikationen. Also sprich, die Daten ins CDR, ins Clinical Data Repository abspalliert und daraus wieder zieht. Das heißt aber, dass ein Kiss sich dann durch andere Dinge herforderen sollte, wie zum Beispiel eine besonders gute Benutzeroberfläche oder besonders gute Ansichten, besonders guten, weiß es nicht darstellung der Workflow, der Prozesse dann in der Gene, also der, wie sich es sagen, die Datenhoheit und das Kiss ändert sich. Oder kann man gleich, glaube ich, auch da mal dazu, wenn dir das ausschreibt, wird das genau so auch mit drin stehen. Also das heißt, es wird wahrscheinlich Anforderungen geben, die genau das vorgeben, dann ist natürlich auch die direkte Frage, gibt dir auch vor, weil ein Kiss selber dann diese Daten, die dann sozusagen auch ein CDR sind selber speichend darf oder ist das euch eigentlich egal, Hauptsache, die Daten landen auch dort. Also wird es eine Redutanz geben? Das ist tatsächlich noch nicht ausformuliert, also wir sind momentan in Ausschreibungsprozesse selbst, auf der Demeer in der April war, so kann noch nicht klein, welche Richtungen wir ausschreiben, das hat sich mittlerweile gelöst, also wir werden die Richtungen auf eine Plattform ausschreiben, das wird teilweise eine Ausschreibung sein, dann erfreulicherweise, welche Anforderungen da jetzt konkret drin stehen, ist momentan tatsächlich in einem Workflow, von der Idee her wird es vielleicht erlaubt sein oder kann es erlaubt sein, das sind Kiss eine eigene Datenheit. Wenn es, sagt man zum Beispiel, der Performance stehend, aber es sollte, alle Daten sollten trotzdem in Realtime im Data Repository sein. Also sprich, dass Data Repository sollte nicht eine Kopie oder eine Spiegelung sein, die alle 24 Stunden abgedeitet wird, von der Eigenkistathalterung, also dem, in Realtime, die Daten dort vorhanden sein, damit sie im anderen Applikationen bezogen werden. Und ich meine, es ist ja nirge, eben nicht die einzige klinisch-medizinisch genutzt Applikation im Spital, sondern die Daten sollten eben trotzdem, zu jedem Zeitpunkt, wenn in anderen Leuten im richtigen Formal zur Verfügung stehen. Dass ich persönlich sehr sehr cool finde, ist das wirklich mit unserem bottom-up-approage aus der Forschung, das geschafft haben, eine komplette Kissauschreibung in einem Universitätschgeteil zu beeinflussen. Also wir sind eben aus dieser Scheinforschungsgruppe mit relativ wenig Zeit, haben wir uns sehr intensiv mit dem Thema, aus dem Datenplattformen, und haben das eben geschafft, das bis zur Verwaltungsrat vorzubringen, in der Ende die Entscheidung getroffen hat, und sich eben auch beeinschossen hat, lassen sich das guter Komplettrum zu reißen, von Beschreiben im Monolithen aus zu beschreiben, wenn wir auf eine Datenplattform aus. Und das finde ich es wirklich sehr sehr cool. Ja, Verwaltungsrat in Deutschland ist der Aufsichtsrat, glaube ich, ich glaube schon, da sind die Begriffe ein bisschen unterschiedlich. 

Macht ihr da Vorgaben zur Plattform? Also was da genutzt werden soll, openEHR, beispielsweise hatten wir auch schon, das heißt es gibt unterschiedliche CDR auf dem Markt, sind die mitteil der Ausschreibung, oder gibt ihr vor welches CDR genutzt wird? Und falls es openEHR bei sehr, das vielleicht magst du dazu kurz auch was sagen. 

Wir haben uns noch nicht entschieden, ob ihr Plattformen und Kids getrennen ausschreiben sollen oder eben ein Kids mit Plattformen, aber der openEHR Standard wird ein Teil der Ausschreibung sein, der wahrscheinlich ist wir sagen können wir wollen, dass das CDR Openair spricht und natürlich auch FHIR in irgendeiner Form muss Teil der Ausschreibung sein, weil eben doch viel Freier. Wir hatten es in Berlin auch kurz, aber ich nehme Markt einfach so viel Schwierigkeiten, war die beiden Begriffe gelingen und abzugrenzten. Hast du da irgendwie eine kurze pragmatische Abgrenzung, wo der Unterschied von FHIR zu openEHR ist? Ja, das ist der Pudels Kern, oder? Mir wird viel diskutiert, wird teilweise offiziell diskutiert, ja, letztendlich sind es, würde ich sagen, das verstandert sie sich gut ergänzen. Wenn man sich das Entwicklungsgeschichtlich ankommt, dann dient oder wurde FHIR eigentlich optimiert dafür, um eine Kommunikationsstanda zu sein, also sprich Daten austausch zwischen Applikationen und openEHR ein Daten-Persystem Standard, also wirklich zur langfristigen Speicherung von Patienten centrierten Daten. Ein zweiter Punkt, den ich irgendwie noch sehr handlich finde, ist openEHR-Comform Maximal Data Set Approach, also versucht wirklich in einem Konzept alle Daten, oder alle Aspekte, die relevant sein könnten für ein clinisches Konzept abzudecken, sodass ich mir die dann nur noch zusammenstreichen brauche für Mein Use Case, wohingegen FHIR eher so ein bisschen aus der so wenig wie möglich, so viel wie nötig Richtung kommen, also erst mal versucht den Kern abzudecken. Und dann über Extensions noch weitere Aspekte, die vielleicht gebraucht werden könnten, dann noch zulässt. Genau, also das heißt ganz konkret, wenn man das, wenn man es genauso einsetzen würde, könnte man sagen, dann nutzt vielleicht openEHR zur Daten-Persistierung, also zur Speicherung, eben in dem Kliniker Data Repository, so würde dann so eine Produktkategorie heißen. Und die Kommunikation erfolgt dann über einen klassischen Kommunikationsstandard, standard wie FHIR und da werden eben z. B. Nur Teile von dieser Daten Spezifikation von openEHR betragen, also von mir ist, wenn wir beim Blutdruck bleiben, dann sind dann noch 17 andere Attribute in openEHR drin, aber standardmäßig wird. Über FHIR, dann eben werden nur sechs übertragen, die nämlich in 0,80% der Nachrichten dann noch tatsächlich relevant sind, wenn man mehr machen möchte, dann macht man erweit. Sehr gut, wunderbar, genau so ist auch mein Verständnis und vielleicht haben wir da ein bisschen für Transparenz im Markt gesorgt. Ok, das heißt, ihr setzt auf openEHR und das ist auch das, was von gesagt, bis jetzt glaube ich, über einen Jahr, beim Unispital in Basel, genau mit openEHR, hast du dich glaube ich da auch beschäftigt. Magst du da noch einen kurzen Erfahrungsbericht abgeben, wie ihr es damit zu arbeiten, wir haben von gehört oder gesagt, das ist sozusagen die medizinischen Daten ja eine eigentlich eher maximale Definition aufgeführt werden sollen, was hast du da das geschafft, in dem einen Jahr und wie aufwendig ist es so? Ja, sehr gern, also nochmal von meinem Hintergrund, ich bin erz, dann wir haben uns eben Rahmen von dem, wie gehen wir mit unseren Daten um. Beschäftig, was gibt es Verstandards, sondern ist eben relativ schnell openEHR und FHIR vorgestochen, und dann wir haben versucht einen kleinen Use Case als Proof of Concept umzusetzen. Und da bin ich mit openEHR relativ schnell relativ weit gekommen, also hat das Gefühl, ok, es ist intuitiv für mich als Klinikerin, ich verstehe, was in diesen Konzepten drin ist, ich kann damit arbeiten. Natürlich muss man sich ein bisschen einladen, sind auch in die, wo es die zur Verfügung gibt und bei FHIR werde ich relativ schnell meine Grenzen bestorzen, vielleicht so als Hintergrund nach dazu. openEHR, genau das Archetyper, das sind zu, die ich damit die klinischen Wissensblack- oder Bausteine, die in openEHR verwendet werden. Ich bin eben ein Konzept ab mit allen Aspekten, die dann in den Datenlementen widerspiegelt werden und ich fand sehr intuitiv damit zu arbeiten. Also, wie du eben sagst, die Blutdruck, ich kippings bei Beispiel, es ist eben nicht nur der Messwert und Neune, sondern es ist eben dabei, wo wurde der denn gemessen und in welchem Zustand war der Patient und mit welchen Gerät und es gibt auch irgendwie ein Schlagnuck für den miterinaterien Druck zum Beispiel. Wenn ich mir das als Ärztin durchlese, denke ich mir so, ja, cooler hat sich jemand was dabei gedacht. Also, ich kenne mich irgendwie wieder von der Denkweise hin. Die Toe ist, die es zu Verfügung gibt, sind zum Teil Open-Source, wie das was Open-Source, das ist auch relativ schnell aufzusetzen und wenn es dann uns eingemacht ist, kann man auch mit Open-Source Lösungen machen. Wir haben uns dann aber schön für einen kommerziellen in Witte-Entschiedungen, um den Konzept einen Schnau umsetzen zu können und auch da, das ging alles relativ flott. Wir haben innerhalb von den wirklich drei Monaten, wir haben von September bis Dezember, seit eigentlich nur zwei und einnachten, eine Schulung gehabt, das Data Repository aufgesetzt, die Use-Cases Modeling, die ja getestet und quasi für gut befunden. Dann ist die spannend, welche und wie viele Use-Cases. Also, was habt ihr da geschafft in drei Monaten? Es war eine Einrufe auf Konzept mit, ich sag mal, wir haben so unterteilt in drei Use-Cases, also das eine war, wir wollten die Daten erfassen auf eine strukturierte Art und Beise und möglichst Intuitive. Wir wollten die Daten an einer zweiten Stelle dann wieder aus dem Data Repository ziehen und weiter verwenden. Okay, das heißt, bei Punkt 1 erfasste sie auch direkt den CDR, nicht in einer Mannasystem. Ja, können wir. Und das zweite ist dann eben, dass das im CDR bespeicherte, dann später weiter zu verwenden. Es wäre eben das, wo jetzt heutzutage klassischerweise copypaste verwendet werden würde, weil es aber keine Kommunikation gibt zwischen den Abliekationen. Sonst dann, okay, wir haben jetzt hier ein anderes Formular, eine andere Umgebung, und wir wollen hier die Daten, die davor eingegeben worden und wieder weiter verwenden, und sich mal machen. Zum Beispiel haben wir einen reichen mit neuen Informationen. Und das dritte war, dass wir das dann auch ein Sekundäre, als wir weiter leiten wollen, jetzt ganz konkret bei uns, das Schweizer Krebs-Riestar hat ganz konkrete Anforderungen für Daten-Elemente dies haben möchte. Und wir wollten die eben dann bestandseitender zu den weiterleiten können und das dann eben auch auf FHIR gemappt, weil das Schweizer Krebs-Riestar hat. Perfekt, das heißt, die habt ihr irgendwie, du hast jetzt sozusagen die Prozesse beschrieben und inheilig wird es dann offenbar um das oncologisches Gerdere sein. Genau, das war das Tumorboard für einem Formel. Also Tumorboard interdiszipliniert einen Fallkonzert bei uns, wo Patientinnen und Patientinnen mit Krebserkarkungen in dem Fall in Formelkrankungen wochen werden. Hodgkin und Hodgkin sind zurück. – Ganz genau. – Okay, ja schön. Und das heißt, du hast dich direkt wie wieder gefunden und du hast dich in dem Proof-Of-Concept habt ihr erstmal die Sachen installiert. 

Hast du dann definiert, hast du die zusammengestellt, gibt es da irgendwie sowas, wie Zwingker Zwingker schon irgendwo was öffentliches, wo man drauf zurückgreifen kann und ich überher auf der grünen Wiese bei 0 anfängt, weil das ist ja dann die große Gefahr von solchen Standards. Also es ist technisch möglich, es ist ein Standards zu machen, aber jeder baut sich seinen eigenen Standards und haben wir eine halbe Million Milliarden Standards. Wie ist da das konkrete Folge? – Genau, Zwingker Zwingker, es gibt den sogenannten Clinical Knowledge Manager, das ist die öffentliche internationale Bibliothek von Archetypen von openEHR und jeder Modenierungsschritt fängt eigentlich dort an. Also sprich, ein Schritt vorher, ich überleg mir was wir nicht machen, was wir nicht abbilden und dann schaue ich mir was, schaue ich mir an, was gibt es dort. Und da muss man natürlich erstmal ein bisschen einlesen, wo es auch verstehen, wie diese andere Typen zu funktionieren, so ein bisschen vom Konzept her jetzt gar nicht technisch, sondern wirklich wie sind die gedacht. Und das heißt, dort schaut man dann was gibt es schon, findet in der Regel auch schon einiges. Der Clinical Knowledge Manager ist das dann so, als wir ein weltweites Metadaten Repository, was du vorhin gesagt hast? Auf eine gewisse Art und Weise, ja, was vielleicht noch etwas fehlt, ist sind die Werte mängen dort nicht definiert, weil die Eiche Typen müssen ja gerade in einem International Former so allgemein gültig sein, dass sie auch auf verschiedene Use-Catch noch ungepasst werden können. Ich mein so, was wie ein Blutdruck ist relativ, ich sage mal eingestrengt, da ist die Werte nicht besonders groß, aber zum Beispiel den Diagnose hat natürlich super viele Use-Catches, und ich damit unterschiedlichen Werte-Mingen befüllen könnte. Ja, da kommt dann normalerweise das, was wie ein nationaler Terminologie-Server dann ins Spiel, wo dann im Klaas, welche Ausprägungen es geben kann für was, was ich was versichert ein Status. Nee, das ist ja bei Medizin nicht wieder. Aber sowas in der Richtung, ja, also das Klaas, welche ICD-Zellen oder von mir ICD-L oder ICD-9-Diagnosen genutzt werden können. Genau, oder ich möchte ich ICD-Zellen haben, oder dann möchte ich, ich meine, die hat nur so mit Snow-Mitkudieren, oder mit was, wenn man erst noch gibt, dass es dann da in dem Fall teilweise noch nicht spezifiziert, was uns aber hat, sind zum Teil schon eindeutigen Minigweinings. Also sprich, die Daten-Elemente schon mit einem SNOMED-Code verknüpft sind, um eindeutig festzulegen, wobei es sich hier handelt. Also eben ein Blutdruck, es ist tolle, es hat dann das Minigwein zum SNOMED-Code für die Observation Entity für den sistolischen Druck. Genau, und so ergibt das dann eigentlich alles ein Sinn. Wir haben also die Daten von unterschiedlichen System-Central gespeichert, wie die dort gespeichert sind, wird durch Open-R, vorgegeben, durch Open-R, kann auch vorgegeben werden, was es semantisch bedeutet, inhaltlich. Und das Ganze kann man dann austauschen über Fire, gibt es also einen Mapping von den Open-R-Archetypen auf die Fire-Ressourcen, da wo es geht, und da wird dann natürlich entsprechend auch, die das SNOMED-Code mitgegeben. Und dann sind wir da, wo man eigentlich hinwächte, man hat die Daten alle sauber in einem System. Und wie ach so, wie achtet ihr dann drauf, dass die Daten, die ins CDR kommen, alle tatsächlich sauber sind. Also gibt es eigentlich so was, würdest du, was wir eine Vorgabe geben, wie ein Türsteher, der dann sagt, nein, du kommst hier nicht rein, du hast keine sauber-resumantische Annotation oder irgendwie sowas, du bist mir zu viel Fließtext. Wenn nach einem CDR viel Mist drinsteht, dann bringt euch das ja auch wieder nicht viel. Genau, das stimmt. Das kannst du gut im Vorfeld einfrigen, was du also drin haben möchtest. Also, kannst du bestimmt möchtest du jetzt in diesem Element darf doch Fließtext reinkommen oder anmuss das kodierter Text sein und sobald schon kodierten Text, das dann spricht das schon quasi dann, wie soll ich sagen, vorgegeben. Du antwortest jetzt technisch, wobei wenn nachher die Bestrebungen ist, wenn gesagt wird, ne ne, ich das werde ich nicht kodieren. Und dann muss man das ja sozusagen organisatorisch lösen und sagen ne, aber wir freitext über Spracherkennung, das wollen wir da nicht drin haben. Also darum ging es für er, also gibt es da irgendwelche Maßgaben, dass dann saubere Daten sozusagen regnet. Ich muss ganz sicher, ob ich das richtig nicht verstehe. Pim ja auch nicht sicher, ob ich mich richtig verstehe. Die Frage ist, wenn man nachher wird sein, dass CDR nutzen möchte, dass es die einige Single Point of Truth oder wie bei das Länden für saubere Daten ist und dann nachher Auswertung drauf laufen lassen möchte. Dann ist natürlich auch wichtig, dass da tatsächlich gute Daten drin sind im Sinne von strukturiert und semantisch annotiert. Ich kann mir vorstellen, dass man mit diesem herren Ansatz startet und erst mal vielleicht auch nicht so viel Freitext drin haben möchte. Aber das ist vielleicht schwierig, wird das durchzuhalten, weil es dann schon bei der Erfassung der Daten vielleicht gescheitert, weil Menschen im Krankenhaus das vielleicht nicht strukturiert machen möchten und dann sagt man, okay, hier nehme wir akzeptierbar Freitext. Ah und da akzeptieren wir auch Freitext und dann bringt es uns CDR natürlich noch nicht mehr viel, dann hat man es bei die Daten an einer Stelle, aber wenn man die nicht auswerten kann, weil es nicht strukturiert und sementisch annotiert sind, bringt das nicht hier. Das ist so die Sorge, die ich habe, wo es hingehen könnte. Ja, das ist vielleicht zum Teil auch berechtigt. Ich bin da kommen wir wieder so ein bisschen auf den Meter-Laden-Katalog zurück. Was ich im Anfang erwähnt habe, diese Prinzip von ich definier wirklich von Anfang bis Ende, was da einkommt oder wie die Daten auszusehen haben. Das heißt, ich habe eigentlich keine Übersetzung mehr zwischen meiner Frontend, meiner da Eingabe. Also das, was dann irgendwie die User in der Genie zu sehen bekommen und das, was hinten im Data repository landet. Das ist eins zu eins, also sprich, da findet keine Übersetzung mehr statt oder irgendwie umwandlungen in der Form. Das heißt, wenn ich sage, okay, ich habe jetzt hier einen Kommentar fällt, das heißt dann in meinem Data repository auch Kommentar. Oder wie blogtro-Kommentar? Was soll man? Und dann ist das im Frontend auch blogtro-Kommentar. Und so habe ich eine Eins- zur Einzelbindung zwischen dem, was die User vorhin sehen, dann formulieren und dem, was hinten quasi im jeweiligen Datentopf im Data repository landet. 

Wie geht es? Weil es gar nicht so lange haben. 

Wie geht es im Soziale? Ich habe die Erfahrung gemacht, dass es schwierig ist, insbesondere bei deinem Berufsstand zu sagen, du müsst jetzt alle strukturiert, dokumentieren und mich freitext und mir das betextbar steigen. Ja. 

Ja. Das ist glaube ich, ja, den Aspekt, den ich meinte. Ja. 

Das wird ja sagen. Ich glaube, ich glaube es wird mir spielt, die, also ich persönlich glaube es wird mir spielt, die. Ich glaube, man kann überaschen viel strukturierter fassen, gerade wenn man irgendwie das, was früher mal freitext war, elegant und mit Konzept irgendwie in Elemente zerlegt. Und klar wird, ich sag mal, ein Clinical Reasoning, also wenn ich mir als Erzene zur Barliga, warum mache ich ja den nächsten Schritt, das werde ich nicht von freitext kommen, weil wir Menschen arbeiten mit Sprachen, oder? Und zu verstehen, was wir tun und wissen weiter zu gehen, man andere, was ein interessantes Konzept sein könnte, ist, dass du eben den freitext oder den gesprochenen Text zum Beispiel mit Spracherkennung dann in, ja, die strukturieren lässt mit NLP, zum Beispiel nur uns hat, glaube ich, ganz spannende Projekte, vielen anderen zu auch, das dann zu zernlegen und im Hintergrund zu kudieren. Und diese Kudierungen könnte man wieder rum, quasi in einem Archetyp, in den verschiedenen Daten, in einem Hintergrund, in den CDH. Ja, also da, ja, muss man ganz sicher sein, dass man die auch später dann so präsentiert, dass man sagt, das sind keine gesicherten von den Menschen strukturiert eingegeben und da, sondern da ist durchaus, man können Fehler mit da drinnen sein, ich weiß vielleicht falsch erkannt wurde, das sind vielleicht, als Beispiel, also ein Ausschluss von der Diagnose, dann steht die Diagnose hinter die Kraft, dann nicht erkannt werden, als der Mensch hat diese Diagnose. Ja, sehr, sehr spannend, ich fährt das auf jeden Fall beobachten, was ihr da so macht, dann sind wir auch schon bei der, beim zeitlichen Limit, wobei ich sehr gerne mit dir weiter ein bisschen schlauern würde. Ich frage am Ende manchmal, manchmal nicht, welche Frage, ob ich den vergessen dir zu stellen. 

Das ist eine gute Frage, dass mir die Standardreaktion auch ja. Es gerbt sich ja, ich denke, es ist ein sehr weiteres Thema, also einerseits von einer Materie an sich, von vielen solchen Aspekten und auch ganz komplett, was wir gemacht haben, es gab ein paar Dinge, die die zwischen euch sagen wollen, in die Mädchen fallen sind. Ja, macht das jetzt. Genau, was vielleicht noch spannend ist, was wir von so ein bisschen übersprungen haben, ist Archetypen selber bauen. Also zwar angenommen, ich finde, für mein Use Case im Plenicle-Nolage-Manager nicht das, was ich suche, dann kann ich das auch selber bauen, auch das geht relativ einfach. Also da habe ich auch das Gefühl gehabt, für mich, als nicht technische Person oder nicht technisch mein Hintergrund, gibt’s da keine große Hürde. 

Was ganz wichtig ist, bei Open-Air-Genose überfeiern, war schon nicht wie allen anderen Interoperabilitätsstandard. Ich muss mehr als als Unternehmen wirklich gut überlegen, wie setz ich meine Prozesse auf. Wie gehe ich damit um, wenn auch, wenn Open-Air gut dafür geeignet ist, so Wildwuchs zu vermeiden, vermeiden, schafft das auch nicht immer. Also ich muss mir das da wirklich vorsichtig sein, dass da keinen Wildwuchs passiert, bei den Archetypen, genauso wie bei FHIR auch. Also Timmerkaweiner ist ganz, ganz, ganz, ganz wichtig, wie je moduliere ich wie integriere ich, dass wir arbeitig mit den Geniken zusammen. Und das ist vielleicht ein gutes Schlusswort. Genau, wunderbar, dem habe ich nix hinzuzufügen, ganz vielen lieben Dank für das sehr interessante Spannende Gespräche.