a Angela
on

 

Hello all,

 

I am trying to implement a new rule. The rule description is:

Missing values for DSDTDY and --DY and --DTC & RFSDTC. Either of these three timing variables should be populated: [DSSTDY] or [--DY] or [DTC and DM, RFSTDTC].

This rule is applied to OM,MA,MI,TF,DM.

I implemented as follwoing:

<val:Condition ID="0053" Message="Missing values for DSSTDY and %Domain%DY and %Domain%DTC and RFSTDTC. Either of these three timing variables should be populated: [DSSTDY] or [%Domain%DY] or [%Domain%DTC and DM, RFSTDTC]" Description="Required timing variables for identification of the day on which group summaries (Group Means and Incidences) are calculated." Category="Presence" Type="Warning" Test="%Domain%DY!=&apos;&apos; @or (DSSTDY!=&apos;&apos;) @or (%Domain%DTC!= &apos;&apos; @and SUB:RFSTDTC!=&apos;&apos;)" Optional="%Domain%DTC, DSSTDY, RFSTDTC, %Domain%DY"/>

I have a problem with 'looking' from rules domains thorw DS and DM resources. Regarding the implementation I provided to you I tested and it works the part with --DY null and with --DTC and DM.RFSTDTC. It is a problem with accessing the DSSTDY value.

Please advice me how to implement this rule.

Best regards,

Angela 

 

 

Forums: SEND

a Angela
on March 6, 2014

Hi all,

I have other issue with implementing the following rule:

Missing value for --RESMOD. The SUPPQUAL domain records should have QNAM populated with --RESMOD.

This rule is applied to MA,MI,TF.

 

I implemented as follwing:

<val:Lookup ID="0057" Message="Missing values for --RESMOD" Description="Missing values for --RESMOD. The SUPPQUAL domain records should have QNAM variable populated with --RESMOND." Category="Consistency" Type="Warning" Variable="%Domain%SEQ==IDVARVAL" When="QVAL!=&apos;&apos; @and QNAM!=&apos;&apos; @and QVAL!=%Domain%LAT @and QVAL!=%Domain%SEV @and QNAM==&apos;%Domain%RESMOD&apos;" From="SUPPQUAL"/>

 

This implementation does not work, but I have no idee why...it could be due to the 'from="SUPPQUAL"'? Could you please advice me how to correct this rule implementation.

 

Thank you,

Angela

 

 

 

 

s Sergiy
on March 6, 2014

Hi Angela, 

"0053" is one of few checks we are still waiting for clarification. What is your interpretation of this business rule?

Thank you, 

Sergiy

 

a Angela
on March 7, 2014

Hello Sergy,

Related to 0053, I just implemented as the rule descrisption says, if one of those 3 assertions (DSSTDY or %Domain%DY or %Domain%DTC and DM.RFSTDTC) are not fulfield the validator should throw this warning. Did you find something wrong into my implementations (regarding both rules 0053 and 0057).

 

Related to 0057 I have the feeling that should be take in care only the MA,MI,TF observation which has --ORRES values and the QVAL is not included indo %Domain%LAT or %Domain%SEV. Only those observation should be take in care by this rule. Could you tell me if you find some issues into my implementation? Or could you tell me how could I set the targer for SUPPQUAL domans?

 

Thank you,

Angela

s Sergiy
on March 7, 2014

Hi Angela,

What is a relationship between DSSTDY and MIDTC?

How DSSTDY can replace a value of MIDTC? "...or...or..."

Let's take an example when a subject has 5 records in DS and 10 records in MI. What particular records in DS and MI should be related? #3 in DS and #5 in MI? Why?

I'm not sure about scientific meaning of this business rule. Most likely it has a typo in its definition. E.g., it shoudl be like "...(MISTDY or MIDY) or (MIDTC and RFSTDTC)". Additional requirements on a presence at least full date part in MIDTC variable value may be needed. Etc.

Kind Regards, 

Sergiy

 

s Sergiy
on March 7, 2014

Hi Angela,

What is a relationship between DSSTDY and MIDTC?

How DSSTDY can replace a value of MIDTC? "...or...or..."

Let's take an example when a subject has 5 records in DS and 10 records in MI. What particular records in DS and MI should be related? #3 in DS and #5 in MI? Why?

I'm not sure about scientific meaning of this business rule. Most likely it has a typo in its definition. E.g., it shoudl be like "...(MISTDY or MIDY) or (MIDTC and RFSTDTC)". Additional requirements on a presence at least full date part in MIDTC variable value may be needed. Etc.

Kind Regards, 

Sergiy

 

a Angela
on March 7, 2014

Hy,

I do not know if we could have more than one observation for a specifi animal into DS...

But what about the other rule :NONCLIN-0057?

Thank you for your replay,

Angela

 

b Bedeoan
on March 7, 2014

Hi Sergyi,

I want to contradict your remark:

"Let's take an example when a subject has 5 records in DS and 10 records in MI. What particular records in DS and MI should be related? #3 in DS and #5 in MI? Why?"

According to the SEND standard, a subject should have just one record in DS.

The logic behing this FDA rule being probably that some dates related to the end of the animal should be known: either the disposition date / day - when the animal was rmeoved from the study, either the dates / days of the post-mortem observations (MA, MI, OM, TF). It is just an assumption; we don't have any official response from FDA.

"The disposition dataset provides a record for the disposition of subjects throughout the study. One record will be created for each subject used in the
study, whether it ultimately died or was removed from the study."

s Sergiy
on March 7, 2014

The confusion with #57 business rule is about if a presence of Result Modifiers info in SUPPQUAL domains is required for all records in the parent domain? Or only for some records? Or if is it always required?

SEND IG says that study data can be collected in both ways: with and without Result Modifiers.

E.g., see #6.3.7.2 on pages 101-102: "Rows 5, 10: These findings demonstrate original results without modifiers."

So, what exactly are we going to check? 

a Angela
on March 7, 2014

I am trying to check only for records that has Modifiers (in --ORRES) which are not included into --SEV or --LAT. This records should be presente in SUPPQUAL domain and the QNAM should be --RESMOD.

For example row 1 page 101,102

MAORRES =Discoloration dark, mucosa and MASEV=null and MALAT=null

in this case SUPPMA should have a record with QNAM="MARESMOD", I must check the QNAM value (nothing else care). 

Best,

Angela

 

b Bedeoan
on March 7, 2014

Hi Sergyi,

My interpretation for rule #57 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.

Again, my comments are just an interpretetation of the rule, based on the SEND standard; no input from FDA was provided; so I might be wrong in my assumptions.

Best regards,

Amelia

 

s Sergiy
on March 7, 2014

Hi all,

My concern is that this business rule is driven by particular data collection process, test and particular finding results. You never know in advance if your future record will have Result Modifier info or not? 

We can create a check which will require Result Modifier info for each record. However there is a risk that this new check will have a high rate of False-Positive Errors, which will make the check useless and annoying.

The programming algorithm should be well defined and refined for practical usage.

If everybody agrees that each record in MA, MI and TF domains must have --RESMOD info, I will be happy to implement this. However I am not sure that strong enforcement of such business rule is what is actually expected.

We are working with FDA on clarifications of some checks. It takes time. This particular rule has not been discussed yet.

Having limited experience with pre-clinical data collection process and standard reporting tools, I am very thankful to all of you for this discussion. E.g., I did not realize that DS data have one record per subject and DTSTDY actually means the subject latest time point in the study. This helps to explain #53 rule. However there are still some questions. A confirmation on all our additional assumptions is required.

Kind Regards,

Sergiy

s Sergiy
on March 7, 2014

Thanks, I see know.

Most likely there are some standard reports/tools which use either of those variables.

b Bedeoan
on March 10, 2014

Hi Sergyi,

Related to your remarks:

"You never know in advance if your future record will have Result Modifier info or not? 

We can create a check which will require Result Modifier info for each record. However there is a risk that this new check will have a high rate of False-Positive Errors, which will make the check useless and annoying.

The programming algorithm should be well defined and refined for practical usage.

If everybody agrees that each record in MA, MI and TF domains must have --RESMOD info, I will be happy to implement this. However I am not sure that strong enforcement of such business rule is what is actually expected."

Based on the SEND standard and also on my exposure (although limited) to SEND datasets, I would say that NOT ALL MA, MI, TF records have Result Modifiers. So the rule should NOT be enforced to all MA, MI, TF records.

My interpretation for rule #57 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.

So the rule should behave somehow like this (although I dont know if such a logic can be described by the OpenCDISC rules API):

1. remove STRESC from ORRES (if STRESC =ORRES then obviously we have no modifiers);

2. remove SEV, LAT, DIR (if they exists) from the remaining text (since they are a "regular" modifier);

3. what remains are the Result modifers; if the text obtained here is not empty, then a RESMOD row should exist for this pathology observation.

The RESMOD row should contain the remaining modifiers, but split by ";", not by "," as they are usually included into an ORRES.

I admit that processing the modifiers by commas and semicolons to make sure there are the same modifiiers might be too much for the validator, but the Validator could at least check if a RESMOD entry exists if the text obtained at step 3 is not empty.

What do you think?

Best regards,

Amelia

 

 

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.