For a full list of available versions, see the Directory of published versions

2.3. Use Cases

The following use cases detail the functional workflows for the contribution of immunization records to the Immunization Repository (IR) Solution. These scenarios illustrate the interactions between Contributor Health Information Custodians (HICs) and the IR Solution, covering the submission of new records, the management of validation responses (including successful processing and error handling), and the process for submitting updates or corrections to previously submitted information. These workflows ensure that immunization data is accurately validated, persisted in the IR Solution database, and made available for query by authorized Point of Service (PoS) systems

2.3.1. Actors

Table- Use Case Participants

2.3.2. Data-In Use Cases

2.3.2.1. IR-UC-1– Contributor HIC submits new immunization record to IR Solution

Primary workflow: Contributor HIC submits a new immunization record to the IR Solution and record passes all validations.

Steps:

1. Contributor HIC submits a new immunization record to the IR Solution.
2. Record is processed and passes all validation steps.
3. HTTP response is sent to Contributor HIC indicating successful processing of the record.
4. Record is written to the IR Solution database and is available for query by PoS systems.

Alternate Workflows:

1. Contributor HIC submits new immunization record to IR Solution and record fails structural, content, or referential validation with Error annotation.
1. Contributor HIC submits a new immunization record to IR 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.
4. Record is written to IR Data Quality Solution (DQS) database.
5. Record is not written to IR Solution database and is unavailable for query by PoS systems.
2. Contributor HIC submits new immunization record to IR Solution and record fails referential validation with Warning and/or Information annotation (no Error).
1. Contributor HIC submits a new immunization record to IR 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 IR DQS database.
5. Record is written to IR Solution database and is available for query by PoS systems.

2.3.2.2. IR-UC-2 – Contributor HIC receives HTTP response indicating validation failure during record processing

Primary workflow: Contributor HIC receives an HTTP response indicating that a validation failure (Error, Warning, or Information) has occurred during processing of an immunization record. The Contributor HIC reviews the details returned, corrects the data in the Contributor HIC System as needed, and resubmits the record to the IR Solution.

Steps:

1. Contributor HIC receives HTTP response indicating that a validation failure has occurred during record processing.
2. Contributor HIC views details of the validation failure contained in the HTTP response (e.g., Operation Outcome).
3. Contributor HIC corrects/updates data in the Contributor HIC System and resubmits the record to the IR Solution.
4. Corrected version of the record is written to the IR Solution database, superseding previous versions of the record where applicable, and is available for query by PoS systems.

Alternate Workflows:

1. Warning/Information only (no Error) - No correction/update required
1. Contributor HIC receives an HTTP response indicating that a Warning or Information message has been generated during record validation.
2. Contributor HIC views details of the validation message(s) contained in the HTTP response.
3. Contributor HIC determines that no further action is required and does not correct/update data in the Contributor HIC System or resubmit the record.
4. The record remains persisted in the IR Solution database and is available for query by POS systems; the annotation is recorded in IR DQS.
2. Error
1. Contributor HIC receives an HTTP response indicating that a validation Error has occurred during record processing.
2. Contributor HIC views details of the validation failure contained in the HTTP response.
3. Contributor HIC is unable to make corrections in the Contributor HIC System.
4. Contributor HIC contacts local support/system vendor and/or Ontario Health Data Quality Administration to address the issue.
5. Upon resolution, the Contributor HIC resubmits the corrected record to the IR Solution.

2.3.2.3. IR-UC-3 – Contributor HIC submits changed version of a previously submitted immunization record

Primary workflow: Contributor HIC submits a changed version (e.g., update/correction) of a previously submitted immunization record to the IR Solution. Changed version is processed and passes all validations.

Steps:

1. Contributor HIC submits a changed version of a previously submitted immunization record to the IR Solution.
2. Changed version is processed and passes all validation steps.
3. HTTP response is sent to the Contributor HIC indicating successful processing of the record.
4. Changed version is written to the IR Solution database, superseding previous versions of the record where applicable, and is available for query by PoS systems.

Alternate Workflows:

1. Changed version fails structural, content, or referential validation (Error)
1. Contributor HIC submits a changed version of a previously submitted immunization record to the IR Solution.
2. Changed version is processed and fails structural, content, or referential validation with Error annotation.
3. HTTP response is sent to the Contributor HIC indicating that an error has occurred during record validation.
4. Changed version of record is written to IR Data Quality Solution (DQS) for remediation.
5. Changed version is not written to the IR Solution database and is unavailable for query by PoS systems.
6. The previously submitted version of the record remains available for query by PoS systems.
2. Changed version fails referential validation with Warning/Information (no Error)
1. Contributor HIC submits a changed version of a previously submitted immunization record to the IR Solution.
2. Changed version is processed and fails referential validation with Warning and/or Information annotation (no Error).
3. HTTP response is sent to the Contributor HIC indicating that a warning or informational message has been generated during record validation.
4. Changed version is written to IR DQS (annotation recorded).
5. Changed version is written to the IR Solution database, superseding previous versions of the record where applicable, and is available for query by PoS systems.

2.3.3. Data-Out Use Cases

2.3.3.2. IR-UC-5 - IR Solution returns augmented and normalized immunization terminology to integrated systems and viewers (Data Out)

Primary Workflow: Integrated system or viewer queries immunization information from the IR Solution and receives standardized vaccine terminology (e.g., NVC) and harmonized vaccine display information.

Steps:

1. Integrated system or viewer submits a request for immunization information to the IR Solution.
2. IR Solution retrieves the immunization record(s) from the IR database.
3. IR Solution identifies whether augmented or normalized terminology information is available for the immunization record(s).
4. IR Solution performs Data Out terminology normalization and augmentation processing.
5. Where immunization records originally submitted using alternate terminology formats (e.g., DINs submitted by pharmacies), the IR Solution maps and returns the associated standardized vaccine terminology and standardized display information from National Vaccine Catalogue (NVC).
6. IR Solution constructs the outbound response payload using standardized terminology information, which may include:
   • National Vaccine Catalogue (NVC) code
   • Standardized vaccine display name
   • Trade name representation
   • Generic agent name representation
   • Historical terminology associations where applicable
7. HTTP response or outbound synchronization payload is sent to the integrated system or viewer.
8. Immunization information is displayed or processed consistently across integrated systems and viewers.

Alternate Workflows:

• A1: IR Solution returns original submitted terminology where augmentation is unavailable
  1. Integrated system or viewer submits a request for immunization information to the IR Solution.
  2. IR Solution retrieves the immunization record(s) from the IR database.
  3. IR Solution determines that standardized terminology augmentation is unavailable or no mapping exists for the submitted terminology.
  4. IR Solution returns the original submitted terminology representation in accordance with IR interoperability and terminology policies.

2.3.3.3. IR-UC-6 - Provider Application requests IR Records - Records successfully returned (Search by HCN) (Data Out)

Primary Workflow: Provider Application submits a request for immunization records to the IR Solution using patient identifiers and receives immunization records for the specified patient and date range.

Steps:

1. Provider Application submits a request for immunization records to Provider Gateway with the following parameters:
   • Ontario Health Card Number (HCN)
   • Date of Birth (DOB)
   • Search date range
   • Optional: Gender
2. Provider Gateway authorizes and validates the request and forwards the request to the IR Solution.
3. IR Solution uses the patient identifiers provided and calls Provincial Client Registry (PCR) and Consent Management Technology Asset (CMTA).
   • 1. PCR validates patient identity using Health Card Number and Date of Birth.
   • 2. CMTA validates that no consent block is in place.
4. All identifiers associated with the patient (e.g., multiple MRNs, HCNs, ECID) are retrieved from PCR.
5. IR Solution searches the IR database using all identifiers associated with the patient.
6. Immunization records are found in the IR database for the specified patient and date range.
7. IR Solution retrieves and constructs the outbound immunization response payload.
8. Where immunization records contain augmented or normalized terminology information, the IR Solution returns standardized vaccine terminology and harmonized vaccine display information.
9. HTTP response is sent to the Provider Application via Provider Gateway.
10. Provider Application displays the immunization information to the provider.

Alternate Workflows:

• A1: Provider Application requests IR records without specifying date parameter
  1. Provider Application submits a search request for immunization records without a specified date range.
  2. Provider Gateway authorizes and validates the request and forwards the request to the IR.
  3. IR applies the default query period as defined by IR business rules.
  4. IR returns immunization records from the IR to the Provider Application via Provider Gateway for the default period.
• A2: Patient not found
  1. Provider Application submits a search request for immunization records using patient identifiers.
  2. PCR is unable to validate or match the patient identity using the provided identifiers.
  3. Error response is returned to the Provider Application via Provider Gateway.
  4. Provider Application displays the error or no-match message to the provider.
• A3: Consent block exists
  1. Provider Application submits a search request for immunization records.
  2. PCR validates patient identity.
  3. CMTA identifies that a consent block is in place.
  4. IR does not return the blocked immunization records.
  5. Provider Application receives a response indicating that records cannot be returned due to applicable consent rules.

2.3.3.4. IR-UC-7 - Provider Application requests IR Records - Records successfully returned (Search by OIID/MRN) (Data Out)

Primary Workflow: Provider Application submits a request for immunization records to the IR Solution using an Ontario Immunization Identifier (OIID), Medical Record Number (MRN), or other associated patient identifier and receives immunization records for the specified patient and date range.

Steps:

1. Provider Application submits a request for immunization records to Provider Gateway with the following parameters:
   • Medical Record Number (MRN), or other associated identifier in the same field (e.g., Ontario Immunization Identification Number)
   • Optional: Date of Birth (DOB)
   • Search date range
   • Optional: Gender
2. Provider Gateway authorizes and validates the request and forwards the request to the IR Solution.
3. IR Solution uses the patient identifiers provided and calls Provincial Client Registry (PCR) and Consent Management Technology Asset (CMTA).
   • 1. PCR validates and resolves patient identity using the provided identifier.
   • 2. CMTA validates that no consent block is in place.
4. All identifiers associated with the patient (e.g., multiple MRNs, HCNs, ECID, OIID) are retrieved from PCR.
5. IR Solution searches the IR database using all identifiers associated with the patient.
6. Immunization records are found in the IR database for the specified patient and date range.
7. IR Solution retrieves and constructs the outbound immunization response payload.
8. Where immunization records contain augmented or normalized terminology information, the IR Solution returns standardized vaccine terminology and harmonized vaccine display information.
9. HTTP response is sent to the Provider Application via Provider Gateway.
10. Provider Application displays the immunization information to the provider.

Alternate Workflows:

• A1: Provider Application requests IR records without specifying date parameter
  • 1. Provider Application submits a search request for immunization records without a specified date range.
  • 2. Provider Gateway authorizes and validates the request and forwards the request to the IR.
  • 3. IR applies the default query period as defined by IR business rules.
  • 4. IR returns immunization records from the IR to the Provider Application via Provider Gateway for the default period.
• A2: Patient not found
  • 1. Provider Application submits a search request for immunization records using patient identifiers.
  • 2. PCR is unable to validate or match the patient identity using the provided identifiers.
  • 3. Error response is returned to the Provider Application via Provider Gateway.
  • 4. Provider Application displays the error or no-match message to the provider.
• A3: Consent block exists
  • 1. Provider Application submits a search request for immunization records.
  • 2. PCR validates patient identity.
  • 3. CMTA identifies that a consent block is in place.
  • 4. IR does not return the blocked immunization records.
  • 5. Provider Application receives a response indicating that records cannot be returned due to applicable consent rules.

2.3.3.5. IR-UC-8 - Provider Application requests IR Records - Records blocked by Patient Consent Directive (Search by HCN, OIID/MRN) (Data Out)

Primary Workflow: Provider Application submits a request for immunization records to the IR Solution and all search results are blocked by a patient consent directive. Note: This use case and any use cases involving consent management are subject to change pending evolving Ontario Health consent management policies and implementation decisions.

Steps:

1. Provider Application submits a request for immunization records to Provider Gateway using one or more patient identifiers, which may include:
   • Ontario Health Card Number (HCN)
   • Ontario Immunization Identifier (OIID) or Medical Record Number (MRN)
   • Date of Birth (DOB)
   • Optional: Gender
   • Search date range
2. Provider Gateway authorizes and validates the request and forwards the request to the IR Solution.
3. IR Solution calls Provincial Client Registry (PCR) and Consent Management Technology Asset (CMTA).
4. PCR validates and resolves the patient identity using the provided identifiers.
5. CMTA identifies that a consent block exists on the patient's immunization record(s).
6. CMTA determines that no active consent override exists for the patient and requesting user organization.
7. IR Solution does not return blocked immunization records.
8. IR Solution returns a response message to the Provider Application via Provider Gateway indicating that access to immunization information has been restricted due to a patient consent directive.
9. Provider Gateway forwards the response to the Provider Application.
10. Provider Application displays the consent restriction message to the provider.

2.3.3.6. IR-UC-9 - Provider Application requests temporary unblocking of blocked IR records

Primary Workflow: A consent block is identified on a patient's immunization records (see IR-UC-8). Provider obtains permission from the patient or the patient's Substitute Decision Maker (SDM), or another permitted consent override reason applies, and the Provider performs a temporary consent override. Blocked immunization records are subsequently returned by the IR Solution. Note: This use case and any use cases involving consent management are subject to change pending evolving Ontario Health consent management policies and implementation decisions.

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

1. Provider Application displays a message indicating that a consent directive exists on the patient's immunization records.
2. Provider selects an action within the Provider Application to initiate a Consent Directive Override. Provider Application launches the Provincial Consent Override Interface (PCOI) hosted by Ontario Health, returning a web-based user interface.
3. Provider completes the required prompts within PCOI and selects the applicable consent override reason.
4. PCOI validates and records the consent override request in accordance with Ontario Health consent management policies. PCOI displays confirmation that temporary consent unblocking has been successfully applied.
5. Provider Application resubmits the request for immunization records to the IR Solution via Provider Gateway.
6. IR solution returns the unblocked IR records and informational message that Patient has temporarily unblocked access to the Provider Application via Provider Gateway.
7. Provider Application displays message that the Provider is viewing records that have been unblocked.
8. 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.

Alternate Workflows:

• A1: Another provider within the same Viewing HIC has already performed a temporary consent override
  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 IR records for search criteria are displayed.

2.3.3.7. IR-UC-10 - Provider Application requests IR Records - Records are not successfully returned due to validation or system failure (Data Out)

Primary Workflow: Provider Application requests immunization records from the IR Solution and records are not successfully returned due to validation failures, authorization failures, or system availability issues.

Workflows Not Expanded:

1. Provider Application request fails validation in Provider Gateway (e.g., Provider Application user is not authorized to access application). Error message returned to Provider Application.
2. Provider Application request fails validation in IR (e.g., Provider Application request contains date range where TO date value is prior to FROM date value). Error messages returned to Provider Application.
3. PCR, IR or Provider Gateway not available. Error messages returned to Provider Application.
4. Patient identifier fails validation in IR. Error message returned to Provider Application.

2.3.3.8. IR-UC-11 - IR Solution enriches NVC-coded immunization records with additional code sets for Data Out

Primary Workflow: Integrated system or viewer queries immunization information from the IR Solution and the IR Solution enriches NVC-coded immunization records with additional approved code sets, where applicable, to support downstream display, interpretation, and interoperability.

Steps:

1. Integrated system or viewer submits a request for immunization information to the IR Solution.
2. IR Solution retrieves the immunization record(s) from the IR database.
3. IR Solution identifies that the immunization record contains a National Vaccine Catalogue (NVC) code as the standardized vaccine terminology.
4. IR Solution checks whether additional approved terminology mappings are available for the NVC-coded vaccine.
5. IR Solution enriches the outbound immunization payload with additional code sets and related metadata, which may include:
   • CVX code, where applicable
   • SNOMED CT code, where applicable
   • Trade name
   • Generic vaccine agent
   • Manufacturer information
   • Dosage and UOM, where applicable
   • Standardized display name
6. IR Solution constructs the outbound response payload using the standardized NVC code and the additional enriched code sets required for the receiving system or viewer.
7. HTTP response or outbound synchronization payload is sent to the integrated system or viewer.
8. Receiving system or viewer displays or processes the immunization information using the enriched terminology provided by the IR Solution.

2.3.3.9. IR-UC-12 - IR Solution publishes immunization records to Panorama through Data Out synchronization

Primary Workflow: Immunization records stored within the IR Solution are published and synchronized to Panorama through an ongoing Data Out integration mechanism (e.g., publish/subscribe model).

Steps:

1. A new immunization record submission or an update is committed within the IR Solution.
2. IR Solution identifies that the immunization record is eligible for outbound synchronization to Panorama.
3. IR Solution generates a Data Out synchronization event for the immunization record.
4. IR Solution constructs the outbound immunization payload in accordance with approved Panorama interoperability specifications and IR Data Out business rules.
5. IR Solution includes standardized and normalized terminology information within the outbound payload, which may include:
   • National Vaccine Catalogue (NVC) code
   • Standardized vaccine display name
   • Trade name representation
   • Generic agent representation
   • Historical terminology associations where applicable
6. IR Solution includes record versioning and provenance metadata within the outbound payload to support synchronization ordering and traceability.
7. IR Solution publishes the outbound immunization event to the appropriate topic/queue.
8. Panorama, as a subscribed entity, consumes and validates the immunization payload.
9. Panorama processes the immunization record update and stores the synchronized immunization information.
10. IR Solution records synchronization transaction details, status, and audit metadata.