Innovation Vault - Blog

Concluding the IoMT Wearable Device’s Journey on the Innovation Roadmap: Regulatory Controls and Preparing for Commercialization: Stop 3 (of 3 Stops)

Written by Christopher Montalbano | Sep 8, 2021 1:47:57 PM

Part 5 of a 5 Part Blog Series on | "Advancing Public Health with Wearables; Strategic Development of IoMT Biosensing Lifestyle Devices"

 

Thus far in our series, we performed a deep dive into the topic of IoMT biosensing lifestyle devices, learned the intimate details of their development, and followed their progression on the Innovation Roadmap™ through the 1st and 2nd Stops. We have explored the medical wearables market, discovered and investigated opportunities for innovation, and brought concepts to life with research and design. Now, with vision in hand, it is time to set out on the final leg of our journey, to Stop 3, where devices prepare for commercialization under regulatory controls, eventually emerging as full-fledged FDA approved products ready to debut on the market. 

 

Incorporating Regulatory Controls

While the importance of regulatory requirements like FDA QSR and ISO-13485 have been acknowledged throughout, it is not until this point in development that they demand any action. Stops 1 and 2 have been left as periods of unconstrained discovery and innovation by the FDA. Now is the time, within Stop 3, to implement these prescribed methods and ensure that your device is appropriately effective and safe to the public. 

 

Key to beginning this complicated process is a robust Quality Management System (QMS) containing a Quality Manual that establishes SOPs, or standard operating procedures, clearly defining the necessary activities to deploy for product realization. At MIDI, this QMS is known as DevelopmentDNA™, and all documentation relative to it is archived, rev-controlled, and date-controlled with e-signature verification utilizing the cloud-based tool MatrixQMS. With collateral in place from Stops 1 and 2, our first activity at Stop 3 is working with regulatory partners to determine the device’s intended use and what efficacy claims will be made about it— significant because, alongside safety for the stakeholders, a device’s efficacy for its intended use, including functional performance and ease of use, are the FDA’s most basic and essential priorities for wearable IoMT devices.  

 

Next, the device must be categorized in one of three FDA-defined medical device classes— Class-1, consisting of no or low-risk devices; Class-2, containing intermediate-risk devices; or Class-3, devices that can carry the risk for severe injury and typically support or sustain life. The vast majority of devices, including IoMT wearables, fall under Class-2. With class and use established, the appropriate regulatory path may then be selected from 510(k), DeNovo, or PMA. 510(k) paths are predefined, with predicates and product codes available for reference, pointing to the regulatory documents necessary for compliance. Meanwhile, DeNovo and PMA paths lack precursors and often require FDA consultation to clarify their proper regulatory procedures. 

 

Further Preparation

However, this is not the last of the preemptive work that must be done before beginning the development activities of Stop 3. A key component in the ISO-13485 Product Realization methodology and MIDI’s proven technique for generating predictable success, thoroughly defined plans addressing all major regulatory concerns should be created and documented. 

Some high-level examples of these plans include:

  • A Design and Development Plan covering practical elements like staffing and timing.
  • A Risk Management Plan assists in identifying unacceptable risks and performing the necessary mitigation process in conformity with ISO-14971. 
  • A Verification Plan containing an Internal Engineering Testing Plan.
  • A Validation Plan including a plan for testing with end-users.

Because IoMT wearables utilize various software, additional plans are required for compliance with IEC-62304. Examples of these include:

  • Software Development Plan
  • Configuration Management Plan
  • Issue/Defect Management Plan
  • System Verification Plan
  • Software Verification/Validation Plan

Utilizing MatrixALM (Application Lifestyle Management), a cloud-based tool, MIDI documents all plans in a unique method standardized with rev- and date-control confirmed by e-signatures in accordance with FDA QSR.

 

Requirements and Innovations

At this point, the process may seem very regimented such that innovation will be inhibited. The counter is true. Let’s review again the definition of Wearable IoMT Device Innovation established at Stop 1; It’s the process of translating an invention into a device (i.e. commercialization) which creates value for the user.

Therefore the device must:

  1. Satisfy a specific market need.
  2. Be effective in both functional performance and ease of use.
  3. Be safe for all stakeholders.

 

While the first of these will have been addressed at Stop 1, it is at Stop 3 that the device may finally fulfill the latter two. 

 

With this process being grounded in ISO 13485, the development team now starts the process of capturing what are called requirements. In this case, at MIDI we break the requirements down into 2 primary categories:

 

  1. Regulatory Requirements: These consist of the imperatives laid out by governing agencies for the creation of a SAFE device. It requires sifting through regulatory documents identified earlier as relevant to the wearable device in development and capturing the requirements. 
  2. User Requirements: Encompassing the needs of healthcare providers and patients, these are collected by MIDI using tools such as VOC (Voice of the Customer) and workflow and task mapping. All requirements must be overlaid with the programmatic processes of Human Factors Engineering per IEC-62366.

 

Examining user requirements will allow the team to identify additional requirements of two types at a system level: client requirements and device requirements. Addressing the latter allows the development team to derive specific device feature definitions from decomposed user requirements, which often results in new intellectual property and enhanced device value. Meanwhile, discovery and capture of the former utilizing tools like Client Goal Mapping and Quality Function Deployment (QFD) provide the opportunity to conceptualize beyond the baseline device features and implement new innovative features that offer enhanced value to the customer and augmented revenue for the client. One trending feature in this area is the implementation of a robust IoMT (internet of medical things) system to provide additional value to the user and an additional revenue stream to the client. Once again, all requirements must be documented with FDA compliant controls within MatrixALM. 

 

The Risk Management Process

Before design and engineering activities may begin, we must also address risk management, specify design inputs, and define the parameters of verification and validation. Risk management is a process in which ISO-14971’s standard definition of risk within medical devices is used to guide documentation and mitigation. This begins with a Risk Management Plan consisting of proposed methods of dealing with:

  1. Risk Analysis: Includes reaffirming intended use and foreseeing potential misuse. It also requires identifying hazards, such as current leakage, moving parts, cyber security, acoustic energy and beyond.
  2. Risk Evaluation: Involves examining risks for a level of acceptability and advancing unacceptable ones to the risk control stage.
  3. Risk Control: Consists of analyzing risk control options, implementing of risk control measures, and performing residual risk evaluations, among other activities.
  4. Evaluation of overall residual risk
  5. Risk Management Review
  6. Production and Post-Production Activities

 

The process of creating this plan allows the development team to establish a clear definition of the device’s purpose and how users and patients will be using it, detect opportunities for misuse, and plan for handling use/misuse in advance of engineering. For Risk Evaluation, MIDI deploys its MatrixALM risk evaluation tool to document earlier identified hazards and quantify their probability of occurrence, severity, and detectability. The tool then produces a Risk Before Mitigation (RBM) value for each. RBM values over a particular threshold of acceptability are prioritized for mitigation. In the risk control stage, identified risks are categorized into one of the three following categories and handled accordingly:

  1. Inherently safe, which only requires cross-linking existing design inputs.
  2. Protective design feature, which requires new design inputs.
  3. Information safety, which necessitates additional instruction, labeling, and training.

 

After a mitigation is conceptualized, overall residual risk is re-calculated using MatrixALM again to produce a Risk After Mitigation (RAM) value; this value must fall below the range of acceptability established within the Risk Management Plan for the process to be completed.

 

Design Inputs, Verification, Validation

Design inputs, also known as design specifications or simply specs, define the exact acceptable quantifiable criteria for any one feature. They are decomposed directly from requirements previously collected and entered into MatrixALM. One can say that a requirement provides a high level general description where the design input is the engineering interpretation of how to achieve that requirement. Often one requirement gets decomposed into multiple design inputs.

 

Each design input is subject to verification testing defined by MIDI and the international standards community, particularly the IEC 60601-1 family, sometimes called ANSI in the United States. Verification testing is intended to ensure each design input conforms with the pre-defined quantifiable acceptable values. At MIDI, it is typically performed in-house and with the assistance of external laboratory partners such as TUV and INTERTEK. 

 

While verification testing is directly tied to design inputs (as established with traceable connections in MatrixALM), validation testing concerns the user requirements at their core. Because these are high-level, more nebulous standards, validation is in many ways more challenging than verification, which uses clearly defined values to measure acceptance. Instead, the team must rely on established stakeholder feedback and test cases, clinical trials, and other tools to prove that the device works as intended and fulfills all user needs with these qualitative methods.

 

Both validation and verification testing are critical steps in ensuring that the impending IoMT wearable device will be, as all medical devices should, practical with proper efficacy and safe for all stakeholders.

 

Goal in Sight

With the establishment of a product definition, our wearable design may finally begin commercialization development. Formal alpha prototypes and beta prototypes (pilot production) are developed, each iteration of which receives verification testing. The user base is regularly consulted on usability during this process, and clinical evaluations are performed using the beta prototypes for validation testing. 

 

And, with this, our IoMT biosensing lifestyle device may finally become a fully realized product ready for manufacturing. MIDI typically works with clients up to the pre-production phase, at which point a design history file (DHF) has been handed over to manufacturing partners, and production will have already begun. 

 

IoMT wearable medical devices are already massively popular among providers, patients, and consumers at large today. As biosensing technology continues to develop and further expand its capabilities, we are now cresting upon a new generation of these products, with likely deep penetration into our lifestyles and everyday life. Yet, being on the cutting-edge of innovation means that their development can have challenges not yet seen with other device types, whether they be in the design process or that of achieving regulatory compliance. MIDI’s DevelopmentDNA™ approach is specifically constructed to assist clients in navigating this unfamiliar territory; with its Innovation Roadmap™, developers are supported by a proven process as they manage obstacles and, with regulatory controls minted into this process, all the while exploring and creating innovative opportunities unhindered by red tape. Deployment of MIDI’s Innovation Roadmap™ addresses a device's functional, lifestyle, business, safety, and cost-to-manufacturer requirements of “the gold-standard approach” to product development with its tools to execute upon it in a rapid, AGILE product development fashion. Devices emerge that satisfy their stakeholders, improve users’ quality of life, are proven effective and safe for those users, and stand ready for market success. 


Unfortunately, this overview of the IoMT wearable device’s journey on the Innovation Roadmap™ cannot address every one of the wide range of circumstances faced by any project. If you would like to learn more about how MIDI can assist you on your device development journey under its Quality-First™ umbrella, visit our website today and reach out to us!