What Health & Safety can and cannot record

Most modules in PTRS fail in one place. This one is unusual. What PTRS checks before it saves anything is the best-built work in the whole product, and almost every failure sits on the boundary between that check and the screen a person actually uses.

That distinction matters for deciding what to do about it. None of this needs a different design. Almost all of it is a short list of mismatched words, one missing setup step, and one button that was never built.

What PTRS checks is genuinely good

Before PTRS lets a dose be marked as given, it does more than any other save in the product:

• it confirms the medication belongs to the child it says it does, at a site your account can see;
• it checks four separate conditions, and when one fails it names that specific one, not active, expired, no parent authorisation on file, or no physician authorisation on file, rather than a single vague refusal;
• it requires the staff member giving the dose to hold a certification for it that has not expired;
• it copies the medication's name and route from its own record rather than trusting whatever is typed at the moment of giving it;
• it stamps the time from PTRS's own clock, not a number someone could type wrong;
• and it writes a permanent audit entry.

The site medication policy tier is also real and enforced, and the illness record correctly writes a note when an illness is contagious.

This is careful work. Almost none of it can be reached from a screen.

One rule reaches all the way through, and it is worth naming on its own. Recording an illness pickup sets a day the child may not return before, and check-in the next time genuinely refuses that child while that day has not arrived, naming the reason and recording any exception made. It is the only rule in this module that runs start to finish: something written on one screen changes what a different screen allows a different person to do the next morning. Two things temper it. The rule reads as "not before tomorrow" rather than a literal 24 hours, since it compares dates rather than times. And PTRS can record an exception to the rule, and no screen anywhere sends one, so from a screen the block cannot be lifted at all.

One missing step stops the only automatic check

PTRS is meant to look once a day, in the small hours by Delaware time, for a physical exam, a consent form or a certification about to lapse, and for a member whose immunisations are not marked current. That check was never finished being connected into PTRS. It runs on schedule, shows up as failing in a technical dashboard nobody at a club opens, and fails every single time, for every organisation, since the day PTRS was built.

This is one of only two places in PTRS able to raise an urgent compliance warning at all. The other sits inside the Compliance module's own engine, which fails before it gets there, for its own separate reason. So:

No urgent compliance warning of this kind has ever been raised, by any path, in any installed copy of PTRS.

The visible result is not inside this module at all. The main dashboard's Urgent Actions strip reads this same warning list, and that section is permanently empty in every installed copy of PTRS. Not because nothing is expiring. Because nothing can ever write the line that would say so.

A site director looking at that dashboard sees an absence of warnings and reads it as an absence of problems. That is the single most consequential thing on this page.

The check would need more fixing before it could safely run

Finishing the connection would make the check run, and running it would expose four further problems. Each of its four parts writes a fresh warning every time it runs, with no check for one that already exists. On a daily schedule that means a new, duplicate set every single morning, for as long as the underlying condition lasts.

None of the three date windows has an early bound either. The physical exam check matches anything older than 335 days; the certification check matches anything expiring within 60 days, including things that lapsed years ago. So one old, stale record raises a fresh warning every morning, indefinitely. And the immunisation check is not an expiry check at all: it warns about every active member whose immunisation status is not marked current, on every run, with no date attached to say when it became a problem.

Turning the check on without also fixing the duplication would replace an empty dashboard with an unusable one.

The real problem underneath: four choices, and no shared vocabulary

PTRS's screens and PTRS's own record-keeping are written separately, by hand, with nothing that forces the words on a dropdown to match the words PTRS actually recognises. Four choices in this module feed straight into a check like that, and three of the four offer values PTRS's own record-keeping simply does not have:

Choice	Options offered	Options PTRS accepts
Medication Type	3	All 3
Route	9	4: Oral, Topical, Nasal, Rectal
Illness Disposition	5	3: Isolated, Sent Home, Returned to Program
Certification Type	8	1: First Aid

Every one of these failures shows up at the moment of saving, as a plain refusal message. Nothing is logged anywhere for a technical team to catch on its own, and nothing on screen tells you the difference between "that choice does not exist" and "the save simply failed."

The pattern is not random. In each case the screen was written using the words a person would actually say, and PTRS's own record-keeping uses different ones:

• Inhaler and Injection are what a clinician says. PTRS's own words are Inhaled and Injected.
• Eye Drops and Ear Drops are what a label says. PTRS's own words are Ophthalmic and Otic.
• Hospital Transport is what happened. PTRS's own word is Emergency Services.
• OCCL Medication Administration is what the certificate is called. PTRS's own word is Medication Administration.

Two choices offer something PTRS has no equivalent for at all: Nebulizer is not a route PTRS recognises, and Refused Entry is not an outcome it recognises.

The three consequences that matter most, in order:

1. A rescue inhaler and an adrenaline auto-injector, the two medications a club is most likely to hold, cannot be recorded with their real route.
2. A child taken to hospital cannot be recorded with that outcome. It is the one a licensing inspector is most likely to ask about.
3. The certification that authorises giving medication cannot be created at all: no choice on the form produces it.

The save that has no button

The third consequence compounds into the module's headline. Suppose the certification really could be recorded. There would still be nowhere to record that a dose was given.

The save exists. The check described above, the one that names the exact reason a dose is blocked, is real and correct. The rule requiring a current certification is real and correct. The connection between the screen and the save exists too, and nothing in the product calls any of it. There is no form, no dialog and no button. The Medications tab renders the read side of the same feature, a table headed Administration Log, which can only ever show "No medication administration records for this location."

This is not an unfinished feature. Every layer but the last was built carefully, and then no screen was ever attached to it.

What is worked out but never checked

Two things in this module compute a correct answer that nothing ever reads.

The first is the consent model. PTRS already works out, correctly, which consents a medication needs: an emergency medication needs one authorisation, and an injected prescription needs four different ones. PTRS also already records which consents a family has actually signed, through the Members module. The comparison between the two is itself built and correct, and nothing ever calls it, so PTRS never actually compares what a medication needs against what is on file.

The second is the Adverse Reaction column on the Administration Log table. The value behind it is never sent by the server at all, so it reads "None" for every row it could ever show, whether or not a reaction happened. This is the same root cause as the dropdowns above, a screen asserting a shape the server was never asked to satisfy, showing up here as a confident wrong answer instead of a loud refusal.

A column headed Adverse Reaction that structurally cannot ever report one is worse than no column at all. It answers a safety question, confidently, while connected to nothing.

Who can see what, and who is shown what

This module has the heaviest per-screen authorisation anywhere in PTRS: a floor that everyone with a health role clears, and most individual saves narrowing it further on top. No save widens the floor, and none skips authorisation entirely, so the true answer to "who can do this" is always the stricter of the two rules, which makes it unusually easy to state and trust.

The screen itself does not reflect that. It shows every save button to a much wider group than the one PTRS will actually accept a save from, so a Staff member and a Regional Director see and can press Register Medication, Edit, Return, Record New Illness, Add Certification, Renew, and every emergency action plan and site health control, and are refused by every one of them. It is the widest such gap found in the portal so far, and it runs the opposite way from most: elsewhere a role reaches a whole page it should not see; here two roles are shown working looking buttons on a page they genuinely need to read.

Two smaller asymmetries sit on the same table:

• The one save admitting a Staff account is recording that a dose was given, gated by a policy named for reading rather than writing. That is almost certainly deliberate: the person giving a dose should be the one recording it, and the certification check applies regardless. The audience is right. The name would mislead a future reader into narrowing it.
• An OCCL auditor's account can reach nothing here. One screen is meant for that role, and it has no client function, no hook and no visible control anywhere. Every other screen in the module excludes the role before it even gets there.

What this module is, honestly

It records medication inventory well: what is on site, for whom, where it is kept, when it runs out, and, for the four routes the form can actually submit, how it is meant to be given. It records illness well, apart from the two outcomes it refuses. It records emergency action plans and care plans in full, and it is the only module in PTRS that asks for triggers, mild symptoms, severe symptoms and response steps as their own required fields.

It does not record administration. That is the line between a medication inventory system and a medication management system, and it is the line an OCCL inspector is actually asking about.

Everything on this page is a boundary problem: mismatched words, one missing setup step, a screen that overstates what the server sends, and a save that was never given a button. None of it needs a different design. The part that is already right is the part underneath.

---

Related

• Medication and certification fields
• Who can do what with health and safety records
• Work the medication screens
• Compliance, the other place an urgent warning could come from