Security model

Patient access starts with verification.

Every caller starts without access to patient information. A one-time code can open only the specific help they need; the conversation itself cannot change that rule.

01 / How we think about risk

Every caller starts as a stranger.

Caller ID can be useful, but it is not proof of identity. Mainline is designed for the possibility that someone may impersonate a patient, provide misleading information, or simply be mistaken.

  • Caller speech cannot grant authorization.
  • Reference documents cannot override privacy or emergency rules.
  • Office staff can update business information, but not locked safety rules.
  • Verified callers receive only the detail needed for the task—not unrestricted chart access.

02 / Patient-data boundary

Four safeguards enforce one rule.

1

Verification belongs to the call

A call becomes verified only after the correct one-time code is entered.

2

Every patient request checks first

If verification is missing or expired, the request stops without returning patient information.

3

Only specific answers are available

Mainline can retrieve details such as the next appointment—not an unrestricted copy of the chart.

4

Patient details use one protected path

That path returns nothing until verification succeeds, regardless of what is said during the conversation.

The useful consequence: callers, reference documents, and editable practice information cannot talk their way around verification.

03 / Caller verification

A code goes only to a contact already on file.

The caller supplies a name and date of birth. The response is deliberately identical whether or not a matching patient exists; confirming the existence of a record can itself reveal patient information.

6 digitsCryptographically random
5 minutesThen the challenge expires
3 attemptsBefore the challenge locks
2 resendsWith cross-call rate limits
  • Codes are stored as salted hashes and compared in constant time.
  • The message contains only the code—no patient name or practice name.
  • SMS and voice are preferred; email is disabled unless the practice explicitly accepts that risk.
  • Every start, send, success, failure, expiry, and rate limit is audited.
Before patient-specific self-service: secure code delivery by text or voice must be connected under the required agreement. Until then, Mainline keeps patient details closed and takes a message or callback request.

04 / Data journey

What stays in the practice—and what does not.

At the practice

Caller audio

The caller’s voice becomes text without leaving the practice.

AWS Bedrock under BAA

Conversation text

Conversation text—not call audio—is processed in the practice’s approved AWS environment.

At the practice

Agent voice

The response becomes speech at the practice and plays back to the caller.

Protected patient details are stored at the practice and can be used only after verified access. The phone provider carries the call, but its recording, transcription, and AI add-ons must remain off.

05 / Storage and audit

Encrypted data. Deliberately boring logs.

Encrypted at the practice

Patient data is stored in an encrypted database. Its key is kept separately, and production units also require full-disk encryption for temporary files and uploads.

A patient-free audit trail

Audit events are limited to approved non-patient details. Anything that looks like patient information is redacted and raises a warning for review.

Backups must also be encrypted and rotated on a schedule. A copied data folder is not readable without its separately protected key.

06 / Retention

Keep the minimum. Delete on schedule.

DataDefaultWhat that means
One-time code challenges24 hours after expiryOnly salted code hashes are stored; codes expire in 5 minutes.
Raw call recordingsOffRecording is not enabled in the shipped configuration.
Call transcripts30 daysCaller and assistant turns; configurable per practice.
Completed intake requests90 days after completionOpen items are not purged.
Audit and security events365 daysDesigned to contain no patient information.

Practices can adjust retention settings after their own review. The shipped defaults favor less raw data and longer retention only for audit events designed not to contain patient information.

07 / Vendors and agreements

Each boundary has its own legal posture.

AWS Bedrock
Used under the practice’s AWS Business Associate Agreement. Bedrock is a HIPAA-eligible service in the configured region.
SIP carrier
Routing-only trunks rely on the conduit posture when recording, transcription, and AI add-ons are off and TLS/SRTP are enforced.
OTP provider
A production SMS or voice provider that handles verification associations requires the appropriate agreement and deployment review.
Mainline support
Mainline becomes a business associate when support can access patient information. A BAA is available as part of onboarding.

Mainline does not present HIPAA as a product certification—because it is not one—and does not claim SOC 2 status it does not hold.

08 / Known limits

Security documentation should include the unfinished work.

  • Production SMS/voice OTP delivery must be configured before protected patient self-service is enabled.
  • TOTP two-factor authentication exists for admins; mandatory MFA for every owner account remains a hardening item.
  • Passkeys/WebAuthn are planned, not shipped.
  • Remote support procedures must avoid patient access or operate under the practice agreement.
  • Recording patient calls requires a separate consent, security, retention, and audit design. It is off.
Bring your lawyer or IT consultant.

We will walk the boundary with them.

Call the demo line