Wegen eines verweigerten Zugriffs auf das Organspenderegister wurde Ursachenforschung betrieben, und es zeigte sich, dass fälschlicherweise in einem von zwei Konnektoren bei der Akquinet nicht die Institutskarte des KH, sondern die eines ermächtigten Arztes steckte (das war mit Sicherheit unsere eigene Schuld). Kurzfristige Abhilfe wurde geschaffen, indem einfach ein KT am anderen Konnektor benutzt wurde. Ich möchte das natürlich schnellstmöglich bereinigt haben, traue mich aber nicht so recht, den Tausch gegen die korrekte Karte anzuleiern, da ich nicht weiß, an welchen Stellen im Primärsystem (i.s.h.) hier irgendwelche Auswirkungen zu erwarten und entsprechend vorbeugend zu bearbeiten sind. Das ginge ja nicht nur mit einem Wechsel der T-ID, sondern auch des Institutstyps einher, denn momentan steckt eine Ärzteschaft-Karte. Ich wage gar nicht, darüber nachzudenken, was da alles in den verschiedenen SMCB- signierten eAUs drinsteht undsoweiter. Kann jemand etwas dazu sagen? Danke Zanko
karte ist gemeint die gSMC-K? das sind 3 baugleich smc's die nicht mehr ausgewechselt werden dürfen, da Laufzeitverlängerung ratifiziert.
Seit Mai 2022 endlich online! secunet konnektor World Healthcare ingenico ORGA 6141 online allUp2date
„Wir brauchen Regierungen, die sich des Schadens für Zivilpersonen bewusst sind, der aus dem Anhäufen und Ausnutzen solcher Software-Sicherheitsprobleme entsteht“– Brad Smith
Wir betreiben zwei Konnektoren (KoCo), mit je 40 Anschlüssen. Soll-Zustand: in beiden Konnektoren (genauer: in zwei daran angeschlossenen KTs) stecken identische SMC-Bs für KH (also Präfix 5). Sollte also ein Konnektor vorübergehend ausfallen, kann über die KTs die am anderen Konnektor hängen, dieselbe Funktionalität wahrgenommen werden. Ist-Zustand: In einem Konnektor steckt die Institutskarte des Krankenhauses, im anderen aber die eines Arztes (Präfix 1). Die vom Arzt soll raus und gegen eine Duplette der KH-SMC-B getauscht werden. Alle KIM-Adressen sind glücklicherweise an der T-ID der KH-SMC-B gebunden. Die Frage ist, an welchen Stellen noch Auswirkungen zu erwarten sind. Real genutzt wird bei uns im breiten Stil aktuell die eAU, das eRezept und natürlich VSDM. All dies kann über die SMC-B eines Arztes abgewickelt werden. Dies gilt jedoch nicht für den Zugriff auf das Organspenderegister (klappt nicht für Ärzte), und so ist diese Situation überhaupt erst zu Tage getreten.
beide konnektoren von CGM (kann nichts dazu beitragen) KT1 und KT2 sind in beiden konnektoren registriert. richtig? alles mit statischen ip-adressen? wurde die smc-b schon kopiert? ist das in krankenhäuser üblich? was sagt cgm dazu? was ist mit präfix gemeint? (wahrscheinlich kaum relevant) wie lange sind die smc-b's noch gültig? https://www.google.com/search?q=zweite+smc-b+karte hier findet man ergebnisse, dass es mit der 2. smc-b auf eigene kosten geht. ich sage smc-b duplizieren, wer auch immer herausgeber der smc-b war. darauf achten, dass die telematik-ID gleich bleibt ("...Nur eine Telematik-ID pro Betriebserlaubnis..." https://www.deutsche-apotheker-zeitung.d...karte/chapter:2 ) smc-b vom KH-arzt raus, alte smc-b vorerst nicht löschen, neue smc-b rein, aktivieren, mit webportal, transport-pin etc., evtl. hilft cgm dabei.
Seit Mai 2022 endlich online! secunet konnektor World Healthcare ingenico ORGA 6141 online allUp2date
„Wir brauchen Regierungen, die sich des Schadens für Zivilpersonen bewusst sind, der aus dem Anhäufen und Ausnutzen solcher Software-Sicherheitsprobleme entsteht“– Brad Smith
Zitat von Zanko im Beitrag #1 Ich wage gar nicht, darüber nachzudenken, was da alles in den verschiedenen SMCB- signierten eAUs drinsteht undsoweiter.
Um zu sehen, was jetzt als "Unterschrift/Instituts-Signatur" ggf. unter der eAU steht- ich hätte da eine Idee: ich würd mal im KIM Postausgang eine eAU anschauen- und den .p7s Anhang runterladen, der ja dem Inhalt der eAU entspricht: den dann mal mit Notepad öffnen und schauen was da ganz unten steht zu SMC-B... also hab das grad mal bei mir probiert und ich meine, dass ich da MEINE SMC-B sehe, also mit der das maschinell erstellte Dokument signiert wurde..ganz sicher bin ich nicht, aber ich meine das könnte passen soweit mein verständnis bei dem Thema reicht:
Hier mal ein Beispiel:
Allgemein um zu sehen welche Auswirkungen eine "falsche" instituts-SMC-B von dem ermächtigten Arzt hat:
1. Ich denke man sollte da 2 Gruppen von Prozessen unterscheiden: Gruppe 1: allgemein smc-B abhängige ti-prozesse - also alles, was bei SMC-B Ausfall nicht geht, weil VPN Konnektor down: das betriftt dann wirklich alles: von VSDM, KIM, eAU bis hin zu eRezept usw. - wenn es keine valide SMC-B gibt, läuft gar nichts- ob VSDM , eREzept die SMC-B im Austausch mit TI Servern auch nach extern für LoggingProtokolle o.ä. auch noch weitergeben oder ob das nur Sache des Konnektors intern ist, dass halt der vpn und vergleichbare FUnktionen ohne SMC-B nicht aufgebaut werden, dazu weiß ich technisch zu wenige Details @MLangguth wird das aber sicher wissen, ob die "Gegenstelle" z.B: Kassenserver "sieht und protokolliert im Log", welche Institution und SMC-B Nummer da eine Kartenabfrage gemacht hat beim Karteneinlesen (VSDM) - und ob z.B. beim eRezept auch noch irgendwo sowas mit versandt wird beim hochladen in die VAU usw.
Gruppe 2: zusätzlich mit smc-B signierfähige Prozesse: wobei mir nur einfällt da : Elektronische Beantragungsverfahren (eHKP) - werden Sie im krankenhaus nicht haben , das ist derzeit nur Projekt der Zahnärzte soweit ich weiß- und eben die eAU - alles andere lässt sich ausschließlich mit EHBA signieren : also eRezept und eArztbrief.
Kritisch in Haftungssicht wäre hier ggf, wenn die eAUs ggf. jetzt alle von dem einen ermächtigten Arzt mit der SMC-B signiert sein sollten - wobei ja EIIIIGENTLICh auch die signatur mit einer SmC-B einer eAU nur notlösung ist , wenn der EHBA des AU ausstellenden Arztes technisch nicht verfügbar ist - dass das in der Praxis anders läuft, steht auf einem anderen Blatt - da weiß ich halt nicht, wie die Struktur Ihrer Klinik ist: haben Sie alle EHBAs im Backend stecken bzw. haben die Ärzte alle KTs in ihrer Nähe um ihren EHBA dann auch je Verordnung stecken zu können? Oder ist es wie bei den meisten draußen: funktioniert strukturell so (noch) nicht und daher nimmt man dann halt doch die smc-B weil es einfach praktikabler ist:
Und um zu sehen, was passiert, wenn man jetzt die ungewollte SMC-B gegen die SMC-B Krankenhaus tauscht: ich glaub ich würd als erstes erstmal nur die "ermächtigter Doktor-SMC-B" nur mal befristet und reversibel rausnehmen -z.B. Pairing auflösen im Konnektor (CGM ist da jetzt recht gut, sowas zu begleiten, hatte in letzter Zeit gute erfahrungen auch mit Level 1 Hotline bei dem Thema) - so gehen müsste ja dann der Konnektor, zu dem das KT mit dieser SMC-B gepaired ist, ja seinen VPN sofort runterfahren und alle TI Prozesse auf Störung gehen. Oder die SMC-B mal ganz raus aus dem Kartenterminal und Konnektor , der damit gepaired ist neu starten...hat vermutlich den gleichen effekt:
Sollte der betroffene Konnektor das 2. Kartenterminal mit der richtigen SMC-B auch schon bereits via Infomodell zusätzlich "sehen" und ggf. diese 2. SMC-B (weiß ich nicht, ob sowas ginge und wie genau da Ihre Konfig ist ) auch gepaired sein zusätzlich - könnte ich mir vorstellen, dass sich der Konnektor dann halt dort seine SMC-B sucht, wo eine ist- und es läuft dann trotzdem alles weiter oder er hat schon immer für seine Sachen die richtige SMC-B genommen ;-) - falls nicht, und der Konnektor 1 ist wirklich NUR mit dem ermächtigte Arzt-SMC-B KT verbunden, müsste dann alles down sein in dem Bereich.
Und für die weiteren Prozesse : wenn in Ihrem KIS nur ein einziger Zielkonnektor 1 und kein Fallback Ziel Konnektor 2 hinterlegt werden kann, dann muss das KIS ja zwangsläufig über den betroffenen Konnektor 1 gehen, wo Sie tauschen möchten und wenn es das ausschließlich tut, läuft es je nach Konfig Konnektor s.o. dann trotzdem alles was TI Allgemein ist weiter oder eben , wenn wirklich Konnektor 1 nur gepaired ist mit der falschen smc-B läuft dann vermutlich nicht mehr.
Bitte unbedingt berichten, wie das ganze dann ausgegangen ist nach dem Tausch. Ist ein sehr spannendes Thema, was Sie da als Beitrag eingestellt haben:-)
Zitat von Zanko im Beitrag #5Die Frage ist, an welchen Stellen noch Auswirkungen zu erwarten sind.
Ich würde tatsächlich keine Auswirkungen erwarten.
Mit einer KH-SMC-B sollten sie ja die gleichen Dinge tun können, wie mit einer Arztpraxis-SMC-B. Von daher sollten alle TI-Prozesse an sich weiterlaufen. Wenn in dem Konnektor mit der Arzt-SMC-B ausschließlich diese Arzt-SMC-B vorhanden ist, dann wurde auch der TI-Zugang (via VPN-Zugangsprovider) auch mit dieser Karte registriert. Das müsste dann erst de-registriert und mit der neuen SMC-B neu registriert werden (über den Konnektor).
Die Frage ist, ob im ish an irgendeiner Stelle die Arzt-SMC-B (deren TID oder Kartennummer) eingetragen, konfiguriert oder gemerkt wurde und das KIS dann mit genau dieser Karte arbeiten will (per Übergabe an den Konnektor) und daher auf einen Fehler läuft, wenn genau diese Karte dann nicht mehr da ist. Das können Sie nur im ish prüfen (mit einem entsprechenden Admin).
Ansonsten dürfen, wie @Junioruser1976 schon geschrieben hat, an etlichen Stellen Zugriffe mit der falschen Karte protokolliert sein (lokal, auf den eGKs, bei zentralen Diensten). Das ist aber schon so und hat zu keinem Problem geführt. Ergo wird ein Wechsel auf die korrekten Protokolleinträge keine Probleme erzeugen. 😉
"Duplette" war das falsche Wort, sorry. Es sind natürlich Karten mit unterschiedlicher ICCSN, aber eben identischer T-ID. So wie es sein sollte. Nur steckt eben an einem Konnektor ein Karte mit anderer T-ID. Das geschah irgendwann vor meiner Zeit beim Umzug vom lokalen RZ zur Akquinet. Das Präfix ist eine Zeichenfolge, mit welcher die T-ID beginnt, bei Krankenhäusern "5-2". Daran wird eben erkannt, welche Art von Einrichtung sich hier authentifiziert, und daran können eben bestimmte Zugriffe scheitern, weil beispielsweise ein Arzt (Präfix 1..) nicht auf das Organspenderegister zugreifen darf (so geschehen bei uns, weil eben die besagte Arztkarte steckt und nicht die KH-KJArte).
Ich möchte zunächst mal nur kurz auf die Idee mit dem KiM-Postausgang eingehen. Auf die Idee bin ich selbst nämlich noch nicht gekommen. Wir betreiben i.s.h.med mit omniconnect (x-tention) und amasys (cerner). Währende eines onlinetermins mit x-tention wegen James-Problemen in oniconnect habe ich das mal angesprochen, denn ich finde leider in omniconnect nicht das Postfach der eAU-KiM-accounts. Dieser account wird irgendwo anders konfiguriert, was auch gut so ist, denn sonst wäre auch das von der James-Fehlkonfiguration betroffen gewesen. Jedenfalls komme ich über omniconnect nicht da dran.
Bleibt Amasys.
Da war der Ansprechpartner natürlich erstmal raus, und ich selbst habe in Amasys nichts gefunden, wo ich diese Informationen hätte sehen können. Hat irgendjemand einen Tip für mich? Nebenbei bemerkt: Das GUI von Amasys ist ohnehin alles anderes als übersichtlich und intuitiv. Grundsätzlich muss man natürlich sagen, dass das ganze inzwischen von ziemlich akademischen Interesse ist, denn das Kind ist ja schon seit Inbetriebnahme der eAU in 2023 in den Brunnen gefallen. Übrigens ist die Signatur mittels SMC-B auch bei uns nur in Ausnahmefällen zulässig (wir erweitern ja nicht den gesetzlichen Rahmen), aber es wird eben dennoch immer wieder gemacht, auch ohne Ausnahmefall.
Das ist die prägnante Zusammenfassung meines Stands. Und ich wüsste gerne, ob, und wenn ja , an welchen stellen unser Primärsystem genau diese Karte haben möchte. Ich werde wohl mal bei cerner eine Anfrage machen, und letztendlich muss es ein Test dann erbringen. Ich werde berichten, sobald das weitergeht.
Zitat von Zanko im Beitrag #5Die Frage ist, an welchen Stellen noch Auswirkungen zu erwarten sind.
Ich würde tatsächlich keine Auswirkungen erwarten.
Mit einer KH-SMC-B sollten sie ja die gleichen Dinge tun können, wie mit einer Arztpraxis-SMC-B. Von daher sollten alle TI-Prozesse an sich weiterlaufen. Wenn in dem Konnektor mit der Arzt-SMC-B ausschließlich diese Arzt-SMC-B vorhanden ist, dann wurde auch der TI-Zugang (via VPN-Zugangsprovider) auch mit dieser Karte registriert. Das müsste dann erst de-registriert und mit der neuen SMC-B neu registriert werden (über den Konnektor).
Die Frage ist, ob im ish an irgendeiner Stelle die Arzt-SMC-B (deren TID oder Kartennummer) eingetragen, konfiguriert oder gemerkt wurde und das KIS dann mit genau dieser Karte arbeiten will (per Übergabe an den Konnektor) und daher auf einen Fehler läuft, wenn genau diese Karte dann nicht mehr da ist. Das können Sie nur im ish prüfen (mit einem entsprechenden Admin).
Ansonsten dürfen, wie @Junioruser1976 schon geschrieben hat, an etlichen Stellen Zugriffe mit der falschen Karte protokolliert sein (lokal, auf den eGKs, bei zentralen Diensten). Das ist aber schon so und hat zu keinem Problem geführt. Ergo wird ein Wechsel auf die korrekten Protokolleinträge keine Probleme erzeugen. 😉
Heißt das es interessiert keinen der zentralen TI-Dienste ob die verwendete Identifikation bzw. Signatur berechtigt ist?
Zitat von Zanko im Beitrag #11und ich wüsste gerne, ob, und wenn ja , an welchen stellen unser Primärsystem genau diese Karte haben möchte
Zitat von MLangguth im Beitrag #8Die Frage ist, ob im ish an irgendeiner Stelle die Arzt-SMC-B (deren TID oder Kartennummer) eingetragen, konfiguriert oder gemerkt wurde und das KIS dann mit genau dieser Karte arbeiten will (per Übergabe an den Konnektor) und daher auf einen Fehler läuft, wenn genau diese Karte dann nicht mehr da ist.
Dass SMC-Bs, die es eigentlich im System nicht mehr gibt, an bestimmten Stellen vom AIS weiter "gehalten" werden, kann ich praktisch bestätigen: Jedenfalls bei Charly/Solutio nach SMC-B Tausch von Ende 2022 ist bei uns die SMC-B alt nicht aus dem System komplett verschwunden automatisch-sondern wird bis heute z.B: bei eHKP und eAU , wenn ich eine Signatur machen möchte, im Frontend auch als Option weiter fleißig angeboten- also die software "merkt" sich alle möglichen Karten- zur Korrektur müsste man erst die entsprechenden Einträge in der Datenbank dann alle manuell löschen, wenn einen das zu sehr stört. Hab ich bis heute nicht gemacht, weil es bei uns kleine überschaubare Struktur ist, lohnte den Aufwand nicht sich da ins Backend reinzufummeln nur deshalb- aber in komplexen Anwendungen beim KIS ist das sicherlich noch ein umso wichtigeresThema.Eben weil man der SMC-B, außer man kennt die Nummer auswendig, im Ggs. zum EHBA in der Applikation, die diese als Signaturoption anbietet, nicht ansieht gleich, wofür sie ist.
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
Zitat von Lauterbach im Beitrag #12Heißt das es interessiert keinen der zentralen TI-Dienste ob die verwendete Identifikation bzw. Signatur berechtigt ist?
Definiere "berechtigt". Die zentralen Systeme wissen ja nicht, welche Person mit welcher Organisation in welchem Vertragsverhältnis steht. Daher können die zentralen Bestandteile das nicht prüfen. Dort wird die ROLLE geprüft und durchgesetzt, also dass z.B. eine eAU mit einer Unterschrift einer SMC-B-Org einer Krankenkassen abgelehnt wird (obwohl die Signatur technisch möglich ist).
Aber ob im Einzelfall der Zugriff / der Protokolleintrag mit der im konkreten Einzelfall gültigen Karte erfolgte, ergibt sich nur aus konkreten Einzel-Vertragsverhältnissen. Und die können nur durch Menschen geprüft werden. Und das wird nur gemacht, wenn jemand den Prozess startet, in dem er beispielsweise eine Verdacht auf missbräuchliche Nutzung meldet. Und wer es wann, wo und in welcher Weise prüft, hängt auch wieder davon ab, welcher Fachdienst in welcher Konstellation betroffen war und wo sich der Mensch "beschwert" hat (bei der Praxis, bei eine Aufsichtsbehörde, vor Gericht).
Ich hätte gedacht die gematik hat hier eine Art Validierung vorgesehen; also doch nur analog Prozesse elektrifiziert. Im Endeffekt ist doch jetzt jede eAU falsch signiert; (unvorsätzlicher) Straftatbestand?
TI-Community
»
TI-Nutzung und Nutzen aus Anwendersicht
»
TI-Plattform - Hardware, Zugang, Einrichtung
»
Falsche SMC-B im Konnektor
Thema drucken
17.05.2024 16:45
Antworten
