Systems Engineering in Healthcare Q&A

Pioneering Excellence in Healthcare: Q&A with Systems Engineering in Healthcare

On December 5th, 2023, Jama Software^® hosted an exclusive one-day thought leadership event, featuring industry experts Chris Unger – Retired GE Healthcare Chief Systems Engineering Officer – PracticalSE LLC, Bijan Elahi – Founder of MedTech Safety, and Vincent Balgos – Director of Medical Device Solutions at Jama Software. Attendees of this event were invited to deep dive into best practices in Systems Engineering and Risk Management, crucial pillars of successful medical device development.

The following is the transcript of a Q&A session from this event. Please note that the answers were given verbally and may not be exactly as recorded. Some changes have been made for clarity.

“What are some insights for product development teams to consider when keeping up with the speed of innovation?”

Chris Unger: Separate out research (from development), and spend certain time on long lead items. Typically, our programs are 6 to 18 months. And so, if there is basic research that takes more time, make sure you have a certain amount of your budget – 5, 10% – with risk retiring the initial basic piece of the work, and the handoff between research and [development] programs in where we think we can retire the remaining risks in the 12 months. And then the rest of it has to really focus on what is really core. Eating the elephant one bite at a time. Focus on what’s really innovative. But one of my general managers said, ‘You want your product development to be a wall. Big, small, small, big, small.’ Product development should be a phased approach where you work on various scoped tasks. Focus on the high-risk and most innovative stuff. Low-hanging fruit can wait. Spend the time really on the breakthrough, and then maybe every six months for the next year just do small iterations, maybe some covers, maybe some better user interface and workflow, while you’re buying time for the next major innovation to come through. So, portfolio management.

Bijan Elahi: With respect to risk management, innovation in new technologies is useful for reducing risk to medical devices. You may have seen the definition of “state of the art” in the latest edition of ISO 14971 Standard, which says that the manufacturers are required to consider the consolidated findings of technology research practice to incorporate into the medical devices to reduce risks as much as possible. However, it also says that the latest technology state of the art is not necessarily the latest technology [from all industries]. And medical devices, we are a little slower than other industries like semiconductors. So, for us, state of the art must be generally considered good practice, and then innovations that are proven and accessible to be used to reduce risk.

Chris Unger: The other comment I might make is one of the reasons you slow down is scope creep. For every function, every person is like, “I just need my one. It’s just small.” It’s the straw that breaks the camel’s back. And one of our most successful businesses, the ultrasound team, said that time to market and this time blocks delivery was a team effort. Instead of having one person beating away, that all the functions sort of gang up on each other. It’s like, “Well, I didn’t put my extra in.” We’re all committed to delivering this every year, something important every year. And so rather than having the program manager fighting for scope, it’s the team that says, “Look, I’m willing to commit to this limited scope to get something this year, you help me out.” So, make sure it’s the team’s focus on speed to market.

Vincent Balgos: In this post-pandemic event, collaboration can pose a challenge in working remote, hybrid, onsite, especially for systems engineering and risk management where we need to work across the aisle amongst different types of groups.

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

Vincent Balgos: “So my question to maybe Bijan first, is what are some lessons learned that you’d offer to maintain efficiency and progress, that works better than others? And we are a bunch of engineers here, definitely want to talk about technical, but are there any key soft skills that we may also want to consider as well?”

Bijan Elahi: In one of my classes, I teach that you need to cultivate humility and curiosity. So, what do I mean by that? As I said, risk management is a team sport, and humility does not mean self-deprecation, it means to recognize that the answer is not all within you, it’s within your team. And the curiosity part is that some people are just shy about sharing their thoughts. So, curiosity is to seek it. It doesn’t always just come to you. So, this is a soft skill that I can offer you, to cultivate humility and curiosity.

Chris Unger: This is a good advertisement for the February webinar I am hosting with Jama Software. I was going to plan something on requirements writing techniques, which will probably be later in the year. I’d say a couple of things, make sure that you focus on communication. So, in a crisis, a lot of people just focus on getting their work done. And the first thing that you should maintain, a lesson straight off, is making sure you talk to the team, that you get consistency and use simple forms, and keep publicizing. Example like “What are my decisions? What are the important ones?” Just keep over-communicating, it’s something simple in the survival handbook, “Guys, here’s my list of decisions, here’s my list of risks.” Keep it simple, keep it single reference.

And the other thing I do is, don’t use that to communicate, use that to archive your decisions. I get really annoyed when my team says, “I wrote defects in the tool. Of course, they’re going to respond.” Talk to people, call them up, ask them questions. Do they understand? Do they understand why it’s important to do this? Do they accept that it’s their defect? I had one, my first program at my previous employer, we got to each milestone, we had like a hundred open defects. And people came to me complaining, “Well, I got rid of my defects. I fixed 50 of them and I transitioned 50 to every other defect. But it’s not fair Chris, because everybody else transitioned their defects to me last night. How am I supposed to…” But we’re a team. Don’t reassign the defect in the tool and assume they’ll accept it. Talk to them. Say, “I’m going to reassign these five defects to you. Do you agree that they’re yours?” Talk more than use the tool to communicate. I love Jama Connect. I love the risk management aspect, all the risk files. But if you are going to assign a risk mitigation to somebody, talk to them before you assign them.

Vincent Balgos: “What are some market and technology trends you see coming to the industry in 2024?”

Bijan Elahi: The big ones are Artificial Intelligence (AI) and Machine Learning (ML). A lot of medical devices are now deploying technologies that are based on AI and ML. And this has really created the challenge for risk management. In fact, we don’t know how to really completely answer this yet. This is an unanswered question. And the regulatory agencies, ISO experts, they’re all working on this. So, answering this question of how do we manage the risks of a medical device that is constantly changing? With current medical devices, if you want us to make a change to it, you’re supposed to submit something to the FDA. What about a medical device that is changing by the hour? It’s not really possible to keep making submissions. So, this is one of the challenges that’s happening in 2024.

Chris Unger: Yeah, that’s the obvious thing. I was a skeptic. People a long time ago said, “Are you doing AI machine learning?” And I kept responding with “No, it’s not ready. It’s not ready.” It’s ready. It’s coming. It’s now. It’s 2024. I wouldn’t say it’s a 2024 trend, it’s ongoing and continuing in cybersecurity. I mean, all these things are connected. That we want to network. Radiologists want to work remotely. It was a long time ago that somebody talked to us and said, “Look, this is great. I’m the head of a radiology network in northern Jersey. We’ve got five radiologists. And when people come to my clinic, I’ll do a quick read of every scan in my area, but I’m the liver guy. So, all the liver scans get sent to me. And somebody else is the head guy.

But that means a network, which means you’ve got huge network security. So, cybersecurity is just always going to get more and more critical. And we’ve never been liable. We’ve had hospitals come to us saying, somebody’s stuck a USB stick into your system and you let that virus go and it infected their network, but it went through your product. Why didn’t you protect it? And that was a huge malware. Whatever ransomware hospital costs more money than effective fiber is going to be way more effective.

RELATED: 2024 Predictions for Medical Device & Life Sciences Product, Systems, and Software Development

Audience Question: “I was curious, looking at your workflows with the dotted lines, I recently debated whether usability engineering should be its own pillar containing risk, containing system requirements or embedded within the existing infrastructure for those. Do you have any pros or cons or suggestions on whether you should look at usability engineering independently as a whole? Or as part of the risk plan system requirements plan?”

Bijan Elahi: Usability engineering is very well integrated into risk management. It is its own discipline, and it has its own standard IEC 62366:2015. But a lot of its work products are very similar to an actual integration with an ISO 14971 workflow. So, I can’t say that it should be independent, but I say integrated with risk management.

Chris Unger: Yeah, I think it’s both and, not either or. As Bijan said, there’s a use analysis report that is mandated. So, it’s its own discipline and it’s part of everything. It’s part of workflow. Remember I said, “Gee, we want, custom things that are easy to use. No training needed, just use it.” And that’s a customer value. It’s part of marketing. Think about reliability. So, if I take this and I drop it… what are the stresses? How do I test this stuff? It’s part of uses. When we did things, it was probably two-thirds of our reliability issues were unexpected use cases. So, we had this baby warmer, and it was in Philadelphia, so they had cobblestone streets, and they were just transporting it from one wing of the hospital to the other, no baby in it. And there was an infrared warmer, it went over it and the interim warmer fell over to where the baby would be. Because it was doing a shake test going over the cobblestone. And we didn’t think about that.

Another case we had a mobile X-Ray. Takes an X-ray system, moves it into the surgery, into the ICU, the recovery room. And it’s a battery… It was probably 600, 700 pounds. Great when you have this big hulking tester and they move it over this expected ramp, something like this was easy to move it over. You get 110-pound nurse in a hospital with a two-centimeter step going into the elevator and guess what? The only way they could get over the ramp was to take a running start and use the momentum. We had wheels falling off. What was that? So, we went to the hospital and watched them. Oh! We expected like 5 Gs and the upper limit (UL) is like 50 Gs or 10 x factor plus 200 Gs. Once we designed for 200 Gs, wheels stopped falling off. So, usability is part of reliability engineering. So, it’s part of everything and it’s used in analysis report.

Audience Question: This is a more general question, but for companies that have two or more variants of a product, what are your recommendations? And this is to both of you about managing both product development and product assets. So, let’s say 90% of the assets are common across three variants and how to handle risk management when the clinical usage of those three variants could be different?

Bijan Elahi: With respect to risk management. EU MDR allows you to do risk management for a family of projects. So, if this is a family that are very similar, you can do a common risk management and then do differential risk management for the differences between them to submit.

Vincent Balgos: I’ll also add that varying management configuration is a hot topic within the medical, especially as you build family of products and then you build your… Let’s say child products off that. How do you reuse and share some of that information for efficient product development? So, this is where Jama Software is really a great, unique opportunity where we’ve actually learned from other industries, particularly in automotive and in terms of how they deal with those different types of variants. So, we’re incorporating some good practices off the bat and again, happy to talk with each of you, especially if there’s specific questions on how to solve some problems.

Audience Question: My question is about integration. I mean we see more and more devices now have the ability to work together with solutions from other vendors. How can we can be prepared for that? I mean sometimes if your product is on the market, and somebody wants to use it and integrate it with a different solution. How can we be prepared for that from both a system engineer design perspective and for risk management?

Chris Unger: System engineering is kind of simple. Keep a configuration compatibility matrix to ensure that this version of your product is compatible with what version. And then really think through the use cases. The rainy day and sunny day. We had cases where our monitoring central station… So, we built some temperature monitors, fetal monitors, cardiac monitors, but we also then built a central station that have to work with our sensors but anybody’s sensors in the world. And we did pretty good with that.

We had a recall where somebody would plug in a… I forget what it was… temperature monitor? But it was a safety-critical device in the intensive care unit, and we didn’t have a fast enough response that it was plugging in. Usability. So, the nurse pulled it out, put it in again, pulled it out, and put it in again. And finally, the system had a race condition. It said you pulled it out, and when they put it in it tried to reset. So, the nurse had thought that it was plugged in it, and it wasn’t. And so, the nurse was assuming that the patient’s heart rate was monitored when it wasn’t, we had to recall the entire product. So have a standard interface. Have a compatibility matrix and test the unusual customer uses.

Bijan Elahi: With respect to risk management, if you’re making a medical device that is supposed to work with other medical devices together, then the together becomes a system. The patient is experiencing the risks that could come from the integration of all the devices that connect with your device. To manage the risk of that, what you need to know is which devices are going to plug into your device and then you test them to make sure that they’re safe together. And then you make a list of approved compatible devices that could be used with your device and your manufacturer makes another device that wants to be used with yours and you must check that too. Just keep expanding your list of approved devices.

Author
Recent Posts

Jama Software

Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.