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 snapshotAugust 2, 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

    Temporary masked text travels securely for processing.

  4. 4

    Delete exhaust

    Temporary audio and transcript text are removed.

  5. 5

    Choose

    The summary stays private unless the patient shares.

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

Model provider

Temporarily turns the requested masked text into a summary response.

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. Transcript text is transient and never persisted or logged by Bast.
  2. Explicit sharing. Sharing nothing is valid; every share is patient-selected and revocable.
  3. Summary is durable. Audio and full transcript are deleted from the iPhone after summary creation.
  4. Full account deletion. Deleting a Bast account removes account-linked identity, access, encrypted shares, and local app data.
  5. 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 audio on-device and remove temporary audio and text after the summary is saved.
  3. Show clear progress and recovery choices while processing.
  4. Let the patient preview, share, change, and revoke from My Visits.
  5. Remove a CareTeam member’s access and require a new invitation before access can return.
  6. Delete the Bast account, account-linked server data, and local app data.

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 local 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.