Calculations – Dive into Syntax

1. Calculations – Dive into Syntax James R. Pomicter, BS,MLS(ASCP) jamespo@softcomputer.com

2. This presentation will address the following: • What Can Calculations Do • Where To Write Calculations • How To Write Basic Calculations • Examples

3. What Can Calculations Do • Automatically result a test using results from other tests BUN/CREAT ratio Calculate corrected WBC based on NRBC’s • Cancel a test "." • Attach interpretive comment to a result " @MESG"

4. Where To Write Calculations • Individual test 240 characters • RBS 255 characters Multiple time frames Can be used conditionally • Canned messages >240 characters ID entered in individual test or RBS as <<CMSG>>

5. How To Write Basic Calculations • Use Only Individual Tests when evaluating result level. • All tests included in calculation must be in the same order number [Except RBS rules] • Best Practice: Do NOT use special characters in Test ID

6. Calculations Basic Math – Algebra Level

7. Syntax - Operators

8. Dive into Syntax Simplified history of formulas evolution to illustrate @TID operators. @TID (Numeric Result) Originally, RBS formulas were pretty primitive and user couldn't enter textual formulas directly. RBS generated them internally based on the logic grid in RBS setup. In calculations you could only access test result field (ARESULT) numerically via “sea-monkey" operator @TID. It was the only “sea-monkey" operator available. There were only a few numeric result comparison operators (like "!=" or "<") and numeric functions (LOG, EXP) available at that time in calculations. And you couldn't access any other test field except ARESULT (result field) via @TID.   

9. Dive into Syntax @@TID (Result and Result Flag (ranges e.g. Abnormal, Absurd, Panic, etc.) Then, there was a need to have rules based on result flags (AFLAGS2) too, not just result, which is another test field beside ARESULT, to check and fire RBS based on abnormal flags. So RBS had to be extended in order to be able to refer to that field (AFLAGS2) somehow. And the solution was to add another test “sea-monkey" operator to refer to that field and @@TID operator was invented.

10. Dive into Syntax #@TID (Same as ANY(TID) – is this test ID present on the order) Then, there was a need for RBS to fire only in case a test is ordered, regardless of result being present. And another “sea-monkey" operator (#@TID) was invented.

11. Dive into Syntax $@TID (Alphanumeric result) Then, there was a need to check alphanumeric results too. The solution was to extend RBS and add $@TID “sea-monkey" operator to refer to test result alphanumerically. New functions like MATCH were added also, to allow alphanumeric comparisons.

12. Dive into Syntax DBFLD (Database Field) Then, there was a need to check some other test fields and even fields from other records, like patient or stay or order. It was clear at this point that adding more “sea-monkey" operators to refer to different fields would be cumbersome. This resulted in inception of DBFLD function.  

13. Dive into Syntax GETDBF and@TID->"TFLD“ (Get Database field) Then, there was a deficiency discovered related to DBFLD. If we used DBFLD("TID", "FLDID") in RBS, RBS didn't know that test TID was used on the formula. RBS only knows if a test is being used on the formula if we use one of the “sea-monkey" operators with the test id, like @TID. So DBFLD was deprecated. GETDBF was invented to access fields from other than test records and @TID->"TFLD" operator was added to access test fields only.

14. Dive into Syntax “Sea-monkey" operators have another function. They hint RBS on how to search for those tests in db. For example, if we use #@TID, RBS only checks if test is ordered and doesn't read test data. So referring to test field via #@TID->"TFLD" in RBS often doesn't work. It was actually syntax error to write #@TID->"TFLD“. You could only use @TID->"TFLD". In the case of operator @TID, RBS reads the test but only if there is a result and test is not cancelled. So it is impossible to check test field via @TID->"TFLD" in RBS if test is not resulted or is cancelled. (See the next for the fix. ) 

15. Dive into Syntax ^@TID (Test Flags (regular e.g. Collected, Received, Posted, Verified, Rerun, etc.) Then came a need to check regular test flags in RBS (AFLAGS1). At this point we could use @TID->"AFLAGS1" but there is a problem here as mentioned in the previous chapter. RBS, when it sees @TID, it only reads the test if there is a result present. But "AFLAGS1" can have collection flags set before test resulting and we wouldn't be able to inspect them until resulting. The solution was to invent one more “sea-monkey" operator (^@TID) and tell RBS that if you see this “sea-monkey", read the test data even if there is no result. This way we can check for example test collection on not resulted test in RBS by writing ^@TID->"ISCOLL"

16. Dive into Syntax Summary And this is how we ended up with 5 different "monkey" operators (@TID, @@TID, #@TID, $@TID, ^@TID). And we can use any of them to refer to any test field, like: @TID->"AFLAGS1", #@TID->"AFLAGS2", ^@TID->"ACOUNTER", etc. There are some redundancies: $@TID returns the same as @TID->"ARESULT" @@TID returns the same as @TID->"AFLAGS2" ^@TID returns the same as @TID->"AFLAGS1"

17. Dive into Syntax • @ = Numeric result • Example: @GLU reads as “Numeric result of test GLU” • BUN/CREAT Ratio • @BUN/@CREAT • Straight quote marks Only - typically used to specify alphanumeric characters in a result field. • "POSITIVE" • " @CANN" • Should use straight "quotes"Not“quotes” or “quotes” • Be careful when Copying and Pasting from Word or e-mails because these will use a different style of quotation marks, e.g.,- “quotes”. • Write the Calculations inside the application or use Notepad if you want to Copy/Paste 

18. Calculations - Common • True/False • ? = • : = If this is true • If this happens ? Then do this : Otherwise do this • Condition ? Command if true : Command if false Otherwise do this @DIG<0.2?"NONE DETECTED":@DIG @DIG<0.2?"<0.2":@DIG If the numeric value of DIG test is less than 0.2, and that is True, result NONE DETECTED. Otherwise result the numeric value of DIG.

19. Numeric Test With An Alphanumeric Result • @DIG<0.2? "<0.2 ":@DIG What if DIG results >5 also need to be converted to report as ">5" ?

20. We Need More Syntax • Syntax • We need to string together “If This is True/Otherwise Do This” expressions • Keep in mind: For every true statement we MUST have and Otherwise statement • ? = • : = If this is true Otherwise do this • @DIG<0.2 ?"<0.2" :(@DIG>5.0?">5" :$@DIG) • $@DIG = the Alphanumeric result of DIG at the end of the calculation ensures that any alphanumeric result in the result field will be maintained e.g. 2.2 @CONF

21. String Multiple True/False Conditions @SWEAT=40?@SWEAT+"@SWTN":(@SWEAT=60?@SWEAT+"@SWTP":(@SWEAT=80?@SWEAT+"@SWTQ":@SWEAT+"@SWTB")) TIP Count all of your Open Parentheses and make sure you have the EXACT same number of Closing Parenthesis  @FHGBR>=0.0000&&@FHGBR<=0.0045?"1": (@FHGBR>=0.0046&&@FHGBR<0.0091?"3": (@FHGBR>=0.0091&&@FHGBR<0.0136?"4": (@FHGBR>=0.0136&&@FHGBR<0.0181?"5": (@FHGBR>=0.0181&&@FHGBR<0.0226?"6": (@FHGBR>=0.0226&&@FHGBR<0.0271?"7": (@FHGBR>=0.0271&&@FHGBR<0.0315?"8": "Not Indicated"))))))

22. Need More than1 Conditionto be True && = AND = expressions/ conditions on Both sides of the && symbols must be met for the expression to be True @HGB>5 && @HCT<20? "BAD" : "GOOD“ Only if the result of the HGB is less than 5 AND the result of the HCT is less than 20 will the word BAD be placed in the result field of this test. Otherwise, if either of these are not true, will the word GOOD be placed in the result field.

23. Need Only1 Condition to be True || = expression/ condition on Either side of the || symbols must be met for the expression to be True $@UCOLR=="Brown" || $@UCOLR=="Red" || $@UBLD == "Trace-intact" || $@UBLD == "Trace-Intact" || $@UBLD == "TRACE-INTACT" || $@UBLD == "Trace-lysed" || $@UBLD == "Trace-Lysed" || $@UBLD == "Trace-LYSED" || $@UBLD == "1+" || $@UBLD == "2+" || $@UBLD == "3+" || $@ULEU == "Trace" || $@ULEU == "1+" || $@ULEU == "2+" || $@ULEU == "3+" || • $@UNIT == "Positive" ? "See Microscopic" : "Not Indicated"

24. Is the Test ID Resulted On The Order? • ANY() or# = Looking to see if test has been resulted ANY(@AUER)?@BLAST +" @LEUK":@BLAST Same as #@AUER?@BLAST + " @LEUK" :@BLAST

25. Serial Tests – Lactic Acid • Setup a Series test to include as many Lactic Acid draws as needed and set them to be drawn X hours apart. • My example is set to have a subsequent LA drawn 3 hours after the first. • You must build a unique Test ID for each Lactic Acid you want to order/draw e.g. LA, LA3 • LA = Already built Lactic Acid test ID • LA3 = new test created for 3 hour Lactic Acid. [MUST be assigned a different Tube type built/assigned to this test from the original LA] • Calculation on new LA3 test should be @LA<=2.0?".":@LA3

26. Serial Tests – Lactic Acid Combine those individual test ID’s into a Group test. (SERIES TEST must be checked)

27. Examples

28. Examples Calculated Osmolality 9+(1.86*@NA)+(@GLU/18)+(@BUN/2.8) [Used on UBIL Test ID] $@ICTO=="Negative"?"Negative"+" @CNF":(@ICTO=="Result Required"?"Result Required":@UBIL) [Used on ICTO Test ID] $@UBIL != "Negative"?"Result Required":$@ICTO [Used on OVERD Test ID] ( (@ACETM > 50) && (@H > 500) ) || ( (@ACETM > 30 && @ACETM < 50) && (@H > 250) ) || ( (@ACETM > 15 && @ACETM < 30) && (@H > 40))

29. Calculation Addition and/or Modification In a post-live environment, it becomes important to protect historical data. Care must be taken when modifying calculations so that old results are not affected. There are three options to preserving historical information:

30. Option #1 Calculation Addition and/or Modification 1. Create a new test and inactivate the old test.

31. Calculation - Addition Option # 2 With a command, tell the system to only perform the calculation before or after a specified date. The GETDBF function works well in this situation. Example: Because of a new methodology, all Vitamin D (VITD) instrument results must be multiplied by .04 The new methodology will take place on Jan. 1, 2018 It was been decided to retain the original test ID, so a calculation will be entered in VITD to only perform the calculation after the specific date. GETDBF("ACCDATE")<20180101?$@VITD:@VITD*0.04 TIP – Build your Calculation as a Canned Message…you’ll be glad you did if you ever need to change it . Place the following in the Calculation field of the Individual Test. <<CANMG>> This calculation looks at the order collection date (ACCDATE) and if it’s before 01/01/2018, the result will stay the same. If it’s after that date, the result will be multiplied by .04 In the calculation the date format must follow YYYYMMDD

32. Calculation - Modification Option #3 Use the expiration date functionality in the Canned Message setup file. Once the calculation is entered into a Canned Message then the Canned Message ID is entered in the Individual Test calculation field. When the Canned Message ID is entered into the calculation field, it must be in a specific syntax so that the individual test evaluates the expiration date field of the Canned Message. MESEXPDATE("MES",GETDBF("ACCDATE"));<<MES>>

33. Preserve Historical Data MESEXPDATE(<expr1>,<expr2>) Checks the expiration date for the canned messages used in the calculation where <expr1>returns the code of the message <expr2> returns the date according which program will search for the message. Example: MESEXPDATE("MES",GETDBF(ACCDATE"));<<MES>> This calculation is using function MESEXPDATE, which is looking at the canned message expiration date for message “MES” and comparing it to the order collection date (ACCDATE).

34. Easy Steps To Follow Create a Canned Message (Type=Other) with the OLD calculation. Expire this Canned Message. Create a NEW Canned Message calculation, using the OLD canned message ID (The Canned Message ID’s will be the Same) Enter the new calculation. This Canned Message will NOT be expired as the old one was. Save the message. Place the new canned message ID in the calculation box of the Individual test following the format below. MESEXPDATE("MES",GETDBF("ACCDATE"));<<MES>>

35. Create a Canned Message (Type=Other) with the OLD calculation. Expire this Canned Message

36. Create a NEW Canned Message calculation, using the OLD canned message ID (The Canned Message ID’s will be the Same) Enter the new calculation. This Canned Message will NOT be expired as the old one was. Save the message

37. Don’t Forget About The Translation Table

38. Test Maintenance

39. Don’t Forget About The Values Tab

40. Variables are helpful when writing long calculationsand/or calculations that have the same expressionsused multiple times. Variables

41. Variables • OneCapital letter code can be used in different calculations as needed. The definition of the Variable by single letter is specific ONLY to that calculation and does not carry-over to any other variable calculation. Maximum defined Variables per calculation = 26 [Letters A – Z] Only $C:=@CAT+@DOG; $A:=@FAST+@SLOW; 186*$C*$A Same as… 186*(@CAT+@DOG)*(@FAST+@SLOW) Notice the semi-colon after each variable definition. This semi-colon tells the system to perform each part of the calculation consecutively.

42. CKD-EPI GFR calculation The CKD-EPI (Chronic Kidney Disease Epidemiology Collaboration) equation was developed in an effort to create a more precise formula to estimate glomerular filtrate rate (GFR) from serum creatinine and other readily available clinical parameters, especially at when actual GFR is >60 mL/min per 1.73m2. GFR = 141 X min(Scr/κ,1)α X max(Scr/k,1)-1.209 X 0.993Age X 1.018 [if female] X 1.159 [if black] Where Scr is serum creatinine (mg/dL), κ is 0.7 for females and 0.9 for males, α is -0.329 for females and -0.411 for males, min indicates the minimum of Scr/ κ or 1, and max indicates the maximum of Scr/ κ or 1.

43. CKD-EPI GFR calculation <<EGFRA>> - AFRICAN AMERICAN $S:=DBFLD("","SEX")=="F"; $C:=POW(@CREAT/0.7,-0.329); $E:=POW(@CREAT/0.7,-1.209); $A:=POW(0.993,((DBFLD("ACCDATE","AGE"))/365.25)); $G:=POW(@CREAT/0.9,-0.411); $H:=POW(@CREAT/0.9,-1.209); $J:=(@CREAT/0.7)<1?$C:1; $K:=(@CREAT/0.7)>1?$E:1; $L:=(@CREAT/0.9)<1?$G:1; $M:=(@CREAT/0.9)>1?$H:1; $N:=141*$J*$K*$A; $O:=141*$L*$M*$A; $S?(1.018*1.159*$N>=90?">=90":1.018*1.159*$N):(1.159*$O>=90?">=90":1.159*$O)

44. CKD-EPI GFR calculation <<EGFRO>> - NON-AFRICAN AMERICAN $S:=DBFLD("","SEX")=="F"; $C:=POW(@CREAT/0.7,-0.329); $E:=POW(@CREAT/0.7,-1.209); $A:=POW(0.993,((DBFLD("ACCDATE","AGE"))/365.25)); $G:=POW(@CREAT/0.9,-0.411); $H:=POW(@CREAT/0.9,-1.209); $J:=(@CREAT/0.7)<1?$C:1; $K:=(@CREAT/0.7)>1?$E:1; $L:=(@CREAT/0.9)<1?$G:1; $M:=(@CREAT/0.9)>1?$H:1; $N:=141*$J*$K*$A; $O:=141*$L*$M*$A; $S?(1.018*$N>=90?">=90":1.018*$N):($O>=90?">=90":$O)

45. GETDBF Looking at Database Fields in Calculations The ability to look at database fields in calculations started in SoftLab version 3.x with the introduction of function Sometime later another function was added, GETDBF. For most instances, the two functions were interchangeable, except when calculating AGE. [Then DBFLD was superior since it could be written to only calculate the patient’s age at a specific time, like ACCDATE (order collection date)]. This does not mean that calculations already present in the system written using DBFLD need to be changed  There is also a third function that allows us look at database fields. It is known as “test access operator” or “->”.

46. GETDBF With three options available, which is the best to use? That depends! Since the beginning of release 4.0, using GETDBF and ->have been the most prevalent because of the ease of use. Overall, you will find that if assistance in writing calculations is needed or if conversion in RBS takes place, you will only see these two operators.

47. GETDBF • If looking specifically in the Test levelthen it’s best to use the -> operator • For example, if I want to look to see if the SOURCE of the CXURN is URN, I would write it this way: • #@CXURN[0]->"SOURCE" == "URN" • If I want to see if the specimen and workstation for test T5 are LAV and PCHMA, I’d do this: • (@T5->"ASPECIM" == "LAV")&&(@T5->"ATWRKID" == "PCHMA") • If looking at the Patient, Stay, Order level, then best to use the GETDBF • If I want to see if the patient MRN is 123, I’d do this: • GETDBF("MRN")=="123" • If I want to see if the order collection date is before July 13, 2010, I’d do this: • GETDBF("ACCDATE")<20100713

48. GETDBF • Available fields • At the present moment only the following Patientlevel fields can be used in calculation formula: • MRNUM Medical Record NumberSSNUM Social Security NumberSEX Sex/GenderRACE RaceDOB Date of BirthAGE Age of PatientTEL Telephone Number of PatientESO Epidemiologically Significant DiagnosisCITY City of Patient AddressSTATE State of Patient AddressZIP Zip Code of Patient AddressRELIGION Religion of PatientPTOB Patient Time of Birth • DOD Patient Date of Death • TOD Patient Time of Death

49. GETDBF GETDBF("SEX")=="F"? @TESTO+"@CM":$@TESTO If the gender of the patient is F (female) then take the result of test TESTO and add canned message @CM, otherwise just take the result of TESTO. • GETDBF("ACCDATE")>20180214?(MATCH("*@SPH*",$@SPREG)?$@SPREG:$@SPREG+ " @SPH") • If the Collection Date is after date Feb-14-2018 and that is true…Look for a Match of @SPH in any position of the result field for test Serum Pregnancy…if that is true report the Alphanumeric result of Serum Pregnancy test..otherwise…report the Alphanumeric result of Serum Pregnancy test and add Result Canned Message @SPH.

50. GETDBF • Available fields • At the present moment only the following Doctorlevel fields can be used in calculation formula: • DCNUM Doctor Number (ID) - RequestingDCROUTE Doctor Route – Courier RouteDCSERV Doctor Service TypeDCSCHED Doctor ScheduleDCPCSCHED Doctor Pickup ScheduleDCMEDSERV Doctor Medical Service Code GETDBF("DCNUM")=="12045"? @TESTO+"@CM":$@TESTO