Security
Six layers of defence, HIPAA-ready from day one. Internally we call the stack LMLSE.
An exosystem rather than an ecosystem: it wraps the practice from the outside. Six layers, each built on the assumption that the one before it might fail.
The short version
LogBlues keeps records on the machines in your building. There is no copy of your patients on our servers, because nothing in normal use sends one.
That one decision closes off a lot of the ways clinical data goes astray. It does not close off all of them, which is what the layers below are for.
Layer by layer
Before the app trusts the machine it’s running on, it checks it. Encryption enabled, screen lock present, no obvious tampering. A laptop that fails those checks is a laptop that shouldn’t be holding charts.
Credentials and keys live in the operating system’s own secure store, Windows DPAPI and the Android keystore, never in a file we invented. The workspace database is encrypted at rest with AES-256-GCM under a key held in that store, and portable backups are separately encrypted with a passphrase you choose.
Where this stops today: files you attach to a chart — scans, lab PDFs, imaging — are stored in the application’s own data folder without a second layer of encryption on top, and rely on the operating system’s file permissions and on whole-disk encryption being switched on. Encrypting attachments individually is on the way. If a workstation is shared, turn on BitLocker or FileVault.
Ten roles across twenty-six permissions decide which screens, dashboard cards and actions a person reaches, and an administrator can subtract further for one individual. Blues is handed the same permissions you have, so it cannot answer past your role.
Where this stops today: the gate is at the workspace level rather than inside an open chart, so a role that can open a patient record can read the clinical notes in it. Per-note permissions and a second check in the backend are both in progress.
Results flagged sensitive ask again. You get a one-time code generated from a cryptographically secure source and expiring in ten minutes; verifying that way unlocks for the rest of that session, so sign out rather than walk away from a shared workstation. Verifying with Windows Hello or a device credential instead holds for fifteen minutes and then lapses on its own. An administrator can turn re-verification off for the whole clinic in Settings, and every unlock either way is logged.
Where this stops today: the code is delivered to your notification tray inside the app, on the same machine, so it confirms you are the person at that workstation rather than proving who you are from a second channel. Email and text delivery switch on with the practice cloud account service.
Exports, backups, protected-result verifications and security-policy changes are written to a security log the person who triggered them cannot quietly edit, alongside encrypted local export. Being straight about where this layer stands: the log lives for the session today rather than across restarts, and it does not yet record sign-in, record access, deletes or permission changes. A durable, append-only and complete trail is not included with the current build.
Today it does not. Practice runs local-only: your records stay on your machines and the application does not connect to a sync service.
What is built and waiting: the backend schema already enforces per-practice isolation at the row level in the database itself, so one clinic could not read another’s data even if the application layer were wrong, and the client is written against an authenticated API rather than an open database. None of it is switched on in the current build, and we would rather say so than describe protection you are not yet using.
The assistant
The usual way to add AI to clinical software is to send the chart to somebody else’s API. We didn’t. Blues runs against a model on the clinic’s own machine, so what a clinician types stays on that machine.
It’s also bound by the same permissions as the person using it: Blues cannot read or write anything you couldn’t yourself, and every write asks before it happens.
Your data
The worst thing a software company can do to a practice is make its own records hard to retrieve. It is worth checking how any vendor answers this, including us.
What we would suggest asking us, and anyone else: what exactly comes out, in what format, who is allowed to run it, what it costs, and what happens to the copy you leave behind.
AI and your data
If Blues ever gains a feature that sends anything off the machine, it will be opt-in, it will say so on this page, and it will be described here before it ships.
Agreements and support
Business Associate Agreement: available on request, at no charge. Write to us and we will send it and talk it through. We would rather have that conversation early than have it become a surprise during your diligence.
Support is email today, answered by a person who works on the software, not a tier you upgrade into. As the practice base grows we will publish response times and hours here rather than leaving them implied.
Use the contact form — agreements, security questions and everything else
Being straight with you
LogBlues is HIPAA-ready from day one. We don’t say “HIPAA compliant,” because compliance isn’t a property of software — it’s a property of a practice, its agreements, and how it works. Software can make it achievable. It can’t hand it to you.
What we can tell you is what the software does, which is the list above, and that we’ll put it in writing. If you need a Business Associate Agreement, ask and we’ll talk it through.
Contact form (general)
— agreements and BAA requests
Contact form (security)
— security questions and disclosure
Why any of this matters
The point of building this in from the start, rather than selling it as a tier, is that protecting your patients’ information should not become another thing you have to manage.
You are the one in the room doing the work that matters. We would like this part to be one less thing on your mind.
United States and Mexico at launch.