[Webinar Recap] Systems Engineering MedTech Challenges

Systems Engineering

[Webinar Recap] Systems Engineering MedTech Challenges

By |
[Webinar Recap] Systems Engineering MedTech Challenges

In this blog, we recap our recent webinar, “Systems Engineering MedTech Challenges”

Systems Engineering MedTech Challenges

Implementing systems engineering (SE) practices in MedTech presents unique challenges. From aligning with regulatory standards like ISO 13485 to managing time-to-market pressures and technical complexity, MedTech professionals must navigate a highly regulated and rapidly evolving environment.

In this webinar, industry experts Mike Johnson, Trainer & Co-Founder of SE-Training GmbH and Vincent Balgos, Director of Medical Device Solutions at Jama Software share actionable strategies to overcome these obstacles and explore how MedTech can lead the way in adopting SE methodologies.

Key Takeaways:

  • Overview of Systems Engineering practices in the Medical Device industry
  • Common early-career challenges and practical tips to overcome them in MedTech
  • Aligning SE practices with regulatory standards like ISO 13485 and addressing gaps in conceptualization, system analysis, and risk management
  • Opportunities for adopting SE methodologies, including Model-based Systems Engineering (MBSE)
  • Don’t miss this opportunity to learn from industry leaders and gain strategies for addressing MedTech’s common SE challenges.

The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

Mike Johnson: Thank you very much to all the people of Jama Software for supporting this webinar this evening. The topic is Systems Engineering MedTech Challenges. I’m Mike Johnson and I’m working for a company called SE-Training GmbH. To give you a little introduction on tonight’s topics, so firstly, I have a short introduction about SE-Training, the company I co-founded. Then I want to dive into practical perspectives, aligning systems engineering, challenges, systems engineering opportunities, tips and tricks for overcoming common obstacles, and we have some time then at the end for a wrap-up summary and questions.

Short introduction about the company SE-Training. We are a group of systems engineering experts working on the development and support of technically complex systems. So, the technical complexity is the thing that unites us all and is very much what unites the systems engineering approach. The problems caused by complexity are often very multifaceted, often have a lot of non-linearities, many dependencies, et cetera, and it’s not easy to overcome them. We are an endorsed training provider by the INCOSE UK group. So INCOSE stands for the International Council on Systems Engineering. We are accredited here in Switzerland by the EduQua training accreditation and many people come to us because they would like to achieve one of the accreditations in INCOSE.

That’s the ASEP, the CSEP, or the ESEP. ASEP is the Associated Systems Engineering Professional. CSEP is the Chartered Systems Engineering Professional. ESEP is very experienced. And of course, with both the ASEP and the CSEP, you need to take an exam and it’s not an easy exam. You have to revise quite a lot for it, and so we have a dedicated training course to prepare you for it. Also, for anyone in Switzerland, which may be quite a few people in this webinar, anyone working in Switzerland, if you’re working as a temporary worker, then you can find us on tempservice.ch.

So the challenges for this webinar that we’re trying to overcome, firstly I want to talk about the practical perspectives on the context and constraints. I want to talk about aligning systems engineering implementation initiatives with the applicable standards, ongoing challenges in the MedTech industry, opportunities, and tips and tricks for overcoming the common obstacles in highly regulated industries. Short introduction about myself, I’m British, which means sometimes I make silly jokes. That is of course what the British do. And growing up I attended the University of Exeter firstly to study physics. Following my undergraduate in physics, I went to the University of St. Andrews to gain my master’s in optics and optoelectronics there. My first job was at Thales Optronics in the UK and already from a young age, I was a systems engineer. I was always a systems engineer in my early career, firstly working as an optical systems engineer, especially working with the military.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Johnson: And many of you may know the company Thales. Thales is very big on systems engineering. It’s a core competence there and there I was able to already at a young age, deliver a very big category, a project for the infantry on some very complex systems. I then moved to Switzerland and in Switzerland, I moved to a space company called RUAG Space, which is now called Thales Alenia Space, Switzerland, and there as well as leading the systems engineering group. In addition, I was also a systems engineer, and probably my best application of systems engineering at that time was on the very, very quick development of a space telescope called CaSSIS. The CaSSIS is on the ExoMars Trace Gas Orbiter. Been in orbit since 2017 and we had to do end-to-end development and verification activities, et cetera, and deliver in under two years, which really, really was challenging. I must say though that it is also a very good application of systems engineering, especially from a value-oriented perspective.

There after five years at RUAG Space, I moved to Roche Diagnostics. I moved to the MedTech industry. There, I was head of systems engineering in the molecular division, especially all the systems there using PCR or the polymerase chain reaction, I was there for seven years with a group of about 30 people, business analysts, systems engineers, requirements engineers, et cetera, really specializing on a lot of the upfront product definition activities on these, again, very complex systems. Whether they’re pre-analytics or analytics or analytics systems, both are equally very complex, with many aspects that you need to consider. You can’t just go in and start writing software or start cutting metal as such. Also introduce many organizational initiatives across the whole of Roche Diagnostics, not just in our site in Switzerland. And then for the last two years, I’ve been full-time with my company SE-Training as a consultant and trainer.

So for this webinar, first topic I want to talk about is practical perspectives. The importance here of considering firstly many aspects of MedTech context and constraints. And I say this of course based a lot on my history and my history is that I’ve come from a strong systems engineering background in aerospace, defense, and then come into MedTech. So of course my views and my reflections are based very much on my experience here may not be the same for everybody. How do I see things? Well, number one, it’s a very high compliance-driven development process, so it’s very important in MedTech that you show evidence for what you’ve done or what you said you were going to do. That’s really important in the development processes. Now of course, if I’m just making a very simple product, just a few requirements, a few verification activities, well, that’s not so difficult, is it?

But of course,e if I’m making very complex systems, I have many different subcontractors supporting them as well, many aspects possibly changing, then actually having that evidence to show compliance is really important, especially since I’ve got a high level of confidence that everything is available and is consistent. Otherwise, I’m open very much to a lot of liability. So you’re going to expect that in this industry. In particular, in MedTech, the development process is very centered around usability and safety. Now of course, safety is called product risk, but it’s a term that I must say I’m not a particular fan of. I’d rather we call things safety, but these are core to the development processes. So right from the beginning of the development you circle around usability and safety is absolutely critical. And of course, we know why or any of us working in the MedTech industry know why, because we’ve seen how both usability and safety can lead to, of course, in many cases, deaths. Unfortunately, from the misuse of medical devices or from liability issues, et cetera.

I mean, it’s medical devices you could be connected to, which if they failed you could be dead within two or three minutes or seriously injured within two or three minutes. So of course these two quality attributes or -ilities or emerging or engineering specialties or emergent properties, whatever you want to call them, these two in particular are very, very critical and of course, we know that as we go through the development processes, we need to circle around them. In both these cases, we should already be thinking we want to be supported in implementing and executing these processes. Just so that I say something that’s obvious, there’s high pressure on time to market, no one’s in denial about that.

That’s probably one of the critical constraints on any project you work on in MedTech is the pressure to get to market first is absolutely as high as you can imagine from any other industry. Often, of course, projects have dropped because they’re not achieving their timelines or simply a competitor has moved in. An unexpected competitor has got their product to market before you, really, really critical time to market. And that’s where actually from my time in the space industry, I can relate to that as well with our developing telescopes. If we were late, we simply wouldn’t get onto the rocket. We simply wouldn’t have gone to Mars.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Johnson: So actually that’s quite similar and I used to say to people actually in the MedTech industry, I used to say to my colleagues often, imagine it’s a space rocket that you’re trying to get your product onto because the space rocket doesn’t work, doesn’t wait for you. I say this as well after working across all three industries. What I saw in MedTech, is often technically the most complex systems, especially when you start analyzing the complexity of the system of systems that they’re operating within. And interestingly here, it’s not just that it’s a very high level of complexity, but also what I often saw in MedTech was that the complexity was underestimated.

People weren’t realizing just how complex these systems were, whether they were taking over jobs that people could do, so automating activities, or doing some very high-level chemistry for the samples. But whatever they were doing, often the people themselves didn’t realize just how technically complex these things were, which I would say is actually quite different to the aerospace and defense industry. Often there actually I found that you didn’t so much underestimate the complexity. You were more aware of the complexity. Often actually I think you could do overkill, you could do too much, or get to try and navigate your way around the complexity. Whereas in MedTech, I often found it was quite underestimated and yet these were really, really complex systems.

So after the contextualization and constraints, look at alignment with standards. Now of course, the one big standard we should all know is the ISO 13485. Very interesting. If you do a control F, so you look at what’s in the ISO 13485 standard. Of course, you won’t find the word systems engineering. So having failed on your first control F, you start to look for other words, don’t you? You say, well, what is that is systems engineering? What do we find in there? It’s clear they want to see a high level of traceability throughout the design and development process. Now, you think typically that products can be developed, like mid-complex products may be developed in three to five years, scales, things like this, three to five years. And well, in those three to five years what can happen? A whole load of things can change, your scope can change, your design can change, your verification can change, da, da, da. A whole load of things can change.

Project team members can change, and subcontractor suppliers can change. All these things, of course, can change. And if at the end of it you say, the regulator comes to you and says, “Well, where’s the evidence that you did what you said you were going to do five years ago?” And you look back at them with a bit of surprise and you’ve got no way of showing that evidence through the traceability of the process and of course,e you’re in trouble. Which again is often why we will have infrastructure supporting us through that process.

THIS IS A PREVIEW OF OUR WEBINAR, WATCH IT IN ITS ENTIRETY:
Systems Engineering MedTech Challenges

Vincent Balgos
Latest posts by Vincent Balgos (see all)