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 |
As an Enterprise Master Patient Index (EMPI), the Provincial Client Registry (PCR) aggregates patient demographic data and identifiers (e.g. healthcards & medical record numbers) from participating healthcare organizations to provide a provincial level source of patient identity and demographic information. The identifiers maintained in the PCR are used by other EHR services (e.g. clinical repositories) to associate health information with the appropriate patient, and to enable healthcare provider access to a patients’ latest demographics (e.g. name, address, phone) and provincial health record. |
| 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 - Provincial Clinical Viewer Queries
The use cases below provide a basic illustration of how a user interacts with miCDR using Provincial Clinical Viewer. The initial rollout of the MI FHIR query API is expected to support access through the provincial clinical viewer. Support for integration with additional point-of-service systems may be considered in future releases. Ontario Health (OH) plans to engage with HICs to further explore and discuss potential integration approaches.
Summary
User requests a list of MI information via Provincial Clincal Viewer 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 Provincial Clincal Viewer.
- 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 Provincial Clincal Viewer.
- Provincial Clincal Viewer 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 calls PCR to perform patient identifier resolution to return all match identifiers, and also CMTA to check if consent directive is in place.
- miCDR performs the search on all returned patient identifiers, and returns information (DocumentReference resources) from miCDR for the specified patient to Provincial Clinical Viewer via One Access Gateway.
- Provincial Clinical Viewer displays the relevant information received from One Access Gateway to the user.
Alternate Flow
No records found
- Provincial Clinical Viewer displays a message indicating that no records were found for the patient in the search parameter.
records found, but cannot return due to consent block in place
- Provincial Clinical Viewer displays a message indicating the result cannot be displayed due to consent block. User has the option to perform consent override to retry the search.
Post-Conditions
- Success: If record is found and there is no consent block, Provincial Clinical Viewer displays the records. If no record is found, Provincial Clinical Viewer displays the message that no record is found.
- Failure: If consent directive blocks the records to be displayed, Provincial Clinical Viewer will display appropriate message to the user.
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 to Provincial Clinical Viewer.
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 Provincial Clinical Viewer to view details of a specific miCDR record.
- Provincial Clinical Viewer generates the FHIR request for the specific record 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 Provincial Clinical Viewer via the One Access Gateway.
- One Access Gateway forwards the response to Provincial Clinical Viewer
- Provincial Clinical Viewer displays the detailed MI information to the user. If the requested record is an imaging study, Provincial Clinical Viewer will provide link to the images. User is able to click the link to load the image using the image viewer in the Provincial Clinical Viewer.
Alternate Flow
None
