HIPAA Architecture Brief

Version: 1.1 Effective date: 2026-05-18 (initial 2026-05-07) Vendor: Sapience Systems LLP, an English limited liability partnership (LLP No. OC454938), registered office at Stoney Works, 8 Stoney Lane, London SE19 3BD, United Kingdom Product: Sapience Med — offline medical voice dictation Audience: clinic compliance officers, IT security teams, procurement reviewers

1. Purpose of this document

This brief explains the technical architecture of Sapience Med and the resulting HIPAA classification of Sapience Systems LLP. It is intended to be sent in response to a clinic's request for a Business Associate Agreement, vendor security questionnaire, or HIPAA compliance attestation, and to give a compliance reviewer everything they need to make a determination in one read.

2. Bottom line

Sapience Systems LLP is not a Business Associate of any clinic that uses Sapience Med, because the software is architected so that Sapience Systems LLP never creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of the clinic.

This determination is grounded in:

• The plain text of the Business Associate definition in 45 CFR § 160.103
• HHS guidance that a software vendor is not a Business Associate unless the vendor performs a function involving the use or disclosure of PHI
• A code-level security audit (attached as CODE_AUDIT_REPORT.md) verifying that no network path exists in the Sapience Med application by which patient audio, transcripts, or clinical content can leave the clinician's device

If your procurement process nevertheless requires a contract, we offer a Limited-Scope Vendor Agreement that codifies the no-PHI architecture in writing. We do not sign a full Business Associate Agreement, because doing so would misrepresent our actual relationship to your PHI.

3. Legal framework

3.1 Business Associate definition (45 CFR § 160.103)

"Business associate" means... a person who, on behalf of a covered entity... creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter...

Four verbs: creates, receives, maintains, transmits. A vendor whose product does none of the four with respect to PHI is not a Business Associate.

3.2 HHS guidance for software vendors

The U.S. Department of Health and Human Services, Office for Civil Rights, has stated:

"A software vendor is not a business associate of a covered entity unless the vendor performs a function on behalf of the covered entity that involves the use or disclosure of PHI." — HHS HIPAA FAQ #256

The reference comparators are Microsoft Word and Apple Notes: a clinician can dictate or type clinical notes into either, and neither Microsoft nor Apple becomes the clinician's Business Associate, because the software is shrink-wrapped and the vendor never accesses the content.

Sapience Med is architected to operate in the same lane.

3.3 The "Conduit Exception" is not invoked

Some vendors (cloud storage providers, email forwarders) attempt to claim the narrow Conduit Exception under HIPAA. We do not. The Conduit Exception is irrelevant here because Sapience Med does not transmit PHI at all — there is no transmission to be excepted from. The relevant doctrine is the simpler one above: we are a software vendor that does not touch PHI.

4. Technical architecture (data flow)

The dictation pipeline operates entirely on the clinician's device. Audio, transcripts, and any derived content remain in the clinician's filesystem and process memory. No clinical content is transmitted off the device by the application.

4.1 Dictation flow

[ Clinician holds hotkey ]
        ↓
[ Audio captured to RAM via OS audio API (cpal crate on macOS,
   WASAPI on Windows) ]
        ↓
[ Voice-Activity-Detection (VAD) trims silence ]
        ↓
[ Audio resampled via rubato to 16 kHz mono and passed to
   whisper.cpp running the Whisper-large-v3-turbo Q5 GGUF model
   (≈547 MB), bundled in the installer, loaded from the user's
   local disk, accelerated by Metal on macOS or Vulkan on Windows.
   Never updated from a network source in normal operation. ]
        ↓
[ Post-processing: filler removal, punctuation cleanup,
   drug-name spell correction against a local 21,000-term
   RxNorm/ICD-10 dictionary, user-defined corrections —
   all pure-function transformations, all in RAM ]
        ↓
[ Text written to OS clipboard ]
        ↓
[ Synthetic Cmd+V / Ctrl+V keystroke injects text at cursor in active app ]
        ↓
[ Audio buffer and transcript string drop out of scope and are
   garbage-collected. No file is written. No clinical content
   is transmitted off the device. ]

4.2 What persists to the clinician's local filesystem

Sapience Med stores six small JSON files in the OS-standard application-data directory (~/Library/Application Support/com.golosflow.clinical/ on macOS, %APPDATA%\GolosFlow Clinical\ on Windows):

These files are local to the clinician's device. They are not transmitted to Sapience Systems LLP at any time. They may contain content fragments derived from the clinician's work (a learned correction may include a patient name's spelling), but they are not PHI in transit; they are PHI at rest on the clinician's own device, which is fully under the clinician's control and the clinician's HIPAA Security Rule obligations.

4.3 What never persists

The application never writes the following to disk in release builds:

• Audio recordings (no .wav or other audio file is created)
• Full transcripts (the dictated text is in clipboard and target application; no transcript history file is kept by Sapience Med)
• Logs containing transcript content (debug-build content logs are gated behind #[cfg(debug_assertions)] and excluded from the release binary by the Rust compiler)
• Crash dumps containing user content (the panic handler writes only the panic message and stack frames to the process stderr; no memory dump file is written)

4.4 Network behavior

The dictation pipeline described in §4.1 contains zero outbound network calls. No part of the path between audio capture and clipboard injection touches the network. This was verified by the most recent code audit (see CODE_AUDIT_REPORT.md):

• No HTTP, WebSocket, gRPC, or raw socket primitives in the audio, transcription, post-processing, or injection source files;
• The Tauri capabilities manifest (capabilities/default.json) grants the minimum set required for the dictation pipeline and license validation; no shell:execute, no fs:write to arbitrary paths;
• The webview Content-Security-Policy is default-src 'self'; style-src 'self' 'unsafe-inline' — the webview cannot fetch off-device resources except to the license-validation endpoint we operate;
• No third-party analytics or telemetry SDKs are linked into the binary.

The application does make two narrow categories of outbound HTTPS calls. Both transmit only operational metadata. Neither transmits PHI, audio, transcripts, dictionary contents, snippet contents, usage statistics tied to clinical content, or anything derived from clinical content.

(a) License validation — active in the current version. The Software periodically calls https://license.sapience.systems/verify to check that the user's license is currently active. The request transmits:

• The license-key identifier (a UUID, not your email);
• A salted one-way HMAC of a stable device identifier (used to enforce per-seat licensing; not reversible to the device's hardware ID);
• The Software version string and OS-architecture string.

The response carries the license status (active, expired, revoked) and a short-lived signed token for subsequent requests. The license-validation endpoint runs on Cloudflare Workers. Its access logs are retained for no longer than 30 days and are not correlated with clinical activity (none exists to correlate).

(b) Update-check — planned for v1.1, not active in the current version. When enabled, the Software will fetch a static JSON manifest from https://releases.sapience.systems/clinical/latest.json. The fetch will transmit only the Software version, the OS-architecture string, and standard HTTP headers (User-Agent, Accept-Language). The update endpoint will not log IP addresses beyond a 24-hour transient window enforced by Cloudflare. No PHI, no clinical metadata, no clinical content reference will be transmitted.

The Tauri auto-updater plugin is not bundled in the current build. Updates are distributed manually via signed downloads from downloads.sapience.systems until (b) ships.

Neither (a) nor (b) changes the Business Associate analysis in §2–§3, because neither transmits PHI or any data derived from PHI.

5. The six conditions that preserve our non-BA status

Sapience Systems LLP commits to maintaining the following six architectural conditions for the Sapience Med product. These conditions are codified in our internal product policy and are visible to anyone reading our public source-of-truth strategy document.

1. Software runs entirely on the clinician's device. No server-side processing of clinical content.
2. No vendor access to clinical content. Remote support never reads PHI; debug builds with content logging are not shipped to customers.
3. No telemetry containing PHI. No third-party analytics SDK is included (Sentry, Mixpanel, Amplitude, PostHog, Segment, Datadog, OpenTelemetry, Honeycomb, Rollbar, Bugsnag — all absent from the dependency tree, verified in the audit).
4. No cloud features in the product. No sync across devices, no cloud backup, no share-via-link, no team workspaces, no email-this-note feature.
5. Auto-update, when enabled, will be cryptographically signed and operate over a static manifest with no PHI in the request. Update checks transmit only the application version and OS architecture.
6. No services that require PHI. No fine-tuning the model on customer data. No "send us a transcript so we can debug." No manual review of user content.

If we ever change one of the six, we will publish an updated version of this brief in advance and notify customers under contract. The current version of this brief reflects the product as of 2026-05-18.

6. Customer (Covered Entity) responsibilities

This brief documents Sapience Systems LLP's role. The clinician's clinic remains the Covered Entity (or the Business Associate of one) and retains all of its own HIPAA obligations:

• The Security Risk Assessment for the clinic's environment, including how Sapience Med fits into it
• Workforce training for clinicians who use the software
• Auto-lock at the operating-system level (Windows / macOS screen lock with password)
• Disk encryption (FileVault on macOS, BitLocker on Windows) — recommended baseline for any clinical workstation
• Backup and disaster-recovery for the clinician's local data
• Audit logging at the clinic level if required by clinic policy
• Patient consent, breach notification, and all other HIPAA obligations that rest with the Covered Entity

Sapience Med is one tool among many on the clinician's device. The clinic's HIPAA program governs the device; Sapience Med simply runs on it.

7. Security audit summary

A full security audit of the Sapience Med codebase was performed on 2026-05-07 against the then-current ASR engine. Following the migration to Whisper-large-v3-turbo and the activation of license validation, a refresh audit is scheduled for the next stable release; until then, the original report (attached as CODE_AUDIT_REPORT.md) remains a faithful description of the non-network-touching portion of the pipeline.

Original verdict: zero in-scope vulnerabilities found. The architectural claim — that the dictation pipeline transmits no PHI — holds for the current build.

Audit highlights:

• 0 telemetry/analytics packages across the Rust dependency tree;
• 0 HTTP/WebSocket/socket primitives in the dictation pipeline source files (audio, ASR, post-processing, injection);
• 0 hardcoded URLs to vendor servers other than the license-validation and update endpoints described in §4.4;
• 0 external secrets in the source repository (.env is gitignored, CI uses scoped GitHub Actions secrets only);
• All content-revealing diagnostic logs gated behind #[cfg(debug_assertions)] and compiled out of release builds;
• Tauri capabilities locked to the minimum set; webview CSP restricts off-device fetches to the license endpoint only.

8. What we ask in return

If your compliance review accepts the architectural argument above, we ask only that the clinic acknowledge in writing that it understands Sapience Med is not a Business Associate relationship. This can be a one-line clause in your standard purchase order, or our Limited-Scope Vendor Agreement (attached separately on request).

If your compliance review requires a full Business Associate Agreement regardless of the architectural facts, we politely decline. Signing a BAA when the underlying relationship does not satisfy the Business Associate definition would misrepresent the arrangement and would not improve your patients' privacy. We are happy to discuss alternative contractual structures with your counsel.

9. Roadmap items disclosed in good faith

The following are not yet implemented in the version of Sapience Med covered by this brief. They are disclosed here so that compliance reviewers have a complete picture of the current product state. None of them changes the non-BA classification.

• Local app-launch authentication (password / Touch ID gate before app opens). Currently the app opens without requiring app-level auth; the operating-system lock screen is the only gate. Planned for v1.1.
• Application-level encryption at rest for the local JSON files listed in §4.2. Currently those files rely on operating-system encryption (FileVault / BitLocker). Planned for v1.1.
• Auto-lock after inactivity. Currently relies on OS-level lock. Planned for v1.1.
• Auto-update with signed binaries via Tauri's updater plugin. Planned for v1.1. Until then, updates are distributed manually via download links from sapience.systems.

These items improve defense-in-depth but do not affect the legal classification under HIPAA, because the no-PHI-in-transit architecture is what determines the classification.

10. Contact

For questions about this brief or to request the Limited-Scope Vendor Agreement template:

Sapience Systems LLP Stoney Works 8 Stoney Lane London SE19 3BD United Kingdom Limited Liability Partnership No. OC454938

Email: team@sapience.systems Compliance contact: team@sapience.systems

Appendix A — References

• 45 CFR § 160.103 — Business Associate definition
• 45 CFR Part 164 Subpart C — Security Rule (applies to Covered Entities and Business Associates only)
• 45 CFR Part 164 Subpart E — Privacy Rule
• HHS HIPAA FAQ #256 — Software vendor classification: https://www.hhs.gov/hipaa/for-professionals/faq/256/is-software-vendor-business-associate/index.html
• HHS Conduit Exception guidance — https://www.hhs.gov/hipaa/for-professionals/faq/2077/
• HHS HIPAA for Professionals — https://www.hhs.gov/hipaa/for-professionals/index.html

This brief is provided for informational purposes. It is not legal advice. Each clinic should make its own determination, in consultation with its own counsel, about whether the architecture described above is acceptable for its use case.