In the last CDISC SEND Core Team meeting, we got to discussing Anti-Drug Antibody (ADA) data, and its representation in SEND. We were debating what we’d recommend, and this is the cause of my conflict.
The purist within me wants to scream “Custom Domain!”. The pragmatist knows the industry isn’t ready for this. I want to shout about that fact that at Instem, we have the tools and services to support custom domains; but I’m not supposed to use CDISC for such promotion. I want to tell everyone listening that we have the products and services available to help industry create these custom domains; but that would be overstepping the mark. So, as a card-carrying member of the CDISC SEND Core Team – I’m forced to admit to myself that industry just isn’t there yet.
So, I’m conflicted.
This arose due to the work over at FDA CBER and their recent pilot of the SEND standard. They have a real need to see ADA in SEND. In the current version of SEND, there isn’t a domain for these results, however SDTMIG (the implementation guide for the clinical equivalent of SEND) has such a domain. It’s called IS – Immunogenicity Specimen Assessment; but it’s not in the SENDIG.
PHUSE have previously looked into this situation and came up with two solutions, which can be summarized as showing how to either, force-fit ADA data into the existing LB domain; or borrowing IS from SDTMIG and adding it to a SEND package as a custom domain. (I’m probably doing a huge disservice to its authors by reducing an entire white paper to a single sentence!)
At this point, I’ll acknowledge but completely sidestep the question of whether or not this would actually be considered in scope or not; and totally dodge the issues around SDTM version compatibly and the fact that CDISC are adding an IS domain to SEND 3.2. If you want to dive into that, then drop me a line, marc.ellison@instem.com, because I’d be happy at taking the discussion down that particular rabbit hole!
So, I’m conflicted; and a big part of that conflict is due to the fact that I relish being at the cutting edge of SEND. The ‘right’ answer is, that as these data are important for safety evaluation, that they should be represented in SEND. This being the case, then the IS domain is a better fit than a misused LB domain. However, by and large, the industry isn’t at the cutting edge and as such many probably don’t have the tools or expertise needed. This is unsurprising as at CDISC, I think we could have done a better job at making the information available. We have an Implementation Guide that includes custom domains, but at no point acts to guide implementation of a custom domain. That being the case, I’ll hold my hand up as a CDISC volunteer and take my share of the responsibility for that.
Being at the cutting-edge means having developed the tools and services already. Not only does our Submit™ software create and consume such domains, but our SEND Explorer software can visualize them, and our services team can create and verify them. So, we are now sitting pretty with our ducks all aligned. But I know that doesn’t really apply to many others.
So, I’m still conflicted.
This is not supposed to sound like shameless self-promotion, of “look what we can do”; it’s relating the personal challenge of taking my CDISC responsibility seriously and ensuring I don’t overstep my privileged position of having a seat at the SEND Leadership table.
Till next time
Marc
Sensible SEND Blog 