Some of the information discussed will be the implementation of internationally recognized standards for quality systems, and the distillation of 20 years of experience in medical device design, project management, and engineering. You’ll learn how we organize our efforts and resources, and how we manage activities, timelines, and budgets. We also describe our commitment to producing optimal designs through iterative medial device development practices and building prototypes.
Table of Contents
- Part 1: Introduction
- A Medical Device Development Model
- The Model: Tracks, Phases, and Tasks
- Part 2: The 6 Phases of a Medical Device Development Project
- Research Phase
- Proof of Concept Phase
- Alpha Phase
- Beta Phase
- Pilot Production Phase
- Manufacturing Phase
- Part 3: The FDA “Waterfall” and DeviceLab’s 6 Phases
- Part 4: The 6 Medical Device Product Development Tracks – Design in Parallel
- The Intellectual Property Track
- The Medical Product Development Track
- The Risk Management Track
- The Manufacturing Track
- The Human Factors Track
- The Regulatory Track
- Part 5: Agile Hardware Development – Why It’s Important to Iterate a Design
- Assembling the Right Team
- Comprehensive Documentation
- Client Feedback
- QMS Regulations
- Part 6: The Project Management Process at DeviceLab
- Part 7: Leveraging Prototypes in Medical Device Development
- Research Phase
- Proof-of-Concept Phase
- Alpha Phase
- Beta Phase
- Pilot Production Phase
- Manufacturing Phase
- Part 8: Tips for Outsourcing Medical Product Development & Medical Device
- Development
- Scope of Projects
- Micro-management
- Subcontractors
- Development Contracts
- Communications
- Points of Contact
- Work Tracking
- Planning
- Part 9: When to Invoke Design Controls in a Medical Device Project
Part 1: Introduction
A Medical Device Development Model
DeviceLab has refined a model of medical device development that captures both regulatory imperatives and best practices in business and engineering. This blog series presents that model and explores how it accomplishes the goals we set for it. While some products are too simple or too complex for this model, most projects benefit from iterating the product through four design embodiments that we’ll call Proof-of-Concept, including;
- Alpha
- Beta
- Pilot Production
- Manufacturing
Each of these embodiments is associated with a set of goals and requirements that become more complex and stringent over time. This “multi-pass” approach facilitates thorough debugging, selection of best options, and design for manufacturing and testing. Most projects also incorporate a Research Phase where conceptual design is performed prior to invoking Design Controls.
The Model: Tracks, Phases, and Tasks
The DeviceLab RoadMap below diagrams how we organize our projects. Time flows left-to-right, and the six tracks (rows) shown represent different functional areas of the effort, with tasks generally being performed by the same specialists over the course of the program. In each track, individual tasks are shown, but they really represent just a summary of the actual tasks in the plan. Some projects won’t need all these tasks, and tasks can slide forward or backward when opportunities or problems present themselves. In that way, we adapt our RoadMap to the needs of the individual client.
Part 2: The 6 Phases of a Medical Device Development Project
We typically employ six phases for every project. Sometimes we participate in all of these phases, while in other projects our clients bring us in for a limited period. For each phase below, there’s a brief description of its purpose, activities along our RoadMap’s parallel design tracks, what sorts of prototypes might be made, and the criteria used to advance to the next phase (phase gate).
Research Phase
Purpose of the Research Phase
-
- To discover everything you need to know about the user, use the environment, product, market, technology, regulatory landscape, and intellectual property situation to make a go/no-go decision on proceeding with a medical device project.
Intellectual Property
-
- Work begins with patent searches followed by analyses of patentability and freedom to operate. Based on the results of these analyses and what markets are targeted, a legal strategy can be established for protecting IP developed and/or mitigating the business impact of existing patents.
Product Development
-
- Designers start with design research and conceptual design. Competitive and alternative products are investigated as baselines, and “blue sky” ideation is applied to develop a range of design alternatives. Sometimes the design work of the research phase can be accomplished very quickly (e.g., “me too” products), while other times, it is necessary to do conceptual design renderings and even simple prototypes to convince everyone that success is possible. While DeviceLab is typically not involved, our clients also focus on validating the clinical need, researching pricing and reimbursement, and sketching out how the product might be marketed.
Prototypes
-
- In the Research Phase, prototypes are generally just mockups with little function, produced in small quantities. They are typically used for fundraising presentations and Key Opinion Leader discussions.
Risk Management
-
- Activities start with an evaluation of known hazards (typically from predicate devices), and once a design concept is established, consideration of safety characteristics is taken into account.
Manufacturing
-
- Development begins with a process plan – how each of the components will be made and assembled based on the conceptual design. Tradeoffs based on expected production volumes are considered, and investigations are begun into whether needed capabilities are available.
Human Factors
-
- Work begins with a consideration of who the Users are (patients, doctors, nurses) and the Use Environment (hospital, office, home, mobile), followed by a definition of the Intended Use and User Needs.
Regulatory
-
- Activities begin in the research phase with a search for predicate devices and an analysis of classification and applicable standards for the device. Based on this information, an initial regulatory strategy can be developed for target markets.
Phase Gate
- The basic question being asked in the Research Phase is, “Is there a product here?” By this, we mean:
-
- Is there a real clinical need?
- Can our device address that need?
- Does it have a competitive advantage?
- Can we build it?
- Can we get it approved for sale?
- Can we protect it with a patent?
- Can we market/sell it profitably?
- It may not be possible to answer these questions fully during the Research Phase, but if the team’s impression is that the answers are probably “yes,” then the project can be greenlighted.
Proof of Concept Phase
Purpose of the Proof-of-Concept Phase
-
- In the Proof-of-Concept Phase, the team seeks to identify and eliminate any fatal weaknesses in the design concept established in the Research Phase. There may be questions about safety, efficacy, cost, ease of manufacture, regulatory uncertainties, or patentability that should be identified, ranked, assessed, and summarized. If uncertainty remains, more research is done and test systems or subsystems are prototyped and tested to answer these questions. This is also the time where Design Controls are usually invoked, starting with a formal release with documents worked on in draft form during the Research Phase.
Intellectual Property
-
- Work begins on provisional patent applications for key elements of the product with disclosures of invention by team members.
Product Development
-
- The next step is to evolve the conceptual design into a preliminary design, incorporating enough features and details that it can be prototyped and tested. Placeholder components in the research phase design are specified in greater detail, and interfaces between components are designed. System diagrams are created, and preliminary software requirements are developed.
Prototypes
-
- Proof-of-Concept prototypes are produced (often by additive manufacturing) in intermediate quantities and a variety of configurations in this phase. Software deliverables are typically just for demo at this stage, and mechanisms are simple breadboards.
Risk Management
-
- A Use Hazard Analysis is developed based on the evolving design, considering intended uses and foreseeable misuses. The risks assessed here are those of the actual use of the device on patients, not the failures of the device to operate as designed.
Manufacturing
-
- Some products are so novel or contain such novel components that they require the development of new processes to make them. In the POC stage, preliminary vendors are found, and experiments are performed to demonstrate that an effective way exists to manufacture the device.
Human Factors
-
- Based on the User Needs, Human Factors work proceeds into the design of interfaces inherent in the design. Considerations include physical shape/size, controls, displays & annunciators, ergonomics, and safety.
Regulatory
-
- The regulatory strategy is now crystallized into Regulatory Requirements in the Requirements Trace Matrix, and a formal Design Plan is created, including all the tasks implied in the strategy.
Phase Gate
-
- At the end of the Proof-of-Concept Phase, the team should be convinced that there are no insurmountable problems ahead and that solutions have been identified for all known issues. While the conceptual design may be simple, it should indeed “prove the concept.”
Alpha Phase
Purpose of the Alpha Phase
-
- In the Alpha Phase, the design is refined to incorporate the learnings from proof-of-concept evaluations, to seek out the best alternatives among the many ways most devices can be built, and to explore the many tradeoffs inherent in any design.
Intellectual Property
-
- Work continues with the development of alternative embodiments for the device, as well as methods of making or using the device.
Product Development
-
- In the Alpha Phase the POC design is refined, eliminating placeholder components. Detailed design of the parts is begun, and functional code modules are developed and connected. Components and subsystems are tested to assure needed performance can be obtained.
Prototypes
-
- Alpha prototypes are made to facilitate testing and user evaluations, aiming to show that proven concept can be an actual product. These prototypes are sometimes both aesthetic and functional (but usually limited to a few functions of interest). In Alpha prototypes, the software is usually demonstrated offline, often using a non-functional simulation. Electronics might be spread across the lab bench and hooked up to instruments, but basic functions are shown to be operable. Mechanisms, sensors, and interconnects are selected, and software tools and platforms are established. Occasionally, several design embodiments may survive and compete through the Alpha stage.
Risk Management
-
- Now that the design concept is firming up, the risks in the design can be identified and evaluated, using tools such as FTA, FMECA, etc. Plans for risk mitigation are formed and put into place. While the design is still evolving, much of this work can be done at this time.
Manufacturing
-
- Around this time, it’s important to begin the process of vendor selection and qualification. Oftentimes our clients need no new vendors, but any new design may bring new requirements those vendors must agree to and comply with.
Human Factors
-
- With Alpha Prototypes and user testing, the interface design candidates are finalized, and a protocol for the Formative Study is written.
Regulatory
-
- Important tasks in this phase include the release of the Design Input Requirements and a Requirements Traceability Matrix.
Phase Gate
-
- At the end of the Alpha Phase, the team should be convinced there’s a proven way to make the device. All of the important design options have been explored, and choices made among them.
Beta Phase
Purpose of the Beta Phase
-
- In the Beta Phase, the design incorporates features that aren’t necessary during earlier evaluations, like shielding, water ingress, and safety features. Prototypes are built that combine functions that may have been demonstrated separately during Alpha. Details like assembly breakdowns, fastening methods, the system block diagram, and software division of labor are decided upon and evaluated with Beta Prototypes. Material selection, especially for patient contact components, and packaging design, are begun. The design is reviewed for manufacturability, and any issues are addressed prior to tooling start.
Intellectual Property
-
- A lot is learned during medical device product development, and in response, there are often additional patents, continuations, or divisionals that need to be filed. Depending on the markets sought, foreign patent applications may be filed.
Product Development
-
- In the Beta Phase design documentation is assembled into a Device Master Record. Preparations are made for Design Verification and Validation testing, including the development of protocols and liaison with outside labs. Any design issues that arose in Alpha Phase testing must now be resolved.
Prototypes
-
- Beta prototypes are made as needed to support refinement testing and user evaluations post-Alpha. There is typically only one embodiment tested at this stage.
Risk Management
-
- Risk Mitigation is the primary task in this phase, including verification of mitigation. Aside from the risks associated with manufacturing processes, all known risks should be mitigated to acceptable levels.
Manufacturing
-
- At this time, the design of many parts are already frozen, and tooling production can begin. Arrangements are made with vendors for the production V&V (verification and validation) units, and work instructions for any new processes are written.
Human Factors
-
- Using Beta prototypes, the Formative study is performed, and any findings impacting the design are incorporated into the Pilot Production version.
Regulatory
-
- In the Beta Phase, the Device Master record is compiled and critically reviewed for Pilot Production suitability.
Phase Gate
-
- With the update of the design based on the learnings of the Beta phase, the design is frozen. It’s expected that any design changes proposed during or after Pilot Production will be minor enough as to require little or no re-validation. The big question at this time is whether the product is “Pilot Production-ready,” including all parts of the supply chain.
Pilot Production Phase
Purpose of the Pilot Production Phase
-
- In the Pilot Production Phase, the primary purpose is to work out any bugs in making the product in volume. It’s also the time where V&V and safety testing is performed, and where much of the paperwork is wrapped up.
Intellectual Property
-
- Prior to this time, it’s safe to be stealthy, but when your baby leaves home, it needs protection. If any patentable art hasn’t been filed, it gets filed now.
Product Development
- This phase is all about V&V testing, including building the test units. Activities include a lot of vendor liaison and paperwork.
Prototypes
-
- Pilot Production units are as close to sales units as we can make them so that V&V testing remains valid when you enter production. Depending on the types of V&V tests required, they may be produced in anywhere from tens to thousands of units. Pilot Production prototypes are also often used for sales and support training.
Risk Management
- As the manufacturing processes have been established, a Process FMEA (failure mode and effects analysis) can be performed and used to mitigate any risks found. Together with the Use and Design analyses, residual and overall risks can be shown to be mitigated to an acceptable level.
Manufacturing
- This is a very busy time, with operator training, process validation, and the manufacture of Pilot Production units.
Human Factors
-
- Using Pilot Production prototypes, the Summative study is performed, demonstrating that the device will be properly and safely used.
Regulatory
-
- At this time, activities depend on the device classification. Tasks may include preparing technical files, 510(k) submissions, PMA supplements, or IDE filings. Clinical trials are performed, and preliminary meetings are held with FDA, Notified Bodies, Institutional Review Boards, and Ministries of Health.
Phase Gate
- The Pilot Production Phase ends when development is over, and manufacturing begins in earnest. So, the phase gate questions are all about “is it ready to sell”:
-
- Is the design Verified and Validated?
- Have all individual risks and overall risk shown to be acceptable when compared to benefits?
- Has all-important intellectual property been secured by patent, license, or other means?
- Are all regulatory requirements fulfilled?
- Is the design properly documented in the DMR?
- Is the development properly documented in the DHF?
- Is the design intuitive, ergonomic, and safe to use?
- Are the manufacturing processes capable?
- Can the device be produced for an acceptable cost?
Manufacturing Phase
Purpose of the Manufacturing Phase
-
- This is the only phase where a long duration is desirable. At this time, you want the development team to be done and off on their next project. This is only possible if the design has been properly transferred during Pilot Production, and the Manufacturing team knows everything it needs to.
Intellectual Property
-
- When you start selling your product, the competition may try to invalidate some of your IP (intellectual property) or show that you infringe on some of theirs. Defending your IP against such assaults, and extending the range of your patent umbrella become the important things. It’s also a time to consider whether other companies might benefit from your inventions and would be willing to pay for a license.
Product Development
-
- It’s done now. Negative customer feedback or adverse events are two ways that the design team might be called back in to help evaluate device failures or assist in any needed redesign and revalidation. Customer feedback sometimes identifies opportunities rather than problems and a re-design might stem from one of these.
Prototypes
-
- Prototyping is also over, except to support any redesign efforts arising from post-market feedback. Prototyping resources may be involved in making tools for support and training activities.
Risk Management
-
- Once a product is in production, Risk Management takes a monitoring role for the field use of the product and the processes used to make it. When any new risk-pertinent information comes in from the field or if any design changes are made, Risk Analyses may need to be performed again.
Manufacturing
-
- Production, support, and service are the focus now. Efforts to reduce COGS (cost of goods sold), improve process capability, reduce WIP (work in progress) and lead time, or increase quality become routine work.
Human Factors
-
- As with Risk Management, Human Factor issues may arise if users find a new way to misuse the product, or if continued use results in ergonomic or safety issues. Documentation such as manuals and labeling may require revision to address such issues.
Regulatory
-
- Maintenance of the system established during the design by monitoring and measurement, quality audits, CAPA (corrective and preventive action), and management review is the mission. In the case of adverse events or complaints, it may be necessary to perform investigations and notify regulators.
Phase Gate
-
- Manufacturing ends when you don’t want to sell the product anymore. But as long as your product is in the field, you remain responsible for it in many ways. Before you can kill a product, you need to plan for how you will continue to service and support existing customers, transition them to your new product, or even decommission equipment.
- So, that’s how we look at projects here at DeviceLab. In our next post, we’ll talk about how DeviceLab’s process for medical device development compares to the famous FDA “waterfall” diagram. See the Process and Compliance pages on our website for more information on how we do things.
<h2id=”Part-3″>Part 3: The FDA “Waterfall” and DeviceLab’s 6 Phases
You’ve all seen it. It’s one of the first slides in the Design Controls training class deck –
It’s a description of the interactions between certain factors and processes in the development of medical devices. In the white boxes are a series of steps from User Needs to the Medical Device, with progression governed by Design Reviews, and based on two comparisons: Design Output to Input during Verification and Medical Device to User Needs during Validation. This structure is a logical construct; more a map than a plan. It also omits the required steps of Design Planning and Design Transfer, but that’s because they don’t participate in the explicit feedback loops that are the meat of the diagram.
While this map is intended to drive the development process to a high assurance of safety and efficacy, it cares not about business imperatives and offers no help on how to actually design a device or run a project. This is deliberate – people can find many ways to accomplish things, and the FDA doesn’t care how you do it as long as your process incorporates the necessary controls and can prove that they work. So, each organization that seeks to develop a medical device must develop its own system for product development that meets regulatory requirements and works for their particular needs.
At DeviceLab, we have developed a framework for medical device projects that incorporates six phases (see the prior post in this series for more details). These phases are established to capture the elements of the waterfall diagram, as well as an iterative development approach so successfully employed in Agile Software Development. Of course, some projects are so much bigger or smaller than typical that this model can’t be applied, and often we get involved with a subset of the phases. However, this framework is a useful tool for thinking about the organization of a project, regardless of size.
So, how does our six-phase approach map to activities on the traditional FDA waterfall? While not an exact match, here’s what we deploy:
- Proof-of-Concept maps to Design Planning
- Alpha maps to Design Inputs
- Beta maps to Design Output
- Pilot Production maps to Design Verification and Validation
- Manufacturing maps to Design Transfer
We work by incrementally chipping away at the very long list of things to do in digestible chunks along six parallel design tracks. We see the FDA Waterfall as a framework by which an evolving design progresses through successive versions, each accomplishing a greater portion of the requirements until they are all satisfied.
In our next post, we’ll talk about the six parallel tracks of activity that operate during a medical device project. You’ll learn more about how the project looks to each of the various disciplines involved and how they cooperate to achieve your goals. Please visit the Process and Compliance pages on our website to find out how we do things.
Part 4: The 6 Medical Device Product Development Tracks – Design in Parallel
Medical device development is an interdisciplinary task. Designers, engineers, scientists, manufacturing, regulatory, medical, legal, and business specialists all work together toward a common goal but have distinct contributions to the medical device development. At DeviceLab, we’ve organized these efforts into six tracks, which covers the needs of most projects. Our RoadMap below shows this structure graphically.
The Intellectual Property Track
This track begins with patent disclosures and searches and continues through a Freedom to Operate and Patentability analysis. As the product design evolves, provisional patent applications are prepared and alternative embodiments, such as “methods of making” and “picket fence” ideas are explored. One the design is mature, but before public disclosure, key design and method patents are filed. After this basis is established, an international IP strategy is implemented, and any available licensing options are explored.
While much of this work is done by lawyers, the development team contributes many of the ideas, depictions, data, and technical argument. There is often some patent coverage extent before the start of a project, but valuable additional art is usually acquired during product realization, especially alternative embodiments and discovery of key design parameters.
The Medical Device Product Design Track
Product Development begins with Research and Conceptual Design. Building on this concept and User Needs, regulatory requirements, predicates, and known hazards, designers and engineers craft Design Input Requirements that capture the essential features of the intended product. Working from these inputs, the team creates and tests multiple iterations of the product design until all requirements appear to be met, and records the resultant design as Design Outputs. When Outputs are complete, they are compared against the Design Inputs in Design Verification, and the medical device itself is compared against the User Needs in Design Validation. Design Transfer follows, to ensure that the design is correctly transferred to manufacturing (Device Master Record) and all requirements will continue to be met. Throughout the process, a Design History File is accumulated.
Product Development is often done by specialist engineers and designers, rather than the inventor or technical team of the manufacturer. Along the way, multiple prototypes are created and tested, and design reviews are executed to ensure that the project is meeting its goals.
The Risk Management Track
Risk Management starts with an investigation of similar products and known hazards, and as a design concept emerges, a consideration of safety characteristics. In combination with User Needs, Intended Use, foreseeable misuses, and regulatory requirements, a Use Hazards Analysis is performed so that mitigation means can be incorporated into the design. Once detailed design features are established, Risk Analysis using tools such as FTA, FMECA, etc. are applied. Hazards are mitigated as far as possible and verified in the Risk Management Report. During Pilot Production, a process FMEA is performed, and residual and overall risks are assessed to ensure acceptability. Before transfer to manufacturing, a HACCP analysis is performed and a control plan is implemented. Depending on the device, Post-Market Surveillance systems may be established.
Depending on the size of the organization, the team players on the Risk Management Track may be specialists or the same people performing the design, human factors, manufacturing, or regulatory tracks. Many companies rely on consultants for tasks such as predicate and known hazard research.
The Manufacturing Track
The Manufacturing Track starts with a plan to manufacture, assemble, test, and package the device. If necessary, manufacturing processes are developed and demonstrated as a part of Proof-of-Concept. Vendors are selected and qualified in the Alpha Phase, and tooling and work instruction development follows in Beta. Operator training and process validation are completed as the first part of Pilot Production, where units needed for validation testing, marketing, or other purposes are produced. The Design Transfer Design Review marks the transition to production for sale.
As with Risk Management, manufacturing specialists (with a contract manufacturer, for example) can perform the tasks on this track, but they are often performed by development engineers due to their familiarity with the design.
The Human Factors Track
30% of medical device adverse incidents reported to the FDA are user errors, not device failures. Human Factors Engineering is applied to mitigate these risks by creating intuitive, comfortable, and fault-tolerant designs with proper instructions and/or training. The process begins with a consideration of user needs, combining information from literature, the MAUDE reporting system, and user research. During Design Input, the device interfaces, intended uses, and foreseeable misuses are considered. During Design Output, interface approaches are prototyped and tested to assure that they address Human Factors properly. Approaching Design Freeze, protocols are developed for Human Factors User Studies; generally, a Formative Study followed by a Summary Study.
Most Human Factors/Usability engineering is typically performed by Industrial Designers working with the engineers doing the detailed mechanical, electrical, system, and software engineering.
The Regulatory Track
The Regulatory typically begins with a consideration of predicate devices. Even for entirely novel devices, there may be predicates for major components or functions to be found in earlier devices. Based on this review, a strategy can be formulated for regulatory approval in the markets targeted. Beginning with an evaluation of the likely Classification (I, II, or III) of the device, and requirements coming from consensus standards covering the device type (e.g., IOL, heart monitor, scalpel) pertinent regulations can be applied. A plan for regulatory compliance is incorporated into the Design Plan. During Design Input and Output, a Design History File is maintained, and Design Reviews are performed to document compliance. During Design Verification and Validation, protocols are populated with any tests required by regulation or standard, and test outcomes are compared with requirements. Around the time of Design Transfer, the Regulatory Track is usually consumed with the production and presentation of a Design History File and Device Master Record in an approval process before FDA and/or an ISO Notified Body.
Regulatory Track tasks are usually performed by specialists. At larger companies, these people are usually in-house, but it is typical for startups and common for small companies to hire regulatory consultants to help out.
Conclusion
We hope this look into how the various disciplines operating in a project work and cooperate stimulates your thinking about how to accomplish project goals in device development. Our next post in this series talks about how the Agile approach can be applied to the development of hardware as well as software, and what benefits this approach provides to the client. See the Process and Compliance pages on our website to learn more about how we do things.
Part 5: Agile Hardware Development – Why It’s Important to Iterate a Medical Device Design
In the Agile Manifesto, Agile Values are defined by a series of preferences:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
All of these values can be applied to the development of hardware, but as others have noted, hardware is different in procurement and changes lead times, component costs, and the diversity of disciplines working in the team. Daily stand-up meetings may not be able to include the whole team. New working deliverables can’t appear after an all-nighter. Making dramatic changes late in the game can be a lot harder because component interfaces can be more complicated.
Medical device projects face additional regulatory requirements that make it hard to adhere to some of the values. One can’t work without a plan or comprehensive documentation (at least of the final product), development contracts are required (as is vendor qualification), and adherence to defined processes is beloved in the hearts of device manufacturers (and enforced by their Quality Management Systems).
So, with all these obstacles, what parts of the Agile approach can be applied to hardware development, specifically medical device hardware? DeviceLab does the following things to implement Agile values in our work:
Assembling the Right Team
We take care in establishing our project teams to select not only the right technical background, but also the right capabilities, desire, and fit with the rest of the team. We collaborate very closely in a common workspace and with frequent client contact. Our telecommunications infrastructure promotes high-bandwidth exchanges.
Comprehensive Documentation
Comprehensive documentation is a requirement in medical devices. We can’t really value it very much, but we can be efficient about how much we do and when we do it. Lots of important design questions in a project can be answered in a Research Phase prior to invoking Design Controls, which significantly reduces paperwork. The emphasis on working product over comprehensive documentation is something we respect with a focus on the frequent delivery of working components and subsystems in a series of prototypes with ever-improving fulfillment of design requirements.
Client Feedback
DeviceLab believes that frequent client feedback is essential for success in our projects. We find that it’s better to have development contracts which don’t tie down requirements too much too soon, and evolve the plan as we go. We meet regularly with clients so that they know exactly what’s going on. When the client is in the loop, and trust is earned, contracts can be less prescriptive and thus more flexible. And, everyone benefits by spending less time on tracking and haggling over numbers that don’t measure success.
QMS Regulations
QMS regulations require that all medical development projects must have a plan and that you actually use it. However, they don’t say a whole lot about just how detailed your plan must be. They do say that plans can be revised during a project and encourage you to do so. Everybody knows that things change during a development project. You change course, like choosing to do something in hardware instead of software. While the end device may look identical to the user, the development plan will be much different. The trick to balancing these competing factors lies in developing plans that acknowledge possible forks in the road and don’t contain unnecessary detail in future phases. We then make it easy to revise the plan and review it regularly as we work through the phases. For example, as we’re wrapping up the Beta Phase, we’ll update the plan for Pilot Production phase from a simplified placeholder to a real plan for the upcoming weeks or months.
It may seem like the dogma of Design Controls is incompatible with the Agile Manifesto, but it turns out that you can adopt a lot of Agile thinking in medical device development. It’s really more about teamwork and the process of doing development projects, so much of the Agile mojo is available. See the Process page on our website for more information on how we do things.
Following that line of thought, our next post is about project management specifically. We’ve done a whole lot of projects at DeviceLab, so we have a few thoughts on the matter…
Part 6: The Project Management Process at DeviceLab
Because we’ve done so many projects in our 20 years, we have developed a process for managing projects that establish needed controls, allows our teams to work effectively, and provides visibility to the client. This process is in compliance with regulations for outsourced development work and embraces the values of the Agile manifesto.
Medical device product development & project development starts with a discussion. There are many things we need to learn before we can determine that we have access to the skills needed for the project and that our organization has the capacity to handle your project. We need to understand the technologies involved, where you are in your work so far, and what goals you have for the product. This discussion is usually between our client’s program manager and a few of DeviceLab’s senior staff, often in a teleconference.
Based on all the input we receive, and if the project looks like a good fit for DeviceLab, we then prepare a Project Proposal which includes a description of tasks to be performed, estimated timelines and costs, and the deliverables to be provided. We submit our proposal and follow-up with a call to answer any questions or make any requested tweaks. If the proposal meets with your expectations, a Development Contract is executed, and DeviceLab begins work.
A Project Manager is assigned as the main point of contact for all business issues (budgets, billing, and reporting), but they also serve as a technical leader for the DeviceLab team. We appoint designers and engineers to the team so that it is properly resourced, and establish project directories and charge numbers. A Project Plan is prepared so that you can see all of the required tasks and can track progress against each one. The plan typically shows the first phase in detail and the big picture in subsequent phases.
We like to start projects with a Kick-Off Meeting with all stakeholders present to make sure we receive all inputs available. It’s a good way to make contacts within the team and achieve consensus on the path ahead.
Once a project is underway, the project manager is responsible for keeping the customer in the loop. Regular progress reports, detailed billing, and frequent meetings prevent runaway projects. The project manager is also responsible for resolving technical disputes, providing resources, and chairing meetings, including design reviews. As the project proceeds, the project manager updates the project plan and associated cost and time estimates going forward.
When a project reaches completion, the project manager oversees the transfer of all of the materials, product, and information accumulated back to the client. Records may be retained, depending on the contract and whether future work is anticipated.
So that’s how we do project management at DeviceLab. We have a well-honed process that keeps problems at bay and delivers quality designs by design. In the next post in this series, we’ll talk about why we like to build prototypes in device projects, generally several times.
Part 7: Leveraging Prototypes in Medical Device Development
There’s a long list of reasons why we believe it’s wise to build prototypes when you’re developing a medical device, but the overriding reason is to facilitate learning. Even experienced designers, aided by powerful design and analysis tools, learn a lot by building prototypes. Predicting things like the best shape for a surgical handpiece or the best way to organize an input form can be difficult without trying it out in actual or simulated use. Performance of mechanical or electronic systems can be simulated, but simulations are rarely complete and can be fooled by unexpected things in the real world. Only by building actual prototypes you can interact with, criticize, and improve can you truly achieve an optimal design for your product.
So, when should you build a prototype? How many should you build? What functionality should they have?
Using our six development phases as a framework, what follows is a discussion of the prototypes that might be made in a project, and their purposes and uses.
Research Phase
Prototypes made in this phase are usually about providing a tangible representation to facilitate user discussions and support presentations for fundraising. They rarely are functional but are sometimes made with fine finishes to appear realistic. Few units are needed, but there are often multiple embodiments depicted. These prototypes are inexpensive and can be produced very rapidly.
Proof-of-Concept Phase
In this phase, prototypes are used as tools to prove the product concept. Usually, they’re used in tests of functions where there is some doubt about feasibility. This may mean whether users can accept a surgical tool of this weight in the intended procedure, that a fluidic circuit can separate cells as intended most of the time, or that a patient can understand what a diagnostic device is telling them and act properly. It usually doesn’t take more than a few units to prove out a problem area of a product concept, but there are sometimes several areas that need testing in separate prototypes. Except in cases of high complexity, POC prototypes are usually modest in price and can be built quickly.
Alpha Phase
Alpha Phase prototypes are used to determine specific use details and performances of the device and to work out details of how it will be put together. These prototypes help work out the specific requirements that are important to safety and efficacy and facilitate major design decisions. Since Alpha testing is more specific and precise, multiple units may be required and their functionality will be greater than POC prototypes. They will also be more expensive and may take longer to build.
Beta Phase
Beta Phase prototypes are used to evaluate whole systems in the design. Final component choices are often used, and things like battery life, cabling, ingress protection, grounding, shielding, EMC, and ESD are subjected to preliminary tests. The quantity of Beta prototypes needed varies by type of product, and the tests needed to verify required performances. Cost and lead times are similar to Alpha prototypes.
Pilot Production Phase
Pilot Production prototypes can be extremely important. These units are intended to be functionally equivalent to production units and are used in verification and validation testing. Any design change after V&V testing may create the need for revalidation, so the design is generally frozen after all the learnings of the Beta Phase have been incorporated. V&V protocols will determine the number of pilot production units needed. These units generally cost a bit more than production units due to small batch sizes and more expensive labor and take a little longer to build.
Manufacturing Phase
The need for prototypes pretty much disappears when production units appear, but they are still occasionally produced for trade shows and manufacturing operator, user, and sales training. Sometimes units are built to show design options our client would like to explore or lacking expensive or hazardous components to be used for demo only.
Conclusion
At DeviceLab, we make prototypes early and often throughout the process. It’s true that they can sometimes be costly, but the learning they provide is invaluable. They also provide assurance that things are on track in a project and reveal opportunities for design improvements. Altogether, making prototypes is money well spent. Check out the Process and Compliance pages on our website to discover how we do things.
In the next post in this series, we’ll talk about the design process from our client’s point of view and offer several tips on how to successfully outsource design projects to companies like DeviceLab.
Part 8: Tips for Outsourcing Medical Product Development & Medical Device Development
DeviceLab has been doing medical device projects for 20 years, with over 100 major programs completed. Our team also includes members who have worked at other design firms, and have seen lots of different approaches to program management. As a result, we have developed a set of practices that reduce friction, speed progress and maximize synergies. Looking at this body of knowledge from our client’s point of view, we can offer a series of tips for doing business with a firm like DeviceLab.
Scope of Projects
Our clients have a wide range of capability in-house. Some of them are large, capable companies that come to us for work in a single discipline, like Industrial Design or Software Engineering, because of our talents or experience in the field. Others are startups, seeking to outsource all or nearly all of the development work. There are advantages to both approaches, as well as difficulties. If you bring in just one discipline (say Industrial Design), you save money by using your in-house Mechanical Engineers. However, you also accept the responsibility for how ID interfaces with ME and Software. If both are outsourced, the coordination is our responsibility and occurs between people that work together every day. Outsourcing entire projects to a design firm puts all of your eggs in one basket but also precludes pissing matches between multiple contractors when things don’t go right.
Design firms have a culture of moving fast that’s very hard to duplicate in a large firm. So even if you can do some of it yourself, consider the advantages of outsourcing more to a company who does new products every day. Our tip is to use a vendor who has the scope to handle all of the things you need and put as much as you can on them.
Micro-management
Sometimes, our client contact is a development professional who cares deeply about the process of design. If their ideas about program management differ from the project manager DeviceLab has assigned, our contact may become overly involved in assignments, scheduling, and work tracking in minute detail. This is counter-productive. Our project managers know how to best leverage the talents of the teams we assemble and have a lot of experience in managing disparate assets to accomplish plans. Insisting on justifications for minutes charged (for example) not only takes your project manager away from value-added activities like resolving technical issues but imparts a chilling effect on the team that makes them want to prematurely end activities to meet a budget. Our tip is to resist the temptation to micro-manage a project.
Subcontractors
Sometimes, DeviceLab doesn’t have a specific skill (or enough bandwidth in a skill) to support a project. We turn to our subcontractor network in these situations, a set of individuals and firms we work with all the time. Our network contains resources with deep technical expertise, but it’s also informed with their observed performance on multiple projects. In this sense, our subcontractors are more deeply vetted than is possible for a company who doesn’t do a bunch of development projects every year. Our tip is to let your design firm choose their subcontractors – you may know a really great resource, but ours are great too, and we know how to work with them.
Development Contracts
Medical device development work is usually outsourced under a development contract formed between the design firm and client. The contract usually specifies the work to be performed, the requirements imposed, the results expected, and estimated costs and duration. As development work resolves many unknowns, it’s not possible to produce accurate budgets or timelines before a project starts. Attempts to do so only create a dangerous fiction that can be clung to in the face of a very different reality. Moreover,firms that claim to be able to do a large project on a fixed bid are the same ones that come back for more money when you’re 80% done. Our tip is that it’s more sensible to expect rough estimates for whole project budgetary purposes, and specific budgets for only the current phase and the next one.
Communications
Many companies, especially large ones, have communication problems. People get comfortable in their silos and don’t talk as much as they should. When you outsource a development project, communications can be even worse, but they can also be better. Why is that? The internal communication between the folks at DeviceLab is really great, probably better than in most of our clients, and unlike your internal team members, our folks deal with outside contacts every day. We’re also accountable for communications in a way that often exceeds the accountability of our clients’ employees. What this means is that we can be trusted to hold up our end of important knowledge flows. Our tip is to expect great communication about the project and insist on it from start to finish.
Points of Contact
In the same area of communications is the designation of points of contact in a program. Both the client and DeviceLab must make it clear who is the point of contact for each topic or area. We insist that all communications to DeviceLab be copied to the project manager, but we also designate specific points of contact in-house who have assumed responsibility for portions of the design like electronics or ID. To the extent that client employees are also working on the project, it’s important to designate specific ones as points of contact, empower them, and assign responsibility for liaison with the design firm resources. Our tip is to make sure you know who is responsible for each aspect of the project, both in-house and at the design firm.
Work Tracking
Every project establishes expectations when started, and nobody wants to wait for the end to know whether those expectations will be met. This impatience expresses itself as a desire for information that purports to measure progress so that the measurement can be compared to the expectation. While it’s true that “% of task effort completed” and “% of task budget spent” can be compared to measured progress, it’s important to remember that the budget is a number you estimated before you began and the % completed is an estimate from a worker still working the incomplete task. It’s dangerous to fall into the trap that the plan is infallible in predicting effort and browbeat individuals because unknown things changed our predictions of reality. Our tip is to use progress tracking at a coarse level – ignore individual tasks and focus on phases to manage budgets and schedules.
Planning
You have to have a Design Plan in any medical device project. You may already have created one – if so, that’s great. You may also have a plan for the development project, including things that don’t bear mention in the Design Plan. In fact, most clients walk in with one or both of these plans at some level. So, we see a lot of plans for medical device development,and have written many ourselves. What we’ve learned is that planning new product development is different from planning more predictable activities like putting up a new commercial building. There is far more uncertainty, including the “unknown unknowns,” which are impossible to plan for. Fortunately, reducing this uncertainty is a prime objective of development, so as a project moves forward our view of the future improves. Our tip is to plan the distant future in broad terms and the near future in specific terms, then refine the plan as you progress through the phases.
Conclusion
DeviceLab gets a lot of repeat business because we’re good at being an outsourced team. To get the best out of us (or any other design firm), follow these tips and you’ll have much smoother sailing. See the Process page on our website for more information on how we do things.
Part 9: When to Invoke Design Controls in a Medical Device Project
Many medical device executives bemoan the burdens of Design Controls, claiming that they stifle creativity and drive up costs. That may be so, but we’re stuck with them. Given their unavoidability, we’re left to find ways to make these controls less burdensome and perform whatever work than can be done outside their strictures “off the books.”
The first part of this is making your QMS agile and easy to use so that compliance with design controls carries as little cost as possible. This means a less prescriptive approach, elimination of low-value process requirements like restrictive formats, and efficient approval routing. This style provides less hand-holding and can be problematic with inexperienced workers, but can be safely used by the experienced development professionals at DeviceLab.
The second part is embodied in what we call the Research Phase. At DeviceLab, we use the research phase to answer known questions and discover unknown unknowns prior to establishing the proof-of-concept design. Documentation is limited to research notebooks, which are not released to document control. In this mode, we’re free to change paths instantly, try multiple alternatives, and pursue ideas.
The research phase ends when a conceptual design has been formulated. A formal design plan is created, and the design requirements are accumulated. Information can flow from the Research phase into Proof-of-Concept (like design choices), but if there is an important research test result underpinning the design, you may want to go back and repeat it under controlled and documented conditions.
So, in our experience, most projects benefit from a little time in the unsupervised sandbox before moving to the pool with its long list of rules. When playtime’s over, we invoke Design Controls built for rapid evolution. In this way, we keep the burdens of Design Controls from vexing our clients.
That’s the last post in this series about the process of medical device design at DeviceLab. If you haven’t read the previous ones, please check them out!
