eRp auf einem Arbeitsplatz mit 2 Ärzten, 2 eHBA .. geht das??

[turbotm]

Hat das jemand zum Laufen bekommen?

Ein Arbeitsplatz (Terminal über RDP), auf diesem wird TM unter dem Benutzer Dr. A gestartet, eRp wird (von Dr A) erstellt und auch gleich aktiviert (ohne Komfort), die PIN vom eHBA von Dr. A wird am Arbeitsplatz stehenden Kartenterminal eingegeben. In diesem Kartenterminal stecken die eHBA von Dr. A und Dr. B.

An diesem Arbeitsplatz wird TM neu gestartet unter dem Benutzer Dr. B. Der erstellt ein eRp und will es aktivieren --> am unteren linken Fensterbereich erscheint: "Es ist ein Fehler beim Signieren aufgetreten"

Und das ist nur einer von vielen völlig unlogischen Problemen.
Wenn Dr. A angemeldet ist und ein eRp, das von Dr. B ausgestellt wurde über das eMuster-Center aktivieren will, dreht sich das Rädchen unten links zu Tode "Die E_Rezepte werden zum Signieren vorbereitet"

Es kann ja wohl nicht an der Koco Box resp. Infomodell liegen. aber welche Einstellungen bei TM könnten dafür verantwortlich sein?
Langsam gebe ich es auf. Könnte ja noch für 500€ einen Berater fragen, der dann geht, wenn es wieder nicht mehr funktioniert. Meine Wut sind inzwischen einem Heulen gewichen...

[INP]

Ja, etliche Male.

Das einzige "Ärgernis", der Arzt A muss sich auch als TM Benutzer Arzt A am Rechner anmelden und genau so bei Arzt B. Das heißt bei Rechnern die von unterschiedlichen Ärzten verwendet wird, immer den TM Benutzer Arzt A abmelden, und dann Arzt B anmelden. Komfortsignatur muss dafür nicht aktiviert sein, kann es aber.

Was nicht geht, ist das Rezept von Arzt B erstellt wurde, durch Arzt A zu signieren. Deshalb muss das Personal, was für beide Ärzte arbeitet, bei der vorbereiten des Rezeptes den Arzt vorher auswählen.

Jens

[turbotm]

Für Dr. A funktioniert alles.
Wenn Dr. B angemeldet ist, eine eAU ausgestellt hat und dann mit seinem Namen signieren will, kommt "Fehler 1044"
Ich finde ums gottverrecken nicht den Unteschied zwischen Dr A und Dr. B.
Dr. B hat keine eigene KIM Adresse, aber KIM wird als grün angezeigt, wenn man nachschaut... Das hat doch nichts miteinander zu tun?

[INP]

Ist den die KIM Adresse bei TM als Praxis oder auf dem Arzt registiert?

Der Fehler 1044 sage mir nichts, gibt es dazu einen Fehlermeldungstext?

Bitte mal den eHBA von Arzt A testweise aus dem KT entfernen, wenn Arzt B signieren will. Kommt dann der gleiche Fehler?

Jens

[turbotm]

Hallo Jens
Wenn Karte Dr. A nicht steckt kommt Hinweis: der für die Signatur notwendige eHBA wurde nicht im zugeordneten Kartenterminal gefunden..... alternativ signiren sie mit SMC-B.....

[turbotm]

Ob die KIM Adresse auf die Praxis oder Arzt registriert ist, weiß ich leider nicht mehr. Kann man das irgendwo sehen?
Und zu 1044 gibt es sonst nichts, auch nicht im Forum

[INP]

Einfach schauen unter:

Schritt 1: sonstiges - > Praxisdaten

Schritt 2: bei der Praxis schauen, also Zasatzdaten -> KIM-Zusatzdaten anklicken

Schritt 3: Dann bei den Ärzte schauen, wie Schritt 1 und dann jeweils auf den Artz gehen, auf "bearbeiten". Dann weiter wie bei Schritt 2

Wo sind die KIM Daten hinterlegt?

[pmortara]

Wurden denn die Zertifikate des eHBA von Arzt B schon freigeschaltet?

[INP]

Wurden denn die Zertifikate des eHBA von Arzt B schon freigeschaltet?

Ja, die Idee ist mir auch gerade gekommen. Oder die der eHBA ggf. durch zuviele PIN-Fehleingaben gesperrt?

Auch, ist der eHBA in TM hinterlegt?

[pmortara]

Wenn die PIN gesperrt ist, wird das i.d.R. auch so angezeigt. Fehler 1044 deutet eher auf die Zertifikate hin, d.h. die Online-Freischaltung ist noch nicht erfolgt.

Mit der Art und Weise wie die KIM Adresse eingerichtet ist, hat das jedenfalls nichts zu tun würde ich sagen!

[INP]

Wenn die PIN gesperrt ist, wird das i.d.R. auch so angezeigt. Fehler 1044 deutet eher auf die Zertifikate hin, d.h. die Online-Freischaltung ist noch nicht erfolgt.

Mit der Art und Weise wie die KIM Adresse eingerichtet ist, hat das jedenfalls nichts zu tun würde ich sagen!

Hallo!

Mit der eHBA haben Sie wahrscheinlich recht! Bisher hatten wir bei den von uns betreuten Praxen nur einmal den Fall, dass eine eHBA gesperrt war. Und das ist auch mehr als 1 Jahr her. Was da angezeigt wurde, als klare Fehlermeldung oder nur als nummerischen Fehlercode, weiß ich nicht mehr.

KIM: Ja, wahrscheinlich ist das nicht das ursprüngliche Problem. In den letzten Wochen haben wir zahlreiche Praxen, die wir normalerweise nicht betreuen, per Fernwartung die TI eingerichtet. Und bei Praxen mit mehr als einem Arzt war bei jeder 2. Praxis KIM mit SMC-B falsch eingerichtet. Und auch wenn es für die E-Rezepte nicht entscheidend ist, fällt es einem irgendwann mal auf die Füße.

Jens

[turbotm]

Schritt 1: sonstiges - > Praxisdaten
Schritt 2: bei der Praxis schauen, also Zasatzdaten -> KIM-Zusatzdaten anklicken: Hier sind ganz oben alle Ärzte aufgeführt

Schritt 3: Dann bei den Ärzte schauen, wie Schritt 1 und dann jeweils auf den Artz gehen, auf "bearbeiten". Dann weiter wie bei Schritt 2 --> hier steht ganz oben jeweils der angeklickte Arzt

Das muss ich tatsächlich prüfen, ob die Karte von Dr.B auch von jenem freigeschaltet wurde. Gesagt hatte sie es, aber wenn man nicht alles selbst macht...
Werde mich danach melden, aber schon einmal wieder so viel Dank

[DC19]

Guten Abend,

wir sind auch zwei Ärzte und nutzen ebenfalls einen Terminal Server.

Was spricht dagegen auf dem Client zwei RDP zu nutzen? So behält jeder Arzt seine Season, und die an-Abmeldung in TM wird obsolet.

Falls ich Ihr Anliegen richtig verstanden habe..

[FortiSecond]

Was spricht dagegen auf dem Client zwei RDP zu nutzen? So behält jeder Arzt seine Season, und die an-Abmeldung in TM wird obsolet.

Der "Gesunde Technikerverstand".

Angenommen, Sie nutzen nicht einen entsprechend präparierten Client (RDP-Verbindungsaufbau mit unterschiedlichen Client-Namen; unter Windows mit 2X-Client (bzw. Parallels Client seit Übernahme) oder bei linuxoidem System mit freeRDP/Remmina etc.) und nutzen auch nicht den weiter unten dargestellten "Trick" mit dem Erstellen einer Sitzung per Opfer-PC:

Prinzipiell erzeugen Sie das, was am normalen Client mit "Auf dieser Arbeitsstation läuft bereits..." verhindert werden soll (und muss).
So haben wir aus Sicht von TurboMed zwei Sitzungen unter demselben Clientnamen, aber unterschiedlichen Benutzern in TurboMed. Durch Letzteres umgeht man die Probleme mit identischen TM-Usern, aber durch die konkurrierenden Sitzungen entstehen neue und unter Umständen wirklich gefährliche Situationen.

Folgende Dinge sind allgemein zu bedenken bei sowas und müssen nicht zwingend für TM gültig sein. Die Nennung von TM-Eigenschaften dient nur der Veranschaulichung:
- TM öffnet in der Datenbank stationsbezogene Tabellen für Druckereinstellungen, Praxis-E-Mail, geöffnete Patienten usw.
Blockiert die Sitzung A eine Tabelle, kann es sein, dass TM in Sitzung B weiterarbeitet, aber Dinge nicht speichert
Praxis-E-Mail gehen an Stationsnamen. In welcher Sitzung soll die Nachricht aufploppen, welche soll sie als gelesen markieren
- Zwei Sitzungen nutzen im Hintergrund die TI-Funktionen in demselben Kontext/Infomodell, sei es KIM oder eHBA usw.
Konnektor kann das ab. Kartenleser auch. Aber kann TM das auf Dauer fehlerfrei abwickeln?
- Ebenfalls nicht auszuschließen ist eine "Wanderung" von Eingaben in den fremden Kontext, also z.B. Import in den jeweils in der anderen Sitzung geöffneten Patienten.
Ich habe schon Datenfehler gesehen, wenn EIN Client-PC sowohl lokal TM am laufen hat als auch zeitgleich per RDP am Server ein TM nutzt.

Das ist nur eine oberflächliche Betrachtung. TM ist für Terminalserver freigegeben und funktioniert unter Normalbedingungen = mit unterschiedlichen Client-Kontexten und unterschiedlichen TM-Nutzern.

Off-topic

So richtig auf die Spitze treibt folgende technisch machbare, aber vorsätzlich destruktive Konstellation:
- Vom selben Client zwei oder mehrere RDP-Sessions zu einem Terminalserver
- Anmeldung mit demselben Windows-Account am TS (Machbar? Ja, mit Multi-Session-Unterstützung, siehe TSplus - andere Wege sind möglich)
- TM-Start als tmuser in jeder der Sessions
Wenn das einen Tag lang bei normaler Arbeitslast klappt ohne Crash, Datenverlust und seltsames Verhalten, dann grenzt es an ein Wunder.

Aber zurück zu LÖSUNGEN:
1) 2X-Client nutzen und für die beiden Sessions unterschiedliche Clientnamen nutzen. Problem gelöst.
2) Von einem "überflüssigen" PC aus am RDP-Server anmelden und TM starten. Auf dem zu nutzenden PC diese Session übernehmen. Dann läuft die Windows-Sitzung samt TM (bis zu dessen Neustart) im Kontext des geopferten PC, der dann nicht genutzt werden sollte. Parallel dann eine zweite RDP- Sitzung ohne besondere Vorkehrungen starten, denn dort läuft TM dann im Kontext des Clients.

[DC19]

Jeder Arzt hat seine eigene Remote - Verknüpfung. Die Season können im Tag offen bleiben, und man kann Sie in jeden Raum mitnehmen…. Jeder Arzt hat seine eigene.
Und damit auf dem Server seinen eigenen Client, welche auch jeweils im Konnektor, TM , usw eingerichtet sind.

[DC19]

Was spricht dagegen auf dem Client zwei RDP zu nutzen? So behält jeder Arzt seine Season, und die an-Abmeldung in TM wird obsolet.

Der "Gesunde Technikerverstand".

Angenommen, Sie nutzen nicht einen entsprechend präparierten Client (RDP-Verbindungsaufbau mit unterschiedlichen Client-Namen; unter Windows mit 2X-Client (bzw. Parallels Client seit Übernahme) oder bei linuxoidem System mit freeRDP/Remmina etc.) und nutzen auch nicht den weiter unten dargestellten "Trick" mit dem Erstellen einer Sitzung per Opfer-PC:

Prinzipiell erzeugen Sie das, was am normalen Client mit "Auf dieser Arbeitsstation läuft bereits..." verhindert werden soll (und muss).
So haben wir aus Sicht von TurboMed zwei Sitzungen unter demselben Clientnamen, aber unterschiedlichen Benutzern in TurboMed. Durch Letzteres umgeht man die Probleme mit identischen TM-Usern, aber durch die konkurrierenden Sitzungen entstehen neue und unter Umständen wirklich gefährliche Situationen.

Folgende Dinge sind allgemein zu bedenken bei sowas und müssen nicht zwingend für TM gültig sein. Die Nennung von TM-Eigenschaften dient nur der Veranschaulichung:
- TM öffnet in der Datenbank stationsbezogene Tabellen für Druckereinstellungen, Praxis-E-Mail, geöffnete Patienten usw.
Blockiert die Sitzung A eine Tabelle, kann es sein, dass TM in Sitzung B weiterarbeitet, aber Dinge nicht speichert
Praxis-E-Mail gehen an Stationsnamen. In welcher Sitzung soll die Nachricht aufploppen, welche soll sie als gelesen markieren
- Zwei Sitzungen nutzen im Hintergrund die TI-Funktionen in demselben Kontext/Infomodell, sei es KIM oder eHBA usw.
Konnektor kann das ab. Kartenleser auch. Aber kann TM das auf Dauer fehlerfrei abwickeln?
- Ebenfalls nicht auszuschließen ist eine "Wanderung" von Eingaben in den fremden Kontext, also z.B. Import in den jeweils in der anderen Sitzung geöffneten Patienten.
Ich habe schon Datenfehler gesehen, wenn EIN Client-PC sowohl lokal TM am laufen hat als auch zeitgleich per RDP am Server ein TM nutzt.

Das ist nur eine oberflächliche Betrachtung. TM ist für Terminalserver freigegeben und funktioniert unter Normalbedingungen = mit unterschiedlichen Client-Kontexten und unterschiedlichen TM-Nutzern.

Off-topic

So richtig auf die Spitze treibt folgende technisch machbare, aber vorsätzlich destruktive Konstellation:
- Vom selben Client zwei oder mehrere RDP-Sessions zu einem Terminalserver
- Anmeldung mit demselben Windows-Account am TS (Machbar? Ja, mit Multi-Session-Unterstützung, siehe TSplus - andere Wege sind möglich)
- TM-Start als tmuser in jeder der Sessions
Wenn das einen Tag lang bei normaler Arbeitslast klappt ohne Crash, Datenverlust und seltsames Verhalten, dann grenzt es an ein Wunder.

Aber zurück zu LÖSUNGEN:
1) 2X-Client nutzen und für die beiden Sessions unterschiedliche Clientnamen nutzen. Problem gelöst.
2) Von einem "überflüssigen" PC aus am RDP-Server anmelden und TM starten. Auf dem zu nutzenden PC diese Session übernehmen. Dann läuft die Windows-Sitzung samt TM (bis zu dessen Neustart) im Kontext des geopferten PC, der dann nicht genutzt werden sollte. Parallel dann eine zweite RDP- Sitzung ohne besondere Vorkehrungen starten, denn dort läuft TM dann im Kontext des Clients.

Guten Abend,

ich habe mir Ihren Beitrag noch einmal durchgelesen und zweifle an unserer Realität der Arbeitsweise:-)

Warum muss ein PC (physisch - nicht virtuell) geopfert werden?

Wir arbeiten z.b. an einem physischen Rechner und haben auf diesen mehrere RDP Season offen/gestartet/geschlossen-aber nicht beendet. Beendet wird/soll am Arbeitstag-Ende. Jede Season ist einzeln einmalig konfiguriert (bis zur Konnektor Ebene - die physikalischen Clients). Die eine ist mit dem eHBA am Kartenterminal A konfiguriert, die andere zum eHBA am Kartenterminal B und je einem Arzt zugeordnet. Remote Desktop PIN (glaube so nannte sich der Punkt am Konnektor) ermöglicht die Signatur an anderen Geräten. Diese Seasons kann ich nach belieben an jeden Arbeitsplatz übernehmen (innerhalb des Praxisnetztes- ggf. Per VPN von sonst wo), und oder starten…. (Die physischen Clients müssen dabei im Infomodel richtig konfiguriert sein). Wenn ich zu Hause bin und Schwester X hat ein Problem, übernehme ich Ihre Arbeitsstation, oder die der Kollegin.

Wo ergeben sich bei dieser Denkweise grundsätzliche Probleme?

Teilweise arbeiten ich links und rechts mit zwei unterschiedlichen Seasons für nacharbeiten…. Auf einem großen Monitor an einem physischen Rechner. Eine dauerhafte „getrennte RDP Season“ übernimmt ohne administrative Rechte die ganzen USB Geräte (Scanner, HZV Key, EKG, ABI, Usw)

Neugieriges Nachfragen.

Ergänzung: eine RDP Season ist am iPAd für Hausbesuche… geht mittlerweile gut! Keine großen Nacharbeiten…

[FortiSecond]

@DC19

Vorweg: Die beschriebene Realität bei Ihnen "kenne ich so nicht" und würde unglaublich gern verstehen, warum das reibungslos klappt. Entweder übersehe ich seit der Jahrtausendwende einen megacoolen Kniff bzw. eine unglaublich raffinierte Programmierung innerhalb von TM (und das meine ich im positiven Sinne, weil ich die Funktionalität mehrfach schmerzlich vermisst habe und bis heute durchaus eine Verwendung dafür hätte), oder es ist einfach Zufall, dass das bisher gutgeht. Warum auch immer das so gut läuft - ich finde das spannend und überraschend.

Jetzt versuche ich erst einmal, mein Fragezeichen zu beschreiben...
(Vielleicht liege ich falsch, weil es die TSadmin (o.ä.) mit Einstellungen "pro Nutzer" und "pro Station" gibt und diese genau hier hilft...)

Konkret meine ich folgende Situation:
1)
>>1 Client, von dem aus 2 oder mehr RDP-Sitzungen per mstsc.exe zu einem Windows-Server mit der Rolle RDS aufgebaut wird und innerhalb derer (immer noch an diesem 1 Client) jeweils eine TM-Instanz mit unterschiedlichen TM-Benutzern gestartet wird<<
In dieser Konstellation haben alle Sitzungen auf ein und denselben Hostnamen. Sie sind im Infomodell EIN Arbeitsplatz.
TM sieht EINE Station.
Dennoch bleiben es getrennte Sitzungen, bei denen (zunächst) nur mit identischen (stationsbezogenen) Rechten auf TM-Funktionen und die TI zugegriffen wird. Diese Sitzungen stellen ihre eigenen Anfragen an die TI und bekommen die Antwort.
Bis hierhin klingt es harmlos, wenn man vom Lizenzverstoß RDS-CAL absieht (potenziell, muss nicht immer einer sein).

Wechselt Person B zu einer anderen Station 2 und übernimmt die laufende Sitzung, ist zwar für den Windows-Server der Hostname geändert, nicht aber innerhalb von TM. Zumindest der Erfahrung nach würden Nachrichten an den ursprünglichen Stationsnamen "1" dann (auch) in der übernommenen Sitzung an Platz "2" ankommen, die ja innerhalb von TM noch immer Station 1 ist.
Ebenso dürften die Druckereinstellungen von Station 2 nicht greifen, weil TM sich immer noch in der 1 wähnt.
Dafür aber (nutzerbezogen) die eHBA-Zuordnung.

2) Wenn nun Person B an Station 2 im TM-Kontext der Station 1 an Druckereinstellungen spielt, sollte sich das auf die Einstellungen an Station 1 auswirken, weil TM hier den Stationsnamen abgreift.

3) Die Umgehung wäre, die beiden oder mehr Sessions jeweils an einem anderen PC zu eröffnen, um in unterschiedlichen Kontexten unterwegs zu sein. Das "Opfern" bezieht sich darauf, dann diese PCs bei lokaler Nutzung einen Einfluss auf die TM-Einstellungen für den lokalen PC *und* die RDP-Session in ihrem jeweiligen PC-Kontext haben.

Aber... wenn angesichts von 0 tatsächlich nutzerbezogene Einstellungen unabhängig vom Arbeitsplatz/Hostnamen möglich sind, dann nimmt Nutzer tatsächlich "seine" Einstellungen überall mit hin. Was wiederum problematisch mit ortsbezogenen Druckerpräferenzen bedeuten würde UND gemäß Infomodell Probleme mit den lokalen Kartenlesern bringen würde...

Puh, sehe ich den Wald vor lauter Bäumen nicht?

[FortiSecond]

Nachtrag: Wird jeder RDP-Sitzung an einem separaten Platz gestartet?

[DC19]

Leider habe ich zu lange für die Antwort gebraucht, so dass mein ganzer Text weg ist: deshalb eine Kurzfassung:

Drucker sind zentral am Server konfiguriert. (dieser Steht im hintersten Zimmer). Die Drucker selbst stehen an der Anmeldung. Damit gibt es keine unterschiedliche Druckereinstellungen egal ob Client oder RDP….. Auch innerhalb von TM sind alle Benutzer und Ihre Drucker gleich konfiguriert. Lokale Clientdrucker (z.b. Homeoffice) können einzeln in der RDP Season ausgewählt werden. Die Standartdrucker sind aber praxisübergreifend fest.

Es ist egal wo an welchem Client Sie die RDP starten….. Wir starten aber so damit die Kollegin nicht durcheinander kommt:

An Client PC1 wird sowohl die RDP Season A mit lokalem Lesegerät A und eHBA von A gestartet, als auch die RDP Season B mit lokalem Lesegerät A, ABER eHBA von B in einem Lesegerät B was am Client PC 2 steht. An Client PC1 kann sowohl Arzt A als auch B mit dem Lesegerät A eine Komfortsignatur, Einzel oder Stapelsignatur durchführen.

Umgedreht geht dies am Client PC2 mit lokalem Lesegerät B mit eHBA von B für ARZT A und B und ihrer auf diesen PC eigenen arztbezogenen RDP Season.

Zur Übersicht haben die Schwestern am Client Anmeldung 1 die RDP Season Anmeldung 1. TM Nutzer Anmeldung 1.
Anmeldung 2 RDP 2 usw. Aber dies sind nur Namen.

Ich kann an jedem Client jede Praxis RDP Season übernehmen… ich kann an einem Client alle RDP Seasons gleichzeitig übernehmen/Starten. Es gibt nur die Limitierung auf der Arztseite bzgl. des Funktionsumfang der Ti. Hat der Arbeitsplatz ein Lesegerät - und oder Zuordnung, und kann ich da mit der Konfiguration eine Signatur machen, oder Einzel.

Zumindest ist dies eine Lösungsmöglichkeit für die initial gestellte Frage: 1. Client, 2 Ärzte die dort ggf. abwechselnd mit der Ti arbeiten wollen/müssen. Die Probleme mit den Geräten haben wir nicht, da alles am Server zentral und nicht lokal konfiguriert ist und angebunden. Wo die Geräte dann Stehen ist dann egal und eine Konzeptionsfrage.

[Nervenarzt]

Hört sich alles für mich sehr spannend an, aber wie "übernimmt" man eine RDP-Session ?
Ich arbeite mit Terminal/Client und Thinstuff....