Feature documentation

Every feature of the AI-native platform, documented in depth: what it is for, who uses it, how the workflow runs end to end, and the guardrails and audit events wired into it. Every feature here was designed for AI use of protected data from the start — the governance is in the feature, not wrapped around it. Organized the way the navigation is, so this page can be read alongside the screens themselves.

Every feature, at a glance

1. Clinical workspace

1.1 PHI AI assistant (PHI RAG)

Problem

A clinician's question — what changed since the last visit, what has this patient been on, why was this claim denied — is answerable from the record, but answering it means opening six screens and holding the pieces in your head. The pain is not that the data is missing; it is that assembling it costs minutes that belong to the patient. The naive fix, an LLM pointed at the chart, trades that cost for a worse one: an answer nobody can check, drawn from records the reader may not be permitted to see.

Persona & context

Every profile holding assistant:use, with the available tools differing by role — a clinician mid-visit, a coder reconstructing a claim, an analyst sizing a population. The context that matters: the asker is under time pressure and will not verify an answer that makes verification difficult.

Solution & value

The question is asked in plain language. The assistant plans retrieval against role-scoped tools, the gates release what the role allows and count what they withhold, the model drafts only from released excerpts at temperature 0, and the answer renders with citations ([MRN-###### · chart]) plus an explicit withholding statement when anything was held back. Every record it names is one click away. The value is not speed alone — it is an answer whose basis a reader can check in the time they would have spent assembling it.

Validation & metrics

Quantitative: question volume and per-tool disclosure counts from ai.query and each tool's own event; citation density per answer; rate of answers containing a withholding statement (a rate near zero on a mixed population means the gates are not being exercised and deserves investigation, not celebration). Qualitative: whether readers follow the citations — a cited answer nobody clicks through is being trusted rather than verified, which is the failure mode this design exists to prevent.

Assumptions & constraints

Answers come only from retrieved records; absence is never asserted from documents that were not read; minimum-necessary confirmation precedes population sweeps; the counts-never-lists rule holds on the population plane; psychotherapy content requires the Psychotherapy role and an explicit confirmation. Questions are stored per user and can be saved or deleted; answers are never stored, so history cannot become a stale shadow chart. The thread keeps the last twelve turns, and a clicked history entry prefills the ask box — never auto-runs.

1.2 Patients & charts

Problem

Finding the right patient and reading their record is the most-repeated action in the building, and the one where a chart that quietly omits what it is not showing does the most damage. A reader who cannot tell the difference between "no such record" and "a record you may not see" will make decisions on a chart they believe is complete.

Persona & context

Clinician, HIM and Psychotherapist, working from partial identifiers — a surname and a birth year, an MRN fragment on a fax — often mid-workflow rather than at the start of one.

Solution & value

Search is token-wise AND over names and MRNs: every word must match, in any order, so partial identifiers converge instead of returning everything. The chart renders as a storyboard — demographics banner, active problems, medications deduplicated to the latest per drug, allergies, encounters, labs and vitals with abnormal flags, documents, imaging, a claims summary for claims:read holders, and the psychotherapy block only for the Psychotherapy role. The value is a chart that states its own incompleteness rather than implying completeness.

Validation & metrics

Quantitative: phi.search per search and phi.disclosure per chart open, each carrying reader and purpose — which together make "who read this chart, and why" a query rather than an investigation. Searches per successful chart open is the usability measure: a rising ratio means the search is not converging. Qualitative: whether the sensitivity callout is understood as "records exist and are withheld" rather than "no records".

Assumptions & constraints

A sensitivity callout states how many records were withheld and under which categories. Assumes MRN is the stable identifier and that role assignment is correct upstream — this feature enforces the role model, it does not decide it.

1.3 Summarization

Problem

Reading into an unfamiliar chart before a visit takes longer than the visit allows, and the summaries people write to cope with that become a parallel record that ages badly — accurate on the day it was written and quietly wrong thereafter.

Persona & context

Any reader with patient:read coming to a chart cold: a covering clinician, a specialist at first consult, a reviewer picking up a queue.

Solution & value

A clinically ordered brief — active problems with their supporting evidence, medication status, recent trajectory — generated on request and never cached, so it cannot go stale. Every sentence is traceable to a cited record and unknowns are stated as unknowns.

Validation & metrics

Quantitative: ai.query plus the underlying phi.disclosure reads; the share of summaries a clinician signs into the record versus reads and discards — both are valid outcomes, and the ratio says which job the feature is actually doing. Qualitative: whether the brief changes what the reader does first in the encounter.

Assumptions & constraints

The summary is labeled generated and is not part of the record unless a clinician signs it into a note. Generated per request, so it costs an inference every time — the deliberate trade for never serving a stale narrative.

1.4 Inbox triage

Problem

Results and messages arrive in the order they were sent, which has nothing to do with the order they should be read. The dangerous item sits between two routine ones, and volume — not judgement — decides what gets missed.

Persona & context

Clinicians and their support staff working a queue that refills faster than it empties, usually in the gaps between patients.

Solution & value

Each item is ranked with its reason shown — the abnormal value, the overdue follow-up — so the ranking argues for itself rather than asserting authority. The value is that the dangerous item surfaces without anything being taken away.

Validation & metrics

Quantitative: time to first action on high-rank items against the queue baseline; the rate at which clinicians act on low-ranked items early, which measures how much the ranking is trusted and how often it is wrong. Qualitative: whether the stated reason is the reason a clinician would have given.

Assumptions & constraints

The ranking is advisory: nothing is auto-dismissed, nothing auto-answered, and the queue remains the clinician's. A triage model that hides an item is a patient-safety event, so this one only reorders — never removes. Assumes result feeds arrive complete; a gap upstream is a triage gap this feature cannot see.

1.5 Ambient documentation

Problem

The note is written after the visit, from memory, at the end of a day already over. The cost is documentation burden measured in hours and a record that is thinner than the encounter that produced it. Ambient capture is the obvious answer and carries a non-obvious risk: recording a clinical conversation is regulated differently in different states, and a tool that records first and asks later creates the exposure it was meant to relieve.

Persona & context

Clinicians holding ambient:capture, in person or over telehealth — a distinction that matters, because the parties may sit in different jurisdictions.

Solution & value

The flow starts at the consent gate (§6.3): recording is possible only where the jurisdiction-and-modality verdict allows, and in all-party states the visit-level attestation is captured first (consent.attested). Capture runs through the ambient listener — a self-hosted speech-recognition model in the registry's ambient slot — which transcribes with speaker labels, writing model.inference per transcription. The drafting model turns the transcript into a SOAP note, flagging ASR-uncertain terms as [ASR: …] for the signer rather than guessing. The draft enters the signature queue like every other draft. Because the listener runs inside the deployment, audio never leaves the account: no ASR vendor exists, so no vendor BAA is needed.

Validation & metrics

Quantitative: documentation time per encounter against the pre-deployment baseline; edit distance between draft and signed note (a draft signed unchanged deserves as much scrutiny as one heavily rewritten); count of [ASR: …] flags per note as a transcription-quality signal; consent refusals recorded rather than worked around. Qualitative: whether clinicians keep the flags in the draft while reviewing, which is the behaviour the flags exist to produce.

Assumptions & constraints

No consent, no recording. The note is a draft until signed (§1.7). Raw-audio retention is a governed setting the deploying organization sets. Assumes the jurisdiction table is maintained with counsel — the gate is only as current as its rules. On this demonstration site the encounters are synthetic recordings.

1.6 Patient instructions

Problem

After-visit instructions are written in clinical register and handed to someone who has just been given news. What the patient takes home is a document they cannot act on, and the failure shows up later as a missed medication or an avoidable readmission.

Persona & context

Clinicians and discharge staff with patient:read, at the end of an encounter when attention is lowest and the temptation to reuse a template is highest.

Solution & value

Instructions drafted at a patient-appropriate reading level from the visit's actual orders and diagnoses — this patient's medications and follow-up, not a template's. Reading-level targeting changes wording, never content.

Validation & metrics

Quantitative: reading-level score of issued instructions against target; the share of drafts edited before signature; downstream follow-up attendance and medication pickup where the organization can join those. Qualitative: teach-back — whether the patient can restate the plan.

Assumptions & constraints

Instructions derive only from what is in the record; no invented advice. Drafts are signed before they reach the patient. Assumes the orders are recorded before the instructions are drafted — this reads the record, it does not anticipate it.

1.7 Signature queue

Problem

Every generated draft eventually meets the question of who is accountable for it. Systems that answer that question with a timeout, a default, or a batch approval have moved the accountability without moving the judgement — and the record ends up carrying text no clinician ever read.

Persona & context

Licensed reviewers holding patient:read, working a queue that mixes ambient notes, appeal letters, coding queries, instructions and imaging reports.

Solution & value

Drafts wait with their citations. The reviewer reads, edits, and either signs — writing signature.committed and releasing the note to write-back, attributed to the signer — or returns it. The value is structural rather than procedural: an unsigned draft has no write path at all, so the rule cannot be skipped under pressure.

Validation & metrics

Quantitative: queue depth and age; sign versus return rates per draft type — a type approaching a 100% sign rate is either excellent or unread, and the edit distance distinguishes them; zero drafts reaching write-back without signature.committed, which is a boolean the audit trail can prove. Qualitative: whether reviewers report the queue as a place they think, or a place they click.

Assumptions & constraints

Nothing advances by timeout, default or batch approval. Assumes reviewer capacity matches draft production — the gate holds regardless, so an under-staffed queue shows up as depth rather than as unreviewed text in the record, which is the correct failure.

2. Revenue & records — every feature's core is a model

Each feature below is powered by a registered model in the Control panel's registry, with its own enable switch, its metrics on the Model monitoring screen, and the standard degradation rule: a disabled core means the feature says so and computes nothing unmanaged.

2.1 Claims & billing — the denial risk model

Problem

Denials are discovered after adjudication, when the cheapest fix — correcting the claim before it went out — has already expired. Rework is expensive, appeals are slower still, and the same avoidable denial recurs because nobody sees the pattern behind the individual claim.

Persona & context

Revenue-cycle staff holding claims:read, working a pending queue under a submission deadline.

Solution & value

Registry entry Denial risk model (predictive, slot claims) scores every pending claim 0–99 before adjudication from the payer and service-line denial history in the Data Store. Each factor cites the real counts it came from, so the score argues rather than asserts. The screen leads with the scored queue and the strongest payer × service denial clusters — where a process fix beats resubmission.

Validation & metrics

Quantitative: score separation between denied and paid claims on the validation sample, and per-band calibration — both computed on Model monitoring from outcomes, never self-reported; first-pass acceptance rate; rework hours. Population-stability index on the input mix flags when the payer landscape has moved under the model. Qualitative: whether the clusters lead to process changes, which is the outcome; a well-calibrated score nobody acts on has not solved the problem.

Assumptions & constraints

A score never blocks a claim. Assumes denial history is representative of what the payer will do next — the assumption drift monitoring exists to falsify. Subgroup behaviour belongs to the fairness discipline (§6.2), not to this screen.

2.2 Prior auth & appeals — the evidence assembler

Problem

A prior authorization is a scavenger hunt through the chart for evidence against criteria written by someone else, and an appeal is the same hunt done twice under a deadline. The work is clerical, the stakes are clinical, and the gap that sinks a submission is usually one nobody noticed was a gap.

Persona & context

Prior-auth and appeals staff with claims:read, working from a payer policy the platform did not write and cannot assume.

Solution & value

Registry entry Prior auth evidence assembler (retrieval, slot priorauth) checks each criterion by retrieval — diagnosis, order, result series, trial-of-therapy note — each citing its chart entry, with gaps shown as gaps and never inferred. From that evidence it drafts the appeal letter, acknowledging NOT-MET criteria plainly, and the draft lands in the signature queue. An honest gap is worth more than a confident guess: it tells staff what to go and get.

Validation & metrics

Quantitative: drafts-signed acceptance rate on Model monitoring; authorization approval and appeal overturn rates; time from criteria evaluation to submission. Qualitative: whether staff trust the NOT-MET verdicts enough to act on them rather than re-checking the chart by hand.

Assumptions & constraints

The payer's criteria must be supplied — pasted policy text is treated as data, never as instructions. Drafting is audited (ai.query, ai.draft_created) and the signature rule holds the letter until a clinician signs.

2.3 Documentation gaps — the coding integrity model

Problem

Documentation and coding drift apart in both directions: conditions the record demonstrates but nobody coded, and money billed with no clinical note to support it. Tools exist for the first direction because it pays. A tool that only finds revenue is upcoding with better branding, and it leaves the compliance exposure — the billed line with no note — entirely unexamined.

Persona & context

Coders, CDI specialists and compliance staff with claims:read (the chart audit additionally requires patient:read, because reading the note is the point).

Solution & value

Registry entry Coding integrity model (classifier, slot coding) reads both directions: charts whose own results support an uncoded diagnosis (A1c ≥ 6.5 with no diabetes coded; eGFR < 60 twice with no CKD; sustained hypertensive pressures with no hypertension), and billed lines with no clinical note in a ±45-day window. Findings carry their evidence and become drafted clinician queries.

Validation & metrics

Quantitative: finding counts and backlog by direction on Model monitoring — and the ratio between them, which is the integrity measure: a deployment where the revenue direction vastly outpaces the compliance direction is being used selectively. Query response and agreement rates. Qualitative: whether clinicians find the queries answerable, since an unanswerable query is documentation burden with extra steps.

Assumptions & constraints

The model never changes a code or a note; every finding becomes a query a human answers. Assumes the ±45-day window matches the organization's documentation practice — a configurable that should be set, not inherited.

2.4 Release of information — the requirements validator

Problem

A release of information is a legal determination made under production pressure by staff who are not lawyers, against requirements that vary by jurisdiction and by the kind of content being released. The failure is asymmetric and irreversible: an over-release cannot be recalled.

Persona & context

HIM and ROI staff holding roi:manage, working a queue of requests from patients, insurers, attorneys and other providers.

Solution & value

Registry entry ROI requirements validator (classifier, slot roi) validates every request against the configured requirements of the applicable jurisdiction — federal authorization elements (signature, expiration, scope specificity, revocation language, Part 2 consent) plus the state rules counsel configures. Verdicts are met / UNMET / needs-review, each with its citation. A hard unmet requirement makes Fulfil a recorded refusal naming the requirement (roi.refused). The asymmetry is the design: the validator can block a release and can never approve one — the human decision remains the release.

Validation & metrics

Quantitative: validation and block rates on Model monitoring; refusals by requirement, which names the recurring defect in incoming requests; over-releases, where the target is zero and any non-zero result is an incident rather than a metric. Qualitative: whether staff can explain a refusal to the requester using the citation the validator produced.

Assumptions & constraints

Every evaluation is recorded (roi.requirements_evaluated). Patient-access requests are evaluated under the access right, not the authorization rules. Unconfigured jurisdictions fail closed to human review. Assumes counsel configures the state rules — the platform supplies the mechanism, not the legal position.

2.5 Sensitive categories — the classifier, in the open

Problem

Part 2, HIV, reproductive and mental-health records carry handling rules stricter than the rest of the chart, and they arrive mixed into ordinary feeds with nothing marking them. Classification has to happen at the door, and it will sometimes be uncertain — a missed Part 2 record is the most consequential error this platform could make.

Persona & context

HIM and privacy staff holding sensitivity:view, reviewing what the classifier could not decide — a queue that exists because the alternative is a silent guess.

Solution & value

Registry entry Sensitivity classifier (classifier, slot segmentation) classifies every incoming condition, medication and document at the ingestion door, and manages its uncertainty in the open: thin-evidence classifications queue for human review and uncertain content stays withheld — fail closed. The review queue is the feature, not a footnote.

Validation & metrics

Quantitative: queue depth and reclassification counts on Model monitoring; precision and recall against a human-adjudicated sample, reported separately per category because the cost of a miss is not uniform across them; time-to-review on the queue, since fail-closed content is invisible to care while it waits. Qualitative: reviewer agreement, and whether the evidence shown is enough to decide without opening the source.

Assumptions & constraints

Every confirm/clear decision is audited (segmentation.reclassified). Fail-closed is a deliberate trade: withheld-but-reviewable beats released-and-wrong, and it costs availability. Assumes a reviewer exists — the queue is a commitment, not a buffer.

3. Population

3.1 Cohort builder

Problem

Population questions — how many patients have this condition, is this program worth running, is this study feasible here — get answered today by exporting a patient list and counting it. The count was the question; the list is a disclosure nobody needed to make.

Persona & context

Analysts, HIM and administrators holding analytics:query, usually early in a decision when the answer is a go/no-go rather than a care action.

Solution & value

A condition query returns a count with a composition breakdown by sex, age band and payer. The value is that the identity disclosure never happens, because the query path cannot return identities at all — "who are they?" is not a harder question on this plane, it is an impossible one.

Validation & metrics

Quantitative: query volume via analytics.query; the count of identity exports that did not happen — measurable as the decline in ad-hoc list extracts once this exists, which is the actual privacy outcome. Qualitative: whether analysts stop asking for a list.

Assumptions & constraints

Counts-never-lists is structural, not a setting. Small cells are suppressed so a count cannot be walked back to a person. Assumes the questions really are population questions — a workflow that genuinely needs the individuals belongs on the clinical plane, with its disclosures.

3.2 No-show risk

Problem

Missed appointments waste clinical capacity and hurt most the patients who miss them. Outreach budgets are finite, so they get spread evenly — which sends reminders to people who would have come anyway and misses the people who needed transport.

Persona & context

Scheduling and outreach staff with patient:read, planning a week of clinics against a fixed outreach capacity.

Solution & value

An additive, transparent score over the real record — time since last seen, visit-history depth, age band, coverage — with every point printed next to it. A risk score nobody can inspect is a rumour, so this one shows its arithmetic and its subgroup performance (§6.2).

Validation & metrics

Quantitative: calibration against realised attendance; arrival-rate lift among contacted high-risk patients versus an uncontacted control — the only measure that shows outreach worked rather than that the score was correct; subgroup burden, which must not concentrate. Qualitative: whether staff can explain to a patient why they were called.

Assumptions & constraints

The permitted intervention is support — reminders, transport, double-texting — never denial of scheduling. A model whose burden concentrates on a protected group fails the fairness screen before deployment. Assumes attendance history is recorded accurately; a clinic that does not mark no-shows trains this on noise.

3.3 Scheduling optimization

Problem

Templates and overbooking are set from habit and defended by anecdote. Optimising them purely for utilisation pushes the cost of a full clinic onto whoever waits longest — and that burden is rarely distributed evenly.

Persona & context

Operations and clinic managers with analytics:query, planning capacity a season at a time.

Solution & value

A real hour-demand curve and no-show-weighted overbooking maths, run under explicit fairness constraints, with the constraint shown holding rather than asserted.

Validation & metrics

Quantitative: utilisation and overtime against baseline; wait-time distribution by subgroup, not just its mean — a mean that improves while a subgroup's tail worsens is a regression this metric is designed to catch. Qualitative: whether front-desk staff recognise the modelled day as their day.

Assumptions & constraints

Overbooking burden is a fairness surface; the optimiser's constraints require that cost not to concentrate on protected groups. Assumes historical demand predicts future demand — false after a service line changes, which is when the model should be re-fit rather than trusted.

3.4 Trial pre-screening

Problem

Feasibility questions for a study — is there a population here at all — are answered by handing study staff a patient list, which is a disclosure made for a question that was only ever about numbers.

Persona & context

Research and study staff with patient:read, assessing whether a protocol can run at this site before anyone is approached.

Solution & value

Protocol criteria evaluate on the de-identified plane. Study staff receive counts and eligibility breakdowns with the criteria evidence, never identities. Consent-to-contact remains a clinical workflow the platform deliberately does not shortcut.

Validation & metrics

Quantitative: analytics.query volume; screening yield — the share of pre-screened-eligible patients who prove eligible on clinical review, which measures whether the criteria translated faithfully. Qualitative: whether study staff accept counts as the answer instead of asking for the list anyway.

Assumptions & constraints

Criteria must be expressible against coded data; free-text-only criteria will under-screen, and saying so is better than a confident under-count. The platform does not contact patients.

3.5 Quality measures

Problem

eCQM abstraction is done by hand or by a black box. Both fail the same audit question — show me why this patient is in the numerator — and the answer arrives months after the submission.

Persona & context

Quality and reporting staff with claims:read or analytics:query, working to a submission deadline.

Solution & value

Numerators, denominators and exclusions computed from the record, with every measure element traceable to its source record — so an abstraction is defensible in an audit rather than merely reproducible.

Validation & metrics

Quantitative: agreement with manual abstraction on a sample; the share of measure elements with a resolvable source citation, where anything under 100% is the finding; submission acceptance rates. Qualitative: whether an auditor can follow a single patient from measure to record without help.

Assumptions & constraints

Submissions leave through the streaming export manager (§4.5) on an acknowledged feed. Assumes measure definitions are current — a specification change is a code change, not a configuration change.

3.6 Ingest & mapping QA

Problem

Terminology mapping fails quietly. An unmapped source code becomes an absent finding, and absence looks identical to health — so the damage surfaces downstream, in a cohort that is wrong for a reason nobody can see.

Persona & context

Integration and data-quality staff with report:read, usually after an interface change or a new source system.

Solution & value

Deterministic integrity rules sweep the whole corpus — unmapped source codes, mapping confidence, orphaned references — and a review queue holds low-confidence matches. An AI reviewer summarises likely root causes and what to fix first. The value is that mapping debt becomes visible debt.

Validation & metrics

Quantitative: unmapped-code count and rate by source; review-queue depth and age; flagged-row counts by rule over time, where the trend matters more than the level. Qualitative: whether root-cause summaries lead to interface fixes rather than to per-record corrections.

Assumptions & constraints

A low-confidence mapping is queued for a human, never silently accepted. Results are cached hourly, so the screen is a recent picture and says so.

3.7 Imaging worklist & AI read

Problem

Studies wait for a reader, and the wait is invisible until someone asks. Meanwhile "AI imaging" in most products means a template that describes what a study of this type usually shows — which is not a reading, and is most confident exactly where it is least useful.

Persona & context

Clinicians and imaging staff with patient:read, triaging a worklist by modality, body site and report status.

Solution & value

The study viewer's AI read sends representative frames of the series to the registry's imaging-slot vision model — a genuine inference over the pixels. The model is not told where a finding is; it describes what it can see, measures discrete findings from the burned-in acquisition scale, and drafts a structured report (TECHNIQUE / FINDINGS / IMPRESSION) that files to the signature queue. One read per study, cached for every later viewer.

Validation & metrics

Quantitative: model.inference per read; agreement with the signing radiologist's final report; measurement error against known geometry; unread-report backlog and time-to-read. Qualitative: whether readers treat the draft as a starting point rather than a verdict.

Assumptions & constraints

Representative frames are a sample, not the series — a finding outside the sampled frames will be missed, and the read says so rather than implying coverage. Never diagnostic on its own authority: it drafts, a licensed reader signs. On this demonstration site the frames are synthetic phantoms and the read says so in its own text.

3.8 Data Store

Problem

"What is actually in this system right now?" is a question most platforms answer with a diagram from the implementation project. Nobody can check it, so nobody does — until an auditor asks and the answer has to be assembled by hand.

Persona & context

Public to every role, because it shows aggregates and never records — the honest posture for a page whose whole purpose is to be checkable.

Solution & value

Every table with row counts and date ranges, plus integrity checks run on load: orphaned references, encounter linkage, sensitivity-classification coverage, duplicates, the psychotherapy separation invariant, and full audit-chain verification. A failing check renders as a failure.

Validation & metrics

Quantitative: integrity-check pass rate on every load; audit-chain verification result, which is binary and computed live rather than asserted; classification coverage as a percentage of records. Qualitative: whether a reviewer can answer their own question here instead of filing a request.

Assumptions & constraints

Checks run on page load, so the page costs real query time on a large corpus — the deliberate trade for numbers that are true at the moment they are read rather than true last night.

4. Integration

4.1 Source & target EMRs

Problem

Integrations are configured against what a vendor's documentation promises, and fail against what its API actually does. The gap surfaces in production, usually as a write that silently never lands.

Persona & context

Administrators holding admin:config, standing up or changing a connection.

Solution & value

Each supported vendor is registered with its real seams in view — auth method, bulk capability, write surface — so a configuration is made knowing the vendor's actual limits rather than discovering them later. Source and target are two independent registrations, because reading from one system and writing to another is the normal case, not the exception.

Validation & metrics

Quantitative: config.changed on save; connection test outcomes; the count of downstream refusals that name a vendor seam, which should fall as configuration improves. Qualitative: whether an administrator can predict what will fail before trying it.

Assumptions & constraints

The posture shown must match what conformance (§6.5) verified; a claimed capability that has not been tested is what makes an export manager's refusal look arbitrary.

4.2 Bulk import manager

Problem

Population-scale ingestion runs for hours and fails in the middle. The dangerous outcome is not the failure — it is a run that half-succeeded and advanced its watermark, so the missing records are never requested again.

Persona & context

HIM and administrators monitoring with integration:view; administrators starting runs with admin:config.

Solution & value

History shows each run — started, finished, source, group, status, record count, notes. A kickoff runs the vendor flow (kickoff → poll → download → encrypt-store-index) and the watermark advances only on a clean run. An interrupted run is failed, never partially complete.

Validation & metrics

Quantitative: run success rate and duration; records delivered against records expected; watermark continuity, where any gap is an incident; refused kickoffs (bulk.refused) inside the vendor's 24-hour window, which prove the limit is respected rather than discovered. Qualitative: whether operators trust the watermark enough not to re-run "just in case".

Assumptions & constraints

The System Administrator's hold-release override exists and is audited (system.hold_released) — the escape hatch is available and never quiet. Assumes the vendor honours its own rate limits.

4.3 Streaming data (inbound)

Problem

Real-time feeds go down, and the failure mode that matters is the silent one: processing resumes from "now" and the outage window is simply missing, with nothing in the record to say so.

Persona & context

Integration staff with integration:view, watching ADT, ORU results and 835 remittance feeds.

Solution & value

Per-partition checkpoints, with the gap between acknowledged checkpoint and latest offset surfaced with its exact range. Processing resumes from the checkpoint after an outage — nothing skipped, nothing interpolated.

Validation & metrics

Quantitative: checkpoint lag per partition; gap ranges and their duration; messages processed against messages produced. Qualitative: whether an outage produces a stated range rather than a shrug.

Assumptions & constraints

A gap is never interpolated — an estimated record is worse than an absent one that is named. Assumes the source retains messages long enough to replay from the checkpoint; beyond that retention the gap is permanent and should be reported as such.

4.4 Bulk export manager

Problem

Records leaving in bulk is where a privacy programme is actually tested. The failure is not usually malice; it is a Part 2 record riding along inside a routine production because nothing checked at the door.

Persona & context

Administrators and HIM with integration:export, delivering to target EMRs, HIEs, registries and ROI productions.

Solution & value

A run names scope, destination and format, passes the consent & redisclosure gate, and delivers on the destination's write surface. History shows all three outcomes: complete with records-delivered and records-withheld counts, failed when the destination rejects, and refused when the gate says no.

Validation & metrics

Quantitative: export.completed / export.refused; withheld counts per run, which should never be zero on a mixed population; redisclosure refusals by category. Qualitative: whether a refused production is understood as the system working rather than as an obstacle to route around.

Assumptions & constraints

Psychotherapy notes never export. Part 2 content refuses redisclosure without Part 2-specific consent. Sensitive-category exclusions are counted, never silent. A destination with no bulk write surface refuses with the seam named.

4.5 Streaming export (outbound)

Problem

Outbound obligations — ADT notifications, results to the portal, claims to the clearinghouse, measure submissions — fail at the destination, and a queue that silently drops or silently regenerates turns a delivery problem into a data-integrity problem.

Persona & context

Integration staff with integration:export, accountable for obligations with regulatory teeth (the CMS Condition of Participation among them).

Solution & value

Each feed tracks acknowledged versus produced sequence; the difference is the held backlog, stated rather than inferred. Three honest states: healthy (delivering), held (destination failing — queued and accounted, retried without regenerating or skipping), paused (a governance decision from the Control panel — accumulates, does not leak).

Validation & metrics

Quantitative: acknowledged-vs-produced gap per feed; time in held state; zero regenerated or skipped sequence numbers, which is the integrity invariant. Qualitative: whether a paused feed is understood as accumulating rather than as off.

Assumptions & constraints

The research feed carries no identifiers by construction, not by filter. Assumes destinations acknowledge — a destination that accepts without acknowledging cannot be distinguished from one that silently drops.

5. System

5.1 Control panel

Problem

Administrative power in clinical systems tends to be both scattered and unlogged: the switch that changes what a model does lives in a config file, and the record of who threw it lives in someone's memory. Full control quietly becomes exemption from the accountability everyone else has.

Persona & context

The System Administrator — the one profile holding system:admin — usually acting under time pressure during an incident, which is exactly when an unlogged change is most tempting and most damaging.

Solution & value

One seat for everything: system status with a live full-chain audit verification on every load; the capability deck and per-model panels (§5.2); live controls (bulk-hold release, feed pause/resume); the users-and-roles matrix with each profile's exact permissions; platform configuration; and the recent administrative-action log. Full control is not exemption — every switch writes a system.* event under the administrator's own name.

Validation & metrics

Quantitative: administrative actions per week by actor; zero configuration changes reaching production without a system.* event, which the chain can prove; audit-chain verification result on every load. Qualitative: whether an administrator can reconstruct last week's changes without asking a colleague.

Assumptions & constraints

Assumes the administrator role is held by few people — the log is a deterrent and a reconstruction aid, not an approval workflow. Nothing here validates a model clinically.

5.2 Model management & registry

Problem

"Which models are running here, on what, since when?" is usually unanswerable, because the AI inventory is a slide and the real inventory is scattered across services. Governance frameworks assume an inventory exists; mostly it does not, and the ones that do cover only the language models — leaving the classifier that fences sensitive records unregistered.

Persona & context

The System Administrator, plus whoever must answer an oversight committee. The context that matters: the answer has to be current, not a document that was true at go-live.

Solution & value

The registry holds every model the platform runs — any kind, not only LLMs: the assistant's language models, the no-show risk model, the sensitivity classifier, the scheduling optimiser, the terminology mapper. Bring your own: register an LLM by provider and model ID, or any other model by its HTTPS inference endpoint. The lifecycle is registered → enabled → activated into its slot, each step its own audited decision.

Validation & metrics

Quantitative: registered models against models observed making inferences — a discrepancy is shadow AI and the metric exists to find it; lifecycle events (system.model_registered / _enabled / _disabled / _activated / _removed); time from registration to activation. Qualitative: whether an oversight committee accepts the registry as the inventory rather than asking for a spreadsheet.

Assumptions & constraints

Non-TLS inference endpoints are rejected at registration. The fairness screen applies to any predictive model before it serves patients. The three assistant models carry richer panels — PHI RAG's retrieval switch (off means the assistant refuses to read the Data Store at all and says so), the foundation model's provider and live-calls switch (off degrades to the scripted fallback, labelled), and the scripted fallback itself, which has no switch deliberately: the platform degrades to something honest, never to silence.

5.3 Model analytics & monitoring

Problem

A model's performance is reported by the model, or by the vendor who sold it, and drift is discovered when someone downstream complains. An unwatched model is an unmanaged one, and the metric that would have caught it is usually computed from the model's own confidence rather than from outcomes.

Persona & context

Administrators with admin:config, reading at a glance — often on a second screen — which is why this surface is dark and instrument-shaped.

Solution & value

Live metrics computed from the Data Store and the audit trail, never self-reported: the denial model's denied-vs-paid score separation and per-band calibration; drafts-signed acceptance for the evidence assembler; finding and backlog counts for coding integrity; validation and block rates for the ROI validator; queue depth and reclassification counts for the sensitivity classifier; question and read volumes for the assistant. Drift is a population-stability index of the input mix against baseline, with the outcome-rate shift beside it.

Validation & metrics

Quantitative: PSI against the conventional thresholds (≥0.10 watch, ≥0.25 act); alert count and time-to-acknowledge; recurrence rate of acknowledged conditions, which is the measure of whether acknowledgement led to a fix. Qualitative: whether an alert changes what someone does, rather than being cleared to tidy the screen.

Assumptions & constraints

Alerts never auto-close: acknowledging is an audited human action (model.alert_acknowledged) and a recurring condition re-fires. Monitoring does not validate a model clinically; the organisation's oversight duties stand.

6. Governance

6.1 Registry & preflight

Problem

Capabilities acquire new powers incrementally — a tool gains a scope, a prompt gains a data source — and no single change looks like the moment the declared scope stopped being true.

Persona & context

Oversight and administrators with report:read to see what was cleared; admin:config to run preflight before go-live.

Solution & value

Every capability declares its scope — what it reads, what it produces, which roles may invoke it — before first use, and preflight checks the declaration against what the capability is about to do. A capability acting outside its declaration is refused at preflight, and the refusal is recorded.

Validation & metrics

Quantitative: capabilities declared against capabilities observed; preflight pass/refuse counts per release; zero capabilities serving without a current declaration. Qualitative: whether a refusal leads to a corrected declaration rather than to a waiver.

Assumptions & constraints

Preflight compares a declaration to behaviour; it cannot tell whether the declaration was wise. That judgement is the oversight committee's.

6.2 Fairness screen

Problem

Aggregate accuracy hides subgroup failure. A model can be right overall and systematically wrong for one group, and averaging is precisely the operation that makes that invisible.

Persona & context

Oversight, quality and administrators with report:read, both before deployment and continuously after.

Solution & value

Calibration and error rates by demographic group, shown rather than averaged away, with small cells suppressed so the screen cannot itself become a disclosure. Gap verdicts against stated thresholds.

Validation & metrics

Quantitative: per-subgroup calibration and error-rate gaps against threshold; number of models blocked from deployment by this screen — a screen that has never blocked anything is either lucky or ornamental; suppressed-cell counts. Qualitative: whether the screen is consulted before deployment or cited after an incident.

Assumptions & constraints

The screen is an instrument, not a verdict: it makes underperformance visible before deployment and keeps it visible during. Assumes demographic data is recorded and accurate — a subgroup that is not recorded cannot be screened for, which is itself a finding worth surfacing.

6.3 Ambient consent gate

Problem

Recording-consent law varies by jurisdiction and by modality, and a telehealth visit can put the parties in two states with different rules. A product that records first and reasons later has already created the exposure.

Persona & context

Clinicians with consent:review and the compliance staff who configure the rules, at the head of a visit when the decision must be immediate.

Solution & value

The verdict is keyed on jurisdiction and modality, denies by default, and distinguishes a registration-packet consent from a visit-level attestation captured at the head of the recording. The decision happens before any recording exists.

Validation & metrics

Quantitative: consent.evaluated with verdict per evaluation; denial rate by jurisdiction and modality; zero recordings existing without a permitting verdict, which the trail can prove. Qualitative: whether clinicians understand a denial as a rule rather than as a malfunction.

Assumptions & constraints

Denies by default, so an unconfigured jurisdiction blocks rather than guesses. Assumes the jurisdiction table is maintained with counsel — the gate is exactly as current as its rules, and a stale table fails toward refusal rather than toward exposure.

6.4 Source attributes

Problem

When a record looks wrong, the question is where it came from — and provenance is usually reconstructed by interviewing whoever remembers the interface project.

Persona & context

HIM, integration and quality staff with patient:read, investigating a specific record.

Solution & value

Which source system, which run and which mapping produced each record class, so any record's lineage traces to an ingestion event.

Validation & metrics

Quantitative: share of records with complete provenance — anything short of total is the gap; time-to-answer for a "where did this come from" investigation. Qualitative: whether investigations end here rather than starting here.

Assumptions & constraints

Provenance is only as good as what the source declared; a system that does not identify its runs limits the lineage to where the trail actually starts, and the page shows that boundary rather than inventing past it.

6.5 EMR conformance

Problem

Vendor capability claims and vendor behaviour differ, and every downstream refusal that cites a missing write surface looks arbitrary unless someone actually tested it.

Persona & context

Integration staff and administrators with integration:view, before and after vendor upgrades.

Solution & value

The verified capability posture of each connected vendor — what its API actually supports, tested rather than assumed. This is what keeps the import and export managers' refusals honest.

Validation & metrics

Quantitative: conformance run recency per vendor; drift between claimed and verified capability; count of downstream refusals traceable to a verified seam. Qualitative: whether a vendor conversation starts from evidence instead of from a disagreement.

Assumptions & constraints

A posture is true as of its last run; vendors change APIs, so recency is part of the reading and is shown.

6.6 Retention

Problem

Records are kept forever because deleting them is frightening, or deleted on a schedule that ignores a legal hold. Both are failures; the second is unrecoverable.

Persona & context

The Disposition role with retention:read, working a queue of what is due against schedules the organisation set with counsel.

Solution & value

Schedules by record class drive a disposition queue of what is due, evaluated against the real corpus. Disposition is a recorded human decision, and legal holds override schedules.

Validation & metrics

Quantitative: queue depth and age; dispositions executed against dispositions proposed; zero records disposed under an active hold, which is the invariant that matters. Qualitative: whether the queue is worked or allowed to accumulate — an ignored queue is the same as no schedule.

Assumptions & constraints

The platform never deletes on its own authority; it proposes and records. Assumes schedules and holds are maintained — this executes policy, it does not author it.

6.7 Audit

Problem

Audit logs are written to be stored, not read: they capture too little to answer a question or so much that the answer cannot be found, and they are usually editable by whoever runs the database.

Persona & context

The Auditor role with audit:read, answering a specific question about a specific access.

Solution & value

Events with timestamp, actor (shown by their proper name), action, object reference, purpose and chain position — append-only and hash-chained, so altering history breaks the chain visibly.

Validation & metrics

Quantitative: chain verification result, computed live; events per action type; time-to-answer for an access investigation. Qualitative: whether an auditor can answer without a database query.

Assumptions & constraints

The screen reads; nothing edits — there is no edit surface to gate. Content is never in the log, so audit review is not itself a disclosure event. Assumes clocks are trustworthy: chain order is structural, wall-clock time is evidentiary.

7. Cross-cutting features

7.1 Purpose of use

Problem

Purpose of use is usually a login-time dropdown, which makes it a formality: one claim covering an entire session of unrelated work.

Persona & context

Everyone, on every action that moves data.

Solution & value

Integrated into each workflow, never a session mode: the assistant asks per question, an ROI request carries its own recorded purpose through every resolution, signature commits are treatment by definition, and reads default from the role doing the work. The claimed basis is recorded on the specific event it justifies.

Validation & metrics

Quantitative: purpose distribution per role — a role whose reads are 100% one purpose is either narrow or not really asserting; share of data-moving events carrying a purpose, where the target is all of them. Qualitative: whether the selection is considered or reflexive.

Assumptions & constraints

A purpose is an assertion by a person; the platform records it and scopes by it, and cannot verify the claim's sincerity — which is precisely why it is recorded per action rather than per session.

7.2 Role switching (evaluation deployments)

Problem

Evaluating a role model requires seeing it from inside several roles, and standing up enterprise sign-on for an evaluation costs more than the evaluation.

Persona & context

Evaluators and reviewers on a non-production deployment.

Solution & value

The persona menu switches among profiles instantly — an affordance replacing enterprise sign-on. Every action is still attributed to the persona shown, and switching keeps you on the screen you were reading; if the new role may not see it, that screen refuses, which is the role model demonstrating itself where a silent bounce would hide it.

Validation & metrics

Quantitative: session.persona per switch; refusals encountered immediately after a switch, which is the evaluation working. Qualitative: whether evaluators discover the boundaries themselves rather than being told about them.

Assumptions & constraints

Evaluation deployments only — production identity comes from the organisation's directory. A stale persona from an older session falls back to the least-privileged default.

7.3 Documentation (this menu)

Problem

Documentation about how a system governs data is usually available only to the people who run it, which excludes everyone the governance is supposed to protect.

Persona & context

Every role, plus anyone evaluating the platform.

Solution & value

System documentation, this feature reference, API details, the animated architecture and data-flow diagrams, and the compliance map — public by design. How the platform governs data is not a secret from the people governed by it.

Validation & metrics

Quantitative: documentation views by section; assistant questions that the documentation already answers, which is a content gap rather than a user failure. Qualitative: whether reviewers arrive already understanding the role model.

Assumptions & constraints

Sections a role cannot use are not offered, and a direct URL to one refuses — the documentation obeys the role model it documents.

7.4 The refusal, everywhere

Problem

Governance controls are invisible when they work, so they get optimised away — nobody defends a control they have never seen do anything.

Persona & context

Everyone, constantly, usually without noticing it.

Solution & value

The platform's signature feature is the one it shows most often: the recorded refusal. A 403 naming its missing permission, an export history with a refused row, a rate-limited kickoff, a withheld-records count on a chart — each is governance working in the open.

Validation & metrics

Quantitative: refusal counts by type over time. The unusual property of this metric is its direction: a rate falling toward zero is a warning, not a win — it means either the population stopped containing sensitive records or the gates stopped firing, and only one of those is good news. Qualitative: whether people read a refusal as the system working.

Assumptions & constraints

Refusals must stay legible: a refusal that does not name what it refused and why trains people to route around it. If the refusals ever stopped appearing, that would be the finding.

Companion pages: system documentation for the role matrix and event catalog, API details for the calls behind these features, and data flow diagrams for the animated journeys.