AdvaMed Webinar: The Unique Challenges of Complex Safety-Critical Medical Device Development - Transcript

Sunrise Labs Webinar Recording 12.7.23 Innovation and Safety The Unique Challenges of Complex Safety-Critical Medical Device
0:10
Good afternoon everyone.
0:12
My name is Monty Sylvan and I'm the membership coordinator here at Abimed.
0:18
Today we have a wonderful presentation aligned with for you today in partnership with Sunrise Labs.
0:26
Today we will be discussing the innovation and safety, the unique challenges of complex safety critical
medical device development.
0:36
We have our our presenters today, Eric Soderbergh, President and CEO of Sunrise Labs, Tracy Wilinski,
President and CEO of Culture Consulting as well as Steve Gimmel, an independent Medtech
consultant.
0:53
I will ask that you ask any questions that you may have in our Q&A section and not the chat.
1:00
And if you do place in the chat, I'll just kindly guide you to the Q&A just so we can all view this, view
the questions appropriately.
1:09
I am now going to hand this over to Eric and they will get started.
1:14
Eric, Wonderful, great.
1:17
It's wonderful to be here with you all.
1:20
This is a great topic and it's great to be here with Steve and Tracy who have both a lot of scars and
learning to to do things the right way and the wrong way.
1:32
I'm sorry, you're learning how to do things the right way by doing them the wrong way.
1:36
Even had some experience working together with with Steve on some neat, neat projects.
1:42
But that that's how we learn and we're hoping to share that learning with you today.
1:46
So anyway, I'm the, you know, CEO of Sunrise Labs.
1:50
About 15 years ago, I took control of Sunrise and focused us, you know, exclusively on medical
devices.
1:57
And so we're an engineering services firm in Bedford, NH, an hour north of Boston, where we develop
and help our clients develop medical devices.
2:11
Steve.
2:13
Yeah, hi everyone.
2:15
My name is Steve Gammel.
2:16
I have over 20 years experience in medical device product development and commercialization
including many VP and leadership roles in R&D and operations at in Select Corporation on Duo,
Citellas, Biosystems, Human Addicts and multiple startups.
2:38
I, I actually started my career as a system software engineer and have designed and launched several
innovative products in markets like diabetes technology, drug delivery and surgical.
2:55
Hi everybody.
2:56
I'm Tracy Polinski, I'm the President and CEO of Qaltra Consulting.
3:00
Qaltra is a boutique consulting firm located in the Greater Boston area and we specialize in regulatory,
quality and clinical affairs for medical devices and combination products.
3:12
So it's nice to be here with all of you, right.
3:15
So I'll, I'll jump right in it.
3:17
It's first question is you know what's special about developing a safety critical or complex medical
device.
3:26
So, so if we contrast an over the counter blood pressure cuff say to an artificial heart, OK, the over the
counter blood pressure cuff is, is you know there there, there's hundreds of models out there on on
the shelf in your drug store to go out and buy at any time that that that so.
3:44
So it's a it's a mature market.
3:46
We know what the requirements are for it.
3:49
We know what it takes to sell one and if you're going to differentiate yourself on it, it's going to be in
you know, ease of use or something.
3:56
But but the technology's well understood and and one of the one of the main differences here is that
you know if it fails and puts an X on the screen or something, you're not going to hurt anyone or it's
very unlikely you can hurt somebody.
4:10
You can argue that a bad reading would but you know it's it's it's it's failure.
4:15
You just go pick up another one and and run that.
4:20
So an artificial heart on the other side and it's probably you're doing a lot of new and novel things,
OK.
4:26
And and each one of these things sort of adds more risk to that product development process.
4:33
It's you still have all the market risk, is it going to be a success in the market that's a huge risk, right
for any device or any product at all really.
4:42
But on top of those you've you've got this you know when some when a fault happens in the system
you you got to keep operating or or you you might kill someone you know or you know in the in the
case of the artificial heart there there often there there's there's no predicate so that doesn't the way
quite the way you do it or that that means that it's a less established not just the market needs.
5:10
You know we don't know you know how how long should the battery last what does does it have to
as a driver does it have to work in the shower the the regulatory pathway you know it's it's probably
it's APMA but what claims are we gonna make and what what you know what what kind of validation
will that incur.
5:31
So, so a lot of, a lot of new questions there.
5:33
There's often a lot of subsystems involved in in a complex device.
5:37
There's, you know, the batteries that could be the motors could be you know the balancing system or
brain and you know the the, the user interface and all these things you have to make decisions on on
you know, do I use existing things that are out there that I can purchase off the shelf and put them
together or do I, where's the secret sauce that I really want to keep and and and and develop
ourselves here and and and completely home, you know and so the technology itself may be doing
things.
6:13
There may be a new some, some, some kind of material that that lasts a long time without blood
clotting onto it or something.
6:21
There may be things related to the the battery technology or to keep it small and light you may be
using a bleeding edge technology there and and so that's that's an added risk and and of course
these are very complex devices take a lot of money to develop and and and time so.
6:42
So it's a big investment.
6:44
So in summary it's sort of you know you you had a lot of risks and and and and it's a high stakes game
here because of the expense.
6:55
So when those are the conditions this is just one thing to keep in mind is is is even if those risks you
have a lot of risks and they all look small they they don't add they they they multiply and and and so
the probability of success for your project gets gets pretty small at when when when you take risks in
a lot of different areas and so so really the message here is is to you know pick your pick your battles
and and and you know don't take risks where you don't have to.
7:23
So to do that we'll talk a lot more about the foundation it's it's the got to figure out what it what it is
you you really want to build what are the constraints and and minimum buyable product what what
are the things it has to do.
7:39
And so if it's the first of its kind on the market, you know maybe you don't need all the web
connectivity maybe there's there's some things you can you you you where you can you know get rid
of some project risk by by just you know not doing that in the first first generation.
7:55
And and you really need to be careful about watching those risks and and and tracking them as you
go through the project and and retiring the risk as soon as possible.
8:04
You know build prototypes, test them, attention to detail are absolutely you got to do it right.
8:11
Taking shortcuts for a complex device and and and especially especially safety critical one will will
almost certainly take longer.
8:21
The shortcuts may look short but and and there's there, you know there's often a lot of pressure here.
8:28
So it starts with with figuring out, you know the real base level here.
8:36
What are those market needs?
8:37
What are The Who are the stakeholders?
8:40
Who who's the what's the target patient population What's the price point you need to get to to to be
viable in that market regulatory what are the claims you're going to make huge huge question to
weigh out you know versus the the validation required for them the five 10K or PMA what are the
consensus standards that that that will be required to be met to to get through the regulatory bodies
the FDA clearance or approval technologies.
9:12
You know you're probably pushing a technology in one area but there may be other places where you
where you don't have to push the state-of-the-art.
9:21
So so is this is is the stuff that you're working with here something out of a research laboratory that
hasn't been proven yet or is it is it mature.
9:29
And those we we use a technology readiness level scale a numerical scale that based on sort of what
NASA's done to determine sort of you know what what level of risk is there to the project by going
with with certain technology choices user centered design.
9:49
What are the use cases that they're that are most experienced excuse me that are most pertinent to to
this and and and you know the user experience what what are what are you going after how how are
you you know do you want to be the easiest thing to use the thing that does the most things the what
do you want to be and and all those things the decisions and trade-offs made among these first four
pillars sort of feed into the defining that minimum viable product which I spoke to a second ago.
10:16
It's so important to you know choose your risks carefully.
10:21
So this this is a foundation but it has to start fluid.
10:25
You know example the first medical device I worked on was 25 years ago class 3 medical device was
the I bot.
10:32
We we didn't call it wheelchair but mobility system that would take a person with disabilities and put
them up at eye level by balancing them on two wheels.
10:40
OK and it did climb stairs and and did some other things too But you know marketing would come in
and say hey it's got a hold of £350 payload and you know on a on a battery charge it has to last for a
week and and the product has to lay weigh less than 125 lbs and cost less than $250.
10:57
And you know it's like OK and engineering says well you know with the technology available today we
we we can you know we we we we can hit $2500 and and you know maybe a a £300 machine to do
this what if we we we back it down to a £250 payload and and and one day of of of battery life and
and back and forth it goes user centered design says hey you know what this this has to work in the
shower it's crazy for not to how else are the people gonna get in and out of the shower you know so
so it's this cross functional the negotiation that you want to to do right up front to figure out what
what is real important to get into that minimum bile product another recent examples implanted
monitor that that that wants to monitor a a certain body function continu ously and and in order you
know to but but but for the use case continuously means yeah if I got it a couple times a day it would
be enough but while our predicate you know this is where the regulatory piece comes up better the
predicate does it like every 10 seconds so we we have to be at least as good as the predicate or or five
10K is going to fall far so there there's a lot of back and forth that that happens.
12:14
Among all all all four of these.
12:16
And it's a great time to do it as early and then before you before your detailed design starts and you
you start investing a lot of money in a in a path that that that may be changing so that that's that's
that's that's the main message we want to send today is just this it it it sometimes there's a lot of
pressures coming you know from above or wherever to to to move quickly but this is how you move
quickly by doing this up front and and and you know you know avoid you know features that that
sound good.
12:56
You know they'd be really cool but they're not core to what you're really trying to do that that that's
the foundation we're talking about.
13:06
Then we get into actually implementing the design.
13:12
There's just a plethora of a trade-offs and the the the architecture is the first thing.
13:17
This is the floor built on top of the foundation.
13:20
OK and and this is where you're really you know Steve's going to talk more about system architecture
but I'll just talk to just this just this you know just just if you just look at the safety sort of element of
the system architecture.
13:38
I just want to give you a feeling for for how complex this you get how you you really want to be
working with experts that have done this before and and and they're also familiar with with the
present state-of-the-art and what you can what what technologies you can apply that there are off the
shelf that that that will work.
13:56
For you but you know just the safety part of this requires A semester course to introduce it it's it's a
you know what what what parts of the system immediately fail safe what parts can be fault operative
what parts just have to be robust.
14:12
You know there's fault tree analysis things you get into look at probabilities of this happens then this
happens and and that results in harm.
14:20
There's FM EAS Aerospace really invented much of the science behind this safety of that stuff but it it
it is a science and it's important to engage people who are familiar with the science here for for the
safety piece so so so that that's you know again Steve will talk more to the the system architecture.
14:41
I just wanted to get a little bit on on on on how how important that piece is and and complex that
part is yeah prototype let me just and he'll Steve will also talk about hazard analysis prototyping is is is
a real interesting as you're planning a project and I talked about retiring risks this is this is one way to
retire risks is to build a little prototype that says well you know what it is is is this this battery hasn't
been tested at this temperature with this kind of load profile.
15:14
Well go take a battery and put it in the refrigerator whatever it is and and and and and test it without
low profile and see what happens.
15:23
You can do one offs so so each prototype you build should have you know a why behind why why are
you doing that and and then you should stick to that plan 'cause you know we we've had examples
where we're building a prototype to test to make sure all the system components of a optical device
that looks in your eye let's see if that is is is that system's all gonna play together with this
microprocessor and and you know if we get everything done we think we can with this technology
and and and then it's like well why don't you just package it into a a handheld because it's kind of
small anyway and why don't you make it look pretty.
16:03
So I can you know show that to the board of directors and they can see hey look look at this.
16:07
I got a working device here and then ends up taking an extra two months and cost things wise as
much and kind of like what happened and it happens.
16:18
It happens often stick by stick thing becomes a big big pile of of of things.
16:25
Everything's interrelated at a complex system.
16:28
So when you change something one place it affects things and three other places.
16:31
That's just something to keep in mind is is I have a plan stick with it.
16:36
It's not waterfall versus agile when you get to the process side it's it's a combination If you've got you
know obvious one is a a graphical user interface that's agile you you want to put it in front of people
and iterate on it OK and but building a foundation is kind of war abolished by by definition.
16:56
So keeping that cross that cross functional team that that that helps you decide what what you know
among the pillars what what was most important there's going to be surprises that come up as you go
and and and execute this product development is is about learning it's it's never been done before
you're doing it for the first time you need that cross functional team engaged to keep you to keep you
agile and moving forward and making decisions quickly.
17:22
So with that I'll hand it to Steve.
17:29
OK thanks Eric great stuff.
17:33
So what's next?
17:34
I'll start with just pointing out pretty standard the diagram or product development steps and how
they stem from a good understanding of requirements through different design stages and how they
relate to verification and validation.
17:49
But you know, the emphasis here is on the product requirements and they come from many sources
and not all of them are obvious, right.
17:57
You know, first I want to highlight the idea of user studies, and this is beyond marketing survey
information.
18:04
For a product that is solving a complex problem, especially solving it in a new way or introducing A
paradigm shift, you need to make sure you understand how your users will respond to the product
and to the change in workflow that you're introducing.
18:21
And I I think back to early days of insulin when we were just conceiving of the first disposable insulin
pump, the patch pump that became Omni pod.
18:32
Yeah, we had a remote controlled user interface that would not always be with the user while the
pump is pumping and it was a big leap from the current use model for insulin pumps.
18:42
And so we ended up executing an extensive user study with people with with type one diabetes built
and verified a fully functional version of it And we learned a ton.
18:52
We learned about the features of the product, the use cases, what people liked and did not and it was
really the best thing we could have done before we committed to a much larger scale development
product.
19:05
Another area that is often not well defined relates to a clear definition of product reliability and
performance expectations, things like the useful life of the product.
19:16
And this is really fundamental to the whole value proposition in the market strategy.
19:21
What are we doing differently than what's in the market?
19:25
You know, so you think about what is the true expected life of the device You have to work out, is it 2
years, is it four years, six months?
19:32
How many uses per day, per week?
19:35
They're not easy answers to come up with, but the answer should not be, well, let's wait, you know,
let's conduct reliability testing at the end of the project, Let's see how it turns out and come up with
our warranty cost and service strategy.
19:50
That's not what you want it to be.
19:53
You've got to make a priority to find this and relate it to all of your target markets and your cost
structure.
20:01
And So what, you know, just that element of of the, the project is a tall order, right.
20:07
I mean, you've got to.
20:10
There's always going to be resource constraints on what your team is able to execute.
20:15
So you've got to be realistic, not overly optimistic.
20:19
And so with that, I, I, you know, say reach out to experts.
20:23
You know if there's areas of your design where you're pushing the envelope in, in electronics or
software or cybersecurity.
20:30
If you don't in your company, have expertise in biocompatibility, design for manufacturability, UX,
whatever it is for a complex product that is safety critical and undoubtedly is crucial to your
company's success, which really isn't the time for you to DIY and start trying, trying things where the
stakes are so high.
20:54
Next slide.
20:58
So for any medical device products and project, everything we do of course has to be centered in the
safety of the patient and the operator of the device.
21:10
And so clearly you need to make sure that your team has the expertise and risk management, hazard
analysis and it really, really must inform your architecture design at a fundamental level.
21:24
More on that later, we're we're probably all used to the typical tools in risk management.
21:31
Eric mentioned a couple like like a suite of FMEAS, you know like a design FMEA process FMEA use
FMEA or URRA as Tracy I know we'll discuss a bit later.
21:44
You know just to touch on this a little bit.
21:47
You know, best practice we probably all know focuses on ensuring that you're looking at design
mitigations that will address or eliminate key failures and failure modes rather than passing along the
burden of mitigation to manufacturers, to to your manufacturing group or to your suppliers or worse
yet to your users.
22:09
You know via labeling and and warning screens, you've really got to have a cross functional team
working on these.
22:17
But I wanted also highlight kind of beyond the safety risk part of this, right.
22:24
If you look at FM EAS there they tend to highlight you know and prioritize areas to focus on, right?
22:30
I mean really it's a project management tool of sorts that's focused on safety.
22:34
But what what I've seen is it often this process misses an opportunity to simultaneously highlight and
evaluate business risks associated with failure modes.
22:47
You know, for example, like in your system, if an alarm is properly generated and prevents A
hazardous situation, that's a good thing, right?
22:55
That's what you're going for.
22:56
That line and your FMEA is going to be in the green and typically the team moves on.
23:02
But if you think about the flip side of that, if the process of recovering from that alarm, you know, like
a reboot, changing out, a disposable calling, customer service, whatever it is, if that if that is onerous,
the procedure could be delayed resulting maybe in a rescheduled appointment, unhappy customers,
you know, there's a lot of downside, you know it's not just victory because you've detected an error.
23:29
So how do we programmatically address these as well?
23:34
My recommendation is actually to amend the process like an FMEA process a bit to actually consider
non safety issues associated with these same failure modes.
23:44
And you can actually have an additional ranking and RPN values for these items.
23:49
And you know after you've done through the the safety items, you can review that same list in the
RPNS of the business risk items through a different lens with a with a perhaps even a different group
but really looking at the business risk side of it and that can be applied to reliability issues.
24:07
It can be applied to supply chain or other items that that might you know affect the business.
24:15
And then the other area I just want to highlight that's that's critical to, you know, the early stages of
the product, product development in the area of risk is cybersecurity, the cybersecurity risk
management which is even now more highly scrutinized by FDA, right.
24:33
I think we all know cybersecurity weaknesses in a products can introduce both patient safety risks and
business risks.
24:41
And you really got to get that work started early and make sure your team has deep cybersecurity
expertise on board and if if necessary you know utilize consultants and I think Tracy will tell you also
aren't going to get cleared through the FDA without it.
25:00
So some other items I'd like to highlight with respect to complex devices are in the category of of
project management oversight and Eric touched upon some of this.
25:09
You know a a project to develop safety critical safety critical product often you know has feasibility
activities and something that teams really, really need to do.
25:21
And you know I'm I'm talking to my fellow engineers out there is resisting the temptation of going too
far in feasibility and cranking into the design without really solidifying like all of the pillars.
25:33
You know that that you know Eric mentioned you know and the feasibility side, you got to understand
specifically what are we trying to do risk, what is this feasibility we're doing?
25:44
What are we, what question are we trying to answer?
25:46
Is it related to power, to speed noise and algorithm whatever it is got to answer that question, get
back to the team on that because the more complex the system is, the more likely you are to have a
larger team which then makes communication more difficult.
26:05
So you know, one way to address this is to ensure that you're creating documentation for the product
prospectively in real time, right?
26:18
I think we've all been part of the projects where the documentation catches up at the end, but you've
got to in a safety critical device document that overall system architecture, the software architecture,
theory of operations, calculations between critical electronic circuits, tolerance analysis, that's got to
be documented early so you can double check your architecture.
26:40
And what I'm always on the lookout for is design trade-offs that are being made within a discipline
without really involving the cross functional team.
26:51
And I highlight that is because the reality of designing any complex product is that time is always the
enemy.
27:00
And when people start falling behind, they start looking for ways to simplify.
27:03
And you know, hey, do we really need that sensor to monitor the pressure or the flow or noise or
whatever, you know, isn't that redundant?
27:11
Couldn't we save time and money with a software algorithm or, you know, we've got a working
prototype.
27:17
Can't we just move ahead with these electronics?
27:20
Watch out for those moments in the project.
27:23
They're coming and decisions that are made.
27:26
Trade-offs that are made in the dark without the full team are typically revisited later in V&V and
production via delays or in the field.
27:37
You know which is even worse.
27:41
One way to align on on the the architecture risks and project risks in these systems is through critical
integration points, right these these should really be as early as possible, to the point that that often
they become painful.
27:56
It should really challenge the team and you know, sometimes you get, well, wait a minute, aren't we
just redesigning the whole system faster?
28:03
Isn't that what you're asking?
28:04
Like no, really, it's not a full working system.
28:08
That's the goal of some of these integration points.
28:10
It's a demonstration of some of the key use cases that touch multiple subsystems from end to end.
28:18
That's really the goal.
28:19
And then the final item in this area that I'd like to highlight is related to pilot manufacturing, because
the more complex or innovative that something is, the more likely you're breaking new ground.
28:31
And this might rely not just on design, it could be related to innovating manufacturing processes
either in house or at a vendor.
28:38
You're pushing a vendor to do something that stretches the limit of manufacturability.
28:43
So I would just say ensure you have manufacturing engineers on the project early on and create you
know for most products, create an in house pilot line as as soon as possible because you're going to
learn every time that you build next.
29:04
So which which brings me on to VNV which is a real complex, you know of a complex system.
29:11
It's a massive undertaking and it typically represents a huge risk to project execution.
29:19
And so to that, you know, I would say really you have to begin planning for VNV at the beginning of
the project and it starts with strong requirements.
29:30
I would say invest in a requirements management tool.
29:33
There are many out there.
29:34
Invest in a tool and focus on writing testable requirements.
29:41
And it also emphasizes a strong architecture that can leverage some subsystem testing.
29:48
If you're thinking about subsisting testing early on, it's going to dramatically help you in many areas.
29:54
I mean #1, it helps you decouple dependencies in your schedule, right you if one sub assembly is
ready to test, you can get going on that independently testing that kind of ahead of rather than serial
doing doing everything.
30:07
But I think even more importantly it aids in regression testing if you because if you have a sub
assembly you need to make a change to a component or an algorithm and it's late in the game and
you will right you always there will be something that comes up.
30:22
If you have strong traceability and sub assembly level testing you can have confidence in the impact
of your change and make a very strong case for a focused regression test.
30:38
And then the other area I'd say about V&V is that your results should not come as a surprise.
30:45
And what I what I mean by that is do dry runs early, especially if you need to go out of house for
compliance testing to standards like electrical compliance and immunity drop testing, ship testing,
human all those things you want to know as soon as possible if your product gets put in a strange
state when subjected to electrical interference or vibration or extreme temperatures, you want to
know that, understand those States and you also want to understand the point of failure of your
design.
31:16
You know for example if when doing electrical compliance testing there's different thresholds say for
ESD, static discharge, exposure and if you pass that's great.
31:28
But I'd say don't stop there.
31:30
I would say keep going beyond the spec and find the weaknesses in your design and find the breaking
point.
31:36
Because I remember many years ago doing work on a wearable medical device that met all the
immunity standards for ESD.
31:44
Yet we still had field failures that we related, traced it back to ESD and we soon realized that some of
the electrostatic discharge events that, you know, you would see in the dead of winter, cold dry air for
people wearing wireless medical devices, wearables underneath the fleece or something like this.
32:07
Or you know, better yet, one of the most fascinating ones with a child wearing a, a, a, a wearable
medical device and going down a plastic slide on a playground generate massive ESD events that are
way beyond the standards.
32:23
So tests beyond the standards really understand your environment.
32:30
And then the last item I would say related to the V&V is that one of the great pains is finding ways to
subject your device to all of the exception cases and how you capture data demonstrating proper
performance.
32:45
And so I would really focus on building a system and tools that support data extraction, support
automated testing, support scripting, especially something ultimately that can be used by a technician
and not a senior engineer only.
33:00
These will help for informal debugging and development, but also informal VNV and possibly even in
production.
33:08
You just have to be prepared to, to validate the subset of those tools that you're using Next, please.
33:17
And so you know, finally we get to maintaining complex systems, right?
33:22
You finish VNV, you've got regular regulatory clearance to launch.
33:26
You've built commercial products.
33:29
So now be prepared to change it because change is going to happen.
33:34
No.
33:34
You know whether you want to or not.
33:36
You know why?
33:38
All it takes is a single supplier of a single component to not be able to keep up with production
volumes or tolerances or timelines and boom, you've you're now evaluating spec adjustments,
alternative materials, qualifying new suppliers.
33:57
Change will come from that and also from the field.
33:59
You inevitably get feedback from the field, which may or may not be accurate, reporting issues,
suggesting changes.
34:06
So how do you manage all that?
34:09
What I would say first don't underestimate the amount of time and effort and expertise it'll take to
maintain your design, support production, support suppliers, debug, field issues.
34:22
You need a cross functional team, you need quality, you need regulatory, clinical, manufacturing,
supply chain, sustaining, engineering.
34:30
It's got to be collaborative.
34:32
You know what level of V&V do we need to repeat, Do we need new 510 Ki mean fundamentally you
need a strong sustaining engineering process.
34:40
You know, SOP, strong change control process are critical, but you also need a way to filter through
the information that you're you're getting to understand, OK, we heard this report, but how is the
product really performing?
35:01
You need a way to collect the data and hopefully you know given the complexity of the product and
the safety critical nature of the product that you've designed, you've anticipated this.
35:11
You know you've implemented critical data logs within the devices in the field that are captured
automatically.
35:17
You have a way of automatically transmitting the data.
35:20
You have a way to parse and analyze and present the data in a dashboard so that people, people
besides a single engineer can can look at that data and this all gets back to the initial requirements.
35:33
Build this functionality into your requirements at the beginning.
35:37
Make sure you have a strategy for how you will deal with the product changes that are being made.
35:43
If we need over the year software updates or special service mode, service tools, service depot, all of
that, that strategy goes back to phase one plan for it so that you're not scrambling to invent new
processes and tools when that first complaint comes in, you know, so I'll end it just saying you know
the systems engineer, the systems lead, project lead has to be exploring the needs of the entire
product life cycle at the start of the project, not just the the functional specs.
36:18
Great point, Steve.
36:18
Thank you, Gracie.
36:21
Hi everybody.
36:23
So, so building off of Eric and Steve's comments on regarding the strong foundations, I want to just
spend a little bit of time and talk about regulatory strategy.
36:33
So there are several pieces that contribute to a strong strategy.
36:37
We're going to talk about each of those and this should really serve as your your playbook through
the development process and the real cornerstone of all of this is communication and collaboration.
36:49
And so both internally and externally you want to make sure as Steve has said that you're talking cross
functionally with throughout your design team.
36:59
So that's that's really important.
37:03
Next slide, that's OK.
37:07
So the first piece is really defining your regulatory pathway.
37:11
So for those of you that are in the regulatory field, you know that the first piece that you really want to
understand is your device classification and the regulations that your safety critical device might
comply with.
37:26
And so I think Eric said maybe it was Steve, you know, what claims are you looking for and what does
your company really want to come away with claims for this device.
37:38
And so that's, you know, just another piece of your regulatory strategy.
37:42
But one of the things you need to consider is, is your device a novel device And there are some really
great programs for novel devices.
37:52
And so if you should consider whether or not you can use the breakthrough designation request
program and for those of you that are not familiar with that, there's a great guidance document that
walks you through what the criteria are and it's really great for kind of expediting the process for
breakthrough technologies.
38:14
If your device isn't doesn't qualify for the breakthrough designation, maybe it qualifies for the SAFER
technology program or the STEP program.
38:25
And so again there are there are guidance documents that can can walk you through that.
38:31
The STEP program is really used for improvements of safety and currently available treatments,
whereas the breakthrough designation is for something really brand new and novel.
38:42
Another piece that you need to consider is, are there any special controls for the type of device that
you are developing?
38:50
And so examples of that might be special labeling or safety assurance cases or are there additional
performance tests that need to be done.
38:59
And so that all needs to go into your, into your regulatory strategy.
39:08
So during the development of safety critical devices, it's really important to understand how the user
is going to interact with this device and the environment in which the device is going to be used.
39:20
So I really can't, I I can't stress that enough.
39:24
I think Steve's already talked about it because use related errors have led to hundreds of thousands of
death since 2000.
39:34
And so if you think about that, that's really incredible.
39:38
The FDA has published a list of safety critical devices, so ventilators, infusion pumps, insulin delivery
systems, defibrillators, those kind of devices that require human factors testing as part of the
submission.
39:54
So the FDA has recognized that these safety critical devices are are important because they have clear
potential for serious harm from use error.
40:05
So manufacturers have been encouraged to engage with the Office of Device Evaluation to obtain
feedback on their human factors testing and their protocols to ensure that there's adequate attention.
40:19
Given to the usability of the device in its use environment by the actual users, so you know human
factors is just so critical when you're talking about safety critical devices.
40:34
So with devices becoming more interconnected, they're also more vulnerable for safety breaches.
40:40
So Steve kind of touched on this as well.
40:44
So how will this affect your device and patient's safety?
40:48
So you need to really work with your internal teams and your external experts to fully understand the
potential for these breaches you may have.
40:57
You may have heard about the cyber security hacking of insulin pumps and pacemakers in the mid
2000s and the FDA, because of that FDA and the safety critical device manufacturers were really called
on the carpet to ensure that their devices remain safe during use.
41:17
So out of that came a lot of new guidance documents that would help strengthen the testing
requirements of software and and Bluetooth enabled devices.
41:27
So when you're developing your regulatory strategy, you want to make sure that you have a full
understanding of what your device is going to be doing and what guidance documents, consensus
standards are out there to help you get through those those pieces.
41:48
So with safety critical devices, especially novel devices, a manufacturer should engage with the agency
as early as possible in the development process.
41:59
So even if it's just presenting your device in an informational meeting, you want to make sure that
you're aligning on the submission type, that you understand the clinical evaluation and the evidence
that you're going to need to present in the submission.
42:14
And all of those interactions are going to reduce your frustration, They're going to reduce cost and
ultimately they're going to expedite your timelines.
42:27
So I just wanted to talk a little bit about infusion pumps kind of a then and now Sue, as as Steve had
had mentioned, Steve and I actually worked at insulin together.
42:38
So we have our insulin delivery experience and insulin delivery devices are actually infusion pumps.
42:44
So between the early 2005 and 2009, the FDA received over 5500 or 55,000, excuse me, adverse event
reports.
42:58
And during that same.
42:59
They had almost 90 recalls in infusion pumps across the industry, which is really incredible if you think
about it in four years.
43:08
So most of those issues were related to software defects, usability issues and then mechanical and
electrical failures.
43:20
So out of that FDA initiated what they call the infusion pump improvement initiative and that was in
2010.
43:29
And so they really the idea was to establish you know additional requirements so that the infusion
pump manufacturers understood what the agency was expecting.
43:40
They called on manufacturers to facilitate device improvements, so to be proactive in addressing
concerns and they wanted to increase you know general user awareness.
43:52
So there became there's a lot of information on the FD as website about infusion pumps because
there were so many recalls.
44:03
And so Speaking of recalls you may have just heard last week BD had a recall of their Alaris pump in it
was it's being recalled because of compatibility issues with the Monojet syringes.
44:17
So it's not the same system errors or software issues or use related errors that caused the Alaris recall
in 2020, but it still brings home the point that communication and collaboration with your external
suppliers and your external sources is really important when you're talking about managing the entire
total product life cycle.
44:41
So you want to make sure that you are you know reaching out to your suppliers, understanding if
they've made some changes which generally they're supposed to tell you if they do, but so that you
can incorporate that is and and bring that back into your design team so you can evaluate what those
changes mean.
45:02
So I talked just a little bit about you know the total product life cycle and I just want to kind of just
bring that all in, especially when it when we're talking about infusion pumps or insulin delivery
devices.
45:16
And so the total product life cycle is an excellent tool to help the development team and the
regulatory team ensure that all the bases are covered.
45:26
It's also a great tool if you're not using infusion pumps or insulin delivery devices because the
strategies that are in the product total or the total product life cycle are actually can be used in other
safety critical devices.
45:43
So the central tenet of this is really surrounding risk mitigation.
45:48
So safety assurance, cases, user related risk analysis, hazard analysis, all of those things start to to
contribute to the risk planning of your TPLC.
46:05
And so from a regulatory perspective, I talked a little bit about communication and collaboration with
the design and development team and it's again I can't stress this enough, how important it is to
reach your goals as a company for safe and effective commercial product.
46:22
So working together with those teams, you're going to address issues and challenges upfront as they
arise and that's really going to be important as you're commercializing this product and once it's on
the market so that you can constantly be updating it.
46:41
And so lastly, I just want to you know, touch on the point that you're not generally in full production
when you need to start any of these performance tests.
46:52
Your regulatory strategy should really discuss the stages of development that you're going to begin
testing and the acceptance of controlled bills for testing purposes.
47:02
So as an example, you know a manufacturer of an insulin pump might start stability testing because
they, I'm sorry, they might start sterilization testing on their fluid path prototype to allow the insulin
stability testing to start.
47:23
So that you have you, you know whether the, the, the drug properties of the insulin are being affected
by your sterilization either the length or the type of sterilization that you're doing.
47:36
So you know you want to make sure your regulatory strategy brings in all of the total life cycle plan
and all of the performance testing that you're going to be doing to make sure that you've covered
everything that you're going to need going into the future.
47:54
So from that that's I wrapped mine up fairly quickly, but I just wanted to summarize all of the, all of
the presentations and really into a few bullet points.
48:08
So it's critical that you have a comprehensive foundation for your design and development program.
48:15
You want to understand the trade-offs and the non negotiables as Eric mentioned because it's
paramount to your successful project.
48:23
Steve talked about having strong system leads and want to make sure that you have a strong system
lead to drive that project commercialization.
48:32
And then lastly, I hope you understood for me for safety critical devices, you know communication
and that collaboration internally and externally is really going to help you mitigate your risks and it's
going to drive your project and the timeline to completion.
48:52
And so with that I just thank you all for participating and I think we can open it up for some questions.
49:00
Great, thank you, fantastic, great presentations so far everyone.
49:07
I have a few questions that I am prepared to ask on behalf of the audience.
49:14
If you're ready, I can begin.
49:17
First question we have is how do you know when and where you need to add redundant system
components to keep a system safe?
49:26
Oh, that's an excellent question.
49:30
I'll jump in and if if Steve or Tracy want to add to it, But it really does start with your hazard analysis
defining what what you you sort of define what what is safe enough and safe enough.
49:43
I'll back up a little is is it depends upon the device right.
49:46
If if you were let's say take a Nova cure device company on the seacoast New Hampshire here that
makes a device that radiates your brain with with RF energy to kill cancer cells.
50:01
If the person doesn't get that therapy they're very likely going to die and so you can take more risks
the the the the safety you know so so one of the one of the risk factors would be sort of OK yeah turn
the volume up too high radiate too much and and somehow damage some other brain cells not just
the cancerous ones.
50:24
I think that would be your your sort of level of of of that happening is weighed against sort of well
what's the there's a risk return there versus if you're sort of the I bot case where you're you know OK
you're you're giving somebody some mobility but you know they they don't want to die over trying to
get from point A to point B.
50:43
There were safer ways to do that.
50:45
The the threshold's a little lower so the the the probability you know so the likelihood of them falling
over is is it and they're getting hurt that that's that's not a reasonable risk to take and so now you
have to say OK so so so how do you limit the probability of that to be very small And and and when
you have to do that you often have to go into you know doing things that are, you know they start to
get fancy.
51:14
Every motor is really two motors there's an A side and AB side and that feeds up a change to chain to
an A battery and AB battery.
51:22
So if one battery fails, or anything in that whole drive chain you know fails, then there's still another
one there to keep them upright.
51:33
So you know.
51:34
The answer of course is it all depends but it depends on both your sort of risk reward equation for the
device and on you you know what what what the implications are of of a failure.
51:50
So so often what you do is you look at you know making it a system but like the IBO you you make it
immune to single point failures and you say that across the board that's that's my that that's what I
need to do if if if if one battery cell or one transistor or one anything fails you can't hurt somebody
and and then you walk through the system and say what's that mean and in some cases it's it's it's
fault operative some cases it's fail safe like the user control has two sensors on on each axis so t hat
you know if it's bad or not and if it's being held forward because it's really been commanded or not.
52:29
And if you got a disagreement, you say, oh I got a disagreement.
52:32
Yes.
52:32
Stop that that that's OK to stop.
52:34
You can stop that and still not you know have somebody fall.
52:39
But it the so there's there there's different parts through our system and then and then there's you
know there's there's some pieces like a wheel falls off whether I can balance most and you know two
wheels, one of the wheels falls off they're gonna fall over.
52:50
Right.
52:51
So well I can't have two wheels on every, you know shaft or something.
52:56
So.
52:56
So I I just need to design that with enough safety margin.
52:58
So it's very unlikely that a wheel will fall off or break.
53:03
So absolutely thank you for that response.
53:07
Our next question we have is when you need to bring it, excuse me, when you need to bring in
outside groups or consultants to work on a project or do compliance testing, How do you manage
integrating their work into your own DHF at that, I mean I I think it it all depends on how your quality
system is, is arranged and how structured it is.
53:35
But what I what I've often seen is that especially when it comes to compliance testing, you might write
your own, you'll ask the vendor to create a report, a protocol, excuse me, a protocol based upon the
specific specifics of your product and you might need to supply some of the background material.
53:55
But they'll typically use their own processes for that and generate A protocol, generate a report, and
when that's delivered to you, you then have to make sure that you integrate that into your your own
system by following your own procedures.
54:10
Write your own protocol, it's kind of a wrapper, and use theirs as attachments within the document,
and something similar can be done.
54:17
If they're writing requirements documents or something for you, you've got to you have to make sure
you're following your own process and your own design development plan which which might call
that out at the beginning.
54:32
So there's lots of ways to do great, great.
54:38
Following question is relating to integrating reliability or other factors into the risk management
process.
54:45
Are you suggesting creating a new type of FEMA, FM, EA and new SOP or how do you do that?
54:53
That's Tuesday.
54:57
I guess you don't necessarily need a new SOP for that.
55:04
It depends what your SOP says and how you want to do it.
55:07
But what I've seen that does not add overhead to your process is literally taking your standard FMEA
template in, adding extra columns that after you figured out the failure modes and the effect and so
forth and the severity.
55:25
You can have extra columns for the the severity of that problem to the business or reliability and and
do your own calculation of another RPM within the same document.
55:39
And it doesn't necessarily need to be a whole new SOP or anything like that.
55:44
I would just make sure that ahead of time if you're doing this, make sure you align all of your FMA as
your process, your use, your design.
55:53
You might have one specific for software and hardware as well.
55:57
Align those templates ahead of time so they all look alike and so that you're not left with something
at the end where they're all different.
56:06
So alright, the next question we have is when is the best time to begin human factors testing?
56:18
I can probably take that one sooner rather than later.
56:23
So you really wanna do it when you're beginning your development because you're gonna be doing
formative human factors testing all the way through to learn what is and isn't working from a user
perspective.
56:36
And so I think Steve would agree that the more information that you have, and I believe Steve actually
even spoke to this, the more information that you have during that development is going to allow you
to mitigate some of the risks associated with the product.
56:53
And right, if you're looking at usability, you just really want to make sure that you're you're you have
all of your use user groups, use groups identified and the environments in which they're going to be
using that product.
57:06
And so from that perspective, I just say early and often you know you just want to keep doing it until
you're sure that you're ready for your summative testing which is the next thing after your formative.
57:20
And you're also going to want the FDA to weigh in on those protocols, make sure that they are
aligned with the FD as expectations.
57:28
Anything you want to add, Steve?
57:31
No, that sounds, that sounds great and very familiar, which is just what I added.
57:37
Sometimes, you know you you might want to wait till you have a certain product type stage.
57:40
Sometimes that might be the reason you are making a certain kind of prototype is to test it with the
user.
57:45
So.
57:46
So it should be sick.
57:46
You know, there's often coordination there.
57:49
Yeah, absolutely awesome.
57:52
And we have time for a couple more questions.
57:55
This is another one from the audience.
57:56
We have the inclusion or the state's statement and question.
58:01
The inclusion of business risk evaluation in a FM EA exercise is intriguing.
58:08
My question is how would you establish a clear demarcation between product compliance slash safety
aspects from the business risks, from the business risks, especially during an audit?
58:22
Yeah, I think what what I would suggest is that you can, you can call out you know in your either in
your product development plan you'd say or in your SOP for your risk analysis that you're doing this.
58:35
At the same time make it clear that you know typically the the safety, the safety risks and what you're
auditing to and what you're reporting on and doing the benefit risk analysis and the residual, all of
that.
58:51
You've just got to be clear what you're looking at.
58:53
And so I would envision you know the whole section, the first column so to speak of all the RPN,
These are the ones you would highlight in your procedures and in your project plan.
59:04
This is what you know relates to the safety and that the other areas related to business, business risk
and have a simple way of separating it from the compliance perspective 'cause this is in addition to
the compliance, it is somewhat separate, yeah.
59:23
So it's typical to have a hazard analysis you have certain risk there and the way you mitigate it is with
with a some feature of of the design that that that that becomes a requirement and and it's good to
have those tagged to those safety related requirements tagged for a number of reasons you know but
one of them is is sort of before you go into a clinical study you don't have to necessarily validate all
your requirements but you know to to get through an IDE to improve a study.
59:54
But you may a subset of your requirements make sense to to say OK we've we've done all the same
we we've validated that all the excuse verified I should say that all the safety issues are are handled
and and and and so we we can tell you that we think this is safe enough to use with people now going
to you know going to a clinical study you know before you.
1:00:15
Do all the stuff that maybe isn't as important.
1:00:19
OK, great, great.
1:00:21
And our last question for this session will be, excuse me, breakthrough designation is only for a
therapy that didn't previously exist before or a state-of-the-art method for a therapy that already
exists.
1:00:37
But the state-of-the-art method would be a great improvement on the therapies available.
1:00:45
So I'm not sure I understand actually the question right breakthrough designation is it for sure you
can have it.
1:00:55
It's for devices that previously didn't exist.
1:01:00
But there are exceptions for devices that you're making a a big improvement, a novel improvement on
a device that did exist and it's it's something new in the most recent guidance document adding the
benefit for the patient.
1:01:18
And so there is, if I understand maybe the question correctly, state-of-the-art is a from ACE
perspective, a international perspective is a great way to to to show that improvement.
1:01:37
And you are expected if your product is is regulated around the world, you're expected to have all of
that state-of-the-art information to support your tech file.
1:01:51
So you could I I guess you you should most people, most companies don't have two different
processes.
1:01:59
So if you're using all of that state-of-the-art methodology internally to support your international
submissions, you would be doing that in for your domestic submissions as well.
1:02:11
So I'm not 100% sure I understand what the question actually is.
1:02:16
We do have a contact information here.
1:02:18
Yeah.
1:02:19
So the person that asked it if they want to direct you know message me that would be great and I can
we can talk a little bit more about it.
1:02:29
Awesome.
1:02:29
They just thank you for your response and I they also followed up saying that they will reach out.
1:02:37
So on that note, I do want to thank everyone for this wonderful presentation, Steve, Tracy, Eric, I also
want to thank Sunrise Labs and Quality Consulting for collabing collaborating with Avamed on this
webinar, if you all have any closing words with nothing times, Oh, thank you.
1:03:03
It's been fun.
1:03:04
Please reach out if if you have further questions.
1:03:07
Absolutely.
1:03:07
Thanks for having us.
1:03:10
Also, the presentation will be available shortly after to be sent out.
1:03:16
I do encourage reaching out to our presenters today for any further questions to be answered.
1:03:24
They would be the best resource for that.
1:03:26
But outside of that, I hope everyone continues to have a wonderful rest of their evening and until next
time, thank you.
1:03:35
Bye.
1:03:35
Thank you.