Pan-Canadian HALO Specification

Business Requirements

This section outlines the fundamental business requirements of the HALO framework, specifying the core capabilities necessary for effective implementation. The requirements define what must, should, or may be implemented, as well as explicitly stating what is prohibited. This supports alignment with legal and privacy frameworks and ensures the effective implementation of FHIR-based data exchange within the healthcare ecosystem.

The requirements refer to a standardized expression of actors, entities, and user-system interactions, which will be further defined within this specification. Definitions of the terms used throughout the requirements may be found in the HALO Specification: Glossary of Terms and Acronyms

Additional requirements may emerge and will be included in subsequent releases of the HALO specifications.

Conformance Language

The HALO specification utilizes conformance verbs such as SHALL, SHOULD, and MAY as defined in RFC 2119. They are described below for convenience:

SHALL: This word defines an absolute requirement for all implementations.
SHALL NOT: This phrase defines an absolute prohibition against inclusion for all implementations.
SHOULD: This word defines a recommendation that is considered good practice to be included by an implementer. The full implications of ignoring it must be understood and carefully weighed before doing so.
SHOULD NOT: This phrase defines a common bad practice to be omitted or ignored by an implementer. The full implications of implementing it must be understood and carefully weighed before doing so.
MAY: This word defines truly optional items, which an implementer may choose to include or omit with no implications.

Requirement Identification

The requirements in this specification follow a standardized naming convention to ensure clarity and organization. The structure is based on three primary categories, each assigned a unique prefix, followed by a three-digit numerical identifier. The prefixes and categories are as follows:

R-###: Foundational Requirements – These focus on ensuring that processes align with legal, privacy, and collaborative business frameworks.
IR-###: Interoperability Requirements – These requirements relate to the ability of systems to communicate and exchange data effectively.
SR-###: Solution Requirements – These requirements guide implementers on how to meet interoperability requirements, offering guidance on integrating specific solutions.

Requirements

Foundational Requirements

This section defines the core functionalities that represent the motivating requirements for the HALO framework. These requirements highlight the core needs for HALO's implementation by addressing critical functionality for care providers, ensuring seamless app access, app launch, and data interoperability.

ID	Description
R-001	The Care Provider SHALL be able to access the App Catalog from the PoC Solution
R-002	The authorized care provider SHALL be able to launch the SMART App from within the PoC Solution
R-003	The PoC Solution SHOULD be able to share FHIR R4.0.1 structured data to the SMART app
R-004	The PoC Solution SHOULD be able to import FHIR R4.0.1 structured data from the SMART app
R-005	For PoC systems that do not include a native FHIR server, the HALO solution SHOULD enable the SMART App Launch flow by implementing the HALO SMART on FHIR Accelerator.

Interoperability Requirements

This section focuses on ensuring the system adheres to technical standards for data protection, FHIR-based structured data exchange, and supports the integration of third-party apps and data sharing mechanisms within the HALO framework.

ID	Description
IR-001	A HALO Solution SHALL protect health information in transit, adhering to jurisdictional legislation and applicable standards and policies, and information security. Note: For example, jurisdictional standards for encryption SHOULD cover concepts of cryptographic algorithms and protocols, management of encryption keys during the transmission of PHI to maintain the confidentiality and integrity of the Patient Information.
IR-002	A HALO Solution SHALL create structured data using FHIR R4 (v4.0.1), supporting JSON and XML file interchange formats.
IR-003	A HALO Solution SHALL adhere to the syntactic, semantic/terminology and content standards for interoperability using FHIR R4 (v4.0.1) and established pan-Canadian FHIR specifications.
IR-004	The PoC solution SHALL be able to retrieve the list of approved SMART Apps included in the App Catalog.
IR-005	The PoC solution SHALL be able to retrieve the details of each approved SMART App included in the App Catalog.
IR-006	The PoC Solution SHOULD only share FHIR resources during the launch process that are defined in the SMART App capability statement.
IR-007	The PoC Solution SHALL be able to share logical ids of the contextual FHIR resources during the launch process of the SMART App using protocols defined by the HALO framework and specification. (See Operation: $set-context)
IR-008	The PoC Solution SHALL be able to share clinical discrete data resources with the SMART App based on existing pan-Canadian specifications. The App Catalog will allow the SMART App to define its specification scope. Note: For this release, for use cases with existing specifications, those specifications SHALL be used (PS-CA v2.0.0 DFT-Ballot, CA:eReC v1.0.3 DFT). For use cases that do not have an existing specification, PS-CA FHIR profiles SHALL be used.
IR-009	The SMART App SHALL identify what resources it requires in its listing in the App Catalog. Resources identified SHOULD be available in existing pan-Canadian specifications (PS-CA, CA:eReC).
IR-010	The PoC Solution SHOULD be able to receive, process, and store updated clinical data shared by the SMART App via the available protocols defined by the HALO framework and specification.
IR-011	The PoC Solution SHALL be able to share clinical discrete data resources with the SMART App based on existing pan-Canadian specifications. The App Catalog will allow the SMART App to define its specification scope. Note: The HALO framework will promote the use of the harmonized CA Core+ product specification which provides the base set of FHIR profiles that will enable consistent exchange of data between applications across use cases.
IR-012	The SMART App SHALL be able to share clinical discrete data resources with the PoC Solution based on the existing pan-Canadian specification. The App Catalog will allow the SMART App to define its specification scope.

Solution Requirements

This section defines the functional capabilities the system must or may offer to enhance user experience, including SMART app launch features, user interaction management, error handling, and optional functionalities related to app management and user preferences.

ID	Description
SR-001	PoC Solution SHOULD display list of SMART apps retrieved from the App catalog.
SR-002	The PoC Solution SHOULD a capability to be able to present the details about each SMART App (i.e. App Name, Description of features) to the user.
SR-003	If the App Catalog cannot be accessed or launched, the PoC Solution MAY consider showing a message advising the Care Provider to try again later.
SR-004	The PoC Solution SHALL be able to use the SMART App details to build the launch capability.
SR-005	The PoC Solution SHALL be able to launch the SMART App using SMART on FHIR and, if required, share clinical data using guidance provided in the HALO framework and specifications (set-context guidance).
SR-006	The PoC Solution SHALL provide the ability to launch the SMART App with a patient identifier, or without a patient identifier.
SR-007	If the SMART App cannot be launched, the PoC Solution MAY show a message advising them to try again later.
SR-008	The PoC Solution MAY consider making previously used apps easily accessible through its user interface by providing the ability for these apps to be added to a favourite list by the care provider.
SR-009	The PoC Solution MAY consider a capability that allows care providers to manage their favourite SMART Apps (add, remove, re-order the list)
SR-010	The PoC Solution MAY provide capability to display and manage notifications (turn them on/off) sent by the SMART App or HALO Solution.
SR-011	If network connectivity issues occur, the PoC Solution MAY consider showing a notification to the care provider with options to retry or return to the PoC Solution.
SR-012	The PoC Solution SHALL register with the regional IdP and SHALL be setup to connect to the Regional IdP to authenticate itself when using jurisdictional SMART Apps that require them to perform additional authentication.
SR-013	The care provider SHALL have appropriate access rights within the PoC Solution to launch and interact with each SMART app.
SR-014	If the IdP requires MFA (Multi-factor Authentication), the care provider MAY complete this step before proceeding with the SMART app launch.
SR-015	The SMART App launch process SHOULD be quick and intuitive, minimizing disruption to the care provider's workflow.
SR-016	The PoC solution MAY support functionality for a user to launch/open multiple SMART Apps in parallel.
SR-017	If the care provider exits without launching an app, the PoC Solution MAY return the care provider to the main PoC application interface with no changes made.
SR-018	The PoC Solution MAY display the source of the information next to the imported data.
SR-019	The PoC Solution MAY provide the care provider the ability to discover all SMART apps available to them and request access to those they do not have access to.
SR-020	The HALO Solution SHOULD provide a centralized App Catalog.
SR-021	The HALO Solution’s App Catalog SHOULD be accessible via a public RESTful API conforming to the App Catalog specification.
SR-022	A HALO Solution SHOULD implement the SoFA component of the HALO framework if it wants to provide support for PoC Solutions that do not have a native FHIR Server.