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

3.2. Implementer Responsibility

3.2.1. Privacy and Security

Note: This Privacy and Security section is under review and is expected to be updated based on feedback from Ontario Health Privacy and Legal. The heading and content may change in a future revision of this Implementation Guide.

Under PHIPA, Ontario Health (OH) is a Prescribed Organization (PO) with the power and duty to develop and maintain the electronic health record. In doing so, OH manages and integrates personal health information (PHI) it receives from HICs and enables HICs to collect, use and disclose personal health information by means of the EHR.

HICs who contribute records of PHI to OH as a PO are not considered to be disclosing said records to OH, nor is OH as PO considered to be collecting same from the HIC. Despite this, HICs have responsibilities related to this contribution of PHI and are required to complete onboarding processes, comply with OH privacy and security policies, procedures, and standards, and contribute PHI in accordance with interoperability specifications established by OH. These and other requirements are set forth in the EHR Contributor Agreement (ECA) and other OH agreements as applicable, which OH executes with contributing HICs.

HICs who view records of PHI by means of the EHR are considered to be either collecting said records if the records were contributed by a different HIC, or using said records if the records were contributed by the viewing HIC. When a viewing HIC collects PHI, this is also considered a disclosure by the contributing HIC. Accordingly, HICs have responsibilities related to viewing of PHI and are required to complete onboarding processes, comply with OH privacy and security policies, procedures, and standards, adhere to consent override requirements, and to query PHI in accordance with the interoperability specifications established by OH. These and other requirements are set forth in the EHR Access Services Schedule of the OH Services Agreement (ESA) and other OH agreements as applicable, which OH executes with viewing HICs.

This document is an interoperability specification established by OH pursuant to O. Reg. 329/04 subsection 27(1) and referenced under “EHR Data-In Interface Specifications” in the ECA. Accordingly, subject to the Scope section “Applying the DHDR Data Contribution & Query HL7 FHIR IG” of this document, the specified HICs who contribute and query EHR PHI are required to ensure the specified digital health assets comply with this interoperability specification.

Further to the above, the specified HICs are also required to provide a report to the OH, upon the request by OH that sets out their compliance with the requirement to select, develop or use digital health assets that comply with this interoperability specification. Such reports must be provided by the HIC through the means, in the format, and within the time period determined by OH. These HICs also must co-operate with and assist OH in monitoring their own compliance with the requirements and must provide any information or records (Which must not include PHI) to OH upon request.

Should OH find reasonable grounds to believe that a HIC has contravened or is about to contravene the requirement to select, develop or use digital health assets that comply with this interoperability specification, OH may make a complaint to the Commissioner under Part VI of the Act and may provide to the Commissioner any information and records obtained under O. Reg. 329/04 sections 32 and 33.

Of note, this interoperability specification by itself does not serve to mandate contribution by HICs to the EHR, but rather establishes the business and/or technical requirements applicable to contribution by specified HICs and specified digital health assets. The information herein is to be read in conjunction with the terms and conditions set forth in the ECA, the EHR Access Services Schedule of the ESA, and any other applicable agreements. For greater certainty, nothing within this interoperability specification relieves a HIC of its obligation to comply with any provisions of PHIPA and its regulations.

3.2.2. User Credentials

To support all instances where personal health information is collected, used and disclosed, user credential information SHALL be included in each applicable eForms transaction for audit and logging purposes and to identify the user who initiated the request, when that request was initiated by an actual user (as opposed to when performed by a system with no PHI disclosure to an individual user). Refer to the Connectivity section for further details.

3.2.3. System Responsibility for User Authorization and Authentication

A "system" level integration is when an eForms client (e.g., a Point of Service (PoS) system representing many users) integrates to render and process eForms, instead of registering individual users at the integration boundary. In this case, access is granted to the client system and all users accessing through that system are treated under the client’s trust relationship.

The responsibility to authenticate and authorize individual user access is delegated to the implementing organization operating the client system. The implementing organization must ensure that individual users access eForms and PHI as required by Ontario Health’s privacy and security policies and any applicable agreements.

The implementing organization is responsible for ensuring the accuracy of the identity of the individual requester represented in the transaction. User identities must be tied to authenticated user accounts.

3.2.4. System responsibilities for conformance (actor support)

Systems conforming to this IG SHALL implement one or more of the actors defined in the Conformance Rules section (e.g., Renderer, Population Engine, Extraction Engine, QR Narrative Generator). A given system might support only one actor or it might support multiple. Conformance with this IG means that a system SHALL meet the obligations that apply to each actor it declares.

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.2.5. Auditing

Implementers SHALL audit user-initiated activities such as retrieval of Questionnaires, rendering and completion of Questionnaires, submission or storage of QuestionnaireResponses, and any extraction or narrative generation workflows that involve PHI. Audit logs are maintained by the implementing system to audit PHI disclosure to end users and support investigation of inappropriate access.

3.2.6. Logging

Implementers SHALL log all user-initiated or system-initiated activities that occur as part of eForms workflows (e.g., HTTP GET or POST requests where applicable).

• Application logs are tracked by the implementing system for activities performed by the system. PHI SHALL NOT be stored in application log files.
• Access logs are tracked by the implementing system when the user accesses the system. PI may be stored in access logs.
• Application logs should log the API request/response HTTP responses codes and operational outcome.

All of the above logs are retained in accordance with the implementer’s obligations as defined by and applicable PHIPA agreements or other agreements with Ontario Health.