WEBVTT
1
00:00:04.240 --> 00:00:12.669
And so FDA's providing this framework to
allow for a computer software validation process that
2
00:00:12.869 --> 00:00:21.070
is worst based and will provide for
more testing and potentially less documentation of systems
3
00:00:21.500 --> 00:00:28.660
in order to promote automation use in
the manufacturing of medical devices, pharmaceuticals and
4
00:00:29.260 --> 00:00:44.890
biologics. Welcome to life sciences accelerated, a podcast where we discuss experiences and
5
00:00:45.009 --> 00:00:50.880
groundbreaking innovations in compliance and technology,
from molecule to market. Tune in for
6
00:00:51.039 --> 00:00:57.479
in depth interviews with wellknown thought leaders
and renown subject matter experts with unparalleled knowledge
7
00:00:57.759 --> 00:01:03.079
in the technology and life sciences industry. Innovative, helpful and thought provoking.
8
00:01:03.399 --> 00:01:10.950
This is life sciences accelerated. Hi
Everyone, welcome to the life science is
9
00:01:11.030 --> 00:01:15.109
accelerated podcast. I'm your host,
Ryan Carmel, and today we're talking about
10
00:01:15.230 --> 00:01:21.420
computer system validation. There's a lot
of discussion in the life sciences industry about
11
00:01:21.459 --> 00:01:26.980
the FDA changing focus from compliance to
quality and encouraging the use of automation and
12
00:01:27.099 --> 00:01:33.849
new technologies. The FDA Center for
devices and radiological health plans to release new
13
00:01:34.170 --> 00:01:41.170
draft guidance later this year called computer
software assurance. It's for manufacturing operations and
14
00:01:41.329 --> 00:01:46.250
quality system software. This impending guidance
is creating a lot of buzz, so
15
00:01:46.409 --> 00:01:52.040
we decided this would make a fantastic
first discussion in our brand new podcast.
16
00:01:52.480 --> 00:01:56.040
So today I have Dianne lines are
with me. Diane is the VP of
17
00:01:56.120 --> 00:02:00.510
life science solutions and head of regulatory
compliance at US dum life sciences. Diane
18
00:02:00.549 --> 00:02:06.230
has three decades of experience in the
life sciences industry and leads a highly skilled
19
00:02:06.269 --> 00:02:10.189
team of implementation and compliance engineers.
I also have sandy hedbird, who is
20
00:02:10.310 --> 00:02:15.740
the QA and ur a manager for
US DM's cloud assurance division. See,
21
00:02:15.740 --> 00:02:20.259
and he has over twenty years of
experience and quality and regulatory affairs and the
22
00:02:20.340 --> 00:02:24.139
medical device, pharmaceutical and biologics industries. So thank you both for joining us
23
00:02:24.219 --> 00:02:29.300
for our first official PODCAST. All
right, so before we jump into the
24
00:02:29.379 --> 00:02:32.650
new guidance, Diane, can you
give us a quick history lesson on computer
25
00:02:32.729 --> 00:02:38.330
system validation, what it is and
how it's evolved over time? Sure,
26
00:02:38.449 --> 00:02:45.240
Ryan, computer system validation really just
means to show written evidence that the computer
27
00:02:45.439 --> 00:02:50.360
system that you're using to generate or
modify any record is required by the predicate
28
00:02:50.439 --> 00:02:54.280
rules, and the predicate rules are
things like part hundred twenty four medical device
29
00:02:54.479 --> 00:03:00.750
to tend to eleven, among others, for Pharmaceuticals and x eleven. There's
30
00:03:00.750 --> 00:03:05.629
a whole boatload of require regulations out
there, but that any records that you're
31
00:03:05.710 --> 00:03:09.349
generating are modifying that are required by
those predicate rules. Works for its intended
32
00:03:09.430 --> 00:03:13.780
use. It works the way you
wanted it to work. The goal of
33
00:03:13.819 --> 00:03:20.900
the computer system validation is to ensure
that your consistently producing accurate, reliable results.
34
00:03:21.419 --> 00:03:27.569
Historically, best practices of dictated.
The activities that occur during that are
35
00:03:27.810 --> 00:03:32.810
things like planning activities, documenting what
you're planning to do, documenting your requirements,
36
00:03:34.210 --> 00:03:38.610
the functionality of the system necessary to
meet those requirements, traceability of those
37
00:03:38.650 --> 00:03:45.159
requirements to where you've tested it,
verification that the systems installed and configured properly,
38
00:03:45.840 --> 00:03:50.719
system functionality required to meet your user
needs works the way that you expect
39
00:03:50.719 --> 00:03:54.949
it to work and that the system
performs according to the user requirements. And
40
00:03:55.110 --> 00:04:00.229
then there's a report generated at the
end that summarizes the effort, noting any
41
00:04:00.310 --> 00:04:04.909
constraints or restrictions on the system,
andy deviations that you encountered during the validation
42
00:04:05.110 --> 00:04:11.139
effort and a statement that the system
meets its intended use or not. Based
43
00:04:11.180 --> 00:04:14.740
on the evidence. HMM, okay, and then, Sandy, I'll ask
44
00:04:14.780 --> 00:04:18.139
you. So why is the FDA
making this change then? Well, FDA
45
00:04:18.300 --> 00:04:26.250
is trying to urge manufacturers to utilize
automation and their manufacturing process and their qms
46
00:04:26.329 --> 00:04:32.569
processes, because they've noted in other
industries that those industries have better product safety
47
00:04:33.250 --> 00:04:39.600
and quality of those products. So
they're trying to find a way to get
48
00:04:39.720 --> 00:04:46.639
industry to buy into more automation.
One of the driving factors associated with not
49
00:04:46.839 --> 00:04:51.000
doing that in the industry is that
everybody thinks it's too expensive because of all
50
00:04:51.040 --> 00:04:57.629
the validation effort that's required. Now, the validation requirements are part of a
51
00:04:57.670 --> 00:05:04.149
guidance document that's over twenty years o
old and there's oftentimes people over test because
52
00:05:04.750 --> 00:05:11.699
they believe there's there could be regulatory
punishment and instead of doing the right thing
53
00:05:11.819 --> 00:05:16.100
from a risk based approach in order
to get good quality and good quality products,
54
00:05:16.540 --> 00:05:21.689
they focus on the testing instead of
focusing on or they focus on driving
55
00:05:23.050 --> 00:05:29.529
documentation instead of focusing on the testing. And so FDA's providing this framework to
56
00:05:30.490 --> 00:05:38.800
allow for a computer software validation process
that is risk based and will provide for
57
00:05:39.519 --> 00:05:45.759
more testing and potentially less documentation of
systems in order to promote automation use in
58
00:05:46.160 --> 00:05:54.550
the manufacturing of medical devices, pharmaceuticals
and biologics. For people that are tuning
59
00:05:54.589 --> 00:05:59.189
into this, and and maybe they're
they've heard of the CSA a little bit,
60
00:05:59.430 --> 00:06:02.189
but dig into the weeds a little
bit for a Sandy. What is
61
00:06:02.389 --> 00:06:08.779
this exactly and how would you compare
it to more of a traditional CSV approach?
62
00:06:09.379 --> 00:06:13.860
Sure, it's very similar to a
CSV approach. It's utilizing a risk
63
00:06:13.899 --> 00:06:18.970
based approach that has always been acceptable
by FDA. What is foundation is is
64
00:06:19.649 --> 00:06:26.850
utilizing your supplier qualification and what your
suppliers are already doing in order to take
65
00:06:26.970 --> 00:06:33.319
credit for that and have that drive
your downstream testing and to make sure that
66
00:06:34.079 --> 00:06:42.360
there are alternate approaches from the fdah
perspective to lessen the documentation and providing more
67
00:06:42.399 --> 00:06:53.069
emphasis on testing, less emphasis on
documentation and providing for a better software validation
68
00:06:53.350 --> 00:06:59.750
process to ensure that your system meets
your intended use and it allows you to
69
00:07:00.829 --> 00:07:06.180
for the level of risk of those
sitting with that product, leverage and utilize
70
00:07:06.339 --> 00:07:13.060
different versions or different types of documentation, from ad hoc documentation all the way
71
00:07:13.100 --> 00:07:19.009
through your robrusscripted testing that we do
today for your documentation purposes for these types
72
00:07:19.050 --> 00:07:26.769
of systems, from a lowers perspective
to a Highris perspective. Mm and what
73
00:07:26.970 --> 00:07:30.120
types of life sciences companies can take
advantage of this approach. I think there
74
00:07:30.160 --> 00:07:35.839
are some misconceptions. I've heard some
rumblings that this is something that really only
75
00:07:35.839 --> 00:07:39.519
the medical device community can take advantage
of it. I think that, in
76
00:07:39.639 --> 00:07:45.709
particular comes from the fact that this
guidance is coming from the the medical device
77
00:07:46.189 --> 00:07:48.509
side of the House within the FDA. But there are some misconceptions there.
78
00:07:48.670 --> 00:07:53.709
Is that not true? Diane?
That is true that there are misconceptions.
79
00:07:53.990 --> 00:07:58.819
CDA are a ris to the group
who are working in producing this new draft
80
00:07:58.860 --> 00:08:03.500
guidance and at one point there may
have been an intention that it would start
81
00:08:03.540 --> 00:08:07.459
with medical devices and then move out
towards some of the other industries. But
82
00:08:09.139 --> 00:08:15.730
really this approach is acceptable today across
the board. So even though the CDR
83
00:08:16.050 --> 00:08:20.370
CD R H is the group that's
putting the guidance out there, working hand
84
00:08:20.449 --> 00:08:26.170
in hand, cooperating with the biologics
evaluation division, this drug evaluation and research
85
00:08:26.290 --> 00:08:30.800
division, and not just with FDA
divisions, but they're working with the EU
86
00:08:31.040 --> 00:08:35.559
they're working with Japan other regulatory bodies. So really, if you look at
87
00:08:35.559 --> 00:08:41.830
the ISO regulations, if you look
at Gamp guidances, these are all very
88
00:08:41.029 --> 00:08:48.110
consistent with the approach that's being defined
by the CDRH. So there's really no
89
00:08:48.870 --> 00:08:54.909
need for the pharmaceutical industry or the
biological biologics industries to not take advantage of
90
00:08:54.029 --> 00:08:58.740
a more streamlined and effective approach right
away. Don't even have to wait for
91
00:08:58.779 --> 00:09:03.100
the regulation to come out. It
can be implemented today as long as you
92
00:09:03.179 --> 00:09:07.299
update your processes and procedures internally.
So start doing it now. You don't
93
00:09:07.299 --> 00:09:11.169
have to wait. Yeah, and
for these companies that are listening, that
94
00:09:11.250 --> 00:09:16.009
are that are saying, Hey,
we're already doing this risk based validation approach,
95
00:09:16.129 --> 00:09:20.129
what do you say to them about
how to take advantage of the CSA
96
00:09:20.210 --> 00:09:24.720
approach? See, and you'll ask
you this. Yeah, yeah, using
97
00:09:24.840 --> 00:09:30.120
rostpace approach is really nothing new.
It's been promoted by FDA, gamp and
98
00:09:30.279 --> 00:09:35.320
other agencies for a long time.
The basic type of change that we're seeing
99
00:09:35.360 --> 00:09:41.870
here is that the FDA is providing
a framework in order to ensure that your
100
00:09:41.950 --> 00:09:46.590
testing activities are consistent with that risk
based approach. So for example, if
101
00:09:46.629 --> 00:09:54.220
I have an indirect QM sistem like
a campus system, that is needing a
102
00:09:54.700 --> 00:10:00.100
new validation, than you would be
allowed to potentially just do an ad hoc
103
00:10:00.419 --> 00:10:03.860
testing or you document what you tested
in the system, who did it,
104
00:10:03.379 --> 00:10:09.090
the dates that tested and sign off
of it and go. And so the
105
00:10:09.850 --> 00:10:18.009
clarification in this approach is really to
flip the focus on testing everything to testing
106
00:10:18.129 --> 00:10:22.360
what you need to test. So
instead of doing a twenty percent testing and
107
00:10:22.480 --> 00:10:26.399
eighty percent documentation, the feaims to
flip that so you do eighty percent testing
108
00:10:26.600 --> 00:10:33.679
and only twenty percent documentation. So
in doing less documentation you have more time
109
00:10:33.919 --> 00:10:39.830
to be able to do ad hoc
testing that will provide you assurance that that
110
00:10:39.950 --> 00:10:43.190
system works in your environment and you're
intended use and and they've had done some
111
00:10:43.350 --> 00:10:50.139
pilots with some companies where it they
they found that the one you want live
112
00:10:50.259 --> 00:10:54.059
and implementation of these systems. There
were less issues at that point in time
113
00:10:54.139 --> 00:10:58.460
because you did more of the upfront
work than you would have normally done in
114
00:10:58.700 --> 00:11:03.450
just doing a noncsa approach, because
you had more time to test and you
115
00:11:03.649 --> 00:11:11.690
spent less time writing test scripts.
You earlier, Sandy, you mentioned non
116
00:11:11.049 --> 00:11:16.210
products quality systems. Can you talk
more about that? Right? Right.
117
00:11:16.330 --> 00:11:22.480
So this this guidance is not intended
for medical device manufacturing products like medical devices,
118
00:11:22.639 --> 00:11:26.240
medical devices as services or in products
that are used in the medical device
119
00:11:26.279 --> 00:11:31.120
industry. This is really just for
those types of systems that are used in
120
00:11:31.240 --> 00:11:37.870
manufacturing, in the Quality Manu management
system where you have indirect or potentially direct
121
00:11:37.950 --> 00:11:43.429
impact to patient safety, product quality
and those types of things. So most
122
00:11:43.470 --> 00:11:46.500
of the time you're your quality management
system software are going to be indirect systems
123
00:11:48.259 --> 00:11:50.059
where you're not going to have a
direct impact on the product, like your
124
00:11:50.860 --> 00:11:56.419
complaint handling systems, your csfeed Type
Process Systems, like bug tracking systems,
125
00:11:56.419 --> 00:12:01.009
your tools, load testing tools,
life management tools, so life cycle management
126
00:12:01.049 --> 00:12:07.450
tools. They don't directly impact the
product. So those types of systems require
127
00:12:07.529 --> 00:12:11.889
less documentation, but remember you want
to make sure you do more testing but
128
00:12:11.970 --> 00:12:16.399
less documentation. Those systems that more
have more of a direct impact on the
129
00:12:16.440 --> 00:12:20.679
patient safety of the product quality,
like if you had any electronic adverse event
130
00:12:20.840 --> 00:12:24.919
reporting system that would report directly to
FDA. Those types of systems are going
131
00:12:24.919 --> 00:12:31.870
to require more documentation and probably increased
testing based on their risk and the impact
132
00:12:31.950 --> 00:12:35.710
on the end product. So in
those particular cases you're going to have more
133
00:12:35.789 --> 00:12:41.429
testing and the documentation. In the
other types of the direct systems you're going
134
00:12:41.429 --> 00:12:45.220
to have less documentation but more testing
because you're going to be able to do
135
00:12:45.379 --> 00:12:48.460
more testing in the time, the
same time that it would take you to
136
00:12:48.500 --> 00:12:52.100
do all the documentation that you used
to do. You want to do more
137
00:12:52.179 --> 00:12:54.940
testing, you want to make sure
that it's done in a manner consistent with
138
00:12:54.980 --> 00:13:01.250
with the users use of the system
and that way you won't have as many
139
00:13:01.370 --> 00:13:05.809
problems when you when you go live. Uh Huh. And what feedbacks and
140
00:13:05.929 --> 00:13:11.450
you are you hearing from the life
sciences community about this upcoming guidance? I'm
141
00:13:11.529 --> 00:13:15.960
hearing some concerns that people don't want
to implement this until the guidance document comes
142
00:13:16.000 --> 00:13:20.159
out, which FDA has been adamant
that this type of approach and this framework
143
00:13:20.200 --> 00:13:26.919
that they're proposing is acceptable to FTA
today and does not need to what you
144
00:13:26.960 --> 00:13:31.110
don't need to wait till the guidance
document comes out. I've also heard where
145
00:13:31.429 --> 00:13:35.269
customers are saying, well, we
already use a respace approach. We've seen
146
00:13:35.350 --> 00:13:39.590
that at a lot of places where
they say they're using over space approach,
147
00:13:39.669 --> 00:13:43.059
but in reality they're still testing everything
and they're still testing them to the about
148
00:13:43.100 --> 00:13:50.779
the same rigor as as they would
in a regular CSV type approach. The
149
00:13:50.899 --> 00:13:54.419
problem that that most people have is, if I have a good vendor that's
150
00:13:54.460 --> 00:13:58.250
been around a long time, do
I really need it to do testing on
151
00:13:58.330 --> 00:14:01.929
my log in capabilities, because they
probably already tested it to the nth degree
152
00:14:01.009 --> 00:14:05.610
at the vendor and if you already
know that, why are you your time
153
00:14:05.850 --> 00:14:09.399
on that test? Go on to
something else that would be more related to
154
00:14:09.480 --> 00:14:13.440
your use case or how the users
use the system in in order to identify
155
00:14:13.480 --> 00:14:18.600
any issues up front before you go
live in that production environment and then have
156
00:14:18.720 --> 00:14:22.559
an issue. I think Diane has
a couple concerns that she's heard and actually
157
00:14:22.600 --> 00:14:26.870
non concerns that she's heard from some
from some clients as well. Yeah,
158
00:14:26.870 --> 00:14:31.029
I think you know, I'm hearing
a lot of excitement in the industry about
159
00:14:31.029 --> 00:14:37.750
the potential for not having to do
so much documentation. There's there's certainly a
160
00:14:37.950 --> 00:14:41.740
great deal of interest and how that
might look what that looks like. Certainly
161
00:14:41.779 --> 00:14:46.700
all the poor people who've been doing
testing for so long and printed out thousands
162
00:14:46.740 --> 00:14:50.740
of screenshots are are really pretty excited
about the fact that you don't need to
163
00:14:50.980 --> 00:14:56.809
show so much objective evidence, just
really where it counts, where you really
164
00:14:56.889 --> 00:15:00.889
really need it. You know,
you don't need screenshots for everything anymore and
165
00:15:01.049 --> 00:15:05.690
that's a lot of time and effort
saved over the over the course of a
166
00:15:05.730 --> 00:15:11.720
validation or several validation events. I've
heard a couple of customers concerned what would
167
00:15:11.720 --> 00:15:18.519
happen in an inspection situation? Will
the new inspectors be trained to know what
168
00:15:18.679 --> 00:15:24.669
this approach is? Really an inspector
looks at what your approach is, what
169
00:15:24.830 --> 00:15:31.389
your computer system validation process is,
and they inspect to that process, and
170
00:15:31.870 --> 00:15:35.139
so that really minimizes a concern.
I will say that I've seen a few
171
00:15:35.179 --> 00:15:41.820
instances where someone's used a different approach
than gamp. There's nothing wrong with that
172
00:15:41.100 --> 00:15:46.379
and if an inspector is not familiar
with the approach you're using, it could
173
00:15:46.419 --> 00:15:50.809
lengthen the time of inspection and that
makes people nervous. But it shouldn't because
174
00:15:50.850 --> 00:15:54.970
you're doing the right thing if you've
documented what you're going to do and it's
175
00:15:54.009 --> 00:15:58.570
been approved across the board by the
right people, and then you're doing what
176
00:15:58.649 --> 00:16:02.889
you said you were going to do, then that's what they're going to hold
177
00:16:02.889 --> 00:16:07.000
you too. So I think that
that concern is probably not as great as
178
00:16:07.039 --> 00:16:12.519
some people fear. I've also heard
some concerns that their quality people won't accept
179
00:16:12.519 --> 00:16:17.559
the new approach, and that could
well be. It's a matter of quality
180
00:16:17.600 --> 00:16:22.389
people understanding what the approach is,
how it's done, how it's executed and
181
00:16:22.669 --> 00:16:30.350
why it's a better approach. I
would imagine some of these large legacy life
182
00:16:30.429 --> 00:16:34.539
sciences companies that have well established processes
for CSV. I'm going to take a
183
00:16:34.620 --> 00:16:38.299
guess here and say that this is
going to be a little bit more of
184
00:16:38.379 --> 00:16:42.179
an obstacle or more of a challenge
to to get some of these companies to
185
00:16:42.539 --> 00:16:47.970
get on board with this approach.
What do you say to those types of
186
00:16:48.049 --> 00:16:52.610
companies? I would say that a
lot of our bigger customers are embracing this
187
00:16:52.730 --> 00:16:57.289
approach and excited about trying to put
it in place. You're right, it's
188
00:16:57.330 --> 00:17:02.919
like moving a mountain sometimes. Yeah, but the bigger companies are the ones
189
00:17:02.919 --> 00:17:06.559
who are going to benefit from this
approach the most. There is a real
190
00:17:06.799 --> 00:17:11.519
savings in terms of time and resources
necessary. Validation's always been thought of as
191
00:17:11.519 --> 00:17:15.789
a ball and chain that hangs on
the end of a validation effort and drags
192
00:17:15.829 --> 00:17:19.150
it backwards and pulls that timeline out
because it doesn't get started till the end.
193
00:17:19.630 --> 00:17:25.750
It just delays implementation of a system
and that shouldn't be what it is.
194
00:17:25.910 --> 00:17:30.619
It should be an efficient, effective
test that says yes, my system
195
00:17:30.660 --> 00:17:33.940
is ready to put out there on
the floor and to be used by everybody.
196
00:17:33.500 --> 00:17:37.579
So, for our larger customers,
they're looking at things like using a
197
00:17:37.700 --> 00:17:42.660
pilot study so that they can help
to convince quality and it and other teams
198
00:17:44.099 --> 00:17:47.849
that this approach will work. So
try it on one system or group of
199
00:17:47.930 --> 00:17:52.170
systems first and measure your results,
especially systems that you already have validation results
200
00:17:52.289 --> 00:17:56.809
on, see how it's different and
if that pilot works, then you can
201
00:17:56.930 --> 00:18:00.960
start expanding it out to other systems. I think it's important to make sure
202
00:18:00.039 --> 00:18:06.119
everybody's on board before you just change
your methodology. But I think it's also
203
00:18:06.279 --> 00:18:10.160
important to your company, Your Corporation. You can do more work and less
204
00:18:10.240 --> 00:18:15.069
time better, more effective systems out
for people to use. You're going to
205
00:18:15.150 --> 00:18:19.630
produce better data, you'll have better
data integrity and ultimately you're going to still
206
00:18:19.630 --> 00:18:23.869
save time and money in doing this. MMM, and what do you say
207
00:18:25.029 --> 00:18:27.700
to the folks that are part of
some of these smaller companies, you know,
208
00:18:27.819 --> 00:18:30.900
a start up or an emerging life
sciences company? Is it? Is
209
00:18:30.980 --> 00:18:34.819
the message the same or is it
sort of a different are the selling points
210
00:18:34.859 --> 00:18:37.220
a little bit different? Well,
I would say the selling points are a
211
00:18:37.259 --> 00:18:41.369
little bit different because they don't have
established methodologies. In most cases, where
212
00:18:41.369 --> 00:18:45.089
you have an established methodology and a
group of people who are used to doing
213
00:18:45.210 --> 00:18:48.809
things a certain way, you got
to change your culture a little bit.
214
00:18:49.049 --> 00:18:53.930
But with these smaller companies, who
don't have processes in place already for validation
215
00:18:55.130 --> 00:18:57.720
efforts, they can start with this
right away. There's there's no need to
216
00:18:57.839 --> 00:19:03.440
start with a fullblown effort. That's
often expensive and time consuming and resource consuming
217
00:19:03.880 --> 00:19:07.680
when you don't have a lot of
resources on hand to do it. So
218
00:19:08.079 --> 00:19:11.670
saving time and money, can start
right from the beginning for them. Yeah,
219
00:19:11.710 --> 00:19:15.390
that makes sense. Well, before
we run out of time here,
220
00:19:15.670 --> 00:19:19.789
Sandy, any other thoughts on this
CSA approach? I I know it's probably
221
00:19:19.990 --> 00:19:25.019
not new. I think pretty much
everybody has heard about it by now.
222
00:19:25.660 --> 00:19:29.259
Is that fair to say? Yeah, this, this is not the guidance
223
00:19:29.299 --> 00:19:32.940
itself as new, but the approach
isn't that new. It is just a
224
00:19:33.059 --> 00:19:37.849
new framework that FDA has been promoting
in order to get us Awf of doing
225
00:19:38.049 --> 00:19:44.009
our our screenshots and our test,
you know, stuff by set test cases
226
00:19:44.009 --> 00:19:47.930
all the time for those types of
systems that are that have an indirect impact
227
00:19:48.049 --> 00:19:52.440
on manufacturing or quality. It's allowing
us to do more testing and less documentation
228
00:19:53.279 --> 00:19:59.640
and hopefully, based on your critical
thinking and your wrist based approach, you
229
00:19:59.759 --> 00:20:03.920
can get more bang for your book
and you're doing a better job of testing
230
00:20:03.960 --> 00:20:08.230
and concentrating on those things that are
really critical to that application. Yeah,
231
00:20:08.390 --> 00:20:12.230
okay, and Diane, anything else
from you? I know we've heard a
232
00:20:12.269 --> 00:20:18.069
lot about screen shots these days,
even in the context of CSA. Are
233
00:20:18.150 --> 00:20:22.299
Those those a thing of the past? They they won't ever be a thing
234
00:20:22.380 --> 00:20:26.140
of the past, I don't think, because they do have their value.
235
00:20:26.819 --> 00:20:32.539
But I see a lot of people
so concerned about not having the right objective
236
00:20:32.579 --> 00:20:37.490
evidence that they lose sight of what
the right objective evidence is. It doesn't
237
00:20:37.529 --> 00:20:41.329
have to be a screen shot and
you don't need a screenshot at every step.
238
00:20:41.809 --> 00:20:45.769
Use them where they're really meaningful,
so you're showing that that something works,
239
00:20:45.890 --> 00:20:52.200
that isn't obvious otherwise and understand this
is applicable now. You don't have
240
00:20:52.319 --> 00:20:56.880
to wait for the guidance to come
out. The methodology is firm. It's
241
00:20:56.920 --> 00:21:00.640
up to you to establish as a
company what your level of risk aversion is
242
00:21:00.240 --> 00:21:06.789
and to leverage that level in your
testing and documentation. Yeah, all right.
243
00:21:07.509 --> 00:21:10.990
Well, Sandy and Diane, thank
you so much for joining us today.
244
00:21:11.470 --> 00:21:15.829
We hope you enjoyed this first episode
of life sciences accelerated. We have
245
00:21:15.910 --> 00:21:18.180
a lot more resources available to you
on our website. You can head to
246
00:21:18.180 --> 00:21:22.940
us dmcom. We've got Webinar as, we've got blogs. I've got white
247
00:21:22.940 --> 00:21:26.059
papers on all sorts of life sciences
subjects, including the one that we talked
248
00:21:26.059 --> 00:21:33.170
about today, this CSA approach,
this computer software assurance approach, that guidance
249
00:21:33.250 --> 00:21:37.130
that's coming from the FDA later on
this year. Again, thanks so much
250
00:21:37.130 --> 00:21:40.130
for joining us and we hope to
see you back here on a future episode.
251
00:21:44.730 --> 00:21:49.200
US DM's thought leaders have decades of
life science expertise and some previously worked
252
00:21:49.240 --> 00:21:55.240
for the FDA to help create requirements
we follow today. Get more insights at
253
00:21:55.359 --> 00:22:07.390
US DMCOM. You've been listening to
life sciences accelerated. If you enjoyed this
254
00:22:07.549 --> 00:22:11.390
episode, please subscribe and leave us
a review. If you'd like to learn
255
00:22:11.390 --> 00:22:18.900
more about strategies to digitally transform your
company and ways to streamline your organizations compliance
256
00:22:18.019 --> 00:22:25.539
process, visit us dmcom. That's
US, dmcom. Thanks so much for
257
00:22:25.700 --> 00:22:26.099
listening, until next time.
1
00:00:04.240 --> 00:00:12.669
And so FDA's providing this framework to
allow for a computer software validation process that
2
00:00:12.869 --> 00:00:21.070
is worst based and will provide for
more testing and potentially less documentation of systems
3
00:00:21.500 --> 00:00:28.660
in order to promote automation use in
the manufacturing of medical devices, pharmaceuticals and
4
00:00:29.260 --> 00:00:44.890
biologics. Welcome to life sciences accelerated, a podcast where we discuss experiences and
5
00:00:45.009 --> 00:00:50.880
groundbreaking innovations in compliance and technology,
from molecule to market. Tune in for
6
00:00:51.039 --> 00:00:57.479
in depth interviews with wellknown thought leaders
and renown subject matter experts with unparalleled knowledge
7
00:00:57.759 --> 00:01:03.079
in the technology and life sciences industry. Innovative, helpful and thought provoking.
8
00:01:03.399 --> 00:01:10.950
This is life sciences accelerated. Hi
Everyone, welcome to the life science is
9
00:01:11.030 --> 00:01:15.109
accelerated podcast. I'm your host,
Ryan Carmel, and today we're talking about
10
00:01:15.230 --> 00:01:21.420
computer system validation. There's a lot
of discussion in the life sciences industry about
11
00:01:21.459 --> 00:01:26.980
the FDA changing focus from compliance to
quality and encouraging the use of automation and
12
00:01:27.099 --> 00:01:33.849
new technologies. The FDA Center for
devices and radiological health plans to release new
13
00:01:34.170 --> 00:01:41.170
draft guidance later this year called computer
software assurance. It's for manufacturing operations and
14
00:01:41.329 --> 00:01:46.250
quality system software. This impending guidance
is creating a lot of buzz, so
15
00:01:46.409 --> 00:01:52.040
we decided this would make a fantastic
first discussion in our brand new podcast.
16
00:01:52.480 --> 00:01:56.040
So today I have Dianne lines are
with me. Diane is the VP of
17
00:01:56.120 --> 00:02:00.510
life science solutions and head of regulatory
compliance at US dum life sciences. Diane
18
00:02:00.549 --> 00:02:06.230
has three decades of experience in the
life sciences industry and leads a highly skilled
19
00:02:06.269 --> 00:02:10.189
team of implementation and compliance engineers.
I also have sandy hedbird, who is
20
00:02:10.310 --> 00:02:15.740
the QA and ur a manager for
US DM's cloud assurance division. See,
21
00:02:15.740 --> 00:02:20.259
and he has over twenty years of
experience and quality and regulatory affairs and the
22
00:02:20.340 --> 00:02:24.139
medical device, pharmaceutical and biologics industries. So thank you both for joining us
23
00:02:24.219 --> 00:02:29.300
for our first official PODCAST. All
right, so before we jump into the
24
00:02:29.379 --> 00:02:32.650
new guidance, Diane, can you
give us a quick history lesson on computer
25
00:02:32.729 --> 00:02:38.330
system validation, what it is and
how it's evolved over time? Sure,
26
00:02:38.449 --> 00:02:45.240
Ryan, computer system validation really just
means to show written evidence that the computer
27
00:02:45.439 --> 00:02:50.360
system that you're using to generate or
modify any record is required by the predicate
28
00:02:50.439 --> 00:02:54.280
rules, and the predicate rules are
things like part hundred twenty four medical device
29
00:02:54.479 --> 00:03:00.750
to tend to eleven, among others, for Pharmaceuticals and x eleven. There's
30
00:03:00.750 --> 00:03:05.629
a whole boatload of require regulations out
there, but that any records that you're
31
00:03:05.710 --> 00:03:09.349
generating are modifying that are required by
those predicate rules. Works for its intended
32
00:03:09.430 --> 00:03:13.780
use. It works the way you
wanted it to work. The goal of
33
00:03:13.819 --> 00:03:20.900
the computer system validation is to ensure
that your consistently producing accurate, reliable results.
34
00:03:21.419 --> 00:03:27.569
Historically, best practices of dictated.
The activities that occur during that are
35
00:03:27.810 --> 00:03:32.810
things like planning activities, documenting what
you're planning to do, documenting your requirements,
36
00:03:34.210 --> 00:03:38.610
the functionality of the system necessary to
meet those requirements, traceability of those
37
00:03:38.650 --> 00:03:45.159
requirements to where you've tested it,
verification that the systems installed and configured properly,
38
00:03:45.840 --> 00:03:50.719
system functionality required to meet your user
needs works the way that you expect
39
00:03:50.719 --> 00:03:54.949
it to work and that the system
performs according to the user requirements. And
40
00:03:55.110 --> 00:04:00.229
then there's a report generated at the
end that summarizes the effort, noting any
41
00:04:00.310 --> 00:04:04.909
constraints or restrictions on the system,
andy deviations that you encountered during the validation
42
00:04:05.110 --> 00:04:11.139
effort and a statement that the system
meets its intended use or not. Based
43
00:04:11.180 --> 00:04:14.740
on the evidence. HMM, okay, and then, Sandy, I'll ask
44
00:04:14.780 --> 00:04:18.139
you. So why is the FDA
making this change then? Well, FDA
45
00:04:18.300 --> 00:04:26.250
is trying to urge manufacturers to utilize
automation and their manufacturing process and their qms
46
00:04:26.329 --> 00:04:32.569
processes, because they've noted in other
industries that those industries have better product safety
47
00:04:33.250 --> 00:04:39.600
and quality of those products. So
they're trying to find a way to get
48
00:04:39.720 --> 00:04:46.639
industry to buy into more automation.
One of the driving factors associated with not
49
00:04:46.839 --> 00:04:51.000
doing that in the industry is that
everybody thinks it's too expensive because of all
50
00:04:51.040 --> 00:04:57.629
the validation effort that's required. Now, the validation requirements are part of a
51
00:04:57.670 --> 00:05:04.149
guidance document that's over twenty years o
old and there's oftentimes people over test because
52
00:05:04.750 --> 00:05:11.699
they believe there's there could be regulatory
punishment and instead of doing the right thing
53
00:05:11.819 --> 00:05:16.100
from a risk based approach in order
to get good quality and good quality products,
54
00:05:16.540 --> 00:05:21.689
they focus on the testing instead of
focusing on or they focus on driving
55
00:05:23.050 --> 00:05:29.529
documentation instead of focusing on the testing. And so FDA's providing this framework to
56
00:05:30.490 --> 00:05:38.800
allow for a computer software validation process
that is risk based and will provide for
57
00:05:39.519 --> 00:05:45.759
more testing and potentially less documentation of
systems in order to promote automation use in
58
00:05:46.160 --> 00:05:54.550
the manufacturing of medical devices, pharmaceuticals
and biologics. For people that are tuning
59
00:05:54.589 --> 00:05:59.189
into this, and and maybe they're
they've heard of the CSA a little bit,
60
00:05:59.430 --> 00:06:02.189
but dig into the weeds a little
bit for a Sandy. What is
61
00:06:02.389 --> 00:06:08.779
this exactly and how would you compare
it to more of a traditional CSV approach?
62
00:06:09.379 --> 00:06:13.860
Sure, it's very similar to a
CSV approach. It's utilizing a risk
63
00:06:13.899 --> 00:06:18.970
based approach that has always been acceptable
by FDA. What is foundation is is
64
00:06:19.649 --> 00:06:26.850
utilizing your supplier qualification and what your
suppliers are already doing in order to take
65
00:06:26.970 --> 00:06:33.319
credit for that and have that drive
your downstream testing and to make sure that
66
00:06:34.079 --> 00:06:42.360
there are alternate approaches from the fdah
perspective to lessen the documentation and providing more
67
00:06:42.399 --> 00:06:53.069
emphasis on testing, less emphasis on
documentation and providing for a better software validation
68
00:06:53.350 --> 00:06:59.750
process to ensure that your system meets
your intended use and it allows you to
69
00:07:00.829 --> 00:07:06.180
for the level of risk of those
sitting with that product, leverage and utilize
70
00:07:06.339 --> 00:07:13.060
different versions or different types of documentation, from ad hoc documentation all the way
71
00:07:13.100 --> 00:07:19.009
through your robrusscripted testing that we do
today for your documentation purposes for these types
72
00:07:19.050 --> 00:07:26.769
of systems, from a lowers perspective
to a Highris perspective. Mm and what
73
00:07:26.970 --> 00:07:30.120
types of life sciences companies can take
advantage of this approach. I think there
74
00:07:30.160 --> 00:07:35.839
are some misconceptions. I've heard some
rumblings that this is something that really only
75
00:07:35.839 --> 00:07:39.519
the medical device community can take advantage
of it. I think that, in
76
00:07:39.639 --> 00:07:45.709
particular comes from the fact that this
guidance is coming from the the medical device
77
00:07:46.189 --> 00:07:48.509
side of the House within the FDA. But there are some misconceptions there.
78
00:07:48.670 --> 00:07:53.709
Is that not true? Diane?
That is true that there are misconceptions.
79
00:07:53.990 --> 00:07:58.819
CDA are a ris to the group
who are working in producing this new draft
80
00:07:58.860 --> 00:08:03.500
guidance and at one point there may
have been an intention that it would start
81
00:08:03.540 --> 00:08:07.459
with medical devices and then move out
towards some of the other industries. But
82
00:08:09.139 --> 00:08:15.730
really this approach is acceptable today across
the board. So even though the CDR
83
00:08:16.050 --> 00:08:20.370
CD R H is the group that's
putting the guidance out there, working hand
84
00:08:20.449 --> 00:08:26.170
in hand, cooperating with the biologics
evaluation division, this drug evaluation and research
85
00:08:26.290 --> 00:08:30.800
division, and not just with FDA
divisions, but they're working with the EU
86
00:08:31.040 --> 00:08:35.559
they're working with Japan other regulatory bodies. So really, if you look at
87
00:08:35.559 --> 00:08:41.830
the ISO regulations, if you look
at Gamp guidances, these are all very
88
00:08:41.029 --> 00:08:48.110
consistent with the approach that's being defined
by the CDRH. So there's really no
89
00:08:48.870 --> 00:08:54.909
need for the pharmaceutical industry or the
biological biologics industries to not take advantage of
90
00:08:54.029 --> 00:08:58.740
a more streamlined and effective approach right
away. Don't even have to wait for
91
00:08:58.779 --> 00:09:03.100
the regulation to come out. It
can be implemented today as long as you
92
00:09:03.179 --> 00:09:07.299
update your processes and procedures internally.
So start doing it now. You don't
93
00:09:07.299 --> 00:09:11.169
have to wait. Yeah, and
for these companies that are listening, that
94
00:09:11.250 --> 00:09:16.009
are that are saying, Hey,
we're already doing this risk based validation approach,
95
00:09:16.129 --> 00:09:20.129
what do you say to them about
how to take advantage of the CSA
96
00:09:20.210 --> 00:09:24.720
approach? See, and you'll ask
you this. Yeah, yeah, using
97
00:09:24.840 --> 00:09:30.120
rostpace approach is really nothing new.
It's been promoted by FDA, gamp and
98
00:09:30.279 --> 00:09:35.320
other agencies for a long time.
The basic type of change that we're seeing
99
00:09:35.360 --> 00:09:41.870
here is that the FDA is providing
a framework in order to ensure that your
100
00:09:41.950 --> 00:09:46.590
testing activities are consistent with that risk
based approach. So for example, if
101
00:09:46.629 --> 00:09:54.220
I have an indirect QM sistem like
a campus system, that is needing a
102
00:09:54.700 --> 00:10:00.100
new validation, than you would be
allowed to potentially just do an ad hoc
103
00:10:00.419 --> 00:10:03.860
testing or you document what you tested
in the system, who did it,
104
00:10:03.379 --> 00:10:09.090
the dates that tested and sign off
of it and go. And so the
105
00:10:09.850 --> 00:10:18.009
clarification in this approach is really to
flip the focus on testing everything to testing
106
00:10:18.129 --> 00:10:22.360
what you need to test. So
instead of doing a twenty percent testing and
107
00:10:22.480 --> 00:10:26.399
eighty percent documentation, the feaims to
flip that so you do eighty percent testing
108
00:10:26.600 --> 00:10:33.679
and only twenty percent documentation. So
in doing less documentation you have more time
109
00:10:33.919 --> 00:10:39.830
to be able to do ad hoc
testing that will provide you assurance that that
110
00:10:39.950 --> 00:10:43.190
system works in your environment and you're
intended use and and they've had done some
111
00:10:43.350 --> 00:10:50.139
pilots with some companies where it they
they found that the one you want live
112
00:10:50.259 --> 00:10:54.059
and implementation of these systems. There
were less issues at that point in time
113
00:10:54.139 --> 00:10:58.460
because you did more of the upfront
work than you would have normally done in
114
00:10:58.700 --> 00:11:03.450
just doing a noncsa approach, because
you had more time to test and you
115
00:11:03.649 --> 00:11:11.690
spent less time writing test scripts.
You earlier, Sandy, you mentioned non
116
00:11:11.049 --> 00:11:16.210
products quality systems. Can you talk
more about that? Right? Right.
117
00:11:16.330 --> 00:11:22.480
So this this guidance is not intended
for medical device manufacturing products like medical devices,
118
00:11:22.639 --> 00:11:26.240
medical devices as services or in products
that are used in the medical device
119
00:11:26.279 --> 00:11:31.120
industry. This is really just for
those types of systems that are used in
120
00:11:31.240 --> 00:11:37.870
manufacturing, in the Quality Manu management
system where you have indirect or potentially direct
121
00:11:37.950 --> 00:11:43.429
impact to patient safety, product quality
and those types of things. So most
122
00:11:43.470 --> 00:11:46.500
of the time you're your quality management
system software are going to be indirect systems
123
00:11:48.259 --> 00:11:50.059
where you're not going to have a
direct impact on the product, like your
124
00:11:50.860 --> 00:11:56.419
complaint handling systems, your csfeed Type
Process Systems, like bug tracking systems,
125
00:11:56.419 --> 00:12:01.009
your tools, load testing tools,
life management tools, so life cycle management
126
00:12:01.049 --> 00:12:07.450
tools. They don't directly impact the
product. So those types of systems require
127
00:12:07.529 --> 00:12:11.889
less documentation, but remember you want
to make sure you do more testing but
128
00:12:11.970 --> 00:12:16.399
less documentation. Those systems that more
have more of a direct impact on the
129
00:12:16.440 --> 00:12:20.679
patient safety of the product quality,
like if you had any electronic adverse event
130
00:12:20.840 --> 00:12:24.919
reporting system that would report directly to
FDA. Those types of systems are going
131
00:12:24.919 --> 00:12:31.870
to require more documentation and probably increased
testing based on their risk and the impact
132
00:12:31.950 --> 00:12:35.710
on the end product. So in
those particular cases you're going to have more
133
00:12:35.789 --> 00:12:41.429
testing and the documentation. In the
other types of the direct systems you're going
134
00:12:41.429 --> 00:12:45.220
to have less documentation but more testing
because you're going to be able to do
135
00:12:45.379 --> 00:12:48.460
more testing in the time, the
same time that it would take you to
136
00:12:48.500 --> 00:12:52.100
do all the documentation that you used
to do. You want to do more
137
00:12:52.179 --> 00:12:54.940
testing, you want to make sure
that it's done in a manner consistent with
138
00:12:54.980 --> 00:13:01.250
with the users use of the system
and that way you won't have as many
139
00:13:01.370 --> 00:13:05.809
problems when you when you go live. Uh Huh. And what feedbacks and
140
00:13:05.929 --> 00:13:11.450
you are you hearing from the life
sciences community about this upcoming guidance? I'm
141
00:13:11.529 --> 00:13:15.960
hearing some concerns that people don't want
to implement this until the guidance document comes
142
00:13:16.000 --> 00:13:20.159
out, which FDA has been adamant
that this type of approach and this framework
143
00:13:20.200 --> 00:13:26.919
that they're proposing is acceptable to FTA
today and does not need to what you
144
00:13:26.960 --> 00:13:31.110
don't need to wait till the guidance
document comes out. I've also heard where
145
00:13:31.429 --> 00:13:35.269
customers are saying, well, we
already use a respace approach. We've seen
146
00:13:35.350 --> 00:13:39.590
that at a lot of places where
they say they're using over space approach,
147
00:13:39.669 --> 00:13:43.059
but in reality they're still testing everything
and they're still testing them to the about
148
00:13:43.100 --> 00:13:50.779
the same rigor as as they would
in a regular CSV type approach. The
149
00:13:50.899 --> 00:13:54.419
problem that that most people have is, if I have a good vendor that's
150
00:13:54.460 --> 00:13:58.250
been around a long time, do
I really need it to do testing on
151
00:13:58.330 --> 00:14:01.929
my log in capabilities, because they
probably already tested it to the nth degree
152
00:14:01.009 --> 00:14:05.610
at the vendor and if you already
know that, why are you your time
153
00:14:05.850 --> 00:14:09.399
on that test? Go on to
something else that would be more related to
154
00:14:09.480 --> 00:14:13.440
your use case or how the users
use the system in in order to identify
155
00:14:13.480 --> 00:14:18.600
any issues up front before you go
live in that production environment and then have
156
00:14:18.720 --> 00:14:22.559
an issue. I think Diane has
a couple concerns that she's heard and actually
157
00:14:22.600 --> 00:14:26.870
non concerns that she's heard from some
from some clients as well. Yeah,
158
00:14:26.870 --> 00:14:31.029
I think you know, I'm hearing
a lot of excitement in the industry about
159
00:14:31.029 --> 00:14:37.750
the potential for not having to do
so much documentation. There's there's certainly a
160
00:14:37.950 --> 00:14:41.740
great deal of interest and how that
might look what that looks like. Certainly
161
00:14:41.779 --> 00:14:46.700
all the poor people who've been doing
testing for so long and printed out thousands
162
00:14:46.740 --> 00:14:50.740
of screenshots are are really pretty excited
about the fact that you don't need to
163
00:14:50.980 --> 00:14:56.809
show so much objective evidence, just
really where it counts, where you really
164
00:14:56.889 --> 00:15:00.889
really need it. You know,
you don't need screenshots for everything anymore and
165
00:15:01.049 --> 00:15:05.690
that's a lot of time and effort
saved over the over the course of a
166
00:15:05.730 --> 00:15:11.720
validation or several validation events. I've
heard a couple of customers concerned what would
167
00:15:11.720 --> 00:15:18.519
happen in an inspection situation? Will
the new inspectors be trained to know what
168
00:15:18.679 --> 00:15:24.669
this approach is? Really an inspector
looks at what your approach is, what
169
00:15:24.830 --> 00:15:31.389
your computer system validation process is,
and they inspect to that process, and
170
00:15:31.870 --> 00:15:35.139
so that really minimizes a concern.
I will say that I've seen a few
171
00:15:35.179 --> 00:15:41.820
instances where someone's used a different approach
than gamp. There's nothing wrong with that
172
00:15:41.100 --> 00:15:46.379
and if an inspector is not familiar
with the approach you're using, it could
173
00:15:46.419 --> 00:15:50.809
lengthen the time of inspection and that
makes people nervous. But it shouldn't because
174
00:15:50.850 --> 00:15:54.970
you're doing the right thing if you've
documented what you're going to do and it's
175
00:15:54.009 --> 00:15:58.570
been approved across the board by the
right people, and then you're doing what
176
00:15:58.649 --> 00:16:02.889
you said you were going to do, then that's what they're going to hold
177
00:16:02.889 --> 00:16:07.000
you too. So I think that
that concern is probably not as great as
178
00:16:07.039 --> 00:16:12.519
some people fear. I've also heard
some concerns that their quality people won't accept
179
00:16:12.519 --> 00:16:17.559
the new approach, and that could
well be. It's a matter of quality
180
00:16:17.600 --> 00:16:22.389
people understanding what the approach is,
how it's done, how it's executed and
181
00:16:22.669 --> 00:16:30.350
why it's a better approach. I
would imagine some of these large legacy life
182
00:16:30.429 --> 00:16:34.539
sciences companies that have well established processes
for CSV. I'm going to take a
183
00:16:34.620 --> 00:16:38.299
guess here and say that this is
going to be a little bit more of
184
00:16:38.379 --> 00:16:42.179
an obstacle or more of a challenge
to to get some of these companies to
185
00:16:42.539 --> 00:16:47.970
get on board with this approach.
What do you say to those types of
186
00:16:48.049 --> 00:16:52.610
companies? I would say that a
lot of our bigger customers are embracing this
187
00:16:52.730 --> 00:16:57.289
approach and excited about trying to put
it in place. You're right, it's
188
00:16:57.330 --> 00:17:02.919
like moving a mountain sometimes. Yeah, but the bigger companies are the ones
189
00:17:02.919 --> 00:17:06.559
who are going to benefit from this
approach the most. There is a real
190
00:17:06.799 --> 00:17:11.519
savings in terms of time and resources
necessary. Validation's always been thought of as
191
00:17:11.519 --> 00:17:15.789
a ball and chain that hangs on
the end of a validation effort and drags
192
00:17:15.829 --> 00:17:19.150
it backwards and pulls that timeline out
because it doesn't get started till the end.
193
00:17:19.630 --> 00:17:25.750
It just delays implementation of a system
and that shouldn't be what it is.
194
00:17:25.910 --> 00:17:30.619
It should be an efficient, effective
test that says yes, my system
195
00:17:30.660 --> 00:17:33.940
is ready to put out there on
the floor and to be used by everybody.
196
00:17:33.500 --> 00:17:37.579
So, for our larger customers,
they're looking at things like using a
197
00:17:37.700 --> 00:17:42.660
pilot study so that they can help
to convince quality and it and other teams
198
00:17:44.099 --> 00:17:47.849
that this approach will work. So
try it on one system or group of
199
00:17:47.930 --> 00:17:52.170
systems first and measure your results,
especially systems that you already have validation results
200
00:17:52.289 --> 00:17:56.809
on, see how it's different and
if that pilot works, then you can
201
00:17:56.930 --> 00:18:00.960
start expanding it out to other systems. I think it's important to make sure
202
00:18:00.039 --> 00:18:06.119
everybody's on board before you just change
your methodology. But I think it's also
203
00:18:06.279 --> 00:18:10.160
important to your company, Your Corporation. You can do more work and less
204
00:18:10.240 --> 00:18:15.069
time better, more effective systems out
for people to use. You're going to
205
00:18:15.150 --> 00:18:19.630
produce better data, you'll have better
data integrity and ultimately you're going to still
206
00:18:19.630 --> 00:18:23.869
save time and money in doing this. MMM, and what do you say
207
00:18:25.029 --> 00:18:27.700
to the folks that are part of
some of these smaller companies, you know,
208
00:18:27.819 --> 00:18:30.900
a start up or an emerging life
sciences company? Is it? Is
209
00:18:30.980 --> 00:18:34.819
the message the same or is it
sort of a different are the selling points
210
00:18:34.859 --> 00:18:37.220
a little bit different? Well,
I would say the selling points are a
211
00:18:37.259 --> 00:18:41.369
little bit different because they don't have
established methodologies. In most cases, where
212
00:18:41.369 --> 00:18:45.089
you have an established methodology and a
group of people who are used to doing
213
00:18:45.210 --> 00:18:48.809
things a certain way, you got
to change your culture a little bit.
214
00:18:49.049 --> 00:18:53.930
But with these smaller companies, who
don't have processes in place already for validation
215
00:18:55.130 --> 00:18:57.720
efforts, they can start with this
right away. There's there's no need to
216
00:18:57.839 --> 00:19:03.440
start with a fullblown effort. That's
often expensive and time consuming and resource consuming
217
00:19:03.880 --> 00:19:07.680
when you don't have a lot of
resources on hand to do it. So
218
00:19:08.079 --> 00:19:11.670
saving time and money, can start
right from the beginning for them. Yeah,
219
00:19:11.710 --> 00:19:15.390
that makes sense. Well, before
we run out of time here,
220
00:19:15.670 --> 00:19:19.789
Sandy, any other thoughts on this
CSA approach? I I know it's probably
221
00:19:19.990 --> 00:19:25.019
not new. I think pretty much
everybody has heard about it by now.
222
00:19:25.660 --> 00:19:29.259
Is that fair to say? Yeah, this, this is not the guidance
223
00:19:29.299 --> 00:19:32.940
itself as new, but the approach
isn't that new. It is just a
224
00:19:33.059 --> 00:19:37.849
new framework that FDA has been promoting
in order to get us Awf of doing
225
00:19:38.049 --> 00:19:44.009
our our screenshots and our test,
you know, stuff by set test cases
226
00:19:44.009 --> 00:19:47.930
all the time for those types of
systems that are that have an indirect impact
227
00:19:48.049 --> 00:19:52.440
on manufacturing or quality. It's allowing
us to do more testing and less documentation
228
00:19:53.279 --> 00:19:59.640
and hopefully, based on your critical
thinking and your wrist based approach, you
229
00:19:59.759 --> 00:20:03.920
can get more bang for your book
and you're doing a better job of testing
230
00:20:03.960 --> 00:20:08.230
and concentrating on those things that are
really critical to that application. Yeah,
231
00:20:08.390 --> 00:20:12.230
okay, and Diane, anything else
from you? I know we've heard a
232
00:20:12.269 --> 00:20:18.069
lot about screen shots these days,
even in the context of CSA. Are
233
00:20:18.150 --> 00:20:22.299
Those those a thing of the past? They they won't ever be a thing
234
00:20:22.380 --> 00:20:26.140
of the past, I don't think, because they do have their value.
235
00:20:26.819 --> 00:20:32.539
But I see a lot of people
so concerned about not having the right objective
236
00:20:32.579 --> 00:20:37.490
evidence that they lose sight of what
the right objective evidence is. It doesn't
237
00:20:37.529 --> 00:20:41.329
have to be a screen shot and
you don't need a screenshot at every step.
238
00:20:41.809 --> 00:20:45.769
Use them where they're really meaningful,
so you're showing that that something works,
239
00:20:45.890 --> 00:20:52.200
that isn't obvious otherwise and understand this
is applicable now. You don't have
240
00:20:52.319 --> 00:20:56.880
to wait for the guidance to come
out. The methodology is firm. It's
241
00:20:56.920 --> 00:21:00.640
up to you to establish as a
company what your level of risk aversion is
242
00:21:00.240 --> 00:21:06.789
and to leverage that level in your
testing and documentation. Yeah, all right.
243
00:21:07.509 --> 00:21:10.990
Well, Sandy and Diane, thank
you so much for joining us today.
244
00:21:11.470 --> 00:21:15.829
We hope you enjoyed this first episode
of life sciences accelerated. We have
245
00:21:15.910 --> 00:21:18.180
a lot more resources available to you
on our website. You can head to
246
00:21:18.180 --> 00:21:22.940
us dmcom. We've got Webinar as, we've got blogs. I've got white
247
00:21:22.940 --> 00:21:26.059
papers on all sorts of life sciences
subjects, including the one that we talked
248
00:21:26.059 --> 00:21:33.170
about today, this CSA approach,
this computer software assurance approach, that guidance
249
00:21:33.250 --> 00:21:37.130
that's coming from the FDA later on
this year. Again, thanks so much
250
00:21:37.130 --> 00:21:40.130
for joining us and we hope to
see you back here on a future episode.
251
00:21:44.730 --> 00:21:49.200
US DM's thought leaders have decades of
life science expertise and some previously worked
252
00:21:49.240 --> 00:21:55.240
for the FDA to help create requirements
we follow today. Get more insights at
253
00:21:55.359 --> 00:22:07.390
US DMCOM. You've been listening to
life sciences accelerated. If you enjoyed this
254
00:22:07.549 --> 00:22:11.390
episode, please subscribe and leave us
a review. If you'd like to learn
255
00:22:11.390 --> 00:22:18.900
more about strategies to digitally transform your
company and ways to streamline your organizations compliance
256
00:22:18.019 --> 00:22:25.539
process, visit us dmcom. That's
US, dmcom. Thanks so much for
257
00:22:25.700 --> 00:22:26.099
listening, until next time.
