So far on our journey, we have visited Stops 1 and 2 on the Innovation Roadmap, exploring the market, identifying opportunities, investigating technologies, and performing R&D, largely unaffected by regulatory controls. It is at Stop 3, during commercialization and implementation, that guidelines such as FDA QSR and ISO 13485 must be actively deployed. Taking us deeper into this pivotal process and detailing the initial stages of Stop 3 is MIDI’s CEO Chris Montalbano, joined by Wolfgang Huber, co-founder of Matrix Requirements.
Compliance and Predictable Success
Although the first two Stops on the Innovation Roadmap have no particular regulations imposed on them, keeping guidelines in mind during these steps can make their implementation in Stop 3 far easier, increasing the likelihood of project success. As early MVPs, or Minimum Viable Products, are developed and tested during activities at Stop 2, the teams at MIDI carefully document each step towards advancement, including observations, innovations, and improvements made across multiple iterations. This record-keeping not only mitigates risk down the line, but also supports the establishment of a quality feedback loop, constituting a method of generating what, per Chris, MIDI calls “predictable success.”
Ultimately, the goal of FDA QSR and ISO 13485 guidelines are to ensure that medical devices released to the market are both safe for all stakeholders, including doctors and patients, as well as effective for its intended purpose, something that is primarily characterized by functional performance and ease of use. With the implementation of these guidelines beginning at Stop 3, MIDI seeks to establish a standardized process that frees their teams to focus on the commercialization and implementation of development innovations.
The Value of Quality Management Tools, MatrixALM and QMS
Doing this requires the use of a robust QMS, or quality management system, consisting of a quality manual detailing Standard Operating Procedures (SOPs). Defined by steps and flowcharts, these SOPs, in Chris’ words, “methodically define in detail the product realization activities to deploy.” MIDI’s own QMS is their DevelopmentDNA™ approach. They also make use of the cloud-based quality management tool MatrixQMS, developed by Matrix Requirements. Using this software, MIDI archives, rev-controls, and date-stamp controls with E-signatures QMS documents per FDA QSR. By relieving the burden of documentation requirements, tools such as these allow staff to focus their time and energy on the more creative aspects of development, where innovation takes place.
The advantages provided by MatrixQMS do not stop there, however. As Wolfgang explains, Matrix Requirements developed both MatrixQMS and MatrixALM with the goal of supporting companies in developing innovative devices more efficiently. MatrixALM assists engineers in recording various requirements with their associated design inputs and output requirements. Meanwhile, MatrixQMS supports the implementation of quality systems, procedures, and records such as CAPAs. The key to the success of these programs lies in what Wolfgang describes as “putting the documentation in the center of a design,” while supporting AGILE design methods.
Using these systems, time, money, and labor can be conserved when making design changes or analyzing the risks of doing so. This is because the systems rely on the use of a cloud-linked database where the entire team stores and updates design details throughout development, maintaining accurate documentation that can be changed quickly and easily when needed. With this, impact analysis can be performed that might be prohibitively expensive or even downright impossible when using a paper-based system. On the quality system side, if a smaller process within the design control procedure needs improvement, using Matrix allows for changes to be made within minutes as opposed to months.
Determining Paths and Defining Plans
Entering Stop 3 supported by these advanced methods and tools, the first step is working with regulatory partners to define the device’s intended use and what efficacy claims will be made regarding it, as well as to determine a class identification for the device, of which there are three. Class 1 devices pose minimal risk of harm to users, typically having simpler designs. The majority of medical devices fall into Class 2, defined by having a moderate risk of injuring users. Finally, devices within Class 3 are categorized by having the potential for a high risk of injuries, usually being devices that sustain or support life. Once a device’s class is identified, a regulatory path such as 510(k), De Novo, or a Pre-Market Approval (PMA) path is then identified. Some paths, like a 510(k), will include predicates that will assist in finding relevant regulatory documents to follow, while others will require preliminary discussions with the FDA to solidify the regulatory path to be taken.
With this step completed, the next order of business is defining Plans as part of following the ISO 13485 product realization methodology, while maintaining a methodical approach to development. One example of such Plans created under the DevelopmentDNA™ approach is Risk Management Plans in compliance with ISO 14971, which helps developers identify “unacceptable risks” and deploy a mitigation process in response. Other such examples include Verification Plans for internal engineering testing, Validation Plans identifying what tests will be deployed with end users in the field, and Design & Development Plans. When a design involves software, further plans must be formed to conform with IEC 62304, such as: Software Development, Configuration Management, and Issue Defect Management Plans. Throughout, the MatrixALM system is used in a unique method to record these plans in compliance with FDA QSR.
Capturing, Evaluating, and Applying Requirements
Moving forward, the next phase is to revisit the definition of innovation laid out in previous episodes and capture requirements to that effect, remaining grounded in ISO 13485. At MIDI, these requirements are of one of two categories: Regulatory Requirements or User Requirements. Regulatory Requirements are aimed towards making the device as safe as possible, and are determined through the careful study of regulatory documents in which relevant sections are identified. In defining User Requirements, MIDI makes use of tools like VOC or Voice of the Customer, task mapping, and workflow analysis while overlaying the IEC 62366 “programatic process of human factors engineering.” Importantly, these user requirements are instrumental in the discovery and capture of additional, system-level requirements, of which there are also two categories: Client Requirements and Device Requirements. Through the use of things like client goal mapping and quality function deployment QFD, Client Requirements allow for the conceptualization of innovative features beyond baseline functions, a current example of such being the use of IoT or Internet of Things systems. These features provide further value to users and additional revenue to MIDI’s clients. In the capture of Device Requirements, user requirements are decomposed into specific features and team brainstorming techniques are used by the development team to create new intellectual property, enhancing device value with the creation of protective barriers.
Yet, still we are not ready to move into active design and engineering; with the DevelopmentDNA™ approach following ISO 13485 very closely, further steps are required. Captured requirements must be expanded upon utilizing MatrixALM, and design inputs, verification, and validation parameters must be defined. These aspects of Stop 3, as well as the final steps of the development process, will be examined in our final episode on the Innovation Roadmap.
Stay tuned for this exciting conclusion to the second season of MIDI Innovation Vault, in which our device will become market-ready at last!
