Where your patient data actually lives

The question under every other question

Ask a clinical software vendor where your charts live. In most cases, the honest answer is: on their servers, in their account, under their control.

That answer has consequences. Your PHI now sits somewhere you cannot inspect, governed by terms you did not write. And the vendor, holding thousands of practices' records in one place, becomes a permanent and attractive target.

We built LogBlues on a different answer. Records stay on the machines in your practice. There is no copy of your patients on our servers, because normal use never sends one. That is not a policy we promise to honor. It is how the software works.

The LMLSE: six layers, from the outside in

Keeping data local is the foundation, not the whole building. A local file is only as safe as the machine holding it. So we wrap the practice in the LogBlues Multi-Layered Security Exosystem, six layers that each assume the one before it might fail.

• Layer 1, the device. Before the app trusts a machine, it checks it: disk encryption enabled, screen lock present, no signs of tampering. An untrusted device does not get to be a quiet exception.
• Layer 2, at rest. Credentials and keys live in the operating system's own secure store, Windows DPAPI and the Android keystore. Never a homemade key file. Local data is encrypted at rest.
• Layer 3, permissions. Role-based access control is applied where data is read, not merely where a button is drawn. Hiding a menu item is not security; it is decoration.
• Layer 4, the second door. Screens holding real PHI require re-authentication. A one-time code is emailed from a domain-verified, DKIM-signed sender, generated from a cryptographically secure source and expiring in ten minutes. The unlock lasts for that session only and ends at sign-out.
• Layer 5, the trail. Exports, backups, protected-result verifications and security-policy changes are written to a security log the triggering user cannot quietly edit, paired with encrypted local export. Today that log lives for the session; making it durable, append-only and complete — covering sign-in, record access and permission changes too — is the work in front of us on this layer, and so is tested recovery. A backup nobody has restored is a hope, not a plan.
• Layer 6, sync. When cloud sync arrives, it never exposes a database to the internet. The app talks to an authenticated API. Storage is isolated per practice and enforced at the row level, so one clinic cannot read another's data even if the application layer is wrong.

Why layer 6 is written that way

That last point deserves a moment, because it is where most sync designs get sloppy. It is common to separate tenants in application code and call the job finished. That works right up until a query is built wrong.

Row-level enforcement means the isolation lives in the storage layer itself. If the application asks for data it should not have, the answer is still no. We are designing the boundary to hold even when our own code has a bad day.

On compliance, said plainly

LogBlues is HIPAA-ready from day one. Encryption at rest, access controls enforced at the data layer, an audit trail, re-authentication for PHI, tested recovery. These are the technical safeguards the rule contemplates, and they are built in rather than bolted on.

Here is the honest part. Compliance is a property of a practice and its agreements, not of software alone. It depends on your policies, your training, your business associate agreements, and how your staff actually behaves on a busy Thursday. Any vendor who tells you their product makes you compliant is selling you a feeling.

What software can do is make the right thing the default and the wrong thing difficult. Keep the data where you can see it. Encrypt it. Check the machine. Gate the sensitive screens. Log every look. Then, when sync arrives, refuse to loosen any of it for convenience.

You should not have to trust us with your patients to use our software. That is the point of building it this way.