Verification of Custom fields on Empower

[StephenO]

After creating custom fields to calculate the amount of active in a sample what is the best way to verify that the custom field is working properely. In that what would the regulatory authorities accept as sufficient.

[Johnny Rod]

Get reports with both the custom calc results and the data that goes into them (peak areas etc.) then show in the protocol that the calculation is correct. You should also be able to get a printout of some sort showing what the custom field contains (the formula), even if it's only a screen shot. If it's a validated system then the real info is in there, the screen shot etc. just demonstrates this.

[StephenO]

Thanks for your help Johnny

[ydna1977]

Hi ,

Anybody want to expand on this?
Would test scripts not be a useful documentation of custom field testing or is that overkill..
Or document custom field in bound lab book with formula explained and checked ?
Any testing would only be once since custom field would be locked under super user and then used where required for other projects?
Thanks

[DR]

Good documentation and change control are both good ideas.
Scripting is probably well outside the Empower/Oracle EULA.

[ydna1977]

Thanks ,

What about an amendment to custom fields that is outwith the Empower COTs package, (commercial off the shelf)

Only additional validation will be required here ?

As it has been effectively reconfigured as now going from COTs GAMP 3 to GAMP 4 plus to meeting Annex 11 requirements.

Any thoughts please share

[DR]

Anything you write will have to be verified/validated & documented. The only off the shelf packages are for GPC, Dissolution and maybe one or two other things and even these require a little verification to make sure that *You're using them correctly and getting the results expected.

[ydna1977]

Hi ,

Thanks for the information
Just to clarify 'any custom field will need to validated /verified

So for example a simple formula : SUM (PK_NormalisedArea)
This will be using custom field program /wizard and is part of the COTS software will need to verified ?

On the other hand a more complicated formula :
REPLACE(Cconst1,1)*(Area-BLANK.%.SAME(Area))*(GTE(Area-BLANK.%.SAME(Area),0))
THis will require more scrutiny

But once checked /verified and custom fields locked this can be used for other projects without further checks due to custom fields locked by privilege levels?

Just trying to get some balance on compliance , efficiencies (is it worth time and effort creating custom fields if documentation /testing takes twice as long !) and current acceptable practices on this subject

Thanks

[scottythree]

I suggest that if you are in a regulated realm that you put forth effort towards an SOP for custom calculations defining "this is what they are" and "this is what we do" in terms of verification of functionality. The hard line approach is that if a calculation is not a default one provided under the original packaged validation then it is a custom calculation that needs verification (no matter how simple). Once proven then lock it and use it! Without such an SOP I would be cringing upon inspection by a regulating body.

I find it very similar to the back in the day, but still current, spreadsheet calculation/functions. I figure we all have had to deal with this one within the last 20 years...We are doing the same thing but now we do not have to export the data to a third party platform for our calculations.

[ydna1977]

Hi ,

Thanks for the advice

So documents worth considering :

SOP to cover use, control, admin and testing of custom fields
Test scripts to document and creation/verification of formula

Thanks

[shaun78]

I've always used a GAMP 5 type approach for commercial software that is user customizable.

In instances like your example above, depending upon complexity I have used an approach of "if the result come out right in the end, then the individual pieces must be working" depending upon the number of logic checks being performed by the custom fields.