A couple of weeks ago, I discussed the TMF Reference Model, how it came about, why it’s important. The level of organization is thorough and in depth. As someone who arranges the contents of their closet by color, sleeve length, and fabric weight, I find this extremely practical and spiritually fulfilling. Not kidding.
That was all background, so that you would understand how intensely awesome the folder structure was that I created inside of Document Locator!
One of the more quiet, and yet intensely useful features in Document Locator is the Folder Structure Manager. It allows you to build a repeatable folder structure, one that you use over and over—for example, a new employee folder. Instead of building a new set of folders every time you hire someone, you can right click, and have the folder structure built out for you—including all of the appropriate folders, metadata, templates (i.e. new hire forms and documents), workflows (it’s been six months since this folder was built, it’s time for your employee’s review!) etc.
I used this nifty tool to build out the folder structure for the TMF Reference Model. The entire TMF Reference Model is basically a set of instructions on how to arrange a (huge) hierarchical tree structure, with all of the information laid out clearly, in an Excel spreadsheet.
When putting the information into a tree structure, I knew, by looking at the TMF Reference Model, that it was going to look something like this:
I also saw that there was a lot of metadata that I wanted to embed in the profiles for each folder structure. Ideally, I would embed as much of the metadata as possible into the folder structure itself—the less someone has to fill-out when they’re putting documents away, the more likely it will be done right.
This involved a lot of layering, and as I built this, it was almost like a puzzle—where does this data need to live? At what point is this metadata attached to the folder structure? It came down to how static the metadata was. For example, the zone/section/artifact names and numbering—that was wholly static, and wouldn’t ever change—so that metadata was attached to the structure as I created it, in the folder structure manager.
Other metadata, such as the Private Investigator, and the Site Number, for the Site Files, was a bit more flexible—it would vary, every time you built out a new instance of the folder structure, but not within that set of files. So I created a prompt for the information when you build out that new instance, and then it remains static for that instance.
Doing this drastically reduced the amount of information that you need to enter into the system when you import a document. As you can see—all that is left are a couple of fields.
We all know that the fewer number of fields someone has to fill out when they’re filing a document in the system, the more likely it is that those fields will be filled properly!
This was a great project, and it is empowering, to be able to create such a well-tailored solution, because the software is so well-rounded. You only want to have to build one of these out once, though–let me tell you, it’s a beast!
It’s important, when it comes time to tackle the eTMF problem, that you evaluate your resources, and look at what the best solution is for your circumstances. As I concluded in my last post, sometimes the best solution is built on something you already have, or is a combination of two or more systems, which was the case for the solution that I built out.
This was possible because many of the requirements for such a system were built into Document Locator—all of the documents in the system are kept with a full document log, which keeps them audit ready, and workflow and granular security settings are inherent in the software. You can manage digital and electronic signatures appropriately, and you can access Document Locator via the web, no matter where you are in the world. Document Locator can even non-programmatically link to a CTMS system, to further reduce human error in managing documents and processes, and to maintain consistency across all of your operations.
All of these are key components to creating a successful solution for an eTMF. The solution that you choose to go with will need to have that same level of flexibility and security, in order to comply with FDA regulations, and to create a secure and collaborative environment to work inside of.
In the last three years, having a Trial Master File entirely on paper, in filing cabinets, has become unsustainable, and companies are now in the process of transitioning to eTMF’s, resulting in a hybrid of paper and shared file drives, which are also unsustainable as long term solutions. The question is—how will you transition to a fully digital eTMF?