DE202021100647U1 - Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token - Google Patents

Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token Download PDF

Info

Publication number
DE202021100647U1
DE202021100647U1 DE202021100647.1U DE202021100647U DE202021100647U1 DE 202021100647 U1 DE202021100647 U1 DE 202021100647U1 DE 202021100647 U DE202021100647 U DE 202021100647U DE 202021100647 U1 DE202021100647 U1 DE 202021100647U1
Authority
DE
Germany
Prior art keywords
data
sensitive
token
pdas
personal data
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.)
Active
Application number
DE202021100647.1U
Other languages
English (en)
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.)
Biotronik SE and Co KG
Original Assignee
Biotronik SE and Co KG
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 Biotronik SE and Co KG filed Critical Biotronik SE and Co KG
Priority to DE202021100647.1U priority Critical patent/DE202021100647U1/de
Publication of DE202021100647U1 publication Critical patent/DE202021100647U1/de
Priority to US18/263,736 priority patent/US20240119174A1/en
Priority to PCT/EP2022/052524 priority patent/WO2022171509A1/en
Priority to EP22706757.6A priority patent/EP4292003A1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Einrichtung (120) zum Schutz sensibler personenbezogener Daten, die in öffentlichen Speichern (130) verwaltet werden, aufweisend:
- ein vertrauenswürdiges Tokenisierungs-System mit mindestens einer vertrauenswürdigen Schnittstelle zu einer Instanz, die sensible personenbezogene Daten zur Verfügung stellen, verarbeiten, besitzen und/oder abrufen darf, und
- mindestens eine Schnittstelle zu einem öffentlichen Speicher (130), der keine sensiblen personenbezogenen Daten beinhaltet, wobei das Tokenisierungs-System dazu konfiguriert ist, den sensitiven Personenbezug der Daten in den öffentlichen Speichersystemen durch ein nicht-sensitives Datenelement (5) zu ersetzen und die Zuordnung zwischen sensitivem Personenbezug und nicht-sensitivem Datenelement in einer gesicherten Umgebung (160) abzuspeichern, wobei das nicht-sensitive Datenelement (5) anwenderspezifisch generiert wird, so dass das nicht-sensitive Datenelement (5) in einer vorhandenen Infrastruktur des Anwenders ohne Anpassung dieser Infrastruktur verarbeitbar ist.

Description

  • Die Erfindung beschreibt eine Einrichtung und ein Verfahren, um sensible persönliche Daten in öffentlichen Speichersystemen verwalten zu können, ohne dass dabei eine unautorisierte persönliche Datenzuordnung möglich ist.
  • Es gibt immer mehr externe Cloud-Anbieter und Dienstleister, die an großen Mengen von personenbezogenen Daten (z.B. Gesundheitsdaten) interessiert sind, diese verwalten können, heterogene Daten migrieren können sowie diese Daten z.B. mittels Machine Learning verarbeiten wollen, um beispielsweise für Ärzte eine verbesserte Diagnoseunterstützung zu liefern. Solche Cloud-Dienstleister sind u.a. allgemeine öffentliche Clouds (beispielsweise von Google oder Apple) oder spezifische Health-Provider Clouds (beispielsweise von Cerner, Epic oder von Krankenkassen). Bei diesen Cloud-Anbietern besteht grundsätzlich das Risiko der Offenlegung der gesammelten Patientendaten oder deren Verfälschung, sowie rechtliche Limitationen, personenbezogene Daten zu verarbeiten.
  • Die vorgenannten Probleme werden im Stand der Technik z. B. durch
    • - die Verschlüsselung der abgelegten Daten, oder
    • - die Verwendung geschlossener Systeme zur Speicherung von sensiblen personenbezogenen Daten vermieden.
  • Derartige bekannte Lösungen können jedoch - durch die Notwendigkeit des vertrauenswürdigen Umgangs mit sensiblen personenbezogenen Daten - nicht die Vorteile großer nicht-vertrauenswürdiger Datendienste, wie Cloud-Speicher und öffentliche Big-Data Systeme nutzen.
  • Der Erfindung liegt daher die Aufgabe zugrunde eine Einrichtung bzw. ein Personendatenanonymisierungssystem (PDAS) bereitzustellen, das hinsichtlich der vorgenannten Problematik verbessert ist. Insbesondere soll ein PDAS zur sicheren Lieferung von unverfälschten und hinreichend anonymisierten personenbezogenen Daten, vorzugsweise Gesundheitsdaten (vgl. auch HIPAA-Compliance) für die entsprechenden externen Cloud-Dienstleister bereitgestellt werden. Insbesondere sollen nur von der Person bzw. dem Patienten autorisierte Daten an externe Dienstleister geschickt werden können, so zum Beispiel an eine „low risk“ Krankenkassen-Cloud andere oder weniger anonymisierte Personendaten, als an eine öffentliche „high risk“ Health-Cloud z.B. von Google.
  • Insbesondere soll nur die erfindungsgemäße Einrichtung (PDAS) die Zuordnung der Person zu allen ihren Datenelementen leisten können und auch nur Teilmengen dieser Daten, nach Freigabe der Person, an entsprechende externe Stellen herausgeben. Außerdem soll die Integrität jedes gespeicherten Datenelements gesichert werden.
  • Die vorstehend dargelegte Aufgabe wird durch eine Einrichtung mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen dieses Erfindungsaspekts sowie weitere Aspekte der Erfindung werden nachfolgend beschrieben.
  • Gemäß Anspruch 1 wird eine Einrichtung zum Schutz sensibler personenbezogener Daten offenbart, die in öffentlichen Speichersystemen verwaltet werden, aufweisend:
    • - ein vertrauenswürdiges Tokenisierung-System mit mindestens einer vertrauenswürdigen Schnittstelle zu einer Instanz, die sensible personenbezogene Daten zur Verfügung stellen, verarbeiten, besitzen und/oder abrufen darf, und
    • - mindestens eine Schnittstelle zu einem öffentlichen (d.h. nicht-vertrauenswürdigen) Speicher, der keine sensiblen personenbezogenen Daten beinhalten darf,
    wobei das Tokenisierung-System dazu konfiguriert ist, den sensitiven Personenbezug der Daten in den öffentlichen Speichersystemen durch ein nicht-sensitives Datenelement (Token) zu ersetzen und die Zuordnung zwischen sensitivem Personenbezug und Token in einer gesicherten Umgebung abzuspeichern, wobei das Token anwenderspezifisch bzw. kundenspezifisch (individuell) generiert wird, so dass das Token in einer vorhandenen Infrastruktur des Anwenders bzw. Kunden ohne Anpassung dieser Infrastruktur verarbeitbar ist. Die erfindungsgemäße Einrichtung wird vorliegend auch als Personendatenanonymisierungssystem (PDAS) bezeichnet.
  • Die Erfindung betrifft mit anderen Worten eine Einrichtung (PDAS), die es gestattet, sensible persönliche Daten in öffentlichen Speichersystemen zu verwalten, ohne dass dabei eine unautorisierte persönliche Datenzuordnung möglich ist, indem der sensitive Personenbezug der Daten in den öffentlichen Speichersystemen durch ein nicht-sensitives, kundenspezifisches Datenelement (Token) ersetzt wird und die Zuordnung zwischen sensitivem Personenbezug und nicht-sensitivem Datenelement in einer gesicherten und autorisierten Umgebung hergestellt wird.
  • Die Erfindung gestattet daher mit Vorteil, dass sensible personenbezogene Daten in einem nicht-vertrauenswürdigen Speicher offen (d.h. unverschlüsselt) abgelegt werden können, ohne dass dabei ein Bezug zur jeweiligen Person möglich ist, dieser jedoch in einer vertrauenswürdigen Umgebung wieder hergestellt werden kann, so dass die die individuellen Daten zur Verfügung stellenden Personen von den Ergebnissen der Datenanalysen durch die o.g. Systeme profitieren können.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung sind die personenbezogenen Daten Gesundheits- bzw. Patientendaten.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass die Einrichtung ein Rechtesystem für Datenzugriffe aufweist, das vorzugsweise konfigurierbar ist.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass eine Verwaltung/Zuordnung verteilter Datenelemente pro Person möglich ist.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass mehrere Token für verschiedene Anwendungsfälle (Use Cases) generierbar sind.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass eine zusätzliche Verschlüsselung / Signierung der Daten vorgesehen ist.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass die Einrichtung zur Verhinderung einer Verfälschung von Daten ausgestaltet ist.
  • Weiterhin ist gemäß einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass die Einrichtung zur Verhinderung einer falschen Zuordnung von Daten ausgestaltet ist.
  • Schließlich ist gemäß einer weiteren Ausführungsform der Erfindung vorgesehen, dass die Einrichtung zur Einbeziehung der Person / des Patienten als zentrale Datenfreigabe-Instanz eingerichtet ist.
  • Die technische Lösung der vorliegenden Erfindung basiert auf dem Konzept der sogenannten Tokenisierung: Darunter wird verstanden, dass sensible persondenidentifizierende Information, also die Personen-ID (z.B. Name + Vorname + Geburtsdatum + Wohnort), durch Referenzwerte, sogenannte Token, ersetzt werden. Ein Token kann ohne Einschränkung von externen Systemen und Anwendungen genutzt werden, während der Personenbezug zu diesem Token in einem sicheren Datentresor abgelegt wird. Die externen Cloud-Dienstleister müssen also keine sensiblen personenidentifizierenden Daten speichern, um personenbezogene Gesundheitsdaten auszuwerten. Die Tokenisierung kann also, wenn sie auf die Datensicherheit angewendet wird, als ein Prozess des Ersetzens eines sensiblen Datenelements durch ein nicht-sensibles Äquivalent verstanden werden, das als Token bezeichnet wird und keine extrinsische oder ausnutzbare Bedeutung oder Wert hat. Das Token ist eine Referenz (d.h. eine Kennung), die über ein Tokenisierungssystem auf die sensiblen Daten zurückgeführt wird. Bei der Abbildung von Originaldaten auf ein Token werden Methoden verwendet, die eine Umkehrung der Token in Abwesenheit des Tokenisierungssystems unmöglich machen.
  • Die erfindungsgemäße Einrichtung bzw. Personendatenanonymisierungssystem (PDAS) ermöglicht es einer Person (anonymisiert durch ein Token) zu einem Zeitpunkt die Herausgabe bestimmter Daten aus dem PDAS z.B. an einen Cloud-Dienstleister zu autorisieren. Das PDAS soll dabei Zugriff auf alle externen Speicher haben, auf denen die „tokenisierten“ Personendaten liegen. Es soll ferner die herauszugebenen Datenelemente sicher Zwischenspeichern können sowie die Zuordnung des Tokens zu einer Personen-ID sicher durchführen können. Dies gestattet es dem PDAS die gewünschten Patientendaten, passend zu dem angefragten Token, an den Cloud-Dienstleister herauszugeben. Dabei tritt die Person dem Cloud-Dienstleister nur anonymisiert, also in Form eines eindeutigen Tokens, gegenüber. Die Auflösung Token zu Person kann nur das PDAS leisten. Nichtsdestotrotz erhalten die Cloud-Dienstleister personenbezogene Daten (d.h. Daten einer anonymen Person), welche sie z.B. für Machine Learning Applikationen nutzen können.
  • Die Person kann z.B. per Smartphone-App nur die Herausgabe bestimmter anonymisierter Datenelemente für einen bestimmten externen Cloud-Dienstleister autorisieren. (Die Werte der Datenelemente liegen in weiteren externen Speichern (z.B. private Klinik-Cloud) aber nicht auf dem Smartphone der Person). Hierbei kann ein zweiter Faktor zur Bestätigung der Herausgabe dieser Daten vorliegen, z.B. durch einen Fingerabdruck, eine Face-ID, einen implantierten Ausweis, der per Smartphone NFC ausgelesen werden kann, eine Autorisierungsserver-Schnittstelle (wie z.B. Google Authenticator).
  • Weiterhin kann die Person bestimmte Verwendungszwecke dieser Daten autorisieren (z.B. Zuführung in ein Machine Learning System, jedoch keine Speicherung in Datenbanken für klinische Studien) und andere ausschließen.
  • Ferner hat die Person jederzeit das Recht zur Löschung seiner Token-zu-Person Beziehung aus dem PDAS.
  • Zusätzlich zum PDAS kann eine Datenbank vorhanden sein, welche alle Personendaten enthält und diese sicher (z.B. verschlüsselt und/oder signiert) speichert. Das bedeutet, dass die Daten somit vertraulich, integer und verfügbar gespeichert sind. Werden Daten aus dieser Datenbank abgefragt (z.B. aufgrund einer Cloud-Dienstleister Anfrage an das PDAS), dann kann dieses Abfrageergebnis, also die angeforderten Datenelemente, automatisch mit einer kryptografischen Prüfsumme (Signatur) versehen werden, für welche ein Zertifikat (zur Signaturprüfung) zusammen mit dem Abfrageergebnis nach außen gegeben wird und die Daten somit jederzeit auf Integrität (Unverfälschtheit) überprüft werden können.
  • Grundsätzlich, wenn nicht ausdrücklich durch die Person freigegeben, werden durch das PDAS bevorzugt nur anonymisierte Daten an externe Systeme gegeben. Das sind vorzugsweise mindestens HIPAA-konforme und/oder DSGVO-konforme Anonymisierungen (z.B. sollen niemals Namen, Sexualität, Religion oder Parteizugehörigkeiten zu einem Token nach außen gegeben werden). Neben den HIPAA- und DSGVO-Regeln zur Anonymisierung von extern angefragten Datensätzen können weitere Regeln implementiert werden, z.B. eine seltene Krankheit kombiniert mit einer seltenen Blutgruppe einer Person darf auch nicht uneingeschränkt oder erst nach einer zweiten Zustimmung durch die Person nach Außen gegeben werden. Es ist denkbar weitere Anonymisierungsregeln umzusetzen.
  • Da die Person die Herausgabe bestimmter Daten nur zu einem bestimmten Zeitpunkt gewünscht und z.B. per Smartphone und zweitem Faktor autorisiert hat, soll es vorzugsweise nicht möglich sein, ihre Daten durch eine Replay-Attacke auch z.B. Jahre später den damals gewählten Cloud-Dienstleistern zur Verfügung zu stellen. Dazu wird vorzugsweise jede Transaktion zusätzlich durch einen einmaligen dynamischen Sicherheitscode autorisiert.
  • Weiterhin kann vorgesehen sein, dass wenn eine Person beim PDAS ein Token anfragt, die Person nicht nur das Token, sondern zusätzlich auch einen Token-Key (technisch: ein Public Key) zurückbekommt. Mit jeder Transaktion, also der Beauftragung bestimmte Datenelemente (identifiziert durch Datenelement-IDs) an einen Cloud-Dienstleister zu senden, welche die Person auslöst, werden dann nicht nur das Token und die zugehörigen autorisierten Datenelement-IDs versendet, sondern auch ein für die Transaktion eindeutiger und nur für eine bestimmte Zeitspanne (z.B. 10 Minuten) gültiger Sicherheitscode, verschlüsselt mit dem Token-Key. Der Sicherheitscode ist ein mit dem Token-Key verschlüsselter Hashwert aus: Token + zu sendende Datenelement-IDs + minutengenauer Time-Stamp + IP-Adresse der Person + evtl. weiteren transaktionsspezifischen Details.
  • Der Cloud-Dienstleister erhält die Transaktionsdaten von der Person bzw. ihrem Smartphone. Dann leitet der Cloud-Dienstleister diese Daten sowie die IP-Adresse des Smartphones der Person an das PDAS weiter. Dort wird die Transaktion mittels des verschlüsselten Hashwerts, der nur im PDAS (mit dem zum Public Key gehörenden Private Key) entschlüsselt werden kann, überprüft, ob sie unverändert ist, von der ursprünglichen IP-Adresse gesendet wurde und im aktuellen Zeitfenster noch gültig ist.
  • Dann wird das Token innerhalb des PDAS auf die echte Person (bzw. Personen-ID) abgebildet und die geforderten Daten aus den anderen (externen) Speichern eingesammelt und nur diese zu dem Token gehörenden und nach allen geforderten Regeln hinreichend anonymisierten Daten an den Cloud-Dienstleister als Antwort gesendet. Ein Replay der Transaktionsdaten ist so 10 Minuten später oder von einer anderen IP-Adresse nicht mehr möglich.
  • Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zum Schutz sensibler personenbezogener Daten, die in öffentlichen Speichersystemen verwaltet werden, wobei ein vertrauenswürdiges Tokenisierungs-System mit mindestens einer vertrauenswürdigen Schnittstelle zu einer Instanz, die sensible personenbezogene Daten zur Verfügung stellen, verarbeiten, besitzen und/oder abrufen darf, sowie zumindest eine Schnittstelle zu einem öffentlichen (d.h. nicht-vertrauenswürdigen) Speicher, der keine sensiblen personenbezogenen Daten beinhalten darf, bereitgestellt werden, und wobei das Tokenisierungs-System den sensitiven Personenbezug der Daten in den öffentlichen Speichersystemen durch ein nicht-sensitives Datenelement (Token) ersetzt und die Zuordnung zwischen sensitivem Personenbezug und Token in einer gesicherten Umgebung abspeichert, wobei das Token anwenderspezifisch bzw. kundenspezifisch (individuell) generiert wird, so dass insbesondere das Token in einer vorhandenen Infrastruktur des Anwenders bzw. Kunden ohne Anpassung dieser Infrastruktur verarbeitet werden kann bzw. wird.
  • Die oben hinsichtlich der erfindungsgemäßen Einrichtung erwähnten Ausführungsformen der Erfindung können in analoger Weise zur Weiterbildung des erfindungsgemäßen Verfahrens verwendet werden.
  • Im Folgenden soll exemplarisch eine Ausführungsformen der Erfindung sowie weitere Merkmale und Vorteile der Erfindung anhand der Figur erläutert werden. Es zeigt:
    • 1 eine Ausführungsform einer erfindungsgemäßen Einrichtung.
  • 1 zeigt ein vereinfachtes Implementierungsbeispiel einer erfindungsgemäßen Einrichtung bzw. PDAS 120, am Beispiel einer Arzt-Patienten-Beziehung. Der Arzt 100 sendet in diesem Beispiel ein EKG eines Patienten P über einen gesicherten vertrauenswürdigen Zugang 110, zum Beispiel in Form eines PDAS-Clients, mit der zugehörigen Patienteninformation an das PDAS 120. Dieses PDAS generiert ein nicht-sensitives Datenelement 5 bzw. einen Token 5 in Form einer eineindeutigen, aber nichtsensitiven, nicht-ausspionierbaren Informationseinheit und ersetzt damit den sensitiven Personen- bzw. Patientenbezug. Die Zuordnung von Token 5 und Patient P wird ausschließlich im PDAS 120 gespeichert. Anschließend wird das EKG mit zugehörigem Token in einen allgemein zugänglichen Speicher 130, zum Beispiel eine Daten-Cloud, hochgeladen. An diese Daten-Cloud können optional weitere Datenanalysesysteme, wie z.B. ein auf AI (Artifical Intelligence, Machine learning, etc.) basiertes EKG-Datenanalysesystem 140 angeschlossen sein, welches beauftragt wird, die EKG-Daten zu befunden oder es können noch weitere Systeme angeschlossen sein, wie z.B. mindestens ein System mit Anwendungen zur statistischen EKG-Datenauswertung 150.
  • Jeglicher Personenbezug findet ausschließlich in der vertrauenswürdigen bzw. gesicherten Umgebung 160 statt und in der nicht-vertrauenswürdigen Umgebung, wie dem Speicher 130, können weitere Analysen und Datenauswertungen (allgemein: Big-Data Anwendungen) ausgeführt werden, die eine große Datenbasis benötigen, jedoch keinen Personenbezug haben müssen.
  • Der Arzt 100 kann die Ergebnisse der Analysen und Auswertungen über einen gesicherten Zugang mit einem PDAS-Client 110, der mit dem PDAS 120 verbunden ist, abfragen und den Personenbezug herstellen. Das PDAS 120 kann als ein Server ausgebildet sein.
  • Hierbei kann die vertrauenswürdige Umgebung 160 z.B. kostenpflichtig als universelle Schnittstelle zur Verfügung gestellt werden
  • Die Erfindung gestattet es mit Vorteil, sensible personenbezogene Daten in „öffentlichen“, nicht-vertrauenswürdigen Speichersystem ablegen und verarbeiten zu können, ohne dass der Schutz der personenbezogenen Daten eingeschränkt wird. Das dabei zur Pseudonymisierung verwendete Token wird dazu jeweils in einer kundenspezifischen Struktur generiert, so dass dieses in bereits vorhandenen IT-Infrastrukturen ohne zusätzliche Anpassung verarbeitet werden kann.

Claims (1)

  1. Einrichtung (120) zum Schutz sensibler personenbezogener Daten, die in öffentlichen Speichern (130) verwaltet werden, aufweisend: - ein vertrauenswürdiges Tokenisierungs-System mit mindestens einer vertrauenswürdigen Schnittstelle zu einer Instanz, die sensible personenbezogene Daten zur Verfügung stellen, verarbeiten, besitzen und/oder abrufen darf, und - mindestens eine Schnittstelle zu einem öffentlichen Speicher (130), der keine sensiblen personenbezogenen Daten beinhaltet, wobei das Tokenisierungs-System dazu konfiguriert ist, den sensitiven Personenbezug der Daten in den öffentlichen Speichersystemen durch ein nicht-sensitives Datenelement (5) zu ersetzen und die Zuordnung zwischen sensitivem Personenbezug und nicht-sensitivem Datenelement in einer gesicherten Umgebung (160) abzuspeichern, wobei das nicht-sensitive Datenelement (5) anwenderspezifisch generiert wird, so dass das nicht-sensitive Datenelement (5) in einer vorhandenen Infrastruktur des Anwenders ohne Anpassung dieser Infrastruktur verarbeitbar ist.
DE202021100647.1U 2021-02-10 2021-02-10 Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token Active DE202021100647U1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE202021100647.1U DE202021100647U1 (de) 2021-02-10 2021-02-10 Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token
US18/263,736 US20240119174A1 (en) 2021-02-10 2022-02-03 Personal Data Anonymization System (PDAS) with Customized Token
PCT/EP2022/052524 WO2022171509A1 (en) 2021-02-10 2022-02-03 Personal data anonymization system (pdas) with customized token
EP22706757.6A EP4292003A1 (de) 2021-02-10 2022-02-03 System zur anonymisierung persönlicher daten (pdas) mit kundenspezifischem token

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE202021100647.1U DE202021100647U1 (de) 2021-02-10 2021-02-10 Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token

Publications (1)

Publication Number Publication Date
DE202021100647U1 true DE202021100647U1 (de) 2021-02-17

Family

ID=74846137

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202021100647.1U Active DE202021100647U1 (de) 2021-02-10 2021-02-10 Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token

Country Status (4)

Country Link
US (1) US20240119174A1 (de)
EP (1) EP4292003A1 (de)
DE (1) DE202021100647U1 (de)
WO (1) WO2022171509A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10572684B2 (en) * 2013-11-01 2020-02-25 Anonos Inc. Systems and methods for enforcing centralized privacy controls in de-centralized systems
US10389688B2 (en) * 2016-08-23 2019-08-20 NXT-Security, LLC Vaultless tokenization engine

Also Published As

Publication number Publication date
WO2022171509A1 (en) 2022-08-18
US20240119174A1 (en) 2024-04-11
EP4292003A1 (de) 2023-12-20

Similar Documents

Publication Publication Date Title
EP1290530B1 (de) Verschlüsseln von abzuspeichernden daten in einem iv-system
EP2409255B1 (de) Verfahren zur erzeugung von asymmetrischen kryptografischen schlüsselpaaren
EP1451736A2 (de) Datenverarbeitungssystem für patientendaten
DE102006012311A1 (de) Verfahren und Vorrichtung zur Pseudonymisierung von digitalen Daten
EP1084465B1 (de) Verfahren zum abgesicherten zugriff auf daten in einem netzwerk
EP3452941A1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
DE10156877A1 (de) Verfahren und System zum gesicherten Speichern und Auslesen von Nutzdaten
DE112020007364T5 (de) Verfahren und verteiltes Ledger-System zur Unterstützung der gemeinsamen Nutzung digitaler Gesundheitsdaten von Reisenden in einer Reiseumgebung
EP3629516B1 (de) Dezentralisierte identitätsmanagement-lösung
DE102019217738A1 (de) Computerimplementiertes Verfahren zur Steuerung und Kontrolle der Verteilung von verifizierten personenbezogenen Nutzer-Daten eines Nutzers auf einer Vielzahl von Anbieter-Servern
DE202021100647U1 (de) Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token
DE102010037326A1 (de) Verfahren zum anonymen Zusammenführen von vertraulichen Daten und zugehörigen Identifizierungsdaten
EP4315117A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
DE10307996B4 (de) Verfahren zum Ver- und Entschlüsseln von Daten durch verschiedene Nutzer
DE10209780B4 (de) Datenverarbeitungssystem für Patientendaten
DE102020207034A1 (de) Geteiltes widerrufsprotokoll für datenzugriffskontrolle
DE102006021371A1 (de) Verfahren zur reversiblen Anonymisierung vertraulicher Datenteile und eine entsprechende Datenstruktur
DE102018204447A1 (de) Automatisiertes Verfahren zum Schutz von elektronischen Daten zum Zwecke der Datenverarbeitung durch Dritte unter Einbezug transparenter und unterbrechungssicherer Vergütung
DE102018010027A1 (de) Abwicklungssystem
DE10307995B4 (de) Verfahren zum Signieren von Daten
WO2022002502A1 (de) Anonymisiertes bereitstellen eines dienstes
EP4068720A1 (de) Verfahren zur elektronischen versendung einer persönlichen identifikationskennung
EP4145324A1 (de) Verfahren und system zum gesicherten verarbeiten von zertifizierungsanfragen
DE4416253B4 (de) Verfahren zur datenschutzgerechten Verteilung von Schlüsselinformationen
WO2020169502A1 (de) Verfahren zum transfer von daten

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: GALANDER, MARCUS, DIPL.-PHYS. DR.RER.NAT., DE

R207 Utility model specification