In dieser Folge sprechen die Gastgeber über §291d SGB V und die Integration offener Schnittstellen in informationstechnische Systeme im Gesundheitswesen. Dabei geht es um die Anforderungen an Praxissoftware-, KIS- und Medikationssoftware-Hersteller sowie um die zunehmende Bedeutung interoperabler Systeme in der ambulanten und stationären Versorgung. Im Mittelpunkt steht das Interview mit Jens Naumann, der die Auswirkungen der gesetzlichen Vorgaben auf Softwarehersteller und Gesundheitseinrichtungen erläutert und Einblicke in aktuelle Entwicklungen rund um offene Schnittstellen und digitale Versorgungskonzepte gibt.
Podcast: Play in new window
Transkription
Dann kommen wir zu unserem Hauptthema heute Paragraph 291d. Wir haben wieder einen Gast dabei, wie schon angekündigt. Jens Naumann, ich glaube es dritte Mal bist du jetzt dabei, magst du dich noch mal kurz vorstellen für die Leute, die jetzt zu die ersten Podcasts nicht mitbekommen haben. Klar, Gaste Ansegerin, hallo in die Runde. Ja, Jens Naumann, mein Name. Ich bin Geschäftsführer der medatixx. Wir sind ein Anbieter von Praxis Software in Deutschland. Und ich bin derzeit im Hobby, im Ehrenamt sozusagen Vorsitzender des Vorstandes des bvitg, Bundesverbandesundheits IT und da eben auch damit beschäftigt. Mit Kassenärztlichen Bundesvereinigungen, mit Kassen, mit gematik und Politik über die Rahmenbedingung der Digitalisierung und Gesundheitswesen auszutauschen. Perfekt, deswegen bist du in hervorragender Gesprächspartner hierfür. Wir sind ja ansonsten, was den ambulanten Sektor angeht, er ein bisschen dünn aufgestellt kann, so sagen deswegen.
Vielen Dank, dass jetzt das dritte Mal dabei bist. Thema Paragraph 291d. Jetzt hast du vorher, als wir das Thema abgestimmt haben, gesagt, dass es ein emotionales Thema ist. Ist er jetzt schon heiß? Habt ihr eine Klimaanlage? Ist die ob das Thema’s heiß? Oder tatsächlich, weil der Raum so warm ist, wie geht es dir damit? Also eine Mischung aus allem, der Raum ist warm, ja. Wir haben ein schönes Tonstudie bei unserem Unternehmen, dass aber keine Klimaanlage hat. Emotional, auch deshalb, weil wir, und da sprach ich jetzt von der gesamten Industrie, sowohl ambulante als auch stationäre Welt, die ja gleichermaßen davon betroffen sind, von Anfang an der Meinung waren und auch noch sind, dass es dieser gesetzlichen Regelung gar nicht bedroft, weil das, was der Gesetzgeber da fordert, heute im Markt schon geregelt ist oder andersartig gelöst wird. Und hier der Gesetzgeber in unserer Wahrnehmung, eine Argumentation insbesondere der kassenärztlichen Bundesvereinigung gefolgt ist, in der der möglicherweise andere Ziele stecken, als die der Gesetzgeber jetzt damit intendiert hat. Insofern ist hier viel Arbeit entstanden, um etwas, was die Versorgung draußen und die Nutzung der IT in Krankenhäusern und Praxen nicht wirklich verbessert.
Jetzt haben wir noch gar nicht gesagt, du bist schon direkt politisch eingestiegen, jetzt haben wir noch gar nicht gesagt, was das überhaupt ist. Und wenn ich das mit meinen Worten mal ganz grob zusammenfassen darf, besagt dieser Paragraph 291-D vom Sozialgesetzbuch 5, dass in Zukunft die Medikationsmodule aus KIS und auch Arztpraxissystem herausgelöst werden müssen, als Modul angeboten werden müssen, so dass man leichter als niedergelassener Arzt oder auch in ambulanzem Krankenhaus dieser Medikationsmodule auswechseln können muss. Das ist richtig. Genau, also der 291d hat ja genau genommen, mit mehreren aber zwei wesentliche Elemente. Der Absatz einstagt, dass es eine Archiv- und Wechselschnittstelle geben soll. Es wird oftmals wenn über 291d gesprochen wird, auch und unterschätzt. Also der Gesetzgeber liegt fest, das Systeme in der vertragsärztlichen, zernärztlichen und Krankenhausversorgung. Standardisierteschnittstellen haben müssen, um Daten in ein einheitliches, naturales Archivformat zu bringen und ein Systemwechsel zu erleichtern, das der erste Absatz. Der ist gerade erst in Arbeit, deswegen oder die Umsetzung ist gerade erst in Arbeit, deswegen noch nicht so in der Öffentlichkeit. Und es gibt den Absatz 1a und dieser Absatz 1a sagt genau das aus, was du gerade gesagt hast. Verordnungssoftware, was das ist, wurde jetzt gerade erst durch die KBV definiert, muss für einen Anwender eines klinischen Informationssystemen einer ambulanzlösung und einer Praxissoftware austauschbar anwechselbar sein, ohne dass er sein ganzes Krankenhaussystem oder seine Praxissoftware wechselt. Dafür hat die KBV im ambulanten Bereich, die DKG im stationären Bereich, den Auftrag bekommen, Schrittstellen zu spezifizieren, sie sind es wester reinzuschreiben und dann auch die Anbieter damit verpflichtend zu zertifizieren.
Wie kommt es denn, dass sich da die Medikation heraus gepickt wurde? Und nicht irgendwas anderes, also es könnte ja genauso gut, die weiß nicht, der genosen Erfassung oder was, was ich was war. Wir glauben sogar, dass der Anfang ist, dass man mit weiteren Modulen, mit weiteren Funktionalitätsbereichen aus Praxissoft, der ambulanzlösungen weiter machen wird. Die Grundidee, die dahinter steckt ist, man möchte eine Modularisierung der Anwendungen insbesondere auch im ambulanten Umfeld erzeugen. Und wenn man uns mal das vergleicht, die klinische Welt mit der ambulanten Welt, dann haben wir ja in der klinischen Welt schon sehr oftmals diesen Best of Breed Ansatz. Also ein Krankenhaus sucht sich für verschiedene Themen, verschiedene Anwendungen aus und lässt sie mit Kommunikationsserver miteinander arbeiten. Im niedergleichenden Bereich laufen da eher die Online-Anwendungen heute, also die Praxissoftware, in der Verordnungen, Dokumentation, Formularwesen, Abrechnungen, alles, was dazu gehört, eher monolithisch abgebildet sind. Und das soll durch dieses Gesetz begonnen, beginnend aufgebrochen werden. Warum die KBV diesen Gesetzestext gefordert und am Ende auch durch politische Lobbyarbeite erfolgreicher bekommen hat, ist eine Empfindung der KBV oder der Ärzteschaft im Zusammenhang mit der Einführung des Bundesmedikationsplans. Ach ja, stimmt. Und der Bundesmedikationsplan wurde im Frühjahr letzten Jahres eingeführt, verpflichtend für Anbieter von ambulanz und Praxissoftware. Die Ärzte haben etwa 180 Millionen Euro jährliche Sonnera mehr verhandelt, um die Mehrarbeiten, die durch das Befüllen des Planes zu auftreten, finanziert zu bekommen. Und die Praxissoftware-Branche, die Ambulanzsoftware der Anbieter haben solche Module gebaut, der eine hat es im Samsofterpflegevertrag angeboten. Und der andere hat eben gesagt, ich verlangere für den Bundesmedikationsplan eine zusätzliche Lizenzgebühr oder Pflegegebühr. Und das wurde von der Ärzteschaft als, ja, als nicht gerechtfertigt, als nicht angemessen bewertet mit dem Wunsch und der dadurch formulierten Forderung der KBV. Man möge dem Gesetzgeber, der Gesetzgeber möge der KBV die Chance geben und das Recht geben Praxissoftware-Systeme soweit zu modularisieren und das ist eine Arzt, der mit seiner Verordnung software dazu gehört der Medikationsplan, wenn nicht einverstanden ist, weil er dafür Geld bezahlen muss, einen anderen Anbieter zu nehmen, der einen anderen Preis aufruft, das umsonst anbietet, wie auch immer. Also getrieben war das Ganze durch den Unmuth der Ärzteschaft, dass der Bundesmedikationsplan von einigen Anbietern verwendet wurde, um Geld zu verlangen.
Also prinzipiell muss ich ja sagen, dass es eigentliche erst mal gut klingt, wenn man Sachen modularisiert, das ist ja was, wie es jetzt mit der Informatikerbrille sowieso laufen sollte, dass die Sachen eben nicht irgendwie zusammenhängen, sondern dass sie sich gegenseitig aufrufen ist ja eigentlich geschickt. Das Zweite ist, best of breed ist der eigentlich für den Arzt und für Patienten, vermutlich auch eine sinnvolle Sache.
Das heißt, wenn damit, die dieses Wendolok in aufgebrochen wird, dass der Arzt also große Probleme hat, vielleicht seine Software zu wechseln, ist jetzt vielleicht für die Softwarestelle erst mal nicht, aber für den Arzt klingt es ja erst mal gut. Die andere Sache ist, was du gerade gesagt hast, die Begründung der Frage, der hängt es doch vehement davon ab, wie die Verträge ausgestaltet sind.
Das heißt, wenn man jetzt vielleicht einfach gesprochen gesagt hat, dass alle gesetzlichen Änderungen in Zukunft mit einem gewissen Preis abgegollen ist, dann finde ich es auch, oder es ist vermutlich rustisch auch fraglich, wenn man dafür Geld verlangt, wenn man andere Verträge hat, warum sollte man das dort dann nicht auch bezahlt bekommen? Also wenn es stärkere oder herterere Gesetze in der Automobilbranche gibt, dann werden die Autos entsprechend auch teurer, wenn man neues Auto kauft oder hinkt der Vergleich. Ja, also du hast natürlich recht die Frage, dass ein Arzt oder ein Anwender, das ist ja am klinischen Umfeld, trifft ja genauso zu, wie in der ambulanten Welt. Da ist es aber jetzt offensichtlicher und auch emotionaler diskutiert worden. Ein Arzt sagt, ich möchte gerne bestimmte Funktionalitäten in meinem System haben, die ich in den bestehenden nicht finde, dann habe ich die Möglichkeit, mehr ein anderes zu suchen und das im Markt, in dem freien Markt. Das ist ein kluger richtiger Ansatz und keiner von den Anbieter der Markt hat, ich glaube, Sorge davon, deshalb, dass ihm Anwender deshalb von der Pfanne gehen. Die Unlogik, die er dahinter steht und das ist der große Unterschied zum Bereich der klinischen Software ist, das schon immer Praxissoftware mit dem Funktionsumfang, den es heute im Kern hat. Das Behasismodul war und das eine Vielzahl von Zusatzapplikationen heute schon angedockt sind, also ein Archivierungssystem, eine Spracherkennung, Kommunikationslösung. Sind ja heute schon Dinge, die ein Arzt sich wählen kann aus einem Portfolio oder die er eben in der Auswahl von dem, was ihm angeboten wird, nutzen kann. Wenn man aber das Kernmodul und Verordnung, alle Rezeptmasken, die dazugehörige Medikationsstatenbank, der Bundesmedikationsplan, die Hausapotheke der Praxis, also die Niste der häufig benötigten Medikamente, vielleicht sogar die Statistiken zu den Verordnungen aus dem monolithischen Basissystem rauslöst, entsteht der folgende Situation, dass der Arzt eine Ergonomie hat in der Bedienung seiner Software, die heute in sich geschlossen ist. Dokumentation, formularwesen, Verordnung, Abrechnung sind in einer Logik, in einer Programmlogik, in einem Programmdesign in einer Ergonomie gestaltet. Und unsere Erfahrungen markten, das haben wir auch sehr ausführlich mit der KBV diskutiert, dass eine Verordnung ein so wichtiger Bereich ist, der in so viele Stellen der Praxissoftware eingreift und aus der Haares aufgerufen wird und interagiert. Das in dem Fall, wo der Arzt die Verordnungssoftware nicht mehr gut findet, also mit den Verordnungsfunktionalitäten, er nicht mehr einverstanden ist. Das passiert, was sowieso heute schon passiert, dass er seine Praxissoftware wechselt, das Gesamtsystem wechselt. Also wir sehen hier eine Feingranularisierung auf eine Ebene runter, die am Ende dazu führen wird, dass das Arzt kein Arzt tut. Und wenn das tut, wird er einen Ergonomiebruch haben, einen Designbruch haben, einen Nutzungskwalitätsverlust haben, neben der Tatsache, dass er dann in seinem Premiere-System die Schnittstelle bezahlen muss, wenn er ein Anbieter das bei Schnittstelle anbietet und die Verordnungssoftware, die sich von Fremden dritten dazu kauft, auch noch ein Preis haben wird. Und dann noch dazu kommt, dass er dann zwei Firmen hat, zwei Servicepartner hat, regionale Strukturen hat, die in Konkurrenz zueinander an seiner Praxissoftware-EDV-Anlage konfigurieren. Also für diesen konkreten Fall ist das eine Lösung, die im Markt nicht dazu führen wird, das ärztet sich mit dem Basis-Systempraxissoftware zusätzliche andere oder alternative Verordnungssysteme dazu holen. Kommt auch noch hinzu, was generell bei best-of-Breden-Problem ist, wenn man nachher irgendwelche Spirigkeiten mit dem System hat, kann es sein, dass man zwischen Anbieter A und B hin und her läuft und immer auf den jeweils anderen verwiesen wird. Genau, das kann passieren. Und natürlich ist das die Argumentation der KBV, und da ist es ja auch nicht völlig unbegründet zu sagen, es gibt dieses Vendor Lock-in. Also wenn ich einmal die Praxissoftware der Firma X Y habe, dann muss ich all die Funktionalität auch verwenden, die die mir anbieten. Also wenn ich ein integriertes Archivsystem, mein integriertes DMS oder PACS haben möchte, wenn ich integrierte Spracherkennung haben möchte, Kommunikationslösung haben möchte, dann bin ich, und das ist stärker als in der klinischen Welt. Darauf angewiesen, dass der Anbieter dieser Praxissoftware das auch integriert und der wird zählten. So ist es heute so, vier verschiedene Archivsysteme, tief integrieren oder Kommunikationslösungen mehrere integrieren. Und an der Stelle ist es klug und sinnvoll und vernünftig. Und unterstützt es Wert von uns, dass man zu diesen Sekundärsystemen, die neben Praxissoftware, Amulanzsoftware laufen, standardisierte eineliche Schnittstellschaft, die immer Apps zum Beispiel derzeit gar nicht unterstützen wir vollständig. Aber dass das Basissystem zerrissen werden soll, und für den Anwender keinerlei Vorteil bringt, ist eine reine politische Wunsch der KBV in diesem Bereich einzukaufen. Okay, vielleicht noch eine Anmerkung. Jetzt Jetzt ist es ja so, dass es, was du es gesagt, im Krankenhaus, dass schon Gang und Gärbe ist. Da gibt es aber in der Regel auch eigene IT-Abteilung, die nachschauen können, falls bei den Schnittstellen etwas steht, das wird in den Gegnern gestern. Praxis ist natürlich ein bisschen schwierig. Also die Qualität muss dort so sein, dass es eigentlich zu keinem Ausfall mehr kommt. Da ja dort kaum jemand, der sich direkt dort draufschalten kann. Wieso man am Ende ist es jetzt so, es gibt diesen Paragraphen, die KBV hat die gesetzliche Pflicht. Sie hat selber um diesen KBVen gekämpft, sie hat ihn bekommen, sie hat ihre gesetzliche Pflicht erfüllt, die in dem Paragraphen steht, wie sich das gehört. Sie hat eine Spezifikation, einer Verordnungssoftware definiert. Das war auch interessant, was denn die KBV unter Verordnungssoftware versteht. Also die KBV hat jetzt eine völlig neue Softwarekategorie im Markt erfunden. Also welche Elemente aus einer Praxissoftware jetzt als Verordnungssoftware gelten? Und hat die entsprechende Schnittstelle, die notwendig ist, in einer Praxissoftware um diese Verordnungssoftware aufzurufen, im Fest dafür öffentlich. Und jetzt ist es von den Systemern wieder umzusetzen, weil es Zulassungsrelevant ist und in den Markt auszuräulen. Mit der großen Frage wird das tatsächlich dazu führen, dass Ärzte, die heute Praxissoftware haben, mit dem integrierten Verordnungsmodul morgen die Software behalten und das Verordnungsmodul B oder Zee nehmen. Das wird der Markt zeigen, man hat es so entschieden, wie als Verbandhalten ist für nicht notwendig, weil es keine wirkliche Marktrelevanz hat. Aber natürlich steht dort das Argument der KBV im Hause, dass sie sagt, dass die Hersteller-Systemeffnung möglicherweise nicht gut finden, weil sie das Wendelock in etwas öffnen, ist natürlich auch eine Argumentation, der man sie stellen muss. Ja, also jetzt einfach mal ohne tiefer darüber nachzudenken, finde ich das auch gut. Was ich auch noch gut finde, was die KBV meiner Meinung nach sinnvoller gemacht hat. Ich habe mir die Schnittstelle in Spezifikation angeschaut. Z. B. Das erste Dokument, was ich gefunden habe, ist noch nicht 100% diktiv. Und was du gerade meintest, was die KBV jetzt beschrieben hat, diese Verordnungssoftware, die besteht aus den Klassenbehandler, Rezept, Medikament, Patient und Betriebsstätte. Und was die Gott sei Dank gemacht haben, die haben FHIR definiert als Schnittstelle. Und dort gibt es dann eben die Standardprofile, die wir auch schon mal während haben, Patient-Kostenträger, Medikament. Und haben das ganz freier Konform gemacht haben, also die zusätzlichen Informationen. Also die man zusätzlich braucht zur Standard-Rissource-Patient, haben die dann in speziellen KBV-FHIR-Extensions gemacht. Ich habe in einer Stellungnahme vom bvitg auch gelesen, dass man das eigentlich gar nicht braucht, weil es schon XBDT gibt. Jetzt mal unter uns gesprochen, hört ja keiner zu. XBDT ist eigentlich, wenn das auf dem XDT Standard basiert, das ist ja wirklich nicht mehr Zukunftsfähig. Von daher finde ich es ein technisch gesehen, schon auch geschickt, dass jetzt die Praxishersteller gezwungen werden, auf FHIR zu gehen.
Ganz wichtiger Punkt, Kastel, und hier liegt eine große Verwechslung vor dem Markt, die ich auch immer wieder höre. Wir müssen unterscheiden zwischen dem Paragraph 2.91. D. Absatz 1a und Absatz 1, klingt nach Paragraphemreiterrei, ist aber ein großer Unterschied. Was wir darüber gerade gesprochen haben, ist die Schnittstelle, die im Samoem operativen Betrieb. Das ist der Praxissoftware heraus, es ermöglicht eine fremde Verordnungssoftware aufzurufen, oder aus der Ambulanzsoftware heraus. Die ist, und das haben wir als Verband begrüßt, sind wir ein sehr sehr schönen Schwenk der KBV-Morner stützt. Basierend auf FHIR, moderne Standards, gab es einen Kommentierungsverfahren, was die KBV da mal leider nicht in der Methodik gemacht hat, wie man standardisiert, Kommentierungsverfahren macht, weil der Gesetzgeber hat gesagt, sie muss sich ins Benehmen setzen mit der Industrie, das heißt, man kann sich unsere Haltung in Meinungen anhören, aber man muss hier nicht berücksichtigen. Aber dass man auf FHIR gegangen ist, und dass man da vernünftig in diesen Klassenarbeit haben wir begrüßt und unterstützt. Worüber du gerade gesprochen hast auf der Basis-XBDT, ist der Absatz 1, das ist §91. Da geht es nicht um die Anbindung einer Verordnungssoftware, die im täglichen Betrieb 300 mal aufgerufen wird, sondern es geht darum, dass für Zwecke der Archivierung, oder, und das war vor allem der Wunsch der KBV bei der Mitformulierung dieses Paragraphen, für den Fall des Systemwechsels ein gesamthafter Export, aller Behandlungs- und Konfigurationsdaten aus der Praxissoftware in ein Zwischenformat erfolgt. Und dieses Zwischenformat dann von dem neuen System eingelesen werden kann, damit mit dem System dann gearbeitet werden kann. Das ist die Wechselschnittstelle. Was anderes als die Verordnungssoftware-Schnittstelle. Und bei dieser Wechselschnittstelle haben wir, der KBV gesagt, es gibt im Marikzeit ungefähr 20 Jahren den XBDT, der zum einen eine Satzbeschreibung beinhaltet, die sämtliche in einer Praxissoftware-Sittermann. 95% in einer Praxissoftware gespeicherte Daten. In Klammern, die Welt in der Praxissoftware geht er weit über den Regelungsbereich der KBV hinaus. Wir haben selektivverträge der Hausärzte, der Fachärzte. Wir haben Privatpatienten, wir haben BG-Patienten, das Regulator, die KBV alles gar nicht. Aber die all diese Dinge berücksichtigen. Und wo ein Export aus einem Praxissoftware-Systema gemacht wird in das Zwischenformat. Und dann in ein Praxissoftware-System B eingebaut kann. In dieser Standard ist über 20 Jahren entwickelt worden im Markt. Hast du recht, auf dem alten ED-Fakt basierten XDT-Format, aber es etabliert. Er funktioniert, es gibt Import- und Export-Routinen. Und jetzt kommt die KBV und sagt, wir definieren das mal alles neu. Ihr müsst also komplett neue Export- und Import-Rotinen programmieren. Die lange brauchen werden auf der Basis von FHIR an einen anderen Standards. Bis sie das können, was der XBDT kann. Deshalb unserer Vorschlag zur Erfüllung dieser gesetzlichen Pflicht. Liebe KBV, verwendet doch das, was im Markt jährlich sechs bis siebentausend mal gut benutzt wird. Und lasst uns gemeinsam daran arbeiten, das in eine moderne technologische Struktur zu heben. Die KBV auch eine Weile darüber nachgedacht, hat sich mit XBDT beschäftigt. Hat sich jetzt aber entschieden, auch aus Gründen, die die KBV nicht alleine zu verantworten hat. Jetzt ein komplett neues Datenmodell zu schreiben, eine komplett neue Wechselstelle zu spezifizieren. Aber die ist jetzt gerade erst in Kommentierung. Wie ist noch gar nicht fertig und auch noch nicht veröffentlicht?
Das heißt, für das Medikationstool ist das FHIR, das ist schon definiert, das ist gut so. Und für den Export und ein Import in ein neues Arztpraxissystem, da soll dann eben in Zukunft nicht mehr XBDT genutzt werden, sondern etwas, was neu gerade definiert wird. Genau, und was dann am Ende als Export und Import-Ritinen in den Systemen zu implementieren ist. Und auch da, also das ist ja klug und sinnvoll und vernünftig. Und das ist so etwas gibt. Nur es gibt es eben schon lange seit vielen Jahren, natürlich durch die 20 Jahre Laufzeit, nicht auf moderner Technologie basierend und nicht als gesetzig verpflichtendes Element. Und jetzt hat es der Gesetzgeber eben zur Pflicht gemacht. Da haben wir kein Problem mit da arbeiten, wir an der Kommentierung der Spezifikationen mit. Natürlich sollen die Ärzte die Möglichkeit haben, ihre Daten mitzunehmen. Die haben sie aber heute auch schon. Aber das machen wir es immer neu.
Wenn wir das Verordnungsmodul herauslösen, sind die Daten dann in beiden System vorhanden? Ist das spätisiert? Es ist eine spannende Frage, also die Frage hat uns die KBV nicht beantwortet, weil sie sagt, das ist eure freie Entscheidung. Wenn man die Spezifikation, die jetzt im KBV-Regelwerk eingetragen wurde von der KBV, so ein Thema Verordnungsschensstelle sich anschaut, dann ist die handwerklich gut gemacht, weil sie hat FHIR hat vernünftige Ansätze und die Frage, wie wir das konkret umsetzen. Also welches System zum Beispiel die Daten hält zur Verordnung des Patienten, das kann jeder für sich entscheiden. Ich glaube, dass die Realität zu sein wird, dass das Praxissoftersystem und das Ambulanzsystem der Klinik das Datenhaltende führende System ist und das ist für die Verordnung diesen Kleien aufruft, in dem Rezept, als eine Arzneimitteldatenbank, Hausabtäke, Bundesmedikationsplan hinterlegt sind. Und das dann wieder der Rückschrieb zur Datenhaltung in das jeweilige Primärsystem erfolgt.
Mit Hinblick auf die Zeit, schwitzte schon sehr, willst du wieder raus aus dem heißen Aufnahmeraum. Ich glaube, wir haben jetzt jetzt auch gut angesprochen, großes Thema, was mir fast alles softwarehersteller, was mir jetzt treffen wird oder schon getroffen hat. Würde ich sagen, beenden wir die Folge für heute.
Vielen Dank.
Sehr gern.
Links
Schlagwörter
§291d SGB V, Offene Schnittstellen, Interoperabilität, Praxissoftware, Medikationssoftware, Krankenhausinformationssystem, KIS, eHealth, Gesundheitswesen, Gesundheits-IT, Digitalisierung, Healthcare IT, medatixx, Jens Naumann, Schnittstellen, Ambulante Versorgung, Digitale Gesundheit, Softwareintegration, Medizinische Informatik, IT im Gesundheitswesen