In spreadsheet validation, when writing the URS, do we need to specify explicitly what cell corresponds to what info? Do we then need to write down the formula’s that are used in the sheets, so instead of saying for instance that the average of a range of values must be calculated, we must specify how it must be calculated (AVERAGE(Dx:Dy)).
Thanks for your answer!
I would leave that level of detail for your FDS.
Making the URS too specific is a bad idea in my opinion and will only make the FDS look identical to the URS.
I would say “An average of a range of values must be calculated” in the URS with the corresponding tag in the FDS detailing how this will happen ie use your formula here.
Regards
We do not have any FS or TDS since the spreadsheets are GAMP category 3. We will then describe high level what must be calculated in the URS and in OQ write the tests to test each cell more in detail, is that correct?
OK, I see what you mean I would call it a combined URS/FDS document and then develop your testing from that.
Well, it’s not even a combined URS/FDS. We just don’t write FS and TDS at all and proceed from URS to an IQ, PQ. Then I think in PQ we will be kind of combining OQ and PQ, so we will perform the tests specifically per cell and state what cell to test and what should be expected. Does that seem like a correct approach?
The detail that you are putting into the URS seems more like FDS detail, so even though you are calling it a URS. If you are just testing off the requirments from the URS then I would say that this level of detail is required in order to fully test at the OQ/PQ phase. Dont forget to include what version of excel you are using and on what OS. As you dont have an IQ place this information into the OQ.
The discussion of number and level of documents aside, I don’t think getting down to which specific cell contains the formulas is a good approach. That locks you down too tightly. The only time I could see doing that is if another application requrired the formula (or results) in a specific cell. If you’re going to have a single spec-level document, I don’t see any problem with specifying the formulas that “shall” be used. That can certainly be verified.
We have, at times, used the test procedures to resolve ambiguities in the specifications. Certainly that’s not ideal but a) it works and b) it’s been accepted so far (US FDA). You can’t take that approach to completely eliminate the specifications, though! 
Thanks Yodon, good points
The URS is the single most important document in the validation chain. I can hear the cries of utter nonsense, from here. But it is true, no URS – translates to nobody wants anything.
The URS is an active document throughout (at the very least) the design live of a system (whether software is used or not).
The end user lists what he wants A (the required item) to do and goes on to detail anything else that needs to be specified for the end user to use the equipment.
i.e.
Must be bench-top mounted
Must be powered of 230 volts ac.
Training needs.
Manuals
Validation Documentation.
Any other operator specific requirements.
At this stage (if A warrants it) a validation plan is authored and approved.
These two documents go to the vendors – be they internal or external.
The vendors enter into discussion and are narrowed down by selective processes. (which will include an audit for product critical equipment)
They may each be asked to produce a Function Specification for review by the client.
When a vendor is appointed they are given the URS to complete.
Section one of the URS (detailing the operability) was completed by the end user
The functionality that is required to achieve the end-users operability, must be listed (by the vendor) in the URS and each single function must be link to its requirement.
Where software is used, the code writer must now link their lines of, or groups of lines of code, to the individual function they deliver.
You can see that the URS is a live interactive document right up to the time when A is ready for SAT.
Now you have traceability from the operators requirements to the individual lines of code that are used to deliver the requirement. This allows much easier code modifications, validation justifications, and compliance.
This traceability is mandated for GAMP category 5 software. It is very often difficult instigate. Do not expect software writers to conform willingly, generally I have found you must detail all these requirements in the VP, to ensure all your vendors know the full details of your requirements.
Alex Kennedy
Hi Alex,
Out of interest what are your opinions on a system that has already gone live without any validation at all (Yes this has happened believe it or not, I am currently working with a small pharam and validation was never even mentioned)
Retrospecively I assume all of the above still needs to be followed.
What are your views?
Regards
Hi Graham
No validation - means your product cannot be sold into the pharmaceutical or medical device market anywhere in the world (every country has regulatory compliance requirements).
Sell in the USA, and if you are from the USA you face fines – prison – product destruction and the most costly of all – total product recall.
If you export into the USA (e.g. your not indigenous to the USA) market, all your product will be banned from the market and total product recall will be enforced. If you fail to do this to the required standard, it will be done for you, and charged to you.
No validation means all your product trials and testing are void – you cannot use none-validated equipment to produce data required by predicate rules.
All this work will have been done and it is completely wasted. Retrospective validation only qualifies the product produced post validation. Product produced prior to validation should and must all be considered adultered.
Total product recall means accounting for each item of product manufactured, and proving through a qualified reconciliation, that it is all destroyed or back in the manufacturers facility.
This means accounting and collecting from;
Manufacturer – wholesaler – shipping/air/road freight – exporters – foreign importers – foreign distributors – all retailers domestic and foreign – end users worldwide.
I personally cannot recall any company that was subjected to a total product call and that survived and continued in business.
Validation is a legal requirement and the regulators have all the power they need to make everyone aware of this. They actually have quite draconian powers.
Alex Kennedy
Sorry Alex i should have been more specific.
The company in questions has an electronic document management system, that is/will house all of their SOP’s, important documents, invoices etc. At the moment the system is live but a paper record of all documents also exists with wet signatures (the system does not have electronic sign-off yet)
The primary records are still the signed off paper documents. What they want to do is stop the paper and just have an electronic repository of all their documents (Of course electronic signatures will also have to implement into the system).
I am currently developing the MVP which includes all of the necessary documents they need in order to comply and be fully validated.
For example do I need to do a vendor audit retrospectively even though the system has already being purchased and should I get the vendor to implement the electronic signature module before I start the project (this will really slow down the project)
Any input would be great.
Cheers
Can you convince them to validate without electronic records and then in a follow-on effort, validate just the electronic records part (with possible some limited re-validation of the other parts)? Maybe that can get them in production quicker.
As far as the vendor qualification goes, I don’t think a retrospective audit adds any value. You may want to gather data to at least show they are a qualified supplier. There’s already exposure in Purchasing Controls here (either they had processes in place and didn’t follow them or they don’t have procedures) so you’re already in damage control. Either way, probably a CAPA is in order.
Good luck… would be interested to hear what does get done and how things turn out.
Hi
You must carry out your risk assessment, and pay particular attention to high risk data. If your system (to be) is the protector of this data then your system must follow the full life cycle validation process (FLCV).
This means producing enough life cycle information to convince yourself, and verify for the regulators that the software was designed and constructed in accordance with a an approved quality plan. That all aspects of the software from concept to FAT, were documented and tested.
If you are working with one of the reputable manufacturers of FLCV software they will be able to supply the documented history you require.
If you are working with a COTS supplier - you haven’t a hope.
A good starting point is to execute a DQ - can the item to be purchased deliver the requirements of your URS and conform to all FDA rules and regulations.
At the end of the day, the regulators always want to know (documented) that you knew exactly what you wanted to purchase (URS) and that you documented evidence, that what you are purchasing is fit for that purpose (DQ).
In closing let me say it is impossible to put together a FLCV package retrospectively.
Sweeping statement - Yes - so let me qualify it by saying - the cost would be totally unrealistic.
Alex Kennedy