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:

  1. SHALL: This word defines an absolute requirement for all implementations.
  2. SHALL NOT: This phrase defines an absolute prohibition against inclusion for all implementations.
  3. 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.
  4. 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.
  5. 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, supporting patient context where applicable, with consistent error handling.
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.
R-006 HALO solution SHOULD act as Secure Node or Secure Application from ATNA profile OR HALO Solution SHOULD adhere to jurisdictional standards for creation of secure audit logs that capture access to, modification or disclosure of patient and other sensitive information. This includes the activities of all applicable actors that are implemented by the participating systems.

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 conform to applicable information security practices. 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 required or explicitly requested by the SMART App for its intended functionality.
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 (e.g. PS-CA: v2.1.1 DFT, CA:eReC: v1.1.0 DFT). For use cases that do not have an existing specification, CA Core+ profiles SHOULD 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 Deprecated
IR-012 The SMART App SHOULD 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 be able to display a list of SMART apps retrieved from the App catalog.
SR-002 The PoC Solution SHOULD be able to present the details about each SMART App (i.e. App Name, Description of features) to the user.
SR-003 The PoC Solution SHOULD display a user-facing notification for App Catalog access failures, including HTTP error codes, reason for failure, details of the errors, and retry options.
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 user interface 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 user interface 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.
SR-023 The PoC Solution SHOULD implement standardized error handling for App Catalog access and SMART App interactions, using FHIR OperationOutcome resources and retry mechanisms.
SR-024 PoC Solutions SHOULD implement FHIR resources allocation strategies and UX best practices during parallel SMART App launches.