HIPAA compliance for custom clinic software.

5 November 2026 · 7 min read

That distinction matters for any US clinic commissioning a custom build. This guide covers what HIPAA actually asks of clinic software, how to protect patient data at rest and in transit, what access and audit controls look like in practice, where Business Associate Agreements fit, and why safeguards are cheaper to design in than to add later. For the wider feature list, see clinic management software features.

What does HIPAA require of clinic software?

The rules lean on how systems are built because of what happens when they are not. By the count of the HIPAA Journal, 725 breaches of 500 or more records were reported to federal regulators in 2024, exposing about 275 million records, and 81.2% of them were hacking or IT incidents. One attack on Change Healthcare accounted for some 190 million of those records.

HIPAA does not hand you a product checklist. The Security Rule sets three kinds of safeguards for electronic protected health information: administrative (risk analysis, policies, training), physical (facilities, workstations, devices) and technical. The technical ones are what software implements directly: access control, audit controls, integrity, authentication and transmission security.

The US Department of Health and Human Services publishes a plain summary of the rule. It describes the rule as flexible, scalable and technology neutral: a two-doctor practice and a hospital network meet the same standards in proportion to their size and risk. A tool can make that easier or harder, but the clinic, as the covered entity, stays accountable for the result.

How do you secure patient data at rest and in transit?

Patient data has to be protected in two states: at rest, in a database or a backup, and in transit, as it moves between a browser, an app and the server. In transit that means HTTPS on every connection, with no unencrypted fallback. At rest it means encrypting the database, file storage and backups, so a stolen disk or a copied backup is unreadable without the keys.

Under today's rule, encryption is an "addressable" specification. HHS is clear that this does not mean optional: a clinic must adopt it where it is reasonable and appropriate, and where it is not, it must document why and use an alternative that achieves the same purpose. In practice almost every risk analysis ends at "encrypt it". The rule may also change. In December 2024 HHS proposed making every specification required, encryption at rest and in transit included, along with multi-factor authentication. It is still a proposal: the current rule remains in effect, and the federal agenda now projects final action for July 2027. Software built now should assume it will pass.

Beyond encryption, careful handling covers keys, backups and disposal. Keys should live apart from the data they unlock, backups need the same protection as live data, and records past their retention period should be removed so they cannot be recovered.

Why do access controls and audit logging matter?

With most large breaches starting as hacking or IT incidents, limiting who can reach patient data and recording every access are two of the most useful controls a clinic has. The Security Rule names both as technical safeguards.

Access control starts with a unique identity for every user, which the rule lists as a required specification. Shared logins make it impossible to tie an action to a person. From there, permissions should follow the minimum-necessary principle: a scheduler sees appointments, not clinical notes. Automatic logoff, an addressable specification, closes an unattended session before someone else can use it.

Audit logging is the other half. The system should record who viewed, created, edited or exported each record, and when, in a log that ordinary users cannot alter. The log lets a privacy officer investigate a suspected snoop, and it shows an auditor that the clinic enforces its own policy. HHS also expects clinics to review those records regularly, so a log nobody reads does half its job.

What are a vendor's responsibilities, and where do BAAs fit?

A vendor that creates, receives, maintains or transmits patient data for a clinic is a business associate under HIPAA. Before the vendor touches that data, the clinic must have a Business Associate Agreement in place: the written assurance that the vendor will follow the Security Rule, report security incidents and breaches, and return or destroy the data at the end. HHS publishes sample agreement provisions. Without the agreement, handing the vendor patient data is itself a violation, however secure the software is.

The chain continues past your vendor. A cloud host that stores the data, a text-message service that sends reminders, or an analytics tool that sees patient records is a subcontractor, and your vendor must hold its own agreement with each. Ask your vendor to show you that chain in writing, and make the agreement a condition of the project, not an afterthought.

How do you build compliance in from the start?

Safeguards designed into the first version cost less and hold up better than ones added after launch. Retrofitting audit logging or role-based access into a live clinic system often means reworking the data model, which is slower and riskier than getting it right the first time. A few habits help:

• Run a risk analysis before writing code, so each safeguard maps to a real threat.
• Mark which tables and files hold patient data, so they can be protected and retained as a set.
• Write the access log in one place that every patient screen goes through, rather than screen by screen.
• Put the Business Associate Agreement, and the list of subcontractors, in the project scope.

This is where a custom build has a real edge: roles and screens can match how one clinic actually works, so the minimum-necessary rule is enforced precisely instead of approximately. The trade-off is accountability. Your vendor builds the controls, but you still have to configure them, train staff and keep access current.

For a sense of what this looks like in a working product, our clinic system HMSNow writes a row every time a staff member opens a patient's profile, dental chart, encounter, prescription, lab result, imaging report, document or portal conversation. The row records who, when, from which address and browser, and whether a platform administrator was signed in as that user. The application cannot edit or delete those rows; they leave only through the retention setting, and the Chart Access Log screen filters them by patient, staff member, record type and date. Each staff member is granted specific modules, checked on every page and action, and every system is served over HTTPS with HSTS (see our security page).

It is also fair to say where HMSNow stops. It does not encrypt individual record fields inside the application, a session ends after two hours without activity rather than after a short front-desk timeout, it does not alert anyone to unusual access patterns, and the access log cannot be exported from the screen. We do not describe HMSNow as HIPAA compliant. If you are a US clinic, ask us where the data is hosted and what agreements we can sign before you commit to anything; we answer in writing.

Questions about HIPAA and clinic software

What makes software HIPAA compliant?

No product is compliant on its own and there is no official certification. Software supports compliance when it provides the Security Rule's technical safeguards (access control, audit controls, integrity, authentication and transmission security) and its vendor signs a Business Associate Agreement. The clinic's own risk analysis, policies and training complete the picture.

Does HIPAA require encryption?

Under the current rule, encryption is an addressable specification: required where it is reasonable and appropriate, and otherwise replaced by a documented equivalent. A 2024 HHS proposal would make encryption at rest and in transit required, with limited exceptions, but it has not been finalised. Most clinic software encrypts by default either way.

Is a custom-built clinic system easier to keep compliant?

It can be, because safeguards can be built into the data model and workflows rather than bolted on. It does not move the responsibility: the clinic stays accountable, and the vendor is directly liable for its own part as a business associate.

Who signs a Business Associate Agreement?

Any vendor that creates, receives, maintains or transmits patient data on your clinic's behalf signs one with you, including your software developer. That vendor in turn signs agreements with its own subcontractors, such as a hosting provider or a messaging service.