r Rosie
on

 

Hi, I've been trying to validate a test database and I've just come across the rule SD0009: "No qualifiers set to 'Y', when AE is Serious".

I'm using SDTM IG 3.1.3 and I can't find this referenced there - can someone tell me where it comes from?  And whether it's mandatory or just recommended, as the qualifiers are not something we'd normally collect?  (It gives a Warning rather than an Error.)

Thanks!

Forums: SDTM

m Michael
on September 16, 2014

I believe this comes from FDACLIN-0195.   Serigy presented this rule as an example during the OpenCDISC Live event at Novartis last week.

s Sergiy
on September 16, 2014

Hi!

SD0009 check came from ICH 2A and ICH E6.

Kind Regards, 

Sergiy

r Rosie
on September 17, 2014

Thanks mdigian and Sergiy.  We are pretty new to all this.  Have you got a link for either of those?  When I Google the 1st one it just brings me back to my comment...

s Sergiy
on September 17, 2014

http://www.ich.org/fileadmin/Public_Web_Site/ICH_Products/Guidelines/Efficacy/E2A/Step4/E2A_Guideline.pdf

http://www.fda.gov/downloads/Drugs/Guidances/ucm073122.pdf

All ICH Guindances: http://www.ich.org/products/guidelines/efficacy/article/efficacy-guidelines.html

m Michael
on September 17, 2014

Also note that when serious (SER = Y), there are 8 CDISC options for which one must be checked, but only 5 are ICH compliant.  Futhermore all values including AESER are bound to CDISC CT code C66742 (Yes/No) codelist.   

 

Predicate

Concept

variable

ICH 
Compliant

Results in

Death

__SDTH

 

Results in

Life threat

__SLIFE

 

Results in

Disability

__SDISAB

 

Results in

Hospitalization

__SHOSP

 

Associated with

Congenitgal Anomaly/Birth Defect

__SCONG

 

Associated with

Cancer

__SCAN

No

Occurred From

Overdose

__SOD

No

unknown

Other Serious Medically Important Event

__SMIE

No

m Michael
on September 17, 2014

The reason a qualifier should be checked is because a reviewer may want to quickly understand at a high level why the sponsor indicated the AE was serious.   The next obvious step is if any one of those 8 boxes are checked, it would be good to create a RELREC that links this Serious AE to the concept which qualifies it seriousness.  

For example if the AE occurred from overdose, you may want to link to the Conmed (CM) or Exposure (EX) records which contained the overdose.   If it was associated with a Congenital Anomoly or Birth defect, perhaps a link to the patients Medical History (MH).   If it resulted in death, it should link back to another record in AE and possibly Disposition.    Anything resulting in diability or hospitaliztion might point to some custom domain recording the event or perhaps Findings About (FA).   

r Rosie
on September 18, 2014

Thanks both!

I'm a bit confused now, because I am thinking from the perspective of data collection, and CDASH 1.1 says this:

If the details regarding a Serious AE should be collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. In many cases sponsors will only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore do not need to be collected in the clinical database.

 

The second sentence represents pretty normal practice for us!  Adding all the reasons for seriousness would add a burden of 8 data collection fields in the CRF, and duplicate information already collected by PV.  Are we expected to merge PV data with CRF data to produce SDTM?  Or is including the fields merely "recommended"?

I hope all this isn't going beyond the remit of the forum!  I think you're doing a great job in interpreting the great faceless morass of CDISC for us on the ground, so it's very tempting to be lazy and just ask questions.

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.