The healthcare industry is growing very fast. Every day we can hear about new technological innovations and new features that can produce a massive demand for medical treatments and services. 

With the significant number of people involved in the healthcare industry, for now, we see as advancements in technology serve healthcare providers in their everyday tasks and challenging cases and also help them to save our lives and produce the best quality of service.

For now, technologies are used in various areas of the healthcare industry, e.g., electronic medical records, electronic data transactions, improvements of the patient’s experience, and many others. Specific of the healthcare industry is the source of some cases that can be crucial for new products.

Every new healthcare product should be built on the following principles:

• Security
• Performance
• Quality

Security 

When we are thinking about the most security-sensitive industries – healthcare is in the top five. Information leaks can entirely ruin performed work and investments that have been spent during development. Reputation loss can be even more significant so that the QA team should be careful in the testing of security-related stuff. The variety and complexity of the permissions system, representation of the sensitive information – all these areas should be covered by test cases and included as part of regular checks before the release of new features. 

In terms of permissions testing, it’s crucial to have a well-detailed suite of autotests to exclude the possibility of regressions. The problem with the approach is that usually, such types of autotests require much preparation before the exact run. Verification of email content, pages, and features accessibility sometimes require the test data creation, configuring the entire application and permissions, etc. The QA team should keep in mind that the time needed for test execution increases exponentially with the increase of test case coverage. It means that QAs should take care of the performance of the autotests at the early stage. 

Another interesting case is mostly related to the protection of Patients’ Sensitive Information. According to the Health Insurance Portability & Accountability Act (HIPAA), any entity that can collect or store sensitive patient healthcare information should keep the information secured and protected against unauthorized access or use. As a result, usually, the QA team doesn’t have access to the ‘production’ environment and especially to the real patients’ data. 

So when we should check a fix for some issue that is actual for ‘production’ environment only and haven’t noticed before for ‘test’ environments – it’s a challenge to investigate steps to reproduce or some specific configs without access to real examples of patients with that issue. This investigation requires deep research of developers’ pull requests, user stories, any small details that could be a key to the understanding of conditions and/or steps that have produced the issue.

Performance

When the development is just started – it’s hard to predict all possible ‘bottlenecks’ in the system. The “cost” of such issues can be very high. Performance and load testing should be introduced as soon as possible to make sure that the system behaves as expected for final users. It’s worth nothing to say, “Let’s create performance tests”. But in reality – the QA team often doesn’t have access to internal logic. So that if we are talking about such tests – usually it will require some support from the developers’ side. 

A good example is the HL7 messaging. HL7 standards are used for the exchange, integration, sharing, and retrieval of electronic health information. These standards define how data is packaged and communicated from one department to another, setting the structure, language, and data types required for seamless integration between systems. HL7 standards support clinical practice, management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

These standards are very flexible and provide various guidelines and methodologies, which can be used by healthcare systems to communicate with each other. The flexibility of this technology is useful for the application itself, but it can be a nightmare for QAs. It’s almost impossible to prepare a file with the HL7 message manually (due to format specifics and significant amounts of the data). But even if the QA team decides to use autotests, they will need to spend a lot of time investigating specifics of each HL7 message format that is used in the app. But if all these difficulties are resolved, the QA team can simulate real interactions between different services and check their performance. Sounds good, right? Hold on a sec. Once QAs have implemented basic patterns for a lot of HL7 messages types, created code that automatically generates fresh patients’ data – they should investigate and figure out how to connect to the server, which will process their messages. Set up correct IP addresses in system configs, configure a proxy, generate and set public keys (we are protecting patient’s data, say “hello” to HIPAA) – all these points aren’t so challenging like another issue – “race conditions”.

When we send some data to the server, we suppose to see that this data will be processed, and we will see the results (for example – new patients created). But what if we perform several different actions? For example, if we are trying to create new patients in the system and modify them using 2 different HL7 messages. The tricky point there is processing time. In terms of autotests, we should make sure that our patients will be created before the attempts to update them. Otherwise, we will get errors from the server or our system. But what if we are using hundreds of HL7 messages in several threads? Balancing such cases will require a lot of work and creativity from QAs.

Quality

The cost of mistakes in healthcare applications is high. Sometimes the product can be delivered to clients without full test coverage or even with untested functionality. Unfortunately, the healthcare industry is pretty sensitive to the quality of the product. 

Improvements in patient experience are one of the key trends nowadays.

Let’s say you choose between two clinics with more less the same level of service. Your choice may depend on various factors, but a nice looking site, simple and most important working(!) registration form, fast processing of your requests can be determinant.

That’s why the QA team should always be oriented to the best quality of the product. It’s not enough just to check the new features but more important to continuously work on improvements. 

Usually, QA engineers have a lot of tasks, which include manual testing of new features, regression and smoke testing, design and development of autotests, supporting the existing tests, creation of test documentation (test cases) for new features, etc. It’s worth nothing to forget about the main QAs task to provide the best quality of products for our customers.

Conclusions

With the fast growth of the healthcare industry and improvements in technologies, we are forced to produce quick solutions for business. It’s essential to keep the balance between development speed and detailed testing. When we invest time in testing in the early stages, we can save a lot of resources in the future, and the cost of the bugs is less.