Use Cases

This section provides a structured overview of common scenarios where the Subscription Service enhances healthcare interoperability by enabling event-driven notifications. Each use case provides description of real life example and highlights high level interactions among the key actors - event source (Publisher), Subscription Service, and event consumer (Subscriber)

Use case diagram

UC Diagram Pub Sub

Actors

Following table provides a definition of the use case actors.

Actor Description
Subscriber The system requesting a subscription (e.g., EMR, public health system, home care system, patient portal).
Subscription Service Enables subscription management and real-time notifications to subscribed systems when relevant clinical or administrative events occur. It facilitates seamless data exchange between healthcare providers, systems, and stakeholders by ensuring timely delivery of critical updates, such as new lab results, medication dispenses, patient admissions, or care plan changes. managing subscriptions and event notifications.
Publisher System or entity responsible for generating and publishing events to a designated topic. It acts as the source of truth for specific types of data changes, such as new lab results, medication dispenses, or patient admissions.

Use Case 1: Create Subscription

Business context

The Subscriber relies on real-time notifications for relevant Events generated by the Publisher, enabling timely intervention, seamless continuity of care, and enhanced patient outcomes.

Example: A family physician (Subscriber) wants to subscribe to hospital admission events for his/hers registered patients generated by the HIS/EMRs (Publisher).

The Subscription Service enables the creation of subscriptions for specific event types (topics), ensuring that subscribers receive timely notifications whenever a publisher triggers an event.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Physician initiates a process to create subscription for admission events for his/hers patients.

•The clinic’s EMR system (or physician manually) submits a FHIR Subscription request to HALO layer. 
•The ONE ACCESS GATEWAY authenticates and validates the request and forwards it to SoFA Server.

Step 2: SoFA process Subscription interaction and forwards it to Ontario Health's Pub-Sub Service.

•SoFA process Create Subscription request and modifies the parameter as per SoFA specification.
•SoFA submits Create Subscription request to Subscription Service.

Step 3: Subscription Service creates subscription for requested event and returns status to the Subscribers system end point.

•Subscription service process request ansd returns response with Subscription ID and Status to designated channel end point indicated in the Create Subscription Request.

Use Case 2: Delete Subscription

Business context

The Subscriber relies on real-time notifications for relevant Events generated by the Publisher, enabling timely intervention, seamless continuity of care, and enhanced patient outcomes.

Example: A family physician (Subscriber) wants to delete subscription to hospital admission events for his/hers registered patients generated by the HIS/EMRs (Publisher).

The Subscription Service enables the lofical deletion of subscriptions for specific event types (topics), ensuring that subscribers will remove the subscription to stop receiveing notifications.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Physician initiates a process to delete subscription for admission events for his/hers patients

•The clinic’s EMR system (or physician manually) submits a FHIR Delete Subscription request to HALO layer that included subscription ID.
•The ONE ACCESS GATEWAY authenticates and validates the request and forwards it to SoFA Server.

Step 2: SoFA process Subscription interaction and forwards it to Pub-Sub Service

•SoFA process Create Subscription request and modifies the parameter as per SoFA specification.
•SoFA submits Create Subscription request to Subscription Service.

Step 3: Subscription Service creates subscription for requested event and returns status to the Subscribers system end point.

•Subscription service process request ansd returns response indicating operation status to designated end point indicated in the Create Subscription Request.

Use Case 3: Get Subscription Status

Business context

The Subscriber wants to retreive the status of a subscription for specific event.

Example: A family physician (Subscriber) wants to validate status for subscription to hospital admission events for his/hers registered patients generated by the HIS/EMRs (Publisher).

The Subscription Service enables subscriber to request subscriptions status .

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Physician initiates a process to retreive status for subscription for admission events for his/hers patients

•The clinic’s EMR system (or physician manually) submits a request for Subscription status.
•The ONE ACCESS GATEWAY authenticates and validates the request and forwards it to SoFA Server.

Step 2: SoFA process Subscription interaction and forwards it to Pub-Sub Service

•SoFA process Create Subscription request and modifies the parameter as per SoFA specification.
•SoFA submits Create Subscription request to Subscription Service.

Step 3: Subscription Service process request and returns status to the Subscribers system end point. •Subscription service process request ansd returns response with Subscription resource with Subscription Status to designated end point indicated in the Create Subscription Request.


Use Case 4: Get Notification Events

Business context

The Subscriber missed notifications for Events generated by the Publisher. and wants to retrieve all notifications for the specified period of time.

Example: A family physician (Subscriber) wants to retrieve recent hospital admission events for his/hers registered patients generated by the HIS/EMRs (Publisher) that were not retreived due to outage of the system endpoint.

The Subscription Service enables subscriber to request recent event notificadtions whihc are persisted in Subscription Service repository.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Physician initiates a process to retireve recent event notifications for admission events for his/hers patients

•The clinic’s EMR system (or physician manually) submits a Get Notification request to HALO layer.
•The ONE ACCESS GATEWAY authenticates and validates the request and forwards it to SoFA Server.

Step 2: SoFA process Subscription interaction and forwards it to Pub-Sub Service

•SoFA process Create Subscription request and modifies the parameter as per SoFA specification.
•SoFA submits Create Subscription request to Subscription Service.

Step 3: Subscription Service process request, gets all event notifications for period indicated in the request and returns Bundle resourceto the Subscribers system end point.


Use Case 5: Modify Subscription

Business context

The Subscriber wants to update Subscription either to change the desired event or to change the status of the subscritpion (for example if it is expired).

Example: SUbscribers system (EMR) has become iresponsive and Subscription Service fails to deliver notification, thus it changes the subscription status to OFF. The Subscriber wants to change the status to be "ACTIVE" again.

The Subscription Service enables the updates to the existing subscriptions, ensuring that subscribers receive timely notifications whenever a publisher triggers an event.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Physician initiates a process to modify subscription for admission events for his/hers patients, that has been turned off.

•The clinic’s EMR system (or physician manually) submits a FHIR Subscription Modify request to HALO layer.
•The ONE ACCESS GATEWAY authenticates and validates the request and forwards it to SoFA Server.

Step 2: SoFA process Update Subscription request and forwards it to Subscription Service

•SoFA process Create Subscription request and modifies the parameter as per SoFA specification.
•SoFA submits Update Subscription request to Subscription Service.

Step 3: Subscription Service updates subscription for requested event and returns status to the Subscribers system end point.

•Subscription service process request ansd returns response with updated Subscription resource to designated end point indicated in the Subscription Request.

Use Case 6: Subscriber Endpoint Health Check

Business context

Subscription service needs to verify that subscribers' notification endpoints are operational. In case where health check fails, the Subscription service disables Supscription for a given endpoint to prevent notifications being sent to unreachable endpoints.

Note: This use case is technical in nature but required to ensure proper implementation pub sub service components.

Example: EMR solution implements an endpoint for accepting notifications from Subscription service. Subscription service implements heartbeat interaction at predefined intervals to ping the endpoint for health check.

The Subscription Service enables notification endpoint health check via heart beat interaction.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Subscription Service perfroms periodic health checks of Subscriber's notification end point by initiating REST-full opeartion.

•The Subscription Service pings the subscriber’s endpoint using a POST method to submit the reques. 

Step 2: Upon receiving the heart beat response Subscription Service handles the response to determine the follow up actions for subscriptions.

•Success (200 OK) → The server confirms the subscriber is reachable.
•If the subscriber fails multiple health checks, the Subscription Server deactivates the subscription.

Use Case 7: Subscription Service Handshake

Business context

Before activating the subscription, the Subscription Service performs a system handshake to verify that the subscriber's endpoint is reachable and properly configured.

Note: This use case is technical in nature and describes system interactions (not visible to business user) that occure as part of the Create Subscription to ensure proper implementation of pub sub service components.

Example: EMR solution implements an endpoint for accepting notifications from Subscription service. Subscription service requires a handshake to validate and confirm subscribers interface.

Business Workflow

The business workflow outlines the step-by-step interactions between key actors in a use case. Definition of the interactions and detailed sequence diagram are provided in Profile and Interaction section of this IG.

Step 1: Subscriber submits Create Subscription request (Use Case 1). Before creating and activating the subscription, Subscription Service sends a handshake request to the subscriber's endpoint.

•The handshake request contains Bundle resource with BundleType= history and SubscriptionType = handshake, verifying the endpoint is reachable, authentication works correctly and the client can process FHIR notifications.

Step 2: Subscriber's endpoint process and acknowledges the handshake.

•The subscriber system responds with HTTP 200 OK if the handshake is successful and Subscription Service activates the Subscription.
•If the subscriber fails to respond or returns an error (e.g., 401 Unauthorized), the subscription remains in requested or error state.

Use Case 8: Get Topics List

Business context

Subscriber wants to retreive a list of subscription topics (as cannonical URLs) available and implemented by Subscription Service.

There are few options to implement this use case.

• As part of the onboarding procedure OH shall provide the list of predefined topics with canonical URIs. The implementers will use this information to facilitate subscription creation.

• Since at this point in time R5 SubscriptionTopic resource is not supported, OH may implment custom built, propriatery API for systems to query available topics. It may be provided in a Bundle resource as a list of Properties with cannonical URI. There may be specific business rules that will restric specific organization from using particular topics (for example, HALO topics only for HALO users, Orion Health Portal topic for Orian solution, etc.

• Target state capability for OH Subscritpion Service will be to implement query for SubscriptionTopics as indicated by FHIR R5 specification.