Public documentation written so a facility, provider organization, county, state agency, health system, procurement team or technical evaluator can answer architecture, reporting, permission and implementation questions without scheduling a meeting. Every document names its version, the date it was last reviewed, its owner, the edition it applies to and whether it is approved.
Everything below is publicly available. Nothing is published ahead of the implementation it describes, and where an owner decision has not been made the document says so instead of filling the gap.
What OCRS is, who uses it, and the boundary of the hosted service.
What the Occupancy & Capacity Reporting System does, who uses it, and where the boundary of the hosted service sits.
The approved OCRS vocabulary: what each term means, what it must not be confused with, which wording is withdrawn, and the verified difference between platform availability, census updates, submissions, notifications, delivery and retries.
How reporting information moves from a facility to an authorized jurisdiction recipient.
The authoritative Facility → OCRS → State/Jurisdiction reporting model, the role of organization aggregation, and a procurement-level data-flow diagram.
Bed states, licensed capacity, census snapshots and the values calculated from them.
Licensed capacity, bed states, block reasons, expected admissions and discharge orders, census snapshots and reporting periods — with physical bed state kept distinct from calculated reporting values.
What a submission must satisfy before it is accepted, and the published extract schema.
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.
Field-by-field reference for the public OCRS reporting extract: description, type, requirement class, source, validation and an example for every published field.
The implemented role registry and what each role may do.
The implemented OCRS role registry, what each role may do across facility data, census, reports, users, configuration and visibility, and how authorization is enforced.
Census history, audit records, exports, retrieval and account termination.
How census history, reporting history, audit records and exports behave; what happens to data on account termination; and which retention decisions are still awaiting owner policy.
Interoperability capabilities and the actual implementation status of each.
An honest status list for every OCRS interoperability capability: what is available in production today, what is configured, and what is only planned.
What a customer must decide or provide before an OCRS deployment can go live.
What a prospective customer must decide or provide before an OCRS deployment can go live, and which responsibilities sit with the customer versus OCRS.
Authentication, authorization, tenant separation and auditability, bounded by evidence.
High-level authentication, authorization, tenant separation, auditability and data-handling behaviour, stated only to the extent the implementation and the Claims & Evidence Register support it.
Support windows, scheduled reporting operations and what OCRS does not publish.
How scheduled reporting runs, what the published support window and initial-response target mean, and what OCRS deliberately does not publish about service status.
Product change history for reporting, validation, roles and exports.
Versioned record of product changes affecting the reporting schema, validation, roles, permissions, integrations, retention and exports.
In Development — not yet published
The full evaluation set in one place. Items with no link are either in development or deliberately not published — they are listed so the gap is visible rather than hidden.
Deeper material is released only through an approved due-diligence or security review. These documents are not published, because publishing them would enlarge the OCRS attack surface without helping an evaluation. Where no approved evidence exists yet, that is stated plainly rather than implied.
Detailed security architecture
ApprovedComponent-level architecture, trust boundaries, secret handling and administrative access paths.
Available during qualified security/procurement review Publishing it would enlarge the attack surface without helping an evaluation.
Authorization control documentation (row-level policy implementation)
ApprovedTable-by-table access policies, predicates and the tests that prove them.
Available during qualified security/procurement review Policy predicates are exploitable detail; the public matrix states the effect instead.
Infrastructure and network diagrams
ApprovedHosting topology, environments, hostnames and network paths.
Available during qualified security/procurement review Infrastructure detail is never published.
Internal control and verification evidence
ApprovedExecuted verification runs for permissions, tenant isolation, reporting and readiness gates.
Available during qualified security/procurement review Released under review so results are read with their scope and environment.
Security questionnaire responses
Under ReviewCompleted responses to a reviewer's own security or vendor-risk questionnaire.
Available during qualified security/procurement review Prepared per reviewer.
Penetration-testing evidence
In DevelopmentIndependent penetration-test scope, findings and remediation evidence.
Not available — no approved evidence exists yet No engagement has been completed, so no evidence exists to release.
Disaster-recovery evidence
In DevelopmentRecovery objectives, rehearsal records and restoration evidence.
Not available — no approved evidence exists yet Recovery objectives have not been approved, so nothing is published or released.
Operational reference material for people using OCRS day to day, alongside the guides and training courses in the Resource Center.
The recurring reporting schedule, what triggers an immediate report, how delivery is logged, and how repeated runs are kept idempotent.
Every OCRS role, what it can read and write, how scope limits it to a jurisdiction, organization or facility, and how isolation is enforced.
Field-by-field reference for occupancy exports and the state bed extract file layout.
Every validation rule applied to a census submission and the message it produces.
How an external system will be able to read published capacity data once the OCRS API is released.
