If you are building a healthcare application that handles patient data in the United States, HIPAA compliance is not optional. It is a legal requirement — and violations carry penalties ranging from $100 to $50,000 per violation, up to $1.9 million per year for repeated violations of the same provision.
HIPAA-compliant app development is not just about adding encryption at the end of your build. It is an architectural discipline that starts with your first design decision and runs through every layer of your application.
This guide covers the specific technical and operational requirements your healthcare application needs to meet — from data architecture and encryption standards through audit trails, access controls and the vendor agreements that protect you legally.
HIPAA applies to any organisation that creates, receives, maintains or transmits Protected Health Information (PHI). That includes:
If you are building software that stores, processes or transmits any data that could identify a patient alongside their health information — diagnosis, treatment, payment, test results — your application is almost certainly subject to HIPAA. When in doubt, assume it applies and consult a healthcare compliance attorney.
PHI is any individually identifiable health information. This includes 18 specific identifiers that, when combined with health data, make the data “identifiable”:
Electronic PHI (ePHI) — PHI that is stored or transmitted electronically — is what the HIPAA Security Rule primarily governs. If your app stores any of these identifiers alongside health data, it is handling ePHI.
The Privacy Rule governs how PHI can be used and disclosed. For your application, this means:
The Security Rule governs the technical and physical safeguards for ePHI. This is where most of the engineering work lives:
If your application suffers a breach of unsecured PHI, you must notify affected individuals within 60 days, and the Department of Health and Human Services (HHS) must be notified. Breaches affecting 500 or more individuals require notification to prominent media outlets in the affected state. This rule makes security incident response planning a compliance requirement, not just a best practice.
All ePHI must be encrypted. HIPAA does not specify the exact encryption standard but references NIST guidance — in practice, this means:
HIPAA requires that access to ePHI be limited to the minimum necessary for each user to do their job. Your application architecture must implement:
HIPAA requires comprehensive audit logs that record who accessed what PHI, when, and what they did. Your application must log:
Audit logs must be stored separately from the primary database, protected from modification and retained for a minimum of 6 years under the HIPAA minimum standard (though many healthcare organisations extend this to 7 or 10 years).
HIPAA requires controls to ensure that ePHI is not improperly altered or destroyed. In practice:
Major cloud providers offer HIPAA-eligible services under a Business Associate Agreement (BAA):
Important: using a HIPAA-eligible cloud service does not make your application HIPAA-compliant. The cloud provider is responsible for the security of the infrastructure (security of the cloud). You are responsible for the security of your application and data running on that infrastructure (security in the cloud).
Every third-party vendor who accesses ePHI on your behalf must sign a BAA before you share any patient data with them. This includes:
If a vendor will not sign a BAA, you cannot use them in a context where they could access ePHI. Full stop. This is one of the most commonly overlooked compliance requirements — and one of the most common sources of violations.
HIPAA does not require perfection — it requires reasonable and appropriate safeguards given the size, complexity and capabilities of your organisation. Specifically:
At Fortmindz, we have built HIPAA-compliant healthcare applications including SpineAlly (a clinical mobile application backed by the University of Calgary) and
SweetLifeSaver (a diabetes management platform). Our standard HIPAA-compliant architecture includes:
HIPAA compliance is not a feature you add to a healthcare application — it is an architectural foundation you build on. The most expensive HIPAA projects are the ones that tried to retrofit compliance onto an architecture that was not designed for it.
If you are building a healthcare application that will handle patient data, start with compliance by design. The cost of building it right from day one is a fraction of the cost of fixing it after a breach — or a regulatory audit.
We build healthcare software at Fortmindz and understand the specific technical and operational requirements that healthcare applications demand. If you are planning a healthcare product, tell us what you are building and we will tell you what compliance will require for your specific use case.
Not necessarily. HIPAA applies to covered entities and their business associates— not to general consumer wellness apps that operate independently of the healthcare system. A step-counting app does not handle PHI. But if your wellness app connects to a healthcare provider, health insurer or health system, or processes data that could identify a patient alongside their health condition, HIPAA likely applies. When in doubt, consult a healthcare compliance attorney.
A HIPAA-compliant healthcare MVP typically takes 14-20 weeks — longer than a non-healthcare MVP due to the compliance architecture required (encryption setup, BAA procurement, audit logging, security testing). A full healthcare platform takes 6-12 months. HIPAA compliance is not what slows you down — it is the minimum viable security architecture that happens to also be HIPAA-compliant.
AWS is HIPAA-eligible, meaning it offers services that can be used in a HIPAA-compliant manner and signs Business Associate Agreements. AWS is not itself HIPAA-certified (HIPAA does not certify infrastructure providers). Your application running on AWS is not automatically compliant — you are responsible for the security of your application and how you use AWS services.
A Business Associate Agreement is a legally binding contract between a covered entity and a vendor who will access PHI on their behalf. HIPAA requires a BAA with every vendor — cloud provider, analytics platform, customer support tool — before you share any patient data with them. Without a BAA, sharing PHI with a vendor is a HIPAA violation regardless of that vendor's security practices.
Hear from our clients and why 3000+
businesses trust Fortmindz
“Essential Designs was able to create a cutting edge application that will save lives, they always say "Anything can be done" and are definitely able to deliver on that promise.”
“Essential Designs was able to create a cutting edge application that will save lives, they always say "Anything can be done" and are definitely able to deliver on that promise.”
Transformation Engineers Delivered
Game-changing Products
