Separate Medical flavor
Medical builds use separate product identifiers, app names, local storage names, backend headers, Medical legal URLs, and Medical backend defaults.
DictaFlow Medical Security Overview
DictaFlow Medical separates clinical workflows from the consumer product and adds HIPAA-oriented controls for provider routing, local data protection, audit metadata, support handling, and legal links.
Provider allowlist
The Medical backend can require BAA-covered providers and fail closed when a transcription or formatting route is not in the approved provider allowlist.
Local data protection
Medical desktop builds treat history, notes, selected text, prompts, dictionary entries, snippets, credentials, and retry audio as sensitive local app data.
Audit and disclosure metadata
Medical backend operations can write metadata-only audit and provider-disclosure records while avoiding raw audio, transcript text, prompts, or dictionary content in those records.
Data minimization
Medical workflows are designed to send only the data needed to perform dictation, transcription, formatting, account, billing, sync, security, or support operations. Production logs and client-facing errors should avoid raw provider payloads, transcript text, selected text, prompts, patient identifiers, and support content that is not needed for operation.
Support and admin access
Support access to customer data should be approved, limited, and logged. Users should not send PHI through ordinary support email or screenshots unless the channel and handling process are approved under the applicable BAA.
Customer responsibility
Customers remain responsible for local device security, OS updates, MDM policy, workstation access, user termination, EHR permissions, and clinical review of all output before it is stored, signed, billed, or used for patient care.
Request more detail
For BAA, security review, or vendor questionnaire requests, contact ryan@dictaflow.io.