DE102015217359A1 - Netzgestütztes elektronisches Therapieüberwachungssystem - Google Patents

Netzgestütztes elektronisches Therapieüberwachungssystem Download PDF

Info

Publication number
DE102015217359A1
DE102015217359A1 DE102015217359.3A DE102015217359A DE102015217359A1 DE 102015217359 A1 DE102015217359 A1 DE 102015217359A1 DE 102015217359 A DE102015217359 A DE 102015217359A DE 102015217359 A1 DE102015217359 A1 DE 102015217359A1
Authority
DE
Germany
Prior art keywords
data
therapy
server
patient
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102015217359.3A
Other languages
English (en)
Inventor
Ulrich Moissl
Peter Eifler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fresenius Medical Care Deutschland GmbH
Original Assignee
Fresenius Medical Care Deutschland GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fresenius Medical Care Deutschland GmbH filed Critical Fresenius Medical Care Deutschland GmbH
Priority to DE102015217359.3A priority Critical patent/DE102015217359A1/de
Priority to US15/250,349 priority patent/US20170076069A1/en
Priority to PCT/EP2016/071278 priority patent/WO2017042320A1/de
Publication of DE102015217359A1 publication Critical patent/DE102015217359A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
    • G16Z99/00—Subject matter not provided for in other main groups of this subclass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Databases & Information Systems (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Biomedical Technology (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein netzgestütztes elektronisches Therapieüberwachungssystem (1). Das netzgestützte elektronische Therapieüberwachungssystem (1) weist ein Datenübertragungsnetzwerk auf, wobei das Datenübertragungsnetzwerk zumindest ein durch eine Firewall (FW) geschütztes Teilnetzwerk (TN) aufweist. Weiterhin weist das netzgestützte elektronische Therapieüberwachungssystem (1) zumindest einen Datenbankserver (DB) zur Speicherung von Patientendaten und Therapiedaten auf, wobei der Datenbankserver (DB) im geschützten Teilnetzwerk (TN) angeordnet ist. Zumindest ein Server (PR) ist außerhalb des geschützten Teilnetzwerks (TN) angeordnet, und zumindest ein Client (CL1, CL2, CL3), welcher einem Therapiegerät (TG1, TG2) und/oder einem Patienten (P1, P2, P3) zugeordnet ist, ist ebenfalls außerhalb des geschützten Teilnetzwerks (TN) angeordnet. Der Client (CL1, CL2, CL3) ist eingerichtet, um Therapiedaten und/oder Patientendaten mittels eines Push-Mechanismus an den Server (PR) zu übertragen, und der Datenbankserver (DB) ist eingerichtet, um Therapiedaten und/oder Patientendaten mittels eines Pull-Mechanismus von dem Server (PR) abzurufen.

Description

  • Hintergrund der Erfindung
  • In vielen Bereichen der Medizintechnik ist die Sicherheit von Patientendaten aber auch die Sicherheit von Geräten ein großes Problem.
  • So ist z.B. festzustellen, dass immer mehr Daten nicht mehr (nur) in Papierform gespeichert werden, sondern zunehmend auch elektronisch gespeichert und verarbeitet werden. Dies hat den Vorteil, dass nunmehr die entsprechenden Daten an vielen Orten und zu vielen Zwecken schnell verfügbar sind. Um dies zu ermöglichen, ist eine Vielzahl dieser Geräte untereinander über Datenübertragungsnetzwerke, wie z.B. das Internet, miteinander verbunden.
  • Allerdings steigt mit dem Grad der Vernetzung auch die Gefahr des missbräuchlichen Zugriffs.
  • Daher werden zahlreiche Vorkehrungen getroffen, um einen unerlaubten Zugriff auf Daten und Geräte zu unterbinden.
  • Beispielsweise werden sogenannte Firewalls eingesetzt. Firewalls bieten z.B. in Datenübertragungsnetzwerken wie dem Internet, die Möglichkeit, Zugriffsrichtungen als auch Zugriffsanwendungen zu beschränken. D.h. das Datenübertragungsnetzwerk wird damit in einen als geschützten Bereich angesehenen Bereich „hinter“ der Firewall und einen ungeschützten Bereich „vor“ der Firewall unterteilt.
  • Im Bereich der Medizintechnik werden Firewalls äußerst restriktiv eingestellt, sodass z.B. Zugriffe, die von außen veranlasst werden, blockiert werden. Zudem werden häufig auch nur selektive Anwendungen von innen nach außen zugelassen. Beispielsweise werden Zugriffe nur auf bestimmten Ports (entsprechend Anwendungen) zugelassen, um z.B. kritische Anwendungen in ihrer Nutzung durch Personal „hinter“ der Firewall einzuschränken oder gar vollständig zu unterbinden, um so zu verhindern, dass beispielsweise Schadsoftware auf Rechner hinter der Firewall eingeschleust werden kann.
  • Dabei ergibt sich das Problem, dass ein Zugriff von „außen“ praktisch nicht möglich ist und zugleich der Zugriff von „innen“ stark beschränkt ist.
  • Sollen nun Daten von Therapiegeräten und/oder Patienten, die außerhalb der Firewall befindlich sind, z.B. in eine Datenbank für Patientendaten und/oder Therapiedaten abgelegt werden, so ist der Zugriff nicht möglich.
  • Zwar wäre es im Prinzip möglich durch Öffnen der Zugriffsrichtung und / oder Öffnen der entsprechenden Ports dies zu ermöglichen, jedoch stehen hier die oben aufgezeigten Sicherheitsbedenken entgegen.
  • Gelegentlich wurde in der Vergangenheit versucht Behandlungsberichte per Email zu senden. Allerdings hat sich diese Form der Einzelübermittlung als nur bedingt geeignet erwiesen, da Patienten häufig falsche Ziele angegeben haben und Patienten häufig auch keine sichere Rückmeldung über den Eingang ihrer Behandlungsberichte an der richtigen Stelle erhalten haben.
  • Aufgabe
  • Es ist daher eine Aufgabe der Erfindung ein verbessertes netzgestütztes Therapiesystem zur Verfügung zu stellen, das auch unter erschwerten Netzwerkbedingungen eine sichere Kommunikation zur Verfügung stellt.
  • Kurzdarstellung der Erfindung
  • Die Aufgabe wird gelöst durch ein netzgestütztes elektronisches Therapieüberwachungssystem, welches ein Datenübertragungsnetzwerk aufweist. Das Datenübertragungsnetzwerk weist zumindest ein durch eine Firewall geschütztes Teilnetzwerk auf. Weiterhin weist das System zumindest einen Datenbankserver zur Speicherung von Patientendaten und Therapiedaten auf, wobei der Datenbankserver im geschützten Teilnetzwerk angeordnet ist. Zudem weist das System zumindest einen Server außerhalb des geschützten Teilnetzwerks auf. Weiterhin weist das System auch zumindest einen Client auf, welcher einem Therapiegerät und/oder einem Patienten zugeordnet ist, wobei der Client ebenfalls außerhalb des geschützten Teilnetzwerks angeordnet ist. Der Client ist eingerichtet, um Therapiedaten und/oder Patientendaten an den Server mittels eines Push-Mechanismus zu übertragen, und der Datenbankserver ist eingerichtet ist, um Therapiedaten und/oder Patientendaten von dem Server mittels eines Pull-Mechanismus abzurufen.
  • Die Aufgabe wird weiterhin durch entsprechende Verfahren auf dem Server bzw. dem Datenbankserver gelöst.
  • Weitere vorteilhafte Ausgestaltungen sind Gegenstand der abhängigen Ansprüche und der ausführlichen Beschreibung.
  • Kurzdarstellung der Figuren
  • Nachfolgend wird die Erfindung näher unter Bezugnahme auf die Figuren erläutert werden. In diesen zeigt:
  • 1 eine schematische Übersicht auf Systeme gemäß Ausführungsformen der Erfindung, und
  • 2 schematische Ablaufpläne für Verfahren gemäß Ausführungsformen der Erfindung.
  • Detaillierte Beschreibung
  • Nachfolgend wird die Erfindung eingehender unter Bezugnahme auf die Figur dargestellt werden. Dabei ist anzumerken, dass unterschiedliche Aspekte beschreiben werden, die jeweils einzeln oder in Kombination zum Einsatz kommen können. D.h. jeglicher Aspekt kann mit unterschiedlichen Ausführungsformen der Erfindung verwendet werden soweit nicht explizit als reine Alternative dargestellt.
  • Weiterhin wird nachfolgend der Einfachheit halber in aller Regel immer nur auf eine Entität Bezug genommen werden. Soweit nicht explizit vermerkt, kann die Erfindung aber auch jeweils mehrere der betroffenen Entitäten aufweisen. Insofern ist die Verwendung der Wörter „ein“, „eine“ und „eines“ nur als Hinweis darauf zu verstehen, dass in einer einfachen Ausführungsform zumindest eine Entität verwendet wird.
  • Ein erfindungsgemäßes netzgestütztes elektronisches Therapieüberwachungssystem 1 ist in 1 schematisch dargestellt. Das netzgestützte elektronische Therapieüberwachungssystem 1 weist ein Datenübertragungsnetzwerk auf. Dieses Datenübertragungsnetzwerk kann auf unterschiedlicher Basis zusammengesetzt sein und beispielsweise drahtlose Verbindungen als auch drahtgebunden Verbindungen aufweisen. D.h. die Hardware des Datenübertragungsnetzwerkes ist ohne Belang für die Erfindung. Ein beispielhaftes Datenübertagungsnetzwerk ist beispielsweise das Internet.
  • Typischerweise kann das Datenübertragungsnetzwerk in unterschiedliche Teilnetze eingeteilt werden. Solche Teilnetze sind z.B. lokale Netzwerke, wie Sie im Heimbereich, aber auch in Firmen und öffentlichen Einrichtungen für die Kommunikation zur Verfügung gestellt werden. Diese Teilnetzwerke können dann über Übergangspunkte mit anderen Netzwerken verbunden sein.
  • In unserem Beispiel weist das Datenübertragungsnetzwerk zumindest ein durch eine Firewall FW geschütztes Teilnetzwerk TN auf. Die Firewall FW ist beispielhaft durch eine gestrichelt Linie dargestellt.
  • Die Firewall FW schützt dabei, wie eingangs beschrieben, das Teilnetzwerk TN vor unerlaubten Zugriffen von außen, d.h. Zugriffe, die von außen initiiert werden, und kann zudem so konfiguriert sein, dass nur bestimmte Anwendungen von Innen nach Außen, d.h. aus dem Teilnetzwerk TN in den außerhalb liegenden Bereich des Datenübertragungsnetzwerks, gesendet werden können. Ein solches beispielhaft geschütztes Teilnetzwerk TN ist z.B. das Netzwerk eines Krankenhauses.
  • Weiterhin ist in dem erfindungsgemäßen System zumindest ein Datenbankserver DB zur Speicherung von Patientendaten und Therapiedaten vorgesehen, wobei der Datenbankserver DB im geschützten Teilnetzwerk TN angeordnet ist. Offensichtlich kann diese Funktion auch auf verschiedene Datenbankserver verteilt sein.
  • Da das Teilnetzwerk TN hinter einer Firewall geschützt angeordnet ist, ist es nicht ohne weiteres möglich Patientendaten und / oder Therapiedaten von außen an den Datenbankserver DB innerhalb des Teilnetzwerkes TN zu übertragen.
  • D.h. ein Client CL1, CL2, CL3, welcher einem Therapiegerät TG1, TG2 und/oder einem Patienten P1, P2, P3 zugeordnet, der ebenfalls außerhalb des geschützten Teilnetzwerks TN angeordnet ist, kann keine Daten von sich aus an den Datenbankserver DB senden.
  • Um dies zu ermöglich sieht die Erfindung weiterhin zumindest einen Server PR außerhalb des geschützten Teilnetzwerks TN vor.
  • Nunmehr kann zumindest ein Client CL1, CL2, CL3, welcher einem Therapiegerät TG1, TG2 und/oder einem Patienten P1, P2, P3 zugeordnet ist, Therapiedaten und/oder Patientendaten an den Server PR mittels eines Push-Mechanismus an den Server PR übertragen.
  • Der Datenbankserver DB hingegen ist so eingerichtet, dass Therapiedaten und/oder Patientendaten von dem Server PR mittels eines Pull-Mechanismus abgerufen werden können.
  • D.h. wenn z.B. das Therapiegerät TG1 ein (Heim-)Dialysegerät ist, könnten Daten in Bezug auf eine Dialysebehandlung während der Behandlung und/oder nach Abschluss einer Behandlung an den Server PR übertragen werden. Dabei können die Daten entweder automatisch erfasst sein und/oder manuell eingegeben werden.
  • Wenn z.B. ein Client CL1 in ein Therapiegerät TG1 integriert ist und nur zur Behandlung eines einzigen Patienten P1 gedacht ist, so kann z.B. eine direkte Zuordnung eines Patienten P1 zum Gerät TG1 vorgenommen werden. Nunmehr können die Daten automatisch erfasst werden und mittels des Datenübertragungsnetzwerkes an den Server PR übermittelt werden, ohne dass es einer Änderung der Firewall bedarf.
  • Wenn in der obigen Situation der Client CL1 nicht in ein Therapiegerät TG1 integriert wäre, könnte ein Patient P1 z.B. Daten bezüglich einer erfolgten Behandlung an den Server PR senden. Hierzu könnte beispielsweise eine App für ein Smartphone oder einen Tablet-Computer oder ein geeignetes WWW-Interface auf einer Seite in Zusammenhang mit den Server PR vorgesehen sein, sodass Daten in Bezug auf eine Behandlung eines Patienten nunmehr zunächst auf dem Server PR erfasst werden könnten. Natürlich können auch andere Wege der Informationsweiterleitung vorgesehen sein. Beispielsweise könnten die Daten auch mittels einer (vorformatierten) Email oder einem anderen (Text-)Nachrichtensystem, wie z.B. SMS, an den Server übermittelt werden.
  • Aber auch in Fällen, in den z.B. ein Dialysezentrum mehrere Patienten P2, P3, P4 an einem Therapiegerät TG2 behandelt, kann die Erfindung gleichermaßen eingesetzt werden. Hier kann z.B. eine Identifikation mittels Eingabe von Patientendaten oder Einlesen von Patientendaten (z.B. von einer Patientenkarte / elektronischen Gesundheitskarte, etc.) vor oder nach einer Behandlung erfolgen. Anschließend können die Daten in Bezug auf die Behandlung automatisch erfasst werden und mittels des Datenübertragungsnetzwerkes an den Server PR übermittelt werden, ohne dass es einer Änderung der Firewall bedarf.
  • D.h. Patient P2 kann direkt mit dem Client CL2 identifiziert werden, während bei Client CL3 zusätzlichen Angaben zur Identifikation des Patienten P3 oder P4 erforderlich sind, z.B. durch eine manuelle Eingabe von Patientendaten oder durch Einlesen einer Patientenkarte, etc.
  • Innerhalb dieser Anordnung kann nunmehr, da der Datenbankserver DB von Innen eine Abfrage an den Server PR startet, die Firewall FW „geöffnet“ werden. Somit kann die Integrität des geschützten Teilnetzwerkes TN gewahrt werden. Da der Zugriff von Ihnen stattfindet, kann auch ein geeigneter Port für die Übermittlung bereitgestellt werden. Beispielsweise kann die Abfrage seitens des Datenbankservers DB mittels SOAP oder REST auf einem geeignetem Port, wie z.B. Port 80 (http) oder 443 (https) oder einem anderen Port (z.B. 1143), implementiert sein.
  • In einer Ausgestaltung des Systems kann z.B. auch vorgesehen sein, dass sowohl ein Client CL1, CL2, CL3 als auch der Server PR alternativ oder zusätzlich dazu eingerichtet sind, um Therapiedaten und/oder Patientendaten verschlüsselt an den Server PR zu übertragen. Beispielhafte Verschlüsselungstechniken können dabei symmetrische oder unsymmetrische Verschlüsselungssysteme sein, insbesondere SSL-Schlüssel oder PGP-Schlüssel, die z.B. Verwendung in S/Mime, PGP/INLINE, PGP/MIME oder https Zugriffen finden. Diese Schlüssel können sowohl von einer Zertifizierungsstelle erstellt sein als auch eigen erstellt sein.
  • Somit kann gewährleistet werden, dass z.B. auch Patientendaten und/oder Therapiedaten im Datenübertragungsnetzwerk, das nicht durch die Firewall FW geschützt ist, sicher vor unberechtigtem Zugriff übermittelt werden können.
  • Alternativ oder zusätzlich kann natürlich auch vorgesehen sein, dass der Server PR und der Datenbankserver DB entsprechend eingerichtet sind, um Therapiedaten und/oder Patientendaten an den Datenbankserver DB mittels eines Pull-Mechanismus verschlüsselt zu übertragen.
  • Auch hier können in gleicher Weise gesicherte Verbindungen z.B. https, Verwendung finden.
  • In entsprechender Weise kann das System auch durch eine entsprechende programmtechnische Einrichtung von Geräten erreicht werden.
  • Beispielhaften Verfahren werden nunmehr in Zusammenhang mit der 2 erläutert werden.
  • Dabei sind verschiedene Verfahren so angeordnet, dass ein Ineinandergreifen von Schritten unterschiedlicher Verfahren ersichtlich werden kann. Während auf der linken Seite und in der Mitte Verfahren in Zusammenhang mit dem Server PR zu sehen sind, ist auf der rechten Seite ein Verfahren in Zusammenhang mit dem Datenbankserver DB dargestellt. Zur Unterscheidung ist die Firewall FW als gestrichelte Linie eingezeichnet, sodass Verfahren, die im „ungeschützten“ Bereich des Datenübertragungsnetzwerkes angeordnet sind, links von der Firewall FW dargestellt sind, während Verfahren, die im „geschützten“ Bereich des Datenübertragungsnetzwerkes, d.h. im Teilnetzwerk TN, angeordnet sind, rechts von der Firewall FW dargestellt sind. Dabei sind die Verfahrensschritte im Wesentlichen so angeordnet, dass Verfahrensschritte, die weiter unten angeordnet sind, zeitlich nachfolgend sind.
  • In einem erfindungsgemäßen Verfahren für einen Server PR in einem netzgestütztem elektronischem Therapiesystem 1 werden zunächst in einem Schritt 100 Therapiedaten und/oder Patientendaten von einem Client CL1, CL2, CL3 empfangen, wobei die Therapiedaten und/oder Patientendaten mittels eines Push-Mechanismus an den Server PR übertragen werden. Anschließend werden die so erhaltenen Daten in einer geeigneten Speichereinrichtung in einem Schritt 200 zwischengespeichert. Die Zwischenspeicherung kann so lange erfolgen, bis die Daten einmalig abgerufen wurden. Es kann aber auch vorgesehen sein, dass die Daten oder Teile der Daten, z.B. Daten ohne Patientenbezug, weiter gespeichert werden. Weiterhin kann vorgesehen sein, dass ein Löschen von Daten nach Abruf durch den Datenbankserver DB von diesem veranlasst gelöscht werden.
  • Nachdem die Daten zwischengespeichert sind, können weitere Daten empfangen werden. Natürlich können auch mehrere solcher Prozesse in Bezug auf mehrere Patienten parallel ablaufen. Daher wurde in 2 dieser Teilprozess als eigenständig aufgeführt. Wie bereits ausgeführt kann hier auch eine Patientenzuordnung dadurch gegeben sein, dass ein bestimmtes Therapiegerät, wie z.B. TG1 nur einem einzigen Patienten P1 zugeordnet ist.
  • Nunmehr kann in einem Schritt 300 eine Anfrage nach Therapiedaten und/oder Patientendaten von einem Datenbankserver DB empfangen werden. Anschließend können in einem Schritt 400 angefragte Therapiedaten und/oder Patientendate in Bezug auf den Patienten P1, P2, P3 und / oder den Client CL1, CL2, CL3 an den Datenbankserver DB gesendet werden.
  • Natürlich können auch mehrere solcher Prozesse in Bezug auf mehrere Patienten parallel ablaufen. Daher wurde in 2 dieser Teilprozess als eigenständig aufgeführt.
  • Ohne weiteres ist es natürlich auch möglich, dass Therapiedaten in Bezug auf einen Patienten, z.B. P1, an den Server PR ohne die Übermittlung von Patientendaten und nur mit Übermittlung von Daten in Bezug auf das Therapiegerät TG1 erfolgt. Dann ist z.B. in einer weiteren Datenbank (nicht dargestellt) eine Patienten-Therapiegeräte-Zuordnung hinterlegt (P1 <-> TG1), sodass auch eine Anfrage seitens des Datenbankservers DB nach Daten in Bezug auf eine bestimmten Patienten P1 zugordnet und bearbeitet werden können.
  • Aber auch in Fällen, in den z.B. ein Dialysezentrum mehrere Patienten P2, P3, P4 an einem Therapiegerät TG2 behandelt, kann die Erfindung gleichermaßen eingesetzt werden. Hier kann z.B. eine Identifikation mittels Eingabe von Patientendaten oder Einlesen von Patientendaten (z.B. von einer Patientenkarte / elektronischen Gesundheitskarte, etc.) vor oder nach einer Behandlung erfolgen. Anschließend können die Daten in Bezug auf die Behandlung automatisch erfasst werden und mittels des Datenübertragungsnetzwerkes an den Server PR übermittelt werden, ohne dass es einer Änderung der Firewall bedarf.
  • D.h. Patient P2 kann direkt mit dem Client CL2 identifiziert werden, während bei Client CL3 zusätzlichen Angaben zur Identifikation des Patienten P3 oder P4 erforderlich sind, z.B. durch eine manuelle Eingabe von Patientendaten oder durch Einlesen einer Patientenkarte, etc.
  • In gleicher Weise kann natürlich auch vorgesehen sein, dass z.B. ein bestimmter Client CL1, CL2, CL3 immer nur einem Patienten P1, P2, P3 oder immer nur einem Therapiegerät zugordnet ist. Dies kann z.B. durch eine entsprechend Konfiguration, z.B. mittels einer individuellen Kennzeichnung – beispielsweise ein entsprechender Cookie, eine Mobilfunknummer, etc. – bewerkstelligt werden. Offensichtlich kann eine solche Zuordnung bereits beim Empfangen oder Zwischenspeichern erfolgen. Genauso gut kann sie aber auch erst später bei einer Abfrage nach Daten erfolgen.
  • In einem entsprechenden erfindungsgemäßen Verfahren für einen Server PR in einem netzgestütztem elektronischem Therapiesystem 1 wird zunächst in einem Schritt 250 eine Anfrage nach Therapiedaten und/oder Patientendaten und/oder Daten einer Therapieeinrichtung an einen Server PR gesendet. Die Anfrage wird wie zuvor beschrieben von dem Server PR verarbeitet und in einem Schritt 450 werden die angefragten Therapiedaten und/oder Patientendaten in Bezug auf den Patienten P1, P2, P3 / Client CL1, CL2, CL3 von dem Server PR empfangen.
  • Natürlich kann auch vorgesehen sein, dass z.B. eine Zuordnung von Patienten P1, P2, P3 zu einem Therapiegerät TG1, TG2 und/oder Patienten P1, P2, P3 zu einem Client CL1, CL2, CL3 und/oder Client CL1, CL2, CL3 zu einem Therapiegerät TG1, TG2 auch innerhalb des geschützten Teilnetzwerkes TN vorgenommen wird. D.h. die zuvor in Zusammenhang mit dem Server PR beschrieben Zuordnungen können alternativ oder zusätzlich auch von dem Datenbank-server vorgenommen werden. D.h. das System erlaubt eine weitegehende Entkopplung von Patientendaten von Therapiedaten, sodass z.B. Patientendaten nur innerhalb des geschützten Teilnetzwerkes TN verbleiben können. Werden Daten einer Therapieeinrichtung übermittelt, so können z.B. ganze Datengruppen vorausgewählt undübertragen werden.
  • In einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens wird der Schritt des Sendens 250 einer Anfrage regelmäßig wiederholt. Hierzu kann z.B. eine geeignete Beding für eine Zeitablauf 550 implementiert sein, sodass das Verfahren regelmäßig, z.B. jeden Tag, wiederholt wird.
  • Insbesondere kann dabei vorgesehen sein, dass sich die Wiederholungsrate der Anfrage 250 an der Wiederholungsrate einer Therapie eines Patienten P1, P2, P3 orientiert oder dieser entspricht. D.h. wenn z.B. ein Patient P1 täglich eine Therapie bedarf, so wird täglich abgerufen, während ein Patient P2 nur alle 3 Tage eine Therapie bedürfen, die Abfrage nur alle 3 Tage stattfindet. Hierdurch kann die Netzwerklast durch unnötigen Verkehr vermindert werden. Zudem kann die Belastung des Servers PR reduziert werden, da dieser nun weniger Anfragen behandeln muss und z.B. Anfragen nach Daten in der Zwischenzeit, welche nicht vorhanden sind, nicht negativ beantworten muss.
  • Um die Sicherheit des Servers PR weiter zu erhöhen kann z.B. vorgesehen sein, dass der Datenbankserver DB sich erst gegenüber dem Server PR autorisieren muss. Hierzu kann vorgesehen sein, dass vor dem Senden in Schritt 400 der angefragten Therapiedaten und/oder Patientendaten in Schritt 400 der Zugriff durch Eingabe einer Passphrase in einem vorgelagerten Schritt 350 freigegeben werden muss. Natürlich kann auch vorgesehen sein, dass sobald der Schritt 350 einmalig erfolgreich erfolgt ist, diese Autorisierung für eine Abfrage-Sitzung und/oder einen vorbestimmten Zeitraum gültig ist und anschließend erneut erfolgen muss.
  • Weiterhin kann zudem vorgesehen sein, dass alternativ oder zusätzlich vor dem Empfang einer Anfrage nach Therapiedaten und/oder Patientendaten der Datenbankserver zunächst durch Port-Knocking in einem Schritt 225 der Pull-Port am Server aktivieret werden muss.
  • Durch eine derartige Maßnahme werden z.B. Denial-of-Service-Attacks verhindert, wie sie immer wieder festzustellen sind, um Server zum Zusammenbrechen zu bringen, oder dazu zu bringen einen Zugriff auf Daten zu gewähren. Hierdurch steigt die Verfügbarkeit des Systems und zudem wird die Sicherheit erhöht.
  • Weiterhin vorteilhaft kann vorgesehen sein, dass z.B. der Server PR weiterhin die Therapiedaten in Bezug auf das Therapiegerät TG1, TG2 auswertet, um zu bestimmen, ob eine Wartung des Therapiegerätes notwendig ist, wobei, wenn eine Wartung notwendig ist, ein entsprechender Hinweis zur Verfügung gestellt wird.
  • Hierdurch kann die Verfügbarkeit der Therapiegeräte und damit auch die Patienten-Compilance erhöht werden.
  • Dabei kann der Hinweis sowohl dem entsprechenden Clienten, z.B. integriert im Therapiegerät oder getrennt hiervon, und/oder einem Clienten von Wartungspersonal zur Verfügung gestellt werden. Natürlich bietet es sich an hierzu ebenfalls das Datenübertragungsnetzwerk zu verwenden. Beispielweise kann eine entsprechende Meldung auf einer WWW-seite oder einer App angezeigt werden. Alternativ oder zusätzlich kann aber auch vorgesehen sein, dass z.B. der Hinweis einem Wartungsdienstleister DL für das Therapiegerät TG1, TG2, TG3 zur Verfügung gestellt wird.
  • Offensichtlich ist für einen Hinweis an einen Wartungsdienstleister DL es nicht notwendig über Patientendaten zu verfügen. D.h. für die Erstellung von Hinweisen genügt es (anonyme) Therapiedaten in Bezug auf ein Therapiegerät auszuwerten. Hieraus kann z.B. abgeleitet werden, ob einzelne Teile ausgetauscht oder Verbrauchsmaterialien ergänzt werden müssen.
  • D.h. mittels der Erfindung wird es ermöglicht, dass (mobile) Clients nunmehr Daten an einen Datenbankserver in einem durch eine Firewall gesicherten klinischen Umfeld übertragen könne. Dabei fungiert der Server PR ähnlich wie ein Proxy-Server. Der Server PR kann dabei z.B. ein geeignet eingerichteter Web-server sein.
  • Mittels des Clients, der entweder in ein Therapiegerät integriert ist oder aber von einem Patienten oder anderen Personen bedient wird, können z.B. Behandlungsberichte an den Server PR weitergegeben werden.
  • Dabei ist vorteilhaft, dass in dem erfindungsgemäßen System die Weiterleitung der Daten in standardisierter Form ermöglicht wird und somit auch die Sicherheit der Datenübertragung steigt. D.h. ein Patient kann nunmehr sicher sein, dass seine Daten von dem Server PR auch erhalten wurden. Zudem erlaubt das System auch die statistische Analyse von Patientendaten. Dabei können z.B. Therapiedaten einer Vielzahl von Patienten und (anonymisierte) Patientendaten von dem Server PR abgerufen werden. D.h. anstatt des Datenbankservers DB können die Daten auch von einem weiteren Stelle mittels der selben oder ähnlicher Mechanismen abgerufen werden.
  • Ebenso ist es aber auch denkbar, dass derlei statistische Auswertungen auch auf dem Server PR selbst durchgeführt werden und lediglich die Ergebnisse bereitgestellt werden.

Claims (12)

  1. Netzgestütztes elektronisches Therapieüberwachungssystem (1) aufweisend • ein Datenübertragungsnetzwerk, wobei das Datenübertragungsnetzwerk zumindest ein durch eine Firewall (FW) geschütztes Teilnetzwerk (TN) aufweist, • zumindest einen Datenbankserver (DB) zur Speicherung von Patientendaten und Therapiedaten, wobei der Datenbankserver (DB) im geschützten Teilnetzwerk (TN) angeordnet ist, • zumindest einen Server (PR) außerhalb des geschützten Teilnetzwerks (TN), • zumindest einen Client (CL1, CL2, CL3), welcher einem Therapiegerät (TG1, TG2) und/oder einem Patienten (P1, P2, P3) zugeordnet ist, wobei der Client (CL1, CL2, CL3) ebenfalls außerhalb des geschützten Teilnetzwerks (TN) angeordnet ist, • wobei der Client (CL1, CL2, CL3) eingerichtet ist, um Therapiedaten und/oder Patientendaten mittels eines Push-Mechanismus an den Server (PR) zu übertragen, und • wobei der Datenbankserver (DB) eingerichtet ist, um Therapiedaten und/oder Patientendaten mittels eines Pull-Mechanismus von dem Server (PR) abzurufen.
  2. Netzgestütztes elektronisches Therapieüberwachungssystem (1) nach Anspruch 1, dadurch gekennzeichnet, dass der Client (CL1, CL2, CL3) und der Server (PR) eingerichtet sind, um Therapiedaten und/oder Patientendaten mittels eines Push-Mechanismus verschlüsselt an den Server (PR) zu übertragen.
  3. Netzgestütztes elektronisches Therapieüberwachungssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Server (PR) und der Datenbankserver (DB) eingerichtet sind, um Therapiedaten und/oder Patientendaten mittels eines Pull-Mechanismus verschlüsselt an den Datenbankserver (DB) zu übertragen
  4. Verfahren für einen Server (PR) in einem netzgestütztem elektronischem Therapiesystem (1) gemäß einem der Ansprüche 1 bis 3, aufweisend die Schritte: • empfangen (100) von Therapiedaten und/oder Patientendaten von einem Client (CL1, CL2, CL3), wobei die Therapiedaten und/oder Patientendaten mittels eines Push-Mechanismus an den Server (PR) übertragen werden, • zwischenspeichern (200) der empfangenen Therapiedaten und/oder Patientendaten, • empfangen (300) einer Anfrage nach Therapiedaten und/oder Patientendaten in Bezug auf den Patienten (P1, P2, P3) / Client (CL1, CL2, CL3) von einem Datenbankserver (DB), • senden (400) der angefragten Therapiedaten und/oder Patientendaten in Bezug auf den Patienten (P1, P2, P3) / Client (CL1, CL2, CL3) an den Datenbankserver (DB).
  5. Verfahren für einen Datenbankserver (DB) in einem netzgestütztem elektronischem Therapiesystem (1) gemäß einem der Ansprüche 1 bis 3, aufweisend die Schritte: • senden (250) einer Anfrage nach Therapiedaten und/oder Patientendaten in Bezug auf den Patienten (P1, P2, P3) / Client (CL1, CL2, CL3) und/oder Daten einer Therapieeinrichtung an einen Server (PR), • empfangen (450) der angefragten Therapiedaten und/oder Patientendaten in Bezug auf den Patienten / Client (CL1, CL2, CL3) von dem Server (PR).
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der Schritt des Sendens (250) einer Anfrage regelmäßig wiederholt wird (550).
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Wiederholungsrate der Wiederholungsrate einer Therapie eines Patienten (P1, P2, P3) entspricht.
  8. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass vor dem Senden (400) der angefragten Therapiedaten und/oder Patientendaten in Bezug auf den Patienten (P1, P2, P3) / Client (CL1, CL2, CL3) der Zugriff durch Eingabe einer Passphrase (350) freigegeben werden muss.
  9. Verfahren nach Anspruch 4 oder 8, dadurch gekennzeichnet, dass vor dem Empfang einer Anfrage nach Therapiedaten und/oder Patientendaten der Datenbankserver zunächst durch Port-Knocking (225) den Pull-Port am Server aktivieren muss.
  10. Verfahren nach Anspruch 4, 8 oder 9, dadurch gekennzeichnet, dass der Server (PR) weiterhin die Therapiedaten in Bezug auf das Therapiegerät (TG1, TG2) auswertet, um zu bestimmen, ob eine Wartung des Therapiegerätes notwendig ist, wobei, wenn eine Wartung notwendig ist, ein entsprechender Hinweis zur Verfügung gestellt wird.
  11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der Hinweis dem Client (CL1, CL2, CL3) zur Verfügung gestellt wird.
  12. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass der Hinweis einem Wartungsdienstleister (DL) für das Therapiegerät (TG1, TG2, TG3) zur Verfügung gestellt wird.
DE102015217359.3A 2015-09-10 2015-09-10 Netzgestütztes elektronisches Therapieüberwachungssystem Ceased DE102015217359A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102015217359.3A DE102015217359A1 (de) 2015-09-10 2015-09-10 Netzgestütztes elektronisches Therapieüberwachungssystem
US15/250,349 US20170076069A1 (en) 2015-09-10 2016-08-29 Secure network-based system for communication of clinical data
PCT/EP2016/071278 WO2017042320A1 (de) 2015-09-10 2016-09-09 Netzgestütztes elektronisches therapieüberwachungssystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102015217359.3A DE102015217359A1 (de) 2015-09-10 2015-09-10 Netzgestütztes elektronisches Therapieüberwachungssystem

Publications (1)

Publication Number Publication Date
DE102015217359A1 true DE102015217359A1 (de) 2017-03-16

Family

ID=56893976

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015217359.3A Ceased DE102015217359A1 (de) 2015-09-10 2015-09-10 Netzgestütztes elektronisches Therapieüberwachungssystem

Country Status (3)

Country Link
US (1) US20170076069A1 (de)
DE (1) DE102015217359A1 (de)
WO (1) WO2017042320A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011107795A1 (de) 2011-07-15 2013-01-17 Fresenius Medical Care Deutschland Gmbh Verfahren und Vorrichtung zur entfernten Überwachung und Steuerung von medizinischen Fluidmanagementgeräten
US10623188B2 (en) 2017-04-26 2020-04-14 Fresenius Medical Care Holdings, Inc. Securely distributing medical prescriptions
US11389575B2 (en) 2017-07-14 2022-07-19 Fresenius Medical Care Holdings, Inc. Prescription compatibility checking for a medical device
US11342073B2 (en) 2017-09-29 2022-05-24 Fresenius Medical Care Holdings, Inc. Transmitted display casting for medical devices
US11491270B2 (en) 2018-01-05 2022-11-08 Fresenius Medical Care Holdings, Inc. Non-touch communication with a dialysis machine using a connected health system
US20190327584A1 (en) 2018-04-18 2019-10-24 Fresenius Medical Care Holdings, Inc. Home Dialysis Management Using a Connected Health System Network
US11141518B2 (en) 2018-06-15 2021-10-12 Fresenius Medical Care Holdings, Inc. Smart connector for a medical device
US20200020443A1 (en) 2018-07-10 2020-01-16 Fresenius Medical Care Holdings, Inc. Remote monitoring of equipment associated with renal treatments
US10758660B2 (en) 2018-12-21 2020-09-01 Fresenius Medical Care Holdings, Inc. Dialysis system with artificial intelligence

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100138534A1 (en) * 2008-11-25 2010-06-03 Rishi Mutnuru Systems and methods for monitor an access gateway

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60126448T2 (de) * 2000-04-17 2007-06-14 Nec Corp. Verfahren und System zur Bereitstellung eines heimbasierten Gesundheitsdienstes
US20050144042A1 (en) * 2002-02-19 2005-06-30 David Joffe Associated systems and methods for managing biological data and providing data interpretation tools
US20100122336A1 (en) * 2004-11-22 2010-05-13 Elias Hunt Method and apparatus for two-way transmission of medical data
US20160004820A1 (en) * 2005-02-01 2016-01-07 Newsilike Media Group, Inc. Security facility for maintaining health care data pools
US8374925B2 (en) * 2005-04-29 2013-02-12 Abbott Diabetes Care Inc. Method and system for monitoring consumable item usage and providing replenishment thereof
US20100332245A1 (en) * 2006-11-30 2010-12-30 General Electric Company Integrated RFID sensor method and system
US20080249386A1 (en) * 2007-04-04 2008-10-09 Pronia Medical Systems, Llc Systems, Methods, and Computer Program Product for Improved Management of Medical Procedures for Patients on Medical Protocols
US8344847B2 (en) * 2009-07-09 2013-01-01 Medtronic Minimed, Inc. Coordination of control commands in a medical device system having at least one therapy delivery device and at least one wireless controller device
US20110154469A1 (en) * 2009-12-17 2011-06-23 At&T Intellectual Property Llp Methods, systems, and computer program products for access control services using source port filtering
US11244745B2 (en) * 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
CN102028990B (zh) * 2010-02-22 2013-05-29 缪学明 一种输液监测方法
US9852266B2 (en) * 2012-09-21 2017-12-26 Md Revolution, Inc. Interactive graphical user interfaces for implementing personalized health and wellness programs
US20140368352A1 (en) * 2013-06-12 2014-12-18 Authentidate Holding Corp. Method and system for automated interactive gateway system
US20150025449A1 (en) * 2013-07-22 2015-01-22 Fresenius Medical Care Holdings, Inc. Activating Peripheral Devices in a Dialysis System
US20150106123A1 (en) * 2013-10-15 2015-04-16 Parkland Center For Clinical Innovation Intelligent continuity of care information system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100138534A1 (en) * 2008-11-25 2010-06-03 Rishi Mutnuru Systems and methods for monitor an access gateway

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Deutschsprachige Wikipedia zum Begriff ftp (Software). 19.05.2015. URL: https://de.wikipedia.org/wiki/Ftp_(Software) [abgerufen am 11.01.2016] *
KRZYWINSKI, Martin: Port knocking from the inside out. 2003. URL: http://portknocking.org/docs/portknocking_an_introduction.pdf, Archiviert in archive org am 07.04.2015 [abgerufen am 11.01.2016] *

Also Published As

Publication number Publication date
WO2017042320A1 (de) 2017-03-16
US20170076069A1 (en) 2017-03-16

Similar Documents

Publication Publication Date Title
DE102015217359A1 (de) Netzgestütztes elektronisches Therapieüberwachungssystem
DE60222871T2 (de) Anordnung und Verfahren zum Schutz von Endbenutzerdaten
DE112004000428B4 (de) Verfahren und Systeme zum Verwalten von Sicherheitsrichtlinien
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
WO2001090855A1 (de) Verschlüsseln von abzuspeichernden daten in einem iv-system
DE102010044517A1 (de) Verfahren zur Zertifikats-basierten Authentisierung
DE102013221159B3 (de) Verfahren und System zum manipulationssicheren Bereitstellen mehrerer digitaler Zertifikate für mehrere öffentliche Schlüssel eines Geräts
DE10296511T5 (de) Verfahren und Einrichtung zum Überwachen der Benutzung eines Programms
DE102016206739A1 (de) Systeme und Verfahren zum Absichern einer Remotekonfiguration
EP3529967B1 (de) Verfahren zum verbinden von geräten mit der sogenannten cloud, computerprogramm mit einer implementation des verfahrens und verarbeitungseinheit zur ausführung des verfahrens
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
EP3151503B1 (de) Verfahren und system zur authentifizierung einer umgebenden web-anwendung durch eine einzubettende web-anwendung
EP3105898B1 (de) Verfahren zur kommunikation zwischen abgesicherten computersystemen sowie computernetz-infrastruktur
DE102018217964A1 (de) Verfahren und Vorrichtung zur Überwachung einer Datenkommunikation
DE102017105396A1 (de) System zum elektronischen Signieren eines Dokuments
DE102018102608A1 (de) Verfahren zur Benutzerverwaltung eines Feldgeräts
DE102015119687B4 (de) Verfahren zum Generieren und/oder Übertragen einer verschlüsselten Nachricht
DE102021000645B3 (de) Verfahren zur Überprüfung von kryptografischen Geheimnissen auf Gleichheit
EP2929672B1 (de) Arbeitsverfahren für ein system sowie system
EP3627755A1 (de) Verfahren für eine sichere kommunikation in einem kommunikationsnetzwerk mit einer vielzahl von einheiten mit unterschiedlichen sicherheitsniveaus
DE102018105495A1 (de) Verfahren und System zum Ermitteln einer Konfiguration einer Schnittstelle
EP3231150A1 (de) Verfahren und vorrichtung zur übertragung von daten in getrennten netzen
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
DE102005050336B4 (de) Verfahren und Anordnung zum Betreiben eines Sicherheitsgateways
EP1246391A1 (de) Verfahren und System zur kryptographischen Datenkommunikation mit mehreren Instanzen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0019000000

Ipc: G16Z0099000000

R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final