Today's medical device and instrument engineers are facing mounting pressure to innovate faster while meeting increasingly stringent FDA regulations. Anticipating potential roadblocks early in the design process allows engineers to rapidly identify and address issues, avoid costly redesigns while reducing time to market.

While each new project has its own set of obstacles and opportunities, there are three common steps that when not properly executed bog down product development:

Define specifications

To determine the requirements for a particular device, a large number of stakeholders must be involved, including marketing, regulatory, safety, and technical personnel. Since it is impossible to satisfy everyone, it is necessary to identify where certain features and functions can be eliminated without sacrificing marketability. Each performance requirement, from throughput to operating environment, affects features and functions. In turn, these features and functions affect cost, time to market, and product size.

In a laboratory automation system, for example, the ability to conduct upfront processing of a sample may not be worth the cost to an end user. In some cases, money and time are better spent developing faster robotics and fluidics to increase downstream throughput. Fully understanding the value of certain functions to the end user is critical to designing a device or instrument that will be successful in the marketplace.

Using a template of potential features and functions for similar devices can streamline the requirements definition process. Drawing on research from past development projects, or working with a partner that has the relevant experience with a particular type of product, can speed the development process and ensure that no necessary features and functions are left out. A general feature and function template can be tailored by the design team for an instrument's specific purpose.

To ensure the most comprehensive template of features and functions, companies should conduct customer focus groups and market surveys to find out what challenges customers face and which automated processes would increase efficiency in the field. This feedback can verify that certain features should be incorporated in the device.

Once a comprehensive template has been established, the next step is to begin trading off features and functions. Through brainstorming sessions, design engineers and stakeholders should work together to eliminate features and functions that will add significant cost, time to market, or size to an instrument, carefully considering how much end users are willing to invest for certain requirements. Further, an experienced development group or external partner can leverage prior project experiences to identify which features and functions are necessary and which ones may be eliminated.

After tradeoffs are made, it is important to ensure that the product's features and functions meet each stakeholder's objectives and to verify that the engineering teams' conceptual ideas mesh. This can be achieved through a comprehensive design review involving all members of the project team. Often, the most important stakeholder objective is the cost target for the device or instrument. A thorough review of the features and functions and conceptual ideas for the design will give a better understanding of how much the final product will cost. Further, the team should review the initial design concepts for each module and ensure they are compatible with one another. That is, mechanical engineers cannot set out to build the Taj Mahal while the systems engineering team plans on using a generator to power it.

Once the initial design concepts have been developed, a thorough architecture review involving members from the mechanical, electrical, software, and systems teams as well as regulatory and safety experts needs to take place. Returning to the building analogy, there are a number of ways to construct a house, but it can look like a colonial, Victorian or contemporary model. An architecture review can ensure the right building blocks are in place to meet the product's objectives.

Finally, end users can provide valuable input on initial concepts. Following the architecture review, companies should put together a hard model or foam core markup of the concept, which will allow them to go into the field with a focus group.

We worked with an OEM on developing an automated processor for preparing bacterial samples for identification and drug testing. The OEM's systems engineer recognized that automating the inoculation of the test sample was not worth the time for development or the additional costs that it would require. Further, the company set up end-user interviews that confirmed this. Because the OEM recognized the need to trade off the inoculation process, the product was introduced into the marketplace in a timely and cost-effective manner.

Manage change

When change occurs during development, companies must understand what is driving it in order to properly manage it. The three major drivers for change during product development are market needs, technical challenges, and cost targets. Each cause requires different steps to avoid even further increasing costs and slowed development schedules.

A stage-gate process provides a roadmap for companies to take products from ideas to commercial realities with market needs being an important drive of change. The process is comprised of set tasks that must be completed before a project can move to the next stage. Each stage should require management approval. A stage-gate process for a medical device or instrument could be comprised of the following stages:1) Specification, Planning and Concept, 2) Development, 3) Verification and Production Transition,4) Production, 5) Post Production. Incorporating these checks and balances into each of these product development phases ensures that management and marketing remain involved in order to identify changes in market needs before the product moves too far along into the process.

Another common driver of change is the implementation of unfamiliar technologies. If a module needs to be included in the design of the device and the engineering team lacks the relevant experience to rapidly develop it, valuable product-development time is lost. Breadboards, prototypes, and early-stage, off-the-shelf software for manipulating the device to perform basic functions will let the engineering team achieve a greater level of familiarity with the product. Working with an external partner who has a suite of early stage tools can also give companies access to a wider range of experienced engineers, which helps mitigate the risk associated with implementing new technologies.

When cost is the driver of change, frequent design reviews centered around specific modules can help meet cost targets. Involving both design and management teams in these reviews keeps all stakeholders abreast of potential cost increases and allows the group to brainstorm areas where other features and functions can be traded off to reduce cost.

Regardless of their cause, changes during the development process must be properly managed. Program management is a key factor in properly dealing with change and ensuring time, money, and resources are not wasted. A well-documented product requirement definition can also help the program manager and teams stay focused on their roles and responsibilities when change occurs.

System Integration

A major obstacle to delivering devices and instruments to market on time and on budget is the system integration process, which compiles all of the subsystems to ensure the device or instrument works properly as a whole.

Often, complex medical systems are the result of work from many internal groups or outside partners. Initially, detailed requirements and interface documents can help keep internal and external groups on the same page leading up to integration. Groups performing different segments of product development, including mechanical, fluidics, systems and software, need detailed information about each component to ensure the system will interface well. Not anticipating that certain elements of the design may not work together until system integration commences can be extremely costly as entire subsystems may have to be re-designed.

Additionally, regular meetings with all engineering teams leading up to integration will ensure each team is aware of which subsystems will need to interface (work together), decreasing the chance of major malfunctions during integration.

Lastly, enlisting the help of an experienced partner to manage a collaborative development team can smooth the system integration phase.