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. Languages and Translations

Ontario Health supports the publication and exchange of standardized referral forms containing both English and French content. Implementing systems SHALL support presentation of form labels, instructions, and other user-facing content in the language selected by the end user, consistent with the translation and localization mechanisms defined by this Implementation Guide.

French language text is communicated in the Questionnaire using the 'translation' extension present on most string elements. In the completed QuestionnaireResponse, the item text and code display values SHALL be what the user saw when completing the Questionnaire, with the exception of 'string' questions with enumerated options. In those situations, the values must remain the English string. However, the translated French equivalent (copied from the Questionnaire) SHALL be present as a translation extension to allow appropriate rendering.

An example of a Questionnaire with translations can be found here, along with completed QuestionnaireResponses in English and French.

NOTE: The example Questionnaire provided does not have updated Liquid that supports French narrative generation. This is expected to be addressed in a future release.

3.1.6. Rendering and Style Expectations

The guide makes use of styles on item, text, and option.

• Item styles deal with outline and background color and apply to the item and its children (unless overridden by styles declared on descendant items).
• Text styles affect the rendering of the text of a display item, question, or group heading.
• Option styles affect the rendering of answers. Text styles do not apply to answers; only option styles apply.

3.1.6.1. Constrained style lists

Each style extension is constrained to a specific list of styles. Ontario Health forms will not make use of styles not covered in these lists without producing a new version of the guide. These lists are constrained to allow implementers a chance to map from the “HTML styles” to whatever style mechanism they use internally, if they do not render their forms using HTML. Also, knowledge of what styles may be asserted may influence EMR default rendering choices.

3.1.6.2. Use of HTML

It is also possible for styles to be asserted as part of HTML elements. However, such elements will limit themselves to the same value sets as are used for the base elements (i.e. text HTML will be limited to text styles, option HTML will be limited to option styles). The primary purpose of HTML is where styles need to be mixed (e.g. some text is bold or italic, while other text is not). HTML also allows embedding line breaks as part of the text.

3.1.6.3. Spacing

XHTML may also be used to insert non-breaking spaces (for example,  ) into content where needed to preserve intended spacing or prevent undesirable line wrapping.

3.1.6.4. Control 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.7. 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.