The US Food and Drug Administration (FDA)’s voluntary Qualification of Medical Device Development Tools (fda.gov) is intended to encourage use of innovative technologies and novel approaches to medical device development and create a favourable regulatory framework to expand the availability of entirely new medical devices to patients.

This blog includes an overview of MDDT program, its categories, history, benefits, Centre for Devices and Radiological Health (CDRH) Qualification Process and Decision Framework.

FDA’s MDDT program provides a more efficient and predictable means for collecting the necessary information to support regulatory submissions and associated decision-making.  The MDDT program enables the FDA to qualify tools that medical device sponsors can use in the development and evaluation of medical devices.

MDDT Overview

A Qualifying Medical Device Development Tools (MDDT) is a method, material, or measurement used to assess the effectiveness, safety, or performance of a medical device. An MDDT is scientifically validated and can be qualified for use in device evaluation and to support regulatory decision-making. Examples are clinical outcome assessments, assessments of biomarkers, and nonclinical assessment methods or models. The use of a qualified MDDT by a product sponsor is voluntary.

The process for MDDT qualification can be initiated in one of three ways: 1) FDA identifies an area of need and/or calls for development activity in a specific area; 2) need and interest in an area is determined by individual or consortia of stakeholders (may include academia, industry, medical societies, patient groups); or 3) MDDT developer pursues qualification to foster broad use of the tool, potentially across multiple device development programs.

While these tools are not part of the medical devices or products themselves, they do support the end-product at some point in (or even throughout) its lifecycle. If the tool in question can have an impact on the quality and safety of the device, then it needs to be validated to meet regulatory requirements, reassure clients and end-users, and enable the business to scale.

MDDT Categories

Here are the main categories the FDA has identified for MDDTs according to how FDA measures the relevant parameters:

• Clinical Outcome Assessment (COA). Reports generated by a clinician, patient, non-clinical observer, or performance-based assessment on how a person feels, functions or survive. It does not merely consist of a score or outcome but also contains information of defined methods and instructions for administering the tool and a standard format for data collection. Even the methods used for scoring analysis and results for interpretation are clearly defined. The following are 4 common types of COAs:
  • Patient-reported outcome (PRO) measures. This is a report from the patient directly regarding the patient’s health condition without the interference of the clinician or anyone else. PRO is unique in a way that symptoms and other unobservable concepts (such as pain severity and quality of life) can be measured only by this method. One such example is the EXAcerbations of Chronic Pulmonary Disease Tool – Patient Reported Outcome (EXACCT-PRO).
  • Observer-reported outcome (ObsRO) measures. ObsRO measures are reported by a parent, caregiver or someone who observes the patient on a day-to-day basis. This method is used in the case when the patient cannot respond by themselves (for example, an infant or cognitively impaired patients).
  • Clinician-reported outcome (ClinRO) measures. These measurements come from the clinician in cases where their clinical judgment and interpretation of the observable signs or other physical manifestations can help provide feedback of the patient’s health status.
  • Performance outcome (PerfO) measures: These measurements are based on a task(s) performed by a patient according to instructions given by a health care professional. Performance outcomes require patient cooperation and motivation. These include measures of gait speed (e.g., timed 25-foot walk test), memory recall, or other cognitive testing (e.g., digit symbol substitution test).
• A Biomarker Test (BT) is a test or instrument used to detect or measure a biomarker of a particular risk or identify safety concerns or predict treatment outcomes in patients. Different types of biomarkers include molecular, histologic, radiographic, or physiologic characteristics.
• Nonclinical Assessment Model (NAM). It is a method which measures or predicts the parameters of interest regarding safety, performance or device effectiveness.
• In-vitro models to replace animal testing; physics, chemical, or biological based computational models, human or animal-based models to replace clinical testing are some examples of NAMs.

Qualified NAMs can be used to evaluate a new material property, modifications to an existing design, or a device feature historically evaluated through other bench, animal or human testing.

MDDT History

FDA issued a final guidance on the MDDT program in August 2017.

• First FDA qualified MDDT was the 23-item Kansas City Cardiomyopathy Questionnaire.
• The Minnesota Living with Heart Failure Questionnaire became the second MDDT in May 2018.
• OsiriX CDE Software Modul was the third FDA-qualified MDDTs in March 2019. A tissue mimicking material (TMM) for use in the preclinical development and evaluation of ultrasound medical devices became the first MDDT developed by the FDA to receive FDA qualification in 2019.

The first two are clinical outcome assessment tools and the third is a biomarker test. The fourth—the TMM—falls under the category of nonclinical assessment.

All these MDDT programs play an important role in helping the FDA understand how medical devices work, in terms of safety, effectiveness, and other aspects of performance.

MDDT Qualification and its Benefits

Qualification is a conclusion, based upon FDA review of the MDDT qualification Package, that within the context of use (COU), the results of an assessment that uses and MDDT can be relied upon in device evaluation and regulatory review. In addition to being a direct regulatory requirement in some markets, validating tools via MDDT brings significant benefits and the opportunity to improve and grow your organization. Benefits include:

• Good Selling Point Being able to say your tools are validated will help reassure customers, winning new business and giving you an edge over competitors who aren’t validating their tools.
• Gets your team on the same page The process of validating tools often involves many company stakeholders. This can be a great opportunity to familiarize colleagues from different departments with important tools, get their buy-in, and engage them for more fluid collaboration.
• Helps your business scale Increasing productivity and completing audits smoothly and quickly will help your business flourish and avoid costly delays.
• Makes you compliant Validating your tools means you are complaint with industry and regional regulations, and you can avoid any unpleasant delays or fines as a result of not using validated tools.

Other examples and roles for MDDT in device development include:

• Select clinical study subjects
• Stratify patient population by predicted risk
• Study population enrichment
• Intermediate endpoint
• Develop surrogate endpoint
• Define an adverse event (AE) or symptoms of disease
• Reduce test duration or minimize sample size, e.g., using as a computational model
• Replace an evaluation typically conducted in human studies
• Reduce or minimize the use of animals, e.g., using a simulation
• Develop post-market surveillance methodologies such as methods or models capturing real world outcomes.

MDDT CDRH Qualification Process

The MDDT CDRH qualification process consists of several phases as described below:

• Proposal Phase. The goal of the proposal phase is an initial phase of assessment to determine if the MDDT is suitable for qualification through the MDDT program. The number of proposals accepted depends on available FDA resources. A complete proposal package includes the MDDT description, Context of Use (COU is a statement that fully and clearly describes the way the MDDT is to be used and the medical product development-related purpose of the use), Performance Criteria, Qualification Plan, Assessment of advantages and limitations.
• Qualification phase. The goal of the qualification phase is to determine whether, for a specific Context of Use (COU), the tool is qualified based on the evidence provided. A complete Qualification Package includes MDDT description, COU, Qualification Plan, Tool evidence, Assessment of Advantages and Limitations of Qualification, Summary of evidence and basis of Qualification.

Potential changes to qualification status. Once the MDDT is qualified and the developer wishes to make some changes to the MDDT or expand its COU based on new data available, it can be done through the qualification program. CDRH may re-evaluate the qualification in case where the bases on which the MDDT was qualified earlier has changed.

CDRH Qualification Decision Framework

• MDDT description. Is the MDDT adequately described?
• Context of use. Is the proposed context of use adequately and appropriately defined?
• Public Health Impact. Would the scope and use of the tool have a broad public health impact?
• Strength of evidence. Does the available scientific evidence demonstrate that the MDDT reliably and accurately measures what is intended, is scientifically plausible, and is reasonably likely to predict the outcome of interest?
• Assessment of advantages and disadvantages. Within the specified context of use and given the available strength of evidence, do the advantages outweigh potential disadvantages of making decisions based on measurements obtained using the MDDT? Of particular importance are regulatory, public health, and/or clinical impact.

Evidence to support qualification

The type of evidence needed will vary depending on the tool type and COU and may include (but is not limited to) as appropriate:

• design verification
• simulation results from computational models
• bench performance data (including full test reports and protocols)
• animal performance data (including full test reports and protocols)
• clinical data (including full test reports, protocols, and all appropriate (pre-specified) statistical analyses to demonstrate the relationship between the tool and the COU)
• human factors testing; and/or
• literature articles (the full text article, a summary and a description of how the article supports qualification).

Best practices for tool validation

• If possible, start before you acquire the tool. Knowing the system configuration and planning it makes the process smoother.
• Use an industry guideline. Industry guidelines with widely accepted standards have been developed to make this complex process easier. This framework for validation covers all aspects of the product lifecycle from planning to system retirement, and outlines how you should do things, name items, and set up roles and responsibilities, amongst other handy tips. This helps understand how a validation process, in general, is carried out. In the case of development tools, you’ll want to consider the intended use of the platform, e.g. each of the features you’ll be using, and validate the tool based on those use cases.
• Put the right person in charge. Do not underestimate the process of validating tools in safety-critical industries. The tools themselves are often complex, with tons of functionalities that your team might not be exhaustively familiar with. Validation is often a bigger task than expected and takes a chunk of time to carry out. Hire a software validation professional to do it or assign a team member with relevant experience to project manage it, and make sure to allocate sufficient time and resources to ensure it’s a success. Alternatively, if your tool vendor offers such a service, consider having your tool validated by the vendor for a fraction of the time and costs of carrying out a manual validation process.
• Involve stakeholders from the beginning. Throughout the process of validating tools, you’ll find that you end up needing inputs, approvals, and sign-offs from a variety of individuals in your organization, spanning different teams and departments. It’s best to set the validation process up as a project from the beginning and involve them from the start, rather than dragging people in one by one as you go along in a haphazard manner.
• Use the vendors as a source. If you can, work with the service providers or product creators themselves and ask them to look over your validation documentation before it’s executed. They are the experts for their own tools and can help you understand what your processes and configuration should look like, as well as fully grasp the functionalities of the tool.
• Document everything. A hugely important part of validation is that you have evidence and documentation to show that you have documented how you’re planning to use the tool; have identified all affected functionality and that a testing protocol was run to assess the correct functioning of those features. This shows customers and auditors that everything is good to go and you have the proof to back it up.
• Future-proof your setup. Once you’ve validated your tools, you need to maintain that validated state. Tools are often updated and upgraded throughout their lifecycle, and these changes can affect their status. Place every tool under change control processes and make sure to conduct periodic reviews to ensure you can still consider them to be validated.