FDAC213-Duplicate records in CE domain

FDAC213-Duplicate records in CE domain

If you have prespecified terms, and one of them is selected, you should also set CEPRESP to "Y". See assumption 2 of the SDTMIG v.3.2.
Regarding record uniqueness, it is YOU who define what the keys for unique records are in the define.xml. Did you do that? The variables that form the unique key have to be marked by a "KeySequence" attribute on the "ItemRef". Validation software should pick that up to find out whether there are duplicate records.

Now only --STDTC Timing variable in Events domains

Hi Priyanka, 

Now timing variables for Duplicate Records in Events domains are limited to --STDTC. 

We are considering to extend it by adding --STTPT.

Kind Regards, 

Sergiy

FDAC213-Duplicate records in CE domain

--STTPT is of course a typical key for checking for duplicate records. As already stated, it should be picked up from the define.xml where it is marked as such using the KeySequence attribute. It is the user who decides what the keys for record uniqueness are.

Thanks Sergiy. This will…

Thanks Sergiy. This will really help. Is this update coming up for next version?

Thanks,

Priyanka

Thanks. Will update the…

Thanks. Will update the define Key variables accordingly and run through the validator.

No

Hi Priyanka, 

No, a new algorithm for SD1201 rule will not be available in the next release of Community until its patch update (~ 1 extra month).

Kind Regards, 

Sergiy

FDAC213-Duplicate records in CE domain

I looked into the matter in deep detail again.
The FDAC213 rule states: "The structure of Events class domains should be one records per Event per subject. No Events with the same Collected Term (--TERM), Decoded Term (--DECOD), Category (--CAT), Subcategory (--SCAT), Severity (--SEV), and Toxicity Grade (--TOXGR) values for the same Subject (USUBJID) and the same Start Date (--STDTC) are expected".  

So it might be that the software is not to blame for this warning, as essentially, the rule is just damned wrong. It ignores that the granularity of the uniqueness may be higher and complexer, as happened in this case, and it ignores that the sponsor is responsible for assigning the uniqueness keys, and not the FDA (or whoever developed the rule). The better way to express this is the CDISC rule CG013: "Each record is unique per sponsor defined key variables as documented in the define.xml".

Hi, Yes, the problem is…

Hi,

Yes, the problem is with the situation where CETERM is same (since it is pre-specified) and the CESTDTC is null for multiple records for a subject as these records have CEOCCUR as "N" collected at different time points. 

The below rule is applicable when the CEOCCUR is Y , since we will not expect the same start date for same CETERM  collected at different time points.

The structure of Events class domains should be one records per Event per subject. No Events with the same Collected Term (--TERM), Decoded Term (--DECOD), Category (--CAT), Subcategory (--SCAT), Severity (--SEV), and Toxicity Grade (--TOXGR) values for the same Subject (USUBJID) and the same Start Date (--STDTC) are expected