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

3.3. Conformance Rules

This section defines the conformance framework for the Ontario eForms FHIR Implementation Guide, including how systems declare conformance, how role-based requirements are expressed, and how to interpret obligation codes applied throughout the profiles.A system that claims conformance SHALL:

• Implement at least one actor defined in this IG, and
• Conform to all obligations that apply to the actor(s) it declares.

3.3.1. Implementation obligations

Ontario Health (OH) projects operate under different conformance expectations depending on system role. In this environment, the traditional use of mustSupport has proven insufficient because it:

• does not specify which system is responsible for supporting an element,
• does not describe what “support” means (display, processing, validation, tolerance, etc.), and
• leads to inconsistent implementations across projects and vendors.

To address this, this Implementation Guide replaces mustSupport with explicit implementation obligations. Obligations allow the IG to clearly state:

• which actor(s) a requirement applies to (Renderer, Population Engine, etc.), and
• what level of expectation applies (SHALL, SHOULD, MAY) and what behavior is required (e.g., SHALL:display, SHALL:process, SHALL:reject-invalid, SHALL:no-error).

This approach enables role-specific conformance, testable and enforceable expectations, and consistent interpretation across OH implementations.

3.3.2. Obligation actors and definitions

This specification defines several ‘Actors’. Each actor represents a set of functionality a system can be responsible for. A given system might support only one actor or it might support multiple. Conformance with this guide means that a system SHALL declare support with at least one actor. Other Ontario specifications may mandate (SHALL) or encourage (SHOULD) support for specific combinations of actors.

For each actor, the following section indicates the name of the actor, provides a summary of the types of responsibilities it has, and lists the primary obligations associated with the actor. In cases where the meaning of an obligation is variable (such as ‘shall process’), these descriptions will also provide context on how the obligation is interpreted within the context of this specification.

Note: Irrespective of the obligations specified, systems SHALL NOT fail merely as a result of the inclusion of any non-modifier data elements defined in this IG.

3.3.2.1. Renderer (Form Filler / UI engine)

Renderer (Form Filler / UI engine): Renders a Questionnaire and captures a user’s responses as a QuestionnaireResponse. This actor is responsible for obeying user-interface instructions (e.g., styling, layout, question controls), flow control logic, and input-time validation that directly affects user entry.

Key responsibilities:

• SHALL:display human-facing text and rich content when present.
• SHOULD:display form metadata intended for discovery/categorization (e.g., descriptive fields used in form listing/catalog scenarios), where applicable to the implementation.
• SHALL:process UI-driving rules and dynamic behavior, including conditionality and dynamic option logic (e.g., enableWhen, enableWhenExpression, hidden, answerOptionsToggle), as well as user-interface instructions (e.g., renderStyle, itemStyle, itemControl, choiceOrientation, sameLine, supportLink, collapsible behavior).
• SHALL:process calculatedExpression where present (compute and apply calculated answers as part of form-filling behavior).
• SHALL:process input-time validation for constraints feasible to evaluate in a form-filling context, including minLength, maxLength, minValue, maxValue, minOccurs, maxOccurs, maxSize, and mimeType, and enforce rule-based constraints expressed via targetConstraint where required by the form.
• SHALL:process terminology-related configuration used for rendering and capture, including preferredTerminologyServer, and enforce terminology constraints where locally knowable (e.g., explicit answerOption).

3.3.2.2. Population Engine

Population Engine: In this Implementation Guide, population is performed natively by the form-filling client as part of the renderer capability. Population uses Questionnaire metadata (expressions, variables, context) to prefill answers based on data available to the client at run time. Execution of population logic does not guarantee that data exists. The Population Engine may not have access to external data endpoints; its responsibility is limited to evaluating declared logic using the available context.

Key responsibilities:

• SHALL:process all population-driving context, expressions, and structural anchors required for native prefill, including launchContext (and name/type), variable (including value.language/expression) at both Questionnaire and item levels, itemPopulationContext, initialExpression (including value.language/expression), and the Questionnaire item structure needed to locate and type populated results (Questionnaire.item, groups, item.linkId, and item.type).

3.3.2.3. Extraction Engine

Extraction Engine: In this Implementation Guide, extraction is performed natively by the form-filling client (or a local component within the solution). Extraction uses metadata in the associated Questionnaire to transform a QuestionnaireResponse into a Bundle of derived resources (e.g., Observation, Procedure, MedicationStatement) for standardized downstream use.

Key responsibilities:

• SHALL:process all extraction-driving content needed for native mapping, including extraction instructions wherever they appear in the Questionnaire (Questionnaire-level and item/group/question-level definitionExtract, definitionExtractValue, extractAllocateId, and their sub-elements such as definition, fullUrl, expression/language, and fixed-value), as well as the Questionnaire item structure required to locate and map answers (Questionnaire.item, groups, item.linkId) and definition-based mapping hooks (Questionnaire.item.definition / Questionnaire.item:question.definition).

3.3.2.4. QR Narrative Generator (Liquid + narrative hooks)

QR Narrative Generator (Liquid + narrative hooks): Generates a human-readable summary of a completed QuestionnaireResponse by generating the QuestionnaireResponse.text narrative using Liquid templates embedded in the Questionnaire.

Key responsibilities:

• SHALL:process responseRenderingLiquid (including value / reference) and required template dependencies to generate QuestionnaireResponse.text.
• SHALL:process referenced/contained template assets required for narrative generation (e.g., contained Library / Binary via Questionnaire.contained) where used by the template.

Note: The noteInfo extensions (including option-level noteInfo) are intended for internal Ontario Health authoring and template-generation workflows. These extensions may be removed prior to distribution of Questionnaires to implementers. This Implementation Guide places no obligations on systems to process noteInfo, and narrative generation SHALL NOT depend on its presence.

3.3.3. QuestionnaireResponse Obligations

This QuestionnaireResponse profile defines obligations using role-based obligation codes (e.g., SHALL:populate, SHALL:user-input, SHALL:display, SHALL:process). These obligations describe the expected behavior of systems that create, populate, transform, or summarize QuestionnaireResponse instances.

3.3.3.1. Renderer (Form Filler / UI engine)

The Renderer captures user input and produces a QuestionnaireResponse.

• Elements marked with Renderer = SHALL:populate indicate the Renderer is expected to populate those elements in the QuestionnaireResponse it produces (e.g., identifier, questionnaire, status, subject, authored, author, and the response item structure such as item, item.linkId, item.answer, and item.answer.value).
• Elements marked with Renderer = MAY:populate indicate the Renderer may populate the element when supported and applicable (e.g., QR-level signature, item-level signature).
• Elements marked with Renderer = SHALL:user-input indicate the Renderer must support user entry/capture of the content (e.g., where media or answer content is captured directly from the user).
• Elements marked with Renderer = SHALL:display indicate the Renderer is expected to present human-facing response content to users where applicable (e.g., QuestionnaireResponse.item.text, media content).
• Elements marked with Renderer = SHALL:process indicate the Renderer must preserve and handle the element correctly as part of producing a structurally valid QuestionnaireResponse (e.g., maintaining item hierarchy, preserving linkId, and correctly representing answer datatypes in value).

3.3.3.2. Population Engine

The Population Engine performs native population logic and contributes populated values into the QuestionnaireResponse produced by the Renderer.

• Elements marked with Population = SHALL:process indicate the Population Engine must read/use these structures when performing population, including:
  • the response context elements used to determine population scope (e.g., QuestionnaireResponse.subject), and
  • the response item framework required to locate where values belong (e.g., item, item.linkId, item.text, item.answer, item.answer.value, and nested item.item / item.answer.item).
• Where an element is marked Renderer = SHALL:populate and Population = SHALL:process, the intent is that the Population Engine drives the value determination and placement, while the Renderer is responsible for producing the correct QuestionnaireResponse instance containing those populated results.

3.3.3.3. Extraction Engine

The Extraction Engine reads QuestionnaireResponse content to create derived resources for downstream use.

• Elements marked with Extraction = SHALL:process indicate the Extraction Engine must locate and interpret the response structure and values needed for mapping (e.g., traverse item, resolve answers via linkId, and read answer.value and nested items).
• Extraction is expected to process key context fields that anchor mapping (e.g., QuestionnaireResponse.subject, authored, author) where they are marked for extraction processing.
• Where weighted answers are present (e.g., item.answer.extension:itemWeight), SHALL:process indicates the extraction/mapping logic must be able to read and use weight when relevant to downstream use cases.

3.3.3.4. QR Narrative Generator (Liquid)

The QR Narrative Generator generates a human-readable narrative in QuestionnaireResponse.text using Liquid templates.

• Elements marked with Narrative = SHALL:process indicate the narrative generator must read/use the relevant response content when generating narrative, including core response item structure (e.g., item, item.linkId, item.answer, item.answer.value, and nested items).
• Where the narrative generator is expected to generate narrative from response content, it must process item text where present and answers used by the template.