b Bedeoan
on

 

Hi all,

Please see below a set of observations made after running some tests with Validator 1.5 on some SEND datasets. The info was also sent by e-mail, but is also shared here for the public review.

#1. SE2315    "No result modifier (--RESMOD) qualifer for MA/MI/TF domain"
The newly implemented rule is reporting false positive warnings.
Please see some of our previous discussions on this subject here: http://www.opencdisc.org/forum/fda-rule-implementation#comment-1292

My interpretation for rule NONCLIN-0057 is that: if --ORRES has some modifiers, other than --SEV, they should be present in --SUPP on a new row with QNAM=--RESMOD and QVAL = concatenated modifiers.

Example #1: For MAORRES="Foci dark, mucosa", MASTRESC="Foci", and "dark; mucosa" goes in SUPPMA.
Example #2: For MAORRES="Congestion, left lobe moderate", MASTRESC="Congestion" and MASEV="moderate", so just "left lobe" goes in SUPPMA.
Example #3: FOR MAORRES="No necropsy observations noted", MASTRESC="Normal", nothing should go in SUPPMA - this is the scenario for which SE2315 is incorrectly reported.

We could reduce the number of false positive warnings by skipping records where MASTRESC equalsIgnoreCase "Normal", but this would still not be enough.
And we could also identify if the pathology observation has modifiers or not by comparing MASTRESC from MAORRES (since MAORRES is by definition MASTRESC + modifiers in comma separated list).

I guess we could extend SE2315 by adding a "When" clause for MASTRESC != MAORRES and MASTRESC != "Normal"; this would not cover all scenarios, but at least would reduce the false positive warnings.
What do you think?

#2. SE0063 "SEND/dataset variable label mismatch"
This warning is reported for LBSTNRC.
I recommend correcting the label for LBSTNRC from "Reference Range for Char Rslt-Std Units" to "Reference Range for Char Rslt-Std Unit" (no "s" at the end, as it is in the SEND specs).
Previous discussion also here: http://www.opencdisc.org/forum/validator-141-some-incorrect-validations-pp-pc

#3. CT0051    "Value for PCSTRESU not found in (UNIT) CT codelist" and CT0050 "Value for PCORRESU not found in (UNIT) CT codelist"
These 2 Controlled Terminology warnings are reported for PCSTRESU / PCORRESU, but the 2 PC variables are under a different CT: C85494=(PKUNIT, PK Parameter Units of Measure).
The correct CT rules for PC units are CT0086 and CT0087; they should be assigned to PC instead of CT0050 and CT0051.

#4. CT0051    "Value for VSSTRESU not found in (UNIT) CT codelist" and CT0050    "Value for VSORRESU not found in (UNIT) CT codelist"
Same observation as above: VSSTRESU and VSORRESU are not controlled by the (UNIT) CT, but by C66770=(VSRESU, Units for Vital Signs Results).
The correct CT rules for VS units are CT0086 and CT0087, which are already assigned to VS; CT0050 and CT0051 should be removed from VS.

#5. SD0026 and SD0029

The SD0026 and SD0029 provide false positive warnings for measures without units (e.g. pH).

The SD0026 and SD0029 rules already seem to exclude situations when TEST contains "Ratio" or "Antibody" and TESTCD contains "PH" or "SPGRAV". But more input is needed (for measures withoit units), so that th rules are extended to skip more then "Ratio" , "Antibody" etc.

#6. SD1079    "Variable is in wrong order within domain"
This warning is reported for MIMETHOD, TFMETHOD and PPSTINT.
I suggest moving MI.MIMETHOD before MI.MILOC, TF.TFMETHOD before TF.TFLOC, and PP.PPSTINT before PP.PPENINT, in the SEND config file, to prevent this warning.
Previous discussion here: http://www.opencdisc.org/forum/validator-141-some-incorrect-validations-pp-pc.

#7. SD1122    "Missing value for SCSTRESN"
This warning is reported for SC Subject Characteristics, when SCORRES = SCTRESC is fed with numeric values (in our situation is the ALTID Alternate Identifier of the animal).
The SD1122 rule is correctly defined from my perspective, but maybe it should be disabled for SC? Since by the domain's definition we should never have to actually feed SCSTRESN...

#8. SD1085    "FWDY variable value is imputed" and SD1093    "FWENDY variable value is imputed"
This warning is reported for FW records related to a POOLID and not to a USUBJID, since the rule verifies that: --DY/--ENDY should be populated when both --DTC and RFSTDTC are provided and both of them include complete date part, and for POOLID fed the RFSTDTC is not known.
We could extend SD1085 and SD1093 so that they don't apply when POOLID is fed instead of USUBJID. What do you think?

Best regards,

Amelia

 

Forums: SEND

s Sergiy
on April 15, 2014

Hi Amelia, 

Thanks for your findings!

#1. Rule SE2315 was modified to exclude Normal results: When="USUBJID != '' @and %Domain%STRESC != 'NORMAL'"

#2. Label for LBSTNRC was fixed to "Reference Range for Char Rslt-Std Unit"

#3. We believe that there is a typo in SEND IG about CT for PCORRESU and PCSTRESU. E.g., a name for PKUNIT is "PK Parameter Units of Measure"; assignments in SDTM IG are different; most units include time portions their associated tests are expected to be derived, rather than collected.

We still keep CT0051 and assigned to PC domain and adjusted descriptions of CT0086-87 rules by removing a reference to PC domain.

#4. CT0050 and CT0051 rules were removed from VS domain and added to all other FINDINGS and INTERVENTIONS domains (except PP and DD) 

#5. Please confirm that you have False-Positive messages for pH. Do you use LBTESTCD="PH"?

#6. There is inconsistency in SEND IG and SDTM Model about order of variables. According to SEND IG an order of variables within datasets should be done as specified in SDTM Model.

 

  • MIMETHOD is an example, when SEND IG has a different position for the variable.
  • --STINT and --ENINT variables are already ordered as you suggested. Please check if in your MI dataset you have any other variables after those two. 

 

Note, than --STINT and --ENINT variables were added only in SDTM v1.4 published in Dec 2013, while SEND IG has used these variables since May 2011. There is two and a half year delay.

#7. We removed SD1122 from SC domain as you suggested.

#8. We modified SD1085 and two other similar rules SD1089, -93 to be applied only to subject level records.

I've emailed you an updated configuration file for testing.

Thank you for your help!

Kind Regards, 

Sergiy

 

m Michael
on April 15, 2014

I had modified SE2315 shortly after the release to only run when –STRESC != ‘NORMAL’ .   It can easily be extended to add @and %Domain%STRESC != %Domain%ORRES

 

What other cases for false positive would still be present ?

b Bedeoan
on April 16, 2014

Hi Sergiy,

Thank you for the fast feedback. I looked at the updates you just did and I have a few small observations:

#9. CT0050 and CT0051 were added to EX, but they should not, since EX does not have ORRESU and STRESU. The units in EX are stored under EXDOSU (Dose Units) and EXVAMTU (Amount Administered Units).

I haven't found any rules to verify that these 2 columns are part of the UNIT CT. Maybe you can add two rules similar to CT0050 and CT0051, but applied to EXDOSU and EXVAMTU and only for the EX domain?

#10. CT0050 and CT0051 were added to CL, but the standard domain definition for CL does not contain ORRESU and STRESU. I don't know if it's necessary to keep these 2 rules in CL, in the idea that someone might add ORRESU and STRESU in CL althought not in the standard; what do you think?

#11. Same observation for CT0050 and CT0051 added to MA: MA does not contain ORRESU and STRESU.

Best regards,

Amelia

 

 

b Bedeoan
on April 16, 2014

Some other comments related to the observations from the previous message:

#2. The label for LBSTNRC does not seem to be updated in the config-send-3.0 FIXED 20140415.xml file you sent.

#3. Are you sure about keeping CT0050 and CT0051 for PC units and not moving them on CT0086 and CT0087?

E.g. I'm looking at some PC files we received and the unit of measure is "ng/mL" for PCSPEC=PLASMA; and this unit of measure is present in CT just for PKUNIT, and not for UNIT. I do not have enough examples to draw a conclusion; maybe someone else can also share their experience here?

#5. You are right, I'm not getting a false positive warning for SD0026 and SD0029 when LBTESTCD=PH, just when LBTESTCD=pH. I know that the CT value should be toUpperCase (so "PH" not "pH"), but could we extend the rules SD0026 and SD0029 to check equalsIgnoreCase instead of just equals?

#6. You are saying that we should follow the order of variables as recommended by SDTM, and not the one from SENDIGv3.pdf? And do nothing in the config-send-3.0.xml file, but rather change the order of columns in the dataset, for MI, TF and PP?

#8. The rules SD1085 and SD1093 were incorrectly updated (the condition for @and USUBJID !=''" should be outside the parantesis). See below the correction:

<val:Condition ID="SD1085" Message="%Domain%DY variable value is imputed" Description="Collection Study Day (--DY) variable value should be not be imputed. It may be only populated, when both Collection Study Date/Time (--DTC) and Subject Reference Start Date/Time (RFSTDTC) variables values are provided and both of them include complete date part." Category="Presence" Type="Warning" Test="%Domain%DY == &apos;&apos;" When="!(SUB:RFSTDTC @re &apos;\d{4}-\d{2}-\d{2}.*&apos; @and %Domain%DTC @re &apos;\d{4}-\d{2}-\d{2}.*&apos;) @and USUBJID !=&apos;&apos;" />

and

<val:Condition ID="SD1093" Message="%Domain%ENDY variable value is imputed" Description="Study Day of End (--ENDY) variable value should be not be imputed. It may be only populated, when both End Study Date/Time (--ENDTC) and Subject Reference Start Date/Time (RFSTDTC) variables values are provided, and both of them include complete date part." Category="Presence" Type="Warning" Test="%Domain%ENDY == &apos;&apos;" When="!(SUB:RFSTDTC @re &apos;\d{4}-\d{2}-\d{2}.*&apos; @and %Domain%ENDTC @re &apos;\d{4}-\d{2}-\d{2}.*&apos;) @and USUBJID !=&apos;&apos;" />

b Bedeoan
on April 16, 2014

Hi Michael,

I have added in my config file the condition for STRESC !=ORRES and at the first tests everything is working properly; no more false positive warnings.

I will extend my tests scenarios anyway and let you know if I still find something.

Congrats for all the hard work and the great results!

Amelia

 

l Laura
on April 16, 2014

Hi all:

Re: which codelist to use for PC domain

The PKUNIT codelist, specified by SENDIG for use with the PC domain, includes CDISC submission values that include time (eg, L/kg/day) as well as some that do not include time (eg, ng/mL and ug/mL). Therefore, the PKUNIT codelist is applicable to both the PC and PP domains. I agree with Amelia that the correct rules for PC units for the PC domain should be CT0086 and CT0087. 

Best, Laura

l Laura
on April 16, 2014

Re: Item 5 in Amelia's and Sergiy's Posts for SD0026 and SD0029

Many urinalysis measurements and microscopic evaluations of blood smears are qualitative, and these are being flagged as false positive warnings by SD0026 and SD0029. See page 97 in SENDIG 3.0 for an example of an LB domain populated with qualitative (or categorical) data. 

The following qualitative urinalysis measurements were incorrectly flagged in our tests:

Tyrosine Crystals

Calcium Phosphate Crystals

Squamous Epithelial Cells

Bacteria

Calcium Sulphate

Spermatozoa

Waxy Casts

Calcium Carbonate Crystals

Uric Acid Crystals

Erythrocytes

Yeast Cells

Epithelial Casts

Leukocytes

Fat Droplet

Tubular Casts

Granular Casts

Tubular Epithelial Cells

Epithelial Cells

Cystine Crystals

Starch Crystals

Calcium Oxalate Crystals

Fatty Casts

Amorphous Sediment

WBC Casts

Cholesterol Crystals

Hyaline Casts

Bilirubin Crystals

Triple Phosphate Crystals

RBC Casts

Also consider filters for the following urinary parameters, if you don't already have them: Protein, Ketones, Urobilinogen, Glucose, Color  

 

The following qualitative blood abnormalities were incorrectly flagged in our tests:

Hypochromia

Macrocytes

Hyperchromia

Microcytes

Macrocytes

Large Unstained Cells

Large Platelets

Platelet Clumps

Anisocytes

These rules should be extensible, as the lists above are not exhaustive and the number of parameters is very large. 

Best, Laura

 

 

 

 

 

 

 

 

 

 

 

l Laura
on April 17, 2014

SD1117 "Duplicate Records"

We are finding that this rule is resulting in false positives for MA, MI, LB, PP.

This could be fixed by use of Keys as presented in SENDIG 3.0, Table 3.2.1 Dataset Definition Metadata.

Best, Laura

 

Want a demo?

Let’s Talk.

We're eager to share and ready to listen.

Cookie Policy

Pinnacle 21 uses cookies to make our site easier for you to use. By continuing to use this website, you agree to our use of cookies. For more info visit our Privacy Policy.