Krátká odpověď: Subscription říká FHIR serveru, aby upozornil tento koncový bod, když se změní zdroje odpovídající těmto podmínkám. Ve FHIR R4 jsou podmínky vyhledávací řetězec (criteria: "Observation?patient=123&code=85354-9") a server odešle odpovídající zdroj na REST hook, websocket, e-mail nebo FHIR zprávu. Ve R4B a R5 byl model přestavěn kolem SubscriptionTopic: server publikuje události, o kterých může informovat, klient se přihlásí k odběru tématu s filtry a oznámení přicházejí jako Bundle typu subscription-notification, který vždy začíná zdrojem SubscriptionStatus. Implementační příručka Subscriptions R5 Backport umožňuje R4 serverům nabízet nový model.
R4: odběry založené na kritériích
Ve FHIR R4 je odběr založen na kritériích: klient vytvoří zdroj Subscription, jehož kritéria jsou vyhledávací řetězec, jako je Observation?code=…&patient=…, a jehož kanál je rest-hook, websocket, email, sms nebo message. Server vyhodnotí kritéria proti každému vytvoření a aktualizaci a odešle odpovídající zdroj nebo prázdné oznámení na koncový bod.
{
"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>"]
}
}
Server vyhodnocuje kritéria při každém vytvoření a aktualizaci. Když zdroj odpovídá, odešle ho na koncový bod (nebo odešle prázdné tělo, pokud je payload vynechán, takže si klient zdroj načte sám). Fungovalo to, ale se třemi problémy: servery nemohly říci, jaká kritéria podporují, klienti nemohli rozlišit zmeškané oznámení od klidného období a „zdroj odpovídal vyhledávání“ není totéž jako „událost se stala“ (ukončení Encounter nelze vyjádřit jako vyhledávání).
R4B a R5: odběry založené na tématech
Ve FHIR R4B a R5 jsou odběry založeny na tématech. Server publikuje zdroje SubscriptionTopic, které popisují události (zdroj, spouštěč, jako je vytvoření, aktualizace, smazání nebo podmínka FHIRPath, a povolené filtry). Předplatitel vytvoří Subscription odkazující na téma s hodnotami filterBy, typem kanálu, koncovým bodem, periodou srdečního tepu a nastavením obsahu na empty, id-only nebo full-resource.
SubscriptionTopic je zdroj, který server publikuje a popisuje událost: který zdroj, jaký spouštěč (vytvoření, aktualizace, smazání nebo podmínka FHIRPath, jako je %previous.status != 'finished' and %current.status = 'finished') a jaké filtry může odběratel použít. Odběratel pak vytvoří Subscription, která odkazuje na téma:
{
"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 vybírá, kolik se odešle: empty (pouze událost), id-only (odkazy, zbytek načtěte s vlastním oprávněním) nebo full-resource. heartbeatPeriod způsobí, že server odešle srdeční tep, takže je ticho detekovatelné.
Jak vypadá oznámení
Oznámení o odběru FHIR je Bundle typu subscription-notification, jehož první položka je zdroj SubscriptionStatus poskytující odběr, téma, typ oznámení (handshake, heartbeat, event-notification, query-status nebo query-event) a čítač eventsSinceSubscriptionStart pro detekci zmeškaných událostí. Další položky nesou změněné zdroje nebo jejich reference, v závislosti na nastavení obsahu.
Každé oznámení je Bundle typu subscription-notification. Jeho první položka je SubscriptionStatus s odkazem na odběr, tématem, typem oznámení (handshake, heartbeat, event-notification, query-status, query-event) a čítačem eventsSinceSubscriptionStart; mezera v čítači znamená zmeškanou událost a klient může zavolat $events k jejímu obnovení. Další položky nesou zdroje nebo jejich odkazy, v závislosti na content.
Kanály: rest-hook (server odešle POST na váš HTTPS koncový bod), websocket (klient se připojí a přijímá oznámení na socketu, užitečné pro prohlížečové aplikace), email (pouze oznámení, žádná data), message (FHIR zpráva typu Bundle). Kanál R4 sms byl zrušen.
Provoz v produkci
Provoz odběrů FHIR v produkci vyžaduje idempotentní zpracování klíčované podle čísla události a verze zdroje, zabezpečení koncového bodu, které ověřuje odesílatele a nikdy nepovažuje obsah za autorizaci, toleranci pro dávkové balíčky s mnoha událostmi, odpověď 2xx na úvodní oznámení handshake a povědomí o tom, že mnoho serverů stále omezuje odběry na backendové služby spíše než na klientské aplikace.
- Idempotence. Oznámení mohou být po opakování duplikována; klíčujte podle čísla události a verze zdroje.
- Zabezpečení. Koncový bod musí ověřit odesílatele (sdílené tajné hlavičky, vzájemné TLS nebo podpisy) a nikdy nesmí důvěřovat obsahu jako autorizaci; načtěte citlivá data zpět ze serveru pomocí vlastního tokenu, pokud je
contentid-only. - Zpětný tlak. Servery seskupují události a respektují
maxCount; klienti musí přijímat balíčky s mnoha událostmi. - Handshake. Po aktivaci server odešle oznámení
handshakea očekává 2xx; jinak se odběr přesune do stavuerror. - Rozsahy. SMART on FHIR pomalu přidával rozsahy pro odběry; mnoho serverů stále omezuje odběry na backendové služby (přihlašovací údaje klienta) namísto klientských aplikací.
Webhooky, které nejsou FHIR odběry
Webhooky, které nejsou odběry FHIR, jsou standardní mechanismy platformy: zaregistrujete HTTPS URL a obdržíte podepsané JSON události, jako je zápis zdroje nebo změna souhlasu, bez jakéhokoli SubscriptionTopic. Anpheros nabízí takové webhooky. Jsou jednodušší pro jednu platformu, ale nejsou zjistitelné obecným klientem FHIR, takže integrace, které musí fungovat s jakýmkoli serverem FHIR, používají odběry.
Mnoho platforem, včetně Anpheros, nabízí běžné webhooky: zaregistrujete HTTPS URL a přijímáte podepsané JSON události, jako je zdroj zapsán, změněn souhlas, dokument finalizován. Řeší stejnou potřebu s menší formalitou a bez SubscriptionTopic a nejsou to FHIR zdroje, takže je obecný FHIR klient nemůže objevit. Pokud vaše integrace musí fungovat s jakýmkoli FHIR serverem, použijte Subscriptions; pokud cílí na jednu platformu, její webhooky jsou obvykle jednodušší. Anpheros dokumentuje své webhooky na vývojářském webu (odkaz níže).
Související stránky
- FHIR R4 vs R5
- Vysvětlení vyhledávání FHIR
- Vysvětlení FHIR Bundle
- Vysvětlení CDS Hooks
- Vzdálené monitorování pacientů s FHIR
- Webhooky Anpheros (vývojáři)
Zdroje
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus a oznámení
- HL7 FHIR R4: Subscription
- Implementační příručka Subscriptions R5 Backport
Časté otázky
Mohu použít odběry ve stylu R5 na serveru R4?
Ano, pokud server implementuje implementační příručku Subscriptions R5 Backport, která kóduje téma, filtry a nastavení kanálu jako rozšíření na zdroji R4 Subscription a používá R4 Bundles pro oznámení.
Jaký je rozdíl mezi Subscription a dotazováním s _lastUpdated?
Dotazování se opakovaně ptá serveru a nic nezmešká, ale je pomalé a neefektivní; Subscriptions posílají události, jakmile nastanou. Robustní klienti kombinují obojí: přihlásí se k odběru pro rychlost, dotazuje se nebo volá $events k obnovení po výpadku.
Obsahuje oznámení data?
Pouze pokud je content full-resource. Bezpečnější výchozí nastavení je id-only: oznámení vám řekne, který zdroj se změnil, a vy si ho načtete s vlastním oprávněním.
Jsou FHIR Subscriptions stejné jako webhooky?
Rest-hook subscription je webhook s tvarem definovaným FHIR: zjistitelné témata, standardní oznámení ve formátu Bundle a sledování stavu. Běžné webhooky nabízené platformou dělají totéž pouze pro tuto platformu.
Vyzkoušejte zdarma v sandboxu
První volání FHIR za 5 minut. API standardu HL7 FHIR R4 s integrovaným souhlasem pacienta: vyzkoušejte si ho v sandboxu a poté propojte svou vlastní aplikaci nebo klinický systém.
Zdarma · 30 syntetických pacientů · bez karty
Anpheros vytváří zdravotní záznamy, které pacient ovládá a může sdílet s jakoukoli klinikou, na platformě HL7 FHIR R4 se sídlem v EU. Tyto průvodce vám pomohou porozumět vašemu zdraví a uspořádat si ho; nenahrazují vašeho lékaře.
O Anpheros →