Kurze Antwort: Eine Subscription weist einen FHIR-Server an, diesen Endpunkt zu benachrichtigen, wenn Ressourcen, die diesen Bedingungen entsprechen, geändert werden. In FHIR R4 sind die Bedingungen eine Suchzeichenkette (criteria: "Observation?patient=123&code=85354-9") und der Server sendet die passende Ressource an einen REST-Hook, einen Websocket, eine E-Mail oder eine FHIR-Nachricht. In R4B und R5 wurde das Modell um SubscriptionTopic herum neu aufgebaut: Der Server veröffentlicht die Ereignisse, über die er benachrichtigen kann, der Client abonniert ein Thema mit Filtern, und Benachrichtigungen kommen als Bundle vom Typ subscription-notification an, das immer mit einer SubscriptionStatus-Ressource beginnt. Die Subscriptions R5 Backport Implementierungsanleitung ermöglicht es R4-Servern, das neue Modell anzubieten.
R4: Kriterienbasierte Abonnements
In FHIR R4 basiert ein Abonnement auf Kriterien: Der Client erstellt eine Abonnement-Ressource, deren Kriterien ein Suchstring wie Observation?code=…&patient=… ist und deren Kanal rest-hook, websocket, E-Mail, SMS oder Nachricht ist. Der Server wertet die Kriterien gegen jede Erstellung und Aktualisierung aus und sendet jede übereinstimmende Ressource oder eine leere Benachrichtigung an den Endpunkt.
{
"resourceType": "Subscription",
"status": "requested",
"reason": "Blood pressure alerts for the hypertension clinic",
"criteria": "Observation?code=http://loinc.org|85354-9&patient=Patient/123",
"channel": {
"type": "rest-hook",
"endpoint": "https://clinic.example.org/hooks/bp",
"payload": "application/fhir+json",
"header": ["Authorization: Bearer <token>"]
}
}
Der Server wertet die Kriterien bei jeder Erstellung und Aktualisierung aus. Wenn eine Ressource übereinstimmt, POSTet er sie an den Endpunkt (oder POSTet einen leeren Body, wenn payload weggelassen wird, damit der Client die Ressource selbst abruft). Das funktionierte, aber mit drei Problemen: Server konnten nicht angeben, welche Kriterien sie unterstützten, Clients konnten eine verpasste Benachrichtigung nicht von einer ruhigen Periode unterscheiden, und "eine Ressource entsprach einer Suche" ist nicht dasselbe wie "ein Ereignis ist eingetreten" (ein beendetes Encounter kann nicht als Suche ausgedrückt werden).
R4B und R5: Themenbasierte Abonnements
In FHIR R4B und R5 basieren Abonnements auf Themen. Der Server veröffentlicht SubscriptionTopic-Ressourcen, die Ereignisse beschreiben (die Ressource, einen Auslöser wie Erstellung, Aktualisierung, Löschung oder eine FHIRPath-Bedingung und erlaubte Filter). Ein Abonnent erstellt ein Abonnement, das auf ein Thema mit filterBy-Werten, einem Kanaltyp, einem Endpunkt, einer Herzschlagperiode und einer Inhaltseinstellung von leer, nur ID oder vollständige Ressource verweist.
SubscriptionTopic ist eine vom Server veröffentlichte Ressource, die ein Ereignis beschreibt: welche Ressource, welcher Auslöser (Erstellung, Aktualisierung, Löschung oder eine FHIRPath-Bedingung wie %previous.status != 'finished' and %current.status = 'finished') und welche Filter ein Abonnent verwenden kann. Der Abonnent erstellt dann eine Subscription, die auf das Thema verweist:
{
"resourceType": "Subscription",
"status": "requested",
"topic": "http://example.org/fhir/SubscriptionTopic/encounter-end",
"filterBy": [{"resourceType": "Encounter", "filterParameter": "patient", "value": "Patient/123"}],
"channelType": {"system": "http://terminology.hl7.org/CodeSystem/subscription-channel-type", "code": "rest-hook"},
"endpoint": "https://clinic.example.org/hooks/encounters",
"heartbeatPeriod": 60,
"timeout": 30,
"contentType": "application/fhir+json",
"content": "id-only"
}
content wählt aus, wie viel übertragen wird: empty (nur das Ereignis), id-only (Referenzen, den Rest mit Ihrer eigenen Autorisierung abrufen) oder full-resource. heartbeatPeriod veranlasst den Server, einen Heartbeat zu senden, damit Stille erkennbar ist.
Wie eine Benachrichtigung aussieht
Eine FHIR-Abonnementbenachrichtigung ist ein Bundle vom Typ subscription-notification, dessen erster Eintrag eine SubscriptionStatus-Ressource ist, die das Abonnement, das Thema, den Benachrichtigungstyp (handshake, heartbeat, event-notification, query-status oder query-event) und einen eventsSinceSubscriptionStart-Zähler zur Erkennung verpasster Ereignisse angibt. Weitere Einträge enthalten die geänderten Ressourcen oder ihre Referenzen, abhängig von der Inhaltseinstellung.
Jede Benachrichtigung ist ein Bundle vom Typ subscription-notification. Sein erster Eintrag ist ein SubscriptionStatus mit der Abonnementreferenz, dem Thema, der Art der Benachrichtigung (handshake, heartbeat, event-notification, query-status, query-event) und einem eventsSinceSubscriptionStart-Zähler; eine Lücke im Zähler bedeutet ein verpasstes Ereignis, und der Client kann $events aufrufen, um es wiederherzustellen. Weitere Einträge enthalten die Ressourcen oder ihre Referenzen, abhängig von content.
Kanäle: rest-hook (der Server POSTet an Ihren HTTPS-Endpunkt), websocket (der Client verbindet sich und empfängt Benachrichtigungen über den Socket, nützlich für Browser-Apps), email (nur Benachrichtigung, keine Daten), message (ein FHIR-Messaging-Bundle). Der R4 sms-Kanal wurde gestrichen.
Betrieb in der Produktion
Der Betrieb von FHIR-Abonnements in der Produktion erfordert eine idempotente Handhabung, die auf der Ereignisnummer und der Ressourcenversion basiert, Endpunktsicherheit, die den Absender verifiziert und die Nutzlast niemals als Autorisierung behandelt, Toleranz für gebündelte Bundles mit vielen Ereignissen, eine 2xx-Antwort auf die anfängliche Handshake-Benachrichtigung und das Bewusstsein, dass viele Server Abonnements weiterhin auf Backend-Dienste und nicht auf Patienten-Apps beschränken.
- Idempotenz. Benachrichtigungen können nach einem Wiederholungsversuch dupliziert werden; schlüsseln Sie nach der Ereignisnummer und der Ressourcenversion.
- Sicherheit. Der Endpunkt muss den Absender verifizieren (ein gemeinsamer geheimer Header, gegenseitiges TLS oder Signaturen) und darf dem Payload niemals als Autorisierung vertrauen; rufen Sie sensible Daten mit Ihrem eigenen Token vom Server ab, wenn
contentid-onlyist. - Backpressure. Server bündeln Ereignisse und respektieren
maxCount; Clients müssen Bundles mit vielen Ereignissen akzeptieren. - Handshake. Bei der Aktivierung sendet der Server eine
handshake-Benachrichtigung und erwartet eine 2xx-Antwort; andernfalls wechselt das Abonnement in den Statuserror. - Scopes. SMART on FHIR hat Abonnement-Scopes langsam hinzugefügt; viele Server beschränken Abonnements immer noch auf Backend-Dienste (Client-Credentials) anstatt auf Patienten-Apps.
Webhooks, die keine FHIR-Abonnements sind
Webhooks, die keine FHIR-Abonnements sind, sind einfache Plattformmechanismen: Sie registrieren eine HTTPS-URL und erhalten signierte JSON-Ereignisse wie Ressource geschrieben oder Zustimmung geändert, ohne ein SubscriptionTopic. Anpheros bietet solche Webhooks an. Sie sind für eine Plattform einfacher, aber nicht von einem generischen FHIR-Client auffindbar. Daher verwenden Integrationen, die mit jedem FHIR-Server funktionieren müssen, Abonnements.
Viele Plattformen, darunter Anpheros, bieten einfache Webhooks an: Sie registrieren eine HTTPS-URL und erhalten signierte JSON-Ereignisse wie Ressource geschrieben, Einwilligung geändert, Dokument finalisiert. Sie lösen denselben Bedarf mit weniger Aufwand und ohne SubscriptionTopic, und sie sind keine FHIR-Ressourcen, sodass ein generischer FHIR-Client sie nicht entdecken kann. Wenn Ihre Integration gegen jeden FHIR-Server funktionieren muss, verwenden Sie Subscriptions; wenn sie auf eine Plattform abzielt, sind ihre Webhooks in der Regel einfacher. Anpheros dokumentiert seine Webhooks auf der Entwicklerseite (Link unten).
Verwandte Seiten
- FHIR R4 vs R5
- FHIR-Suche erklärt
- FHIR Bundle erklärt
- CDS Hooks erklärt
- Remote-Patientenüberwachung mit FHIR
- Anpheros Webhooks (Entwickler)
Quellen
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus und Benachrichtigungen
- HL7 FHIR R4: Subscription
- Subscriptions R5 Backport Implementierungsanleitung
Häufige Fragen
Kann ich R5-ähnliche Abonnements auf einem R4-Server verwenden?
Ja, wenn der Server die Subscriptions R5 Backport Implementierungsanleitung implementiert, die das Thema, die Filter und die Kanaleinstellungen als Erweiterungen der R4 Subscription-Ressource kodiert und R4 Bundles für Benachrichtigungen verwendet.
Was ist der Unterschied zwischen einer Subscription und Polling mit _lastUpdated?
Polling fragt den Server wiederholt ab und verpasst nichts, ist aber langsam und verschwenderisch; Subscriptions pushen Ereignisse, sobald sie auftreten. Robuste Clients kombinieren beides: Abonnieren für Geschwindigkeit, Polling oder $events aufrufen, um sich nach Ausfallzeiten zu erholen.
Enthält die Benachrichtigung die Daten?
Nur wenn content full-resource ist. Die sicherere Standardeinstellung ist id-only: Die Benachrichtigung teilt Ihnen mit, welche Ressource sich geändert hat, und Sie rufen sie mit Ihrer eigenen Autorisierung ab.
Sind FHIR-Abonnements dasselbe wie Webhooks?
Ein Rest-Hook-Abonnement ist ein Webhook mit einer FHIR-definierten Form: entdeckbare Themen, standardmäßige Benachrichtigungs-Bundles und Statusverfolgung. Einfache Webhooks, die von einer Plattform angeboten werden, erfüllen denselben Zweck nur für diese Plattform.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →