Skip to content

Commit 2c1763a

Browse files
ChristianAlbrechtGematikChristianAlbrechtGematik
authored
QS KTR und Subscription
1 parent 6df8b6f commit 2c1763a

11 files changed

Lines changed: 139 additions & 49 deletions

‎igs/core/input/pagecontent/menu-schnittstellen-query-api.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -6,5 +6,6 @@ Die folgenden Query APIs stellt der TI-Flow-Fachdienst den Clientsystemen zur Ve
66
- [Query API: MedicationDispense](./query-api-medicationdispense.html)
77
- [Query API: Communication](./query-api-communication.html)
88
- [Query API: Consent](./query-api-consent.html)
9+
- [Query API: Subscription](./query-api-subscription.html)
910
- [Query API: Push Notification - pushers](./query-api-pushers.html)
1011
- [Query API: Push Notification - channels](./query-api-channels.html)

‎igs/core/input/pagecontent/op-accept-req-ktr.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ Diese Seite enthält die workflowtyp-übergreifenden normativen Anforderungen an
77
<actor name="CS_E-Rezept_KTR">
88
<testProcedure id="Herstellererklärung"/>
99
</actor>
10-
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Verordnung abrufen" zum Herunterladen des E-Rezepts die HTTP-Operation POST /Task/&#60;id&#62;/$accept mit
10+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Verordnung abrufen" zum Herunterladen der Verordnung die HTTP-Operation POST /Task/&#60;id&#62;/$accept mit
1111
<ul>
1212
<li>ACCESS_TOKEN im Authorization-Header</li>
1313
<li>Task-ID in URL &#60;id&#62;</li>

‎igs/core/input/pagecontent/op-reject-req-ktr.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,5 +21,5 @@ Diese Seite enthält die workflowtyp-übergreifenden normativen Anforderungen an
2121
<actor name="CS_E-Rezept_KTR">
2222
<testProcedure id="Herstellererklärung"/>
2323
</actor>
24-
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Verordnung durch Clientsystem zurückgeben" für das zurückzugebende E-Rezept nach erfolgreichem Aufruf der Operation "Eine Verordnung zurückweisen" die Daten zu Verordnung, E-Rezept-Token und das Geheimnis im CS löschen.
24+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Verordnung durch Clientsystem zurückgeben" für die zurückzugebende Verornung nach erfolgreichem Aufruf der Operation "Eine Verordnung zurückweisen" die Daten zu Verordnung, E-Rezept-Token und das Geheimnis im CS löschen.
2525
</requirement>

‎igs/core/input/pagecontent/query-api-communication-req-avs.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ Diese Seite beschreibt Anforderungen an Clients zur Nutzung der `Communication`-
88
<actor name="PS_E-Rezept_abgebend">
99
<testProcedure id="Herstellererklärung"/>
1010
</actor>
11-
Das PS der abgebenden LEI MUSS im Anwendungsfall "Nachrichten von Versicherten empfangen" zwischen den Aufrufen der Operation GET /Communication mindestens 5 Minuten warten. Der Zeitraum zwischen den Aufrufen muss um eine zufällige Zeitspanne zwischen 0 und 10.000 Millisekunden verlängert werden, um eine Gleichverteilung der Anfragen am TI-Flow-Fachdienst über alle Apotheken zu erreichen.
11+
Das PS der abgebenden LEI MUSS im Anwendungsfall "Nachrichten von Versicherten empfangen" zwischen den Aufrufen der Operation GET /Communication mindestens 5 Minuten warten. Der Zeitraum zwischen den Aufrufen muss um eine zufällige Zeitspanne zwischen 0 und 10.000 Millisekunden verlängert werden, um eine Gleichverteilung der Anfragen am TI-Flow-Fachdienst über alle Clientsysteme zu erreichen.
1212
</requirement>
1313

1414
<!-- A_19329-01 -->

‎igs/core/input/pagecontent/query-api-communication-req-ktr.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ Diese Seite beschreibt Anforderungen ein Clientsystem des Kostenrägers zur Nutz
99
<actor name="CS_E-Rezept_KTR">
1010
<testProcedure id="Herstellererklärung"/>
1111
</actor>
12-
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Nachrichten von Versicherten empfangen" zwischen den Aufrufen der Operation GET /Communication mindestens 5 Minuten warten. Der Zeitraum zwischen den Aufrufen muss um eine zufällige Zeitspanne zwischen 0 und 10.000 Millisekunden verlängert werden, um eine Gleichverteilung der Anfragen am TI-Flow-Fachdienst über alle Apotheken zu erreichen.
12+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Nachrichten von Versicherten empfangen" zwischen den Aufrufen der Operation GET /Communication mindestens 5 Minuten warten. Der Zeitraum zwischen den Aufrufen muss um eine zufällige Zeitspanne zwischen 0 und 10.000 Millisekunden verlängert werden, um eine Gleichverteilung der Anfragen am TI-Flow-Fachdienst über alle Clientsysteme zu erreichen.
1313
</requirement>
1414

1515
<!-- A_19329-01 -->
@@ -27,7 +27,7 @@ Diese Seite beschreibt Anforderungen ein Clientsystem des Kostenrägers zur Nutz
2727
ausführen.
2828
</requirement>
2929

30-
Falls eine oder mehrere E-Rezept-Nachrichten für die abgebende LEI auf dem TI-Flow-Fachdienst bereitstehen, übermittelt der TI-Flow-Fachdienst ein Bundle von Communication Ressourcen. 
30+
Falls eine oder mehrere E-Rezept-Nachrichten für den Kostenträger auf dem TI-Flow-Fachdienst bereitstehen, übermittelt der TI-Flow-Fachdienst ein Bundle von Communication Ressourcen. 
3131

3232

3333
### Nachricht versenden
@@ -50,7 +50,7 @@ Die für die Nachricht zu verwendende Communication-Ressource wird modul- und an
5050

5151
### Nachricht löschen
5252

53-
Mit diesem Anwendungsfall kann die abgebende LEI von ihr versendete Nachrichten an einen Versicherten auf dem Fachdienst löschen.
53+
Mit diesem Anwendungsfall kann ein Kostenträger von ihm versendete Nachrichten an einen Versicherten auf dem Fachdienst löschen.
5454

5555
Das CS Kostenträger MUSS es dem Nutzer ermöglichen, eine Nachricht zum
5656
Löschen auf dem Fachdienst auszuwählen.
@@ -73,7 +73,7 @@ Löschen abzubrechen.
7373
ausführen.
7474
</requirement>
7575

76-
Der Fachdienst prüft anhand der Telematik-ID im ACCESS_TOKEN, ob die LEI der Absender der zu löschenden Nachricht ist.
76+
Der Fachdienst prüft anhand der Telematik-ID im ACCESS_TOKEN, ob der Kostenträger der Absender der zu löschenden Nachricht ist.
7777

7878
Das CS Kostenträger KANN im Anwendungsfall "Nachricht durch Abgebenden
7979
löschen" dem Nutzer ermöglichen, die Nachricht auch lokal im PS zu löschen.

‎igs/core/input/pagecontent/query-api-subscription-req-avs.md‎

Lines changed: 34 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -2,42 +2,22 @@ Diese Seite beschreibt Anforderungen an Clients zur Nutzung der `Subscription`-Q
22

33
Um die Last am TI-Flow-Fachdienst zu kontrollieren, wurde festgelegt, dass ein AVS nicht öfter als alle 5 min nach neuen Nachrichten anfragen darf (A_21556). Die dadurch bis zu 5 min entstehende Verzögerung verlängert die Zeit, bis eine Apotheke auf die Nachricht des Versicherten reagieren kann. Aus dem Grund wird eine Funktionalität eingeführt, mit der AVS eine Notification erhalten, dass eine neue Nachricht für eine Telematik-ID vorliegt. Nach Erhalt einer Notification darf das AVS die neue Nachricht sofort abrufen.
44

5-
<!-- ToDo: um KTR erweitern -->
6-
75
<!-- A_22426 -->
86
<requirement conformance="SHALL NOT" key="IG-TIFLOW-CORE-305" title="PS abgebende LEI: Subscription für neue Communication - eine Subscription pro Telematik-ID" version="0">
97
<meta lockversion="false"/>
108
<actor name="PS_E-Rezept_abgebend">
119
<testProcedure id="Herstellererklärung"/>
12-
</actor>
13-
<actor name="CS_E-Rezept_KTR">
14-
<testProcedure id="Herstellererklärung"/>
1510
</actor>
1611
Das PS der abgebenden LEI DARF NICHT mehr als eine Subscription pro Telematik-ID registrieren.
1712
</requirement>
1813

19-
<!-- A_22372 -->
20-
<requirement conformance="SHALL" key="IG-TIFLOW-CORE-306" title="PS abgebende LEI: Subscription für neue Communication" version="0">
21-
<meta lockversion="false"/>
22-
<actor name="PS_E-Rezept_abgebend">
23-
<testProcedure id="Herstellererklärung"/>
24-
</actor>
25-
<actor name="CS_E-Rezept_KTR">
26-
<testProcedure id="Herstellererklärung"/>
27-
</actor>
28-
Das PS der abgebenden LEI MUSS den Anwendungsfall "Subscription für neue Communication" gemäß TAB_ILFERP_017 umsetzen. Tabelle # : TAB_ILFERP_017 – Subscription für neue Communication Name Subscription für neue Communication Auslöser Periodischer Aufruf, wenn keine Websocket-Verbindung für die Notification besteht Akteur AVS Vorbedingung Die LEI hat sich gegenüber der TI authentisiert. Nachbedingung Es besteht eine Websocket-Verbindung zum Empfang der Notification Standardablauf Subscription Ressource erstellen Subscription registrieren Websocket-Verbindung zu Subscription Service aufbauen Listening
29-
</requirement>
30-
3114
<!-- A_22373 -->
3215
<requirement conformance="SHALL" key="IG-TIFLOW-CORE-307" title="PS abgebende LEI: Subscription für neue Communication - Subscription Ressource erstellen" version="0">
3316
<meta lockversion="false"/>
3417
<actor name="PS_E-Rezept_abgebend">
3518
<testProcedure id="Herstellererklärung"/>
3619
</actor>
37-
<actor name="CS_E-Rezept_KTR">
38-
<testProcedure id="Herstellererklärung"/>
39-
</actor>
40-
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" eine Subscription Ressource mit Telematik-ID in Element criteria Attribut receipient erstellen.
20+
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" eine Subscription Ressource mit Telematik-ID in Element criteria Attribut receipient erstellen.
4121
</requirement>
4222

4323
<!-- A_22374 -->
@@ -46,10 +26,7 @@ Um die Last am TI-Flow-Fachdienst zu kontrollieren, wurde festgelegt, dass ein A
4626
<actor name="PS_E-Rezept_abgebend">
4727
<testProcedure id="Herstellererklärung"/>
4828
</actor>
49-
<actor name="CS_E-Rezept_KTR">
50-
<testProcedure id="Herstellererklärung"/>
51-
</actor>
52-
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" zum Registrieren im TI-Flow-Fachdienst die HTTP-Operation POST /v1/Subscription mit ACCESS_TOKEN im Authorization-Header ausführen.
29+
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" zum Registrieren im TI-Flow-Fachdienst die HTTP-Operation POST /v1/Subscription mit ACCESS_TOKEN im Authorization-Header ausführen.
5330
</requirement>
5431

5532
<!-- A_22375 -->
@@ -58,20 +35,44 @@ Um die Last am TI-Flow-Fachdienst zu kontrollieren, wurde festgelegt, dass ein A
5835
<actor name="PS_E-Rezept_abgebend">
5936
<testProcedure id="Herstellererklärung"/>
6037
</actor>
61-
<actor name="CS_E-Rezept_KTR">
62-
<testProcedure id="Herstellererklärung"/>
63-
</actor>
64-
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" nach der Registrierung eine Web Socket Verbindung zum Subscription Service mit Authorization Header aufbauen und ein Upgrade durchführen.
38+
Das PS der abgebenden LEI MUSS im Anwendungsfall "Subscription für neue Communication" nach der Registrierung eine Web Socket Verbindung zum Subscription Service mit Authorization Header aufbauen und ein Upgrade durchführen.
6539
</requirement>
6640

41+
Beispiel:
42+
GET https://subscription.zentral.erp.splitdns.ti-dienste.de/subscription
43+
Authorization: Bearer secret-token-abc-123
44+
Connection: Upgrade
45+
Pragma: no-cache
46+
Cache-Control: no-cache
47+
Upgrade: websocket
48+
Sec-WebSocket-Version: 13
49+
Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==
50+
51+
Der Subscription Service antwortet mit dem Upgrade
52+
HTTP/1.1 101 Switching Protocols
53+
Upgrade: websocket
54+
Connection: Upgrade
55+
Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=
56+
57+
Das Upgrade erfolgt mit einer "bind" Text-Nachricht über die Web Socket-Verbindung an den Server.
58+
bind: &lt;subscription id&gt;
59+
60+
Der Subscription Service antwortet mit einer "bound" um die Einrichtung der Subscription zu bestätigen.
61+
bound: &lt;subscription id&gt;
62+
63+
Wenn eine neue Nachricht für die Telematik-ID des Clients eingestellt wird, dann sendet der TI-Flow-Fachdienst eine Nachricht ping: &lt;subscription-id&gt;. Das Clientsystem kann dann diese Nachricht mittels des Anwendungsfalls "Nachrichten von Versicherten empfangen" unter Nutzung des Requests
64+
GET /Communication?received=null&recipient=&lt;Telematik-ID&gt;
65+
abrufen.
66+
67+
Bei Nutzung des Subscription Services kann abweichend von der Anforderung "A_21556 - PS abgebende LEI: Häufigkeit des Abrufen von Nachrichten" die Operation GET /Communication häufiger als alle 5 Minuten, d.h. nach jeder Notification, mit den obigen Parametern angefragt werden.
68+
6769
<!-- A_22379 -->
6870
<requirement conformance="MAY" key="IG-TIFLOW-CORE-310" title="PS abgebende LEI: Subscription für neue Communication - Wartezeit" version="0">
6971
<meta lockversion="false"/>
7072
<actor name="PS_E-Rezept_abgebend">
7173
<testProcedure id="Herstellererklärung"/>
7274
</actor>
73-
<actor name="CS_E-Rezept_KTR">
74-
<testProcedure id="Herstellererklärung"/>
75-
</actor>
76-
Der Primärsystem der abgebenden LEI KANN eine beliebige Wartezeit bis zum Abruf der Nachrichten mit Anwendungsfall „Nachrichten von Versicherten empfangen“ umsetzen, wenn in einem Zeitraum sehr viele ping-Benachrichtigungen empfangen werden.
75+
Das PS der abgebenden LEI KANN eine beliebige Wartezeit bis zum Abruf der Nachrichten mit Anwendungsfall „Nachrichten von Versicherten empfangen“ umsetzen, wenn in einem Zeitraum sehr viele ping-Benachrichtigungen empfangen werden.
7776
</requirement>
77+
78+
Hinweis: Jede eingestellte Nachricht führt zu einem Ping, ggfs. im Millisekundenbereich, wenn viele Nachrichten an einen Empfänger gerichtet werden. In Abhängigkeit von der Implementierung kann dieses Verhalten zu einer Überlastung des Clientsystems führen, wenn bspw. jedes einzelne Ping den Anwendungsfall „Nachrichten von Versicherten empfangen“ triggert.

‎igs/core/input/pagecontent/query-api-subscription-req-fd.md‎

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,13 @@ Diese Seite enthält die normativen Anforderungen an den TI-Flow-Fachdienst für
1515
<actor name="TI_Flow_FD">
1616
<testProcedure id="Produkttest"/>
1717
</actor>
18-
Der TI-Flow-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf die /Subscription Ressource mit einem Response antworten, welcher eine Subscription Ressource mit Pseudonym der Telematik-ID in id aktueller Timestamp + 12 h in end Bearer Token in Authorization enthält.
18+
Der TI-Flow-Fachdienst MUSS beim Aufruf der Http-POST-Operation auf die /Subscription Ressource mit einem Response antworten, welcher eine Subscription Ressource mit
19+
<ul>
20+
<li>Pseudonym der Telematik-ID in id</li>
21+
<li>aktueller Timestamp + 12 h in end</li>
22+
<li>Bearer Token in Authorization</li>
23+
</ul>
24+
enthält.
1925
</requirement>
2026

2127
<!-- A_22365 -->

‎igs/core/input/pagecontent/query-api-subscription-req-ktr.md‎

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
Diese Seite beschreibt Anforderungen an Clients zur Nutzung der `Subscription`-Query-Endpunkte.
2+
3+
Um die Last am TI-Flow-Fachdienst zu kontrollieren, wurde festgelegt, dass ein Clientsystem des Kostenträgers nicht öfter als alle 5 min nach neuen Nachrichten anfragen darf (A_21556). Die dadurch bis zu 5 min entstehende Verzögerung verlängert die Zeit, bis ein Kostenträger auf die Nachricht des Versicherten reagieren kann. Aus dem Grund wird eine Funktionalität eingeführt, mit der ein Clientsystem des Kostenträgers eine Notification erhält, dass eine neue Nachricht für eine Telematik-ID vorliegt. Nach Erhalt einer Notification darf das Clientsystem des Kostenträgers die neue Nachricht sofort abrufen.
4+
5+
<!-- A_22426 -->
6+
<requirement conformance="SHALL NOT" key="" title="CS Kostenträger: Subscription für neue Communication - eine Subscription pro Telematik-ID" version="0">
7+
<meta lockversion="false"/>
8+
<actor name="CS_E-Rezept_KTR">
9+
<testProcedure id="Herstellererklärung"/>
10+
</actor>
11+
Das Clientsystem Kostenträger DARF NICHT mehr als eine Subscription pro Telematik-ID registrieren.
12+
</requirement>
13+
14+
<!-- A_22373 -->
15+
<requirement conformance="SHALL" key="" title="CS Kostenträger: Subscription für neue Communication - Subscription Ressource erstellen" version="0">
16+
<meta lockversion="false"/>
17+
<actor name="CS_E-Rezept_KTR">
18+
<testProcedure id="Herstellererklärung"/>
19+
</actor>
20+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Subscription für neue Communication" eine Subscription Ressource mit Telematik-ID in Element criteria Attribut receipient erstellen.
21+
</requirement>
22+
23+
<!-- A_22374 -->
24+
<requirement conformance="SHALL" key="" title="CS Kostenträger: Subscription für neue Communication - Subscription registrieren" version="0">
25+
<meta lockversion="false"/>
26+
<actor name="CS_E-Rezept_KTR">
27+
<testProcedure id="Herstellererklärung"/>
28+
</actor>
29+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Subscription für neue Communication" zum Registrieren im TI-Flow-Fachdienst die HTTP-Operation POST /v1/Subscription mit ACCESS_TOKEN im Authorization-Header ausführen.
30+
</requirement>
31+
32+
<!-- A_22375 -->
33+
<requirement conformance="SHALL" key="" title="CS Kostenträger: Subscription für neue Communication - Subscription" version="0">
34+
<meta lockversion="false"/>
35+
<actor name="CS_E-Rezept_KTR">
36+
<testProcedure id="Herstellererklärung"/>
37+
</actor>
38+
Das Clientsystem Kostenträger MUSS im Anwendungsfall "Subscription für neue Communication" nach der Registrierung eine Web Socket Verbindung zum Subscription Service mit Authorization Header aufbauen und ein Upgrade durchführen.
39+
</requirement>
40+
41+
Beispiel:
42+
GET https://subscription.zentral.erp.splitdns.ti-dienste.de/subscription
43+
Authorization: Bearer secret-token-abc-123
44+
Connection: Upgrade
45+
Pragma: no-cache
46+
Cache-Control: no-cache
47+
Upgrade: websocket
48+
Sec-WebSocket-Version: 13
49+
Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==
50+
51+
Der Subscription Service antwortet mit dem Upgrade
52+
HTTP/1.1 101 Switching Protocols
53+
Upgrade: websocket
54+
Connection: Upgrade
55+
Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=
56+
57+
Das Upgrade erfolgt mit einer "bind" Text-Nachricht über die Web Socket-Verbindung an den Server.
58+
bind: &lt;subscription id&gt;
59+
60+
Der Subscription Service antwortet mit einer "bound" um die Einrichtung der Subscription zu bestätigen.
61+
bound: &lt;subscription id&gt;
62+
63+
Wenn eine neue Nachricht für die Telematik-ID des Clients eingestellt wird, dann sendet der TI-Flow-Fachdienst eine Nachricht ping: &lt;subscription-id&gt;. Das Clientsystem kann dann diese Nachricht mittels des Anwendungsfalls "Nachrichten von Versicherten empfangen" unter Nutzung des Requests
64+
GET /Communication?received=null&recipient=&lt;Telematik-ID&gt;
65+
abrufen.
66+
67+
Bei Nutzung des Subscription Services kann abweichend von der Anforderung "A_21556 - PS abgebende LEI: Häufigkeit des Abrufen von Nachrichten" die Operation GET /Communication häufiger als alle 5 Minuten, d.h. nach jeder Notification, mit den obigen Parametern angefragt werden.
68+
69+
<!-- A_22379 -->
70+
<requirement conformance="MAY" key="" title="CS Kostenträger: Subscription für neue Communication - Wartezeit" version="0">
71+
<meta lockversion="false"/>
72+
<actor name="CS_E-Rezept_KTR">
73+
<testProcedure id="Herstellererklärung"/>
74+
</actor>
75+
Das Clientsystem Kostenträger KANN eine beliebige Wartezeit bis zum Abruf der Nachrichten mit Anwendungsfall „Nachrichten von Versicherten empfangen“ umsetzen, wenn in einem Zeitraum sehr viele ping-Benachrichtigungen empfangen werden.
76+
</requirement>
77+
78+
Hinweis: Jede eingestellte Nachricht führt zu einem Ping, ggfs. im Millisekundenbereich, wenn viele Nachrichten an einen Empfänger gerichtet werden. In Abhängigkeit von der Implementierung kann dieses Verhalten zu einer Überlastung des Clientsystems führen, wenn bspw. jedes einzelne Ping den Anwendungsfall „Nachrichten von Versicherten empfangen“ triggert.

0 commit comments

Comments
 (0)