Document Taxonomy Redesign Before a DMS Migration: Types, Metadata, and Owners

Why the Taxonomy Comes Before the Platform

A document taxonomy is the agreed list of document types a company manages, how those types are grouped, what each one must carry as metadata, how each is numbered, and who is responsible for it. In a DMS, the taxonomy is not a label on the side. It decides which fields a user sees, which lifecycle and approval workflow a document follows, who can read it, and how long it is kept. When the taxonomy is wrong, every one of those behaviors is wrong with it.

That is why the order of work matters. Redesigning the taxonomy before a migration is a planning exercise on paper and in spreadsheets. Redesigning it after go-live means reclassifying live controlled documents, reworking validated configuration, and retraining users who have just learned the new system.

What Regulators Expect of Document Types

The regulations do not prescribe a taxonomy, but they do expect one to exist. The principle section of EU GMP Chapter 4 says that “The various types of documents and media used should be fully defined in the manufacturer’s Quality Management System.”¹ Paragraph 4.1 adds that “All types of document should be defined and adhered to.” Chapter 4 then lists the documentation it expects by type: the site master file; instruction types such as specifications, manufacturing formulae and processing instructions, procedures, protocols, and technical agreements; and record and report types such as records, certificates of analysis, and reports.¹ The January 2011 version of Chapter 4 is still the one EudraLex Volume 4 lists as current.²

Chapter 4 also sets expectations that a taxonomy has to support. Paragraph 4.3 asks that instruction documents be “uniquely identifiable” and that “The effective date should be defined.” Paragraph 4.5 says “Documents within the Quality Management System should be regularly reviewed and kept up-to-date.”¹ Unique identification, an effective date, and a review cycle are all things the DMS can only enforce if the document type carries them.

On the clinical side, ICH E6(R3) moved from “essential documents” to “essential records.” Appendix C asks that records be identifiable and version controlled when appropriate, and that they show authors, reviewers, and approvers as appropriate, with date and signature where needed. It also says the Essential Records Table is not an exhaustive list, so sponsors must decide which other trial records are essential.³ The EMA guideline on the trial master file is more direct about metadata: “Metadata applied to documents should be formally defined to ensure consistency across all documents.”⁴ It also expects “a suitable overall index or table of contents to enable the location of essential documents in the TMF to be traced.”⁴

Read together, these say the same thing in different words. The company must define its document types, define the metadata on them, identify each document uniquely, and be able to find it. A taxonomy is how you meet all four at once.

Why Copying the Old Structure Moves the Old Problems

Commercial DMS platforms build behavior on the type hierarchy. Veeva Vault’s own help documentation, for example, explains that document types form a hierarchy in which each type can have its own fields, and that the hierarchy also sets some security settings, available lifecycles, rendition types, and default search fields.⁵ The same page states that you cannot delete a document type, subtype, or classification while any document of that type exists, and that “Inactivating a document type does not affect existing documents of that type.”⁵ Other platforms differ in detail, but the pattern is common: once documents are loaded against a type, that type stays.

So if the legacy system has “SOP,” “Procedure,” “Standard Procedure,” and “Global SOP” as four types that mean the same thing, and the migration carries all four across, the new system will hold four types forever. You can inactivate three of them, but the documents stay where they were loaded, and every report and search has to account for all four. The redesign has to happen before the load file is built.

What a Taxonomy Contains

It helps to agree on the parts before the work starts. ISO 15489-1, the international standard on records management concepts and principles, covers records and metadata for records, assigned responsibilities, analysis of business context, and records controls.⁶ For a GxP DMS, those translate into seven parts that each need a decision.

The seventh part is the crosswalk: the table that maps every legacy type and field to its new home. It is the link between the redesign and the migration, and it is covered in the last step.

Step One: Inventory the Document Types You Have

The first instinct is to count files. That is useful for sizing the migration, but it does not tell you about the taxonomy. The inventory that matters here is an inventory of types: every type, category, folder convention, and template in use across every system that holds controlled content.

Inventory Types, Not Files

Start with the configured types in the current DMS, then look further. Most companies have controlled or semi-controlled content in more than one place: a legacy DMS, a separate eTMF, a regulatory publishing repository, a learning system that holds training materials, shared drives, and site-specific systems inherited through acquisitions. The EMA trial master file guideline makes the same point for clinical content, asking sponsors to identify and record the location of all documentation that forms the TMF, even when several departments, countries, and systems are involved.⁴

For each system, export the type list with counts and the field definitions attached to each type. Then pull a sample of documents from each type, usually ten to twenty, and read them. The configured type tells you what someone intended. The sample tells you what people have filed there.

The Fields to Capture for Each Current Type

A spreadsheet is enough for this work. One row per legacy type, with these columns:

Signs a Type Is Not a Distinct Type

As the inventory fills in, a few patterns show up in almost every legacy system. Watch for these:

• Same content, different names. Two or more types hold the same kind of document, often because sites or acquired companies set up their own.
• Types named after departments. “QA Documents” or “Engineering Documents” describe who wrote something, not what it is. Department belongs in metadata, not in the type.
• Catch-all types. “Miscellaneous,” “General,” or “Other” types with large counts. These are where classification decisions were skipped.
• Types that encode a version or year. “SOP 2019 Format” or “New Template” types exist because a template change was handled by creating a new type.
• Types with one or two documents. These are usually one-off decisions, and the documents often belong in an existing type with a subtype or a metadata value.
• Types with fields nobody fills. If a required field reads “N/A” in most of the sample, either the field is wrong for the type or the type is too broad.

None of these is a failure by the people who built the old system. Each one was a reasonable fix at the time. The point of the inventory is to see them all at once, which is the only way to fix them together.

Step Two: Consolidate and Define the Target Types

With the inventory in hand, design the target list. The goal is fewer types with clear definitions, not the smallest possible number. A type should exist when documents of that kind need different behavior: different fields, a different lifecycle, different approvers, different access, or a different retention rule. If none of those differ, it is probably a subtype or a metadata value.

Decision Rules for Merging, Splitting, and Retiring Types

Write the rules down before applying them, so that decisions are consistent across domains and can be explained later:

• Merge when two legacy types hold the same kind of document and follow the same lifecycle. Keep the difference, if any, as a metadata value (site, region, product).
• Split when one legacy type holds documents that need different approvers or retention. A “Validation Document” type that holds both protocols and reports is a common example, because the two have different review and approval steps.
• Demote to a subtype when documents share a lifecycle but need one or two extra fields. A subtype keeps the parent’s behavior and adds what is specific.
• Demote to a metadata value when the only difference is a characteristic such as site, language, or product.
• Retire a type when it has no current documents, no owner, and no regulatory driver. Its historical documents still need a target in the crosswalk, usually a merged type with a legacy-type metadata value.

Write a Definition for Every Type

A type name is not a definition. “Report” can mean a validation report, an investigation report, an annual product review, or a clinical study report. Each target type needs a short written definition that says what it is, what it is not, and gives two or three examples. EU GMP Chapter 4 is a useful model here because it defines each documentation type in a sentence. Procedures, for example, are defined as documents that “give directions for performing certain operations,” and records as documents that “Provide evidence of various actions taken to demonstrate compliance with instructions.”¹

The definitions go into the DMS where the platform allows it, so that users see them when they choose a type. They also go into the governing procedure for document control. When a filing question comes up later, the answer is in the definition, not in someone’s memory.

Choose How Deep the Hierarchy Goes

Most DMS platforms support three levels: type, subtype, and a third level that may be called classification or artifact. More levels make filing slower and errors more likely. A practical rule is to use the third level only where an external reference model already defines it, as the TMF model does for clinical content, and to stop at two levels everywhere else. If a domain seems to need four levels, some of those levels are almost certainly metadata.

Numbering: What the Document Number Should and Should Not Carry

Chapter 4 asks that documents be “uniquely identifiable.”¹ It does not say how. Legacy numbering schemes tend to pack meaning into the number: site code, department code, product code, year. That feels efficient until a department is renamed, a site is sold, or a procedure becomes global. Then the number says something false, and the company either renumbers (breaking every reference to the old number in batch records, training records, and other procedures) or lives with numbers that mislead.

A sturdier rule is to let the number carry only two things that never change for a document: a short type prefix and a sequence. Site, department, product, and region go into metadata, where they can be updated without changing the identifier. Version is tracked as its own field, not appended to the number. Two further decisions are worth making explicitly:

• Legacy numbers. Decide whether migrated documents keep their old numbers or receive new ones. Keeping old numbers avoids breaking references but carries old patterns forward. Renumbering gives a clean scheme but requires a searchable legacy-number field on every migrated document and a plan for references inside other documents. Either can be defended; what matters is that the decision is written down and applied the same way across the migration.
• Records versus instructions. Executed records, such as completed forms or batch records, are usually identified by the transaction (batch number, study and site, equipment ID) rather than by a document sequence. The taxonomy should say which identifier is the primary one for each record type.

Step Three: Align With Reference Models Where They Exist

Some domains already have an industry model for document types. Using it saves design effort, makes exchange with partners easier, and gives inspectors and auditors a structure they recognize. Two areas are well covered: clinical trial content and regulatory submissions. Quality and manufacturing content has no single equivalent, so those domains have to be designed in-house.

Clinical Trial Content: The CDISC TMF Standard Model

Many people still call this the DIA TMF Reference Model, and that is where it started. CDISC’s own FAQ explains that the initiative was formerly a sub-group of DIA’s Document and Records Management Community and has been part of CDISC since June 2022, with its work products in the public domain.⁸ DIA’s own 2026 RIM Reference Model guide says the same thing, noting that the TMF model “started out as a DIA-led initiative and has now become part of CDISC standards.”⁹ CDISC now titles its page “Trial Master File Standard Model.”⁷ When a project charter or vendor proposal cites the “DIA TMF Reference Model,” it is worth checking that everyone means the current CDISC version.

The structure is well suited to a DMS taxonomy. Artifacts are grouped into 11 zones, from Trial Management (zone 1) to Statistics (zone 11), and each zone is divided into sections. Each artifact has a unique artifact ID number, common alternate names, a description, and a reference to the relevant ICH section. Artifacts are labeled core or recommended, and each exists at the trial, country, or site level, or more than one of these. Version 3 added optional sub-artifacts, which CDISC says require company-specific customization to match SOPs.⁷

Three points matter for a migration plan:

• Know which version you are aligning to. The current published version is v3.3.1, dated 11 August 2023. CDISC has also opened a community review of a “CDISC TMF Standard Model v1,” with comments due 20 November 2026.⁷ Version 3.3.1 predates the January 2025 ICH E6(R3) guideline, so a team designing an eTMF taxonomy now should align to v3.3.1, store the artifact ID as a field, and plan a review once the new model is published.
• Adapt, but record the adaptation. CDISC states that the model is not meant to be used off the shelf and that organizations are under no obligation to adopt it.⁸ Keep a table of every place your taxonomy departs from the model and why, so the alignment can be shown on request.
• Use the exchange standard for transfers. The eTMF Exchange Mechanism Standard (current version 1.0.2, January 2022) is a specification for moving TMF content between eTMF systems, including CRO-to-sponsor transfers and migrations after a merger or system change. It uses an exchange.xml manifest of the files being transferred, validated against an XSD schema, with checksum verification before import.¹¹ If both the source and target support it, it gives the migration a defined format to work with.

Regulatory Submission Content: The CTD and eCTD Structure

For submission content, the reference structure is the ICH Common Technical Document. ICH M4 organizes the CTD into five modules. Module 1 holds region-specific administrative and prescribing information, and Modules 2 through 5 (summaries, quality, nonclinical, and clinical) are common across regions.¹² The M4 granularity annex defines what counts as one document at each level of the hierarchy. It also warns that once a sponsor chooses how to split content into documents, the same approach should be used for the life of the dossier, because changed information is provided as replacement documents.¹²

That last point is the one that matters most for a DMS. If the DMS stores a Module 3 specification as one document but the dossier treats it as two, every update requires manual rework at publishing time. The submission document types and subtypes in the DMS should match the granularity the company uses in its dossiers.

There is a common mistake, though. A DMS taxonomy should not simply copy the CTD table of contents. The DIA EDM Reference Model guide from 2010, written for companies building document repositories for submissions, made this point clearly. It said the model was organized into domains that translate to submission sections rather than following the structure of any one submission standard, because the same document can be used in several places in a submission, and the repository should store it once.¹³ That guide is old, but the logic still holds. Classify submission content by what it is (a specification, a stability report, a clinical study report) and carry the CTD section as metadata, which can hold more than one value.

What eCTD v4.0 Adds

eCTD v4.0 strengthens the case for that approach. FDA’s eCTD v4.0 page states that CDER and CBER have supported new applications in eCTD v4.0 since September 16, 2024, and accept forward compatibility for existing v3.2.2 applications as of October 16, 2026.¹⁶ FDA’s v4.0 technical conformance guide explains that a v4.0 message can refer to documents submitted earlier in separate applications by their unique identifier, so “a document can be referenced without including the physical file in the new message.”¹⁷ The same guide explains that keywords replace the eCTD 3.2.2 attributes, and that document type keywords replace file tags.¹⁷ An IQVIA white paper notes that v4.0 is accepted voluntarily in the US and EU and is mandatory in Japan for new marketing authorization applications, and that it allows metadata and keyword updates without resubmitting the physical files.¹⁸

For the DMS, this means three things. Each submission-ready document needs a stable identifier that does not change when the document is reused. Document type and CTD section metadata should be designed so they can be translated to v4.0 keywords. And the controlled lists behind product, substance, and manufacturer fields should match what the publishing tool will need.

Some eCTD rules also affect how the DMS should name and title files. FDA’s eCTD guidance requires that folder and file names use only letters, numbers, hyphens, or underscores, with no spaces or special characters, and that the full path not exceed 150 characters.¹⁴ FDA’s v3.2.2 technical conformance guide makes a related point about titles: “Although some eCTD tools generate leaf titles that are similar to file names, the two are not related.”¹⁵ The DMS document title, the rendition file name, and the eCTD leaf title are three different values, and the taxonomy should say where each one comes from.

Quality and Manufacturing Content: Build From Chapter 4

There is no industry reference model for GMP and quality documents with the reach of the TMF model. The best starting point is the documentation type list in EU GMP Chapter 4, because it is short, defined, and already the vocabulary inspectors use: site master file, specifications, manufacturing formulae and processing instructions, procedures, protocols, technical agreements, records, certificates of analysis, and reports.¹ Use those as the top-level types for the quality and manufacturing domains, then add subtypes only where behavior differs (for example, a master batch record and a packaging instruction are both manufacturing instructions, but they may have different approvers).

Where the Reference Models Stop

The reference models describe documents. They do not describe the business objects those documents are about: products, substances, studies, sites, and registrations. DIA’s RIM Reference Model V2.0 draws that line directly, describing the EDM and TMF models as document and metadata centered while the RIM model is about processes, data objects, attributes, and their relationships.⁹ Its product objects run from product family down to individual medicinal products and align with standards such as IDMP, HL7 FHIR, and the eCTD.⁹

For a taxonomy project this is useful in a practical way. The product, study, and site fields on documents should draw their values from the system that owns those objects, whether that is a RIM system, a clinical trial management system, or a master data service. A product field typed by hand in the DMS will not match the product list in RIM, and the mismatch will surface the first time someone tries to pull every document for one product.

Step Four: Define the Required Metadata

Metadata is where most legacy document systems go wrong over time. Fields are added for one project, made optional to avoid blocking users, and filled inconsistently. The redesign is a chance to set a smaller, stricter set. The EMA trial master file guideline gives a useful list of what metadata can include: creator or author, date and time of creation, archiving date, location in the eTMF, file title or keywords, version, file type, file size, and other file properties.⁴ For a cross-domain DMS, organize the required fields into three layers.

Three Layers of Metadata

Controlled Lists and Where They Come From

Every field that will be used to search, filter, report, or drive a workflow should take its value from a controlled list, not free text. For each list, the taxonomy should name the source system, the owner who can add or retire values, and how changes reach the DMS. Product, study, and site lists are the most important, because they connect documents to the rest of the business. If those lists are maintained by hand in the DMS, they will drift from the source within months.

Free text still has a place. Titles, descriptions, and change summaries should be free text. The test is simple: if anyone will ever need to find all documents with a given value, the field needs a list.

Define What Each Date Means

Dates cause more confusion in migrated content than almost any other field. A legacy system may hold a creation date, an upload date, an approval date, an effective date, and a “document date” typed by the user, and the migration tool may populate the new system’s created date with the date of the migration run. The EMA trial master file guideline asks for a predefined document date, with time based on a standard time zone where appropriate, so files can be shown in chronological order. It also suggests defining which dates are used for filing, such as date of receipt, date of filing, date of approval, or date of expiration.⁴ Chapter 4 requires the effective date of instruction documents to be defined.¹

The taxonomy should list each date field, define what event it records, say which legacy field populates it during migration, and state what happens when the legacy value is missing. Leaving a migrated date blank with a recorded reason is better than filling it with the migration date and implying an event that never happened.

Keep the Required Set Small

Every required field is a field a user must complete for every document of that type, forever. Required fields that are not used for search, workflow, retention, or reporting become fields that users fill with whatever lets them save. A practical review question for each proposed field is: who will use this value, and for what? If nobody can answer, make it optional or drop it.

Step Five: Assign Owners, Review Cycles, and Retention

Without owners, a new taxonomy becomes as inconsistent as the one it replaced, and just as quickly. The redesign should assign ownership at two levels and attach a review rule and a retention rule to every type.

Type Owners and Document Owners Are Different Roles

A document owner is responsible for the content of one document: keeping it accurate, starting revisions, and completing periodic review. A type owner is responsible for the type itself: its definition, its required fields, its template, its lifecycle, and decisions about what belongs in it. The head of quality systems might own the SOP type, while hundreds of individual procedure owners each own their own SOPs.

Type owners should be named by role, not by person, so that ownership survives staff changes. Each type owner should also be the person who approves changes to that type’s configuration and who answers filing questions. When a type has no plausible owner, that is a strong sign it should be merged or retired.

Setting Periodic Review Cycles by Type

Chapter 4 says that quality system documents “should be regularly reviewed and kept up-to-date,” but it does not set an interval.¹ That leaves the company to choose and justify one. The taxonomy is the right place to record it, because different types need different rules:

• Fixed interval for instruction documents that drive GxP work, such as procedures, work instructions, and specifications. The interval is a company decision based on risk and rate of change.
• Event-driven review for documents tied to something that changes on its own schedule, such as technical agreements (reviewed at renewal or on a change in the outsourced activity) or the site master file (reviewed when the site changes).
• No periodic review for records and reports, which document what happened and should not be revised. Executed batch records, completed validation reports, and clinical study reports belong here.

Configuring the review rule on the type lets the DMS create review tasks automatically and report overdue reviews by type and owner. Setting it document by document, which many legacy systems do, makes that reporting unreliable.

Retention Belongs to the Type

Retention rules should also be attached to types, not decided per document. Chapter 4 gives specific requirements for batch documentation, which “must be kept for one year after expiry of the batch to which it relates or at least five years after certification of the batch by the Qualified Person, whichever is the longer.” For other documentation, it says the retention period depends on the business activity the documentation supports, and that critical documentation, including raw data supporting the marketing authorization, should be kept while the authorization remains in force.¹ For clinical records, ICH E6(R3) asks sponsors and investigators to retain essential records according to applicable regulatory requirements.³

In practice, the taxonomy should record a retention rule for each type, expressed as a trigger plus a period (for example, “five years after batch certification or one year after batch expiry, whichever is later”), and point to the company’s retention schedule for the justification. The trigger matters as much as the period, because the DMS needs a date field that records the trigger event. A rule of “keep while the marketing authorization is in force” only works if the document is linked to the authorization.

Governance for Changes to the Taxonomy Itself

After go-live, people will ask for new types and new fields. Some requests will be valid. Without a process, the new system will grow the same overlaps the old one had. Put the taxonomy under change control: a short procedure that says who can request a change, who reviews it (the affected type owners plus quality for GxP types), and what evidence is needed (the documents that do not fit the current types, and why a subtype or metadata value will not work). Review the full taxonomy once a year, retire types with no new documents, and check fill rates on required fields.

A Sample Taxonomy Table

The table below shows what a finished taxonomy looks like for a small to mid-size company with GMP manufacturing, clinical trials, and regulatory submissions. It is illustrative. The prefixes, review intervals, and owner roles are examples of choices a company makes, not regulatory requirements, and each company will set its own based on its risk assessment and organization. The alignment column shows where each type maps to Chapter 4 documentation types, the TMF model, or the CTD.

A few design choices in this table are worth explaining. The number format carries only a type prefix and a sequence, as described in step two. The clinical artifact type relies on the TMF model’s artifact ID as a metadata field rather than creating a separate DMS type for every artifact, which keeps the type list manageable while preserving full alignment. Submission components carry the CTD section as a repeatable field, so one document can support several sections without being stored twice. And records and reports have no periodic review, because they document events and are not revised.

Step Six: Map Old to New for the Migration

The crosswalk is where the taxonomy becomes a migration input. It is a table with one row for every legacy type (and, for complex types, every legacy type and subtype combination), showing where its documents go and how each field is transformed. Migration tools load from it. Testers verify against it. Quality approves it.

Four Kinds of Mapping

Metadata Transformation Rules

Each target field needs a row in the crosswalk that names its legacy source and the transformation: copy as is, map through a lookup table (for example, legacy site names to the new site list), derive from another field, set a default, or leave blank with a reason. Lookup tables are where most of the effort goes, because legacy free-text fields hold many spellings of the same value. Build and approve those tables before the first trial load, and decide in advance what happens to values that do not match.

Two fields deserve special attention. Keep the legacy document number and the legacy source system as fields on every migrated document, so that references in older records, training histories, and regulatory correspondence can still be resolved. And map dates by definition, as described in step four, so that a migrated approval date means the same event as a native one.

What the Crosswalk Means for Validation

The crosswalk is also the specification the migration is verified against. EU GMP Annex 11 says that when data are moved to another format or system, “validation should include checks that data are not altered in value and/or meaning during this migration process.”¹⁹ The EMA trial master file guideline asks that any transfer or migration be validated “to ensure that migrated data have the same information as the original, including metadata.”⁴ The MHRA’s data integrity guidance adds a warning that applies directly to taxonomy changes: “The challenges of migrating data are often underestimated, particularly regarding maintaining the full meaning of the migrated records.”²⁰

A taxonomy redesign changes how documents are classified, so the meaning question is real. When three legacy types become one, the migration must show that no information was lost in the merge. In practice that means the legacy type is retained as a field, the derived values (such as site) are verified against the source, and the crosswalk itself is an approved document under change control. If the redesign is approved separately from the migration, the crosswalk shows how the two connect.

The Full Sequence

Mistakes That Undo the Redesign

A few patterns can undo careful taxonomy work late in a project:

• Adding types during configuration. Once the configuration team starts building, requests for “just one more type” bypass the consolidation rules. Route every new type request through the same decision log used in step two.
• Making fields optional to finish the load. When legacy data does not fill a required field, the quick fix is to make the field optional. That fixes the migration and weakens every future document. Use a defined default or a “legacy, not recorded” value instead, so the gap is visible.
• Treating the reference model as fixed. The TMF model is being revised. Store artifact IDs as data so a future version can be mapped without reclassifying every document.
• No owner for the controlled lists. The product, study, and site lists are the first thing to drift after go-live if no one is named to maintain them.

Conclusion

A DMS migration is the one point when a company can change its document taxonomy without reclassifying live content, because the new system has no documents in it yet. The regulations already expect defined document types, unique identification, formally defined metadata, regular review, and migrations that keep meaning intact. A redesigned taxonomy meets those expectations directly, and the reference models for clinical and submission content mean that a large part of the design is already done. What remains is the work only the company can do: deciding which of its own types are real, writing definitions people can follow, naming owners who will keep the structure clean, and building a crosswalk that shows every legacy document has a defensible new home.

Sakara Digital works with pharma and biotech organizations on document management, quality systems, and the data structures underneath them. If you are planning a DMS migration and want an independent view of your current taxonomy before the configuration work starts, we are happy to have that conversation.

For Further Reading