10 Questions To Answer Before Starting a Medical Device Engineering Project

Getting ready to add medical device engineering muscle to your development process? It’s going to require the teamwork and symphony of a chorus working in harmony.

If they’re any good, they’ll ask you these (or similar) questions before accepting your assignment.

Because it’s easy to take your money.

It’s harder to deliver what you want, on budget, and with minimal headache and rework along the way.

Ten Questions They Should Ask You
Before They Accept Your Project

  1. What documentation is available for your product or device?
    (i.e. specifications, CAD files, Flow Charts, Concepts, working models?)

  2. What will the device be able to do?

  3. How many systems need to be produced?

    1. Feasibility Prototypes

    2. Prototypes

    3. First year production units

    4. After first year

  4. What are your time frame expectations?

    1. When would you like to start project?

    2. Concept Phase complete?

    3. Design Phase complete?

    4. Prototype assembled and functional?

    5. Any show or special meeting for prototypes?

    6. Design revised and completed for manufacturing?

    7. Test Plan developed?

    8. System assembled and ready for test with documentation?

    9. Test stage?

    10. Full scale production run?

  5. Are there others in the development process with whom we would interface? If so, who are they? What will they provide?
    (e.g. electronics, software control, technology, commercially available component etc.)
    • Will we be asked to work with existing team members?

  6. Will FDA approvals or clearances be required?

  7. Do you presently have a quality system in place?

  8. What parts or modules will require invention or research? Are there subsystems to be validated?

  9. Is there an unproven that needs validation before moving to the design stage?

  10. In your opinion, what are the key engineering risks?

Why time and materials contracts are better for medical product development

Traditionally, all business relationships begin with lower levels of trust between the parties. We have had our past experiences to be wary of open ended and ambiguous contracts when working with service providers. For many things this is appropriate. However, for complex systems development, fixed cost has two major shortfalls. It will take more time and it will cost more money.

We all know that the longer things take the more money they will cost, so insisting on a fixed price does nothing to save you money. You might have someone to blame for the schedule delay, but is that really the most important thing? When trying to launch a product the one thing you don’t have the luxury of, is time.

We have been successful employing time and materials contracts for development for years. We believe that it does several things that benefit the project, the customer, and ourselves.

Product Benefits

  • Reduced tracking overhead. We proceed through the project as quickly as possible without delays caused by scope and cost discussions.
  • Right resources at right time. Prototyping is a prime example.
  • Creativity. We are free to be creative and explore improvements at any time.

Customer Benefits

  • Closer working relationships. Everyone involved is free to incorporate new ideas.
  • Reduced overhead tracking. We update you weekly. This is also important to develop the relationship and trust .
  • Speed. This is the fastest way to get to product completion because no development goes entirely as planned.

Ultimately we can all agree that the process of developing a new product is difficult and fraught with change. Why then would we want to have a contractual relationship that does not allow for this? It just does not make sense.

Therefore, time and materials is appropriate for creative work like medical product development. This is not to say that we should not have budgets and schedules.

On the contrary, these are necessary for all projects. However, if you decide that a change in direction is warranted, we must be able to pivot quickly without spending days, weeks or months renegotiating contracts, and losing momentum.

Use of Arduino or Raspberry Pi in Medical Devices

TechFlex has increasingly seen customers trying to incorporate these popular Single Board Computers (SBCs) into their devices. While these devices definitely serve a purpose in prototyping and hobbies, we recommend against using them in production designs for a number of reasons.

  • Given the nature of medical devices, the build quality and more importantly the consistency of these products may not be sufficient for medical device production.
  • Using these devices may pose regulatory issues or increase the regulatory burden in terms of risk management, and source control.
  • While these SBC’s are low cost, you are incorporating a lot of functionality that you may not require in the device that you might have to disable etc. This may actually add to your Cost of Goods as opposed to designing only the features you need using a custom design.
  • These components are difficult to control from a supply chain perspective, most medical devices require components to be available for up to 10 years. The supply of these SBC’s are not reliable and any changes to the product could trigger the need for recertification. The open source nature of the systems is both a positive and a negative.

In summary, we prefer to use standard available microprocessors to control most medical devices. Having done this hundreds of times, the cost in development time is negligible while the control and production cost benefits are numerous.

How past experiences might sabotage relationships with your new developer

It is obvious that the more investment that anyone has in gaining something the higher the value they place on it. This investment can take many forms, money is the obvious one, but hard work, pain, discomfort, shame are all “investments” that automatically increase our perception of value of that knowledge or item.

In product development outsourcing, this phenomenon can hinder the development of trust, set unrealistic expectations, and in general, make outsourced projects more difficult.

Example

Acme Widget Company decided to develop a new product internally. The product required (as all new products do) some new processes that have not been combined before. Acme spent considerable time testing to find the optimal combination. They launched the product and had some failures in the field that cost considerable money, time, and reputation to mediate.(i.e. the investment) Now the company is planning to develop the next generation product using an outside resource.

Questions You Should Ask

  • Given Acme’s history, how trusting do you think they will be of the external resource?
  • What will Acme’s perceptions of the difficulty of the project be compared to others who have not made the same “investment”? or perhaps to a company that has done similar developments many times before?
  • What is the value of the information now that it is known? is it equal to, less than, or more than the “investment?”
  • How skeptical would Acme be of an outside entity after making such an “investment?”
  • Would they fear that the same mistakes would be repeated?