In my previous blog, I recalled the tale of my first experience with SEND. I’d assumed that standardizing nonclinical data would be straightforward, after all we have standard glossaries and lexicons from the likes of INHAND, and isn’t one 28-day study pretty much like another? Yet, this SEND thing seemed so alien and impenetrable to me at first. I suspect it is for a lot of other people too.

The suspicious amongst us may wonder if those creating the standards would intentionally make it as difficult as possible to keep themselves in a job for life. However, having now got on the inside of this CDISC thing, I can reassure us that this is not the case.

I think for most people, the first time they get a hint that this thing is going to be more complicated than they expected, is when they ask the deceptively simple question: “Does my study require SEND?”.  You’d be forgiven for expecting a straight Yes or No answer, but instead you’d be hit with a barrage of unexpected questions like “What is the study start date?”; “Where will it be placed in eCTD structure?”; “Which FDA center will it be submitted to?”; “What type of submission is it?”. While these questions may take us by surprise at first, the reason behind them is that not all study types are applicable for SEND, and the eCTD sections are used as a good indicator of what’s in scope and what’s out of scope. Similarly, not all centers within FDA have adopted SEND, and so the list goes on. The agency has tried to be as gentle as they can with industry, giving us time to implement SEND, and making sure that it’s only required where it is applicable.

Getting past that simple of question, is often like taking the Matrix’s Red Pill and as the film’s character, Morpheus, says “You take the red pill…you stay in Wonderland, and I show you how deep the rabbit hole goes” because what comes next is a whole new world of interconnecting standards, guidance, regulations, publications, terminology and the like. We suddenly realize that SEND isn’t a single standard, it’s multiple standards. For example, a single study may have data using the SEND standard, but also requires the Define-XML standard. It needs to apply Controlled Terminology (known as CT, and at the time of writing there are almost 40 different versions to choose from). The study also includes an nSDRG and should follow the FDA’s TCG and comply with their TRC and we suddenly find ourselves in a head-spinning world of acronyms (that’s Nonclinical Study Data Reviewers Guide; Technical Conformance Guide and Technical Rejection Criteria, just in case you were wondering).

Now drowning in multiple standards, you’d be forgiven for asking “Why didn’t they just write it all down in one place?” The answer to that is that each piece of this spinning jigsaw is written by a different organization or group. For example, CDISC writes the standard, but FDA requires the standard and PHUSE provides implementation guidance while NCI provides the CT (what? more acronyms!). It was important for FDA that they used an existing standard created, by industry themselves. So, we have multiple moving parts, each separately version controlled and each on different release cycles and timelines. For example, CT is published quarterly; FDA’s TCG is published twice annually while the main SEND IG is updated roughly every 5 years.

Then we come to the thing that makes SEND so damn hard, by far: Clinical Baggage. The fact is that that SEND is not really a nonclinical standard. It’s actually a clinical standard that has been butchered I mean amended, into supporting nonclinical studies. This brings with it many, many advantages, but it also makes SEND really difficult for the novice.  Subjects on human clinical trials visit their clinic and are examined, questioned and have results taken. Often, they don’t turn up exactly when they should, and this is all captured in the concept of a visit; which turns up in SEND because it was baked into the clinical standard up on which SEND was based. This is just one of many examples where we may feel like we’ve slipped into a surreal parallel world. (For the most surreal nonclinical example, check out page 215 of the SEND IG where it talks about noting why a result is NULL and actually gives the example “patient was asked but didn’t know”). Yes, I’m being a little flippant here, but these are extreme examples of an underlying truth that SEND is based on clinical and so has concepts that seem a little out of whack with nonclinical. In order to correctly render our nonclinical data, we need to understand this and know how to use these concepts in order to best represent our data.

Oh, and I didn’t even get time to explain why SEND has its own language and ask if you knew what an “Ex-Teepee Tea” might be.

Till next time

Marc