One patient table. No bridge, no sync, no reconciliation.

Both front ends authenticate against the same signed cookie issued by the same auth router, and both point at the same API base. The milestone document states the rule directly: every network router is the canonical source, and the EMR is a thin client over it.

The consequence is the product. A problem added during a visit, an allergy recorded at intake, a signed note — each is immediately visible to a utilization reviewer or a care manager working in the network portal who holds a grant to that patient. Not after a nightly job. Not after a reconciliation. The alternative architecture, two systems and an interface engine, spends its life answering the question 'which copy is right'.

That distinction is what lets a medical director whose active entity is their own provider record open a chart owned by the parent IPA they oversee, without switching context, provided a grant actually exists.

On top of the entity gate sits a narrower panel gate: by-id chart routes require the caller to be on the patient's care team unless they hold a cross-panel permission. The code comments explain exactly which hole this closed — the panel filter used to live only on the my-panel list query, so a clinician who could not find a patient through the interface could still open the whole chart by guessing the URL. Both gates deny with 404 rather than 403, so an identifier probe learns nothing about what exists.

Then the orchestrator dispatches three side effects: render and store the after-visit summary as a document, draft a claim from the encounter's billing data, and recompute the patient's risk score. Each runs inside its own savepoint, so a claim that violates a constraint rolls back only itself rather than poisoning the signature.

Each side effect is recorded in an outbox table keyed uniquely on encounter and side-effect name. That unique constraint is the idempotency mechanism: an addendum re-sign, or a retry from the cron that sweeps failed rows up to three times, is a no-op once the side effect has completed. The document is not generated twice and the claim is not drafted twice.

• Co-signature eligibility is defined once in a shared predicate module used by five call sites — introduced specifically to stop an attending's own notes appearing in their own co-sign queue.

Tabs scroll to their section rather than routing, with a click-lock so an in-flight scroll animation and the intersection-observer scroll spy do not fight each other. Each section is an independent card component, so the page assembles rather than navigates.

The page's own comments record the history: an earlier vertical quick-nav was removed once the tab bar covered the same destinations. That is worth noting because it is the kind of decision that usually goes unrecorded and then gets re-litigated every six months.

That last outcome is the important one. The hook is fail-open by construction — if the delegation evaluation cannot complete, the referral row is still created and a cron retries the authorization later. The clinician is never blocked by an authorization service having a bad afternoon.

The loop closes on the way back. When a specialist's consult note returns, the referral is stamped as reported, the referring provider is notified, and — again fail-open — a quality measure event is credited if the specialty maps to one of the tracked screening or diabetes measures. If that credit fails to write, the consult note still lands; only the measure credit is lost, and it is logged.

Routing is delegation-aware: the lab vendor and requisition template are resolved from the patient's payer and the IPA's routing overrides rather than hardcoded per clinic. Standing orders are generated by a cron guarded by a unique constraint on patient, test code and due date, so a re-run cannot create duplicate pending labs.

Before a result reaches a patient portal account, a release layer applies adolescent-proxy masking — results in sensitive categories for patients aged twelve to seventeen are withheld from a parent or guardian proxy account. That is a legal requirement in many states, and it is enforced in a service rather than left to a template.

Controlled substances are handled separately and more strictly. Classification comes from a catalog, and at the moment of signing an immutable audit row is written capturing the schedule and snapshotting the prescriber's registration as it stood then — even if the drug is later voided or reclassified. If no active registration is on file the row is still written with a null value, so the gap is visible in the trail rather than silently absent. The router already hard-blocks that combination; the log entry is defence in depth.

Identity proofing for controlled-substance prescribing is delegated to the eRx vendor's hosted two-factor flow — a one-time enrolment tied to the prescriber, not a per-prescription step, and not something we built ourselves.

The guardrail is the data model, not a warning banner. Every AI suggestion — assessment, care gap, medication, order, differential — is recorded as its own decision row carrying the original value, the final value, and a verb of accepted, modified or rejected. Nothing auto-commits to the chart. If you want to audit what the model proposed versus what the clinician actually signed, the answer is a query, not an investigation.

Consent is captured as a required row before recording proceeds, carrying its source and the version of the consent text shown. Audio chunks are purged by a cron after a configurable retention window; the transcript and the draft are retained as the record. Raw audio goes only to the configured speech engine, never to the drafting model.

The evaluation-and-management level suggester is explicitly not an AI service. It is a deterministic, rules-based implementation of the published medical-decision-making and time-based guidelines, and the provider attests before submit. That choice is worth stating plainly: for a decision that carries audit exposure, a rule you can read beats a model you have to trust.

The chart-to-claim path is closed end to end and exercised as one loop rather than as three separate features, which is what makes a coding change visible in the claim it produces on the same visit rather than a reconciliation cycle later.

On top of that sits a per-patient accounting-of-disclosures surface, which implements the privacy-rule right for a patient to be told who accessed their record. It filters audit events by patient and streams them as CSV — and it audits the act of viewing the access log itself as its own action.

A second, coarser trail runs alongside: an append-only per-patient event timeline that is never updated or deleted. Two independent trails at different granularities is more useful than one, because they can be compared.