RSBAC - Installation und Administration

| # Rule Set Based Access Control (RSBAC) for Linux - Installation und Administration

## ACHTUNG: Dieser Text ist für die alte Version 1.0.2a und wird inhaltlich nicht mehr gepflegt!

## Installation und Administration

Die Quellen des RSBAC-Paketes sind in zwei Teile unterteilt, die Kernerweiterungen in den Dateien rsbac-patch-*.gz und die Administrationswerkzeuge in den Dateien rsbac-admin-*.tar.gz, die getrennt zu installieren sind. Alle Quellen sind über das Internet unter http://www.rsbac.org zu beziehen. Grundkenntnisse im Umgang mit Unix-Systemen werden hier vorausgesetzt.

## Systemkern

### Installation der Quellen

Zwingende Grundlage der Installation sind die Linux-Kernquellen in der angegebenen Version. Diese sind üblicherweise in einer Datei namens linux-2.0.xx.tar.gz erhältlich, die z.B. im Verzeichnis /usr/src mit dem Befehl `tar xvzf linux-2.0.xx.tar.gz` zu entpacken ist. Dabei wird ein Unterverzeichnis linux erzeugt, das in linux-2.0.xx-rsbac umbenannt werden sollte, um Verwechslungen zu vermeiden. Existieren bereits ein Verzeichnis oder eine Datei mit dem Namen linux, sind diese natürlich vorher zu löschen oder umzubenennen. Für den gesamten Quellbaum inklusive RSBAC sind mindestens 30 MB zu veranschlagen.

Anschließend ist die Datei rsbac-patch-*.gz mit `gzip -d rsbac-patch-*.gz` zu dekomprimieren. Ich empfehle, die entstandene Datei rsbac-patch-* ebenfalls in das Verzeichnis /usr/src zu kopieren. Ist das geschehen, können im Kernquell-Hauptverzeichnis /usr/src/linux-2.0.xx-rsbac mit dem Befehl `patch -p1 </usr/src/rsbac-patch-*` die Kernerweiterungen eingespielt werden. Da das Protokoll auf die Standard-Fehlerausgabe geschrieben wird, kann durch Anhängen von `2>/usr/src/err` an den Befehl eine Protokolldatei erzeugt und anschließend überprüft werden. Schlägt die Erweiterung fehl, sollte der gesamte Quellbaum neu erzeugt werden, da eine Wiederholung der Anpassung problematisch ist.

Bei der Erweiterung eines bereits vorhandenen und anderweitig veränderten Quellbaumes kann es passieren, daß Fehler entstehen oder Teile zurückgewiesen werden. Dann ist es sinnvoll, eine Protokolldatei erzeugen zu lassen und gründlich zu prüfen, ob alle Änderungen wie vorgesehen durchgeführt wurden. Selbstverständlich sollte vor jeder Änderung eine Sicherheitskopie des Urzustandes angelegt werden.

### Kernkonfiguration und Übersetzung

Die Konfiguration des Kernes erfolgt durch die üblichen Konfigurationsprogramme, z.B. durch Eingabe von `make menuconfig` im Quellhauptverzeichnis. Das Konfigurationsmenü enthält jetzt ein weiteres Untermenü Rule Set Based Access Control, in dem die Einstellungen der folgenden Liste aktiviert werden können:

- Rule Set Based Access Control: Hauptschalter für sämtliche Erweiterungen. Ist dieser ausgeschaltet, verhält sich der Kern exakt wie die Originalversion. Alle weiteren Punkte erscheinen nur, wenn der Hauptschalter aktiviert ist.
- RSBAC support for MAC policy: Aktivierung der mandatorischen Kontrolle
- RSBAC support for CWI policy: Clark-Wilson-Modul, leider noch ohne Funktion.
- RSBAC support for FC policy; Funktionale Kontrolle
- RSBAC support for SIM policy: Kontrolle der Modifikation von Sicherheitsinformationen
- RSBAC support for PM policy: Datenschutzmodul
- RSBAC support for MS policy: On-Access Malware Scan
- RSBAC policies switchable: An- und Abschalten einzelner Entscheidungsmodule zur Laufzeit, je nach Modul verschiedene Berechtigungen notwendig.
- Use RSBAC maintained process owner: Prozeßbesitzer selber verwalten, sollte aus bleiben
- RSBAC net support: Kontrolle von Netzwerk-Verbindungen (sockets)
- RSBAC check sys_syslog: Überprüfung des Systemaufrufes sys_syslog, verursacht spürbare Zusatzbelastung des Systems ohne großen Sicherheitsnutzen und sollte deaktiviert bleiben
- RSBAC enhanced admin check: Erscheint nur, wenn eine der Politiken MAC, FC oder SIM aktiviert wurde. Ändert die Überprüfung des Benutzers auf Kennung root (Unix-Systemverwalter) in eine Überprüfung auf die Systemrolle Systemadministrator, falls eine der genannten Politiken aktiv ist. Kann die Stabilität des Kerns reduzieren und ist nur dann sinnvoll, wenn mehrere Administratorkennungen verwendet werden sollen.

Nach der Konfiguration kann der Kern wie gewohnt übersetzt und installiert werden. Vor dem Neustart mit diesem Kern ist unbedingt eine der useraci-Dateien aus dem Administrationspaket in das Verzeichnis /rsbac zu kopieren (`make install` im zugehörigen Verzeichnis), da der Systemstart ohne den eingetragenen Administrator root nicht möglich ist! Außerdem sollten ein Sicherheitsbeauftragter mit der Benutzernummer 400 und, falls das Datenschutzmodell verwendet werden soll, ein Datenschutzbeauftragter mit der Nummer 401 eingerichtet werden. Die verwendeten Kennungen können dann später geändert werden.

Erscheint beim Systemstart eine Meldung rsbac_init(): User ACI could not be read und fährt das System nicht vollständig hoch, so ist die kopierte Datei für das verwendete System unbrauchbar. In diesem Fall sind mit einem Warmstart ein unveränderter Kern hochzufahren, in der Kernkonfiguration alle Politiken zu deaktivieren (RSBAC an, aber alle Module abgeschaltet) sowie damit ein neuer Wartungskern zu erzeugen und ebenfalls in das LILO-Startmenü einzutragen. Mit dem Wartungskern können die Administrationswerkzeuge verwendet werden, um die benötigten Rollen neu zu setzen.

### Kernparameter

Beim Start des Systems ermöglicht der Linux-Loader (LILO), dem Kern Parameter zu übergeben, die sein Verhalten beeinflussen. Die von den RSBAC-Erweiterungen akzeptierten Parameter zeigt die folgende Liste:

- rsbac_debug_ds: Erweiterte Ablauf- und Fehlermeldungen der Datenhaltung
- rsbac_debug_aef: Erweiterte Ablauf- und Fehlermeldungen der Durchsetzung
- rsbac_debug_no_adf (ab v1.0.1): Voreinstellung: keine Protokollierung von Anforderungen an die Entscheidungskomponente
- rsbac_debug_adf: Voreinstellung: Protokollierung abgelehnter Anforderungen an die Entscheidungskomponente (für den Testbetrieb dringend, später bedarfsabhängig zu empfehlen)
- rsbac_debug_adf_all: Voreinstellung: Protokollierung aller Anforderungen an die Entscheidungskomponente (erzeugt sehr viele Daten!)
- rsbac_debug_ds_pm: Erweiterte Ablauf- und Fehlermeldungen der Datenhaltung für das Datenschutzmodul
- rsbac_debug_aef_pm: Erweiterte Ablauf- und Fehlermeldungen der PM-Systemaufrufe
- rsbac_debug_adf_pm: Erweiterte Ablauf- und Fehlermeldungen der Zugriffskontrolle in PM-Entscheidungen
- rsbac_debug_pm: Setzt rsbac_debug_ds_pm, rsbac_debug_aef_pm, rsbac_debug_adf_pm (für den PM-Testbetrieb ebenfalls zu empfehlen)
- rsbac_debug_adf_ms (ab 1.0.2): Erweiterte Ablauf- und Fehlermeldungen der Zugriffskontrolle in MS-Entscheidungen
- rsbac_debug_all: Setzt rsbac_debug_ds, rsbac_debug_aef, rsbac_debug_adf_all, rsbac_debug_pm, rsbac_debug_ms

## Administrationswerkzeuge

### Installation

Die Administrationswerkzeuge in der Datei rsbac-admin-*.tar.gz können in einem beliebigen Verzeichnis, z.B. /root/rsbac, mit dem Befehl `tar xvzf rsbac-admin-*.tar.gz` ausgepackt werden. Danach sind in Makefile die Pfade zum Verzeichnis der Kernquellen, für die Programminstallation und für die Hilfe-Seiten (man-Seiten) anzupassen.

Mit `make` werden die Hilfsprogramme erzeugt, mit `make install` installiert und mit `make allclean` das Verzeichnis wieder aufgeräumt. Falls sie nicht existiert, erzeugt `make install` außerdem die Datei /rsbac/useraci, die die benötigten Benutzerattribute für den Systemstart und die Administration enthält.

### Allgemeine Administration

Die allgemeine Administration erfolgt ausschließlich über Kommandozeilen. Dazu existieren mehrere Hilfsprogramme, die sich der neuen Systemaufrufe bedienen. Jedes dieser Programme gibt beim Aufruf ohne Parameter eine kurze Hilfe aus. Die Überprüfung der Berechtigung des jeweiligen Aufrufes erfolgt in den Systemaufrufen. Die folgende Liste bietet eine kurze Beschreibung der Befehle:

- attr_get_fd: Auslesen von Attributwerten von FILE- und DIR-Objekten aus der allgemeinen Datenhaltung. Die Parameter sind Zieltyp (FILE oder DIR), Attributname und die Namen der Dateien oder Verzeichnisse, deren Attribute auszulesen sind. Die Ausgabe erfolgt als Zahlenwert des jeweiligen Wertes.
- attr_get_file_dir: Neuere Version ab v1.0.1, script-optimiert.
- attr_set_fd: Setzen entsprechender Attributwerte. Die Parameter sind Zieltyp (FILE oder DIR), Attributname, Zahlenwert und die Namen der Dateien oder Verzeichnisse, deren Attribute zu setzen sind.
- attr_set_file_dir: Neuere Version ab v1.0.1, script-optimiert.
- attr_get_up: Auslesen von Attributwerten von USER- und PROCESS-Objekten aus der allgemeinen Datenhaltung. Die Parameter sind Zieltyp (USER oder PROCESS), Attributname und die Nummer des Objektes, dessen Attribut auszulesen ist. Die Ausgabe erfolgt als Zahlenwert des jeweiligen Wertes.
- attr_get_user: Neuere Version ab v1.0.1, script-optimiert.
- attr_get_process: Neuere Version ab v1.0.1, script-optimiert.
- attr_set_up: Setzen entsprechender Attributwerte. Die Parameter sind Zieltyp (USER oder PROCESS), Attributname, Zahlenwert und die Nummer des Objektes, dessen Attribut zu setzen ist.
- attr_set_user: Neuere Version ab v1.0.1, script-optimiert.
- attr_set_process: Neuere Version ab v1.0.1, script-optimiert.
- attr_rm_user: Löschen aller Attribute der angegebenen Benutzer
- attr_get_ipc: Neu ab v1.0.1 f$uuml;r IPC-Objekte, script-optimiert.
- attr_set_ipc: Neu ab v1.0.1 f$uuml;r IPC-Objekte, script-optimiert.
- rsbac_menu: Neu ab v1.0.1, dialog-Hauptmenü für die Grundadministration
- rsbac_fd_menu: Neu ab v1.0.1, dialog-Menü für die FILE/DIR-Administration
- rsbac_user_menu: Neu ab v1.0.1, dialog-Menü für die USER-Administration
- rsbac_process_menu: Neu ab v1.0.1, dialog-Menü für die PROCESS-Administration
- rsbac_ipc_menu: Neu ab v1.0.1, dialog-Menü für die IPC-Administration
- rsbac_stats: Ausgabe des Status der allgemeinen Datenhaltung über das System-Log, Stufe KERN_INFO.
- switch_adf_log: Festlegen der Protokollstufe eines Systemaufrufes. Die Parameter sind Name der Anforderung und Stufe (0-2).
- switch_module: An- und Abschalten von Modulen, falls aktiviert. Die Parameter sind Modulname und 0 oder 1. Die benötigten Berechtigungen sind modulabhängig.

Bis auf das Datenschutzmodell erfolgt die gesamte Administration aller implementierten Sicherheitsmodelle durch das Setzen entsprechender Attribute. Dieses ist aber nur Benutzern mit der System-Rolle Sicherheitsbeauftragter gestattet, die bei der Installation für Benutzer Nr. 400 eingetragen wird. Ist kein Sicherheitsbeauftragter vorhanden, muß, wie oben beschrieben, ein Wartungskern ohne Sicherheitsmodule erzeugt und mit diesem die Neuverteilung der Rollen vorgenommen werden.

Die zu setzenden Attribute sind bei den Modellen beschrieben. Zudem werden dort die den verwendeten Systemaufrufen zugrundeliegenden Datentypen vorgestellt, in denen sich alle verwendbaren Attribute wiederfinden. Die exakte Schreibweise ist der jeweiligen Kurzhilfe der Befehle zu entnehmen. Eine eventuell benötigte Ordnungsnummer ergibt sich aus dem Datentyp des Attributs und ist ebenfalls der Kurzhilfe zu entnehmen.

### Administration des PM-Moduls

Sobald das Datenschutzmodul aktiv ist, können keine für dieses Modul relevanten Attribute mit den bisher genannten Befehlen mehr gesetzt werden. Stattdessen erfolgt die gesamte Verwaltung mit dem Programm rsbac_pm, das hauptsächlich eine Eingabeschnittstelle zu dem gleichlautenden, Ticket-basierten Systemaufruf ist. Allerdings können hier an Stelle von Ordnungsnummern auch die jeweiligen Bezeichnungen verwendet werden, beispielsweise security_officer bei der Funktion set_role.

Da die Vergabe von PM-Rollen nur mit Tickets möglich ist, muß jeweils mindestens ein Benutzer mit der Rolle Sicherheitsbeauftragter und der Rolle Datenschutzbeauftragter existieren, was bei den Installation sichergestellt sein sollte. Ansonsten sind der schon beschriebene Wartungskern zu installieren und die Rollen mit `attr_set_up USER pm_role Ordnungsnummer Benutzernummer` zu setzen.

### Weitere Programme

Bei den Administrationswerkzeugen befinden sich noch weitere Programme, deren Verwendung hier kurz erläutert werden soll. Selbstverständlich unterliegen diese Programme der Zugriffskontrolle.

- rsbac_pm: Komplette Administration des PM-Moduls
- rsbac_stats_pm: Ausgabe des Status der Datenhaltung des PM-Moduls über das System-Log.
- pm_create: Erzeugen von Dateien mit angegebener PM-Objektklasse. Die Parameter sind Objektklasse, diskreter Modus (z.B. 644) und Namen der Dateien.
- pm_ct_exec: Ausführen eines Programmes mit angegebener aktueller Aufgabe, das diese nicht selbsttätig setzen kann. Die Parameter sind aktuelle Aufgabe, Programmname und dessen Parameter.

## Anwendungsbeispiel

Zur Demonstration des Systems ist in Zusammenarbeit mit Simone Fischer-Hübner ein vereinfachtes Anwendungsbeispiel entstanden, das zwar mehrere der implementierten Sicherheitsmodelle verwendet, sich aber auf das umfangreichste, das Datenschutzmodell, konzentriert. Weitere Module können natürlich jederzeit dazugeschaltet werden.

### Aufgabenstellung

Für eine kleinere Operationsklinik ist elektronische Datenverarbeitung zu betreiben. Dabei soll der Datenschutz für sämtliche Patientendaten gewährleistet, aber auch Forschung in Form von statistischer Auswertung des Operationsverlaufes betrieben werden. Die Grundsätze minimalen Wissens und größtmöglicher Aufgabentrennung sind außerdem zu beachten.

Die Vorhaltung und Verarbeitung der Daten soll innerhalb eines geschützten Systems ohne Fremdzugriffe und Weitergabe betrieben werden. Die einzigen Ausnahmen sind die Weitergabe der Abrechnungdaten eines Patienten an die zuständige Krankenkasse und die Übermittlung der Diagnose bei einer Überweisung zu einer anderen Behandlungsstelle. Beides erfolgt über eine bestehende, angemessen gesicherte Netzwerkverbindung.

Der Gesamtaufenthalt eines Patienten soll folgende Schritte durchlaufen:

1. Aufnahme durch die Verwaltung
2. Diagnose und Behandlungsauftrag durch einen Internisten
3. Operation durch einen Chirurgen
4. Betreuende Therapie
5. Entlassung
6. Abrechnung mit der zuständigen Krankenkasse

### Umsetzung in das Datenschutzmodell

Zunächst sind die Zwecke der Datenspeicherung mit ihren zugeordneten Aufgaben festzulegen:

Zweck | Behandlung | Verwaltung | Forschung
--- | --- | --- | ---
Aufgaben | Diagnose | Aufnahme | Statistik
| Operation | Entlassung |
| Therapie | Abrechnung |
| Überweisung | Datenweitergabe |

Zur Speicherung der Daten sind Objektklassen mit zugeordneten Zwecken zu definieren:

Objektklasse | Zwecke | Inhalte
--- | --- | ---
Aufnahmedaten | Verwaltung | Grunddaten des Patienten
Abrechnungsdaten | Verwaltung | Abrechnung der erbrachten Leistungen
Befund | Behandlung | Diagnosedaten
Behandlungsauftrag | Behandlung | Anweisungen an Operateure und Therapeuten
OP-Daten | Behandlung | Verlauf der Operation
Leistungsdaten | Verwaltung, Behandlung | Erbrachte Leistungen
Statistiken | Forschung | Auswertungen der Operationsverläufe

Als nächstes werden Benutzer definiert und für ihre Aufgaben autorisiert:

Benutzer | Autorisierte Aufgaben
--- | ---
Internist | Diagnose, Therapie, Überweisung
Chirurg | Operation, Überweisung
Therapeut | Therapie
Verwalter | Aufnahme, Entlassung
Buchhalter | Abrechnung, Datenweitergabe
Forscher | Statistik

Zur Verarbeitung der Daten werden folgende Transformationsprozeduren definiert:

TP | Einsatz
--- | ---
pm_create | Erzeugen von Dateien einer Klasse
Anfüge-Editor | Erfassen eines Textes und Anhängen an eine Datei
Editor | Ändern einer Textdatei
Anzeigeprogramm | Bildschirmanzeige einer Textdatei
Löschprogramm | Löschen einer Datei
Weitergabeprogramm | Verschlüsselte Weitergabe von Dateiinhalten über Interprozeßkommunikation
Statistikprogramm | Lesen einer Datei, Erstellen einer Statistik und Schreiben in eine andere Datei

Der nächste Schritt ist die Bestimmung der autorisierten Transformationsprozeduren aller Aufgaben:

Aufgabe | Autorisierte TP
--- | ---
Diagnose | pm_create, Anfüge-Editor, Editor, Anzeigeprogramm
Operation | pm_create, Anfüge-Editor, Editor, Anzeigeprogramm
Therapie | Anfüge-Editor, Anzeigeprogramm
Überweisung | Weitergabeprogramm
Aufnahme | pm_create, Editor
Entlassung | Anfüge-Editor
Abrechnung | Editor, Anzeigeprogramm
Datenweitergabe | Weitergabeprogramm
Statistik | pm_create, Editor, Statistikprogramm

Schließlich ist als letztes die Menge der notwendigen Zugriffe zu bestimmen. Die möglichen Zugriffsarten sind Lesen, Schreiben, Löschen, Erzeugen und Anfügen.

Aufgabe | Objektklasse | TP | Zugriffe
--- | --- | --- | ---
Diagnose | Befund | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
" | " | Anzeigeprogramm | Lesen
" | Leistungsdaten | Anfüge-Editor | Anfügen
" | Behandlungsauftrag | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
Operation | Behandlungsauftrag | Anzeigeprogramm | Lesen
" | OP-Daten | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
" | Leistungsdaten | Anfüge-Editor | Anfügen
Therapie | Behandlungsauftrag | Anzeigeprogramm | Lesen
" | Leistungsdaten | Anfüge-Editor | Anfügen
Überweisung | Befund | Weitergabeprogramm | Lesen
" | Behandlungsauftrag | Weitergabeprogramm | Lesen
" | Interprozeßkommunikation | Weitergabeprogramm | Erzeugen, Schreiben, Anfügen
Aufnahme | Aufnahmedaten | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
" | Leistungsdaten | pm_create | Erzeugen
" | " | Anfüge-Editor | Anfügen
Entlassung | Aufnahmedaten | Anfüge-Editor | Anfügen
" | Leistungsdaten | Anfüge-Editor | Anfügen
Abrechnung | Leistungsdaten | Anzeigeprogramm | Lesen
" | Abrechnungsdaten | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
Datenweitergabe | Abrechnungsdaten | Weitergabeprogramm | Lesen
" | Interprozeßkommunikation | Weitergabeprogramm | Erzeugen, Schreiben, Anfügen
Statistik | Statistikdaten | pm_create | Erzeugen
" | " | Editor | Lesen, Schreiben, Anfügen
" | " | Löschprogramm | Löschen
" | " | Statistikprogramm | Schreiben, Anfügen
" | Befund | Statistikprogramm | Lesen
" | Behandlungsauftrag | Statistikprogramm | Lesen
" | OP-Daten | Statistikprogramm | Lesen

Für das PM-Modul sind in der aktuellen Fassung alle genannten Bezeichnungen als Zahlenwert zu kodieren und über Tickets mit rsbac_pm einzugeben.

### Andere Modelle

Da das PM-Modell nur personenbezogene Daten und Administrations-Systemaufrufe vor Unbefugten schützt, bleiben andere Dateien und Verzeichnisse von der diskreten Rechteverwaltung abhängig. Es liegt nahe, diese durch mindestens ein anderes Modell vor Zugriffen zu schützen. Aufgrund der höheren Sicherheit sollte aber zumindest die Authentisierungsdatei /etc/shadow als personenbezogen mit eigener Objektklasse definiert und das Öffnen über notwendige Zugriffe beschränkt werden.

Für dieses Beispiel bietet sich die Verwendung der funktionalen Kontrolle an, um den Zugriff auf alle anderen sicherheitsrelevanten Dateien und Verzeichnisse über die Objektkategorien Sicherheits- und Systemobjekt einzuschränken. Für die sicherheitsrelevanten Objekte, die, wie die Identifizierungsdatei /etc/passwd, nur nicht unbefugt verändert werden sollen, kann das Sicherheits-Informations-Modifikations-Modell (SIM) mit dem Attribut Datentyp eingesetzt werden.

Das mandatorische Modell ist dann zusätzlich sinnvoll, wenn auch vertrauliche, nicht-personenbezogene Daten abzulegen sind, z.B. Geschäftsdaten.

### Ablauf aus Systemsicht

Der Durchgang eines Patienten durch die Klinik wird durch folgende Schritte abgebildet:

1. Der Verwalter nimmt den Patienten in die Klinik auf. Dabei erzeugt er mit pm_create eine Datei für die Leistungsdaten und mit dem Editor eine Datei für die Aufnahmedaten, die er dort auch gleich vermerkt. Die Aufnahme wird anschließend mit dem Anfügeeditor als Leistung eingetragen.
2. Der Internist erzeugt eine Diagnosedatei und verwendet den Editor, um die Diagnose zu schreiben und bei Bedarf anzupassen. Anschließend erzeugt er eine Datei mit dem Behandlungsauftrag für diesen Patienten, den er per Editor einträgt und bei Bedarf ebenfalls anpaßt. Zum Schluß wird die erbrachte Leistung an die Leistungsdaten angefügt.

   Bei Bedarf kann der Patient außerdem an einen anderen Arzt oder eine andere Klinik überwiesen werden. Dazu können bisherige Diagnose und Behandlungsauftrag verschlüsselt per Netzwerk übermittelt werden.

3. Der Chirurg liest den Behandlungsauftrag mit dem Anzeigeprogramm und operiert den Patienten. Anschließend erzeugt und editiert er die OP-Daten, um den Verlauf der Operation zu dokumentieren. Auch der Chirurg fügt seine Leistung den Leistungsdaten hinzu.

   Wie der Internist kann der Chirurg den Patienten bei Bedarf an einen anderen Arzt oder eine andere Klinik überweisen und Diagnose- und Behandlungsauftragsdaten dorthin übertragen.

4. Der Therapeut liest ebenfalls den Behandlungsauftrag, therapiert und pflegt den Patienten und fügt seine erbrachte Leistung an die Leistungsdaten an.
5. Nach Ende der Behandlung wird der Patient durch den Verwalter entlassen, der dazu Aufnahme- und Leistungsdaten mit dem Anfügeeditor abschließt.
6. Der Buchhalter liest die Leistungdaten und erzeugt und editiert die Abrechnungsdaten, die er anschlieáend mit dem Weitergabeprogramm an die Krankenkasse übermittelt.
7. Befund, Behandlungsauftrag und OP-Daten können vom Forscher mit dem Statistikprogramm ausgewertet und Statistikdaten erzeugt, geändert sowie gelöscht werden. Die Verwendung weiterer Daten des Patienten erfordert dessen Einwilligung zum Zweck Forschung.

Zurück zur RSBAC-Hauptseite

- Questions, tips, etc.

05-Mar-99, -ao