HIPAA compliance testing for web applications

IDC Health Insights reports that healthcare providers invested in IT over $5 billion in 2016, and the investments are still on the rise. So, what stops IT companies from rushing to the U.S. healthcare IT market? The thing is that a legislative Cerberus guards this market. It is called Health Insurance Portability and Accountability Act (HIPAA).

Adopted in 1996, HIPAA protects personal health information (PHI) in health facilities. Any healthcare software product entering the U.S. market must comply with it. This fostered a huge demand for testing medical software for HIPAA compliance.

So how can software testing ensure that a healthcare application complies with HIPAA? To find out the answer, let’s consider HIPAA compliance testing of a hospital web application.

HIPAA compliance testing for web applications

A silver lining of HIPAA Security Rule

Though HIPAA is an all-encompassing document, you should only focus on HIPAA Security Rule. HIPAA Security Rule covers protection of electronic PHI (EPHI) and requires the implementation of 3 types of safeguards (standards):

  1. Administrative
  2. Physical
  3. Technical

Administrative Safeguards and Physical Safeguards rest upon caregivers. Healthcare IT products should comply with Technical Safeguards only.

Technical safeguards and project requirements

Technical Safeguards are a set of technical standards applied to any software product involving EPHI. They provide guidelines to ensure EPHI protection. Technical Safeguards don’t favor any particular technology and welcome any implementation that protects EPHI.

Technical Safeguards provide two sets of implementation specifications – required and addressable. Testing healthcare software for HIPAA compliance, bear in mind that your product requirements are just as important as the legislation in question. In case your product provides for implementing addressable specifications, they should be covered with relevant test cases. Likewise, if your project requirements say nothing about secure data transmission or other required specifications, you don’t need to assure compliance with them.

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 security

Though medical web applications work in healthcare provider’s intranet, it doesn’t guarantee security. An intranet is usually connected to the internet via several gateway computers, which exposes web applications to various threats, most important being malware and hacker attacks aimed at gaining access to EHR. Thus, secure connection is a point of concern.

To ensure secure connection, healthcare providers employ HTTPS protocol. However, SSL and TSL-protected pages operate slower and load longer, which may impede hospital work. Therefore, not all parts of medical web applications are protected. Make sure that EPHI is not present in unprotected parts of the application, as well as in URLs.

Drafting HIPAA compliance test matrix

Typically, medical web applications requiring HIPAA compliance have a complex structure and provide access to EPHI on the basis of role-based approach (RBA). Test matrix reflecting relevant user roles and their access to EPHI will be useful to plan testing efforts. For security concerns, you will need to substitute real EPHI by test data to include in test cases.

HIPAA requirements for web applications

HIPAA Technical Safeguards provide for different types of software. We will specifically feature Technical Safeguards applicable to hospital web applications.

Access Control

  • Unique User Identification (required)

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

  • Authentication (required)

Medical web applications usually follow two-factor authentication model.

The first factor is knowledge-based and requires a login and a password. To assure security, you should employ most probable negative test cases, such as 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 any case, the healthcare facility should have server software to accept or deny access to EPHI. Employ relevant test cases for positive/negative testing to verify that the application grants access to authorized users and denies it to all others. You should assure that even an authorized user has access to the information necessary for work and no more.

  • 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. You should double-check whether the web application requires emergency access and employ a relevant user scenario to test it.

  • Automatic Logoff (addressable)

Though deemed addressable, this requirement is critical for protecting EPHI privacy. You should 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 information system activities involving EPHI are recorded for further examination. For medical web applications, the standard requires detailed activity logging on a server. You should assure that activity logs record all the activities within the web application with the special focus on attempts to access EPHI. Logs should also provide sufficient information on the user’s activity when he or she access EPHI, i.e. detailed description of changes made, information added, etc. Thus, you should test activity logs for different types of users attempting to access EPHI.

Integrity (required)

Integrity standard requires a healthcare provider to protect EPHI from improper altering or unauthorized termination.  Thus, controls that check for human errors and accuracy of back-ups should be employed. All the tools mentioned above should be tested with the help of relevant user scenarios and log analysis.

Transmission Security

  • Encryption (addressable) and Integrity Controls (addressable)

Though both specifications under Transmission Security standard are addressable, for web applications they are necessary. Users can transmit EPHI either between backend and frontend 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, employ user scenarios with access to EPHI (doctors, nurses, IT professionals). When testing, assure security for both types of transmission employing relevant user scenarios and checking data encryption at every transmission point. Compare the EPHI sent with the EPHI received to assure that repeated encryption and decryption didn’t alter the information in any way.

Not so black as painted

However arduous, HIPAA compliance testing is not impossible. It requires due attention and well-thought testing strategy. Here are the key points to rely on:

  1. Though HIPAA is a large and comprehensive document, HIPAA conformance for software products revolves around Technical Safeguards of HIPAA Security Rule.
  2. Addressable requirements of the Technical Safeguards, when applied to the product, make a point to comply to and should be covered with relevant test cases.
  3. HIPAA compliance implementations greatly depend on the product functionality, so your project requirements are just as important.

Hospital web applications are not the only IT solution for healthcare. Stay tuned for our blog post on HIPAA compliance testing for medical mobile apps.

Every project has its specifics in terms of functionality and target users. We offer software testing services tailored to your business needs.

Related Articles

HIPAA compliance testing for hospital mobile apps
Smart approach to healthcare software testing

Ask the Author

Sending the message ...

0/511

Sharing Information

In compliance with GDPR, your personal information will be collected and stored for five years on servers located in the Untied States. After this term is expired, your information will be erased. We will share your information with our development center, located at 2 Leanida Biady str., Minsk, Belarus, where it will be processed. At our headquarters and our development center we apply the same level of care in respect of your information as prescribed with GDPR rules. For more information, please refer to our Privacy PolicyYou may request erasing or updating your personal information here.