Publish Box goes here

Home

Subscription Adapter Implementation Guide

This draft Implementation Guide documents an adapter for parties that supply or process care data, but do not want to implement the FHIR Subscription lifecycle themselves.

The adapter implements the FHIR R4 Subscription Backport pattern at the network boundary. Behind that boundary, existing care systems integrate through small, explicit HTTP or FHIR calls. This keeps the subscription protocol out of systems that only need to publish events or consume data.

The same adapter implementation can run in two roles:

• Source adapter role: placed in front of a source system or EPD. It exposes FHIR topics and subscriptions, stores active subscriptions, receives simple source-system event signals, sends notifications and serves pull requests.
• Subscriber adapter role: placed in front of a receiving or processing party. It offers a simple local API to request subscriptions, receives FHIR notifications, executes the pull and exposes the received event data to the processing system.

The source system itself does not need to implement FHIR Subscription. It only needs to expose or provide the data elements that belong to an event, and it must notify the adapter when such an event is available.

The receiving system itself does not need to parse Subscription notification bundles or understand the R4 Backport shape. It can ask its local adapter to subscribe to a topic and patient, then consume pulled event data from the adapter.

Design rule

Notify is trigger, pull is truth.

The notification tells the subscriber role that event data is available. The subscriber role then performs a pull against the source adapter role. The medical content is retrieved in that pull response, not embedded in the notification itself.

This guide uses one practical example topic for primary exchange in heart-failure home monitoring:

https://fhir.cumuluz.org/subscription-topic/heart-failure-daily-check

The example event data contains:

• body weight as FHIR Observation;
• symptom and status context as FHIR QuestionnaireResponse.

What This Adapter Does

The adapter is responsible for:

• topic discovery;
• accepting and deduplicating subscription requests;
• storing active subscriptions by endpoint, topic and patient;
• performing the Subscription Backport handshake;
• matching source events to active subscriptions;
• sending event notifications;
• exposing a notified-pull endpoint;
• pulling or assembling event-specific FHIR resources from the source system;
• receiving notifications on the subscriber side;
• executing the pull and making the result visible to the receiving system.

The adapter is not responsible for:

• clinical decision logic;
• owning the source clinical record;
• long-term medical data storage;
• replacing source-system authorization, consent or audit;
• defining national topic governance;
• transforming every possible FHIR profile in this prototype.

How To Read This Guide

• Use Source Role Integration if you have an EPD, monitoring platform or other system that publishes care data.
• Use Subscriber Role Integration if you have an application, research pipeline, monitoring center or processing system that wants to receive event-driven care data.
• Use Notify Pull Flow for the protocol sequence over the line.
• Use Internal HTTP API for the simple local integration points implemented by this prototype.