HIPAA Security Rule: 6 Essentials for Secure Healthcare Software

The HIPAA Security Rule for Healthcare Software: What Should Be Built Into the Product

Even if a healthcare product looks to be sufficiently secure at the time of its demonstration, it can still be vulnerable when it is used on an everyday basis.

One of the employees can have more permissions than he actually needs to perform his duties. One of the administrators can fail to determine who modified a certain patient’s record. There may be a backup but it was never checked.

There may be a third-party service which manipulates health-related data but which was not sufficiently reviewed and did not enter the appropriate contracts.

That is what the HIPAA Security Rule is for. It obliges regulated organizations to implement reasonable and appropriate safeguards to ensure protection of electronic protected health information or ePHI.

For healthcare entrepreneurs and developers, it means that security should not be an afterthought that is implemented only right before product release.

What Is the HIPAA Security Rule?

The HIPAA Security Rule is a standard in the United States meant to safeguard ePHI. It is supposed to ensure the confidentiality, integrity and availability of the information.

In more practical terms:

• Confidentiality involves the protection of ePHI from disclosure to anyone else or system that does not have the authorisation to see it.
• Integrity involves the protection of information from any modification or destruction that should not occur.
• Availability entails ensuring authorised individuals are able to access the information.

The rule applies to HIPAA covered entities and their business associates. Covered entities include, among others, health plans, healthcare clearinghouses and some healthcare providers.

Business associates are any persons performing certain functions involving the use of ePHI on the behalf of covered entities.

However, an application for healthcare or wellness purposes is not necessarily a covered entity under HIPAA just because it holds health information. 

This is based on who owns the application, what it does and who it works with.

 

The Three Categories of HIPAA Safeguards

The HIPAA Security Rule organises safeguards into three categories.

Administrative Safeguards

Administrative safeguards cover the policies and processes used to manage security. They include risk analysis, workforce access, security responsibility, staff training, incident response, contingency planning and periodic evaluation.

Software cannot fulfil these responsibilities alone, but it must support them. For example, if an organisation defines different access rights for doctors, billing staff and support agents, the application needs a permission model capable of enforcing those decisions.

Physical Safeguards

Physical safeguards concern access to facilities, devices, workstations and electronic media.

They remain relevant even for cloud-based products. Staff may access patient information from shared clinical workstations, tablets, laptops or home offices. Session handling, local downloads, device security and screen exposure must therefore be considered during product design.

Technical Safeguards

Technical safeguards control how technology protects ePHI. They cover access control, audit controls, data integrity, authentication and transmission security.

These are the safeguards most visible within the software itself, but they must reflect the organisation’s policies, risk assessment and real working environment.

 

Six Essential Requirements for Healthcare Software

1. Map the Complete ePHI Data Flow

Security planning should begin with the data, not the interface.

Teams need to document where ePHI is collected, processed, stored, transmitted, backed up and deleted. This map should include more than the primary database.

Health information may also appear in:

• Application logs
• Analytics platforms
• Customer-support tools
• Email or notification services
• Temporary files
• Data exports
• Connected medical devices
• Third-party integrations

Mapping the complete data flow helps identify risks that would otherwise remain hidden and gives the team a stronger basis for architecture and vendor decisions.

2. Build Access Around Real User Responsibilities

Not every employee needs access to every patient record.

A therapist may need clinical notes for assigned patients. A billing specialist may need insurance details without seeing complete treatment notes. A support agent may need limited account information to resolve a technical issue.

Healthcare software should therefore support:

• Role-based access
• Least-privilege permissions
• Record-level restrictions
• Separate administrator controls
• Formal access approval and removal
• Automatic session expiration

Permissions must be enforced on the server side. Hiding information in the interface does not prevent an unauthorised user or system from requesting it directly.

3. Use Reliable Authentication and Session Controls

The Security Rule requires regulated entities to verify that a person or system requesting access is who they claim to be.

Depending on the organisation’s risk assessment, authentication controls may include unique user accounts, strong password policies, multi-factor authentication, secure account recovery and re-authentication for sensitive actions.

Session behaviour matters as well. The application should be able to terminate inactive sessions, revoke access after role changes and respond appropriately when credentials may have been compromised.

Security must also fit the clinical workflow. If authentication is unnecessarily slow or confusing, users may share accounts or find unsafe workarounds.

4. Create Meaningful Audit Trails

An audit trail should help the organisation reconstruct activity involving ePHI.

It should be possible to identify:

• Who accessed the information
• What they viewed, changed, exported or deleted
• When the action occurred
• Which account or system initiated it
• Whether the action was successful
• Whether a permission or role was changed

Audit logs should be protected from unauthorised modification and should not collect unnecessary sensitive content.

Logging everything without a review process is not enough. Organisations also need appropriate retention, monitoring and investigation procedures.

5. Protect Data and Preserve Its Integrity

Healthcare software must protect ePHI while it is being transmitted and stored.

Technical measures may include transport encryption, encrypted databases and backups, secure key management, protected API connections and proper secrets management.

The team should understand where encryption begins and ends, who controls the keys and when information becomes readable.

Data integrity is equally important. Server-side validation, version histories, database constraints and controlled correction processes can reduce the risk of records being improperly altered or destroyed.

For critical clinical information, silently replacing an earlier value may be less appropriate than recording who made the change, when it happened and why.

6. Plan for Vendors, Recovery and Ongoing Security

Healthcare products often depend on cloud providers, telehealth services, analytics tools, identity platforms and EHR integrations.

When a vendor creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate, a Business Associate Agreement may be required. A BAA defines responsibilities, but it does not replace technical due diligence or risk analysis.

Teams should review how each vendor handles data, subcontractors, incidents, retention and deletion.

They also need a tested recovery plan. A backup is useful only when accurate data can be restored within an acceptable period.

After launch, organisations should continue reviewing access, monitoring logs, patching vulnerabilities, testing recovery and reassessing risks when the product or its environment changes.

 

Six Essential Requirements for Healthcare Software

1. Map the Complete ePHI Data Flow

Security planning should begin with the data, not the interface.

Teams need to document where ePHI is collected, processed, stored, transmitted, backed up and deleted. This map should include more than the primary database.

Health information may also appear in:

• Application logs
• Analytics platforms
• Customer-support tools
• Email or notification services
• Temporary files
• Data exports
• Connected medical devices
• Third-party integrations

Mapping the complete data flow helps identify risks that would otherwise remain hidden and gives the team a stronger basis for architecture and vendor decisions.

2. Grant Access Based On Actual User Responsibilities

Not everyone should have access to all patient records.

Therapist needs clinical notes of their assigned patients. A billing person might need insurance information without viewing treatment notes of a patient. The customer service representative needs partial account data in order to fix a technical problem.

As a result, healthcare software should provide:

• Role-based access
• Least privilege approach
• Record-level restrictions
• Admin tools for granting/removing access and managing users
• Access request and removal process
• Session expiration feature

Permission handling should be enforced at the server level. Obscuring data from the UI does not stop an unauthorized user from requesting that same data.

3. Use Reliable Authentication and Session Controls

The Security Rule requires regulated entities to verify that a person or system requesting access is who they claim to be.

Depending on the organisation’s risk assessment, authentication controls may include unique user accounts, strong password policies, multi-factor authentication, secure account recovery and re-authentication for sensitive actions.

Session behaviour matters as well. The application should be able to terminate inactive sessions, revoke access after role changes and respond appropriately when credentials may have been compromised.

Security must also fit the clinical workflow. When there is any issue with account verification due to excessive delay or complexity, users resort to sharing accounts.

4. Create Meaningful Audit Trails

An audit trail should help the organisation reconstruct activity involving ePHI.

It should be possible to identify:

• Who accessed the information
• What they viewed, changed, exported or deleted
• When the action occurred
• Which account or system initiated it
• Whether the action was successful
• Whether a permission or role was changed

Audit logs should be protected from unauthorised modification and should not collect unnecessary sensitive content.

Logging everything without a review process is not enough. Organisations also need appropriate retention, monitoring and investigation procedures.

5. Secure Data and Maintain its Integrity

Software used in healthcare should secure electronic Protected Health Information during transmission and storage.

This can be achieved through the use of transport encryption, database and backup encryption, secure key management, and secured API connections among others.

It should be clear which part of the solution encrypts data and which decrypts it, who has access to keys and when data becomes readable.

Maintaining data integrity is also very important. Server-side validation, version history of the records, DB-level constraints and corrections can help to avoid data modification and destruction.

In case of critical clinical information, it might make more sense to track who changes data, what they change and why rather than silently overwriting it.

6. Plan for Vendors, Recovery and Ongoing Security

Healthcare products often depend on cloud providers, telehealth services, analytics tools, identity platforms and EHR integrations.

When a vendor creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate, a Business Associate Agreement may be required. A BAA outlines the obligations, but it is not a substitute for due diligence or risk assessment.

Teams should review how each vendor handles data, subcontractors, incidents, retention and deletion.

They also need a tested recovery plan. A backup is useful only when accurate data can be restored within an acceptable period.

After launch, organisations should continue reviewing access, monitoring logs, patching vulnerabilities, testing recovery and reassessing risks when the product or its environment changes. 

What Does “Addressable” Mean?

Under the current HIPAA Security Rule, some implementation specifications are described as addressable. This does not mean they can be ignored.

The organisation must assess whether an addressable measure is reasonable and appropriate for its environment. If it is, the measure must be implemented. If it is not, the decision must be documented and an appropriate alternative may be required.

This is especially important when discussing controls such as encryption. Decisions should be based on documented risk, not on the assumption that “addressable” means optional.

What About the Proposed HIPAA Security Rule Changes?

In December 2024, the US Department of Health and Human Services announced proposed modifications that would enhance the cybersecurity safeguards for ePHI.

Such areas include multi-factor authentication, asset management, network diagrams, vulnerability assessments, penetration tests, network segmentation and recovery strategies.

This is just a proposal and is not an official requirement as yet. At the moment, the HIPAA Security Rule still applies as the rulemaking process is ongoing.

Healthcare organizations need to follow the official announcements from HHS while also taking into account the new cybersecurity measures in their risk management strategy. 

Building Security Into the Product

HIPAA-oriented healthcare software is not created by adding a compliance label to a finished application.

It requires a clear understanding of the data, users, workflows, vendors and risks surrounding the product. Access controls, auditability, authentication, data protection and recovery should be planned before development begins and reviewed after launch.

AveryBit Solutions helps healthcare and wellness teams plan and develop secure digital products, including patient portals, telemedicine platforms, mental wellbeing applications, healthcare automation and system integrations.

The goal is not to apply a generic “HIPAA-compliant” label. It is to build a technical foundation that reflects the product’s real users, data flows and security responsibilities.

Planning a healthcare product that handles sensitive patient data? Talk to AveryBit Solutions about building security into the product from the beginning. 

Official Source

This article draws on publicly available guidance from the US Department of Health and Human Services, including its Summary of the HIPAA Security Rule.

Disclaimer: This article is provided for general informational purposes only and does not constitute legal, regulatory or compliance advice. Organisations should consult qualified legal and compliance professionals regarding their specific circumstances.