DE10348371A1

DE10348371A1 - Mehrfachorganisationsdatenzugriffsüberwachungs- und -managementsystem

Info

Publication number: DE10348371A1
Application number: DE10348371A
Authority: DE
Inventors: William D. Lusen
Original assignee: Siemens Medical Solutions Health Services Corp
Current assignee: Siemens Medical Solutions USA Inc
Priority date: 2002-10-18
Filing date: 2003-10-17
Publication date: 2004-05-19
Also published as: US20040128169A1

Abstract

Ein System zur Überwachung der Aktivität einer ausführbaren Anwendung, mit einem Eingabeprozessor, einem Ereignisprozessor, einem Überwachungsprozessor und einem Ausgabeprozessor. Der Eingabeprozessor empfängt eine Nachricht, die ein Ereignis identifiziert, welches die Aktivität repräsentiert, die von einer ausführbaren Anwendung ausgeführt wird, und Daten aufweist, die mit dem Ereignis in Zusammenhang stehen. Die ereignisbezogenen Daten umfassen einen Startzeitpunkt und einen Endzeitpunkt des Ereignisses. Der Ereignisprozessor speichert einen Datensatz des identifizierten Ereignisses und die ereignisbezogenen Daten in einem Datensatzspeicher. Der Überwachungsprozessor wählt bestimmte Ereignisse aus zur Verwendung in der Überwachung einer bestimmten Aktivität der ausführbaren Anwendung in Antwort auf einen empfangenen Befehl. Der Ausgabeprozessor vergleicht ereignisbezogene Daten, die von dem Datensatzspeicher abgefragt werden, für die ausgewählten bestimmten Ereignisse, und verarbeitet und formatiert die verglichenen Ereignisdaten zur Präsentation an einen Benutzer.

Description

Die Erfindung betrifft allgemein Informationssysteme. Speziell betrifft die Erfindung ein Informationssystem, welches ein Mehrfachorganisationsdatenzugriffsüberwachungs- und -managementsystem aufweist.

Viele Industrien, Organisationen und Unternehmen (jeweils allgemein als Unternehmen bezeichnet), beispielsweise medizinische Versorgungsunternehmen, verwenden ein elektronisches Informationssystem, um ihre Tätigkeiten zu organisieren und zu optimieren. Die Tätigkeiten umfassen jeden Ablauf im Unternehmen, beispielsweise die Buchführung, die Aktenaufbewahrung, die Textverarbeitung, das Dokumentenabbilden, die Planung, etc..

Unternehmen, wie beispielsweise medizinische Versorgungsunternehmen, haben steigende Anforderungen an Sicherheit, Verantwortlichkeit und Produktivität. Insbesondere brauchen Unternehmen, die ein Softwaresystem haben, beispielsweise ein Dokumentenimagingsystem, Benutzer und Überwachungsmanagement, um ein Verfahren bereitzustellen, um eine Verarbeitung zu verfolgen und zu berichten, die von Dokumenten-Imaginganwendungen in dem System durchgeführt wird, ansprechend auf eine automatisierte Verarbeitung oder eine Benutzeranfrage. Obwohl eine Aufzeichnung von Prozessen auf Papier von Hand erfolgen kann, um Benutzeranfragen zu verfolgen, reduziert die Zeit, die Benutzer brauchen, um die Papieraufzeichnung von Hand zu erzeugen, die Produktivität, und berücksichtigt keine Tätigkeiten, die von automatischen Prozessen durchgeführt werden. Ausgehend von dem Vorangegangenen, wäre es wünschenswert, einen zentralen softwareangetriebenen Mechanismus zu haben, der die verarbeitete Information automatisch überwacht und aufzeichnet. Entsprechend besteht Bedarf nach einem Mehrfachorganisationsdatenzugriffsüberwachungs- und -managementsystem, das diese und andere Nachteile bereits bekannter Systeme überwindet.

Gemäß einem Aspekt der Erfindung weist ein System zur Überwachung der Aktivität einer ausführbaren Anwendung einen Eingabeprozessor, einen Ereignisprozessor, einen Überwachungsprozessor und einen Ausgabeprozessor auf. Der Eingabeprozessor empfängt eine Nachricht, die ein Ereignis identifiziert, das die Aktivität repräsentiert, die von einer ausführbaren Anwendung ausgeführt wird, und Daten enthält, die mit dem Ereignis in Zusammenhang stehen. Die mit dem Ereignis in Zusammenhang stehenden Daten umfassen eine Start- und Endzeit des Ereignisses. Der Ereignisprozessor speichert einen Datensatz des identifizierten Ereignisses und mit dem Ereignis in Zusammenhang stehende Daten in einem Datensatzspeicher. Der Überwachungsprozessor wählt bestimmte Ereignisse aus, zur Verwendung bei der Überwachung eines bestimmten Ablaufs der ausführbaren Anwendung, in Antwort auf einen empfangenen Befehl. Der Ausgabeprozessor vergleicht ereignisbezogene Daten, die aus dem Datensatzspeicher wiedergewonnen werden, für die ausgewählten bestimmten Ereignisse, und verarbeitet und formatiert die verglichenen Ereignisdaten, um sie einem Benutzer darzustellen.

1 zeigt eine Blockdiagramm eines Audit-Subsystems eines Informationssystems gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
2 zeigt eine grafische Darstellung eines Ereignisspeichers, der durch Verwendung einer relationalen Datenbank implementiert ist, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
3 zeigt ein Benutzerschnittstellenfenster, welches den Job Status liefert, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
4 zeigt ein Benutzerschnittstellenfenster, welches Audit-Reports liefert, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
5 zeigt ein Audit-Report Inhaltsverzeichnis, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
6 zeigt einen Mehrfachbenutzungsreport, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
7 zeigt ein Benutzerschnittstellenfenster, welches Audit-Reporttypen zur Verfügung stellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
8 zeigt ein medizinisches Versorgungsunternehmen, welches Ereignisse aufweist, die auf Unternehmensebene und auf Organisationsebene geprüft werden, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
9 zeigt ein Benutzerschnittstellenfenster, welches Sicherheitsfunktionen bereitstellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
10 zeigt ein Benutzerschnittstellenfenster, welches eine Gruppenauswahl bereitstellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
1 zeigt ein Blockdiagramm eines Audit-Subsystems 100 eines Informationssystems, das von einem Unternehmen verwendet wird, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Das Unternehmen umfasst einen Organisationstyp oder mehrere Organisationstypen, umfassend jedoch nicht darauf beschränkt, (a) ein Krankenhaus, (b) eine Arztgruppe, (c) eine Klinik, (d) eine Gesundheitsvorsorgezahlerorganisation, (e) eine Gesundheitsvorsorgeanbieterorganisation und (f) eine Krankenhausabteilung.
Das Audit-Subsystem 100 stellt im allgemeinen einen zentralisierten Mechanismus zur Verfügung, um den Ablauf, der von irgendeiner Softwareanwendung durchgeführt wird (im übrigen als ausführbare Anwendung bezeichnet) aufzuzeichnen (allgemein gesprochen "zu überwachen") und zu berichten (allgemein gesprochen "zu verwalten"), entweder veranlasst durch einen Benutzer oder einen automatisierten Prozess. Das Audit-Subsystem 100 stellt einen Dienst bereit, der von irgendeinem Softwareprozess aufgerufen werden kann, um einen Datensatz dieser Verarbeitung zu speichern. Das Audit Subsystem 100 stellt auch ein Mittel bereit, um über verarbeitete Datensätze, die es gesammelt hat, zu berichten.
Für Zwecke einer Auditierung umfasst die Aktivität in einem Informationssystem unabhängige Ereignisse, die jeweils aufgespürt und in gewisser Weise auditiert werden. Jedes Ereignis ist vorzugsweise eine Kombination einer Aktion und irgendwelchen Daten für die diese Aktion durchgeführt wird. Aktionen können umfassen, beispielsweise und ohne Einschränkung, das Lesen und/oder Manipulieren von Daten, das Lesen und/oder Ändern von Systemkonfigurationen oder einfach Zugreifen auf das System als Ganzes.
Das Audit-Subsystem 100 weist im allgemeinen einen externen Prozess 102 auf, ein Ereignis 104, einen Schreibereignisaufzeichnungsdienst 106 (anderweitig Eingabeprozessor und/oder Ereignisprozessor genannt), und einen Ereignisspeicher 108 (anderweitig Datensatzspeicher genannt), eine Berichterstattungsbenutzerschnittstelle 110 (anderweitig Überwachungsprozessor genannt), einen festgelegten Berichterstattungsprozess 112 (anderweitig auch Überwachungsprozessor genannt), einen Reporterzeugungsprozess 114 (anderweitig Ausgabeprozessor genannt), einen Datensatzbereinigungsprozess 116, einen Historienberichterstattungsprozess 118, der einen Historiendurchsichtprozess 120 aufweist, und einen Datensatzwiederherstellungsprozess 122, gesendete exportierte Datensätze 124, empfangene exportierte Datensätze 126, einen Audit-Report 128, und einen Speicher- und Indizierprozess 130.
Vorzugsweise führt der externe Prozess 102 eine Aufgabe aus und zeichnet die Aufgabe als Ereignis 104 auf, indem der Schreibereignisaufzeichnungsdienst 106 verwendet wird, der einen Datensatz dieses Ereignisses in dem Ereignisspeicher 108 speichert. Der Schreibereignisaufzeichnungsdienst 106 liefert vorzugsweise einen Eingabeprozessor zum Empfangen einer Nachricht, die ein Ereignis identifiziert, welches eine Aktivität repräsentiert, die von einer ausführbaren Anwendung ausgeführt wird, und die Daten enthält, die mit diesem Ereignis in Zusammenhang stehen. Die mit dem Ereignis in Zusammenhang stehenden Daten umfassen die Startzeit und die Endzeit des Ereignisses. Der Schreibereignisaufzeichnungsdienst 106 stellt ebenfalls vorzugsweise einen Ereignisprozessor bereit zur Speicherung eines Datensatzes des identifizierten Ereignisses und der ereignisbezogenen Daten in dem Ereignisspeicher 108. In einem medizinischen Versorgungsunternehmen empfängt der Eingabeprozessor eine Nachricht, die ein Ereignis identifiziert, welches mit dem Zugriff durch eine Person (beispielsweise Benutzer) von einer der Organisationen in Zusammenhang steht, auf patientenmedizinische Datensatzinformation. Die medizinische Patientendatensatzinformation umfasst, ohne darauf beschränkt zu sein, eine oder mehrere von: (a) klinische Patienteninformation, (b) Patientenrechnungs- oder Finanzinformation, (c) medizinische Überweisungsinformation, (d) medizinische Eignungsverifikationsinformation, (e) medizinische Bedürfnisverifikationsinformation und (f) medizinische Behandlungskosten oder Erstattungsbetragsinformation.
Ein Benutzer kann die Erzeugung von Audit-Reports anfordern, indem er die Berichterstattungsbenutzerschnittstelle 110 verwendet. Der Benutzer kann auch die Berichterstattungsbenutzerschnittstelle 110 verwenden, um die Erzeugung eines Audit-Reports 128 festzulegen. Der festgelegte Berichterstattungsprozess 112 veranlasst die Erzeugung des Audit-Reports 128 automatisch basierend auf der festgelegten Konfiguration, die von der Berichterstattungsbenutzerschnittstelle 110 gehalten wird. Beide, die Berichterstattungsbenutzerschnittstelle 110 und der festgelegte Berichterstattungsprozess 112 reichen Reporterzeugungsanfragen an den Reporterzeugungsprozess 114, der den Ereignisspeicher 108 abfrägt und die Ausgabe in einen benutzerlesbaren Report formatiert.
Vorzugsweise stellen die Berichterstattungsbenutzerschnittstelle 110 und der festgelegte Berichterstattungsprozess 112 einen Überwachungsprozessor bereit zur Auswahl bestimmter Ereignisse, die bei der Überwachung einer bestimmten Aktion der ausführbaren Anwendung zu verwenden sind, in Antwort auf einen empfangenen Befehl (beispielsweise automatisch oder benutzererzeugt). Vorzugsweise wählt der Überwachungsprozessor ebenfalls bestimmte Ereignisse aus zur Verwendung bei der Überwachung einer bestimmten Aktivität der ausführbaren Anwendung in Antwort auf empfangene Abfragekriterien. Der Überwachungsprozessor wählt ebenfalls vorzugsweise periodisch oder automatisch bestimmte Ereignisse aus zur Verwendung bei der Überwachung einer bestimmten Aktivität des ausführbaren Programms in Antwort auf eine vorbestimmte Ablaufplaninformation. Vorzugsweise wählt der Überwachungsprozessor ferner bestimmte Ereignisse aus zur Verwendung bei der Überwachung des Zugriffs auf medizinische Patientendatensätze in Antwort auf empfangene Abfragekriterien.
Der Überwachungsprozessor vergleicht vorzugsweise Datensätze der ausgewählten bestimmten Ereignisse, um einen Audit-Trial bereitzustellen, der für eine Person (beispielsweise Benutzer) einer der Organisationen, kennzeichnet eines oder mehrere von: (a) eine Benutzerkennnung, (b) eine Organisation, die mit dem Benutzer in Verbindung steht, (c) einen Ort der Organisation, die mit dem Benutzer in Verbindung steht und (d) einen zugegriffenen Patientendatensatz. Für ein medizinisches Versorgungsunternehmen vergleicht der Überwachungsprozessor Datensätze der ausgewählten bestimmten Ereignisse, um einen Audit-Trial bereitzustellen, der einen oder mehrere identifiziert von: (a) Patientendatensatzänderungen, (b) Patientendatensatzlöschungen, (c) Patientendatensatzhinzufügungen, und (d) Startzeit und Endzeit des Patientendatensatzzugriffs. Medizinische Patientendatensatzinformation enthält vorzugsweise, ohne dass dies eine Einschränkung ist, (a) klinische Patienteninformation, (b) Patientenabrechnungs- oder Finanzinformation, (c) Patientenüberweisungsinformation, (d) medizinische Eignungsverifikationsinformation, (e) medizinische Notwendigkeitsverifikationsinformation und (f) medizinische Behandlungskosten oder Erstattungssummeninformation.
Der Reporterzeugungsprozess 114 in Kombination mit der Berichterstattungsbenutzerschnittstelle 110 stellt einen Ausgabeprozessor bereit zum Vergleichen von ereignisbezogenen Daten, die aus dem Ereignisspeicher 108 wiedergewonnen werden, für die ausgewählten bestimmten Ereignisse und zur Verarbeitung und Formatierung der verglichenen Ereignisdaten, um sie einem Benutzer darzustellen. Der Ausgabeprozessor verarbeitet und formatiert vorzugsweise auch die verglichenen Ereignisdaten, um sie einem Benutzer zu präsentieren, als: (a) ein angezeigtes Bild und/oder (b) einen Report in Antwort auf vorbestimmte Ablaufinformation.
Der Datensatzbereinigungsprozess 116 begrenzt den Speicher, der für den Ereignisspeicher 108 erforderlich ist, indem Ereignisdatensätze basierend auf ihrem Alter extrahiert werden, und Datensätze, die für zukünftige Bezugsnamen notwendig sind, archiviert werden. Der Historienberichterstattungsprozess 118 macht archivierte Ereignisdatensätze verfügbar zum Ansehen oder aktiven Berichten entweder durch Anzeigen dieser als Dokumente oder durch Wiedereinführen zurück in den Ereignisspeicher 108.
Ereignisspeicher
Im Kern des Audit-Subsystems 100 befindet sich der Ereignisspeicher 108, der vorzugsweise aktiv berichtbare Ereignisdatensätze speichert. Der Ereignisspeicher 108 verbindet vorzugsweise ein Ereignis mit einem oder mehreren von: (a) einer Aktionstypkennung, (b) einer Aktionskennung, (c) einer Kategoriekennung und (d) einer Clientkennung oder benutzerbezogenen Kennung, wobei die Aktion von den ausführbaren Anwendung durchgeführt wird. Die ereignisbezogenen Daten umfassen vorzugsweise mindestens eines von: (a) einer Anwendungsumgebungskennung, (b) einer Computerjobkennung, (c) einer Kennung einer Einheit, die für das Ereignis verantwortlich ist, (d) einer Kennung eines Benutzers, der für das Ereignis verantwortlich ist, (e) einer Kennung eines Typs des Clientortes, der das Ereignis anfrägt, (f) einer Kennung eines Clientortes, der mit der Anfrage des Ereignisses in Zusammenhang steht, (g) einer Anzeige des Erfolgs oder des Fehlschlagens des Ereignisses, (h) einer Kennung eines Objekttyps, der aufgrund des Ereignisses arbeitet, (i) einer Kennung einer Anzahl von Objekten, die in dem Ereignis arbeiten, und (j) einer Kennung eines Datenstroms, einschließlich Daten, die die Objekte kennzeichnen, auf denen in dem Ereignis gearbeitet wird.
Der Ereignisspeicher 108 ist eine relationale Datenbank mit einer Tabelle zur Speicherung der Ereignisdatensätze und mit anderen Tabellen, die eines oder mehrere der folgenden erweiterten Referenzdaten aufweisen:

1. Eine Liste von Aktionen, die auditiert werden können (beispielsweise Objekt modifizieren, Objekt anzeigen, etc.),
2. eine Liste von generalisierten Aktionskategorien (beispielsweise Erzeugen, Lesen, Aktualisieren, Löschen, Ausführen),
3. eine Liste von Typen von Clientorten von denen Aktionen initiiert werden können (beispielsweise Arbeitsstation, Internetprotokoll (IP)-Adresse, Telefonnummer, etc.), und
4. eine Liste von Typen von Objekten für die Aktionen vorgenommen werden können (beispielsweise ein Dokument, Ordner, etc.).

Jede Reihe in der Ereignisdatensatztabelle enthält vorzugsweise Information, die mit einem aufgezeichneten Ereignis in Zusammenhang steht.
Ereignisdaten
Jedes Ereignis 104 erfordert eine oder mehrere der folgenden Ereignisdateninformation:

1. Eine Zeichenkette, die die Anwendungsumgebung repräsentiert, in der das Ereignis auftritt (diese wird typischerweise verwendet, um die kooperierende Organisation zu identifizieren, die für das Ereignis verantwortlich ist – mehrere Organisationen können gleichzeitig unterstützt werden),
2. eine ID, die einen Hintergrund "Job Kontext" darstellt, falls einer existiert (diese wird verwendet, um einen Satz von Ereignisses zu verbinden, die zu einer einzelnen, nicht interaktiven Operation gehören – also keine Benutzerbeteiligung),
3. eine Zeichenkette, die die Einheit oder Organisation repräsentiert, die für das Ereignis verantwortlich ist (diese wird verwendet zur Unterteilung der verantwortlichen Organisation, jedoch nachrangige Organisationen – beispielsweise separate Krankenhäuser, die einer einzelnen Firmenorganisation gehören),
4. der Zeitpunkt, zu dem das Ereignis initiiert wurde,
5. der Zeitpunkt, zu dem das Ereignis abgeschlossen ist,
6. der Benutzer, der für das Ereignis verantwortlich ist (dies ist die reale Person, die für das Ereignis verantwortlich ist),
7. ein Bezug auf die Aktionskategorie, in die das Ereignis passt,
8. ein Bezug auf die gegenwärtige Aktion, die während des Ereignisses durchgeführt wird,
9. ein Bezug auf den Typ des Clientortes, der das Ereignis anfragt,
10. der Name oder die Kennung, die mit der anfragenden Clientposition in Zusammenhang steht (dieser repräsentiert den eigentlichen Ursprung, oder Platz, von wo aus die Ereignisaktion initiiert wurde, beispielsweise eine Arbeitsstation oder ein Server),
11. eine Anzeige des Erfolgs oder Misserfolgs des Ereignisses (0 für Erfolg oder ein Fehlercode),
12 den Typ des Objekts, der bearbeitet wird,
13. Kennungsdaten, die das primäre Objekt repräsentieren (wenn anwendbar) umfassend: a. einen Objekt-Subtyp (beispielsweise ein Ordnertyp, wenn der Objekttyp ein "Ordner" ist) b. einen Objektindexnamen (beispielsweise "med rec no", wenn das Objekt ein medizinischer Datensatzordner ist), c. den Wert des Objektindex (beispielsweise "12345", wenn der Objektindex "med rec no" ist), und d. den Objektnamen (beispielsweise der Patientenname, wenn das Objekt ein Klinikordner ist, der mit einem bestimmten Patienten in Zusammenhang steht),
14. ein Zähler der Anzahl der Objekte, die in das Ereignis involviert sind, wenn das Ereignis sich nach einer Liste richtet, und
15. einen Datenstrom, der die Liste der Objekte beschreibt, die in dem Ereignis eingebunden sind, wenn das Ereignis sich nach einer Liste richtet.

Beispieldatenbankdesign
2 zeigt eine grafische Darstellung des Ereignisspeichers 108, der implementiert wurde, indem eine relationale Datenbank verwendet wurde, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Vorzugsweise ist die relationale Datenbank in einem Microsoft^® SQL-Server implementiert. 2 beschreibt allgemein vier Referenzdatentabellen, umfassend eine ActionTypes-Tabelle 202, eine ActionDescs-Tabelle 204, eine C1iLocTypes-Tabelle 206, eine ObjCategories-Tabelle 208 und eine Events-Tabelle 210. Die ActionTypes-Tabelle 202, die ActionDescs-Tabelle 204, die C1iLocTypes-Tabelle 206 und die ObjCategories-Tabelle 208 werden im folgenden beschrieben als Tabellen 2, 3, 4 und 5. Die Tabellen 2, 3, 4 und 5 enthalten anfänglich geladene Information. Vorzugsweise ist die Information in den Tabellen 2, 3, 4 und 5 speziell zur Verwendung mit einem Dokumentenimagingsystem definiert, können jedoch jederzeit für andere Dokumentenimagingsysteme und/oder andere Typen (beispielsweise Nichtdokumentimagingtyp) von Anwendungen erweitert werden. Die Events Tabelle 210 speichert vorzugsweise Ereignisse 104, die auftreten können.
Tabelle 2 zeigt Aktionstypen gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 2
Aktionstypen
Tabelle 3 zeigt Aktionsbeschreibungen gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 3
ActionDescs
Tabelle 4 zeigt Clientorttypen, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 4
CliLoctypen
Tabelle 5 zeigt Objektkategorien gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 5
ObjCategories
Schreibereignisaufzeichnungsdienst
Das Audit-Subsystem 100 zeigt einen Schreibereignisaufzeichnungsdienst 106, der jeder Softwarekomponente oder einem System erlaubt, einen Datensatz eines einzelnen Ereignisses aufzuzeichnen. Vorzugsweise erfolgt dieser Dienst über einen oder mehrere der folgenden Mechanismen:
als eine native C + + Funktion,
als eine Methode in einer Windows AxtiveX-Steuerung, und
als ein HTTP-POST Dienst.
Diese Mechanismen nehmen als Argumente die Information, die ein Ereignis definiert (wie im vorangegangenen in dem Ereignisspeicher 108 aufgelistet – Ereignisdaten). Die C + + Argumente können in nativen Datentypen übernommen werden, was von einem Softwareentwickler auf diesem Gebiet verstanden wird. Die ActiveX Steuerung und der HTTP-POST Dienst übernehmen die Argumente in einem einzelnen XML-Stream, beispielsweise wie der im folgenden gezeigte Beispielstream:
Funktionsdesign
Sobald einmal aufgerufen, führt der Schreibereignisaufzeichnungsdienst 106 vorzugsweise die folgenden Schritte durch:

1. Die Argumente werden in native Datentypen analysiert, wenn als XML übernommen werden (beispielsweise wird die Aktion id in einen numerischen Wert übersetzt).
2. Die Konfiguration wird geprüft, um zu bestimmen, ob die Aktion eine Gespeicherte ist (wenn nicht, dann erfolgt keine weitere Verarbeitung).
3. Der Dienst verwendet Datenzugriffstools (beispielsweise, jedoch nicht darauf beschränkt, ADO.NET, ADO, OLEDB oder ODBC), um einen Datensatz in der Events-Tabelle des Ereignisspeichers zu speichern.

Berichtersttung
Das Erzeugen eines Audit-Reports von dem Audit-Subsystem 100 umfasst eine Abfrage der Daten in dem Ereignisspeicher 108, und dann ein Formatieren der Abfrageergebnisse in ein benutzerlesbares Format. Um Bericht zu erstatten über unterschiedlichen Nebensätze von Ereignisdaten unterstützt das Audit-Subsystem 100 die Definition von Audit-Report Typen. Jeder Audit-Report-Typ definiert vorzugsweise die Parameter, die von der Ereignisspeicherabfrage verwendet werden (dies spezifiziert den Nebensatz abgefragte Ereignisdaten), und wie die Ergebnisliste der Ereignisse in eine bedeutungsvolle Ausgabe transformiert werden kann.
Vorzugsweise wird überwiegend XML verwendet, während der Erzeugung des Audit-Reports. Die Ereignisspeicherabfrage gibt die Abfrageergebnisse als <EventList> XML Stream zurück. Das resultierende XML wird dann in einen HTML formatierten Bericht transformiert, indem ein XSL Style Sheet verwendet wird. Ein Beispiel von XML Streams für ein Ereignis und eine Ereignisliste sind im folgenden gezeigt.
Event
Audit-Reporttypen
Vorzugsweise besteht ein Audit-Report Typ vorzugsweise aus einem oder aus mehreren vier eindeutigen Teilen.

1. Einem Typnamen (zur internen Systemreferenz),
2. einer Beschreibung (die dem Benutzer anzuzeigen ist),
3. einem Satz von Parametern, die zur Abfrage des Ereignisspeichers verwendet werden, und
4. einem Satz von Anweisungen, wie die Abfrageergebnisse in einen formatierten Report zu transformieren sind.

Die Ereignisspeicherabfrageparameter bestehen vorzugsweise aus einem Satz von absoluten Werten und möglicherweise aus einigen benutzerdefinierten Werten, um einem Nebensatz der Ereignisdaten zu entsprechen. Die Parameter sind registriert als Teil des Audit-Report Typs, als ein unvollständiger Satz von HTML entry field tags (möglicherweise umfassend <input> und <select> Tags). Dann werden die HTML entry field tags in eine Daten entry form eingebettet, die dem Benutzer präsentiert wird. Vorzugsweise werden das <input> Feld und das <select> Feld dann verwendet, um mehrere spezifische Abfragekriterien zusammen. Die Transformationsanweisungen werden registriert als Teil des Audit-Report Typs, als ein XSL Style Sheet, das verwendet wird, um die Abfrageergebnis XML in einen formatierten HTML-Bericht zu tansformieren.
Audit-Reporttypbeispiel
Ein Beispiel eines Audit-Report Typs ist im folgenden gezeigt.
Ein Audit-Report Typ besteht aus einem oder aus mehreren vier eindeutigen Teilen:

1. einem Typnamen (zur internen Systemreferenz),
2. einer Beschreibung (die dem Benutzer anzuzeigen ist),
3. einem Satz von Parametern, die zur Abfrage des Ereignisspeichers verwendet werden, und
4. einem Satz von Anweisungen, wie die Abfrageergebnisse in einen formatierten Bericht zu transformieren sind.

Ein Beispiel jedes Teils des Audit-Report Typs wird im folgenden beschrieben.
Name
Der Name dient zur internen Verwendung durch das Audit-Subsystem. Er ist vorzugsweise eine Zeichenkette mit angemessener Begrenzung (beispielsweise 12 Zeichen).
Der Audit-Report Name, der in diesem Beispielabschnitt verwendet wird, ist ActivitySumm.
Beschreibung
Die Beschreibung wird für eine Benutzerreferenz verwendet. Die Beschreibung wird in der Benutzerschnittstelle angezeigt, um diesen Reporttyp zu spezifizieren. Die Beschreibung für den ActivitySumm Report Typ ist Aktivitätszusammenfassung pro Benutzer.
Ereignisspeicherabfrageparameter
Die Ereignisspeicherabfrageparameter spezifizieren, welche Werte verwendet werden, wenn eine Abfrage des Ereignisspeichers durchgeführt wird. Vorzugsweise sind diese Parameter in einem XML Stream dargestellt, beispielsweise:
Für jeden gegebenen Report Typ können einige dieser Werte absolut sein (also der Benutzer kann sie nicht ändern), und einige können vom Benutzer konfigurierbar sein. Vorzugsweise werden diese Definitionen ausgedrückt, indem ein unvollständiger HTML-Stream verwendet wird, der in einen größeren Reporterzeugungsprozess 114 eingebunden sein kann. Absolute Werte werden ausgedrückt in versteckten INPUT-Feldern, und benutzerkonfigurierbare Felder werden ausgedrückt in angezeigten INPUT- oder SELECT-Feldern. Die HTML für den ActivitySumm Report Typ ist in einer Datei enthalten, die lasActivitySumm.htm genannt wird.
Transformationsanweisungen
Um einen Report in benutzerlesbarem Format zu präsentieren, werden die Ergebnisse der Berichtereignisabfrage vorzugsweise von XSL in ein HTML-Dokument transformiert, indem ein XSL-Style Sheet verwendet wird. Jeder Reporttyp hat ein bestimmtes Style Sheet, um die Abfrageergebnisse in einer Weise zu präsentieren, die Sinn macht für den Typ des Reports, der erzeugt wurde. Der Reporterzeugungsprozeß 114 verwendet den Style Sheet, um die Ausgabe zu erzeugen, die an den Prozess zurückgegeben wird, der den Report aufruft. Das XSL-Style Sheet für den ActivitySumm Report Typ ist in einer Datei enthalten, die lasActivitySumm.xsl genannt wird.
Reporterzeugung
Der Reporterzeugungsprozess 114 implementiert vorzugsweise die Ereignisspeicherabfrage und die XML-Report Transformation. Architektonisch beginnt dieser Prozess mit einem identifiziertem Satz an Abfragekriterien und endet mit einem HTML formatierten Report.
Funktionsdesign
Die folgenden Schritte implementieren den Reporterzeugungsprozess.

1. Ein externer Prozess, einschließlich, jedoch nicht darauf beschränkt, die Berichterstattungsbenutzerschnittstelle 110 oder der festgelegte Berichterstattungsprozess 112 aktiviert den Reporterzeugungsprozess 114. Der externe Prozess übergibt einen Satz von Werten, die als Ereignisspeicherabfragekriterien zu verwenden sind und das anwendbare XSL Style Sheet für die XML-Report Transformation.
2. Eine der zwei Abfragen wird dann durchgeführt, indem Standard Windowsdatenzugriffmethoden verwendet werden, umfassend, jedoch nicht darauf beschränkt, ADO.NET, ADO, OLEDB und/oder ODBC). Die SQL, die verwendet wird zur Durchführung dieser Abfrage ist angewiesen, die Ergebnisse als XML-Stream zu formatieren. Entweder a) erfolgt eine einzelne, direkte SQL-Abfrage, indem die Kriterien verwendet werden, die mit Datensätzen in dem Ereignisspeicher abgestimmt sind, oder b) es werden die Anfangskriterien verwendet, um eine Liste von Datensätzen abzufragen, dann wird eine Liste von Jobinhalten (also Jobld) von diesen Ergebnissen kompaliert und verwendet, um Datensätze, die mit diesen Jobs in Verbindung stehen, abzufragen.
3. Die XML-Ergebnisse werden in ein MS-XML Parser Objekt eingelesen (oder andere Industriestandardtools für die XML-Manipulation), um das XSL Style Sheet anzuwenden und die Abfrageergebnisse in einen HTML-Bericht zu transformieren.
4. Der HTML-Report wird an den aufrufenden Prozess zurückgegeben.

Beispielabfragekriterien
Beispielhafte Abfragekriterien, die für eine Benutzeraktivitätenzusammenfassungsreport („Activity Summary by user Report") verwendet werden, sind wie folgt:
Bseispielabfrageergebnisse
Ein Beispiel von Abfrageergebnissen für einen „Benutzeraktivitätszusammenfassungsreport" sieht wie folgt aus:
Tabelle 1 zeigt einen „Activity Summary by User Report", gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 1
Festgelegte Berichterstattung
Der zeitlich festgelegte Berichterstattungsprozess 112 liefert ein Mittel zur Erzeugung von Berichten in regelmäßigen Abständen, ohne Beisein des Benutzers. Die Konfiguration steuert diesen Prozess mit Null oder mit mehreren Sätzen von Ereignisspeicherabfragekriterien, die jeweils verwendet werden können, um einen Report täglich, wöchentlich, monatlich oder jährlich zu erzeugen. Der festgelegte Berichterstattungsprozess 112 wird vorzugsweise einmal pro Tag ausgeführt, indem die Liste der zu erzeugenden Reports gelesen wird, und indem der Reporterzeugungsprozess 114 für die Reports aufgerufen wird, die für die Erzeugung an diesem Tag konfiguriert sind.
Konfiguration
Die Konfiguration für den festgelegten Berichterstattungsprozess 112 beinhaltet eine Liste von zeitlich festgelegten Reports. Jeder festgelegte Report enthält vorzugsweise eine oder mehrere der folgenden Informationen: Einen festgelegten Referenznamen, das Transformations XSL Style Sheet, die Häufigkeit der Erzeugung (beispielsweise täglich, wöchentlich, monatlich oder jährlich), die Zeitzone, die für die Datums/Zeit-Anzeige zu verwenden ist, den Dokumententyp (beispielsweise aufgelistet durch DocTypeName), die verwendet werden, wenn der erzeugte Report archiviert wird, und die Kriterien, die für die Abfrage des Ereignisspeichers verwendet werden. Die Konfiguration wird vorzugsweise als XML-Stream gespeichert, ähnlich wie:
Funktionsdesign
Der festgelegte Berichterstattungsprozess 112 wird vorzugsweise als Dienst implementiert, der festgelegt ist, um einmal pro Tag zu einem bestimmten Zeitpunkt einer geringen Systemaktivität (beispielsweise typischerweise 2 Uhr) ausgeführt zu werden. Diese Festlegung erfolgt vorzugsweise, indem der Windows Schedule Service verwendet wird, was einem Softwareprogrammierer, der mit der Windowsprogrammierung befasst ist, bekannt ist. Die folgenden Schritte implementieren den festgelegten Berichterstattungsprozess 112.

1. Lesen der Konfiguration für die Liste der festgelegten Reports. Für jeden Eintrag in der Liste, Ausführen der Schritte 2 bis 4.
2. Bestimmen des augenblicklich lokalisierten Datums/Zeit, basierend auf der Zeitzone, die für den Report gespeichert ist.
3. Bestimmen, ob der Report für irgendeinen Zeitrahmen zwischen dem LastRun-Datum und dem augenblicklichen Datum/Zeit erzeugt wird. Dies erfolgt vorzugsweise durch Verwendung der folgenden Logik für jede Häufigkeit. Wenn die Häufigkeit "täglich" ist, dann wird der Report für jeden verstrichenen vollen 24 Stundentag erzeugt, zwischen dem LastRun-Datum/Zeit und dem augenblicklichen Datum/Zeit. Wenn die Häufigkeit "wöchentlich" ist, dann wird der Report für jede volle Woche erzeugt (beginnend an einem konfigurierbaren Tag), die vergangen ist, seit dem LastRun-Datum/Zeit. Wenn die Häufigkeit "monatlich" ist, dann wird der Report für jeden vollständigen Monat erzeugt, der seit dem LastRun-Datum/Zeit vergangen ist. Wenn die Häufigkeit "jährlich" ist, dann wird der Report für jedes volle Jahr erzeugt, das seit dem LastRun-Datum/Zeit vergangen ist.
4. Aktivieren des Reporterzeugungsprozesses 114 für jeden Zeitrahmen (also Tag, Woche, Monat oder Jahr) seit dem LastRun-Datum/Zeit. Weiterleiten jedes erzeugten Reports 128 an einen Hintergrunderfassungsprozess (nicht in 1 gezeigt), um für zukünftige Zugriffe archiviert zu werden.

Benutzerschnittstellen
Das Audit-Subsystem 100 umfasst zwei Typen von Benutzerschnittstellen, enthaltend Maintain Audit-Report und Generate Audit-Reports. Die Maintain Audit-Reports erlauben das Hinzufügen, Ändern und/oder Löschen von Report Typen. Die Generate Audit-Reports erlauben das Abfragen einer angeforderten oder festgelegten Erzeugung von Audit-Reports.
Datensatzbereinigung
Die Größe der aktiven Auditdatensatzdatenbank kann in der Größe relativ schnell zunehmen. Folglich werden die Audit Datensätze in einer Datenbank solange gehalten, wie sie für eine aktive Berichterstattung erforderlich sind. Der Datensatzbereinigungsprozess 116 bereinigt unnötige Ereignisdatensätze, um Speicherplatz zu schonen. Der Datensatzbereinigungsprozess 116 archiviert auch einen Nebensatz von bereinigten Datensätzen für den Fall, dass sie für eine historische Berichterstattung in der Zukunft benötigt werden.
Für den Zweck der Datensatzbereinigung werden die Auditdatensätze in eine oder in mehrere der folgenden drei Kategorien klassifiziert:

1. Benutzeraktivitätsdatensätze (beispielsweise Ereignisse, die mit einer Benutzeraktion in Zusammenhang stehen),
2. Betriebsaktivitätsdatensätze (beispielsweise Ereignisse, die mit Hintergrundsystemaktivität in Zusammenhang stehen), und
3. Durchsatzdaten nur Datensätze (beispielsweise Datensätze, die den Durchsatz von potentiellen Flaschenhalsprozessen aufspüren, die Teil von anderen größeren Ereignissen sind, jedoch kein Ereignis selbst bilden).

Die Datensätze in jeder dieser Kategorien werden zu unterschiedlichen Zeiten bereinigt (also wenn sie älter sind als die Anzahl konfigurierter Tage), da sie in der Zeit abweichen, für die sie für aktive Berichterstattung benötigt werden. Die bevorzugten Zeitintervalle werden wie folgt beschrieben.
Die „Durchsatzdaten" Datensätze werden allein zur Überwachung des Durchsatzes und zur Problembehebung verwendet, und folglich schnell bereinigt. Der Modellbereinigungszeitpunkt dieser Datensätze beträgt sieben Tage. Diese Datensätze werden nicht für eine historische Berichterstattung benötigt und nicht archiviert.
Die „Betriebsaktivität" Datensätze werden typischerweise verwendet, um modellfestgelegte Betriebsberichte zu erzeugen (beispielsweise den OLC Activity Report) und werden nicht für ein historisches Berichterstatten bevorzugt. Da es notwendig sein kann, Betriebsaktivitäten nachzuverfolgen, beträgt die bevorzugte Bereinigungszeit dieser Datensätze einunddreißig Tage. Diese Datensätze werden nicht archiviert, da ihre Information in archivierten Reports angesammelt ist.
Die „Benutzeraktivität" Datensätze werden verwendet zur Berichterstattung bezüglich Produktivität und Verantwortlichkeit. Kurz gesagt, es sind diese Datensätze, die zu der Fähigkeit beitragen, derartige Fragen zu beantworten, wie "Was hat jeder Mitarbeiter getan?" und "Was hat wer mit einem bestimmten Datensatz gemacht?". Da diese Datensätze im Lichte der Sicherheitspolitik wichtig sind, und da sie für Health Insurance Protability And Accountability Act (HIPAA) Berichterstattung verwendet werden, ist die bevorzugte Bereinigungszeit dieser Datensätze zweiundneunzig Tage. Da diese Datensätze für ein historisches Berichterstatten erforderlich sind, werden sie von dem Ereignisspeicher 108 als XML-Stream exportiert und in dem bevorzugten Dokumenten Imagingsystem archiviert für zukünftige Zugriffe und für historisches Berichterstatten.
Funktionsdesign
Der Datensatzbereinigungsprozess 116 wird vorzugsweise zeitlich festgelegt, um einmal pro Tag ausgeführt zu werden. Einmal aktiviert werden die folgenden Schritte ausgeführt.

1. Der Bereinigungszeitpunkt für jede Datensatzkategorie wird von der Konfiguration gelesen.
2. Ein Datensatzablaufdatum wird für jede Datensatzkategorie berechnet, indem der Bereinigungszeitpunkt von dem gegenwärtigen Datum abgezogen wird (also Datensätze älter als das berechnete Datum werden einer Bereinigung unterworfen)
3. Eine Abfrage wird ausgeführt, um „Benutzeraktivität" Datensätze zu extrahieren, die Gegenstand der Bereinigung sind. Diese Abfrage formatiert die extrahierten Datensätze als <EventList> XML-Stream (siehe den beispielhaften <EventList> Stream).
4. Die exportierten „Benutzeraktivität" Datensätze werden an ein Hintergrunderfassungssystem (nicht in 1 gezeigt) gesendet), um in dem Dokumentenimagingarchiv als ein einzelnes XML-Dokument gespeichert zu werden.
5. Abgelaufene Datensätze werden aus dem Ereignisspeicher 108 entfernt, indem ein "Lösch" SQL-Statement für die Events-Tabelle verwendet wird.

Historische Berichterstattung
Die historische Berichterstattung umfasst vorzugsweise sowohl die Fähigkeit archivierte Ereignisdatensätze anzusehen (bezeichnet als "Historien-Review 120") und die Fähigkeit, diese in dem Ereignisspeicher 108 wiederherzustellen, für eine aktive Berichterstattung (bezeichnet als "Datensatzwiederherstellung 122").
Historien-Review Funktionsdesign
Der Historien-Review Prozess 120 liefert vorzugsweise die Fähigkeit für das Audit Subsystem 100 die extrahierten Ereignisdatensatz-XML-Dokumente aus dem Archiv abzufragen, und sie in einer Dokumentenimaginganwendung anzuzeigen. Dies erfolgt über standardmäßige Dokumentenimagingwiedergewinnungs- und -betrachtungsmechanismen. Die XML- Dokumente werden an einen wiederauffindbaren Ordner abgegeben, der in einem Ordneranzeigefenster angezeigt und in einem Dokumentenanzeigefenster betrachtet werden kann. Wenn er angezeigt wird, verwendet das XML-Dokument die XML/XSL-Vorlagezusammenfassungsfähigkeiten eines Bildbetrachters, um das Dokument in einem benutzerlesbaren Format anzuzeigen.
Datensatzwiederherstellungsfunktionsdesign
Der Datensatzwiederherstellungsprozess 122 liest vorzugsweise ein oder mehrere Ereignisdatensatz-XML-Dokumente (beispielsweise aus dem Dokumentenimagingarchiv aufgefundene) und fügt diese Datensätze erneut in den Ereignisspeicher 108 ein. Die folgende Schritte implementieren den Datensatzwiederherstellungsprozess 122.

1. Ein Benutzer ruft eine Liste von Ereignisdatensatz-XML-Dokumenten von dem Dokumentenimagingarchiv auf, indem Standarddokumentenimaginganwendungsfunktionalität verwendet wird. Die Abfrage erfolgt vorzugsweise entweder durch Abfragen des Ordners, der diese Dokumente enthält, oder durch Abfragen der Dokumente selbst. Bei beiden Wegen werden sie in dem Ordneranzeigefenster angezeigt.
2. Der Benutzer wählt einen Nebensatz dieser Ereignisdatensatz-XML-Dokumente aus und ruft über sie den "Datensatzwiederherstellungs" Prozess von der Dokumentimaginganwendung auf. Dieser wird von einer "Audit-Datensätze wiederherstellen" -Funktion in dem Ordneranzeigefenster gestartet. Die "Audit-Datensätze wiederherstellen" Funktion aktiviert den Datensatzwiederherstellungsprozess 122 asynchron und gibt die Anwendungssteuerung an den Benutzer zurück.
3. Der Datensatzwiederherstellungsprozess 122 wird im Hintergrund ausgeführt und führt folgende Schritte durch: a. Jedes Ereignisdatensatz-XML-Dokument wird aus dem Archiv geholt. b. Jedes XML-Dokument wird in eine Serie von "Einfüge" SQL Statements konvertiert, die an die Ereignisspeicher "Events"-Tabelle gerichtet werden. c. Die erzeugten SQL-Statements werden ausgeführt, um die Datensätze für eine aktive Berichterstattung verfügbar zu machen, indem der Audit-Subsystem 100 Berichterstattungsmechanismus verwendet wird.

Ein Beispiel von Audit-Report Abfrageergebnissen ist im folgenden beschrieben.
In einem medizinischem Vorsorgeunternehmen, verfolgt das Audit-Subsystem 100 vorteilhafterweise Zugriff auf medizinischen Datensatz, medizinische Überweisungen, medizinische Verfahrensberechtigungen, medizinische Eignungsverifikation, Behandlungsreihenfolgen und andere Kommunikationen, die mit Gesundheitsvorsorge in Zusammenhang stehen, zwischen mehreren unterschiedlichen Organisationen. Diese Tracking-Funktion liefert einem medizinischen Vorsorgeunternehmen (beispielsweise einem Krankenhaus), die Möglichkeit, medizinische Kommunikationen außerhalb der bestimmten Organisation nachzuverfolgen. Wenn beispielsweise ein Patient von dem Krankenhaus A an das Krankenhaus B verwiesen wird, und der Patient wichtige Dokumente, Filme oder Bilder mitbringen muss, wird die Überweisung kontrolliert und von dem Krankenhaus A aufgespürt, und die notwendigen Dokumente, Bilder, etc. sind im Krankenhaus B von dem Dokumentspeichersystem zugreifbar, welches als zentraler Speicher arbeitet. Ferner, wenn das Krankenhaus B den Patienten an das Krankenhaus C schickt, wird diese Überweisung autorisiert, überwacht und über das Audit- und Dokumentspeichersystem nachverfolgt.
Das Audit-Subsystem 100 ermöglicht ebenfalls vorteilhafterweise einem Patienten, der das Krankenhaus B besucht, dem Krankenhaus B eine Erlaubnis zu erteilen und aufzuzeichnen, dass er die Erlaubnis zum Zugriff auf seine Datensätze gegeben hat, die in dem zentralen Dokumentspeichersystem vom Krankenhaus A gespeichert werden. Alternativ kann das System eine Anfrage an das Mehrorganisationsdokumentenspeichersystem initiieren, um irgendeinen Datensatz, der für den Patienten vom Krankenhaus A gespeichert wurde, zu suchen.
Operationsüberwachung und Funktionenüberwachung von Jobzuständen
3 zeigt ein Benutzerschnittstellenfenster, welches den Jobstatus 300 liefert, gemäß einem bevorzugtem Ausführungsbeispiel der Erfindung. Die Jobstatusfunktion ermöglicht Systemadministratoren und Geschäftsbüromanagern fehlgeschlagene Systemhintergrundjobs zu betrachten und in einigen Fällen zu editieren/wiederaufzubereiten. Von einem Operationsmenü aus wählt ein Benutzer "Jobstatus" aus, um das Jobstatusbenutzerschnittstellenfenster 300 anzuzeigen.
Wenn ein Benutzer zuerst auf das Jobstatusfenster 300 zugreift, listet die obere Hälfte des Schirms die Jobs auf. Ein Job kann einen von drei Zuständen aufweisen (und zusätzliche Zustände in anderen Ausführungsbeispielen)

1. FAIL (also der Job ist vollständig oder teilweise fehlgeschlagen)
2. IN PROG (also der Job wird gerade bearbeitet)
3. SUCCESS (also der Job ist erfolgreich abgeschlossen)

Jobtypen
Die Jobtypen umfassen vorzugsweise, jedoch nicht darauf beschränkt, Audit-Reports 302, Audit-Datenbankbereinigung 304 und Internetinformationsdienste (IIS) Log Purge 306. Für den Audit-Reports 302 Typ, läuft ein Job jedes Mal dann, wenn ein festgelegter Audit-Report läuft. Für den Audit-Datenbankbereinigung 304 Typ läuft ein Job täglich, der die Audit-Datenbank sicherheitskopiert und sie bereinigt, um zu verhindern, dass die Audit-Datenbank zu groß wird. Für den IIS Log Purge 306 Typ überwacht ein IIS die Aktivität auf einem Internetinformationsmanagerserver. Ein Job läuft, der die Logdatei bereinigt, die von IIS erzeugt wird.
Audit-Reports
4 zeigt ein Benutzerschnittstellenfenster, welches Audit-Reports 400 liefert, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Die Audit-Reports liefern Systemadministratoren und Büromanagern Statistiken über Benutzeraktivität und/oder Produktivität sowie Systemverarbeitungsstatistiken. Von dem "Operations" Menü, wird "Audit-Reports" ausgewählt, um das Audit-Reports Fenster 400 anzuzeigen. Die folgenden Typen 402 von Audit-Reports sind verfügbar.

1. Zugriffshistorie eines ausgewählten Datensatzes.
2. Aktivitätseinzelheiten über einen Benutzer.
3. Aktivitätszusammenfassung über einen Benutzer.
4. Gleichzeitige Aktivität.
5. Vom Benutzer zugegriffene Dokumente.
6. Vom Benutzer zugegriffene Ordner.
7. Online Clerk-Aktivität.

Erzeugen von Reports
Die Schritte zum Erzeugen irgendeines des Audit-Reports sind vorzugsweise gleich. Die Unterschiede liegen in Feldern, die ein Benutzer auswählen kann, um Anfragen zu erzeugen. Für Felddefinitionen siehe die folgenden Audit-Reports Feldbeschreibungen. Für eine Beschreibung jedes Reports siehe im folgenden Report Beschreibungen. Die Reihenfolge jedes Reports ist vorzugsweise am Ende jedes Report-Beschreibungsabschnittes aufgelistet. Ein Benutzer erzeugt einen Report, indem folgende Schritte durchgeführt werden.

1. Auswahl des gewünschten Reporttyps 402 aus der "Report" Dropdownliste.
2. Eingabe eines "Startdatums" 406 und optional des "Enddatums" 408. Wenn der Benutzer das Enddatum freilässt, wird der Report für den Tag erzeugt, den das Startdatumsfeld spezifiziert.
3. Zusätzliche Felder eingeben, um den Bereich des Reports einzugrenzen. a. Je mehr Felder eingegeben werden, desto genauer wird der Report. b. die Eingabe von großen Datumsbereichen erhöht die Reporterzeugungszeit. c. Einige Felder erlauben einem Benutzer mehrere Werte auszuwählen. Ein Benutzer kann die Shift- und Ctrl-Tasten verwenden, um mehrere Werte auszuwählen. 4. Klicken der "Erzeugen"-Taste 410, um den Audit-Report zu erzeugen.

Die Ergebnisse der Abfrage erscheinen vorzugsweise in einem separaten Anzeigefenster. Der Benutzer hat die Möglichkeit, irgendeinen der Reports festzulegen, um regelmäßig zu laufen. Siehe "Festlegen von Reports, damit sie täglich, wöchentlich oder monatlich laufen" im folgenden.
Sichern und Betrachten von Optionen
Ein Benutzer hat verschiedene Optionen zum Betrachten und Sichern von Audit-Reports.

1. Festgelegte Reports werden automatisch nach Datum in dem AUDITRPTHTM Ordner gesichert. Siehe "Festlegen von Reports, damit sie täglich, wöchentlich oder monatlich laufen" im folgenden.
2. Der Report kann auch von dem Jobstatusfenster aus betrachtet werden (wenn der Erzeugungsjob noch in der Warteschlange ist).
3. Wenn ein Benutzer den Report auf Anforderung erzeugt, erscheint darüber hinaus der Report in einem separaten Internetexplorer (IE)-Fenster. Von dem Dateimenü aus kann ein Benutzer "Speichern unter" auswählen, um den Report zu speichern. Wenn es gewünscht ist, kann ein Benutzer einen gespeicherten Report zurück in das Audit-Subsystem 100 importieren. Festgelegte Reports, die auf einer täglichen, wöchentlichen oder monatlichen Basis laufen.

Jeder der Audit-Reports kann festgelegt werden 404, um automatisch auf einer täglichen, wöchentlichen oder monatlichen Basis zu laufen, wobei

1. ein Tag bei 12:00 AM beginnt und bei 12:00 PM endet.
2. Eine Woche am Montag um 12:00 AM beginnt und am Montag um 12:00 PM endet.
3. Ein Monat am ersten um 12:00 AM beginnt und um 12:00 AM am ersten Tag des nächsten Monats endet.

Die Reports werden vorzugsweise wie folgt festgelegt.

1. Modelljobs werden festgelegt, um um 2:00 in der Früh für den vorherigen Tag zu laufen. Dies ist typischerweise keine Spitzenzeit.
2. Wenn der Benutzer ein Application Specific Provider (ASP) Customer auf Pacific Zeit ist, und ihre Reports einen Tag später erscheinen, kann eine Einstellung für die Festlegung des Zeitpunkts der Reports erfolgen.
3. Wenn aus irgendeinem Grund ein Teil des Systems gestört ist und ein festgelegter Report nicht erzeugt wird, wird beim nächsten Mal, wenn der Reportgenerator läuft, dies kompensiert und die verpasste Zeitperiode sowie die gegenwärtige berichtet.

Ein Report wird wie folgt festgelegt.

1. Auswahl des Reporttyps 402.
2. Auswahl der Reportkriterien, um den festgelegten Report zu erzeugen. Gebe kein Startdatum 406 oder Enddatum 408 ein.
3. In dem "Erzeugen"-Feld 412 wähle täglich, wöchentlich oder monatlich.
4. Gib einen beschreibenden Reportnamen 414 ein.
5. Auswählen des "Zeitdokumenttyps" 416 zur Verbindung mit diesem Report.

Dieser Dokumenttyp sollte dem Typ des Reports entsprechen, der erzeugt wurde als:

a. Zugriffshistorie des ausgewählten Datensatzes (ACCESHIS)
b. Aktivitätseinzelheit über Benutzer (ACTDETL)
c. Aktivitätszusammenfassung über Benutzer (ACTSUMM)
d. Gleichzeitige Aktivität
e. Dokumente, auf die der Benutzer zugegriffen hat (DOCACCES)
f. Ordner, auf die der Benutzer zugegriffen hat (FOLDACES)
g. Online Clerk Aktivität (OLCACT)

Wenn ein Benutzer seinen eigenen Audit-Report erstellt und ihn zeitlich festlegt zu laufen, wählt der Benutzer entweder einen Dokumententyp eines ähnlichen Reports aus oder erzeugt einen neuen Dokumententyp, der mit keinen Bursting- und Filingregeln in Zusammenhang steht.
6. Klicken der "Erzeugen"-Schaltfläche 410. Eine Bestätigungsaufforderung und ein Fenster erscheinen.
Audit-Reports Feldbeschreibungen
Dieser Abschnitt enthält Beschreibungen für Felder, die ein Benutzer abfragen kann, wenn ein Audit-Report erzeugt wird. Nicht alle Felder erscheinen auf jedem Report. Die Felder, die mehr als eine Option anzeigen, erlauben einem Benutzer die Auswahl von mehr als einem Objekt, durch Verwendung von Shift+ Auswählen, Ctrl+ Auswählen, oder eine Kombination der zwei (beispielsweise Shift+ Auswählen eines Bereichs, dann Ctrl+ Auswählen eines zusätzlichen einzelnen Objekts). Tabelle 6
Dieser Report liefert detaillierte Systembenutzungsstatistiken für einen ausgewählten Datumsbereich. Die Zusammenfassungsstatistiken werden wie folgt angezeigt.

1. Startdatum – Startdatum der Reportanfrage
2. Enddatum – Enddatum für die Reportanfrage
3. Datensatzzahl – Gesamtanzahl an Datensätze, die die Suchkriterien erfüllen.

Für jedes Datum innerhalb des Suchbereichs, mit gefundenen Übereinstimmungen werden vorzugsweise folgenden Informationen berichtet.

1. Vollständige Zeit – Zeit, zu der die in dem Operationsfeld aufgelistete Aktion ausgeführt wurde
2. Benutzer Id – Id des Benutzers, der die Aktion ausgeführt hat, die in dem Operationsfeld aufgelistet ist. Dieses Feld kann auch verwendet werden, um den Service Account entweder eines Pollers oder eines Empfängers einzugeben, um zu sehen, welche Ordner von diesen Diensten aktualisiert wurden.
3. Operation – Operation, die für das Dokument oder den Ordner ausgeführt wurde (beispielsweise Öffnen, Hinzuaddieren, Kopieren, Verschieben, etc.).
4. Objekttyp Name – Ordner oder Dokumenttyp.
5. Objekt Index – Ordern oder Dokumentkey.
6. Objekt Name – Wert, der dem Primary Index des Ordners oder dem Dokument zugewiesen ist (also Antragsstellername, medizinische Datensatznummer, etc.).
7. Objektnamenzählwert – Für Operationen, wo eine Liste von Objekten abgefragt wird (beispielsweise Abfrageordner), dieses Feld listet die Anzahl der zurückgegebenen Objekte auf. Für bestimmte Ordneroptionen (beispielsweise Öffnen eines Ordners) listet dieses Feld die Anzahl der Dokumente in dem Ordner auf.

Die bevorzugte Sortierreihenfolge für die Zugriffshistorie des ausgewählten Datensatzreports ist Datum, dann die Benutzer ID, dann das vollständige Datum/Uhrzeit in aufsteigender Reihenfolge.
Aktivitätsdetail über Benutzer
Dieser Report liefert eine detaillierte Zusammenfassung von Information über Systembenutzungsstatistiken für jeden Benutzer. Die folgenden Zusammenfassungsstatistiken werden angezeigt.

1. Startdatum – Startdatum für die Reportanfrage.
2. Enddatum – Enddatum für die Reportanfrage.
3. Datensatzzahl – Gesamtanzahl von Datensätzen, die die Suchkriterien erfüllen.

Für jeden spezifizierten Benutzer wird die folgende Information nach Datum berichtet.

1. Operation – Operation, die für das Dokument oder für den Ordner ausgeführt wurde (beispielsweise Öffnen, Hinzufügen, Kopieren, Bewegen, etc.).
2. Zeit – Zeit, zu der die Aktion, die in dem Operationsfeld aufgelistet ist, ausgeführt wurde.
3. Objekttyp Name – Ordner oder Dokumenttyp.
4. Objekt Index – Ordner oder Dokumentschlüssel.
5. Objekt Name – Wert, der den Primary Index des Ordners oder dem Dokument zugewiesen ist (also Antragsteller, Name, medizinische Datensatznummer, etc.).
6. Objekt Name Zahl- Für Operationen, wo eine Liste von Objekten angefragt wird (beispielsweise Abfrageordner), dieses Feld listet die Anzahl von zurückgegebenen Objekten auf. Für bestimmte Ordneroperationen (beispielsweise Öffnen eines Ordners), listet dieses Feld die Anzahl von Dokumenten in dem Ordner auf.

Die Sortierreihenfolge für den Benutzeraktivitätsdetailreport ist Datum, dann die Benutzer ID, dann der Aktionsname (von der Aktions-ID), dann das vollständige Datum/Zeit in aufsteigender Reihenfolge.
Aktivitätszusammenfassung über Benutzer
Dieser Report liefert eine Zusammenfassung der Systembenutzungsstatistiken für jeden Benutzer. Die folgenden Zusammenfassungsstatistiken werden angezeigt.

1. Startdatum – Startdatum der Reportanfrage.
2. Enddatum – Enddatum für die Reportanfrage.
3. Datensatzzahl – Gesamtzahl an Datensätzen, die die Suchkriterien erfüllen.

Für jedes Datum und jeden Benutzer wird die folgende Information für den Benutzer geliefert.

1. Anzahl der angezeigten Dokumente.
2. Anzahl der importierten Dokumente.
3. Anzahl der erfassten Dokumente.
4. Anzahl der exportierten Dokumente.
5. Anzahl der erfassten Seiten.
6. Anzahl der gedruckten Dokumente.
7. Anzahl der gedruckten Seiten.
8. Anmeldezeitpunkt.

Für jeden Benutzer wird nach Datum eine Historie der Anmelde- und Abmeldezeitpunkte geliefert. Darüber hinaus wird die oben aufgelistete Information für Benutzer an einem bestimmten Tag zur Verfügung gestellt, sowie für Benutzer für bestimmte Tage in dem Reportbereich. Die Sortierreihenfolge für den Benutzeraktivitätszusammenfassungsreport ist vorzugsweise Datum, dann Benutzer-ID, dann vollständiges Datum/Zeit in aufsteigender Reihenfolge.
Audit-Report Inhaltsverzeichnis
5 zeigt ein Audit-Report Inhaltsverzeichnis 500, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Tägliche, wöchentliche und monatliche Reports werden in dem Ordner mit dem Namen "AUDITRPTHTM" gespeichert. Der Ordner wird jeden Tag erzeugt, an dem ein Report erzeugt wird. Die Reports werden in den Ordner abgegeben, entsprechend dem Startdatum des Reports, nicht entsprechend dem Datum, an dem der Report erzeugt wurde. Beispielsweise sind in dem Audit-Report Inhaltsverzeichnis 500 wöchentliche Reports, die die Zeitperiode vom 19. August bis zum 26. August abdecken, in den Ordner abgegeben, der mit 19. August 2002 gekennzeichnet ist, obwohl der Report am 26. August erstellt wurde.
Gleichzeitige Aktivität
6 zeigt einen Simultanbenutzungs-Report 600, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Der Report 600 liefert Statistiken über die tägliche, wöchentliche und monatliche Systembenutzung. Für den Report 600 ist ein gleichzeitiger Benutzer eine Arbeitsstation mit mindesten einem geöffneten Browser und mit der Dokument-Imaginganwendung verbunden. Die Benutzer, die mehrere Browser auf ihren Arbeitsstationen öffnen, werden nicht als mehrere Benutzer gezählt. Für jeden Tag der Berichterstattungsperiode wird eine stündliche Spitzenzahl der angeschlossenen Arbeitsstationen berechnet, und die größte dieser wird als Tagesspitze berichtet. Die Tagesspitzen für Montag bis Freitag werden gemittelt, um eine Wochenspitze zu berechnen, dann werden die Wochenspitzen gemittelt, um eine Monatsspitze zu berechnen.
Obwohl dieser Report auf Anfrage erstellt werden kann, ist beabsichtigt ihn monatlich festzulegen. Wenn Benutzer ihn auf Anfrage erstellen wollen, müssen die Benutzer vorzugsweise:

1. Ein Enddatum eingeben, welches in der Vergangenheit liegt und
2. ein Startdatum eingeben, das mindestens ein Monat vor dem eingegebenen Enddatum liegt.

Dokumente, auf die von einem Benutzer zugegriffen wurde Dieser Report liefert die Gesamtanzahl an Zeitpunkten, zu denen eine Aktion durchgeführt wurde nach Dokumenttyp. Die folgenden Zusammenfassungsstatistiken werden angezeigt.

1. Startdatum – Startdatum für die Reportanfrage.
2. Enddatum – Enddatum für die Reportanfrage.
3. Datensatzzahl – Gesamtanzahl an Datensätzen, die die Suchkriterien erfüllen.

Für jedes Datum, jeden Benutzer und Dokumententyp werden die folgenden Informationen geliefert.

1. Anzahl von Dokumenten, die im Hintergrund erfasst wurden.
2. Anzahl von Dokumenten, die über ein Importieren erfasst wurden.
3. Anzahl von Dokumenten, die über ein Gerät erfasst wurden.
4. Gesamtanzahl von erfassten Dokumenten.
5. Anzahl der Seiten, die von dem Gerät erfasst wurden.
6. Anzahl der angezeigten Dokumente.
7. Anzahl der gedruckten Dokumente.
8. Anzahl der gedruckten Seiten.
9. Anzahl der exportierten Dokumente.

Die Sortierreihenfolge für den Report für Dokumente, auf die ein Benutzer zugegriffen hat, ist vorzugsweise Datum, dann die User-ID, dann der Objekttyp Name, dann das vollständige Datum/Zeit in aufsteigender Reihenfolge.
Ordner, auf die ein Benutzer zugegriffen hat
Dieser Report liefert die Anzahl von Zeitpunkten, an denen eine Aktion ausgeführt wurde, nach Ordnertyp für jeden Benutzer. Die folgenden Zusammenfassungsstatistiken werden angezeigt.

Für jedes Datum innerhalb des Suchbereichs, für welches eine Übereinstimmung gefunden wurde, und für jeden spezifizierten Benutzer, wird die folgende Information berichtet.

1. Zeit – Zeit, zu der die in dem Operationsfeld aufgelistete Aktion ausgeführt wurde.
2. Operation – Operation, die für den Ordner ausgeführt wurde (beispielsweise Öffnen, Hinzufügen, Kopieren, Verschieben, etc.).
3. Objekt Typ Name – Objekttyp 4. Objekt Index – Ordnerkey
5. Objekt Name – Wert, der den Primary Index des Ordners zugewiesen ist (also Antragsteller Name, medizinische Datensatznummer, etc.).
6. Objekt Name Zahl- Für Operationen, wo eine Liste von Objekten angefragt ist (beispielsweise Abfrageordner), dieses Feld listet die Anzahl an zurückgegebenen Objekten auf. Für bestimmte Ordneroperationen (beispielsweise Öffnen eines Ordners) listet dieses Feld die Anzahl an Dokumenten in dem Ordner auf.

Die Sortierreihenfolge des Reports für Ordner, auf die ein Benutzer zugegriffen hat, ist vorzugsweise das Datum, dann die Benutzer-ID, dann das vollständige Datum/Zeit in aufsteigender Reihenfolge.
Online Clerk Aktivität
Dieser Bericht fasst die Online Clerk Aktivität für die spezifizierte Zeitperiode zusammen. Die folgenden Zusammenfassungsstatistiken werden angezeigt.

Für jedes Datum wird folgendes geliefert.

1. Liste der OLC-Reports, die verarbeitet wurden.
2. Liste der Dokumente, die erzeugt wurden.
3. Liste der Ordner, die erzeugt wurden.
4. Liste der Ordner, die aktualisiert wurden.
5. Liste der Ordner, die Dokumente aufweisen, die darin platziert wurden.

Die Information, die in irgendeiner der hier beschriebenen Listen enthalten ist, kann abweichen. Vorzugsweise enthalten die Listen den Zeitpunkt der Aktion und andere Information, die die Indexwerte betrifft (beispielsweise Ordnertyp, Dokumenttyp, Primary Indexwert, etc.). Wenn keine Objekte für eine bestimmte Liste vorliegen (beispielsweise keine Ordner wurden an diesem Tag erzeugt), erscheint diese Kategorie nicht.
Die folgende Zusammenfassungsinformation wird für jedes Datum geliefert.

1. Gesamtanzahl von verarbeiteten Reports.
2. Gesamtanzahl von verarbeiteten Dokumenten.
3. Gesamtanzahl von umgangenen Reports (siehe Bemerkung 1 unmittelbar im Anschluss).
4. Gesamtanzahl von Wiederherstellungsreports (siehe Bemerkung 2 unmittelbar im Anschluss).
5. Gesamtanzahl von Dokumenten, die durch Rückgewinnung gelöscht wurden (siehe Bemerkung 2 unmittelbar im Anschluss).
6. Gesamtanzahl von Reports mit verworfenen Dokumenten (siehe Bemerkung 3 unmittelbar im Anschluss).
7. Gesamtanzahl von verworfenen Dokumenten (siehe Bemerkung 3 unmittelbar im Anschluss).
8. Durchschnittliche Verarbeitungszeit pro Report.

Die Sortierreihenfolge des Online Clerk Aktivitätsreports ist vorzugsweise das Datum, dann die Aktions-ID-Domain (in absteigender Reihenfolge), dann die Aktions-ID, dann das vollständige Datum/Zeit in aufsteigender Reihenfolge.
Zu beachten ist:

1. OLC kann Burstingregeln aufweisen, die einen Report vollständig umgehen (also wenn ein Benutzer einem XYZ-Report begegnet, sollte der Benutzer ihn nicht bearbeiten).
2. Gelegentlich misslingt ein Report, nachdem eine Verarbeitung begonnen wurde. Einige Dokumente können verarbeitet worden sein. In diesem Fall wird der misslungene Job an das Jobstatusfenster 300 in 3 gesendet. Ein Rückgewinnungsreport wird gestartet, der alle Dokumente löscht, die verarbeitet wurden, bevor Job fehlgeschlagen ist. Diese Dokumente werden hinzugefügt, wenn Fehler korrigiert werden und der Job erneut verarbeitet wird.
3. Einige Dokumente werden verworfen, da sie keine Kriterien erfüllen, die als Filter spezifiziert wurden, während der Indexextraktion (beispielsweise ein Benutzer sollte nicht bearbeiten, wenn das Anfangsdatum vor einem bestimmten Datum liegt).

Modifizieren und Hinzufügen von Audit-Reports
Abgesehen von Audit-Reports, die mit deinem System kommen, hat ein Benutzer die Optionen:

1. Erzeugen ihrer eigenen Reports (was die Verwendung eines existierenden Reports als Vorlage umfasst, um einen Neuen zu erzeugen), oder
2. Modifizieren der existierenden Reports auf ihrem eigenen System.

Zu beachten ist:
Reports werden außerhalb des Systems erzeugt, indem ein Editor deiner Wahl verwendet wird, und dann hochgeladen, indem die Audit-Report Types-Funktion im Administratormenü verwendet wird. Für Dokumentationszwecke sei angenommen, dass der Benutzer einen existierenden Report als Vorlage verwendet, um einen neuen Report zu erstellen. Wenn der Benutzer einen Modellreport editiert, gelten die Anweisungen, die in dem "Using an Existing Report" als Vorlage geliefert werden.

2. Es liegt in der Verantwortlichkeit des Benutzers, neue oder modifizierte Audit-Reports, die dem System hinzugefügt wurden, zu sichern.
3. Wenn ein Benutzer einen Modell Report editiert und feststellt, dass er nicht länger arbeitet, kann eine Backup-Version von einem Hersteller des Systems eingeholt werden.

Verwendung eines existierenden Reports als Vorlage
In den meisten Fällen erzeugt ein Benutzer einen neuen Report nicht von Anfang an. Statt dessen lädt ein Benutzer einen existierenden Report runter, benennt ihn um, aktualisiert ihn und lädt ihn zurück in das System. Eine beispielhafte Report-Abfragedatei listet mögliche Felder auf, die verwendet werden können, wenn der Report erzeugt wird. Der Dateiname ist vorzugsweise lasQueryIdentitiy.htm. Obwohl ein entsprechendes Style Sheet (lasQueryIdentitiy.xsl) existiert, sollte ein Benutzer besser das Style Sheet eines Reports verwenden, der einem ähnelt, der ihren Report anschließend abbildet.
Um eine existierende Datei herunterzuladen, sollte ein Benutzer:

1. Auf die Internetexplorer (IE) Adressenzeile zugreifen.
2. /AuditRpts an das Ende der Webadresse der Anwendung hinzufügen (also http://mlvv3p7a/XXYY/html/AuditRpts, wobei "XXYY" eine einzigartige Organisationskennung (ID) ist).
3. Die Returntaste drücken, um das folgende Inhaltsverzeichnis anzuzeigen, wie in Tabelle 7 gezeigt.

Tabelle 7 zeigt ein Audit-Reports Inhaltsverzeichnis 710, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 7
Audit-Reports – Inhaltsverzeichnis

1. Das Audit-Reports Inhaltsverzeichnis 710 listet vorzugsweise die Modell Audit-Reports auf (und einen, den der Benutzer hinzugefügt haben kann). Die Dateinamen ähneln dem Reporttitel (beispielsweise lasActivitySumm.htm ist der Report für die Aktivitätszusammenfassung pro Benutzer). Für jeden Report gibt es zwei Dateien (HTM und XSL für Audit-Reports, wie im folgenden beschrieben): a. Dateiname.htm – enthält den Code für das Abfragefenster, das erscheint, wenn der Benutzer den Report von dem Reporttyp Dropdown-Feld auswählt. b. Dateiname.xsl – Style Sheet, das den Code für die Reportausgabe aufweist, die erscheint, wenn der Benutzer erzeugend in dem Audit-Report-Fenster auswählt.
2. Ein Benutzer klickt mit rechts auf die gewünschte .htm-Datei wählt Speicher Ziel unter ... und liefert einen einzigartigen Namen für den neuen Report des Benutzers. Es wird empfohlen, dass beide Dateien den gleichen Dateinamen aufweisen (also die Erweiterung unterscheidet sich).
3. Ein Benutzer wiederholt den vorherigen Schritt für die entsprechende .xsl Datei.
4. Durch Verwendung des gewählten Benutzereditors formatiert ein Benutzer die Report-Datei (.htm) und das Style Sheet (.xsl) wenn dies notwendig ist und kopiert die Dateien zurück in das/AuditRpts Verzeichnis.

Hochladen und Hinzufügen neuer Reports
7 zeigt ein Benutzerschnittstellenfenster, welches Audit-Report Typen 700 zur Verfügung stellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Sobald ein Benutzer eine Audit Abfragefelddatei und ein Style Sheet erzeugt oder modifiziert hat, muss ein Benutzer es in das AuditRpts Verzeichnis laden. Von dem Administratormenü wird Audit-Report Typen ausgewählt, um das folgende Fenster anzuzeigen.

1. In der Datei zum Hochladen eines Feldes zur Schaltfläche des Schirms, gibt ein Benutzer den .htm Dateinamen ein oder verwendet die Browser ... Schaltfläche um ihn zu lokalisieren und klickt auf Hochladen.
2. Ein Benutzer wiederholt diesen Schritt für die .xsl Datei.

Als nächstes muss ein Benutzer diesen Report zu der Report Typ Dropdownliste hinzufügen.

1. Ein Benutzer klickt auf die Schaltfläche Erzeugen.
2. Ein Benutzer gibt den Report Typ Namen und eine Beschreibung ein (die Beschreibung ist dass, was in der Dropdownliste erscheint).
3. Ein Benutzer wählt die .htm Datei aus der Abfragefelderdatei aus und die entsprechende .xsl Datei von der Ausgabe Style Sheet Dropdownliste.
4. Ein Benutzer klickt auf die Schaltfläche Speichern.

Sicherheitskonzepte
Die Dokumentimagingsicherheit erlaubt einem Benutzer eine Berechtigung für die folgenden Systemkomponenten sicherzustellen: Dokument-Imaginganwendung, Dokumenttypen, Ordnertypen und Funktionen. Jedes separate sicherbare Objekt wird als Token bezeichnet. Berechtigungen für diese Objekte werden einer NT-Steuergruppe gewährt, die aus Regeln besteht. Eine Regel ist eine logische Sammlung von Anwendungsbenutzern, die ähnliche Funktionen durchführen.
Die Verwendung von Gruppen in Windows 2000 gegenüber NT 4.0.
In Windows 2000 haben Benutzer die Möglichkeit zur Erzeugung von zwei Typen von Gruppen:

1. Rollengruppen: Benutzer sind Rollengruppen zugewiesen.
2. Steuergruppen: Berechtigungen sind den Steuergruppen zugewiesen.

Dies liefert die Flexibilität zur Definierung verschiedener Rollen in einer Organisation des Benutzers (beispielsweise Scanner, DI-Benutzer, Administratoren, etc.) und zum Zuweisen von Modellberechtigungen (also Steuergruppe). Ein Benutzer kann ebenfalls Gruppen erzeugen, die ähnliche Benutzer aufweisen (also Rollengruppe). Ein Benutzer kann dann mehrere Rollengruppen einer Steuergruppe hinzufügen. Zu beachten ist, dass in der Realität ein Benutzer eine oder mehrere Gruppen ineinander verschachtelt. Beispielsweise Stationsbenutzern absuchen in unterschiedlichen Registrationsbereichen (also Personal, welches die gleichen Typen von Dokumenten abfrägt, wie Versicherungskarten, Einverständnisse, etc.) in den gleichen Typ von Ordnern (beispielsweise Patientenbegegnungsordnern), und Ausführen der gleichen Typen von Funktionen (z.B. Dokumente abfragen, Kommente anzeigen). Eine empfohlene Technik ist die Verwendung des gleichen Namens sowohl für die Steuergruppe als auch die Rollengruppe, wobei die Rollengruppe durch Hinzufügen des Worts "Rolle" an das Ende des Namens gekennzeichnet ist. Beispielsweise

1. Steuergruppe: DI Registrierungsscanner – Dokument-Imaging IP und OP Reg Scanner (Beachte: Dies ist, wo Berechtigungen gewährt sind.).
2. Rollengruppe: DI Registrierungsscannerrolle – Dokument-Imaging IP und OP Benutzer (Beachte: Dies ist, wo Benutzer zugewiesen sind).

In NT 4.0 haben Benutzer nicht die Möglichkeit, Gruppen innerhalb von Gruppen zu verschachteln.
Beide Berechtigungstoken
Ein Token ist ein einzelnes Objekt, welches etwas repräsentiert, das mit der Dokument- Imaginganwendung gesichert werden kann. Es gibt fünf Kategorien von Sicherheitstokens, wie in der folgenden Tabelle 8 beschrieben. Tabelle 8 verdeutlicht Sicherheitstokens, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung.
Tabelle 8
Sicherheitstokens
Anwendungstoken
Das Dokument-Imaginganwendungssicherheitstoken (IMSAPP) wird vorzugsweise auf Unternehmerebene überprüft. Wenn ein Benutzer keine Ausführungsrechte für dieses Token hat, dann ist der Benutzer nicht in der Lage, auf die Anwendung zuzugreifen.
Funktionstoken
Das Dokument-Imagingfunktionstoken (beispielsweise FN_MAINT_DOCTYPES) wird vorzugsweise auf Betriebsebene geprüft. Die eine Ausnahme ist das FN_MAINT-OLCRPTUNDO-Token, welches auf Organisationsebene verwendet werden kann.
Wenn ein Benutzer keine Ausführungsrechte für ein gegebenes Funktionstoken hat, und das Token eine assoziiertes Menüobjekt in dem Dokument-Imagingmenü hat, dann ist dieser Menüpunkt nicht sichtbar. Wenn ein Benutzer keine Ausführungsberechtigung für irgendeinen Menüpunkt hat, für ein gegebenes Menü (beispielsweise Administratormenü), dann ist das gesamte Menü nicht sichtbar.
Ordnertyptokens
Im allgemeinen sollte für Ordnertypen mit Ausnahme der Organisation, wenn ein Benutzer eine Erzeugungsberechtigung für diesen Ordnertyp zuweist, ein Benutzer Leseberechtigung zur Verfügung stellen. Ordnertypsicherheitstokens verwenden Instanzen von Ordnern, nicht Ordnertypen selbst. In einer Mehrorganisationskonfiguration kann die Ordnertypsicherheit entweder auf Betriebsebene oder Organisationsebene geprüft werden, in Abhängigkeit von dem Typ des in Frage stehenden Ordners, wie in 8 weiter beschrieben.
Die folgenden Ordnertypen werden auf Betriebsebene geprüft:

1. Antragsteller.
2. Garantiegeber.
3. Anbieter.
4. Arbeitsliste.
5. Irgendein generischer Ordnertyp.

Die folgenden Ordnertypen werden auf Organisationsebene geprüft:

1. Begegnung.
2. Medizinischer Datensatz.
3. Anspruch.
4. Organisation.
5. Batch.
6. Organisation.

Dokumenttyptokens
Dokumenttypsicherheitstokens verwenden Instanzen von Dokumenten, nicht die Dokumenttypen selbst. Dokumentinstanzen sind vorzugsweise "Eigentum" von oder "gehören" zu dem Unternehmen; in einer Mehrorganisationskonfiguration kann jedoch die Dokumenttypsicherheit entweder auf Betriebsebene oder Organisationsebene in Abhängigkeit von der Situation geprüft werden.
Vorzugsweise werden die Dokumenttypsicherheitstokens auf der Betriebsebene geprüft, wenn:

1. Eine Instana eines Dokuments eines gegebenen Typs (Vordergrund- oder Hintergrundsverarbeitung) erzeugt, geändert oder gelöscht wird, oder
2. Wiedergewinnen einer Instanz eines Dokuments eines gegebenen Typs über die Wiedergewinnungsdokumentenfuktion

Die Dokumentrypsicherheitstokens werden vorzugsweise auf Organisationsebene geprüft, wenn:

1. Ein Ordner geöffnet wird (unter Verwendung der Ordneranzeigefunktion), die direkt an eine gegebene Organisation gebunden ist (beispielsweise ein Begegnungsordner), der Dokumente eines gesicherten Dokumententyps enthält.

VIP Ordnerinstanztokens
Das VIP Objektfeld liefert eine Extrasicherheitsschicht für Ordner, indem ein VIP-Status gewährt wird. Die VIP-Sicherheit kann für jede Instanz eines Ordners verwendet werden, über die Erzeugungs-, Änderungs-, Löschordnerfunktion für Ordner und das Dokumentenmenü. Benutzer mit Ausführungsberechtigung für das FN_SECURE_FOLDER Sicherheitstoken (also Sicherheitsordnerinstanz) kann VIP-Sicherheit verwenden für eine gegebene Ordnerinstanz; im übrigen wird die VIP-Objekt Drop-down-Liste deaktiviert.
Wenn ein Benutzer versucht auf einen Ordner zuzugreifen, erfolgt zuerst die Prüfung, um zu sehen, ob der Benutzer eine gegebene Berechtigung (beispielsweise Lesen, Aktualisieren oder Löschen) für den gegebenen Ordnertyp hat. Wenn der Benutzer die Berechtigung hat; dann erfolgt ein Überprüfen, um zu sehen, ob der Benutzer die Berechtigung für das VIP-Token hat (beispielsweise VIP_CELEBRITY), bevor die gegebene Operation ausgeführt werden kann.
Zu beachten ist:

1. Für Objekte, die auf Organisationsebene geprüft werden, sei angenommen, dass die Sicherheit für individuelle Krankenhäuser konfiguriert ist, um in dieser Weise zu arbeiten. Standardmäßig, wenn ein Benutzer eine Organisation erzeugt, indem die Organisationsoption in dem Administratormenü verwendet wird, wird das "Sicherheit verwendet"-Feld auf die Betriebsebenensicherheitseinstellungen gesetzt.
2. Die Benutzer bräuchten ebenfalls Lese-, Aktualisierungs- oder Löschberechtigungen für den entsprechenden VIP-Status (also VIP_CELEBRITY, VIP_GOV_OFFICIAL oder VIP_HOSP_EMPLOYEES).
3. Obwohl die VIP Sicherheitsschicht ausgelegt wurde, um patientenbezogene Information zu sichern, kann sie für irgendeinen Ordnertyp in dem System verwendet werden (also generisch).
4. Der VIP-Status kann zum Zeitpunkt der Erzeugung des Ordners zugewiesen werden, oder zu irgendeinem Zeitpunkt, zu dem der Ordner geändert wird.
5. Die Ausführungsberechtigung auf das FN_SECURE-FOLDER Token erlaubt einem Benutzer, den FIP-Status zuzuweisen. Wenn diese Berechtigung nicht gewährt ist, ist der Benutzer nicht in der Lage, auf das VIP-Statusfeld zuzugreifen. Wenn diese Berechtigung gewährt ist, gelten die Lese-, Aktualisierungs- oder Löschberechtigungen für das gegebene VIP-Token (beispielsweise VIP_CELEBRITY), wenn ein Benutzer versucht, den Ordner mit einem VIP-Status aufzurufen, zu aktualisieren oder zu löschen.

Unternehmen gegenüber Organisation
8 zeigt ein medizinisches Versorgungsunternehmen 800, mit Ereignissen, die auf Unternehmensebene geprüft werden und auf Organisationsebene, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Bestimmte Sicherheitstokens werden auf Unternehmerebene geprüft, während andere auf Krankenhausebene geprüft werden. Jede Gewähr auf Unternehmensebene fließt nach unten zur Organisationsebene (also angenommene Gewährungen auf Organisationsebene(n)). Jede Gewährung auf Organisationsebene überschreibt eine Zurückweisung auf Unternehmensebene.
Dokumentimaging Tokens zuweisen
9 zeigt ein Benutzerschnittstellenfenster, welches Sicherheitsfunktionen 900 bereitstellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. Die Sicherheitsfunktion ermöglicht einem Benutzer Zugriff auf die verschiedenen Funktionen und Schirme in der Imaginganwendung zuzuweisen oder zu verweigern. Aus dem Administratormenü wählt ein Benutzer "Security", um das Fenster 900 anzuzeigen. Die Sicherheit kann für einen Benutzer oder für eine Gruppe von verschiedenen Unternehmen angewendet werden. Sicherheitsfunktionen für jedes Sicherheitstoken umfassen, sind jedoch nicht darauf beschränkt, das Erzeugen, Lesen, Aktualisieren, Löschen und Ausführen.
In einem medizinischen Versorgungsunternehmen stellt vorzugsweise das Benutzerschnittstellenfenster, welches Sicherheitsfunktionen 900 bereitstellt, einen Zugriff auf einen Speicher zur Verfügung, um eine Sicherheitsinformationsspeicherung zu liefern, die Patientendatensatzzugriffsautorisierungsinformation für Personal unterschiedlicher Organisationen kennzeichnet, wie in 9 gezeigt. Der Report des Erzeugungsprozesses 114 stellt ebenfalls einen Autorisierungsprozessor zur Verfügung, um Zugriff durch ein Individuum (beispielsweise Benutzer) einer der Organisationen auf einen medizinischen Patientendatensatz zu erlauben, in Antwort auf die Autorisierung, die von der Patientendatensatzzugriffsautorisierungsinformation bestimmt wird. Die Sicherheitsinformationsspeicherung in Kombination mit dem Autorisierungsprozessor erlaubt einer Organisation sicheren und geschützten Zugriff auf die Information.
10 zeigt ein Benutzerschnittstellenfenster, welches eine Gruppenauswahl 1000 zur Verfügung stellt, gemäß einem bevorzugten Ausführungsbeispiel der Erfindung. 10 beschreibt allgemein ein medizinisches Versorgungsunternehmen, beispielsweise ein allgemeines Krankenhaussystem, mit einer County Nord Organisation, einer Couny Süd Organisation und einer Kinderklinikorganisation. Begegnungsordner, medizinische Datensatzordner, Anspruchsordner, Organisationsordner, Batchordner und Angestelltenordner werden immer auf Organisationsebene geprüft. Das Anwendungstoken, die Funktionstoken, die Antragstellerordner, die Garantiegeberordner, die generischen Ordner, die Lieferantenordner und die Arbeitslistenordner werden immer auf Unternehmensebene geprüft.
Bevor Sicherheit Gruppen zugewiesen wird, definiert vorzugsweise ein Benutzer zuerst Gruppen und fügt die Gruppen dem NT hinzu. Vorzugsweise führt für jede Gruppe ein Benutzer die folgenden Schritte durch.

1. In 9 stellt ein Benutzer sicher, dass die „Gruppen Radio Button" Schaltfläche ausgewählt ist, dann die Gruppe von dem Drop-down (falls vorhanden) ausgewählt wird, und eine andere Gruppe von der Dropdownliste neben der Schaltflächegruppe ausgewählt wird.
2. In 10, wenn es notwendig ist, wählt ein Benutzer die gewünschte Domain von der Dropdownliste aus, dann wählt er die gewünschte Gruppe und klickt auf die OK-Schaltfläche.
3. In 9 wählt ein Benutzer Unternehmen von dem Organisationsmenü aus.
4. In 9 weist ein Benutzer Rechte zu für unterschiedliche Funktionen, Ordnertypen und Dokumenttpen.
5. In 9 klickt ein Benutzer auf die Speichern Schaltfläche.

Nachdem der Benutzer diese Schritte durchgeführt hat, erscheint die ausgewählte Gruppe automatisch in der Gruppenliste.
Organisationen und Gruppen
Wenn der Benutzer in einer Einzelort-, Einzelorganisationseinrichtung ist, lässt ein Benutzer die Organisationsauswahl als Unternehmen. Wenn der Benutzer vorzugsweise eine Gruppe erzeugt und Berechtigungen an Funktionen zuweist innerhalb der Gruppe, wirken sich diese Berechtigungen über die Organisationen innerhalb eines Unternehmens aus. Wenn der Benutzer folglich Berechtigungen an eine Gruppe gibt, sollte der Benutzer sie zuerst über das Unternehmen zuweisen. Durch Auswahl einer bestimmten Organisation, sind die einzigen Tokens, die der Benutzer ändern kann, Ordner und Dokumenttypen.
Die bevorzugten Ausführungsbeispiele der Erfindung zusammengefasst, stellt das Audit Subsystem 100 einen zentralisierten Mechanismus bereit, um eine Aktivität aufzuzeichnen und zu berichten, die in jeder Softwareanwendung ausgeführt wird, entweder durch automatisierte Prozesse oder durch eine Benutzerinteraktion initiiert. Das Audio-Subsystem 100 kann für irgendein Informationssystem verwendet werden. Für die Zwecke des Auditierens ist die Systemaktivität aus unabhängigen Ereignissen gebildet, die jeweils aufgespürt und in gewisser Weise auditiert werden können. Jedes Ereignis ist eine Kombination einer Aktion und irgendwelchen Daten, für die die Aktion ausgeführt wird. Aktionen können das Lesen und/oder Manipulieren von Daten umfassen, das Lesen und/oder Ändern von Systemkonfigurationen, oder einfach ein Zugreifen auf das System als Ganzes. Das Audit-Subsystem 100 liefert vorzugsweise einen zentralen softwaregesteuerten Mechanismus, der die verarbeitete Information überwacht und aufzeichnet, die sich automatisch ergibt, in verbessertem Datensatzaufbewahren, Management, Sicherheit und Produktivität für ein Informationssystem.
Obwohl die Erfindung unter Bezugnahme auf verschiedene dargestellte Ausführungsbeispiele geschrieben wurde, ist nicht beabsichtigt, die Erfindung auf diese spezifischen Ausführungsbeispiele zu beschränken. Fachleute auf diesem Gebiet erkennen, dass Abweichungen, Modifikationen und Kombinationen der offenbarten Gegenstände vorgenommen werden können, ohne den Schutzbereich der Erfindung, wie er in den beigefügten Ansprüchen definiert ist, zu verlassen.

Claims

System zur Überwachung der Aktivität mindestens einer ausführbaren Anwendung, mit: einem Eingabeprozessor zum Empfangen einer Nachricht, die ein Ereignis identifiziert, welches einer Aktivität entspricht, die von einer ausführbaren Anwendung ausgeführt wird, und die Daten enthält, die mit diesem Ereignis in Zusammenhang stehen, wobei die mit dem Ereignis in Zusammenhang stehenden Daten eine Startzeit und eine Endzeit des Ereignisses enthalten; einem Ereignisprozessor zum Speichern eines Datensatzes des identifizierten Ereignisses und der mit dem Ereignis in Zusammenhang stehenden Daten in einem Datensatzspeicher; einem Überwachungsprozessor zum Auswählen bestimmter Ereignisse, zur Verwendung bei der Überwachung einer bestimmten Aktivität der mindestens einen ausführbaren Anwendung in Antwort auf einen empfangenen Befehl; und einem Ausgabeprozessor zum Vergleichen von ereignisbezogenen Daten, die aus dem Datensatzspeicher abgerufen werden, für die ausgewählten bestimmten Ereignisse und zur Verarbeitung und Formatierung der verglichenen Ereignisdaten, um sie einem Benutzer zu präsentieren.
System nach Anspruch 1, bei dem der Datensatzspeicher einem Ereignis mindestens eine Kennung zuordnet, die ausgewählt ist aus (a) einer Aktionstypkennung, (b) einer Aktionskennung, (c) einer Kategoriekennung und (d) einer client- oder benutzerbezogenen Kennung, wobei die Aktion von der ausführbaren Anwendung ausgeführt wird.
System nach Anspruch 1 oder 2, bei dem die ereignisbezogenen Daten mindestens eine Kennung enthalten, ausgewählt aus (a) einer Anwendungsumgebungskennung, (b) einer Computerjobkennnung, (c) einer Kennung einer Einheit, die für das Ereignis verantwortlich ist, (d) einer Kennung eines Benutzers, der für das Ereignis verantwortlich ist, (e) einer Kennung eines Typs des Clientortes, der das Ereignis anfragt, (f) einer Kennung eines Clientortes, der mit dem Anfragen des Ereignisses in Zusammenhang steht, (g) einer Kennung bezüglich des Erfolges oder des Fehlschlagens des Ereignisses, (h) einer Kennung eines Objekttyps, auf dem in dem Ereignis agiert wird, (i) einer Kennung einer Anzahl von Objekten, auf denen in dem Ereignis agiert wird, und (j) einer Kennung eines Datenstroms, der Daten enthält, die auf Objekte hinweisen, auf denen in dem Ereignis agiert wurde.
System nach irgendeinem der Ansprüche 1 bis 3, bei dem der Überwachungsprozessor bestimmte Ereignisse auswählt, zur Verwendung bei der Überwachung einer bestimmten Aktivität der mindestens einen ausführbaren Anwendung in Antwort auf empfangene Abfragekriterien; und der Ausgabeprozessor die verglichenen Ereignisdaten, um sie einem Benutzer zu präsentieren, in mindestens ein (a) angezeigtes Bild und/oder (b) einen Report verarbeitet und formatiert.
System nach einem der Ansprüche 1 bis 4, bei dem der Überwachungsprozessor periodisch und automatisch bestimmte Ereignisse auswählt zur Verwendung bei der Überwachung einer bestimmten Aktivität der mindestens einen ausführbaren Anwendung in Antwort auf eine vorbestimmte festgelegte Information; und der Ausgabeprozessor die verglichenen Ereignisdaten, um sie einem Benutzer zu präsentieren, in mindestens (a) ein angezeigtes Bild und/oder (b) einen Report verarbeitet und formatiert, in Antwort auf die vorbestimmte festgelegte Information.
System nach einem der Ansprüche 1 bis 5, bei dem der Überwachungsprozessor bestimmte Ereignisse auswählt zur Verwendung bei der Überwachung des Zugriffs auf medizinische Patientendatensätze in Antwort auf empfangene Abfragekriterien.
Datenzugriffsüberwachungssystem zur Ermöglichung des Zugriffs auf medizinische Patientendatensatzinformation durch Personal unterschiedlicher Organisationen an unterschiedlichen Orten, enthaltend: einen Sicherheitsinformationsspeicher, der Patientendatensatzzugriffsautorisierungsinformation für Personal unterschiedlicher Organisationen identifiziert; einen Autorisierungsprozessor zur Ermöglichung des Zugriffs durch eine Person einer der Organisationen auf einen medizinischen Patientendatensatz in Antwort auf eine Autorisierung, die von der Patientendatensatzzugriffsautorisierungsinformation bestimmt wird; einen Eingabeprozessor zum Empfangen einer Nachricht, die ein Ereignis identifiziert, welches mit dem Zugriff durch eine Person einer der Organisationen auf einen medizinischen Patientendatensatz in Zusammenhang steht und Daten enthält, die mit dem Ereignis in Verbindung stehen, wobei die ereignisbezogenen Daten einen Startezeitpunkt und einen Endzeitpunkt des Ereignisses aufweisen; einen Ereignisprozessor zum Speichern eines Datensatzes des identifizierten Ereignisses und der ereignisbezogenen Daten in einem Datensatzspeicher; und einen Überwachungsprozessor zum Auswählen bestimmter Ereignisse zur Verwendung bei der Überwachung des Zugriffs durch die Person einer der Organisationen auf den medizinischen Patientendatensatz.
System nach Anspruch 7, mit einem Ausgabeprozessor zum Vergleichen von ereignisbezogenen Daten, die aus dem Datensatzspeicher abgefragt werden, für die ausgewählten bestimmten Ereignisse und zur Verarbeitung und Formatierung der verglichenen Ereignisdaten, um sie einem Benutzer zu präsentieren.
System nach Anspruch 7 oder 8, bei dem die mehreren Organisationen einen Typ oder mehrere Organisationstypen aufweisen, ausgewählt aus (a) einem Krankenhaus, (b) einer Arztgruppe, (c) einer Klinik, (d) einer Einrichtung, die im Rahmen des Gesundheitswesens zahlt, (e) einer Einrichtung, die im Rahmen des Gesundheitswesens Dienste anbietet, und (f) einer Krankenhausabteilung.
Datenzugriffsmanagementsystem zur Ermöglichung des Zugriffs auf medizinische Patientendatensatzinformation durch Personal unterschiedlicher Organisationen an unterschiedlichen Orten, enthaltend: einen Sicherheitsinformationsspeicher, der Patientendatensatzzugriffsautorisierungsinformation für Personal der unterschiedlichen Organisationen identifiziert; einen Autorisierungsprozessor zur Ermöglichung des Zugriffs durch eine Person einer der Organisationen auf einen medizinischen Patientendatensatz in Antwort auf die Autorisierung, die aus der Patientendatensatzzugriffsautorisierungsinformation bestimmt wird; einen Eingabeprozessor zum Empfangen einer Nachricht, die ein Ereignis identifiziert, welches mit dem Zugriff durch eine Person einer der Organisationen in Zusammenhang steht, auf einen medizinischen Patientendatensatz, und Daten aufweist, die mit dem Ereignis in Zusammenhang stehen; einen Ereignisprozessor zum Speichern eines Datensatzes des identifizierten Ereignisses und des Ereignisses, das mit den Daten in dem Datensatzspeicher in Zusammenhang steht; und einen Überwachungsprozessor zum Auswählen bestimmter Ereignisse zur Verwendung bei der Überwachung des Zugriffs durch die Person einer der Organisationen auf den medizinischen Patientendatensatz.
System nach Anspruch 10, bei dem der Überwachungsprozessor Datensätze der ausgewählten bestimmten Ereignisse vergleicht, um einen Audit-Trial zu liefern, das für die Person einer der Organisationen (a) eine Benutzerkennung, (b) eine Organisation, die mit dem Benutzer in Verbindung steht, (c) einen Ort der Organisation, die mit dem Benutzer in Zusammenhang steht, und (d) einen zugegriffenen Patientendatensatz identifiziert.
System nach Anspruch 10 oder 11, bei dem der Überwachungsprozessor Datensätze der ausgewählten bestimmten Ereignisse vergleicht, um einen Audit-Trial zu liefern, das von (a) Patientendatensatzneuerungen, (b) Patientendatensatzlöschungen, (c) Patientendatensatzhinzufügungen und (d) Startzeitpunkt und Endzeitpunkt des Patientendatensatzzugriffs mindestens eines identifiziert.
System nach einem der Ansprüche 10 bis 12, bei dem der medizinische Patientendatensatz aufweist: (a) Klinik betreffende Patienteninformation, (b) Patientenabrechnungs- oder Finanzinformation, (c) medizinische Überweisungsinformation, (d) medizinische Eignungsverifikationsinformation, (e) medizinische Notwendigkeitsverifikationsinformation und (f) medizinische Behandlungskosten- oder Erstattungsinformation.
System nach einem der Ansprüche 10 bis 13, bei dem der Eingabeprozessor eine Nachricht empfängt, die ein Ereignis identifiziert, welches mit dem Zugriff durch eine Person einer der Organisationen in Zusammenhang steht, auf medizinische Patientendatensatzinformation, enthaltend mindestens eine Information, ausgewählt aus (a) Klinik betreffende Patienteninformation, (b) Patientenabrechnungs- oder Finanzinformation, (c) medizinische Überweisungsinformation, (d) medizinische Eignungsverifikationsinformation, (e) medizinische Notwendigkeitsverifikationsinformation und (f) medizinische Behandlungskosten- oder Erstattungsinformation.
System nach einem der Ansprüche 10 bis 14, bei dem der Autorisierungsprozessor Zugriff ermöglicht durch eine Person einer der Organisationen auf einen medizinischen Patientendatensatz enthaltend mindestens eine Information, die ausgewählt ist aus: (a) Klinik betreffende Patienteninformation, (b) Patientenabrechnungs- oder Finanzinformation, (c) medizinische Überweisungsinformation, (d) medizinische Vermögensverifikationsinformation, (e) medizinische Notwendigkeitsverifikationsinformation und (f) medizinische Behandlungskosten- oder Erstattungsinformation.