Zahlen sehen, ohne Einzelschicksale zu offenbaren
Entwicklung von Fachanwendungen und Auswertungen für Träger, Praxen und Dienstleister in Haar, deren Daten nur einem eng begrenzten Personenkreis offenstehen dürfen.
Haar liegt rund 13 km östlich unseres Büros in München-Neuhausen. Das Gesundheits- und Sozialwesen prägt den Ort stärker als jede andere Branche, daneben stehen Wohnbebauung und gemischtes Gewerbe. Für die Softwareentwicklung ergibt sich daraus eine ungewöhnliche Ausgangslage: Nicht der Funktionsumfang ist hier die schwierigste Frage, sondern die Sichtbarkeit. Eine Auswertung, die in einem Handelsbetrieb selbstverständlich wäre, kann in einer Einrichtung mit Betreuungsdaten unzulässig sein, sobald sich aus wenigen Merkmalen eine einzelne Person rekonstruieren lässt. Genau an dieser Grenze arbeiten wir.
Auswertung mit eingebauter Grenze
Kennzahlen werden erst ab einer festgelegten Fallzahl angezeigt. Unterschreitet eine Auswahl diese Schwelle, bleibt das Feld leer statt verräterisch klein.
Rechte im Datenmodell, nicht in der Oberfläche
Zugriffsregeln werden dort durchgesetzt, wo die Abfrage entsteht. Ein ausgeblendetes Feld allein ist keine Schutzmaßnahme.
Anbindung an Fachverfahren
Bestehende Dokumentationssysteme bleiben führend. Wir holen Daten lesend ab, statt eine zweite Wahrheit zu erzeugen.
Protokoll als Bestandteil
Jeder lesende Zugriff auf sensible Datensätze wird mitgeschrieben, damit eine spätere Rückfrage beantwortbar bleibt.
Warum Auswertungen in Haar anders geplant werden müssen
Die üblichen Anforderungen an ein Berichtswesen lauten: möglichst frei filterbar, möglichst tief aufschlüsselbar, möglichst nah am Einzelfall. In einer Einrichtung mit besonderen Kategorien personenbezogener Daten ist jede dieser drei Eigenschaften ein Risiko. Wer nach Standort, Altersgruppe und Betreuungsform filtert, landet bei kleinen Gruppen schnell bei genau einer Person.
Wir planen deshalb von der Ausgabe her rückwärts: Zuerst wird festgelegt, welche Aussage eine Kennzahl tragen soll und wer sie braucht. Erst danach entsteht die Abfrage. Filterkombinationen, die zur Einzelperson führen, lassen wir technisch nicht zu.
- ✓Festlegung von Mindestfallzahlen je Auswertung
- ✓Sperrung von Filterkombinationen mit Rekonstruktionsrisiko
- ✓Getrennte Berichte für Leitung, Fachbereich und Träger
- ✓Kennzeichnung aggregierter Werte mit ihrer Bezugsmenge
Zugriffstrennung technisch durchsetzen
In gewachsenen Umgebungen hängt die Rechtevergabe oft an Dateifreigaben. Sobald eine Anwendung ins Spiel kommt, reicht das nicht mehr, weil die Anwendung selbst mit einem technischen Konto auf die Datenbank zugreift und damit potenziell alles sehen kann.
Wir lösen das über Filterung auf Datenbankebene: Die Anmeldung bestimmt, welche Datensätze überhaupt geladen werden. Wer keine Berechtigung für einen Bereich hat, erhält keine leere Maske, sondern schlicht keine Zeile. Ergänzend trennen wir Bearbeitungs- von Leserechten und binden das Rollenmodell an Funktionen statt an einzelne Namen.
- ✓Datensatzbezogene Filterung statt Ausblenden im Frontend
- ✓Rollen an Funktionen gekoppelt, nicht an Personen
- ✓Trennung von Lese-, Bearbeitungs- und Exportrechten
- ✓Export nur für ausdrücklich freigegebene Berichte
Bestehende Dokumentationssysteme einbinden
Fachverfahren in Betreuung und Versorgung sind selten austauschbar. Sie bilden gesetzliche Vorgaben ab, sind zertifiziert oder von einem Kostenträger vorgegeben. Eine Eigenentwicklung, die diese Systeme ersetzen will, ist in aller Regel der falsche Weg.
Sinnvoll ist stattdessen die Ergänzung. Wir greifen über eine Herstellerschnittstelle oder eine lesende Datenbankverbindung auf die vorhandenen Daten zu und bauen darauf die Auswertung, die Dienstplanhilfe oder die Belegungsübersicht, die das Fachverfahren nicht liefert. Die Datenhoheit bleibt dabei ausdrücklich beim führenden System.
- ✓Lesender Zugriff statt paralleler Datenhaltung
- ✓Abstimmung mit dem Hersteller des Fachverfahrens
- ✓Ergänzende Module für Lücken im Standardumfang
- ✓Klare Festlegung, welches System bei Konflikten gilt
Nachvollziehbarkeit ohne Überwachungseindruck
Protokollierung ist in sensiblen Umgebungen notwendig, wirkt im Team aber schnell wie Kontrolle. Wir gehen deshalb offen damit um: Was mitgeschrieben wird, steht in der Anwenderdokumentation, und die Anwendung zeigt es beim Aufruf sensibler Bereiche auch an.
Technisch schreiben wir Zeitpunkt, Konto, aufgerufenen Datensatz und Art des Zugriffs mit. Auswertbar ist das Protokoll nur für einen benannten Personenkreis, und die Auswertung selbst wird ebenfalls protokolliert. Das nimmt der Sache die Einseitigkeit.
- ✓Transparente Beschreibung des Protokollumfangs
- ✓Hinweis in der Oberfläche beim Öffnen sensibler Daten
- ✓Auswertung des Protokolls nur durch benannte Rollen
- ✓Aufbewahrungsfrist für Protokolldaten festgelegt
Wann wir in Haar von Eigenentwicklung abraten
Sobald eine Anforderung direkt aus einer Abrechnungsvorschrift stammt, raten wir zum Standardprodukt. Die Regeln ändern sich regelmäßig, und eine Eigenentwicklung müsste jeder Änderung hinterherlaufen – auf Ihre Kosten und mit Ihrem Risiko.
Ebenso wenig sinnvoll ist eine eigene Lösung, wenn ein Kostenträger ein bestimmtes Verfahren oder ein Austauschformat vorgibt, das nur ein zugelassenes Produkt erzeugen darf. Das sagen wir im Erstgespräch, auch wenn es das Projekt kleiner macht.
- ✓Abrechnungslogik gehört in geprüfte Standardsoftware
- ✓Vorgegebene Verfahren nicht durch Eigenbau ersetzen
- ✓Eigenentwicklung für Ergänzungen und Auswertungen
- ✓Ehrliche Absage statt unnötigem Entwicklungsauftrag
Häufige Fragen
Technisch spricht nichts dagegen, solange Zweckbindung, Zugriffsbeschränkung und Löschfristen eingehalten werden. Die rechtliche Bewertung nimmt Ihre Datenschutzbeauftragung vor; wir liefern die technische Beschreibung: welche Daten verarbeitet werden, wo sie liegen und wer sie sehen kann.
Ja, wenn das von Anfang an Teil der Anforderung ist. Wir arbeiten mit Mindestfallzahlen und gesperrten Filterkombinationen. Nachträglich lässt sich das nur eingeschränkt ergänzen, weil die Datenstruktur dann bereits auf Einzelzugriff ausgelegt ist. Deshalb klären wir diesen Punkt in der Analysephase zuerst.
Bei dieser Datenlage empfehlen wir üblicherweise den Betrieb in Ihrer eigenen Umgebung. Möglich ist auch ein deutscher Standort mit Auftragsverarbeitungsvertrag. Ausschlaggebend ist, welche Datenkategorien tatsächlich in die Anwendung gelangen und ob überhaupt ein Personenbezug entsteht oder ob ausschließlich aggregierte Werte verarbeitet werden.
Das Protokoll bleibt bis zum Ende der vereinbarten Aufbewahrungsfrist bestehen, auch wenn das zugehörige Konto deaktiviert wird. Wir deaktivieren Konten, statt sie zu löschen, damit vergangene Einträge zuordenbar bleiben. Nach Fristablauf werden Protokolleinträge automatisiert entfernt.
Ja. Die Prozessaufnahme führen wir grundsätzlich vor Ort durch, weil sich Abläufe in sensiblen Bereichen schlecht am Telefon erklären lassen. Die Strecke von rund 13 km ist gut zu bewältigen, je nach Verkehrslage planen wir den Termin morgens oder am frühen Nachmittag. Laufende Abstimmungen während der Entwicklung erfolgen meist remote.
Lass uns über dein Projekt sprechen
Kostenloses Erstgespräch & IT-Bestandsaufnahme – unverbindlich und ohne versteckte Kosten.