visit the hl7 website
Ontario eForms HL7® FHIR® SDC Implementation Guide - v1.0.0 Ballot
fhir-logo
  • Index
  • Home
    • Home
    • Introduction
    • Relationship to Other Specifications
    • Scope
    • Glossary
  • Business Context
    • Business Context
    • Business Model
    • Business Data
    • Use Cases
  • Technical Context
    • Technical Context
    • Form Behavior and Rendering
    • Implementer Responsibility
    • Conformance Rules
    • Connectivity Summary
  • FHIR Artifacts
    • FHIR Artifacts
    • Profiles
    • Extensions
    • Terminology
    • Examples
    • Response Handling
    • Downloads
  • Change Log
    • Change Log
    • Known Issues & Future Developments
    • Revision History
    1. Index
    2. Business Context
    3. Business Model

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

2.1. Business Model

This page describes the business model for Ontario Health eForms and the roles involved in creating, publishing, rendering, completing, and consuming standardized digital forms.

2.1.1. Background and intent

Ontario Health eForms were created under the Patients Before Paperwork (Pb4P) initiative to reduce administrative burden on clinicians, streamline processes, eliminate redundancy, enhance efficiency, and provide faster service to individuals. This IG supports those goals by defining a shared, standardized approach for representing and processing eForms using HL7 FHIR® Structured Data Capture (SDC).

The intent is that EMRs and other systems can use a single shared software component to manage form rendering and completion, and that individuals experience consistent form behavior regardless of the purpose for which they are filling out forms.

2.1.2. Business roles

  • Ontario Health (Form Publisher)
    Publishes standardized form definitions as FHIR Questionnaires and establishes conformance expectations for how those forms are rendered, validated, and processed.

  • Form Author / Content Maintainer
    Designs form content, structure, constraints, conditionality, and presentation rules (including optional narrative templates). Authors may use tooling that generates or maintains the underlying FHIR artifacts.

  • Form Filler (Clinician / Individual)
    Completes forms through a user-facing application. A Form Filler interacts with the rendered Questionnaire and produces a QuestionnaireResponse.

  • Implementing System (e.g., EMR / PoS / Portal)
    Implements one or more eForms capabilities defined in this IG, such as rendering, validation, pre-population, extraction, and narrative generation.

  • Downstream Consumer (Reader of Completed Form)
    Consumes completed form content either as structured responses (QuestionnaireResponse and/or extracted resources) or as a narrative summary.

2.1.3. Alignment to obligation actors

This IG expresses conformance using role-based implementation obligations (defined in the Conformance Rules section). Business roles often map to technical responsibilities as follows:

  • Implementing systems that display and capture form responses typically implement the Renderer capability.
  • Implementing systems may also implement Population Engine, Extraction Engine, and/or QR Narrative Generator capabilities as part of their solution.

Note: This IG defines generic capabilities only. Use-case specific IGs may impose additional workflow expectations (e.g., where forms are located, what data sources must be supported for population, what extracted resource types are required).

Version: 1.0.0 FHIR Version: R4.0.1

Powered by SIMPLIFIER.NET

HL7® and FHIR® are the registered trademarks of Health Level Seven International