Compliance & posture

Built for the OR. Designed to pass the audit.

Diri sits between surgeons and device representatives — two populations that operate under strict, distinct regulatory regimes. This page describes the controls in the current prototype and the gaps we'll close before any non-demo deployment.

Prototype status: this is a working demo, not a pilot-grade system. Items below distinguish what's live from what's on the roadmap.

HIPAA posture — no PHI

The prototype intentionally contains zero Protected Health Information. Cases use synthetic identifiers (Case #1247, Pt MRN-XXXX-redacted). Surgeon and rep accounts are seeded demo personas.

Pre-pilot we will execute BAAs with Supabase, Anthropic, Twilio, and Vercel; enable PHI-safe logging and encryption-at-rest verification; and add a minimum-necessary policy on what fields surface in AI prompts.

Sunshine Act audit trail

Every rep request, status change, AI tool call, and SMS bridge event is written to an immutable audit_logs table with actor, action, entity, and payload. This is the paper trail a manufacturer would need under 42 CFR §403.904 for any transfer-of-value disclosure tied to a device interaction.

Reps and surgeons do not write to this table directly — it is populated server-side from trusted code paths.

AdvaMed Code awareness

Diri facilitates clinical coordination — confirming loaner tray coverage, relaying technique-guide content, and routing case-prep questions. It is not a promotional channel. Reps cannot push unsolicited offers through the platform; surgeons initiate every interaction.

The AdvaMed Code of Ethics restrictions on entertainment, gifts, and consulting payments are out-of-scope for the platform — Diri carries no financial transfer between parties.

RBAC via Row-Level Security

Authorization is enforced in Postgres, not in app code. Surgeons cannot read other surgeons’ cases. Reps see only requests routed to their assigned rep_company. Coordinators see the cases at their facility. Admins are gated by an explicit profiles.role = 'admin' check.

Every policy is in supabase/migrations/ and reviewable in plain SQL.

FDA UDI alignment (roadmap)

Devices in the catalog are keyed by manufacturer + product name today. Pre-pilot, every device row will carry a UDI-DI (21 CFR §830) so that tray contents are unambiguously identifiable in audit, recall, and adverse-event workflows.

510(k) summaries already in the corpus are sourced from the public FDA database; synthetic-IFU content carries an amber SYNTHETIC badge so demo viewers can tell the difference.

AI scope & disclaimer

Every AI response carries: “AI-generated. Consult your device representative and follow institutional protocols for all clinical decisions. This is not autonomous surgical advice.”

Claude is prompted to refuse autonomous clinical recommendations (e.g., implant selection for a given fracture pattern), to cite IFU/technique-guide sources by section, and to surface when no cited source is available rather than fabricating one.

Pre-pilot security backlog

We track open security and compliance items in the repo's TODO.md and review them before any deployment that handles real surgeon traffic. Items include: framework version pinning, tightened RLS for device documents, inbound SMS rate limiting, and Twilio signature verification against the production host.