Business Context Index > Use Cases

Use Cases

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

Actors

Participant Type Description
Data Contributor Organization HICs who generates medical imaging data and contributes to miCDR. A HIC is defined as "A person or organization that has custody or control of personal health information for the purpose of health care or other health-related duties. Examples include physicians, hospitals, pharmacies, laboratories and the Ministry of Health." In this implementation guide, OCINet submits the data to miCDR on behalf of HICs.
Data Contributor System System OCINet information system that receives medical imaging data from DIRs and send them to miCDR. In the following Data Contribution Use Cases, the Data Contributor Systems will be OCINet system.
miCDR System A centralized data repository that enables the contribution of MI report, order, and imaging study records from Data Contributors and the sharing of this information with authorized HICs.
PoS Systems System Provinical clinical viewer who queries miCDR and displays the data in the response
Provider Human An authorized HIC agent acting on behalf of an EHR-viewing Health Information Custodian Organization who interacts with the system via a provider application to search a person's Medical Imaging information in miCDR.
Provider Application System A digital application used by a provider to search Medical Imaging information in miCDR. The application maintains, manages, and validates the user information and credentials prior to the request being sent to miCDR.
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 miCDR.
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.
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.
HIC Human or Organization A Health Information Custodian (HIC) is a person or organization that has custody or control of personal health information, as a result of their duties or powers. This means they are responsible for collecting, using, and disclosing this information in accordance with PHIPA rules.

Data Contribution Use Cases

UC-C1 – OCINet submits new MI record (report, order or imaging study) to miCDR

OCINet submits a new MI record to miCDR and record passes all validations.

Steps:

  1. OCINet submits a new MI record to miCDR.
  2. Record is processed and passes all validation steps.
  3. Record is written to miCDR and is available for query
  4. A Documentreference resource is written to miCDR and is available for query.

Alternate Workflows:

  1. OCINet submits a new MI record to miCDR and a record fails structural, content, or referential validation with Error annotation.
    1. OCINet submits a new MI record to miCDR.
    2. Record is processed and fails structural, content, or referential validation with Error annotation.
    3. HTTP response and applicable OperationOutcome are generated and sent to OCINet.
    4. Record is not written to miCDR and is unavailable for query.
  2. OCINet submits a new MI record to miCDR and a record fails referential validation with Warning and/or Information annotation (no Error).
    1. OCINet submits a new MI record to miCDR.
    2. Record is processed and fails referential validation with Warning and/or Information annotation (no Error).
    3. HTTP response and applicable OperationOutcome are generated and sent to OCINet.
    4. Record is written to miCDR and is available for query
    5. A Documenteference resource is written to miCDR and is available for query.

UC-C2 – OCINet submits a changed version of a previously submitted MI record

OCINet submits a changed version (e.g., update, correction) of a previously submitted MI record to miCDR and this record passes all validations.

Steps:

  1. OCINet submits changed version of a previously submitted MI record.
  2. Changed version of record is processed and passes all validation steps.
  3. Changed version of record is written to miCDR, superseding previous versions of record where applicable, and is available for query.
  4. A Documenteference resource gets updated in miCDR and is available for query.

Alternate Workflows:

  1. OCINet submits a changed version of a previously submitted MI record to miCDR and a changed version of record fails structural, content, or referential validation with Error annotation.
    1. HTTP response and applicable OperationOutcome are generated and sent to OCINet.
    2. Changed version of a record is not written to miCDR and is unavailable for query.
  2. OCINet submits changed version of previously submitted MI record to miCDR and record fails referential validation with Warning or Information annotation (no Error).
    1. HTTP response and applicable OperationOutcome are generated and sent to OCINet.
    2. Changed version of record is written to miCDR, superseding previous versions of record where applicable, and is available for query.
    3. A Documenteference resource gets updated in miCDR and is available for query.

Data Consumption Use Cases – EHR Viewing Channel Queries

The use cases below provide a basic illustration of how a user interacts with miCDR using EHR viewing channels such as provincial clinical viewer (PCV).

UC-Q1 – User requests a list of Patient's MI Information (reports, and/or orders, and/or imaging studies)

Summary

User requests a list of MI information via provider application with a specific date range and patient identifier. The requested information include (MI report(s), and/or order(s), and/or imaging study(s) information).

Pre-Conditions

  1. User is authenticated and authorized to access EHR Viewing Channel.
  2. miCDR and Provider Gateway are operational.
  3. Patient identifiers and consent status are available in PCR and CMTA.

Primary Flow

  1. User enters search criteria in EHR Viewing Channel.
  2. EHR Viewing Channel formulates the search request and submits a DocumentReference search request to the Provider gateway
  3. Provider Gateway authorizes and validates the requests and forwards a request to miCDR.
  4. miCDR uses patient 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. Searches miCDR using patient identifiers.
  7. Information is found in miCDR.
  8. miCDR returns information (DocumentReference resources) from miCDR for the specified patient to EHR Viewing Channel via the Provider Gateway.
  9. Provider Gateway forwards response to EHR Viewing Channel.
  10. EHR Viewing Channel displays the relevant information received from the Provider Gateway to a provider.

Alternate Flow

  1. No records found

    1. miCDR returns a message indicating that no records were found for the provided search parameters.

  2. Records found, but not returned due to existence of consent block

    1. miCDR returns an OperationOutcome message indicating records are blocked due to consent

Post-Conditions

  1. Success: User receives the requested MI information in EHR Viewing Channel.

    1.1. If records are blocked by consent, user can perform consent override. If override is successful, the record will be returned.

  2. Failure: No MI records are returned; an empty bundle indicates that no records were found.


UC-Q2 – Provider requests details of a specific miCDR record

Summary

After successfully receiving a list of MI records, a provider (i.e., clinician) requests details of a specific record. miCDR returns the detailed information via EHR Viewing Channel such as PCV.

Pre-Conditions

  1. User has successfully retrieved MI records (completion of UC-Q1).
  2. miCDR and Provider Gateway are operational.

Primary Flow

  1. Provider performs an action in EHR Viewing Channel to view details of a specific miCDR record.
  2. EHR Viewing Channel formulates the request (HTTP GET to the URI of the selected MI record) and submits it to the Provider Gateway.
  3. Provider Gateway authorizes and validates the request, then forwards it to miCDR.
  4. miCDR returns the MI record details to EHR Viewing Channel via the Provider Gateway.
  5. Provider Gateway forwards the response to EHR Viewing Channel.
  6. EHR Viewing Channel displays the detailed MI information to the provider.

Alternate Flow

  1. No records found
    1. miCDR returns a message indicating no records were found for the provided search parameters.
    2. EHR Viewing Channel displays a message to the provider.

Post-Conditions

  1. User views the detailed MI record successfully.

UC-Q3 – Provider requests a list of MI records of a sepcific type (either MI reports, or orders, or imaging studies) using EHR Viewing Channel

Summary

Provider requests a list of MI records of a specific type (reports, orders, or imaging studies) using EHR Viewing Channel. miCDR searches and returns the requested information via the Provider Gateway.

Pre-Conditions

  1. User has successfully retrieved MI records (completion of UC-Q1).
  2. miCDR and Provider Gateway are operational.
  3. Patient identifiers and consent status are available in PCR and CMTA.

Primary Flow

  1. Provider selects to search for MI reports, orders, or imaging studies and enters search criteria in EHR Viewing Channel.
  2. EHR Viewing Channel formulates the search request and submits it to the Provider Gateway.
  3. Provider Gateway authorizes and validates the request, then forwards it to miCDR.
  4. miCDR uses the patient identifiers provided and calls:
    1. PCR to validate patient identity (health card number and DOB).
    2. CMTA to validate that no consent block is in place.
  5. All identifiers associated with the patient (e.g., multiple MRNs) are retrieved from PCR.
  6. miCDR searches for the requested MI records using the patient identifiers.
  7. Information is found in miCDR.
  8. miCDR returns the requested information (reports, orders, or imaging studies) from miCDR for the specified patient to EHR Viewing Channel via the Provider Gateway.
  9. Provider Gateway forwards the response to EHR Viewing Channel.
  10. EHR Viewing Channel displays the relevant information to the provider.

Alternate Flow

  1. No records found

    1. miCDR returns a message indicating no records were found for the provided search parameters.

  2. Records found, but not returned due to existence of consent block

    1. miCDR returns an OperationOutcome message indicating records are blocked due to consent

Post-Conditions

  1. Success: Provider views the requested MI records in EHR Viewing Channel.

    1.1. If records are blocked by consent, user can perform consent override. If override is successful, the record will be returned.

  2. Failure: No MI records are returned; an empty bundle indicates that no records were found.