Коротка відповідь: Subscription (Підписка) повідомляє FHIR-серверу сповістити цей кінцевий пункт, коли ресурси, що відповідають цим умовам, зміняться. У FHIR R4 умови — це пошуковий рядок (criteria: "Observation?patient=123&code=85354-9"), і сервер надсилає відповідний ресурс через REST hook, websocket, електронну пошту або FHIR-повідомлення. У R4B та R5 модель була перебудована навколо SubscriptionTopic: сервер публікує події, про які він може сповіщати, клієнт підписується на тему з фільтрами, а сповіщення надходять як Bundle типу subscription-notification, який завжди починається з ресурсу SubscriptionStatus. Посібник з реалізації Subscriptions R5 Backport дозволяє серверам R4 пропонувати нову модель.
R4: підписки на основі критеріїв
У FHIR R4 підписка (Subscription) базується на критеріях: клієнт створює ресурс Subscription, критеріями якого є пошуковий рядок, наприклад Observation?code=…&patient=…, а каналом – rest-hook, websocket, email, sms або message. Сервер оцінює критерії для кожного створеного або оновленого ресурсу та надсилає відповідний ресурс або порожнє сповіщення на кінцеву точку.
{
"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>"]
}
}
Сервер оцінює критерії для кожного створення та оновлення. Коли ресурс відповідає, він надсилає його до кінцевого пункту (або надсилає порожнє тіло, якщо payload пропущено, тоді клієнт отримує ресурс самостійно). Це працювало, але з трьома проблемами: сервери не могли сказати, які критерії вони підтримують, клієнти не могли відрізнити пропущене сповіщення від періоду тиші, а "ресурс відповідав пошуку" — це не те саме, що "відбулася подія" (завершення Encounter неможливо виразити як пошук).
R4B та R5: підписки на основі тем
У FHIR R4B та R5 підписки базуються на темах. Сервер публікує ресурси SubscriptionTopic, що описують події (ресурс, тригер, як-от створення, оновлення, видалення, або умова FHIRPath, та дозволені фільтри). Підписник створює підписку, що вказує на тему з значеннями filterBy, тип каналу, кінцеву точку, період пульсу та налаштування вмісту: порожній, лише ідентифікатор або повний ресурс.
SubscriptionTopic — це ресурс, який публікує сервер, описуючи подію: який ресурс, який тригер (створення, оновлення, видалення або умова FHIRPath, як-от %previous.status != 'finished' and %current.status = 'finished'), і які фільтри може використовувати абонент. Потім абонент створює Підписку, яка вказує на тему:
{
"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 вибирає, скільки даних передається: empty (тільки подія), id-only (посилання, отримайте решту за допомогою власної авторизації) або full-resource. heartbeatPeriod змушує сервер надсилати сигнал пульсу, щоб можна було виявити тишу.
Як виглядає сповіщення
Сповіщення про FHIR-підписку – це Bundle типу subscription-notification, перший запис якого містить ресурс SubscriptionStatus, що надає інформацію про підписку, тему, тип сповіщення (handshake, heartbeat, event-notification, query-status або query-event) та лічильник eventsSinceSubscriptionStart для виявлення пропущених подій. Наступні записи містять змінені ресурси або їхні посилання, залежно від налаштування вмісту.
Кожне сповіщення — це Bundle типу subscription-notification. Його перший запис — це SubscriptionStatus із посиланням на підписку, темою, типом сповіщення (handshake, heartbeat, event-notification, query-status, query-event) та лічильником eventsSinceSubscriptionStart; пропуск у лічильнику означає пропущену подію, і клієнт може викликати $events для її відновлення. Наступні записи містять ресурси або їхні посилання, залежно від content.
Канали: rest-hook (сервер надсилає POST-запити на ваш HTTPS-кінцевий пункт), websocket (клієнт підключається та отримує сповіщення через сокет, корисно для браузерних програм), email (тільки сповіщення, без даних), message (FHIR-повідомлення Bundle). Канал R4 sms було видалено.
Використання в продакшені
Запуск FHIR Subscriptions у продакшені вимагає ідемпотентної обробки за номером події та версією ресурсу, безпеки кінцевої точки, яка перевіряє відправника і ніколи не розглядає вміст як дозвіл, стійкості до пакетних Bundle з багатьма подіями, відповіді 2xx на початкове сповіщення handshake та усвідомлення того, що багато серверів досі обмежують підписки для бекенд-сервісів, а не для додатків пацієнтів.
- Ідемпотентність. Сповіщення можуть дублюватися після повторної спроби; використовуйте номер події та версію ресурсу як ключ.
- Безпека. Кінцевий пункт повинен перевіряти відправника (заголовок спільного секрету, взаємний TLS або підписи) і ніколи не повинен довіряти вмісту як авторизації; отримуйте конфіденційні дані назад із сервера за допомогою власного токена, коли
contentмає значенняid-only. - Зворотний тиск. Сервери групують події та поважають
maxCount; клієнти повинні приймати пакети з багатьма подіями. - Рукостискання. Після активації сервер надсилає сповіщення
handshakeі очікує відповіді 2xx; інакше підписка переходить у станerror. - Області дії. SMART on FHIR повільно додавав області дії підписок; багато серверів досі обмежують підписки для бекенд-сервісів (облікові дані клієнта), а не для додатків пацієнтів.
Вебхуки, які не є FHIR-підписками
Вебхуки, які не є FHIR Subscriptions, – це стандартні механізми платформи: ви реєструєте HTTPS URL і отримуєте підписані JSON-події, такі як запис ресурсу або зміна згоди, без будь-яких SubscriptionTopic. Anpheros пропонує такі вебхуки. Вони простіші для однієї платформи, але не можуть бути виявлені загальним FHIR-клієнтом, тому інтеграції, які мають працювати з будь-яким FHIR-сервером, використовують Subscriptions.
Багато платформ, включаючи Anpheros, пропонують звичайні вебхуки: ви реєструєте HTTPS-URL і отримуєте підписані JSON-події, такі як запис ресурсу, зміна згоди, завершення документа. Вони вирішують ту саму потребу з меншою кількістю церемоній і без SubscriptionTopic, і вони не є FHIR-ресурсами, тому загальний FHIR-клієнт не може їх виявити. Якщо ваша інтеграція повинна працювати з будь-яким FHIR-сервером, використовуйте Підписки; якщо вона націлена на одну платформу, її вебхуки зазвичай простіші. Anpheros документує свої вебхуки на сайті для розробників (посилання нижче).
Пов'язані сторінки
- FHIR R4 проти R5
- Пояснення пошуку FHIR
- Пояснення FHIR Bundle
- Пояснення CDS Hooks
- Дистанційний моніторинг пацієнтів за допомогою FHIR
- Вебхуки Anpheros (для розробників)
Джерела
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus та сповіщення
- HL7 FHIR R4: Subscription
- Посібник з реалізації Subscriptions R5 Backport
Поширені запитання
Чи можу я використовувати підписки в стилі R5 на сервері R4?
Так, якщо сервер реалізує посібник з реалізації Subscriptions R5 Backport, який кодує тему, фільтри та налаштування каналу як розширення ресурсу R4 Subscription і використовує R4 Bundles для сповіщень.
Яка різниця між підпискою та опитуванням з _lastUpdated?
Опитування багаторазово запитує сервер і нічого не пропускає, але це повільно та марнотратно; Підписки надсилають події в міру їх виникнення. Надійні клієнти поєднують обидва методи: підписуються для швидкості, опитують або викликають $events для відновлення після простою.
Чи містить сповіщення дані?
Тільки якщо content має значення full-resource. Безпечнішим стандартним значенням є id-only: сповіщення повідомляє вам, який ресурс змінився, і ви отримуєте його за допомогою власної авторизації.
Чи є FHIR-підписки тим самим, що й вебхуки?
Підписка rest-hook — це вебхук із визначеною FHIR формою: теми, які можна виявити, стандартні пакети сповіщень та відстеження статусу. Звичайні вебхуки, що пропонуються платформою, виконують ту саму функцію лише для цієї платформи.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →