Security and HIPAA posture

The core security argument: the data never leaves

The strongest security property of MiniPACS is also the simplest to state. It is self-hosted, so the imaging archive, the database and the audit log all live on hardware you control, in your building or on your own rented server, rather than in a vendor's cloud. The images never leave premises you control unless you choose to share them. For an IT administrator or a procurement lead, that single fact collapses a whole column of risk: there is no third party holding the studies, no shared-tenancy caveat, and no request to file to get your own data back.

Everything below is a layer on top of that foundation. Access control, encryption, audit logging and network isolation all matter more, not less, once you accept that the archive sits on your side of the wall. For the wider case for running the whole system yourself, see self-hosted PACS; for the plain-language account of what a PACS is, see what is PACS.

The honest line on HIPAA

No software is HIPAA compliant on its own. Covered entities pass HIPAA, not products, and any vendor that tells you their box makes you compliant is selling you a fiction. What a system can honestly do is give you the ability to meet the controls. MiniPACS is built to map onto the Security Rule's technical safeguards at 45 CFR 164.312, so your compliance officer can finish the administrative and physical side rather than fight the software to get there.

Concretely, the technical safeguards the software implements are unique user identification, automatic logoff, encryption in motion, encrypted backups, audit controls, authentication and instant session revocation. What your clinic still owns is the rest of the standard: a written risk assessment, annual staff training, a contingency plan with a restore test, full-disk encryption on the host, and a business associate agreement with every vendor that touches protected health information. The software gives you the tools; the way you operate it is the compliance.

Access control and roles

Every action in the system is attributed to a unique user id, which is the foundation everything else in the audit trail rests on. Sign-in uses bcrypt password hashing with a 12-character minimum and a complexity gate, and login attempts are rate limited so a stolen password cannot be brute forced from the outside. Sessions log off automatically after 15 minutes with a 60-second warning, and expired tokens are rejected rather than quietly renewed.

When you need to cut someone off, a single click invalidates every open session for that user, so revocation is immediate rather than a promise that takes effect at the next login. Multi-factor authentication is not shipped yet; it is on the roadmap. Until it lands, keep administrator login on the LAN, which the network design below makes straightforward.

Encryption: in motion and at rest

In motion, traffic is protected with TLS on both the WAN and the LAN, and DICOM traffic from your modalities is gated to the LAN rather than exposed across the wider network. Backups are encrypted with AES-256 before anything leaves the machine, and the backup process refuses to run at all without a passphrase, so an unencrypted copy of the archive is never silently written to disk.

At rest, full-disk encryption on the host, using BitLocker on Windows or LUKS on Linux, is the layer you add and control yourself. It is a property of the machine rather than the application, which is why it belongs to you: a stolen or decommissioned drive should be unreadable without the key, and only you hold that key.

Audit logging

The audit log is an append-only record of who did what, when and from where. Because every entry is tied to a unique user id, it answers the access questions a HIPAA review actually asks, and it exports as CSV so your compliance officer can review activity directly instead of filing a request with a vendor and waiting. Append-only matters: the record is written to be added to, not quietly edited, so the history you review is the history that happened.

Network segmentation and exposure

The server does not sit open on the public internet. It dials out through a tunnel; nothing dials in. There is no inbound port waiting to be scanned or attacked, and remote access rides the same outbound connection. DICOM traffic stays on the LAN, which keeps the noisiest, least authenticated protocol in your environment off any route that faces outward.

One honest caveat belongs here. If you use a managed tunnel to reach the system remotely, that provider touches the path your PHI travels, so it needs a business associate agreement. Cloudflare Tunnel, for example, requires an Enterprise BAA; without one in place, run the system LAN-only or choose a tunnel that is covered by a BAA. This is a configuration decision you make, not a default the product makes for you.

Backups you own and test

Backups are daily, automatic and AES-256 encrypted before they leave the machine, and restoring is a single command. Because the archive is standard DICOM on storage you own, the second copy is genuinely yours to hold, unlike a cloud backup you cannot see or verify. The discipline that makes this real is old and boring on purpose: keep 3 copies on 2 kinds of media with 1 off-site, and restore from the backup on a schedule so you know it works. A backup you have never restored from is a hope, not a backup, and a yearly restore test is part of the contingency plan HIPAA expects anyway.

Ownership also shapes your exit. Because the data sits on your disk in standard DICOM, moving off MiniPACS is a data copy rather than a negotiation, and even the worst case, a vendor that disappears, leaves you with a readable archive any PACS or IT contractor can pick up.

How this compares to cloud PACS

With a cloud PACS the archive lives on the vendor's systems, the encryption keys and audit access are theirs to grant, and your data-residency answer is a paragraph in their attestation. Self-hosting inverts that: the data, the keys, the audit log and the backups are all on your side, and the trade you accept in return is owning the hardware and the hardening. Neither model is universally right, and the honest comparison is cloud PACS versus on-site, which walks the trade-off in full rather than pretending one side wins for everyone.

What to verify before you commit

• Data residency in writing. Confirm where the archive, the database and the audit log physically live, and that no copy is created off your infrastructure without your say.
• Full-disk encryption on the host. This is your layer; plan BitLocker or LUKS and the key custody before go-live.
• The audit export. Pull a CSV of the log and confirm it shows who, what, when and from where, so your reviews do not depend on a vendor.
• BAAs for anything that touches PHI. Including a managed tunnel; if a BAA is not in place, run LAN-only until it is.
• A tested restore. Decide the off-site copy and run a real restore, not just a backup, before the first drive fails.

If you want to see the access controls, the audit log and the backup flow rather than read about them, the landing page has a live demo you can click through on synthetic data, and the HIPAA notes open in a modal there with the full safeguard mapping.

FAQ