HIPAA Voice Agent — Medical AI Scribe

Status: in active private development. Current state: an ambient-scribe web app with a clearly-labeled synthetic demo mode, plus a clinical voice-command intent router (20 ranked intent patterns) wired into a hold-to-talk UI where two intents execute end-to-end and the rest honestly report that they need an EHR/FHIR backend. There is no public deployment, and no independently verifiable compliance posture or clinical pilot yet, so no clinical-use claims appear here.

Healthcare AI is a regulated space; substantive claims (clinical accuracy, PHI handling, FHIR/EHR integration, compliance posture) will only appear here when they are independently verifiable.

What’s Built and Tested Today

The unfinished parts are stated plainly above; what is built is real, tested engineering — the security substrate a healthcare evaluation actually scrutinizes:

• At-rest note encryption — AES-256-GCM via WebCrypto. The encryption helper fails closed (throws) when the encryption key isn’t provisioned, so a note is never written unencrypted by accident.
• Honest intent routing — two intents execute end-to-end; the rest return an explicit “needs an EHR/FHIR backend” instead of pretending an action succeeded.
• An audit trail over sensitive actions, plus a clearly-watermarked synthetic demo mode (no real PHI in the demo path). The trail covers the two endpoints where audio and spoken text leave the system boundary, and the tests assert that the transcript text itself never lands in the audit log.
• Speaker-safe voice output — when the intent router flags a response as PHI-in-audio, it is rendered on screen instead of spoken. Speaking it aloud requires provider mode, which is entered only after a verbal “confirm”, and each mode transition writes an audit row. The microphone is half-duplex: while the system is speaking, the talk key is ignored.
• A claims-regression test that fails if “HIPAA-compliant” reappears as a present-tense property of the code in any shipped artifact. It runs in the repo’s local pre-push gate; hosted CI is disabled on that repo.
• A test suite across the JS and Python surfaces keeps the above enforced.

None of this is a compliance claim — it’s the engineering foundation. The independently-auditable posture and a clinical pilot (below) are what would make the product substantive.

For inquiries, contact us via the SUMequities contact page.

When This Entry Becomes Substantive

The project will move from “under repair” to a substantive surface only when at least one of the following holds:

• An independently auditable compliance posture (HIPAA / SOC 2 / equivalent) is in place, with the audit accessible to interested parties under appropriate NDA, and/or
• A pilot deployment with a real clinical partner is underway and the partner is willing to be referenced.

Until either condition is met, no public-facing claim about clinical use will appear here.