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. Once IAR is integrated into the Ontario EHR asset and becomes part of the broader provincial EHR ecosystem, it will need to align its data exchange standards, connectivity, and other system components with those established within the Ontario EHR. These components are expected to differ from the current IAR implementation and may therefore require updates.

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 preferred 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 sources 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, this release will continue to use the message bundle type in this specification. This decision is based on several practical implementation considerations

• the effort, cost, and impact of transitioning from message bundles to transaction bundles during this phase,
• the existing FHIR R3 production implementation based on messaging, which allows reuse of existing components and reduces the need for customization,
• the need to maintain backward compatibility,
• the current pass-through architecture,
• the stable current 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.