How to Build HIPAA-Compliant Healthcare Software

Building HIPAA-compliant healthcare software is essential for protecting sensitive patient data and avoiding costly violations. Here’s a quick summary of what you need to know:

A note on scope: HIPAA is United States federal law. It applies only to US “covered entities” (health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically) and their “business associates” — vendors and developers who handle protected health information (PHI) on a covered entity’s behalf. If you build healthcare software outside the US, or for non-US patients, other regimes apply instead — for example UK GDPR and the Data Protection Act 2018, the EU GDPR, or Canada’s PIPEDA. HIPAA becomes relevant to a non-US firm only when it processes PHI as a business associate of a US covered entity. The guidance below concerns US HIPAA obligations.

1. Understand HIPAA Rules:
   • Privacy Rule: Restricts access to patient data, enforcing the “minimum necessary” standard.
   • Security Rule: Requires administrative, physical, and technical safeguards — including access controls (RBAC), audit logging, integrity controls, and transmission security. Encryption (AES-256 for data at rest, TLS 1.2 or higher for data in transit) is currently an “addressable” specification rather than strictly mandatory. A proposed 2025 update to the Security Rule (see below) would make encryption and multi-factor authentication (MFA) mandatory.
   • Breach Notification Rule: Requires notifying affected individuals and HHS without unreasonable delay and no later than 60 days from discovery of a breach; business associates must notify the covered entity within the same window.
2. Risk Assessments:
   • Conduct regular evaluations to identify vulnerabilities in data storage, APIs, and system architecture.
   • Document risks, assign impact ratings, and create mitigation plans.
3. Technical Safeguards:
   • Encrypt all ePHI.
   • Use strong access controls with unique user IDs and session timeouts.
   • Implement tamper-proof audit logs.
4. Administrative Safeguards:
   • Appoint a security officer and ensure staff training on HIPAA policies.
   • Retain compliance documentation for at least six years.
5. Physical Safeguards:
   • Secure devices and workstations using locks, privacy screens, and restricted physical access.
6. Development Best Practices:
   • Avoid using real patient data in testing.
   • Regularly perform vulnerability scans and penetration tests.
   • Ensure third-party vendors sign Business Associate Agreements (BAAs).

Final note: Non-compliance can be expensive. Under the 2026 inflation-adjusted penalty schedule, HIPAA civil monetary penalties run on a four-tier scale up to a maximum of $2,190,294 per identical-violation category in a single calendar year, and serious cases can also carry criminal penalties. By integrating these measures into your custom web development process, you can safeguard patient data and maintain regulatory compliance.

Conducting a Risk Assessment for HIPAA Compliance

A risk assessment forms the backbone of any HIPAA compliance strategy. HIPAA has always required a risk analysis, and a proposed 2025 update to the Security Rule would require it to be performed at least annually and refreshed after significant changes — a shift that acknowledges the ever-evolving nature of threats. The assessment’s goal is to pinpoint where electronic protected health information (ePHI) is stored, how it flows, and where vulnerabilities might exist.

This process often brings up tough questions: Do outdated systems lack proper audit logging? Does your API middleware temporarily store PHI? What happens to patient data in dead-letter queues when processes fail? Pavel Kirillov, CTO at NineTwoThree AI Studio, provides a stark warning:

“If your product has evolved but your risk analysis hasn’t, you’ll fail an audit before they even look at your code”.

Identifying Risks in Software Architecture

Start by cataloguing every asset that processes or stores ePHI, then map out how data moves between internal systems and external partners. This approach helps uncover vulnerabilities, such as those in retries, logs, third-party integrations, or support tools.

Examine vulnerabilities across four states: at rest, in use, in motion, and during disposal. Pay close attention to API connections, as they are common breach points. Determine whether your middleware uses a “Data-Hoarding” model, which stores PHI at rest, or a “Pass-Through Proxy” model, which processes data only in memory. The latter significantly reduces exposure.

Legacy systems can pose significant challenges. For example, if older systems lack features like role-based access control (RBAC) or encrypted data storage, retrofitting these later can be a daunting task. It’s far better to address security requirements during the design phase rather than trying to bolt them on later. Classify your data into categories such as PHI, De-identified, Operational, or Public to apply the right level of security controls.

Documenting Risk Assessments

Proper documentation of your risk assessment is crucial, especially during OCR audits or breach investigations. Keep these records for at least six years.

Your documentation should include a detailed account of every identified threat, along with formal ratings for “likelihood” and “impact”. If you decide not to implement an “addressable” specification, provide a written explanation of why and describe any alternative measures in place. Each risk also needs a clear mitigation plan, complete with enforceable deadlines for addressing the issue.

Think of your risk assessment as a living document. Update it whenever there are significant changes to your product, new threats are identified, or your infrastructure evolves. The OCR has increased its focus on risk management and analysis, making outdated documentation a potential liability. These insights should then guide the implementation of necessary safeguards.

Using Risk Assessments to Guide Safeguard Implementation

The findings from your risk assessment are essential for deciding on technical, administrative, and physical safeguards. Misconfigured cloud storage buckets remain one of the most common causes of cloud data breaches, particularly when building AWS SaaS solutions, so automated configuration scanning and regular audits should be a priority. Similarly, given that hacking has accounted for the majority of large PHI breaches over the past decade, intrusion detection systems and multi-factor authentication (MFA) are critical.

The proposed 2025 Security Rule update — published by OCR as a Notice of Proposed Rulemaking in January 2025 and not yet finalised — would make encryption mandatory, requiring AES-256 for data at rest and TLS 1.2 or higher for data in transit, and would set fixed patching deadlines (critical vulnerabilities within 15 days and high-risk vulnerabilities within 30 days of identification). Even before any final rule takes effect, your risk assessment should document these controls and emphasise continuous monitoring rather than relying solely on periodic reviews.

Implementing Technical Safeguards for HIPAA Compliance

Protecting electronic protected health information (ePHI) requires robust technical safeguards. Under the proposed 2025 Security Rule update, encryption would become mandatory, removing its current “addressable” status. Daniel Ashcraft, Founder of Of Ash and Fire, describes the direction of travel:

“Encryption is no longer ‘addressable’ – it’s required. All ePHI must be encrypted”.

The stakes are high regardless: healthcare remains the most expensive sector for data breaches, with an average cost of $7.42 million per breach in 2025 (IBM Cost of a Data Breach Report) — the highest of any industry for the fourteenth year running. Effective technical controls, built on thorough risk assessments, are critical to safeguarding patient data. Key measures include encryption, access controls, and audit logging, forming a layered defence strategy.

Data Encryption Standards

Encryption is the backbone of protecting ePHI. For data at rest, AES-256 encryption is the recognised standard — and would be the minimum under the proposed rule — covering everything from databases to backups and temporary files. For data in transit, use TLS 1.2 or higher (the proposed rule references TLS 1.2 as the floor; TLS 1.3 is recommended where supported). Older protocols like SSLv3, TLS 1.0, and TLS 1.1 should be completely disabled. To enforce encrypted connections, enable HTTP Strict Transport Security (HSTS).

Encryption key management is equally important. Use secure tools like AWS KMS, Azure Key Vault, or HashiCorp Vault to store keys separately. Rotate keys at least once a year and consider envelope encryption for added security. Always rely on FIPS 140-validated cryptographic modules — these are also what qualify you for the breach-notification “safe harbour”.

Temporary data storage is an often-overlooked weak spot. Sensitive information can end up in cache layers, search indexes, or logs during system failures. These areas must receive the same encryption treatment as primary databases. Additionally, avoid exposing PHI in URLs or query parameters; instead, use encrypted payloads for API calls.

The next step is to secure access through strong authentication measures.

Access Controls and Authentication

Every individual accessing ePHI must have a unique identifier — shared accounts undermine accountability and should be avoided. Role-based access control (RBAC) ensures users only access the information necessary for their role, such as clinician, billing, or IT support. Multi-factor authentication (MFA) is already strong best practice and would be required for all users under the proposed Security Rule update. Modern phishing-resistant methods like FIDO2/WebAuthn keys are preferred over SMS-based codes, which are vulnerable to SIM-swap attacks.

Session management is another critical area. Set automatic logoffs based on device risk: 10–15 minutes for workstations, 5 minutes for mobile devices, and 2–5 minutes for public kiosks. For high-risk actions like role changes or bulk data exports, enforce step-up authentication. “Break-glass” emergency access procedures should include time limits, justification prompts, and supervisor notifications.

Automating access lifecycle management can streamline processes. Use “Joiner-Mover-Leaver” workflows to grant or revoke access based on HR updates. Conduct quarterly reviews of privileged accounts and deactivate dormant ones immediately. As one expert puts it:

“Strong identity is the front door.” – Accountable.

Finally, comprehensive audit trails are essential for tracking and monitoring ePHI activity.

Audit Trails and Logging

Every interaction with ePHI should be logged with six key details: Who (user identity), What (action/resource), When (timestamp), Where (source IP/device), Why (clinical purpose), and Outcome (success/failure). Crucially, these logs must be tamper-proof: if an attacker can alter or delete logs, they can erase the evidence of a breach and frustrate any subsequent investigation.

To prevent tampering, use Write-Once-Read-Many (WORM) storage solutions like AWS S3 Object Lock or Azure Immutable Blob Storage. Incorporate cryptographic hash chains (e.g., SHA-256) or Merkle trees, which link each log entry to the previous one, making any alteration detectable. Merkle trees are particularly useful for verifying large datasets efficiently.

When storing logs, only include patient identifiers or tokens, not full details. Synchronise timestamps across systems using a central time source (NTP) for accurate event tracking. Automate background checks to verify hash chains and detect sequence gaps. Logs must be retained for at least six years.

Incorporating Administrative and Physical Safeguards

Encryption and access logs are just one part of achieving HIPAA compliance. To fully secure ePHI (electronic Protected Health Information), organisations must implement administrative and physical safeguards alongside technical controls. Together, these measures create a comprehensive framework for compliance.

Administrative Safeguards

Administrative safeguards focus on processes and people. A security official must be appointed to develop and enforce HIPAA policies. This individual oversees essential activities such as conducting risk analyses, setting up incident response plans, and ensuring that only authorised personnel access ePHI. Supervision and proper documentation are key – HIPAA requires retaining all policies and training logs for six years from their creation or last use.

Keeping policies up to date and employees informed is a persistent challenge, since regulations and threats both evolve. Ongoing training is a cornerstone of administrative safeguards, ensuring that staff understand and follow the latest security protocols. This topic is explored in more detail below.

Physical Safeguards

Physical safeguards protect the spaces and hardware where ePHI is stored. This includes restricting physical access to areas like server rooms and workstations. Policies should cover proper workstation use, such as positioning monitors to prevent unauthorised viewing, and managing how devices containing ePHI are received, transported, or disposed of.

Practical steps include using privacy screen filters, securing portable devices with cable locks, and storing mobile hardware in locked cabinets. These measures reduce the risk of theft or unauthorised access.

Staff Training and Awareness

Regular training for all employees is essential to prevent HIPAA violations, which often stem from human error or vendor-related issues. Training programmes should emphasise the “minimum necessary” standard, which restricts PHI access to only what is needed for specific roles.

Key training topics include recognising phishing attempts, understanding escalation procedures, and following protocols for common security threats. Employees should also be familiar with emergency access procedures, ensuring they can access PHI securely during system disruptions. Refresher sessions are vital to keep staff informed about regulatory changes and emerging threats.

Workstation and Facility Security

Strong physical security measures complement administrative protocols. Facility access should be restricted to authorised personnel using systems like keycards, visitor logs, and surveillance cameras in sensitive areas. For workstations, policies should define acceptable use and specify physical security requirements, such as positioning and locking devices.

Automatic session timeouts on unattended workstations can prevent unauthorised access. Labelling devices aids tracking, while physical locks or barriers provide extra security for unmanned workstations. For portable devices, cable locks (e.g., Kensington locks) offer additional protection. When disposing of media, use software to securely erase data or physically destroy it through methods like shredding to ensure PHI cannot be recovered.

Developing Access Control Policies

Access control policies ensure that the “minimum necessary” standard is applied effectively. These policies map user roles to specific data needs, defining who can access what information and under what conditions. Role-based access control (RBAC) is a common approach, assigning permissions based on job functions. For instance, a doctor’s access would differ from that of a billing clerk.

Shared accounts should be avoided. Instead, unique logins should be assigned to enable accurate audit tracking. Policies should also include clear breach-notification procedures: business associates are required to notify the covered entity of a breach without unreasonable delay and no later than 60 days from discovery. Emergency access protocols, often called “break-glass” procedures, allow authorised users to access critical PHI during emergencies. All such access must be logged for later review.

Integrating Compliance into the Software Development Lifecycle

Start embedding HIPAA compliance right from the design phase. Addressing security and regulatory requirements as architectural elements — rather than afterthoughts — is consistently cheaper than retrofitting them once a system is built.

Using a Secure Development Lifecycle (SDL) framework ensures compliance is maintained throughout all stages – planning, development, testing, and deployment. Before any coding begins, conduct a HIPAA Security Risk Analysis and assign a dedicated security officer, as previously discussed. Also, secure Business Associate Agreements (BAAs) with all third-party vendors handling ePHI — a frequent gap, since many vendors are not contractually or technically ready to meet HIPAA obligations on first review. Rigorous upfront planning avoids these compliance gaps.

Secure Development Practices

During the development phase, employ tools like Static Application Security Testing (SAST) to find vulnerabilities in source code and Dynamic Application Security Testing (DAST) to detect runtime flaws. Regular peer reviews and automated checks help ensure that every code commit aligns with HIPAA technical standards. Always avoid using real PHI in development or testing environments. Instead, use synthetic or de-identified data to safeguard against accidental exposure while maintaining realistic testing conditions.

When designing APIs, take measures to prevent PHI leakage. Avoid placing PHI in URL paths or query strings, and implement consistent, non-revealing error messages. Regularly scan dependencies to identify risks in third-party libraries and pin them to secure versions. With large healthcare breaches caused by hacking up 89% since 2019 (per HHS data cited in the proposed Security Rule), these precautions are more critical than ever.

Threat Modelling and Penetration Testing

Once secure coding practices are in place, take a proactive approach by modelling threats and testing defences to uncover vulnerabilities early. Threat modelling during the design phase can identify potential breach points before they’re introduced into the system. Analyse every API endpoint and data flow to understand how unauthorised access to ePHI could occur. This early detection helps address weaknesses when they’re least expensive to fix.

Before deployment, conduct penetration tests using scenarios tailored to the healthcare sector. While current HIPAA does not mandate fixed testing intervals, the proposed 2025 Security Rule update would require vulnerability scans at least every six months and penetration testing at least annually — a useful baseline to adopt now. These tests should confirm that audit logs capture every PHI access event, including details such as user ID, timestamp, action performed, and – if applicable – the AI model version used. In 2023, a record 725 large breaches (those affecting 500 or more individuals) exposed over 133 million records in the US alone, illustrating the consequences of insufficient testing.

Change Control and Versioning

To maintain compliance during updates, enforce strict change management processes. Any major changes – whether adding new features, altering architecture, or updating AI models – must trigger a compliance review. Document all modifications, maintain version control, and provide clear timelines for migrating deprecated features.

HIPAA requires that all documentation, including training records and risk assessments, be retained for six years from their creation or last use. Automating evidence collection can significantly reduce the manual burden of audit preparation. When updating APIs, version them thoughtfully and give partners sufficient notice before implementing breaking changes. These practices, combined with earlier risk assessments and safeguards, create a continuous compliance framework that keeps your development process aligned with regulatory requirements at every stage.

Conclusion

Summary of Compliance Steps

Creating HIPAA-compliant healthcare software requires embedding security and privacy measures right from the start. Begin with detailed risk assessments to pinpoint architectural weaknesses, then implement strong technical and administrative safeguards like encryption, access controls, and regular staff training. Ensure that all third-party vendors handling electronic Protected Health Information (ePHI) sign secure Business Associate Agreements. Additionally, maintain detailed audit trails that log every interaction with PHI using tamper-proof, timestamped records. Conduct regular vulnerability scans and penetration tests to identify and address potential threats. Throughout your Software Development Life Cycle (SDLC), adopt secure coding practices, threat modelling, and enforce strict change control processes.

Non-compliance can result in hefty penalties — HIPAA civil monetary penalties reach up to $2,190,294 per identical-violation category in a single calendar year under the 2026 schedule, alongside potential criminal liability in serious cases. Moreover, large healthcare breaches due to hacking have risen by 89% since 2019. Staying vigilant not only protects patient data but also shields your organisation’s reputation. By following these steps, you can establish a robust framework for HIPAA compliance, safeguarding both your patients and your organisation.

The Benefits of Partnering with Experienced Developers

Given the intricate nature of securing healthcare software, working with seasoned developers can streamline compliance efforts and enhance security. Experienced teams design privacy-first architectures from the ground up, automate much of the audit-evidence gathering, and ensure critical features like multi-factor authentication and role-based access control are implemented correctly from the outset. This proactive approach avoids expensive retroactive fixes and ensures your software is audit-ready before launch.

Tucanoo Solutions Ltd (https://tucanoo.com) specialises in bespoke software development for healthcare organisations, offering services such as full-stack development, SaaS solutions, and mobile app development. Their expertise in building scalable, cloud-based web solutions ensures compliance is integrated throughout the development process, from initial design to deployment and ongoing support. For teams building software that touches US PHI, partnering with developers who track regulatory change while delivering secure, interoperable systems provides both technical expertise and peace of mind.

FAQs

Does my app need to be HIPAA compliant?

HIPAA applies if your app handles US protected health information on behalf of, or as, a US covered entity — for example, software dealing with Protected Health Information (PHI), Electronic Health Records (EHR), billing details, or telemedicine services for US healthcare providers or plans. In those cases, compliance helps you avoid legal penalties and maintains patient trust.

If your app does not handle US PHI, or operates entirely outside US healthcare contexts, HIPAA may not apply — though other regimes (such as UK GDPR or the EU GDPR) likely will. Carefully evaluate how your app interacts with PHI, and in which jurisdiction, to determine which obligations apply to you.

What counts as ePHI in software systems?

ePHI (electronic protected health information) refers to any individually identifiable health information that a US covered entity or business associate stores or transmits in digital format. This can include information managed in EHR systems, billing software, or telemedicine platforms. Because these systems deal with highly sensitive patient information, they fall under HIPAA’s privacy and security requirements.

How do I prove HIPAA compliance in an audit?

To demonstrate HIPAA compliance during an audit, your healthcare software must align with all applicable regulations and security protocols. Keep thorough records of your compliance activities, such as documented policies, procedures, and implemented technical safeguards. Ensure you can provide evidence of key measures, including risk assessments, staff training programmes, access control mechanisms, audit logs, and data encryption practices. Regularly review and update both your documentation and security measures to show consistent commitment to HIPAA standards.