Medical Device Vs Pharma

COMPUTER SYSTEM VALIDATION (CSV)
1

I have been working in medical device environment for a few years now
after working for a number of years in pharma. I see a lot of
differences in opinion with regard to expectations on software
validation. I’d love to open up a discussion with those that work in
either or both of these industries.

The basic premise of the discussion is…

  • What kinds of differences in approach for software validation
    are being taken between medical device and pharma. (please note I would
    like to limit the discussion to “non-product” software)

For starters, here are a few of my observations…

Pharma has been at software validation for a long time and have a lot of
lessons learned. In some cases, best practices have been incorporated
into procedures and these have been shared throughout the industry.
Once practices get to be common, people start to assume that they are
required by the regulators, when in fact they are not explicitly
required. This does not take away from the fact that these are good
processes and help to deliver not only compliance, but QUALITY.

Medical Device on the other hand is a newer industry, relative to
pharma. So people are still on a learning curve… between learning
how to be compliant and learning what makes the most sense with regard
to QUALITY. Medical Devices make software as a product and are subject
to design controls. Because of this, medical device industry is
developing a different philosophy on software quality than pharma. It
is influenced by the idea of verification and validation, with
validation being only one phase of product development. This is very
different than the idea of a validation covering the entire system
lifecycle, as is supported by GAMP for example.

Last observation is with regard to the industry to keep software validation for
non-product software SIMPLE. Some folks take this as license to deliver
the minimum. I take it to mean we are trying to convince people
that software validation is not that bad, and it is only slightly
incremental to what you should be doing as part of good software
engineering anyway.

So now that I have been long winded and overly philosophical, I am very
interested to hear others thoughts!

2

I question that. In my experience, most of the so-called “best practices” suffer
from two problems:

  1. They are not scalable. They can’t be used by small companies because they
    tend to require more resources than small companies can afford, and they can’t
    be used effectively for small systems because you wind up applying more effort
    than the actual use of the system would justify.

  2. They provide little or no direct value to the business other than assuring
    that a regulatory body won’t be able to pick off low-hanging fruit. Many times,
    they mask the true quality of the system - it’s well-documented on paper, but
    the business can’t use the system as built, so they end up doing some things
    that aren’t in the SOP or the user documents just so that they can get their
    jobs done.

If the business can’t use the system in the way that they need to use it in
order to get their jobs done in a timely manner, have you REALLY provided a
quality solution? Not in my book.

3

From working in both industry sectors for many years, I would say that both
industry types are as good or as bad as each other in terms of their
approach, simply because “FDA software validation” and “approach” are
defined by “people”, and the quality of all of this across all industries
ranges from very poor to very good.

*- There is no agreed standard for FDA software validation. Key players
include IEEE, GAMP and FDA Guidance. Of the three GAMP is probably
recognized as a standard by the majority. If there was agreement, we would
not keep having these discussions.

*- There is no agreed standard of software quality. Software Development
companies follow ISO, CMM and internal standards. Software Engineering is
still evolving as a practice. Software development changes standards and
tools every 5 years. The pursuit of perfection is lost in billions of
dollars of failed CASE tools, RAD and Agility products, and MCSE courses.

*- There is no agreed education qualification for software engineering or
validation so that as a result, everyone is an expert.

Put the above three together and you get a wide range of solutions, from the
very best to the very worst. Everyone is willing to defend their approach
because everyone is an expert.

Personally, I would sooner see the standards war declared as “over” and have
the industry embrace GAMP warts and all, and then work aggressively to
dealing with the warts and improving the standard.

Until Universities start turning out qualified graduate Software Engineers,
who can pursue a professional designation similar to Doctors and Engineers
along with all the moral and ethical and legal implications of that
professional approach, then we are spinning our wheels. These people need 10
years to become embedded into the software industry, into decision making
roles. Very very few of them exist today.

Only then will Software Development companies move away from bug ridden
software and marketing driven quality programs. The end result will be a
simplified, engineered, quality approach to implementing that software
within a customers business. Software will validate itself and customers
will be able to move purely towards “configuration verification” for
purchased software.