Skip to main content

How reporting deadlines are triggered

Jordan Price, 14, walks out of the Claymont building without telling anyone and is found twenty minutes later at the bus stop. Delaware licensing and Boys and Girls Clubs of America both want to hear about that within a day. A deadline is only useful if the clock starts by itself, and PTRS starts both clocks from one test, applied once, at the moment an incident is created. This page explains that test, why it runs only once, and why the filing wizard can never pass it.

The rule​

An incident is treated as reportable if either of these is true:

  • its type is one of abuse, neglect, elopement, missing child, or emergency 911 called; or
  • its severity is one of the two highest of the five levels.

When the test passes, PTRS sets five things at once: OCCL is marked as required, the OCCL status becomes Pending with a deadline 24 hours after the incident time, and the BGCA status becomes Pending with its own deadline, also 24 hours after the incident time.

When it fails, both statuses are Not Required, both deadlines are empty, and the OCCL tracker does not appear on the incident at all.

"Incident time" is the moment the incident was created, not when the event happened. There is no way to give an incident an earlier time. Jordan's walkout at 4:10 pm, written up at 9 am the next morning, gets a deadline of 9 am the morning after that. Put the real time in the description.

Why the deadlines are both 24 hours​

Both figures are settings, not fixed rules, and both start at 24. The two clocks are separate, so an organisation whose BGCA duty differs from its state duty can set them differently. Ask whoever looks after your PTRS what yours are set to before you treat 24 hours as fact.

From the regulation The duty itself comes from Delaware licensing (DELACARE, enforced by OCCL) and, in parallel, from BGCA's national critical-incident reporting. PTRS stores the deadline as a number of hours. It does not store the regulation.

The rule runs once, at creation, and never again​

This is the part with real consequences.

After an incident is created, the only things you can change are the health and safety details: first aid, emergency medication, EMS and BGCA reported. Type and severity cannot be changed by any screen or by any other means. So:

  • An incident filed as routine and later understood to be serious does not gain a deadline. Nothing looks at it again.
  • An incident filed with the wrong type or severity cannot be corrected. If it is still a draft, you can delete it and file again. Once submitted it cannot be deleted either, because of mandatory reporting rules, so the correction has to live in a new incident that refers to the first, or outside PTRS.

Get the type and severity right at the point of creation. That is the whole practical consequence.

Which is a problem, because the wizard cannot set them​

The five-step wizard creates the incident at the end of step 1 with your description, your site and your name. It sends no type and no severity, so PTRS uses its defaults: type Other, lowest severity. Neither passes the test.

Step 3 shows Incident Type and Severity lists, and what you choose there is never saved. So an incident filed through the wizard, whatever you pick on step 3, is stored as Other at the lowest severity and starts no reporting clock.

Until that is fixed, a reportable incident either has to be created by someone with technical access to PTRS who can supply the type and severity directly, or its reporting has to be tracked outside PTRS. Treat the wizard's OCCL displays as decoration, not as a record.

Three OCCL verdicts on three screens​

Three different places give you an OCCL verdict, they disagree, and only one of them is the record.

WhereWhat decides itThe deadline it shows
Step 3, the blue AI Classification Result bannerPTRS's own test, from when the incident was createdThe real deadline, shown with a fixed label of "5:00 PM" whatever the actual time
Step 3 and step 5, the assistant panel on the right and the red Begin OCCL notification workflow rowA word-matcher in your browser with a different rule: medical attention needed, or EMS called, or high or critical severity, or a medical type above lowTomorrow at 4:30 pm, skipping weekends. Invented in the browser and unrelated to the record
The incident page, OCCL Notification TrackerThe stored deadlineThe real deadline and a live countdown

Only the third is the record. The browser rule fires far more often than PTRS's own, which is why the wizard can insist an OCCL notification is required for an incident PTRS has stored as not required.

Nothing moves a deadline once it is set​

Inside Incidents nothing runs on a schedule. In particular:

  • Nothing sets the OCCL status to Overdue when the deadline passes. The countdown on the incident page turns red and reads "OVERDUE by …", and the stored status stays Pending.
  • Nothing sets the BGCA status to Overdue either. The only change PTRS ever makes to it is Pending to Reported, when someone ticks BGCA Critical Incident Reported.
  • Nothing emails, texts or otherwise contacts a person about an approaching deadline.

One thing outside Incidents does read the deadline. Every 15 minutes, PTRS looks for incidents where OCCL is required, the status is still Pending, and the deadline is within the next four hours and has not yet passed. For each one it sends a warning to whoever has one particular screen open. Three limits decide what that is worth:

  1. It stops at the deadline. Once a deadline passes, the incident drops out of the check and is never mentioned again.
  2. The warning reaches one screen: the CACFP real-time feed, and only while someone has it open.
  3. It cannot see an incident filed through the wizard, because it needs OCCL marked as required, and the wizard never sets that.

The full trace is on Who learns that an incident happened.

For practical purposes the deadline is a record and a countdown. Watching it is a person's job.

Which of these would start a clock?​

Denise files Jordan's walkout through the wizard and picks Elopement on step 3.

No clock. The wizard does not save the type, so the incident is stored as Other at the lowest severity. The OCCL tracker never appears. Tom has to track the 24 hours himself.

Someone with technical access creates the same incident with the type set to Elopement.

Both clocks start, 24 hours from the moment of creation. The OCCL tracker appears on the incident with a countdown, and the 15-minute check will send a warning to the CACFP feed screen during the last four hours, if anyone has it open.

What this means for how you work​

  1. Decide the type and severity before the incident is created, not on step 3.
  2. Put the real time of the event in the description. The stored time is when you filed it.
  3. For anything reportable, keep your own reminder. PTRS will not chase you.
  4. Advance the OCCL status as you go, so the timeline shows what was done and when. See Advance an OCCL notification.

Checked against PTRS on 7 September 2026.