For this week’s blog post, I thought it would be good to discuss the current use of the define.xml file within the nonclinical industry, so I’ve asked Charuta Bapat to discuss this with us as her enthusiasm for the Define-XML is bordering on infectious. Charuta works alongside me and is responsible for our define tools and is a member of the CDISC nonclinical define team. Here’s her take on the subject:
Some people are passionate about music, some like art, some love nature, and in our pre-clinical world there are many SEND-addicts. I enjoy working with SEND, but ever since I entered the regulatory industry, my heart has been set on Define-XML. Yes, you read that right! I am one of those rare specimens who is excited by the define.xml and strongly believe in the value of creating great define files.
Imagine you are in a restaurant and looking at the menu – the menu has a great cover with attractive colours. As you open it, you are expecting to see a list your favourite dishes and their pricing. But when you look closely, the menu doesn’t make sense at all. There are spelling mistakes, the description is not readable, the appetizers are mixed with desserts, and you cannot understand the price list. How would that make you feel? Would you start doubting the quality of food? Would you rather go to a different restaurant? Would you feel frustrated that you have to ask a series of questions to the waiter? I suppose regulatory reviewers get the same sort of feeling when they get an improperly structured define file. define.xml much like my menu analogy, how the file is laid out impacts a reviewer’s first impression. It is basically a table of contents for your study and most useful in describing the structure and content of the submitted data.
Despite Define-XML being in the picture of data submission for more than a decade, it’s evident that the nonclinical industry is still struggling with it. It’s either a neglected or worrying bit of submission that regulatory authorities have not been transparent about when it comes to their expectations. Sadly, many organizations treat define.xml like a household chore.
As a result, many choose to take an approach that suits them, some don’t give it much importance, some submit system-generated default files, and some don’t understand the specification. But I have also seen those who go to great lengths to create truly good define files. Of course, they are the ones who see the benefit they deserve – their regulatory review is much smoother than others.
Everyone feels the Define-XML specification is quite technical in nature and it’s true, but I think it offers an advantage as well – it brings discipline and homogeneity. It can not only be consumed by the software but can also be read manually. It creates a framework in a reviewer’s mind as well as in the software to receive the actual data.
In my opinion, the define.xml has tremendous potential and we all need to work together with CDISC and the regulatory authorities to make the best use of it and unveil its true ability. All we need is the right mindset and efficient tools. We could turn this once laborious household chore into a key piece of valuable data for SEND packages. I know I could never stop talking about define. If you are interested in learning more about improving define files or chatting about the FDA’s feedback on this topic, get in touch with me – I’d love to connect with you!
Charuta
Sensible SEND Blog 