Conformance

FHIR® Compliance

The HALO specification leverages HL7® FHIR® R4 (v4.0.1) to define FHIR®-based interactions. Please note that a future version of the specification may adopt HL7® FHIR® R4B (v4.3.0) to leverage features such as Subscription-related resources for publish/subscribe capabilities.

Point of Care (PoC) systems, SMART Apps, and jurisdictional service vendors are expected to support specific FHIR® resources deemed essential by the HALO specification. Supporting these resources ensures that PoC systems and SMART Apps can seamlessly communicate and effectively participate in the HALO ecosystem to achieve interoperability at the jurisdictional and pan-Canadian levels.

FHIR® is a closed specification with base artifacts that include specific resources, documented messaging requirements, and rules. HALO plans to use existing pan-Canadian profiles and artifacts (e.g., CA Core+, CA:eReC, PS-CA, etc.) that can be referenced within the specification. Conformance with this specification does not provide any guarantee of patient or data safety.

FHIR® compliance is crucial for PoC systems to fully realize the benefits of capabilities offered by the HALO specification. PoC systems will be able to exchange health information with SMART Apps, reduce integration complexities by adhering to a common data format, and provide their healthcare professionals with timely access to third-party systems from within their PoC (e.g., EMR) systems.

Must Support

While this specification is intended to align with the Pan-Canadian CA Core+ specification, HALO will refer to other Pan-Canadian profiles, such as PS-CA v2.0.0 DFT-preBallot and CA:eReC v1.0.0 DFT-Ballot, until CA Core+ inheritance has been completed.

In the context of HALO, "MustSupport" on any data element SHALL be interpreted as follows:

1. When creating content:

   • Conformant systems SHALL be capable of producing a value for any element marked as "MustSupport" (if available and supported within their systems).
   • Conformant systems SHALL be able to show that they can obtain and send all fields that carry the "MustSupport" flag.
   • Elements that are not marked as "MustSupport" SHOULD still be populated. However, they carry no expectations in the implementation guide.

2. When receiving content:

   • Conformant systems SHALL be capable of receiving resource instances containing data elements marked as "MustSupport" without generating an error or causing the application to fail.
   • Elements that are not marked as "MustSupport" SHOULD still be received without generating an error or causing the application to fail.
   • Conformant systems SHOULD be capable of displaying data elements that carry the "MustSupport" flag for human use or processing (including, storing them) for multiple events.

Note: Implementers SHOULD expect that some jurisdictions may further constrain support of data elements within the context of their jurisdictions (e.g., PS-ON and PS-BC constraints on PS-CA).

SMART on FHIR® Compliance

The HALO specification utilizes SMART App Launch v2.1.0 as a foundational framework for Point of Care (PoC) systems to securely launch and share data with third-party applications (i.e., SMART apps). By adopting this framework, HALO enables healthcare providers to seamlessly integrate approved SMART apps directly within their PoC systems.

Please note that this guidance is intended to be informative and provide a simplified overview of the information contained in the base SMART App Launch specification. In the event of any discrepancies or conflicts between the summary presented here and the base specification, the base specification shall prevail. Users are encouraged to refer to the base specification for detailed and complete guidance.

One of the key benefits of leveraging SMART on FHIR® is the ability to leverage existing Electronic Medical Record (EMR) system capabilities. Many PoC systems already have mechanisms to launch SMART apps directly within them, providing accelerated integration benefits and reducing the burden on PoC vendors. Adopting the SMART App Launch framework brings several other advantages to the HALO specification, including:

1. Standardization: Provides a well-established, standardized approach for extending PoC systems with third-party applications using the HL7 FHIR® standard.
2. Interoperability: Allows for seamless administrative and clinical data exchange between disparate systems.
3. Security: Enables the utilization of reliable and secure authorization protocols such as OAuth 2.0 and OpenID Connect (OIDC) to mediate access based on a set of rules configured to enforce institutional or jurisdictional policies.
4. Jurisdictional Approval: Allows clinicians and other authorized users to access and exchange data with third-party applications approved at the institutional or jurisdictional level.

The SMART App Launch framework dictates that a PoC system SHALL have the following capabilities:

1. The PoC system SHALL provide access to FHIR-based interfaces through a RESTful API to facilitate the exchange of contextual data.
2. The PoC system SHALL expose an authorization server that is compliant with OAuth 2.0 and OpenID Connect (OIDC) to handle secure authentication and authorization processes and provide the SMART App with the appropriate launch context.

The HALO specification introduces the concept of a SMART on FHIR® Accelerator (SoFA), which acts as an optional mechanism to bridge the gap and provide a pathway for adoption for PoC systems that cannot expose the abovementioned capabilities (i.e., FHIR-based interfaces and authorization server). This mechanism allows PoC systems to participate in the HALO ecosystem without the burden of fully adopting all the components required by SMART on FHIR®. SoFA also includes jurisdictional support for context management, publish/subscribe messaging patterns, and temporary administrative and clinical data storage.

FHIR Subscriptions R5 Backport Compliance

The HALO specification leverages FHIR Subscriptions—implemented via the FHIR R5 Backport (v1.2.0-ballot)—to synchronize updates from the SMART on FHIR Accelerator (SoFA) back to Point of Care (PoC) systems. After the $set-context operation (See Operation: $set-context) establishes clinical context, Subscriptions ensure that the PoC remains up-to-date with any changes or additions to the critical clinical data.

Please note that this guidance is intended to be informative and provide a simplified overview of the information contained in the base FHIR Subscriptions R5 Backport specification. In the event of any discrepancies or conflicts between the summary presented here and the base specification, the base specification shall prevail. Users are encouraged to refer to the base specification for detailed and complete guidance.

Key aspects include:

• Data Change Notifications: Once context is established via $set-context, the SoFA monitors the clinical data—such as updates to Patient, Encounter, or related resources—and notifies the PoC when these resources are modified or when new resources (e.g., additional clinical observations from SMART apps) are created. This ensures that the PoC system continuously reflects the most current patient information.

• Topic-Based Filtering: Each Subscription uses a canonical URL (e.g., for the SoFA Content Update topic) to precisely filter the events that trigger notifications. This targeted approach guarantees that only relevant clinical updates are communicated.

• Notification Workflow: A handshake process validates the PoC’s notification endpoint before the Subscription becomes active. Subsequent notifications include sequence numbers for ordered processing and are delivered via supported channels (rest-hook and websockets) according to the FHIR R5 Backport guidelines.

By implementing FHIR Subscriptions in this manner, HALO supports a modern, event-driven architecture that enhances interoperability and ensures timely delivery of critical clinical updates within the ecosystem. For more information, see the Subscriptions page.