Seiteninhalt:
Diese Seite beschreibt die Subscription-Schnittstelle des TI-Flow-Fachdienstes. Das konzeptuelle Pattern des Subscription-Mechanismus ist auf der Seite Technische Umsetzung - Subscription beschrieben.
Die Subscription-Schnittstelle besteht aus zwei Endpunkten:
| Endpunkt | HTTP-Methode | Absicherung | Zweck |
|---|---|---|---|
/Subscription |
POST | ZETA | Subscription registrieren, Bearer-Token erhalten |
/subscription |
GET (WebSocket Upgrade) | TLS + FD Bearer-Token | WebSocket-Verbindung aufbauen |
Der Client sendet eine FHIR-Subscription-Ressource über die ZETA-gesicherte FHIR-API. Der TI-Flow-Fachdienst generiert ein Pseudonym der Telematik-ID als Subscription.id und stellt einen Bearer-Token für den Subscription-Endpunkt aus.
{"resourceType":"CapabilityStatement","id":"ti-flow-fachdienst-server","meta":{"profile":["https://gematik.de/fhir/ti/StructureDefinition/ti-capability-statement"]},"text":{"status":"extensions","div":"<div xmlns=\"http://www.w3.org/1999/xhtml\"><p class=\"res-header-id\">Generated Narrative: CapabilityStatement ti-flow-fachdienst-server</p><a name=\"ti-flow-fachdienst-server\"> </a><a name=\"hcti-flow-fachdienst-server\"> </a><div style=\"display: inline-block; background-color: #d9e0e7; padding: 6px; margin: 4px; border: 1px solid #8da1b4; border-radius: 5px; line-height: 60%\"><p style=\"margin-bottom: 0px\"/><p style=\"margin-bottom: 0px\">Profile: <a href=\"https://gematik.de/fhir/ti/1.4.0-ballot.1/StructureDefinition-ti-capability-statement.html\">Capability Statement Profil für TI FHIR Data Service</a></p></div><h2 id=\"title\">CapabilityStatement für den TI-Flow-Fachdienst</h2>application/fhir+json, application/fhir+xmlNote to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
</blockquote><h2 id=\"rest\">FHIR RESTful Capabilities</h2><div class=\"panel panel-default\"><div class=\"panel-heading\"><h3 id=\"mode1\" class=\"panel-title\">Mode:server</h3></div><div class=\"panel-body\"/></div><h3 id=\"resourcesCap1\">Capabilities by Resource/Profile</h3><h4 id=\"resourcesSummary1\">Summary</h4>The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude_include_revincludesearch-type.<a href=\"StructureDefinition-GEM-ERP-PR-Device.html\">GEM ERP PR Device</a>
</div></div></div></div></div><div class=\"panel panel-default\"><div class=\"panel-heading\"><h4 id=\"AuditEvent1-2\" class=\"panel-title\"><span style=\"float: right;\">Resource Conformance: SHALL </span>AuditEvent</h4></div><div class=\"panel-body\"><div class=\"container\"><div class=\"row\"><div class=\"col-lg-4\"><span class=\"lead\">Core FHIR Resource</span>search-type, read.<a href=\"StructureDefinition-audit-event-rest.html\">TI Audit Event Rest</a>
</div></div><div class=\"row\"><div class=\"col-lg-7\"><span class=\"lead\">Search Parameters</span><table class=\"table table-condensed table-hover\">dateAuditEvent.recorded - Unterstützt die Suche nach dem Aufzeichnungsdatum; default sort if _sort is not provided
\nreferenceAuditEvent.entity.what.identifier.value - Unterstützt die Suche nach betroffenen Entitäten
\nstringUnterstützt das Sortieren nach unterstützten AuditEvent-Suchkriterien
\nnumberMaximale Anzahl zurückgegebener Einträge pro Seite; maximum value is 50
\nnumberNullbasierter Offset des ersten zurückgegebenen Eintrags; default is 0
\nNach der Registrierung baut der Client eine TLS-verschlüsselte WebSocket-Verbindung zum Subscription-Endpunkt auf. Dieser Request läuft nicht über ZETA, sondern direkt zum Subscription-Service.
Request:
GET /subscription HTTP/1.1
Host: <subscription-endpunkt>
Authorization: Bearer <vom TI-Flow-FD ausgestellter Bearer-Token>
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: <Base64-kodierte Nonce (16 Byte)>
Response (erfolgreicher Upgrade):
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: <Hash>
Nach dem Upgrade sendet der Client eine bind-Nachricht mit der Subscription.id:
bind: <Subscription.id>
Der Subscription-Service bestätigt mit:
bound: <Subscription.id>
Ab diesem Zeitpunkt sendet der Subscription-Service bei jeder neu vorliegenden Ressource:
ping: <Subscription.id>
Der Client ruft die Ressourcen daraufhin über die reguläre ZETA-gesicherte FHIR-Schnittstelle ab. Über die WebSocket-Verbindung selbst werden keine fachlichen Daten übertragen.
Hinweis: Der Subscription-Service antwortet beim Schließen der Verbindung mit WebSocket-Status-Codes gemäß RFC 6455, Section 7.4. Bei internen Fehlern liefert er HTTP-Status 502 Bad Gateway oder 504 Gateway Timeout.
Hinweis: Die Signaturschlüssel für Bearer-Tokens müssen nicht aus der Komponenten-PKI der TI abgeleitet werden. Es wird kein fester Wechsel-Turnus festgelegt; ein Schlüsselwechsel kann über betriebliche Prozesse initiiert werden. Der Schlüssel muss sicher gespeichert, jedoch nicht zwingend in einem HSM abgelegt werden.