A device that retries should never see an error.

Entity and patient are always resolved from the authenticated device row and never from the request body. That closes the obvious attack: a compromised key can only write readings for the patient its device belongs to. A retired or suspended device is rejected even with a valid key, which is the mechanism for revoking a stolen credential.

Value ranges are enforced as schema constraints per vital type — systolic, diastolic, heart rate, weight, glucose, oxygen saturation and temperature each have a plausible band — plus a validator requiring the fields that match the declared reading type. A device reporting a body temperature of two hundred degrees is a malfunction, and it should be rejected at the door rather than alerted on.

The status code matters here. A retrying device firmware that receives an error will usually retry harder, or worse, drop the reading. Returning success with a flag means the correct outcome — the reading is stored exactly once — is also the outcome the device understands.

The code calls this a Stripe-style idempotency guarantee, which is the right reference: the client's job is to keep trying until it hears success, and the server's job is to make repeated attempts harmless.

Without that widening, a reading taken at eleven at night local time on the last day of the month — stored in UTC as the first of the next month — would be counted in the wrong month, or dropped. With it, the count is right.

Only device-sourced readings that have not been invalidated count toward the reading-day threshold. Manually entered readings never do, which is a deliberate decision recorded in the plan. Alongside the headline count, the summary stores a per-sensor count for each vital type, so the detailed columns in the interface cannot disagree with the total above them.

• Clinical minutes are summed against the specific enrollment, not just the patient and program, so a re-enrollment cannot double-count a prior enrollment's time.

Once the fifth arrives, any prior-month summary not yet frozen is marked frozen, and the computation refuses to touch a frozen row again. From that point last month's number is a stable historical fact rather than something that quietly changes underneath a report someone already exported.

This is the kind of decision that only looks important the first time a number changes after someone has acted on it. Building the freeze in from the start costs a day; retrofitting it after a customer has noticed costs considerably more.

Devices carry an optional measurement schedule — a frequency and up to six local times. Staleness is computed on read rather than stored: a device silent for a week is flagged as a warning, two weeks as critical, anchored on the last transmission or, for a device that has never transmitted, on its activation.

The patient-facing device list joins each device to its most recent reading. That query's docstring records a real production lesson: dropping the patient scope on the inner ranking subquery once made it rank the entire readings table before joining, which hung the panel once the table held several hundred thousand device-linked rows.

Rules are either an entity default or a per-patient override, and resolution is wholesale. The module docstring gives the reason directly: a patient row that only sets an upper systolic bound would silently inherit the entity default's diastolic bound too. A merged rule is a rule nobody wrote.

Severity escalates to critical only when the triggering value also falls inside a fixed emergency band. Everything else is a warning. Deduplication suppresses a repeat while an open alert of the same type and metric already exists — otherwise a patient with a persistently high reading generates an alert per measurement and the inbox becomes noise.

The two day-count rule types — missed measurement and consecutive days — run on a separate nightly path deliberately shaped as one grouped query per rule and sensor across the whole patient set, never a per-patient loop.

Emergencies are the exception. A critical breach or a panic-button press fans out in-app plus email and SMS, to the assigned care manager or, if none is assigned, to everyone at the entity holding write access. It deliberately ignores each recipient's notification preferences, and the module docstring explains that in one line: a digest of panic-button presses is not a thing anyone wants.

Dispatch always runs after the row commits. The critical path, which fires deep inside the reading's own transaction, queues the alert on the session and the transaction owner drains that queue immediately after commit. Nobody is ever paged about a reading that a later error rolls back.

Columns cover patient, clinic and care-manager identity, program, reading-day counts overall and per sensor, clinical minutes and tier, and open and resolved alert counts. There are no billing identifiers, and the program dashboard carries no revenue fields at all — that is a locked design decision stated in the router itself.

The chart-side history view offers a print route with its own print stylesheet rather than a bundled PDF library. A spreadsheet importer for historical readings runs them through the same creation path as manual entry, so imported values evaluate thresholds and raise alerts exactly like anything else — replacing an older tool that, as the docstring records, generated its sample values randomly rather than reading them.