When the quality of software directly impacts someone’s life, the role of QA becomes that much more crucial.
Digital transformation in healthcare is one of the great breakthroughs in the healthcare and diagnostic industry. The physician getting the diagnosis right is the first step towards providing an accurate interpretation of the patient’s health problem based on which the subsequent decisions are made. Healthcare software applications play a significant role in processing relevant patient information, storing patient records, retrieving patient history, insurance information, and so on, in a holistic and purposeful way. Patients get treated easier, know their body better and trust the software and their assessments so much so, that they base their next visit to the physician if the reading on their device goes above or below normal.
So what if a device shows a normal reading when the patient’s blood sugar level has risen above normal? What if a healthcare billing application shows that a subscribed insurance is invalid for a premium user? Think of the physical and mental stress these malfunctions would cause the patients apart from the disease itself. It is harrowing. Keeping in mind these dire consequences, it is necessary that healthcare software applications or health devices are tested with unparalleled thoroughness.
Following are the strategies and the keys to building a compliant, secure, and fault free healthcare application:
Regulatory Compliance for HC Applications and their Quality Assurance
Stolen medical data costs more than $20, even more than credit card data. It is a standard that all healthcare apps in the US should be compliant with the HIPAA regulations. If a company knowingly neglects the HIPAA regulations and delivers a healthcare application to the market, the government has the authority to levy a fine of $50,000 or more and the patients affected could sue you in court too.
The following are the few ways to confirm if your healthcare app is HIPAA compliant.
1.Access Control
A healthcare app should restrict who should view the Patient’s health information — PHI — which contains the patient’s personal information such as name, address, birth date, SSN, photographs, and medical history. Providing a privilege id for each user role id, performing actions such as creation, read, update, and delete on the PHI records is one way to provide access control. With this unique user id/privilege id combination, a physician might have the privileges 1, 2 and 3 which gives him access to create, read and update a record, whereas a lab administrator role which is mapped to a privilege id of 2, can only read the patient record. Grouping of this concept gives us role-based access control which provides specific access to role groups such as physicians, administrators, technicians. All these rules are thoroughly understood by the QA, formed a matrix, and tested rigorously to confirm if they are working as expected. These flows are automated and the scripts check the access controls on a daily basis to determine if a fix in an associated functionality has caused this critical functionality to malfunction.
2. Mode of Authentication:
The next step is to make sure that the person who accesses PHI is actually who he claims to be. This can be done in several ways as prescribed below:
- Biometric access & Passwords
- Two-factor authentication where a one-time password SMS is sent to the registered mobile number of the user trying to login.
- Even authentication can be bypassed by hackers when they steal your sessions by getting in between the authentication from the user’s device and the application server. This can be prevented by a digital signature wherein a password entry is required.
QA should have a robust list of scenarios to check for any loopholes that the developers might have overlooked and ensured that the authentication mode is foolproof.
3. Transmission Security:
We need to make sure that all communication between the client and the server happens through HTTPS — especially for those pages transmitting Patient information & authorization cookies. HTTPS is a secure communication protocol that transfers sensitive data after encrypting them. This encrypted data is useless even in the hands of a hacker without the decryption key. The encryption is done with SSL cryptographic protocol. Also, in order to send and receive files, usage of secure file transfer mediums such as FTPS or SSH should be mandated. Instead of Gmail, a secure mail client such as Posteo should be used. The QA should be proficient in using tools such as SSL labs or SSL checker which can identify all the latest vulnerabilities/misconfigurations in the application.
4. Disposal of PHI:
When a particular PHI is not required, it is best to dispose of it permanently and in a way that it cannot be recovered. There have been cases in the US, for example with Affinity Health Plan, a U.S. based care plan provider, which had to settle $1.2 M in fines for the data leak from its outdated photocopier that had been released for scrap.
5. Backup storage of sensitive data:
This is to save you from the worst-case scenario. If your database gets corrupted, or your server crashes, it could easily affect and erase the valuable PHI in your system. So it is important to store the information in several different places. All the high and medium risk information should be backed up on a daily basis and stored securely. And remember, a backup is worthless if you do not have a restoration plan. QA should test these negative scenarios to bring down a server and validate if the recovery management happens as expected.
6. Audit logs and Monitoring:
If there are no audit logs monitoring your healthcare system, then that could cause your organization to be fined! Periodic auditing of the recorded logs should be done by QA to validate their accuracy in logging the activity, related information, and the time at which they were performed. Logging can either be done through a separate table in the database or by means of a log file.
7. Automatic Logoff:
A system that handles PHI should automatically terminate a session after a period of inactivity. Once the logoff is successful, the mode of authentication described above should take effect before allowing the user to again view or act on sensitive information.
Automatic logoff can be implemented as 2 to 3 minutes for a mobile app. For a web application, it should not exceed 10 minutes.
8. Mobile Apps & additional security features:
When a healthcare app with sensitive information is on a mobile device there are additional security risks that come into the picture. The device could be easily stolen or might not be locked with a password/fingerprint. Of course, there is no way to mandate the users of your app to use these on their device, but the least we could do is intimate them constantly about what it could mean if the data was stolen and make them keep their phone safe and secure. The app developers could use the welcome/onboarding emails, or send a separate email informing the same.
9. No Push Notifications:
Push notifications aren’t secure by default and hence it is best to configure the app to not send any PHI as push notifications.
10. Use secure messaging services for communicating PHI:
Instead of using smartphones to communicate PHI, physicians and patients should make use of secure portals.
The above are the minimum requirements for making your website/mobile app HIPAA compliant. Although this might not be enough to prevent a phishing attack to steal data, it would definitely be enough if an auditor checks for compliance regulation features to provide approval.
The crucial role of testing in Healthcare applications:
In order to confirm that the PHI is protected from stealth & is truly private, generous amounts of security testing, revamping of the code to root out the flaws is imperative. Payoda QA runs security checks for mobile apps, websites, APIs, and cloud-based applications using Industry standard tools. We use ethical hacking techniques to find out existing vulnerabilities and confirm your software to be hack-proof before your end users get to use it.
Our key areas in terms of Healthcare system testing center around data management, data confidentiality, usability, automation of functional workflows, and performance testing. We provide end to end test coverage, HL7 standards testing, and verify and validate the functional requirements with great thoroughness. Our testers are primed to implement out of the box thinking and effective testing strategies. We do compatibility testing, volume testing, load testing, stress testing, interoperability testing, functional testing and automation, UI / Usability testing, regression testing, regulatory compliance testing, security testing, API testing, and automation and Acceptance testing. We assure you, that a combination of all these testing practices will help your company’s mobile app/web application to stand apart from the rest in terms of quality, usability, performance, and security.
A note on our Security Testing methods and expertise:
We try to pre-empt and prevent by providing a comprehensive statement about all the issues that are affecting or might affect your software in the future. We perform Threat modeling, Denial of Service attack related testing, Authentication Testing, Penetration Testing, Session Management Testing, Compliance Testing, Security standards testing, Data validation testing, Vulnerability assessment, network testing, and code review to check for other security flaws.
Our security testing experts are experienced and have proven their mettle by testing and perfecting several applications across various domains such as healthcare, e-commerce, banking and finance, insurance, social media, and entertainment and networking. Our holistic approach towards testing, regular feedback mechanisms, risk analysis, and mitigation processes, knowledge of compliance standards, owning a wide range of licensed and open-source security tools will make a huge difference in terms of the kind of secure product you deliver to the market.
Attacks that can be prevented with a Superlative Security Testing Service:
The following security attacks can be prevented if continuous security testing is done.
Do not forget that there is no such thing called ‘a good time to do security testing’. The hackers are always out there and they are waiting for an opportunity for you to kick back and relax. We need to be two steps ahead and not give them that window of opportunity. Apart from continuous security checks, instances when there is a new deployment when a new network is added to the system or is integrated with a central system, security patches are added, user policy is updated are few instances when we make the security testing mandatory.
