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

2.3. Use Cases

The use cases below provide basic illustrations of how actors interact with the PCR to consume patient information.

2.3.0.1. Participants

Use Case Participants

2.3.1. UC1 - Creating a Patient Record (Add Patient)

2.3.1.1. Description

The Patient Create business use case enables PCR to establish a new patient identity from a submitted patient record. The process validates patient information, evaluates potential matches against existing patient identities, and applies duplicate prevention and identity resolution rules. If no acceptable match is found, PCR creates a new patient record and identity while preserving source attribution, audit history, and identity governance requirements.

• Business Operation: Patient Create
• Trigger: Contributor submits a request to create a Patient Record containing patient identifiers, demographic information, and other required attributes.

2.3.1.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.1.3. Preconditions

• The Contributor is authorized to submit patient contributions.
• Required patient information has been collected and validated in accordance with Ontario Health specifications.
• The patient is eligible for registration within PCR.
• The submitted information conforms to applicable PCR business and validation requirements.
• Required privacy, consent, regulatory, and data governance obligations have been satisfied.
• PCR identity management, validation, and audit services are operational.

2.3.1.4. Normal Flow

1. Contributor submits a Patient Create request.
2. PCR validates the request structure and mandatory patient information.
3. PCR validates contributor authorization and governance requirements.
4. PCR validates identifiers, demographic information, and business rules.
5. PCR evaluates the submitted patient information against existing managed patient identities.
6. PCR applies duplicate prevention, identity resolution, and source authority rules.
7. PCR determines that no acceptable patient identity exists.
8. PCR creates a new Patient Record.
9. PCR assigns a unique patient identifier and version information.
10. PCR records source attribution, lineage information, and audit history.
11. PCR publishes notifications when subscription criteria are met.
12. PCR returns a successful response to the contributing system.

2.3.1.5. Alternative Flows

• AF-1: Existing Patient Identity Identified
  • PCR identifies an existing patient identity that satisfies matching criteria.
  • Duplicate prevention rules are applied.
  • No new Patient Record is created.
  • PCR returns the applicable duplicate prevention response.
• AF-2: Manual Review Required
  • PCR determines that available matching evidence is inconclusive.
  • The request is routed for stewardship review.
  • Processing is suspended pending an authorized determination.
  • The Contributor is informed that processing remains under review.
• AF-3: Governance Review Required
  • PCR determines that an additional governance or policy review is required.
  • Processing is suspended pending approval.
  • No Patient Record is created until authorization is received.
• AF-4: Notification Failure
  • Patient creation processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The newly created Patient Record remains committed within PCR.

2.3.1.6. Exception Flows

• EX-1: Contributor Not Authorized – PCR rejects the Patient Create request. Audit information is recorded. PCR returns an appropriate authorization error response.
• EX-2: Non-Conformant Message – PCR determines that the request does not conform to supported structure, data, business rules, or format requirements. The request is rejected. Audit information is recorded.
• EX-3: Mandatory Information Missing – Required patient information is incomplete. The request is rejected. Audit information is recorded.
• EX-4: Invalid Patient Data – Submitted identifiers, demographic information, or code values fail validation requirements. The request is rejected. Audit information is recorded.
• EX-5: Duplicate Prevention Rule Triggered – PCR identifies an existing patient identity or an unacceptable duplicate risk. No new Patient Record is created. The request is rejected or routed according to approved duplicate prevention policies.
• EX-6: Patient Identity Cannot Be Determined – PCR cannot determine whether the submitted patient represents a unique identity. Processing cannot continue automatically. The request is rejected or routed for stewardship review according to governance policy.
• EX-7: Governance Rule Violation – The request violates approved governance, identity management, or stewardship policies. Processing is rejected. Audit information is recorded.
• EX-8: PCR Service Unavailable – PCR cannot process the request due to a service interruption. No Patient Record is created. Appropriate error information or retry guidance is provided.
• EX-9: Audit Logging Failure – PCR processes or rejects the request according to approved governance and operational policy. Available diagnostic information is recorded where possible. The Contributor is informed of the applicable outcome.
• EX-10: Network or System Error – Transaction processing cannot be completed. The request is not processed or its final status cannot be confirmed. Appropriate error information is returned to the Contributor.

2.3.2. UC2 - Creating a Patient Record Conditionally

2.3.2.1. Description

The Patient Conditional Create business use case enables PCR to create a new patient identity when approved duplicate prevention criteria are met. The process evaluates the submitted patient information against existing patient identities and applies conditional matching rules. If an acceptable match is found, PCR returns the existing patient identity and prevents duplicate creation. If no acceptable match is identified, PCR creates a new patient record and identity while preserving source attribution, audit history, and identity governance requirements.

• Business Operation: Conditional Patient Create
• Trigger: Contributors submit a conditional patient create request containing patient demographic information and approved conditional search criteria.

2.3.2.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.2.3. Preconditions

• The Contributor is authorized to submit patient contributions.
• A patient requires registration within PCR.
• Approved conditional create criteria are provided with the request.
• The conditional search criteria conform to PCR-supported search and matching requirements.
• Required patient information has been collected and confirmed in accordance with Ontario Health specifications and organizational policies.
• The patient record being submitted is within the scope of PCR identity management policies.
• Required privacy, consent, regulatory, and data governance obligations have been satisfied.

2.3.2.4. Normal Flow

1. Contributor submits a Conditional Patient Create request.
2. PCR validates request structure and conditional create criteria.
3. PCR validates contributor authorization and governance requirements.
4. PCR searches existing patient identities using approved conditional search criteria.
5. PCR evaluates search results according to approved patient matching and duplicate prevention policies.
6. PCR determines that no acceptable patient identity exists.
7. PCR creates a new Patient Record.
8. PCR assigns a unique patient identifier and version information.
9. PCR records source attribution, lineage information, and audit history.
10. PCR publishes notifications when subscription criteria are met.
11. PCR returns a successful response to the contributing system.

2.3.2.5. Alternative Flows

• AF-1: Existing Patient Identity Found
  • PCR identifies an existing patient identity that satisfies the conditional create criteria.
  • PCR determines that duplicate prevention rules have been satisfied.
  • PCR returns the existing patient identity information.
  • No new Patient Record is created.
• AF-2: Multiple Potential Matches Found
  • PCR identifies multiple potential matching patient identities.
  • PCR cannot automatically determine an acceptable match.
  • The request is routed for stewardship review according to governance policy.
  • No Patient Record is created until a determination is made.
• AF-3: Manual Review Required
  • PCR determines that available matching evidence is inconclusive.
  • Processing is suspended pending stewardship review.
  • An authorized determination is required before processing continues.
• AF-4: Notification Failure
  • Conditional create processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The resulting patient identity outcome remains committed within PCR.

2.3.2.6. Exception Flows

• EX-1: Contributor Not Authorized – PCR rejects the conditional create request. Audit information is recorded. PCR returns an appropriate authorization error response.
• EX-2: Invalid Conditional Criteria – PCR determines that the submitted conditional search criteria are invalid, unsupported, or incorrectly formatted. The request is rejected. Audit information is recorded.
• EX-3: Mandatory Information Missing – PCR determines that required patient information is incomplete. The request is rejected. Audit information is recorded.
• EX-4: Invalid Patient Data – Submitted identifiers or demographic information fail validation requirements. The request is rejected. Audit information is recorded.
• EX-5: Patient Match Evaluation Failure – PCR cannot complete patient matching activities because required matching functions are unavailable or fail to complete. Processing cannot continue. Appropriate error information is returned.
• EX-6: Conditional Criteria Resolution Failure – PCR cannot resolve the conditional criteria in accordance with approved matching policies. The request is rejected or routed for stewardship review according to governance policy.
• EX-7: Governance Rule Violation – The request violates approved governance or identity management policies. Processing is rejected. Audit information is recorded.
• EX-8: PCR Service Unavailable – Conditional create processing cannot be completed due to service interruption. No Patient Record is created. Appropriate error information or retry guidance is returned.
• EX-9: Audit Logging Failure – PCR processes or rejects the request according to approved governance and operational policy. Available diagnostic information is recorded where possible. The Contributor is informed of the applicable outcome.
• EX-10: Network or System Error – Transaction processing cannot be completed. The request is not processed or its final status cannot be confirmed. Appropriate error information is returned to the Contributor.

2.3.3. UC3 - Updating a Patient Record (Revise Patient)

2.3.3.1. Description

The Patient Update business use case enables PCR to update an existing patient record with submitted changes. The process validates the updated patient information, confirms contributor authority, and applies source authority and survivorship rules as required. When validation criteria are met, PCR updates the patient record while preserving audit history, traceability, and identity governance requirements.

• Business Operation: Patient Update
• Trigger: Contributor submits a Patient Update request for an existing Patient Record within PCR.

2.3.3.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.3.3. Preconditions

• The Contributor is authorized to update patient information.
• Required privacy, consent, regulatory, and data governance obligations have been satisfied.
• The Patient Record already exists within PCR.
• The Patient Record to be updated can be uniquely identified.
• The submitted changes contain the minimum information required to support the requested update.
• The submitted information conforms to applicable PCR data, format, and business rule requirements.
• PCR identity management, validation, and audit services are available.

2.3.3.4. Normal Flow

1. Contributor submits a Patient Update request.
2. PCR validates the request structure and mandatory information.
3. PCR validates contributor authority and applicable governance requirements.
4. PCR validates patient identifiers, demographic information, and applicable business rules.
5. PCR confirms that the Patient Record exists and can be uniquely identified.
6. PCR evaluates field-level update permissions, source authority rules, and applicable survivorship requirements.
7. PCR applies the approved changes to the Patient Record.
8. PCR records source attribution, audit information, lineage information, and update history.
9. PCR publishes update notifications when subscription criteria are met.
10. PCR returns a successful response to the contributing system.

2.3.3.5. Alternative Flows

• AF-1: Partial Update
  • Contributor submits an update request containing only selected patient attributes.
  • PCR evaluates only the fields included in the request.
  • Existing values remain unchanged unless explicitly modified and approved in accordance with governance rules.
  • PCR updates the approved fields and records audit information.
• AF-2: Source Authority Restriction
  • PCR determines that the Contributor is not permitted to update one or more submitted attributes.
  • PCR applies only the updates allowed under source authority rules, or rejects the request where partial processing is not permitted.
  • PCR records audit information and returns an appropriate response indicating the restricted attributes.
• AF-3: Survivorship Rule Applied
  • PCR determines that one or more submitted values conflict with established survivorship rules.
  • PCR retains the surviving value according to approved stewardship rules.
  • PCR applies any remaining approved changes.
  • PCR returns applicable warning or informational details to the Contributor.
• AF-4: Manual Review Required
  • PCR determines that the submitted changes cannot be resolved automatically due to governance, source authority, identity, or survivorship considerations.
  • PCR routes the request for manual stewardship review.
  • Processing is suspended until an authorized decision is made.
  • PCR informs the Contributor that processing of the request is pending review.
• AF-5: Notification Failure
  • Patient update processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The Patient Record update remains committed within PCR.
  • PCR records the notification outcome where applicable.

2.3.3.6. Exception Flows

• EX-1: Contributor Not Authorized – PCR rejects the update request. Audit information is recorded. PCR returns an appropriate error response.
• EX-2: Patient Record Not Found – PCR cannot locate the specified Patient Record. The update request is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-3: Patient Record Not Uniquely Identified – PCR cannot uniquely identify the Patient Record to be updated. The update request is rejected or routed for stewardship review according to governance policy. Audit information is recorded. PCR returns an appropriate response.
• EX-4: Mandatory Information Missing – PCR determines that required patient information is incomplete. The request is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-5: Invalid Patient Data – PCR determines that submitted identifiers, demographic information, or other patient attributes fail validation requirements. The request is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-6: Governance Rule Violation – PCR determines that the requested update violates established governance policies. The update request is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-7: Source Authority Restriction – PCR determines that the Contributor is not permitted to modify one or more submitted attributes. The update is rejected or restricted according to governance policy. Audit information is recorded. PCR returns an appropriate response indicating the restricted attributes.
• EX-8: Survivorship Conflict – PCR determines that the requested change conflicts with established survivorship rules. The update is rejected, restricted, or partially applied according to approved governance policy. Audit information is recorded. PCR returns an appropriate response.
• EX-9: PCR Service Unavailable – PCR is unable to process the update request due to a service interruption. The request is not processed. The Contributor is informed that PCR is unavailable and provided with appropriate error information or retry guidance.
• EX-10: Audit Logging Failure – PCR processes or rejects the update request according to approved governance and operational policy. Available diagnostic information is recorded where possible. The Contributor is informed of the applicable outcome.
• EX-11: Network or System Error – Transaction processing cannot be completed. The request is not processed or its final status cannot be confirmed. The Contributor is informed with the appropriate error information.

2.3.4. UC4 - Merging Patient Records

2.3.4.1. Description

The Patient Merge business use case enables PCR to merge duplicate patient records for the same individual into a single trusted patient identity. The process validates merge criteria, determines the surviving record, and preserves audit history, source attribution, and identity relationships.

• Business Operation: Patient Merge
• Trigger: Contributor or Steward submits a merge request identifying duplicate Patient Records believed to represent the same individual.

2.3.4.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.4.3. Preconditions

• The Contributor or Steward is authorized to perform merge activities.
• Two or more Patient Records exist within PCR.
• The records can be uniquely identified.
• Sufficient evidence exists to support reconciliation of the records.
• Required privacy, stewardship, regulatory, and governance requirements have been satisfied.
• PCR governance permits the requested merge activity.
• PCR identity management and audit services are operational.

2.3.4.4. Normal Flow

1. Contributor or Steward submits a merge request.
2. PCR validates the request structure and merge criteria.
3. PCR validates requester authorization and governance requirements.
4. PCR identifies and validates the Patient Records involved in the merge.
5. PCR evaluates duplicate evidence and identity relationships.
6. PCR determines the surviving patient identity in accordance with approved governance and stewardship policies.
7. PCR updates Patient identity relationships, linkage information, status, and lineage information.
8. PCR preserves source attribution and audit history for all affected records.
9. PCR records merge activity in audit history.
10. PCR publishes merge notifications when subscription criteria are met.
11. PCR returns a successful response to the requesting system.

2.3.4.5. Alternative Flows

• AF-1: Manual Review Required
  • PCR determines that available duplicate evidence is inconclusive.
  • The request is routed for stewardship review.
  • No merge occurs until an authorized decision is made.
  • The requester is informed that processing is pending review.
• AF-2: Governance Approval Required
  • PCR determines additional governance approval is required.
  • Processing is suspended pending authorization.
  • The requester is informed that the merge remains under review.
• AF-3: Surviving Identity Review
  • Multiple valid survivor candidates are identified.
  • PCR routes the request for stewardship determination.
  • Processing remains suspended until a decision is made.
• AF-4: Notification Failure
  • Merge processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The merge remains committed within PCR.

2.3.4.6. Exception Flows

• EX-1: Contributor or Steward Not Authorized – PCR rejects the merge request. Audit information is recorded. PCR returns an appropriate error response.
• EX-2: Patient Record Not Found – One or more Patient Records referenced in the request cannot be located. The merge request is rejected. Audit information is recorded.
• EX-3: Merge Criteria Not Satisfied – PCR determines that the records do not satisfy approved merge criteria. The request is rejected. Audit information is recorded.
• EX-4: Duplicate Evidence Insufficient – PCR determines there is insufficient evidence to support reconciliation. The merge request is rejected or routed for stewardship review. Appropriate outcome information is returned.
• EX-5: Patient Records Not Uniquely Identified – PCR cannot uniquely identify one or more Patient Records involved in the merge. Processing cannot continue. The request is rejected or routed for review according to governance policy.
• EX-6: Governance Rule Violation – The requested merge violates established governance or stewardship policies. PCR rejects the request. Audit information is recorded.
• EX-7: Survivorship Determination Failure – PCR cannot determine a surviving patient identity according to approved governance rules. The merge request cannot be completed. Appropriate error information is returned.
• EX-8: PCR Service Unavailable – PCR is unable to process the merge request due to a service interruption. No merge activity occurs. Appropriate error information or retry instructions are provided.
• EX-9: Audit Logging Failure – PCR processes or rejects the merge request according to approved governance and operational policy. Available diagnostic information is recorded where possible. Appropriate outcome information is returned.
• EX-10: Network or System Error – Transaction processing cannot be completed. The request is not processed or its final status cannot be confirmed. Appropriate error information is returned to the requester.

2.3.5. UC5 - Unmerging Previously Merged Patient Records

2.3.5.1. Description

The Patient Unmerge business use case enables PCR to separate patient records that were previously merged in error. The process validates the unmerge request, restores the affected patient identities, and re-establishes appropriate identity relationships. PCR preserves source attribution, lineage, historical relationships, and audit history while maintaining identity integrity and governance requirements.

• Business Operation: Patient Unmerge
• Trigger: Contributor or Steward submits an unmerge request and supporting justification indicating that a previous merge should be reversed.

2.3.5.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.5.3. Preconditions

• A previous merge relationship exists within PCR.
• The merge relationship can be uniquely identified.
• Evidence supports reversal of the merge.
• The requester is authorized to perform unmerge activities.
• PCR governance permits reversal of the merge.
• Required privacy, stewardship, regulatory, and governance requirements have been satisfied.
• PCR identity management and audit services are operational.

2.3.5.4. Normal Flow

1. Contributor or Steward submits an unmerge request.
2. PCR validates the request structure and supporting justification.
3. PCR validates requester authorization and governance requirements.
4. PCR verifies the original merge relationship.
5. PCR validates that the merge relationship satisfies unmerge criteria.
6. PCR restores the affected patient identities.
7. PCR re-establishes identity relationships, lineage information, and patient associations.
8. PCR preserves source attribution and historical audit information.
9. PCR records unmerge activity in audit history.
10. PCR publishes unmerge notifications when subscription criteria are met.
11. PCR returns a successful response to the requester.

2.3.5.5. Alternative Flows

• AF-1: Manual Review Required
  • PCR determines that additional stewardship review is required.
  • Processing is suspended pending review.
  • No unmerge activity occurs until an authorized decision is made.
  • The requester is informed that processing remains under review.
• AF-2: Governance Approval Required
  • PCR determines that additional governance approval is required before reversal can proceed.
  • Processing remains suspended pending authorization.
  • The requester is informed that the request remains under review.
• AF-3: Partial Identity Recovery
  • PCR determines that some historical information cannot be automatically restored.
  • Approved exception-handling procedures are followed.
  • The requester is informed of any limitations affecting the restoration process.
• AF-4: Notification Failure
  • Unmerge processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The unmerge remains successfully committed within PCR.

2.3.5.6. Exception Flows

• EX-1: Prior Merge Not Found – PCR cannot locate the referenced merge relationship. The unmerge request is rejected. Audit information is recorded.
• EX-2: Requester Not Authorized – PCR determines that the requester lacks authority to perform unmerge activities. The request is rejected. Audit information is recorded.
• EX-3: Governance Approval Failure – Required governance or stewardship approval is not obtained. Unmerge processing is not permitted. The request is rejected.
• EX-4: Insufficient Evidence for Unmerge – PCR determines that available evidence does not support reversal of the merge. The request is rejected or routed for manual review. Appropriate outcome information is returned.
• EX-5: Merge Relationship Not Uniquely Identified – PCR cannot uniquely identify the merge relationship to be reversed. The request is rejected or routed for stewardship review according to governance policy. Audit information is recorded.
• EX-6: Identity Restoration Failure – PCR is unable to fully restore one or more patient identities according to approved governance rules. Processing cannot be completed. Appropriate error information is returned.
• EX-7: PCR Service Unavailable – PCR is unable to process the request due to a service interruption. No unmerge activity occurs. Appropriate retry guidance or error information is provided.
• EX-8: Audit Logging Failure – PCR processes or rejects the request according to approved governance and operational policy. Available diagnostic information is recorded where possible. The requester is informed of the applicable outcome.
• EX-9: Network or System Error – Transaction processing cannot be completed. The request is not processed or its final status cannot be confirmed. Appropriate error information is returned to the requester.

2.3.6. UC6 - Batch or Transaction Bundle Submission

2.3.6.1. Description

The Batch Transaction Submission business use case enables a Contributor to submit multiple patient transactions for processing within a single batch. The batch may contain patient create, patient update, and patient merge requests. PCR validates the batch submission and processes each transaction according to applicable patient identity management, governance, stewardship, duplicate prevention, and survivorship policies. Individual transactions within the batch are evaluated independently and may result in successful processing, rejection, or routing for stewardship review.

• Business Operation: Batch or Transaction Bundle Submission
• Trigger: Contributor submits a batch transaction request containing one or more patient create, patient update, and patient merge transactions.

2.3.6.2. Actors

• Primary Actor: Data Contributor
• Supporting Actor: Provincial Client Registry (PCR)

2.3.6.3. Preconditions

• The Contributor is authorized to submit batch transactions.
• PCR batch processing services are operational.
• The batch submission conforms to approved message specifications.
• All transactions within the batch contain the information required for processing.
• Required privacy, consent, regulatory, and data governance obligations have been satisfied.
• Audit and logging services are available.

2.3.6.4. Normal Flow

1. Contributor submits a batch transaction request.
2. PCR validates batch structure and mandatory submission requirements.
3. PCR validates contributor authority and governance requirements.
4. PCR validates each transaction contained within the batch.
5. PCR processes patient create transactions according to patient creation policies.
6. PCR processes patient update transactions according to update, survivorship, and source authority policies.
7. PCR processes patient merge transactions according to approved merge and stewardship policies.
8. PCR records audit information for each transaction processed.
9. PCR compiles transaction processing results.
10. PCR returns a batch processing response to the Contributor.

2.3.6.5. Alternative Flows

• AF-1: Partial Batch Success
  • PCR validates and processes individual transactions within the batch.
  • One or more transactions fail validation or business rules.
  • Valid transactions are processed successfully.
  • Failed transactions are rejected with applicable error information.
  • PCR returns a consolidated processing summary for the batch.
• AF-2: Manual Review Required
  • PCR determines that one or more transactions require stewardship review.
  • The affected transactions are routed for manual review.
  • Remaining eligible transactions continue processing.
  • PCR informs the Contributor that specific transactions are pending review.
• AF-3: Duplicate Patient Identified During Create
  • PCR identifies an existing patient identity during a patient create transaction.
  • PCR prevents duplicate patient creation.
  • PCR returns an appropriate duplicate prevention response for the transaction.
  • Processing continues for the remaining batch transactions.
• AF-4: Notification Failure
  • Batch processing completes successfully.
  • Subscriber notification delivery is deferred or retried according to operational policy.
  • The batch transactions remain successfully committed within PCR.

2.3.6.6. Exception Flows

• EX-1: Contributor Not Authorized – PCR rejects the batch transaction request. Audit information is recorded. PCR returns an appropriate error response.
• EX-2: Invalid Batch Structure – PCR determines that the batch submission does not conform to approved specifications. The batch request is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-3: Non-Conformant Message – PCR determines that the batch submission does not comply with message format, structure, or validation requirements. The batch request is rejected. Audit information is recorded. PCR returns information describing the reason for rejection.
• EX-4: Patient Record Not Found – PCR cannot locate a patient record referenced by an update or merge transaction. The affected transaction is rejected. Audit information is recorded. Processing continues according to batch processing policy.
• EX-5: Merge Criteria Not Satisfied – PCR determines that patient records identified for merging do not satisfy approved merge criteria. The merge transaction is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-6: Invalid Patient Data – PCR determines that submitted patient information fails validation requirements. The affected transaction is rejected. Audit information is recorded. PCR returns an appropriate error response.
• EX-7: PCR Service Unavailable – PCR is unable to process the batch request due to a service interruption. The batch request is not processed. The Contributor is informed that PCR is unavailable and provided with appropriate instructions.
• EX-8: Audit Logging Failure – PCR rejects the batch request according to governance policy. The Contributor is informed of the reason for rejection.
• EX-9: Network or System Error – Batch transaction processing cannot be completed. The request is not processed. The Contributor is informed with the appropriate error information.