Eine Änderung zählt erst, wenn sie gesichert ist

RegMon prüft täglich die regulatorischen Quellen der deutschen Gesundheits-IT auf Änderungen. Im September haben wir die Frage gestellt, was ein solches System einem auditpflichtigen Kunden zusagen kann — und den eigenen Erfassungsweg zuerst so geprüft, wie es ein Auditor tun würde. Das Ergebnis ist eine Zusage, die sich nachrechnen lässt, und eine Produktversion, die sie einlöst. Dieser Beitrag beschreibt den Weg dorthin, einschließlich dessen, was die Prüfung gefunden hat.

Zuerst die Prüfung

Bevor man eine Zusage gibt, prüft man, ob man sie halten kann. Wir haben deshalb im September den gesamten Erfassungsweg von RegMon so durchgesehen, wie es ein Auditor tun würde: Quelle für Quelle, vom Abruf über die Änderungserkennung bis zur Aufzeichnung im Hauptbuch, mit dem Audit-Trail unserer Referenzinstanz seit Juni als Beleg.

Bei allen übrigen Quellen führte dieser Weg durch — rund 2.100 Ereignisse im Hauptbuch der Referenzinstanz belegen das. Bei einer fehlte ein Schritt: dem Plugin für die zwölf Webbereiche der KBV (Pressemitteilungen, Abrechnung, Agenda, Stellungnahmen, Bekanntmachungen, Bundesmantelvertrag, Beschlüsse, Unfallversicherungsträger und weitere Kostenträger, weitere Rechtsquellen, Publikationen, Videos, Studien und Berichte). Es erkannte Änderungen zuverlässig und meldete sie dem Scheduler. Die Datei, aus der der Aggregator das Hauptbuch füllt, schrieb es im automatischen Betrieb aber nicht, und der gespeicherte Zustand wurde trotzdem fortgeschrieben. Für diese eine Quelle blieb das Hauptbuch seit dem 25. März ohne Einträge, während der Audit-Trail korrekt festhielt, dass das Plugin gelaufen war und Änderungen gefunden hatte.

Was uns daran beschäftigt hat, ist weniger der Fehler als seine Form. Jeder Eintrag im Audit-Trail war wahr, und genau deshalb fiel nichts auf: Ein Nachweis beweist, was er protokolliert — und er protokollierte den Abruf, nicht die Ankunft. Es ist dieselbe Lücke, die wir im August bei Xommodo beschrieben haben, von der anderen Seite gesehen.

Die Durchsicht fand außerdem vier Stellen, an denen ein Ausfall still geblieben wäre. Für keine davon fand sie einen eingetretenen Fall; alle vier sind mit derselben Version geschlossen:

• Ein Abruffehler hätte wie ein ruhiger Tag ausgesehen. Mehrere Plugins gaben bei einem HTTP-Fehler eine leere Liste zurück — im Audit-Trail nicht zu unterscheiden von „keine Änderung".
• Der Zustand wurde vor dem Delta gesichert. Ein Absturz genau dazwischen hätte eine Änderung dauerhaft als gesehen markiert.
• Der Aggregator archivierte, bevor er sicherte. Ein Fehler mitten im Lauf hätte Dateien verschoben, deren Ereignisse noch nicht im Hauptbuch standen.
• Ein verpasster Lauf hätte keine Spur hinterlassen. Nichts prüfte, wann eine Quelle zuletzt erfolgreich gelesen worden war.

Die Testsuite hatte jeden dieser Schritte für sich geprüft, und jeder bestand. Was fehlte, war die Prüfung des ganzen Wegs von der Quelle bis ins Hauptbuch — die Perspektive, die ein Auditor einnimmt und die ein System über sich selbst einnehmen muss. Genau diese Perspektive ist seit September in RegMon eingebaut.

Was ein Monitoring-System zusagen kann

Die wörtliche Zusage — „wir erfassen jede relevante Änderung" — kann niemand halten, der die Quellen nicht kontrolliert. Eine Behörde baut ihre Seite um, und der beste Parser liest ins Leere.

Ein Auditor verlangt das auch nicht. ISO 13485 und die MDR verpflichten den Hersteller, regulatorische Anforderungen zu ermitteln und aktuell zu halten; ISO 27001 kennt dieselbe Pflicht für rechtliche und vertragliche Anforderungen; die GxP-Datenintegrität fordert mit ALCOA+ die Vollständigkeit der Aufzeichnung. Gemeinsam ist ihnen der Maßstab: ein beherrschter Prozess. Definierter Umfang, definiertes Verfahren, definierte Frequenz, eine Aufzeichnung jeder Durchführung, Abweichungen erkannt und behandelt.

Daraus folgt die Zusage, auf die RegMon gebaut wird:

Für jede Quelle im vereinbarten Quellenregister und für jeden vereinbarten Erfassungszeitpunkt liegt genau eine Aufzeichnung vor. Entweder wurde der veröffentlichte Bestand erhoben und jede Abweichung zum vorherigen Bestand als Ereignis dauerhaft gesichert — oder die Abweichung ist mit Ursache aufgezeichnet, dem Kunden sichtbar und durch eine dokumentierte Nachholung geschlossen.

Zwei Trennungen machen sie tragfähig. Erfassen ist nicht Einstufen: Garantiert wird, dass jede Änderung an einer Registerquelle ankommt. Ob sie relevant ist, entscheidet weiterhin ein Mensch, und diese Entscheidung ist auditiert — ein Sprachmodell bereitet vor, es entscheidet nicht. Vollständigkeit wird bewiesen, nicht behauptet: Jede Aussage im Nachweis leitet sich aus Aufzeichnungen ab, die der Auditor selbst nachrechnen kann.

Was sich geändert hat

Die erste Stufe dieser Zusage ist seit dem 15. September mit Version 2.2.0 umgesetzt und läuft auf der Referenzinstanz. Sie sichert den Weg von der Erkennung bis ins Hauptbuch:

• Delta vor Zustand, in jedem Plugin. Erst wird die Änderung dauerhaft geschrieben, dann der Zustand fortgeschrieben — atomar, damit auch ein Absturz dazwischen nichts verliert. Eine Änderung gilt nie als gesehen, bevor sie gesichert ist.
• Ein Fehler ist ein Fehler. Fällt eine von zwölf Seiten aus, behält das Plugin die elf gelungenen, trägt den alten Zustand der zwölften weiter und beendet den Lauf als Teilausfall — im Audit-Trail ok: false mit Seitenliste. Eine Seite, die mit HTTP 200 und null Einträgen antwortet, obwohl der Zustand die Kategorie kennt, gilt als Selektor-Drift, nicht als „alles entfernt".
• Ein Sicherheitsnetz im Scheduler. Liefert ein Plugin Ereignisse, ohne dass eine Delta-Datei entsteht, schreibt der Scheduler sie selbst und vermerkt das im Audit-Eintrag. Kein Plugin, auch kein künftiges, kann Ereignisse noch still verlieren.
• Hauptbuch vor Archiv. Der Aggregator sichert nach jeder Delta-Datei und archiviert erst danach. Ungültige Dateien blockieren den Lauf nicht und gehen nicht verloren: Sie wandern in eine Quarantäne, und der Lauf endet mit einem sichtbaren Fehler.
• Verpasste Läufe hinterlassen Spuren und werden nachgeholt. Ein Lauf-Register hält je Quelle den letzten Versuch und den letzten Erfolg; ein verschlafener Zeitpunkt wird innerhalb einer Kulanzzeit nachgeholt, und nach einem Neustart laufen alle Quellen ohne Erfolg in den letzten 26 Stunden einmal nach.
• Der Selbsttest prüft die Frische. Jede registrierte Quelle braucht einen erfolgreichen Lauf innerhalb von 26 Stunden, sonst meldet sich das System als beeinträchtigt und nennt die Quelle mit letztem Status und Fehler.
• Die Audit-Kette läuft über Tagesgrenzen. Bisher begann jede Tagesdatei neu, eine gelöschte Tagesdatei war unsichtbar. Jetzt trägt der erste Eintrag eines Tages den Hash des letzten Eintrags vom Vortag, und die Prüfung meldet eine fehlende oder nachträglich veränderte Vortagsdatei als Bruch.

Für die zwölf KBV-Webbereiche holt der erste Lauf nach dem Update den vollständigen aktuellen Bestand einmal nach, als Basislinie gekennzeichnet — damit steht alles, was die KBV dort heute veröffentlicht, im Hauptbuch. Was zwischen März und September erschienen und wieder zurückgezogen wurde, kann kein Nachzug erfassen; das steht so im Release-Hinweis. Der Bestand ist vollständig, die Grenze ist benannt.

Was daraus für Prüfsysteme folgt

• Prüfen Sie den ganzen Weg bis ins Hauptbuch. Ein Audit-Trail bezeugt genau das, was er protokolliert; wer die Ankunft protokolliert, hat sie bewiesen. Ein Test, der eine Änderung an der Quelle stellt und im Hauptbuch nachsieht, findet eine solche Lücke am ersten Tag.
• Jeder Ausfall bekommt ein eigenes Wort. „Keine Änderung" und „konnte nicht lesen" sehen im Protokoll verschieden aus — so bleibt ein Ausfall von einem ruhigen Tag unterscheidbar und lässt sich melden.
• Frische ist eine Prüfgröße. „Letzter Erfolg je Quelle" ist die einzige Zahl, die einen still ausgefallenen Lauf sichtbar macht. Sie gehört in jeden Selbsttest.
• Erst sichern, dann fortschreiten. Wer das Ergebnis dauerhaft schreibt, bevor er den Zustand fortschreibt, hat nach jedem Abbruch genau zwei Fälle: Die Änderung ist gesichert, oder sie wird beim nächsten Lauf erneut erkannt: Die Reihenfolge entscheidet!

Grenzen

Diese Stufe sichert den Weg von der Erkennung bis ins Hauptbuch. Die Erkennung selbst arbeitet heute über Titel, Datum und Dateigröße; der Inhaltsvergleich, der auch eine unter gleicher Adresse ersetzte PDF als Änderung erkennt, ist die nächste Stufe. Rohantworten werden noch nicht als Snapshot aufbewahrt, und die Hash-Kette bleibt ohne externen Anker gegenüber dem Neuschreiben aller Dateien blind. Das sind die nächsten Stufen: ein vertraglich fixiertes Quellenregister, eine Bestandserfassung mit Inhaltshash, ein Abdeckungsbuch, das auch einen nicht stattgefundenen Lauf bezeugt, und ein monatlich signierter Erfassungsbericht.

Die Reihenfolge ist bewusst gewählt: Erst muss ankommen, was erkannt wird. Dann lohnt es sich, mehr zu erkennen.

Zur RegMon-Produktseite →

Die vollständigen Release-Notes ab Version 2.2.0 stehen öffentlich auf GitHub.