Software for HIPAA compliance: an obligation-to-evidence buying guide

Key takeaways

HIPAA status and a BAA are baseline checks for medical-spa software.
A certified EHR does not replace a full security risk analysis.
Vendor help can be useful, but your organization remains responsible for a complete risk analysis.

The right way to compare software for HIPAA compliance is to look past the label. Start with the work your clinic must perform, the records the product can help maintain, and the person who owns each task. Keep three decisions clear: managing a compliance program, hiring a vendor that accesses protected health information, and building an application that handles that information.

Each decision needs a different test. A program-management product should be examined through the risks, actions, incidents, and recovery work it records. Vendor procurement turns on required access to PHI and the resulting business-associate question. Application development starts with every kind of PHI the system handles and the safeguards built around it. Separating those jobs keeps a broad product claim from answering a narrower question it was never meant to settle.

Start with PHI scope and risk analysis

Before you compare features, establish what information and workflows are in scope. Protected health information, or PHI, may appear in paper files, electronic records, and images. Documenting those forms gives your clinic a defined starting point for its compliance work.

Risk analysis is the first step in identifying and putting safeguards in place under the HIPAA Security Rule. Covered entities and business associates must assess their healthcare organizations to find where PHI may be at risk. That requirement makes risk analysis an organizational responsibility, not a feature you can settle by finding a HIPAA badge in a product demo.

For electronic PHI, the safeguards address three properties: confidentiality, integrity, and availability. They span administrative, physical, and technical measures. In plain terms, your review has to reach beyond a single product screen because the rule covers different kinds of safeguards around the information.

A useful scope starts with the information your clinic handles, then connects it to the systems and workflows involved. That gives you a sound basis for evaluating whether a product supports the risk work your organization must complete. It also keeps a software hipaa compliance review grounded in the clinic's actual PHI instead of a vendor's broad category claim.

Write down the PHI in each form before you shortlist software. Then assess where that information may be at risk and which administrative, physical, and technical safeguards apply. This sequence gives the buyer a defined set of organizational needs to bring into product evaluation.

Compare software for HIPAA compliance by the work and records

What's the best HIPAA compliance tool? A badge alone cannot answer that buying question. For medical-spa software, HIPAA status and a Business Associate Agreement, or BAA, are baseline criteria, not sufficient differentiators. Our method is to compare every candidate across seven compliance jobs, then inspect the records and ownership behind each one.

HIPAA status and a BAA are baseline checks; compare tools by the work performed, record retained, and owner named.

Compliance job	Buyer criterion	Record or evidence to inspect	Ownership question
PHI inventory and risk analysis	Inventories systems and workflows that store or interact with PHI, evaluates vulnerabilities, and prioritizes remediation where risk is highest	System and workflow inventory, risk assessment, and remediation priorities	Who owns the inventory and decides remediation priorities?
Risk-register tracking	Records owners, treatment plans, target dates, and residual-risk evaluations	Risk register with those fields	Who keeps the register and evaluates residual risk?
Vendor assurance	Makes tangible assurance material available for review	BAA, SOC 2 audit, HITRUST certification, penetration-testing results, and an actionable incident-response plan	Who collects and reviews the assurance material?
Vendor risk review	Assesses risk before selection and onboarding, groups vendors into risk tiers, and repeats assessment at defined intervals. Reviews cover inherent risk, control effectiveness, and residual risk	Completed vendor risk assessments and risk tiers that focus more effort on high-risk vendors	Who sets review intervals and decides on remediation or risk acceptance?
Incident response	Documents roles, communication channels, triage and recovery criteria, breach-notification workflows, logging, and evidence handling	Incident-response plan, notification workflow, and forensics-ready logs	Who leads the response and handles the evidence?
Action history	Shows what actions were taken, when they occurred, and which controls governed them	Dated action and control records	Who preserves the action history and can retrieve it?
Recovery testing	Documents procedures, assigned roles, tested communication channels, recovery processes, and recent recovery testing for systems handling PHI	Recovery procedures and evidence of recent recovery testing	Who schedules recovery tests and records the results?

For every candidate, ask how the work is performed, what record remains afterward, and who is accountable. A feature name cannot answer those operating questions. The records matter after an incident because healthcare organizations can fail an audit when they cannot prove what happened.

The matrix also exposes different kinds of vendor proof. Assurance documents can include a BAA, audit or certification material, penetration-test results, and an incident-response plan. Operational records show whether risks, actions, incidents, and recovery tests are being tracked. Both belong in the buying review, but they answer different questions.

How do you know whether software is HIPAA compliant?

Treat a product's HIPAA status and BAA as the start of verification, not the end of comparison. Installing a certified electronic health record does not replace a full security risk analysis across all electronic PHI your organization maintains.

An EHR vendor may provide product information, assistance, and training on privacy and security. Your organization still retains responsibility for having a complete risk analysis conducted. That is why the strongest shortlist is tied to your PHI scope, the seven jobs above, and the records each product can support.

When does a software vendor become a business associate?

A software vendor becomes a business associate when it needs access to a covered entity's PHI to provide its service. The trigger is the vendor's required access, not simply the fact that the product is sold to healthcare organizations.

A vendor that needs PHI access is a business associate; covered activities include creating, receiving, maintaining, or transmitting PHI.

Business-associate obligations apply to activities involving the creation, receipt, maintenance, or transmission of PHI. Those four activities give you a practical lens for evaluating a vendor's role in a workflow. Map what the service does with PHI before treating its BAA language as the whole answer.

For each service, document its role in the workflow and whether providing that service requires access to the covered entity's PHI. Then identify whether the vendor creates, receives, maintains, or transmits that information. This turns "Does software have to be HIPAA compliant?" into a scoped review of the vendor's actual access and activity.

Our Business Associate Agreement guide explains the agreement category before you review a vendor that will access PHI. Canadian operators evaluating a U.S. HIPAA-regulated workflow can also keep our PHIPA compliance guide nearby for the separate Canadian privacy question.

The Security Risk Assessment Tool guides the required assessment

You do not have to invent the assessment structure from a blank page. The downloadable Security Risk Assessment Tool guides healthcare providers through the security risk assessment required by the HIPAA Security Rule.

Use that assessment work to sharpen the software shortlist. Once your team has identified where PHI may be at risk, the product review can focus on the relevant systems, workflows, safeguards, and records. The tool's role is specific: it guides healthcare providers through the required security risk assessment. Your procurement matrix can then test how a candidate supports the work and evidence that assessment brings into view.

That sequence also prevents the software category from defining the clinic's risk scope for you. The assessment begins with the healthcare organization and its PHI. The shortlist follows from that work.

Bring the assessment findings into product conversations as concrete requirements. If the assessment reveals risk around a system or workflow that handles PHI, the shortlist should show how each candidate fits the related safeguard and what evidence the clinic can retain. The assessment defines the concern; the buying review tests the product's support for it.

Medical-spa software has a second buying test

A medical spa operates as both a clinical practice and a service business. Its software therefore has to serve clinical documentation and compliance obligations as well as booking, retention, and margin needs.

Apply the seven compliance jobs first, then build a separate commercial cost view. Include subscription fees, add-ons, and processing rates in total cost. Weigh that cost against bookings, retention, and revenue per visit. A low subscription price does not describe the add-ons or processing rates, while a long feature list does not answer what the clinic pays in total.

This is where a product can clear the baseline compliance criteria without finishing the buying decision. Your clinic still needs software that serves clinical documentation and compliance work alongside the service business. Put the complete cost beside the three commercial measures instead of comparing subscriptions alone. The result is one decision that accounts for both sides of the medical spa.

Keep the software category precise while you compare. Our healthcare CRM guide covers the CRM category, and our guide to scheduling software for a medical office stays with the scheduling decision. The clinical and commercial tests belong in the same final buying review because the selected system has to serve both sides of the medical spa.

Is there a HIPAA-compliant ChatGPT option?

There is a healthcare-specific product designed to support healthcare organizations' HIPAA compliance requirements, but the answer depends on the exact product. ChatGPT for Healthcare is part of OpenAI for Healthcare and is designed for that support role.

For the OpenAI API platform, using PHI requires a BAA with OpenAI. OpenAI does not offer a BAA for ChatGPT Business. Those statements apply to the named products. They do not establish a universal HIPAA status for other ChatGPT plans, so keep the product name attached to every contract and workflow review.

The BAA question is only one part of an AI vendor review. Evaluate how the vendor manages risk throughout the product lifecycle. Ask for risk-management policies, governance documentation, AI security procedures, and internal review processes. These records let your team examine the operating structure behind the product's healthcare language.

Write the exact product name into the review. If the workflow uses the API platform with PHI, attach the API BAA requirement to that workflow. If the candidate is ChatGPT Business, attach the stated absence of a BAA to that product. This avoids carrying one product's terms over to another product simply because both use the ChatGPT name.

Then bring the candidate back to the same clinic-level questions: what PHI the workflow handles, what access the vendor needs, which records the system produces, and who owns the work. This prevents a broad AI label from replacing the more exact product, contract, and workflow review.

Can Microsoft 365 support HIPAA compliance?

Microsoft 365 can support HIPAA compliance through a BAA and enabled security controls. That support is not automatic, and responsibility remains with the healthcare organization using Microsoft 365.

For a buyer, the useful distinction is between the availability of a BAA and the organization's use of enabled controls. Treat both as inputs to the wider risk analysis. A Microsoft 365 decision still has to connect to the PHI your clinic handles, the applicable systems and workflows, and the organization responsible for the assessment.

This is the same ownership boundary seen with an EHR vendor. Product support may contribute to the work, but it does not transfer responsibility for a complete organizational risk analysis.

In the shortlist, record the BAA and enabled-control requirement as separate checks. Then keep the clinic's full risk analysis in view, because the organization's responsibility continues after those checks are recorded.

How do you build HIPAA-compliant software?

HIPAA-compliant application development starts by identifying all PHI the system handles. The build must then apply safeguards for the confidentiality, integrity, and availability of that PHI.

The development scope includes encryption, workforce training, access controls, monitoring, and ongoing risk analysis. The application also needs secure data storage, audit controls, PHI access management, and disaster-recovery readiness. These are build requirements, not a substitute for defining the organization's PHI or completing its wider risk work.

Turn those requirements into work your team can inspect. Keep the PHI inventory tied to the system design. Include the named safeguards in the build scope. Preserve audit controls and access management as operating requirements, and keep disaster-recovery readiness visible instead of leaving it outside the application decision.

Building for HIPAA includes PHI scope, application controls, and ongoing operating requirements. Identify all PHI handled by the system. Apply safeguards for confidentiality, integrity, and availability. Account for the named security measures during development, then keep ongoing risk analysis, access management, audit controls, and recovery readiness in the operating requirements. These measures belong in the application's operating requirements.

If you are buying instead of building, compare every shortlisted product across the seven compliance jobs before choosing one. For any vendor that will access PHI, read our Business Associate Agreement guide and bring the access trigger into your review.