Publish Box goes here

Notify Pull Flow

Notify Pull Flow

The adapter uses the R4 shape from the HL7 Subscriptions R5 Backport IG. This lets R4 systems use the Subscription concepts from later FHIR versions without requiring native R5 support.

• topic discovery is exposed as R4 Basic resources;
• subscription negotiation uses FHIR R4 Subscription plus backport extensions;
• notifications are Bundle.type = history;
• the first bundle entry is a Parameters resource representing backported SubscriptionStatus;
• notified pull uses a related-query part in notification-event.

Sequence

subscriber system
  -> local subscribe request
subscriber adapter
  -> FHIR Subscription
source adapter
  -> handshake notification
subscriber adapter

source system
  -> simple event signal
source adapter
  -> event notification with related-query
subscriber adapter
  -> GET related-query
source adapter
  -> event-specific FHIR Bundle
subscriber adapter
  -> local received event data
subscriber system

Notification Content

The notification does not include the medical content. It includes enough context to let the receiver perform a pull:

• subscription reference;
• topic canonical;
• notification type;
• event number;
• timestamp;
• focus reference;
• related query URL.

The example related query is:

GET /source-adapter/fhir/$notify-pull?notification-id={notification-id}

Pull Response

The source adapter role queries the source-system FHIR API by notification-id and returns a FHIR searchset Bundle containing only the data elements for that event:

• body-weight Observation;
• symptom QuestionnaireResponse.

The pull response is intentionally event-specific. It should not return all resources for the patient. This keeps event notifications small and makes replay/audit behavior easier to reason about.

Subscription Matching

The source adapter matches source events to subscriptions by:

• topic;
• patient;
• active subscription status.

The prototype stores patient scope on the subscription. A production topic may define additional filters, but patient-level scope is the minimum for this example.

Duplicate Requests

Creating the same subscription again for the same endpoint, topic and patient returns the existing subscription. The source adapter does not create another active subscription and does not send another handshake.

This makes subscription creation safe to retry.

Why Notify Pull

Notify pull is useful when:

• notifications should not carry clinical payloads;
• the receiver should fetch data only when ready;
• the source wants to enforce authorization at pull time;
• event content may need to be assembled from multiple source resources;
• payload size and retry behavior must stay predictable.

In production, the pull query must be governed by active relationship, consent, authorization, replay policy, endpoint identity and source-system audit.