Pan-Canadian HALO Specification
HALO is a standardized “visual interactive framework” that would enable web applications to plug into their existing design.
This section defines key terms used in the HALO Implementation Guide to ensure a common understanding of the concepts and processes described.
An OAuth access token is a unique credential issued to an OAuth client, included in requests to a resource server to validate and authorize the client’s access to specific resources on behalf of the user. While an access token may be a JSON Web Token (JWT) that contains structured data in the form of claims, from the client’s perspective, they are assumed to be opaque (See Opaque Token). This means that, unlike the ID Token, they should not be used to communicate user identity information and are strictly for authorizing access to resources. See RFC 6749 Section 1.4.
A defined interface or entry point that allows software systems to interact and exchange data, specifying the permitted data types, message formats, parameters, and operations. APIs enable systems to access the functionality and data of other systems, allowing integration and interoperability between different applications and services without exposing underlying code or system processes.
Refers to the overarching HALO App Launch specification (inherited from SMART on FHIR) that defines a standardized method for initiating the SMART App Launch flow from within a PoC application.
A piece of information (such as a unique identifier, role, or permission) included in a JWT (JSON Web Token) and used in OAuth 2.0 to assert facts about the entity, typically a user or client application. Claims are encoded within the token and can represent identity, scope, or other authorization attributes. More information on Claims can be found in the OAuth2 Specification.
A health care provider involved in delivering healthcare services. In the HALO framework, they are the primary users, driving the Point of Care (PoC) application and the App Launch flow, ultimately accessing and using SMART apps to enhance patient care and clinical workflows.
A software application (or set of applications) used by healthcare providers to manage patient health information and clinical workflows.
A text-based flexible markup language used to store and transport data. It defines a set of rules for encoding documents in a format that is both human-readable and machine-readable, making it widely used for document exchange between systems. See XML.
A model that allows users to authenticate across multiple applications using a single set of credentials. In the HALO project, the Central IdP manages authentication for various apps, ensuring a consistent and secure experience across systems.
A structured API defined by the HL7 FHIR (Fast Healthcare Interoperability Resources) standard, designed specifically for healthcare data exchange. The FHIR REST API represents healthcare entities (e.g., patients, observations, medications) as discrete Resources, and a set of interactions based on the HTTP request/response paradigm, enabling the exchange of structured healthcare information. It establishes a common, standardized way to define, access, and organize healthcare data, promoting interoperability across healthcare systems. See the HL7 FHIR RESTful API specification.
A system that stores, retrieves, and exchanges resources such as patient data and clinical information following the FHIR standard, that can be shared across healthcare applications. In the HALO architecture, this server is typically a jurisdictional or PoC managed server that provides data to the HALO App via RESTful FHIR APIs.
A mechanism defined by FHIR that enables a FHIR server to send notifications about resource changes to subscribing systems. It allows the point‐of‐care (PoC) system to stay updated on relevant data modifications.
The Health Application Lightweight Protocol is a standardized technology framework that enables approved jurisdictional and vendor applications to seamlessly integrate into any authorized Point of care systems, such as EMRs, with the ability to coordinate their activities with SMART applications and other jurisdictional assets.
An implementation of the HALO specification offered by a jurisdiction or another implementing entity.
HL7 is a standard for the electronic data exchange of healthcare information. HL7 endeavours to standardize the format and protocol of the exchange of certain key sets of data among healthcare computer application systems, such as patient administration/registration, discharge, and requisitions for laboratory testing, results and clinical observations.
A standard developed by HL7 (Health Level Seven International) for electronic health data exchange. FHIR defines how healthcare information can be structured, shared, and accessed across different systems.. It does this by organizing healthcare data into modular components called "resources," such as patients, medications, observations, and more. Each resource is standardized with a specific structure, which includes data elements, attributes, and relationships to other resources. For more information see the official HL7® FHIR® standard.
A specific data entity within the FHIR standard that represents a clinical or administrative concept, such as a Patient, Observation, Encounter, Document, or Medication. Each resource contains structured data elements that follow the FHIR format for standardized healthcare data exchange.
An ID Token is a JSON Web Token (JWT) issued by an OpenID Connect (OIDC) Identity Provider (IdP) that contains identity-related information (claims) about an authenticated user. It is typically used to verify the identity of the user to the client application after authentication, and can include claims such as user ID, name, email, and other relevant attributes. Unlike an access token, an ID token is not intended for authorizing access to resources but for conveying information about the authenticated user. In SMART on FHIR, obtaining an ID Token requires requesting the openid and fhirUser scopes. See OpenID Connect Core Specification.
With identity federation, an IdP acts as a central point for user authentication and enables organizations to manage user identities across different domains and platforms. The IdP allows users to authenticate once and access multiple applications without requiring repeated logins, using single sign-on (SSO) across connected apps. In many cases, an IdP also functions as an authorization server. For example, in OAuth 2.0 & OIDC, the IdP often handles both authentication and authorization.
An implementation guide (IG) is a set of rules about how FHIR resources are used (or should be used) to solve a particular problem, with associated documentation to support and clarify the usage.
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format, derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. See RFC 8259.
A compact, URL-safe token format used to encode claims as JSON objects. In OAuth 2.0, JWTs are often used for transmitting Access Tokens or ID Tokens between parties in a secure and verifiable manner. The token contains header, payload (claims), and signature sections to ensure both data integrity and authenticity. See RFC 7519.
A security process that requires the use of two or more verification factors to access a system, application, or account. MFA combines different types of credentials, typically involving something a user knows (e.g., a password), something the user has (e.g., a mobile device or security token), or something the user is (e.g., biometric data like fingerprints or facial recognition). The purpose of MFA is to strengthen security by ensuring that the compromise of one factor does not grant unauthorized access to the system. See Security in layers with Multi-Factor Authentication by the Canadian Centre for Cyber Security.
An open standard for token-based authentication and authorization on the Internet. See RFC 6749.
An opaque token, in the context of authentication and authorization systems, is a type of token where the token itself does not carry any discernible information about the user or the session. It is simply a random string of characters with no intrinsic meaning. The token is considered "opaque" because it cannot be decoded or understood by external parties. Its meaning and/or associated data (such as user identity, permissions, or session details) are not embedded within it and are instead maintained by the issuing service (e.g., an IdP). RFC 6819 and RFC 6749 from IETF both describe Opaque tokens in detail.
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750). It simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner. See the official OpenID Connect Core 1.0.
Identifying information about an individual, whether oral or recorded if the information relates to the individual's physical or mental condition, including family medical history, provision of health care to the individual, is a plan of service for the individual, payments, or eligibility for health care or for coverage for health care, donation of any body part or bodily substance or is derived from the testing or examination of any such body part or bodily substance, is the individual's health number or identifies a health care provider or a substitute decision-maker for the individual. "Identifying information" includes information that identifies an individual or for which it is reasonably foreseeable that it could be used, either alone or with other information, to identify an individual. See Personal Health Information Protection Act, 2004.
In the HALO framework, the Point of Care (PoC) system is the primary healthcare application, typically an EMR, used by clinicians to deliver care. It serves as the driving application that creates and shares the clinical context, initiates app launches, and facilitates real-time access to patient data within integrated healthcare applications.
A credential issued by the authorization server that allows an OAuth client to request a new access token when the current one expires or becomes invalid. This token, representing the authorization granted to the client, enables the client to obtain additional access tokens with the same or a narrower scope. Issuing a refresh token is optional and at the discretion of the authorization server. See RFC 6749 Section 1.5.
An architectural style for building web services that structures interactions as a series of stateless requests, with each request representing a distinct transaction. REST relies on defined resources, representing various types of data, that can be manipulated using standard operations. It facilitates scalable, simple, and loosely coupled communication by organizing information into manageable resources that can be accessed via unique identifiers.
A SMART App is a third-party application that securely integrates with a PoC system using the SMART on FHIR standard. It builds on FHIR by adding security protocols like OAuth 2.0 and OpenID Connect (OIDC) to manage authorization and access. This allows the app to extend the functionality of EMR systems by securely accessing standardized health data via FHIR resources.
A framework that enables secure and standardized access for third-party applications to Electronic Health Record (EHR) data, using the FHIR API. By leveraging OAuth 2.0 for authorization, SMART on FHIR supports apps for both clinicians and patients, allowing them to launch from within an EHR or standalone. It defines a flexible approach to access various FHIR resources, supporting a range of clinical use cases, from data visualization to decision support, all while maintaining privacy and security standards. See SMART on FHIR.
The SMART on FHIR Accelerator (SoFA) is a service (or set of services) that enable Point of Care (PoC) systems without native FHIR servers or OAuth 2.0 Identity Providers (IdPs) to connect with healthcare applications using centralized jurisdictional services. By providing a FHIR server and context management, SoFA allows these systems to securely integrate SMART apps, facilitating context sharing and data access on their behalf.
The delivery mechanism used to send notifications for a subscription.
A canonical identifier (URL) that defines a specific set of events on a FHIR server. Clients subscribe to these topics to receive notifications when those events occur.
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. See RFC 3986.
A reference or address used to access resources on the internet. It specifies the location of a resource and how to retrieve it. A URL is a specific type of Uniform Resource Identifier (URI) that provides the means to locate a resource. See RFC 1738.
The .well-known/smart-configuration endpoint is a standardized URL offered by a FHIR server that can be used by SMART applications to discover necessary configuration details for authentication and authorization with an PoC's authorization server. When an app queries this endpoint, it receives a JSON document containing key metadata, such as URLs for the authorization and token endpoints, and supported OAuth 2.0 and OpenID Connect features, including scopes, client authentication methods, and PKCE support. This metadata is essential for third-party SMART apps to interact with FHIR resources securely and in compliance with the PoC's policies, enabling streamlined access to clinical data while supporting privacy and security standards.