According to Statista, 81% of doctors and nurses used mobile devices in their professional activities in 2015, and the number is still on the rise. So is the development of hospital medical apps for doctors and nurses, which require ensuring HIPAA compliance. We already discussed HIPAA compliance testing for web applications, and luckily, for mobile applications the points to comply to are the same. It’s the very nature of mobile apps that provides for some differences in testing approach. So what are they? Let’s consider a hospital app to gain some insights into relevant mobile app testing services.
What You Will Learn
To begin with
To ensure that electronic personal health information (EPHI) is safe in a mobile app, we offer to start this kind of medical software testing with some preliminary procedures:
Performing HIPAA compliance testing, pay attention to push-notifications. This handy feature poses a potential threat of data breach, as anyone can casually see them. Assure that EPHI is never present in push notifications.
Working out role matrix
Apps for doctors and nurses, like medical web applications, should use role-based approach (RBA) to provide access to EPHI. Thus, a role matrix reflecting relevant user roles and their access to EPHI will be useful to plan testing efforts.
Creating test data
EPHI may occasionally pop up when you are testing secure data transmission, access control, etc. Therefore, you should replace real EPHI by test data to prevent data leakage when testing.
HIPAA Technical Safeguards: required and addressable
Like other healthcare software products involving EPHI, medical mobile apps should comply with HIPAA Technical Safeguards, which contain two sets of specifications – required and addressable. Testing healthcare software for HIPAA compliance, you should bear in mind that your product requirements are just as important as HIPAA Technical Safeguards. In case your product requires the implementation of addressable specifications, they should be covered with relevant test cases. If some required specification is out of your project’s scope, you shouldn’t bother about it.
Now we will specifically feature Technical Safeguards applicable to hospital apps.
- Unique User Identification (required)
User identification is a unique name and/or number for identifying and tracking user identity.
- Authentication (required)
Business-to-Employee (B2E) medical mobile apps should use two-factor authentication. The first factor is the good old login and password that you should test employing not only positive, but also negative test cases (empty login or password field, invalid login or password, etc.). As for the second factor, biometry is the best choice. Biometry saves time, as the app can check the second factor (fingerprint, retina scan, etc.) as the doctor fills in the password field.
Employ positive/negative testing to verify that the app grants access to authorized users and denies it to the others. Still, you should assure that even an authorized user has access to the minimal information required for work, but nothing else.
- Emergency access procedure (required)
Though medical apps may run on devices for personal use (the Bring Your Own Device trend), they are still work-related software, which means emergency access should be assured. Typically, emergency controls grant access to the app to the hospital IT professionals. This way IT specialists can retrieve the necessary EPHI if needed. You can test emergency access procedure applying a relevant user scenario.
- Automatic Logoff (addressable)
For hospital apps, the addressable requirement of automatic log off is a must. You should make sure the app terminates the session and forces the user to repeat two-factor authentication when left inactive for a while. In some cases developers use lock-screen password functionality to renew the session, so you should test it too.
Audit Controls (required)
For medical apps, the user’s activity should be logged only on the caregiver’s server. Just like with web applications, you should check activity logs for various types of users seeking access to EPHI. At the same time, assure that EPHI doesn’t leak to log files.
To ensure integrity, developers employ certain features protecting EPHI from unauthorized changes or deletion. These features include back-up accuracy, controls that protect the product from human and program errors that may corrupt data. You should test these features applying relevant user scenarios and log analysis.
• Encryption (addressable) and Integrity Controls (addressable)
Transmission security makes one of the key points of medical mobile apps. Whenever transmitted, EPHI must be safely encrypted, delivered to the recipient without any unintended changes and decrypted. Data encryption should be observed at all transfer points. It seems easy, doesn’t it? In fact, it’s not.
Transmission security makes the most challenging part of HIPAA compliance for an application. Mobile devices use different protocols for information exchange, including not-encrypted SMS and MMS. Other means of communication (emails, database/API calls, etc.) only work for sending EPHI in case the Internet providers are the caregiver’s business associates (HIPAA compliant 3rd party). Thus, employ positive/negative testing to assure EPHI may only be sent through business associate channels.
Mobile app security testing is critical to assure the app can resist hacking attacks, and here you cannot limit to black box or white box penetration testing alone. While black box pentesting will reveal the app’s vulnerabilities with the special focus on EPHI leakage sources, white box pentesting will examine the app’s internal structure and address possible weak points in the code. Perform both types of penetration testing to assure the app is stable and immune to hacking attacks.
Unfortunately, mobile devices often fall victims to our carelessness. Stolen, left at restaurants or cabs, mobile devices may create potential data breaches. Luckily, healthcare software developers can address this challenge employing remote wiping when a user reports the device loss. Remote wipe is a technology a network administrator or a device owner applies to delete data from a lost or stolen device. Remote wipe offers four implementations:
- Deleting data in selected folders.
- Repeatedly overwriting the data to prevent recovery.
- Returning the device to factory settings.
- Removing all the software from the device.
Simulate lost device situation and assure that a remote wipe implementation is in place.
To sum up
Though HIPAA is a large and complex document, HIPAA compliance testing for software products is based on HIPAA Technical Safeguards. The main point of HIPAA Technical Safeguards is protecting EPHI privacy, which in case of mobile apps is a challenging task. Thus, HIPAA compliance testing for medical apps should feature the following:
- HIPAA Technical Safeguards implementations for mobile apps (special focus on secure data transmission).
- Project requirements (special focus on EPHI involvement in potentially vulnerable areas of the app).
- App security (comprehensive pentesting).
- Human factor (special focus on protecting EPHI in case a device is lost).
As you can see, in medical software testing, mobile technologies make QA engineers go beyond functional requirements and imitate real-life situations to assure EPHI is protected. However, it is possible to meet this challenge applying an elaborate testing strategy.
Vast device coverage and complex functionality are key features of mobile apps. Mobile app testing services have to ensure them. That’s what we do.