Two months free. Download LogBlues and let us prove it — no card, no contract. Start free →
LogBlues
The LMLSE shield.

Security

Your charts stay on your machines, and we cannot read them.

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

Patient data does not move unless you move it.

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

Six layers. What each one is for.

  • 1 The device

    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.

  • 2 The record at rest

    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.

  • 3 Who sees what

    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.

  • 4 The second door

    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.

  • 5 The trail

    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.

  • 6 When it syncs

    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

Blues is inside the exosystem, not an exception to it.

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.

More about Blues →

Your data

Getting it out is not a favour we do you.

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.

  • The records are already on your machines. There is no retrieval request, because there is nothing of yours being held anywhere else.
  • Export is built in and free. Encrypted, complete, and runnable by you without asking us or waiting on a ticket.
  • No expiry window. Nothing that hands you a download link that dies in a week.
  • A patient asking for their chart can be answered the same day, from the chart itself.

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

In plain language, before the legal version.

  • Nothing you type to Blues leaves your machine. The model runs locally. There is no API call carrying a chart to a third party.
  • Your patient data is never used to train a model. Not by us and not by anyone else, because it never reaches anywhere it could be trained on.
  • No transcripts are retained by us. Conversations live on that device and are yours to keep or clear.
  • Blues is bound by your permissions and asks before every write.
  • There is nothing to opt out of, which we think is a better answer than a well-designed opt-out.

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

A BAA, and a person to email.

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

What we do and don’t claim.

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

You have patients to see.

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.

Four things it comes down to.

  • Secure Access
  • Encryption
  • Permissions
  • Audit & Recovery

United States and Mexico at launch.