Healthcare Software Development: What HIPAA Actually Demands From Your Code

HIPAA compliance gets framed as a legal exercise. It isn’t, mostly. The vast majority of HIPAA compliance for a healthcare application is engineering work: specific technical controls that have to exist in your codebase, your infrastructure, your deployment pipeline, and your operational monitoring. Lawyers can help with policy and Business Associate Agreements; they can’t write the encryption, build the access control system, or stand up the audit logging. The compliance lives in the code, and the proposed 2025 update to the HIPAA Security Rule, if finalized, would make that distinction even more concrete than at any point since the rule was first written in 2003.

The shift is real but still pending. On January 6, 2025 the HHS Office for Civil Rights published a Notice of Proposed Rulemaking to modernize the HIPAA Security Rule, the first substantial update proposed in over a decade. As of mid-2026, the proposal remains proposed: the comment period closed in March 2025, OCR is still reviewing comments, and the current Security Rule (in effect since 2013) remains in force. HHS itself states explicitly that the current rule continues to apply during this rulemaking. If finalized as proposed, the HHS fact sheet describes engineering implications that are significant: the proposed rule would remove the distinction between “required” and “addressable” implementation specifications and make all of them required. Encryption would become a baseline rather than a recommendation. Multi-factor authentication would move from common practice to mandatory across all ePHI access. Annual penetration testing, network segmentation, and specific operational timelines (including 72-hour data restoration after an applicable event) would become controls regulators verify, not just policies you document. The compliance bar would rise meaningfully; the work to clear it would be in the code, not the contract.

Here’s what HIPAA actually requires from your code today, what the proposed 2025 update would change if finalized, and what the engineering work looks like for any healthcare software development project being scoped right now.

Key Takeaways

• HIPAA compliance for software is mostly engineering work, not legal work. The technical safeguards are your developers’ responsibility, not your lawyers’.
• The 2025 HIPAA Security Rule NPRM remains proposed as of mid-2026. The current Security Rule (in effect since 2013) still applies. If finalized, the proposal would remove the ‘addressable’ flexibility and make encryption, MFA, and other technical controls explicit requirements.
• Six technical safeguards define HIPAA engineering work today and would tighten further if the NPRM is finalized: encryption at rest and in transit, MFA for ePHI access, unique user identification with RBAC, comprehensive audit logging, annual penetration testing, and network segmentation.
• Audit logs are compliance artifacts under 45 CFR §164.312(b). HIPAA’s general documentation retention requirement under §164.316(b)(2)(i) is six years; how that applies to specific audit log content is often guided by enterprise risk analysis, and some state laws (especially around medical records) require longer.
• HIPAA compliant app development costs typically run 25% to 35% above non-regulated equivalents. Healthcare app cost ranges from $80K for basic apps to $500K+ for enterprise EHR integrations.
• Business Associate Agreements (BAAs) extend compliance obligations to every third-party vendor touching ePHI. Verify BAA capability before any vendor integration, not after.
• EHR software development requires not just HIPAA compliance but also integration with Epic, Cerner, or similar systems via HL7 v2 or FHIR APIs. The integration layer is its own compliance scope.

Why HIPAA Compliance Lives in Your Code

Most healthcare software development guides treat HIPAA as a checklist of policies and procedures, with technical implementation as an afterthought. That framing dramatically underestimates the engineering burden. The HIPAA Security Rule’s Technical Safeguards section (45 CFR §164.312) names specific code-level requirements: access control, audit controls, integrity controls, person or entity authentication, and transmission security. Each of these is built, configured, and operated by engineering teams, not by lawyers or compliance officers.

The 2025 NPRM, if finalized, would sharpen this distinction further. The HHS fact sheet on the NPRM makes clear that the proposed rule would move from documented intent to proven technical enforcement. Where today a covered entity can argue that encryption is “not reasonable and appropriate” for their specific context under the current ‘addressable’ framework, the proposed rule would eliminate that flexibility. Encryption would be required. Multi-factor authentication would be explicitly required. Audit logging is already required under the current rule, but the proposal would also require active log review. Penetration testing would become a named requirement with explicit cadence. Until the NPRM is finalized, the current Security Rule’s framework governs; in practice, mature healthcare engineering teams are scoping toward the proposal’s direction because OCR’s enforcement focus already reflects the same priorities.

Definitive scope questions about regulatory obligations should always involve qualified healthcare compliance counsel; this article covers the engineering implementation, not the legal interpretation. But the engineering implementation is where the bulk of the work, the budget, and the risk of audit failure actually live.

The Six Technical Safeguards That Define HIPAA Engineering Work

Across the current HIPAA Security Rule, the proposed 2025 NPRM, and decades of OCR enforcement patterns, six technical controls determine whether a healthcare application meets the engineering bar. Each one is engineering work; each one has to be implemented before a HIPAA compliant app development project ships, not retrofitted before an audit. For each safeguard below, we note what the current Security Rule requires and what the proposed 2025 NPRM would change if finalized.

1. Encryption at rest and in transit

What it requires: All ePHI encrypted whenever stored (databases, file systems, backups, log files, cache) and whenever transmitted (HTTPS for all client-server traffic, TLS for service-to-service, encrypted message queues, no plaintext ePHI in URLs or query strings).

What the 2025 NPRM would change if finalized: Encryption is no longer “addressable.” The proposed rule removes the flexibility to skip encryption based on risk analysis. Encryption is mandatory across all systems handling ePHI, including development and staging environments where production-like data exists.

Engineering implementation: Database-level encryption (Transparent Data Encryption, column-level encryption for highly sensitive fields), encrypted backups, AES-256 for files, TLS 1.2+ for all transport, encrypted secret storage in vaults (HashiCorp Vault, AWS KMS, Azure Key Vault). Encryption keys themselves managed in HSMs or managed KMS services, with rotation policies and access controls.

2. Multi-factor authentication for ePHI access

What it requires: Multi-factor authentication for any user accessing systems that contain or process ePHI, including administrators, developers, and integrated third-party systems.

What the 2025 NPRM would change if finalized: MFA moves from “strongly recommended” to explicitly required across all access points. The proposed rule expects MFA for cloud consoles, applications, administrator accounts, and any path to ePHI; not just user-facing login.

Engineering implementation: MFA-ready authentication built into the application architecture from day one, not bolted on. Standard approaches: TOTP (Google Authenticator, Authy), WebAuthn / passkeys, push-based authentication via managed identity providers (Okta, Auth0, Azure AD, AWS Cognito). Avoid SMS-based 2FA as a primary factor where higher-assurance options are available.

3. Unique user identification with role-based access control

What it requires: Every system user has a unique ID; no shared accounts. Every action touching ePHI traces back to an individual. Access follows minimum-necessary principles via role-based access control (RBAC), with users only seeing the ePHI relevant to their role.

What the 2025 NPRM would change if finalized: The rule clarifies that the unique-ID requirement extends to service accounts, database connections, and API keys. Shared credentials in any form are non-compliant. The minimum-necessary standard is verified in audits, not just documented.

Engineering implementation: Identity-aware proxies, named service accounts with rotation, RBAC enforced at the application layer and at the database layer where possible. Common implementation patterns: Auth0 / Okta / Azure AD for human identity, IAM roles for service identity, attribute-based access control (ABAC) for finer-grained authorization, all-or-nothing access deprecated.

4. Comprehensive audit logging

What it requires: Every access to ePHI logged with user identity, timestamp, action taken, data accessed, and result. HIPAA’s general documentation retention requirement under 45 CFR §164.316(b)(2)(i) is six years for HIPAA-related documentation; how that applies specifically to audit log content varies by organization and is often guided by enterprise risk analysis, with some state laws (particularly for medical records) requiring longer. Logs themselves protected from tampering and reviewed regularly for anomalies.

What the 2025 NPRM would change if finalized: Audit log review becomes an active control, not a passive one. The proposed rule expects evidence of regular log review, anomaly detection, and incident response triggered by log analysis. Dumping events to a log file nobody reads doesn’t satisfy the requirement.

Engineering implementation: Structured logging (JSON), centralized log aggregation (Splunk, Datadog, ELK, AWS CloudWatch, Azure Sentinel), immutable storage for compliance logs, automated anomaly detection rules, defined log review cadence. The same governance principles we apply when auditing AI agents extend directly to healthcare audit trails: every action traceable, every actor identifiable, every approval verifiable.

5. Annual penetration testing and vulnerability scanning

What it requires: Annual penetration testing by qualified third parties, ongoing vulnerability scanning, and documented remediation of findings.

What the 2025 NPRM would change if finalized: Penetration testing becomes a named requirement with explicit cadence, rather than an addressable best practice. Scans alone are no longer sufficient; the proposed rule expects adversarial testing.

Engineering implementation: Annual pen testing scoped to the entire ePHI surface (web apps, APIs, mobile apps, integrations, cloud configuration), with documented remediation timelines. Continuous SAST and DAST in CI/CD, SCA for dependency vulnerabilities, network vulnerability scanning, and a defined process for prioritizing and remediating findings by severity.

6. Network segmentation and incident response

What it requires: Network architecture that segments ePHI systems from general-purpose infrastructure, limiting lateral movement in the event of a breach. Documented incident response procedures and the operational capacity to detect, classify, and respond to security incidents on tight timelines. The proposed 2025 NPRM specifies, among other things, written procedures to restore critical electronic information systems and data within 72 hours of an applicable event (a data restoration timeline rather than a generic incident response window), and 24-hour business associate notification when a contingency plan is activated.

What the 2025 NPRM would change if finalized: Network segmentation would become an explicit requirement at 45 CFR §164.312, rather than an implied component of “reasonable and appropriate” security. The proposal also adds specific operational timelines: written procedures to restore critical systems and data within 72 hours of an applicable event, and 24-hour business associate notification when a contingency plan is activated. Teams scoping for the proposed rule need detection, classification, and restoration infrastructure that can meet these timeframes; teams operating under the current rule still need the same controls in practice, just without the named timeframes named in regulation.

Engineering implementation: Network segmentation via VPCs, subnets, security groups, and service meshes. Zero-trust network architecture where possible. Documented incident response playbooks, automated alerting for ePHI-relevant security events, breach classification criteria, and notification workflows. The disciplines we apply across our work on AI implementation challenges surface here too: modern security controls break when retrofitted onto legacy architectures.

The Six Safeguards at a Glance

The table below summarizes the six technical controls, their status under the current rule and the proposed 2025 NPRM, and the engineering work each one requires.

Healthcare App Cost: What HIPAA Compliance Adds to the Build

Compliance scope changes the cost structure of healthcare engineering meaningfully. From our delivery experience, healthcare app cost typically runs 25% to 35% above the equivalent non-regulated application, because every architectural decision has to account for encryption, access control, audit logging, and compliance verification. The table below shows the typical cost bands we see across healthcare engagements.

These are illustrative bands from our delivery experience and broader industry data, not industry-wide benchmarks. The real number depends on the scope of ePHI handling, integration complexity (Epic, Cerner, Allscripts, athenahealth all carry different integration costs), and the maturity of the compliance posture being designed.

EHR Software Development: The Integration Layer That Adds Its Own Compliance Scope

Most modern healthcare applications don’t operate in isolation; they integrate with existing electronic health record systems. EHR software development therefore extends the HIPAA scope to the integration layer, where each connected system, message format, and API surface carries its own compliance requirements.

The current integration landscape in 2026:

• HL7 v2 messaging remains widespread in hospital environments; older but well-supported, requires specific message-level encryption and integrity checking.
• FHIR (Fast Healthcare Interoperability Resources) has become the modern standard for new integrations; REST-based, JSON-friendly, well-supported by Epic, Cerner, athenahealth, and other major EHRs.
• Epic’s App Orchard and Cerner’s Code Cloud (Oracle Health) are the certified-integration paths for major EHR connections, with specific HIPAA and operational requirements.
• Bulk FHIR APIs for population-level data access, with their own access patterns and rate-limiting considerations.
• Direct database integrations (legacy approach) typically require Business Associate Agreements with the EHR vendor and meaningful security review; modernization to FHIR is usually the right path.

Integration with legacy EHR systems often runs into the same patterns we examine in our legacy application modernization engagements: outdated authentication, inconsistent data models, weak audit trails on the source side. The modernization work is sometimes a prerequisite to clean HIPAA compliance, not a separate concern.

Where Healthcare Software Compliance Actually Breaks

From our delivery experience across healthcare engagements, compliance failures cluster around a small number of recognizable patterns. Each one is preventable with the right engineering discipline at the architecture stage.

Plaintext ePHI in development or staging environments

Production ePHI gets encrypted; development environments often use real production data that nobody encrypted because “it’s just dev.” The proposed 2025 rule would explicitly extend encryption requirements to development and staging environments where production-like data exists. Even under the current rule, using unencrypted production data in dev environments is generally treated as a compliance failure under risk analysis principles. The fix is synthetic data or properly anonymized data sets for non-production work, with the same encryption posture as production.

Audit logs that nobody actually reviews

Audit logging exists; review processes don’t. OCR investigations consistently find that audit logs are written but not actively monitored. The fix is structured anomaly detection, named owners for log review, and documented response procedures for flagged events.

Service accounts and API keys treated as exceptions

Human users have unique IDs and MFA; service accounts share credentials and rotate rarely. The proposed 2025 rule would clarify that unique-ID requirements apply to all credentials, including service accounts and API keys; even under the current rule, shared service credentials raise risk-analysis concerns and surface frequently in OCR audits. The fix is named service identities, vault-managed secrets, mandatory rotation, and CI-level secret scanning.

BAA gaps with third-party vendors

Healthcare applications integrate with dozens of third-party services: analytics, email providers, payment processors, cloud services, monitoring tools. Each one that touches ePHI requires a Business Associate Agreement. Gaps in BAA coverage are common compliance failures; the fix is a documented BAA inventory across all vendor relationships, refreshed at every contract renewal.

Compliance retrofitted before audit, not designed in from day one

Teams that treat HIPAA as documentation work added six months before audit consistently discover that retrofitting encryption, access control, and audit logging into an existing codebase costs multiples of designing them in from the start. The fix is compliance-by-design from sprint one, with architecture decisions reviewed against the technical safeguards before implementation begins.

When a Full HIPAA Build Is the Wrong Investment Right Now

Not every healthcare-adjacent project needs a full HIPAA build. Here is when we tell teams to wait or scope differently.

You’re not actually handling ePHI. Wellness apps, fitness trackers, and general health information tools often don’t touch ePHI in the legal sense. If protected health information genuinely isn’t in scope, HIPAA may not apply, and the compliance investment may be unnecessary. Verify with qualified counsel before assuming HIPAA applies.

The product hasn’t been validated. Building a HIPAA-compliant prototype to test whether anyone wants the product wastes 25% to 35% of the budget on compliance for a product that may never ship. Run discovery first with de-identified or synthetic data; commit to HIPAA scope once the product hypothesis is validated.

You don’t have an internal compliance owner. HIPAA compliance requires ongoing organizational capacity: policy maintenance, incident response, BAA management, audit responses. Building a HIPAA-compliant application without naming an internal owner produces a maintenance gap that surfaces in an audit or breach.

The underlying data foundation can’t support it. HIPAA compliance breaks on poor data foundations: fragmented patient records, inconsistent identifiers, weak audit trails on source systems. Sometimes the right next step is fixing the foundation, not building on top of it. The pattern parallels what we cover in AI implementation challenges: modern compliance requirements break on architectures that weren’t built for them.

How Ariel Approaches Healthcare Engagements

From our delivery experience across healthcare engagements in clinical workflow, patient engagement, telemedicine, and EHR integration, healthcare software development produces clean compliance outcomes when the technical safeguards are designed in from sprint one rather than retrofitted before audit. The engagements that pass OCR scrutiny share a small number of disciplines, regardless of application type.

The operating principles we apply across every healthcare engagement are:

• Compliance designed into architecture from sprint one. Encryption, access control, audit logging, and incident response built into the platform foundation, not bolted on before audit.
• Synthetic or de-identified data in non-production environments. Production-like data quality without HIPAA exposure during development and testing.
• Named compliance ownership on both sides. Internal compliance owner on the client side, dedicated compliance lead on our delivery side, with regular alignment meetings.
• BAA inventory and verification before any vendor integration. Every third-party service touching ePHI verified, BAA in place, and reviewed at contract renewal.

Across healthcare applications, the throughline is consistent: teams that treat HIPAA as engineering rather than paperwork produce systems that survive audits and breach scenarios; teams that treat it as documentation produce expensive remediations.

Frequently Asked Questions

1. What does HIPAA actually require from healthcare software development?

Healthcare software development under HIPAA centers on six technical controls: encryption of ePHI at rest and in transit, multi-factor authentication for systems accessing ePHI, unique user identification with role-based access control (including service accounts), comprehensive audit logging with active review, annual penetration testing and vulnerability scanning, and network segmentation with documented incident response procedures. Under the current HIPAA Security Rule (in effect since 2013), several of these (including encryption) are ‘addressable’ rather than strictly required, and the framework relies on risk analysis to determine implementation. The proposed 2025 NPRM, if finalized, would remove the ‘addressable’ flexibility, make these controls explicit requirements, and add named timelines (including 72-hour data restoration after an applicable event). These are engineering implementations, not policy documents.

2. How much does HIPAA compliant app development cost?

HIPAA compliant app development typically costs 25% to 35% more than equivalent non-regulated applications. Basic patient-facing HIPAA-compliant apps run $80K to $200K with $30K to $60K in compliance work. Telemedicine platforms run $150K to $400K. Clinical workflow applications run $200K to $600K. Enterprise EHR integrations run $300K to $1M+ with $100K to $250K in compliance scope. Ongoing annual costs (audit, monitoring, maintenance) run 25% to 40% of build cost. These are illustrative bands from our delivery experience, not industry-wide benchmarks.

3. What is the typical healthcare app cost in 2026?

The typical healthcare app cost depends on complexity and HIPAA scope. Simple patient-facing apps with basic ePHI handling run $80,000 to $200,000. Telemedicine with video, messaging, and clinical integration runs $150,000 to $400,000. Clinical workflow applications run $200,000 to $600,000. EHR-integrated platforms run $300,000 to over $1 million. AI-powered diagnostic or decision-support applications run $250,000 to $800,000+. Total first-year cost typically runs 120% to 140% of the build estimate when ongoing compliance, monitoring, and infrastructure are included.

4. What does EHR software development actually involve?

EHR software development extends HIPAA scope to integration with major electronic health record systems (Epic, Cerner / Oracle Health, athenahealth, Allscripts). The technical work includes HL7 v2 messaging for legacy hospital environments, FHIR APIs for modern integrations, certified integration paths through Epic App Orchard or Cerner Code Cloud, bulk FHIR for population-level data, and direct database integrations where modernization is in scope. Each integration carries its own compliance scope: BAAs with the EHR vendor, encryption at the integration boundary, audit logging for every ePHI exchange.

5. What is the status of the proposed 2025 HIPAA Security Rule update?

On January 6, 2025, HHS published a Notice of Proposed Rulemaking (NPRM) to modernize the HIPAA Security Rule. The comment period closed March 7, 2025. As of mid-2026, the NPRM remains proposed; OCR is still reviewing comments and the current Security Rule (in effect since 2013) remains in force. HHS’s regulatory agenda targeted May 2026 for finalization, but that window has passed without action. The proposal could be finalized as written, modified, delayed, republished, or withdrawn. If finalized as proposed, the rule would remove the ‘addressable’ designation and make encryption, MFA, network segmentation, annual penetration testing, and specific operational timelines (including 72-hour data restoration after an applicable event and 24-hour business associate notification when a contingency plan is activated) explicit requirements. Until the rule is finalized, the current Security Rule governs; in practice, mature healthcare engineering teams are scoping toward the proposal’s direction because OCR’s enforcement focus already reflects the same priorities.

6. Can Ariel help us build a HIPAA-compliant healthcare application?

Yes. We help healthcare teams design, build, and deploy HIPAA-compliant applications with technical safeguards engineered in from sprint one rather than retrofitted before audit. The review covers your ePHI surface, integration scope, compliance posture under the current Security Rule, and your readiness for the proposed 2025 NPRM if finalized. Definitive scope questions about regulatory obligations always involve qualified healthcare compliance counsel. Get in touch for a delivery-grade conversation about your healthcare application.

The Code Behind the Compliance

Effective healthcare software development in 2026 isn’t about producing the right documentation. It’s about implementing the right technical controls in your codebase, your infrastructure, and your operational discipline. The current HIPAA Security Rule already centers on six technical safeguards (encryption, MFA, unique IDs with RBAC, audit logging, penetration testing, network segmentation) in some form. The proposed 2025 NPRM, if finalized, would tighten the bar by removing the ‘addressable’ flexibility, naming specific operational timelines, and extending requirements to service accounts and non-production environments. Either way, the compliance lives in the code, and the engineering team owns the work.

Design encryption into the architecture from sprint one. Build MFA-ready authentication. Use named identities for every service account and API key. Aggregate and actively review audit logs. Run annual pen tests with documented remediation. Segment the network around ePHI. Maintain BAAs with every vendor in scope. The teams that get healthcare compliance right are the ones where the technical safeguards are properties of the platform, not paperwork added before audit.