• In Bearbeitung

    • Vorschlag Technischer Ablauf Lieferung klinischer Daten zum RKI

    Owned by MeisegeierS (Unlicensed)
    Last updated: 26. Sept. 2023
    3 min read

    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 (DRAFT)

    Setup Verschlüsselung

    Details Schlüsselmaterial

    • RKI generiert neues Schlüsselmaterial für asymmetrische Verschlüsselung mit folgenden Eigenschaften:

      • Bitlänge: 4096

      • Signaturalgorithmus: sha256RSA

      • Ausgestellt durch: anfangs selbst-signiert, ab Folgejahr durch PKI CA am RKI

      • Gültigkeitsdauer: bei selbst-signiertem Schlüssel 1y, danach 2y (ggf. Verlängerung mit privatem Schlüssel)

      • Schlüsselverwendung: Datenverschlüsselung

    • öffentlicher Schlüssel

      • gespeichert im PEM Format

      • wird den definierten Ansprechpersonen der Lieferregistern bekannt gegeben, sobald PKI CA anwendbar ist kann der public key via Webseite bekannt gemacht werden

    • privater Schlüssel

    Details Verschlüsselung

    • verwendeter Algorithmus für die Implementierung ist brainpoolP256r1 (in Anlehnung an RÜD Umsetzungsleitfaden 3.0.0)

    • Format zum Speichern der Bits als String: base64

    • Message Authentication Code (MAC) Algorithmus: HMAC mit SHA256 gem. BSI TR02102

    • Generierung des MAC keys: umgekehrte Bytereihenfolge des symmetrischen Schlüssels

    • Schlüsselableitungsfunktion: HMAC

    • Format zum Speichern des Tripels der ECIES Nachricht: JWT Format (erweitert um Initialisierungsvektor)

    Nutzung des Transportschemas KKRTransport

    • verschlüsselte Daten werden unter data in das Transportschema eingebettet

      • Institutskennzeichen receiver_ik kann nicht vergeben werden, darum Verwendung von dummy Wert 000000000

      • auf Signaturbildung wird verzichtet aufgrund der gewählten Sicherheitsarchitektur. Im Feld signatureAlgorithm kann dann ebenfalls ein dummy Wert verwendet werden, etwa none

      • alle Dateien werden dann in einen (bzw. einige) zip Ordner organisiert

    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

      • verschlüsselt

      • in KKRTransport eingebettet

    • alle Dateien werden dann in einen (bzw. einige) zip Ordner organisiert

    • der Transport der zu liefernden Dateien erfolgt über den sicheren Austauschserver des RKI “cryptshare”

    • es wird ein Muster für ein bundesweit gültiges, jährlich wechselndes Transferpasswort mit den definierten Ansprechpersonen ausgetauscht aufgrund der Ende-zu-Ende-Verschlüsselung der transportierten Daten kann ein einheitliches Transportpasswortes verwendet werden

    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)