For a full list of available versions, see the Directory of published versions

5.1. Known Issues & Future Developments

Note: If there are issues not listed under this section, report them to DigitalHealthStandards@OntarioHealth.ca

This section documents issues, limitations, and planned enhancements related to this Implementation Guide (IG).

---

5.1.1. Known Rendering Defects/Issues

The MustSupport (MS) flag on choice-type elements (value[x]) may render inconsistently across the profiles especially on the extension data elements. When MS is applied at the parent level, any child data type modified in the differential is implicitly MustSupport. However, some data elements do not propagate the MS flag to these child elements, resulting in inconsistent display.

---

5.1.2. Known Business Content Issues

None.

---

5.1.3. Other Known Issues

None.

---

5.1.4. Future Developments

5.1.4.1. Future Considerations for Consent Interoperability

Ontario Health plans to transition IAR into the provincial EHR environment in future phases, where disclosure for care operates under an implied‑consent model, this may introduce CHANGES for standardized consent‑directive signaling, including FHIR Consent resources or consent‑reference validation, in future phases of the IAR modernization initiative. Implementers should anticipate that consent interoperability requirements may evolve as part of Ontario’s Digital Health Information Exchange (DHIEX) framework. Nothing in this specification precludes the introduction of system‑enforced consent controls in subsequent releases.

5.1.4.2. Future EHR Modernization Roadmap

In the future, to align with Ontario Health’s EHR modernization roadmap, IAR will modernize its system architecture, data standards, and integration capabilities. IAR will transition into the Digital Health Community Repository (DHCR), an Ontario Health (OH) EHR asset that serves as the centralized repository for Community Mental Health and Community Support Services assessment data. Following this integration, as part of the OH EHR assets, data exchange standards, connectivity, and other system elements may evolve, though the details have not yet been defined.

5.1.4.3. Future State Conceptual Model

The architectural design for the future system is not yet finalized. The high-level diagram below shows the preferred approach from the options considered.

In the future, Data Contributors will submit IAR assessment forms in FHIR format to a FHIR clinical data repository (CDR), which will connect to the Provincial Client Registry (PCR). This data will then be accessible through the Provincial Clinical Viewer (PCV) within the OH system. Integration with a terminology service is also planned.

The diagrams illustrate how different users interact with the system in the future.

The systems in this state include:

• Data Contributor (HIC Apps): This actor is responsible for submitting IAR assessment forms, in the FHIR format.
• FHIR Server (SmileCDR): This is the clinical data repository (CDR) and processing engine for the FHIR resources. SmileCDR is the FHIR server implementation.
• Data Consumer (Provincial Viewer): This actor retrieves the data from the FHIR Server.

5.1.4.4. Future State Data Exhange Methods

A review of FHIR data exchange options identified that bundle type transaction is the best approach for the future phase. This decision was based on several factors, including:

• a decision-point analysis on FHIR guidance for choosing an exchange mechanism,
• alignment with Ontario Health’s EHR Data Model recommendations, and
• consistency with Ontario Health’s eForms Release 2.0 data model.

All of these inputs recommend a transaction-based exchange approach instead of message bundles. In addition, examples in the CIHI IRRS FHIR Implementation Guide STU3 v1.1.5 illustrate the use of transaction submissions, although these examples are not considered prescriptive.

However, for this release, this specification continues to use the bundle type message. This decision is based on the several practical implementation considerations:

• the effort, cost, and impact associated with shifting from message bundles to transaction bundles within this phase,
• the presence of an existing FHIR R3 production implementation based on messaging, which enables reuse of established components and minimizes customization,
• the need to maintain backward compatibility,
• the existing pass-through architecture and legacy infrastructure, originally designed for messaging workflows, and
• the fact that current sending systems are already configured to submit message-based payloads.

Although a transaction-based exchange is the recommended approach for future phase, messaging is retained in this version to support implementation feasibility.