Custom Field Experts
Would I be right in saying its coded as follows:
ABS(((A.1.(Area)-B.1.(Area)))/((A.1.(Area)+B.1.(Area))/2)*100.
Or are there too many brackets, or maybe Empower cant do two divisions in one cf? Anyone out there with any insight? I'm trying to keep my list of custom fields as short as possible.
Best Answer
-
If it were up to me:
SS1 custom field: SS1.%.%.AVE(Area)
SS1_RRF custom field: SS1/Amount
CHK custom field: CHK.%.%.AVE(Area)
CHK_RRF: CHK/Amount
Difference custom field: ((SS1_RRF - CHK_RRF)/(0.5*(SS1_RRF+CHK_RRF)))*100
And finally a field to bind them all into one:
EQ(Label,"SS1")*SS1 + EQ(Label,"CHK")*Difference
This last field will allow you to report your RSD of the first standard and the % difference of the second standard from the same custom field in a report, assuming you use the proper table and order the standards appropriately.
2
Answers
-
Empower should not have a problem calculating this for you. However, your syntax is slightly incorrect.
Conventions for pulling peak parameters from named components are as follows:
Compound1_Name[Area]
Compound2_Name[Area]
Substitute what I have above for your A.1.(Area), etc...
Is your intention of the custom fields you have written to be in the format of W.X.Y.Z(Parameter), where W=label, X=injection; Y=channel; Z=Function (AVE, SUM, etc); Parameter=peak property? If yes, then that is not the approach you want to take as the suggestion above is much easier.
1 -
Hi shaunwat, yes I intend to keep it as Label.Injection.Channel.Function(Field) as A.1.(Area). There is only one active in the injections so I don't need to specify a CCalRef1 peak to keep memory low.
However, its taken a lot of failed attempts before I got the bracketing right. I was advised by a Waters employee to "specify" bracketed calculations as much as possible. For example, for adding two cfs and dividing by two, its not A.1.(Area)+B.1.(Area)/2, its actually ((A.1.(Area)+B.1.(Area)/2)), otherwise the former calculation will just add the Area in A to half the Area in B!
Its only through trial and error that I got the hang of these brackets. I wonder is there a coding guide to Empower custom fields?
0 -
Well, you are making the calculation much more difficult than it needs to be by the use of an intersample caculation. However, if that is the way you want to skin the cat, then go for it!
I've yet to find any truly good references for Empower calculations. I've gotten where I am at by 15+ years of experience and trial and error. You can do some pretty amazing calculations in Empower (dissolution, content uniformity, impurities with specs and processing), but it will take a while to get there...
0 -
Thanks for reply shaunwat. I know what you are saying about making it difficult but I'm tied to intersample calculations because my calculation is: (weight adjusted peak areas of Standard A plus Standard B/mean of weight adjusted areas of A and
so I inject Std A once then Std B. I'm stuck with intersample calculations. But its handy to know that shortcut for samples with just 1 injection.
I wonder who exactly codes and validates the custom fields in Empower, someone obviously is responsible for it and they need to have specialist knowledge. It would be an interesting job in my opinion.
0 -
Weight adjusted as in normalized response?
I've run across the cvustomization folks at Waters from time to time... You will eventually get there, but it will take time (I've coded Water's disso option for Empower when I worked for a company that did not want to purchase). That involved some fancy work...
Never having used the disso option in Empower, I would suspect Waters offloads to some other application to perform the math and specification checking via the toolkit, but I've got no direct proof of that other than coding everything with custom fields required significant creativity on my end.
1 -
Yes, we need to weight adjust the areas, so I typically multiply the area in "A" by CConst3/CConst1 (theretical weight/actual sample weight). So my first weight adjusted custom field is A.%.(area)*(CConst3/CConst1). Weight adjusting is normalising right?
I am sorry if these questions are a tad basic, I am still learning myself and as the memory from my custom fields testing project can testify, I have had to try about 50 times before I got one to work right. Particularly hard to get used to was the bracketing. I was advised to always add an extra set for safety and to really tie down your intention, so a cf like Amount/Label Claim * CConst1/CConst2 becomes (Amount/LabelClaim)*((CConst1/CConst2)) etc.
0 -
I'm not sure of the intention to multiuply the theoretical sample weight divided by the actual sample weight, but then again I don't really know what the end result of your calculation is.
What are you trying to achieve?
If you are adjusting sample weights in the manner that you descrive, then what happens when you test more than one sample. Using the CConst metric in the processing method only allows for one variable to be stored. Or are you using the term "sample" and "standard" weight interchangably?
Are you trying to calculate a % difference for a check standard?
0 -
Hi shsunwat. The calculation is a standard compliance. Before we can run any samples like assay swabs blends etc we must test the % difference between 2 working standards.
Typically we prep 2 working standards and then the calculation for % difference is:
Difference between weight adjusted areas/mean of weight adjusted areas *100 and the spec is typically not more than 2% difference. If it passes this spec then either working standard may be used for running samples.
We use this calculation site wide for every product we have.0 -
you'd do W1/A1 x A2/W2 than -1 x 100. i think ICH have the limit at 3.0%0
