Bast

BastCare solution architecture

Small by design. Patient-controlled by default.

This public view explains the people, components, data boundaries, decisions, functional requirements, and quality requirements behind BastCare.

Architecture snapshotSeptember 9, 2026
Take the architecture with you.

Download the public six-page system context, visit lifecycle, CareTeam sharing, deletion, and accountability view.

Download PDF

Context

The patient is in control.

A patient records with everyone’s permission, receives a plain-language summary, and decides whether a CareTeam can see it. BastCare organizes and communicates; it does not provide medical advice.

Visit flow

One simple path from permission to a private summary.

  1. 1

    Ask

    Everyone agrees before recording.

  2. 2

    Capture

    Audio and Apple Speech stay on the iPhone.

  3. 3

    Summarize

    A masked copy travels securely for temporary processing.

  4. 4

    Keep the source

    Audio is removed; the original transcript remains on the iPhone.

  5. 5

    Choose

    Review, regenerate, share, or keep the summary private.

Content boundary: Bast server logs and storage exclude audio, transcript words, prompt and response bodies, summary words, diagnoses, and medications.

Components

Each part has one job.

01

BastCare iPhone app

Consent, on-device capture, local summaries, encryption keys, sharing choices, and deletion.

02

Apple services

Device speech and Sign in with Apple.

03

Summary boundary

Authenticated temporary processing with content-free success, failure, timing, and token-count evidence.

04

CareTeam relay

Delivers only patient-approved encrypted summary copies and removes access after revocation.

05

Metadata ledger

Stores limited operational facts without visit words and records deletion outcomes.

06

Selected AI provider

Anthropic or OpenAI temporarily turns the requested masked text into a summary response.

Which AI does BastCare use? BastCare can use Anthropic or OpenAI models. We match the model to the task and evaluate quality, reliability, speed, and resource use. The provider can change as those needs change; each request goes only to the selected provider.

Account deletion

Confirm → delete server data → clear the phone.

  1. Patientconfirms account deletion
  2. BastCaresends one authenticated request
  3. Bastrevokes sessions and deletes account-linked auth, relay, and metadata
  4. Evidencede-links aggregate token counts and records a content-free deletion event
  5. BastCareclears the iPhone only after success

Design commitments

What you can expect

  1. No server transcript archive. Bast does not persist or log transcript text.
  2. On-device source. The original transcript stays protected with the visit until the user deletes it.
  3. User-controlled regeneration. A new summary remains a preview until the user chooses Use this summary; sharing it again is a separate choice.
  4. Explicit sharing. Sharing nothing is valid; every share is patient-selected and revocable.
  5. Full account deletion. Deleting a Bast account removes account-linked identity, access, encrypted shares, and local app data.
  6. Not a medical device. BastCare organizes and communicates; it does not make clinical claims.

Functional requirements

What the product must do

  1. Ask for cloud-processing choice and fresh recording permission.
  2. Keep the original transcript protected on-device and remove audio after a summary is saved successfully.
  3. Let the patient view or download the transcript and regenerate a summary from it.
  4. Keep regeneration as a preview until the patient chooses Use this summary.
  5. Let the patient preview, share, change, and revoke from My Visits.
  6. Delete a visit with its transcript and summary; delete account-linked server and local app data when the account is deleted.

Non-functional requirements

How it must behave

Privacy
No server persistence or logging of visit content.
Security
Account isolation, secure connections, protected keys, and encrypted sharing.
Reliability
Try Again without silent loss; server success before audio deletion.
Accessibility
VoiceOver, Dynamic Type, text-first actions, visible focus, and no color-only meaning.
Auditability
De-identified usage and content-free events without retaining a deleted identity.
Performance
Immediate feedback; network waits never freeze navigation.