Systems-thinking must always be present in medical device development. Systems Engineers (SEs) live where complex development needs managing. In a very small project team people can communicate continuously and tightly enough that everybody understands where they’re headed and what’s going on.

As projects become more complex and teams become larger, the team needs someone with experience, training, and tools to understand how changes in one area will affect other areas. The team needs to leverage defined requirements, structured architecture, and reference artifacts that the SE can help facilitate, create, and manage.  

Systems engineers discuss their role in medical device product development and how systems engineering improves development outcomes.  

Stakeholder Advocacy 

Systems engineers are advocates for a program’s diverse stakeholders during the design process. They collect, consolidate, and rank stakeholders’ needs, then guide the technical team to focus on developing the right product. To do this successfully, they broker trade-offs between value and constraints. Decisions are underpinned by the patients’ best interests, which are not necessarily the best performing solution the technical team can implement within the budget and timeline. SEs are uniquely positioned to understand stakeholders’ perspectives and then align them to the end goal.  

SEs represent stakeholders by translating stakeholders’ needs into unique requirements that can be independently verified. The solution should adhere to requirements and optimize where possible. For example, if a client requests a knife, the SE figures out what properties of the knife are essential. A kitchen knife doesn’t need to be as long or as sharp as a katana when the goal is to develop a cutting tool for cooking dinner. 

Understanding the Big Picture 

Medical devices are an amalgamation of ideas and components from multiple engineering disciplines, including human factors, industrial design, electrical, mechanical, optical, and software. In the design process it is too easy to get stuck analyzing the technical details of a particular specialty and miss out on synergies or opportunities to execute in a different manner.  

SEs deal in levels of abstraction. They avoid the minutia and instead step back and look at the larger picture to understand how everything is going to come together in a single entity. They bring that vision back to the rest of the team for the different disciplines to build upon. 

Effective SEs must have strong verbal, written, and visual communication skills in order to facilitate communications inside the design team and make sure that all development efforts come together to create a cohesive product. Without SE, gaps between disciplines often get missed which can lead to an unsuccessful product.  

The quantity and complexity of medical device development regulations and standards are an extra challenge. SEs work with regulatory affairs experts to assess which standards must be met. They help free up mental space for the development team to focus on their specific deliverables. SEs are often in the background asking, ‘Have you considered this standard? Have you considered this area of risk? Have you considered the trade-offs between X and Y?’ The team isn’t constantly wondering if there are any gaps. 

Which development phase benefits most from system engineering?

Systems engineering benefits all phases of development benefit, from initial product strategy alignment and stakeholder needs definition through design, integration, verification, and validation. To a greater extent than other engineering disciplines, systems engineering is involved continuously throughout the design and development of a product. They keep the team unified in the same direction, especially when team members come onto and leave as program needs change. Keeping a cohesive direction and client goals top of mind is a key role of the SE. 

System Engineering versus Project Management  

Systems engineering and project management overlap a bit, so at times it is hard to understand the differences between these roles. Project management is responsible for the resourcing, scheduling, and budget expended during a project, while systems engineering is more focused on the technical and product side. As an example, if a client needs to reduce costs or timelines to achieve their target milestone, PMs rely on SEs to help define which features can be deferred to future product iterations without negatively impacting things like patient value, clinical safety and efficacy, and regulatory strategy. 

SEs are responsible for technical maturity of the product during design and development. The product maturity is intertwined with any programmatic risks to the project. There must be tight collaboration between systems engineering and project management to identify and reduce these risks.  

Overall, an effective SE will have experience in project management, just as an effective engineering PM will have experience in systems engineering. 

Issues Systems Engineers Typically Handle

The systems engineering role varies during the design and development life cycle. In concept development, part of an SE’s job is resolving conflicting requirements from different stakeholders. For example, one stakeholder wants a very fast processor and another wants a low power mode so the device can last ten days without recharging. Those two needs might be in conflict because the fast processor will consume a lot of power. The SE will meet with the stakeholders and negotiate the right balance. 

During development, the SE makes technical decisions on how the product will come together. For example, one team member may be developing firmware on a microcontroller while another is creating a graphical user interface. The interface between these two components and the functionality that the product provides to a user is the responsibility of the SE. Establishing the order of operations and timeliness of data exchange is another example of the kind of problem that SEs solve. 

During integration, SEs tend to be system-level problem solvers. When subsystems that are working perfectly are integrated, they won’t necessarily meet the overall product requirements. That’s when SEs help troubleshoot interactions between diverse parts of the systems.