For a full list of available versions, see the Directory of published versions
2.3. Use Cases
The use cases below provide a basic illustration of how actors interact with miCDR.
2.3.1. Actors
| Participant |
Type |
Description |
| Data Contributor |
Organization |
Hospitals and ICHSCs |
| Data Contributor System |
System |
Hospital information system that generates medical imaging data and sends them to miCDR. In the following data contribution use cases, the data contributor systems include systems used by hospitals and ICHSCs. |
| 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 using their EHR viewing channel |
| EHR Viewing Channel |
System |
A software application used by health information custodians for viewing or managing personal health information (PHI). Common EHR viewing channels are point of service systems that include, but are not limited to, provincial clinical viewers, health information system (HIS) and primary care electronic medical records (EMRs). |
| Provider |
Human |
An authorized HIC 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. |
| One Access Gateway |
System |
An interface layer that processes security and user-based information received from a system requesting access to miCDR. One Access Gateway authenticates the access request and authorizes the request 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 EHR. |
| 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
2.3.2. UC-C1 - Data Contributor submits new MI record (report or order) to miCDR
Actors
Refer to section above i.e., 2.3.1. Actors.
Summary
A data contributor submits a medical imaging (MI) record (report or order) to miCDR. miCDR validates the submission and, if successful, stores the MI record.
Pre-Conditions
- Data contributor is authenticated and authorized by the One Access Gateway.
- miCDR is available to receive submissions.
Primary Flow
- Data Contributor submits a new MI record to miCDR.
- Record is processed and passes all validation steps.
- Record is stored in miCDR and a success response is sent back to data contributor. A DocumentReference resource is also generated and stored in miCDR.
Alternate Flow
- Data contributor submits a new MI record to miCDR and the record fails structural, content, or referential validation with Error annotation. (Error)
- Data contributor submits a new MI record to miCDR.
- Record is processed and fails structural, content, or referential validation with Error annotation.
- Error notification is generated and sent to Data Contributor.
- Record is not stored in miCDR.
- Data contributor submits a new MI record to miCDR and a record fails referential validation with Warning and/or Information annotation. (No Error, Warning/Information only)
- Data contributor submits a new MI record to miCDR.
- Record is processed and fails referential validation with Warning and/or Information annotation (no Error).
- Warning or informational notification is generated and sent to data contributor.
- Record is written to miCDR. A DocumentReference resource is also generated and stored in miCDR.
Post-Conditions
- Success: MI record and DocumentReference are available for query.
- Failure: Record is not stored and data contributor is notified of errors.
2.3.3. UC-C2 - Data Contributor submits a changed version of a previously submitted MI record
Actors
Refer to section above i.e., 2.3.1. Actors.
Summary
A data contributor submits a changed version (update or correction) of a previously submitted MI record to miCDR. miCDR validates the updated record and, if successful, stores it, supersedes previous versions where applicable. The corresponding DocumentReference resource is also updated and available for query.
Pre-Conditions
- Data contributor is authenticated and authorized.
- miCDR is available to receive submissions.
- The original MI record exists in miCDR.
Primary Flow
- Data contributor submits a changed version of a previously submitted MI record.
- Changed version of record is processed and passes all validation steps.
- Changed version of record is written to miCDR, superseding previous versions of record where applicable.
- The corresponding DocumentReference resource gets updated in miCDR.
Alternate Flow
- Data contributor 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.
- Data contributor submits a changed version of a previously submitted MI record to miCDR.
- miCDR processes the record and detects structural, content, or referential validation errors (Error annotation).
- Error notification describing the validation errors is generated and sent to the data contributor.
- The changed record is not stored in miCDR.
- Data contributor submits changed version of previously submitted MI record to miCDR and record fails referential validation with Warning or Information annotation (no Error, Warning/Information only).
- Warning or informational notification is generated and sent to the data contributor.
- The changed record is stored in miCDR, superseding previous versions where applicable.
- The corresponding DocumentReference resource is updated.
Post-Conditions
- Success: The system updates the record and returns only the most recent version in search results.
- Failure: The system rejects the change and the previous record remains active. The system notifies the data contributor of the specific validation errors or warnings.
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) and other point of service systems.
Summary
User requests a list of MI information via EHR view channels 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.
Pre-Conditions
- User is authenticated and authorized to access EHR Viewing Channel.
- miCDR and One Access Gateway are operational.
- Patient identifiers and consent status are available in PCR and CMTA.
Primary Flow
- User enters search criteria in EHR Viewing Channel.
- EHR Viewing Channel formulates the search request and submits a DocumentReference search request to One Access Gateway
- One Access Gateway authorizes and validates the requests and forwards a request to miCDR.
- miCDR uses patient identifiers provided and makes two calls to PCR and CMTA.
- PCR validates patient identity using health card number and DOB.
- CMTA validates that no consent block is in place.
- All identifiers associated with the patient (e.g., multiple MRNs) are retrieved from PCR.
- Searches miCDR using patient identifiers.
- Information is found in miCDR.
- miCDR returns information (DocumentReference resources) from miCDR for the specified patient to EHR Viewing Channel via One Access Gateway.
- One Access Gateway forwards response to EHR Viewing Channel.
- EHR Viewing Channel displays the relevant information received from One Access Gateway to the user.
Alternate Flow
- No records found
- miCDR returns a message indicating that no records were found for the provided search parameters.
Post-Conditions
- Success: User receives the requested MI information in EHR Viewing Channel.
- Failure: No MI records are returned; a notification indicates that no records were found.
2.3.5. UC-Q2 – User requests details of a specific miCDR record
Summary
After successfully receiving a list of MI records, a user requests details of a specific record. miCDR returns the detailed information via EHR Viewing Channel such as PCV.
Pre-Conditions
- User has successfully retrieved MI records (completion of UC-Q1).
- miCDR and One Access Gateway are operational.
Primary Flow
- User performs an action in EHR Viewing Channel to view details of a specific miCDR record.
- EHR Viewing Channel formulates the request and sends it to One Access Gateway.
- One Access Gateway authenticates and validates the request, then forwards it to miCDR.
- miCDR returns the MI record details to EHR Viewing Channel via the One Access Gateway.
- One Access Gateway forwards the response to EHR Viewing Channel.
- EHR Viewing Channel displays the detailed MI information to the user.
Alternate Flow
- No records found
- miCDR returns a message indicating no records were found for the provided search parameters.
- EHR Viewing Channel displays a message to the user.
2.3.6. UC-Q3 – User requests a list of MI records of a specific type (either MI reports, or orders, or imaging studies) using EHR Viewing Channel
Summary
User 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 One Access Gateway.
Pre-Conditions
- User has successfully retrieved MI records (completion of UC-Q1).
- miCDR and One Access Gateway are operational.
- Patient identifiers and consent status are available in PCR and CMTA.
Primary Flow
- User selects to search for MI reports, orders, or imaging studies and enters search criteria in EHR Viewing Channel.
- EHR Viewing Channel formulates the search request and submits it to the One Access Gateway.
- One Access Gateway authorizes and validates the request, then forwards it to miCDR.
- miCDR uses the patient identifiers provided and calls:
- PCR to validate patient identity (health card number and DOB).
- CMTA to validate that no consent block is in place.
- All identifiers associated with the patient (e.g., multiple MRNs) are retrieved from PCR.
- miCDR searches for the requested MI records using the patient identifiers.
- Information is found in miCDR.
- MiCDR returns the requested information (reports, orders, or imaging studies) from miCDR for the specified patient to EHR Viewing Channel via One Access Gateway.
- One Access Gateway forwards the response to EHR Viewing Channel.
- EHR Viewing Channel displays the relevant information to the provider.
Alternate Flow
- No records found
- miCDR returns a message indicating no records were found for the provided search parameters.
