EDM Reference Model Metadata and eCTD Submissions
Many of you are no doubt familiar with the EDM Reference Model. This is a cross-SIAC initiative by the DRM (Document and Records Management (DRM) SIAC. [A SIAC is a Special Interest Area Community within DIA.]
As a quick refresher, the goal of this group is to define a minimum set of metadata to enable the context of use of regulatory submission for CTD documents and supporting documents.
In other words, what metadata should be used to tag each type of document that is included to or closely related to a CTD submission, in order to fully understand what information it is representing? The problem was broken down into six domain areas: Regulatory administrative, Regulatory labeling, Regulatory Pharmacovigilance, Clinical, Nonclinical, and Quality/CMC.
The taxonomy/metadata reference model could then be used by any company as a starting point for building document management processes and electronic document management systems, shortening the timeline and reducing the expense of implementing EDM systems. It might also enable documents and data to be exchanged between disparate systems in licensing-in or acquisition business scenarios.
This approach is familiar to me as in my former life I was a document management consultant specializing in submission documents. Along with my colleagues, we piloted a similar approach starting around 2000, and constantly refined our “best practice” taxonomy and metadata with feedback from our clients.
We also reviewed it with every change in guidance from a regulatory authority. The approach worked really well, cutting down the analysis time for an EDMS for submission documents by an order of magnitude compared to the “blank slate” approach. (However, many big pharma, unless firmly managed by their own project manager, continued to find reasons why the model could not possibly be used out of the box for them because they were “different”.)
Anyway, to get back to the story – the EDM Reference Model appears to be gaining some traction now as I see a number of vendors have made announcements that their products are incorporating the model. On the whole, I think that’s a good thing. While I don’t think it offers much benefit to clients of my former company (which already had a sophisticated best practice model), it offers a major step up for some vendors who, in the past, have been more about the tools than about the best practices and industry knowledge.
While I was back in the document management world, there was one “Holy Grail” that we never reached – using metadata to automatically populate an eCTD table of contents. It was always something that was out there for our next release (since we had almost all the necessary metadata) but something we never quite got to.
Since I have moved out of the document management world and more into the submissions world, I have become skeptical about the true value of that “Holy Grail”. Realistically, I think there are a number of reasons why the auto-population would be a nice to have but in the end not really much of a time-saver.
These reasons include:
- Despite the best intentions of eCTD being a “global” submission, documents submitted are substantially different in each region. And it’s not usually workable to tag a document (such as an analytical method or stability document) for the exact regions in which it will be submitted.
- Study components submitted in Europe are often different than in the US, and it’s not just as simple as excluding SAS files and CRFs.
- In the CMC world, you may be submitting documents that are not the current version.
- Again despite best intentions, document management systems often have various documents in them that won’t ever be submitted, multiple documents representing the same content, and other issues it takes a person to resolve.
But in the end, the real reason I don’t think it’s really a significantly worthwhile exercise is that it really only makes sense for an original application. How would a computer know which documents you wanted to put in an amendment, variation or supplement unless you told it? Which would amount to doing the same work as you do dragging and dropping a document into a submission anyway.
The bottom line is that even the biggest company only produces at most three or four NDAs/MAAs in a year – most work goes into maintaining submissions. When you look at how long it takes to populate the submission TOC, even for an original application, you would not be saving much time. However, you would be increasing coupling between your EDMS and your publishing tool, and significantly increasing the time and complexity to validate (think about what happens if it misses a document).
But I would be interested in the thoughts of others in this area…