gematik
[Kommentierung 1.5.3] kimData.appTags
Es existiert keine formale Beschreibung von AppTags. Wie muss das “Format” aussehen? Die Beispiele sind widersprüchlich.
kimData: [email protected],1.0,DALE-UV;Einsendung;V1.0|eEB;V1.0
Gemäß Beschreibung wäre also DALE-UV;Einsendung;V1.0 ein einzelnes AppTag. Wie soll das geparst werden? Dort wäre die Version an 3. Stelle getrennt mit Semikolon, bei eEB;V1.0 ist die Version an 2. Stelle. Hier sollte eine einheitliche formale Definition der AppTags erfolgen, da sonst jeder AppTag selbst unterschiedlich geparst werden muss, was ein schlechter Weg wäre.
Ohne formale Definition kann auch keine Validierung geschehen und bei den REST Aufrufen ungültige bzw. destruktive AppTags gesendet werden (z.B. Komma innerhalb des Tags).
Die appTags werden von der jeweiligen KIM Anwendung festgelegt. In der Spezifikation der Anwendung wird auch beschrieben, wie die appTags der jeweiligen Anwendung zu interpretieren und zu verwenden sind. Ein Primärsystem, dass die KIM Anwendung implementiert muss sich an die Spezifikation der Anwendung halten. Das KIM Clientmodul muss sicherstellen, dass nur korrekte appTags verwendet werden. Dies kann anhand des FHIR Codesystems geprüft und bereits bei der Eingabe sichergestellt werden.
Hallo zusammen,
Ergänzende Hinweise im Kontext der nachfolgenden Spec: A_23819 - VZD, I_Directory_Application_Maintenance, Behandlung komLeData & kimData REST Tabelle 15: Tab_VZD_Datenbeschreibung
Delimiter in kimData beachten/überdenken
- "|" (pipe) ggf. ungeeignet, da Filtersyntax LDAP
- "," (Komma) ggf. ungeeignet, da potenziell Inhalt appTag/Anwendungskennzeichen (extern definiert)
- die kann jedoch in der Betrachtung von kimData als array aus Element semantisch fester Position vernachlässigt werden [<[0]kim-address>,<[1]komle-version>,<[2 (0..n)]appTagg/Anwendungskennzeichen>]
"|" (pipe) als Delimiter im VZD ist nicht problematisch, da die Suche-Parameter vom PS in der Regel Name und postalische Adressdaten sind. Wenn nach einem appTag gesucht wird, dann ist das trotz Pipe Delimiter möglich (kimData: <appTag>).
Wenn man in kimData nach appTags sucht, muss in der ldapsuche der pipe delimiter Gründer appTags escaped werden, damit er nicht als ldap delimiter erkannt wird. Technisch ist das nicht problematisch, aber verwirrend und kann zu Fehlern bei den PS führen, wenn nicht korrekt das escaping eingesetzt wird.