Systems Engineering

[Webinar Recap] Application of Systems Engineering in Healthcare

By |
Application of Systems Engineering in Healthcare

In this blog, we recap our webinar, “Application of Systems Engineering in Healthcare”. Click HERE to watch the entire webinar.

When it comes to healthcare, the first to market usually gains 80% of the market share, making development speed one of the most crucial aspects of success – or failure. That’s why many organizations are looking at systems engineering as a way of connecting needs to solutions.

In this webinar, Chris Unger of PracticalSE LLC and Vincent Balgos Director, Medical Device Solutions at Jama Software® have partnered up for an engaging webinar on the application of systems engineering in healthcare.

We invite you to join in as we delve into transformative role systems engineering is playing in the healthcare industry.

What to Expect:

1. The Power of Simplicity:

Discover how focusing on the basics, while maintaining world-class performance levels, can yield astonishing returns. We’ll show you how simplicity can be a game-changer in the complex world of healthcare systems engineering.

2. Market-Driven vs. Contract-Driven:

Intrigued by the difference between market-driven and contract-driven industries? We’ll explore how systems engineering varies in these two landscapes. Learn why “Market Driven” industries emphasize competitive value creation and use cases more than traditional requirements, and how this shift can redefine your approach in healthcare.

3. Striking the Perfect Balance:

Explore the ideal state of systems engineering in healthcare, often a harmonious blend of Agile, Lean Startup, and more traditional systems approaches. Uncover strategies to adapt, innovate, and succeed in this dynamic field.

Don’t miss this opportunity to gain a comprehensive understanding of how systems engineering can revolutionize healthcare. Whether you’re a seasoned professional or just beginning your journey in healthcare systems, this webinar promises valuable takeaways for all.

Below is an abbreviated transcript of our webinar.

Application of Systems Engineering in Healthcare

Chris Unger: We’re going to talk today about systems engineering in the medical industry, particularly medical device development. So the medical device industry faces several challenges. There’s clearly constant time pressure in developing and launching safe and effective products. We’ve got to be faster than the competition with better products. And as you can see from the statistics, this is a challenge. Part of the challenges in delivering things on time is the shifting regulatory landscape. I’m sure everyone’s aware of MDR. There’s software for medical devices. The FDA is going to think about redoing design controls next year. When we were at GE Healthcare, there were like 8,000 regulations we had to monitor. So it’s a very challenging and shifting regulatory landscape. Not only do you have to be compliant with regulations, but you have to ensure your device is safe. And so quality issues, safety and just keeping performance are key elements of delivering on time and that’s getting more and more expensive as you can see here, billions of dollars of financial risk of getting this wrong.

So to make all that harder, there’s a constant increase in complexity. When I first started, there were typical software development teams were 20 to 40 people. It’s now hundreds of people and lots of interactions. So additional things like AI, machine learning, or new technologies, really have to manage a lot of complexity inside of your devices. The organizational structure is getting more and more complex. There’s a heavy focus on acquisition, so you’re integrating new teams, new cultures, and geographically distributed development teams. So that makes it all challenging. So we’re going to talk about how systems engineering can help address some of these particular challenges.

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

Unger: As I mentioned, a key differentiator is getting to market faster. So the success of a program in a market-driven environment is basically profits. The first mover tends to collect the lion’s share of the profits. We typically have many customers. You don’t have a single customer marketing and product management tells you roughly what they think the competition will be and what differentiates versus in a contract-driven environment, success is satisfying the contract. So within GE Healthcare, the avionics and oil and gas businesses typically had a single customer. We would produce a floating city block to British Petroleum or Shell, go to the North Sea or the Caribbean and you had a contract and you delivered to that contract versus an engine, an aircraft engine, or a medical device, we deliver to the marketplace. We decide the timing, we decide the features.

So the stakeholders and market-driven are internal to the business and you can negotiate budget and time. If you get a really, really cool feature, you can take an extra month or quarter to develop it, versus in a contract-driven, it’s really fixed. So the challenges of market-driven and contract-driven are different. Contract-driven requirements are a key commitment. You’ve got to negotiate a formal design control versus within a market-driven environment they’re critical. You have to deliver validated requirements, but they’re definitely an internal business tool that helps communication across all the business functions.

So what’s the value of systems engineering in a market-driven industry? We basically turn the ambiguous needs that we get from product marketing or product management and turn them into clear and feasible solutions to be implemented by the hardware and software teams. The key value we produce is that those implementations seamlessly integrate into the customer’s workflow and work systems. So they work really well from day one, they reliably meet their needs. They work really well after five years and not just meet their needs, they delight the customer. We really want to deliver something that the customer enjoys using. So we have to make it work day one, we need to make it work day 50. We need to make it work for every single customer. So you have to deal with all the known variability of hardware and process. Every installation and every service event has to produce a uniform, high-quality, high-performing product.

So with those constraints, we want to optimize the business value. So when we have multiple options, marketing will tell us the customer value of these options. The implementation teams will tell us the delivery and product cost of those functions. The role of systems engineering is to make trade-offs between those and really optimize the business impact based on the cost of implementation. So we want to make sure the work done by those implementation teams is tied to the maximum market impact. And associated with that is managing technical risks. If you go down a path and it turns out to be infeasible, while it might’ve been nice if it worked, you just wasted a lot of that work. So that cost has to be scaled by risk.

In doing all those first four bullets, our key value is making sure design decisions are identified and closed predictably, and that the team acts with one voice. So decisions are framed, the options are agreed to, the decision criteria are agreed to and the final decision is closed and stays closed as stakeholders change. So once you have a frozen design, do you want to make sure that actually integrates easily and when you have integration or quality problems, they’re found early and resolved early. When you have time to react, it’s a lot easier to adjust your design in the first half of your program. It’s really hard when you find severe quality issues with a month left before shipping.

RELATED: Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)

Unger: And so really winning products happen when systems thinkers are effective. So clearly there’s going to be a need for some systems engineering process thinkers, but they’re system thinkers across the entire program. And so we want to make sure that everybody’s involved in systems and that the creativity of the entire program is maximized. So getting specific to GE Healthcare, what is systems engineering at GE Healthcare? Well, we have the essential customer-perceived performance. So a lot of our programs are imaging, so we have the image quality. Still, we also have things like maternal-infant care where we deliver the right humidity and temperature around the neonate. In delivering that essential performance, you’ve got to make sure it’s safe and you’ve got to make sure you have regulatory compliance. And I mentioned we really want products that are easy to use and delight the customer. So usability is a critical part of systems engineering. In doing that, we make sure we define the right implementation requirements and the right reliability strategy, and that it can be installed and serviced properly.

So with that being the overall goal, how do we organize? Well, there are a lot of things that are common across all of our product teams. We do have common program milestones. We do have a common systems’ lifecycle. It’s basically the V-cycle with iteration and agile built in. What differs is that different product teams at GE Healthcare have different levels of safety hazards, so FDA risk. We go from anesthesia where you can easily kill somebody down to ultrasound, where it’s non-ionizing equipment, that’s the light handheld probes. You can’t pinch or crush anybody to even service software that has zero patient impact. There are also almost no risks for anybody and we respond to that by adjusting the process rigor so that the higher-risk safety risk modalities have higher process rigor.

Additionally, things vary across the world or we have different locations with different cultures and different sizes of organizations. We have many systems engineers across the company, but the SE team sizes vary from less than 10. In fact, we had some sites with maybe 10 engineers and the systems engineer was half a person to teams that had over a hundred systems engineers. The scale of the programs we work on is less than 10 engineers and months-long programs to many hundred as engineers applied to a program that might last three years and were based on technology developed over the prior decade. And you want some systems engineering thinking even during that basic research decade.

RELATED: Understanding Integrated Risk Management for Medical Devices

Unger: The organization goes from product centralized, it’s like the SE GM for that hundred engineering group where they all reported to a dotted or solid line, to decentralized in where that team of 10 with one or half a systems engineer, there the manager was a general engineering manager and did not have a lot of systems engineering experience. So I joke that if there is a way of organizing systems engineering, we have one of those within our group somewhere.

But how did we think about tailoring? And so this is a page I put together that was generalized that you might be able to use. Obviously, as I mentioned, higher technical risks including safety risks. One way of measuring that is how many risks there are in your hazard analysis. For things that are a higher risk we looked for a higher level of functional excellence, more process documentation, more process compliance, and higher rigor of the technical design reviews, and maybe more independent reviewers. Team experience. This is subjective to measure, but Joel Goldstein did a very nice study, from Carnegie Mellon, that the value of systems engineering increases with program complexity, but it decreases with a more experienced team if you have a small team that is experiencing the technology and the application, they can get by with less process rigor and while systems engineering excellence delivers some value, it delivers less value.

To watch the entire webinar, visit:
Application of Systems Engineering in Healthcare


Chris Unger
Latest posts by Chris Unger (see all)