HIPAA compliance testing for web applications

Darya Barkova

Darya Barkova

Darya Barkova

Darya Barkova

Darya Barkova is Software Testing Engineer at ScienceSoft. Working in challenging projects featuring Healthcare, Financial Services and Retail, Darya developed expertise in functional and non-functional testing and requirement analysis. Darya’s strong analytical skills and high attention to details helped her excel in healthcare projects requiring deep understanding of UI/UX and HL7 conformance challenges in the industry.

Published:
Updated: 
5 min read

Editor’s note: Are you struggling to ensure your medical app’s compliance with HIPAA? Read on to get some tips about performing HIPAA compliance testing of web applications. And if you want to ensure that the medical app you present to the market is fully reliable and secure, turn to ScienceSoft for compliance testing services.

Health Insurance Portability and Accountability Act (HIPAA) was adopted in 1996 with the aim to protect personal health information (PHI). Any healthcare software product entering the US market must comply with it. This fostered a demand for testing medical software for HIPAA compliance.

In QA and software testing for 32 years, we’d like to share our experience in healthcare software testing and provide a look at HIPAA compliance testing of a hospital web application.

HIPAA compliance testing for web applications

HIPAA Security Rule and Project Requirements

HIPAA Security Rule requires the implementation of 3 types of safeguards:

  • Administrative
  • Physical
  • Technical

Healthcare software should only comply with technical safeguards, while administrative and physical safeguards rest upon caregivers.

Technical safeguards contain guidelines to ensure the protection of electronic PHI (EPHI) and consist of two specifications – required and addressable. For us as a testing provider, checking the compliance with both required and addressable specifications is a must, to the extent provided for by software requirements.

HIPAA compliance testing: preparatory measures

As hospital web applications feature EPHI, HIPAA compliance testing requires certain preparatory measures to prevent EPHI leaks. These measures include:

Assuring internet connection security

Though medical web applications operate in a healthcare provider’s intranet, it doesn’t guarantee security. An intranet is usually connected to the internet via several gateway computers. Thus, medical web applications become exposed to threats, such as malware and hacker attacks aimed at gaining access to EPHI.

Certainly, healthcare providers ensure a secure connection with the internet, but not all the parts of medical web applications are protected since protected pages operate slower and load longer, which may impede hospital work. Therefore, in our projects, we make sure that EPHI is not present in unprotected parts of the application and in URLs.

Drafting HIPAA compliance test matrix

Typically, medical web applications have a complex structure and provide access to EPHI according to the role-based approach. Test matrix reflecting relevant user roles and their access to EPHI will be useful to plan testing efforts. For security concerns, we substitute real EPHI by test data to include in test cases.

Minimize Your Medical App’s Exposure to Threats and Guarantee Patient Data Security!

Software testing services form ScienceSoft will help you warrant your app’s compliance with HIPAA.

The aspects we check in HIPAA compliance testing

HIPAA technical safeguards provide for different types of software. Testing hospital web applications, we concentrate on checking the following aspects:

Access control

  • Unique User Identification (required)

User identification is a unique name and/or number for identifying and tracking user identity.

  • Authentication (required)

Healthcare web applications usually follow the two-factor authentication model.

The first factor is knowledge-based and requires a login and a password. To assure security, we employ most probable negative test cases, such as an empty ID field, empty password field, invalid ID or password, expired account and blocked account.

The second factor is usually possession-based (a security token of PIN-generating software) or biometry-based. In our projects, we employ relevant test cases for positive/negative testing to verify that the application grants access to authorized users and denies it to all others. We also assure that authorized users have access only to the information necessary for work.

  • Emergency access procedure (required)

In case of emergency, access to EPHI may play a key role in saving a patient’s life. Naturally, emergency access controls are very different from those observed normally. We double-check whether the web application requires emergency access and employ a relevant user scenario to test it.

  • Automatic logoff (addressable)

Though considered addressable, this requirement is critical for protecting EPHI privacy. At ScienceSoft, we make sure the application terminates the session after a period of inactivity. Typically, this period takes up 10-30 minutes.

Audit controls (required)

This standard requires that the activities involving EPHI are recorded for further examination. For medical web applications, the standard requires detailed activity logging on a server. Our test enginers assure that activity logs record all the activities within the web application with a special focus on attempts to access EPHI. We also check that logs provide sufficient information on users’ activities when they access EPHI, i.e., the detailed description of changes made, information added, etc. Thus, we test activity logs for different types of users attempting to access EPHI.

Integrity (required)

The integrity standard requires a healthcare provider to protect EPHI from improper altering or unauthorized termination. To validate an app’s compliance with the integrity standard, we employ the controls that check for human errors and the accuracy of back-ups.

Transmission security

  • Encryption (addressable) and integrity controls (addressable)

Though both specifications are addressable, they are necessary for web applications. Users can transmit EPHI either between the back end and the front end or between systems (doctor-patient communication, emails, sharing EPHI with other healthcare providers, etc.). Whenever transmitted, EPHI must be safely encrypted, delivered to the recipient without any unintended changes and decrypted. To test secure transmission, we employ user scenarios with access to EPHI (doctors, nurses, IT professionals). When testing, we assure security for both types of transmission employing relevant user scenarios and checking data encryption at every transmission point. We compare EPHI sent with EPHI received to assure that repeated encryption and decryption didn’t alter the information in any way.

Not so black as painted

These were the essential aspects we verify in HIPAA compliance testing projects. In reality, more addressable specifications might need to be included in the testing scope. The ultimate list of aspects to be checked depends on the specifics and the purpose of a particular application. You are welcome to leverage our experience in testing healthcare applications and turn to us for assistance in defining the optimal testing scope and performing relevant HIPAA compliance testing activities.

With 16 years of experience in healthcare software testing, we will verify your application against relevant HIPAA specifications.