Răspuns scurt: o Subscription îi spune unui server FHIR notifică acest punct final când resursele care corespund acestor condiții se modifică. În FHIR R4, condițiile sunt un șir de căutare (criteria: "Observation?patient=123&code=85354-9") și serverul trimite resursa corespunzătoare către un REST hook, un websocket, un e-mail sau un mesaj FHIR. În R4B și R5, modelul a fost reconstruit în jurul SubscriptionTopic: serverul publică evenimentele despre care poate notifica, clientul se abonează la un topic cu filtre, iar notificările ajung ca un Bundle de tip subscription-notification care începe întotdeauna cu o resursă SubscriptionStatus. Ghidul de implementare Subscriptions R5 Backport permite serverelor R4 să ofere noul model.
R4: abonamente bazate pe criterii
În FHIR R4, un abonament se bazează pe criterii: clientul creează o resursă Subscription ale cărei criterii sunt un șir de căutare precum Observation?code=…&patient=… și al cărei canal este rest-hook, websocket, email, sms sau message. Serverul evaluează criteriile la fiecare creare și actualizare și trimite fiecare resursă corespunzătoare, sau o notificare goală, către endpoint.
{
"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>"]
}
}
Serverul evaluează criteriile la fiecare creare și actualizare. Când o resursă se potrivește, o trimite prin POST la punctul final (sau trimite un corp gol dacă payload este omis, astfel încât clientul să preia singur resursa). A funcționat, dar cu trei probleme: serverele nu puteau spune ce criterii suportau, clienții nu puteau distinge o notificare ratată de o perioadă de liniște, iar „o resursă a corespuns unei căutări” nu este același lucru cu „a avut loc un eveniment” (sfârșitul unui Encounter nu poate fi exprimat ca o căutare).
R4B și R5: abonamente bazate pe topicuri
În FHIR R4B și R5, abonamentele se bazează pe topicuri. Serverul publică resurse SubscriptionTopic care descriu evenimente (resursa, un declanșator precum creare, actualizare, ștergere sau o condiție FHIRPath și filtre permise). Un abonat creează un Subscription care indică un topic cu valori filterBy, un tip de canal, un endpoint, o perioadă de heartbeat și o setare de conținut de tip gol, doar ID sau resursă completă.
SubscriptionTopic este o resursă publicată de server, care descrie un eveniment: ce resursă, ce declanșator (creare, actualizare, ștergere sau o condiție FHIRPath precum %previous.status != 'finished' and %current.status = 'finished') și ce filtre poate folosi un abonat. Apoi, abonatul creează o Subscription care indică topicul:
{
"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 alege cât de mult este transmis: empty (doar evenimentul), id-only (referințe, preia restul cu propria autorizație) sau full-resource. heartbeatPeriod face ca serverul să trimită un heartbeat, astfel încât tăcerea să fie detectabilă.
Cum arată o notificare
O notificare de abonament FHIR este un Bundle de tip subscription-notification al cărui prim element este o resursă SubscriptionStatus care oferă abonamentul, topicul, tipul notificării (handshake, heartbeat, event-notification, query-status sau query-event) și un contor eventsSinceSubscriptionStart pentru detectarea evenimentelor ratate. Elementele ulterioare transportă resursele modificate sau referințele acestora, în funcție de setarea de conținut.
Fiecare notificare este un Bundle de tip subscription-notification. Prima sa intrare este o SubscriptionStatus cu referința abonamentului, topicul, tipul notificării (handshake, heartbeat, event-notification, query-status, query-event) și un contor eventsSinceSubscriptionStart; o pauză în contor înseamnă un eveniment ratat, iar clientul poate apela $events pentru a-l recupera. Intrările ulterioare transportă resursele sau referințele lor, în funcție de content.
Canale: rest-hook (serverul trimite prin POST la punctul final HTTPS al dvs.), websocket (clientul se conectează și primește notificări pe socket, util pentru aplicațiile de browser), email (doar notificare, nu date), message (un Bundle de mesagerie FHIR). Canalul R4 sms a fost eliminat.
Rularea în producție
Rularea abonamentelor FHIR în producție necesită gestionare idempotentă cheiată pe numărul evenimentului și versiunea resursei, securitate la nivel de endpoint care verifică expeditorul și nu tratează niciodată payload-ul ca autorizație, toleranță pentru bundle-uri grupate cu multe evenimente, un răspuns 2xx la notificarea inițială de handshake și conștientizarea faptului că mulți servere încă limitează abonamentele la serviciile backend, mai degrabă decât la aplicațiile pacienților.
- Idempotență. Notificările pot fi duplicate după o reîncercare; cheia este numărul evenimentului și versiunea resursei.
- Securitate. Punctul final trebuie să verifice expeditorul (un antet cu secret partajat, TLS mutual sau semnături) și nu trebuie să aibă încredere niciodată în payload pentru autorizare; preluați date sensibile de la server cu propriul token atunci când
contentesteid-only. - Backpressure. Serverele grupează evenimentele și respectă
maxCount; clienții trebuie să accepte bundle-uri cu multe evenimente. - Handshake. La activare, serverul trimite o notificare
handshakeși așteaptă un 2xx; în caz contrar, abonamentul trece laerror. - Scopes. SMART on FHIR a adăugat scopes de abonament lent; multe servere încă restricționează abonamentele la servicii backend (credințiale client) mai degrabă decât la aplicații pentru pacienți.
Webhooks care nu sunt abonamente FHIR
Webhooks care nu sunt abonamente FHIR sunt mecanisme simple de platformă: înregistrați un URL HTTPS și primiți evenimente JSON semnate, cum ar fi resurse scrise sau consimțământ modificat, fără niciun SubscriptionTopic. Anpheros oferă astfel de webhooks. Aceștia sunt mai simpli pentru o singură platformă, dar nu pot fi descoperiți de un client FHIR generic, astfel încât integrările care trebuie să funcționeze cu orice server FHIR utilizează abonamente.
Multe platforme, inclusiv Anpheros, oferă webhooks simple: înregistrați un URL HTTPS și primiți evenimente JSON semnate, cum ar fi resursă scrisă, consimțământ modificat, document finalizat. Acestea rezolvă aceeași nevoie cu mai puțină ceremonie și fără SubscriptionTopic, și nu sunt resurse FHIR, deci un client FHIR generic nu le poate descoperi. Dacă integrarea dvs. trebuie să funcționeze pe orice server FHIR, utilizați Subscriptions; dacă vizează o singură platformă, webhooks-urile sale sunt de obicei mai simple. Anpheros își documentează webhooks-urile pe site-ul pentru dezvoltatori (link mai jos).
Pagini conexe
- FHIR R4 vs R5
- Căutarea FHIR explicată
- FHIR Bundle explicat
- CDS Hooks explicat
- Monitorizarea la distanță a pacienților cu FHIR
- Webhooks Anpheros (dezvoltatori)
Surse
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus și notificări
- HL7 FHIR R4: Subscription
- Ghid de implementare Subscriptions R5 Backport
Întrebări frecvente
Pot folosi abonamentele în stil R5 pe un server R4?
Da, dacă serverul implementează ghidul de implementare Subscriptions R5 Backport, care codifică topicul, filtrele și setările canalului ca extensii pe resursa R4 Subscription și utilizează Bundle-uri R4 pentru notificări.
Care este diferența dintre o Subscription și polling cu _lastUpdated?
Polling întreabă serverul în mod repetat și nu ratează nimic, dar este lent și ineficient; Subscriptions împinge evenimentele pe măsură ce apar. Clienții robuști combină ambele: abonați-vă pentru viteză, faceți polling sau apelați $events pentru a recupera după întreruperi.
Notificarea conține datele?
Doar dacă content este full-resource. Implicitul mai sigur este id-only: notificarea vă spune ce resursă s-a modificat și o preluați cu propria autorizație.
Sunt FHIR Subscriptions aceleași cu webhooks?
O rest-hook subscription este un webhook cu o formă definită de FHIR: topicuri descoperibile, bundle-uri de notificare standard și urmărirea stării. Webhooks-urile simple oferite de o platformă fac același lucru doar pentru acea platformă.
Încearcă gratuit în sandbox
Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.
Gratuit · 30 de pacienți sintetici · fără card
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →