How to comply with HIPAA in software testing?

Disclaimer – The article only covers major HIPAA compliance software testing areas and not elements like physical safeguards such as non-deployment of software on workstation with open screens. Also, do note that the strategy will depend on the app’s requirements, meaning it won’t be applicable for all the applications.

Healthcare organizations are falling victim to mass-scale data breach instances at an alarming rate. One notable example of this can be seen in the Yuma Regional Medical Center ransomware attack instance which exposed the data of over 700,000 individuals back in April 2022. The growing number of data breach cases is also evident from the graph below.

With the numbers getting more worrisome on an year-on-year level, medical organizations are turning towards software built with unbreachable data protection measures for storing and transmitting their medical data. The organizations are adhering to all HIPAA compliance requirements as well as spending significant time in ensuring the soundness and security of the built healthcare software. 

This puts a lot of focus on HIPAA-compliant software testing. What would happen if you don’t test healthcare software with HIPAA compliance in focus? A non compliance with the HIPAA software testing will open the application to data leaks and its illegal usage. In addition to this, it will lead to severe punishments from the US Department of Health and Human Services department.

This is the reason why it’s necessary for your healthcare software development team to spend time on building a HIPAA compliant application with increased focus on software testing.  

At Appinventiv, in our role as a healthcare software development company, we have successfully developed, tested, and deployed healthcare apps touching multiple stakeholders, without a single breach instance. 

In this article, we will discuss the various ways of checking HIPAA compliance in your application through testing. But first let us look at why building a HIPAA-compliant software is becoming increasingly difficult. 

Why is building a HIPAA compliant software difficult?

While every healthcare service provider keeps security in focus to ensure HIPAA compliance, the complexity of the sector is such that there are times when some elements remain unaddressed. Here’s what typically happens in the absence of a HIPAA compliance software checklist. 

• A lot of data to protect

Before making a structure around data protection, the developers need to have a complete understanding of what constitutes sensitive information. In the healthcare system, evaluating this can be difficult because the data are stored in different formats across multiple locations like physical storage locations, EHR systems, data centers, mobile devices, vendors’ offices, etc. 

• Lack of resources around HIPAA compliance 

Building a truly HIPAA compliant software calls for adding lawyers, system architects, cybersecurity experts, and medical experts in the team. They all contribute extensive knowledge and time in the project – something that is not always possible because of fixed healthcare app development cost and timeline. 

• Multiple data access platforms 

All the platforms in the healthcare system have to be protected with a unified security measure. However, a hospital infrastructure consists of real and digital user endpoints, data centers, servers, cloud resources, etc. to make a unified security infrastructure, it is necessary to look into MDM development for securing sensitive data. 

• Lowered flexibility 

Software built with multiple security requirements in mind can get rigid in nature however, healthcare organizations need flexibility to be able to manage patients and doctors experiences. This leads to a situation where the developers have to manage flexibility and HIPAA compliance without compromising on the healthcare experience. 

• Need to reassess HIPAA implementation 

HIPAA compliance testing doesn’t end with the application being deployed. Multiple elements like cybersecurity threats, HIPAA requirements, and the healthcare organization’s IT needs are constantly changing and to ensure your software remains compliant will need you to conduct regular audits and document updations.

Now that we have looked into the elements that make it difficult to build a HIPAA compliant app, it’s time to look into the solutions as well by looking into the areas of HIPAA compliance software testing and then the ways that answer, what is the process of HIPAA compliance testing?

Strategies and Areas for HIPAA software testing

For easy understanding, we typically divide HIPAA compliance software testing into 5 key areas. Knowing what these areas are is important to answer How do you ensure software is HIPAA compliant?

User authentication 

Typically, user authentication can be any of these – ownership-based like ID cards, knowledge-based like user id/password, and biometric based like fingerprint or face scan. Software testing on this front goes beyond ensuring a successful login path for each role and looks into – 

• Login failure due to – 
  • Empty user id and password
  • Invalid user id and password
  • Expired or blocked account
•  Locked out account
•  Login success post password change
• Login idle timeout
• Login data not stored in application memory

In addition to this, it helps to create a standard structure of the test data, for example, <PatientFirstName><PatientLastName><TestName><Date><Time>. This will help in identifying users seamlessly.

Information disclosure

Information disclosure usually works with two categories – Role-based access and Patient allocation. Under the former, users are grouped in logical classes with specific access levels and in case of latter, the supervisor assigns the patients to a health provider for a specific time. 

It will be helpful to design test cases that specify who can view/modify/add/delete information that have not been accessed to them. Additionally, you should create a practice where once the app is uninstalled all the EPHI information should be removed and deleted from the system. Proper information disclosure should be a key part of the HIPAA compliance software checklist.

Audit trails 

When looking into the audit trails part of HIPAA software testing, here are the factors that should be looked into.

• Every audit trail entry must have the following information – 
  • Date and time of action
  • Id or name of the user performing the action
  • User access level
  • The patient record id on which the action happened 
  • The action that was performed or attempted
  • The specific event from which it was performed (for example, payment or patient charting)
  • The location or system id through which the action happened 

• Entries must conform to software’s security requirements and the audit trail should be made to be easily tracked for future investigation.
• Entries must not be removed from the audit trail.
• Audit trail should be designed to be viewed by specific user accounts.
• All the attempts to breach security should be monitored in the audit trail.
• Audit trail must be encrypted.

Data transfers 

Data transfer is another key area of HIPAA compliance testing where security has to be ensured during –

• Data access between physical and mobile devices where the app is installed
• Data transfer to external device and location
• Movement of data to offline storage location.

During data transfers it is also important to note that typically the data will be encrypted (which would only get decrypted by the authorized users). Here are data encryption best practices that should be made a part of HIPAA compliance requirements. 

• Secure the encryption keys for preventing unauthorized users from using the system data.
• Encrypt sensitive data, irrespective of where it has been stored inside the system. 
• Analyze the algorithm performance during data encryption regularly.

Information of the correct data usage 

Lastly, the application should provide details of data usage before access to it. Based on the application, it could be in the form of a help page for every operation that includes EPHI or creating a training version of the app which allows users to see how the software works before giving access to the accrual EPHI. 

So here are the 5 critical areas of HIPAA compliance software testing, but how do we ensure that it is applied in the healthcare application development process?

What are the steps to achieve and maintain HIPAA compliance in software testing?

Let’s find out in our next section.

Steps to achieve and maintain HIPAA compliance in software testing

At Appinventiv, when we build a healthcare app, we make the HIPAA software requirements a part of the end-to-end development cycle, specifically testing. Here are some ways we ensure the same.

1. Access control

In line with the HIPAA compliance requirements, any user should only be allowed to access information that they need to complete a specific task. Achieving this strict-level of access control can be achieved through the following seven modes: 

• A list of access control which gives user access to specific modules/applications/areas.
• A distinctive name and number for identifying and tracking each user’s identity inside the system.
• User-driven access that requires two-factor authentication for entering the system.
• Role-driven access that depends on the users’ role for finding and deciding the access rights. 
• Context-driven access that limits the access to specific times or dates in a specific network or information system.
• Dedicated process for an emergency situation to gather critical ePHI.
• Electronic processes that will enforce automatic logoff of the electronic session after a predecided inactivity time.  
• Encrypt and decrypt the ePHI.

2. Sanity testing 

The first part of the HIPAA software testing protocol that we follow is running a sanity test where we look for defects in app’s HIPAA compliance standards. It involves looking into areas like –

• For every high-risk role or relationship, we verify if the user of a specific role is able to authenticate easily, is granted view, modification and deletion access, or zero access to specific application component operation. Once all the actions are performed, they are recorded in the audit trail. 
• Encryptions are verified for areas like audit trail entries and EPHI in the database. 

3. Roles matrix

Assuming that the app uses role-based access, it becomes important to identify the roles in the system and the level of access they can have in the application. This step is typically performed by talking to the clients who tell us the risk level based on information disclosure, the usage frequency, chance of error, and the impact of error.  

When we run sanity testing, a chart like this helps in identifying risk levels associated with every relationship and ensure that the issues are found and fixed proactively. 

4. Test cases

The third step we follow in HIPAA compliance software testing is building detailed test cases where the user movements are broken down to action and results level. Let us detail it with an example of a doctor appointment app.