φ(ai) PHI AI
Menu
Clinical workspace
Patients & charts PHI AI assistant Signature queue Ambient documentation Imaging worklist Summarization Inbox triage Patient instructions
Revenue & records
Claims & billing Prior auth & appeals Documentation gaps Release of information Sensitive categories
Population
Cohort builder No-show risk Scheduling optimization Trial pre-screening Quality measures Ingest & mapping QA Data Store
Integration
Source & target EMRs Source patient import Bulk import manager Streaming data Bulk export manager Streaming export
System
Control panel Model monitoring
Governance
Registry & preflight Fairness screen Ambient consent gate Source attributes EMR conformance Retention Audit
Documentation
System documentation Implementation & setup guide Feature documentation System architecture EMR connections Emulators & non-PHI setup Compliance & responsibility Attribution
Ryan GomezRole
Signed in — Ryan Gomez · System Administrator
You stay on this screen — each role sees it as their own permissions allow. The assistant thread and the patient in context start fresh.
Working archetypes — combinations people really hold
One role at a time — each role on its own
DocumentationDocs
System documentation Implementation & setup guide Feature documentation System architecture EMR connections Emulators & non-PHI setup Compliance & responsibility Attribution
Repository

Ingest & mapping QA

Every record that crosses the ingestion door gets audited after the fact: deterministic integrity rules sweep the entire Data Store — every check below just ran against all 33,311 patients — and the AI reviewer reads the findings to argue root causes and fix order. The rules are the authority; the model reasons about what they found and never scores anything silently.

AI core: Ingest QA reviewer v1.0 · llm.analytic · managed in the Control panel · activated from the registry
754,975
clinical rows swept — conditions, meds, labs, encounters, documents
2,091
rows flagged by the integrity rules
2026-08-30 00:18:01
sweep completed · cached one hour

The integrity rules — live results

Rulecondition RowsSample
Condition onset precedes date of birth onset_date < patients.birth_date 0 clean
Condition onset in the future onset_date > today 0 clean
Condition abates before it begins abatement_date < onset_date 0 clean
Encounter ends before it starts ended_at < started_at 0 clean
Numeric result carries no unit value_num set, unit empty ('' or NULL) 0 clean
Observation not mapped to LOINC loinc empty - the mapping table had no target 0 clean
Active medication without dosage text status='active', dosage empty 2,091
MRN-100228 · 24 HR metoprolol succinate 100 MG Extended Release Oral Tablet
MRN-100228 · Abuse-Deterrent 12 HR Oxycodone Hydrochloride 10 MG Extended Release Oral Tablet [Oxycontin]
Document with an empty body body empty after extraction 0 clean
Duplicate MRN (identity collision) same MRN on more than one patient row 0 clean
Condition without a mapped code code empty - source term never mapped 0 clean

A zero is a finding too: it says the mapping held for that rule across the whole corpus. Flagged rows stay in the store — QA quarantines nothing silently; humans decide what a flag means.

✦ AI Reviewer — root causes and fix order

Mapping-pipeline review drafted by claude-sonnet-5 · 2026-08-29 19:35:22 · informs the fix, never applies it
ASSESSMENT
Overall the corpus (33,311 patients / 78,093 conditions / 47,571 medications / 440,889 observations / 150,009 encounters / 38,413 documents) shows a mapping pipeline that is largely intact for coding and identity (0 unmapped condition codes, 0 duplicate MRNs, 0 empty document bodies, 0 unit-less numeric results, 0 unmapped LOINC observations), but has real defects concentrated in **date/time handling on the Condition table** and in **medication dosage-text extraction**. Encounter timing is clean apart from a single outlier. The pattern of errors (future onset dates, abatement-before-onset, onset-before-birth) all point to problems in how date fields are parsed, aligned, or copied during ingest rather than to missing terminology mappings, which are otherwise sound.
LIKELY ROOT CAUSES
1. **Condition onset in the future (1,672 rows, 2.1% of conditions)** — Both samples show onset dates in 2026 for patients with birth dates decades earlier, ruling out a DOB mixup. This is consistent with (a) a synthetic/simulated source clock (e.g., Synthea-style generator) whose internal "now" is ahead of the QA sweep's real-world "today," or (b) an ETL date-parsing fault (e.g., locale mismatch swapping month/day, or a timezone rollover pushing dates past midnight into the next year in edge cases). The scale (>1.6k) suggests a systemic generator/parser issue rather than isolated data entry.

2. **Condition abates before it begins (1,220 rows, 1.6%)** — Sample rows show onset/abatement pairs that look transposed (e.g., onset 2026-08-21 / abatement 2023-11-04). This strongly suggests an onset/abatement column swap for a subset of source records or condition types (likely "resolved" conditions ingested from a source table where the two date columns are ordered differently than assumed by the mapper).

3. **Condition onset precedes date of birth (122 rows, 0.16%)** — Sam

SPEC 5.13, live: deterministic rules over the full synthetic corpus, an audited model run over their output, and no automatic mutation of anything. Synthetic data throughout — no real patients.