簡単な説明: Subscription は、FHIRサーバーに対して「これらの条件に一致するリソースが変更されたら、このエンドポイントに通知してください」と伝えるものです。FHIR R4 では、条件は検索文字列 (criteria: "Observation?patient=123&code=85354-9") で、サーバーは一致したリソースをRESTフック、websocket、メール、またはFHIRメッセージで送信します。R4BおよびR5 では、モデルは SubscriptionTopic を中心に再構築されました。サーバーは通知可能なイベントを発行し、クライアントはフィルターを使用してトピックを購読し、通知は常に SubscriptionStatus リソースで始まる subscription-notification タイプ のBundleとして届きます。Subscriptions R5 Backport 実装ガイドにより、R4サーバーでも新しいモデルを提供できます。
R4: criteriaベースのサブスクリプション
FHIR R4では、サブスクリプションは基準に基づいています。クライアントは、Observation?code=…&patient=…のような検索文字列を基準とし、チャネルをrest-hook、websocket、email、sms、またはmessageとするSubscriptionリソースを作成します。サーバーは、作成および更新のたびに基準を評価し、一致した各リソース、または空の通知をエンドポイントにPOSTします。
{
"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>"]
}
}
サーバーは、すべての作成と更新に対して基準を評価します。リソースが一致すると、それをエンドポイントにPOSTします（payload が省略されている場合は空のボディをPOSTするため、クライアントはリソース自体を取得します）。これは機能しましたが、3つの問題がありました。サーバーはどの基準をサポートしているかを伝えることができず、クライアントは通知の欠落と静かな期間を区別できず、「リソースが検索に一致した」ということは「イベントが発生した」ということと同じではありません（Encounterの 終了 は検索として表現できません）。
R4BおよびR5: topicベースのサブスクリプション
FHIR R4BおよびR5では、サブスクリプションはトピックに基づいています。サーバーは、イベント（リソース、作成、更新、削除などのトリガー、またはFHIRPath条件）と許可されたフィルターを記述するSubscriptionTopicリソースを発行します。購読者は、filterByの値、チャネルタイプ、エンドポイント、ハートビート期間、およびempty、id-only、full-resourceのいずれかのコンテンツ設定を持つトピックを指すSubscriptionを作成します。
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サブスクリプション通知は、subscription-notificationタイプのBundleであり、最初のエントリはサブスクリプション、トピック、通知タイプ（handshake、heartbeat、event-notification、query-status、またはquery-event）、および見逃したイベントを検出するためのeventsSinceSubscriptionStartカウンターを提供するSubscriptionStatusリソースです。後続のエントリは、コンテンツ設定に応じて、変更されたリソースまたはその参照を運びます。
すべての通知は、タイプ subscription-notification のBundleです。最初の項目は、サブスクリプションの参照、トピック、通知のタイプ（handshake、heartbeat、event-notification、query-status、query-event）、および eventsSinceSubscriptionStart カウンターを持つ SubscriptionStatus です。カウンターのギャップはイベントの欠落を意味し、クライアントは $events を呼び出して回復できます。content に応じて、さらに項目がリソースまたはその参照を運びます。
チャネル：rest-hook（サーバーがHTTPSエンドポイントにPOSTします）、websocket（クライアントが接続し、ソケットで通知を受信します。ブラウザアプリに便利です）、email（通知のみ、データなし）、message（FHIRメッセージングBundle）。R4の sms チャネルは廃止されました。
本番環境での実行
本番環境でFHIRサブスクリプションを実行するには、イベント番号とリソースバージョンをキーとするべき等処理、送信者を検証しペイロードを決して認証として扱わないエンドポイントセキュリティ、多数のイベントを含むバッチ処理されたBundleへの耐性、初期ハンドシェイク通知への2xx応答、および多くのサーバーが依然としてサブスクリプションを患者アプリではなくバックエンドサービスに限定しているという認識が必要です。
- べき等性。 通知はリトライ後に重複する可能性があります。イベント番号とリソースバージョンをキーにしてください。
- セキュリティ。 エンドポイントは送信者を検証する必要があります（共有シークレットヘッダー、相互TLS、または署名）。ペイロードを認証として決して信頼しないでください。
contentがid-onlyの場合は、ご自身のトークンを使用してサーバーから機密データを取得してください。 - バックプレッシャー。 サーバーはイベントをバッチ処理し、
maxCountを尊重します。クライアントは多くのイベントを含むバンドルを受け入れる必要があります。 - ハンドシェイク。 アクティベーション時にサーバーは
handshake通知を送信し、2xxを期待します。それ以外の場合、サブスクリプションはerrorに移行します。 - スコープ。 SMART on FHIR はサブスクリプションスコープをゆっくりと追加しました。多くのサーバーは依然として、患者アプリではなくバックエンドサービス（クライアント認証情報）にサブスクリプションを制限しています。
FHIRサブスクリプションではないWebhook
FHIRサブスクリプションではないWebhookは、プレーンなプラットフォームメカニズムです。HTTPS URLを登録すると、SubscriptionTopicなしで、リソースの書き込みや同意の変更などの署名付きJSONイベントを受信します。AnpherosはこのようなWebhookを提供しています。これらは1つのプラットフォームにとってはよりシンプルですが、汎用的なFHIRクライアントでは検出できないため、任意のFHIRサーバーに対して機能する必要がある統合ではサブスクリプションを使用します。
Anpherosを含む多くのプラットフォームは、通常のWebhookを提供しています。HTTPS URLを登録すると、リソース書き込み、同意変更、ドキュメント最終化 などの署名付きJSONイベントを受信します。これらは、より少ない手順とSubscriptionTopicなしで同じニーズを満たし、FHIRリソースではないため、汎用FHIRクライアントでは検出できません。統合が任意のFHIRサーバーで機能する必要がある場合は、Subscriptionsを使用してください。特定のプラットフォームを対象とする場合は、そのWebhookの方が通常シンプルです。Anpherosは開発者サイト（下記リンク）でWebhookを文書化しています。
関連ページ
資料
- HL7 FHIR R5: Subscription
- HL7 FHIR R5: SubscriptionTopic
- HL7 FHIR R5: SubscriptionStatus and notifications
- HL7 FHIR R4: Subscription
- Subscriptions R5 Backport 実装ガイド
よくある質問
R4サーバーでR5スタイルのサブスクリプションを使用できますか？
はい、サーバーがSubscriptions R5 Backport実装ガイドを実装している場合、R4 Subscriptionリソースの拡張機能としてトピック、フィルター、チャネル設定をエンコードし、通知にR4 Bundleを使用します。
Subscriptionと_lastUpdatedによるポーリングの違いは何ですか？
ポーリングはサーバーに繰り返し問い合わせ、何も見逃しませんが、遅く無駄が多いです。Subscriptionはイベントが発生するとプッシュします。堅牢なクライアントは両方を組み合わせます。速度のためにサブスクライブし、ダウンタイム後に回復するためにポーリングまたは$eventsを呼び出します。
通知にはデータが含まれますか？
contentがfull-resourceの場合のみです。より安全なデフォルトはid-onlyです。通知はどのリソースが変更されたかを伝え、ご自身の認証でそれを取得します。
FHIR SubscriptionはWebhookと同じですか？
rest-hookサブスクリプションは、FHIRで定義された形式のWebhookです。検出可能なトピック、標準的な通知バンドル、ステータストラッキングを備えています。プラットフォームが提供する通常のWebhookは、そのプラットフォームのみで同じジョブを実行します。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →