Carla Reyes is at the front desk with a folder of paperwork and her daughter
Maya, age nine, standing beside her. Denise Okafor takes the folder, opens
Maya's record on the screen, and in the next few minutes decides who Maya is
to PTRS: her name and birthday, who is allowed to pick her up, what she
cannot eat, and who to call if something goes wrong. Everything the club does
for Maya for the rest of the year starts from what Denise enters right now.
A child at the door is released to the adult standing there because a record
says that adult may collect her. The kitchen leaves out the peanuts because a
record says what she is allergic to. A paramedic is handed a physician's name
because a record has one. None of that is a report someone reads later. It is
a look-up, under time pressure, by whoever is on the desk.
Members holds that record: the child's identity, her guardians, her
emergency contacts, who may and may not collect her, her consents, her
medical detail, her documents, and her enrolment history. Nine other parts of
PTRS point back at this one child record, more than any other part of the
product. Getting Maya's record right, on the first afternoon, is what
everything downstream depends on.
Staff members, site directors, organisation administrators and super admins
can use every Members screen. A regional director sees the same menu and the
same buttons, and PTRS refuses every one of them: reading a child, editing a
child, adding a guardian, all of it. Guardians, read-only accounts and OCCL
auditors see the Members entries in the menu too, because the menu hides
nothing from anyone, and then the directory reads "No members found." for
them.
Two screens work differently from the rest of the module. The Financial
tab, covered on Member financial information,
is open only to organisation administrators and super admins, including for a
regional director. And the blank enrolment application form is open to
anyone, signed in or not, because nobody built a sign-in check for it.
There is no line between reading and approving
One setting covers almost everything a person can do with a child's record,
from reading her allergy list to deleting her pickup list, and it admits
staff members. Editing any field on any child, adding and removing a
guardian, adding and removing an authorised pickup, adding and removing a
restricted person, granting and revoking a consent, verifying a document
and confirming a scanned application into a live record are all allowed for
the most junior working role in PTRS.
The same staff account can read a child's pickup password, her insurance
policy number, every medical detail on file, and any note marked
"Confidential" whether or not the checkbox was meant to hide it. This is
recorded for the PTRS team and is not changed by this guide.
Carla's folder has Maya's birth certificate, an immunisation card and a
signed emergency form. Denise opens Quick Actions and Quick Member
Entry, types Maya's name, birthday and grade, and Carla's name and phone
number, and presses Create. Maya now has a record and Carla is her
guardian, marked primary and cleared to collect her.
Denise opens Maya's new record to finish it. She adds a second emergency
contact, because the club will not let Maya enrol without two. She records a
consent for emergency medical treatment, because that is required too. She
opens the Health tab and marks Maya's immunisations current and enters
the date of her last physical, copying both from the folder. Only then does
Add Enrolment succeed.
A week later Tom Bradley, the site director, is doing rounds and notices
Maya's allergy is not showing on the kitchen's list. He checks her record:
her peanut allergy is there, in the red banner at the top. It is not on the
kitchen's list because nothing in PTRS carries a structured allergy from a
child's record to the kitchen. He tells Denise to keep a paper list at the
serving line, the way the club always has.
Holds a detailed child record: identity, address, school, a medical
summary, insurance, a pickup password, and where the family heard about the
club, alongside guardians, emergency contacts, authorised and barred
pickups, consents, demographics, documents, notes and enrolment history.
All of it reads back on one record with eleven sections
Lets you find a child fast, with a searchable, filterable directory and
four alternative views of the same list
Gives four other screens outside Members a name search to pick a child
from: the header's quick attendance entry, Health and Safety, and both
Programs enrolment screens
Refuses to enrol a child until two emergency contacts, an active emergency
consent, current immunisations, a physical exam within the year and every
emergency medication on site are all confirmed. This is one of the few
real safety controls in PTRS, and it works
Reads a photograph or scan of a paper application with Quick Scan,
which sends the form to a real AI model and returns every field with a
confidence label, for a person to check against the paper. See
What Quick Scan extracts
Prints a wallet-sized photo badge with a scannable code, built in the
browser
Logs a change to the audit trail for almost every write in the module
Numbers this page does not carry
"Records complete on the first day", "average time to register a child" and
"scan accuracy" are the figures an evaluator asks for here. None is
published. The first cannot be measured honestly: the missing-document check
looks for three fixed document types and ignores whether a document is
actually required for that child. The third would need a labelled set of
forms checked by a person, and none exists. The only confidence figure in
Quick Scan is a number the model reports about its own work.
Type Maya's allergy into her record and it goes into a free-text banner
that only her own record shows. It never reaches the meal-tracking or
health-and-safety screens that are supposed to check it, because nothing
in PTRS can write a structured allergy anywhere. Keep telling the kitchen
on paper
If Maya's birthday is entered wrong, on paper or by a misread scan, it
cannot be fixed. No screen in PTRS changes a date of birth once a child is
created
The eight-step registration wizard looks complete and cannot finish a
single registration. Use Quick Member Entry and the child's own
record instead, and read Add a child to PTRS
for why
Adding a guardian always creates a new one, so three children in one
family end up with three unrelated guardian records. Correcting a phone
number means doing it once per child
Removing an authorised pickup keeps no visible history. Note it on paper
if a family will ask later
Five screens make up Members, and Quick Scan behind two of them.
Screen
What it is
What it can do today
The directory
The searchable list of children, with four alternative views
Works. The search box only matches a first or last name, though it says otherwise. Three of five clickable column headers sort by last name no matter which you click
A child's record
Eleven sections covering identity, health, documents, notes, pickups and more
Mostly works. Three sections cannot save what they show, and two statistics are computed over the five most recent visits or incidents only
The registration wizard
An eight-step guided sign-up with a review page
Loads and walks through all eight steps. The final save always fails partway through
The scan review queue
A list of uploaded application scans awaiting a person's check
Works for reading the list. The scanned image itself never displays
The split-screen scan review
The extracted fields beside the scanned image, for a detailed check
The fields display and cannot be typed into. The image beside them is always blank
One task runs on a schedule and touches this module. Once a day, at 2 in the
morning Delaware time in winter and 3 in the morning in summer, PTRS looks
for a child's document that will expire within 30 days and writes a note to
its own internal log. It does not send an alert, an email or a message to
anyone, and it does not skip a document that has already been removed from a
record, so a removed document keeps producing a daily note until its
expiry date passes on its own.
Nothing else in the module runs on its own. There is no message sent when a
record changes and no automatic notice of any kind.
A child's check-ins show on her record's Attendance section, and the header's quick attendance entry uses this module's name search
Programs
Enrolling a child into a specific programme, and the licence-capacity check that runs when you do, happens in Programs, not here. The link between the two is solid
Incidents
A child's record shows her five most recent incidents and her role in each
CACFP
An enrolment links a child to a meal programme by typing her record id as plain text, with no picker to choose her by name. Three CACFP screens are supposed to read her structured allergy and cannot, because nothing writes one
Health and Safety
A child's emergency action plans and medications on site are that module's own screens, shown inside her record. Its readiness check also depends on the structured allergy that nothing writes
Parent Portal
A guardian's messages and signed authorisation forms both point back at the child record
Notifications
Not connected. Nothing in Members sends a message of any kind
Audit
Nearly every write is logged. Twelve fields on the child record, including her allergy text, her medications, her insurance number and her pickup password, are deliberately left out of what the audit trail remembers about a change
These are defects in PTRS, not in this guide. They are written up for the
PTRS team in the Members findings document. This guide describes PTRS as
it behaves today and does not change it.
Member and guardian fields, every
field on a child, a guardian, a contact, a pickup, a consent and a
document, with the rule PTRS actually enforces on each