Publish Box goes here

Implementation Notes

Implementation Notes

The prototype is implemented as one Kotlin/Ktor process so that both roles and the mock source system can be inspected together. In deployment these responsibilities can be split.

Runtime Components

• Subscriber adapter role: asks for subscriptions and receives REST-hook notifications.
• Source adapter role: manages supported topics, subscriptions, notifications and pull retrieval.
• Mock source system: exposes minimal FHIR data and sends simple event signals to the adapter.
• Demo UI: shows both roles, active subscriptions, source events, received notifications and transport log entries.

The implementation uses HAPI FHIR R4 for typed FHIR resources and JSON serialization.

Code Structure

• TopicCatalog defines supported topics.
• SubscriptionRegistry owns lifecycle state and deduplicates by endpoint, topic and patient.
• NotificationFactory builds R4 Backport notification bundles.
• HeartFailureFixtures creates sample source-system resources.
• SubscriberInbox receives notifications and executes the pull.
• Servers wires HTTP routes for the UI, source adapter, subscriber adapter and mock source system.

Integration Pattern

The adapter keeps the complex exchange protocol at the boundary:

• outside: FHIR R4 Subscription Backport and notified pull;
• inside: small local HTTP calls and simple FHIR searches.

This is the main design point. Existing care systems can integrate by exposing the minimum local contract instead of implementing the full subscription lifecycle.

Data Scope In The Prototype

The heart-failure event contains:

• one Observation for body weight;
• one QuestionnaireResponse for symptoms and daily status;
• patient references for scoping.

The notified-pull response returns the resources for the event notification id. It does not return all patient resources.

Production Gaps

This is a prototype. It does not implement production:

• authentication or mTLS;
• endpoint trust management;
• authorization and consent checks;
• durable subscription storage;
• durable event storage;
• retry queues;
• replay windows;
• dead-letter handling;
• endpoint allowlisting;
• profile validation against national packages;
• topic governance;
• audit export;
• operational monitoring.

These concerns belong around the same adapter boundaries shown here. They should not be pushed into source systems that only provide care data or into receiving systems that only process pulled event content.