The pharmaceutical industry is no stranger to big data or big innovation. Earlier this month, a new requirement from the US Food and Drug Administration (FDA) formalized the digitization of the process by which companies submit new drug and medical device applications.
To learn more about the “electronic common technical document” standard (eCTD), the processes behind it, and how e-discovery know-how can simplify its completion, we sat down with Michael Sarlo, vice president of e-discovery and digital forensics at HAYSTACKID. Here’s what we learned.
Tell us a little bit about the electronic common technical document. What is it and what is it used for?
The eCTD format has become the FDA’s Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research’s (CBER) standard for application submissions, as well as amendments, supplements, and other reports. Thus, it’s in use by medical device companies, biologics industries, pharmaceuticals—anyone dealing with applications or re-patenting for new and existing drugs or devices. The European Medicines Agency has been requiring it since 2010, while a range of other nations have encouraged its use.
As far as what it physically is, in e-discovery terms, it’s much like a load file that we’re used to seeing in other use cases. It’s an incredibly complex .xml, a common format. Drug companies need to assemble this load file with their relevant data to create an application for FDA approval.
The load file contains some typical things for discovery, like metadata and hard links for native documents, but it’s also more complex than that. Imagine one .xml that links to many others, with extended metadata that we don’t see in typical e-discovery. It also includes modules for organizing the various components of an application—like any application, there are many sections you’re required to fill. A table of contents moderates it all.
Sounds complicated! How much work is it to put one of these files together in compliance with the requirements?
Separating it from the technology and thinking of just what it takes to research, create a drug, endure clinical trials, and gather test data, it all costs millions of dollars and takes years of work. Once all of that is done, it becomes centralized around the eCTD. Applicants are investing in people, software, and expertise to go through the process of compiling all that information to gather FDA approval on their final product.
Just like in typical compliance or e-discovery projects, you might come across technical issues—docs that don’t render right, or broken links. But these organizations are spending millions of dollars to perform the research and gather this information, and they want it to be perfect, so a broken link isn’t going to cut it. The compiling work is iterative, the eCTD grows as you move through the process, and sometimes back-and-forth with regulators can complicate it further. In short, this is by no means quick.
How does compiling an eCTD operate similarly to litigation-related e-discovery? How is it different?
It probably makes sense to go back in time and set this up. Back in the days of traditional discovery, everything was paper. You’d get a bunch of documents and have an army of people putting sticky notes or Bates stamps on them, or scanning and re-printing them with new stamps, to pass onto opposing parties. The evolution of the medical industry to this eCTD standard has followed our same process of digitizing everything. These applications were also a bunch of paper in boxes and binders. So that’s a parallel: the shift from paper to electronic processes is a big benefit, but also a big jump for some teams.
We all know the best way to review this volume of digital documents is to use a database. Building the eCTD is very similar to building a production—compiling documents as you move through a cache of data—but with some differences. For example, you might want to do it just once and build a single load file, but the FDA will commonly come back and request more information.
Another thing to note is that, while e-discovery starts fresh and you’re building the end production yourself, an eCTD starts with a pre-built load file format. The submission process is an open and clear record of choices that have led to the creation of the submission. If you have a document you’d, on second thought, remove from a production during e-discovery, you might not need to tell the other side—but in this process, everything is open. You want to appease the regulator as much as possible, so every move is documented with tracked changes.
What is a typical pain point for teams working on these submissions, and how can it be overcome?
Just like in e-discovery, the big law firms and corporations don’t suffer as much—they have the technology, resources, and people to tackle this. But this process being mandatory now means smaller companies, with fewer resources, may face a bigger challenge.
When you submit in this format, there’s an initial check on the load file before the FDA begins reviewing the merits of your application. If you don’t make it past that step, you’ll face instant refusal from the FDA, meaning you have to start the submission process all over. What’s more, if you do get through the initial check but lack proper navigation or have a ton of mistakes, you can still get a refusal to file in that initial 60-day period. So not doing it right can severely mess up a timeline.
This obstacle can be avoided for small organizations through a variety of software, vendors, and experts out there to help streamline the compilation process. As they grow, they may choose to bring this in-house, and they often do. A whole world of pharmaceutical software and services is out there and very comparable to the e-discovery industry: you have vendors, software companies, consultants, and so on available to assist.
Similarly—and often in greater proportion—to the legal world, there’s a ton of money and risk behind these projects. Every application must be clean, not just in substance but in style. If you do a book report for school and it’s just not readable or engaging, even if the content is good, you can still get a bad grade. Leveraging the right tools and help can make all the difference.
Can e-discovery software be used for these projects?
e-Discovery software is great for reviewing these files. Experts in this space have the skills to work with data formats like this, as well as the technical requirements of a load file and all its components. A tool like Relativity is great for this use case because it’s open, has a robust API and open connectors, and displays data nicely.
For example, HAYSTACKID has a tool that streamlines the process of getting an eCTD into Relativity. It takes some programmers and some vision and experience in both industries, but it makes a great centralization point.
I also mentioned an eCTD’s tracked changes. Our app allows you to see the historical changes on each eCTD and verify you’re looking at the latest one, so throughout the application’s lifecycle you can see its progress and evolution.
Beyond that, this software helps because there’s a ton of litigation that surrounds these same data points and documents. These documents can become mission critical in cases where, say, there’s an accusation of study data being modified to push an application through. The ability to review and produce this data is critical in these cases, and having it already centralized and organized makes understanding the documents and their data easier, allowing clients to pick and choose what goes out to regulators and other bodies and when, as the need arises.
Michael Sarlo, EnCE, CCLO, RCA, CBE, CCPA, is the Vice President of e-Discovery & Digital Forensics at Haystack Information Discovery (“HAYSTACKID”), a Relativity Authorized Partner and leading provider of end-to-end technology-driven, forensics, litigation preparedness, and e-discovery services. Michael facilitates all HAYSTACKID's operations related to e-discovery in the United States and abroad, while working on highly complex forensic and e-discovery projects. He has full oversight of all facilities, and manages workflow and change management to ensure consistent, quality, and efficiency of all processes for each project entering HAYSTACKID’s walls.
Sam Bock is a member of the marketing communications team at Relativity, and serves as editor of The Relativity Blog.