Folge #118 – FHIR feurig refired

So, hallo und herzlich willkommen zu einer neuen Folge des eHealth-Podcasts. Wir sind zwar noch nicht, wenn die Folge rauskommt in der Osterzeit, aber trotzdem möchte ich hier eine Osterfolge machen und immer mal wieder für euch ein paar Ostereier versteckt bringen in Form von schlechten Wortspielen. Draußen ist es kalt, macht es euch gemütlich am Lagerfeier und ich feier sehr, dass wir heute einen ganz hervorragenden Gast haben zu dem Thema. Ist euch vielleicht schon aufgefallen, Thema heute ist FHIR und ich begrüße Simone von gefyra. Hallo, Simone magst du dich kurz vorstellen. 

Ja, danke, mein Name ist Simone Heckmann. Ich bin Geschäftsführerin bei der gefyra GmbH. Wir sind ein ja noch relativ junges Unternehmen 2016 gegründet, dass sich auf das Thema FHIR spezialisiert hat und dafür Schulungen und Beratungen anbietet. Genau und du bist sozusagen schon die graue in den Enz, kann man nicht sagen, aber du bist schon die grauen Damen, die kann man auch nicht sagen. Was wäre denn jetzt politisch korrekt? Du bist eine absolute Expertin, wenn es um FHIR geht und deswegen, genau, freue ich mich sehr, dass du heute da bist. Ich bin, ich bin so grau wie man beim Thema FHIR auch nur sein kann ungefähr. So, so alt ist das ja noch gar nicht. Aber damit wird es sein, du bist von Anfang an dabei. Ziemlich fast von Anfang an, ja. Ich habe durch meine vorherige Tätigkeit viel mit Schnittstellen und HL7 Standards zu tun gehabt, hatte dadurch auch den Kontakt zu der Organisation HL7 und bin relativ früh etwa 2013 durfte das gewesen sein. Auf FHIR aufmerksam geworden und habe das dann einige Jahre eigentlich als Hobby betrieben und wie gesagt 2016 dann zum Beruf gemacht. 

Okay, perfekt. Ich gebe mal ganz kurz so eine grobe Agenda, damit die zudere wissen, was auf sie zukommt. Ach so, wenn ihr schlechte Wortspiele nicht wirkt, dann müsst ihr vielleicht ausschalten. Das wird heute, dann habt ihr eine Anleitung schon gehört, das wird heute das eine oder andere schlechte Wortspiele kommen. Also, Vorstellung, Simone und Geführer haben wir schon gemacht. Gleich werde ich in eine ganz kurze Einschätzung der aktuellen Lage geben zu FHIR. Wir haben nämlich ja schon eine Folge zu FHIR gemacht. Das war ganz am Anfang, welche das jetzt war, weiß ich gar nicht mehr aus. Wenn ich dann wird uns hauptsächlich die Simone erklären, was ist denn FHIR überhaupt? Also geht es in Richtung API, Kommunikationsstandard, syntaktisch, sehmante, moderne Technik und so weiter. Dann freue ich mich darauf, dass du erklären was bringt das denn überhaupt? Also ist das jetzt die 47. Der 47. Kommunikationsstandard im Gesundheitswesen oder wo liegen dann hier die Vorteile? Wie wird FHIR eingesetzt, wenn man bereits ein bestehendes System hat? Also bestehende Kist zum Beispiel? Dann etwas, was ich immer wieder mitbekommen, was schwierig ist, dass die Leute das immer so inhaltlich zusammen in ein großes gedankliches Bild bekommen, nämlich wie interagiert FHIR mit zu anderen Sachen, die wir am Podcast, die Antauern behandeln, IHA, CDA, H7V2, LOINCCDS, SNOMED CT und so weiter. Und wenn man danach Zeit und Lust haben und nicht das ganze Pulver schon während der Aufnahme jetzt verschossen haben, machen wir sowas wie Fast and FHIRious, die großen fünf. 

Was ist denn jetzt FHIR? Das hast du, ich hab schon mehrere Vorträge von dir gesehen, liegt da mal los und erkläre noch mal, ich mach mal eine kleine Wiederholung zu der anderen Podcastfolge, was ist denn jetzt FHIR? Ja, FHIR wird häufig als das HTML of Hells bezeichnet, eine Analogie, etwas hinkt aus meiner Sicht, aber es ist insofern richtig, dass es natürlich die selben Paradigmen verwendet, die wir alltäglich gewohnt sind, jedes Mal, wenn wir irgendwo eine Webseite angucken wollen, eben eine URL irgendwo einzutippen und dann Daten von dem Server war zu bekommen, die uns die Informationen liefern, die wir benötigen. Und FHIR überträgt eben genau dieses Prinzip, diesen restbasierten Ansatz auf das Gesundheitswesen und sagt, wenn jemand Patienten Daten haben möchte, warum nicht einfach eine URL des Patienten angeben und dann die Daten zu diesem Patienten empfangen. Das ist im Prinzip das, was hinter FHIR steckt. Für die Entwickler heißt das, die damit Technologien umsetzen müssen, dass sie eben das Ganze auf einer technologischen Basis machen können, die heute sehr, sehr weit verbreitet ist. Es sind ja nicht nur die Browser, die Webseiten abrufen, die dieses Paradigma verwenden, sondern im Prinzip jede mobile App, jede webbasierte Applikation kommuniziert, irgendwo mit ihrem Server, mit Rest über HTTP und empfängt dann irgendwelche Daten, die in den meisten Fällen dann auch mit JSON kodiert sind. Und das sind eben genau die technologischen Grundlagen, die wir jetzt auch für FHIR verwenden. Das Ziel ist es einfach, das Ganze für Entwickler so zugänglich wie möglich zu machen, also Technologien zu verwenden, die weit verbreitet sind und die vor allem eben auch auf etwas Ressourcen schwächeren geräten, wie eben mal einem Smartphone oder einem Tablet dann auch sehr gut umsetzbar sind. Bei manchen gehen vielleicht jetzt die Alarmglocken an, wenn ich sage, Patienten Daten abrufen ist so einfach wie Webseiten. Das heißt natürlich nicht, dass wir jetzt alle Patienten Daten ins Internet stellen, sondern es geht wirklich um das technologische Prinzip, was dahinter steckt, mit dem ein Client mit einem Server kommuniziert, immer natürlich Unterbeachtung der Datenschutzrichtlinien, der Benutzerauto, Indifikation, Autorisation, Verschlüsselung und so weiter. 

Genau ganz im Gegenteil, das war ja vorher, also mit dem Standard, der so ein bisschen inhaltlich zu vergleichen ist oder mit dem ähnliche da anderen übertragen worden sind. Zumindest im Krankenhausumfeld, HL7v2. Da war es ja so, dass eben zum Beispiel nicht festgelegt wurde, wie danach ja diese Informationsanheiten verschickt worden sind. Das heißt, manche Leute haben das in mir auf einen Fallzwerber gepackt. Manche haben das vielleicht über so eine TCP-Socket-Verbindung geschickt oder FTP, was was ich, was alles. Und da war eben nicht festgelegt, wie so was zum Beispiel verschlüsselt ist. Das ist bei FHIRn natürlich anders. Da kann man eben die Verschlüsselungsmetode nutzen, die man auch von der Bank kennt zum Beispiel. Und das ist jetzt auch der große Unterschied oder erstens nutzt das moderne Technik. Also das heißt, wir haben nachher XML oder JSON, das was nachher dann syntaktisch sozusagen übertragen wird. Und es ist auch festgelegt, wie es übertragen wird, der übertragungsweg, nämlich das, was du gesagt habt mit Rest, also Webtechnologie, aber auch verschlüsselt. Also das ist der große Vorteil. Wenn vorher bei HL7 V2 sich neue Leute oder Startups dann die Daten abrufen wollten, dann mussten erstmal HL7 V2 implementieren und das sieht nicht schön aus, sondern HL7 V2 in die 80er-Jahre. Aber aber auch kein schönes Kind der 80er-Jahre. Also das ist eine schöne Kinder, jetzt habe ich mir einen Eigentur gemacht. Ja, eben selber. Du hast mich auch angegriffen. Du hast mich jetzt gemobbt. Nee, also das ist, du hast schon recht für das, für 80er-Jahre ist das in Ordnung, aber es ist ja nicht mehr zeitgemäß. Also da sind, man muss sich überlegen, in welcher Reihenfolge, Informationen, in welchen Feldern stehen und so weiter. Gut, ich muss jetzt auch mal eine Landsebrechen für HL7 V2. Also ist natürlich, das ist eine indirekte Kommunikation, die da stattfindet. HL7 V2 tauscht Daten oder schickt Daten von einem Server auf den anderen Server. Das heißt, da ist immer noch mal ein System dazwischen. Was dann entscheidet, was davon der Anwender tatsächlich sehen darf. Insofern ist jetzt die eigentliche Benutzer-Steuerung in der Kommunikation jetzt eher nicht so wichtig. Das ist aber auch der Grund. Ich werde ja auch häufig gefragt, ja ist dann HL7 V2 jetzt abgekündigt. Machen wir Zukunft nur noch FHIR? Nein. Also ich gehe davon aus, dass dort, wo heute diese Server zu Server-Kommunikation ausreichend ist, dass wir da auch in vielen Jahren immer noch diese V2-Kommunikation sehen werden. Gute alte Informatiker-Region Never-Tutcher-Running-System, ja, wenn das funktioniert und sein Zweck erfüllt, dann lasst es in Ruhe. FHIR ist ein anderer Ansatz. FHIR kämpelt in Prinzip diesen einen zusätzlichen Server, der diese Daten, ganzen Daten aus dem Primärsystem noch mal kopiert, um sie dann einem kleinen zur Verfügung zu stellen, komplett aus diesem Bild raus und sagt, warum soll nicht der Kleint direkt auf das Primärsystem zugreifen können und die Daten abrufen, die er benötigt. Und dann haben wir natürlich diese zusätzliche Kontrollinstanz eines zweiten Systems mit eigener Benutzer-Steuerung nicht mehr dazwischen. Und deswegen ist nämlich das Thema bei FHIR auch deutlich wichtiger, als das bei Version 2 jemals war. Aber der Vorteil ist natürlich der, dass wir damit eben auch wirklich eine schnelle und einfache Möglichkeit bieten können. Ganz einfach gestrickte Web-Applikationen, direkt unmittelbar in dieses Kommunikationsumfeld-Krankenhaus zu bringen, ohne dass die jedes mal ihren eigenen Server mitbringen müssen, den man dann erst mal installieren muss, in V2-Kommunikation anbinden, der dann erst mal ein Monat lang vorbetankt werden muss mit V2-Nachrichten, damit überhaupt irgendwelche Patienten Daten drin sind. Das fällt im Prinzip komplett weg, sondern man kann eben die Möglichkeit schaffen, endanwendern-Applikationen direkt in dem KIS-System, die Daten abzurufen, abrufen zu lassen, diese benötigen. Genau, und das ist sozusagen der einer der vielen Vorteile, dass du vorhin vielleicht mit anderen Worten nochmal beschrieben. Wenn mit V2 war es so, dann muss man es gibt Ausnahmen, es gibt alte 7 Veteranen, die mir dann gleich wieder schreiben werden, dass es nicht immer stimmt, aber 95 Prozent der Anwendung war so, dass die Systeme sozusagen lauschen müssen und einfach die Daten mit protokulieren, bei V2 um dann später zu entscheiden, ob sie die vielleicht brauchen oder nicht. Das gibt es jetzt nicht mehr, jetzt kann man die Daten einfach anfragen, man muss also nicht in zweites und drittes Mal auf unterschiedlichen Servern, die identischen Daten speichern, obwohl man gar nicht weiß, ob man die brauchen würde. Und mit FHIR kann man einfach anfragen. Gibt mir mal alle Patienten, die auf der Station 11 liegen oder da gibt mir mal die aktuellen Diagnosen, ohne dass man die vorher, wie du gesagt hast, einen Monat mitgeschnitten haben muss. Das ist cool und das nächste ist genau, wenn man kann einfach sagen, wir nutzen HTTPS wie so schon, wir haben Get und Post und Put für die Informatiker, für die Programmierer, das kann man hier einfach einsetzen. Also das geht schneller, wir kriegen damit Innovation schneller auf den Boden und da hat das BMG auch mitgespielt, in dem die gesagt haben, es gibt jetzt einfach gewisse Schnittstellen, die müssen so spezifiziert sein, dass eben jetzt auch dann Start-ups, auch auf die Daten zugreifen können, was ja auch ein großer Vorteil ist. Ja, ja. Was ich gerade noch mal zu Kunstgesetzgewehr erwähnt hast, was da ja auch explizit drinsteht, ist ja die Integrations- von Entscheidungsunterstützungssysteme. Und das finde ich, ist auch ein sehr sehr wichtiger, bisher noch relativ wenig beachteter Use-Case für FHIR-Schnittstellen. Dass ich eben aus einem Primärsystem heraus irgendein Decision-Support Service triggern kann, der sich dann die Daten abrufen kann, die er benötigt, um jetzt irgendeine Entscheidung hier zu treffen oder irgendeine Empfehlung auszusprechen und die dann an das Primärsystem zurückzuliefern. Auch da ist mit V2 kein Blumtopf mehr zu gewinnen, weil es euch in Formen der Integration. Da ist FHIR eigentlich die einzige Lösung, die technisch plausibel und unsetzbar ist und es gibt ja auch in FHIR schon ein entsprechendes Framework, das CDS Hooks Framework, das eben genau beschreibt, wie mit Hilfe von FHIR ein Decision-Supportdienst, ein Entscheidungsunterstützungssystem, in ein Primärsystem integriert, mit Standardtechnologie und damit eben auch dann wesentlich einfacher als heute eben irgendwelche proprietären Schnittstellen darin zu schrauben. Letzter Low-Poodlei auf FHIR, also jetzt nicht nur klinische Decision-Support, sondern es gibt ja auch durchaus Use-Cases, wo vielleicht KIS-Hersteller gesagt haben, ja, es ist sicher sinnvoll und spannend, aber das lohnt sich nicht für uns, das zu entwickeln, für zwei Häuser, die da vielleicht Interesse haben, wo das sinnvoll ist, das machen wir nicht. Und wenn es jetzt eben so standardisierte Schnittstellen sind, die auch wirklich standardisiert sind, wo technisch, als auch syntaktisch und semantisch, dann kann man ja wirklich da auch Start-up-Strand setzen, für die sich das vielleicht lohnt. Das heißt, auch da wird so ein bisschen die Technikbarriere gebrochen, dass eben auch kleine innovative Unternehmen damit spielen können. Wir haben momentan ein Henneproblem am Markt. Die KIS-Hersteller sagen, warum soll ich das entwickeln? Es gibt ja gar keine Systeme, die ich da anbinden kann. Die Subsystemhersteller sagen, wie so soll ich dann systemen entwickeln, es gibt ja kein Kiss, was das unterstützt. Und da hoffe ich jetzt, dass eben die Spezifikationen wie isig, beispielsweise von der Gematik, was du erwähnt hattest, dass eben die Hersteller einfach dazu verpflichtet, bin in zwei Jahresfrist, bestimmte minimal Schnittstellen zu implementieren, dass das Ding in Steinen dann auch ins Rollen bringt. Gut, Hennenei, Steinen ins Rollen, da können wir jetzt auch wieder ein bisschen euer Insfrasen Schweinwerfen. Ich glaube, wir haben jetzt, was ist feier, haben wir glaube ich ganz gut erklärt, ich hoffe, das war jetzt nicht zu technisch und wir haben auch ein bisschen was bringt feier. Was ich immer wieder feststelle, ist, dass vielen Leuten nicht klar ist, dass feier trotzdem für bestehende Systeme auch ein Riesenaufwand ist, denn in jedem System, dass ja irgendwie gewachsen ist, und dass jetzt nicht die Daten in FHIR-Ressourcen speichert, das macht eigentlich fast keins, soweit ich weiß, müssen ja die Daten trotzdem irgendwie aus der propräitären Datenhaltung herausgeholt werden, müssen dann in FHIR umgewandet werden, müssen an das zweite System übertragen, werden und dann auch wieder auseinander klamusert werden und dann da wieder ins propräitäre Datenformat umgeschrieben werden. Also von da ist es schon viel auffand und magst du vielleicht mal sagen, was du da die, was so die Top 3 Tipps sind, die du in welchen Kunden geben würdest oder jetzt auch nicht Kunden zuhören, wenn die FHIR umsetzen wollen. 

Ja, also der erste und wichtigste Tipp oder eigentlich ein Missverständnis, was, was FHIR umgibt, ist die Vorstellung, dass FHIR einfach ist, das ist Verkaufsargument für FHIR, FHIR ist einfach zu implementieren, das ist aber nur bedingt richtig, FHIR ist insofern einfach zu implementieren, das ist eben wie gesagt viele übliche, für Entwickler gebräuchliche Technologien verwendet, aber FHIR trifft auch eine ganz bewusste Entscheidung, Komplexität immer auf die Seite des Service zu verlagern. Weil man einfach sagt, wir werden nachher in der Kommunikation ein Primärsystem haben, was die Rolle eines Service einnehmen, das sind in der Regel großes Systeme von großen Firmen, mit entsprechend größeren Entwicklerkapazitäten, an die dann viele einzelne kleine, kleine Applikationen angedockt werden. Wie du es bereits gesagt hast, zum Teil von Start-ups kommen, die einfach nur eine piffige Idee haben und das dann mit relativ wenig Kapazitäten umsetzen müssen. Das heißt, die Client-Entwicklung ist einfach mit FHIR, denn da haben wir auch den Schnellhohn-Durchsatz und die hohe Zahl der Implementierungen, da sparen wir praktisch, ja, the needs of the many outweigh, the needs of the few, um es mister mit Mr. Spock zu sagen, Yes, genauer pagen, Start-ups. Die Server müssen sich aber darüber im Klaren sein, diejenigen die Server entwickeln, dass da eine ganze Menge an Komplexität auf sie zukommt. Und das ist natürlich einerseits, genau wie du es gesagt hast, das Mapping der Daten aus der Datenbank in ein FHIRformat. Da ist eben ein Problem, dass das FHIRformat nicht immer so kwartratisch ist, wie eine relationale Datenbank, sondern dass diese Ressourcen zum Teil etwas hierarchische Strukturen haben, das heißt, dass man da wahrscheinlich dann aus etlichen verschiedenen Datenbank tabellen, sich seine Sachen Informationen zusammenklauben muss, um damit eine FHIR-Ressourse zu befüllen und auf dem Rückweg natürlich genauso. Das ist Aufwand, ja, und das kann FHIR jetzt auch nicht minimieren, in dem moment, wo ich eben einen standardisierten Ansatz, einen proprietäres Back-Entschraube muss sich eben fleißarbeit leisten. Das ist, denke ich, unbestrittende Tatsache. Ein ganz interessanter Punkt ist aber die Tatsache, dass es eben auch diese alternativen Weg gibt, zu sagen, wir speichern unsere Daten im FHIRformat. Das ist eigentlich ein überraschende Aussage, wenn man bedenkt, dass FHIR ein Kommunikationstandard ist und auch eigentlich nur zu diesem Zweck gedacht ist, aber einige pfiffige Entwickler, die sehr früh sich mit FHIR beschäftigt haben und die eben wirklich auf der grünen Wiese entwickeln durften, die sind auf die Idee gekommen, sich dieses ganze Mapping von Kommunikationsformat in Back-Ent zu sparen und die Informationen einfach im FHIRformat in ihre Datenbank zu schreiben und einfach XML-Native oder JSON-Native abzuspeichern, Datenbank-Systeme, die das können und gut und performant können, gibt es ja reichlich, MongoDB, CouchDB, wie sie alle heißen. Und damit schaffen die natürlich im Handumdrehen Systeme, die unglaublich viel können über die Rest AP, weil sie im Prinzip einfach nur noch eins zu eins auf ihr Back-Ent durchgreifen müssen, mehr oder weniger. Das ist mittlerweile auch ein recht beliebter Ansatz und ich habe schon einige Hersteller gesehen, die dann tatsächlich jetzt ihre Architektur auf Links stülpen und sagen, wir machen das genauso, wir machen FHIR im Fronten mit den Back-Ent, aber das ist natürlich ein Schritt, den ich jeder gehen kann. Das ist völlig klar, vielen wird nicht anderes übrig bleiben, als eben aus den bestehenden Datenbanken zu Mapping. 

Ja, da ist es eben wichtig, dass die Informationen, die man Mapping eben bereits jetzt in dem strukturierten und teilweise eben auch codierten Format vorliegen, weil sonst Mappingan da eben ins Leere hinein. Das heißt, da wird sicherlich einiges an Arbeit noch auf die Hersteller zukommen, beispielsweise auch dann sowas wie Snomitcoats in ihre Systeme reinzubringen, um die dann auch in den FHIRressourcen bereitstellen zu können. Was auch nicht trivial ist, genau, bevor wir die Technik verlassen einen, einen Tipp noch von mir, alle Hersteller von Software, wenn gerade ihr neue Module entwickelt, die mit anderen Modulen aus eure Software sprechen, dann sollte ihr überlegen, ob ihr nicht als Maßgabe, Unternehmensmaßgabe vorgebt, das muss erst mal über FHIR laufen, es sei denn es gibt gute Gründe, die dagegen sprechen, das heißt, wenn sie so schon viel Kommunikation im Produkt über Rest von mir läuft, warum nicht direkt sagen, das läuft über FHIR, da macht man sich ja nicht viel falsch. Vielleicht ein kurzer Einwurf von mir noch, was auch noch der Erleichterung dient, es gibt bereits fertige FHIRversaden-Systeme, also das sind fertig implementierte FHIRfrontents, in denen ich eigentlich nur noch das Mapping auf meine Datenbank einbauen muss. Nur in Anführungszeichen, weil wie gesagt, das ist ja eigentlich der schwierige Teil, aber man braucht sich an der Stelle zumindest mit der Implementierung der FHIRarpie nicht mehr allzu sehr auseinandersetzen, weil die ist schon da, solche Systeme gibt es, die kann man auf die kann man zurückgreifen, also es muss niemand hier wirklich bei null anfangen, FHIRspezifikation nachzuprogrammieren, sondern da reg ich einfach dazu an, sich auch ein bisschen in die Community, die weltweite Community der FHIRentwickler einzulassen und dort mal um Tipps zu fragen, weil es gibt eben sehr vieles, was man schon verwenden kann, was schon da ist. Auch Open Source Software, es gibt auch Varianten, die für die Support gibt, die man praktisch einkaufen kann, als auf der Module. Also da ist vieles schon da, da muss man uns jetzt jedes Mal bei null anfangen. 

Ja, wobei die Frage ist natürlich, ob man reines Mapping auf die Datenbank ausreicht, sondern wahrscheinlich wird er vor, die Business Logik noch drüber schauen wollen, ob sie denn, ne, ob das jetzt dann alles so passt und rechte und was weiß ich was. Aber lass uns auch vermitteln, ich würde gerne mit jeder weiter entsprechen, ich glaube, das langweilte irgendwann die Zuhöre. So, jetzt ein Riesenthema, also ich hab’s für mich klar, wir haben jetzt so unglaublich viele Abkürzung immer in unserem Branche, ne, also FHIR. Das haben wir jetzt ja geklärt. Dann gibt es IHE, was sozusagen so eine prozessuale Schicht mit Verantwortlichkeiten und Aktern da noch mal drum rumgieß, haben wir auch einen eigenen Folge dazu, wo man dem weiß, welches System muss, warum, wann, was in welchem Format, an welches andere System schicken. Wir haben CDA, was sowas ist wie so eine, ja, der elektronische Arztbrief, wir haben Teil 7V2, der uns aber Gott sei Dank auch noch lange begleiten wird. Wir haben low ink als medizinisches Ordnungssystem, wo unter anderem eben auch geklärt ist, was Labormaßnahmen jetzt wirklich genau sind, haben wir alles erklärt, wir haben den ICT als Diagnosischlüsseln, wir haben es noch medizinische Nomenklatur, wo medizinische Begriffe kudiert und auch zueinander in Bezug gesetzt werden. Jetzt ist immer das große Problem, selbst immer die einzelnen Sachen verstanden hat, wie spielt das denn jetzt zusammen? Also wenn man FHIR hat, braucht man dann noch IHE und CDA oder verbietet sich das sogar, also braucht man es dann nicht mehr, oder wenn man IHE machen will, was jetzt zum Beispiel mit XDS, also Dokumenten Austausch über unterschiedliche Einrichtungen hinweg, ja durchaus sinnvoll ist und was in Nachbarländern ja auch gemacht wird, Schweiz und Österreich, schließt IHE dann FHIR aus und schließt das CDA aus oder kannst du das mal für uns irgendwie ein bisschen mal uns mal ein Bild, wie das alles zusammen spielt, bitte? 

Ich werde es versuchen, also zunächst mal die der Zusammenhang von FHIR und IHE. IHE ist eben eine Organisation, die zunächst mal UseCase beschreibt, die Akteure, die Transaktionen zwischen den System und dann guckt, welcher Standard ist am besten geeignet, um diese konkrete eine Transaktion jetzt abzubilden. In der Vergangenheit lautet ihr die Antwort auf diese Frage dann häufig Version 2 oder Version 3 oder auch mal was ganz anderes wie bei XDS. In letzter Zeit lautet die Antwort auf diese Frage fast ausschließlich nur noch FHIR. Also wenn man schaut, wer an welchen Profilen IHE momentan arbeitet, die Antwort, welche Technologie es am besten geeignet, lautet eigentlich immer FHIR. Wenn man im IHE wiki mal sortiert nach UseCase Beschreibungen, die FHIR als Basistechnologie verwenden, findet man dort mittlerweile über 30. Ich glaube 32. Ich habe gestern geguckt, und weil FHIR kommt natürlich IHE sehr, sehr stark entgegen. FHIR ist im Prinzip die Antwort, die IHE schon seit zehn Jahren sucht, aber es eigentlich noch nicht wusste, weil einerseits ich bei FHIR eben durch diese Objektorientierung mit diesen einzelnen Ressourcen immer diese widerverwendbaren Komponenten habe, die ich immer wieder einsetzen kann, so dass ich auch bei, wenn ich verschiedene UseCase implementiere, nicht immer diesen Bruch habe, dass ich einmal V2 und beim anderen XDS und beim nächsten CDA verwenden muss, sondern dass ich immer wieder dieselben Bausteine nehmen kann und einfach neu zusammen wirfeln für einen neuen UseCase. Und eine weitere Punkt der IHE sehr in die Hände spielt, ist die Tatsache, dass es mit FHIR eben auch möglich ist, diese Festlegung, die IHE trifft. Was sind die Pflichtfelder in diesem Kontext? Wie müssen bestimmte Dinge kordiert werden? Welche Regeln müssen die Hersteller beachten, wenn sie bestimmte Transaktionen implementieren? Dass die in FHIRmaschinenlesbar ausgedrückt werden können. Die deswegen wirklich in ein Maschinenlesbare Form bringen, sodass man eben nicht mehr einfach nur ein PDF praktisch an den Entwickler gibt und sagt, da steht drin, was du machen musst, was dann auch wieder Missverständnisse zur Folge hat Fehlinterpretationen, jemand hat nicht genau gelesen, jemand hat was übersehen und am Ende kommt doch wieder etwas raus, was nicht genau passt, sondern dass da eben wirklich ein Maschinenlesbares pattern praktisch dem Entwickler an die Hand gegeben wird, mit dem er unmittelbar prüfen kann, ob das was sein System erzeugt, Konform ist oder nicht. Der nächste Punkt, also IHE XDS genau, das war auch noch ein Thema. XDS beschreibt ja den Austausch von Dokumenten, aber sagt nichts darüber aus, was diese Dokumente eigentlich genau sein sollen. Es gibt das dann in unterschiedlichen Geschmacksrichtungen, beispielsweise mit strukturierten Dokumenten, wo man dann eben CDA präferiert, aber ein grundsätzlich kann bei dem Dokumenten Austausch auch ein PDF drin sein. Demzufolge ist es auch nicht ausgeschlossen, dass sich das Dokument, was sich Austausche einfach nur aus einem Bündel von FHIRressoursen besteht. Das konkret sehen wir das ja in der Spezifikation für die E-Parschnittstelle, die seitens der Gematik auf XDS oder so was ähnlichem wie XDS festgelegt worden ist, deren Inhalt aber letzten Endes die MIOs von der KBV sein werden. Wie gesagt bei XDS ist es egal, was ich letzten Endes reintur, es geht hier nur darum, dass die Metadaten dazu einheitlich ausgetauscht werden. Interessanter finde ich allerdings die Tatsache, dass IHE inzwischen auch ein neues Profil für den Dokumenten Austausch vorgelegt hat, namens MHD bzw. MHDS, das genau das gleiche Scenario beschreibt, aber jetzt für den Austausch dieser Dokumente Rest verwendet und für den Austausch der Metadaten eine FHIRressourse verwendet, also komplett auf FHIRtechnologie aufsetzt, um Dokumente auszutauschen. Auch damit der Möglichkeit im Innern dieses Dokumentes ein CDA, ein PDF oder sonst etwas einzubetten, aber eben mit einfachen technologischen Grundlagen für den Dokumenten Austausch. Denn XDS ist von der Technologie her gerade für, wenn ich jetzt meine Dokumente irgendwie auf dem Tablet oder so bringen will, sehr, sehr schwierig zu implementieren. Also Sob ist jetzt auch nicht mehr da aller Letzte schrei, bei der ersehten Kommunikation, Multipartemime, EBI, XML und so weiter. Das sind so Sachen, die… Jetzt wird’s aber hart steh, sind sie wohl da wieder bisschen hoch, so ist gerade… Ich bin aber echt stresspickl, wenn die sowas auf einem mobilen Plattform implementieren müssen. Und insofern ist es eben sehr interessant, dass es mit MHD da jetzt eine Alternative gibt, die letzten Endes in seinem Use-Case erfüllt, aber eben eine etwas weppfreundlicher Technologie da zugrunde legt. Das kann man entweder als Facade vor XDS draufsetzen, dass man also mobilen Endgeräten einfache Möglichkeit gebt auf die Dokumente in XDS durchzugreifen. Man kann das aber auch standalone machen, sodass man eben also die komplette Dokumentenkommunikationen, die Dokumenten austauschbasieren auf FHIR realisiert. 

Wir tauchen ein bisschen weiter auf, ja, das heißt ich tauch jetzt auf 10 Meter unter der Wasseroberfläche auf dem Versuch, nur mit einem Bild irgendwie zu zeichnen und wie das zusammenspielen kann, das ist nur eine Möglichkeit. Also wir sagen mal, die ganzen Daten, die jetzt vielleicht medizinisch erfasst worden sind in irgendeine Eindrichtung von mir aus dem Krankenhaus, die sind dann idealerweise irgendwann annotiert. Semantisch annotiert, also Diagnosen sind nach ECD verschlüsselt. Andere Informationen sind noch mit CTA verschlüsselt oder low-ink wie auch immer, OPS. So diese verschlüsselt Informationen, die können ja dann in einem CDA, in einem elektronischen Atsprieft drin sein. CDA ist dann idealerweise so, dass es ein Bereich gibt, der ist für Menschenlesbar und ein Bereich der ist für Maschinenlesbar, so dass dann eben eine Maschine auch weiß, aha, das ist also dieser Code, das heißt, die Maschinenlesen dann low-ink und ICD und snowmitsität. So, das heißt dann haben wir sozusagen einen Atsprieft, dann ist die Frage, wer darf wandern, diesen Atsprieftlesen und wer darf den wohinschicken? Und wann muss das passieren und wer es in unseren Dokumenten, Konsument, wer es und Dokumenten erzeugen, also die Rollen zu definieren, wann, was wo passiert, wo das hingeht und so weiter, das würde dann IHA unter anderem machen. Das heißt, IAA legt dann fest, wie sehen die Use-Cases aus und dann könnten da solche CDA-Briefe, die dann semantisch annotierte Daten drin haben für Computer und auch andere Daten für Menschen, könnten dann hin und her verschickt werden. So und jetzt legt IHA eben auch fest, wie das verschickt werden kann. Und in früher haben die das dann eben zum Beispiel gesagt, mit HL7V2. Aber so was kann dann jetzt eben auch mit Fire passieren. Das heißt, Fire kann dann im IHA-Kontext auf der einen Seite sozusagen der Übertragungsstandard sein. Aber kann natürlich auch genutzt werden, um zu definieren, was da jetzt alles drin ist. Also, wenn man so eine Abfrage macht bei einem PIX. Ja, PIX ist das. Abfrage von Master Patient Index und Pädikung ist einfach nur suche nach Patienten. Also, das heißt, so was kann natürlich auch wunderbar dann über Fire laufen. Dass man ja an Frage hin gibt, gibt mir alle Patienten bei euch im System mit dem Nachen am Sohntsohnt und Geburtstatt im Sohntsohnt, dann kommen dann eben entsprechende Fire-Rufshorsten zurück. So kann das also zusammenspielen. Heißt, das schließt sich nicht aus. Natürlich gibt es da Überdeckungen, da gibt auch ähnliche Sachen, aber das schließt sich nicht aus. Kommen wir vielleicht noch mal ganz kurz auf die Differenzierung von Fire und CDA zurück. Weil, da haben wir jetzt tatsächlich die Situation, dass wir hier eigentlich zwei Standards haben, die genau dasselbe können, nämlich strukturierte Dokumente abbilden. CDA, wie gesagt, ist ein strukturiertes Dokument, aber eben nur das. Also, die CDA Spezifikation beschreibt, wie ich ein Dokument strukturiere und dann versende, beschreibt aber nicht, was vorher passieren muss, damit ich diese strukturierten Daten in das Dokument reinkriege, oder was danach passieren muss, damit das empfangen des Systemen diese strukturierten Daten weiterverarbeiten kann. Und da sehe ich jetzt den die große Chance von Fire, denn auch Fire kann strukturierte Dokumente abbilden. Wir nennen die Ressource, mit der man das macht, in Fire auch sinnhaft composition. Denn das ist genau das, was passiert zu dem Zeitpunkt, als dem ich ein Dokument erstelle. Ich komponiere Daten, die schon drin sind in meinem System, die strukturierten Diagnosen, die Laborparameter, die Medikationsdaten, die komponiere ich jetzt in ein Dokument. Das heißt, in Fire ist ein Dokument, im Prinzip eine Zusammenstellung von bestimmten bereits vorhandenen Fire-Ressourcen in meinem System. Die dann im Sinne eines Dokumentes, beispielsweise über XDS oder über MHD, versendet werden können und wo der Empfänger einerseits das Ganze dem Menschen im Sinne eines Dokumentes zum Konsum breitstellen kann, aber auch das Ganze einfach nur als ein Verpackungskontainer betrachten kann, in dem ganz viele strukturierte Daten drin sind. Und dann weiter verarbeitet werden können. Und auch dazu gibt es mittlerweile ein interessantes IHE Profil namens, jetzt muss ich nachdenken, QED, Query for Existing Data, glaube ich, ist das genau. Quart errat Demonstrandum. Genau, das im Prinzip beschreibt, wie ich Daten, die über ein strukturiertes Dokument in meinem System reingekommen sind, jetzt als Diskrete Daten wieder abfragen kann. In dem ich zum Beispiel sage, zeig mir mal alle Diagnosen zu diesem Patienten, unabhängig davon, über welches Dokument, die jetzt in meinen System reingekommen sind oder ob es überhaupt über einen Dokument reingekommen sind. So dass ich praktisch diese Daten remixen und neu zusammenstellen kann. Das ist also vielleicht, es ist nicht nur die Folge des schlechten Wortspiele, sondern es ist auch die Folge der schlechten Bilder, einfach um jetzt dann vielleicht nur V2 und und auch CDA zu erklären. Ich mache das bei meinen Studierenden immer mit einem Bild, um den Unterschied klar zu machen, wenn die, also mit dem paar anderen, der paar anderen gerade einkaufen ist und man möchte teksten, bringe Milch mit. Dann ist das so, was er eigentlich wie eine V2-Nachricht. Eine kurze, ein kurzes Antiker macht das oder das neuer Patient ist aufgenommen. Jeder, den es interessiert, soll er speichern, bringe Milch mit. Wenn man dann aber Schlussmacht nach drei Jahren Beziehungen, dann macht man hoffentlich das nicht über Wortsab oder Siegner oder sowas, sondern dann schratt man mit einem Federkiel, einen langen Brief und resumiert noch mal was gut war in der Beziehung und so weiter. Das ist dann RCDA, das heißt, es fast einen längeren Zeitraum zusammen und nimmt auch nicht alle Daten, sondern nur Daten, die jetzt vielleicht dafür relevant sind und so ist der Unterschied zwischen CDA und V2. Richtig, also genau wie bei CDA ist es ja auch so, dass ich zunächst mal einen konkrete Vorstellung haben muss, was ich eigentlich für ein Dokument erstelle und dann beschreiben muss, was in dieses Dokument alles reingehört. Das gibt es ja in Form von diesem CDA Implementierungsleitfelden. In das genau festgelegt ist, wie die Kapitelüberschriften eines Arztbriefes lauten, wie die Diagnosen darin dann codiert dargestellt werden und so weiter. Genauso muss man dann in FHIR eben auch vorgehen, dass wenn man mit FHIR ein Strukturiertes Dokument erstellen möchte, dass man eben genau beschreibt, was da in diesem Dokument an welcher Stelle hineingehört. Wir gehen auch standardmäßig immer davon aus, dass es letzten Endes ein Anwender ist, der ein Dokument zusammenstellt. Ich habe immer das Bild im Kopf, wenn man jetzt ein FHIR Dokument erstellt aus bereits vorhandenen Informationsobjekten, dass man irgendwie so ein User-Interface mit so einem Drag and Drop hat, wo man einfach die Diagnosen dann in die ist. Das Kapitel des Briefes reinzieht, indem man das Ganze haben möchte, lässt sich sicherlich schön und in Bund dann mal umsetzen. Aber letzten Endes ist es ein Anwender, der eben entscheidet, was wichtig ist, was unwichtig ist und was in das Dokument reingehört. Aber Potential gibt es natürlich auch die Möglichkeit, dass ich ja eben zeichne, das glaube ich als Dokument on Demand, dass ich also das Erstellen von Dokumenten automatisiere, indem ich eben ganz klare Regeln, maschinenlesbare Regeln festlege, was in dieses Dokument rein muss. Und wenn dann jemand nach so einem ondemand Dokument anfragt, dass es im System noch gar nicht gibt, dann wird das praktisch ad hoc aus den vorhandenen Informationen zu den Patienten. Zusammengebaut und ausgeliefert. Also auch das ist technisch möglich, sowohl mit CDA als auch mit FHIR. Liebe Simon, ich will sagen, wir machen jetzt mit der Technik FHIRabend und kommen zu den großen, machen wir drei Wortspielen. Oder mit FHIR, weil das sich einfach so wahnsinnig anbietet. Magst du anfangen? Ich habe ja schon ein bisschen Pulver verschossen. 

Ja, den FHIRabend hast du mir gerade genommen, mein Lieblingswortspiel. Aber ich habe nur die Verlängerung, das FHIRabend Bier. Das FHIRabend Bier. Das ist ganz hervorragend. FHIRabend Bier würde ich dann auch feierlich aufmachen. Hast du noch was? Wortspiele, nicht so sehr. Die sind ja auch alle schon wieder ein bisschen… Also was mich immer wieder freut, ist der Ideenreichtum der Community bei dem entwickeln von Produktnamen. Denn die FHIR-Nazensbestimmungen schließen es ja aus. Das waren das Wort FHIR in einem Produkt oder Firmennamen verwenden darf. Aber das kommt dann immer zu so lustigen Produkten, wie z. B. Das Spring-Klei, gibt es um Massen-Tests auf einen Server zu schicken für Performance-Tests und so weiter. Wong fand ich auch immer ganz lustig. Das niederländische Wort für Funke, die Bezeichnung für einen FHIR-Server. Der wurde jetzt aber kürzlich unbenannt, ein FHIR-Liservor, das macht mich etwas traurig. Vielleicht weil Wong etwas zu sehr wie die laut malerische Beschreibung einer Fehler mehr. Aber mein absoluter Liebling ist Barki The Fire Dog. Das ist ein kleiner Gefleck der Hund. Der heißt tatsächlich Sparky ist aus einer amerikanischen Kinderbuch-Serie. Der Hund arbeitet bei der Feuerwehr und seine Aufgabe ist es Kindern beizubringen, wie man Brände vermeidet. Und dieser Sparky The Fire Dog hat das mittlerweile auch zum in-offiziellen Maskottchen der FHIR-Community geschafft. Und aber das ist ja echt nicht mehr feierlich, was es dafür Wortspiele gibt. Ich freue mich auf die FHIRtale, die jetzt kommen wir uns jetzt fast nach Karneval. Falls wir das nicht feiern können, wird man das immer im nächsten Jahr wie nachfeiern müssen, wenn man nicht gerade im Bett liegt und krank feiert. Ansonsten wünsche ich dir, dass du gut nach Hause kommst von der Arbeit, Freitag und nicht in den FHIRabendverkehr kommt. Du meinst vom Schreibtisch zurück zum Sofa. Ja, ich glaube, das klappt. Ich werde mir jetzt ein paar… Wie heißen die diese russischen Eier machen, kennst du dir? Ja, warte hier. Strohbar noch FHIR. Und dann… Das war der allerschlechteste. Jetzt bin ich durch mein Material, das Verschossen. 

Ich danke dir ganz herzlich und wünsche allen Hörern. Ich bedanke mich. Danke, ciao.