On-device processing and de-identification, by design
Capture, extraction, and de-identification are designed to run locally, inside the clinician's device environment. Before content moves to central systems, identifiers such as names, dates, phone numbers, and record numbers are replaced with tokens, so what travels is structured, tokenized clinical content rather than raw patient identity.
One limit, stated plainly: tokenization reduces exposure, but tokenized data is not automatically anonymous, and we do not describe it as anonymized.
See it yourself
The demo's final slide lets you drag the edge shield across a patient snippet and watch identifiers become tokens — the boundary the workflow is designed to enforce on every encounter. Watch the demo.
Audit trail
Clinician edits, approvals, and signatures are recorded in an audit trail that shows which element changed, who changed it, and when — the record a compliance review asks for.
Role-based access
- Clinicians work with their patients' documentation and sign it.
- Coders see the signed note and its coding rationale.
- Administrators see operational volumes, turnaround, and queues — role-based access is designed to keep patient text, names, transcripts, and audio outside the administrator's view.
Regulatory framing — alignment is not certification
The architecture is designed with HIPAA and India's DPDP Act requirements in mind, and with interoperability over FHIR, HL7 v2, and C-CDA. Architectural alignment is not a certification, an audit result, or a legal determination of compliance, and we do not claim any of those. Formal security and compliance assessments are scoped with each partner before any production deployment.