ich interessiere mich dafür, was die Spezifikation zu der physischen und technischen Verbindung zwischen Primärsystem und Konnektor vorschreibt. Gibt es überhaupt Vorschriften? Oder kann man hier kreativ werden? Ist es z.B. vorgeschrieben, dass PS und Konnektor im gleichen physischen Netzwerk sein müssen (so würde ich mal LAN definieren) oder dürfen sie auch getrennt über ein VPN verbunden werden? Darf ich die Schnittstellen des Konnektors an einer öffentlichen IP zugänglich machen? Direkt über öffentliche IP, per Portweiterleitung oder per Reverse Proxy? Darf ich bei einer Webanwendung mit einem Server, auf dem mehrere Benutzer arbeiten den Server als Primärsystem definieren? Brauche dann also nur Verbindungen von den jeweiligen Konnektoren zum Server? Oder wird hier der eigentliche Client, sprich der Browser als Grenze des Primärsystems verstanden und wird eine Verbindung vom PC auf dem der Browser läuft zum Konnektor benötigen?
Ich hoffe, dass die Spezifikation hierzu Aussagen trifft und nicht alle Szenarien tatsächlich möglich wären. Denn einige widersprechen meinem Verständnis einer sicheren Umgebung für Gesundheitsdaten.
Über eine Antwort und Verweise an die jeweiligen Dokumente der Spezifikation würde ich mich sehr freuen. Gerne auch über eine Diskussion über die Interpretationsspielräume der Spezifikation ;-)
die erhoffte Antwort mit Verweis auf eine Spezifikation gibt es da leider nicht, weil unterschiedlichste Verantwortlichkeitsbereiche bei dem Thema betroffen sind - und daher nicht eine Stelle dazu eine normative Festlegung treffen kann. Bei den Festlegungen zum Konnektor endet die Regelungshoheit der gematik z.B. an der Außenschnittstelle des Konnektors. Wie dieser anschließend verwendet wird, liegt im Verantwortungsbereich der Leistungserbringerorganisation (also z.B. der Praxisinhaberin). Für diese gelten dann Festlegungen aus anderen Bereichen: Gesetze, IT-Richtlinie der KBV, Berufsvorschriften etc.
Was man sagen kann:
Der Konnektor bietet seine Schnittstelle im LAN an (lokale IP-Adressen).
Ein LAN kann per VPN über viele örtliche Einzelnetze gespannt werden.
Per Portforwarding kann das LAN-Interface des Konnektors technisch auch ins Internet bereitgestellt werden - das ist sicherheitstechnisch aber natürlich eine furchtbar dumme Idee und führt zu Haftungskonsequenzen für den Konnektor-Betreiber, wenn darüber dann unerlaubt Daten abgegriffen werden (Verstoß Datenschutz und Schweigepflicht).
Der Konnektor fungiert als Server. Aus seiner Sicht greift "irgendeine" Clientsoftware zu. Es muss als kein zertifiziertes PVS sein. Als Admin kann ich die Verwendung der Clientschnittstelle im Konnektor aber auf gewünschte Programme einschränken.
Die Nutzung des HBAs ist an "User" gebunden. Der Konnektor verlässt sich darauf, dass das aufrufende Clientsystem (aka PVS) eine ordentliche Benutzerverwaltung verwendet, damit immer nur der Inhaber des HBAs mit diesem interagiert. Der Konnektor unterstützt das Clientsystem dabei, in dem er für den erstmaligen Aufruf einer HBA-Funktion (bei der eine PIN eingegeben wird) und den nachfolgenden Nutzungsaufrufen identische User-IDs verlangt (durch das PVS beim erstmaligen Aufruf vergeben). Wenn das Clientsystem diese von ihm vergebe User-ID vertraulich behandelt, funktioniert es sicher. Mit vordefinierten User-IDs auf Clientseite nicht.
Für die Nutzung der Komfortsignatur verlangt der Konnektor mittlerweile UserIDs als UUID.
Von Gesetzes wegen muss jede Interaktion mit Patientendaten über den Konnektor auf Arztseite elektronisch dokumentiert werden: Wer hat wann auf welche Daten zugegriffen (ein warum wäre auch hilfreich). Dabei muss Bezug auf die konkrete Person genommen werden ("User4711" oder "MFA" geht nicht). Dies läuft wie gesagt außerhalb des Konnektors und ist eine gesetzliche Anforderung an den SMC-B-Inhaber (aka Praxisinhaber). Er muss entsprechend dafür Sorge tragen eine entsprechende Software einzusetzen.
Ich hoffe das hilft ein wenig... Wofür braucht Du es? Oder: Was genau soll erreicht / geklärt werden?
Vielen Dank für die Einordnung. Das deckt sich "leider" mit dem, was ich der Spezifikation entnommen habe. "Leider" deswegen, weil ich fürchte, dass es in gewissen Branchen von mobilen Anwendergruppen Anbieter geben wird, die dies nutzen und sicherheitstechnisch fragwürdige Konzepte mit Verträgen "absichern". Aus meiner Sicht hilft so ein Vertrag aber leider wenig, wenn es eine Sicherheitslücke bei diesem Anbieter gibt und damit das Vertrauen und die gesamte TI geschädigt wird. Weil ich eine eben solche Branche gut kenne und mit gut vorstellen könnte dass einige Anbieter eben genau so agieren, wird dort die Marktsituation Anbieter ggf. benachteiligen, die bessere Sicherheitskonzepte verfolgen und damit einen Bruch in der User Experience in Kauf nehmen müssten und/oder sehr viel mehr Arbeit für die Umsetzung leisten müssten. Jetzt kann man sagen, dass der Markt entscheidet und die Nutzer sich für das bessere Sicherheitskonzept entscheiden werden, ich bin allerdings überzeugt, dass in der besagten Branche das technische Gefühl für Sicherheit nicht vorhanden ist und die bessere User Experience gewinnt.
Verständlicherweise kann die Gematik nicht regulatorisch in die Anbindung zwischen Client und Konnektor eingreifen, aber damit wird begünstigt, dass es für reale Probleme kreative Lösungen geben wird, die Sicherheitsaspekte umgehen um Lösungen zu schaffen, die eigentlich einer anderen Spezifikation (siehe TI 2.0) bedürfen.
Zitat von MLangguth im Beitrag #2die erhoffte Antwort mit Verweis auf eine Spezifikation gibt es da leider nicht
Meinem Verständnis nach: doch schon, die kommt nur zu keinem anderen Ergebnis. gemKPT_Arch_TIP V2.10.0, Fußnote 1 unterhalb der Tabelle 1: "Die Kommunikation innerhalb der Consumer Zone unterliegt nicht der Regelungshoheit der Telematikinfrastruktur." Kombiniert man das mit Abbildung 10 im gleichen Dokument, ist klar zu erkennen, dass das TI-Nutzer-LAN, über das die fragliche Verbindung geführt wird, in eben dieser Consumer Zone liegt. (Das macht es nicht schöner, aber man kann wenigstens aufhören zu suchen :-))
Was ich meinte, ist an der Stelle nicht relevant - es handelt sich um ein Zitat.
Ich weiß nicht, wie es anderen Teilnehmern geht, aber ich hab hier bei der Anmeldung sowas "unterschrieben":
Ich verstehe und willige darin ein, dass dieses Forum dem konstruktiven und wertschätzenden Austausch zur TI dient. Es soll alle, die sich aktiv an der TI-Community beteiligen, weiterbringen.
Grundsatzfragen über die Sinnhaftigkeit der TI an sich oder ihrer Architektur werde ich in diesem Forum entsprechend nicht stellen, denn das bringt uns hier nicht weiter, da diese Punkte weder hier noch zeitnah geändert werden können. Diese Themen diskutiere ich bei Bedarf entsprechend außerhalb dieses Forums, z.B. auf Twitter. Auch werde ich kein Bashing, Spott oder Sarkasmus zur TI oder den TI-Beteiligten betreiben, denn auch das bringt uns nicht weiter.
Jeder vergreift sich mal im Tonfall - ich nehme mich selbst nicht aus. In der Masse und Schärfe finde ich das aber nicht mehr konstruktiv, und wen das weiterbringen soll, verstehe ich gerade nicht.
3 Mitglieder finden das Top!
3 Mitglieder haben sich bedankt!
Zitat von FS007 im Beitrag #9Könnte man in diesem Forum nicht wenigstens einen Ordner einrichten, indem man sich über die "grundsätzliche Sinnhaftigkeit", Anwendbarkeit, politische Hintergründe, Struktur, Organisation, etc. dieses weltbesten Telematikprojektes austauschen kann ?
Die einfache Antwort lautet: Nein.
Wie bereits zuvor dargestellt dient das Forum einem konstruktivem Austausch zur Etablierung und Nutzung der TI. Diese Regeln hat jeder bei der Anmeldung "unterschrieben" - auch Sie. Es steht jedem frei sich einen Ort im Internet zu suchen oder aufzubauen, wo die von Ihnen gewünschte Richtung diskutiert werde kann. TI-Community ist jedoch nicht der richtige Ort dafür.
Von daher bitte wieder zum konstruktiven Austausch zurückfinden.
Man kann auch schwache Basiskonzepte sowie schlechte konkrete Umsetzungen konstruktiv diskutieren, um Verbesserungsmöglichkeiten sowie Workaround herauszuarbeiten. Ein "Abfackeln" der Lösung zu verlangen ist hingegen weder konstruktiv noch in irgendeiner Form hilfreich für andere. Das manche den Bedarf dazu verspüren kann ich wirklich verstehen. Ist nur menschlich. Aber wie gesagt: Nicht in diesem Forum, dann nur zum "auskotzen" ist es nicht gedacht. Dafür bitte einen anderen Ort suchen.
Sie haben die TI mit ihren Anwendungen in Ihrer Praxis am Laufen? Super! Wenn Kollegen dabei Probleme haben, können sie helfen (haben Sie ja auch schon). Ist konstruktiv und hilfreich. Sie sehen die Bedienung der ePA als umständlich? Gerne konkret benennen an welcher Stelle / in welchem Prozessschritt / in welcher Alltagssituation. Dann lässt sich dazu eventuell eine Lösung finden - oder dieser konkrete Punkt kann dann an die gematik bzw. die Hersteller weitergeleitet werden (wer auch immer gerade bei dem Punkt dann der richtige Ansprechpartner ist). Auch das ist dann überaus konstruktiv - denn diese Form des Austauschs und der Informationssammlung von konkreten Problemen und von dem was schon gut funktioniert gibt es (nach meinem Wissen) bislang nicht.
Ich kann jetzt leider nicht viel schreiben, sehe die Punkte aber weitgehend wie Sie. Das interessante: Soweit ich sehen konnte betrifft keiner der Punkte die gematik - weder im Regelungs- noch Verantwortungsbereich. Vielmehr sind die PVS-Hersteller selbst betroffen, die gemäß Vorgaben nicht der Regelungshoheit der gematik unterliegen sondern nur von der KBV zertifiziert werden. Hier muss mehr passieren - was auch mehr Zeit für die Hersteller beinhaltet. Ich denke, oder hoffe, wirklich, dass ein Zusammentragen konkreter Punkte hier Verbesserung bringen kann. Dort sind dann neben gematik auch KBV & bvitg die Ansprechpartner. Damit das klappt ist es immer gut noch konkretere Beispiele zu haben: Welche Fehlermeldung in welcher Situation war schlecht? Welcher Use Case braucht gemessen wieviel zu lange? Leider macht diese Form des "Berichtens" für die Nutzergruppen sehr viel zusätzliche Arbeit. Nur befürchte ich, dass es ohne solch konkreten Punkte nicht wirklich besser wird (ohne System/Strukturänderung).
Auf einen Wegfall des Konnektors IN DER PRAXIS zu hoffen, wird jedoch keins der Problems lösen. Also wirklich buchstäblich 0.
TI-Community
»
Hersteller- und Zulassungsthemen
»
Konzepte, Spezifikationen, Richtlinie
»
Primärsystem Verbindung Konnektor
Thema drucken
23.08.2021 21:47
Antworten
