visit the hl7 website
Ontario Provincial Consent Override Interface HL7® FHIR® Implementation Guide v1.0.0-draft1
fhir-logo
  • Index
  • Home
    • Home
    • Introduction
    • Relationship to Other Specifications
    • Scope
    • Glossary
  • Business Context
    • Business Context
    • Business Model
    • Business Data
    • Use Cases
    • Business Rules
  • Technical Context
    • Technical Context
    • Implementer Responsibility
    • Conformance Rules
    • Connectivity Summary
  • FHIR Artifacts
    • FHIR Artifacts
    • Interactions
    • Profiles
    • Extensions
    • Terminology
    • System URIs
    • Examples
    • Capability Statement
    • 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


2.1.1. Context

Consent override is a process by which an requester expresses the intention for unblocking any blocked clinical records. It is also referred as “reinstate consent” operation.

At present consent override mechanism varies for each Ontario provincial EHR asset. The current override approach has different types of interfaces, security requirements and interaction patterns for each repository making it difficult for consuming applications to implement.

The PCOI interface aims to propose a consent override approach for the provider gateway that will be consistent across all the lines of business. Provider gateway aims to expose EHR as a unified FHIR service endpoint as opposed to individual repositories, simplifying implementation for consuming applications.


2.1.1.1. Conceptual Architecture

Flow

  1. Ontario Health’s Privacy Office will continue to manage (create, revoke, update) consent policies in CMTA (step-1), which remains the source of truth. Policy copies are routed in real time from CMTA to Smile CDF (step-1a) and OLIS (step-1b) through Pub/Sub for consent enforcement and override.

  2. A Provider logs into the front-end application (step-2) to retrieve or view their patient’s clinical records (i.e. EMR, OneLab, PCV etc.) If a denied consent policy exists for a specific domain(s) (i.e. OLIS, miCDR, DHDR, acCDR), the effected domain(s) records will be blocked from access.

  3. The Provider can temporarily override the consent block (i.e. Express or Emergency consent override) by clicking on the override link/button.

  4. This action will launch the PCOI Viewlet (step-4). PCOI Viewlet will retrieve context values from CMS (step-3), which is initially populated by the front-end application.

  5. After the Provider selects the appropriate LOB(s) and clicks “Unblock records,” the PCOI Viewlet sends the override request through the OAG to the PCOI Façade (step-5).

  6. The PCOI Façade sends override requests for Acute Care (acCDR), Meds (DHDR), and Medical Imaging (miCDR) to Smile CDF (step-6b). Smile CDF temporarily overrides the specified domain of clinical records and returns a success or failure response to the PCOI Façade. The PCOI Façade sends the result to the PCOI Viewlet for display to the Provider. If the override fails, the Provider can try again; if successful, the Provider exits in the PCOI Viewlet and is returned to the front-end application, where the previously blocked records are temporarily visible for the next 8 hours.

  7. If the Provider selects Meds to override, the PCOI Façade sends the override request to both DHDR (in step 6-b) using the blue-line path and DHDR (Legacy) (step-6c) using the red-line path. DHDR Legacy calls CMTA (step-7) to override the consent block. DHDR (Smile) and DHDR (Legacy) return separate responses to the PCOI Façade. The PCOI Façade consolidates the 2 DHDR responses and sends the resulting response to the PCOI Viewlet for display to the Provider.

  8. If the Provider selects OLIS to override, the Façade sends the override request to OLIS (step-6a), where the OLIS clinical records will be overridden. OLIS returns a success or failure response to the PCOI Façade, which sends the result to the PCOI Viewlet for display to the Provider.

The diagram below outlines the PCOI solution flow described above:

pcoi-conceptual-arch


2.1.2. System Components

Note: The descriptions in this section provide additional context regarding each component's role in the PCOI workflow. They supplement, but do not replace, the official definitions contained in the Glossary, which remains the authoritative source for term definitions.

Provincial Consent Override Interface (PCOI): PCOI is the Ontario Health application that allows an authorized healthcare provider to temporarily override a patient consent directive when access to clinical records has been blocked by consent rules.

Context Management System (CMS): This is the context store/service that holds the launch context (patient and consent-related information) used by the PCOI Viewlet.

PCOI Viewlet: This is also called the PCOI SPA (Single Page Application) is the user-facing consent override application that clinicians interact with when they need to override a patient's consent directive.

PCOI Façade: This is the integration and orchestration service that receives consent override requests from the PCOI Viewlet, validates them, gathers required patient identifiers, sends override requests to the target repositories (e.g., Smile, OLIS, DHDR Legacy) and returns the results back to the PCOI Viewlet.

Provincial Clinical Viewer (PCV): Ontario Health's Provincial Clinical Viewer (PCV) is the clinical application through which users access patient data and initiate PCOI consent overrides when access to records is restricted by a consent directive.

Line of Business (LOB): A Line of Business (LOB) is a clinical repository/domain that participates in the consent override workflow and can be individually selected for record unblocking.

Lines of Business (LOB) Domains:

  • acCDR – Acute and Community Care Clinical Data Repository. Displayed as “Acute Care” in the PCOI Viewlet.
  • miCDR – Medical Imaging. Displayed as “Medical Imaging” in the PCOI Viewlet.
  • OLIS - Ontario Laboratory Information System. Displayed as “Labs” in the PCOI Viewlet.
  • CDF-DHDR - New DHDR implementation hosted on the Clinical Data Foundation (CDF) platform and managed through the Smile architecture. Displayed as “Meds” in the PCOI Viewlet.
  • DHDR Legacy - The existing on-premises Digital Health Drug Repository. Displayed as “Meds” in the PCOI Viewlet.

SMILE Clinical Data Framework (CDF): Ontario Health's Clinical Data Framework implementation that is built on the SmileCDR platform and provides a common FHIR-based infrastructure and services layer for multiple clinical repositories and lines of business.

ONE Access Gateway (OAG): The One Access Gateway (OAG) is Ontario Health's provincial API gateway that provides secure access, authentication, authorization, routing, and auditing for PCOI and other provincial digital health services.

Consent Target String: A data element that is passed from the source application (PCV or EMR) into CMS and then used by the PCOI Viewlet to determine which consent-protected domains (LOBs) are relevant for override.

Pub/Sub (Publish/Subscribe): This is the event-driven mechanism that sends copies of consent policies from CMTA to repositories such as Smile CDF and OLIS so they can validate requests and enforce consent directives locally.

ONE ID: ONEID is the identity and authentication service used to verify a healthcare provider's identity and supplies the credentials/tokens that allow authorized users to access and use PCOI.

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