Your clients' data in SignalEHR: the architecture, in plain language
June 5, 2026 · 6 min read · By SignalEHR
Therapists ask a version of the same question before anything else: what happens to my clients' words once they pass through your software?
It's the right thing to lead with. A therapy session is about the most sensitive data there is, and "trust us" isn't an answer. So here is the specific version of what SignalEHR keeps, what it doesn't, who can see it, where it lives, and the places where we choose not to make the bigger claim.
Where the data lives
SignalEHR runs on Google Cloud in the United States, in the us-central1 region, with no database exposed to the internet. Records sit in Firestore and Cloud SQL, reachable only from inside our private network. Everything is encrypted at rest with AES-256, and every connection is encrypted in transit with TLS 1.2+.
Your stored insurance-billing credentials get one more layer on top: an application-level AES-256-GCM envelope, with the key kept in a secrets manager, so a database compromise on its own would not hand someone your payer logins.
One note for Canadian practices. Data is processed in the US today under contractual safeguards, and a Montréal region is on our roadmap for residency by default.
The session audio is never kept
When you run a live individual or couples session, the audio streams in, gets transcribed in real time, and is then gone. It lives in memory for the few seconds it takes to turn speech into text, and it's discarded. SignalEHR does not write raw session audio to disk or keep a recording.
If you use the optional recorded mode for groups or families, that audio is held encrypted only until the transcript and notes come out of it, then deleted. What we keep is the transcript and the clinical note, because that is the record.
We retain your records, and we say so
Some tools advertise that they hold on to nothing at all. We won't, because it isn't true of any real EHR, ours included. A clinical note is a medical-legal record you have to keep for years.
SignalEHR retains the transcript, the note, and the structured clinical signals as your record, encrypted, for the retention period your board requires. What we minimize is the part we don't need, which is the raw audio.
Encrypted in transit and at rest, said plainly
You'll see the phrase "end-to-end" a lot in this space. We don't claim it, because for a platform like ours it would be false. SignalEHR transcribes and analyzes the session on the server, which means the server can read the data. That is the opposite of what end-to-end promises.
What's true is TLS 1.2+ on the wire and AES-256 at rest, plus the billing-credential envelope above. That's strong. It just isn't a slogan.
Your clinical content is not training data
Your identifiable client content, the transcripts and notes and what was said in the room, is not used to train AI models. The services we use for transcription and drafting run under Business Associate Agreements that bar training on your inputs.
Here is the part I won't overstate. SignalEHR does improve its own models over time. But it learns only from de-identified signals. When a clinician corrects a risk flag, that correction, stripped of identifying information under the HIPAA de-identification standard, can make the model better for everyone. Your client's identity never travels with it, and one practice's data is never used to build something another practice sees.
Who can open a client's chart
Confidentiality isn't only about outside attackers. It's about who inside your own practice can open a chart. SignalEHR enforces four roles, in code, on every request. Owners and admins run the practice. Practitioners see their own clients' clinical content. Receptionists can work the front desk, booking and reminders and basic contact details, but the system strips diagnoses, notes, transcripts, and risk data out of their responses, so the data never reaches their screen in the first place.
Every access to protected health information is written to an append-only audit log: who opened what, and when. If a client exercises their right of access or a regulator asks, the trail is there.
Compliance, with the asterisks left in
For US practices there is a real, e-signable Business Associate Agreement built into the product, counter-signed, with safeguards mapped to 45 CFR §164.308 through §164.312. For Canada there is a data-processing agreement covering PIPEDA, Ontario's PHIPA, Québec's Law 25, Alberta's HIA, and BC's PIPA.
We are aligned to the SOC 2 Trust Services Criteria, with a Type I audit in progress. We won't print a certification we haven't earned. The stronger Type II report, the one an auditor compiles by watching the controls operate over months, is something we haven't finished, so we don't claim it.
If we suffer a breach, we notify affected customers without unreasonable delay and no later than 30 days, ahead of HIPAA's 60-day floor. Every third party that touches PHI is under a BAA or DPA and listed publicly on our security page, and we give 30 days' notice before adding a new one.
The short version
Your clients' words are the most sensitive thing you handle. Raw audio isn't kept. Your records are encrypted and retained as your record. Your identifiable content never trains a model. Your front desk can't read clinical notes. Every access is logged, and you get a real, signed BAA.
Where a claim would be too strong to stand behind, we don't make it. You should hold every vendor you trust with client data, us included, to that same standard.
The honest version
We could have printed the usual badges, the ones every vendor in this category prints. We took them down instead and wrote the specific version, because the specific version is the one you can actually verify. If you want to read ours closely, it's all on our security page.
The full security posture, with the receipts
Every claim above is backed on our security page: the exact encryption layers, the sub-processor list, the BAA and DPA, and the breach-notification commitment. No badges we can't defend.