Work the special dietary screen

Maya has a peanut allergy on file, and Denise wants to check it before she plans the week's snack. This page is how to use Special Dietary Accommodations for the one thing it does, and why the form above it cannot record a substitution.

Who can do this

• Front-line staff
• Site director
• Regional director
• Organisation admin
• Super admin

The Record Meal Substitution form is shown to everyone PTRS admits. The two read panels below it check nothing.

The page is subtitled "Meal substitutions, allergen cross-reference, and medical statements." It is in the sidebar under CACFP → Enrollment & Eligibility.

Despite the subtitle, there is nothing about medical statements on it.

Allergen Cross-Reference, the panel that works

This is the useful half of the page, and it is correct. It finds every active CACFP enrolment in your organisation, takes the children behind them, and lists the ones with a recorded allergy by name, ordered alphabetically.

Checkpoint

If a child with a known allergy is missing from this list, the cause is almost always upstream: either the allergy is not recorded on the child's own record, or the child has no active CACFP enrolment. The panel reads enrolments, not attendance.

Two limits to know:

• It has no site filter on screen. Every site's participants appear together, which on an organisation with several sites makes it a poor kitchen-side reference.
• An empty panel looks the same whether nobody has an allergy or nobody is enrolled at all.

Substitution History

Shows the whole organisation's first 25 substitutions, newest first, with no site filter on screen.

It is empty in every copy of PTRS, because nothing can create a substitution.

Record Meal Substitution cannot save

The form collects Member ID, Substitution Basis, Standard Menu Item, Substituted Item, a "Meets meal pattern requirements" checkbox and notes. Three separate problems sit between it and a stored record.

1. Two required fields are sent blank

The page sends a blank site and a blank meal record alongside what you typed. Both are fields PTRS requires to be real records, so the request fails before PTRS even runs its usual checks. The toast reads "Failed to create meal substitution."

2. Every basis value the dropdown offers is rejected

The dropdown offers four values. PTRS recognises three, and there is no overlap at all:

In the dropdown	Recognised by PTRS
Medical	Medical Statement
Disability	Voluntary Accommodation
Religious	Allergy Record
Other	(not recognised)

Whichever you pick, PTRS refuses, naming the value as invalid. This is the fourth time this pattern has shown up in the CACFP module, and the first where none of the choices offered is valid.

3. There is no way to identify the meal being substituted

Even with the two fields above fixed, PTRS requires a real meal record that exists in your organisation. A meal record's own id is not shown anywhere you could copy it from, and the form has no meal picker.

Member ID is a free-text box, exactly as on the CACFP enrolment form. There is no child picker; PTRS checks the id against your organisation and says the member could not be found otherwise.

"Meets meal pattern requirements" is not checked by anything

The checkbox is stored exactly as ticked. No meal pattern check runs on a substitution, not on creating one, not on updating one. The person recording the substitution is asserting the answer, and PTRS stores the assertion.

A substitution cannot be edited or removed, and updating it loses its own audit line

Updating and removing a substitution are both built and reachable from no screen. Looking up one by itself has a hook that nothing calls.

Updating is also the one place in this subset where the record of what changed is lost: the update writes straight to the database in a way that skips PTRS's usual audit step, so the record changes and no line is added to the audit trail. Every other write in this part of the module records one immediately.

Medical dietary statements have four actions and no screen

Creating, listing, looking up and updating a medical dietary statement are all built, validated and recorded in the audit trail. Creating one is described in PTRS's own design as following the federal rule for a physician's order.

None of the four has a screen anywhere in PTRS. The subtitle on this page promises medical statements and shows nothing for them.

The record itself is thorough: physician name and signature date, diagnosis, dietary restriction, prescribed substitution, effective and expiry dates, a life-threatening flag and a document attachment. PTRS defines Active, Expired, Superseded and Revoked statuses; only updating a statement can change one, and nothing calls that action, so every statement would stay at whatever it started as.

The screen piece built to upload a statement's document exists and is used by no page.

Allergy emergency protocols have six actions and no screen

Creating, listing, looking up, updating and a staff-review step for an emergency protocol are all built, along with a lookup PTRS's own design describes as a meal-service banner for a site.

None of the six has a screen. There is no emergency-protocol screen, and no meal-service banner anywhere shows one.

The record holds the allergen, a severity of Mild, Moderate, Severe or Life-Threatening, symptoms to watch, emergency response steps, whether medication is on site and where it is kept, two emergency contacts, and effective and expiry dates.

This is the module's most safety-critical record, and it has no way in and no way out. The only allergy information a person can actually see is the cross-reference panel above, which shows an allergy name and nothing else, no severity, no response steps, no medication location.

Looking up approved substitution items would show every organisation's food catalogue

PTRS can list creditable food items for a component, to help someone pick a substitution. The way it looks them up leaves out the check that keeps it to your own organisation.

That matters because a food item does not carry PTRS's usual organisation safeguard the way most records do, and this is the one place in the module that forgets to add the check by hand.

So this action would return the food items of every organisation in PTRS to anyone who could reach it. It is governed by the same rule as the rest of the module, so any signed-in staff member could call it.

It is not currently called: the screen piece that would use it exists and nothing calls it, and it also expects a different shape of answer than PTRS sends, so it would not display correctly even if it were connected.

Six other records sit in the same unguarded position and are safe today only because every actual use of them adds the organisation check by hand: the food review queue, meal pattern rules and their sets, serving requirements, age-group mappings, and recipe crediting profiles.

Where to go next

• Who can do what with menus and inventory, all seventeen special-dietary actions and which have a screen
• What makes a meal reimbursable, what a substitution would have to satisfy
• Enrol a participant, the enrolment the cross-reference panel reads
• CACFP troubleshooting