Compliance ISP-2519
Validation Checks by Instafill.ai
1
Validates Social Insurance Number (SIN) format and checksum
Ensures the applicant SIN is present and is exactly 9 digits, with optional spaces/hyphens normalized, and passes the Luhn checksum used for Canadian SINs. This is critical because the SIN is the primary identifier used to match the medical report to the CPP disability application and to the correct client record. If the SIN is missing or invalid, the submission should be rejected or routed to manual review and the applicant prompted to correct it.
2
Ensures SIN is consistently provided on all required pages/sections
Checks that the SIN entered at the top of the report (and any repeated SIN fields captured during digitization) matches exactly across all occurrences. This prevents page-mismatch errors where pages from different applicants are combined or scanned together. If any SIN instance differs, the system should flag the submission as potentially corrupted/mixed and require reconciliation before processing.
3
Validates preferred language selection is exactly one option
Verifies that the applicant selects either English or French, but not both and not neither. Preferred language drives correspondence templates and service routing, so ambiguity can cause incorrect communications and delays. If validation fails, the form should be returned for correction or the applicant contacted to confirm the preference.
4
Validates applicant name completeness and character rules
Ensures First Name and Last Name(s) are provided and contain only acceptable characters (letters, spaces, hyphens, apostrophes, and common diacritics), and are not placeholder text. Names are required for identity matching, correspondence, and linking to the application (ISP1151). If missing or containing invalid characters, the submission should be flagged and the applicant asked to correct the fields.
5
Validates Date of Birth (DOB) format and plausibility
Checks DOB is in YYYY-MM-DD format, is a real calendar date, and is not in the future; optionally flags implausible ages (e.g., under 15 or over 120) for review. DOB is used for identity verification and eligibility calculations, and errors can lead to incorrect entitlement decisions. If invalid, the system should block submission or require correction before acceptance.
6
Validates mailing address completeness and Canadian postal code rules
Ensures the mailing address includes at minimum street/PO box, city/town, province/territory, and postal code; if country is not Canada, a country value must be present and postal code rules should be relaxed accordingly. For Canadian addresses, validates postal code format (A1A 1A1) and province/territory is one of the recognized Canadian values. If incomplete or invalid, the system should flag it because benefit correspondence and requests for additional information may not reach the applicant.
7
Validates telephone numbers format and contact preference logic
Checks telephone and alternate telephone numbers (if provided) conform to expected formats (e.g., 10-digit NANP with optional country code, or E.164), and are not obviously invalid (all zeros, too short). Also enforces that if 'Please don't call, send letters only' is selected, the system does not require a phone number and suppresses phone-contact workflows; if not selected, at least one reachable phone number should be present. If validation fails, the submission should be flagged because Service Canada may be unable to contact the applicant, causing processing delays.
8
Validates best time to contact selection is mutually consistent
Ensures the applicant selects at most one of Morning or Afternoon, and that selecting 'Please don't call, send letters only' is not combined with Morning/Afternoon. This prevents contradictory instructions that can lead to privacy issues (unwanted calls) or missed contact attempts. If inconsistent, the system should require the applicant to choose a single, clear contact preference.
9
Validates consent option selection is exactly one and signature is present
Confirms the applicant selects exactly one consent option (Give Consent or Do Not Give Consent) and provides an applicant/authorized representative signature and signature date. Consent governs what third-party information Service Canada can request; missing/ambiguous consent can delay adjudication and may limit evidence collection. If consent choice or signature/date is missing, the submission should be considered incomplete and returned for completion.
10
Validates witness fields are completed only when required (mark signature)
If the applicant signature is indicated as a mark (e.g., 'X') or the system captures a 'signed with a mark' indicator, then witness name, witness telephone, witness signature, and witness date must be present. If the applicant provides a normal signature, witness fields should be blank or ignored to avoid unnecessary personal data collection. If the witness requirement is triggered but incomplete, the consent section should be rejected as not properly executed.
11
Validates all date fields for correct format and cross-field chronology
Checks all YYYY-MM-DD and YYYY-MM fields (e.g., last office visit, start treating primary condition, stop working date, signature dates, medication/treatment start/end dates) are valid and not malformed. Enforces logical ordering such as: start treating date cannot be after last office visit; medication/treatment end date cannot be before start date; signature dates should not be in the future. If chronology fails, the system should flag for correction or clinical review because timelines are central to disability duration and severity assessment.
12
Validates Section 3 relationship duration selection and visit count
Ensures exactly one 'years in care' option is selected and the number of visits in the past 12 months is a non-negative integer within a reasonable range (e.g., 0–365). This information supports credibility and completeness of the medical history and helps interpret the level of ongoing care. If missing or out of range, the submission should be flagged for follow-up with the provider.
13
Validates expedited processing (terminal/grave) details completeness and rules
If 'Terminal: Yes' is selected, requires diagnosis, ICD-9-CM code, and symptom onset date (YYYY-MM), and enforces that the rest of Section 6 is skipped/blank as instructed. If 'Grave: Yes' is selected, requires that at least one condition is fully documented in Section 5 (since details are provided there). If these dependencies are not met, the system should not apply expedited handling and should request missing information to avoid incorrect prioritization.
14
Validates ICD-9-CM code format and presence when a condition is listed
For each medical condition entered in Section 4 or Section 5, checks that an ICD-9-CM code is provided in the expected pattern (typically 3 digits, optionally followed by a decimal and 1–2 digits, e.g., 296.3), and is not placeholder text like 'XXX.X'. ICD codes support standardized classification and downstream analytics and can reduce ambiguity in diagnosis. If missing/invalid, the system should flag the condition entry as incomplete and require correction or allow submission with mandatory manual review.
15
Validates Section 5 condition entry completeness and one-page-per-condition structure
For each condition page/entry, requires: medical condition name, symptom onset (YYYY-MM), impairment(s), functional limitation(s), prognosis selection, expected duration selection, and frequency selection. This ensures the report contains both objective/clinical context and functional impact, which is essential for the CPP 'severe and prolonged' test. If any required elements are missing, the system should mark the medical report as incomplete and request the provider to supply the missing details.
16
Validates 'Unknown' prognosis/frequency requires explanation in Section 7
If prognosis is marked 'unknown' and/or frequency is marked 'unknown' for any condition, checks that Section 7 contains a non-empty explanation (e.g., pending investigations, insufficient follow-up, awaiting specialist consult). This is important because unknowns without rationale reduce adjudicative value and can lead to delays or additional evidence requests. If no explanation is provided, the system should flag the submission and prompt the provider to complete Section 7.
17
Validates Section 6 employment questions branching and required follow-ups
Ensures Question 1 has exactly one response (Yes/No/Not discussed); if 'Yes' is selected, a stop-working date (YYYY-MM-DD) must be provided. For Question 2, if 'Yes' is selected, then Questions 3 and 4 must be answered; if 'No' or 'Unknown' is selected, Questions 3 and 4 should be blank. If branching rules are violated, the system should flag the report because inconsistent employment prognosis can mislead the employability assessment.
18
Validates Section 9 provider declaration completeness and professional type constraints
Requires the provider to select exactly one professional category (GP/CCFP, other physician specialist with specialty specified, nurse practitioner, or registered nurse in geographically isolated community), and to provide name, address/telephone, signature, and declaration date (YYYY-MM-DD). This is essential for authenticity, accountability, and determining whether the signer is an acceptable practitioner for CPP disability medical evidence. If missing or inconsistent (e.g., 'other specialist' selected but specialty blank), the submission should be rejected or held until corrected.