Integration der 'KIM-Encounter-Id' in KIM-Spezifikation

[SvenSommer]

Änderungsdetails:

• Einführung eines neuen Header-Elements: 'X-KIM-Encounter-Id'.
• Zweck: Eindeutige Identifikation und Nachverfolgung von Nachrichten innerhalb eines Behandlungsfalls (Encounter).
• Spezifikation: Die 'X-KIM-Encounter-Id' soll eine UUID enthalten, die über den gesamten Nachrichtenverlauf eines Behandlungsfalls konstant bleibt.
• Implementierung: Bei Antworten muss das Empfängersystem die 'X-KIM-Encounter-Id' der ursprünglichen Nachricht übernehmen.
• FHIR-Kompatibilität: Bei Vorhandensein einer Encounter-FHIR-Ressource im Nachrichten-Body muss der Encounter.identifier mit der 'X-KIM-Encounter-Id' übereinstimmen.

Ziel der Änderung:

Verbesserung der Nachverfolgbarkeit und konsistenten Zuordnung von Nachrichten zu spezifischen Behandlungsfällen.

[Amarteau]

KOM-LE-A_2098-03 - Header der äußeren Nachricht schreibt vor:

Ein Headerelement der inneren Nachricht beginnend mit dem Bezeichner X-KIM- MUSS in den äußeren Header
übernommen werden.

Somit wäre der Header X-KIM-Encounter-Id nicht nur Teil der verschlüsselten, inneren KIM-Nachricht sondern auch Teil der äußeren Nachricht. Ist es wirklich notwendig Informationen mit konkretem Patientenbezug unverschlüsselt in der äußeren Nachricht zu transportieren?

[dhufnagel]

@Amarteau hat einen validen Punkt. Ggf. wäre ein Header Name, der mit einem anderen Präfix beginnt für solche Zwecke sinnvoller. Andererseits gibt es für „Konversation“ ja schon die messageId und den In-Reply-To Header. Den Verlauf müsste dann aber natürlich das PVS zu einem Behandlungsfall mappen.

[dhufnagel]

Scahde dass es kein Feedback zum Feedback gibt.. warum kommentiert man hier eigentlich?! 🤷‍♂️

[Amarteau]

In f64c580da1d1a3157222ee6fd4b435da29ed4681 im develop wurde der Header nun umbenannt. Somit wird er nicht mehr in die äußere Nachricht übernommen.

[SvenSommer]

Vielen Dank an @dhufnagel und @Amarteau für die konstruktiven Beiträge,

[SvenSommer]

Die Zusammenfassung der in der heutigen E-Rezept Sprechstunde diskutierten Bedenken und Unterstützungen bezüglich des vorgeschlagenen 'KIM-Encounter-Id' Headers sieht folgendermaßen aus:

Bedenken:

• Kompatibilität mit dem MIME-Standard: Die Einführung des 'KIM-Encounter-Id' Headers weicht von dem für KIM-Nachrichten genutzten MIME-Standard ab. In MIME-konformen Systemen wird der Nachrichtenverlauf üblicherweise über 'Reply-To' und 'In-Reply-To' Header gesteuert. Diese etablierten Mechanismen sind entscheidend für die effiziente Kommunikation und werden bereits von Primärsystemen verwendet. Die Einführung eines neuen Headers könnte zu Kompatibilitätsproblemen mit existierenden Systemen führen, insbesondere wenn diese auf MIME-Standards basieren.

• Auswirkungen auf Standardtools wie Thunderbird: Die Einführung des 'KIM-Encounter-Id' Headers könnte bedeuten, dass Thunderbird und ähnliche Tools nicht mehr ohne zusätzliche Konfiguration oder manuelles Eingreifen der Apotheker genutzt werden könnten. Dies stellt eine erhebliche Hürde dar, besonders für Benutzer, die auf eine einfache und direkte Nutzung dieser Tools angewiesen sind.

Unterstützung:

• Begrenzungen der Standardsoftware und Bedarf an integrierten Lösungen: Es wurde argumentiert, dass Standardsoftware wie Thunderbird möglicherweise nicht mehr ausreichend sein wird, um die Herausforderungen eines modernen Warenwirtschaftssystems zu bewältigen. Die Einführung des 'KIM-Encounter-Id' Headers könnte die Notwendigkeit reflektieren, vermehrt auf integrierte Lösungen zu setzen, die speziell auf die komplexen Anforderungen und Prozesse in Warenwirtschaftssystemen zugeschnitten sind. Diese integrierten Lösungen könnten eine effizientere und effektivere Verwaltung ermöglichen, indem sie spezifische Funktionen bieten, die über die Kapazitäten der Standardsoftware hinausgehen.

Nach meiner aktuellen Einschätzung überwiegen die Bedenken bezüglich der Implementierung eines neuen Attributs für die Darstellung von Nachrichtenverläufen, da die erforderlichen Funktionen bereits in den vorhandenen Standards abgedeckt sind.

Welchen klaren Vorteil bietet die 'KIM-Encounter-Id' gegenüber einem Identifikator im 'Reply-To'?

[dhufnagel]

Genau das ist meine Kritik hierbei: vorschnelles mergen ohne die Diskussionen zu beachten und darauf einzugehen. Die Bedenken sind absolut nachvollziehbar und ein extra Header für bereits vorhandene Header ist unnötig. Schaut man mal rechts und links, gibt es schon seit Jahrzehnten Mailing-Listen, die eben genau jenes Feature nutzen und in den letzten Jahren hat es die Conversation Ansicht auch in Enduser Anwendungen wie Outlook und Thunderbird geschafft. Dabei wird übrigens nicht nur In-Reply-To verwendet, sondern auch „References“, was 1:1 dem Zweck des neuen Headers entsprechen würde. https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4

[SvenSommer]

Nach eingehender Betrachtung der Diskussionen und Bedenken, die im Kontext des vorgeschlagenen 'KIM-Encounter-Id' Headers aufgekommen sind, möchte ich auf einen neuen Pull Request verweisen, der eine alternative Lösung präsentiert. Dieser neue PR Pull Request #72 adressiert die hervorgebrachten Bedenken bezüglich der Kompatibilität mit dem MIME-Standard und den potenziellen Auswirkungen auf etablierte Tools wie Thunderbird.

In Übereinstimmung mit den Anmerkungen von @dhufnagel und anderen Beitragenden haben wir uns entschieden, statt eines neuen, spezifischen Headers die etablierten MIME-Header 'Reply-To', 'In-Reply-To' und 'References' zu nutzen. Diese Anpassung entspricht den gängigen Kommunikationsstandards, wie in RFC 822 beschrieben, und gewährleistet eine effiziente Nachrichtenverfolgung in bestehenden Systemen, ohne zusätzliche Komplexität oder Kompatibilitätsprobleme zu verursachen.

Der neue PR schlägt eine strukturierte Nutzung dieser Header für die Organisation von Nachrichten in Konversationsverläufen vor. Diese Methode ist nicht nur MIME-konform, sondern auch besser geeignet, um die Bedürfnisse der Nutzer zu erfüllen, die auf eine reibungslose Integration in Standard-E-Mail-Clients angewiesen sind. Wir glauben, dass dieser Ansatz eine ausgewogene und praktikable Lösung darstellt, die sowohl die technischen als auch die benutzerorientierten Aspekte berücksichtigt.

Ich lade alle Beteiligten ein, den neuen Pull Request Pull Request #72 zu überprüfen und Feedback zu geben. Dieser Vorschlag soll die Diskussionen und Bedenken, die bisher geäußert wurden, aufgreifen und eine zufriedenstellende Lösung für alle Beteiligten bieten.