Issue #960 — Procedure Data Quality + Admin UI Audit¶

Date: 2026-05-19 Branch audited from: fix/proxy-review-remaining-procedures (HEAD 494026a) Auditor: automated read-only sweep Scope: state of #960 (MVP procedure coverage, 10 categories end-to-end) vs. prod data, in service of standing up E2E patient-workflow seed data.

Issue #960 was closed on GitHub but the underlying data is only partially complete (matcher + clinical depth wired for the 17 fabricated/Naidu-approved orthopedic/spine/rehab procedures; ICD/SNOMED + LOINC + per-procedure matching overrides + patient fixtures NOT seeded). This audit catalogues what is real, what is fabricated, and what is missing.

1. Issue #960 scope — checklist with status¶

Per the issue body the MVP comprises 10 categories (TKR, THR, bilateral knee, robotic knee, MAKO umbrella, spine bundle, arthroscopy bundle, trauma, rehab, shoulder bundle). Plan was structured into 9 phases.

Overall verdict: the catalog + matching gating side of #960 is largely DONE for the MVP 10. The patient-workflow side (cases, conversations, FHIR, recovery edges, transport flags, per-procedure matcher params) is NOT seeded and is what currently blocks E2E.

2. Postgres inventory¶

All counts pulled 2026-05-19 from Railway service curaway against prod DATABASE_URL.

2.1 Top-level counts¶

2.2 procedure_requirements by metadata->>'data_source'¶

SELECT COALESCE(metadata->>'data_source', '<none>') AS ds, COUNT(*)
FROM procedure_requirements GROUP BY 1;

Note: no rows in PG carry the naidu_approved_claude_proxy_2026_05_1{8,9} marker even though YAML does — the proxy work in YAML has not been re-seeded into PG. See §3 for drift detail.

2.3 procedure_requirements per-row depth (PG today)¶

SELECT procedure_code,
       jsonb_array_length(required_documents) AS rd,
       jsonb_array_length(comorbidity_screening) AS cs,
       jsonb_array_length(contraindications) AS ci,
       jsonb_array_length(keywords) AS kw
FROM procedure_requirements ORDER BY 1;

Observations: - 0 rows have neo4j_slug populated in PG (column is null for all 29 rows) — PG ↔ Neo4j join is name-based, fragile. - Three *_BASE template rows (CARDIAC_BASE, ONCO_BASE, ORTHO_BASE) have no cost / recovery / travel — these appear to be inheritance roots and may pollute the procedure list. - No keywords data for 14 legacy rows in PG — synonym fuzzy match will fail for everything outside the fabricated_pending_ops_2026_05_17 set. - 92920, ONCO-SURG, ONCO-CHEMO, ONCO-RAD, 67228, 67036 exist in YAML but not in PG — see §3.

2.4 providers breakdown¶

SELECT provider_type, country_code, is_active, COUNT(*)
FROM providers GROUP BY 1,2,3 ORDER BY 1,2;

Total: 50 providers (42 hospitals + 8 transport). No metadata column on providers, so data_source tagging is not available at the provider row level — it lives on provider_procedures.metadata.

2.5 provider_procedures by procedure (top 20)¶

data_source split: 132 fabricated, 52 legacy/none.

2.6 doctor_procedures top 20¶

2.7 procedure_capability_requirements — full dump¶

SELECT procedure_code, capability_code, weight, is_blocking FROM procedure_capability_requirements;

Missing capabilities vs. #960 plan: - mako_certified — not present (issue called this out as the canonical tag for MAKO platform). - mri_intraoperative, level_1_trauma_24_7_or, inpatient_rehab_beds_count — not present. - 27447-BIL has no capability requirement despite being a distinct, more complex procedure.

3. YAML vs. DB drift¶

Source: config/procedures.yaml (32 procedures) vs. procedure_requirements (29 rows).

3.1 In YAML but missing from PG procedure_requirements¶

3.2 In PG but missing from YAML¶

3.3 Naidu-proxy depth drift (YAML far richer than PG)¶

For 14 procedures the YAML carries the naidu_approved_claude_proxy_2026_05_19 payload but PG was last seeded under the older fabricated_pending_ops_2026_05_17 profile. Per-field counts (YAML → PG):

The required_documents drift is the most patient-visible regression — Naidu-proxy work in YAML doubles or triples the document checklist, but the current API responses are still serving 2–5 documents per procedure. Re-running seed_procedures.py would close this gap.

3.4 neo4j_slug drift¶

• YAML: every Naidu-proxy procedure carries a neo4j_slug (e.g. acl_repair, scoliosis_correction).
• PG: procedure_requirements.neo4j_slug is NULL for all 29 rows.
• Neo4j: nodes have code (e.g. knee_replacement, acl_repair) and name, no slug.

Cross-store joins are happening on name (or a hardcoded slug lookup somewhere in code). Reseeding from YAML would populate PG neo4j_slug correctly.

4. Neo4j inventory¶

Connected via Bolt URI from railway run. Database GUID 21eea64f.

4.1 Procedure node property keys¶

['anesthesia_type', 'category', 'code', 'complexity', 'max_stay_days',
 'min_stay_days', 'name', 'specialty', 'travel_clearance_days',
 'typical_duration_hours']

No procedure_code field (the issue's CPT code) — Neo4j uses its own code like knee_replacement, acl_repair, scoliosis_correction. The YAML neo4j_slug field aligns with these. There is no foreign key on either side enforcing the join — drift is invisible until lookup time.

4.2 OFFERS edges per procedure (top 25)¶

This is the source of the "1660 providers" puzzle: Neo4j carries a far-larger fabricated provider universe than PG. PG is the source of truth for the matcher / API; Neo4j is being used inconsistently. The matcher's behaviour for the MVP-10 needs to be tested against the PG numbers (7–14 providers per procedure), not the Neo4j 1660s.

4.3 HAS_RECOVERY coverage¶

MATCH ()-[r:HAS_RECOVERY]->() RETURN count(r);  // = 7

Sample (TKR procedure node): Inpatient Recovery, Local Outpatient Rehabilitation, Home Country Follow-up — that's the original 3 phases × 3 procedures totalling ~7 edges. None of the 7 new MVP procedures (bilateral knee, robotic, spine, arthroscopy, trauma, shoulder, rehab) have recovery-phase mappings. This is the Phase 6 blocker that #960 + #958 share.

5. Patient-workflow seed gaps¶

End-to-end test of intake → matching → care plan → recovery requires the following entities to exist as realistic seed data. Current state:

5.1 Existing fixture corpus (handy for replay)¶

tests/fixtures/v6_compliance/persona_a/  (golden + demographic_fabrication + doc_trust_fail + emotional_paraphrase + treatment_recommendation)
tests/fixtures/v6_compliance/persona_b/  (golden + late_records_offer + scope_rejection + two_questions_same_axis + voice_violation)
tests/fixtures/v6_compliance/persona_c/  (abrupt_same_cluster + golden_discovery + json_parse_failure + premature_pivot + soft_axis9_two)
tests/fixtures/procedure_coverage/       (acl_repair, bilateral_knee_replacement, cervical_decompression, fracture_fixation, knee_arthroscopy, laminectomy, lumbar_decompression, meniscus_repair, post_surgical_rehab, robotic_hip_replacement, robotic_knee_replacement, rotator_cuff_repair, scoliosis_correction, shoulder_arthroscopy, shoulder_replacement)

These are JSON conversation transcripts with expected_scores.yaml — designed for the v6 LLM grader, not for E2E API replay. They cover 15 of the 32 procedures but bypass the DB writes entirely.

6. Recommended next actions (prioritised)¶

P0 — blocking E2E patient workflow tests¶

1. Seed a patient-case fixture set into PG. Need at least 5 personas × {case, ≥1 conversation, ≥3 messages, 1-2 fhir_resources (DocumentReference + Observation), 1 procedure interest, expected match outcome}. Add a seeder script app/seeds/seed_patient_journeys.py or extend seed_procedures.py. Tag with data_source: 'fabricated_e2e_test_2026_05_19' so it can be filtered out of prod views and dropped cleanly.
2. Re-run seed_procedures.py against prod to close the YAML → PG drift on required_documents, keywords, and neo4j_slug for the 14 Naidu-proxy procedures (§3.3). Doubles the document checklist patients see.
3. Insert the 6 missing PG rows for 92920, 67228, 67036, ONCO-SURG, ONCO-CHEMO, ONCO-RAD (§3.1). YAML payloads exist; one seed run should fix.
4. Seed HAS_RECOVERY edges in Neo4j for the 7 new MVP procedures (bilateral knee, both robotic, the spine bundle, fracture fixation, shoulder bundle, REHAB-POSTOP-001). Without this the recovery card returns empty for 7 of 10 MVP procedures.
5. Inactivate or delete *_BASE rows in procedure_requirements (CARDIAC_BASE, ONCO_BASE, ORTHO_BASE) — they leak into /api/v1/procedures and confuse the storefront list.

P1 — should-have before declaring #960 truly closed¶

1. Add mako_certified capability + tag MAKO-hosting providers (issue called this out explicitly).
2. Decide on the orphan codes 47135 (liver transplant), 15830, 27487, 96413 — either add YAML rows or remove from provider_procedures / doctor_procedures.
3. Populate procedure_requirements.neo4j_slug from YAML so cross-store joins stop being name-based.
4. Wire per-procedure matching overrides (config/matching/parameters/*.yaml procedure_overrides block from Phase 5 of #960). Without it the matcher still uses 147 global params for trauma vs. cataract.
5. Add a per-procedure LOINC test-gating layer in procedure_capability_requirements (or a new procedure_test_requirements table) — TKR currently shares its lab panel with cardiac.
6. Reconcile Neo4j Provider universe (1660 nodes) with PG (50). Either trim Neo4j to the real 50 or document why the larger fabricated graph exists.

P2 — polish¶

1. Add a data_source column directly to procedure_requirements and providers (currently has to be probed via metadata->>'data_source') — gives ops a queryable filter.
2. Backfill keywords for the 14 legacy procedures (rd column shows kw=0 for 22612, 27130, 27447, 30400, 33405, 33533, 43775, 58970, 66984, BMT-001, CARDIAC_BASE, D6010, ONCO_BASE, ORTHO_BASE).
3. Naidu real sign-off (issue #169) — replaces all naidu_approved_claude_proxy_* markers with naidu_approved_2026_*.
4. Decommission orphan CPT codes 96413, 27487, 15830 from doctor_procedures / provider_procedures after deciding the canonical catalog.

Appendix A — queries used¶

# Run via: railway run --service curaway -- python3 -c "<below>"
import asyncpg, asyncio, os, json
async def main():
    url = os.environ['DATABASE_URL'].replace('postgresql+asyncpg://', 'postgresql://')
    conn = await asyncpg.connect(url)
    # See queries inline in section bodies above.
asyncio.run(main())

Neo4j queried via neo4j Python driver using NEO4J_URI, NEO4J_USER, NEO4J_PASSWORD from the Railway env.

YAML compared via:

import yaml
with open('config/procedures.yaml') as f:
    procs = yaml.safe_load(f)
# enumerate procedure_code, required_documents, ... and diff against PG depth output