Open dhufnagel opened 1 year ago
Wenn wir die Daten (professionOID, specialization, postalCode) nachträglich aus dem VZD abfragen würden, dann müssten die KIM Adressen im Klartext reportet werden. Es sollen aber keine personenbezogenen Profile gebildet werden. Allerdings gelten nach EU Recht auch pseudonymisierte Daten als personenbezogen. :/ Das CM hat die VZD Daten bereits. Daher wurde kein großer Aufwand im CM gesehen.
Die Erfassung der zusätzlichen Daten wird storniert. Die Erfassung der Daten für die Sicherstellung des KIM-Betriebs soll zukünftig über die KIM Fachdienste erfolgen. Die gematik wird dafür in Abstimmung mit dem Datenschutzbeauftragten eine DSGVO konforme Lösung spezifizieren und vorstellen.
Welchen Zweck verfolgen die X-KIM-XXXData-Header? Warum verkompliziert man den Prozess der KIM-Nachrichten in dieser Art und Weise?
Nur für Monitoring? Ist das verhältnismäßig? Warum sucht man diese Informationen im Monitoring nicht einfach aus dem VZD anhand FROM, TO und CC Headern? Warum verlagert man den Prozess in das Clientmodul und erhöht dort die Komplexität?
Aus persönlicher Sicht gehört das ins Monitoring-Tool, wo man genau 1 System anpassen muss und nicht 7+ Clientmodule auf zig-hundertausenden Installationen.