Business Context Index > Use Case

Use Cases

The use cases below provide a basic illustration of how actors interact with the DHDR.

Data Contribution Use Cases

Actors

Table- Use Case Participants

Participant Type Description
Contributor HIC Organization Health Information Custodian (HIC) contributing records to DHDR and operator of the Contributor HIC System.
Contributor HIC System System A system that is used by HICs to contribute administered drug, dispensed drugs and pharmacy services information to the DHDR. In the following Data Contribution Use Cases, the Contributor HIC Systems will be a Pharmacy Management System or a Hospital Information System.
DHDR Solution System A solution (centralized data repository, infrastructure, data quality, reporting, and web services) that enables the contribution of administered drug, dispensed drug, and pharmacy service records from Contributor HICs and the sharing of this information with authorized HICs.
PoS Systems System Represents software applications used by health care or service providers for viewing or managing personal health information (PHI). Common PoS systems include, but are not limited to, provincial clinical viewers, HIS and primary care EMRs.
DQS - DHDR Data Quality Solution System This solution, which is part of the DHDR Solution, will enable authorized Ontario Health and Contributor HIC personnel to review DHDR records submitted by the Contributor HIC to support the conformance, clinical validation, and ongoing data quality analysis of submitted records.

Use Cases

UC-C1 – Contributor HIC submits new dispense or administration record to DHDR Solution

Contributor HIC submits new dispense or administration record to DHDR Solution and record passes all validations.

Steps:

  1. Contributor HIC submits a new dispense or administration record to DHDR Solution.
  2. Record is processed and passes all validation steps.
  3. HTTP response is sent to Contributor HIC indicating successful processing of record.
  4. Record is written to DHDR Solution database and is available for query by PoS systems.

    5. Alternate Workflows:

    1. Contributor HIC submits new dispense or administration record to DHDR and record fails structural, content, or referential validation with Error annotation.
      1. Contributor HIC submits a new dispense or administration record to DHDR Solution.
      2. Record is processed and fails structural, content, or referential validation with Error annotation.
      3. HTTP response is sent to Contributor HIC indicating that an error has occurred during record validation.
      4. Record is written to DHDR Data Quality Solution (DQS) database.
      5. Record is not written to DHDR Solution database and is unavailable for query by PoS systems.
    2. Contributor HIC submits new dispense or administration record to DHDR Solution and record fails referential validation with Warning and/or Information annotation (no Error).
      1. Data Contributor System submits a new dispense or administration record to DHDR Solution.
      2. Record is processed and fails referential validation with Warning and/or Information annotation (no Error).
      3. HTTP response is sent to Contributor HIC indicating that a warning or informational message has been generated during record validation.
      4. Record is written to DHDR DQS database.
      5. Record is written to DHDR Solution database and is available for query by PoS systems.

UC-C2 – Contributor HIC receives HTTP response indicating that a validation failure has occurred during record processing.

Contributor HIC receives HTTP response indicating that a validation failure (error, warning, or informational) has occurred during record processing. Contributor HIC views details of validation failure and resubmits corrected record.

Steps:

  1. Contributor HIC receives HTTP response indicating that a validation failure has occurred during record processing.
  2. Contributor HIC views details of validation failure contained in HTTP response.
  3. Contributor HIC corrects/updates data in Contributor HIC System and resubmits to DHDR Solution.
  4. Corrected version of record is written to the DHDR Solution database, superseding previous versions of record where applicable, and is available for query by PoS systems.

    5. Alternate Workflows:

    1. Contributor HIC receives HTTP response indicating that a warning or informational message has been generated during record validation, views details of validation failure contained in HTTP response, and determines that no correction/update is required.
      1. Contributor HIC receives HTTP response indicating that a warning or informational message has been generated during record validation.
      2. Contributor HIC views details of validation failure contained in HTTP response.
      3. Contributor HIC determines that no further action is required, and Contributor HIC does not correct/update data in Contributor HIC system and resubmit record to DHDR Solution.
    2. Contributor HIC receives HTTP response indicating that validation failure (error, warning, or informational) has occurred during record processing. Contributor HIC views details of validation failure contained in HTTP response, and is unable to make correction in Contributor HIC System.
      1. Contributor HIC receives HTTP response indicating that a validation error has occurred during record processing.
      2. Contributor HIC views details of validation failure contained in HTTP response.
      3. Contributor HIC is unable to make correction in the Contributor HIC System.
      4. Contributor HIC contacts local support/system vendor and/or Ontario Health Data Quality Admin.

UC-C3 – Contributor HIC submits changed version of previously submitted dispense or administration record

Contributor HIC submits changed version (e.g., update, correction) of previously submitted dispense or administration record to DHDR and record passes all validations.

Steps:

  1. Contributor HIC submits changed version of a previously submitted dispense or administration record.
  2. Changed version of record is processed and passes all validation steps.
  3. HTTP response is sent to Contributor HIC indicating successful processing of record.
  4. Changed version of record is written to the DHDR Solution database, superseding previous versions of record where applicable, and is available for query by PoS systems.

    5. Alternate Workflows:

    1. Contributor HIC submits changed version of previously submitted dispense or administration record to DHDR Solution and changed version of record fails structural, content, or referential validation with Error annotation.
      1. HTTP response is sent to Contributor HIC indicating that an error has occurred during record validation.
      2. Changed version of record is written to DHDR DQS database.
      3. Changed version of record is not written to DHDR Solution database and is unavailable for query by PoS systems.
      4. Previously submitted version of record remains available for query by PoS systems.
    2. Contributor HIC submits changed version of previously submitted dispense or administration record to DHDR Solution and record fails referential validation with Warning or Information annotation (no Error).
      1. HTTP response is sent to Contributor HIC indicating that a warning or informational message has been generated during record validation.
      2. Changed version of record is written to DHDR DQS database.
      3. Changed version of record is written to DHDR Solution database, superseding previous versions of record where applicable, and is available for query by PoS systems.


Data Query Use Cases – Provider (User) Queries

The use cases below provide a basic illustration of how actors interact with the DHDR using the Provider Query.

Actors

Table- Use Case Participants

Participant Type Description
Provider Human An authorized PHIPA agent acting on behalf of an EHR-viewing Health Information Custodian who interacts with the system via a provider application to search a person's drug and pharmacy service information in DHDR.
Provider Application System A digital application used by a provider to search drug and pharmacy service information in DHDR. The application maintains, manages, and validates the user information and credentials prior to the request being sent to DHDR.
Provider Gateway System An interface layer that processes security and user-based information received from a provider application. The Provider Gateway authorizes the query to be processed by DHDR.
Patient An individual whose personal health information (i.e., drug and pharmacy service information in the DHDR) is requested, searched and/or accessed by the provider via a provider application
DHDR System A provincial information source of drug and pharmacy service information (EHR asset). DHDR exposes service endpoints to allow access to DHDR information.
COVaxON System The Ministry of Health’s provincial solution for COVID-19 vaccination information. A subset of COVID-19 vaccination information is made available through the DHDR; however the COVaxON system is not part of the provincial Electronic Health Record.
PCR System The Provincial Client Registry (PCR) is a repository that centrally stores and manages demographics and identifiers (e.g. MRN or HCN) pertaining to patients who have received health care in Ontario.
PCOI System The Provincial Consent Override Interface (PCOI) is the mechanism through which consent override requests from application providers are captured. Where a request by an authorized HIC for patient clinical data is made and a consent directive exists, PCOI facilitates, through a standardized web user interface, notification to the HIC of the block, recording of the override reason, and the temporary suspension of the directive permitting the HIC to view the blocked data.
CMTA System Consent Management Technology Asset (CMTA) provides the technology and support to business processes for the collection, storage, and management of consent directives for the provincial Electronic Health Record.

Use Cases

UC-Q1 – Provider requests all DHDR Information – Information successfully returned (Search by HCN)

Provider requests DHDR information via Provider Application with a specific date range and Patient identifier (HCN and DOB). Records for the Patient are found in DHDR and/or COVaxON. Information (community pharmacy dispensed information/HNS, COVaxON and hospital administered medication information) is successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider enters search criteria in Provider Application.
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Application formulates the search request and submits two separate requests to Provider Gateway for:
    1. Community pharmacy dispensed information/HNS
    2. Hospital administered medication.
  3. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  4. DHDR uses the identifiers provided and makes two calls to PCR and CMTA.
    1. PCR validates Patient identity using health card number and DOB.
    2. CMTA validates that no consent block is in place.
  5. All identifiers associated with the Patient (e.g., multiple MRNs) are retrieved from PCR.
  6. DHDR searches DHDR database using all identifiers and calls COVaxON using HCN for COVID-19 vaccination records.
  7. Information is found in DHDR for both or one of requests (2a and 2b) and/or COVaxON.
  8. DHDR returns information from the DHDR and/or COVaxON for the specified Patient and date range to the Provider Application via Provider Gateway.
  9. Provider Gateway forwards response to Provider Application.
  10. Provider Application displays the relevant information received from Provider Gateway to the Provider.

    11. Alternate Workflows:

    1. DHDR Provider requests DHDR information without specifying dispensed date parameter
      1. DHDR returns information from the DHDR and/or COVaxON to the Provider Application via Provider Gateway for a default period of:
        1. 120 days for Community pharmacy dispensed information/HNS
        2. 14 days for Hospital Administered Medication
    2. DHDR No record found
      1. DHDR returns message indicating no records found for search parameters (e.g., no records in HNS/community and hospital repository and COVaxON).
    3. Patient not found
      1. If newborn, see Newborn workflow UC-Q3.
      2. If not newborn, error response is returned (HTTP 404).
    4. Provider Application makes request for only community dispensed information (community pharmacy and HNS claims data)
      1. DHDR makes one call to PCR and CMTA (with HCN and DOB)
      2. Patient is found in PCR, no consent blocks exist in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches in DHDR database (using all identifiers) and calls COVaxON (using HCN) for COVID-19 vaccination records
      4. DHDR returns community pharmacy dispensed, HNS claims and COVaxON information for specified Patient and date range.
    5. Provider Application makes call for only Hospital administered information
      1. DHDR makes one call to PCR and CMTA (with HCN and DOB)
      2. Patient is found in PCR, no consent blocks exist in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches in DHDR database (using all identifiers). COVaxON call is not performed
      4. DHDR returns hospital administered information only for specified Patient and date range.

UC-Q2 – Provider requests all DHDR Information – Information successfully returned (Search by MRN)

Provider requests DHDR information via Provider Application with a specific date range and MRN (i.e., hospital or community pharmacy Patient identifier). DHDR search only is completed and records are found. Information (community, HNS and hospital medication information) is successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider enters search criteria in Provider Application.
    1. Date of Birth and MRN ( see Profile and Operations for MRN components)
    2. Search date range
    3. Optional: Gender
  2. Provider Application formulates the search request and submits two separate requests to Provider Gateway for:
    1. Community pharmacy dispensed information/HNS
    2. Hospital administered medication
  3. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  4. DHDR uses the identifiers provided and makes two calls to PCR and CMTA.
    1. PCR validates Patient identity using MRN and DOB.
    2. CMTA validates that no consent block is in place
  5. All identifiers associated with the Patient (e.g., multiple MRNs) are retrieved from PCR.
  6. DHDR searches in DHDR database only (using Patient identifiers and search date range). COVaxON call is not performed (requires HCN).
  7. Information is found in DHDR for both requests (2a and 2b) or one request.
  8. DHDR returns information from the DHDR for the specified Patient and date range to the Provider Application via Provider Gateway.
  9. Provider Gateway forwards response to Provider Application.
  10. Provider Application displays the relevant information received from Provider Gateway to the Provider.

    11. Alternate Workflows:

    1. DHDR Provider requests DHDR information without specifying dispensed or administered date parameter
      1. For Community Pharmacy Dispensed/HNS request, DHDR returns information from the DHDR for the default parameter of 120 days to the Provider Application via Provider Gateway.
      2. For Hospital Administered Medications request, DHDR returns information from the DHDR for the default parameter of 14 days to the Provider Application via Provider Gateway
    2. DHDR No record found
      1. DHDR returns message indicating no records found for search parameters (no records in HNS/community and hospital repository)
    3. Patient not found
      1. If newborn, see Newborn workflow UC-Q3
      2. If not newborn, error response is returned (HTTP 404)
    4. Provider Application makes request for only community dispensed information (community pharmacy and HNS claims data)
      1. DHDR makes one call to PCR and CMTA (with MRN and DOB)
      2. Patient is found in PCR, no consent blocks exist in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches in DHDR database (using all identifiers).
      4. DHDR returns community pharmacy dispensed, HNS claims information for specified Patient and date range.
    5. Provider Application makes call for only Hospital administered information
      1. DHDR makes one call to PCR and CMTA (with MRN and DOB)
      2. Patient is found in PCR, no consent blocks exist in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches in DHDR database (using all identifiers).
      4. DHDR returns hospital administered information for specified Patient and date range.

UC-Q3– Provider requests DHDR information - Information successfully returned (Newborn)

Provider requests DHDR information via Provider Application with a specific date range and Patient identifier (HCN and DOB). The Patient is not found in PCR. DHDR identifies Patient to be a newborn and searches for records. Information (community, HNS and hospital medication information) is successfully returned by DHDR via Provider Gateway.

Steps: Search by HCN

  1. Provider enters search criteria in Provider Application (Search by HCN)
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Application formulates the search request and submits two separate requests to Provider Gateway for:
    1. Community pharmacy dispensed information/HNS.
    2. Hospital administered medication
  3. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  4. DHDR uses the identifiers provided and makes two calls to PCR and CMTA.
    1. PCR searches using health card number and DOB and does not find Patient.
    2. DHDR identifies the Patient to have been born within 182 days of the present date.
  5. DHDR searches DHDR database and calls COVaxON using HCN for COVID-19 vaccination records.
  6. DHDR returns information from the DHDR and/or COVaxON for the specified Patient and date range to the Provider Application via Provider Gateway.
  7. Provider Gateway forwards response to Provider Application.
  8. Provider Application displays the relevant information received from Provider Gateway to the provider.

    9. Alternate Workflows:

    1. Search by MRN
      1. Provider enters search criteria for Patient: Date of Birth and MRN
      2. Steps 2 and 3 above.
      3. DHDR makes two calls to PCR and CMTA.
      4. PCR searches using MRN and DOB and does not find Patient.
      5. DHDR identifies the Patient to be born within 182 days of the present day.
      6. DHDR searches DHDR using MRN and returns DHDR information for specified Patient identifier to Provider Gateway.
      7. Steps 7-8 above.
    2. DHDR Provider Application requests DHDR information without specifying date parameter
      1. DHDR returns information from the DHDR and/or COVaxON to the Provider Application via Provider Gateway for a default period of:
        1. 120 days for Community pharmacy dispensed information/HNS/COVaxON request
        2. 14 days for Hospital Administered Medication request
    3. DHDR No record found
      1. DHDR returns message indicating no records found for search parameters (i.e., no HNS/community or hospital records found)

UC-Q4– Provider requests details of a specific DHDR record

After successful return of DHDR records, Provider requests details of a specific DHDR record (e.g., selects one record from list of records); follows completion of UC-Q1 or UC-Q2. COVaxON records are available only in the Community Pharmacy Dispensed/HNS response.

Assumption: Provider application does not save/store bundled search response from the DHDR

Steps:

  1. Provider performs an action in Provider Application to view details of a specific DHDR and/or COVaxON record.
  2. Provider Application formulates the request (“read” request using the MedicationDispense ID or the MedicationAdministration ID depending on the type of record) and submits it to Provider Gateway.
  3. Provider Gateway authorizes and validates the request and forwards to DHDR.
  4. DHDR searches DHDR database or calls COVaxON.
  5. Information is found in DHDR or COVaxON.
  6. DHDR returns information from the DHDR or COVaxON to the Provider Application via Provider Gateway.
  7. Provider Gateway forwards response to Provider Application.
  8. Provider Application displays the relevant information received from Provider Gateway to the provider.

UC-Q5 – Provider requests DHDR information - COVaxON information is not returned (COVaxON is not available)

Provider requests DHDR information and COVaxON COVID-19 vaccination information is not successfully returned because COVaxON is not available. DHDR information is returned if available.

Steps:

  1. Provider enters search criteria in Provider Application using Date of Birth and Ontario health card number at minimum and requests Community Pharmacy dispensed information.
  2. Provider Application formulates the search request and submits request to Provider Gateway for Community Pharmacy dispensed information.
  3. Provider Gateway authorizes and validates the request and forwards to DHDR.
  4. DHDR calls PCR and CMTA. Patient is validated and no consent blocks exist.
  5. DHDR searches in DHDR database and calls COVaxON (with HCN).
  6. Call to COVaxON API is unsuccessful (e.g., DHDR query times out or COVaxON API not available).
  7. DHDR returns relevant DHDR results (if found) and notification message that COVID-19 vaccination information is unavailable to Provider Application via Provider Gateway.
  8. Provider Gateway forwards response to Provider Application.
  9. Provider Application displays the relevant information received from Provider Gateway, including notification message, to the Provider.

Provider requests DHDR information via Provider Application and all search results are blocked by a Patient Consent Directive.

NOTE: Use cases UC-Q6 and UC-Q7 and any use cases involving consent are subject to change.

Steps:

  1. After request(s) is/are validated by Provider Gateway and forwarded to DHDR:
  2. DHDR calls PCR and CMTA. Patient is validated.
  3. CMTA finds a block on the Patient’s record. CMTA does not find an active consent override for the Patient and user organization.
  4. DHDR solution returns response message (via the Provider Gateway) that access to DHDR information has been blocked by the Patient. No DHDR (or COVaxON as per necessary search request and Patient identifier) records are returned.
  5. Provider Application displays the message received from Provider Gateway to the Provider.

UC-Q7 – Provider requests to temporarily unblock a blocked DHDR record

Consent block is found. Provider obtains permission from the Patient or the Patient’s substitute decision maker (SDM) to temporarily unblock their record, documents consent via the DHDR Temporary Unblocking of Access form, then stores the paper form securely for audit. The Provider Application allows the user to perform a consent override. (This use case follows the steps after UC-Q6 steps are completed)

NOTE: Use cases UC-Q6 and UC-Q7 and any use cases involving consent are subject to change.

Steps:

After Provider Application displays message indicating consent directive is in place (Step 6 of UC-Q7):

  1. Provider selects action in the Provider Application to initiate Consent Directive Override. Provider application launches the Provincial Consent Override Interface (PCOI) (hosted on an Ontario Health webserver), returning a web-based user interface.
  2. Provider completes prompts on PCOI which include access to a Temporary Unblocking of Access form to obtain written consent and express consent options.
  3. PCOI displays confirmation of successful temporary consent unblock.
  4. Provider Application resubmits the retrieval of DHDR information.
  5. DHDR returns the unblocked DHDR messages to the Provider Application (via Provider Gateway) and informational message that Patient has temporarily unblocked access. COVaxON messages are also returned if required search request and Patient identifier provided.
  6. Provider Application displays message that the Provider is viewing information that has been unblocked.
  7. Unblocked information is available for up to four hours to all Providers acting under at the same HIC as the Provider who performed the override.

    8. Alternate Workflows:

    1. Provider accesses a Patient record in the Provider Application when another Provider from the same HIC has already obtained temporary consent unblock from the Patient or SDM within the past four-hour time frame.
      1. The Provider Application displays a notification to the Provider that consent has temporarily been unblocked. All DHDR records for search criteria are displayed.

UC-Q8 – Provider requests DHDR information - Information is not successfully returned due to validation or system Failure

Provider requests DHDR information via Provider Application and information is not successfully returned by DHDR via Provider Gateway due to validation or system failures.

Workflows not expanded:

  1. Provider Application request fails validation in Provider Gateway (e.g., Provider Application user is not authorized to access application)
    1. Negative response returned to Provider
  2. Provider Application request fails validation in DHDR (e.g., Provider Application request contains date range where TO date value is prior to FROM date value)
    1. Error messages returned to Provider
  3. PCR, DHDR or Provider Gateway not available
    1. Error messages returned to Provider
  4. Patient identifier fails validation in DHDR.
    1. DHDR returns error message. No DHDR information returned.

Data Query Use Cases – Direct Integration Queries

This section covers Data Query use cases where the Provider Application itself with the help of background processes is requesting the information rather than the Provider manually placing a request via the Provider Application.

UC-Q9 – Provider Application makes a direct (background) query for DHDR information – Information Successfully returned

DHDR receives a direct query from background process (system-operated, no action in the Provider Application by Provider (user) to make the request) which includes HCN or MRN Patient identifier and DOB and specific date range. Information is successfully returned. Direct query includes request for Community Pharmacy dispensed information and Hospital administered information.

Steps:

  1. DHDR receives a direct query from background process. Query includes two separate requests to DHDR.
  2. DHDR makes two calls to PCR and CMTA.
  3. DHDR retrieves the Patient ECID through PCR.
  4. Using the ECID, DHDR calls CMTA to check if Patient has a consent directive block in place.
  5. CMTA validates no consent block is in place.
  6. DHDR searches DHDR database and calls COVaxON (as per required search request and Patient identifier).
  7. DHDR returns all DHDR and/or all COVaxON records available for the HCN and search date range to the Provider Application via Provider Gateway.

    8. Alternate Workflows:
    1. DHDR receives direct query which contains one DHDR request (e.g., community pharmacy dispensed information or hospital administered information)
      1. DHDR calls PCR and CMTA. Patient validated. No consent block in place and DHDR searches in DHDR database (using all identifiers) and calls COVaxON (if required search request and Patient identifier provided).
      2. DHDR returns community pharmacy dispensed/ COVaxON or hospital medication information for specified Patient, date range and type of request.
    2. See alternate workflows UC-Q1 a-c.

UC-Q10 – Provider Application makes a direct (background) query for DHDR information - COVaxON information is not returned (COVaxON is not available)

DHDR receives a direct query from background process (system-operated, no action in the Provider Application by Provider (user) to make the request) which includes HCN and DOB and request for Community pharmacy dispensed information. COVaxON information is not successfully returned because COVaxON is not available. Therefore, only DHDR information is returned.

Steps:

  1. DHDR receives a direct query from background process. Query includes the request for community dispensed information.
  2. DHDR makes two calls to PCR and CMTA.
  3. Steps 2-6 above (UC-Q9).
  4. Call to COVaxON API is unsuccessful (e.g., DHDR query times out or COVaxON API not available).
  5. DHDR returns all records for the search parameters and notification message that COVID-19 vaccination information is unavailable to Provider Application via Provider Gateway.
  6. Provider Application displays information received from Provider Gateway including notification message.

DHDR receives a direct query from background process (system-operated, no action in the Provider Application by Provider (user) to make the request) which includes HCN or MRN and DOB. A Patient Consent Directive exists for DHDR records.

Steps:

  1. DHDR receives a direct query from background process.
  2. Steps 2-6 above (UC-Q9).
  3. CMTA validates and finds a block (consent directive) on the Patient’s record.
  4. DHDR solution returns response message (via the Provider Gateway) that access to DHDR information has been blocked by the Patient. No DHDR records (or COVaxON records if required search request and Patient identifier provided) are returned.
  5. This message will be generated even if the organization has an active temporary consent override in place (during a 4-hour window).
  6. Provider Application displays the message received from Provider Gateway.
  7. Temporary consent override is not permitted.