I work with an organization that sells ISO, FDA regulated software that meets 21 CFR Part 11 compliance. We offer a validation protocol workbook for our customers that includes IQ,OQ and PQ test reports. As a vendor, what other items within a validation protocol are we responsible to provide? Are we responsible for any other entities within the validation process?
Thanks!
Edited by Dee on 07-08-08 07:01 AM. Reason for edit: No reason given.
Hi Dee
You make an interesting statement that your product meets 21 CFR Part 11 compliance?
I think you must mean that it has the potential to be used in a 21 CFR Part 11 compliant manner.
I say this because the first stipulation for 21 CFR Part 11 is that the system is validated. This is done at the end users site on the end users hardware and is the end user's responsibility.
As the vendor you are not really responsible for any of the validation (life science validation) which the regulators will audit.
You are responsible for creating software that has been created using Good Software Development Practices(GSDP). This includes such things as using change / version control, structured programming, comments and functions that work. Also you must specifying the minimal hardware requirements. The development must be carried out and managed by qualified and / or experienced software engineering teams. Adhering to recognised programming standards, such as ISO and TickIT, and QMS systems are all part of the concept.
All of the above, and more, can make up a "vendor audit" which potential customers should carryout before engaging a software vendor.
This is an excellent space to discuss what the software industry calls "validation".
You see in the life science industry we use the term slightly differently. Although there are very striking similarities there are also large differences.
The main difference is who is doing what. The software industry often creates software that they think people will need and use. I guess that some market reasearch has been done, but doubt if there is a formal URS as at this point there is no customer. This means creating a PQ out of the box is nigh on impossible.
Unless an end user is working closely with the vendor to develope a novell piece of software never the twain shall meet.
Also the development of the code is not done on the end users hardware. Thus we are really talking about life science system validation.
As you can appreciate there is no such thing as life science software validation. Because it must run on hardware and that becomes a system. Each end user installation and network will be different. Thus software vendors can't really sell pre-validated software (in terms of life science validation).
What you can do is sell a quality, well tested, piece of software which has undergone the software industry verification and validation process.
At this point it is not end user system validated. The regulators put the responsibility for sourcing, installing, configuring and using systems in the lap of end users. End users may deploy vendors to participate in this endeavour but end users still carry the responsibility. It is end user responsibility to use a system which is suitable for its intended purpose.
My aim is to bring this jargon and misunderstanding to the fore so that we in the life science industry can leverage software industry validation work against our effort to perform end user system validation (life science industry validation). The hardware platforms are a key factor in differentiating one from the other.
If your validation package is creating IQ/OQ/PQ protocols in consultation with end users this an excellent way to validate the system.
Hope this gives your organisation some food for thought.
The GAMP books are trying to do what PaulS is 'aiming' at, using vendors GSDP and testing as leverage for qualification efforts, but the user needs to provide enough rationale (assessments) to indicate 'what and what not' to its 'why'.
Now what I've been learnt is to run away from a supplier saying he is part 11 compliant. (No hard feelings)
In general Part 11 compliancy depends how the user is going to integrate your software in its companies structure. This is something the user needs to validate.
Now for small systems (such as lab systems not coupled to a network) the supplier can indeed claim part 11 compliancy but then if the users works with the equipment as the supplier designed it.
In the end, I see qualification/validation as a joined effort between supplier and user. Since the supplier develops his software according to the user's requirements.
You make some valid points, but I have to disagree with your post. SW Vendors wanting to sell their respective SW in the regulated space, must meet certain requirements. A SW vendor must show documented evidence of procedures they have in place for their SDLC, Change Control, Bug Management, Customer Support, Security, etc. In addition, they absolutely must validate their SW. Although the company purchasing the SW has to validate the SW according to their intended use, the SW vendor still has a responsibility to show documented evidence the system general functionality (including Part 11) operates as intended. In other words, testing in the SDLC framework is different then testing in a validation framework. Similar in a bunch of ways, but documentation and execution wise, vastly different.
Dee, if you like to have a conversation about this, I would be happy to. Please see my contact information in my signature.
Ah but you miss the point...A piece of S/W can only be said to be 21 CFR Part 11 compliant once it is installed /operators are trained /SOP written / back up and audit trail systems in place etc..
How can a S/W vendor do this????
Other than that S/W can only be said to have the capability to meet 21 CFR Part if the S/W is utilized correctely (as outlined above).
SDLC activities that you mention is just GSDP (good software dvelopment practices) which I would expect from any reputable software writers. Of course I would expect a good URS to have laid out the requirements needed to meet 21 CFR Part which the S/W vendor is using to write the code.
Implementing S/W to comply with 21 CFR Part 11 has been done to death on other web sites including the FDA's , have a look at 21CFRPart11.com.
Compliance with 21 CFR Part 11 is sooo..dependant on who, how and what you are doing that I get suspicious when S/W vendors make such claims.
You can disagree but I am not a vendor so have nothing to sell but the truth...When big dollars are at stake what is a few white lies told to a customer who knows no better about 21 CFR Part 11.
Go figure...............Gone
Edited by PaulS on 12-17-08 04:35 PM. Reason for edit: No reason given.
I disagree with everyone on the subject of compliance with 21 CFR Part 11.
There is specific software functionality documented in the legislation, and an equipment supplier that has developed software that is compliant with this legislation is entitled to state just that.
Part 11 is no different from other software programs, they all required procedural controls to be in place, before they are validatable.
To return to the core question from Dee.
When Part 11 applies to critical product data your risk assessment will demand that a full life cycle validation approach is used. To successfully execute a full life cycle validation program requires access to the history of construction for the software. These requirements are documented in many FDA documents.
You state you would like to make your software attractive to end users, then include;
A copy of:-
An independent certified code review from a test centre.
A guarantee that the original code will be held in ESCROW.
Quality Plan (QP) that was used to develop the code.
Each specification (software/module/integrat ion/hardware).
The final test specifications. (as above)
The Design Qualification.
The Factory Acceptance Tests.
With these documents available I would without hesitation, use you system and recommend it to other end users.
Sorry Alex but I have to disagree. I again would recommend that Dee search the massive amount of information available in the posts and replies on www.21CFRPart11.com
No software in a box can be said to be 21 CFR Part 11 compliant. Any vendor who uses this term has not grapsed the subtleties of 21 CFR Part 11 compliance.
I would avoid their product.
If however they stated 21 CFR Part 11 enabled or possible or ready then I would know that they have realised that having the functionality available is only half of the story when complying with 21 CFR Part 11.
Implementation and usage is a large part of compliance with 21 CFR Part 11, not just software functionality.
I could give numerous examples but here is a really simple one to highlight the point I am trying to make.
e.g. Lets say a piece of software is installed in a lab system which is GxP critical and has to comply with 21 CFR Part 11. The password access is there, but the administrator has not enabled it or set user IDs or user profiles. The system is wide open and any one can play about with it. Then clearly this system does not comply with the requirements of 21 CFR Part 11. Until the correct usage is set up then 21 CFR Part 11 compliance can not be attained no matter how well the functions meet the vendors interpretation of the legislation.
I think you are missing my point. I stated that when the program designer uses a stringent quality assurance program and through it delivers a rigorously tested software program that has been validated as delivering all the software functionality that Part11 documents as essential functionality for a compliance, with Part 11 requirements. Then I consider that they are entitled to state their program is compliant with all the program requirements detailed in 21 CFR Part 11.
Nothing comes into the Pharma arena without having to be ring fence with documentation;
Commissioning, validation, maintenance, calibration, operation, training, cleaning, SOP’s, method statements, health and safety assessments, are but a few of the documentation requirements. Part 11 is no different. However if the functionality is not securely designed into the system you will be never be able to achieve compliance, and that is all the vendor can do, their job is done, the design is finished, the program works. Now it is up to the user to get it street legal.
Vendors that provide S/W with functionality that enables 21 CFR Part 11 to be met can not state that it complies with 21 CFR Part 11, because compliance can only be achieved on site when the S/W is installed and when the procedures around the S/W are in place.
Thus vendors should avoid stating that their S/W complies to 21 CFR Part 11.
But I'm more of the PaulS side when it comes to the functionality of the acquired software. Alex you are also right, but you seem to take on more of an supplpier audit view.
I think that suppliers may only suggest : designed to comply with part 11.
Part 11 compliancy remains dependent on the intended and final use of the software.
The supplier can foresee certain things to facilitate compliancy, but stating that it therefor is part 11 compliant.
Go figure an ERP system. You can freely flag and unflag fields and tables to log in audit trails. But if your E/S assessment was wrong then you are trailing the wrong items.
So the developper can provide the functionality of flaaging items, but the user needs to define which records are to be flagged.
Hence => PART 11 is a user qualification. These things of possible need to be written in URS or a separate document containing all critical records for the specific system.
But for the user to be able to go swiftly through the validation process, he needs to be able to rely (up to a certain degree) on documentation of the supplier. That's why supplier need to be audited for having a good quality system on how they document control develop and test there software.
So as stated in the beginning you both have a good view on things only a different approach.
But Alex, sometimes (worst case) you can not rely too well on the docs of a supplier. So the effort is put back at the end user to set up these documents. GAMP is there to help suppliers and end users to get swiftly through the documentation processes.
I agree with Paul in regards to the fact that as a vendor you are not required to provide the client with any validation. Also, I agree with his clarification regarding 21 CFR Part 11 compliant product in that the claim should be that the product was designed to meet technical controls of 21 CFR 11. However, from what I understand, your company also assisting the client with validation projects (validation workbook). As a validation consultant and computer systems auditor, I noticed that many of my smaller and star-up clients, specially CROs mistakenly believe that by purchsing a system that is claimed to be 21 CFR Part 11 and executing validation workbooks, they become part 11 compliant. This is dangerous - beacuse as Paul mention, to support a Par 11 claim, the software user (client) must also meet validation, software management requirements, as well as to establish procedural controls around the system. In absance of these, your client reliying on the assertion you made (i.e. 21 CFR Part 11) may end up in the situation where he/she looses the prospective client, or receives observation during 3rd party inspection, or 483 (based on a predicate rule of course).
On the positive note, from your posting, it appears that your company is genuiny interested in providing the client with the product that enables him to meet 21 CFR Part 11. Validation workbook is a great start, all you need to to make next step and start offering validation and QM systems development services.
If you would like to talk more about my comments or hear additional toughts on the topic, or need any assistance in developing satelite to your product services (i.e. valiation, QM), please contact me at alexandra.dilis@ardsci.com or visit the website ardsci.com
Alex
You completely miss the point here. I recommend you attend some 21 CFR Part 11 training before you add anymore posts that yield the wrong information for the users on this board.
SW Vendors wanting to sell their respective SW in the regulated space, must meet certain requirements. A SW vendor must show documented evidence of procedures they have in place for their SDLC, Change Control, Bug Management, Customer Support, Security, etc. In addition, they absolutely must validate their SW. Although the company purchasing the SW has to validate the SW according to their intended use, the SW vendor still has a responsibility to show documented evidence the system general functionality (including Part 11) operates as intended. In other words, testing in the SDLC framework is different then testing in a validation framework. Similar in a bunch of ways, but documentation and execution wise, vastly different.