إجابة مختصرة: Subscription (اشتراك) يخبر خادم FHIR بإخطار هذا العنوان عند تغيير الموارد التي تطابق هذه الشروط. في FHIR R4، الشروط هي سلسلة بحث (criteria: "Observation?patient=123&code=85354-9") ويرسل الخادم المورد المطابق إلى خطاف REST، أو websocket، أو بريد إلكتروني، أو رسالة FHIR. في R4B و R5، تم إعادة بناء النموذج حول SubscriptionTopic (موضوع الاشتراك): ينشر الخادم الأحداث التي يمكنه الإخطار بها، ويشترك العميل في موضوع مع عوامل تصفية، وتصل الإخطارات كـ Bundle من نوع subscription-notification يبدأ دائمًا بـ SubscriptionStatus (حالة الاشتراك). دليل التنفيذ Subscriptions R5 Backport يسمح لخوادم R4 بتقديم النموذج الجديد.
R4: اشتراكات قائمة على المعايير
في FHIR R4، يعتمد الاشتراك على المعايير: يقوم العميل بإنشاء مورد اشتراك (Subscription resource) تكون معاييره عبارة عن سلسلة بحث مثل Observation?code=…&patient=… وتكون قناته (channel) إما rest-hook أو websocket أو email أو sms أو message. يقوم الخادم بتقييم المعايير مقابل كل عملية إنشاء وتحديث، ويرسل كل مورد مطابق، أو إشعارًا فارغًا، إلى نقطة النهاية (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>"]
}
}
يقوم الخادم بتقييم المعايير عند كل إنشاء وتحديث. عندما يتطابق مورد، يقوم بإرساله إلى العنوان (أو يرسل جسمًا فارغًا إذا تم حذف payload، بحيث يقوم العميل بجلب المورد بنفسه). لقد نجح هذا، ولكن مع ثلاث مشاكل: لم تتمكن الخوادم من تحديد المعايير التي تدعمها، ولم يتمكن العملاء من التمييز بين إشعار مفقود وفترة هدوء، و"تطابق مورد مع بحث" ليس هو نفس "حدث ما" (لا يمكن التعبير عن انتهاء لقاء كبحث).
R4B و R5: اشتراكات قائمة على المواضيع
في FHIR R4B و R5، تعتمد الاشتراكات على المواضيع. يقوم الخادم بنشر موارد مواضيع الاشتراك (SubscriptionTopic resources) التي تصف الأحداث (المورد، مشغل مثل الإنشاء أو التحديث أو الحذف أو شرط FHIRPath، والمرشحات المسموح بها). يقوم المشترك بإنشاء اشتراك يشير إلى موضوع بقيم ترشيح (filterBy)، ونوع قناة (channel type)، ونقطة نهاية (endpoint)، وفترة نبضات قلب (heartbeat period)، وإعداد محتوى (content setting) يكون إما فارغًا (empty) أو معرفًا فقط (id-only) أو موردًا كاملاً (full-resource).
SubscriptionTopic (موضوع الاشتراك) هو مورد ينشره الخادم، يصف حدثًا: أي مورد، أي مشغل (إنشاء، تحديث، حذف، أو شرط FHIRPath مثل %previous.status != 'finished' and %current.status = 'finished')، وأي عوامل تصفية يمكن للمشترك استخدامها. ثم يقوم المشترك بإنشاء Subscription يشير إلى الموضوع:
{
"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 resource) الذي يعطي الاشتراك والموضوع ونوع الإشعار (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 messaging Bundle). تم إسقاط قناة R4 sms.
التشغيل في بيئة الإنتاج
يتطلب تشغيل اشتراكات FHIR في بيئة الإنتاج معالجة متطابقة (idempotent handling) مفتاحها هو رقم الحدث وإصدار المورد، وأمان نقطة النهاية الذي يتحقق من المرسل ولا يعامل الحمولة أبدًا على أنها تفويض، وتحمل للأحداث المجمعة (batched bundles) التي تحتوي على العديد من الأحداث، واستجابة 2xx للإشعار الأولي للمصافحة (handshake notification)، وإدراك أن العديد من الخوادم لا تزال تقصر الاشتراكات على الخدمات الخلفية بدلاً من تطبيقات المرضى.
- التطابق (Idempotency). يمكن تكرار الإخطارات بعد إعادة المحاولة؛ استخدم رقم الحدث وإصدار المورد كمفتاح.
- الأمان. يجب على العنوان التحقق من المرسل (رأس سر مشترك، أو TLS متبادل، أو توقيعات) ويجب ألا يثق أبدًا في الحمولة كتفويض؛ قم بجلب البيانات الحساسة مرة أخرى من الخادم باستخدام رمزك الخاص عندما يكون
contentهوid-only. - الضغط الخلفي (Backpressure). تقوم الخوادم بتجميع الأحداث وتحترم
maxCount؛ يجب على العملاء قبول الحزم التي تحتوي على العديد من الأحداث. - المصافحة (Handshake). عند التنشيط، يرسل الخادم إشعار
handshakeويتوقع استجابة 2xx؛ وإلا ينتقل الاشتراك إلىerror. - النطاقات (Scopes). أضاف SMART on FHIR نطاقات الاشتراك ببطء؛ لا تزال العديد من الخوادم تقيد الاشتراكات بالخدمات الخلفية (بيانات اعتماد العميل) بدلاً من تطبيقات المرضى.
خطافات الويب التي ليست اشتراكات FHIR
خطافات الويب (Webhooks) التي ليست اشتراكات FHIR هي آليات منصة بسيطة: تقوم بتسجيل عنوان URL لـ HTTPS وتتلقى أحداث JSON موقعة مثل كتابة مورد أو تغيير موافقة، دون أي موضوع اشتراك (SubscriptionTopic). تقدم Anpheros خطافات ويب كهذه. إنها أبسط لمنصة واحدة ولكن لا يمكن اكتشافها بواسطة عميل FHIR عام، لذا فإن عمليات التكامل التي يجب أن تعمل مع أي خادم FHIR تستخدم الاشتراكات.
تقدم العديد من المنصات، بما في ذلك Anpheros، خطافات ويب عادية: تقوم بتسجيل عنوان URL HTTPS وتتلقى أحداث 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 and notifications
- HL7 FHIR R4: Subscription
- Subscriptions R5 Backport implementation guide
الأسئلة الشائعة
هل يمكنني استخدام اشتراكات نمط R5 على خادم R4؟
نعم، إذا كان الخادم ينفذ دليل التنفيذ Subscriptions R5 Backport، والذي يقوم بتشفير الموضوع وعوامل التصفية وإعدادات القناة كملحقات على مورد R4 Subscription ويستخدم R4 Bundles للإخطارات.
ما الفرق بين الاشتراك والاستقصاء باستخدام _lastUpdated؟
الاستقصاء يطلب من الخادم بشكل متكرر ولا يفوت شيئًا ولكنه بطيء ومُهدر؛ تدفع الاشتراكات الأحداث فور حدوثها. يجمع العملاء الأقوياء بين الاثنين: اشترك للسرعة، واستقصِ أو استدعِ $events للاستعادة بعد فترة توقف.
هل يحتوي الإشعار على البيانات؟
فقط إذا كان المحتوى هو full-resource. الافتراضي الأكثر أمانًا هو id-only: يخبرك الإشعار بالمورد الذي تغير، وتقوم أنت بجلبها بتفويضك الخاص.
هل اشتراكات FHIR هي نفسها خطافات الويب؟
اشتراك rest-hook هو خطاف ويب بشكل FHIR محدد: مواضيع قابلة للاكتشاف، حزم إشعارات قياسية، وتتبع الحالة. خطافات الويب العادية التي تقدمها منصة ما تقوم بنفس المهمة لتلك المنصة فقط.
جرّبه مجانًا في بيئة الاختبار
أول طلب FHIR خلال 5 دقائق. واجهة برمجة تطبيقات HL7 FHIR R4 مع موافقة المريض مدمجة: جربها في بيئة الاختبار، ثم اربط تطبيقك الخاص أو نظام عيادتك.
مجاني · 30 مريضًا اصطناعيًا · دون بطاقة

