DE102004055938A1

DE102004055938A1 - Generieren und Verwalten eines Rechte-Kontextes für die Auftragsabwicklung von technischen Prozessen

Info

Publication number: DE102004055938A1
Application number: DE200410055938
Authority: DE
Inventors: Karlheinz Dorn; Ralf Hofmann; Ivan Murphy; Andreas Schülke
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2004-11-19
Filing date: 2004-11-19
Publication date: 2006-05-24

Abstract

Die Erfindung betrifft eine Vorrichtung, ein Verfahren und eine System-Anordnung zur Ausführung eines Auftrages eines Benutzers, bei dem es notwendig ist, eine Berechtigung zur Ausführung des Auftrages des Benutzers zu überprüfen. Die Berechtigung zur Auftragsausführung wird in einem Rechte-Kontext (18) definiert. Bei Auftragsvergabe seitens eines Benutzers wird der Rechte-Kontext (18) für den Auftrag erfasst, überprüft und für die Dauer des Auftrags eingefroren, damit sichergestellt werden kann, dass der Auftrag auch bei einer Änderung des Rechte-Kontextes (18) zur Laufzeit vollständig ausgeführt werden kann.

Description

Die Erfindung liegt auf dem Gebiet der Auftragsabwicklung von technischen Prozessen, die zumindest teilweise eine Authentifizierung bzw. eine Berechtigung zur Ausführung des Auftrages erfordern.
Die Erfindung bezieht sich insbesondere auf die Ausführung solcher Aufträge und die Verwaltung von Rechten, die in Zusammenhang mit der Ausführung des Auftrages relevant sind.

Das Hauptanwendungsgebiet der vorliegenden Erfindung sind alle technischen Prozesse, die in eine Vielzahl von Funktionen, Aufträgen bzw. Subprozessen in einem verteilten System untergliedert sein können und die eine Auftragsberechtigung erfordern. Bei einer Vielzahl von technischen Prozessen ist eine Berechtigung bzw. eine Authentifizierung zur Ausführung des Prozesses notwendig. Dies ist vor allem bei solchen Prozessen der Fall, die auf einer Verarbeitung von sicherheitsrelevanten Daten basieren. Dies sind beispielsweise medizinische Systeme, die sicherheitskritische Patientendaten verarbeiten. Ein anderes Anwendungsgebiet sind Systeme des Geldzahlungsverkehrs, die sicherheitsrelevante Daten in Form von Kreditkartennummern, PIN-Nummern oder sonstigen konto-spezifischen Daten verarbeiten.

Bei den eingesetzten Systemen handelt es sich in der Regel um Multi-User-Systeme, bei denen ein Auftrag von unterschiedlichen Benutzern ausgeführt und/oder initiiert werden kann. Von daher ist es notwendig, die Berechtigung des jeweiligen Benutzers vor Ausführung eines solchen Auftrages zu erfragen bzw. zu erfassen. So wird beispielsweise in der Regel ein Arzt aus einer Röntgenabteilung umfassendere Zugriffsrechte auf Röntgenbilder haben, als ein medizinisch-technischer As sistent in einem Labor, der nur im Ausnahmefall Röntgenbilder anfordert.

Da bei Multi-User-Systemen eine Fluktuation der Benutzer unumgänglich ist, ist es notwendig, die Rechte der unterschiedlichen Benutzer zu verwalten. Auf der einen Seite muss berücksichtigt werden, dass neue Benutzer hinzukommen und bestehende Benutzer wegfallen können. Zum anderen können sich auch bestehende Rechte ein und desselben Benutzers über die Zeit verändern. Diese Veränderungen müssen berücksichtigt werden. Je nach Anwendungsgebiet ist es möglich, dass der Auftrag ein größeres Zeitintervall beansprucht, so dass während der Abarbeitung des Auftrags mehrere Rechteüberprüfungen notwendig sind. Ebenso ist es möglich, dass es sich bei dem Auftrag um einen Folgeauftrag handelt, z.B. um den Auftrag zur Beschriftung von allen neu erstellten Röntgenbildern. Insgesamt kann es sich bei dem Gesamtauftrag um einen Auftrag von unbegrenzter Dauer handeln.

Schwierigkeiten ergeben sich bei Systemen aus dem Stand der Technik dann, wenn die beiden zuvor genannten situativen Kontextbedingungen erfüllt sind, nämlich dann, wenn ein komplexer oder langer Auftrag eine mehrfache Überprüfung eines Rechte-Kontextes erfordert und wenn es zusätzlich möglich ist, dass sich dieser Rechte-Kontext während der Dauer der Abarbeitung des Auftrages ändert. Das kumulative Auftreten dieser beiden Szenarien führte bei bekannten Systemen aus dem Stand der Technik häufig zu schwerwiegenden Fehlern.

Soll z.B. ein Arzt als Benutzer des Systems auf bestimmte Röntgenbildsätze zugreifen und die Zugriffsrechte ändern sich aufgrund von allgemeinen Konfigurationsänderungen dieses Benutzers während des Zugriffs (anfangs verfügt der Arzt über alle Rechte und dann wird er in seinen Rechten eingeschränkt), so war es in der Regel bisher nicht möglich, dass der Auftrag vollständig durchgeführt werden konnte. Dies konnte weitere Fehler nach sich ziehen, indem beispielsweise die Bilder nicht rechtzeitig auf einem Röntgenfilm zur Diagnose zur Verfügung standen, Bilder verloren gingen, die Bilder neu in Auftrag gegeben werden müssen und/oder dass Konfigurationsänderungen zentral rückgängig gemacht werden müssen, um daraufhin den Auftrag erneut ausführen zu lassen.

Eine Verarbeitung durch medizintechnische Geräte, die eine dynamische Veränderung von Zugriffsrechten und/oder einen Sicherheits-Kontext berücksichtigen, ist bisher nicht bekannt.

Bisher war es vorgesehen, Konfigurationsänderungen nur dann auszuführen, wenn keine Aktivitäten auf den jeweiligen medizintechnischen Geräten laufen, für die die jeweiligen Konfigurationen gelten sollten. Die Möglichkeit, auch während des Betriebs bzw. während eines Zugriffs eine Konfigurationsänderung auszuführen, waren von daher bislang sehr beschränkt.

Des weiteren führte das Vorgehen bei den Systemen aus dem Stand der Technik zu dem Nachteil, dass die Veränderung des Rechte-Kontextes blockiert werden konnte, indem ein Benutzer immer wieder oder sehr lange Aufträge initiiert, da während der Zeit der Auftragsabarbeitung eine Änderung des Rechte-Kontextes bislang nicht möglich war.

Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem eine dynamische Änderung eines Rechte-Kontextes eines Benutzers bei der Ausführung von Aufträgen, die von mehreren Benutzern beauftragt werden können, berücksichtigt werden kann und der es ermöglicht, eine Sicherheitsumgebung des Benutzers zu verwalten.

Diese Aufgabe wird durch ein Verfahren zur Ausführung eines Auftrages gelöst, wobei der Auftrag zumindest eine Auftragsberechtigung erfordert und nur vollständig und fehlerfrei ausgeführt werden kann, wenn eine Überprüfung der Auftragsberechtigung erfolgreich verläuft, wobei die Auftragsberechti gung in einem sogenannten Rechte-Kontext definiert ist, mit folgenden Verfahrensschritten:

– Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages durch Verarbeitung des erfassten Rechte-Kontextes und bei erfolgreicher Überprüfung:
– Ausführen des Auftrages unter Verwendung des erfassten Rechte-Kontextes.

Üblicherweise wird das Verfahren immer dann angestossen, sobald eine Recht Prüfung bei einem Auftrag notwendig ist. Es ist jedoch auch möglich, dass das Verfahren iterativ angewendet wird, indem es auch für einen Auftrag mehrfach durchlaufen wird. Dies ist dann sinnvoll, wenn der Auftrag in mehrere Sub-Aufträge aufgespalten ist und/oder wenn mehrere Rechte-Prüfungen über die Zeitdauer der Auftragsabarbeitung notwendig sind.

In der Regel ist es vorgesehen, dass der Rechte-Kontext von dem erfindungsgemäßen Verfahren für einen Benutzer und/oder für eine Gruppe von Benutzern definiert und erfasst wird. Alternativ oder kumulativ ist es auch möglich, dass der Rechte-Kontext für einen bestimmten Auftrag definiert und erfasst wird.

Der Rechte-Kontext umfasst neben den Zugriffsrechten des jeweiligen Benutzers auch die Sicherheitsumgebung des Benutzers und kann darüber hinaus weitere Einstellungen und Parameter umfassen, wie insbesondere die Zugriffsrechte auf Datenobjekte, Rechte für neu angelegte Daten, benutzer-spezifische Einstellungen und/oder Filter, die beim Auditing (sicherheitstechnische Überprüfungsmechanismen und -verfahren) angewendet werden sollen, etc.

In der bevorzugten Ausführungsform erfolgt das Erfassen, das Überprüfen und/oder das Ausführen des Auftrages automatisch. Dies hat den Vorteil, dass Fehleingaben vermieden werden können und die jeweils erforderlichen Datensätze automatisch ü ber vorgesehene Schnittstellen eingelesen werden können. Alternativ ist es jedoch möglich, zumindest einen dieser drei vorstehend genannten Vorgänge auch halbautomatisch auszuführen, indem die notwendigen Daten über eine Benutzerschnittstelle eingegeben werden können oder von zugeordneten Dateien eingelesen werden.

Vorzugsweise ist das erfindungsgemäße System so ausgebildet, dass eine dynamische Veränderung der Auftragsberechtigung und/oder des Rechte-Kontextes möglich ist. Damit ist es möglich, die Auftragsberechtigung und/oder den Rechte-Kontext auch während der Abarbeitung eines Auftrages zur verändern, ohne dass die Abarbeitung des Auftrages beeinflusst wird. Der Auftrag wird dann mit dem Rechte-Kontext ausgeführt, der unmittelbar vor Beginn der Ausführung des Auftrages aktuell war. Damit bleibt der erfindungsgemäß erfasste Rechte-Kontext während der Auftragsausführung konstant. Es wird somit sichergestellt, dass nur die jeweils aktuelle Sicherheitsumgebung des Benutzers für die Auftragsausführung verwendet wird. Dies erhöht die Zuverlässigkeit des Systems, da sichergestellt ist, dass ein Auftrag – auch bei einer Änderung des Rechte-Kontextes – vollständig ausgeführt wird. Weiterhin steigt die Flexibilität des Systems, indem der Rechte-Kontext zu beliebigen Zeitpunkten verändert werden kann, ohne dass die Auftragsausführung eines laufenden Auftrages behindert oder gestört wird.

Vorteilhafterweise umfasst das Verfahren ein Verwalten des Rechte-Kontextes. Das Verwalten des Rechte-Kontextes erfolgt vorzugsweise automatisch. Das Verwalten des Rechte-Kontextes umfasst ein erstmaliges Erfassen des Rechte-Kontextes, ein Erfassen von Änderungen des Rechte-Kontextes, eine Aktualisierung des Rechte-Kontextes in Bezug auf den jeweils laufenden Auftrag und ein Löschen des Rechte-Kontextes, falls dieser nicht mehr notwendig ist, z.B. wenn der Auftrag vollständig ausgeführt worden ist. Es ist möglich, dass ein Auftrag Subaufträge hat. Das ist dann der Fall, wenn ein relativ auf wendiger und komplexer technischer Prozess in technische Subprozesse untergliedert ist, die zum Teil auch über Rechnergrenzen hinweg auf anderen Applikationen ausgeführt werden können. Bei der erfindungsgemäßen Lösung werden auch diese technischen Subprozesse bei der Verwaltungsaufgabe berücksichtigt. So kann es beispielsweise voreingestellt sein, dass ein Subprozess automatisch den Rechte-Kontext des hierarchisch übergeordneten Prozesses erbt. Darüber hinaus ist es möglich, dass parallel – zeitgleich oder zeitversetzt – mehrere Aufträge auf mehreren Applikationen mit jeweils unterschiedlichem Rechte-Kontext eines Benutzers ausgeführt werden können.

Es ist voreingestellt, dass automatisch der Rechte-Kontext für den jeweiligen Auftrag angewendet wird, der jeweils unmittelbar vor Beginn der Ausführung des Auftrages gilt. In einer alternativen Ausführungsform der Erfindung ist der Rechte-Kontext nicht für die gesamte Dauer des Auftrages konstant, sondern kann für kleinere Teileinheiten des Auftrages verändert werden und wird somit für einen Auftrag jeweils mehrfach neu bestimmt.

Bei einem Auftrag handelt es sich grundsätzlich um einen technischen Prozess, der die Verarbeitung von technischen Geräten erfordert, insbesondere von medizintechnischen Geräten. Der Auftrag ist deshalb geräte-basiert und greift vorzugsweise auf Hardware- und/oder Software-Module zurück. Üblicherweise ist ein Auftrag auf mehrere Applikationen verteilt, die jeweils kommunikationstechnisch über ein Netzwerk miteinander verbunden sind. Es ist möglich, dass zu einem Zeitpunkt für unterschiedliche Applikationen und/oder für unterschiedliche Aufträge ein unterschiedlicher Rechte-Kontext ein und desselben Benutzers vorliegt.

Das Verfahren umfasst mehrere Verfahrensschritte, die nicht notwendigerweise auf ein und demselben Gerät ausgeführt werden müssen. So ist es möglich, dass die Definition des Rech te-Kontextes, das Erfassen des Rechte-Kontextes, das Überprüfen der Auftragsberechtigung und/oder das Ausführen des Auftrages selbst jeweils auf unterschiedlichen Geräten und damit auch ,remote' ausgeführt werden können. Dabei stehen üblicherweise alle Geräte datentechnisch über ein Netzwerk in Kommunikationsverbindung. Üblicherweise erfolgt die Vergabe bzw. die Definition des Rechte-Kontextes zentral und an anderer Stelle (bezogen auf das datentechnische Netzwerk) als die Überprüfung der Zugriffsberechtigung des Benutzers auf Datensätze einer bestimmten Applikation.

Üblicherweise ist der Rechte-Kontext einem Benutzer zugeordnet. Neben den Zugriffsberechtigungen des Benutzers auf Applikationen, auf Datensätze der Applikationen und auf Funktionen innerhalb den Applikationen (Brennen einer CD, Senden von Daten über ein Netzwerk, Ausführen bestimmter applikations-spezifischer Funktionalitäten) umfasst der Rechte-Kontext auch den Benutzernamen und dessen Domäne, die Gruppenzugehörigkeit des Benutzer und/oder bestimmte Voreinstellungen des Benutzers. Alternativ ist es vorgesehen, den Rechte-Kontext auftrags-spezifisch auszuführen, sodass für einen Auftrag definiert ist, welcher Benutzer bzw. welche Gruppe von Benutzern zur Ausführung dieses Auftrages berechtigt sind. In einer vorteilhaften Weiterbildung der Erfindung ist der Rechte-Kontext sowohl Benutzer- als auch auftrags-spezifisch ausgebildet. Damit kann vorteilhafterweise die Flexibilität des Systems erhöht werden, indem weitere Details in Bezug auf Sicherheit, Rechtevergabe, Voreinstellungen etc. einstellbar sind.

Ein besonderer Vorteil des erfindungsgemäßen Verfahrens ist darin zu sehen, dass die Vergabe bzw. Definition des Rechte-Kontextes zeitlich und/oder inhaltlich von der Überprüfung des Rechte-Kontextes gelöst ist. Damit wird es möglich, dass der Rechte-Kontext zentral und zu einem beliebigen Zeitpunkt definiert wird, während eine Überprüfung des Rechte-Kontextes nur dann erfolgt, wenn sie erforderlich ist. Vorzugsweise er folgt die Überprüfung unmittelbar vor einer Auftragsausführung und/oder vor einer berechtigungs-erforderlichen Aktion bei der Auftragsausführung (z.B. einem Zugriff auf sicherheitsrelevante Daten), um sicherzustellen, dass für den jeweiligen Auftrag oder für die notwendigen Aktionen des Auftrags jeweils der aktuelle Sicherheits-Kontext und Rechte-Kontext berücksichtigt werden. In der Regel erfolgen das Erfassen des Rechte-Kontextes und das Überprüfen der Auftragsberechtigung in einem der Auftragsausführung zeitlich vorgelagerten Zeitintervall. Das Erfassen des Rechte-Kontextes ist davon unabhängig.

Falls es sich bei dem Auftrag um einen komplexen Auftrag handelt, der in Unteraufträge unterteilt ist, so ist es in einer vorteilhaften Weiterbildung der Erfindung voreingestellt, dass der Rechte-Kontext des hierarchisch übergeordneten Auftrages automatisch identisch als Rechte-Kontext der hierarchisch untergeordneten Subaufträge verwendet wird. Die Unteraufträge arbeiten dann mit dem erfassten bzw. eingefrorenen Rechte-Kontext des Auftrags. In dieser Ausführungsform wird sozusagen ein Status des Rechte-Kontextes an Sub- bzw. Unteraufträge vererbt. In diesem Fall kann der Verfahrensschritt des Überprüfens der Auftragsberechtigung für die Unteraufträge entfallen. Das Überprüfen der Auftragsberechtigung erfolgt lediglich für den Auftrag selbst und alle Unteraufträge werden automatisch als berechtigt erfasst und somit automatisch ausgeführt. Falls es sich jedoch als sinnvoll erweist, auch eine Auftragsberechtigung für die Unteraufträge auszuführen, so erfolgt in einer alternativen Ausführungsform automatisch oder wahlweise nach Einstellung des System-Administrators eine Überprüfung der Auftragsberechtigung für die Ausführung des Unterauftrages.

Grundsätzlich ist die erfindungsgemäße Lösung so ausgelegt, dass während der Auftragsausführung ausschließlich der erfasste Rechte-Kontext gilt. Parallel dazu kann es jedoch einen Rechte-Kontext des Benutzers geben, in dem beispielsweise Konfigurationsänderungen berücksichtigt werden, die sich zur Laufzeit des Auftrags bzw. zur Auftragsabwicklungszeit ergeben. Dieser (allgemeine) Rechte-Kontext gilt dann für zukünftige Auftragsausführungen, nicht jedoch für die laufende Auftragsabwicklung. Darüber hinaus ist es vorgesehen, dass der erfasste Rechte-Kontext nur für die Dauer der Auftragsausführung existiert und im System gespeichert wird und nach Beendigung der Auftragsausführung wieder gelöscht wird. Dies führt zu einer einfacheren Wartung und Aktualisierung des Systems.

In einer weiteren vorteilhaften Weiterbildung erfasst das erfindungsgemäße Verfahren einen zusätzlichen Verfahrens-Schritt:

– Anzeige des erfassten Rechte-Kontextes.

Dadurch wird die Auftragsabwicklung für den jeweiligen Benutzer transparenter. Ergibt die Überprüfung der Auftragsberechtigung nämlich, dass der Benutzer für diesen Auftrag nicht berechtigt ist, so kann er nicht ausgeführt werden. Dann erscheint auf einer Bildschirmoberfläche ein entsprechendes Fenster, in dem der Benutzer auf diese Tatsache hingewiesen wird. Um den Benutzer jedoch nicht mit unnötigen Anzeigen von erfolgreichen Überprüfungen der Zugriffsberechtigungen zu konfrontieren, ist es in einer alternativen Ausführungsform der Erfindung vorgesehen, dass die Anzeige nur dann erfolgt, wenn die Überprüfung nicht erfolgreich war.

In der bevorzugten Ausführungsform ist die Verwaltung des Rechte-Kontextes nicht prozesslokal und kann damit auch von anderen Prozessen und/oder anderen Applikationen bzw. Rechnern verwendet werden.

Die Erfindung basiert auf der Verwendung eines zentralen Rechte-Kontextes. Damit ist vorteilhafterweise auch eine zentrale Verwaltung bzw. Veränderung des Rechte-Kontextes möglich. Bisherige Systeme basieren auf einer applikations verwalteten Überwachung von Zugriffsrechten. Eine zentrale Verwaltung war bislang nicht möglich.

Darüber hinaus wird die Aufgabe durch eine Vorrichtung und eine System-Anordnung gemäß den nebengeordneten Hauptansprüchen gelöst. Die vorstehend beschriebenen Ausführungsmöglichkeiten und alternativen Gestaltungen des erfindungsgemäßen Verfahrens sind ebenso auf die erfindungsgemäße Vorrichtung und die erfindungsgemäße System-Anordnung anwendbar.

Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahren können auch als Computerprogrammprodukt ausgebildet sein, mit einem von einem Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln, wobei der Computer nach Laden des Computerprogramms zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlaßt wird.

Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.

Zusätzliche, vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.

In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung von wesentlichen Modulen gemäß einer bevorzugten Ausführungsform der Erfindung,
2 ein Ablaufdiagramm gemäß der bevorzugten Ausführungsform der Erfindung und
3 ein Ablaufdiagramm für eine erfindungsgemäße Auftragsabarbeitung in einer Ausführungsform.
In Zusammenhang mit 1 werden nachfolgend die wesentlichen Module und Bauteile gemäß einer bevorzugten Ausführungsform der Erfindung erläutert.
Eine allgemein mit 10 bezeichnete Vorrichtung umfasst zumindest ein Erfassungsmodul 12, zumindest ein Überprüfungsmodul 14 und üblicherweise mehrere Ausführungsmodule 16.
Üblicherweise ist das System als Multi-User-System ausgebildet, sodass eine Vielzahl von Benutzern bzw. Benutzern Aufträge ausführen oder Prozesse initiieren kann. Wird die erfindungsgemäße Lösung auf medizintechnische Systeme in einer komplexen Organisation, wie beispielsweise in einem Krankenhaus, angewendet, so müssen den unterschiedlichen Benutzern jeweils eineindeutig bestimmte Rechte einer Sicherheitsumgebung und/oder benutzer-spezifische Parameter und Einstellungen zugeordnet werden. Diese Einstellungen sind in einem sogenannten Rechte-Kontext 18 zusammengefasst.
Der Rechte-Kontext 18 ist vorzugsweise eine benutzerspezifische Datenstruktur. Dies ist in 1 durch die geschwungene Linie angedeutet, die eine Zuordnung zwischen Benutzer und Rechte-Kontext 18 darstellen soll. Es ist jedoch auch möglich, den Rechte-Kontext 18 auftrags-spezifisch auszubilden. Dies sei durch die geschwungene Linie in 1 zwischen dem Auftrag und dem Rechte-Kontext 18 angedeutet. Dann wird jedem Auftrag ein auftrags-spezifischer Rechte-Kontext 18 zugeordnet. Möchte beispielsweise ein Arzt auf einen bestimmten Röntgenfilm zur Diagnose zugreifen, so muss sein Rechte-Kontext 18 anders gestaltet sein, als wenn beispielsweise ein Assistent die erfassten Röntgenbilder lediglich auf Vollständigkeit hin überprüfen möchte, ohne weitere Manipulationen an den Daten vorzunehmen. Im ersten Fall sollte der Arzt umfangreichere Zugriffsrechte haben, die bei spielsweise auch ein Löschen von irrelevanten Bildern erlauben.
Üblicherweise wird ein Auftrag auf mehrere Ausführungsmodule 16 aufgeteilt, die ihrerseits über ein Netzwerk in Datenaustausch miteinander und mit weiteren Modulen stehen. In der Regel greift ein komplexer Auftrag auf verschiedene Applikationen bzw. Prozesse oder Ausführungsmodule 16 zu. Diese Situation ist in 1 dargestellt.
Gibt beispielsweise ein Benutzer eines Krankenhaus-Informationssystems diesem System einen Auftrag, ein Röntgenfilmblatt einzulesen, so wird es in der Regel notwendig sein, ein entfernt liegendes Ausführungsmodul 16 zu beauftragen. Erfindungsgemäß muss vor dem Auftrag nun überprüft werden, ob der jeweilige Benutzer auch zur Ausführung des Auftrages berechtigt ist.
Deshalb wird jedem Benutzer des Systems ein Rechte-Kontext 18 zugeordnet. Es ist möglich, dass dieser Rechte-Kontext 18 sich verändert. So können auch insbesondere während eines Auftrags die Zugriffsrechte des Benutzers erweitert oder eingeschränkt werden. Die Definition bzw. Vergabe des Rechte-Kontext 18 für einen bestimmten Benutzer kann zu einem beliebigen Zeitpunkt in einer zentralen Definitionsphase erfolgen. Diese Phase ist zeitlich und/oder inhaltlich losgelöst von der nachfolgenden Überprüfungsphase. Dies ist in 2 dargestellt.
Unmittelbar vor Auftragsausführung erfolgt nun ein Zugriff auf den Rechte-Kontext 18 des Benutzers. Der über das Erfassungsmodul 12 erfasste Rechte-Kontext 18 des Benutzers wird dann dem Überprüfungsmodul 14 zugeführt. Das Überprüfungsmodul 14 dient dazu, zu überprüfen, ob der Benutzer auch zur Auftragsausführung berechtigt ist und beispielsweise bestimmte Datensätze lesen und/oder manipulieren kann. Ist dieser Überprüfungsvorgang erfolgreich, so kann der Auftrag ausge führt werden. Daraufhin werden automatisch die jeweiligen Applikationen 16 angesprochen, die zur Auftragsausführung notwendig sind. Der Auftrag kann dann erfolgreich beendet werden.
Ein wesentlicher Aspekt der vorliegenden Erfindung betrifft jedoch die Veränderung des Rechte-Kontextes 18 während der Auftragsabarbeitung. So war es bisher nicht möglich, den Rechte-Kontext 18 während der Verarbeitung zu ändern oder eine Änderung des Rechte-Kontextes 18 während einer laufenden Auftragsbearbeitung musste zu teilweise schwerwiegenden Fehlern führen, da die jeweiligen Applikationen mit einem inkonsistenten Datenstand des Rechte-Kontextes konfrontiert waren.
Verfügt der Benutzer im oben genannten Beispiel über das Recht die Daten zu lesen und zu manipulieren, und startet er daraufhin einen Auftrag, z.B. Datensätze eines Röntgenfilmblattes zu verändern, so erhält der Benutzer üblicherweise eine Bestätigung von dem System, dass sein Auftrag erfolgreich durchgeführt werden kann, da er ja zur Auftragsdurchführung berechtigt ist. Ändert sich nun aber diese Berechtigung nach Beginn der Auftragsabarbeitung und erfordert die Auftragsbearbeitung mehrere Rechte-Überprüfungen, so führen die zeitlich nachgelagerten Rechte-Überprüfungen bei bisherigen Systemen zu einem Fehler, da der Benutzer nun nicht mehr zur Auftragsabarbeitung berechtigt ist. Der Auftrag kann nicht vollständig ausgeführt werden, obwohl der Benutzer vor Beginn des Auftrages berechtigt war. Dieses Fehlverhalten der Systeme nach dem Stand der Technik wird mit der erfindungsgemäßen Lösung vermieden.
Dies wird erreicht, indem unmittelbar vor Auftragsabarbeitung der Rechte-Kontext 18 des jeweiligen Benutzers eingelesen und erfasst wird. Über die Dauer des Auftrags kann dieser erfasste Rechte-Kontext 18 in Bezug auf den jeweiligen Auftrag nicht mehr verändert werden. Ist also der Benutzer bei Auftragsvergabe zur Auftragsvergabe berechtigt, so wird dieser Auftrag auch vollständig und korrekt ausgeführt, unabhängig davon, ob sich während der Auftragsausführung der Rechte-Kontext ändert. Ist dies der Fall und werden beispielsweise dem Benutzer Zugriffsrechte während der Auftragsabarbeitung entzogen, so wird dies in einem Verwaltungsmodul für den Rechte-Kontext 18 gespeichert. Für die aktuelle Auftragsabarbeitung ist aber der von dem Erfassungsmodul 12 erfasste Rechte-Kontext 18 weiterhin gültig. Der Zustand des Rechte-Kontextes 18 unmittelbar vor Auftragsausführung wird somit für die Dauer der Auftragsausführung eingefroren. Nachdem der Auftrag erfolgreich beendet worden ist, kann der erfasste Rechte-Kontext 18 auch wieder gelöscht werden. Für zukünftige Aufträge des Benutzers kann dann der gegebenenfalls veränderte Rechte-Kontext verwendet werden.
In 2 ist ein Ablaufdiagramm gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung dargestellt.
Das erfindungsgemäße Verfahren untergliedert sich in eine Definitionsphase und in eine Überprüfungsphase, die zeitlich und/oder inhaltlich voneinander getrennt erfolgen können. In der Definitionsphase erfolgt vorzugsweise an zentraler Stelle die Definition bzw. die Vergabe des Rechte-Kontextes 18 für einen Benutzer oder für eine Benutzer-Gruppe. Üblicherweise erfolgt die Definition des Rechte-Kontextes 18 beim Einloggen des Benutzers. Es ist jedoch auch möglich, diese Definition zu festgesetzten und voreingestellten Zeitpunkten vorzunehmen.
Vergibt nun der Benutzer einen Auftrag an das System, beispielsweise zum Zugriff auf Datensätze eines Computertomographen, so startet er hiermit die Überprüfungsphase. Die Überprüfungsphase ist von der Definitionsphase entkoppelt. Nach der Beauftragung erfasst das System den Rechte-Kontext 18 für den jeweiligen Benutzer. Daraufhin erfolgt eine Überprüfung des Rechte-Kontextes 18. Hier wird insbesondere untersucht, ob der Benutzer auch zum Zugriff auf die gewünsch ten Datensätze berechtigt ist. Ergibt die Überprüfung, dass er nicht berechtigt ist, so ist es in einer bevorzugten Ausführungsform vorgesehen, dass der jeweilige Rechte-Kontext 18 auf einer Bildschirmoberfläche angezeigt wird. Damit erhält der Benutzer einen Hinweis auf die Tatsache, dass er nicht zur Auftragsausführung berechtigt ist. Daraufhin endet das Verfahren.
Ergibt jedoch die Überprüfung, dass der Benutzer zur Auftragsausführung berechtigt ist, so wird der Auftrag automatisch ausgeführt, indem ein Zugriff auf die jeweiligen Ausführungsmodule 16 erfolgt. Nach vollständigem Beenden des Auftrages kann der für den jeweiligen Auftrag erfasste Rechte-Kontext 18 des Benutzers gelöscht werden. Für weitere, zukünftige Aufträge wird wiederum erneut ein aktueller Rechte-Kontext erfasst. Das Verfahren kann iterativ angewendet werden.
In der bevorzugten Ausführungsform umfasst der Rechte-Kontext 18 neben den Zugriffsrechten weiterhin Privilegien des jeweiligen Benutzers und weitere benutzer-spezifische Einstellungen bzw. Daten, die die Identität des Benutzers referenzieren. Darüber hinaus ist es hier auch möglich einzustellen, dass Objekte, die von dem Benutzer generiert werden – beispielsweise bestimmte Bilddatensätze eines Röntgenarztes – nur einem bestimmten Benutzerkreis zugänglich sein sollen. Ein Benutzer kann also bestimmen, wer zum Zugriff auf die von ihm generierten Objekte berechtigt ist. Diese Berechtigung kann für jeden Datensatz einzeln oder für eine Klasse von Datensätzen (z.B. für alle Datensätze im Bezug auf einen Patienten) erfolgen. Darüber hinaus umfasst der Rechte-Kontext 18 benutzer-spezifische Einstellung und/oder auftrags-spezifische Parameter und/oder Einstellungen, z.B. von Filtern, die beim Auditing angewendet werden sollen. In dem Rechte-Kontext 18 kann beispielsweise eingestellt werden, auf welche Art und/oder in welcher Form bestimmte Benutzer- Gruppen bestimmte Objekte bzw. Datensätze erhalten sollen. Der Rechte-Kontext 18 ist somit zentral.
Deshalb ist es in einer bevorzugten Ausführungsform der Erfindung vorgesehen, dass zusätzlich ein Verwaltungsmodul vorgesehen ist, das zum Verwalten des Rechte-Kontextes 18 bestimmt ist. Das Verwaltungsmodul arbeitet vorzugsweise zentral. Damit wird die Verwaltung des Rechte-Kontextes 18 deutlich vereinfacht. Darüber hinaus kann sichergestellt werden, dass Inkonsistenzen des Rechte-Kontextes 18 vermieden werden.
In der bevorzugten Ausführungsform erfolgt der Zugriff des erfindungsgemäßen Systems auf den Rechte-Kontext 18 nicht bereits bei der Vergabe eines Auftrags des Benutzers oder beim Starten einer Aktivität des Benutzers, sondern erst zum Zeitpunkt innerhalb des Applikationsablaufs, der eine Überprüfung der Berechtigung erfordert. Damit ist die erfindungsgemäße Überprüfung des Rechte-Kontextes ganz speziell auf den Zeitpunkt des Applikationsablaufs zugeschnitten und kann somit mit maximaler Aktualität eingesetzt werden. In Fällen, in denen sich der Rechte-Kontext 18 erst unmittelbar vor dem Zeitpunkt der Überprüfung ändert, kann dies erfindungsgemäß erfasst werden. In diesem Fall kann also der aktuelle Rechte-Kontext 18 zur Auftragsausführung herangezogen werden. Damit kann die Sicherheit des System erhöht werden.
Mit der erfindungsgemäßen Lösung wird es möglich, dass ein Rechte-Kontext 18 auch während eines aktuellen Auftragsablaufs verändert wird, ohne dass die Auftragsabwicklung gestört wird. In diesem Fall unterscheidet sich der für den jeweiligen Auftrag geltende erfasste Rechte-Kontext 18 und der während des Auftrags veränderte Rechte-Kontext 18, der in dem Verwaltungsmodul gespeichert wird und nur für spätere Aufträge herangezogen werden kann.
In 3 ist ein Ablaufdiagramm dargestellt, das eine erfindungsgemäße Auftragsbearbeitung mit einer Überprüfung des Rechte-Kontextes 18 zu einer Hintergrundfunktion zeigt. Hier wird nochmals deutlich, dass ein Auftrag auch Unteraufträge umfassen kann, was durch den Aufruf der ,Applikation2' seitens der ,Applikation' in 3 angedeutet ist.
In der bevorzugten Ausführungsform der Erfindung wird der Rechte-Kontext 18 unmittelbar beim oder nach dem Einloggen des Benutzers auf seinem System erzeugt. Dieser (allgemeine) Rechte-Kontext 18 ist später veränderlich. Nach dem Einloggen können direkt von dem Login-Rechner Aufträge gestartet und Funktionen aktiviert werden, für die bereits der Rechte-Kontext 18 berücksichtigt wird. Der Rechte-Kontext 18 verbleibt auf dem Rechner, der das Login des Benutzers durchgeführt hat. Sind nun zu einem späteren Zeitpunkt weitere Überprüfungen des Rechte-Kontextes 18 gegebenenfalls auf anderen Rechnern (in 3 ,Applikation' und ,Applikation2'), notwendig, so werden diese Überprüfungen nicht dort ausgeführt, sondern die jeweiligen Überprüfungen werden auf den Login-Rechner zurückdelegiert. Dies ist möglich, da bei einer Auftragsvergabe an ,remote' Rechner nur ein Verweis auf den Rechte-Kontext 18 und/oder auf den Benutzer an den ,remote' Rechner weitergereicht wird und dort nicht die Benutzeridentität (d.h. der User Account) weitergegeben bzw. vorhanden sein muss.

Claims

Verfahren zur Ausführung eines Auftrages, der eine Auftragsberechtigung erfordert, so dass der Auftrag nur ausgeführt werden kann, wenn eine Überprüfung der Auftragsberechtigung erfolgreich ist, wobei die Auftragsberechtigung in einem Rechte-Kontext (18) definiert ist, der jeweils für einen Benutzer und/oder jeweils für einen Auftrag erfasst wird, wobei das Verfahren folgende Verfahrensschritte umfasst: – Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages durch Verarbeiten des erfassten Rechte-Kontextes (18) und bei einem erfolgreichen Abschluss der Überprüfung: – Ausführen des Auftrages unter Verwendung des erfassten Rechte-Kontextes (18).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zumindest das Erfassen, das Überprüfen und/oder das Ausführen automatisch erfolgt.
Verfahren nach zumindest einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die Auftragsberechtigung und/oder der Rechte-Kontext (18) dynamisch veränderlich sein können und dass der erfasste Rechte-Kontext (18) während der Ausführung des Auftrages konstant bleibt.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren ein Verwalten des Rechte-Kontextes (18) umfasst.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Auftrag gerätebasiert, insbesondere computerbasiert, ist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren, die Definition des Rechte-Kontextes (18), das Erfassen des Rechte-Kontextes (18), das Überprüfen der Auftragsberechtigung und/oder das Ausführen des Auftrages jeweils auf unterschiedlichen Geräten erfolgen können.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Rechte-Kontext (18) Benutzer- und/oder auftrags-spezifisch ist.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erfassen des Rechte-Kontextes (18) und/oder das Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages erfolgt.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Auftrag zumindest einen Unterauftrag umfassen kann und dass der Unterauftrag – wahlweise automatisch – den erfassten Rechte-Kontext (18) des Auftrags erben kann.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der erfasste Rechte-Kontext (18) nur für die Dauer der Auftragsausführung existiert und danach gelöscht wird.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass parallel verschiedene Aufträge eines Benutzers mit einem jeweils unterschiedlichen erfassten Rechte-Kontext (18) ausgeführt werden können.
Vorrichtung zur Ausführung eines Auftrages, wobei der Auftrag eine Auftragsberechtigung erfordert, so dass er nur ausgeführt werden kann, wenn eine Auftragsberechtigung vorliegt, wobei die Auftragsberechtigung in einem Rechte-Kontext (18) definiert ist, der jeweils für einen Benutzer und/oder jeweils für einen Auftrag mittels eines Erfassungsmoduls (12) erfasst wird, wobei die Vorrichtung (10) folgende in Datenaustausch stehende Module umfasst: – zumindest ein Überprüfungsmodul (14), das zum Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages bestimmt ist durch Verarbeiten des erfassten Rechte-Kontextes (18), und – zumindest ein Ausführungsmodul (16), das zum Ausführen des Auftrages unter Verwendung des erfassten Rechte-Kontextes (18) bestimmt ist, falls das Überprüfungsmodul (14) ein Signal an das Ausführungsmodul (16) gesendet hat, das auf einen erfolgreichen Abschluß der Überprüfung hinweist.
Vorrichtung nach Anspruch 12, dadurch gekennzeichnet, dass zumindest das Erfassungsmodul (12), das Überprüfungsmodul (14) und/oder das Ausführungsmodul (16) automatisch arbeiten.
Vorrichtung nach zumindest einem der Ansprüche 12 oder 13, dadurch gekennzeichnet, dass die Auftragsberechtigung und/oder der Rechte-Kontext (18) dynamisch veränderlich sein können und dass der erfasste Rechte-Kontext (18) während der Ausführung des Auftrages konstant bleibt.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 14, dadurch gekennzeichnet, dass die Vorrichtung ein Verwaltungsmodul umfasst, das zum Verwalten des Rechte-Kontextes (18) bestimmt ist.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 15, dadurch gekennzeichnet, dass der Auftrag gerätebasiert, insbesondere computerbasiert, ist.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 16, dadurch gekennzeichnet, dass die Vorrichtung, ein Modul, das zur Definition des Rechte-Kontextes (18) bestimmt ist, das Erfassungsmodul (12), das Überprüfungsmodul (14) und/oder das Ausführungsmodul (16) jeweils unterschiedlichen Geräten zugeordnet sein können.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 17, dadurch gekennzeichnet, dass der Rechte-Kontext (18) Benutzer- und/oder auftrags-spezifisch ist.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 18, dadurch gekennzeichnet, dass das Erfassungsmodul (12) das Erfassen des Rechte-Kontextes (18) und/oder das Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages initiiert.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 19, dadurch gekennzeichnet, dass ein Auftrag zumindest einen Unterauftrag umfassen kann und dass der Unterauftrag – wahlweise automatisch – den erfassten Rechte-Kontext (18) des Auftrags erben kann.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 20, dadurch gekennzeichnet, dass der erfasste Rechte-Kontext (18) nur für die Dauer der Auftragsausführung existiert und danach gelöscht wird.
Vorrichtung nach zumindest einem der vorhergehenden Ansprüche 12 bis 21, dadurch gekennzeichnet, dass parallel verschiedene Aufträge eines Benutzers mit einem jeweils unterschiedlichen erfassten Rechte-Kontext (18) ausgeführt werden können.
Systemanordnung zur Ausführung eines Auftrages, wobei der Auftrag eine Auftragsberechtigung erfordert, so dass er nur ausgeführt werden kann, wenn eine Auftragsberechtigung vorliegt, wobei die Auftragsberechtigung in einem Rechte-Kontext (18) definiert ist, der jeweils für einen Benutzer und/oder jeweils für einen Auftrag mittels eines Erfassungsmoduls (12) erfasst wird, wobei die Systemanordnung folgende in Datenaustausch stehende Module umfasst: – zumindest ein Verwaltungsmodul, das zum Verwalten des Rechte-Kontextes (18), insbesondere zum Verwalten von Änderungen des Rechte-Kontextes (18), bestimmt ist, – zumindest ein Überprüfungsmodul (14), das zum Überprüfen der Auftragsberechtigung vor Beginn der Ausführung des Auftrages bestimmt ist durch Verarbeiten des erfassten Rechte-Kontextes (18), und – zumindest ein Ausführungsmodul (16), das zum Ausführen des Auftrages unter Verwendung des erfassten Rechte-Kontextes (18) bestimmt ist, falls das Überprüfungsmodul (14) ein Signal an das Ausführungsmodul (16) gesendet hat, das auf einen erfolgreichen Abschluß der Überprüfung hinweist.