HIPAA-Compliant Software Development

HIPAA compliant software development means building a system so that the organization using it can meet the HIPAA Security and Privacy Rules: every piece of protected health information (PHI) is mapped, access is limited to identified users with a reason to see it, data is encrypted in transit and at rest, every access is logged, the cloud environment is configured and contracted correctly, and the whole thing is tested and documented. No software is “HIPAA certified”, because no such certification exists. What you can build is software that makes compliance possible for its users and that you, as the vendor and likely business associate, can defend in front of a customer, an auditor or the Office for Civil Rights. This is general information, not legal advice.

What “HIPAA-compliant software” means, and what it does not

HIPAA regulates organizations, not products. Covered entities (providers, health plans, clearinghouses) and their business associates must comply. Software is compliant only in the loose sense that it provides the safeguards those organizations need and does not force them into violations. Three consequences follow.

• If your software touches PHI for a covered entity, you are a business associate. You must sign a business associate agreement (BAA) with each customer, comply with the Security Rule directly, and flow the obligations down to your own vendors, including your cloud provider.
• “HIPAA compliant hosting” and “HIPAA compliant cloud” describe a contract and a service list, not a finished system. Major cloud providers will sign a BAA and publish which services are eligible for PHI workloads. Everything above that line, from network rules to logging to how your code handles data, is your responsibility under the shared responsibility model.
• Not every health app is covered. A consumer wellness app that a person downloads for themselves, with no covered entity involved, is usually outside HIPAA, although the FTC’s Health Breach Notification Rule and state privacy laws may still apply. The moment a provider or plan uses the app to deliver care or process claims, HIPAA is in play.

The organizational side (policies, training, risk analysis, incident response) is covered in our HIPAA compliance checklist. This guide is about what the software and its environment must do.

Requirements for HIPAA-compliant software development

The Security Rule’s technical safeguards are short and technology-neutral: access control, audit controls, integrity, person or entity authentication and transmission security. The administrative safeguards add the risk analysis, contingency planning and workforce controls. Translated into engineering requirements, that gives you the following list. NIST’s SP 800-66 maps the rule to controls in more detail if you want the long version.

1. Map the PHI before writing code

Produce a data inventory and data-flow diagram: which fields are PHI (the eighteen identifiers plus any health information tied to them), where they enter (forms, uploads, APIs, HL7 and FHIR interfaces, device feeds), where they are stored (databases, object storage, caches, queues, search indexes, backups, logs), who and what reads them, and where they leave (exports, integrations, emails, notifications). Everything that follows depends on this map, and it is the first thing an auditor asks for.

2. Access control

• Unique identity for every human and service account; no shared logins.
• Role-based or attribute-based access that enforces the minimum necessary standard: a front-desk role does not see clinical notes, a billing integration does not read encounter histories.
• Multi-factor authentication for all users, enforced for administrators and remote access at minimum.
• Automatic session timeout and re-authentication for sensitive actions.
• An emergency access (“break-glass”) procedure that is logged and reviewed.
• Provisioning and deprovisioning tied to the customer’s HR events, usually through single sign-on with SAML or OpenID Connect.

3. Audit controls

Log every create, read, update, delete and export of PHI with who, what, when, from where and on whose behalf. Logs must be tamper-evident (append-only storage, integrity hashes or a write-once bucket), retained for the period your policy and contracts require, and searchable so a customer can answer “who looked at this patient’s record” in minutes. Keep PHI out of the logs: log record identifiers, not names and diagnoses.

4. Encryption and key management

Encrypt PHI in transit with current TLS everywhere, including internal service-to-service traffic and interface engines. Encrypt at rest in databases, object storage, queues, backups and on mobile devices. Use the cloud provider’s key management service, prefer customer-managed keys for production, rotate keys on a schedule and restrict who can use them. HHS guidance recognizes encryption that follows NIST standards as rendering PHI “secured”, which matters enormously in a breach assessment, so document exactly which standard you follow.

5. Integrity and availability

Protect records against improper alteration with database constraints, versioning, checksums on documents and images, and signed audit trails. Build for availability with automated backups, point-in-time restore, a tested disaster recovery runbook and defined recovery objectives, because the Security Rule’s contingency plan requirements fall on you as much as on your customer.

6. Secure development lifecycle

• Threat modeling for every feature that handles PHI, with the data-flow map as the input.
• Secure coding standards, with the OWASP Application Security Verification Standard as a practical baseline.
• Static analysis, dependency and secrets scanning in the pipeline; dynamic testing against staging; periodic independent penetration testing.
• Code review that specifically checks authorization logic, because broken access control is the most common application flaw.
• No real PHI in development or test environments: use synthetic or de-identified data under the Privacy Rule’s Safe Harbor or Expert Determination methods.
• Change management with approvals and rollback, so an auditor can trace what changed in production and why.

7. Third parties and SDKs

Every service that can see PHI needs a BAA: cloud platform, email and SMS providers, error tracking, analytics, support desks, transcription or AI services. Analytics and advertising scripts on pages that handle PHI have drawn regulatory attention; keep them off authenticated pages unless you have confirmed what they collect. Push notifications and SMS should prompt the user to open the app, never carry clinical content.

8. Mobile specifics

For HIPAA compliant app development on iOS and Android, add: encrypted local storage (the platform keystore, not plain files), biometric or PIN re-authentication, remote wipe or token revocation, no PHI in screenshots or app-switcher previews where the platform allows control, certificate pinning for API calls, and a clear policy on what is cached offline and for how long.

9. Retention, disposal and the end of the contract

Define retention periods per data type, implement secure deletion that reaches backups and replicas within a stated window, and build the export your customers will need when they leave. Media sanitization should follow NIST SP 800-88. Your BAA will say what happens to PHI at termination; the software has to be able to do it.

Architecture patterns on Azure and AWS

Both platforms will sign a BAA and both can host a HIPAA-compliant cloud workload, provided you build it correctly. Microsoft publishes its HIPAA offering details; AWS publishes its BAA and eligible-services list through its compliance portal. The building blocks map closely.

Requirement	Azure	AWS
Environment isolation	Separate subscriptions for production and non-production under a management group; Azure Policy guardrails	Separate accounts in an organization; service control policies; AWS Config rules
Identity and MFA	Entra ID with conditional access; managed identities for services; Privileged Identity Management	IAM Identity Center with MFA; IAM roles for services; permission boundaries
Network isolation	Virtual networks, private endpoints, network security groups, Application Gateway with WAF	VPC with private subnets, VPC endpoints, security groups, Application Load Balancer with AWS WAF
Encryption and keys	Key Vault with customer-managed keys; Transparent Data Encryption on Azure SQL; Storage Service Encryption	KMS customer-managed keys; encrypted RDS and EBS; S3 default encryption with bucket policies
Audit and monitoring	Azure Monitor and Log Analytics; Microsoft Defender for Cloud; Microsoft Sentinel for detection	CloudTrail with log file validation; CloudWatch; GuardDuty; Security Hub
Backup and recovery	Azure Backup with immutable vaults; geo-redundant storage	AWS Backup with vault lock; cross-region replication
Secrets and configuration	Key Vault secrets; App Configuration	Secrets Manager; Systems Manager Parameter Store
Infrastructure as code	Bicep or Terraform with policy-as-code checks	CloudFormation or Terraform with policy-as-code checks

Five patterns that hold on either platform:

1. A landing zone first. Set up the account structure, identity, logging and guardrails before the first application resource. Retrofitting isolation into a shared subscription is the most expensive mistake we see.
2. PHI in as few places as possible. One system of record, private networking between tiers, no public database endpoints, no PHI in queues or caches unless encrypted and short-lived.
3. Only eligible services on the PHI path. Check the provider’s eligible-services list for every component, including the newest AI and analytics services, and keep the list with your architecture documentation.
4. Central, immutable logs. Application audit logs, platform logs and identity logs go to one place that engineers cannot alter, with alerts on unusual access patterns.
5. Everything reproducible. Infrastructure as code plus misconfiguration scanning in the pipeline keeps production matching the documented architecture, which is what the auditor tests.

HIPAA compliant software checklist

Before the build

• PHI inventory and data-flow diagram approved by the product owner and the security lead.
• Decision recorded on whether HIPAA applies and in what role (covered entity, business associate, neither).
• BAA template reviewed by counsel; BAAs signed with the cloud provider and every subprocessor on the PHI path.
• Threat model for the initial architecture; risk register started.
• Landing zone deployed with logging, guardrails and separate environments.

During the build

• Authentication with MFA and SSO; role model implements minimum necessary.
• Audit logging on every PHI access and export, stored immutably, free of PHI content.
• TLS everywhere; encryption at rest with customer-managed keys; key rotation documented.
• Pipeline runs static analysis, dependency and secrets scanning; failing checks block the release.
• Synthetic test data only; production data never copied to lower environments.
• Session timeouts, break-glass access, and account lockout implemented and tested.
• Mobile: secure storage, re-authentication, remote revocation, no PHI in notifications.

Before release

• Independent penetration test completed; high and critical findings fixed and retested.
• Backup and restore tested end to end; disaster recovery runbook rehearsed.
• Incident response procedure written, including how and when customers are notified under the BAA.
• System description, architecture diagram and control list ready for customer security reviews.
• Integrations such as HL7 and FHIR interfaces reviewed for transport encryption and authorization.

In operation

• Quarterly access reviews; same-day deprovisioning.
• Vulnerability scanning and patching on a defined cadence; cloud configuration drift alerts.
• Annual risk analysis update; penetration test repeated after major changes.
• Subprocessor list maintained and customers notified of changes as the BAA requires.
• Retention and deletion jobs verified; termination export tested.

Where PS3G fits

PS3G designs and builds healthcare software for organizations of every size, from a founder’s first telehealth product to an integration a hospital department needs with its existing systems. Our healthcare software development team applies the requirements above from the first architecture session, on Azure or AWS, with HL7 and FHIR integration and the secure development lifecycle built into the pipeline. Our HIPAA compliance consulting covers the organizational side: the risk analysis, policies, BAAs and the evidence your customers will ask for. We also build and operate our HIPAA-compliant EHR and telehealth platform, DocVilla, so these patterns are ones we run in production ourselves.

Related reading

• HIPAA Compliance Checklist for Small Practices and Health-Tech Vendors
• Telemedicine App Development: Features, Compliance, Cost Drivers
• EHR Integration Explained: HL7 v2, FHIR and What Vendors Must Prepare
• Healthcare software development services

Frequently asked questions

Is there a HIPAA certification for software?

No. Neither HHS nor any other government body certifies software as HIPAA compliant, and a vendor claiming a “HIPAA certified” product is describing a private assessment at best. What customers and auditors look for instead is evidence: a documented architecture, a signed BAA, a risk analysis, penetration test results, audit logging and often a SOC 2 report or HITRUST assessment covering the product.

Is Azure or AWS HIPAA compliant?

Both offer a BAA and both publish the services that are eligible for PHI workloads, so either can host a compliant system. The platform’s compliance covers the infrastructure it operates. Your configuration, your identity model, your logging, your code and your vendors remain your responsibility. A misconfigured storage bucket on a compliant platform is still a reportable breach.

Does HIPAA require encryption?

Encryption is an addressable implementation specification in the Security Rule, which means you must implement it or document why an alternative is reasonable, and in practice almost no modern system can justify skipping it. Encrypting PHI to the standard HHS guidance recognizes also means that lost or stolen data is not “unsecured”, which can take an incident outside the breach notification requirement. Check the current rule text, as HHS has proposed tightening this.

Can I use third-party AI or analytics services with PHI?

Only if the provider will sign a BAA, the specific service is covered by it, and you have confirmed that your data is not used to train or improve the provider’s models unless your agreement and your customers permit it. Many consumer-grade AI tools do not meet these conditions. De-identifying data before it leaves your system is often the simpler path when the use case allows it.

How much does HIPAA add to app development cost?

Less than most teams expect when it is designed in from the start, and far more when it is retrofitted. The additional work is mostly architecture (landing zone, logging, key management), the secure development pipeline, penetration testing and documentation. Teams that build on a cloud landing zone and reuse the same patterns across products spread that cost over everything they ship.