How To Choose And Test Your Individual Healthcare App?

Digital health grows with immense speed: the industry has received a record amount of funding since January. As the world slowly (hopefully) walks out of the global public health crisis, startups within the field will have to prove that they can be agents of care not only when there are no other options.

An example: although telemedicine startups thrived during the pandemic, the usage of non-video telemedicine services decreased. Not because people loved video calls — because consumers generally asked for healthcare services less. 30% of Americans didn’t use telemedicine at all. Newly-developed apps for the elderly occurred to be unfit and inaccessible. Customers are still, in general, vary of mHealth because of data sharing concerns.

It’s difficult to determine how successful digital health — and mHealth apps as a part of it — will become in the long run.

There are good strategies to ensure your healthcare app survives the (possible) decline of software adoption and mistrust, though. One of them is to dedicate a lot of time to testing.

This article briefly describes the pros of healthcare apps and their challenges — for you to get a snapshot of the market — and outlines the main testing types necessary for high-quality mHealth app development  says Slava Vaniukov, expert and CEO of Softermii.

Advantages of Using Healthcare Apps

Let’s review the main advantages of using healthcare apps for different user categories.

For patients. Through mHealth apps, patients get faster access to healthcare services and their medical data, more available and accessible on-demand virtual medical consultation, and more tools to care about themselves more efficiently.

For healthcare organizations. Mobile apps that connect clinicians and patients allow the latter to optimize their workflow; prevent no-shows by offering patients online scheduling tools; get familiar with a patient’s health records before the visit.

For businesses. Companies can use mobile healthcare apps to boost patients’ health and engagement; help them address their issues with mental health and burnout; provide them with different fitness options.

For research organizations. Healthcare hosts a massive amount of health data — and machine learning algorithms make it easier to collect data, analyze it, and study it. mHealth apps for CROs can help them retain trial participants. Also, if apps are integrated with wearables or built with self-reporting tools for participants, it’s easier for CROs to gather more contextual data for their research.

For caregivers. Caregivers can establish a system of continuous care through mHealth apps — e.g., for people with chronic conditions; can communicate with those who are on lockdown through chats and video calls; organize food and medicine deliveries and transportation, etc.

Healthcare Apps Challenges

Diversido.io come with many challenges. Here are three of the major ones.

1. Software companies often don’t understand the market or can’t identify the needs of people in it. That’s partially a reason why, for instance, when the usage of EHRs started to be incentivized under the Affordable Care Act in 2009, and hospitals started implementing new software, the majority of doctors felt it resolves fewer issues than it creates. EHRs weren’t built with a focus on what doctors needed from the health record software — they were created around developers’ assumptions about that.

 

1. Security and privacy, HIPAA regulations, and data sharing concerns — a bundle of challenges under one name: patient data protection. Startups have to focus on compliance and on shielding their app from cyberattacks. A lot of them make security an afterthought—and that’s partially why healthcare is a favorite industry for hackers. That is especially critical when patient-facing mHealth apps are concerned — mobile security risks are often higher than those of, f.i., desktop computers.

 

1. The first two challenges contribute to the third one. Healthcare stakeholders have many issues with the tech industry: its applications, hunger for disruptions, and lack of investments in user and market research. It’s very difficult to sell in the field — especially B2B solutions.

Healthcare App Testing Types

Now, as you know what people and organizations can benefit from a healthcare app and what challenges you may face when developing them, let’s talk about processes that can help you reap the benefits and avoid facing the challenges. (At least, avoid facing the challenges unprepared.)

The first thing to know about testing is that it can be conducted on different levels of app’s abstraction: for instance, engineers often test the tiny bits of the code as they’re writing it (low-level testing) — and, after the app is deployed, product managers invite users to conduct usability testing (high-level testing.) Let’s talk details.

• Unit testing is checking through the smallest testable parts of the code, usually conducted by developers who work on the app.
• The integration testing aims to confirm if different components work together well: it’s an upgrade from unit testing.
• System-level testing aims to figure out if a whole system works smoothly. Here, the software is tested in environments that are as similar to the production settings as possible. Product managers and Q&A specialists figure out if the product works as intended for users; if it runs according to the client’s requirements.
• Acceptance testing is final high-level testing: at this stage, the product team involves users on board to test product quality.

Let’s discuss different types of testing that exist among these levels.

Functional testing

That type is an umbrella for tests that are conducted to test the system according to its functional requirements provided by a client and figure out if features, components, and other elements of the system do what they are supposed to. You can run functional tests on all levels of app abstraction.

One of the subtypes of this type of testing is regression tests: developers run them to figure out if changes in the code didn’t break anything. Developers run regression tests to mitigate the risk of rolling out unsecured app updates (which often happens with the high-pace, hit-and-go development tempo that’s so widely accepted in tech and a big no-no within the digital health industry).

Performance testing

QA engineers test the app to determine if it is stable or not. For performance tests, they have to find a way to overload the app to determine if it can cope with the pressure. That’s extremely important if you’re trying to find out if, for instance, you’ve scaled the app properly — if it can withstand the changing number of users and fit the processing demands. Here, you also test if your new app can hold, like, a hundred telemedicine video calls that start simultaneously and continue for two hours. Performance tests are conducted on a system level.

Security testing

In most cases, security testing is done by cybersecurity experts (who are usually also information security specialists, or DevOps engineers, or incredibly skilled QAs). They try to break the application and expose its vulnerabilities and make sure the code can fight off or at least hold intrusions.

The efficiency of security testing depends on how well your specialists know the common and rare ways to hack your app. Most common cybersecurity threats within mHealth apps come from human errors and using legacy software. Make sure your security specialists know that at least a third of the hospitals haven’t updated Windows 7 yet; have one IT worker; don’t know you should change standard credentials for logging into the server. Security tests run on the system level.

Compliance testing

Compliance tests help to verify that the healthcare app is HIPAA and USCDI compliant, and personal health information that it stores, transfers, or in any other way interacts with is protected on every possible level.

For instance, one of the things to check within the compliance testing is if details from users’ PHIs — messages about X-ray images, diagnosis, medications — are never present in push notifications. Another is role-based access across healthcare departments: therapists in the hospital should never see primary care physician’s notes; physicians — a therapist’s; hospital administrators should have access to neither.

Interoperability testing

An interlude: if you plan to build a healthcare app that integrates with EHRs, it’s necessary to adopt a standard called Fast Healthcare Interoperability Resources (FHIR). A lot of healthcare app developers integrate it in their apps using SMART on FHIR APIs — it helps to engineer solutions that are compatible with every system that uses FHIR. (SMART is very comfortable for developers to use; it’s also included in ONC’s final rule for interoperability as a universal API for healthcare apps, so check it out.). Depending on what’s suitable for your purposes, you can adopt FHIR APIs on top of the existing data access layer — that’s the most common approach. Alternatively, you establish the FHIR standard in every element of your system’s architecture from the beginning, creating an FHIR-native application.

The interoperability testing will include checking if data sharing is smooth and secure: it will go through all HIPAA safeguards for information exchange, check SMART API, and the resilience of data security in transfer, etc. Interoperability tests happen on system and acceptance levels.

Use Case testing

Use case testing uses scenarios to identify gaps or errors in the healthcare app. It’s performed to uncover how the healthcare app performs specific tasks users might want to do with it. It’s important to prepare use cases with the preliminary user research in mind for usability testing to work.

You might find out that, despite the fact the app fits all functional requirements, it’s not usable from the point of a person who has a bad vision; isn’t proficient with smartphones; doesn’t understand specific medical terms.

Testing among first users

This is a method that makes sure the healthcare app works as planned by letting users test it — that’s pretty self-explanatory.

Don’t forget to gather all that feedback, select the most commonly voiced concerns, and address them in the release version of an app. Prioritize issues with accessibility uncovered by users — that is crucial for healthcare apps. Check out standards for ensuring everyone can use your mHealth app at W3C’s website.

Achieving and maintaining high quality is everyone’s job

There’s a widespread misunderstanding of testing that has no place in healthcare app development: people believe that testing and ensuring the high quality of the app is exclusively a job of the quality assurance department. That’s a pretty harmful approach to development: both for the team and the final product. Everyone involved in the project has to work towards creating a good app.

Building high-quality healthcare apps, as you’ve figured, requires a lot of research about the industry, its standards, and its end-users. Asking informed questions makes testing — and development as a whole — much more efficient. If everyone in the team does the necessary due diligence, the likelihood of your app being really good gets higher just because of that acquired expertise.