What’s the deal with the eCTD Study Tagging File (STF), SEND and the Technical Rejection Criteria?

Ensuring alignment between the Study Tagging File and SEND datasets is now critical; miscommunication can lead to technical rejection, highlighting the need for better collaboration across teams.

As you are probably aware, Instem recently acquired PDS Life Sciences and so I’ve been working very closely with my new colleague, Mike Wasko. Mike is a prominent figure within our industry, and this week as we were catching up, we started discussing the question: What is the relationship between the eCTD Study Tagging File (STF) and SEND datasets and the impact on the Technical Rejection Criteria (TRC)? As this is an area that causes some confusion and can lead to an automated Technical Rejection of the submission, I asked Mike to write up his thoughts, so they could be shared in this blog. Here’s what he had to say:

As outlined in the Technical Conformance Guide (TCG), TRC and eCTD Guidance, the study-id used in the STF must match either the STUDYID or the Sponsor’s Reference ID (SPREFID) value in the TS domain. Additionally, this study-id must be present in the define.xml file in the StudyName element. This connection is clearly understood; however, knowing what study-id the Sponsor will use in the STF is another story.

Usually, study conduct and then the subsequent SEND dataset creation, are managed by the Study Director and a SEND team. Whether the SEND team is internal to the CRO or external, the SEND team typically has little to no contact with the submission team creating the STF.

Now that the FDA’s TRC is in effect (September 15, 2021), the connection between the SEND datasets and STF has become essential and communication regarding the study-id in the STF must adapt. In an ideal setting, the team creating the SEND dataset and the associated define.xml file, will be informed of the study-id to be used in the STF.

One would think that the study identifier should be obvious, but that is not always the case. This coupled with the fact that the STF is usually created after the SEND datasets are completed creates a unique problem. For studies conducted by CROs, a study might have several different identifiers, the Sponsor study id, the CRO study id, a report number or even something else. In this situation, it is difficult  for the SEND team to determine which identifier will be used in the STF, and remember that wrong assumptions will cause a technical rejection.

Even if a single study number is used in the report and SEND dataset package, another use case can cause a challenge. The eCTD and STF limit the type of characters that can be used due to folder structure. Special characters such as “/”, “\”, “.” and others should not be used. If the study report and protocol use such characters for the study number, how will it be represented in the STF? Was the character simply removed? Was the character replaced with an acceptable character such as “_” or “-”?

For submissions that occur near the time of a SEND dataset generation, proactive communication from the submission team and can resolve the issue. However, consider that SEND datasets can sit for years before submission say for an NDA. Staff may have changed or maybe the agreement wasn’t well documented. Now the Sponsor will need to ensure that the STF and the STUDYID or SPREFID align.  If they do not, the ts.xpt and define.xml files will have to be updated accordingly.  Currently, we are not aware of any validators that do this check automatically so Sponsors will also need to know where to look in the define.xml and ts.xpt to ensure the study-id specified in the STF matches the dataset and define.xml file. As time progresses, it seems more and more people will need to become SEND aware as it is no longer strictly a SEND team and Study Director responsibility.

I thought that was a great explanation for Mike to share, and you can expect that I will be asking Mike for future contributions as we continue to navigate the challenges and opportunities that SEND presents.

If you’d like to continue this conversation, drop me a line at [email protected]

Till next time,

Marc

Marc Ellison

Marc Ellison is the Director of SEND Solutions at Instem and has been a CDISC volunteer for 12 years. He has 3 decades of experience creating nonclinical software and working with researchers on how to best collect and organize their data. Marc refers to himself as a “SEND nerd” and is truly passionate about the concepts, debates, and evolutions around the SEND standard. Being a strong advocate for the importance of SEND in accelerating research, Marc launched his own educational blog at Instem called “Sensible SEND” to help educate and prepare researchers with cutting-edge details and explanations about the ever-developing process.

Share This Article

Stay up to Date

Get expert tips, industry news, and fresh content delivered to your inbox.