Folge #136 – Clinical Data Repository (CDR)

Wir haben uns heute ein besonderes Thema herausgesucht und zwar CDR, das steht für Clinical Data Repository. Und das Ganze ist ein kleines Steckenpferd von Christian, der heute auch dabei ist. Immer mehr Steckenpferde, ne? Leben syntaktisch-semantische Interoperabilität auch CDR? Ja, passt auch ganz gut dazu. Genau, hängt ja mit zusammen. Auf jeden Fall. 

Und wie sieht die Agenda heute aus? Also erst mal klären wir ein paar Begriffe, dann gucken wir uns noch mal rückblickend, die Architektur im KIS an alle, die diesen Podcast langwierig verfolgen. Die werden da ein paar Minuten überspringen können. Dann gucken wir uns die Aufgaben an, der ein solches CDR haben kann. Wir grenzen das Ganze ab von anderen Technologien und dann gehen wir ins technische, bevor wir uns mit den Vor- und Nachteilen beschäftigen. Und dann ganz am Ende wird es ganz praktisch, wie kann man ganz konkret vorgehen? Wenn man vor hat, ein solches CDR einzuführen? Vielleicht doch. Ich glaube ein paar Minuten brauchst du nicht für die unterschiedlichen KISarchitekturen. Und ich bin mir auch nicht sicher, weil das schon intensiv besprochen haben. Doch, monolithisch. West of breed hatten wir bestimmt schon. Wenn nicht, dann müssen wir das auf jeden Fall in einem der folgenden Podcasten machen, weil das ist ja ein ganz zentrales Thema, der Medizinischen Informatik. Ich recherchiere nachher, wenn wir mit dem Podcast so leicht sind. Sagen die anderen Podcasts da doch auch immer, die hätten eine Liste von Themen, die man noch machen will oder nachprüfen und wenn wir ehrlich sind, haben wir das nicht. Doch, haben wir. Haben wir. Okay, haben wir. Begriffe. Beginnen wir mit Begriffen CDR, nicht CDA, CDR, aber Clinical Document Architecture. Das hat man definitiv schon. CDR mit R am Ende, wie geht es, bildet euch mal, R steht für Richard. Richard. Klinik-Data Repository wie Richard, CDR. Es gibt ganz viele andere Abkürzungen und ähnliche Produkte und Produktnahmen. Von daher möchte ich jetzt hier einigen nennen. Ich, das übrigens vielleicht so viel vorweg, da ist ein Podcast, wo ich mich sehr schwer zu die richtige Flughöhe zu finden, weil es einige Experten gibt in diesem Bereich und die vermutlich auch diesen Podcast dazu hören werden und werden immer wieder an der Einstelle sagen, ja, aber das ist ja nicht ganz so richtig, was der Wache da gesagt hat. Und das kann dann entweder ein richtiger Fehler sein oder aber ich wollte nicht tiefer abtauchen. Von daher seht’s mir nach. Aber dafür haben wir die so selten genutzten Kommentarfunktionen in unserem Podcast. Also, falls dann wirklich etwas sein sollte, was ich mich nicht vorstellen kann, was Christian vergessen haben sollte oder falsch dargestellt haben sollte, gibt es uns entweder auf Twitter oder auf der Webseite. Ja, oder genau. Beschimpft mich auf Twitter das krieg ich schon damit. Also CDR ähnliche Produkte, ähnliche Begriffe. Es gibt so was wie HCM, dass es ein Begriff dazu gibt es auch Bücher, Healthcare Content Management hat man glaube ich sogar auch als eigenes Thema irgendwann. Es gibt Leute, die nennen eine Funktionalität als Datendrehscheibe, wobei das eigentlich kein schöner Begriff ist, aber das soll ähnliche Funktionalität beschreiben, wobei Datendrehscheibe könnte eigentlich in Kommunikation zu über auch sein. Dann gibt es Leute, die nennen das Universalarchiv, manchen Nenz-No-Archiv, manchen Nenz-Vendor Neutral Archive, also VNA, wenn diese Begriffe vorkommen, die eigentlich auch häufig was ähnliches bedeuten, dann ist es häufig eher so, dass die Speicherung Dokumenten bezogen ist, aber da kommen wir später doch mal dazu. Manchen Nenz einfach Plattform, das ist relativ aufzuführen im Rahmen der Medizin-Informatik-Initiative gibt es sogenannte Datenintegrationszentren, wo in ganz kurz Daten aus unterschiedlichen Kliniken gesammelt werden häufig Indikationsspezifisch, also auch DIZ macht sowas wie das, was wir gleich besprechen werden, aber da ist das, ist dieses DIZ eher eine Funktion im Rahmen der Medizin-Informatik-Initiative als jetzt ein Produkt oder einer Produktgattung. So viel zum einordnen, magst du jetzt deine Minuten erzählen, finde ich sehr unterschiedlichen Architektoren von KISS, genau, es gibt zwei grundsätzliche Strukturen einmal die monolithische Struktur eines KISS oder den Best of Breed Ansatz, die namensagens ja schon so ein bisschen monolithisch heißt Monos oder Mono 1 und Littos der Fels, also ein großer Stein, ein großer Popp. Das ist das nachgeguckt gerade, oder weißt du das wirklich, das weiß ich das, das große Greikum, oder so. Wir haben eine Logie, hab ich ja in meinem Portfolio, also ein großer Procken aus dem das KISS besteht, also ein Anbieter und der versucht möglichst alle Bereiche, die ein KISS so abdecken sollte, auch wirklich abzudecken, Vorteile könnten vielleicht auf der Hand liegen. Ich kann sie aber nochmal kurz nennen, wir haben weniger Schnittstellenprobleme. Wir haben einen Zugriff auf alle Daten, also wir müssen die uns nicht erst mühsam zusammensuchen und vielleicht anpassen und integrieren, sondern die liegen normalerweise in einer Datenbank vor, das macht es dann einfacher bei Abfragen, das macht es einfacher zum Beispiel, wenn man Regelprüfungen macht und so weiter. Und wenn man das jetzt so von der betrieblichen Seite sieht und man denkt, man hat ein System gegenüber zehn System, dann hat man es da mit weniger Ansprechpartnern zu tun, wenn Fehler passieren, kann man die leichter zuordnen und es gibt weniger downtime wegen Updates. Auf der anderen Seite ist dann der Best of Breed Ansatz, da haben wir eine sehr heterogene Landschaft, die Ärztinnen und Ärzte, die Benutzer, das Pflegepersonal, die sind eigentlich immer so ein bisschen für den Best of Breed Ansatz, weil da meistens Produkte da sind, die auf sie zugeschnitten sind. Und das ist ja auch wesentlich einfacher, wenn man nicht alles abdecken muss, sondern sich auf eine kleine Sache spezialisieren und fokussieren kann, dann kann man natürlich viel mehr auf die Benutzer und auf die Anforderungen eingehen. Also Benutzer, die lieben den Best of Breed Ansatz, die IT liebt ihn nicht unbedingt so. Trotzdem gibt es natürlich auch Vorteile für die IT, denn wir haben nicht so die Abhängigkeit von einem einzigen Anbieter, es ist normalerweise auch nicht so, dass die KISanbieter besonderen Druck ausüben, aber man hat doch mehr Einflussmöglichkeiten bei so einem kleinen Anbieter, vielleicht neue Funktionalitäten durchzutrücken oder etwas und ist nicht so abhängig von einem einzelnen Anbieter. Und falls man dann tatsächlich sehr unglücklich sein sollte mit dem Anbieter, dann ist es bei einem Best of Breed Ansatz etwas einfacher zu wechseln. Das waren die beiden Konzepte gegeneinander gestellt, monolithisch gegen Best of Breed Ansatz. Genau, und auch hier wieder, das sind natürlich die beiden Extreme und es wird wahrscheinlich kein Krankenhaus gehen, was absolut monolithisch unterwegs ist und viele die Errichtung Best of Breed unterwegs sind, aber die Grenzen kann man jetzt auch nicht drin schaffen, aber wir ziehen. So, das war ein kleiner Ex-Course in die Architektur eines KIS und hier ist mit KIS dann gemeint alle Informationsverarbeitenden Systeme im Krankenhaus. 

Und du hast gerade einen Punkt gesagt, der total zentral ist, warum ein CDR jetzt bei immer mehr Krankenhäusern tatsächlich angeschafft wird, gucken wir uns also mal die Aufgaben an, eines solchen kliniken Data Read Positories. Es muss, steht so ein bisschen wie so eine Spinne im Spinnetz und so nachher die Daten von unterschiedlichen Systemen zentral entgegennehmen, das heißt von der Position, wenn man sich das in so einer Topologie vorstellt, ist es wahrscheinlich ungefähr da, wo wahrscheinlich auch ein Kommunikations-Server stehen würde. Der Kommunikations-Server leitet die Daten aber in der Regel weiter, verarbeitet sie ein bisschen und das CDR soll diese Daten jetzt aber auch zentral, weil sich selbst speichern. Es soll sicherstellen, dass diese Daten korrekt semantisch annotiert sind, wie das funktionieren kann, kann man gleich dazu, und kurz entweder liefern die Systeme das schon, also zum Beispiel wie die Sachen, die wir uns alle hier auch angeguckt haben, die ganzen Ordnung, Systeme, ICD-P-S, SNOMED CT und so weiter und so weiter, LOINC, LOINC oder aber bei leckes dieses Thema das vielleicht nicht möglich ist, wäre es natürlich gut, wenn man das direkt dort auch im CDR nachtrecklich Regeln definieren kann, sodass diese Daten auch semantisch annotiert werden, sodass wir nachher wirklich im CDR sauberen Daten schatz haben, meinen Schatz. Dann sollen die Daten es nicht einfach nur versenkt werden, sondern wenn wir dann also aus unterschiedlichen Systemen, Daten sauber und semantisch annotiert in einem Produkt haben, dann macht man das ja nicht zum Selbstfax, sondern diese Daten, sondern anderen Benutzerinnen und anderen Programmen auch wieder zur Verfügung gestellt werden. Wenn man das dann hat, dann kann man auch nachher Systemübergreifende Workflows definieren. Das klingt jetzt wieder nach Buzzwordbingo, aber wenn Workflow der IT unterstützte Teil von dem Prozess ist, dann ist es ja häufig schwierig, einen Prozess zu definieren, wenn man dann über Systemgrenzen hinwegarbeiten muss, also Labor und KIS und was weiß ich, was alles. Wenn die Daten jetzt aber alle in einem System zeitnah zusammenkommen, dann kann man das dort eigentlich ganz gut abbilden. Für manche Häuser ist es auch interessant, in CDR einzusetzen, weil sie dann manchmal einfacher Datenschutztechnische Anforderungen umsetzen können, wenn also eine Patient in ein Patientskranken ausverlassen hat, dann werden die einfach bei den Umsystem gesperrt. Man hat nur noch Zugriff über das CDR, weil dort die wichtigen Daten drin sind und auch nur im CDR werden dann die alten Fälle wieder eröffnet. Und je nachdem, ob man das auch als Erhief nutzen möchte, wenn man als Erhief sowas wie eine rechtssichere Archivierung haben möchte, also das Gerichte, die Informationen auch als Beweis anerkennt, dann kann ein CDR, manche dieser Produkte auch sowas übernehmen, grob, also rudimentär häufig. Das ist normalerweise nicht die Stärke von clinical data repositories, weil solche rechtssicher Archivierung häufig immer noch Dokumenten bezogen ist. Bei Datenschutz-Zentralerstelle man besser Rechte verwalten kann als in vielen Umsystemen, wo dann vielleicht sogar noch irgendwelche Umsysteme sind, die eine ganz schlechte Rechteverwaltung haben und man gar nicht so richtig steuern kann, wäre worauf Zugriff. Und wieder öffnen und diese ganzen Geschichten, wenn du das dann zentral machst, es ist gerade wenn du auch legacy, also alte Systeme einsetzt, das ist das manchmal einfacher. Aber wenn du dann gerade das Thema Archivierung anspricht, gibt es clinical data repositories, die so eine Signature Funktion haben, gibt es das schon? Ja, es gibt also auch da, ich werde nachher eine grobe Marktübersicht geben und das grobe Einschätzung auch da habe ich die weißheit nicht nur Löffeln gefressen und es gibt jetzt aktuelle CDRs, die kommen dann eher aus so einer Archivschiene, die haben vor Dokumenten basiert, archiviert, kommen eher aus dem IHAXDS Kontext vielleicht und die haben sowas klassischerweise drin, die Produkte, die eher aus diesem, wir nehmen strukturierte Daten auf, aufnehmen, die haben sowas häufig noch nicht drin. IHAXDS, ich glaube das ist eine super Überleitung zum nächsten Thema, was ist etwa so ein clinical data repositories sowas wie IHAXDS? 

War keine super Überleitung, ich fand es zu sehen, also Abgrenzungen, das vorzusagen. Ein clinical data repository kann natürlich, nachher auch Daten, Informationsobjekte wie Dokumente verwalten, also können die meisten, aber die Datenhaltungsschicht vor einem KIS beispielsweise ist kein CDR, das sagen manche ein bisschen doch sind wir, weil wir legen das alles strukturiert ab, aber der Sinn ist bei einem CDR, dass man eben sich unabhängig macht. Deswegen heißen ja manche auch sowas wie Vender Neutral Archive. Ein CDR ist zu verwechseln mit der Datenhaltungsschicht eines KIS oder eines Kass, ein CDRs kein Metadata Repository, das kennen wir auch aus der Medizin Informatik-Initiative oder auch aus einer Podcastfolge von den ganz frühen, wo es um Forschungsunterstützung geht, in ganz, ganz kurz Metadata Repository wieder krasse Wörter hier, da geht es darum, dass man sozusagen Datenpunkte, Daten Informationsobjekte aus unterschiedlichen Systemen matcht, also das Gewicht bei der Aufnahme ist in diesem einem System hier und das gleiche, die gleiche inhaltliche Informationen steht bei einem anderen System dort. Und abgrenzung, DIZ hat man gerade schon der nächste Abkürzung, Datenintegrationszentrum, das ist das, was ich zu Beginn gesagt habe, das sind also diese Zentren, wo häufig Indikationsspezifisch Daten von den Unikliniker gesammelt werden. 

Wenn wir jetzt uns das angucken, dann vielleicht ganz bis wir was zur Technik, was muss denn so ein kliniker data repository auf technischer Seite haben, dass das nachher auch vernünftig funktioniert? Es muss einfach sehr, sehr viele Schnittstellen unterstützen, muss eine hohe Schnittstellen kompetenz haben, also häufig so viel wie so eine Kommunikation zu erwahl, es muss natürlich da 7V2 hoch und runter spielen können, es muss freier verstehen, es sollte IHAX, der S verstehen von mir aus CDA Level 3 verstehen, alles Sachen, die wir hier im Podcast auch schon behandelt haben. Es muss die Ordnungsystemen unterstützen, auch die haben wir ja im Podcast hoch und runter behandelt, also ICD, OPS, ATC, SnomeCT, Dein Loink und so weiter. Es sollte gerade für leggessive für all Systeme, wo so etwas wie eine SnomeCT-Unterstützung nicht mehr umgesetzt wird, in Möglichkeit bieten im CDR selber, die Daten, die dann zum Beispiel für überall 7V2 reinkommen, dort dann noch semantisch zu annotieren, sodass wir dann eben im CDR wirklich nur schöne da nahmen und keine grausigen und häufig ist es so, dass gibt einige Produkte, die setzen in der Technik, da drunter auf openEHR, openEHR, als Datenhaltungsbasis und auch openEHR, weil glaube ich schon zweimal hier im Podcast besprochen, dort sind dann auch sowas wie medizinische Informationsobjekte oder medizinische Objekte sauber definiert und abgelegt. Das heißt, so etwas sollte dann ein CDR technisch können und häufig haben die dann außen drum noch sogenannte Wrapper, so ein FHIRWrapper beispielsweise, wenn wir also im Kern openEHR haben, drüber um FHIRWrapper dann ist man eigentlich ganz gut bedient technisch, weil dann können wir das machen, was in Deutschland gerade passiert. FHIR hat man ja auch schon mit dem E-Sick oder auch den kassenärzliche Bundesvereinigung Mios, die setzt Deutschland ja ganz stark auf FHIR und deswegen werden die Systeme dahingehend und deswegen soll den CDR auch unter anderem FHIR verstehen, sodass die Daten dort dann sauber einschließen. Glaubst du, das wird klar, dass das jetzt als schon wieder zu technisch oder zu abstrakt, bin mir unsicher, ob der Flughöhe über diesem Thema ist. Ich glaube, dass den Leuten vielleicht die die Abkürzung ein bisschen zu viel werden, vielleicht noch einmal kurz, was openEHRj A so im Kroben ist und dann das vielleicht im Zusammenhang setzen zu FHIR, also was sind die Unterschiede zwischen openEHRj A und FHIR da. Dann können wir wieder eine lange Diskussion auf Twitter anhören und gucken, oder man hört jetzt dir kurz zu. Oh God of God, nee, ja, das glaube ich, also das in zwei Sätzen ist schwierig, weil die Konzepte ist schon auch in Teilen relativ ähnlich, sind openEHR, ist jetzt erstmal prinzipiell eher medizinisch ausgerichtet, d.h. Dort kannst du die Daten eher beschreiben, das macht FHIR natürlich auch, also in FHIR haben wir Ressourcen in openEHR mal die Archetypen, FHIR hat aber gleichzeitig auch so eine Kommunikationskomponente mit dabei und FHIR ist prinzipiell erstmal dazu ausgelegt, dass Daten aus einem System rausgelesen werden, also transformiert werden, übermittelt werden und ein anderes System wieder reingespeichert werden. Das ist so grob, das wo FHIR her kommen, also als Kommunikationsstand an. openEHR ist eher als universelle Datenbasis gedacht, wo Länder beispielsweise einfach sagen unsere KIS und von mir ist auch die Arztpraxis-Systeme basieren auf openEHR, haben also eine ähnliche Datenhaltung und wenn wir dann Daten austauschen, dann müssen wir eben nicht mehr transformieren, also vom Ursprungssystem transformieren, rüber schubsen Daten und im Zielsystem auch wieder transformieren und reinspeichen. Also da kommt das ein bisschen her, aber natürlich gibt es ja schon auch viele Bereiche, die sich überdecken und die sich überlappen. Okay, man könnt ja ganz provokant fragen, warum muss man sich überhaupt Gedanken drüber machen, wie jetzt die einzelnen Systeme ihre Daten speichern. Das hat man bisher hier auch nicht gemacht und es hat einigermaßen funktioniert, geht ja wirklich primär um den Austausch, aber das ist ja das Interessante bei openEHR scha, dass die Idee haben, wenn alle das gleich abspeichern, dann wird es später auch noch mal einfacher die Sachen austauschen, wenn ich das so richtig verstanden habe. Ihr dann braucht es dann nicht mehr transformieren, also du musst hier die Daten aus dem Einsystem hier zusammenklauben in ein definiertes Format, egal ob es jetzt hal 7v2 da FHIR ist, muss die irgendwo übertragen und muss sie dann wieder in eine ganz andere Systeme aus auseinander klamüsern. Und da können natürlich Fehler passieren und auch die Datenhaltung selber in einem proprietären System führt ja auch dazu, dass man häufig nicht an die Daten dran kommt. Das sind mich dann gleich auch die Vorteile, das habe ich mir selber unbewusst die Überleitung zu den Vorteilen von so einem CDR gebaut, wenn nämlich, aber das heißt auch noch eine kurze frage Entschuldigung, das heißt aber wenn wir von CDR sprechen, dann reden wir nicht automatisch von OpenEHA, sondern es gibt einige CDRs, die das implementieren und ihre Daten in OpenEHA halten und einige die machen das nicht, die halten sich dann einfach nur an die gängigen Standards, an die Schnittstellen Standards, FHIR hal 7 und so weiter. Genau, also vielleicht noch ein Tipp für die Profis, wenn ihr als Experte auftreten wollt, nennt’s OpenEHA, ja, es spricht ein bisschen aus wie offene Luft, auch wenn’s OpenEHA geschrieben wird. Es gibt einige Produkte, die basieren auf OpenEHA, richtig, andere, die sozusagen bestehende Produkte einfach dazu umgewandelt haben, haben dann natürlich einen anderen Kern. Es gibt auch welche die Arbeit in internen, eher mit den FHIR-Ressourcen und es gibt welche die am proprietären Lösungen. Wichtig ist, dass man hier später an die Daten sauber rankommt und dass man dort nichts zu sagen, auf Gutwill von einem KIShersteller beispielsweise angewiesen ist. Generell, wenn ich sowas vorstelle, auch bei Geschäftsführern, dann sage ich immer, Daten sind wichtig und eigentlich sollte man es Krankenhaus jetzt schon sich überlegen, wenn wir sowas anbinden wollen, wie im Krankenhaus zukunftsgesetz gefordert, Patientin, Patientin, wenn wir Rettungsdienste anbinden wollen, wenn wir nachher Reha-Einrichtung anbinden wollen, etc. Wenn wir Daten vom Patienten nämlich solche Smartwatches Fitness-Tracker mit reinladen wollen, wenn wir KI’s auf eine möglichst komplette Daten basizlos lassen wollen, dann wäre es sehr geschickt, wenn das auch klappt ohne viel Theater. Das ist so die ganz here Idee in dem Intemps-CDR, also Vorteile sind. 

Die Krankenhäuser können sich ein bisschen von den Primärsystemherstellern entkoppeln. Das heißt, sie sind nicht mehr so auf die Bereitschaft angewiesen, zum Beispiel der KIShersteller Schrittstellen zu anderen Systemen anzubieten. Die Hoffnung ist, dass die Daten heute wieder ein bisschen mehr bei dem Krankenhaus und Patientin-Patienten liegt, gerade schon gesagt, man kann damit häufig auch nahrträglich oder von Legacy-Systemen, semantische Annotationen mit reinbringen. Hat, wenn man es richtig spielt, eine redundante Datenbasis, hilfreich, wenn man ein System ausfällt, also ein KIS-Liss-Riss-PDMS, was was ich was, oder aber auch, wenn man ein System austauschen möchte, tatsächlich. Also, wenn man mit dem vielleicht der monolitischen Systemhersteller nicht zufrieden ist und der sagt, müsst ihr machen, weil sonst geben wir euch die Altdaten nicht raus oder kostet so und so viel, dann ist das natürlich hilfreich oder auch, wenn das Systemer abgekündigt werden. Man spart sich über sie die Altdaten übernahme. Ja, aber das Problem ist generell, was ich auch bei CDR immer habe, wenn man das erst mal erzählt, was das alles so können soll und was es für Funktionen hat, dann vergaluppieren sich da viele Leute total. Das heißt, dann ist nachher, geht alles nur noch über den CDR und damit kann man dann alles lösen, egal, welches Problem man hat, weil man einfach erstens das noch nicht richtig kennt und wenn man, wenn man das noch nicht kennt, dann projekiert man einfach sehr viel Wünsche rein. Das ist ein und weil man völlig außer Acht lässt, dass die ganzen Vorteile, die ich bisher genannt habe und ich gleich noch ein bisschen weiter nennen werde, die sind natürlich nicht kostenlos. Das Produkt selber kostet Geld ganz gut sogar und es ist natürlich auch ein super Aufwand, wenn man nachher wirklich saubere Daten drin haben möchte. Das ist ein super, super große Aufwand. Aber wenn man das hat, dann haben wir nachher hoffentlich eine medizinisch vollständige Datenbasis, wo dann Daten aus ambulanzsystemen drin sind, wo dann Daten aus dem KISlist, was ich, was alles drin ist. So, ich glaube ich, jetzt könnte jemand sagen, ja, aber das hast du ja auch, wenn du ein monolithisches System hast. Ja, aber ein ganz monolithisches System hat man normalerweise auch nicht, Punkt 1 und Punkt 2, diese monolithischen Systeme sind, wenn wir ehrlich sind, hier auch keine Systeme, die irgendwann mal auf der grünen Wiese konzipiert worden sind, eine mega saubere Datenhaltung haben, sondern auch da wurden dann Produkte zugekauft und irgendwie mehr oder weniger krude teilweise angeflanscht. Aber wenn man so eine medizinische saubere Datenbasis hat, dann kann man nachher die Sachen machen, wie z. B. Auch in der Medizininformatik, Initiative genutzt, wenn man kann forschen, man kann eher eine KI drauflassen, etc. 

Ich habe ja vorhin diesen Best-of-Breed-Ansatz genannt und den kann man ja hier dann bis in Nächsten so treiben, also wenn sich diese CDRs durchsetzen sollten, dann könnten ja kleinere Unternehmen diese Datenbasis nutzen und dann irgendeinen Mehrwert bieten. Jetzt Jetzt nicht für, wie gesagt mal, das große Thema Abbrechnungen, sondern für irgendwas kleines zum Beispiel, irgendwas kleines in der Kardiologie oder Transportdienst oder irgendeine kleine Applikation. 

Und wenn ich dich nicht hätte, genau, ganz genau das ist es, also das heißt, das wird auf der einen Seite natürlich auch erleichtert durch FHIR mit den definierten Daten unter definierten AP. Aber teilweise gibt es da ja auch von den Primärsystemherstellern sozusagen Geschäftsmodelle, die so was unterbinden wollen. Die dann sagen, ja, ja, kauft du das mal nicht bei dem kleinen Start-up, sondern das machen wir selber in drei Jahren und dann ist das viel besser. Wenn man die Daten aber in so einem CDR hat, also wirklich unabhängig, dann kann man natürlich ja ja sagen, nee, wir haben eine Datenbasis, da kannst du mit FHIR drauf zugreifen und dann ab dafür. Ja, das heißt, das, was ich von meinte, dann muss man hier das mal beim Quizhersteller anklopfen und fragen, ob das den auch geht. Und, klar, ich könnte mir vorstellen, dass große Uniklinikade, so vielleicht ihre eigenen IT-Abteilungen haben und dann eigene kleine Applikationen schreiben auf dieser Datenbasis. Darfteile vorhin schon gesagt, das heißt, sind viele Vorteile, haben aber auch einen hohen Preis. Wir haben ein weiteres IT-System. Man muss normalerweise Lizenzen zahlen. Glamour auf. Ja, es gibt sowas wie EHR-Base oder EHRbase, was ein Open Source-Produkt ist, aber das wird wahrscheinlich keiner ohne Dienstleistung selber betreiben können und dann das Ganze in Mapping, etc. Machen können. Man muss also Wartung zahlen, muss Lizenzen zahlen, man muss Schrittstellen ja trotzdem kaufen und trotzdem am Quizhersteller anfragen. Gips du mir bitte, die da an das Ganze ist, also aufwand, man braucht noch mehr Fachwissen bei den Mitarbeiterinnen und Mitarbeitern, was gerade so das große Problem ist, also richtig Fähige Mitarbeiterinnen und Mitarbeitern zu finden und auch, dass diese Nutzen oder die Vorteile ich von genannt habe. Die gibt es natürlich erst nach einiger Zeit. Das ist auch viel nicht klar, sondern die ersten zwei, drei Jahre wird das Ganze in den meisten Fällen erstmal Geld fressen und Zeit fressen und es bringt erst mal nicht so wahnsinnig viel. Im Wiki, wenn man Wiki startet, sollte man schon ordentlich was rein gefüttert haben, wenn man dann das publiziert, weil dann sonst gucken hier Leute zwei mal rein und wenn er nur ein leeres Wiki ist, gucken die nie wieder rein, ist beim CDR vermutlich auch so, wenn man es installieren und noch gar nichts drin ist, aber man sagt hier, lieber benutze. Hier gibt es uns CDR, schaut mal rein und da keine da anderen sind es das eher umgeschickt. Das wärts tatsächlich wieder in Überleitung zum letzten Punkt, oder? Ich bin heute die Überleitung, die Weltmeister. Weltmeister. Genau, deswegen ist so ein mögliches Vorgehen, es ist natürlich kein Vorschlag und gar nix, aber ganz wichtig ist, dass falls ihr jetzt da, falls wir euch damit jetzt angeticket haben, sich tatsächlich vorzubelegen, was sind unsere wirklichen Anforderungen, was brauchen, wir wirklich und da dann sowas wie Investitionssicherheit, zur berücksichtigen Ausfallssicherheit, etc. Würden, wenn die meisten das wahrscheinlich ausschreiben müssen und dann ganz wichtig sollte man auch überlegen, und das ist auch wieder keine IT-Aufgabe, welche medizinischen Informationen denn in, da gibt es mir wieder zurarbeit von der IT, in welchem Format gespeichert werden sollen. Also wie die medizinischen Informationsobjekte nachher aussehen und bitte speichert mich da einfach PDF-Dateien rein, dann braucht es sowas nicht. Wenn das alles klar ist, dann wäre so die erste große Phase, Daten zu sammeln und von mir es mitzuschneiden, kann natürlich aus den Kommunikationsserber anzapfen und alles, was rein geht theoretisch rauspusten, wenn das Lizenz rechtlich erlaubt ist. 

Könnte man da vielleicht vorgehen, dass man erst mal einen kleinen Datensatz nimmt, dass man vielleicht erst mal nur Abrechnungsdaten nimmt oder nur Vitalparameter oder irgendwie sich darauf fokussiert und erst dann weiter ausbaut oder sollte man am besten den großen Wurf machen. Also es kommt auf an, wenn du in Uniklinikum bist und hast, vor allem sind 4 Ressourcen, kann man das natürlich machen. Ansonsten schlag ich fast eher vor, dass du die essentiellen Sachen, die auch schon sauberisch und sauberische Annotationen überwalt haben, dass man das vielleicht mit rein nimmt. Also Deklassiker natürlich, Medikamente natürlich Diagnosen, von mir ist auch noch die Befunde dann als Text, aber nicht als PDF-Datei, sich vielleicht in dem Zusammenhang auch im Rahmen des KZG zu überlegen, vielleicht machen wir tatsächlich eine Klinikweite an am Lese und packen die dann da auch schon mit rein, so in die Richtung geht es her. Und dann immer, wenn man neue Schnittstellen anflanscht im System generell, nicht nur im CDR, sondern darauf achtet, dass es wirklich alles sauber ist und entsprechend dann auch da mit rein speichert. Oder viele Krankenhäuser rüsten jetzt ihre Labor-Schnittstelle nach über tatsächlich eine tiefe Integration und auch über LOINC, was du für ein gesagt hast, wenn man das sowieso macht, dann sollte man auch immer noch mal ein paar Tage drauf rechnen und dann das entsprechend auch ins CDR mit übernehmen, das ist so die Idee. Gut, wenn dann vielleicht anderthalb zwei Jahre dort Daten drin sind, dann kann man auch sagen, jetzt könnt ihr dort mit rein schauen und könnt euch das anschauen, das ist dann sozusagen der zweite große Schritt, also Daten anzeigen und visualisieren und der dritte große Schritt werden und wenn die Daten aktiv zu nutzen, das wird dann auch relativ bald kommen, wenn die Leute also sehen, wir haben dann eine Datenbasis, dann wird sicher die eine Chefärztin geben, die dann kommt und sagt, hier, ich kenne hier super coole, was, was ich, was startab, das kann irgendwas mega tolles, könnte man dazu greifen, wie was CDR geben. 

Ganz grober Marktausblick, dann jetzt tatsächlich zum Schluss ohne irgendwelche Richtigkeit und Vollständigkeit, sondern nur so die, die mir am häufigsten untergekommen sind auch hier wieder bitter korrigiert, uns auf Twitter etc. Wenn man euch dort vergessen hat. Es gibt da zum Beispiel die Vita-Group mit dem HIP CDR, die haben schon einige Unikliniken im Kundenkreis, also eben der Medizin Informatik, Initiative dabei sind, es gibt Interestsystems mit Iris vor Health, es gibt Extension mit der Orchestra eHealth Suite, es gibt die I-Engineers, die in der Schweiz relativ große und aber auch in Deutschland einige Kunden bekommen mit der Health Engine, es gibt Visus, die auch schon bei uns im Podcast waren mit dem Health Care Content Management System und es gibt Siemens Healthineers, die haben eine Digital Health-Plattform Connect, ich glaube die kommen eher so aus dem IHA XDS, XDR Dokumenten Bereich und dann gibt es neben der Vita-Group von schon gesagt die Open R als Basis haben, gibt es auch Beta, die haben auch Open R und ein eigenes Produkt dazu und das geht auch in Richtung CDR, aber da ganz klar keine Empfehlungen für irgendein Produkt, sondern kann man natürlich nicht machen, sondern um sich vorüberlegen welche Anforderungen habt ihr zum Beispiel als Krankenhaus, das müsste euch sauber überlegen, Requirements Engineering und dann gucken, welches dieser Produkte und der Projekt Teams Match dann besten dazu. Fertig, zu dem gespannt, auf das Feedback bei Twitter, ein bisschen Angst habe ich ja. Gut, fertig, vielen Dank, macht es gut.