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
Data Contributor Organization Health Information Custodian (HIC) contributing records to DHDR and operator of Data Contributor System.
Data Contributor 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 Data Contributor Systems will be a Pharmacy Management System or a Hospital Information System.
Data Quality Administrator (DQA) Human An Ontario Health or Data Contributor resource that interacts with the DHDR solution to use the Data Quality Application Interface.
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 Data Contributors 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 Data Contributor personnel to review DHDR records submitted by the Data Contributor to support the conformance, clinical validation, and ongoing data quality analysis of submitted records.
DQS Application Interface System User interface that allows Data Quality Administrators to view and interact with submitted records and associated annotations that are held in the DQS database.

Use Cases

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

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

Steps:

  1. Data Contributor System submits a new dispense or administration record to DHDR Solution.
  2. Record is processed and passes all validation steps.
  3. Record is written to DHDR Solution database and is available for query by PoS systems.

    4. Alternate Workflows:

    1. Data Contributor System submits new dispense or administration record to DHDR and record fails structural, content, or referential validation with Error annotation.
      1. Data Contributor System submits a new dispense record to DHDR Solution.
      2. Record is processed and fails structural, content, or referential validation with Error annotation.
      3. Notification is generated and sent to Data Contributor.
      4. Record is written to DHDR DQS database.
      5. Record is not written to DHDR Solution database and is unavailable for query by PoS systems.
    2. Data Contributor System 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. Notification is generated and sent to Data Contributor.
      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 – Data Contributor receives notification of an Error, Warning, or Information annotation on submitted record

Data Contributor receives notification of an Error, Warning, or Information annotation on a submitted record. Data Contributor Data Quality Administrator (DQA) logs in to DQS application interface, views details of validation failure, and resubmits corrected record.

Steps:

  1. Data Contributor receives notification of an Error, Warning, or Information annotation on a submitted record.
  2. Data Contributor DQA logs in to DQS application interface.
  3. Data Contributor DQA views details of validation failure, including annotation, original messages from the Data Contributor System, and the transformed data from the DQS database.
  4. Data Contributor corrects/updates data in Data Contributor System and resubmits to DHDR Solution.

    5. Alternate Workflows:

    1. Data Contributor receives notification of a Warning or Information annotation on a submitted record. Data Contributor DQA logs in to DQS application interface, views details of validation failure, and dismisses Warning or Information annotation.
      1. Data Contributor receives notification of a Warning or Information annotation on a submitted record.
      2. Data Contributor DQA logs in to DQS application interface.
      3. Data Contributor DQA views details of validation failure, including annotation, original messages from the Data Contributor System, and the transformed data from the DQS database.
      4. Data Contributor DQA determines that no further action is required and Data Contributor does not correct and resubmit record to DHDR Solution.
    2. Data Contributor receives notification of an Error annotation on a submitted record. Data Contributor DQA logs in to DQS application interface, views details of validation failure, and is unable to correct the error.
      1. Data Contributor receives notification of an Error annotation on a submitted record.
      2. Data Contributor DQA logs in to DQS application interface.
      3. Data Contributor DQA views details of validation failure, including annotation, original messages from the Data Contributor System, and the transformed data from the DQS database.
      4. Data Contributor is unable to correct error in the Data Contributor System.
      5. Data Contributor contacts local support/system vendor and/or Ontario Health Data Quality Admin.

UC-C3 – Data Contributor System submits changed version of previously submitted dispense record

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

Steps:

  1. Data Contributor System submits changed version of a previously submitted dispense or administration record.
  2. Changed version of record is processed and passes all validation steps.
  3. 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.

    4. Alternate Workflows:

    1. Data Contributor System 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. Notification is generated and sent to Data Contributor.
      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.
    2. Data Contributor System 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. Notification is generated and sent to Data Contributor.
      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.

UC-C4 – Data Contributor System submits dispense or administration record to DHDR and fails authentication at Gateway

Data Contributor System submits dispense or administration record to DHDR Solution. Authentication fails at Gateway and an HTTP error is returned to Data Contributor System.

Steps:

  1. Data Contributor System submits a dispense or administration record to DHDR Solution.
  2. Authentication of Data Contributor System fails at Gateway and an HTTP error is returned to the Data Contributor System.
  3. Data Contributor contacts local support/system vendor and/or Ontario Health Service Desk.


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 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 the 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.
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. The record for the patient (HCN) is 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 patient 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 (HCNband DOB). The record for the patient is not found in DHDR and patient is identified to be a Newborn. 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 be 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 Medications/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 authorized users at the same authorized organization (UAO) as the person who performed the override.

    8. Alternate Workflows:

    1. Provider accesses a patient record in the Provider Application when another user from the same organization 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 user 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/ user manually placing a request.

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

DHDR receives a direct query from background process (machine-operated, no action in the application by provider (user) to make the request) which includes HCN, MRN or PMS 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 receive 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 (machine-operated, no action in the 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 (machine-operated, no user request). Query includes the request for community 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 to the provider.

DHDR receives a direct query from background process (machine-operated, no action in the 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 (machine-operated, no user request).
  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 to the provider.
  7. Temporary consent override is not permitted.