[Kommentierung 1.5.3] A_19356-07 - Prüfen der Version des Empfängers

[dhufnagel]

“Ist das LDAP-Directory Attribut komLeData für den Empfänger undefiniert, dann muss ein 136 KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden” - wurde ersatzlos gestrichen. Was passiert wenn weder komLeData noch kimData vorhanden ist?

[hank011]

Weiterführende Frage zu dieser AFO:
Wie ist mit dem Caching umzugehen?
in der Vorveröffentlichung zum Opt-In für große Mails gab es den Absatz zum Caching. In der Veröffentlichung selbst war er dann wieder weg. Nun ist er wieder enthalten (aber nicht als Änderung markiert).

konkretes Beispiel:

• Sender möchte Mail senden, hat für Empfänger 1.5+ im Cache
• zwischenzeitlich hat der Empfänger sein OptIn für große Mails zurückgezogen - im VZD steht damit 1.5 (ohne +)

Soll diese Mail versendet werden (da Cache genutzt) oder darf die Mail nicht versendet werden, da immer im VZD die Version geprüft werden muss für große Mails?

[CLAM01]

Meiner Meinung nach ist das Cachen der KOM-LE Version überflüssig.
Gemäß A_19356-06 (1.5.3 = 07) MUSS das Clientmdoul die Version des Empfängers immer prüfen und abfragen. Somit würde der Cache nie zum Tragen kommen.

Natürlich gibt es auf der Seite des Empfängers auch noch einen Mechanismus der unterbindet, dass das Empfänger CM die Nachricht vom KAS läd wenn nicht dafür frei gegeben und den Empfänger entsprechend informiert.
A_23512 - Auswertung der KOM-LE-Version bei Nachrichten mit KAS-Content

[CLAM01]

“Ist das LDAP-Directory Attribut komLeData für den Empfänger undefiniert, dann muss ein 136 KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden” - wurde ersatzlos gestrichen. Was passiert wenn weder komLeData noch kimData vorhanden ist?

Gute Frage. Ich hätte jetzt fast gesagt, dann ist der Empfänger nicht valide, denn er unterstützt laut VZD weder KIM1.0 noch KIM1.5 noch 1.5+ und müsste eigentlich aus dem Empfängerkreis ausgeschlossen werden.

[dhufnagel]

@CLAM01 das würde für alle Empfänger mit Kim 1.0 Clientmodul gelten und ein Kim 1.5 Clientmodul unbrauchbar machen. Daher sollte aus meiner Sicht die AFO wieder wie vorher lauten und ein nicht vorhandenes komLeData Attribut als Kim 1.0 werten.

[gem-cp]

Vorschlag:
Ab KIM 1.5.3: VZD sorgt dafür dass kimData und komLeData immer vorhanden sind.
Zumindest kimData muss immer vorhanden sein, da das CM ab KIM 1.5.3 kimData als Suchparameter für die VZD-Abfrage verwenden muss. Das ist rforderlich, damit für die Krankenkassen mehrere KIM-Adressen unterstützt werden können ohne die eAU Anwendung zu beeinflussen. Die Kassen brauchen mehrere KIM-Adressen für die Einführung weiterer KIM-Anwendungen.

[dhufnagel]

Wenn der VZD nicht automatisch das kimData Attribut verwaltet oder es HotFixes für alte KIM Fachdienstversionen gibt, wird das kimData Attribut nicht funktionieren. Denn ein KIM 1.5.2 Fachdienst muss das kimData Attribut nicht anpassen und somit wird es nicht gepflegt, auch wenn es einmalig automatisch angelegt wird. Siehe #26

Was war der Hintergedanke beim Streichen des Satzes in der AFO? Die Annahme, dass ein Empfänger nur KIM 1.0 unterstützt ist bei fehlendem komLeData Attribut doch naheliegend?

[gem-cp]

Zu "Was war der Hintergedanke beim Streichen des Satzes in der AFO? Die Annahme, dass ein Empfänger nur KIM 1.0 unterstützt ist bei fehlendem komLeData Attribut doch naheliegend?"

Als komLeData in das Datenmodell des VZD aufgenommen wurde, wurde vom VZD für alle Einträge mit Mail-Adressen auch komLeData angelegt. Daher sind wir davon ausgegangen, dass komLeData mittlerweile immer vorhanden ist und der Satz konnte aus unserer Sicht gestrichen werden.
Es hat sich jedoch gezeigt, dass es wieder Einträge mit mail Adresse aber ohne komLeData gibt, da der VZD komLeData nur einmalig angelegt hat und nicht bei Änderungen an den Einträgen.

[Amarteau]

Aber wäre dann nicht der richtige Weg der, die VZD Spezifikation so zu erweitern, dass der VZD beim Aufruf der Administrationsschnittstelle das komLeData Attribut korrekt befüllt?
Im VZD könnte das zentral an einer Stelle umgesetzt werden, auch in Hinblick auf das kommende kimData Attribut.

[dhufnagel]

Das Clientmodul muss in Kim 1.5.2 schon jetzt diese fallback Logik unterstützen. Daher sehe ich die Notwendigkeit diese in Kim 1.5.3 zu entfernen als wenig hilfreich, wenn dadurch weitere Probleme auftreten.

[stophane]

Hallo zusammen,

Stichwort: Abwärtskompatibilität

Der Teil für undefiniert und fallback auf KOM-LE-Version 1.0, darf nicht gestrichen werden.

• VZD hat gegenüber KIM kein idempotentes Verhalten. Jederzeit können sich Daten verändern, fehlen etc.
• Es werden KIM 1.5 CM´s ausgerollt, welche sich bei der Verarbeitung, gemäß bisheriger Spezifikation, auf komLeData beziehen.
  • Im dezentralen Bereich können CM´s nicht global, sofort ausgetauscht werden (Nutzer führen Updates oft nicht durch)
  • komLeData MUSS weiterhin zu jeder KIM-Adresse, egal ob mail und oder kimData existieren, sonst würde dies im Kontext des bisherigen Fallbacks auf KOM-LE-Version=1.0 dazu führen, dass in bestehenden KIM 1.5 Clientmodulen im Feld, die sich auf KOM-LE-Version 1.5(+) beziehenden Feature nicht mehr nutzbar wären.

Viele Grüße

[gem-cp]

OK. Die Streichung des Satzes wird nicht erfolgen. Dennoch wird der VZD sicherstellen, dass für KIM 1.5.3 komLeData und kimData immer vorhanden sind (in PU voraussichtlich ab Q4 2023).

[dhufnagel]

Also managed der VZD das kimData Attribut? Oder wie soll das nach einer einmaligen Migration sichergestellt werden, wenn danach komLeData durch ein Kim 1.5.2 CM/FD geändert wird. Auf diesen Hinweis/diese Frage wird wiederholt nicht eingegangen.

[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.