Rövid válasz: A Subscription (előfizetés) megmondja egy FHIR szervernek, hogy értesítsen egy adott végpontot, amikor az adott feltételeknek megfelelő erőforrások megváltoznak. FHIR R4 verzióban a feltételek egy keresési sztring (criteria: "Observation?patient=123&code=85354-9"), és a szerver az illeszkedő erőforrást egy REST hook-nak, websocket-nek, e-mail-nek vagy FHIR üzenetnek küldi el. R4B és R5 verziókban a modell a SubscriptionTopic köré épült újjá: a szerver közzéteszi azokat az eseményeket, amelyekről értesíteni tud, az ügyfél feliratkozik egy témára szűrőkkel, és az értesítések egy subscription-notification típusú Bundle-ként érkeznek, amely mindig egy SubscriptionStatus erőforrással kezdődik. A Subscriptions R5 Backport implementációs útmutató lehetővé teszi az R4 szerverek számára az új modell kínálását.
R4: feltétel-alapú előfizetések
FHIR R4-ben az Előfizetés (Subscription) feltétel-alapú: az ügyfél létrehoz egy Előfizetés erőforrást, amelynek feltétele egy keresési sztring, például Observation?code=…&patient=…, és a csatornája rest-hook, websocket, email, sms vagy message. A szerver kiértékeli a feltételt minden létrehozott és frissített erőforrásra, és minden egyező erőforrást, vagy egy üres értesítést küld a végpontra.
{
"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>"]
}
}
A szerver minden létrehozásnál és frissítésnél kiértékeli a feltételt. Amikor egy erőforrás illeszkedik, POST kéréssel elküldi a végpontra (vagy POST kéréssel üres törzset küld, ha a payload el van hagyva, így az ügyfél maga tölti le az erőforrást). Ez működött, de három problémával: a szerverek nem tudták megmondani, mely feltételeket támogatják, az ügyfelek nem tudták megkülönböztetni az elmulasztott értesítést egy csendes időszaktól, és "egy erőforrás megfelelt egy keresésnek" nem ugyanaz, mint "egy esemény történt" (egy Találkozó befejezése nem fejezhető ki keresésként).
R4B és R5: téma-alapú előfizetések
FHIR R4B és R5-ben az előfizetések téma-alapúak. A szerver közzétesz SubscriptionTopic erőforrásokat, amelyek eseményeket írnak le (az erőforrás, egy kiváltó ok, mint például létrehozás, frissítés, törlés, vagy egy FHIRPath feltétel, és az engedélyezett szűrők). Az előfizető létrehoz egy előfizetést, amely egy témára mutat, filterBy értékekkel, csatornatípussal, végponttal, szívverés periódussal és egy tartalombeállítással (empty, id-only vagy full-resource).
A SubscriptionTopic egy erőforrás, amelyet a szerver tesz közzé, és amely egy eseményt ír le: melyik erőforrás, melyik trigger (létrehozás, frissítés, törlés, vagy egy FHIRPath feltétel, mint például %previous.status != 'finished' and %current.status = 'finished'), és mely szűrőket használhat a feliratkozó. A feliratkozó ezután létrehoz egy Subscription-t, amely a témára mutat:
{
"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"
}
A content kiválasztja, mennyi adat utazik: empty (csak az esemény), id-only (hivatkozások, a többit a saját engedélyeddel töltsd le), vagy full-resource. A heartbeatPeriod arra készteti a szervert, hogy szívverést küldjön, így a csend érzékelhető.
Milyen egy értesítés
Egy FHIR előfizetési értesítés egy subscription-notification típusú Bundle, amelynek első bejegyzése egy SubscriptionStatus erőforrás, amely megadja az előfizetést, a témát, az értesítés típusát (handshake, heartbeat, event-notification, query-status vagy query-event) és egy eventsSinceSubscriptionStart számlálót az elmaradt események észleléséhez. További bejegyzések tartalmazzák a megváltozott erőforrásokat vagy azok hivatkozásait, a tartalombeállítástól függően.
Minden értesítés egy subscription-notification típusú Bundle. Az első bejegyzése egy SubscriptionStatus, amely tartalmazza az előfizetés hivatkozását, a témát, az értesítés típusát (handshake, heartbeat, event-notification, query-status, query-event) és egy eventsSinceSubscriptionStart számlálót; a számlálóban lévő rés azt jelenti, hogy egy esemény kimaradt, és az ügyfél meghívhatja a $events funkciót a helyreállításhoz. További bejegyzések tartalmazzák az erőforrásokat vagy azok hivatkozásait, a content beállítástól függően.
Csatornák: rest-hook (a szerver POST kérést küld a HTTPS végpontodra), websocket (az ügyfél csatlakozik és értesítéseket kap a socketen, böngészőalkalmazásokhoz hasznos), email (csak értesítés, adat nem), message (egy FHIR üzenetküldő Bundle). Az R4 sms csatornát elhagyták.
Futás éles környezetben
A FHIR előfizetések éles környezetben történő futtatása megköveteli az eseményszám és az erőforrás verzió alapján történő idempotens kezelést, a végpont biztonságát, amely ellenőrzi a küldőt, és soha nem kezeli a hasznos adatot engedélyként, a kötegelt csomagok toleranciáját sok eseménnyel, a 2xx válasz az első üdvözlő értesítésre, és a tudatosságot, hogy sok szerver továbbra is korlátozza az előfizetéseket a háttérszolgáltatásokra, nem pedig a betegalkalmazásokra.
- Idempotencia. Az értesítések megkettőződhetnek egy újrapróbálkozás után; kulcsold az eseményszámot és az erőforrás verzióját.
- Biztonság. A végpontnak ellenőriznie kell a feladót (megosztott titkos fejléc, kölcsönös TLS vagy aláírások), és soha nem szabad megbíznia a törzsben mint engedélyezésben; érzékeny adatokat a szerverről a saját tokeneddel tölts le, ha a
contentid-only. - Backpressure. A szerverek kötegelik az eseményeket és tiszteletben tartják a
maxCountértéket; az ügyfeleknek el kell fogadniuk sok eseményt tartalmazó Bundle-eket. - Kézfogás. Aktiváláskor a szerver küld egy
handshakeértesítést és 2xx választ vár; ellenkező esetben az előfizetéserrorállapotba kerül. - Hatókörök. A SMART on FHIR lassan adta hozzá az előfizetési hatóköröket; sok szerver továbbra is az előfizetéseket backend szolgáltatásokra (ügyfél hitelesítő adatok) korlátozza, nem pedig páciens alkalmazásokra.
Webhookok, amelyek nem FHIR előfizetések
A webhookok, amelyek nem FHIR előfizetések, egyszerű platformmechanizmusok: regisztrál egy HTTPS URL-t, és aláírt JSON eseményeket kap, mint például erőforrás írása vagy hozzájárulás módosítása, SubscriptionTopic nélkül. Az Anpheros kínál ilyen webhookokat. Ezek egyszerűbbek egy platform számára, de nem fedezhetők fel egy általános FHIR klienssel, így azok az integrációk, amelyeknek bármely FHIR szerverrel kell működniük, előfizetéseket használnak.
Számos platform, köztük az Anpheros is, egyszerű webhookokat kínál: regisztrálsz egy HTTPS URL-t, és aláírt JSON eseményeket kapsz, mint például erőforrás írása, hozzájárulás módosítása, dokumentum véglegesítése. Ezek ugyanazt az igényt elégítik ki kevesebb ceremóniával és SubscriptionTopic nélkül, és nem FHIR erőforrások, így egy általános FHIR ügyfél nem tudja őket felfedezni. Ha az integrációnak bármilyen FHIR szerverrel kell működnie, használj Előfizetéseket; ha egy platformot céloz meg, annak webhookjai általában egyszerűbbek. Az Anpheros a webhookjait a fejlesztői oldalon dokumentálja (a link lentebb található).
Kapcsolódó oldalak
- FHIR R4 vs R5
- FHIR keresés magyarázata
- FHIR Bundle magyarázata
- CDS Hooks magyarázata
- Távoli betegmegfigyelés FHIR-rel
- Anpheros webhookok (fejlesztőknek)
Források
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus és értesítések
- HL7 FHIR R4: Subscription
- Subscriptions R5 Backport implementációs útmutató
Gyakori kérdések
Használhatom az R5 stílusú előfizetéseket egy R4 szerveren?
Igen, ha a szerver implementálja a Subscriptions R5 Backport implementációs útmutatót, amely a témát, a szűrőket és a csatorna beállításokat kiterjesztésekként kódolja az R4 Subscription erőforráson, és R4 Bundle-eket használ az értesítésekhez.
Mi a különbség az Előfizetés és a _lastUpdated-del történő lekérdezés között?
A lekérdezés ismételten kérdezi a szervert, és nem hagy ki semmit, de lassú és pazarló; az Előfizetések push módon küldik az eseményeket, ahogy megtörténnek. A robusztus ügyfelek mindkettőt kombinálják: előfizetnek a sebességért, lekérdeznek vagy meghívják a $events funkciót az állásidő utáni helyreállításhoz.
Az értesítés tartalmazza az adatokat?
Csak akkor, ha a tartalom full-resource. A biztonságosabb alapértelmezés az id-only: az értesítés megmondja, melyik erőforrás változott, és te töltöd le a saját engedélyeddel.
A FHIR Előfizetések ugyanazok, mint a webhookok?
Egy rest-hook előfizetés egy webhook FHIR-definícióval: felfedezhető témák, szabványos értesítési Bundle-ek és állapotkövetés. Egy platform által kínált egyszerű webhookok ugyanazt a feladatot látják el csak az adott platformon.
Próbálja ki ingyen a sandboxban
Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.
Ingyenes · 30 szintetikus beteg · kártya nélkül
Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.
Tudj meg többet az Anpherosról →