[Kommentierung 1.5.3] kimData Attribut

[dhufnagel]

Das kimData Attribut enthält redundant zum komLeData die KIM-Version. Redundanz erzeugt Fehler, weil beide Attribute immer synchron angepasst werden müssen. Warum wird die Version noch einmal in kimData gespiegelt?

Das Attribut ist als optional gekennzeichnet, viele AFO referenzieren aber jetzt statt komLeData kimData. Das kann so nicht funktionieren, da kimData für “alte” Datensätze nicht existiert, bzw. durch die Optionalität nicht existieren muss.

[gem-cp]

Die Reihenfolge in der Speicherung der Daten (KIM Version, KIM-Adresse) musste geändert, um zukünftig (wenn die Krankenkassen mehrere KIM Adressen bekommen) performante Suchen nach der KIM-Adresse im VZD zu ermöglichen. Wir wissen, dass bereits einige Primärsysteme komLeData anstatt des mail Attributs verwenden. Um die Kompatibilität nicht zu gefährden, haben wir uns entschieden, das neue Attribut kimData einzuführen. Das Attribut komLeData ist damit deprecated und wird entfernt, wenn alle KIM CM und KIM Clients es nicht mehr verwenden.
Das Attribut ist optional aus Sicht des Datenmodells des VZD. Ab KIM 1.5.3 wird durch KIM Clientmodule kimData verwendet um anhand der KIM-Adresse die zugehörigen Verschlüsselungszertifikate zu finden.
Die gematik wird Arvato beauftragen das kimData Attribut zu implementieren und mit den komLeData Inhalten oder, falls diese nicht existieren, mit dem Inhalt des Attributs mail zu befüllen. Dadurch wird gewährleistet, dass kimData immer existiert.

[dhufnagel]

Dann sollte das kimData Attribut aus meiner Sicht jedoch nicht als "optional" für KIM 1.5.3 gekennzeichnet sein, denn sonst funktionieren die Referenzen der AFOs nicht. Was ist, nach der Übernahme der Arvato mit kimData, wenn ein Fachdienst oder CM noch KIM 1.5 und nicht KIM 1.5.3 zum ändern der Daten nutzt? Hier müsste eine Synchronisierung aller Fachdienste und des VZD Changes und aller CM stattfinden, was schier unmöglich ist.

[stophane]

Ergänzender Verweis: #27

[gem-cp]

OK; wird geprüft, ob kimData und komLeData Pflichtparameter werden.

[gem-cp]

kimData und komLeData werden Pflicht-Attribute im VZD

[dhufnagel]

Mit Verweis auf #30 #30 (comment)
erneut die Frage:
Wenn in Q4 das kimData Attribut vom VZD hinzugefügt wird und mit dem komLeData Daten vorbefüllt wird, wird es kaum ein CM/FD geben, welches Kim 1.5.3 zugelassen ist. Wie wird verhindert, dass komLeData (welches von 1.5.2 FD gepflegt wird) nicht von kimData abweicht? Wird kimData automatisch vom VZD gepflegt? Wird ein nicht vorhandenes komLeData Attribut auch migriert?
Wenn nachträglich ein Update von Kim 1.0 CM auf Kim 1.5.2 stattfindet und ein komLeData Eintrag erzeugt wird, wer legt dann ein kimData Eintrag an?
Wenn ein Kim 1.5.3 CM nur kimData verwenden darf, wie kann es dann mit Kim 1.5.2 Empfänger kommunizieren, wenn diese nur ein komLeData Attribut habe oder ein leeres kimData aufgrund einer nachträglichen Migration von kim 1.0?

[gem-cp]

Der Prozess läuft wie folgt.
Das CM sendet Accountdaten (Mail Adresse, KIM-Version des CM für diese Mail-Adresse und appTags) an den Accountmanager. Der AccountManager sendet die Daten an den VZD. Der VZD ändert den Eintrag des Nutzers in den KIM Fachdaten (Attribute mail, komLeData und kimData, Primärschlüssel ist die telematikID) und generiert die flache Liste für den Eintrag.

Wie wird verhindert, dass komLeData (welches von 1.5.2 FD gepflegt wird) nicht von kimData abweicht?"
Der VZD stellt das sicher.

Wird kimData automatisch vom VZD gepflegt?
ja.

Wird ein nicht vorhandenes komLeData Attribut auch migriert?_
ja.

Wenn nachträglich ein Update von Kim 1.0 CM auf Kim 1.5.2 stattfindet und ein komLeData Eintrag erzeugt wird, wer legt dann ein kimData Eintrag an?
der VZD