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
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.
Patient
controls →
BastCare appconsent · capture · summary · choice
↗Apple servicesSpeech · sign-in
→Bast platformtemporary processing · encrypted relay · evidence
↘CareTeam membersees only what was shared
Visit flow
One simple path from permission to a private summary.
- 1
Ask
Everyone agrees before recording.
- 2
Capture
Audio and Apple Speech stay on the iPhone.
- 3
Summarize
Temporary masked text travels securely for processing.
- 4
Delete exhaust
Temporary audio and transcript text are removed.
- 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, medications, and CareTeam notes.
Components
Each part has one job.
01BastCare iPhone app
Consent, on-device capture, local summaries, encryption keys, sharing choices, and deletion.
02Apple services
Device speech and Sign in with Apple.
03Summary boundary
Authenticated temporary processing with content-free success, failure, timing, and token-count evidence.
04CareTeam relay
Delivers only patient-approved encrypted summary copies and removes access after revocation.
05Metadata ledger
Stores limited operational facts without visit words and records deletion outcomes.
06Model provider
Temporarily turns the requested masked text into a summary response.
Account deletion
Confirm → delete server data → clear the phone.
- Patientconfirms account deletion
- BastCaresends one authenticated request
- Bastrevokes sessions and deletes account-linked auth, relay, and metadata
- Evidencede-links aggregate token counts and records a content-free deletion event
- BastCareclears the iPhone only after success
Accepted decisions
What is already settled
- Demo/staging now. The public HTTPS development environment is approved for demo, staging, and testing. More than 25 users triggers a production-hardening review; it is not a user cap.
- No server transcript archive. Transcript text is transient and never persisted or logged by Bast.
- Explicit sharing. Sharing nothing is valid; every share is patient-selected and revocable.
- Summary is durable. Audio and full transcript are deleted from the iPhone after summary creation.
- Free first. BastCare 1.0 has no purchase or subscription experience. BastCare Plus is reserved for a future release.
- Not a medical device. BastCare organizes and communicates; it does not make clinical claims.
Functional requirements
What the product must do
- Require cloud-processing choice and fresh recording permission.
- Keep audio on-device and purge temporary audio/text after summary persistence or recovery choice.
- Show moving, honest feedback while processing.
- Preview, share, change, and revoke from My Visits with text-first actions.
- Make member removal and rejoining reliable and idempotent.
- Delete the full Bast account across identity, relay, metadata, authorizations, and phone.
- Expose stable Privacy, Support, Terms, Delete Account, and architecture pages.
Non-functional requirements
How it must behave
- Privacy
- No server persistence or logging of visit content.
- Security
- Account isolation, authenticated HTTPS, device-held keys, encrypted relay, least privilege.
- Reliability
- Try Again without silent loss; server success before local deletion.
- Accessibility
- VoiceOver, Dynamic Type, text-first actions, visible focus, 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.
- Reproducibility
- Clean builds, explicit configuration, scans, and release evidence.
Known pre-submission work
Three proof points remain.
- Implement and test the minimum account-deletion endpoint and iPhone success/failure flow.
- Complete App Store privacy disclosures and release metadata.
- Re-run physical-device remove, re-add, re-share, delayed, and offline revocation tests.
StoreKit is deferred to a future BastCare Plus release. The staging decision and 25-user review threshold are settled; they are not current blockers.