EDMS Metadata and Taxonomy: A Practical Field Reference

EDMS metadata should let a reader identify the exact record, determine its permitted use and retrieve its supporting context. Taxonomy supplies the controlled categories used to organize those records. Start with the decisions your workflow must make, then define fields and values that express them consistently.

This reference provides an illustrative field model for life-sciences document control. It is an editorial design aid, not an FDA, ICH, ISO or vendor-mandated schema. The examples describe one possible implementation; adopt them only after checking your document classes, applicable requirements and existing canonical registries.

The model separates identity, classification, lifecycle and relationships. It does not treat a folder location, filename or AI-generated tag as evidence that a document is approved. The intended users are document controllers, system owners and regulatory operations teams defining or reviewing a metadata contract.

Field dictionary for a controlled document

Use the table as a starting dictionary. “Required” below means required by this proposed profile, not a universal legal obligation. A document class may need additional fields, while some conditional fields may not apply. Record those rules explicitly before configuring forms or imports.

For each field, add the steward, permitted cardinality, validation rule, change authority and interface mapping. For example, applicability can reference several sites when the procedure legitimately covers them, whereas a revision's authoritative identity should not become an unordered list of candidate IDs.

Dublin Core's metadata vocabulary distinguishes concepts such as identifier, title, created, modified, source, provenance and version relationships. Its recommendation supports combining terms in application profiles. Use that semantic distinction as a reference, not as a claim that the table above implements the entire DCMI model or an official pharmaceutical standard. DCMI Metadata Terms, issued January20,2020.

Keep identity separate from display labels

Use stable IDs for relationships and keep human-readable labels alongside them. A product name, department label or site abbreviation can change without creating a different underlying entity. If the identifier changes too, record the mapping rather than leaving historical records orphaned.

Do not deduplicate solely on title, filename or file hash. Two records with identical bytes can have different business contexts and obligations. Conversely, two renditions with different bytes can represent the same approved document revision. Establish which object you are identifying before deciding what counts as a duplicate.

Revision identifiers deserve particular care. Values such as 1.10, 1.2, A and A.1 can have meaning under different conventions. Store them without lossy numeric conversion, preserve source labels during migration and use the owning system's defined ordering. A lexically larger label is not universal evidence of the later approved revision.

For instructions within relevant EU GMP scope, Chapter4 paragraph4.3 addresses unique identification, authorized approval and a defined effective date. Those are separate concepts. A unique record ID does not establish approval, and an approval date does not necessarily establish when an instruction becomes effective. EU GMP Chapter4, revision1.

Maintain one canonical registry for each controlled category

A document-type registry should contain a stable ID, preferred label, definition, permitted synonyms, status and steward. Add parent/child relationships only where they express a useful classification. Do not create a deep hierarchy merely to reproduce an old folder tree.

Use existing authoritative product, site, study and organization registries where available. The EDMS can reference or synchronize approved values without becoming a competing master list. Define which system owns changes and what happens when synchronization fails.

Synonyms can improve search while preserving one meaning. For instance, a registry may approve “standard operating procedure” and “SOP” as labels for the same document type. That does not make every term containing “procedure” equivalent. A test method and an operating procedure may need different workflows in your organization.

When merging or retiring categories, preserve historical meaning. Stop offering a retired value for new assignments if appropriate, but retain the identity needed to interpret older records. Record a replacement relationship only when the replacement is actually valid for the affected use.

If an imported value has no approved mapping, route it to a steward. Do not create a new canonical category automatically from each spelling variation, and do not map an ambiguous term to the most popular option simply to finish the import.

For example, a fictional type registry contains active TYPE-SOP with approved synonym “standard operating procedure,” active TYPE-METHOD for test methods, and retired TYPE-PROC-OLD retained for historical records. Apply these mappings:

Retain the registry version or effective mapping used for the decision. If a later review creates a replacement mapping, assess which records it applies to instead of rerunning an unqualified substitution across history. This keeps a helpful synonym from becoming an unauthorized lifecycle change.

Distinguish missing, unknown and not applicable

An empty field can mean several things: not collected, not yet known, not applicable or intentionally withheld. Those meanings lead to different actions. Specify them in the field contract rather than asking each consumer to guess.

For this proposed profile, use a value when established; otherwise record an explicit exception state and owner where the workflow requires a decision. A field that is conditionally not applicable should have the applicable rationale. An unresolved mandatory field blocks the dependent decision, not necessarily every unrelated action on the record.

For example, a draft can be stored while its future effective date is undecided. It cannot be represented as currently effective if the required release decision is unresolved. Similarly, a source file can be received while product applicability is under review, but it should not automatically enter that product's operational search results as an accepted instruction.

Do not encode Unknown as a valid product ID such as 0000 unless the canonical registry explicitly defines that value and its use. Otherwise, software may treat the placeholder as a real product and create false relationships.

Define dates by event and precision

Keep the source record's creation, modification, approval and effectiveness facts distinct from import and indexing times. A migration performed today does not make today the date on which the original author wrote or approved the document.

For cross-system event timestamps, adopt an explicit convention with an offset or UTC representation, using an appropriate supported standard. RFC3339 defines an Internet timestamp format; it is not a regulatory rule that every document field must use that exact syntax. RFC3339.

The examples in this reference use UTC strings such as 2026-09-22T13:00:00Z for known instants. This is a deliberately narrow local convention, not an exhaustive statement of valid RFC3339 syntax. A date-only value may be appropriate for a different business concept. Do not silently convert it into midnight UTC when the required event time and time basis are unknown.

Similarly, 09/10/2026 cannot safely establish whether a source means September10 or October9 without its format context. Retain the original value as evidence and obtain the necessary interpretation before using it in a release or retention calculation.

Worked lookup: one approved revision, two possible uses

Assume a fictional laboratory has record DOC-104, revision 3.0, titled “Sample Handling.” Its document-type registry identifies it as an SOP, its owner is QualityRole7, and its applicability is SiteA. Content approval is complete, but operational release is planned for September23 at13:00UTC and still requires a readiness decision.

At September22 at13:00UTC, the appropriate lifecycle meaning is approved with effectiveness pending under this example's procedure. The future date is known; the unresolved prerequisite is separate. A search result can show the document to an authorized reviewer without presenting it as today's effective instruction.

The final row is important for automation. Passing a syntax check establishes only that property. It does not prove that the metadata value is true or that the record is fit for use. Conversely, an unfamiliar revision label should not be rejected because it differs from another system's convention when the source registry permits it.

Preserve relationships for exports and AI retrieval

Export the IDs, selected revisions, relationship types and relevant context needed by the receiving workflow. A flat folder of PDFs can lose the distinction between an original report, a translated version and a summary derived from it. Agree the receiving representation and test whether another reviewer can reconstruct those relationships.

Search and AI retrieval should use metadata to constrain the relevant record population, while actual authorization remains enforced by the system. A prompt asking for “only SiteA documents” is not a substitute for access controls. Test that prohibited records are not exposed through results, previews, summaries or exports in the intended configuration.

For an AI-generated label, preserve its suggested status until the required review accepts it. A confidence score is useful only within a defined assessment; it does not grant approval authority. Include missing metadata and ambiguous source terms in the evaluation so the workflow demonstrates how it requests clarification.

When the metadata contract changes, identify affected interfaces, saved searches, reports and retrieval rules. Test one ordinary record, one retired value, one unknown field and one historical revision. Do not automatically rewrite old records to today's taxonomy without assessing the effect on their meaning.

Put the dictionary under ownership

Approve the field definitions, controlled-value sources and exception rules together. Keep changes traceable and communicate them to authors, migration teams, administrators and downstream consumers. A well-defined field that nobody maintains will eventually become another free-text guess.

Use the QMS document-control guide to connect the dictionary to actual lifecycle decisions. For source-to-submission relationships, the quality-to-regulatory traceability guide covers the wider handoff.

Assyro publishes this reference. Bring your dictionary and ambiguous-input examples to a document-workflow discussion when evaluating its relevance to regulatory preparation or review. The goal is a demonstrated agreement on what each field means and which decisions it supports.