Reporting and validation rules
What a facility must satisfy before a report can be accepted: required identifiers and fields, valid bed states, capacity constraints, date validation, facility configuration, duplicate handling, corrections and failure behaviour.
- Document version
- 1.0
- Last updated
- 2026-09-08
- Document owner
- OWNER INPUT REQUIRED — DOCUMENT GOVERNANCE
- Applies to
- OCRS 2.4.0 (multi-tenant hosted edition)
- Status
- Approved
- Audience
- Provider organizations, State agencies, Technical evaluators
- Evidence source
- src/lib/reporting/jurisdiction-spec.server.ts (pre-submission gate) · src/lib/obcc/state-csv.ts (schema, boolean and date rules) · src/lib/reporting/census-template.ts (required reporting fields)
How validation is applied
Validation runs before a submission or an extract is accepted, not afterwards. The receiving jurisdiction's configured required-field list is authoritative: it decides which fields must be present, the facility's own records supply the values, and a missing value blocks the submission at source. Where a jurisdiction has not configured a list, the published extract schema's required columns apply and the gap is surfaced as a jurisdiction-configuration defect rather than silently defaulted.
Rules a submission must satisfy
| Rule class | Requirement | Class | Failure behaviour |
|---|---|---|---|
| Required identifiers | The facility must exist in the directory, resolve to a named organization, and carry its OCRS Facility ID. | Required | Submission blocked; the missing field, the reason and where to correct it are named. |
| Required facility configuration | The facility must resolve to a configured jurisdiction and carry its licensed level of care; bed rows must carry room and bed labels. | Required | Submission blocked before any extract is generated. |
| Conditional identifiers | Licence number is required when the receiving jurisdiction's specification lists it. | Conditional | Blocked only for jurisdictions that require the field. |
| Valid bed states | Active, occupied, blocked, expected-admission and discharge-order flags must each be exactly True or False — never blank. | Required | Row rejected as invalid; nothing partial is stored. |
| Capacity constraints | Bed rows must reconcile to the facility's licensed capacity; inactive physical beds are reported as inactive rather than omitted, and no count may be negative. | Required | Submission rejected with the offending figure named. |
| Date and time validation | Expected-admission and discharge-order dates must be valid calendar dates in the facility's local time zone, in the published date format. | Conditional | Row rejected as invalid when a populated date does not validate. |
| Occupant attributes | Age (or the 90+ band) is the only occupant attribute carried, and only for an occupied bed. | Conditional | Any other occupant attribute is not accepted by the schema. |
| Block reason | Recorded only where the bed is blocked. | Optional | Left empty for beds that are not blocked. |
| Calculated values | Available capacity, occupancy and coverage are computed by OCRS from accepted records. | Derived | Cannot be submitted or overridden by a user. |
Duplicate submissions and corrections
- A second submission for the same facility and reporting date is a correction, not a duplicate record: the later submission becomes the current value and the earlier one is retained as superseded.
- A submitted census is not edited or deleted from the application; a correction is always an additional entry with its own timestamp and author.
- Scheduled report dispatch is identified by jurisdiction, schedule and reporting window, so a retried or twice-triggered run reuses the existing cycle instead of delivering a second report.
- A submission that fails validation is rejected in full, with the specific field, the reason and the place to correct it named. Nothing partial is stored.
Published extract format
The machine-ingestion format is a fixed, versioned CSV at schema version 2.0.0, one row per physical bed, with a fixed column order. PDF and spreadsheet outputs are human-review artifacts generated from the same records. Field-by-field detail is in the reporting data dictionary.
Version history
This document covers a change-managed subject, so every substantive change is versioned with its effective date and the audience it affects.
| Version | Effective date | What changed | Affected audience |
|---|---|---|---|
| 1.0 | 2026-09-08 | First published validation reference, derived from the implemented pre-submission gate and extract schema. | Facilities, provider organizations, jurisdictions |