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 code, which is then exchanged for an access token. For subsequent app launches, if the IdP session is still active, clinicians are not prompted to re-authenticate. The 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.
HALO enables applications and services to access and, where authorized, modify health information using standardized interoperability patterns. These capabilities support important clinical and operational workflows, but they also require careful attention to responsible data use, transparency, provenance, accountability, and data minimization.
This section provides high-level design considerations for responsible data access and modification across the HALO ecosystem. It is not intended to introduce additional conformance requirements. Decisions about how a PoC system stores, displays, reviews, reconciles, or incorporates received information remain implementation, workflow, and policy decisions for the responsible organization, vendor, jurisdiction, or downstream specification.
Responsible use of health information is a shared responsibility across all participating actors.
Jurisdictions and App Catalog maintainers should take care when reviewing and publishing applications or services for use within the HALO ecosystem. This includes considering whether the application has a clear purpose, whether its requested capabilities align with that purpose, and whether appropriate privacy, security, operational, and data-sharing expectations have been established.
SMART Apps and Backend Services clients should be transparent to PoCs and Jurisdictions about the data they need and the operations they intend to perform. They should request only the minimum scopes needed to support their function and should avoid broad read or write permissions unless there is a clear justification. The capabilities represented in catalog metadata, onboarding material, registration processes, and runtime requests should align with the actual behaviour of the application or service.
PoC systems should surface sufficient information about a SMART App or Backend Service to support informed review and approval where those decisions are presented to a user or administrator. Relevant information may include the application's identity and purpose, requested scopes, intended capabilities, and other applicable metadata available through the App Catalog.
Authorization servers and resource servers also play an important role. Requested scopes should be treated as requests, not entitlements. Authorization servers should avoid granting access beyond what is appropriate for the client and its approved purpose. Resource servers should validate tokens, enforce granted scopes, and apply local access control rules before returning or accepting clinical data.
Applications and services should limit their access, storage, and retention of health information to what is necessary for their intended purpose. Resource servers should apply the same principle when responding to requests by returning only the data needed to support the authorized interaction, and avoiding the disclosure of additional information that is not required.
This principle applies throughout the data lifecycle, including information that is transmitted as launch context in SoFA workflows, returned by FHIR resource servers, cached by applications, exported for downstream use, derived through processing, or stored outside the original system.
Where an application or service is authorized to create, update, patch, or delete FHIR resources, those operations should be performed carefully and predictably. Authorization to write does not imply that an application or service should modify data whenever it is technically able to do so.
Write operations should be tied to the purpose of the application or service and should occur in a context where the relevant user, organization, health information custodian, or jurisdiction would reasonably expect the modification to occur. Applications should avoid unexpected or unnecessary changes, and user-facing workflows should make it clear when clinically significant information is being submitted, changed, or removed.
Implementers should ensure that sufficient information is retained to trace significant activity across HALO workflows. This typically includes application onboarding and registration, authorization decisions, access to health information, FHIR read and write operations, Backend Services activity, and other security- or workflow-relevant interactions.
Where appropriate, the FHIR AuditEvent resource can be used to represent auditable events involving users, applications, services, systems, and affected resources. Traceability may also rely on related authorization, application identity, provenance, and system log information to provide a complete view of how an interaction occurred.
HALO does not currently define specific conformance requirements for which events must be recorded or how audit information must be retained or reviewed. These expectations remain subject to applicable jurisdictional, organizational, security, privacy, and operational requirements.
For more information, see the FHIR AuditEvent resource.
Applications and services should consider using the FHIR Provenance resource when creating or modifying resources so the receiving system can understand where the data came from, who or what submitted it, and what activity produced it. Where appropriate, provenance can be submitted alongside the relevant resource or, where supported, attached to a request using the FHIR X-Provenance HTTP header. This allows provenance information to be communicated without embedding it directly in the request body.
HALO does not currently define specific conformance requirements for the use of provenance in these interactions. Provenance does not replace authorization, audit, review, or reconciliation, but it can support those processes by giving receiving systems clearer source and attribution information. Future iterations of HALO may make more direct considerations for provenance where sufficiently specific and broadly applicable patterns emerge.
For more information, see the FHIR Provenance resource.
Consent requirements vary across jurisdictions, organizations, care settings, and purposes of use. Implementers should consider which consent model applies to a given HALO workflow and how that consent model affects access, disclosure, use, or modification of health information.
Where a computable representation of consent is needed, the FHIR Consent resource may be used to record and communicate consent directives or consent-related restrictions. This can help systems understand whether particular actors, roles, purposes, actions, or data categories are permitted or restricted within a defined policy context. See the FHIR Consent resource for more information.
Consent should be addressed alongside authorization, scope enforcement, provenance, audit, and local access control. The presence of a valid access token does not, by itself, resolve all consent or privacy considerations. Similarly, the Consent resource can help communicate consent information, but the enforcement of consent policies remains dependent on the applicable jurisdictional rules, organizational policies, agreements, and system behaviour. HALO does not currently define a specific set of consent requirements for these workflows, though future iterations of HALO may make more direct considerations for consent where clearer interoperability expectations emerge.
Backend Services clients require additional caution because they operate without an active user authorization step at runtime. These clients are pre-authorized system-to-system actors and may access or modify data on behalf of an organization, program, jurisdiction, or trusted service.
Because there is no user in the loop during the runtime flow, Backend Services clients should be reviewed carefully before being granted access. Their purpose, requested scopes, permitted operations, and data handling expectations should be clearly understood. Broad system-level access, especially write access, should be avoided unless it is necessary and justified for the intended workflow.
Some workflows may require user review, approval, rejection, reconciliation, or signing before externally sourced information is incorporated into a local clinical workflow or patient record. These expectations are often specific to the clinical context, resource type, user role, jurisdictional policy, EMR implementation, and workflow being supported.
For this reason, HALO does not impose a blanket requirement that all externally generated writes must be manually reviewed and approved by a user before being stored or incorporated. Where review or approval is needed, it should be defined by the relevant downstream specification, implementation guide, jurisdictional policy, or local workflow design. These more specific contexts are better suited to defining what is being reviewed, who is responsible for the review, what approval means, and how rejection or reconciliation is handled.
PoC vendors may still choose to implement internal staging, triage, reconciliation, or approval mechanisms for externally sourced writes. Where they do, they should consider the impact on downstream systems. SMART Apps and Backend Services clients may expect that a successful FHIR write response means the resource has been persisted and is available for subsequent workflow steps. If a PoC system accepts a write into a pending state instead, that behaviour should be predictable and should not unintentionally break application workflows. For more information on overall privacy and security expectations within HALO, see the Privacy and Security Guidance page.