Technisches Gebiet
[0001] Die Erfindung bezieht sich auf ein Verfahren zur Ermittlung, Kontrolle und Festlegung der rollenbasierten Berechtigung eines Benutzers für den Zugriff auf gesundheitsbezogene Daten einer Person in elektronischer Form. Sie bezieht sich weiter auf ein sogenanntes medizinisches "Clearingsystem" zur Durchführung eines solchen Verfahrens. Die Erfindung gehört damit zum Bereich der Medizininformatik.
Stand der Technik
[0002] Um gesundheitsbezogene Leistungen zu erbringen ist es für den Erbringer der Leistung wichtig, die früheren gesundheitsbezogenen Daten des Leistungsempfängers zu kennen. Diese Daten müssen auch einem Leistungserbringer zugänglich sein, der die zugrundeliegende Leistung nicht selbst erbracht hat. Dabei muss einerseits aus Datenschutzgründen berücksichtigt werden, dass einem Leistungserbringer nur diejenigen Daten offengelegt werden, die ihm der Eigentümer der Daten (nach Beratung mit einer Fachperson seines Vertrauens) auch tatsächlich offenlegen will. Anderseits müssen dem Leistungserbringer zwingend diejenigen Daten offengelegt werden, deren Offenlegung gesetzlich vorgeschrieben ist oder deren Offenlegung zum fehlerfreien Erbringen der Leistung fachlich notwendig ist.
Im Gesundheitswesen können neben den Patienten auch die Leistungserbringer Eigentümer von Daten sein, insbesondere wenn die Daten ihrem Charakter nach Kommentaren und Beobachtungen darstellen.
[0003] Verschiedene existierende Speicher- und Ablagesysteme für gesundheitsbezogene Daten identifizieren Patienten anhand einer Identifikationsnummer, mit deren Hilfe die Daten aufgefunden und dem Leistungserbringer zur Verfügung gestellt werden können. Der grundlegende Nachteil dieser Systeme liegt in ihrer oftmals proprietären Natur, welche den Datenaustausch behindert oder gar verunmöglicht. Sind die Datenablagen zudem papier- oder mikrofilmbasiert, lässt sich eine Zugriffskontrolle aus praktischen Gründen nur in sehr grobem Rahmen realisieren; die Kontrolle hinunter bis auf die Ebene einzelner Daten ist technisch zu aufwendig.
[0004] Neuere Datenspeichersysteme benutzen Plastikkarten mit Speicher und Prozessorchip (sogenannte "Smartcards"). Auf solchen Karten lassen sich in verschlüsselter Form Patientendaten speichern. Gängige Systeme speichern "Notfalldatensets", die einer Teilmenge des Patientendossiers entsprechen und meist unverschlüsselt sind. Andere Kartensysteme speichern anstelle der Patientendaten nur Hinweise ("Zeiger") auf den eigentlichen Speicherort der Daten innerhalb eines Netzwerks, auf das mit der Karte zugegriffen werden kann. Da die Datensets und Zeigerlisten allgemein nicht oder zu wenig standardisiert sind, und die verschiedenen Anbieter und/oder Betreiber solcher kartenbasierten Systeme unterschiedliche technische Spezifikationen verwenden, ist ein ziel- und zweckgerichteter Datenaustausch nicht gewährleistet.
[0005] Daneben lassen sich auf solchen Karten aber auch elektronische Schlüsselzertifikate abspeichern. Diese bestätigen die Vergabe eines elektronischen Schlüssels für asynchrone Verschlüsselung an den Zertifikatsinhaber (sogenannte "Public Key Infrastructure"). Schlüssel und Zertifikat werden durch eine Instanz, deren Glaubwürdigkeit auf staatlicher Kontrolle beruht, sowohl für Patient und Leistungserbringer vergeben. Das Schlüsselzertifikat dient der Identifikation seines Inhabers. Sofern sich dieser gegenüber dem elektronischen System, welches das Schlüsselzertifikat verarbeitet, mit einem PIN-Code authentifiziert, kann das Zertifikat zudem als digitale Unterschrift benutzt werden. Die Programmlogik, welche den Kartenzugriff überprüft und freigibt, ist bei Karten mit Prozessorchip direkt auf der Karte selbst enthalten und wird durch den Prozessor abgearbeitet.
Abhängig davon, ob eine solche Karte für einen Patienten ausgestellt wird oder für einen Leistungserbringer, werden die Karten sinngemäss als "Health Cards" oder als "Health Professional Cards" bezeichnet. Während die Health Card in der Regel Notfalldaten oder Zeigerlisten auf die Gesundheitsdaten des Patienten sowie dessen Schlüsselzertifikat enthält, sind auf der Health Professional Card Qualifikationsdaten des Leistungserbringers und dessen Schlüsselzertifikat gespeichert.
[0006] Mit Hilfe des Schlüsselzertifikats und des PIN-Codes einer Health Card resp. einer Health Professional Card können moderne Datenverarbeitungssysteme Zugriff auf das auf einer "Health Card" gespeicherte Datenset oder in ein Netzwerk, in dem die Patientendaten gespeichert sind, gewähren. Eine Zugriffskontrolle, die ausschliesslich auf den Schlüsselzertifikaten des Dateneigentümers und einer anfragenden Person beruht, ist allerdings nicht in der Lage, hinreichend genau abgestufte Zugriffe im Sinne des Dateneigentümers und im Rahmen gesetzlicher Vorschriften effizient zu gewährleisten.
Darstellung der Erfindung
[0007] Um diese Einschränkungen zu überwinden, legt die vorliegende Erfindung ein Verfahren zur Ermittlung, Kontrolle und Festlegung der rollenbasierten Berechtigung eines Benutzers für den Zugriff auf gesundheitsbezogene Daten einer Person in elektronischer Form dar, wobei mittels zertifizierten Computerapplikationen im Rahmen eines Sicherheitskontexts zwischen Terminals und einer Clearingstelle auf in einem Trustcenter zu speichernde gesundheitsbezogene Daten zum Zwecke der Bearbeitung zugegriffen wird.
Der Sicherheitskontext wird durch den gleichzeitigen Einsatz bei einer Clearingstelle registrierter eindeutig identifizierbarer Prozessorchips für synchrone Verschlüsselung, Schlüsseln und entsprechenden Zertifikaten für asynchrone Verschlüsselung und Smartcards für die Speicherung von Personenidentifikationen, Teilen von Schlüsseln, Schlüsselzertifikaten und Prozesstoken hergestellt. Die Prozessorchips für synchrone Verschlüsselung sind in die Terminals einbaubar.
[0008] Ein medizinisches Clearingsystem zur Durchführung des Verfahrens zur Ermittlung, Kontrolle und Festlegung der rollenbasierten Berechtigung eines Benutzers für den Zugriff auf gesundheitsbezogene Daten einer Person in elektronischer Form umfasst Terminals, ein Trustcenter zum Speichern der gesundheitsbezogenen Daten, eine Clearingstelle und Schlüssel und entsprechende Zertifikate für asynchrone Verschlüsselung.
Mit zertifizierten Applikationen wird im Rahmen eines Sicherheitskontexts zwischen Terminals und Clearingstelle auf die im Trustcenter zu speichernden Daten zum Zwecke der Bearbeitung zugegriffen, wobei der Sicherheitskontext durch den gleichzeitigen Einsatz bei der Clearingstelle registrierter eindeutig identifizierbarer und in die Terminals einbaubarer Prozessorchips für synchrone Verschlüsselung, der Schlüssel und entsprechender Zertifikate für asynchrone Verschlüsselung und Smartcards für die Speicherung von Personenidentifikationen, Teilen von Schlüsseln, Schlüsselzertifikaten und Prozesstoken hergestellt wird.
[0009] Die Ermittlung, Kontrolle und Festlegung erfolgt von den registrierten Terminals aus mit Hilfe der identifizierbaren Prozessorchips für synchrone Verschlüsselung, Schlüsseln und entsprechenden Zertifikaten für asynchrone Verschlüsselung, sowie den Smartcards für die Speicherung von Personenidentifikationen, Teilen von Schlüsseln, Schlüsselzertifikaten und Prozesstoken. Das System wird eingesetzt zur Kontrolle der Datenzugriffe, welche Leistungserbringer, Patienten und weitere Personen mit Hilfe von Computerapplikationen auf elektronisch gespeicherte Daten über den Gesundheitszustand einer Person oder über die dafür erbrachten Leistungen durchführen wollen.
Der Vorteil eines solchen Systems liegt in der Sichtbarmachung von Prozessen, einer präziseren, schnelleren und sichereren Abrechnung medizinischer Leistungen gegenüber dem bisherigem Stand der Technik, vor allem aber in der bis auf Ebene einzelner Daten durchsetzbaren Kontrolle der Datenschutzrechte und Verbesserung der Qualität medizinischer Dokumentation.
Ausführung der Erfindung
[0010] Das Clearingsystem besteht einerseits aus Geräten für den Datenzugriff (sogenannte "Terminals"), von denen aus eine Datenabfrage mit Hilfe von Smartcards und zertifizierten Computerapplikationen initiiert werden kann. Auf den Smartcards werden die Identifikationsnummer des Besitzers, sein privater Schlüssel, das dazugehörige Schlüsselzertifikat sowie seine aktuellen Prozesstoken gespeichert.
Anderseits besteht das Clearingsystem aus einer offiziellen Instanz (sogenannte "Clearingstelle"), die (a) asynchrone elektronische Schlüssel generiert und dazugehörige Zertifikate vergibt, (b) Computerapplikationen für den Betrieb auf Terminals und die Teilnahme am Clearingsystem zertifiziert, (c) Prozessorchips für die synchrone Verschlüsselung zum Einbau in Terminals und zur Verwendung innerhalb des Clearingsystems registriert, (d) die entsprechend der Zugriffsberechtigung eines Anfragers aus einem zum Clearingsystem gehörigen Trustcenter verschlüsselt gespeicherte Daten abruft, entschlüsselt, an den Anfrager übermittelt resp. umgekehrt Dateneingaben von diesem entgegennimmt, und im genannten Trustcenter wieder verschlüsselt ablegt.
Schliesslich beinhaltet das Clearingsystem Datenbanken, in denen (a) fachliche Qualifikationen, (b) deren Gewichtung ("Dignität"), (c) Schlüssel und Schlüsselzertifikate (d) sowie Muster für die Identifikation und Authentifizierung der am Clearingsystem teilnehmenden Personen erfasst werden. Die Clearingstelle betreibt ausserdem Datenbanken, in denen Datenzugriffs- und Terminalbenutzungsrechte erfasst sind. Diese Rechte können vom jeweiligen Eigentümer oder einer von ihm bezeichneten Person aktualisiert werden. Die Clearingstelle protokolliert alle Vorgänge zwischen ihr und den Terminals. Letztlich gehört zum Clearingsystem ein Applikationszentrum, welches von der Clearingstelle zertifizierte Computerapplikationen für den Transfer auf Terminals bereithält, diese Applikationen aber auch zentral ausführen und weiteren Applikationen als zugrunde liegender Webservice anbieten kann.
[0011] Sowohl die Clearingstelle als auch die Terminals sind mit einem Prozessorchip ausgerüstet, der sich anhand einer einmaligen Nummer eindeutig elektronisch identifizieren lässt und eine synchrone Verschlüsselung zwischen Clearingstelle und dem einzelnen Terminal gewährleistet. Die Prozessorchips werden von der Clearingstelle registriert, zertifiziert und zum Einbau in die Terminals freigegeben. Die Clearingstelle führt eine elektronische Liste, in der festgehalten wird, welcher Prozessorchip in welches Terminal eingebaut wird, welcher Institution ein Terminal gehört, und welchem Zweck ein Terminal dient.
[0012] Das Terminal ist mit einem Lesegerät für Smartcards ausgestattet und kann von der Clearingstelle zertifizierte Computerapplikationen abarbeiten. Durch die Anmeldung eines vom Clearingsystem anerkannten Benutzers (sogenannter Anfrager) mit Hilfe seiner Smartcard wird ein Sicherheitskontext zwischen Clearingstelle und Terminal geschaffen, im Rahmen dessen der Anfrager unter Benutzung zertifizierter Computerapplikationen auf Daten zugreifen und diese verarbeiten kann. Es ist möglich, eine virtuelle Person (sogenannter "Systemaccount") für ein Terminal zu definieren, dessen Sicherheitsangaben permanent im Terminal gespeichert werden, nur dem Terminal zur Verfügung stehen und von diesem dazu benutzt werden, sich analog einer Person am Clearingsystem anzumelden.
[0013] Die Herstellung dieses Sicherheitskontexts ist der erste Teil des Verfahrens zum Ermitteln, Kontrollieren und Festlegen von Zugriffsberechtigungen auf gesundheitsbezogene Daten. Dieser Teil des Verfahrens kann als Algorithmus mit folgenden Schritten dargestellt werden:
<tb>(1)<sep>Der Benutzer meldet sich an einem Terminal manuell durch Einlesen der Benutzeridentifikation von einer Smartcard oder automatisch durch Einlesen der im Terminal gespeicherten Benutzeridentifikation des Systemaccounts an.
<tb>(2)<sep>Das Terminal baut mit Hilfe seines eindeutig identifizierbaren Prozessorchips eine synchron verschlüsselte Verbindung zur Clearingstelle auf. Ist der Prozessorchip nicht registriert, bricht die Clearingstelle den Vorgang ab.
<tb>(3)<sep>Das Terminal übermittelt die Identifikation des Benutzers an die Clearingstelle.
<tb>(4)<sep>Die Clearingstelle überprüft anhand der übermittelten Identifikation und der erfassten Terminalbenutzungsrechte, ob der Benutzer vom benutzten Terminal aus anfragen darf. Wird die Berechtigung verneint, bricht die Clearingstelle den Vorgang ab.
<tb>(5)<sep>Der Benutzer muss sich mit einer Methode seiner Wahl (die Authentifizierungsmuster dazu müssen bei der Clearingstelle hinterlegt sein) authentifizieren. Gelingt dies nicht innerhalb einer begrenzten Zahl von Versuchen, bricht die Clearingstelle den Vorgang ab. Gelingt die Authentifizierung, wird der Benutzer als Anfrager akzeptiert.
<tb>(6)<sep>Die Clearingstelle überschreibt die auf der Smartcard des Anfragers gespeicherten Schlüssel für die aktuellen Rollen des Anfragers mit den bei ihr für diese Rollen gespeicherten Schlüsseln.
<tb>(7)<sep>Die Clearingstelle synchronisiert die bei ihr für Terminal und Rollen des Anfragers gespeicherten Prozesstoken mit denen, die im Terminal und auf der Smartcard des Anfragers gespeichert sind.
<tb>(8)<sep>Die Clearingstelle vergleicht die für Terminal und Rollen des Anfragers gespeicherten Prozesstoken.
<tb>(9)<sep>Die Clearingstelle gewährt dem Anfrager für übereinstimmende Prozesstoken auf dem benutzten Terminal die mit den Prozesstoken verbundenen und bei ihr gespeicherten Zugriffsrechte auf Daten.
<tb>(10)<sep>Damit ist der Sicherheitskontext hergestellt.
<tb>(11)<sep>Der Sicherheitskontext wird solange aufrechterhalten, bis sich der Anfrager am Terminal abmeldet. Er wird zudem durch die Clearingstelle beendet, wenn für eine vom Anfrager festlegbare Zeit keine Abfrage oder Lieferung von Daten durch eine Computerapplikation an die Clearingstelle erfolgt ist. Ebenso wird der Sicherheitskontext durch das Abschalten des Terminals und den Wechsel von Rollen des Anfragers beendet. Die Clearingstelle kann überdies aus vorbehaltenen wichtigen Gründen den Kontext beenden und eine Neuanmeldung des Benutzers verlangen. Das Entfernen der Smartcard aus dem Lesegerät stellt keine Beendigung des Sicherheitskontexts dar!
[0014] In diesem Kontext gestartete zertifizierte Computerapplikationen werden von der Clearingstelle mit Daten entsprechend den Zugriffsrechten den Rollen des Anfragers bedient und können ebenfalls diesen Rechten entsprechend Daten zur Speicherung zurückliefern an die Clearingstelle. Alle an die Clearingstelle gelieferten Daten werden mit Hilfe des Schlüsselzertifikates, welches der Rolle des Anfragers mit den höchsten Zugriffsberechtigungen entspricht, digital signiert. Eine zertifizierte Computerapplikation kann auf einem dafür reservierten Terminal so installiert werden, dass es ausschliesslich der Datenverarbeitung durch diese spezifische Computerapplikation zur Verfügung steht. Damit kann ein Terminal unbedient und dennoch kontrolliert auf Daten zugreifen und diese automatisch verarbeiten.
[0015] Durch die Definition von Prozessen lasen sich Daten, die dem Leistungserbringer gehören (sog. "Prozessdaten"), von Daten, die dem Patienten gehören (sog. "Grunddaten"), unterscheiden und mit verschiedenen Zugriffsberechtigungen versehen. Indem einer Rolle eines Anfragers Zugriff auf einen Prozess erteilt wird (sogenannte "Prozessberechtigung"), erhält sie indirekt auch Zugriff auf die für den Prozess freigegebenen Grunddaten. Diejenige Rolle, die einen Prozess definiert, ist Eigentümerin dieses Prozesses. Sie kann weitere Unterprozesse definieren, anderen Rollen und Terminals Prozessberechtigungen für den Prozess und/oder untergeordnete Prozesse erteilen, automatisch erteilen lassen, oder diese Kompetenz auf weitere Rollen übertragen (eine Rolle hat grundsätzlich Prozessberechtigung an den ihrem eigentlichen Prozess untergeordneten weiteren Prozessen).
Werden die bei der ursprünglichen Prozessdefinition festgelegten Datenzugriffsrechte durch einen solchen Vorgang erweitert, oder wird ein neuer Prozess definiert, benötigt dies immer auch das Einverständnis des Eigentümers der betroffenen Grunddaten.
[0016] Benötigt ein Anfrager Zugriff auf weitere Grund- oder Prozessdaten, so muss er seinen Sicherheitskontext erweitern. Dies geschieht entweder durch Erlangen existierender Prozesstoken zuhanden einer der Rollen des Anfragers (wobei der Anfrager die Rolle selbst wählen kann), oder durch Definition eines neuen Prozesses mit Hilfe einer mit entsprechenden Rechten ausgestatteten Rolle des Anfragers.
[0017] Die Erweiterung des Sicherheitskontexts ist der zweite Teil des Verfahrens zum Ermitteln, Kontrollieren und Festlegen von Zugriffsberechtigungen auf gesundheitsbezogene Daten. Voraussetzung ist die vorgängige Herstellung eines Sicherheitskontexts wie oben beschrieben, innerhalb dessen der nachfolgende Verfahrensteil ablaufen kann. Dieser zweite Teil des Verfahrens kann als Algorithmus mit folgenden Schritten dargestellt werden:
<tb>(1)<sep>Die Smartcard des Anfragers wird aus dem Lesegerät des Terminals entfernt, sofern der Sicherheitskontext mit Hilfe einer Smartcard gestartet wurde.
<tb>(2)<sep>Die Smartcard einer anderen Person wird in das Lesegerät des Terminals eingeführt und die darauf abgespeicherte Identifikation eingelesen.
<tb>(3)<sep>Das Terminal teilt der Clearingstelle mit, dass der Sicherheitskontext des Anfragers erweitert werden soll.
<tb>(4)<sep>Die Clearingstelle prüft anhand der Prozessoridentifikation des Terminals und der dafür erfassten Rechte, ob die gewünschte Operation auf dem benutzten Terminal zulässig ist. Wenn das Terminal nicht für die verlangte Operation vorgesehen ist, bricht die Clearingstelle den Vorgang ab.
<tb>(5)<sep>Das Terminal übermittelt die eingelesene Identifikation an die Clearingstelle.
<tb>(6)<sep>Die Clearingstelle ermittelt die mit der Identifikation verbundenen aktuell gültigen Prozesstoken.
<tb>(7)<sep>Die Clearingstelle vergleicht die Prozesstoken mit denjenigen der Rollen des Anfragers.
<tb>(8)<sep>Die Clearingstelle ermittelt die Prozessrechte des Anfragers für übereinstimmende Prozesstoken.
<tb>(9)<sep>Die Clearingstelle übermittelt die mit der eingelesenen Identifikation verbundenen Prozesstoken, Prozessbeschreibungen und allfällige Prozessrechte des Anfragers an das Terminal.
<tb>(10)<sep>Das Terminal zeigt diese Angaben dem Anfrager.
<tb>(11)<sep>Der Anfrager gibt an, ob er ein existierendes Prozesstoken erlangen (weiter mit Schritt 12) oder einen neuen Prozess definieren will (weiter mit Schritt 25).
<tb>(12)<sep>Der Anfrager gibt an, für welche seiner Rollen der Sicherheitskontext erweitert werden soll.
<tb>(13)<sep>Das Terminal übermittelt die Angabe an die Clearingstelle.
<tb>(14)<sep>Die Clearingstelle ermittelt die möglichen Prozessrechte des Anfragers und übermittelt diese an das Terminal.
<tb>(15)<sep>Das Terminal zeigt diese dem Anfrager an.
<tb>(16)<sep>Der Anfrager gibt an, ob er die Prozessrechte wie vom Terminal präsentiert oder in einer anderen Form beantragt.
<tb>(17)<sep>Das Terminal formuliert einen Antrag und übermittelt diesen an die Clearingstelle.
<tb>(18)<sep>Die Clearingstelle speichert den Antrag, bis sich der Prozesseigentümer am Clearingsystem anmeldet.
<tb>(19)<sep>Die Clearingstelle sendet den Antrag an das Terminal, an welchem der Prozesseigentümer angemeldet ist.
<tb>(20)<sep>Das Terminal, an welchem der Prozesseigentümer angemeldet ist, zeigt diesem den Antrag.
<tb>(21)<sep>Der Prozesseigentümer bestätigt den Antrag uneingeschränkt, mit Korrekturen, oder lehnt ihn ab.
<tb>(22)<sep>Das Terminal, an welchem der Prozesseigentümer angemeldet ist, sendet dessen Reaktion an die Clearingstelle.
<tb>(23)<sep>Abhängig von der Rückmeldung des Prozesseigentümers erweitert die Clearingstelle den Sicherheitskontext des Anfragers. Dazu wird ein allfällig neu erlangtes Prozesstoken in die Tokenliste der vom Anfrager gewählten Rolle eingetragen, die neu erteilten Prozessrechte des Anfragers mit dem Prozesstoken verknüpft. Die Clearingstelle speichert das Prozesstoken auf dem Terminal des Anfragers.
<tb>(24)<sep>Das Terminal des Anfragers fordert diesen auf, seine Smartcard in das Lesegerät einzulegen und speichert das Prozesstoken auf der Smartcard des Anfragers. Weiter mit Schritt 34.
<tb>(25)<sep>Der Anfrager definiert einen neuen Prozess, indem er dem Prozess Terminals und Rollen, die Prozessrechte besitzen sollen, zuweist und deren Zugriffsrecht auf die Grunddaten der zweiten Smartcard festlegt.
<tb>(26)<sep>Das Terminal formuliert einen Antrag und übermittelt diesen an die Clearingstelle.
<tb>(27)<sep>Die Clearingstelle speichert den Antrag, bis sich der Eigentümer der zweiten Smartcard erfolgreich am Clearingsystem anmeldet.
<tb>(28)<sep>Die Clearingstelle sendet den Antrag an das Terminal, an welchem der Eigentümer der zweiten Smartcard angemeldet ist.
<tb>(29)<sep>Das Terminal, an welchem der Eigentümer der zweiten Smartcard angemeldet ist, zeigt diesem den Antrag.
<tb>(30)<sep>Der Eigentümer der zweiten Smartcard bestätigt den Antrag uneingeschränkt, mit Korrekturen, oder lehnt ihn ab.
<tb>(31)<sep>Das Terminal, an welchem der Eigentümer der zweiten Smartcard angemeldet ist, sendet dessen Reaktion an die Clearingstelle.
<tb>(32)<sep>Abhängig von der Rückmeldung des Eigentümers der zweiten Smartcard erweitert die Clearingstelle den Sicherheitskontext des Anfragers. Sie generiert ein eineindeutiges Prozesstoken. Das Token wird zusammengesetzt aus Datum, Zeit, Identifikationsnummer des Prozessorchips des vom Anfrager benutzten Terminals, sowie den Identifikationsnummern von Anfrager und Eigentümer der zweiten Smartcard. Das Prozesstoken ist nur für eine beschränkte Zeit gültig, die vom Prozesseigentümer (der Anfrager oder eine von ihm bezeichnete Rolle) bestimmt und allenfalls verlängert werden kann - beides allerdings nur mit Zustimmung des Eigentümers der Grunddaten. Das Prozesstoken wird in die Tokenliste der vom Anfrager gewählten Rolle eingetragen, ebenso in die Tokenliste des Eigentümers der zweiten Smartcard.
Die neu definierten Prozessrechte des Anfragers werden mit dem Prozesstoken verknüpft. Die Clearingstelle speichert das Prozesstoken auf dem oder den Terminals, an denen sich der Anfrager resp. der Eigentümer der zweiten Smartcard angemeldet hat.
<tb>(33)<sep>Die genannten Terminals fordern den Anfrager resp. Eigentümer der zweiten Smartcard auf, die jeweilige Smartcard in das Lesegerät einzulegen und speichern das Prozesstoken auf der jeweiligen Smartcard ab.
<tb>(34)<sep>Damit ist der Sicherheitskontext erweitert und der Erweiterungsvorgang beendet.
[0018] Das Verfahren zum Ermitteln, Kontrollieren und Festlegen der Zugriffsberechtigung beruht somit auf der Definition von Prozessen, dem Vergleich von Prozesstoken und den damit verknüpften Prozessrechten.
Technical area
The invention relates to a method for determining, controlling and determining the role-based authorization of a user for accessing health-related data of a person in electronic form. It further refers to a so-called medical "clearing system" for carrying out such a method. The invention thus belongs to the field of medical informatics.
State of the art
In order to provide health-related services, it is important for the provider of the service to know the former health-related data of the beneficiary. These data must also be accessible to a service provider who has not provided the underlying service himself. On the one hand, for reasons of data protection, it must be taken into account that only the data that the owner of the data (after consultation with a specialist of his / her trust) intends to actually disclose to a service provider is disclosed. On the other hand, it is mandatory for the service provider to disclose the data whose disclosure is required by law or whose disclosure is technically necessary for the error-free performance of the service.
In healthcare, not only patients but also service providers can be the owners of data, especially if the data are comments and observations in nature.
Various existing storage and storage systems for health-related data identify patients by means of an identification number, with the help of which the data can be found and made available to the service provider. The fundamental disadvantage of these systems lies in their often proprietary nature, which impedes the data exchange or even impossible. If the data files are also based on paper or microfilm, access control can only be implemented on a very rough scale for practical reasons; The control down to the level of individual data is technically too complicated.
Recent data storage systems use plastic cards with memory and processor chip (so-called "smart cards"). On such cards, patient data can be stored in encrypted form. Common systems store "emergency data sets" that correspond to a subset of the patient dossier and are mostly unencrypted. Other card systems store only pointers ("pointers") to the actual location of the data within a network accessible to the card instead of the patient data. Since the data sets and pointer lists are generally not or too little standardized, and the various providers and / or operators of such card-based systems use different technical specifications, a targeted and purposeful data exchange is not guaranteed.
In addition, electronic key certificates can also be stored on such cards. These confirm the assignment of an electronic key for asynchronous encryption to the certificate holder (so-called "Public Key Infrastructure"). The key and certificate are awarded to both the patient and the care provider by an entity whose credibility is based on state control. The key certificate serves to identify its owner. If the latter is authenticated against the electronic system that processes the key certificate with a PIN code, the certificate can also be used as a digital signature. The program logic, which checks and releases the card access, is included directly on the card itself for cards with a processor chip and is processed by the processor.
Depending on whether such a card is issued for a patient or for a service provider, the cards are referred to as "Health Cards" or "Health Professional Cards". While the Health Card typically includes emergency data or pointer lists of the patient's health information and key certificate, the Health Professional Card stores the provider's qualification data and key certificate.
With the help of the key certificate and PIN codes of a Health Card resp. A Health Professional Card allows modern data processing systems to access the dataset stored on a "health card" or to a network where patient data is stored. An access control based exclusively on the key certificates of the data owner and a requesting person, however, is not able to ensure sufficiently precisely graded access for the purposes of the data owner and within the framework of statutory provisions.
Presentation of the invention
To overcome these limitations, the present invention provides a method for determining, controlling and establishing the role-based authorization of a user for accessing a person's health-related data in electronic form, using certified computer applications within a security context between terminals and a clearing house accesses health-related data to be stored in a trust center for the purpose of processing.
The security context is established by concurrent use at a clearinghouse of registered, uniquely identifiable processor chips for synchronous encryption, keys and corresponding asynchronous encryption certificates, and smartcards for storing personal identifications, parts of keys, key certificates, and process tokens. The processor chips for synchronous encryption can be installed in the terminals.
A medical clearing system for performing the method for determining, controlling and establishing the role-based authorization of a user for accessing health-related data of a person in electronic form includes terminals, a trust center for storing the health-related data, a clearing house and keys and corresponding certificates for asynchronous encryption.
Certified applications access the data to be stored in the trust center within the framework of a security context between terminals and clearinghouse, the security context being the key through the simultaneous use with the clearing office of registered uniquely identifiable processor chips for synchronous encryption that can be installed in the terminals and corresponding asynchronous encryption certificates, and smart cards for storing personal identifications, parts of keys, key certificates, and process tokens.
The detection, control and determination takes place from the registered terminals using the identifiable processor chips for synchronous encryption, keys and corresponding certificates for asynchronous encryption, as well as the smart cards for the storage of personal identifications, parts of keys, key certificates and process tokens. The system is used to control data access that service providers, patients, and others use computer applications to perform electronically stored data on a person's health or services.
The advantage of such a system lies in the visualization of processes, a more precise, faster and more secure billing of medical services compared to the prior art, but above all in the control of data protection rights enforceable to the level of individual data and improving the quality of medical documentation.
Embodiment of the invention
The clearing system consists on the one hand of devices for data access (so-called "terminals"), from which a data query with the help of smart cards and certified computer applications can be initiated. The smartcards store the owner's identification number, his private key, the associated key certificate, and his current process token.
On the other hand, the clearing system consists of an official entity (the so - called "clearing house") which (a) generates asynchronous electronic keys and assigns associated certificates, (b) certifies computer applications for operation on terminals and participation in the clearing system, (c) processor chips for the registered synchronous encryption for installation in terminals and for use within the clearing system, (d) the encrypted retrieves stored data according to the access authorization of a requestor from a belonging to the clearing system trust center, transmitted to the requestor resp. conversely, it accepts data input from it, and stores it again encrypted in the named trust center.
Finally, the clearing system includes databases that cover (a) professional qualifications, (b) their weighting ("dignity"), (c) keys and key certificates (d), and patterns for the identification and authentication of persons participating in the clearing system. The clearing house also operates databases that include data access and terminal usage rights. These rights may be updated by the owner or a person designated by him. The clearinghouse logs all operations between it and the terminals. Ultimately, the clearing system includes an application center that has computer applications certified by the clearing house for transfer to terminals, but can also run these applications centrally and offer other applications as the underlying web service.
Both the clearing house and the terminals are equipped with a processor chip, which can be uniquely identified by means of a unique number electronically and ensures a synchronous encryption between the clearing house and the individual terminal. The processor chips are registered by the clearing house, certified and released for installation in the terminals. The clearing house maintains an electronic list stating which processor chip is incorporated into which terminal, which institution owns a terminal, and what purpose a terminal serves.
The terminal is equipped with a smart card reader and can process computer applications certified by the clearing house. By registering a user recognized by the clearing system (so-called requester) with the help of his smart card, a security context is created between the clearing house and the terminal, within which the requester can access and process data using certified computer applications. It is possible to define a virtual person (so-called "system account") for a terminal whose security information is permanently stored in the terminal, only available to the terminal and used by the latter to log in to the clearing system in the same way as a person.
The creation of this security context is the first part of the method for determining, controlling and setting access permissions to health-related data. This part of the procedure can be represented as an algorithm with the following steps:
<tb> (1) <sep> The user logs on to a terminal manually by reading the user identification from a smartcard or automatically by reading the user identification of the system account stored in the terminal.
<tb> (2) <sep> The terminal uses its uniquely identifiable processor chip to establish a synchronously encrypted connection to the clearing house. If the processor chip is not registered, the clearing house aborts the process.
<tb> (3) <sep> The terminal transmits the identification of the user to the clearing house.
<tb> (4) <sep> The Clearing House verifies, on the basis of the transmitted identification and the recorded terminal user rights, whether the user is allowed to inquire from the terminal being used. If the privilege is denied, the clearing house aborts the process.
<tb> (5) <sep> The user must authenticate with a method of their choice (the authentication patterns must be deposited with the clearinghouse). If this does not succeed within a limited number of attempts, the clearing house aborts the process. If the authentication succeeds, the user is accepted as a requestor.
<tb> (6) <sep> The clearing house overwrites the keys stored on the requester's smart card for the current roles of the requester with the keys that it stores for those roles.
<tb> (7) <sep> The clearing house synchronizes the process tokens stored with it for the requestor's terminal and roles with those stored in the terminal and on the requestor's smartcard.
<tb> (8) <sep> The clearing house compares the process tokens stored for the requestor's terminal and roles.
<tb> (9) <sep> The clearing house grants the requestor for matching process tokens on the terminal used the data access rights associated with and stored in the process tokens.
<tb> (10) <sep> This establishes the security context.
<tb> (11) <sep> The security context is maintained until the requestor logs off at the terminal. It will also be terminated by the Clearing Agent if no query or delivery of data by a computer application to the Clearing Agent has taken place for a time specified by the Requester. Likewise, the security context is terminated by switching off the terminal and changing roles of the requester. The clearing house may also terminate the context for reserved important reasons and request a new registration of the user. Removing the smart card from the reader is not an end to the security context!
Certified computer applications started in this context are served by the clearing house with data corresponding to the access rights to the roles of the requestor and can also return these data according to data for storage to the clearing house. All data provided to the clearing house is digitally signed using the key certificate, which corresponds to the role of the highest authorized accessor. A certified computer application can be installed on a dedicated terminal so that it is exclusively available for data processing by this specific computer application. This means that a terminal can access data unattended and yet controlled and process it automatically.
By defining processes, data belonging to the service provider (so-called "process data") can be distinguished from data belonging to the patient (so-called "basic data"), and provided with different access authorizations. By granting access to a process to a role of a requester (so-called "process entitlement"), it indirectly also gains access to the basic data released for the process. The role that defines a process is the owner of that process. It can define further sub-processes, grant process authorizations for the process and / or subordinate processes to other roles and terminals, have them issued automatically, or transfer this competence to other roles (a role basically has process authorization to the further processes subordinate to its actual process).
If the data access rights specified in the original process definition are extended by such a process, or if a new process is defined, this always requires the consent of the owner of the affected basic data.
If a requestor needs access to further basic or process data, he must expand his security context. This is done either by obtaining existing process tokens for one of the requester's roles (whereby the requester can choose the role itself), or by defining a new process using a requisitionor role.
The extension of the security context is the second part of the method for determining, controlling and setting access permissions to health-related data. The prerequisite is the prior establishment of a security context as described above, within which the subsequent part of the process can proceed. This second part of the process can be represented as an algorithm with the following steps:
<tb> (1) <sep> The requestor's smart card is removed from the terminal's reader if the security context was started using a smart card.
<tb> (2) <sep> The smart card of another person is inserted in the reader of the terminal and the identification stored on it is read.
<tb> (3) <sep> The terminal informs the clearing house that the security context of the requester should be extended.
<tb> (4) <sep> The clearing house uses the processor identification of the terminal and the rights acquired to verify that the requested operation is allowed on the terminal being used. If the terminal is not intended for the requested operation, the clearing house aborts the process.
<tb> (5) <sep> The terminal transmits the read-in identification to the clearing house.
<tb> (6) <sep> The clearing house determines the currently valid process tokens associated with the identification.
<tb> (7) <sep> The clearing house compares the process tokens with those of the requestor's roles.
<tb> (8) <sep> The clearing house determines the requestor's process rights for matching process tokens.
<tb> (9) <sep> The clearing house transmits the process token associated with the read identification, process descriptions and any process rights of the requestor to the terminal.
<tb> (10) <sep> The terminal displays this information to the requester.
<tb> (11) <sep> The requestor indicates whether to acquire an existing process token (go to step 12) or to define a new process (go to step 25).
<tb> (12) <sep> The requestor specifies for which of its roles the security context should be extended.
<tb> (13) <sep> The terminal transmits the information to the clearing house.
<tb> (14) <sep> The clearing house determines the possible process rights of the requester and transmits them to the terminal.
<tb> (15) <sep> The terminal displays this to the requester.
<tb> (16) <sep> The requestor indicates whether he presents the process rights as presented by the terminal or in another form.
<tb> (17) <sep> The terminal formulates an application and sends it to the clearing house.
<tb> (18) <sep> The clearing house stores the request until the process owner logs on to the clearing system.
<tb> (19) <sep> The clearing house sends the request to the terminal to which the process owner is registered.
<tb> (20) <sep> The terminal to which the process owner is logged in shows the request.
<tb> (21) <sep> The process owner unconditionally approves the application, with corrections, or rejects it.
<tb> (22) <sep> The terminal to which the process owner is logged in sends its response to the clearinghouse.
<tb> (23) <sep> Depending on the process owner's response, the clearinghouse extends the security context of the requestor. For this purpose, any newly acquired process token is entered in the token list of the role selected by the requester, which links the newly issued process rights of the requestor with the process token. The clearing house stores the process token on the requestor's terminal.
<tb> (24) <sep> The requestor's terminal prompts him to insert his smartcard into the reader and stores the process token on the requester's smartcard. Continue with step 34.
<tb> (25) <sep> The requester defines a new process by assigning to the process terminals and roles that should have process rights and specifying their access rights to the basic data of the second smartcard.
<tb> (26) <sep> The terminal formulates an application and sends it to the clearing house.
<tb> (27) <sep> The clearinghouse stores the request until the owner of the second smartcard successfully logs on to the clearing system.
<tb> (28) <sep> The clearing house sends the request to the terminal where the owner of the second smartcard is registered.
<tb> (29) <sep> The terminal to which the owner of the second smartcard is logged in will show the request.
<tb> (30) <sep> The owner of the second smartcard fully or unconditionally acknowledges the application, with corrections, or rejects it.
<tb> (31) <sep> The terminal to which the owner of the second smartcard is registered sends its response to the clearing house.
<tb> (32) <sep> Depending on the feedback from the owner of the second smartcard, the clearinghouse extends the security context of the requestor. It generates a one-to-one process token. The token is composed of the date, time, identification number of the processor chip of the terminal used by the requester, as well as the identification numbers of the requestor and the owner of the second smartcard. The process token is only valid for a limited time, which can be determined by the process owner (the requester or a role designated by him) and possibly extended - but only with the consent of the owner of the basic data. The process token is entered in the token list of the role chosen by the requester, as well as in the token list of the owner of the second smartcard.
The newly defined process rights of the requester are linked to the process token. The clearing house stores the process token on the terminal (s) where the requester resp. the owner of the second smart card has logged on.
<tb> (33) <sep> The mentioned terminals require the requester resp. Owners of the second smart card to insert the respective smart card in the reader and store the process token on the respective smart card.
<tb> (34) <sep> This expands the security context and completes the expansion process.
The method for determining, controlling and determining the access authorization is thus based on the definition of processes, the comparison of process tokens and the associated process rights.