Health Technology Software Quality & Compliance

“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.”
—Stewart Brand

Health Technology is defined by the World Health Organization (WHO) as “the application of organized knowledge and skills in the form of devices, medicines, vaccines, procedures and systems developed to solve a health problem and improve quality of lives”. However, as IT professionals in the life sciences, we focus on the Health Technologies that use software to perform their intended use.

In recent years, we have witnessed how health and technology have increasingly come together. Whilst in the old days, technology in the life sciences was merely associated with business commodity and manufacturing processes to help bring products to the market. Nowadays, technology has become the product itself. The market has been provided with an enormous portfolio of mobile applications, web-based applications, wearables and many other technology-based tools that support healthcare professionals or even replace their functions, and help patients improve their quality of life. As a consequence, and with a view to increasing their chances of success, many life sciences companies have formed powerful partnerships with tech firms to develop innovative solutions together. To mention some examples of these health technology products:

• Smartwatch that can take an electrocardiogram (ECG) of the user and can help detect conditions such as atrial fibrillation (AFib).
• Mobile application for patients to track on a daily basis, their symptoms and medication  and get quick information about their disease.
• Artificial intelligence software used by healthcare professionals for image-based diagnosis.

It makes sense to think that, in a fast-changing environment like this, where new health (software-based) technologies are continuously developed and released, quality and compliance professionals must keep themselves ahead of the game. In order to protect patients from undesired outcomes, new solutions in the areas of Digital Health, Healthcare Technology or Medical Technology require quality and compliance approaches that keep up with innovation and new technologies to ensure quality and compliance are built in the products. To ensure compliance we first need to understand what kind of product we’ve got and what the applicable regulatory requirements are. Additionally, to ensure quality and security, we must get to know in-depth the technical details of the design, intended use as well as the expected end-users and their usability behaviours. By ensuring quality and security are built-in, we aim to protect users from unexpected software failure that could cause any type of direct or indirect harm to them or others. Furthermore, by ensuring compliance we pursue product approval and business continuity. But let’s have a look at some of the topics that we should consider when dealing with the quality and compliance of health technology software products.

Understanding the Solution & How it is Regulated 

In order to ensure compliance with applicable regulations we first need to understand what those regulatory requirements are. With the advent of new health software solutions that include innovative and challenging technologies such as artificial intelligence/machine learning (AI/ML), or augmented and virtual reality (AR/VR), among others, this task is getting more and more difficult, even for regulators, who have the duty to keep the regulatory requirements up to date to regulate and control these new technologies to protect patients.

Firstly, we will have to assess the solution based on the intended use or “what the solution does” and the markets where it is to be placed, and then identify the regulatory classification. Our health technology software could have no regulatory impact, but most probably it will. It could fall under GxP (good practices) in the case of a website with static content that includes electronic versions of drug labels or that allows patients to record and communicate adverse events, or a mobile application to gather clinical trial data, etc. When GxP records come into play, we must consider the applicability of 21 CFR Part 11 for the US market and EU GMP Annex 11 for the European market. The solution could also fall under medical device regulation, if it performs actions on a patient or healthcare professional data for a medical purpose (for example, to diagnose, prevent, treat or alleviate a disease). If the software performs these actions without being part of a hardware medical device, it might be a Software as a Medical Device (SaMD).

SaMD is a trending topic in the industry nowadays, due to the emergence of health solutions using AI/ML or AR/VR. So much so that the FDA (U.S. Food & Drug Administration) is working on a new regulatory framework for these technologies that would allow for modifications to be made from real-world learning and adaptation, while still ensuring that the safety and effectiveness of the software as a medical device is maintained.¹ It is worth mentioning some examples of SaMD, in order to fully understand this concept, if new for you:

• A diagnosis algorithm coded on a web/mobile application.
• A mobile application for processing ECGs.
• A mobile application for viewing the anatomy of the human body.
• A mobile application for the communication between patient and caregivers while giving birth.
• Software that allows MRI (magnetic resonance imaging) and other types of medical imaging to be viewed on regular mobile devices.
• Software that performs image processing to detect cancer.
• Software that regulates an installed medical device, like a pacemaker.
• Software that regulates an infusion pump to administer a drug.
• Software that calculates the drug dose for a patient, based on personalized data.
• A diagnosis algorithm coded on a web/mobile application.

It could be that the solution is neither GxP regulated nor a medical device. This might be the case of a fitness mobile application, a mobile application that helps patients track their symptoms and reminds them to take medication, a web-based application that provides treatment recommendations (i.e., electronic version of medical practices), or any other solution which does not fall under GxP or medical device classification. In this case, we must check if there are any regulatory requirements related to health care compliance in the countries where we are planning to make the solution available for use.

Apart from these health-related regulatory requirements, there are other regulatory requirements we must consider and include in our assessment, such as SOX (Sarbanes–Oxley Act), data privacy (i.e. GDPR), cybersecurity, etc.

Cybersecurity is a hot topic. Especially for medical devices, and manufacturers should put the focus to ensure they build solutions with the lowest possible number of vulnerabilities. Regulatory bodies know this is a highly critical aspect of some products using connectivity technologies and, as a consequence, they are increasingly tightening cybersecurity requirements and encouraging companies to develop products that incorporate security by design. Recently, a medical device was recalled (Class I recall, the most serious type of recall) by the FDA due to potential cybersecurity risks.² 

Finally, when it comes to performing the regulatory assessment and regulatory classification of the solution, which will serve as a baseline for ensuring compliance, we must make sure different domain experts review and approve the outcome. This can include but is not limited to regulatory affairs, legal, marketing, medical affairs, quality & compliance, and other relevant representatives.

Ensuring Quality & Compliance of Health Technology Software

Some manufacturers identify the requirements from the regulation and then just focus on “checking the box” so that they are good to place the solutions on the market. This can be a very risky approach and should be avoided by all means. Often, you will end up struggling with customer complaints and health authorities’ inspectional observations or, in the worst case, recalls and patient impact. Instead, companies should adopt a quality mindset, and not only strive to demonstrate compliance but also incorporate true quality into their culture. When quality is embraced and integrated into the various business processes, including product design and development, and a proactive approach is applied (in opposition to the reactive nature of the compliance-focused mindset), we increase our chances of delivering high quality and safety and, for sure, compliant products.

But how can we achieve this? Manufacturers should start by putting in place a quality management system (QMS) that incorporates the different applicable regulations and quality standards into their business processes. We can define a QMS as a collection of business processes, principles and practices focused on consistently meeting customer and regulatory requirements, as well as quality standards. It should be aligned with an organization’s purpose and strategic direction.

We have already talked about regulatory requirements, let’s talk now about quality standards. The American Society for Quality (ASQ) defines quality standards as “documents that provide requirements, specifications, guidelines, or characteristics that can be used consistently to ensure that materials, products, processes, and services are fit for their purpose”. International standards are widely recognized and accepted, and incorporates recommendations to meet the regulatory requirements. Thus, if we succeed to follow their recommendations, we will not only achieve high quality but also a high compliance standard. When related to Health Technology software manufacturers, these are some valuable quality standards:

• ISO 13485:2019 (QMS for medical device manufacturers)
• ISO 14971:2007 (risk management)
• IEC 62304:2006 (software life cycle processes for medical device manufacturers)
• ISO/IEC 27001:2013 (information technology security)
• ISO/IEC 25010:2011 (software quality requirements and evaluation)
• IEC 62366-1:2015 (usability engineering)
• ISO 9241-220:2019 (human-centered design)
• GAMP Good Practice Guide: Regulated Mobile Applications

The different processes as laid down in the quality standards and incorporated in the QMS, aim to ensure that good quality practices are followed and maintained during the whole product lifecycle. Before we wrap up this article, we would like to share some common good quality practices we deem essential for Health Technology software solutions:

• Assign cross-functional teams, involving different domains (i.e. Quality, Compliance, Regulatory, Lega, etc.) from the beginning to understand the solution and perform the regulatory assessment and classification.
• Ensure suppliers are acceptable via supplier assessment and include regulatory and quality requirements in the service level agreements.
• Specify the user, technical, regulatory, safety, usability, etc. requirements for the solution as a baseline for the SDLC (software development lifecycle).
• Detail the design specifications, including architecture, code, components, configurations, user interface, security, connectivity, environment parameters, etc.
• Set and maintain the traceability between all the requirements and design specifications levels.
• Develop the solution using coding standards and ensure that code versions are testable, traceable and controlled.
• Test the solution in a testing environment during the whole SDLC, with different verification levels (unit, integration, system testing, etc.) and test types (functional, non-functional testing, etc.).
• Ensure the defined requirements are met during the different verification levels. Set and maintain the traceability from requirements to testing and ensure all the requirements are tested.
• Ensure the solution is validated (objective evidence that ensure the intended use can be met is documented). Obtain feedback and approval from end users in an equivalent production environment.
• Ensure the release process is planned and documented.
• Ensure the solution is enabled for deliver and support (i.e. changes, incidents, etc.).
• Monitor the solution to identify changes that could affect the validated and regulatory state of the solution (i.e. a functional change could make the solution a medical device).
• Define operation procedures to ensure complaints, security, problems or other issues are properly handled, and put in place contingency plans, back and restore procedures, etc.
• Ensure the decommission of the solution follows an approved plan with defined processes (i.e. data archival, patient notifications, etc.).

¹Artificial
Intelligence and Machine Learning in Software as a Medical Device: https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device

² Medtronic Recalls Remote Controllers for MiniMed Insulin Pumps for Potential Cybersecurity Risks: https://www.fda.gov/medical-devices/medical-device-recalls/medtronic-recalls-remote-controllers-minimed-insulin-pumps-potential-cybersecurity-risks

Author: Rodrigo Alvarez Life Science Consultant, KVALITO

Do you need support identifying the regulatory requirements affecting your Health Technology software? Or ensuring your design and development processes are compliant with the applicable regulations? Or do you just want to check the ability of your QMS to deliver high quality and security solutions? KVALITO is a strategic partner and a global quality and compliance services provider and network for regulated industries. To learn more about our service please visit us on www.kvalito.ch

If you would like to benefit from KVALITO’s expert services, feel free to contact
us or send us an email to contact@kvalito.ch.