eSubs and eCTD and RPS, Oh My!

An Opinion from:
Leah Kleylein, Principal Consultant, Product Management
e-Mail: lkleylein@octagonresearch.com

Not that long ago, “publishing” a submission in the pharmaceutical field involved real-life tools like copiers, hole-punchers, paginators, and white-out. Lots of white-out. The headaches involved back then were the last-minute changes; some of which resulted in a volume being way more than the hoped-for 300-400 pages. I once had a Volume 1 that tipped the scales at 510 pages thanks to last-minute additions and changes. We barely managed to get the binder to close with that one. But if a page had a typo on it, you just got a replacement page, and replaced it in the original and copies.

When you completed your major application, you could look around your submissions room and feel the satisfaction of seeing all your hard work represented with volume after volume of copies. The plus side of paper submissions is that it can easily accommodate last-minute changes. Other than deciding how to update the pagination (do we use an “a” after the number or re-paginate the volume) and updating any Tables of Contents that needed it, that was pretty much it. You kept your fingers crossed that any in-text references buried in some other document wouldn’t be messed up by the change. It was too difficult to track all those in-text references down in a paper submission. We went on a wing and a prayer. And when I think back on all the trees that I personally caused to be cut down…all that paper, what a waste. Making extra copies of hundreds of volumes (just to be “safe”), or re-copying published references to make the margins straighter; it was a waste of time and effort. The content is what really matters, no matter how clean and pretty your margins are.

Somewhere along the way electronic submissions were introduced. Our jobs as regulatory publishers began to morph into something different. We had to know how to render to PDF, to electronically paginate, and how to “mask” on a computer screen rather than with white-out and a copier. We spent lots of time helping our co-workers know how to do this as well, trying to explain that if it was done right first, we wouldn’t have to fix it later, as is, please don’t create your own custom styles in Word, just use the default settings. We got to be very good at reviewing PDFs for strange symbols or page breaks due to fonts and section breaks in Word. Does anyone other than me remember the joy of finally discovering that your problem was coming from an actual setting that you could change in the Word document (like Odd Page Break)? To this day I make my formatting options visible in Word, though it is a pale shadow of what WordPerfect used to show me in Reveal Codes.

And then it happened; the Electronic CTD. All publishing groups suddenly became separated into two camps: the technical and the non-technical. If you were technical, you learned the power of the pointy little bracket thingys and a slash, as in:

<company-name>I Heart Metadata, Inc.</company-name>

You learned very quickly that this technical XML stuff was really, really picky and that the Health Authorities got real specific about what they wanted. The US is fine with their submission date being in yyyymmdd format. But Canada wants dashes. And the EU doesn’t want a date at all. Publishing software turned up that made XML backbones for us, so we wouldn’t have to manually type it in notepad, but there was still a division-technical people who understood what was happening in the XML and the non-technical.

I was fortunate in that after several thousand mistakes, I started to grasp what made the XML backbone work. I experimented and found out what the consequences were of different actions. Did I have any business doing any of that? Of course not, my background is Liberal Arts, tra la la, I should be teaching English somewhere, or being a guidance counselor in a school, not hacking apart a co-workers XML to find where the problem was.

So with that in mind, I’m sure you think that I’m looking forward to our next great leap forward, RPS (Regulated Product Submission). Honestly? Yes and no. I admit I love finding out what is making something work or not work. When I’m in the mood for it, that is. Do I want to always be getting phone calls because someone else’s submission is broken? Heck no. I want them to be able to build their submissions all on their own and be proud of themselves for their accomplishments (see, that’s where that whole guidance counselor thing comes out).

Techy vs. Regulatory
We’ve done something, we publishers, in that we’ve put ourselves into this niche where we are required to be very technical. Is that really what we are supposed to be doing? What’s our career path with that? It’s pretty difficult to find a balance between learning regulatory strategy and knowing how to do technical stuff. We can’t reasonably expect people to do both.

I have a bold statement to make here. How about we leave the technical stuff to the IT folks? How about if we take back the “Regulatory” in regulatory publishing? I’m proposing that we demand (and create) publishing software that doesn’t require a certification in XML or HTML or whatever ML for me to successfully create a submission. When RPS does become the format of choice, I don’t think it should change how I publish a submission in any way, except that at some point in the process, I would select “RPS” as the output format. The rest of my process should stay the same, whatever publishing software I’m using.

Think about it. Mucking around in the index.xml and regional XMLs happened because we didn’t trust the new format or the new tools. Ok, I didn’t trust the new format and the new tools, and I don’t want to project onto you. But I think some of you feel the same. eCTD was new and scary and we weren’t sure what we were doing. If we knew what was happening in the background, maybe we could better understand what was happening to our content while we built the submission. And, inevitably, some of us started to like looking at the backbone.

But was that really the intent when this new electronic format was introduced? That we all become XML experts? Of course not. It was intended to provide a better and more consistent framework around what was actually important (the content) and make it easier for reviewers to navigate their way through a submission.

Tools should be doing the heavy lifting of creating, fixing and reading XML, and we should be demanding tools that do it in such a way that we are not forced to audit it every step of the way. Think about your online banking transactions. You transmit some funds, and you get a message that it was completed. Do you see all the scary technical things going on in the background? Or is the message good enough for you? We should be able to publish a submission, and just get a happy message that it’s been completed.

Too radical? I don’t think so.