Report an incident

A child is hurt, or something happens that Delaware requires a licensed program to report. What follows crosses Incidents, Notifications and Compliance, and it runs against two clocks at once: the site director needs to know right now, and OCCL needs to be told within a fixed deadline.

PTRS keeps a good record of this and tells nobody at all. That one sentence is the whole flow. This page traces both halves, the record, which genuinely works, and the notification chain, which does not exist, so the part you have to do yourself is visible before you actually need it, not afterward.

The flow at a glance

#	Step	Part of PTRS	Documented in
1	Describe what happened and create the incident	Incidents	File your first incident report
2	Attach the children involved as participants	Incidents, Members	File your first incident report
3	Record the health and safety facts	Incidents	Record health and safety details
4	A reporting deadline is set, or is not	Incidents	How reporting deadlines are triggered
5	Submit. The incident becomes impossible to delete	Incidents	File your first incident report
6	Tell people yourself. PTRS will not	(none)	Who learns that an incident happened
7	Move the OCCL notification through to submitted	Incidents	Advance an OCCL notification
8	Export the report when it is asked for	Incidents	Export an incident report
9	Review the pattern across incidents	Incidents	Review incident patterns

Every change made in steps 1, 3, 5 and 7 adds a timeline entry and a row to the audit trail. That is what the record is actually made of.

Steps 1 to 3: the record

The filing wizard is documented step by step at file your first incident report, and every field with the rule PTRS itself enforces on it at Incident fields.

The parts a flow reader actually needs to know:

Participants are children drawn from Members. Attaching one is the flow's only crossing into another part of PTRS before it is submitted.

Health and safety facts go on a separate panel. See record health and safety details. This is the incident's own record; the Health & Safety module's own medication and illness logs are kept separately and are never written from here. What that module can and cannot record is at what Health & Safety can and cannot record.

The description field is the one piece that survives everything. It is kept permanently, and it reaches the exported document.

Step 4: the OCCL deadline

Whether an incident actually carries an OCCL deadline, and how that deadline is worked out, is at how reporting deadlines are triggered.

One consequence belongs on this page, because it decides what step 7 can actually do: an incident filed through the wizard can never come out the other end flagged as OCCL-required. The background job that checks deadlines every 15 minutes only selects incidents carrying that flag, so an incident filed through the screen never enters its results at all.

Step 5: submit

Submitting sets the status, adds a timeline entry and writes an audit row. The incident becomes impossible to delete after this, which is the correct behaviour for a regulated record.

The confirmation screen lists four things that did not happen

The last step of the wizard offers four switches: notify the director, notify the parent or guardian, start the OCCL notification process, create follow-up tasks. These live only in your own browser; the actual save sends the incident's own id and nothing else at all.

Afterward, the screen shows a fixed confirmation list saying the site director was notified by push notification, the regional director was notified by email, guardians were notified, and several follow-up tasks were created and assigned.

Every one of those lines is fixed text, and none of the four things actually happened. There is no way any of the four could happen: no push notification is ever sent, no email is ever sent, no guardian is ever notified, and nothing anywhere in PTRS ever creates a follow-up task from here. Read the timeline instead; it shows what was actually recorded.

Step 6: the notification chain, which is not actually there

This is the step the whole flow exists to make visible, because it is the one step a reader will naturally assume PTRS already covers.

Nobody is actually told. The full trace, piece by piece, is at who learns that an incident happened. In short:

The action that creates an incident has no way of reaching anyone at all; nothing in how it is built could ever notify a person.

A complete pair of messages for "incident created" and "incident submitted" is fully built and registered, and nothing anywhere in PTRS ever actually sends either one.

PTRS has a complete notification system built, and the only thing that ever calls it is the emergency-alert escalation process, which can never actually reach that call, because nothing anywhere creates an emergency alert record in the first place. See Notifications.

The specific field meant to record a parent notification on an incident is never actually set by anything. The detail screen fills that gap with fixed text instead, which is why the parent communication panel reports that a parent notification was not required, for every incident ever filed, without exception.

The one thing that happens automatically around an incident is the 15-minute OCCL deadline check, and its warning appears on exactly one screen, the CACFP live feed. It is not saved anywhere, so closing that page loses it for good.

Tell people yourself, separately, and write down that you did

By phone, by radio, in person. Then put who you told and when directly into the incident's own description, because that is the only field that is actually kept permanently and the only one that reaches the exported document. The parent communication panel cannot record any of this for you.

Step 7: moving the OCCL notification along

Advancing the OCCL status is documented at advance an OCCL notification. This is the one part of this whole flow that both works and produces a record that survives being questioned later: each move adds a timeline entry and an audit row, with the time it happened.

PTRS does not actually contact OCCL. Advancing the status only records that you did. The notification itself has to be made the way your own licence requires it, by phone, through the state's own portal, or on paper, and PTRS's own record is your evidence that it happened when you say it did.

Compliance reads these very records back: one built-in rule checks that no OCCL-required incident is still pending past its own deadline, and the inspection checklist at prepare for an OCCL inspection lists the three incident items an inspector will actually look for.

The compliance rule that reads this flow does not currently produce a score

That built-in rule is correctly written, and the calculation it runs inside of fails outright on every single run before it ever writes anything, so no compliance score and no compliance alert is ever actually produced from it. See how the compliance score is calculated. The checklist is the working substitute, and it can be printed.

Steps 8 and 9: afterward

Export the report whenever a regulator, an insurer or a parent asks for it. See export an incident report.

Review patterns across incidents on review incident patterns. Read that page's own cautions before quoting it anywhere: the pattern detection is a simple keyword match run in your own browser against fixed thresholds, not a model of any kind.

The audit trail holds every change made through PTRS itself, secured by a tamper-evident chain over the sequence of events. See read the audit trail and the audit hash chain. What that chain does and does not actually prove is stated precisely on that page; it is worth reading before you rely on it in a dispute.

What is real, and what is decoration

The incident record, its timeline and its audit rows	Real. Written on every path
Impossible to delete after submission	Real
The OCCL status history, with its own times	Real, and it is your own evidence
The exported document	Real
The submit screen's four confirmation lines	Decoration. None of the four actually happened
The parent communication panel	Decoration. It reads a fixed piece of text built into the screen
Any belief that a director, a regional director or a guardian was told	Not true. Nothing was actually sent

Related

• Incidents overview, Notifications, Compliance overview
• Who can do what in Incidents
• Incidents troubleshooting
• Keep a credential current, the other flow that also ends at OCCL