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

3.1. Form Behavior and Rendering

This section defines expectations for how Ontario SDC-compliant forms are rendered, how logic is executed, and how data is prepopulated and processed by conformant systems.

3.1.1. Form Versioning and Versioned References

This Implementation Guide defines technical requirements for form versioning to support traceability and consistent interpretation across systems.

• Each Questionnaire SHALL declare a Questionnaire.version and a Questionnaire.versionAlgorithm (extension) to indicate how version values are compared. Implementers are strongly encouraged to use semantic versioning (SemVer).
• To avoid ambiguity, references to forms SHOULD be version-specific, ensuring that completed QuestionnaireResponse instances can be reliably associated with the exact form definition used at the time of data capture.
• This Implementation Guide does not define business workflows for form lifecycle management (such as when new versions are created, retired, or selected). These processes are considered organizational decisions and are outside the scope of this IG.

3.1.2. Expressions

The Ontario Questionnaire profile includes several mustSupport extensions that use the Expression data type.

• All expressions SHALL be written in FHIRPath.
• Form fillers SHALL support any valid FHIRPath 2.0.0 expression used in forms.
• Expressions may be used for logic, conditional visibility, validation rules, calculated values, and dynamic rendering.

3.1.3. Population and Extraction

Form fillers SHALL support Expression-based population and Definition-based extraction.

Implementation Note: The eForms IG defines auto-population logic using FHIRPath expressions to provide a standards-based reference for the data elements to be populated in forms. However, the IG does not mandate how consuming systems retrieve or execute this logic. Implementing systems (e.g., EMRs) may evaluate FHIRPath expressions against FHIR APIs, translate them into local query mechanisms (such as SQL), or resolve them using in-memory data models, as long as the populated results are consistent.

3.1.4. QuestionnaireResponse Narrative

When a QuestionnaireResponse is completed, form fillers SHALL generate the narrative using any provided FHIR Liquid template pointed to by the Questionnaire’s ResponseRenderingLiquid extension.

3.1.5. Rendering Expectations

Ontario Health specifies the following behavior for compliant rendering systems:

• Radio Buttons SHALL be rendered as individual buttons, where the 'selected' button is highlighted as depressed.

3.1.6. Ontario-Specific Rendering Behaviours

In addition to the standard rendering guidance defined in the HL7 Structured Data Capture (SDC) specification, the Ontario eForms ecosystem includes a small set of Ontario-specific rendering capabilities that support referral workflows and advanced presentation formats.

Liquid-Based Response Rendering Templates

Some referral workflows require a structured referral letter to be generated after a QuestionnaireResponse is completed. Ontario systems accomplish this by using Liquid templates that are referenced directly from the Questionnaire.

• A Questionnaire MAY include the responseRenderingLiquid extension
  , which points to a Liquid template stored as:
  • a contained Library or Binary resource (Questionnaire.contained), or
  • a Library available on a FHIR server.
• When the form is completed, form fillers use this template to generate a human-readable referral letter or summary from the QuestionnaireResponse.
• The template MAY read additional Ontario “note” extensions that provide extra narrative content and rules, including:
  • Group Note Info
  • Question Note Info
  • Option Note Info

These note extensions are attached to Questionnaire.item (group/question) or Questionnaire.item.answerOption and can convey conditional note logic, sort order, positive or negative phrasing, and styling.
Form fillers MAY ignore these extensions; however, systems that support Liquid-based rendering can use them to generate rich, structured referral letters.

Interactive SVG-Based Form Presentations

Some systems in Ontario implement clickable SVG-based forms, where the form layout is rendered as an SVG image and user interactions (for example, clicking regions of the image) populate values in the underlying Questionnaire.

• Questions that use SVG diagrams MAY declare the choiceDiagram on Questionnaire.item.
• The choiceDiagram extension can reference an SVG image stored as a contained Binary resource or hosted externally.

These rendering capabilities are optional and represent Ontario-specific presentation behaviours layered on top of the standard SDC Questionnaire model. Systems that do not support them can still process the underlying Questionnaire and QuestionnaireResponse in a fully conformant manner.