Business Context Index > Use Cases

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 medication, dispensed medication and pharmacy service 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 and web services) that enables the contribution of administered medication, dispensed medication, 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 - Data Quality Solution System This solution enables 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 community pharmacy Medication Dispense record to DHDR Solution

Primary workflow: Contributor HIC submits new community pharmacy Medication Dispense record to DHDR Solution and record passes all validations.

Steps:

  1. Contributor HIC submits a new community pharmacy Medication Dispense 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.

Alternate Workflows:

  1. Contributor HIC submits new record to DHDR and record fails structural, content, or referential validation with Error annotation.
    1. Contributor HIC submits a new 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. See UC-C4 – Contributor HIC receives HTTP response indicating that a validation failure has occurred during record processing.
    4. Record is written to 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 record to DHDR Solution and record fails referential validation with Warning and/or Information annotation (no Error).
    1. Data Contributor System submits a new 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 DQS database.
    5. Record is written to DHDR Solution database and is available for query by PoS systems.

UC-C2 – Contributor HIC submits new hospital administered medication record to DHDR Solution

Primary workflow: Contributor HIC submits new hospital administered medication record with at least one drug product (i.e., has CCDD-MP, CCDD-NTP code(s)) to DHDR Solution.
Example:

  • Medication ordered is warfarin 5 mg (product ordered is warfarin 5 mg tablet x1)
  • Medication administered is warfarin 5 mg (products administered are warfarin 2 mg tablet x1 and warfarin 3 mg tablet x1)

Note 1: The primary workflow is not applicable to compound medications, natural health products (i.e., has NPN) or medications where no CCDD-NTP or CCDD-MP code is available. For these scenarios, refer to Alternate Workflow A.
Note 2: When submitting administration records for a continuous infusion, every action shall be contributed as a standalone hospital administered medication record. Actions include, but are not limited to, starts, stops, and rate adjustments of a continuous infusion medication.

Steps:

    1. Contributor HIC submits hospital administered medication record with at least one drug product (i.e., has CCDD-MP, CCDD-NTP code(s)) to DHDR Solution as follows:
    1. One parent MedicationRequest resource with referenced Medication resource representing ordered medication information. Example: warfarin 5 mg
    2. One or more child MedicationRequest resources with referenced Medication resource capturing product information if available. Contributing HIC submits one child MedicationRequest resource with referenced Medication resource for each ordered product. Example: child: warfarin 5 mg tablet
      1. .basedOn element of each child MedicationRequest references the parent MedicationRequest resource
      2. Additional elements inherited from parent MedicationRequest resource
    3. One parent MedicationAdministration resource with referenced Medication resource representing administered medication information. Example: warfarin 5 mg
    4. One or more child MedicationAdministration resources with referenced Medication resource capturing product information if available. Contributing HIC submits one child MedicationAdministration resource for each administered product. Example: child #1: warfarin 2 mg tablet; child #2: warfarin 3 mg tablet
      1. .partOf element of each child MedicationAdministration references the parent MedicationAdministration resource
      2. Additional elements inherited from parent MedicationAdministration resource
    2. Record is processed and passes all validation steps.

    1. HTTP response is sent to Contributor HIC indicating successful processing of record.

    2. Record is written to DHDR Solution database and is available for query by PoS systems.


Alternate Workflows:

  1. Contributor HIC submits new hospital administered medication record that does not contain any drug product (i.e., no available CCDD-MP, CCDD-NTP code(s)) to DHDR Solution.
    1. Contributor HIC submits new hospital administered medication record that does not contain any drug product (i.e., no available CCDD-MP, CCDD-NTP code(s)) to DHDR Solution. No child MedicationRequest or MedicationAdministration resources are sent.
    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.
  2. Refer to UC-C1 – Alternative Workflows

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

Contributor HIC submits changed version (e.g., update, correction, cancellation/reversal) 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.

UC-C4 – 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.


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 Solution System A solution (centralized data repository, infrastructure and web services) that enables the contribution of administered medication, dispensed medication, and pharmacy service records from Contributor HICs and the sharing of this information with authorized HICs.
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 Application requests DHDR Records – Records successfully returned (Search by HCN)

Provider Application submits request for DHDR records with a specific date range and Patient identifiers (HCN and DOB). Records for the Patient are found in DHDR and are successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider Application submits two separate search requests (for community pharmacy Medication Dispense records and for hospital Medication Administration records) to Provider Gateway with the following parameters:
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  3. For each request, DHDR uses the Patient identifiers provided and calls PCR and CMTA.
    1. PCR validates Patient identity using health card number and DOB.
    2. CMTA validates that no consent block is in place.
  4. All identifiers associated with the Patient (e.g., multiple MRNs, ECID) are retrieved from PCR.
  5. DHDR searches DHDR database using all identifiers.
  6. Records are found in DHDR for community pharmacy Medication Dispense and/or hospital Medication Administration requests.
  7. DHDR returns records from DHDR for the specified Patient and date range to the Provider Application via Provider Gateway.
  8. Provider Gateway forwards response to Provider Application.
  9. Provider Application displays the relevant information received from Provider Gateway to the Provider.

    10. Alternate Workflows:

    1. Provider application requests DHDR records without specifying date parameter
      1. DHDR returns records from the DHDR to the Provider Application via Provider Gateway for a default period of 120 days.
    2. No record found
      1. DHDR returns message indicating no records found for search parameters.
    3. Patient not found
      1. Error response is returned (HTTP 404).
    4. Provider Application makes request for only community pharmacy Medication Dispense records
      1. DHDR makes calls to PCR and CMTA with HCN and DOB
      2. Patient is found in PCR, no consent block exists in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches for community pharmacy Medication Dispense records in DHDR database using all identifiers.
      4. DHDR returns community pharmacy Medication Dispense for specified Patient and date range.
    5. Provider Application makes call for only hospital Medication Administration records
      1. DHDR makes calls to PCR and CMTA with HCN and DOB
      2. Patient is found in PCR, no consent block exists in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches for hospital Medication Administration records in DHDR database using all identifiers.
      4. DHDR returns hospital Medication Administration records for specified Patient and date range.

UC-Q2 – Provider Application requests DHDR Records– Records successfully returned (Search by MRN)

Provider Application submits request for DHDR records with a specific date range and MRN (i.e., hospital or community pharmacy Patient identifier). DHDR search is completed and records for the Patient are found and successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider Application submits two separate search requests (for community pharmacy Medication Dispense records and for hospital Medication Administration records) to Provider Gateway with the following parameters:
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  3. 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
  4. All identifiers associated with the Patient (e.g., multiple MRNs, HCN, ECID) are retrieved from PCR.
  5. DHDR searches in DHDR database using Patient identifiers and search date range.
  6. Records are found in DHDR for community pharmacy Medication Dispense and/or hospital Medication Administration requests.
  7. DHDR returns records from the DHDR for the specified Patient and date range to the Provider Application via Provider Gateway.
  8. Provider Gateway forwards response to Provider Application.
  9. Provider Application displays the relevant information received from Provider Gateway to the Provider.

    10. Alternate Workflows:

    1. Provider Application requests DHDR records without specifying date parameter.
      1. DHDR returns records from the DHDR to the Provider Application via Provider Gateway for a default period of 120 days.
    2. No record found
      1. DHDR returns message indicating no records found for search parameters.
    3. Patient not found
      1. Error response is returned (HTTP 404)
    4. Provider Application makes request for only community pharmacy Medication Dispense records
      1. DHDR makes calls to PCR and CMTA with MRN and DOB
      2. Patient is found in PCR, no consent block exists in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches for community pharmacy Medication Dispense records in DHDR database using all identifiers.
      4. DHDR returns community pharmacy Medication Dispense records for specified Patient and date range.
    5. Provider Application makes call for only hospital Medication Administration records
      1. DHDR makes calls to PCR and CMTA with MRN and DOB
      2. Patient is found in PCR, no consent block exists in CMTA, and all identifiers are retrieved from PCR
      3. DHDR searches for hospital Medication Administration records in DHDR database using all identifiers.
      4. DHDR returns hospital Medication Administration records for specified Patient and date range.

UC-Q3– Provider Application requests DHDR records – Records successfully returned (Search by ECID)

Provider Application submits request for DHDR records with a specific date range and ECID (PCR Enterprise Client ID). DHDR search is completed and records for the Patient are found and successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider Application submits two separate search requests (for community pharmacy Medication Dispense records and for hospital Medication Administration records) to Provider Gateway with the following parameters:
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  3. For each request, DHDR uses the Patient identifiers provided and calls PCR and CMTA.
    1. CMTA validates that no consent block is in place.
  4. All identifiers associated with the Patient (e.g., multiple MRNs, HCN) are retrieved from PCR.
  5. DHDR searches in DHDR database using all Patient identifiers and search date range.
  6. Records are found in DHDR for community pharmacy Medication Dispense and/or hospital Medication Administration requests.
  7. DHDR returns records from DHDR for the specified Patient and date range to the Provider Application via Provider Gateway.
  8. Provider Gateway forwards response to Provider Application.
  9. Provider Application displays the relevant information received from Provider Gateway.

Alternate Workflows:

  1. Provider Application requests DHDR records without specifying date parameter
    1. DHDR returns records from the DHDR to the Provider Application via Provider Gateway for a default period of 120 days.
  2. DHDR No record found
    1. DHDR returns message indicating no records found for search parameters.
  3. Patient not found
    1. Error response is returned (HTTP 404)
  4. Provider Application makes request for only community pharmacy Medication Dispense records.
    1. DHDR makes calls to PCR and CMTA with ECID.
    2. Patient is found in PCR, no consent blocks exist in CMTA, and all identifiers are retrieved from PCR.
    3. DHDR searches for community pharmacy Medication Dispense records in DHDR database using all identifiers.
    4. DHDR returns community pharmacy Medication Dispense records for specified Patient and date range.
  5. Provider Application makes call for only hospital Medication Administration records.
    1. DHDR makes calls to PCR and CMTA with ECID
    2. Patient is found in PCR, no consent block exists in CMTA, and all identifiers are retrieved from PCR
    3. DHDR searches for hospital Medication Administration records in DHDR database using all identifiers.
    4. DHDR returns returns hospital Medication Administration records for specified Patient and date range.

Provider Application submits request for DHDR records (community pharmacy Medication Dispense records and/or hospital Medication Administration records) and all search results are blocked by a Patient Consent Directive.

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

Steps:

  1. 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 returns response message to Provider Application via the Provider Gateway indicating that access to DHDR information has been blocked by the Patient. No DHDR records are returned.
  5. Provider Application displays the message received from Provider Gateway.

UC-Q5 – Provider Application requests to temporary unblocking of a blocked DHDR record

Consent block is found (see UC-Q4). Provider obtains permission from the Patient or the Patient’s substitute decision maker (SDM), and documents permission or other valid consent reason in consent override interface to temporarily unblock the patient’s record. The Provider Application allows the user to perform a consent override and blocked records are returned by the DHDR. (This use case follows the steps after UC-Q4 steps are completed)

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

Steps:

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

  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 to select consent override reason.
  3. PCOI displays confirmation of successful temporary consent unblock.
  4. Provider Application resubmits the retrieval of DHDR records.
  5. DHDR returns the unblocked DHDR records and informational message that Patient has temporarily unblocked access to the Provider Application via Provider Gateway.
  6. Provider Application displays message that the Provider is viewing records that have been unblocked.
  7. Unblocked records remain available for up to eight hours to all Providers acting under the same Viewing 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 Viewing HIC has already performed a temporary consent unblock within the past eight-hour time frame.
      1. The Provider Application displays a notification to the Provider that consent has been temporarily unblocked. All DHDR records for search criteria are displayed.

UC-Q6 – Provider Application requests DHDR records - Records are not successfully returned due to validation or system Failure

Provider Application requests DHDR records and records are 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. Error message returned to Provider Application.
  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 Application.
  3. PCR, DHDR or Provider Gateway not available
    1. Error messages returned to Provider Application.
  4. Patient identifier fails validation in DHDR.
    1. Error message returned to Provider Application.

Data Query Use Cases – Direct Integration Queries

This section covers Data Query use cases where the Provider Application through background processes directly requests DHDR information rather than the Provider making a hands-on-keyboard request via the Provider Application.

UC-Q7 – Provider Application makes a direct (background) query for DHDR records – Records Successfully returned

Provider Application submits a direct query from background process (system-operated, no action in the Provider Application by Provider (user) to make the request) for DHDR records with a specific date range and Patient identifiers (HCN and DOB). Records for the Patient are found in DHDR and are successfully returned by DHDR via Provider Gateway.

Steps:

  1. Provider Application submits two separate direct query search requests from background process (for community pharmacy Medication Dispense records and for hospital Medication Administration records) to Provider Gateway with the following parameters:
    1. Patient identifier: Date of Birth and Ontario health card number (HCN)
    2. Search date range
    3. Optional: Gender
  2. Provider Gateway authorizes and validates the requests and forwards both requests to the DHDR.
  3. For each request, DHDR uses the Patient identifiers provided and calls PCR and CMTA.
    1. PCR validates Patient identity using health card number and DOB.
    2. CMTA validates no consent block is in place.
  4. All identifiers associated with the Patient (e.g., multiple MRNs, ECID) are retrieved from PCR.
  5. DHDR searches DHDR database using all identifiers.
  6. Records are found in DHDR for community pharmacy Medication Dispense and/or hospital Medication Administration requests.
  7. DHDR returns records from DHDR for the specified Patient and date range to the Provider Application via Provider Gateway.
  8. Provider Gateway forwards response to Provider Application.
  9. Provider Application displays the relevant information received from Provider Gateway.

    10. 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.
      2. DHDR returns community pharmacy Medication Dispense or hospital Medication Administration records, for specified Patient, date range and type of request.
    2. See alternate workflows UC-Q1 a-c.

Provider Application submits a direct query from background process (system-operated, no action in the Provider Application by Provider (user) to make the request) for DHDR records (community pharmacy Medication Dispense records and/or hospital Medication Administration records) and all search results are blocked by a Patient Consent Directive.

Steps:

  1. DHDR receives a direct query from background process.
  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 returns response message to Provider Application via the Provider Gateway indicating that access to DHDR information has been blocked by the Patient. No DHDR records are returned.
  5. Provider Application displays the message received from Provider Gateway.
  6. Temporary consent override is not permitted.