Volumenschätzug
im Folgenden sind Ergebnisse aus einer Simulation mit künstlich generierten Daten dargestellt
ermittelter Platzbedarf für eine .xml Datei mit 1.000 Patienten: 18 MB
das gilt für bei Verzicht auf Formatierung, “pretty formatting” verdoppelt etwa die Dateigrösse (wird natürlich nicht verwendet für Lieferung)
Packen als .zip: → 1,5 MB
die Dateigrösse korreliert relativ gut mit der Patientenanzahl, Hochrechnungen wären also grundsätzlich denkbar
getroffene Annahmen / Merkmale der Datei
.xml ist valide gegen oBDS-RKI
2 Tumore pro Patient
alle optionalen Elemente sind gesetzt
Freitexte auf 10 Zeichen Länge gesetzt als angenommener Durchschnittswert
Klassifikationen sind “echte” Ausprägungen gemäß den jeweiligen Wertebereichen
alle in “Menge_” gekapselten Elemente (OP, ST, Folgeereignis etc) sind in zufälliger Anzahl zwischen 1 und 3 erzeugt
Schlussfolgerung: auf Basis der Annahmen dieser Simulation erscheint eine Stückelung auf 10.000 Patienten pro Datei machbar
Vorschlag Lieferprozess
Setup Verschlüsselung
RKI generiert neues Schlüsselpaar für asymmetrische Verschlüsselung gemäß anwendbaren Regularien (RKI verwendet bislang 2048 bit RSA key im pgp Verfahren für die epi-Daten)
öffentlicher Teil des Schlüssels wird den Lieferregistern bekannt gegeben
Lieferung - Register
die Lieferung erfolgt jährlich
Register generiert n Dateien mit Daten im Lieferschema gemäß Stückelung
es werden alle Daten erfasst (“Volllieferung”)
diese Daten werden pro Datei
mit dem öffentlichen Schlüssel für Lieferung ans RKI behandelt
als payload in eine Datei eingebettet gemäß Schema KKRTransport
basierend auf der dann aktuellen Definition KKRTransport (derzeit v2.0.0)?
RKI benötigte dann Institutskennzeichen
receiver_ik? Alternativ kann das Feld leer bleiben?Signaturbildung der KR: im ersten Schritt nicht vorgesehen, aber mglw. erforderlich aufgrund Sicherheitsüberlegungen
PGP-Verschlüsselung ist vorerst gesetzt, RÜD-REST wird nicht angewendet
Sendung EPI vs. klinisch: vorgesehen ist die gemischte / integrierte Übermittlung. Für eine reine epi Übermittlung könnten bestehende Wege genutzt werden
alle Dateien werden dann in einen (bzw. einige) zip Ordner organisiert
dieser Ordner wird per cryptshare (https://austausch.rki.de) an ein Funktionspostfach im ZfKD gesendet
Empfang - RKI
das verwendete cryptshare Passwort wird dem RKI bekannt gemacht
RKI lädt Datein von cryptshare und entpackt .zip in einen dedizierten Ordner
ein dafür implementiertes import tool
erfasst alle Dateien in diesem Ordner
entschlüsselt mittels private key
validiert jede einzelne xml und protokolliert das Ergebnis
überführt den xml Inhalt in ein zum vereinbarten Schema passendes relationales Modell
Prüfung - RKI
da in der fallbasierten Übermittlung die Bewertung einzelner Meldungen in den Hintergrund tritt, werden gelieferte Dateien auch angenommen, wenn in der Schemavaliderung Fehler auftreten wie z.B.
Pflichtfelder nicht angegeben
pattern für Werteausprägungen nicht eingehalten
in bestimmten Fällen könnte der import nicht durchgeführt werden, und die Lieferung müsste zurückgewiesen werden, wenn
xml Strukturen vom Schema abweichen, so dass die eindeutige Erfassung und Speicherung fehlschlägt
ID nicht eindeutig vergeben sind oder fehlen
RKI prüft dann die Plausibilität der Datenlieferungen analog dem für die epi Daten etablierten Verfahren
voraussichtlich wird es weiterhin Korrekturalgorithmen für die Dateninhalte geben (müssen), deren Anwendung vom RKI transparent dargestellt werden können
ähnlich dem kürzlich eingeführten System für die epi Daten sollen Rückmeldungen an die Register erfolgen
Korrekturen erfolgen nach Absprache als Austausch der kompletten Lieferung (keine inkrementellen Updates)