Building a HIPAA-compliant app means engineering your software, infrastructure, and internal processes so that protected health information (PHI) stays confidential, accurate, and available in line with U.S. federal law. In practice, compliance is not a single feature you switch on — it is the combination of technical safeguards (encryption, access control, audit logging), signed Business Associate Agreements with every vendor that touches PHI, and documented policies proving you manage risk. There is no official "HIPAA certification," so the goal is defensible, auditable adherence to the HIPAA Privacy, Security, and Breach Notification Rules.
What does HIPAA actually require from an app?
HIPAA (the Health Insurance Portability and Accountability Act of 1996, strengthened by the 2009 HITECH Act) applies whenever your application creates, receives, stores, or transmits electronic protected health information (ePHI) on behalf of a covered entity or another business associate. If you build patient-facing telehealth tools, provider dashboards, billing systems, or health data pipelines, you are almost certainly in scope.
The law is organized into three rules that matter most for software teams:
- The Privacy Rule governs how PHI may be used and disclosed, and enforces the "minimum necessary" principle — only expose the data a given role or workflow genuinely needs.
- The Security Rule sets the technical, administrative, and physical safeguards for ePHI. This is where most engineering work lives.
- The Breach Notification Rule defines what you must do — and how quickly — if PHI is exposed.
You can read the primary requirements directly from the regulator on the HHS HIPAA for Professionals pages, which remain the authoritative reference.
Are you a covered entity or a business associate?
Your obligations depend on your role. A covered entity is a healthcare provider, health plan, or clearinghouse. A business associate is any vendor that handles PHI on a covered entity's behalf — which includes most software development firms, hosting providers, and SaaS platforms in the healthcare space.
Every business associate must sign a Business Associate Agreement (BAA) with the party it serves, and in turn with its own subcontractors. This creates a chain of accountability. Practically, this means you can only use cloud services (databases, email, analytics, logging, AI APIs) that will sign a BAA. Major providers such as AWS, Google Cloud, and Microsoft Azure offer HIPAA-eligible services under a BAA, but not every service in their catalog is covered — verify each one.
The Security Rule safeguards to build in
The Security Rule groups requirements into three categories. Translated into concrete engineering tasks:
Technical safeguards
- Access control: unique user IDs, role-based access control (RBAC), and automatic session logoff.
- Encryption in transit: TLS 1.2 or higher for every connection carrying ePHI, with no fallback to weak ciphers.
- Encryption at rest: AES-256 for databases, object storage, and backups. Encryption is technically "addressable," but in reality it is the expected default and the safe-harbor that can exempt encrypted data from breach notification.
- Audit controls: immutable logs recording who accessed which PHI, when, and what they did.
- Integrity controls: mechanisms to detect unauthorized alteration of PHI.
- Authentication: strong identity verification, ideally multi-factor authentication for anyone touching PHI.
Administrative safeguards
- A documented risk analysis and ongoing risk management program.
- Workforce training, sanction policies, and a designated security officer.
- Incident response and contingency (backup and disaster recovery) plans.
Physical safeguards
- Facility access controls and device/media disposal policies — largely inherited from a HIPAA-eligible cloud provider, but still your responsibility to document.
For a detailed engineering checklist, the U.S. National Institute of Standards and Technology publishes NIST Special Publication 800-66, which maps the Security Rule to implementable controls.
How do you build a HIPAA-compliant app step by step?
- Scope your PHI. Map exactly what data you collect, where it flows, and where it rests. Everything that touches ePHI is in scope; everything else can be isolated.
- Conduct a risk analysis. Identify threats and vulnerabilities before writing code — this is a mandatory, documented step, not optional.
- Choose HIPAA-eligible infrastructure and execute BAAs with every vendor in the chain.
- Design for least privilege. Segment PHI, enforce RBAC, and apply the minimum-necessary rule at the data-model level.
- Encrypt everywhere — in transit, at rest, and in backups — and manage keys properly.
- Instrument audit logging from day one; retrofitting it later is painful and error-prone.
- Plan for breaches. Build detection, alerting, and a documented notification workflow.
- Test and document. Penetration testing, code review, and written policies turn engineering effort into audit-ready evidence.
Common mistakes that break compliance
- Putting PHI in application logs, error trackers, or analytics tools that lack a BAA.
- Sending appointment details or test results over plain email or SMS.
- Using a third-party API (including AI/LLM services) without confirming BAA coverage.
- Treating de-identification loosely — true de-identified data must meet HIPAA's Safe Harbor or Expert Determination standard before it leaves scope.
- Assuming a cloud provider's compliance covers your application layer. Their BAA covers the infrastructure; your code and configuration are still your responsibility.
These fundamentals apply whether you are shipping a mobile app, a web platform, or backend healthcare software, and they scale from an MVP to enterprise-grade healthcare solutions.
Frequently asked questions
Is there such a thing as HIPAA certification?
No. HHS does not certify apps or vendors as HIPAA-compliant. Third-party audits, HITRUST certification, and SOC 2 reports can demonstrate the maturity of your controls, but compliance is ultimately something you attest to and must be able to defend during an investigation or audit.
Does HIPAA apply to companies outside the United States?
Yes, in effect. HIPAA is U.S. law, but it follows the data. If your app handles PHI for a U.S. covered entity, you become a business associate and must meet the same obligations regardless of where your team is located. Non-U.S. teams building for the U.S. market should also account for cross-border data transfer expectations in their architecture.
How much does HIPAA compliance add to development?
It adds meaningful effort — infrastructure, security engineering, documentation, and testing — but the cost of non-compliance is far higher. Penalties scale by culpability tier and can reach into the millions per year, alongside reputational and contractual damage. Building compliance in from the start is dramatically cheaper than retrofitting it.
Can I use AI or third-party APIs in a HIPAA app?
Yes, provided the vendor will sign a BAA and the service is configured to keep PHI within compliant boundaries. Never send PHI to an API — including AI models — that is not covered by a BAA. When in doubt, de-identify data first or keep processing inside your own compliant environment.
How Direlli can help
Direlli builds secure, compliant healthcare products end to end — from risk analysis and architecture through encryption, audit logging, and audit-ready documentation. With a 5.0 rating on Clutch and delivery for clients across the US, Europe, and MENA, our teams help you ship HIPAA-conscious software without slowing down. Contact us to discuss your healthcare project.
