Integrity Research and Development

Working with entrepreneurs, startups, and even larger companies, the biggest challenge is to step away from the benchtop and planning. When we have an idea, the first thing we want to do is build it. We know that investors or companies that may license or acquire us will not do so without a paper trail and no product. There is no fun in writing documents, i get that. But for an analogy, if you were building a house, would you do so without planning where the rooms will go, their sizes, electrical wiring, plumbing? You may know in your head what you want you want, in theory, but a great deal of preplanning goes into a building project before the first tree is cleared. And yet, when developing a medical device, whether it is software, a instrument set or surgical robot, too often multiple prototypes are built without a single thought to planning out what is going to be built.

As a Research and Development Engineer, I dislike the paperwork as much as the next engineer. But i also don’t like wasting money or time(Time = Money). I don’t think anyone does; and yet, it is difficult to convince engineers and entrepreneurs to slowdown and plan. We want to see physical results. We want to know that our idea works.

Why Plan:

As engineers, we like to tell you, Time, cost quality, pick two. Yet, you can have all three if you understand that time is relative, cost is relative, and quality is not to be compromised. If you consider the entire product life cycle in your paradigm.

As engineers, we like to tell you, Time, cost quality, pick two. Yet, you can have all three if you understand that time is relative, cost is relative, and quality is not to be compromised. If you consider the entire product life cycle in your paradigm.

During the different phases of the lifecycle of a product, the impact of unclear plans can impact the number of iterations of a design that may be needed. Each integration costs money and time. Unclear plans can increase the number of experiments. Testing costs money and time. Without proper planning, a design may get completed, but have no acceptance into the market. The development process costs money and time.

Understanding that quality can’t be compromised in the lifecycle of a device, we all want to maximize cost and we all want to get done as fast as possible, when do we need to start our planning and what should we include?

What should you do to Plan?

The FDA guidance for Design Control and ISO 13485 do not dictate the proof-of-concept phase of a product. Design Control does not start until after this phase. ISO 13485 is focused more on the quality system, and the output of what documents should be present for a product, but not when they should be written. Therefore, as a research and development consultant, it is my job to provide the best advice to clients about when to start planning and what to include when. Two of the most important documents at the start of any project, for the technical team, are the User Needs and the Hazard Analysis documents. Both can take time, require multiple people to input and seem useless at the beginning of a project. User Needs drive the requirements of a product. And although they are required for design control, their ability to drive a design in the right direction is something that many entrepreneurs miss. Often, the starting point is an idea that solves (maybe) what they see as a problem in a particular discipline. By systematically defining who the users are and going through what the needs are for the solution from each user type’s perspective the development team can focus on defining the requirements based on what is relevant verses what is not.

Simplied Example:

Problem: Dangerous pregnancies leading to premature births or stillbirths

Solution From Rubi Life: Life’s fetal activity tracker uses nanotechnology attached to an elastic maternity band to passively track kick count, heartrate, and fetal position. That data is sent to the mom’s smartphone and can alert her if the baby is at risk.

Users: Pregnant mother, Fetus, Healthcare provider

User Needs:

This is obviously just a sampling of a small number of User Needs that can exist. One individual should not be the sole contributor to the list. Actual users should provide the needs based on the problem and proposed solution. At the Proof-of-Concept phase of a project, the description of the project provided to a user should not be too detailed, because as a company, the goal is to not drive the needs, but to have the users drive the requirements. The users should also come from different demographics for their subset, whether geographic, age, specialities (clinical), size and lifestyle (mothers), culture/ethnicities, etc. Obviously, a fetus will not be part of the group providing input, but the team should consider the needs of a fetus, for differences in activity level, size differences, developmental differences, etc.

As a development team, it is important not to get caught up in feature overload. Feature overload can increase the cost and the time to market. It can also create a product that becomes more complex than most users want or are able to use. The goal is to prioritize feature/requirements. The risk assessment should also be used as part of the prioritization.

There are several tools that can be used as part of risk management. During different phases of the project one tool over another may be preffered, based on the project. In the Proof-of-Concept Phase, there are two tools that i like to use. One is a process analysis in which current practice is compared to the process used by the new product with respect to risk and harm. From a design perspective, this allows the development team to understand current practices, the challenges with them/risk and give a clear understanding of the solutions the new product is offering. A key to risk management on a project is to make sure that all those responsible for the design and development participate at some level of the process and if they do not participate, they are knowledgeable of all elements of the analysis.

An example I experience as to why this is important and how it can save time and money:

A bone needle was designed for a orthopedic procedure kit. The handle was a plastic two piece part that snapped together over the metal shaft of the needle. For the project, vendors were used for different aspects of the components. When the pilot kits were delivered and ready for clinical testing, during a procedure, when the surgeon went to drive the needle in, the handle split. This left only the shaft in the bone. The surgeon had to use pliers to remove the needle.

Although the primary development team had seen several orthopedic procedures and thus understood that a mallet would be used to drive the needle into the hard bone, the design engineer that worked on the project for the molders did not know this. Therefore, the handle design was not robust enough for that step of the process.

Time: Redesign and testing

Cost: Redesign, testing, wasted parts

Mitigation: over molding of the two-piece handle

If the process risk assessment had been done early in the development, any assumptions would have been cleared up. In addition, mitigation steps would have been put in place to avoid the failure of the handle splitting.

The other risk analysis i beleieve is critical in the proof-of-concept phase is a device hazard analysis. Like the process analysis, this can avoid costly design errors or decisions early on. With each project team has an idea of what the final device should look like. Often time, that idea is not the same from team member to team member. This is actually a good thing. When doing the hazard analysis, these different assumptions are analysed for risk. In doing so, design decisions can be made based from mitigation of risk instead of the preferences of the development team members.

Both the process and device hazard analysis are team activities. They are not to be done by an individual. Although this may be time consuming, taking several hours, it takes much less time to do it as a team than the time it would take to redesign later in the development cycle.

A note: All members of a team doing risk analysis should be properly trained in the tools being used for risk analysis and have an understanding of the technology being analysed. Including an independent expert is also advised.

As a consultant, getting clients to understand the importance of these two activities, collecting user needs and risk analysis, is very difficult. Most believe they are the experts and thus know what the user needs. Needs is it a case where they understand all the users of their potential device. So many factors impact those needs. Whether it is level of expertise (once a device is approved, the expert investor has no control over the end user’s skill level). The other challenge i have is that planning is not seen as moving them closer to the product. Often first-time entrepreneurs do not have the big picture view of development. They have not worked in an environment where they unplanned product go through several iterations due to not addressing user needs, setting clear requirements based on those needs and prototype failures that could have been avoided. In addition, so many see these documents and design control, in general, as a paper exercise. As a seasoned engineer, i have learned from my experiences that design control and the planning part of development are good engineering. They save time. They save money. They deliver quality products. So, you can have all three, time, money, quality.