Pan-Canadian HALO Specification
HALO is a standardized “visual interactive framework” that would enable web applications to plug into their existing design.
This page presents the technical sequence diagrams for the HALO specification. HALO is structured around four core use cases, and its functionality is expressed through a set of pan-Canadian IHE-style integration profiles. While each profile defines actors, roles, and transactions in isolation, these sequence diagrams combine them to illustrate how multiple profiles interconnect to support end-to-end workflows. The diagrams show how HALO systems act as technical actors and how their coordinated transactions collectively realize each of the four core use cases.
Scenario: A Care Provider uses a Point of Care (PoC) Solution to discover and select jurisdictionally approved SMART Apps that may support or enhance their clinical workflow.
This sequence diagram illustrates how the HALO specification enables the discovery and selection of SMART Apps via an integrated App Catalog. The flow begins with the PoC system initiating a request to retrieve the list of available SMART Apps (CA:AC-1), followed by a response containing the list of approved apps. Once the app list is received, the user selects a specific SMART App from the catalog for use within their workflow.
Scenario: A Care Provider launches a SMART App from the Point of Care Solution to retrieve external clinical data (e.g., lab results, immunizations) from a jurisdictional EHR or other external data service.
Assumption: The SMART App is capable of facilitating access to the external data service. Any subsequent negotiation of credentials, authentication, or authorization required by the external service itself is assumed to have been handled out of band.
This use case supports two models:
The Care Provider initiates a SMART App launch from a Point of Care (PoC) Solution that manages its own FHIR server and Identity Provider. The launch sequence begins with the PoC system initiating the SMART App launch (CA:SoF-1), followed by retrieval of the SMART server metadata (CA:SoF-2) from the well-known endpoint. The SMART App then initiates the authorization flow to obtain access credentials (CA:SoF-3), receiving an access token, ID token, and any relevant launch context. Once the SMART launch flow is complete, the SMART App queries the external jurisdictional EHR or other designated service to obtain the additional patient data.
The Care Provider initiates a SMART App launch from a Point of Care (PoC) Solution that does not expose its own FHIR server or Identity Provider. Instead, the PoC interacts with centralized services—specifically the SMART on FHIR Accelerator (SoFA) and a jurisdictional Identity Provider (IdP)—to manage context and enable secure access to external clinical data.
The launch sequence begins when the PoC system establishes clinical context by sending relevant resource identifiers and workflow data to the SoFA Context Manager (CA:SoFA-1). In response, the Context Manager issues an opaque Launch ID to be used by the SMART App. The PoC then initiates the SMART App launch (CA:SoF-1), prompting the SMART App to retrieve SMART server metadata from the centralized authorization server (CA:SoF-2) and initiate authorization using the provided Launch ID (CA:SoF-3). The authorization server returns the access token, ID token, and associated launch context.
Once the SMART launch flow is complete, the SMART App queries the external jurisdictional EHR or other designated service to obtain the additional patient data.
Note: Although the SMART App does not access FHIR resources from the PoC in this use case, the launch and iss parameters remain mandatory as per the SMART App Launch specification. Accordingly, a SoFA-enabled PoC must first obtain a launch code from the SoFA Context Manager via the $set-context operation (CA:SoFA-1) in order to complete the launch (CA:SoF-1).
Scenario: A Care Provider launches a SMART App from within the Point of Care (PoC) Solution to complete a clinical task—such as initiating an eConsult or submitting an eReferral—by enabling the SMART App to access structured clinical data from the PoC system using a standardized FHIR interface.
This use case supports two models:
The Care Provider initiates a SMART App launch from a Point of Care (PoC) Solution that manages its own FHIR server and Identity Provider. The launch sequence begins with the PoC system initiating the SMART App launch (CA:SoF-1), followed by retrieval of the SMART server metadata (CA:SoF-2) from the well-known endpoint. The SMART App then initiates the authorization flow to obtain access credentials (CA:SoF-3), receiving an access token, ID token, and any relevant launch context. Once authorized, the SMART App accesses the PoC FHIR server by including the access token in its request (CA:SoF-4), enabling it to retrieve structured clinical data necessary to complete the clinical task.
Assumption: The Point of Care (PoC) Solution is leveraging the SMART on FHIR Accelerator (SoFA) launch model and has registered an active FHIR Subscription to the SoFA Content Update topic. The SMART App has been launched using the SoFA flow, is registered with the jurisdictional Identity Provider, and holds a valid access token with permission to write to the SoFA-hosted FHIR server.
The Care Provider initiates a SMART App launch from a Point of Care (PoC) Solution that does not expose its own FHIR server or Identity Provider. Instead, the PoC interacts with centralized services—specifically the SMART on FHIR Accelerator (SoFA) and a jurisdictional Identity Provider (IdP)—to manage context and enable secure access to clinical data.
The launch sequence begins when the PoC system establishes clinical context by sending relevant resource identifiers and workflow data to the SoFA Context Manager (CA:SoFA-1). In response, the Context Manager issues an opaque Launch ID to be used by the SMART App.
The PoC then initiates the SMART App launch (CA:SoF-1), prompting the SMART App to retrieve SMART server metadata from the centralized authorization server (CA:SoF-2) and initiate authorization using the provided Launch ID (CA:SoF-3). The authorization server returns the access token, ID token, and associated launch context.
Once authorized, the SMART App accesses the SoFA-hosted FHIR server by including the access token in its request (CA:SoF-4), allowing it to retrieve the structured clinical data needed to complete the task. After the app has finished, the PoC optionally clears the context from SoFA (CA:SoFA-2), concluding the workflow.
Scenario: A Care Provider uses a SMART App to complete a clinical task that involves external systems pushing structured data back to the Point of Care (PoC) Solution through a secure, standardized interface.
This use case covers several interactions over the lifecycle of data exchange and subscription management for both Base SMART on FHIR and SMART on FHIR Accelerator (SoFA) flows. Specifically, the diagrams that follow illustrate:
Together, these interactions demonstrate how the HALO specification enables external data to be delivered back to the PoC through coordinated pathways. The specific implementation varies depending on the PoC’s deployment model (Base SMART on FHIR or SoFA) and the method of data synchronization—either through direct writes, synchronous event delivery using FHIR Subscriptions, or asynchronous background processing.
Assumption: The Point of Care (PoC) Solution supports SMART on FHIR launches and exposes a standards-compliant FHIR API. The SMART App has been launched from the PoC system using the base SMART on FHIR authorization code flow, has obtained a valid access token, and is registered with the PoC’s authorization server. The app is authorized to write specific FHIR resources based on its registered scopes and client permissions.
The sequence begins after the SMART App is successfully launched and authorized through the SMART on FHIR flow, obtaining an access token with appropriate write permissions. The app then initiates a write operation (CA:SoF-4), sending one or more FHIR resources—such as a ReferralRequest, DiagnosticReport, or Observation—to the PoC’s Resource Server. The server validates the token and applies any necessary business or access control rules.
Upon successful processing, the server stores the resource and responds with a 201 Created status, confirming that the data has been committed and is now available within the PoC system’s patient record.
Assumption: The PoC possesses a valid jurisdictional access token with permissions to create and modify FHIR Subscription resources within the SoFA FHIR server.
The process begins with the PoC system checking for an existing subscription. If none exists, the PoC creates a new Subscription resource (CA:FSub-1), and the SoFA server responds with a representation of the created subscription and its initial requested status. If a subscription already exists, the PoC retrieves its current status (CA:FSub-4) and then updates the existing Subscription to set it back to the requested state (CA:FSub-2). The PoC also searches historical events that occurred prior to the subscription’s reactivation (CA:FSub-5).
Once the Subscription is initialized, the activation sequence begins. For REST Hook-based subscriptions, the SoFA Notification Producer issues a handshake notification to the PoC system (CA:FSub-8). For WebSocket-based subscriptions, the PoC first requests a WebSocket binding token (CA:FSub-6), then connects to the endpoint using the binding token (CA:FSub-7), after which SoFA issues a handshake notification (CA:FSub-8). Upon successful acknowledgment, the subscription status is updated to active.
To maintain the health of the connection, periodic heartbeat notifications are sent from SoFA to the PoC system (CA:FSub-9) for both REST Hook and WebSocket channels until the subscription is no longer active.
Assumption: The PoC has an active Subscription to the SoFA Content Update topic, possesses a valid jurisdictional access token with permissions to delete and/or modify FHIR Subscription resources within the SoFA FHIR server.
To temporarily pause a subscription while retaining the option to resume, the PoC updates the Subscription resource to set its status to off (CA:FSub-2). The SoFA Subscription Manager processes the update and returns the updated Subscription with the modified status.
To permanently end a subscription, the PoC deletes the Subscription resource from the SoFA FHIR server (CA:FSub-3). The SoFA server confirms the deletion by returning a final representation of the deleted resource.e resource and setting its status to off, or permanently by deleting it.
Assumption: The SMART App has been launched by a PoC that is leveraging the SoFA launch flow, the PoC has an active Subscription to the SoFA Content Update topic, and the SMART App possesses a valid jurisdictional access token with permissions to write FHIR resources.
The sequence begins when the SMART App, using a valid jurisdictional access token, issues a FHIR write interaction to the SoFA Resource Server (CA:SoF-4). This triggers a synchronous notification to the PoC system through its active subscription (CA:FSub-10).
If the subscription is REST Hook-based, the SoFA Notification Producer sends an event notification to the PoC, which acknowledges receipt before the resource is committed. If the subscription is WebSocket-based, the SoFA Notification Producer emits the event immediately, without requiring acknowledgment. Once changes are applied by the SoFA server, a 201 Created response is returned to the SMART App, indicating successful write completion.
Assumption: The SMART App has been launched by a PoC that is leveraging the SoFA launch flow, the PoC has an active Subscription to the SoFA Content Update topic, and the SMART App possesses a valid jurisdictional access token with permissions to write FHIR resources.
The sequence begins with the SMART App including its access token and issuing a FHIR write interaction (CA:SoF-4). The SoFA Resource Server accepts the request and returns a 202 Accepted response along with a content location to poll for job status.
The SMART App repeatedly polls the content location to check the status of the asynchronous operation. As long as processing is ongoing, the server continues to respond with 202 Accepted. In parallel, SoFA dequeues the notification and sends an event notification to the PoC system based on its active subscription (CA:FSub-10)—either via REST Hook or WebSocket. The PoC processes the notification, applies the necessary changes, and tracks the event number as needed.
Once processing is complete and the resource is written to the SoFA FHIR server, the job is marked as complete. The next poll from the SMART App returns a 200 OK response, signaling that the write interaction has successfully concluded.