Zitat von FS007 im Beitrag #15Nächster konstruktiver Vorschlag: Warum läuft der KIM-Client eigentlich nicht im Konnektor ? Das hätte den Vorteil gehabt, daß man das ganze KIM Zeug völlig transparent für den Anwender hätte machen können. Für den Anwender wäre der Konnektor dann nichts anderes als jeder andere Mail Server. Damit würde jeder zurecht kommen, auch meine 70+ Kollegen
Idee ist gut aber es fehlt der Speicherplatz. Die E-Mail muss zwischengespeichert, ver- und entschlüsselt werden.
Ein schönes Beispiel. Die PVS-Hersteller wissen auf Grund der Spezifikation:
ZitatDer Code 7400 wird für Fehlerfälle verwendet, die technisch bedingt sind und durch den Nutzer nicht behoben werden können. Diese Fehlerfälle erfordern eine Analyse und Behebung durch den Anbieter.
sowie
ZitatFehlercode 7400 hingegen deutet auf ein Problem im Konnektor hin, bedarf aber einer genaueren Analyse der Log-Dateien.
7400 ist ein Sammelcode, für diverse Probleme, die es technisch gegeben haben kann. Entsprechend müsste bei Fehlercode 7400 ein Hinweis kommen, dass zur Beseitigung des Problems bitte der DVO kontaktiert werden soll und die Fehlercodes des Konnektors im Konnektor-Log geprüft werden müssen. Für den Hersteller bleibt an dieser Stelle erst einmal nur die Hoffnung, dass der Fehler eventuell temporärer Natur war (zeitglich begrenzt bei einem Aktenanbieter oder nur bezogen auf dieses eine eGK) und sich der Fehler daher vielleicht selbst erledigt. In Richtung der gematik darf man fordern, dass auf solche Sammelfehlercodes verzichtet wird und gefälligst jede Fehlersituation, die in der Spec auch ausgeführt wird, einen eigenen Fehlercode nebst Fehlertext erhält.
Meiner Meinung nach ist der Hersteller (in diesem Fall des Konnektors) frei, weitere herstellerspezifische Fehlercodes mit weiterer Detailierung und sprechenden Texten zu senden. Er weiß auch am Besten, wo in seinem Code gerade ein Problem auftrat und kann da genaue Fehlertexte liefern. Des weiteren gibts glaub ich auch ein AFO, die sagt, dass die Fehlermeldungen, -texte geeignet sein sollen die Ursache des Fehlers zu finden und zu beseitigen.
Huch, da schaut man eine Weile hier mal nicht vorbei und dann wird der Thread auf einmal für ganz andere Themen missbraucht.. Da hat wohl auch die E-Mailbenachrichtigung des Forums nicht ganz funktioniert. Da dieser Beitrag eh schon ein bisschen zum "Dampfablassen" missbraucht wurde, könnte ich mich nach einer Stunde TI-Studium mal anschließen.
Ich gehe jetzt nicht auf die ganzen angesprochenen Themen ein, muss aber leider vielem zustimmen. Aus Sicht eines kleinen Primärsystemhersteller, der NICHT im Arztbereich Milliardenumsätze mit der TI erwartet, sondern sich mit einem kleinen Nischenmarkt beschäftigt, der in Zukunft an die TI angebunden werden soll, ist das Thema TI schier unlösbar und unbezahlbar, denn um überhaupt etwas entwickeln zu können, muss man erstmal viel Geld in die Hand nehmen und hoffen, dass die Kunden das später bezahlen. Oder man muss in das Gelddrucksystem einsteigen und die Hardware und Dienste unter eigenem Namen vertreiben. Dann muss man aber auch hoffen und bangen, dass die gematik mit der TI 2.0 nicht die Grundlage für das Gelddrucksystem nimmt, was wiederum zu Lobbyismus führt, der dann die TI 2.0 so umwandelt, dass es möglichst kompliziert und geldintensiv für Endanwender bzw. eigentlich nur für Steuerzahler und Versicherte wird.
Die Informationen seitens der Gematik sind völlig unzureichend bzw. vlt auch nur komplett unzureichend strukturiert. Als Primärsystem können wir uns die Konformität bestätigen lassen, aber nur wenn wir erstmal Geld für KoPS auf den Tisch legen und dann die 5000 Tests durchgehen?! Warum KoPS nicht kostenfrei für Primärsystemhersteller freigeben, immerhin ist das doch zu 100% vom Staat und den Versicherten, also auch von mir, finanziert!
Was soll das KIM-Clientmodul? Warum kann man die Ver- und Entschlüsselung nicht in den Konnektor packen und dann NUR (das veraltete) SOAP nutzen? Warum dann nochmal LDAP als extra Protokoll? Warum nicht auch die Schnittstelle auf den Konnektor und dann einheitlich alles über SOAP? Dann brauch man keine einzige Route im System anlegen und hat die Installation deutlich vereinfacht und eine Vielzahl an Fehlerquellen minimiert. Wie erkennt die TI denn bitte, ob ich eine E-Mail über ein zertifiziertes Client-Modul oder über eine selbstgestrickte Lösung verschicke? Wieso muss das zertifiziert werden? Muss das ganze Primärsystem zeritfiziert werden wenn man das KIM-Clientmodul integriert?
Warum gibt es 4 VPN Zugangsdienste aber dutzende VPN Zugangsdienst Anbieter? Damit möglichst viele sich an den Versicherten bereichern können? Was muss man als VPN Zugangsdienst Anbieter können? Wo in den 10000 kryptisch benannten Dokumenten steht das? Sind wir in den 90er stehen geblieben, dass die Zeichenzahl der Dokumentennamen begrenzt ist?
Ihr seht schon, das sind alles eher rhetorische Fragen, obwohl mich die Antwort auf viele dieser Fragen brennend interessieren wird. Vermutlich wird man dazu aber einen 5-6 stelliges Beraterhonorar zahlen müssen um wirkliche Antworten darauf zu erhalten. Die "Sicherheit" der Ti soll scheinbar dadurch erhöht werden, dass kleinere, agile und auch innovative Primärsystemhersteller sich das nicht leisten können und man den Markt so ausdünnt. Dann kann man den großen wenigen teure Zertifikate verkaufen.
So sehr ich die Digitalisierung im Gesundheitswesen und den Erfolg der TI wünsche, umso frustrierter bin ich jedes mal, wenn ich mich im Unternehmen mit der TI auseinandersetzen muss.
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
Lieber @dhpvs, ich kann den Frust verstehen und nachvollziehen und ich will hier auch keine Lanze für die gematik brechen. Und er ist in jedem Fall berechtigt, z.B. dass die Dokumentation der gematik nicht auf die "Verwender" der TI, also insbesondere auf die PVS-Hersteller ausgerichtet ist. Dafür gibt es Gründe (auch gute), das würde jetzt aber zu weit führen und hilft hier auch nicht weiter. Treffen wir uns mal auf ein Bierchen, erkläre ich das gerne. 😉 Und es ist absolut richtig, dass die Dienste der TI echt umständlich anzuprogrammieren sind (teils historisch bedingt, teils den Sicherheitsanforderungen geschuldet - SOAP ist ja nun auch nicht mehr das bevorzugte moderne Protokoll).
Das die TI als Gelddruckmaschine angelegt ist, ist natürlich Unsinn (erleuterbar). Und auch Behauptungen wie 50,-€ Produktionskosten für den Konnektor zeugen von Frust aber nicht von Kenntnis.😉
Was ich ganz konkret empfehlen kann, sind drei Dinge:
Einstiegspunkt für ein halbwegs gutes Herangehen an die TI-Anwendungen sind die Implementierungsleitfäden für Primärsystemhersteller. Bestimmt schon gefunden. Aber natürlich reichen diese nicht aus, um damit Systeme zu programmieren, dazu muss man dann doch wieder in die dutzende Specs einsteigen.
"Sprechstunden" der gematik nutzen. Für eRezept, ePA und KIM bietet die gematik mittlerweile (zum Glück!!) Teams-Sessions an. Zweiwöchig. Dort kann man seine Fragen loswerden, gemeinsam mit anderen Herstellern.
Zum "PVS-Service" der gematik gehört mittlerweile auch ein Ticket-Portal, über das man Fragen stellen kann. Dort bekommt man auch (oft) (recht) zeitnah eine Antwort.
Auf github hat die gematik mittlerweile auch etliche Projekte mit Beispielimplementierungen.
Aber am einfachsten: Nutzen Sie eine Drittsoftware, die die meiste "TI-Arbeit" für Sie kapselt und die leicht über gröbere REST-Schnittstellen nutzbar ist. Das reduziert den Implementierungsaufwand auf PVS-Seite enorm!
Naja, so ganz stimme ich da nicht zu. Ich kenne die Margen die da pro Konnektor und VPN Zugang etc. geboten werden. Das klingt schon eher nach Geldverteilung. Und Sie möchten als Berater ja mit der TI auch ihr Geld verdienen. Und die Hersteller von der Drittsoftware, vermutlich meinen Sie easyTI, möchten auch nochmal Geld verdienen. Die Kette wird also immer länger und länger und umso mehr kostet es den Versicherten und Steuerzahler.
Schon allein, dass man eine Drittsoftware braucht, die die TI kapselt ist eher ein Armutszeugnis für eine Infrastruktur, welche die Basis für eine modernes digitales Gesundheitssystem sein sollte. Vielleicht sollte man hier mal auf die Bremse treten, einen Schritt zurück gehen und alle mal gut analysieren, wie es ja scheinbar auch diverser Ärztevertretungen fordern.
Die 50€ Produktionskosten kommen zwar nicht von mir, ich glaube aber kaum, dass die reine Hardwarekomponenten viel teurer sind. Das teuerste ist vermutlich die Zertifizierung durch die Gematik und die Einhaltung der kryptischen Spezifikationen.
Wie gesagt, ich finde die Grundideen lobenswert, bei der Umsetzung heißt es aber: Setzen, 6.
Ich will das System nicht "schönreden". Ob es gut umgesetzt ist oder nicht - da darf man geteilter Meinung sein. Insgesamt ist es aber durch die Sicherheitsvorgaben ein komplexes System. Das treibt auch die Entwicklungs- und Zertifizierungskosten in die Höhe. Bei den Konnektoren kostet die HW irgendwas zwischen 150,- und 250,- €. Eine CC-konforme Softwareentwicklung inkl. Zertifizierung kostet hingegen im 7-stelligen Bereich... Also alles andere als Peanuts. Bei den Kartenterminals ist es ähnlich...
Die Drittsoftware ist ja auch nicht zwingend nötig. Sie vereinfachen die Nutzung des Konnektors (und schränken damit die Möglichkeiten auf Softwareseite natürlich auch ein). Für "Nischen-PVS" vermutlich dennoch lohnenswert, weil der Aufwand reduziert wird. Diese Systeme bilden sich frei am Markt. Wenn Nachfrage da ist, lohnt es sich. Müssen die Hersteller selbst entscheiden.
Das ich mit Beratung zur Produktentwicklung im allgemeinen und zur Unterstützung der TI-Umsetzung im speziellen Geld verdiene, hatten der Gesetzgeber sowie die Gesellschafter der gematik sicher nicht als primäres Ziel vor Augen.😉 Es ist aber immer bei komplexen Systemen so, dass für den Einstieg in dieses Thema Spezialwissen gebraucht werden kann, welches in der eigenen Firma nicht ständig vorgehalten werden kann - oder das Einarbeitungszeiten reduziert werden sollen. Dann kommen Berater zum Einsatz. Das ist keine "Erfindung" der TI, sondern ergibt sich ganz natürlich aus Komplexitäten. Gibt's in allen Branchen und Spezialgebieten.🤷♂️
Hier bin ich aber tatsächlich in meiner Freizeit aktiv. Weil mir die digitale Vernetzung im Gesundheitswesen persönlich am Herzen liegt.
TI-Community
»
Hersteller- und Zulassungsthemen
»
Konzepte, Spezifikationen, Richtlinie
»
Primärsystem Verbindung Konnektor
Thema drucken
17.10.2021 21:50 (zuletzt bearbeitet: 17.10.2021 21:50)
Antworten
