Pan-Canadian HALO Specification
HALO is a standardized technology framework that enables approved jurisdictional and vendor applications to seamlessly integrate into any authorized Point of Care system.
To minimize administrative barriers and support a scalable, automated onboarding process across jurisdictional boundaries, the HALO specification establishes an order of preference for SMART Application registration and authentication. The higher-priority methods are preferred, as lower-priority options are subject to future deprecation and phase-out to optimize interoperability and align with evolving standards.
Implementers are responsible for securing their registration process according to industry standards to minimize the attack surface. From a liability and risk management perspective, it is expected that PoC systems maintain the ability to control and approve which applications from the App Catalog are authorized for use within their specific environments.
The registration and authentication mechanisms are listed in order of preference, from highest to lowest priority. The PoC SHOULD support all registration and authentication patterns described below.
Registration Mechanisms
Client Authentication Mechanisms
Applications with a secure backend SHALL register as confidential clients. HALO strongly recommends the use of confidential clients over public clients whenever technically feasible.
To maintain jurisdictional trust, DCR requests are expected to include a signed cryptographic assertion from the jurisdiction or another recognized HALO authority. Jurisdictions are responsible for defining and maintaining the associated vetting process.
Note: Preassigned registration is an interim mechanism, subject to deprecation in favor of DCR as systems mature.
When using preassigned Client Registration, implementers should note that some Authorization Servers may not support explicit configuration of externally assigned client_id values and may instead generate immutable internal client identifiers during client registration or application creation.
Where a jurisdiction supports a preassigned registration flow, an implementer opting for it is expected to reconcile the jurisdictionally assigned Client ID with any internally generated identifier used by the Authorization Server.
This may require a facade, middleware layer, or equivalent mapping mechanism that preserves the externally visible preassigned Client ID for HALO registration, catalog, and launch interactions, while translating to the Authorization Server’s internal identifier as needed for local processing.
Trust Boundaries
In general, the HALO App Catalog must be treated as a jurisdiction-wide trust boundary. The Apps listed in the catalog are expected to undergo a jurisdictional vetting process, with formal developer identity and security attestation aligned with PHIPA obligations. App approval SHOULD require security, privacy, and clinical governance review, with lifecycle controls such as re-certification, key rotation, and real-time revocation.
Critically, individual custodians SHOULD retain the ability to enable or restrict apps based on organizational policies and data sensitivity. Inclusion in the App Catalog does not imply automatic or blanket system-level access.
Endpoint Security
To enforce these boundaries, the App Catalog endpoints SHOULD be secured requiring system authentication. This is especially critical if Client Registration information is allowed by the jurisdiction to be included in the App Catalog, through publishing client IDs, redirect URIs, environment endpoints, detailed scope strings (especially system-level scopes), etc.
To verify the trustworthiness of the client at the App Catalog endpoint, jurisdictions SHOULD authenticate clients at the application layer using signed cryptographic assertions bound to a certificate issued by a trusted Certificate Authority. Where feasible, mutual TLS (mTLS) between the PoC system and the App Catalog endpoint MAY be used as an alternative.
Scope Governance
To maintain strict scope governance, the scopes listed in the App Catalog SHOULD be granular and restricted to the minimum data sets required for operation, preferring user-level or patient-level scopes over system-level and wildcard scopes, to prevent unauthorized bulk data access. Jurisdictions vetting Apps are also responsible for verifying technical correctness, which includes scopes.
Information and Data Protection
The App Catalog SHOULD NOT expose internal architecture details, integration topology, or any configuration that could aid enumeration, impersonation, or targeted attack planning. While not classified as confidential in standard OAuth 2.0 specifications, data elements such as client IDs, redirect URIs, environment endpoints, and detailed scope information (especially system-level scopes) SHOULD be protected and shared only with authorized systems.
Based on the principle of strict data minimization, the App Catalog SHOULD publish only what supports transparency and informed decision-making, withholding anything that expands the attack surface or weakens the overall security posture.
Single Sign-On (SSO) is a key component within the HALO framework, enabling a seamless, secure, and efficient user experience across multiple healthcare applications. SSO centralizes the authentication process, allowing clinicians to log in once to access various applications without needing to re-authenticate each time they switch between systems. This unified access management approach improves both the user experience and security by reducing the reliance on multiple passwords and individual login events. By integrating SSO, HALO facilitates greater interoperability and workflow efficiency, allowing clinicians to engage with a range of healthcare resources within a single identity ecosystem. This integration aligns with modern identity management standards and enhances the security posture by enforcing consistent authentication practices across all HALO-connected applications.
There are several approaches to SSO that could work effectively within the HALO framework. The most common implementations, each with distinct benefits and considerations, are outlined below. These options provide flexible solutions, accommodating the varying infrastructure and identity management capabilities across different healthcare environments.
This approach uses Centralized Identity Registration, where clinicians register with a centralized identity provider and link their jurisdictional account to their EMR. With Single Sign-On (SSO), clinicians can log in once and access multiple applications without needing to re-authenticate, allowing for unified access across systems and improved integration between applications. This setup is particularly suited for complex environments requiring coordinated identity management, as it enables clinicians to move across different HALO-connected apps seamlessly under a single, consistent user identity.
This approach leverages identity providers (IdPs) with OAuth 2.0 and OpenID Connect (OIDC) to streamline authentication across HALO-connected applications. Clinicians first log into their EMR with their local credentials, creating an initial session. Upon launching a HALO-connected app for the first time, they authenticate via the IdP, receiving an authorization, which may then be exchanged for an access token. For subsequent app launches, if the IdP session is still active, clinicians are not prompted to re-authenticate. he app continues to use OAuth 2.0 and OIDC to obtain fresh authorization codes, which are exchanged for access tokens as needed, while the active IdP session enables secure, seamless access without repeated logins.
For the HALO framework, it is recommended that the Federated Single Sign-On approach is implemented wherever feasible. This method provides a streamlined, unified login experience by allowing clinicians to log in once with their centralized credentials, granting them access to both the PoC and connected SMART applications without repeated authentications. Such a fully federated system enhances usability, strengthens security, and aligns with modern identity management standards by leveraging central IdP capabilities. By simplifying access across applications, it reduces administrative overhead and offers a more consistent user experience.
However, not all jurisdictions or PoC vendors may have the infrastructure required to fully support a federated identity system. In these cases, the Local Login with Federated Sign-On approach remains an acceptable alternative. This hybrid model allows for local PoC authentication, while still supporting secure access to SMART apps and the SoFA via the centralized IdP, ensuring that HALO deployments can adapt to varying levels of infrastructure readiness across regions.