HIPAA Compliant Software: A Checklist for Practices Choosing a System

A HIPAA compliant software checklist helps you test a vendor's claims before patient data goes into their system. The short version: no software is "HIPAA compliant" on its own. Compliance is your practice's program, and the software is one part of it. Use the checks below to confirm the vendor's safeguards and contract hold up their side, then fold the answers into your own risk analysis.

This is general guidance, not legal advice. HIPAA rules are interpreted and updated over time, so confirm the details with your compliance adviser or counsel.

Is there such a thing as HIPAA certified software?

No. HHS does not certify, approve or endorse software as HIPAA compliant, and there is no official HIPAA seal. When a vendor says its product is compliant, it means the product has features and the company has practices that support your compliance. That can be true and useful, but it is a claim to verify, not a status.

Two parties carry obligations. Your practice, as a covered entity, must protect patient information however it is stored. A vendor that creates, receives, keeps or sends protected health information (PHI) for you is a business associate, and has its own duties under the Security Rule and its contract with you. The checklist below covers both sides.

The business associate agreement

A business associate that handles PHI for you must sign a business associate agreement (BAA) before it does. A vendor that will not sign one should not hold your patients' data. When you read the BAA, check that it covers these points.

• The vendor signs a BAA, and it names the services that touch PHI.
• It limits how the vendor may use and disclose PHI to what the contract allows.
• It commits the vendor to appropriate safeguards under the Security Rule.
• It requires the vendor to report breaches and security incidents to you, and says how fast.
• It requires the same protections from any subcontractor that handles your PHI (hosting, support, mailing, messaging).
• It covers what happens to PHI when the contract ends: returned to you, or destroyed where that is feasible, and protected while it is kept.
• It lets you get the information you need to answer a patient's request to see or amend their record.

Access controls

The Security Rule's technical safeguards start with who can get in and what they can see. Some specifications are "required" and some are "addressable". Addressable does not mean optional: you must assess it, put it in place where reasonable, or document why not and what you do instead.

• Every person signs in with their own user ID. No shared logins at the front desk or on the billing team (unique user identification is required).
• Access follows the job. A biller, a nurse and a scheduler each see what their work needs, which is how you meet the minimum necessary standard in practice.
• Access can be limited per action, not only per screen: viewing a record and editing it are separate permissions.
• There is a documented way to reach records in an emergency (an emergency access procedure is required).
• Idle sessions end on their own after a period you can set (automatic logoff is addressable).
• Removing a person's access when they leave takes effect at once, and you can see who still has access.

Audit controls and integrity

Audit controls are a required standard: the system must record and let you examine activity on PHI. Integrity means protecting PHI from being changed or destroyed improperly.

• The system records who viewed, created and changed each record, and when.
• Someone at your practice, not only the vendor, can read that history without opening a support ticket.
• The history cannot be edited or erased by ordinary users.
• A correction to a record keeps the earlier version rather than overwriting it.
• Deleting a record hides it rather than destroying it, so the history survives a mistake.
• Changes made by connected systems and automations are recorded too, not only changes made by people.

Authentication and transmission security

Person or entity authentication is required: the system must verify that the person or system signing in is who it claims to be. Transmission security covers PHI in transit.

• Ask what sign-in protections are available, including multi-factor authentication, and whether you can require them.
• PHI is encrypted when it travels between the system and its users, and between the system and other systems (encryption is addressable under the current rule).
• PHI is encrypted where it is stored, including backups (also addressable under the current rule).
• Connections to other software use credentials that can be limited, replaced and revoked. Our guide to healthcare API integration covers what to ask.
• Automated messages to other systems carry no more patient information than they need.

HHS has proposed changes to the Security Rule that would make several safeguards firmer, including encryption and multi-factor authentication, and would remove much of the difference between required and addressable. Check with your adviser whether those changes have been finalized and what they ask of you.

Backups, retention, breaches and leaving the system

Backups and retention

The Security Rule also requires a contingency plan, including a data backup plan and a disaster recovery plan. And you need to know you can get your data out.

• The vendor backs up your data and has tested restoring it.
• There is a plan for an outage: how you keep seeing patients, and how the data comes back.
• You keep required HIPAA documentation (policies, procedures, risk analyses and the records they call for) for 6 years from when it was created or last in effect, whichever is later. Decide where it lives.
• Medical record retention is a separate question. It is set by state law and by other rules, such as Medicare and payer contracts, and can be longer. Ask how long the system keeps records and whether you control it.
• You can export your records in a usable format, and the contract says how and when you get them at the end.

Breach notification

The Breach Notification Rule requires a covered entity to notify affected patients after a breach of unsecured PHI, without unreasonable delay and no later than 60 days after discovery. HHS must be notified too, and for a large breach the media as well; the timing depends on how many patients are affected. A business associate must tell you about a breach it discovers, also without unreasonable delay and within 60 days. State laws and your contract may set shorter deadlines.

• The BAA states the vendor's notice deadline and what the notice will contain.
• The vendor can tell you which records and patients an incident touched, from its logs.
• You know who at the vendor to call, and they know who at your practice to call.

What stays your practice's job

Good software does not make a practice compliant. These are yours regardless of the system you choose.

• A written risk analysis, updated when systems change (required).
• Policies and procedures, and a person responsible for security.
• Training for every member of the workforce, and sanctions when rules are broken.
• Reviewing the system's activity records on a schedule.
• Giving each person the access their job needs, and taking it away when the job changes.

Our list of questions to ask before you choose an EHR covers the rest of the evaluation, beyond security.

Frequently asked questions

Does every software vendor have to sign a BAA?

A vendor that creates, receives, keeps or sends PHI on your behalf is a business associate and needs a BAA. A service that only carries data without access to it, the way a postal service carries mail, is generally not. Where a particular vendor falls is a question for your compliance adviser.

Can a practice use cloud software under HIPAA?

Yes. HHS guidance allows a covered entity to use a cloud service to store or process PHI, provided there is a BAA with the provider and the practice includes the service in its own risk analysis.

Is encryption required under HIPAA?

Under the current Security Rule, encryption is addressable: you must use it where reasonable and appropriate, or document why not and what you do instead. Encryption that meets HHS guidance also matters for breach notification, because the rule applies to unsecured PHI. HHS has proposed making encryption a firmer requirement, so check the current rule.

How long do we have to keep HIPAA records?

HIPAA's own documentation, such as policies and risk analyses, is kept for 6 years from creation or the date it was last in effect, whichever is later. How long you keep the medical record itself is set by state law, Medicare and other program rules, and your payer contracts.

Sources

• What You Should Know About OCR HIPAA Privacy Rule Guidance Materials, HHS Office for Civil Rights
• Business Associate Contracts, HHS Office for Civil Rights
• 45 CFR 164.306, Security standards: General rules, Code of Federal Regulations
• 45 CFR 164.308, Administrative safeguards, Code of Federal Regulations
• 45 CFR 164.312, Technical safeguards, Code of Federal Regulations
• 45 CFR 164.316, Policies and procedures and documentation requirements, Code of Federal Regulations
• Breach Notification Rule, HHS Office for Civil Rights
• 45 CFR 164.404, Notification to individuals, Code of Federal Regulations
• 45 CFR 164.410, Notification by a business associate, Code of Federal Regulations
• Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable, HHS Office for Civil Rights
• Guidance on HIPAA & Cloud Computing, HHS Office for Civil Rights
• HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule), Federal Register