Pan-Canadian HALO Specification
HALO is a standardized “visual interactive framework” that would enable web applications to plug into their existing design.
This section introduces the core concepts of the Pan-Canadian HALO framework, which aims to facilitate seamless interoperability in healthcare across different jurisdictions. These concepts include foundational services like the Jurisdictional App Catalog, App Launch, and Pan-Canadian FHIR profiles, which enable standardized access to healthcare applications and resources. Privacy and security are integral to the architecture, with dedicated components managing data security, auditing, and monitoring to ensure compliant and secure healthcare data exchange.
The diagram below outlines the essential building blocks of the HALO framework, including the SMART on FHIR Accelerator—which extends SMART on FHIR capabilities to systems that cannot make their FHIR servers externally accessible—and core services like context management and identity access. These components work in tandem to provide secure, efficient data sharing, while enabling healthcare providers to leverage jurisdictionally approved applications for enhanced patient care.
| Concept | Description |
|---|---|
| Jurisdictional App Catalog | A centralized repository for healthcare applications that are jurisdictionally approved to improve patient care. See App Catalog. |
| App Launch | A Pan-Canadian extension of the SMART App Launch flow. See App Launch. |
| Jurisdictional Subscriptions | A service for managing and distributing events across relevant systems to facilitate dynamic healthcare workflows. See Subscriptions. |
| Jurisdictional Asset Integrations | SMART Apps may include built-in integrations with jurisdictional assets, helping to reduce the need for custom service-specific integrations at the PoC level, thereby further reducing barriers to jurisdictional interoperability. |
| Pan-Canadian FHIR Profiles | Standardized FHIR profiles used across Canada to ensure consistent healthcare data representation. |
| Jurisdictional Context Management | Manages the context of healthcare sessions to provide seamless and consistent app behavior. |
| SMART on FHIR Accelerator | Extends SMART on FHIR capabilities to systems without externally accessible FHIR servers by leveraging shared jurisdictional infrastructure. |
| Identity & Access Management | Handles authentication and authorization using OAuth 2.0 and OIDC protocols to secure app access. See Design Considerations. |
| Privacy & Security | The HALO framework offers guidance to ensure that stringent privacy, data security, and auditing measures are applied across all components, safeguarding health information and maintaining rigorous compliance throughout the system. See Privacy and Security Guidance. |
| OAuth 2.0 & OIDC | Core protocols in SMART on FHIR, enabling secure, standardized user authentication and authorization across healthcare applications by managing token-based access to FHIR resources. |
| FHIR Server | A standardized data repository for healthcare information that follows FHIR R4 specifications, allowing SMART applications to access and interact with structured health data in a secure and interoperable way. |
| SMART Applications | Apps built to leverage SMART on FHIR standards, designed for interoperability with FHIR servers, enabling access to patient data across authorized healthcare contexts. |
| Context Sharing | A mechanism in SMART on FHIR that allows applications to share user and patient context, ensuring consistent and integrated data flow within and between healthcare applications. |
| Point of Care Applications | The primary systems for healthcare delivery at the point of care, typically represented by EMRs. Within the HALO framework, these applications initiate the SMART App Launch flow, serving as the starting point for accessing, sharing, and contextualizing clinical data in real-time to support patient-centered care. |
The Pan-Canadian HALO Specification outlines two architectures: SMART on FHIR for compliant systems, and the SoFA extension for those that cannot expose FHIR servers. The document emphasizes the use of provincial services to enable seamless SMART app launches, providing a solution for both compliant and non-compliant systems to adopt SMART on FHIR technology effectively.
| Component | Description |
|---|---|
| App Catalog | A centralized repository for healthcare applications that extend the capabilities of clinical systems such as Electronic Medical Records (EMRs). A primary goal of the App Catalog is to provide healthcare providers across Canada with access to jurisdictionally approved third-party applications, streamlining the discovery, configuration, and rollout of applications to improve patient care and clinical workflows. See App Catalog. |
| FHIR Server | In the context of the following diagrams, a FHIR server refers to a RESTful FHIR API that facilitates data exchange using FHIR resources, which adhere to Pan-Canadian FHIR profiles. |
| Identity Provider | A service that authenticates and manages the identity of users and client applications according to the OAuth 2.0 & OIDC specification. |
| LoB Services | Any other service, beyond the contextual FHIR server, that a SMART app utilizes after launch. These services can include jurisdictional or non-jurisdictional FHIR servers, as well as other essential services needed by the application. |
| PoC Application | A local system (e.g., an EMR), used by healthcare professionals to support the delivery of care. This component is responsible for launching a SMART App. |
| SMART Apps | Healthcare applications that adhere to the SMART on FHIR specification, allowing them to be launched from within point of care applications and integrate seamlessly to enhance clinical workflows and patient care. |
| SoFA | The SMART on FHIR® Accelerator is intended to be used when a PoC system does not have the ability to make a FHIR server available for access by external systems. As apart of their SoFA implementations, jurisdictions are expected to support context management, FHIR server, and subscription management (i.e., Pub/Sub) capabilites. |
The SMART on FHIR Architecture allows healthcare systems with local FHIR servers and Identity Providers to integrate seamlessly with SMART applications. It uses OAuth 2.0 for authentication and provides a consistent process for launching and accessing approved applications via an App Catalog, facilitating data exchange and integration at the point of care.
| # | Interaction | Description |
|---|---|---|
| 1 | App Catalog Query | The PoC application queries the jurisdictional App Catalog, which contains a list of SMART apps approved for use within the specified jurisdiction. See App Catalog. |
| 2 | Launch SMART Application | The PoC system launches the SMART app that the user selected in step 1. See App Launch. |
| 3 | SMART App Initiates Discovery Request | The SMART app retrieves the SMART configuration metadata from the FHIR server's /.well-known/smart-configuration endpoint, which includes an authorization endpoint to be used by the SMART app for any subsequent authentication and authorization processes. See App Launch. |
| 4 | SMART App Performs an Authorization Request | The SMART app performs the OAuth 2.0 & OIDC Authorization Code flow against the endpoints received in the discovery response. If the clinician does not have an active session with the IdP, the IdP system will prompt the clinician to authenticate. Please refer to the Security, Authentication and Authorization section of Design Considerations. Also see App Launch for a description of the expected response data. |
| 5 | SMART App Retrieves FHIR Resources | The SMART app retrieves any FHIR resources that it has been granted access to during the initial authorization flow. This includes but may not be limited to, the contextual resources identified within the initial access token response from the IdP. See App Launch. |
| 6 | SMART App Utilizes LoB Services | The SMART app utilizes Line of Business (LoB) services as necessary based on the business logic of the SMART app. |
The HALO SMART on FHIR Accelerator (SoFA) architecture is intended for systems that cannot externally expose FHIR servers. It introduces the SoFA component to manage interactions on behalf of point-of-care systems, using centralized jurisdictional services like identity management, context management, and subscriptions, thereby extending SMART on FHIR capabilities to non-compliant systems.
| # | Interaction | Description |
|---|---|---|
| 1 | App Catalog Query | The PoC application queries the jurisdictional App Catalog, which contains a list of SMART apps approved for use within the specified jurisdiction. See App Catalog. |
| 2 | PoC Performs Authorization Request | The PoC system performs the OAuth 2.0 & OIDC Authorization Code flow against the jurisdictional Identity Provider (IdP). If the clinician is not already authenticated within the jurisdictional IdP, the IdP system will prompt the clinician to authenticate. Refer to the Design Considerations section. |
| 3 | Set Context | The Point of Care (PoC) system invokes the $set-context FHIR operation to transmit the relevant clinical context (e.g., Patient, Practitioner, Encounter) to the SMART on FHIR Accelerator (SoFA). See Operation: $set-context. |
| 4 | Token Introspection | The SoFA validates the request potentially performing an OAuth 2.0 introspection operation (using the received access token) against the IdP to validate the clinician's identity and permissions. See Design Considerations. |
| 5 | Create Subscription | The PoC system creates a topic subscription request to register itself and receive notifications for changes to the respective topic. See Subscriptions. |
| 6 | Launch SMART Application | The PoC system launches the SMART app that the user selected in step 1. See App Launch. |
| 7 | SMART App Initiates Discovery Request | The SMART app retrieves the SMART configuration metadata from the SoFA's /.well-known/smart-configuration endpoint, which includes an authorization endpoint to be used by the SMART app for any subsequent authentication and authorization processes. See App Launch. |
| 8 | SMART App Performs an Authorization Request | The SMART app performs the OAuth 2.0 & OIDC Authorization Code flow against the endpoints received in the discovery response. If the clinician does not have an active session with the IdP, the IdP system will prompt the clinician to authenticate. Please refer to the Security, Authentication and Authorization section of Design Considerations. Also see App Launch for a description of the expected response data. |
| 9 | SMART App Retrieves FHIR Resources | The SMART app retrieves any FHIR resources that it has been granted access to during the initial authorization flow. This includes but may not be limited to, the contextual resources identified within the initial access token response from the IdP. See App Launch. |
| 10 | SMART App Utilizes LoB Services | The SMART app utilizes Line of Business (LoB) services as necessary based on the business logic of the SMART app. |
| 11 | Subscription Service Publishes a Notification to a Subscriber | The Subscription service publishes a notification to one or more subscribing systems based on the subscription topic. This includes the PoC and/or SoFA, depending on whether the PoC has the capabilities to support direct notification and how the subscription was registered. See Subscriptions. |