I'd appreciate some opinions on this, even if it's to tell me I'm way off base.

Situation - We're in the process of implementing a software CAD-type program that will be used to produce Engineering drawings that will be used to:

a) define product
b) machine/assemble product
c) contain drawing approvals
d) control revision and distribution

This particular piece of software will not be used to test product, calibrate tools or automate processes.

What is the intent of ISO/FDA regarding software validation?

My kneejerk reaction is that we should validate it for the functions we require, not depend on the developer's validation. But since it's an established program and this use isn't called out in the standards I'm getting a lot of disagreement. And for that matter, I'm not eager to insist on a considerable expense if it isn't actually required.

Any opinions, please.

Thanks.

Alf

We also use CAD software in our facility to produce engineering and tooling drawings. These drawings are printed in a hard copy form and approved by the appropriate personnel signing the drawing. The hard copy of the drawing is then filed and is the official record. In this sense we are performing verification by output and the software does not need to be validated. If, however, you are not fully verifying the output, then the software must be validated for its intended use.

The FDA has issued a draft guidance for Medical Device industry software validation in which they state, "Off-the-shelf software may have many capabilities, only a few of which are needed by the device manufacturer. The software must be validated for those specific uses for which it is intended." If you do need to validate the software, I think your knee-jerk reaction is appropriate and valid.

More information can be found at the FDA's website.
http://www.fda.gov/cdrh/comp/guidance/938.html

I wish to thank "Buba" for his response to the question regarding software validation, and to concur with his comments. I have worked in the med device and pharmaceutical industries for 11 years, and this approach is sound. Great advice Buba.

I'm surely not a medical type person, but software validation covers all fields,

How can it be proven that software data is correct?

The only way I see it is to measure it against human measurements or like software programs.

How can it be proven that software data is correct?

I think it helps to remember that software is, at its most basic form, simply a process. It takes input and runs it through predefined procedures to produce an output. When you are validating the software, what you are actually validating are those predefined procedures. Unless you are adept at computer languages and have access to the code, the best way to do that is to define what the inputs are and what the expected outputs are. If the outputs do not match what is expected, then there is something wrong with the procedures, i.e. the software.

In order to prove that any software data is correct, you must first know what your inputs are, and what the correct output should be. Obviously, the more features a software package has, the more inputs and outputs you will need to clearly define.

In the case of CAD drawings, the expected output is a graphical and textual representation that communicates to the viewer specified features, requirements, procedures, etc. If the drawing can effectively communicate the needed information (that is input into the software), than the drawing (output of the CAD software) is correct.

I'm not sure if that adequately adresses your question, but that is my basic take on the matter. Whether you use human measurements, or other like software, or some other basis for your expectations, you must be able to define what you expect the outputs to be for the given inputs.:)

I've back after being gone for a few days.

Thank you Bubba and all. That's the info and support I was looking for. It's going to be an uphill battle but I'm going to keep pushing it.

Alf

Bubba-

I owe you a second Thank You for reminding me about the FDA publication, General Principles of Software Validation (draft - 1997). I pulled my dusty old copy out and found exactly what I was looking for.

For anyone else that might benefit from this, the first two sentences in the Scope say:

"This draft guidance is applicable to all medical device software, including blood establishment software, and to software used to design, develop or manufacture medical devices. This draft guidance document represents the agency's current thinking on validation of software related to medical devices."

This couldn't be more clearly related to CAD software, and even though it's a 1997 draft, as far as I know it's still the most current document on the subject.

Does anyone know of anything more recent that supercedes or contradicts this?

Alf

I can't believe it! After waiting four years for the final FDA guidance on software validation, and less than an hour after using the draft version to leverage my position, I get the notice that the final version is available. And from what I see so far, it doesn't support me nearly as well as the old one did.

For anyone that needs it, the final version is at:

www.fda.gov/OHRMS/DOCKETS/98fr/97d-0282_gdl0001.pdf

For whatever reason, I'm not having any luck downloading or printing it but at least it's there.

Alf

Edit Note- The URL isn't coming out right. I'll try again.

Alf,

Thanks for the information on the final revision of the guidance document. I have also been waiting for a long time for this to come out. I followed your hyperlink, but I was only able to get about half of the document. It appears that it is scheduled for publication tomorrow. Maybe by then it will be completely available. It is kind of funny how much the FDA expects out of us for our software development and validation, yet their website is one of the least user-friendly sources of information on the internet.:confused:

I couldn't get the part that talks about off the self software yet, but I'm anxious to look it over.

The FDA today anounced in the Federal Register that the "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" has been released. It is available at http://www.fda.gov/cdrh/oc/938

This will answer most if not all of your questions.

Thanks, Harold-

I tried your link and still couldn't get the document but it helped me find an address that worked. Using the one below I was able to both save and print the document because (apparently) it's text, not PDF.

www.fda.gov/cdrh/comp/guidance/938.html

Alf.

If anybody is still interested, a PDF version is available at:

http://www.fda.gov/cdrh/comp/guidance/938.pdf


Another good source for software info is:

http://www.fda.gov/cdrh/ode/software.pdf