For almost 30 years, medical device product developers have thought of design control in the simplistic model shown below from US FDA (Design Control Guidance for Manufacturers, March 1997).
The image often articulates a rudimentary, cascading methodology, starting with User Needs, which are then translated into technical Design Inputs. Through engineering expertise, these Design Inputs are transferred into tangible elements of the design, known as Design Outputs. Design Verification then evaluates the Design Outputs against the Design Inputs (e.g., Did I design the product right?), whereas Design Validation assesses the device design against the User Needs (e.g., Did I design the right product?). At key points along the way, Design Reviews are held. The whole effort is considered the ‘Design Process’, this is what FDA is looking for illustrated by the box in the very middle of the graphic. Something to control the chaotic world of product development. Lest we think this is an FDA-only desire, largely this rubric has been adopted by ISO 13485.
Moving toward New Product Development
Seeking better Design Process control, many Medical Device Manufacturers (MDM) have expanded upon the FDA image with tangential concepts such as stage gates, design checklists, and, in many cases, entire teams dedicated to design control process assurance. The best MDM product developers have detailed design control procedures that have clear requirements for entering the design control process, with detailed requirements for the different phases or stages of the design control process. Where each stage or phase has a detailed checklist and often a detailed list of attendees with deliverables for the review at each of these stages or phases. Extending this idea of process clarity for product development, a more modern interpretation of the old design control waterfall image may look something like the image below (DQS, 2023).
The intent here is to bring details of the product development process to its participants. Maybe this image is akin to a musical conductor's score, as in a Philharmonic Symphony. The conductor score tells the conductor who is supposed to play what note and when, so when all sections of the symphony are played correctly, beautiful music is produced. Remember, that New Product Development (NPD) is a team sport (e.g., Design, Test, Marketing, Regulatory, Quality, Supply Chain, Manufacturing), which is precisely the intent of this more detailed modern interpretation of the FDA design control methodology. I have for years taught project teams to leverage detailed design control procedures, specific design and development plans that articulate every single step of the product development effort, along with defining who is supposed to conduct each activity, and who should review each activity required by the design control process.
Introducing the Secure Product Development Framework
Today, focusing on connected devices, in late 2023, FDA issued guidance on robust cyber security development practices. In creating this guidance, FDA has leveraged other standards from divergent industries with tangential technologies to help MDMs develop secure devices. A key element in designing robust, secure medical devices, according to this guidance, is for design teams to have a clear development framework. FDA calls this a Secure Product Development Framework (SPDF). So, what is an SPDF when it comes to connected devices? What are regulators looking for from medical device manufacturers regarding these connected devices? The guidance describes several design artifacts such as Network Diagrams, Threat Models, Security Architecture, Software Bill of Materials (SBOM), Security Risk Management, and specific Secure Design requirements.
What the FDA is looking for from MDMs is a Design Process that builds upon the decades of refinement of the old FDA waterfall image to a Design Process that is not only clear about when User Needs should be defined, when Design Inputs are required or when a Risk Management Plan is created, but a Design Process that will yield secure, robust connected devices. The only way that can happen is with a deliberate design process for the items and activities that are unique to connected devices. SPDF simply says that all these connected device design artifacts that you should produce are because we believe those activities and artifacts will yield a secure device. But as you probably can imagine, it's not enough just to produce these design artifacts haphazardly. These design artifacts have to be generated according to a cadence, in support of a development plan, by a knowledgeable, cross-functional team. In other words, according to a development framework or Design Process.
Be Intentional When it Comes to Security
So, after decades of operating using this design control language, we understand that Design Inputs happen early in the development process. We know Design Outputs are probably created somewhere in the middle of the design control process. We certainly know that Design Verification and Design Validation happen closer to the end of the development process. What SPDF is asking for is that these security-related activities and artifacts are intentional regarding where they are created in your design and development process, who creates these artifacts, what is the content of the artifacts, and who reviews/approves these artifacts. SPDF is asking you to build upon your existing Design Process and overlay on top of that an intentional methodology that encompasses critical security-related design activities that articulates when they happen and by whom and who is approving those activities. In other words, be intentional about the things that you should be doing to design robust, connected, secure devices. Certainly, NPD can be chaotic, which should be expected when you are inventing something new. A well-known approach to help manage this chaos is process development, or, in short, a defined process with steps and a plan. SPDF simply extends this thinking around the Design Process to encompass the appropriate security-related design activities. As with many things in the medical device world, we are bound and defined by process, whether it's design control, risk management, usability engineering, or software development. These are all process standards or regulations. Designing connected devices is no different.
Medical Device Security is Challenging - We Can Help
Efficient and effective process design takes time and effort. Even the most astute MDMs are challenged by bloated, ambiguous process elements. Your product development teams depend on process clarity. To discuss your existing design control processes and to make sure your teams can design secure connected devices, contact us for an initial dialogue.
In future blog posts, we will talk about the individual secure design artifacts mentioned here and go into great detail to help you understand what's required of these unique security design artifacts:
Threat modeling
Risk assessment
Validation and testing
SBOM and Vulnerability Management
About the Author
Dr. John Salvato, President, Design Quality Services LLC
Design Quality Services (DQS) was established to support large and small innovators' product development endeavours, resolve quality system challenges, and provide technical training. The pathway to commercialization is complex, regulatory expectations can be ambiguous, and quality management systems (QMS) may become unstable. DQS brings a pragmatic approach to enable these pathways, fostering business growth and market success. We are here to help you solve your toughest challenges. John has an impressive 30-year career spanning quality assurance, manufacturing, and product development in the medical device and automotive industries. As the president of DQS, he brings exceptional engineering abilities and unparalleled global management experience. His leadership has led to successful development projects globally. John leverages his many years of professional experience with his academic work.
コメント