Merge branch 'tim-epa-fdv' into johannes/generate-images

README.adoc

@@ -95,6 +95,7 @@ TI-Messenger Dokumentation
 |   ├──── link:docs/IDP[IDP]
 |   ├──── link:docs/Primaersystem[Primaersystem]
 |   ├──── link:docs/anwendungsfaelle[Anwendungsfälle]
+|   ├──── link:docs/Test/Test.adoc[Testkonzept]
 |   └──── link:docs/FAQ[FAQ]
 ├─ link:images[images] (Bildarchiv)
 │   └──── link:images/drawio[drawio] (gerenderte draw.io Diagramme)

docs/Test/Test.adoc

@@ -0,0 +1,159 @@
+ifdef::env-github[]
+:tip-caption: :bulb:
+:note-caption: :information_source:
+:important-caption: :heavy_exclamation_mark:
+:caution-caption: :fire:
+:warning-caption: :warning:
+endif::[]
+
+:imagesdir: ../../images
+:docsdir: ../
+:toc: macro
+:toclevels: 6
+:toc-title: Table of Contents
+:numbered:
+:sectnumlevels: 6
+
+image:meta/gematik_logo.svg[width=70%]
+
+= Testkonzept TI-Messenger-Dienst
+gematik
+| Version 1.0 | Stand: 26.03.2024
+
+Dokumentenhistorie
+[cols='10%,10%,10%,60%,10%']
+|===
+| *Version*  |*Stand*      | *Kap.* | *Grund der Änderung, besondere Hinweise* | *Bearbeiter*
+| 1.0        | 26.03.2024  |        | initiale Erstellung                               | gematik
+|===
+
+toc::[]
+
+== Test und Zertifizierung der TI-Messenger
+Für die Produkt- und die Anbieter-Zulassung MÜSSEN die TI-Messenger-Fachdienste (TI-M FD) und TI-Messenger-Clients (TI-M Client) bereitgestellt werden, um einen automatisierten Test für den TI-Messenger-Dienst (TI-M Dienst) zu ermöglichen, MUSS die Test-App des TI-M Clients zusätzlich ein Testtreiber-Modul intern oder extern zur Verfügung stellen. Dieses MUSS die Funktionalitäten der produktspezifischen Schnittstelle des TI-M Clients über eine standardisierte Schnittstelle von außen zugänglich machen und einen Fernzugriff ermöglichen. Das Testtreiber-Modul MUSS die Ausgaben des TI-M Clients gemäß der technischen Schnittstelle aufarbeiten, aber DARF NICHT die Inhalte verfälschen.
+
+=== Testvorgehen
+
+Das Testvorgehen für TI-Messenger ePA (TI-M ePA) und TI-Messenger Pro (TI-M Pro) setzt auf das Testvorgehen des TI-M Dienst 1.1.1-1 [gemSpec_TI-Messenger-Dienst] auf. Die existierende Testtreiberschnittstelle und Testsuite wird entsprechend erweitert. Alle Tests innerhalb der Testsuite sind separat ausführbar. Somit ist es möglich, die TI-M Pro und das TI-M ePA-FdV zusammen oder einzeln zu testen. Die erweiterte Testtreiberschnittstelle link:../../src/openapi/TiMessengerTestTreiber.yaml[Testtreiber API] und die Testsuite https://github.com/gematik/TI-Messenger-Testsuite[TI-Messenger-Testsuite] werden auf github veröffentlicht und sind für alle Hersteller zugänglich. Während der Zulassungstests werden genau die veröffentlichten Testfälle geprüft. Die Testfälle bilden die definierten Anwendungsfälle aus der Spezifikation ab. Produkttests zur Sicherstellung der Konformität mit der Spezifikation liegen vollständig in der Verantwortung der Anbieter/Hersteller. Die gematik konzentriert sich bei der Zulassung auf das Zusammenspiel der Produkte durch E2E- und IOP-Tests.
+
+=== Testtreiber Modul
+Um einen automatisierten Test für den TI-Messenger-Dienst zu ermöglichen, MUSS die Test-App des TI-M Clients zusätzlich ein Testtreiber-Modul intern oder extern zur Verfügung stellen. Das Testtreiber-Modul MUSS die Funktionalitäten der produktspezifischen Schnittstellen des TI-M Clients über eine standardisierte Schnittstelle von außen zugänglich machen und einen Fernzugriff ermöglichen. Das Testtreiber Modul wird vom Hersteller entwickelt und betrieben.
+
+Dieses Testtreiber-Module MUSS Bestandteil der Test-APP sein (internes Testtreiber-Modul) oder einen Zugang zum Test-Environment des Herstellers gewährleisten (externes Testtreiber-Modul). Die Schnittstelle wird gemäß link:../../src/openapi/TiMessengerTestTreiber.yaml[Testtreiber API] durch die gematik spezifiziert und bereitgestellt. Das Testtreiber-Modul MUSS die durch den TI-M Client über eine produktspezifische Schnittstelle angebotene Funktionalität nutzen, um die Operationen des TI-M Clients umzusetzen. Für die Ausführung der Tests werden Organisationen und Messenger-Services benötigt. Diese Organisationen und Messenger-Services MÜSSEN von den Herstellern vor Beginn der Testphase eingerichtet und die Daten (Organisationsnamen usw.) MÜSSEN an die gematik übermittelt werden. In den folgenden Abbildungen wird das interne sowie das externe Testtreiber-Modul dargestellt. Wenn ein Client in mehreren Ausprägungen zur Verfügung gestellt wird, wird für jede Ausprägung eine Zulassung mit einem eigenen Testtreiber-Modul benötigt.
+
+
+*Cert bereitstellen*
+
+==== internes Testtreiber-Modul
+Bei einem internen Testtreiber-Modul wird die REST-Schnittstelle in die Test-App integriert (der Zugriff erfolgt hierbei direkt über das Endgerät).
+
+.Abbildung{counter:abbildung: 1}: internes Testtreiber Modul
+image:diagrams/Test/testtreiber-internes-Modul.png[align="left",width="100%", title="internes Testtreiber Modul"]
+
+==== externes Testtreiber-Modul
+Bei einem externen Testtreiber-Modul erhält die REST-Schnittstelle Zugang zum Test-Environment des Herstellers.
+
+.Abbildung{counter:abbildung: 1}: externes Testtreiber Modul
+image:diagrams/Test/testtreiber-externes-Modul.png[align="left",width="100%", title="externes Testtreiber Modul"]
+
+=== TI-Messenger Testtreiber Anschaltung
+
+Das folgende Bild zeigt die Anschaltung der Testtreiber Clients. Die Clients können über eine externe oder interne Testtreiber-Schnittstelle mit der Testsuite remote oder local verbunden werden. Diese Leistung MUSS von jedem Hersteller erbracht werden. Welche Clients eingesetzt werden, können die Hersteller selbstständig entscheiden. Es werden nur bereitgestellte Clients zugelassen. Clients mit den gleichen Eigenschaften werden unter einer URL zusammengefasst. Diese URL wird dann in die Konfigurationsdatei 'combine_items.json' eingetragen. In dieser Datei werden alle Testobjekte verwaltet.
+
+.Abbildung{counter:abbildung: 1}: Anschaltung der Testtreiber Clients
+image:diagrams/Test/Anschaltung der Testtreiber Clients-1.png[align="left",width="100%", title="Anschaltung der Testtreiber Clients"]
+
+Die unterschiedlichen Testtreibeschnittstellen werden mit mTLS gesichert. Die gematik stellt für den zugriff auf die Schnittstelle entsprechende Zertifikate bereit. Weiterführende Informationen zur Testsuite und zur Testtreiber-Schnittstelle findet man in der
+https://github.com/gematik/TI-Messenger-Testsuite/blob/main/doc/userguide/Testsuite.adoc[Testsuite TI-M Dienst Release 1.1.1].
+
+== Test der Hersteller
+
+=== Herstellerverantwortung
+Produkttests zur Sicherstellung der Konformität mit der Spezifikation sind vollständig in der Verantwortung der Anbieter/Hersteller des TI-Messenger-Clients (TI-M Client). Die gematik konzentriert sich bei der Zulassung auf das Zusammenspiel der Produkte durch E2E- und IOP Tests.
+
+Die eigenverantwortlichen Produkttests bei den Industriepartnern umfassen:
+
+    Testumgebung entwickeln,
+    Testfallkatalog erstellen (für eigene Produkttests) und
+    Produkttest durchführen und dokumentieren.
+
+Die Hersteller der TI-Messenger-Dienste (TI-M Dienst) MÜSSEN zusichern, dass die gematik die Produkttests der Industriepartner in Form von Reviews der Testkonzepte, der Testspezifikationen, der Testfälle und mit dem Review der Testprotokolle (Log- und Trace-Daten) überprüfen kann.
+
+Die gematik fördert eine enge Zusammenarbeit und unterstützt Industriepartner dabei, die Qualität der Produkte zu verbessern. Dies erfolgt durch die Organisation zeitnaher IOP-Tests, die Synchronisierung von Meilensteinen sowie regelmäßige industriepartnerübergreifende Test-Sessions. Die Test-Sessions umfassen gegenseitige IOP- und E2E Tests.
+
+Die gematik stellt eine TI-M Dienst Referenzimplementierung zur Verfügung. Zur Sicherstellung der Interoperabilität zwischen verschiedenen TI-Messenger-Fachdiensten (TI-M FD) und TI-M Clients MÜSSEN alle TI-M Dienste gegen diese Referenzimplementierung getestet werden. Der Sourcecode für die in der Referenzimplementierung verwendeten Artefakte wird regelmäßig von der gematik unter https://github.com/tim-ref[TI-Messenger [Referenzimplementierung] veröffentlicht.
+
+=== Referenz-Instanz
+
+Vor der Zulassung können sich die Hersteller eine Referenz-Instanz über die gematik bestellen. Die Referenz-Instanz hilft den Herstellern bei der Entwicklung neuer TI-M Clients, FdV und  TI-M FD Versionen. Für die IOP-Tests zwischen den verschiedenen TI-Messenger-Anbietern bzw. -Herstellern können sowohl die Test-Instanzen als auch die Referenz-Instanzen genutzt werden. Die TI-M Dienste müssen gegen die Referenz-Instanz erfolgreich getestet werden. Die Testergebnisse sind der gematik vorzulegen.
+
+.Abbildung{counter:abbildung: 1}: Referenz-Instanz
+image:diagrams/Test/HerstellerInstanz-1.png[align="left",width="100%", title="Referenz-Instanz"]
+
+=== Hersteller IOP Tests
+
+Alle Anbieter MÜSSEN bereits im Vorfeld diesen IOP- und E2E-Tests selbständig und eigenverantwortlich durchführen. Bei Problemen im Rahmen der Zulassung MÜSSEN die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests dargestellt.
+
+.Abbildung{counter:abbildung: 1}: IOP Testumgebung Hersteller
+image:diagrams/Test/testumgebung-Hersteller.png[align="left",width="100%", title="IOP Testumgebung Hersteller"]
+
+== Zulassung
+
+=== Zulassungstests durch die gematik
+Die gematik testet im Rahmen der Zulassungsverfahren auf Basis von Anwendungsfällen. Dabei wird sich auf die link:{docsdir}anwendungsfaelle/TI-Messenger-Anwendungsfaelle.adoc [Anwendungsfälle] bezogen. Hierbei wird versucht, möglichst viele Funktionsbereiche der Komponenten des TI-Messenger-Dienstes (TI-M Dienst) einzubeziehen.
+
+==== Tests gegen die Referenzimplementierung
+Die Tests werden zunächst gegen die Referenzimplementierung der gematik durchgeführt. In diesem Schritt wird die Funktionalität des Zulassungsobjektes "TI-Messenger-Dienst" geprüft.
+
+==== Zulassung TI-Messenger Pro
+
+Die Hersteller von TI-M Diensten müssen wie zuvor erwähnt die Testtreiberschnittstelle und den Fachdienst bereitstellen. Bei Problemen im Rahmen der Zulassung müssen die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für den Zulassungstest TI-Messenger Pro (TI-M Pro) dargestellt.
+
+.Abbildung{counter:abbildung: 1}: Zulassung TI-Messenger Pro
+image:diagrams/Test/Zulassung TIM-Basis.png[align="left",width="100%", title="Zulassung TI-Messenger Pro"]
+
+==== Zulassung TI-Messenger ePA
+
+Die Hersteller von Versicherten-Frontends müssen ebenfalls das FdV, die Testtreiberschnittstelle und den Fachdienst für Versicherte bereitstellen. Bei Problemen im Rahmen der Zulassung müssen die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für den Zulassungstest TI-Messerger ePA (TI-M ePA) dargestellt.
+
+.Abbildung{counter:abbildung: 1}: Zulassung TI-Messenger ePA
+image:diagrams/Test/Zulassung TIM-ePA.png[align="left",width="100%", title="Zulassung TI-Messenger ePA"]
+
+=== IOP Tests zwischen Anbietern durch die gematik
+Zusätzlich zu den bereits durchgeführten IOP- und E2E-Tests werden weitere Interoperabilitätstests verschiedener TI-Messenger-Lösungen vor und nach der Zulassung durch die gematik durchgeführt. Die folgende Abbildung zeigt die Nutzung der existierenden Testumgebung durch die gematik während der Zulassungs- und Interoperabilitätstests.
+
+.Abbildung{counter:abbildung: 1}: IOP Tests
+image:diagrams/Test/testumgebung-Gematik.png[align="left",width="100%", title="IOP Tests"]
+
+IOP- und E2E-Tests für die Interoperabilität MÜSSEN zwischen den verschiedenen TI-Messenger-Anbietern nachgewiesen werden. Hierfür werden dann alle bereits zur Verfügung stehenden TI-M Dienste (die Test-Instanzen der einzelnen Hersteller) zusammengeschlossen und anschließend gegeneinander getestet.
+
+==== IOP Tests TI-Messenger Pro
+
+Im Anschluss der Zulassung wird mit den IOP- und E2E-Tests die Interoperabilität zwischen den verschiedenen TI-Messenger-Anbietern nachgewiesen. Hierfür werden dann alle bereits zur Verfügung stehenden TI-M Dienste (die Test-Instanzen der einzelnen Hersteller) zusammengeschlossen und anschließen gegeneinander getestet. Alle Anbieter MÜSSEN bereits im Vorfeld diesen IOP- und E2E-Tests selbständig und eigenverantwortlich durchführen. Bei Problemen im Rahmen der IOP Tests MÜSSEN die Anbieter bei der Analyse unterstützen. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests TI-M Pro dargestellt.
+
+.Abbildung{counter:abbildung: 1}: IOP Test TI-Messenger Pro
+image:diagrams/Test/Testumgebung Basis-1.png[align="left",width="100%", title="IOP Test TI-Messenger Pro"]
+
+Weiterhin wird ein dauerhaftes Continuous Testing eingeführt. Das Continuous Testing wird dann in der Folge erweitert Dadurch wird auch ein Test unterschiedlicher Messenger Versionen und Ausprägungen ermöglicht.
+
+==== IOP Tests TI-Messenger ePA
+
+Für den TI-M ePA gelten ebenso die im Kap. 3.2.1 beschriebenen Anforderungen an den IOP Test. In der folgenden Abbildung ist eine Systemumgebung für Herstellertests TI-M ePA dargestellt. Bei Problemen im Rahmen der IOP Tests MÜSSEN die Anbieter des Fachdienstes und des FdVs bei der Analyse unterstützen.
+
+.Abbildung{counter:abbildung: 1}: IOP Test TI-Messenger ePA
+image:diagrams/Test/Testumgebung ePA-1.png[align="left",width="100%", title="IOP Test TI-Messenger ePA"]
+
+==== IOP Tests Pools
+
+Um eine größere Abdeckung zu erhalten werden die Hersteller in Pools eingeteilt. Somit können mehrere Hersteller gleichzeitig getestet werden. Anschließend werden die Pools erneut gemischt.
+
+.Abbildung{counter:abbildung: 1}: IOP Test Pools
+image:diagrams/Test/IOP Pools-1.png[align="left",width="100%", title="Verpflichtung nach der Zulassung"]
+
+== Verpflichtung nach der Zulassung
+Der TI-Messenger-Anbieter MUSS eine Referenz-Instanz und mindestens eine Test-Instanz des TI-Messenger-Fachdienstes (TI-M FD) und TI-Messenger-Clients (TI-M Client) bereitstellen und betreiben. Die Referenz-Instanz hat die gleiche Version wie die Produktionsumgebung. Weiterhin wird die Referenz-Instanz für die Reproduktion aktueller Fehler/Probleme aus der Produktionsumgebung genutzt. Der Zugriff auf die Referenz-Instanz MUSS für die gematik zur Fehleranalyse gewährleistet sein. Die Test-Instanz dient den Herstellern bei der Entwicklung neuer TI-M Clients und TI-M FD Versionen, bei den IOP-Tests zwischen den verschiedenen TI-Messenger-Anbietern und wird zudem von der gematik für die Zulassung genutzt. Der TI-Messenger-Anbieter MUSS die verschiedenen Benutzer der Referenz-Instanz und der Test-Instanz koordinieren (Verwaltung eines Test-/Nutzungsplans). Bei Bedarf (Entwicklung verschiedener Versionen, hoher Auslastung durch andere Hersteller oder durch die gematik) MUSS der TI-Messenger-Anbieter auch mehrere Test-Instanzen mit der gleichen oder mit verschiedenen Versionen bereitstellen und betreiben.
+
+.Abbildung{counter:abbildung: 1}: Verpflichtung nach der Zulassung
+image:diagrams/Test/nach_der_Zulassung-1.png[align="left",width="100%", title="Verpflichtung nach der Zulassung"]
+
+Die Referenz-Instanz und die Test-Instanz wird auch im Anschluss der Zulassung weiter für IOP Test und Continuous Testing genutzt.

docs/anwendungsfaelle/COM-chatbot.adoc

@@ -0,0 +1,64 @@
+ifdef::env-github[]
+:tip-caption: :bulb:
+:note-caption: :information_source:
+:important-caption: :heavy_exclamation_mark:
+:caution-caption: :fire:
+:warning-caption: :warning:
+endif::[]
+
+:imagesdir: ../../images
+
+image:meta/gematik_logo.svg[width=70%]
+
+=== Kommunikation mit einem Chatbot
+Im Folgenden wird ein Beispiel für eine mögliche Zuordnung für die Abbildung von Funktionsaccounts mit Hilfe von Chatbots und eines Akteurs der stellvertretend für die Organisation auftritt.
+Der Chatbot kann automatisiert Anfragen von Akteuren (z. B. für Terminanfragen, Medikationsentscheidung) bearbeiten oder bei Bedarf die zugeordneten und zu diesem Zeitpunkt verfügbaren Akteure in den Chatraum einladen. Die dem Chatbot zur Verfügung stehenden Akteure (in der Spalte "Akteur (MXID)") sind in der Konfiguration des Chatbots zu hinterlegen. Im letzte Beispiel in der Tabelle ist ein Akteur (natürliche Person) als Endpoint hinterlegt und tritt stellvertretend für die Organisation in den Chat ein.
+
+.Übersicht der Zuordnung von Funktionsaccounts und Akteuren
+|=== 
+|Abteilung |Funktionsaccount |Endpoint.address |Akteur (MXID) |Displayname im Chatraum
+
+|Kardiologie |Labor_Kardiologie |@MXID_Bot01:<domain>.de |@MXID_01:<domain>.de @MXID_02:<domain>.de a|
+* Empfang_Kardiologie (Chatbot) 
+* Dennert, Maltilde 
+* Fritsche, Sarah
+
+|Neurologie |Ambulanz_Neurologie |@MXID_Bot02:<domain>.de |@MXID_03:<domain>.de a|
+* Ambulanz_Neurologie (Chatbot) 
+* Gotsch, Gerd
+
+|Radiologie |Empfang_Radiologie |@MXID_04:<domain>.de |- |Fruechtl, Wilfried
+|===
+
+=== Beispiel: Einladung durch einen Chatbot
+Die folgende Grafik zeigt den Ablauf beim Kontaktieren eines Funktionsaccounts durch einen Akteur. Der Funktionsaccount wird durch den Chatbot repräsentiert. Der Chatbot kann automatisiert Anfragen von Akteuren bearbeiten oder bei Bedarf die zugeordneten und zu diesem Zeitpunkt verfügbaren Akteure in den Chatraum einladen. Die dem Chatbot zur Verfügung stehenden Akteure sind in der Konfiguration des Chatbots zu definieren. 
+
+A. Vorbedingung:
+* Die Organisation Klinikum X verfügt über einen TI-Messenger-Client mit Administrationsfunktion und einen Messenger-Service
+* Chatbots stehen zur Verfügung und können vom Akteur in der Rolle "Org-Admin" verwaltet werden
+
+B. Konfiguration von Funktionsaccounts:
+* Der Akteur in der Rolle "Org-Admin" legt einen Funktionsaccount (organisationsbezogene MXID) als einen Endpoint des gewünschten HealthcareService der Organisation an und ordnet dieser MXID einen Chatbot zu. 
+* Der Akteur in der Rolle "Org-Admin" weist zuständige Akteure der Organisation (personenbezogene MXIDs) dem Chatbot zu.
+* Die Zuordnung von Akteuren zu einzelnen Anfragen innerhalb eines Funktionsaccounts (z. B. Terminanfragen, Medikationsentscheidung) erfolgt durch die Konfiguration im Chatbot.
+
+C. Beispielhafter Ablauf (siehe Abbildung "Kommunikation mit einem Chatbot"):
+. Es liegt ein kardiologisches Problem vor und der Akteur sucht nach einer Organisation und/oder Unterstruktur dieser Organisation. (z. B. in seinem Krankenhaus die Abteilung Kardiologie)
+. Der Akteur öffnet einen Chatraum mit dem Funktionsaccount der Abteilung Kardiologie.
+. Der Chatbot des Funktionsaccounts der Abteilung Kardiologie betritt den Raum und erfragt das Anliegen vom Akteur (z. B. Terminanfrage, Rückfrage an Arzt etc.) abfragen.
+. Der Akteur antwortet dem Chatbot.
+. Der Chatbot lädt je nach Anliegen die ihm zugeordneten und verfügbaren Akteure in den Chatraum ein.
+. Eingeladene Akteure betreten den Chatraum mit ihrem Displaynamen und kommunizieren mit dem Akteur.
+
+.Kommunikation mit einem Chatbot
+[%collapsible%open]
+====
+++++
+<p align="center">
+  <img width="100%" src=../../images/diagrams/TI-Messenger-Fachdienst/chatbot-Seite-1.png>
+</p>
+++++
+====
+
+
+