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.
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:
● Administrative safeguards: security management policies, workforce training, contingency plans
● Physical safeguards: facility access controls, workstation and device controls
● Technical safeguards: access controls, audit controls, integrity controls, transmission security
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:
● Data at rest: AES-256 encryption for all databases, file storage and backups containing ePHI
● Data in transit: TLS 1.2 or higher for all API communications — TLS 1.3 is the current standard
● End-to-end encryption for any patient-to-provider messaging features
● Encrypted backups — an unencrypted backup is a HIPAA violation even if your primary database is encrypted
HIPAA requires that access to ePHI be limited to the minimum necessary for each user to do their job. Your application architecture must implement:
● Role-based access control (RBAC) — different roles see different data subsets
● Unique user identification — every user who accesses ePHI must have a unique login
● Automatic logout — sessions must time out after a defined period of inactivity
● Multi-factor authentication (MFA) — required for any access to systems containing ePHI
● Emergency access procedures — a mechanism to access ePHI in genuine clinical emergencies, with full audit logging
HIPAA requires comprehensive audit logs that record who accessed what PHI, when, and what they did. Your application must log:
● All login and logout events (successful and failed)
● All PHI access events — which records were read, by whom and when
● All PHI modifications — what changed, what it was before, who changed it
● All data exports or transmissions of PHI
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:
● Digital signatures or checksums on PHI records to detect tampering
● Immutable audit trails — audit logs that cannot be modified or deleted
● Database transaction logging to enable rollback of accidental modifications
● Backup and recovery procedures tested regularly
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.
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
