Datenschutz – technische Details
Speicherung, Zugriff, Datenminimierung, Mandantentrennung
Diese Seite beschreibt die technischen und organisatorischen Maßnahmen (TOMs) in RevenueForecast. Sie richtet sich an technisches Personal, Datenschutzbeauftragte oder Auditoren.
1. Welche Daten werden gespeichert
| Tabelle / Feld |
Inhalt |
Appointments |
Termine: patient_name (freier Text – kann Pseudonym sein), appointment_date, start_time, duration_minutes, procedure_id, office_id, staff_id (optional), status, notes |
MedicalProcedures |
Behandlungskatalog: Code, Bezeichnung, Dauer, Preis, Farbe – keine Patientendaten |
StaffMembers |
Mitarbeiter: Name, Rolle, Kontakt – keine Patientendaten |
StaffHoliday |
Urlaubs- und Abwesenheitszeiten der Mitarbeiter |
Skills, ProcedureSkills, StaffSkills |
Qualifikationen und deren Zuordnung – keine Patientendaten |
DoctorsOffices |
Praxisstammdaten: Name, Adresse, Kontakt, Branding |
PracticeUsers |
Benutzerkonten: E-Mail, Passwort-Hash, Rolle |
UserColumnMappingPreferences |
gespeicherte CSV-Spaltenzuordnungen pro Benutzer |
Datenminimierung: RevenueForecast erhebt keine Diagnosen, keine Versicherungsdaten, keine Geburtsdaten, keine Adressen. Der Patientenbezug ist ein einzelnes Freitextfeld, das auch als Nummer, Fallzeichen oder Initialen genutzt werden kann.
2. Wo die Daten liegen
- Azure SQL Database, Rechenzentrum in der EU
ALTER DATABASE … SET ENCRYPTION ON – TDE (Transparent Data Encryption), Verschlüsselung ruhender Daten- TLS-Verschlüsselung bei der Übertragung (Standard Azure SQL)
- Azure Key Vault für Verbindungszeichenfolgen – keine Klartext-Geheimnisse in
Web.config
- Automatische Backups durch Azure (Point-in-Time Recovery)
3. Zugriffskontrolle
3.1 Mandantentrennung (Row-Level Security)
Jede Praxis ist ein eigener Tenant. Die Trennung erfolgt auf Datenbankebene über Row-Level Security. Die Filterfunktion security.fn_tenant_filter vergleicht die office_id jeder Zeile mit dem SESSION_CONTEXT('tenant_id') der aktuellen Verbindung.
Der Tenant-Kontext wird ausschließlich serverseitig aus der Anmeldesitzung gesetzt – er ist nicht durch Benutzereingabe manipulierbar. Ein Benutzer einer Praxis kann technisch keine Daten einer anderen Praxis sehen.
3.2 Rollenmodell
PracticeUsers.user_type = 'Admin' – darf Stammdaten ändern (Behandlungen, Mitarbeiter, Qualifikationen)- Alle anderen Rollen – nur Lesen
- Schreibende Stored Procedures rufen zusätzlich
appcal.sp_RequireAdmin auf
3.3 Fehlerprotokollierung
Server-seitige Ausnahmen werden in appcal.DB_Errors protokolliert. Es werden technische Fehlerinformationen gespeichert – keine Patientendaten.
4. Anwendungsarchitektur
- ASP.NET WebForms (.NET Framework 4.8), ausgeliefert von Azure App Service
- Datenzugriff ausschließlich über parametrisierte Stored Procedures
- Keine dynamischen SQL-Strings in der Anwendung – alle Datenbankzugriffe sind serverseitig definiert
- Sitzungsverwaltung per ASP.NET-Session, kein persistenter Login-Token
- Passwörter werden mit BCrypt gehasht gespeichert – kein Klartext, kein umkehrbarer Hash
5. Datenminimierung – der zentrale Punkt
RevenueForecast ist ein Auslastungs- und Umsatzprognose-Werkzeug. Es ist nicht dazu gedacht, Patientinnen und Patienten zu identifizieren. Das schlägt sich in der Architektur nieder:
- Es gibt genau ein Freitextfeld pro Termin, das einen Patientenbezug tragen kann:
patient_name
- Es gibt keine strukturierten Patientendaten (kein Geburtsdatum, keine Adresse, keine Versicherungsnummer)
- Es gibt keine Verknüpfung zu einem Patientenverwaltungssystem – die Zuordnung erfolgt in der Praxis, nicht in der App
Empfehlung für Praxen: Importieren Sie Patientennummern, Fallzeichen oder Initialen anstelle von Klarnamen. Damit bleibt der Nutzen vollständig erhalten und die Datenverarbeitung ist faktisch pseudonymisiert.
6. Was die Anwendung (noch) nicht bietet
Für einen vollständigen Datenschutz-Audit sind folgende Punkte zu ergänzen, sobald das System mit personenbezogenen Patientendaten betrieben wird:
- Auskunfts- und Löschfunktion auf Patientenebene – aktuell können Termine einzeln gelöscht werden; ein „alles zu Patient X exportieren/löschen“ ist nicht implementiert
- Zugriffsprotokoll – wer hat wann welchen Termin angesehen. Für den Routinebetrieb nicht erforderlich, für strenge Audits empfehlenswert
- Auftragsverarbeitungsvertrag (AVV) – organisatorisch, nicht technisch: zwischen Praxis und Anbieter abzuschließen
- Datenschutzerklärung und Impressum für eine öffentliche Instanz
Wichtig: Diese Punkte betreffen
personenbezogene Patientendaten. Wenn Sie – wie oben empfohlen – ausschließlich pseudonyme Kennungen (Patientennummern, Fallzeichen, Initialen) importieren, verarbeitet RevenueForecast
keine personenbezogenen Gesundheitsdaten. Die genannten Punkte sind dann entweder gar nicht relevant oder deutlich weniger dringlich:
- Auskunft/Löschung: Ein Auskunftsersuchen zu „Patient X“ kann ohne Klarnamen nicht gestellt werden – die Praxis identifiziert Patientinnen und Patienten in ihrem Praxisverwaltungssystem, nicht in RevenueForecast.
- Zugriffsprotokoll: Ohne personenbezogene Daten ist eine Zugriffsprotokollierung keine DSGVO-Pflicht mehr.
- AVV: Ein Auftragsverarbeitungsvertrag ist nur erforderlich, wenn im Auftrag personenbezogene Daten verarbeitet werden. Bei rein pseudonymer Nutzung entfällt diese Pflicht.
7. Anpassbarkeit für andere Branchen
Die Kernlogik – Termine, benötigte Qualifikationen, verfügbares Personal, Auslastung – ist nicht medizinisch. Sie passt auf jede Dienstleistung mit gebuchten Zeitfenstern und qualifizierten Mitarbeitern:
- Physiotherapie, Zahnmedizin, Tiermedizin
- Kosmetik- und Friseurbetriebe
- Werkstätten mit Zertifizierungen
- Nachhilfe, Beratung, Kanzleien
Je weiter man sich vom medizinischen Bereich entfernt, desto geringer werden die datenschutzrechtlichen Anforderungen an die verarbeiteten Daten. Eine Version für nicht-medizinische Dienstleister würde patient_name durch ein generisches Kundenmerkmal ersetzen und MedicalProcedures in Services umbenennen – die restliche Architektur bleibt unverändert.
Hinweis: Diese Seite beschreibt technische Maßnahmen, sie ersetzt keine Rechtsberatung. Vor einem Produktivbetrieb mit echten Patientendaten sollten Sie mit einem Datenschutzbeauftragten oder Anwalt für Medizinrecht sprechen.