I spent 20 years in the Marine Corps, where mishandling classified information could end careers, or worse. So when I transitioned into building software for healthcare organizations, I was genuinely surprised by how loosely most development agencies treat patient data.
The numbers tell the story. Between 2009 and 2024, the U.S. Department of Health and Human Services documented 6,759 large-scale healthcare data breaches, exposing the protected health information of over 846 million individuals, more than 2.6 times the entire U.S. population [1]. In 2024 alone, 725 breaches of 500 or more records were reported, averaging nearly two per day [2]. This isn’t a theoretical problem. It’s an operational crisis.
And the agencies building software for healthcare providers are part of the equation. Here’s what HIPAA-compliant software actually requires, not the marketing language, but the engineering decisions backed by research.
The Real Cost of Getting It Wrong
Most conversations about HIPAA compliance start with fines. Those matter, as penalties range from $141 to $71,162 per violation, with annual caps of $2,134,831 per violation category [3]. But the real damage runs deeper.
IBM’s 2024 Cost of a Data Breach Report, conducted in partnership with the Ponemon Institute, found that healthcare remained the most expensive industry for data breaches for the fourteenth consecutive year, with an average cost of $9.77 million per incident [4]. That figure includes notification costs, remediation, regulatory fines, lost business, and reputational harm. For comparison, the financial sector, the second costliest, averaged $6.08 million [4].
But here’s the finding that should change every healthcare executive’s calculus: a peer-reviewed study by Choi, Johnson, and Lehmann published in Health Services Research found that hospitals implementing post-breach security remediation experienced measurable declines in patient care quality. Specifically, door-to-electrocardiogram times increased by as much as 2.7 minutes, and 30-day acute myocardial infarction (heart attack) mortality rates rose by up to 0.36 percentage points in the three years following a breach [5]. In cardiac care, where treatment delays of minutes affect survival, those numbers represent lives.
The lesson is clear: the time to build security into your software is before a breach forces you to bolt it on under pressure.
Encryption: Not a Checkbox, an Architecture Decision
HIPAA’s Security Rule, codified at 45 CFR §164.312, classifies encryption as an “addressable” implementation specification, which does not mean optional. Covered entities must implement encryption or document why an equivalent alternative safeguard is reasonable [6]. In practice, nearly every risk assessment will conclude that encryption is necessary for both data at rest and data in transit.
HIPAA defers to the National Institute of Standards and Technology (NIST) for encryption guidance. NIST Special Publication 800-111 covers encryption for end-user devices and data at rest, while SP 800-52 addresses Transport Layer Security implementations for data in transit [7]. The current technical baseline is AES-256 encryption for stored data and TLS 1.2 or higher (preferably TLS 1.3) for transmitted data, with cryptographic modules validated under FIPS 140-2 or its successor, FIPS 140-3 [7], [8].
If you’re using a managed database like Supabase or AWS RDS, disk-level encryption is typically enabled by default. But “typically” is not a compliance posture. You need to verify it, document it, and understand who holds the encryption keys. If your hosting provider maintains unencrypted backups on shared infrastructure, you have a compliance gap, and a liability.
Access Controls: Where Most Agencies Fail
The Minimum Necessary Standard is one of HIPAA’s most frequently cited but poorly implemented requirements. It mandates that users access only the minimum Protected Health Information (PHI) necessary to perform their job function [9]. In software terms, this means role-based access control must be enforced at the data layer, not merely at the user interface.
Hiding a navigation item in the frontend is not access control. If a patient’s records are one unauthenticated API call away from exposure, the software has failed the standard regardless of what the UI shows.
Research supports this concern. A systematic review by Seh et al. analyzing healthcare breaches from 2009 to 2019 found that unauthorized access and disclosure accounted for a substantial proportion of breach incidents, second only to hacking and IT incidents [10]. The review concluded that inadequate IT security infrastructure at healthcare organizations was a primary facilitating factor.
This is why we build with Row-Level Security (RLS) policies enforced directly in the database. A client authenticated into their portal physically cannot query another client’s records, not because the frontend prevents it, but because the database itself rejects the query. That distinction separates cosmetic security from architectural security.
Audit Logging: The Requirement Everyone Defers
The HIPAA Security Rule requires covered entities to implement hardware, software, and procedural mechanisms to record and examine access to information systems containing ePHI [6]. If a breach occurs and you cannot produce those audit logs, the investigation will be significantly more damaging.
Every operation that creates, reads, updates, or deletes PHI needs to generate an immutable audit trail: timestamps, user identifiers, action descriptions, and affected records. This is not an afterthought feature, it is a core service that runs alongside every database transaction.
The 2024 HIPAA Journal breach report noted that many hacking incidents between 2014 and 2018 went undetected for months or even years after initial compromise [2]. Comprehensive audit logging is one of the primary mechanisms for reducing detection time and limiting breach scope. IBM’s research found that organizations taking longer than 200 days to identify and contain a breach incurred average costs of $5.46 million, significantly higher than those that responded faster [4].
Business Associate Agreements: The Forgotten Dependency
This is the requirement that pure software developers often miss entirely. Under HIPAA, any third-party service that creates, receives, maintains, or transmits PHI on behalf of a covered entity qualifies as a Business Associate and must execute a Business Associate Agreement (BAA) [9].
No BAA, no compliance, regardless of how secure the code is. If your application routes appointment reminders through an email provider that hasn’t signed a BAA, or stores files on a cloud service without one, you’ve created a violation at the vendor level. Every tool in the technology stack that touches PHI needs to be evaluated and contractually covered.
The 2024 HIPAA Journal report underscored this risk: vendor-side breaches have been disproportionately large, with business associate incidents exposing over 93 million records compared to 34.9 million at direct healthcare providers in 2023 [2]. The Change Healthcare ransomware attack in early 2024, affecting a single business associate, disrupted billing and claims processing for millions of transactions nationwide and is projected to cost UnitedHealth Group between $2.3 and $2.45 billion [11].
Backup, Recovery, and Incident Response
HIPAA’s Contingency Plan standard (45 CFR §164.308(a)(7)) requires documented procedures for data backup, disaster recovery, and emergency-mode operations [6]. Your software needs automated, encrypted backups with verified recovery procedures. “We’ll figure it out if something breaks” is not a contingency plan and will not survive an OCR investigation.
You also need a documented incident response plan. HIPAA’s Breach Notification Rule requires notification to affected individuals within 60 days of discovery, and to HHS if more than 500 individuals are impacted [3]. Your engineering and operations teams should know exactly what to do before that day arrives.
A study published in the Journal of Medical Internet Research by Argaw et al. analyzed the JMIR’s own systematic review on health data protection failures across 120 articles and found that healthcare organizations remain vulnerable due to the interaction of multiple actors, including internal staff, external attackers, and inadequate vendor security, all of which a comprehensive incident response plan must address [12].
Building Compliance Into the Architecture
The agencies that treat HIPAA compliance as a phase at the end of development are setting their clients up for exactly the kind of crisis the research describes, expensive breaches followed by rushed remediation that degrades care quality.
Compliance is not a feature. It’s a foundation: encryption at the data layer, access controls in the database schema, audit logging as a core service, vendor agreements as part of procurement, and incident response as a documented procedure, all woven into the architecture from the first commit.
At Kortex Digital Labs, we approach healthcare software the same way the military approaches classified systems: assume the threat is real, enforce the boundaries at every level, and document everything. Because in healthcare, the data you’re protecting belongs to someone’s mother, father, or child. The research confirms what should already be obvious, and that is reason enough to build it right the first time.
Kortex Digital Labs specializes in HIPAA-compliant healthcare platforms, patient portals, and telehealth systems. Start a project to discuss your requirements.
References
[1] U.S. Department of Health and Human Services, Office for Civil Rights, “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,” HHS.gov. [Online]. Available: https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
[2] S. Alder, “2024 Healthcare Data Breach Report,” The HIPAA Journal, Jan. 2025. [Online]. Available: https://www.hipaajournal.com/2024-healthcare-data-breach-report/
[3] U.S. Department of Health and Human Services, “HIPAA Enforcement,” HHS.gov, 2024. [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/index.html
[4] IBM Security and Ponemon Institute, “Cost of a Data Breach Report 2024,” IBM Corp., Armonk, NY, Jul. 2024. [Online]. Available: https://www.ibm.com/reports/data-breach
[5] S. J. Choi, M. E. Johnson, and C. U. Lehmann, “Data breach remediation efforts and their implications for hospital quality,” Health Services Research, vol. 54, no. 5, pp. 971–980, Oct. 2019, doi: 10.1111/1475-6773.13203.
[6] U.S. Department of Health and Human Services, “Security Rule Guidance Material,” 45 CFR §164.312 (Technical Safeguards), §164.308 (Administrative Safeguards). [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html
[7] National Institute of Standards and Technology, “SP 800-111: Guide to Storage Encryption Technologies for End User Devices,” and “SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations,” NIST, Gaithersburg, MD. [Online]. Available: https://csrc.nist.gov/publications
[8] National Institute of Standards and Technology, “FIPS 140-3: Security Requirements for Cryptographic Modules,” NIST, Gaithersburg, MD, 2019. [Online]. Available: https://csrc.nist.gov/publications/detail/fips/140/3/final
[9] U.S. Department of Health and Human Services, “Summary of the HIPAA Privacy Rule,” HHS.gov. [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html
[10] A. H. Seh, M. Zarour, M. Alenezi, A. K. Sarkar, A. Agrawal, R. Kumar, and R. Ahmad Khan, “Healthcare data breaches: Insights and implications,” Healthcare, vol. 8, no. 2, p. 133, May 2020, doi: 10.3390/healthcare8020133.
[11] UnitedHealth Group Inc., “Q3 2024 Earnings Report: Change Healthcare Cyberattack Financial Impact Update,” Oct. 2024.
[12] S. T. Argaw, N. L. Bempong, B. Ez-Zizi, A. Aber, R. P. Rubin, A. Söderholm, and A. Flahault, “A systematic analysis of failures in protecting personal health data: A scoping review,” International Journal of Information Management, vol. 74, p. 102719, 2024, doi: 10.1016/j.ijinfomgt.2023.102719.