Quick answer: HIPAA compliance is a responsibility of the organisations that handle patient information, not a badge a software product can hold. Developers support it by building technical safeguards such as access control, audit logs, encryption, secure transmission and data isolation, and by signing a business associate agreement. Be wary of anyone who calls software "HIPAA certified".
If you are building a healthcare product for the United States, you will hear the word HIPAA in nearly every conversation. Investors ask about it, hospitals demand it, and software vendors sprinkle it across their websites with the confidence of a trademark.
Here is a fact that surprises many founders. The US government does not certify software as HIPAA compliant. No such certificate exists. Compliance describes how a covered organisation, and the partners who handle its data, behave. Software can make compliance easier or much harder, and that difference is where good engineering matters.
The terms in two minutes
- PHI is protected health information: anything that identifies a patient and relates to their health, care or payment.
- Covered entity: a provider, health plan or clearinghouse that handles PHI.
- Business associate: a company that handles PHI on a covered entity's behalf, which includes many software vendors and hosting providers.
- Business associate agreement (BAA): the contract in which a vendor accepts legal responsibility for protecting PHI. It should be signed before engineers see real patient data.
What the Security Rule asks for, in engineering terms
The rule groups safeguards into administrative, physical and technical. Developers mainly deliver the technical ones, and support the others with design.
Access control
Every user has a unique identity, and sees only what their role requires. A receptionist does not need clinical notes, and a developer does not need production records. Roles, least privilege and automatic sign out after inactivity are standard.
Audit controls
The system records who viewed, created, changed or exported patient data, and when. These logs must be protected from tampering and reviewed, because they are your evidence when something goes wrong.
Integrity
Safeguards ensure data is not altered or destroyed improperly. Validation, version history and database controls all contribute.
Authentication
Strong sign in, usually with multi factor authentication for staff, and careful handling of password reset flows.
Transmission security
All data in transit is encrypted, including traffic between services, mobile apps and third party integrations.
Encryption at rest
Technically described as an addressable item, in practice it is expected. Databases, backups and file storage are encrypted, and keys are managed separately from the data.
Design choices that make compliance easier
- Data isolation. For multi location groups or franchises, giving each tenant a separate database prevents one mistake from exposing another clinic's patients. We discuss the trade-offs in our piece on multi-tenant SaaS architecture.
- Minimum necessary data. Collect and display only what the task needs, and keep PHI out of logs, analytics tools and error messages.
- Safe mobile design. Avoid storing PHI on devices, require device locks and make sure screenshots, caches and push notifications do not leak details.
- Vetted vendors. Email, SMS, video and AI providers that touch PHI also need BAAs and appropriate configuration.
- Environments without real data. Development and testing use synthetic records, never copies of live patients.
- Backups and disaster recovery. Encrypted, tested and documented, in line with our ransomware recovery guidance.
What software alone cannot do
Technology covers only part of the rule. The rest is people and process: risk assessments, staff training, written policies, breach response plans, device management and vendor oversight. A perfectly engineered platform can still be used in a non compliant way. Be honest with your team that compliance is a practice, not a purchase.
Questions to ask a development partner
- Will you sign a business associate agreement before accessing any PHI?
- How do you isolate data between our customers?
- What is logged, where is it stored and who can read it?
- How do you handle development and testing without real patient data?
- How are backups encrypted, tested and restored?
- Which third party services will touch PHI, and are BAAs in place?
- What happens if you discover a security incident, and how quickly will you tell us?
Notice what is not on the list: "Are you HIPAA certified?" The right answer is an explanation of how they build and operate, not a badge.
Where to go next
Our healthcare engineering team builds multi-tenant clinical platforms, telehealth products and real time monitoring systems, and signs a BAA before seeing PHI. Read about our HIPAA engineering approach, the BAA we offer and our published pricing ranges.
This article is general information, not legal advice. Always confirm requirements with a qualified healthcare compliance advisor.
Frequently Asked Questions
Is there such a thing as HIPAA certified software?
No. The US Department of Health and Human Services does not certify software or vendors. Compliance depends on how organisations and their business associates handle patient data, supported by well designed software.
What is a business associate agreement?
It is a contract in which a vendor that handles protected health information agrees to safeguard it and meet HIPAA obligations. It should be signed before the vendor accesses real patient data.
Does hosting on a major cloud provider make my app HIPAA compliant?
No. Cloud providers offer eligible services and sign BAAs, but you remain responsible for configuring them correctly and for how your application handles data.
Do developers need to encrypt all patient data?
Encryption in transit and at rest is the expected standard for protected health information, and is considered best practice even where the rule labels it addressable.
Be the first to comment.