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 Health Information Custodian (HIC) contributing records to MiCDR and operator of Data Contributor System.
Data Contributor System System A system that is used by HICs to contribute medical imaging data to MiCDR. In the following Data Contribution Use Cases, the Data Contributor Systems will be a Diagnostic Imaging Repository.
MiCDR System A entralized 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 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.
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 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.

Data Contribution Use Cases

UC-C1 – Data Contributor System submits new MI record (report, order or imaging study) to MiCDR

Data Contributor System submits a new MI record to MiCDR and record passes all validations.

Steps:

  1. Data Contributor System 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 by PoS systems.
  4. A Documenteference resource is written to MiCDR and is available for query by PoS systems.

Alternate Workflows:

  1. Data Contributor System submits a new MI record to MiCDR and a record fails structural, content, or referential validation with Error annotation.
    1. Data Contributor System submits a new MI record to MiCDR.
    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 not written to MiCDR and is unavailable for query by PoS systems.
  2. Data Contributor System submits a new MI record to MiCDR and a record fails referential validation with Warning and/or Information annotation (no Error).
    1. Data Contributor System submits a new MI record to MiCDR.
    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 MiCDR and is available for query by PoS systems.
    5. A Documenteference resource is written to MiCDR and is available for query by PoS systems.

UC-C2 – Data Contributor System submits a changed version of a previously submitted MI record

Data Contributor System submits a changed version (e.g., update, correction) of a previously submitted MI record to MiCDR and this record passes all validations.

Steps:

  1. Data Contributor System 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 by PoS systems.
  4. A Documenteference resource gets updated in MiCDR and is available for query by PoS systems.

Alternate Workflows:

  1. Data Contributor System 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. Notification is generated and sent to Data Contributor.
    2. Changed version of a record is not written to MiCDR and is unavailable for query by PoS systems.
  2. Data Contributor System submits changed version of previously submitted MI record to MiCDR 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 MiCDR, superseding previous versions of record where applicable, and is available for query by PoS systems.
    3. A Documenteference resource gets updated in MiCDR and is available for query by PoS systems.

Data Consumption Use Cases – Provider (User) Queries

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

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

Provider requests a list of MI information via provider application with a specific date range and patient identifier. The record(s) for the patient's identifier is found in MiCDR. Information (MI report(s), and/or order(s), and/or imaging study(s) information) is successfully returned by MiCDR via the Provider Gateway.

Steps:

  1. Provider enters search criteria in Provider Application.
  2. Provider Application 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 a provider application via the Provider Gateway.
  9. Provider Gateway forwards response to Provider Application.
  10. Provider Application displays the relevant information received from the Provider Gateway to a provider.

Alternate Workflow:

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

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

After successful return of MiCDR records, a provider requests details of a specific MiCDR record (e.g., selects one record from the list of records); follows completion of UC-Q3.

Steps:

  1. Provider performs an action in Provider Application to view details of a specific MiCDR record.
  2. Provider Application formulates the request (this triggers an HTTP GET to the URI of the MI record in the list) and submits it to the Provider Gateway.
  3. Provider Gateway authorizes and validates the request and forwards to MiCDR.
  4. MiCDR returns information from MiCDR to a provider application via the Provider Gateway.
  5. Provider Gateway forwards response to Provider Application.
  6. Provider Application displays the relevant information received from the Provider Gateway to a provider.

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

After successful return of MI records, a provider requests details of a specific MI record (e.g., selects one record from the list of records); follows completion of UC-Q3.

Provider requests a list of MI information via provider application with a specific date range and patient identifier. The record(s) for the patient's identifier is found in MiCDR. Information (MI report(s), and/or order(s), and/or imaging study(s) information) is successfully returned by MiCDR via the Provider Gateway.

Steps:

  1. Provider selects to search for MI reports, or orders, or imaging studies and enters search criteria in Provider Application.
  2. Provider Application formulates the search request and submits a 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. MiCDR performs the search using patient identifiers.
  7. Information is found in MiCDR.
  8. MiCDR returns information (MI reports, or orders, or imaging studies) from MiCDR for the specified patient to a provider application via the Provider Gateway.
  9. Provider Gateway forwards response to Provider Application.
  10. Provider Application displays the relevant information received from the Provider Gateway to a provider.

Alternate Workflow:

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