Append-only time, coded plans, and a signature that cannot be taken back.

Creation always writes the row as pending consent regardless of what the client asks for, and two service guards run before the insert. The first checks eligibility — at least two active chronic conditions, computed as the maximum of three independent sources rather than one. The function's own docstring explains why: relying on a single source made every published candidate un-enrollable. The second rejects a second open enrollment for the same patient and program, enforced in the service layer because MySQL cannot express a partial unique index.

Consent is captured as columns on the enrollment row — the date it was given, the method it was given by, and a reference to the signed document. They are written at creation and travel with the enrollment for the life of the programme, so the record of agreement sits on the same row as the care it authorised.

Three tables carry it. A vocabulary table holds the coded terms, where a null entity means a global term every tenant reads and none may edit, and a set entity means a tenant's own. A plans table holds one row per patient, program and month, referencing terms by id. A templates table holds tenant-defined reusable picks keyed to a diagnosis — a real editor with create and update endpoints, not fixed seed data.

Term resolution rejects an id that is unknown, belongs to another tenant, or is the wrong vocabulary type — a risk id supplied where a goal is expected. The service docstring gives the reason plainly: without that check, such a plan reads as a plausible care plan and is silently wrong. There is no version history table because there does not need to be one: each month is a new row, and retired terms are deactivated rather than deleted, so historical plans keep resolving.

Exactly one mutation is permitted afterwards: marking the entry invalidated. That is enforced twice — once in the schema as a literal, and once as an atomic conditional update that only applies to a row still in the recorded state. The second enforcement exists because a read-then-write would let two concurrent invalidations clobber each other's stated reason. There is no endpoint that edits the timestamps and none that deletes a row.

Month-to-date totals sum only recorded minutes and map the total through a plain inclusive-threshold ladder. That function drives the compliance tier care managers see, and it is deliberately separate from the module that derives billing line items — so nothing on the compliance surface implies a payment outcome.

That is a small decision that says a great deal about how the rest of the module treats evidence. A boolean with a default quietly manufactures a claim nobody made; a tri-state admits what it does not know, and leaves the gap visible to whoever reads the record later.

The review's own lifecycle has two states, draft and signed, and signing is one-way. The sign path takes a row lock before checking, so two concurrent signatures cannot both succeed, and returns a conflict if the row is already signed. The same signed check gates update and delete — three call sites, one condition. Two independent trails record who did it: the supervising provider field on the row itself, kept even if the user account is later removed, and the platform-wide audit log.

It performs no insert and no commit. The router's docstring states it directly: compute-vitals is non-destructive, returns a dictionary, and does not persist. The front end applies the returned values through a subsequent explicit update.

The result always carries all six keys, with nulls where the month has no source data. That matters for a review that will be signed: a missing measurement should read as missing, not be silently absent from the record.

The prefix-to-group mapping is derived from the same table the enrollment eligibility check uses, so the list and the gate cannot drift apart — a patient cannot appear as a candidate and then be rejected at enrollment for not qualifying.

The response publishes its own definition of eligibility as a string alongside the results, so a care manager reads the rule the list was built from rather than trusting a number they cannot inspect. A rule you can read is a rule a clinician can argue with, which is the point.

That is the interesting decision. A field-level merge would mean a patient override setting only an upper bound silently inherits an unrelated lower bound from the entity default — a rule nobody wrote and nobody reviewed. Whole-row resolution makes the active rule always something a human authored.

Deduplication suppresses a new alert while an open one of the same type and metric already exists for that patient. Alerts move new, read, then solved or dismissed. Critical breaches feed a separate emergency stream with its own lifecycle, queued on the session and dispatched only after the triggering transaction commits — so an alert is never sent for a reading that a rollback removes.

• In-app notification is written on the same session as the triggering write, deliberately bypassing the platform's self-committing helper so atomicity holds.
• The four alert types are all vitals-driven: threshold breach, missed measurement, a run of consecutive days out of range, and weight change.