November 14, 2023 • 49 mins
Milton Yarberry is Director of Project Management at Integrated Computer Solutions. Milton has developed or managed software development for Motorola, Lucent, Cognex, Inktomi, and FEI, before moving into the medical software sector in 2006 with Foliage, Ivenix and now ICS. In this episode he shares about the Protecting and Transforming Cyber Health Care, or Patch Act, which FDA implemented in October 2023, including what software is impacted, the key take-aways from this regulation, if this effects legacy devices, and how medical device companies will be impacted.
Links from this episode:
- Milton Yarberry LinkedIn https://www.linkedin.com/in/milton-yarberry-06a2311/
- Integrated Computer Solutions https://www.ics.com
Connect with Mastering Medical Device:
- Website: https://www.masteringmedicaldevice.com
- LinkedIn: https://www.linkedin.com/company/mastering-medical-device
- Patrick Kothe LinkedIn: https://www.linkedin.com/in/patrick-kothe
- Patrick Kothe Twitter: https://twitter.com/patrickkothe
Support the show for as little as $3/month: https://www.buzzsprout.com/1286645/support
Thanks for listening!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Pat Kothe (00:31):
Welcome! Software has been and will continue to be
important to delivering qualityand efficient medical care.
With our life saving andsustaining medical devices,
safety has always been at thetop of our list.
But the software world is alittle different.
And the pace is typically muchfaster than a typical hardware
(00:55):
product.
Regulatory bodies haverecognized the issues with
software in and as a medicaldevice and are attempting to
provide guidance andrequirements that assure our
software products meet the samesafety standards as the hardware
ones do.
Today we're going to discuss oneof those pieces of regulation.
(01:16):
Our guest is Milton Yarberry,Director of Project Management
at Integrated ComputerSolutions.
Milton has developed or managedsoftware development for
Motorola, Lucent, Cognex,Inktomi, and FEI before moving
into the medical software sectorin 2006 with Foliage, IVENIX,
(01:40):
and now ICS.
In our conversation we discussthe Protecting and Transforming
Cyber Health Care or PATCH Actwhich FDA implemented in October
2023, including what software isimpacted, the key takeaways from
(02:01):
this regulation, if this affectslegacy devices as well as new
devices, and how medical devicecompanies will be impacted.
Here's our conversation.
Milton, you've, uh, had a quitea career in software development
and you've worked not only inmedical device but also other
(02:22):
industries.
Many times we like to think inin medical device we like to
think that we're unique andsometimes we are but how are we
unique when it comes to softwaredevelopment?
Milton Yarberry (02:35):
Yeah, I feel like there are so many, ways in
which that is true, and yet, um,one thing I can say, I, I, I
think there are a few areas thatit's notoriously different in
terms of the paperwork, definingrequirements, traceability, the
sheer amount of sort of homeworkyou have to do in addition to
the software component.
But, I think what's interesting,what I find interesting, so I
(02:55):
find complexity and challengingproblems interesting and like to
tease them apart and find apractical solution.
And then in this regard, I thinkthat commercial software, if you
follow the process that makessense, it's very close to what
the FDA wants you to do, i.
e.
should you decide what you'regoing to develop before you
develop it?
(03:16):
And that's like the underlyingpremise maybe of like design
controls.
Should you test it, make sure,make sure it works before it
goes to the field?
Not crazy stuff.
Although commercial and medicaldevices, they feel absolutely
different in a variety ofdimensions, they really should
be more similar if you weredoing rational commercial
development.
Not everything is heavy and notwith part 11 compliance on
(03:38):
signatures and that sort ofthing.
But in terms of the generalprocess of define it, build it,
test it, and frequently thatdoesn't happen in commercial
software that way.
Pat Kothe (03:48):
And within software, you know, we, we hear so often,
get an MVP out there, build itfast, break it, come back and
iterate and just keep moving it.
Don't put a perfect product outthere.
Put one that's good enough andthen iterate off of it.
Not quite what we want to do inmedical device.
Milton Yarberry (04:05):
And the key piece is just the safety, right?
Is that if there is a problem inthe field, for most commercial
products, there's no staggeringconsequence, nobody gets hurt
per se.
And of course, the FDA'scharter, safe Safety and
Efficacy, that's what thatprocess addresses.
Pat Kothe (04:22):
Software is, you know a big term and within medical
device we've got software as amedical device and software in a
medical device.
Can you explain a little bitabout what the differences are?
Milton Yarberry (04:34):
Conceptually it's pretty simple.
The software as a medical deviceis basically software that runs
on, not customized or generichardware, so laptops, tablets,
phones.
Where software in a medicaldevice is something that is
using some piece of customizedhardware.
And the reason that matters isbecause the performance of the
(04:55):
hardware matters as you couldsay as much in terms of getting
the process right as thesoftware interpreting what's
coming off of the hardware.
It's a, hardware plus softwareversus just software domain.
Pat Kothe (05:08):
So the regulatory bodies have been iterating on
their guidances for softwareover the past 5 10 years, but
they just recently came out withsomething in 2023, the Patch
Act, Protecting and TransformingCyber Healthcare Act.
(05:29):
Can you lead us through how theregulatory bodies have addressed
software and what thisparticular act is all about?
Milton Yarberry (05:40):
Really this act is, the FDA's request to be able
to regulate cybersecurity andmedical devices.
the Patch Act, which passed aspart of an omnibus spending
bill, I believe, earlier thisyear.
what's interesting about it, ormaybe the high points are, is
that, so this is the FDA saying,you have to have cybersecurity,
and this applies to all medicaldevices with software.
Pat Kothe (06:02):
Whether it's software in a medical device or software
as a medical device.
Milton Yarberry (06:06):
Yeah.
and if you take a look at saythe patch act language versus
the refuse to accept from theFDA, the language is a little
bit different.
The refuse to accept as littlenarrow patch act is a little
broader.
There's two conditions that arethe patch act that has software,
or if it can be connected to theinternet, that's an or
condition.
So what that means is that a lotof companies were using sort of,
uh, the, an air gap solution.
(06:29):
Meaning, okay, our device isn'tgoing to talk to the internet.
We're just going to wrap it upin the box.
And we're going to say, we don'thave to comply with any of that
cybersecurity guidance and thatthat won't fly anymore.
So now merely having software,even if you have no ports going
in.
You still qualify and have tocreate these plans and
Pat Kothe (06:47):
What, why is that?
Why would, why that change?
Milton Yarberry (06:51):
I can see a number of reasons.
Basically maybe the largest isjust in the things that they
want you to have, that arerequirements.
The S bomb, they want you tohave a software bill of
materials.
The vulnerability plan, theywant you to have a response in
case somehow your device doesget hacked.
So envision, even if your thinghas no ports in it.
Somebody cracks it open,reprograms it, now what do you
(07:13):
do?
And if you have no plan, thenyou, as a company, you're, at
that point, you're at thebeginning of the scrambling
stage.
Pat Kothe (07:20):
What other things are, are in this, this act?
I mean, what, what are theyasking companies to do?
Milton Yarberry (07:28):
It's really quite extensive because, if you
go through the guidance refersto other standards.
So when you're trying to figureout what to do at the end of the
day, there isn't a definitiverecipe, here's everything,
there's no checklist.
And there really can't be achecklist because you're looking
at so many different, technicalreports, standards, and, the
(07:48):
FDA's guidance.
And these things somewhatoverlap and they use somewhat
different terms.
So there's no one definitive wayto say this is all you need.
And on top of that, FDA is, saidto kick in the refuse to accept
criteria.
And what that means is that ifyou have a submission and you
don't cover certain basicpoints, like a vulnerability
plan, like an S bomb, then yoursubmission won't even be
(08:12):
considered.
Pat Kothe (08:13):
So let's talk about cybersecurity for a second.
What does cybersecurity mean?
And from a medical devicestandpoint, what are the stakes?
Milton Yarberry (08:21):
It's obvious, it's don't let your device get
hacked, but you know, there's,there's sort of categories of
solution that they expect tohave in place, uh,
authentication, authentication,uh, uh, encryption, um, they
expect you to have a softwareupdate, they expect you to do
the analysis upfront, in athreat model of your entire
system, they expect you tofollow certain practices to
(08:43):
figure out where you'revulnerable, and that's maybe the
newest stuff It'll take quite abit of adapting to, because a
lot of people haven't usedthreat modeling tools.
You're not familiar with theconcepts, figuring out where the
boundaries are and what thevulnerabilities are across those
boundaries.
all I can say is, reach out andgrab one of the tools like,
Microsoft Threat Modeling Tool.
It has a medical device templatethat you can use and it's a
(09:06):
click and drag interface thatallows you to say, here's my
system.
And then the heavy liftingstarts when each thing that you
click and drag has a list ofvulnerabilities.
And you need to basically go inand justify why this doesn't
apply, or here's what we do tomitigate that.
Pat Kothe (09:23):
Hard question, but I'll ask it anyways.
I'm sure everyone is different.
But when you're, the old way ofdeveloping software without this
extensive cybersecurity,emphasis on here.
Is this...
Doubling the work, is this, asmall amount of work?
How substantial is thiscybersecurity, guidance?
Milton Yarberry (09:46):
So that is a great question because, um, In
the actual guidance itself, Ibelieve it's, appendix B or
Appendix two B.
B um, uh, there is a step buriedto the very end of the document
that says uh, any relationshipbetween any two assets, even if
it's through other assets inyour system.
(10:09):
And an asset could be somethinglike a server, an asset could be
like a key, an asset could be apassword.
And so you can envision thatlike in your normal system, you
might have dozens of assets.
they're saying that in betweenany two assets that have a, a
relationship, even if it'sthrough something else, here's
an 18 point list of things thatyou need to satisfy and
(10:31):
describe.
So if you have even just aslightly non trivial, network
configuration, you're talkingabout dozens, of justifications
multiplied by 18 points that youneed to document for that.
Now that's at the very end.
So this is almost like anafterthought.
in an appendix, not dealing witheverything that you're supposed
(10:53):
to do upfront, but in terms of,the simple answer to the
question, it feels to me, itfeels if you did it full
strength, you could double theamount of, let's say, regulatory
overhead on a project.
So that says, yeah, you got tohave a strategy to get through
Pat Kothe (11:06):
So you, you have to have a strategy when you're,
when you're starting a projectfor cybersecurity.
And then there's some...
more or less verificationvalidation work that needs to be
done at the back end to assurethat it's covered.
You're living with thisthroughout the development.
Milton Yarberry (11:25):
Absolutely.
And that's what they say, youknow, as a total product life
cycle, they mandate that youhave an SPDF define, secure
product development framework.
if I'm remembering the acronymcorrectly and that mandates
activities before you startdevelopment, during development,
and once the device hits themarket in terms of post market
surveillance.
(11:46):
But the activities they expectupfront is that you do things
like, okay, write these plans,and then follow these in your
development.
And then after the thing is outthere, watch your product and
report vulnerabilities here.
Check for vulnerabilities there.
It's a full recipe.
I picture a whole suite ofcompanies coming in to provide
services for each of thesestages, just to shortcut this
(12:08):
stuff because it's so much toabsorb when this isn't your main
thing that you do as a company.
Pat Kothe (12:13):
I refer to it as a guidance, but it really isn't a
guidance.
This is a patch act.
This is a requirement, correct?
Milton Yarberry (12:21):
Yeah.
I believe the term is inregulation.
So
Pat Kothe (12:25):
is regulation and as of,
Milton Yarberry (12:26):
becomes law, it's a
Pat Kothe (12:28):
and is it law at this point?
Milton Yarberry (12:30):
It is
Pat Kothe (12:31):
And this, this includes a 510k device, a de
novo device, a PMA device, anydevice that has software that's
connected or not connected tothe internet needs, needs to
follow this, this regulation.
Milton Yarberry (12:47):
and the act itself calls out, yes, it just
needs to have software.
And then you've got to have a, Band C the FDA has a software
interpretation on their RTA, butit doesn't mean that they're
going to pass that.
That just means that they'reopen to the.
Pat Kothe (13:01):
So when you look at this as an experienced person,
what's the easiest devices toimplement this?
And then what, which are themore complex devices where
you're really gonna have some,some extended amount of time to
put into this?
Milton Yarberry (13:17):
Yeah, let's say the most complex would be the
ones where you have multiplenetwork entities or assets.
Let's say that you have theactual medical device itself.
Let's say that it has a, aportal that it, uses to
communicate over, say, multiple,communication paths, not just Wi
Fi and Ethernet, but maybe alsoan additional band as a backup.
(13:39):
Let's say that you have remotepeople on their iPad, observing
a procedure.
Let's say that you have, metricsgoing up to a server.
at that point you have so muchnetwork, so many entities, and
so many agents within that.
And areas where you have to havea robustness against, like
denial of service attacks, forexample, and areas where you
don't care about that.
And you need to have all thatwritten up, justified and,
(14:02):
implemented and tested.
So, I mean, it's, it, it's aheavy lift.
So really being aware of theoverhead as you even scope your
product.
Pat Kothe (14:12):
And on the simple end, it's the software in a
medical device that's notconnected to anything.
that's the easiest one.
Milton Yarberry (14:20):
I actually haven't tried to apply it to
that style.
I've tried to apply it to theone that I just mentioned.
So the more complex scenario,and when I think about how much
can this be cut down for thelower end of the spectrum.
Maybe I can't even comment onthat right now.
I need to think about it.
So,
Pat Kothe (14:37):
So, um, this act didn't come from nowhere.
Somebody decided that there wasa problem here and then some
people got together and wrotethis.
Were medical deviceprofessionals involved in the
writing of this?
Milton Yarberry (14:54):
The actual guidance that the FDA put out, I
believe it was 2014 was thefirst iteration, and then there
was an iteration of believe in2018.
And so it gets feedback on eachof these stages.
the last or the previousguidance that was put out.
typically what happens is theycollect feedback from the,
industry and then they apply itand they'd make it final.
(15:15):
They didn't even get to thatstage.
Things were changing so fast um,with the ransomware attacks
through COVID that they justsaid, okay, you know what?
We're not even going to make thenext, we're not going to update
and release that version.
We're just going to move on tothe next version.
Here's a new set.
I don't know if they're actuallystill pulling for comments on
the current guidance from 2022.
Pat Kothe (15:35):
How is this, this act been embraced by people within
industry?
Has there been pushback?
is it, readily adopted.
What are you hearing from yourpeers?
Milton Yarberry (15:44):
I think it's too new for people to have gone
through full cycle.
The latest guidance, which Ithink it doubles in terms of
length from the previousiterations, it's twice as long
as the previous iteration.
And that tells you about howmuch more substance they put in
it.
And I don't think that, yeah, Idon't think there's, since 22,
(16:05):
there isn't time to apply it,submit, have the feedback from
the FDA.
So I sort of suspected that alot of this is going to be,
they're actually feeling theirway through this.
Like one of the examples I'llgive is that, an SPDF that's
called out in guidance, which islike at least 62, 443 um, is.
(16:26):
is not actually intended formedical devices.
It's for commercial products.
There's another standard, Ibelieve it's 81001, intended for
medical devices, but it wasn'tpositioned in the guidance.
So, um, you know, one of thethings I recommend doing is go
with a, go with the one that,better fits.
(16:46):
but that tells you how newthings are.
And, that other thing Imentioned about the 18 points of
compliance between every twoassets that you're supposed to
write up that's buried in anappendix.
That, that feels kind of,there's more to come on this
does that get cut down to size?
Does it get adapted orqualified?
In terms of what you're supposedto apply it towards, because you
(17:07):
could spend months creatingdocumentation that really
doesn't address thevulnerability of your system,
and that's never good foranybody.
Pat Kothe (17:17):
So I'm sure that, you had projects that were in
process before this hit.
And, it probably affectedtimelines of your projects and
maybe even design of your, ofproducts.
Tell me a little bit about howyou approached that when this
dropped.
Milton Yarberry (17:34):
We tried to get the word out, frankly, before it
became law, before it becameregulation.
People were doing cybersecurityat the end.
They were primarily in thecardiac business or the infusion
pump business or the IBDbusiness.
And their mind was on thisproblem, which was
groundbreaking, which was theirproduct, which, required all of
(17:55):
their concentration and theydon't have time for those other
issues until it's preventingthem from moving forward.
I don't think it's beenencountered yet.
People know a few things thatthey were supposed to do and
they were intended to do that atthe end.
I think it's gonna beinteresting.
Either you will get a bunch, awave of applications which don't
get accepted and then peoplewill start writing about that
(18:18):
and then people will respond.
It's all has to do with how it'sbeing policed, frankly.
Pat Kothe (18:23):
This is similar, similar to what many startup
companies do.
They've got an idea, they starttalking to customers, they start
developing a product, theyunderstand what user
requirements are going to be,and they start building.
And then at some point in timesomebody says, Hey, we should
probably get a quality systemgoing here.
(18:46):
And then they have to gobackwards, and then going
backwards causes all kinds oftime delays, and issues, and
things going on.
So this is a similar situation.
The further down the road youget, the more painful it is to
go backwards.
Milton Yarberry (19:01):
Absolutely.
Absolutely.
Well, and so I guess where I'veseen that happen to both, new
players in the market as well asexperienced players.
and I find that curious, I findit maybe even to the point of,
to understand the dynamics inthat, does that, does it make
more sense to do it that way?
I'll actually toy with thatidea.
(19:22):
is it easier to back into asolution than to manage a
process?
Because managing a processmeans, a decision chain, uh, and
it's sort of an executivefunction.
Um, managing the limited problemis a little more like
firefighting.
You know, it's the urgentresponse.
It's something you can deal withand conquer now.
It's well understood, wellbounded.
I have a term, fires not cats.
(19:43):
Like I can put out a fire.
I know how to do that.
I don't know how to manage cats.
I don't know how to geteverybody in the chain to agree
ahead of time before weimplement.
It's a harder problem.
and I think we are nativelyproblem solvers more than we are
consensus builders.
Pat Kothe (19:57):
Yeah, I find it, um, when, When there's a blur
between research anddevelopment, that's kind of
what, you know, where therebecomes an issue.
If you're still in the researchphase and you're developing
product while you'reresearching, uh, you run into
those problems.
if you've done the research andnow you're able to do
development from, this is theidea, this is the user
(20:20):
requirements, this is the roadroadmap we're taking, and you're
pretty firm there.
Then it goes like clockwork.
But if you start ingest,injecting more research into
that, it kind of messes, thedevelopment project.
Milton Yarberry (20:37):
Absolutely true.
But I feel even those that, havedone this before.
And, um, have, have producedsolutions and had them released.
And, you know, it's, it's kindof a rinse and repeat.
There still is that, fuzziness,a slight fuzziness around
customer needs.
How is this product different?
What's the value add?
And, frankly, there's going tobe less ambiguity after the
(20:57):
thing is built about what needsto be in place.
But I think there's, it's aconfluence.
I don't think it's any one, two,or even three reasons.
There's many reasons, like forexample, for those who don't,
haven't, written requirementsthat go through, verification
and validation before.
It's easy to confuse,requirement writing difficulty
(21:18):
with product uncertainty.
Writing requirements.
It's hard, it's low, it's notexciting.
And they don't know how tobasically write a requirement
that kind of just motivates atest.
That's why you're writing arequirement.
Cause you're going to test it.
You're going to prove it.
So only write the importantthings.
A lot of them don't understand
Pat Kothe (21:35):
Yeah, it's like saying, a requirement is a
surgeon has to like it.
Well, okay.
Milton Yarberry (21:41):
Or be easy to
Pat Kothe (21:42):
Ease of use.
Ease of use is another one.
Yeah, define ease of use.
How am I gonna test againstthat?
Yeah.
So you brought up a reallyinteresting point because many
medical device companies, havefocused on hardware product, and
software is something that'sdifferent.
And when it comes to userrequirements and user needs, I'm
(22:05):
sure that there's a learningcurve for people when it comes
to software.
So they may be a product managerwho's got a hip or a knee or a
shoulder or a catheter, andthey're used to writing those
physical product requirements.
But software is different.
how do people transition fromwriting those hardware to
(22:27):
software requirements?
Milton Yarberry (22:30):
Yeah.
mean, you know, I'm sorry tosay, but kind of poorly, you
know, they, uh, you know, it's,it's, it's, it's difficult.
I would, and I would just say,simply find somebody who,
whether you hire or go outsideyour organization, find somebody
who's done it before.
But even for the people who'vedone it before, if you get two
of those people in a room, thelikelihood for there to be.
(22:52):
Different processes andexpectations is, pretty close to
a hundred
Pat Kothe (22:56):
what are the differences between writing for
software versus hardware?
Milton Yarberry (22:59):
Software tends to be all functional,
particularly when you're writingspecifications around hardware,
electrical systems.
do you specify that it shall bea 19 watt transformer for the
power supply?
Or do you specify that thesystem shall not have brownouts
under any conditions?
So there's a little bit of, hey,how do you write a requirement
(23:20):
that doesn't overspecify yoursolution, specifies what you
actually want to go after as atest.
And that kind of abstractthinking, I find that, people
from the systems end of thespectrum are less familiar with.
And I think it's easier a littlebit on the functional side, the
behavior that you want the userto experience is all around the
user, right?
So there's a clearer chain onthat side.
(23:42):
But I think, um, well, you alsoend up with two different design
processes.
Software, it's very much, what'sa requirement, convert that to
specifications, convert that totasks.
Let's test it at the end of thesprint.
Hardware, you could, forexample, under, board
fabrication, have a whole, threemonths where there is, okay, we
(24:04):
have the schematic, we convertedit to a layout, we sent it out
for fabrication, we populated,we did the burn in test, and you
do all that to get to your firstdoes anything work at all or are
we in another hardware cyclespin?
So the time spans are justdisproportionate to the software
side.
You can't really keep them insync and you really need to have
an overall design plan thatsays, here's how requirements
(24:26):
are managed over here.
Here's how requirements matchover here.
And here are the touch points.
Pat Kothe (24:31):
So when a company comes to you and, and says,
we've got a, we're, we'reprimarily a hardware group.
We, we've got a idea for asoftware, software product.
How do you do that?
I mean, do you help them throughthat process of doing
requirements or are youexpecting them to deliver that?
How does that work?
Milton Yarberry (24:50):
I don't think I've ever, I have to think about
this.
Have I ever had customersactually deliver me?
even requirements that were like50 percent done, you know, I
mean, it's, and, and, and on theother hand, on, in the beginning
of the engagement, if you askthem, they'll say, do you have a
PRD product requirements?
And, I'd say 80 percent say,yes, we have that.
(25:11):
And then on the delivery side,it's okay, most of this doesn't
apply is done yet.
Let's just start over.
and that's where most of ourengagements, begin.
Even when they're really closeto finishing the implementation.
Pat Kothe (25:24):
Wow.
So why do you think that is?
Milton Yarberry (25:28):
That's a really deep multifaceted, question.
I think it's because, I thinkthere are solutions that could
be applied to it.
Like right now, if you thinkabout the process of how do I
define my product?
Okay, we know we have a productrequirements document.
We know we have some sketches.
We know we have conversations.
(25:48):
There's no place whereeverything lives.
And the formal documentation,the cycle time for that to get
reviewed and checked into yourdoc control system and then re
release to engineering.
So now you know what to build isso lengthy that it never gets
used.
So it's kind of like there's noone source where all the inputs
meet.
And then chiefly when, let'sjump forward to where you
(26:13):
actually have completed productrequirements and specifications.
Ask somebody to read one ofthose.
you get about half a page in ofvery carefully worded You know,
factors that you have to keep inyour mind before you're, you
forget what the first one wasthat you read.
So they're very difficult toconsume because they're all
text.
It's very dense.
(26:33):
It's very technical.
So what do you do about that?
This is one of the, reasons whyI'm at the company.
I'm at ICS is one of theproducts that we're, in the
process of creating is somethingthat pulls threads together like
that drives it through pictures,drives it through the user
interface layout, drives itthrough, state machine diagrams,
uh, swim lane diagrams, and thenallows references to your
(26:57):
requirements and specifications.
Pat Kothe (26:59):
Tell me a little bit about ICS, what you guys do,
what types of projects thatyou're involved with.
Milton Yarberry (27:04):
We're a software services business, been
around since, 1987.
and basically, what I like is wetry to solve axel wrapping
problems with noveltechnologies.
We have a couple of internalproducts, one called greenhouse,
which is a low code solution.
So it allows you to basicallydraw pictures for your UI and
(27:25):
then code comes out that givesyou an architecture front end to
back end.
we're developing the product Imentioned around defining your
product.
But otherwise we're a full stackembedded development.
chiefly we have a usability,dedicated usability group.
And we have a deep, you know,reserve of experience around Qt.
But otherwise, I mean, we'refront end and back end automated
(27:47):
testing, V and V testing, cloudconnectivity.
You know, it's kind ofeverything you would have for a
medical device.
Pat Kothe (27:52):
And you personally do the medical device side of
things, but the company doesother verticals as well, right?
Milton Yarberry (28:00):
Yes.
Yes.
Uh, More so it's, uh, medicaldevices sort of taken over.
We're medical devices aboutprobably about 70 percent of the
business we do, in the past,maybe two years, three years.
We also, have, I would say,roots and still ongoing work in
commercial sectors as well forlike automotive, industrial
machines, that sort of thing.
Pat Kothe (28:20):
So I want to focus a little bit now on the user side
of things.
When you go under the hood,there's analysis that needs to
be done, there's the hardcorefunctionality of the product,
but then there's the userinterface.
And within medical device, it,It could be a little bit
different than it is with, withyour phone or with a simple
(28:43):
device where it's all simple.
Sometimes our medical deviceshave multiple things that, you
know, complex issues that peopleneed to enter data in or
manipulate the device, with amore, complexity to it.
How do you guys approach.
UX when it comes to medicaldevice and balancing simplicity
(29:09):
with the needs of the product.
Milton Yarberry (29:11):
great question.
Um, so first of all, I would saythat there is a usability
standard out there, 62, 366,which is the core for us
applying usability to medicaldevices, it gives you a process
or a series of input that allowsyou to itemize and feel like
you've done a comprehensive jobof itemizing your use errors.
(29:36):
So not mistakes the user makesdefects in your device that the
user will step on.
There's that aspect and that'show we approach, designing it
and assuring that we're doingthe risk analysis right around
the user interface and that's,medical devices, safety and
efficacy.
That's, the risk analysis is apretty critical part of that,
and a primary motivator, butusability more broadly, it gets
(30:00):
used by many industries and itcan kind of mean, in my mind,
there's a dichotomy there.
There's the, it's a pleasure touse.
And then there's the does itmaintain safety and do you make
use errors.
And those two have some overlapdepending upon the device, a
little overlap, or a lot.
But there are clearly placeswhere they don't line up.
(30:21):
A pleasure to use advice meansthat maybe it doesn't annoy you,
uh, a medical device that'sgoing through an alarm, you want
to annoy you at the right time.
There's also concepts of alarmfatigue and, mitigation to that,
but there's a different,completely different set of
logic driving those two thingsand, When we're doing medical
(30:41):
devices, we tend to almost, 80percent focus on the safety
aspects over the, was it apleasing experience because, you
don't want that to ever trump,the former.
Pat Kothe (30:54):
My wife went to the dentist last week and she came
back and she was a little upset.
I said, what happened?
She said, I'm laying in thechair, the hygienist is, doing
whatever she's doing.
And then she's turning backaround and I hear something
being entered into a computer.
And then she's coming back in mymouth and I'm thinking, did she
(31:18):
just enter something with herfinger and now she's, you know,
on a keyboard, and now she'sgoing to go back in my mouth.
So when we think about,Software, sometimes it's
entering things in with a mouse,with a keyboard, but it can also
be voice, it can be gestures.
Tell me a little bit about wheresoftware as a medical device is
(31:41):
when it comes to some of theseother things so that somebody
like, like a hygienist is notgoing to be entering things in
on a keyboard.
Milton Yarberry (31:51):
Yeah, that's maybe, a confluence.
so how would that come up?
So first of all, what they'reentering, is probably not even
regulated software.
That's been my experience isthat hospitals and dentist
office, most of what's on theircomputers is, it's not software,
as a medical device, and it'sbecause they can't tie it to an
intended use and a clinicalfunction, so therefore patient
(32:13):
safety is never evaluated, whichis interesting.
I think, based upon what I'veseen, uh, around hospitals and,
the software used for thephysicians and, the nursing
staff.
I imagined in, choose yournumber X number of years that's
going to be regulated, it's justgoing to take a couple of bad
events for that software to saythat patient was treated with
(32:34):
this and they weren't.
For that to be, become an issue.
but, yeah, so basically I guessmy answer is yeah, it's not
regulated.
So,
Pat Kothe (32:44):
But are you dealing with things, with things like
gestures and, and, and, uh,voice, uh, voice activated
things when it comes to softwarethat you're involved with?
Milton Yarberry (32:54):
yeah, yeah, we've seen those, but I don't
feel like it's really ever takenoff.
They've always been sort of moreexperiments, toys, things that
go through formative study.
and I don't know why theyhaven't gained traction in a
more permanent way.
I almost feel like I saw more ofthat, three, four years ago than
(33:15):
today.
Pat Kothe (33:16):
Interesting.
Once you get through the userrequirements, and you have those
down, there's other things thathappen during that development
phase.
So what are some, some areaswhere you see, after user
requirements are locked in, andyou're going through
development, what slows thingsdown?
What makes, uh, you know, some,some sand in the gears??
Milton Yarberry (33:39):
Beyond the areas of, we didn't really
define the product and thatcauses ripples of change
throughout your system.
and those ripples, they canstart at, okay.
We, we had a release candidateand we were testing it and now
we have to do a formative study.
I've been in that scenario andinformative study means there's
a change and the change meansyou're going to go through V and
V again and blah, blah, blah.
So, um.
(34:01):
Things like having to repeatsummative, which typically ends
up being a fairly expensive,often external effort, that
those are big penalties,involved with that.
I think that a key area, as Imentioned, of course, is the,
getting everybody in agreementand aligned around what the
product is.
is a key area where it hurts theproduct all through all phases,
(34:26):
basically, including the testwriting at the end,
understanding, well, is that theway it's supposed to work?
Or, is it supposed to be a or Bor hasn't this not been thought
of yet?
And not having a place to checkthat.
So then that becomes meetingsthat becomes as opposed to, you
can look up the answer in a veryspecific location.
Another area is, yeah.
(34:46):
Especially around medicaldevices where there's a hardware
component is the hardware cycle,everybody knows, of course,
things got killed in COVIDbacklogs, out the door, 18 month
backlogs on some of ourprojects, waiting for hardware
to become available.
so simulators is, a key answerto that.
And,
Pat Kothe (35:06):
What do you mean, what do you mean by simulators?
Milton Yarberry (35:09):
Oh, something that, simulates, emulates,
hardware on your system andallows you to progress with,
development, testing, debugging,
Pat Kothe (35:18):
So even though the hardware isn't done yet, you're
simulating the effect of the
Milton Yarberry (35:23):
Decoupling basically your software and your
hardware programs withsimulators and emulators, yeah.
Pat Kothe (35:29):
Okay.
and then there's the oldmanagement injector, you know,
one more thing, can we just addthis in?
Milton Yarberry (35:39):
Yeah, now, now that, in fairness, I guess I
have to treat that I, I try tobalance all these, points
because I'm interested in rootcause.
And if you have late informationto the table and you're in
charge of a business and aproduct and your job is to bring
that product to market, are youdoing something wrong by
(35:59):
including that, no matter howlate?
It depends is the obviousanswer.
it depends on how much of that'sgoing to hurt you and is it
worth the cost and the risk.
So to those sort of problems,particularly where there, where
the information comes fromoutside the organization, I
guess a fair critique would be,we should have done better
research for that upfront.
And sometimes you do thatresearch and other times, I'd
(36:22):
say most of the time our clientsare so deep in their industry,
that it's difficult to sayyou've spent 25 years in your
industry, you've built four ofthese before you should do some
research.
Pat Kothe (36:33):
Yeah.
Yeah.
And sometimes when we'redeveloping a new product, we
won't.
There will be things that comeup when you go and take it back
out to the customer and say,this is where it is.
And the customer will say, well,if you did that, we can do this.
And, so there's, there is somelate information that comes to
the table that you may not havebeen able to anticipate.
Milton Yarberry (36:57):
Right.
But I think a lot of thatinformation, that type of
scenario, a one off comment latein the game, that's really
dangerous bait, to go after.
You, you have to assume that,there are all these
psychological factors around ourcustomers.
They didn't know they wanted anautomobile because they only had
a horse and carriage.
(37:18):
Those sort of factors.
So you have to figure out whereyou're leading the customer, and
really what's a valid input.
So that should be an entireprocess of vetting and
justification.
Pat Kothe (37:28):
Let's talk a little bit about updates because, you
can enter in with the productthat you want, but if somebody
comes in and says, there's somebait out there and it's actually
strong bait that could be used,but you don't want to slow down
or stop your development programor product launch, but you think
that this is a valid idea.
(37:48):
Now you've got version two that,it could be implemented in.
Let's talk a little bit aboutwhat regulatory bodies are
saying about updates to softwareand how that should be built
into the regulatory filing.
Milton Yarberry (38:06):
Happens in startups a lot.
You work like crazy in order toget the product out the door and
then you finally get itsubmitted.
And then there's a gap betweenthe beginning of the submission
process and then kind of a slowtrickle based upon every time
the FDA comes back to you withcomments.
Maybe you tweak something hereor there and that gives your
entire engineering team, whichwas killing itself, a month ago,
(38:28):
now they have almost no work andthat no work can go for several
months.
So there is sort of a fastfollow release, that is, thought
of, okay, we got our, ourprimary version out the door
that we're going to submit with.
We should consider which changeswe want to fast follow with.
We should consider whatregulatory steps we have to go
(38:48):
to because of those changes, andit could be something as simple
as a letter to file, which islike no FDA interaction, at
least immediately, and then, toa supplemental submission.
There's a lot of leeway and alot of flex in terms of what the
right answer is.
It's very situation
Pat Kothe (39:05):
Yeah, and, and it's something, uh, say it's an
algorithm and you've got machinelearning or some AI in there and
you're going to update thatportion of that.
You may not update the fullpiece of software, but it could
be part of the analysis enginebecause you've got learning
that's occurring real time.
That's another, anothersituation.
Milton Yarberry (39:27):
Yeah, the whole machine learning aspect.
mean, there's a lot of pieces tothat.
there's even the notion that,you as a manufacturer now are
responsible for, curation.
You know, so the data youtrained it on is now kind of,
especially once you've releasedthat, that's a golden fixed set
and which examples you choose toinclude or remove, in a sense,
(39:47):
need to be understood well andjustified.
Why did you include these foursamples and why do you remove
those 200?
But the FDA has, um, publishedexpectations around this for
people that want a shorter pathto being able to update their,
um, They're neural network ortheir machine learning, but most
of that comes down to, uh, youhave expectations for where
(40:09):
you're going to seeimprovements.
And when you have expectationsconsistent with that, then you
have a shortcut.
Otherwise you're kind of in thesame boat of needing to resubmit
or evaluate the level of thechange.
Pat Kothe (40:22):
So when you get um, these changes, um, in your, in
your, uh, uh, developmentprogram, what is the best way to
manage the change process?
Do you have tools that youutilize or methodologies that
you utilize that says, a changeis coming in, now how do we
evaluate the impact of thatchange?
Milton Yarberry (40:44):
Yeah, so there's kind of like two sides
of that fence.
There's a sense before youactually have a formal release.
In which case, changes aren't asformal, aren't as, overhead
burdened.
until the design is quotecomplete, it's not actually a
change.
You are in the process ofdesigning.
As soon as you have a versionthat goes over to your V&V group
or makes it out of your V&Vgroup at that point, now you're
(41:07):
talking about changing yourdesign.
And that requires a formalprocess, particularly where you
take a look at any risk you'reintroducing with your changes.
Pat Kothe (41:15):
The PATCH Act deals with, um, with devices going
forward, but we have a lot ofdevices that are out in the
field right now.
pacemakers that are out there,that, they're inpatients,
they've been in for a while.
We've got, other types of thingsthat were, put out last month,
that, that didn't, didn't, uh,uh, contemplate or weren't as
(41:37):
robust when it comes to these,uh, issues with cybersecurity.
What is the agency and whatdoes, the industry have to do
from a responsibility standpointfrom these systems that are
already out there?
Milton Yarberry (41:54):
I've seen nothing of like, uh, either the
term grandfathering or the needfor anything that's already
deployed to change, at least notin the U S In the EU.
It's a different story.
But, anything that's beenreleased in the past, what since
2018 those devices have probablytaken a look at the guidance and
I think we're past the dayswhere hopefully, anybody is
(42:16):
putting out something with, theydidn't change the root password
and they didn't, they didn't doall the obvious things, So
there's doing the obvious goodhousekeeping, use passwords, use
of, uh, sufficiently, uh,sophisticated encryption, have a
software update process, uh,that, uh, is protected.
Secure boot.
You know, all these things aretable stakes.
(42:40):
But a lot of the threatmodeling, for example, goes
beyond the table stakes.
It's looking at, did you reallyscrub your network to see where
you were vulnerable and how, andtell us explicitly which things
you were, you considered throughyour documentation.
It's almost like a zero dayattack, thinking, rather than
(43:01):
lock the doors, lock thewindows, turn on the burglar
alarm.
Pat Kothe (43:05):
So we're fortunate that, uh, going forward, a lot
of these things are beingcontemplated and built into
systems.
We still have some risk withsome of the legacy systems that
are out there.
The further out we get, thebetter we're all going to be.
But there's still some risk forproducts that were manufactured
previously.
Milton Yarberry (43:23):
Yeah, fortunately, the really old
stuff where, they probablydidn't look at any of the
guidance.
is probably not verycommunication enabled.
So pacemakers, for example, Iknow there are a few cases
where, there have been someglaring problems, but, those
problems have been identified.
Others, are addressing them ifthey had them.
at this point, I don't see a bigremediation wave, like sweeping
(43:45):
through those products, or atleast I don't see the motive for
that yet.
Pat Kothe (43:48):
Yeah, and there's risk reward there too, because,
if it's a, an, implantedproduct, there's risk in taking
that out, so you have to balancethe risk between what's a cyber
security risk versus what's themedical risk for another
procedure.
Milton Yarberry (44:02):
Absolutely.
Absolutely.
The rollout can, yeah, literallykill you.
Pat Kothe (44:06):
Yeah, yeah.
Well, this has really been afascinating discussion and
dealing with a very timely issueand one that, that most medical
device companies are wrestlingwith, that will be wrestling
with because even, simplehardware products can, often be,
augmented with, with a software,software product alongside it.
So thanks for leading us, uh,kind of, uh, on the discussion.
(44:30):
As companies are becoming moresoftware oriented, what do you
see as some things that theyshould be considering as they
make that transition from onlyhardware to having software as
well?
Milton Yarberry (44:46):
well, well, I think the industry is taking
care of that in a sense, youknow, I'd say like the last few
companies I've worked with, it'srare to meet, a mechanical
engineer that's just, doesn'tknow scripting of some sort.
As, uh, uh, the kids are comingout of school and going into
industry, they have themultidiscipline, You find fewer
purists these days and, uh, youknow, that basically the system
(45:10):
will just sort of age in thatdirection so that people are
more system capable rather thanjust in a particular domain
capable.
Pat Kothe (45:17):
When I think of project development or product
development, the marketingpeople are also people that are
interfacing with the customersand translating customer needs
into user requirements.
And, If they're used to beinghardware people, even though the
development people may besoftware people, the marketing
people may not be.
(45:37):
And that, that, that's an areathat I think should probably be
beefed up as well.
Milton Yarberry (45:43):
Although as soon as you're going as far out
as marketing, which, you know,from, uh, I used to be an
engineer and, and, and, uh, youknow, interested in engineering
and the architecture, uh,heavily.
Product marketing is about asfar away in terms of
expectation.
So I think there's already a lotof, support structures uh, you
(46:03):
know, in people's heads and inpeople's processes to, Bob said,
he wants it to be easy.
Okay.
Now we know we got to break thatdown with a formative study.
We know that we have to write ause case, get Bob into use
cases.
and then let's map requirementsto the use case.
We're used to when dealing with,you know, um, business owners,
(46:23):
product owners, marketing, um,to assisting in the conversion
to something concrete andtestable.
Pat Kothe (46:33):
Software is here to stay, and software regulations
are too.
As we grow the types of productswe offer, we need to keep our
North Stars of safety andefficacy front and center.
A few of my takeaways.
First, stay on top of regulatorychanges.
(46:56):
Not just what is here now, butwhat's coming.
Because it will impact yourtimeline.
And it will impact yourdevelopment plan.
And it will impact the costsassociated with your development
plan.
If you need to involve anexpert, seek out someone like
(47:17):
Milton.
It's going to pay off.
Secondly, user requirements.
We had a nice discussion on userrequirements, and we're familiar
with that, uh, with hardware,requirements for, medical
devices, but we may not have aclue what best practices are
with software.
(47:38):
So, find an in house expert.
If you have them and have themrun it, if you don't have one,
bring someone in from theoutside.
Again, your timeline and yourcosts are going to be at risk if
you cut corners in this area.
Finally, changes will occur.
(47:59):
No project goes according toplan in what you did with your
user requirements right upfront.
So try and do the best you canto define the product up front,
but then recognize that changeswill come.
And then you have to manage theproject.
You'll have to make decisionsbased on customer feedback,
(48:23):
timing, launch windows,competitive products, regulatory
issues, and managementexpectations.
So understand up front thatchanges are coming.
And what you need to do isdevelop a management system to
be able to handle those changesefficiently.
(48:46):
Thank you for listening.
Make sure you get episodesdownloaded to your device
automatically by liking orsubscribing to the Mastering
Medical Device podcast whereveryou get your podcasts.
Also, please spread the word andtell a friend or two to listen
to the Mastering Medical Devicepodcast as interviews like
today's can help you become amore effective medical device
leader.
(49:06):
Work hard, be kind.
Welcome! Software has been and will continue to be
important to delivering qualityand efficient medical care.
With our life saving andsustaining medical devices,
safety has always been at thetop of our list.
But the software world is alittle different.
And the pace is typically muchfaster than a typical hardware
(00:55):
product.
Regulatory bodies haverecognized the issues with
software in and as a medicaldevice and are attempting to
provide guidance andrequirements that assure our
software products meet the samesafety standards as the hardware
ones do.
Today we're going to discuss oneof those pieces of regulation.
(01:16):
Our guest is Milton Yarberry,Director of Project Management
at Integrated ComputerSolutions.
Milton has developed or managedsoftware development for
Motorola, Lucent, Cognex,Inktomi, and FEI before moving
into the medical software sectorin 2006 with Foliage, IVENIX,
(01:40):
and now ICS.
In our conversation we discussthe Protecting and Transforming
Cyber Health Care or PATCH Actwhich FDA implemented in October
2023, including what software isimpacted, the key takeaways from
(02:01):
this regulation, if this affectslegacy devices as well as new
devices, and how medical devicecompanies will be impacted.
Here's our conversation.
Milton, you've, uh, had a quitea career in software development
and you've worked not only inmedical device but also other
(02:22):
industries.
Many times we like to think inin medical device we like to
think that we're unique andsometimes we are but how are we
unique when it comes to softwaredevelopment?
Milton Yarberry (02:35):
Yeah, I feel like there are so many, ways in
which that is true, and yet, um,one thing I can say, I, I, I
think there are a few areas thatit's notoriously different in
terms of the paperwork, definingrequirements, traceability, the
sheer amount of sort of homeworkyou have to do in addition to
the software component.
But, I think what's interesting,what I find interesting, so I
(02:55):
find complexity and challengingproblems interesting and like to
tease them apart and find apractical solution.
And then in this regard, I thinkthat commercial software, if you
follow the process that makessense, it's very close to what
the FDA wants you to do, i.
e.
should you decide what you'regoing to develop before you
develop it?
(03:16):
And that's like the underlyingpremise maybe of like design
controls.
Should you test it, make sure,make sure it works before it
goes to the field?
Not crazy stuff.
Although commercial and medicaldevices, they feel absolutely
different in a variety ofdimensions, they really should
be more similar if you weredoing rational commercial
development.
Not everything is heavy and notwith part 11 compliance on
(03:38):
signatures and that sort ofthing.
But in terms of the generalprocess of define it, build it,
test it, and frequently thatdoesn't happen in commercial
software that way.
Pat Kothe (03:48):
And within software, you know, we, we hear so often,
get an MVP out there, build itfast, break it, come back and
iterate and just keep moving it.
Don't put a perfect product outthere.
Put one that's good enough andthen iterate off of it.
Not quite what we want to do inmedical device.
Milton Yarberry (04:05):
And the key piece is just the safety, right?
Is that if there is a problem inthe field, for most commercial
products, there's no staggeringconsequence, nobody gets hurt
per se.
And of course, the FDA'scharter, safe Safety and
Efficacy, that's what thatprocess addresses.
Pat Kothe (04:22):
Software is, you know a big term and within medical
device we've got software as amedical device and software in a
medical device.
Can you explain a little bitabout what the differences are?
Milton Yarberry (04:34):
Conceptually it's pretty simple.
The software as a medical deviceis basically software that runs
on, not customized or generichardware, so laptops, tablets,
phones.
Where software in a medicaldevice is something that is
using some piece of customizedhardware.
And the reason that matters isbecause the performance of the
(04:55):
hardware matters as you couldsay as much in terms of getting
the process right as thesoftware interpreting what's
coming off of the hardware.
It's a, hardware plus softwareversus just software domain.
Pat Kothe (05:08):
So the regulatory bodies have been iterating on
their guidances for softwareover the past 5 10 years, but
they just recently came out withsomething in 2023, the Patch
Act, Protecting and TransformingCyber Healthcare Act.
(05:29):
Can you lead us through how theregulatory bodies have addressed
software and what thisparticular act is all about?
Milton Yarberry (05:40):
Really this act is, the FDA's request to be able
to regulate cybersecurity andmedical devices.
the Patch Act, which passed aspart of an omnibus spending
bill, I believe, earlier thisyear.
what's interesting about it, ormaybe the high points are, is
that, so this is the FDA saying,you have to have cybersecurity,
and this applies to all medicaldevices with software.
Pat Kothe (06:02):
Whether it's software in a medical device or software
as a medical device.
Milton Yarberry (06:06):
Yeah.
and if you take a look at saythe patch act language versus
the refuse to accept from theFDA, the language is a little
bit different.
The refuse to accept as littlenarrow patch act is a little
broader.
There's two conditions that arethe patch act that has software,
or if it can be connected to theinternet, that's an or
condition.
So what that means is that a lotof companies were using sort of,
uh, the, an air gap solution.
(06:29):
Meaning, okay, our device isn'tgoing to talk to the internet.
We're just going to wrap it upin the box.
And we're going to say, we don'thave to comply with any of that
cybersecurity guidance and thatthat won't fly anymore.
So now merely having software,even if you have no ports going
in.
You still qualify and have tocreate these plans and
Pat Kothe (06:47):
What, why is that?
Why would, why that change?
Milton Yarberry (06:51):
I can see a number of reasons.
Basically maybe the largest isjust in the things that they
want you to have, that arerequirements.
The S bomb, they want you tohave a software bill of
materials.
The vulnerability plan, theywant you to have a response in
case somehow your device doesget hacked.
So envision, even if your thinghas no ports in it.
Somebody cracks it open,reprograms it, now what do you
(07:13):
do?
And if you have no plan, thenyou, as a company, you're, at
that point, you're at thebeginning of the scrambling
stage.
Pat Kothe (07:20):
What other things are, are in this, this act?
I mean, what, what are theyasking companies to do?
Milton Yarberry (07:28):
It's really quite extensive because, if you
go through the guidance refersto other standards.
So when you're trying to figureout what to do at the end of the
day, there isn't a definitiverecipe, here's everything,
there's no checklist.
And there really can't be achecklist because you're looking
at so many different, technicalreports, standards, and, the
(07:48):
FDA's guidance.
And these things somewhatoverlap and they use somewhat
different terms.
So there's no one definitive wayto say this is all you need.
And on top of that, FDA is, saidto kick in the refuse to accept
criteria.
And what that means is that ifyou have a submission and you
don't cover certain basicpoints, like a vulnerability
plan, like an S bomb, then yoursubmission won't even be
(08:12):
considered.
Pat Kothe (08:13):
So let's talk about cybersecurity for a second.
What does cybersecurity mean?
And from a medical devicestandpoint, what are the stakes?
Milton Yarberry (08:21):
It's obvious, it's don't let your device get
hacked, but you know, there's,there's sort of categories of
solution that they expect tohave in place, uh,
authentication, authentication,uh, uh, encryption, um, they
expect you to have a softwareupdate, they expect you to do
the analysis upfront, in athreat model of your entire
system, they expect you tofollow certain practices to
(08:43):
figure out where you'revulnerable, and that's maybe the
newest stuff It'll take quite abit of adapting to, because a
lot of people haven't usedthreat modeling tools.
You're not familiar with theconcepts, figuring out where the
boundaries are and what thevulnerabilities are across those
boundaries.
all I can say is, reach out andgrab one of the tools like,
Microsoft Threat Modeling Tool.
It has a medical device templatethat you can use and it's a
(09:06):
click and drag interface thatallows you to say, here's my
system.
And then the heavy liftingstarts when each thing that you
click and drag has a list ofvulnerabilities.
And you need to basically go inand justify why this doesn't
apply, or here's what we do tomitigate that.
Pat Kothe (09:23):
Hard question, but I'll ask it anyways.
I'm sure everyone is different.
But when you're, the old way ofdeveloping software without this
extensive cybersecurity,emphasis on here.
Is this...
Doubling the work, is this, asmall amount of work?
How substantial is thiscybersecurity, guidance?
Milton Yarberry (09:46):
So that is a great question because, um, In
the actual guidance itself, Ibelieve it's, appendix B or
Appendix two B.
B um, uh, there is a step buriedto the very end of the document
that says uh, any relationshipbetween any two assets, even if
it's through other assets inyour system.
(10:09):
And an asset could be somethinglike a server, an asset could be
like a key, an asset could be apassword.
And so you can envision thatlike in your normal system, you
might have dozens of assets.
they're saying that in betweenany two assets that have a, a
relationship, even if it'sthrough something else, here's
an 18 point list of things thatyou need to satisfy and
(10:31):
describe.
So if you have even just aslightly non trivial, network
configuration, you're talkingabout dozens, of justifications
multiplied by 18 points that youneed to document for that.
Now that's at the very end.
So this is almost like anafterthought.
in an appendix, not dealing witheverything that you're supposed
(10:53):
to do upfront, but in terms of,the simple answer to the
question, it feels to me, itfeels if you did it full
strength, you could double theamount of, let's say, regulatory
overhead on a project.
So that says, yeah, you got tohave a strategy to get through
Pat Kothe (11:06):
So you, you have to have a strategy when you're,
when you're starting a projectfor cybersecurity.
And then there's some...
more or less verificationvalidation work that needs to be
done at the back end to assurethat it's covered.
You're living with thisthroughout the development.
Milton Yarberry (11:25):
Absolutely.
And that's what they say, youknow, as a total product life
cycle, they mandate that youhave an SPDF define, secure
product development framework.
if I'm remembering the acronymcorrectly and that mandates
activities before you startdevelopment, during development,
and once the device hits themarket in terms of post market
surveillance.
(11:46):
But the activities they expectupfront is that you do things
like, okay, write these plans,and then follow these in your
development.
And then after the thing is outthere, watch your product and
report vulnerabilities here.
Check for vulnerabilities there.
It's a full recipe.
I picture a whole suite ofcompanies coming in to provide
services for each of thesestages, just to shortcut this
(12:08):
stuff because it's so much toabsorb when this isn't your main
thing that you do as a company.
Pat Kothe (12:13):
I refer to it as a guidance, but it really isn't a
guidance.
This is a patch act.
This is a requirement, correct?
Milton Yarberry (12:21):
Yeah.
I believe the term is inregulation.
So
Pat Kothe (12:25):
is regulation and as of,
Milton Yarberry (12:26):
becomes law, it's a
Pat Kothe (12:28):
and is it law at this point?
Milton Yarberry (12:30):
It is
Pat Kothe (12:31):
And this, this includes a 510k device, a de
novo device, a PMA device, anydevice that has software that's
connected or not connected tothe internet needs, needs to
follow this, this regulation.
Milton Yarberry (12:47):
and the act itself calls out, yes, it just
needs to have software.
And then you've got to have a, Band C the FDA has a software
interpretation on their RTA, butit doesn't mean that they're
going to pass that.
That just means that they'reopen to the.
Pat Kothe (13:01):
So when you look at this as an experienced person,
what's the easiest devices toimplement this?
And then what, which are themore complex devices where
you're really gonna have some,some extended amount of time to
put into this?
Milton Yarberry (13:17):
Yeah, let's say the most complex would be the
ones where you have multiplenetwork entities or assets.
Let's say that you have theactual medical device itself.
Let's say that it has a, aportal that it, uses to
communicate over, say, multiple,communication paths, not just Wi
Fi and Ethernet, but maybe alsoan additional band as a backup.
(13:39):
Let's say that you have remotepeople on their iPad, observing
a procedure.
Let's say that you have, metricsgoing up to a server.
at that point you have so muchnetwork, so many entities, and
so many agents within that.
And areas where you have to havea robustness against, like
denial of service attacks, forexample, and areas where you
don't care about that.
And you need to have all thatwritten up, justified and,
(14:02):
implemented and tested.
So, I mean, it's, it, it's aheavy lift.
So really being aware of theoverhead as you even scope your
product.
Pat Kothe (14:12):
And on the simple end, it's the software in a
medical device that's notconnected to anything.
that's the easiest one.
Milton Yarberry (14:20):
I actually haven't tried to apply it to
that style.
I've tried to apply it to theone that I just mentioned.
So the more complex scenario,and when I think about how much
can this be cut down for thelower end of the spectrum.
Maybe I can't even comment onthat right now.
I need to think about it.
So,
Pat Kothe (14:37):
So, um, this act didn't come from nowhere.
Somebody decided that there wasa problem here and then some
people got together and wrotethis.
Were medical deviceprofessionals involved in the
writing of this?
Milton Yarberry (14:54):
The actual guidance that the FDA put out, I
believe it was 2014 was thefirst iteration, and then there
was an iteration of believe in2018.
And so it gets feedback on eachof these stages.
the last or the previousguidance that was put out.
typically what happens is theycollect feedback from the,
industry and then they apply itand they'd make it final.
(15:15):
They didn't even get to thatstage.
Things were changing so fast um,with the ransomware attacks
through COVID that they justsaid, okay, you know what?
We're not even going to make thenext, we're not going to update
and release that version.
We're just going to move on tothe next version.
Here's a new set.
I don't know if they're actuallystill pulling for comments on
the current guidance from 2022.
Pat Kothe (15:35):
How is this, this act been embraced by people within
industry?
Has there been pushback?
is it, readily adopted.
What are you hearing from yourpeers?
Milton Yarberry (15:44):
I think it's too new for people to have gone
through full cycle.
The latest guidance, which Ithink it doubles in terms of
length from the previousiterations, it's twice as long
as the previous iteration.
And that tells you about howmuch more substance they put in
it.
And I don't think that, yeah, Idon't think there's, since 22,
(16:05):
there isn't time to apply it,submit, have the feedback from
the FDA.
So I sort of suspected that alot of this is going to be,
they're actually feeling theirway through this.
Like one of the examples I'llgive is that, an SPDF that's
called out in guidance, which islike at least 62, 443 um, is.
(16:26):
is not actually intended formedical devices.
It's for commercial products.
There's another standard, Ibelieve it's 81001, intended for
medical devices, but it wasn'tpositioned in the guidance.
So, um, you know, one of thethings I recommend doing is go
with a, go with the one that,better fits.
(16:46):
but that tells you how newthings are.
And, that other thing Imentioned about the 18 points of
compliance between every twoassets that you're supposed to
write up that's buried in anappendix.
That, that feels kind of,there's more to come on this
does that get cut down to size?
Does it get adapted orqualified?
In terms of what you're supposedto apply it towards, because you
(17:07):
could spend months creatingdocumentation that really
doesn't address thevulnerability of your system,
and that's never good foranybody.
Pat Kothe (17:17):
So I'm sure that, you had projects that were in
process before this hit.
And, it probably affectedtimelines of your projects and
maybe even design of your, ofproducts.
Tell me a little bit about howyou approached that when this
dropped.
Milton Yarberry (17:34):
We tried to get the word out, frankly, before it
became law, before it becameregulation.
People were doing cybersecurityat the end.
They were primarily in thecardiac business or the infusion
pump business or the IBDbusiness.
And their mind was on thisproblem, which was
groundbreaking, which was theirproduct, which, required all of
(17:55):
their concentration and theydon't have time for those other
issues until it's preventingthem from moving forward.
I don't think it's beenencountered yet.
People know a few things thatthey were supposed to do and
they were intended to do that atthe end.
I think it's gonna beinteresting.
Either you will get a bunch, awave of applications which don't
get accepted and then peoplewill start writing about that
(18:18):
and then people will respond.
It's all has to do with how it'sbeing policed, frankly.
Pat Kothe (18:23):
This is similar, similar to what many startup
companies do.
They've got an idea, they starttalking to customers, they start
developing a product, theyunderstand what user
requirements are going to be,and they start building.
And then at some point in timesomebody says, Hey, we should
probably get a quality systemgoing here.
(18:46):
And then they have to gobackwards, and then going
backwards causes all kinds oftime delays, and issues, and
things going on.
So this is a similar situation.
The further down the road youget, the more painful it is to
go backwards.
Milton Yarberry (19:01):
Absolutely.
Absolutely.
Well, and so I guess where I'veseen that happen to both, new
players in the market as well asexperienced players.
and I find that curious, I findit maybe even to the point of,
to understand the dynamics inthat, does that, does it make
more sense to do it that way?
I'll actually toy with thatidea.
(19:22):
is it easier to back into asolution than to manage a
process?
Because managing a processmeans, a decision chain, uh, and
it's sort of an executivefunction.
Um, managing the limited problemis a little more like
firefighting.
You know, it's the urgentresponse.
It's something you can deal withand conquer now.
It's well understood, wellbounded.
I have a term, fires not cats.
(19:43):
Like I can put out a fire.
I know how to do that.
I don't know how to manage cats.
I don't know how to geteverybody in the chain to agree
ahead of time before weimplement.
It's a harder problem.
and I think we are nativelyproblem solvers more than we are
consensus builders.
Pat Kothe (19:57):
Yeah, I find it, um, when, When there's a blur
between research anddevelopment, that's kind of
what, you know, where therebecomes an issue.
If you're still in the researchphase and you're developing
product while you'reresearching, uh, you run into
those problems.
if you've done the research andnow you're able to do
development from, this is theidea, this is the user
(20:20):
requirements, this is the roadroadmap we're taking, and you're
pretty firm there.
Then it goes like clockwork.
But if you start ingest,injecting more research into
that, it kind of messes, thedevelopment project.
Milton Yarberry (20:37):
Absolutely true.
But I feel even those that, havedone this before.
And, um, have, have producedsolutions and had them released.
And, you know, it's, it's kindof a rinse and repeat.
There still is that, fuzziness,a slight fuzziness around
customer needs.
How is this product different?
What's the value add?
And, frankly, there's going tobe less ambiguity after the
(20:57):
thing is built about what needsto be in place.
But I think there's, it's aconfluence.
I don't think it's any one, two,or even three reasons.
There's many reasons, like forexample, for those who don't,
haven't, written requirementsthat go through, verification
and validation before.
It's easy to confuse,requirement writing difficulty
(21:18):
with product uncertainty.
Writing requirements.
It's hard, it's low, it's notexciting.
And they don't know how tobasically write a requirement
that kind of just motivates atest.
That's why you're writing arequirement.
Cause you're going to test it.
You're going to prove it.
So only write the importantthings.
A lot of them don't understand
Pat Kothe (21:35):
Yeah, it's like saying, a requirement is a
surgeon has to like it.
Well, okay.
Milton Yarberry (21:41):
Or be easy to
Pat Kothe (21:42):
Ease of use.
Ease of use is another one.
Yeah, define ease of use.
How am I gonna test againstthat?
Yeah.
So you brought up a reallyinteresting point because many
medical device companies, havefocused on hardware product, and
software is something that'sdifferent.
And when it comes to userrequirements and user needs, I'm
(22:05):
sure that there's a learningcurve for people when it comes
to software.
So they may be a product managerwho's got a hip or a knee or a
shoulder or a catheter, andthey're used to writing those
physical product requirements.
But software is different.
how do people transition fromwriting those hardware to
(22:27):
software requirements?
Milton Yarberry (22:30):
Yeah.
mean, you know, I'm sorry tosay, but kind of poorly, you
know, they, uh, you know, it's,it's, it's, it's difficult.
I would, and I would just say,simply find somebody who,
whether you hire or go outsideyour organization, find somebody
who's done it before.
But even for the people who'vedone it before, if you get two
of those people in a room, thelikelihood for there to be.
(22:52):
Different processes andexpectations is, pretty close to
a hundred
Pat Kothe (22:56):
what are the differences between writing for
software versus hardware?
Milton Yarberry (22:59):
Software tends to be all functional,
particularly when you're writingspecifications around hardware,
electrical systems.
do you specify that it shall bea 19 watt transformer for the
power supply?
Or do you specify that thesystem shall not have brownouts
under any conditions?
So there's a little bit of, hey,how do you write a requirement
(23:20):
that doesn't overspecify yoursolution, specifies what you
actually want to go after as atest.
And that kind of abstractthinking, I find that, people
from the systems end of thespectrum are less familiar with.
And I think it's easier a littlebit on the functional side, the
behavior that you want the userto experience is all around the
user, right?
So there's a clearer chain onthat side.
(23:42):
But I think, um, well, you alsoend up with two different design
processes.
Software, it's very much, what'sa requirement, convert that to
specifications, convert that totasks.
Let's test it at the end of thesprint.
Hardware, you could, forexample, under, board
fabrication, have a whole, threemonths where there is, okay, we
(24:04):
have the schematic, we convertedit to a layout, we sent it out
for fabrication, we populated,we did the burn in test, and you
do all that to get to your firstdoes anything work at all or are
we in another hardware cyclespin?
So the time spans are justdisproportionate to the software
side.
You can't really keep them insync and you really need to have
an overall design plan thatsays, here's how requirements
(24:26):
are managed over here.
Here's how requirements matchover here.
And here are the touch points.
Pat Kothe (24:31):
So when a company comes to you and, and says,
we've got a, we're, we'reprimarily a hardware group.
We, we've got a idea for asoftware, software product.
How do you do that?
I mean, do you help them throughthat process of doing
requirements or are youexpecting them to deliver that?
How does that work?
Milton Yarberry (24:50):
I don't think I've ever, I have to think about
this.
Have I ever had customersactually deliver me?
even requirements that were like50 percent done, you know, I
mean, it's, and, and, and on theother hand, on, in the beginning
of the engagement, if you askthem, they'll say, do you have a
PRD product requirements?
And, I'd say 80 percent say,yes, we have that.
(25:11):
And then on the delivery side,it's okay, most of this doesn't
apply is done yet.
Let's just start over.
and that's where most of ourengagements, begin.
Even when they're really closeto finishing the implementation.
Pat Kothe (25:24):
Wow.
So why do you think that is?
Milton Yarberry (25:28):
That's a really deep multifaceted, question.
I think it's because, I thinkthere are solutions that could
be applied to it.
Like right now, if you thinkabout the process of how do I
define my product?
Okay, we know we have a productrequirements document.
We know we have some sketches.
We know we have conversations.
(25:48):
There's no place whereeverything lives.
And the formal documentation,the cycle time for that to get
reviewed and checked into yourdoc control system and then re
release to engineering.
So now you know what to build isso lengthy that it never gets
used.
So it's kind of like there's noone source where all the inputs
meet.
And then chiefly when, let'sjump forward to where you
(26:13):
actually have completed productrequirements and specifications.
Ask somebody to read one ofthose.
you get about half a page in ofvery carefully worded You know,
factors that you have to keep inyour mind before you're, you
forget what the first one wasthat you read.
So they're very difficult toconsume because they're all
text.
It's very dense.
(26:33):
It's very technical.
So what do you do about that?
This is one of the, reasons whyI'm at the company.
I'm at ICS is one of theproducts that we're, in the
process of creating is somethingthat pulls threads together like
that drives it through pictures,drives it through the user
interface layout, drives itthrough, state machine diagrams,
uh, swim lane diagrams, and thenallows references to your
(26:57):
requirements and specifications.
Pat Kothe (26:59):
Tell me a little bit about ICS, what you guys do,
what types of projects thatyou're involved with.
Milton Yarberry (27:04):
We're a software services business, been
around since, 1987.
and basically, what I like is wetry to solve axel wrapping
problems with noveltechnologies.
We have a couple of internalproducts, one called greenhouse,
which is a low code solution.
So it allows you to basicallydraw pictures for your UI and
(27:25):
then code comes out that givesyou an architecture front end to
back end.
we're developing the product Imentioned around defining your
product.
But otherwise we're a full stackembedded development.
chiefly we have a usability,dedicated usability group.
And we have a deep, you know,reserve of experience around Qt.
But otherwise, I mean, we'refront end and back end automated
(27:47):
testing, V and V testing, cloudconnectivity.
You know, it's kind ofeverything you would have for a
medical device.
Pat Kothe (27:52):
And you personally do the medical device side of
things, but the company doesother verticals as well, right?
Milton Yarberry (28:00):
Yes.
Yes.
Uh, More so it's, uh, medicaldevices sort of taken over.
We're medical devices aboutprobably about 70 percent of the
business we do, in the past,maybe two years, three years.
We also, have, I would say,roots and still ongoing work in
commercial sectors as well forlike automotive, industrial
machines, that sort of thing.
Pat Kothe (28:20):
So I want to focus a little bit now on the user side
of things.
When you go under the hood,there's analysis that needs to
be done, there's the hardcorefunctionality of the product,
but then there's the userinterface.
And within medical device, it,It could be a little bit
different than it is with, withyour phone or with a simple
(28:43):
device where it's all simple.
Sometimes our medical deviceshave multiple things that, you
know, complex issues that peopleneed to enter data in or
manipulate the device, with amore, complexity to it.
How do you guys approach.
UX when it comes to medicaldevice and balancing simplicity
(29:09):
with the needs of the product.
Milton Yarberry (29:11):
great question.
Um, so first of all, I would saythat there is a usability
standard out there, 62, 366,which is the core for us
applying usability to medicaldevices, it gives you a process
or a series of input that allowsyou to itemize and feel like
you've done a comprehensive jobof itemizing your use errors.
(29:36):
So not mistakes the user makesdefects in your device that the
user will step on.
There's that aspect and that'show we approach, designing it
and assuring that we're doingthe risk analysis right around
the user interface and that's,medical devices, safety and
efficacy.
That's, the risk analysis is apretty critical part of that,
and a primary motivator, butusability more broadly, it gets
(30:00):
used by many industries and itcan kind of mean, in my mind,
there's a dichotomy there.
There's the, it's a pleasure touse.
And then there's the does itmaintain safety and do you make
use errors.
And those two have some overlapdepending upon the device, a
little overlap, or a lot.
But there are clearly placeswhere they don't line up.
(30:21):
A pleasure to use advice meansthat maybe it doesn't annoy you,
uh, a medical device that'sgoing through an alarm, you want
to annoy you at the right time.
There's also concepts of alarmfatigue and, mitigation to that,
but there's a different,completely different set of
logic driving those two thingsand, When we're doing medical
(30:41):
devices, we tend to almost, 80percent focus on the safety
aspects over the, was it apleasing experience because, you
don't want that to ever trump,the former.
Pat Kothe (30:54):
My wife went to the dentist last week and she came
back and she was a little upset.
I said, what happened?
She said, I'm laying in thechair, the hygienist is, doing
whatever she's doing.
And then she's turning backaround and I hear something
being entered into a computer.
And then she's coming back in mymouth and I'm thinking, did she
(31:18):
just enter something with herfinger and now she's, you know,
on a keyboard, and now she'sgoing to go back in my mouth.
So when we think about,Software, sometimes it's
entering things in with a mouse,with a keyboard, but it can also
be voice, it can be gestures.
Tell me a little bit about wheresoftware as a medical device is
(31:41):
when it comes to some of theseother things so that somebody
like, like a hygienist is notgoing to be entering things in
on a keyboard.
Milton Yarberry (31:51):
Yeah, that's maybe, a confluence.
so how would that come up?
So first of all, what they'reentering, is probably not even
regulated software.
That's been my experience isthat hospitals and dentist
office, most of what's on theircomputers is, it's not software,
as a medical device, and it'sbecause they can't tie it to an
intended use and a clinicalfunction, so therefore patient
(32:13):
safety is never evaluated, whichis interesting.
I think, based upon what I'veseen, uh, around hospitals and,
the software used for thephysicians and, the nursing
staff.
I imagined in, choose yournumber X number of years that's
going to be regulated, it's justgoing to take a couple of bad
events for that software to saythat patient was treated with
(32:34):
this and they weren't.
For that to be, become an issue.
but, yeah, so basically I guessmy answer is yeah, it's not
regulated.
So,
Pat Kothe (32:44):
But are you dealing with things, with things like
gestures and, and, and, uh,voice, uh, voice activated
things when it comes to softwarethat you're involved with?
Milton Yarberry (32:54):
yeah, yeah, we've seen those, but I don't
feel like it's really ever takenoff.
They've always been sort of moreexperiments, toys, things that
go through formative study.
and I don't know why theyhaven't gained traction in a
more permanent way.
I almost feel like I saw more ofthat, three, four years ago than
(33:15):
today.
Pat Kothe (33:16):
Interesting.
Once you get through the userrequirements, and you have those
down, there's other things thathappen during that development
phase.
So what are some, some areaswhere you see, after user
requirements are locked in, andyou're going through
development, what slows thingsdown?
What makes, uh, you know, some,some sand in the gears??
Milton Yarberry (33:39):
Beyond the areas of, we didn't really
define the product and thatcauses ripples of change
throughout your system.
and those ripples, they canstart at, okay.
We, we had a release candidateand we were testing it and now
we have to do a formative study.
I've been in that scenario andinformative study means there's
a change and the change meansyou're going to go through V and
V again and blah, blah, blah.
So, um.
(34:01):
Things like having to repeatsummative, which typically ends
up being a fairly expensive,often external effort, that
those are big penalties,involved with that.
I think that a key area, as Imentioned, of course, is the,
getting everybody in agreementand aligned around what the
product is.
is a key area where it hurts theproduct all through all phases,
(34:26):
basically, including the testwriting at the end,
understanding, well, is that theway it's supposed to work?
Or, is it supposed to be a or Bor hasn't this not been thought
of yet?
And not having a place to checkthat.
So then that becomes meetingsthat becomes as opposed to, you
can look up the answer in a veryspecific location.
Another area is, yeah.
(34:46):
Especially around medicaldevices where there's a hardware
component is the hardware cycle,everybody knows, of course,
things got killed in COVIDbacklogs, out the door, 18 month
backlogs on some of ourprojects, waiting for hardware
to become available.
so simulators is, a key answerto that.
And,
Pat Kothe (35:06):
What do you mean, what do you mean by simulators?
Milton Yarberry (35:09):
Oh, something that, simulates, emulates,
hardware on your system andallows you to progress with,
development, testing, debugging,
Pat Kothe (35:18):
So even though the hardware isn't done yet, you're
simulating the effect of the
Milton Yarberry (35:23):
Decoupling basically your software and your
hardware programs withsimulators and emulators, yeah.
Pat Kothe (35:29):
Okay.
and then there's the oldmanagement injector, you know,
one more thing, can we just addthis in?
Milton Yarberry (35:39):
Yeah, now, now that, in fairness, I guess I
have to treat that I, I try tobalance all these, points
because I'm interested in rootcause.
And if you have late informationto the table and you're in
charge of a business and aproduct and your job is to bring
that product to market, are youdoing something wrong by
(35:59):
including that, no matter howlate?
It depends is the obviousanswer.
it depends on how much of that'sgoing to hurt you and is it
worth the cost and the risk.
So to those sort of problems,particularly where there, where
the information comes fromoutside the organization, I
guess a fair critique would be,we should have done better
research for that upfront.
And sometimes you do thatresearch and other times, I'd
(36:22):
say most of the time our clientsare so deep in their industry,
that it's difficult to sayyou've spent 25 years in your
industry, you've built four ofthese before you should do some
research.
Pat Kothe (36:33):
Yeah.
Yeah.
And sometimes when we'redeveloping a new product, we
won't.
There will be things that comeup when you go and take it back
out to the customer and say,this is where it is.
And the customer will say, well,if you did that, we can do this.
And, so there's, there is somelate information that comes to
the table that you may not havebeen able to anticipate.
Milton Yarberry (36:57):
Right.
But I think a lot of thatinformation, that type of
scenario, a one off comment latein the game, that's really
dangerous bait, to go after.
You, you have to assume that,there are all these
psychological factors around ourcustomers.
They didn't know they wanted anautomobile because they only had
a horse and carriage.
(37:18):
Those sort of factors.
So you have to figure out whereyou're leading the customer, and
really what's a valid input.
So that should be an entireprocess of vetting and
justification.
Pat Kothe (37:28):
Let's talk a little bit about updates because, you
can enter in with the productthat you want, but if somebody
comes in and says, there's somebait out there and it's actually
strong bait that could be used,but you don't want to slow down
or stop your development programor product launch, but you think
that this is a valid idea.
(37:48):
Now you've got version two that,it could be implemented in.
Let's talk a little bit aboutwhat regulatory bodies are
saying about updates to softwareand how that should be built
into the regulatory filing.
Milton Yarberry (38:06):
Happens in startups a lot.
You work like crazy in order toget the product out the door and
then you finally get itsubmitted.
And then there's a gap betweenthe beginning of the submission
process and then kind of a slowtrickle based upon every time
the FDA comes back to you withcomments.
Maybe you tweak something hereor there and that gives your
entire engineering team, whichwas killing itself, a month ago,
(38:28):
now they have almost no work andthat no work can go for several
months.
So there is sort of a fastfollow release, that is, thought
of, okay, we got our, ourprimary version out the door
that we're going to submit with.
We should consider which changeswe want to fast follow with.
We should consider whatregulatory steps we have to go
(38:48):
to because of those changes, andit could be something as simple
as a letter to file, which islike no FDA interaction, at
least immediately, and then, toa supplemental submission.
There's a lot of leeway and alot of flex in terms of what the
right answer is.
It's very situation
Pat Kothe (39:05):
Yeah, and, and it's something, uh, say it's an
algorithm and you've got machinelearning or some AI in there and
you're going to update thatportion of that.
You may not update the fullpiece of software, but it could
be part of the analysis enginebecause you've got learning
that's occurring real time.
That's another, anothersituation.
Milton Yarberry (39:27):
Yeah, the whole machine learning aspect.
mean, there's a lot of pieces tothat.
there's even the notion that,you as a manufacturer now are
responsible for, curation.
You know, so the data youtrained it on is now kind of,
especially once you've releasedthat, that's a golden fixed set
and which examples you choose toinclude or remove, in a sense,
(39:47):
need to be understood well andjustified.
Why did you include these foursamples and why do you remove
those 200?
But the FDA has, um, publishedexpectations around this for
people that want a shorter pathto being able to update their,
um, They're neural network ortheir machine learning, but most
of that comes down to, uh, youhave expectations for where
(40:09):
you're going to seeimprovements.
And when you have expectationsconsistent with that, then you
have a shortcut.
Otherwise you're kind of in thesame boat of needing to resubmit
or evaluate the level of thechange.
Pat Kothe (40:22):
So when you get um, these changes, um, in your, in
your, uh, uh, developmentprogram, what is the best way to
manage the change process?
Do you have tools that youutilize or methodologies that
you utilize that says, a changeis coming in, now how do we
evaluate the impact of thatchange?
Milton Yarberry (40:44):
Yeah, so there's kind of like two sides
of that fence.
There's a sense before youactually have a formal release.
In which case, changes aren't asformal, aren't as, overhead
burdened.
until the design is quotecomplete, it's not actually a
change.
You are in the process ofdesigning.
As soon as you have a versionthat goes over to your V&V group
or makes it out of your V&Vgroup at that point, now you're
(41:07):
talking about changing yourdesign.
And that requires a formalprocess, particularly where you
take a look at any risk you'reintroducing with your changes.
Pat Kothe (41:15):
The PATCH Act deals with, um, with devices going
forward, but we have a lot ofdevices that are out in the
field right now.
pacemakers that are out there,that, they're inpatients,
they've been in for a while.
We've got, other types of thingsthat were, put out last month,
that, that didn't, didn't, uh,uh, contemplate or weren't as
(41:37):
robust when it comes to these,uh, issues with cybersecurity.
What is the agency and whatdoes, the industry have to do
from a responsibility standpointfrom these systems that are
already out there?
Milton Yarberry (41:54):
I've seen nothing of like, uh, either the
term grandfathering or the needfor anything that's already
deployed to change, at least notin the U S In the EU.
It's a different story.
But, anything that's beenreleased in the past, what since
2018 those devices have probablytaken a look at the guidance and
I think we're past the dayswhere hopefully, anybody is
(42:16):
putting out something with, theydidn't change the root password
and they didn't, they didn't doall the obvious things, So
there's doing the obvious goodhousekeeping, use passwords, use
of, uh, sufficiently, uh,sophisticated encryption, have a
software update process, uh,that, uh, is protected.
Secure boot.
You know, all these things aretable stakes.
(42:40):
But a lot of the threatmodeling, for example, goes
beyond the table stakes.
It's looking at, did you reallyscrub your network to see where
you were vulnerable and how, andtell us explicitly which things
you were, you considered throughyour documentation.
It's almost like a zero dayattack, thinking, rather than
(43:01):
lock the doors, lock thewindows, turn on the burglar
alarm.
Pat Kothe (43:05):
So we're fortunate that, uh, going forward, a lot
of these things are beingcontemplated and built into
systems.
We still have some risk withsome of the legacy systems that
are out there.
The further out we get, thebetter we're all going to be.
But there's still some risk forproducts that were manufactured
previously.
Milton Yarberry (43:23):
Yeah, fortunately, the really old
stuff where, they probablydidn't look at any of the
guidance.
is probably not verycommunication enabled.
So pacemakers, for example, Iknow there are a few cases
where, there have been someglaring problems, but, those
problems have been identified.
Others, are addressing them ifthey had them.
at this point, I don't see a bigremediation wave, like sweeping
(43:45):
through those products, or atleast I don't see the motive for
that yet.
Pat Kothe (43:48):
Yeah, and there's risk reward there too, because,
if it's a, an, implantedproduct, there's risk in taking
that out, so you have to balancethe risk between what's a cyber
security risk versus what's themedical risk for another
procedure.
Milton Yarberry (44:02):
Absolutely.
Absolutely.
The rollout can, yeah, literallykill you.
Pat Kothe (44:06):
Yeah, yeah.
Well, this has really been afascinating discussion and
dealing with a very timely issueand one that, that most medical
device companies are wrestlingwith, that will be wrestling
with because even, simplehardware products can, often be,
augmented with, with a software,software product alongside it.
So thanks for leading us, uh,kind of, uh, on the discussion.
(44:30):
As companies are becoming moresoftware oriented, what do you
see as some things that theyshould be considering as they
make that transition from onlyhardware to having software as
well?
Milton Yarberry (44:46):
well, well, I think the industry is taking
care of that in a sense, youknow, I'd say like the last few
companies I've worked with, it'srare to meet, a mechanical
engineer that's just, doesn'tknow scripting of some sort.
As, uh, uh, the kids are comingout of school and going into
industry, they have themultidiscipline, You find fewer
purists these days and, uh, youknow, that basically the system
(45:10):
will just sort of age in thatdirection so that people are
more system capable rather thanjust in a particular domain
capable.
Pat Kothe (45:17):
When I think of project development or product
development, the marketingpeople are also people that are
interfacing with the customersand translating customer needs
into user requirements.
And, If they're used to beinghardware people, even though the
development people may besoftware people, the marketing
people may not be.
(45:37):
And that, that, that's an areathat I think should probably be
beefed up as well.
Milton Yarberry (45:43):
Although as soon as you're going as far out
as marketing, which, you know,from, uh, I used to be an
engineer and, and, and, uh, youknow, interested in engineering
and the architecture, uh,heavily.
Product marketing is about asfar away in terms of
expectation.
So I think there's already a lotof, support structures uh, you
(46:03):
know, in people's heads and inpeople's processes to, Bob said,
he wants it to be easy.
Okay.
Now we know we got to break thatdown with a formative study.
We know that we have to write ause case, get Bob into use
cases.
and then let's map requirementsto the use case.
We're used to when dealing with,you know, um, business owners,
(46:23):
product owners, marketing, um,to assisting in the conversion
to something concrete andtestable.
Pat Kothe (46:33):
Software is here to stay, and software regulations
are too.
As we grow the types of productswe offer, we need to keep our
North Stars of safety andefficacy front and center.
A few of my takeaways.
First, stay on top of regulatorychanges.
(46:56):
Not just what is here now, butwhat's coming.
Because it will impact yourtimeline.
And it will impact yourdevelopment plan.
And it will impact the costsassociated with your development
plan.
If you need to involve anexpert, seek out someone like
(47:17):
Milton.
It's going to pay off.
Secondly, user requirements.
We had a nice discussion on userrequirements, and we're familiar
with that, uh, with hardware,requirements for, medical
devices, but we may not have aclue what best practices are
with software.
(47:38):
So, find an in house expert.
If you have them and have themrun it, if you don't have one,
bring someone in from theoutside.
Again, your timeline and yourcosts are going to be at risk if
you cut corners in this area.
Finally, changes will occur.
(47:59):
No project goes according toplan in what you did with your
user requirements right upfront.
So try and do the best you canto define the product up front,
but then recognize that changeswill come.
And then you have to manage theproject.
You'll have to make decisionsbased on customer feedback,
(48:23):
timing, launch windows,competitive products, regulatory
issues, and managementexpectations.
So understand up front thatchanges are coming.
And what you need to do isdevelop a management system to
be able to handle those changesefficiently.
(48:46):
Thank you for listening.
Make sure you get episodesdownloaded to your device
automatically by liking orsubscribing to the Mastering
Medical Device podcast whereveryou get your podcasts.
Also, please spread the word andtell a friend or two to listen
to the Mastering Medical Devicepodcast as interviews like
today's can help you become amore effective medical device
leader.
(49:06):
Work hard, be kind.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!