HIPAA Basics for Software Buyers Handling Health Information
HIPAA is specific, consequential, and often misunderstood by buyers outside healthcare. If you touch health information, it changes how you buy software.
HIPAA - the Health Insurance Portability and Accountability Act - is a United States law that sets rules for protecting certain health information. For organizations in or adjacent to healthcare, it is not optional, and it directly constrains which software you can use and how. For everyone else, it is a useful example of what regulated data handling looks like.
This is a buyer-level primer, not legal advice. HIPAA compliance is a serious undertaking that depends on your specific circumstances and warrants proper counsel. The aim here is to give you the concepts and the questions so you can evaluate whether a vendor is a safe choice when protected health information is involved.
The concepts that matter for buyers
- PHI (Protected Health Information): individually identifiable health information. HIPAA governs how it is used, stored, and disclosed.
- Covered entities and business associates: healthcare providers, plans, and clearinghouses are covered entities; vendors that handle PHI on their behalf are business associates with their own obligations.
- Business Associate Agreement (BAA): the contract that must be in place between a covered entity and a vendor before that vendor handles PHI.
- Safeguards: HIPAA requires administrative, physical, and technical safeguards - access controls, audit trails, encryption, and more - around PHI.
Why the BAA is the pivotal question
If your organization is a covered entity or handles PHI on behalf of one, you generally cannot lawfully put PHI into a vendor system unless that vendor will sign a Business Associate Agreement. The BAA formalizes the vendor obligations to protect PHI and defines responsibilities if something goes wrong. Whether a vendor offers a BAA is often the single most decisive question in a healthcare software evaluation.
A vendor being generally secure is not the same as being willing and able to act as a HIPAA business associate. Many capable products do not offer BAAs, which simply means PHI should not go into them. Knowing this before you commit avoids a painful discovery later - that you have been storing regulated data somewhere you were not permitted to.
How to evaluate a vendor for PHI
Start with the BAA question and let it gate the rest: will you sign a Business Associate Agreement covering the way we intend to use the product? If not, PHI cannot go there, full stop. If yes, then examine the safeguards - access controls, audit logging, encryption in transit and at rest, and how access is restricted to the minimum necessary. HIPAA emphasizes least-privilege access and the ability to account for who accessed what.
Be precise about scope, too. A vendor may support HIPAA-aligned handling for certain configurations or plans and not others. Confirm that the specific way you will use the product is covered, rather than assuming a general willingness extends to every feature.
A note on Atlas and any general platform
General work platforms, Atlas included, are chosen by a wide range of organizations, and buyers who handle PHI must evaluate any such platform specifically against their HIPAA obligations - starting with whether the appropriate agreements and safeguards are available for their intended use. Do not assume a general-purpose product is suitable for PHI without confirming this directly; that confirmation is the buyer responsibility and should never be inferred.
The broader lesson for buyers is that regulated data raises the bar from is this tool secure to is this tool permitted for this data under our obligations. Those are different questions, and HIPAA is the clearest reminder that the second one can override the first regardless of how good a product is.