search

gematik / api-kim

API specification for gematik's KIM - a secure Email standard, which enables the exchange of information and payload in the German healthcare sector.
Other
33 stars 12 forks source link

[Kommentierung 1.5.3] A_23711 - Clientmodul, gültige Anwendungskennzeichen #49

Open stophane opened 1 year ago

stophane commented 1 year ago

Gemäß dieser Afo muss das Clientmodul die Liste der für den Nutzer wählbaren appTags vom Account Manager abrufen , um diese dem Nutzer zu Auswahl anbieten zu können. Aktuell findet sich unter https://github.com/gematik/api-kim/tree/develop/src/openapi keine unabhängige interface Funktion zum account-unabhängigen Abruf der Liste.

übersehe ich etwas?

Beachte: Die „globale“ Liste der appTags ist unabhängig vom KIM-Account und sollte zwingend nicht Teil spezifischer Account-Informationen sein. Es ist aufgrund der häufig nicht gegebenen Online-Anbindung der Betriebsumgebungen des KIM-Clientmoduls auszuschließen, diese aus dem öffentlichen Internet abzurufen!

In diesem Kontext weiterführend relevant:

37

gem-cp commented 1 year ago

Korrekt. Vorschlag: Die Abfrage der appTags-Liste erfolgt über eine neue GET /appTags Operation in ServiceInformation.yaml Format: wie in Simplifier (json FHIR CodeSystem)

dhufnagel commented 1 year ago

Wie kann das Clientmodul den Nutzer die appTags weitergeben? Gibt es eine Schnittstelle abseits von pop3 und smtp? (Ich habe aktuell keinen Zugriff auf die Spezifikation, daher die Frage)

gem-cp commented 1 year ago

Das CM zeigt dem Nutzer die möglichen appTags im Adminmodul des CM an. Eine separate Schnittstelle des CM zum PS ist nicht vorgesehen. Das CM kann die appTags auch (wie der Accountmanager) aus Simplifier laden.

dhufnagel commented 1 year ago

Inwiefern ist es praktikabel, dass der Endanwender im Adminmodul des CM die appTags ausliest? Ist simplifier (kommerzielle Plattform) wirklich der geeignete Ort für die dauerhafte Ablage von Metadaten? Sollte die gematik nicht einen eigenen Dienst dafür bereitstellen? (Geht in diesem issue vlt zu weit, aber allgemein sehe ich es kritisch sich als gematik in die Abhängigkeit einer kommerziellen Plattform zu begeben). Eine registry bei der gematik bei der apptags registriert und abgefragt werden könnten wäre aus meiner Sicht zu bevorzugen. Damit besteht keine Notwendigkeit, dass das clientmodul die apptags in irgendeiner Weise bereitstellen oder auswerten muss.