The three words that changed everything

Consider a site with 15 active clinical trials. The regulatory coordinator has built a meticulous infrastructure over several years: filing systems organized by study, naming conventions that survive staff turnover, version control procedures for protocols and consent forms, and retrieval processes that can produce any document within minutes of an auditor's request. The system works. It has survived FDA inspections and sponsor audits. It is, by any reasonable measure, a well-designed document management infrastructure.

Then ICH E6(R3) reaches final adoption on 6 January 2025, and three words in the glossary definition render that infrastructure incomplete. Not wrong -- incomplete. Where E6(R2) spoke of "essential documents," E6(R3) speaks of "essential records." And the glossary defines those records as "the documents and data (and relevant metadata), in any format" associated with a clinical trial.

Those three additional concepts -- data, metadata, and any format -- are not cosmetic changes. They represent a fundamental expansion of what site-level records infrastructure must accommodate. A system designed to manage documents alone is no longer sufficient. And the regulatory coordinator who designed that system now faces a structural question: what does the infrastructure need to become?

That is the question this lesson addresses. Not at the level of filing individual documents -- that is the CRC's operational domain. But at the level of infrastructure design: how the shift from "essential documents" to "essential records" changes the systems, processes, and architecture that the RC must build and maintain.

From E6 through E6(R2): the documents-only paradigm

Understanding why this shift matters requires understanding what came before it. The original ICH E6, adopted in May 1996, devoted Section 8 to "Essential Documents for the Conduct of a Clinical Trial." The section was organized around a practical taxonomy: documents to be generated before the clinical phase of the trial began (Section 8.2), during the clinical conduct (Section 8.3), and after completion or termination (Section 8.4). Each subsection listed specific documents -- signed protocols, IRB approvals, informed consent forms, monitoring visit reports -- with the purpose of each document stated alongside.

This was, in its time, a genuinely useful framework. It provided investigators and sponsors with a concrete list: these are the documents you must create, maintain, and retain. The emphasis on "documents" was not accidental. In 1996, clinical trials were overwhelmingly paper-based enterprises. The protocol was a printed document. The case report form was a carbonless multi-part form. The informed consent was a paper document signed with a pen. When Section 8 said "essential documents," it meant what sites actually produced and retained: paper.

E6(R2), adopted on 9 November 2016, did not change this fundamental orientation. The R2 addendum addressed risk-based monitoring, quality management, and electronic record considerations -- significant modernizations, to be sure -- but Section 8 retained its structure and its title. "Essential Documents" remained the organizing concept. And while the addendum acknowledged that electronic systems were increasingly used in trials, it did not redefine what "essential" meant at the conceptual level.

The result, by the time E6(R3) development began, was a growing mismatch. Clinical trials in 2020 bore almost no resemblance to clinical trials in 1996. Electronic data capture had replaced paper CRFs. Interactive response technologies managed randomization and drug supply. Wearable devices and sensors generated continuous data streams. Electronic health records served as source data. And yet the regulatory framework for determining what sites must retain still spoke of "documents" -- a word that, for many in the industry, had become synonymous with paper artifacts in regulatory binders.

The E6(R3) definition: every word matters

ICH E6(R3) replaced Section 8 entirely with Appendix C, titled "Essential Records for the Conduct of a Clinical Trial." The change was not limited to swapping "documents" for "records" in the title. The entire framework was reconceptualized.

The glossary definition is the anchor. I want you to read it carefully, because the infrastructure implications are embedded in every clause:

Let me parse this definition into its infrastructure-relevant components, because each one creates a distinct obligation for the regulatory coordinator designing site-level systems.

"Documents and data." This is the most consequential expansion. Under the prior paradigm, the essential documents list was, in practical terms, a catalog of document types: signed protocols, approved consent forms, monitoring reports, delegation logs. Data -- the actual clinical observations, laboratory values, and outcome measurements collected during the trial -- was not absent from site obligations, but it was not framed within the essential documents construct. E6(R3) places documents and data on equal footing. A site's records infrastructure must now accommodate both.

"And relevant metadata." Metadata is data about data -- and this inclusion is, in my view, the most underappreciated element of the definition. When a coordinator electronically signs a case report form at 14:32 on a Thursday, the signature is data. But the timestamp, the user credentials, the system version, the audit trail entry documenting that the signature occurred -- those are metadata. Under E6(R3), that metadata is part of the essential record. A records infrastructure that captures the document but not the metadata is incomplete.

"In any format." Four words that eliminate every format-based excuse for non-retention. Paper documents, electronic documents, PDF files, database extracts, XML data streams, wearable device output files, photographic images, audio recordings of consent discussions where applicable -- the format is irrelevant. If the content meets the essentiality criteria (which Lesson 2 will address in detail), the record must be retained regardless of the medium in which it exists.

"Associated with a clinical trial." This establishes the boundary. Not every record a site produces is an essential record -- only those associated with a clinical trial. But the boundary is broader than it might first appear. Per Appendix C, Section C.2.12, certain essential records "may not be specific to a trial but may be related to the investigational product, facilities or processes and systems, including computerised systems, involved in running multiple trials." A laboratory's accreditation certificate, a site's SOP for informed consent, the validation documentation for an electronic data capture system -- these are not trial-specific, but they are trial-associated. Infrastructure must account for them.

"Facilitate the ongoing management of the trial and collectively allow the evaluation of the methods used." This is the purpose test. An essential record is not essential because it appears on a list. It is essential because it serves one or both of two functions: enabling the ongoing management of the trial, or enabling post-hoc evaluation of how the trial was conducted. When you encounter a record that does not appear on the Essential Records Table in Appendix C but that clearly serves one of these functions, you are looking at a record that may qualify as essential under Section C.3.3.

Appendix C: the new organizational framework

Beyond the definitional expansion, E6(R3) restructured how essential records are organized and managed. Understanding this structure is necessary before you can design infrastructure around it.

Appendix C is divided into three sections, each serving a distinct function:

C.1 (Introduction) establishes the foundational principles. Section C.1.1 acknowledges that the nature and extent of records are dependent on trial design, conduct, and risk-proportionate approaches -- language that connects the essentiality framework directly to the proportionality principles that pervade E6(R3). Section C.1.3 articulates the purposes essential records serve: evaluation of trial conduct, assessment of investigator and sponsor compliance with GCP, assessment of result reliability, investigator oversight and sponsor oversight (including monitoring), independent audit, regulatory inspection, and IRB/IEC review.

C.2 (Management of Essential Records) specifies how essential records should be handled. This section contains requirements that directly shape infrastructure design: records should be identifiable and version-controlled (C.2.1); arrangements must exist for access and management throughout the trial and retention after completion (C.2.2); records should be maintained in or referenced from repositories -- the trial master file for sponsors, the investigator site file for sites (C.2.3); the storage system must provide for identification, version history, search, and retrieval (C.2.4); and records must remain complete, readable, readily available, and directly accessible upon request (C.2.6).

C.3 (Essentiality of Trial Records) provides the criteria for determining which records are essential and includes the Essential Records Table. This section will be the focus of Lesson 2. For now, what matters is the architectural point: essentiality is determined by criteria (C.3.1), not solely by presence on a fixed list. The list exists (C.3.2), but it is explicitly "not an exhaustive list" (C.3.3).

What a documents-only infrastructure misses

This is where the shift from "essential documents" to "essential records" becomes operationally concrete. A site whose records infrastructure was designed around the E6(R2) essential documents paradigm -- even a well-designed one -- has structural gaps under E6(R3). Those gaps fall into predictable categories.

Electronic data in data acquisition tools. The Essential Records Table explicitly includes "Data and relevant metadata (including documentation of data corrections) in the data acquisition tools." Under a documents-only paradigm, a site might have procedures for filing the blank CRF template and the monitoring visit report confirming CRF completion -- but no infrastructure for managing the actual data within the electronic data capture system itself. That data, and the metadata documenting corrections to it, is now an essential record that the site must be able to access, maintain, and retain.

Audit trails and system metadata. When a coordinator enters data into an EDC system, every keystroke generates metadata: who entered the data, when, what was changed, what the prior value was, and the reason for change. Under the documents-only paradigm, sites generally relied on the sponsor's EDC system to maintain this metadata. Under E6(R3), the metadata is part of the essential record. The infrastructure question for the RC is not whether this metadata exists (it does, in the system) but whether the site's records infrastructure accounts for its retention -- particularly at the end of the trial, when sponsor system access may be terminated.

Non-document records from trial systems. Interactive response technology configuration files. Randomization algorithm parameters. Temperature monitoring data from investigational product storage units. Calibration records for laboratory equipment used in the trial. None of these are "documents" in the traditional sense. All of them potentially qualify as essential records under the E6(R3) definition, because they affect the evaluation of trial conduct and result reliability.

Non-trial-specific records. Section C.2.12 explicitly addresses records that "may not be specific to a trial but may be related to the investigational product, facilities or processes and systems, including computerised systems, involved in running multiple trials." A documents-only infrastructure typically organizes everything by study. But site-level SOPs, laboratory accreditation certificates, facility maintenance records, and system validation documentation apply across studies. Infrastructure must accommodate a dual-repository architecture: trial-specific records and site-level records, with cross-referencing between them.

Applying the expanded definition: what counts now that did not count before

The shift from "essential documents" to "essential records" is not merely theoretical. It changes what the RC must inventory, track, and retain. The following table illustrates the practical classification difference by applying the E6(R3) definition to items commonly found at investigator sites.

What this means for the regulatory coordinator

I have spent my career watching well-intentioned regulatory frameworks collide with operational reality, and I want to be direct about what this shift demands. The expansion from "essential documents" to "essential records" does not mean the RC must redesign everything from scratch overnight. But it does mean that every system the RC maintains or builds must be evaluated against the broader definition.

The inventory must expand. A site's records inventory -- the master list of what exists, where it is stored, and who is responsible for it -- must now include data and metadata, not only documents. Per C.2.4, the site must "maintain a record of where essential records are located, including source records." If the inventory only catalogs documents in the regulatory binder, it is incomplete.

The retention strategy must become format-agnostic. Documents have relatively straightforward retention requirements: keep the paper, or keep a certified copy. Data and metadata in electronic systems present different challenges. What happens to the site's access to EDC data when the study closes? Who retains the audit trails? How are wearable device data files preserved when the platform vendor changes its file format? These are infrastructure questions the RC must answer for every study.

The retrieval capability must cover all formats. Section C.2.6 specifies that essential records "remain complete, readable and readily available and are directly accessible upon request by regulatory authorities, monitors and auditors." Directly accessible. If an auditor asks for the audit trail entries associated with a specific participant's data corrections, the site must be able to produce them. If the data exists only in a sponsor-controlled system to which the site no longer has access, the site has a problem.

The repository architecture must accommodate dual structures. Trial-specific records and site-level records (SOPs, facility certifications, system validations) both qualify as essential records. The infrastructure must maintain both, with clear cross-referencing. Module 2 of this course will address this architectural challenge in detail.

What comes next

This lesson established the conceptual foundation: the shift from "essential documents" to "essential records" is a fundamental expansion of scope, not a terminological nicety. The definition in the E6(R3) glossary -- documents, data, and relevant metadata, in any format -- creates infrastructure obligations that a documents-only system cannot meet.

But knowing that the definition has expanded is only the first step. The next question is: how do you determine whether a specific record qualifies as essential? That is not a judgment call the RC makes by intuition. Appendix C, Section C.3.1, provides 28 distinct criteria -- from regulatory submissions (criterion a) to security breach procedures (criterion bb) -- that constitute the essentiality determination framework. That framework, and how to apply it as an infrastructure design tool, is the subject of Lesson 2.

For now, the takeaway is structural. The RC's job is not to file documents. The RC's job is to design, build, and maintain the systems that ensure every essential record -- document, data, or metadata, in whatever format it exists -- is captured, organized, version-controlled, retrievable, and retained. Everything in this course flows from that expanded mandate.

Key takeaways

The terminology shift is substantive, not cosmetic. E6(R3) replaced "essential documents" with "essential records" to capture a broader reality: what sites must retain now includes documents, data, and relevant metadata in any format. This is codified in the glossary definition and operationalized throughout Appendix C.

Three additions drive infrastructure change. The inclusion of data (not just documents), metadata (not just the records themselves), and any format (not just paper or conventional electronic documents) each creates distinct infrastructure obligations that a documents-only system cannot satisfy.

Appendix C restructured the framework. The old Section 8 was a list organized by trial phase. Appendix C provides a conceptual framework: C.1 establishes principles, C.2 specifies management requirements (including the critical C.2.4 requirements for identification, version history, search, and retrieval), and C.3 provides essentiality criteria. This structure treats essential records as a system design problem, not merely a filing exercise.

Non-trial-specific records are explicitly included. Section C.2.12 brings site-level SOPs, system validations, facility records, and cross-study documentation into the essential records framework. Infrastructure must accommodate both trial-specific and site-level records.

The RC's mandate is infrastructure, not filing. The shift from "essential documents" to "essential records" is fundamentally a shift in what the RC must design systems to accommodate. Every subsequent module in this course builds on this expanded foundation.

The three words that changed everything

Consider a site with 15 active clinical trials. The regulatory coordinator has built a meticulous infrastructure over several years: filing systems organized by study, naming conventions that survive staff turnover, version control procedures for protocols and consent forms, and retrieval processes that can produce any document within minutes of an auditor's request. The system works. It has survived FDA inspections and sponsor audits. It is, by any reasonable measure, a well-designed document management infrastructure.

Then ICH E6(R3) reaches final adoption on 6 January 2025, and three words in the glossary definition render that infrastructure incomplete. Not wrong -- incomplete. Where E6(R2) spoke of "essential documents," E6(R3) speaks of "essential records." And the glossary defines those records as "the documents and data (and relevant metadata), in any format" associated with a clinical trial.

Those three additional concepts -- data, metadata, and any format -- are not cosmetic changes. They represent a fundamental expansion of what site-level records infrastructure must accommodate. A system designed to manage documents alone is no longer sufficient. And the regulatory coordinator who designed that system now faces a structural question: what does the infrastructure need to become?

That is the question this lesson addresses. Not at the level of filing individual documents -- that is the CRC's operational domain. But at the level of infrastructure design: how the shift from "essential documents" to "essential records" changes the systems, processes, and architecture that the RC must build and maintain.

From E6 through E6(R2): the documents-only paradigm

Understanding why this shift matters requires understanding what came before it. The original ICH E6, adopted in May 1996, devoted Section 8 to "Essential Documents for the Conduct of a Clinical Trial." The section was organized around a practical taxonomy: documents to be generated before the clinical phase of the trial began (Section 8.2), during the clinical conduct (Section 8.3), and after completion or termination (Section 8.4). Each subsection listed specific documents -- signed protocols, IRB approvals, informed consent forms, monitoring visit reports -- with the purpose of each document stated alongside.

This was, in its time, a genuinely useful framework. It provided investigators and sponsors with a concrete list: these are the documents you must create, maintain, and retain. The emphasis on "documents" was not accidental. In 1996, clinical trials were overwhelmingly paper-based enterprises. The protocol was a printed document. The case report form was a carbonless multi-part form. The informed consent was a paper document signed with a pen. When Section 8 said "essential documents," it meant what sites actually produced and retained: paper.

E6(R2), adopted on 9 November 2016, did not change this fundamental orientation. The R2 addendum addressed risk-based monitoring, quality management, and electronic record considerations -- significant modernizations, to be sure -- but Section 8 retained its structure and its title. "Essential Documents" remained the organizing concept. And while the addendum acknowledged that electronic systems were increasingly used in trials, it did not redefine what "essential" meant at the conceptual level.

The result, by the time E6(R3) development began, was a growing mismatch. Clinical trials in 2020 bore almost no resemblance to clinical trials in 1996. Electronic data capture had replaced paper CRFs. Interactive response technologies managed randomization and drug supply. Wearable devices and sensors generated continuous data streams. Electronic health records served as source data. And yet the regulatory framework for determining what sites must retain still spoke of "documents" -- a word that, for many in the industry, had become synonymous with paper artifacts in regulatory binders.

The E6(R3) definition: every word matters

ICH E6(R3) replaced Section 8 entirely with Appendix C, titled "Essential Records for the Conduct of a Clinical Trial." The change was not limited to swapping "documents" for "records" in the title. The entire framework was reconceptualized.

The glossary definition is the anchor. I want you to read it carefully, because the infrastructure implications are embedded in every clause:

Let me parse this definition into its infrastructure-relevant components, because each one creates a distinct obligation for the regulatory coordinator designing site-level systems.

"Documents and data." This is the most consequential expansion. Under the prior paradigm, the essential documents list was, in practical terms, a catalog of document types: signed protocols, approved consent forms, monitoring reports, delegation logs. Data -- the actual clinical observations, laboratory values, and outcome measurements collected during the trial -- was not absent from site obligations, but it was not framed within the essential documents construct. E6(R3) places documents and data on equal footing. A site's records infrastructure must now accommodate both.

"And relevant metadata." Metadata is data about data -- and this inclusion is, in my view, the most underappreciated element of the definition. When a coordinator electronically signs a case report form at 14:32 on a Thursday, the signature is data. But the timestamp, the user credentials, the system version, the audit trail entry documenting that the signature occurred -- those are metadata. Under E6(R3), that metadata is part of the essential record. A records infrastructure that captures the document but not the metadata is incomplete.

"In any format." Four words that eliminate every format-based excuse for non-retention. Paper documents, electronic documents, PDF files, database extracts, XML data streams, wearable device output files, photographic images, audio recordings of consent discussions where applicable -- the format is irrelevant. If the content meets the essentiality criteria (which Lesson 2 will address in detail), the record must be retained regardless of the medium in which it exists.

"Associated with a clinical trial." This establishes the boundary. Not every record a site produces is an essential record -- only those associated with a clinical trial. But the boundary is broader than it might first appear. Per Appendix C, Section C.2.12, certain essential records "may not be specific to a trial but may be related to the investigational product, facilities or processes and systems, including computerised systems, involved in running multiple trials." A laboratory's accreditation certificate, a site's SOP for informed consent, the validation documentation for an electronic data capture system -- these are not trial-specific, but they are trial-associated. Infrastructure must account for them.

"Facilitate the ongoing management of the trial and collectively allow the evaluation of the methods used." This is the purpose test. An essential record is not essential because it appears on a list. It is essential because it serves one or both of two functions: enabling the ongoing management of the trial, or enabling post-hoc evaluation of how the trial was conducted. When you encounter a record that does not appear on the Essential Records Table in Appendix C but that clearly serves one of these functions, you are looking at a record that may qualify as essential under Section C.3.3.

Appendix C: the new organizational framework

Beyond the definitional expansion, E6(R3) restructured how essential records are organized and managed. Understanding this structure is necessary before you can design infrastructure around it.

Appendix C is divided into three sections, each serving a distinct function:

C.1 (Introduction) establishes the foundational principles. Section C.1.1 acknowledges that the nature and extent of records are dependent on trial design, conduct, and risk-proportionate approaches -- language that connects the essentiality framework directly to the proportionality principles that pervade E6(R3). Section C.1.3 articulates the purposes essential records serve: evaluation of trial conduct, assessment of investigator and sponsor compliance with GCP, assessment of result reliability, investigator oversight and sponsor oversight (including monitoring), independent audit, regulatory inspection, and IRB/IEC review.

C.2 (Management of Essential Records) specifies how essential records should be handled. This section contains requirements that directly shape infrastructure design: records should be identifiable and version-controlled (C.2.1); arrangements must exist for access and management throughout the trial and retention after completion (C.2.2); records should be maintained in or referenced from repositories -- the trial master file for sponsors, the investigator site file for sites (C.2.3); the storage system must provide for identification, version history, search, and retrieval (C.2.4); and records must remain complete, readable, readily available, and directly accessible upon request (C.2.6).

C.3 (Essentiality of Trial Records) provides the criteria for determining which records are essential and includes the Essential Records Table. This section will be the focus of Lesson 2. For now, what matters is the architectural point: essentiality is determined by criteria (C.3.1), not solely by presence on a fixed list. The list exists (C.3.2), but it is explicitly "not an exhaustive list" (C.3.3).

What a documents-only infrastructure misses

This is where the shift from "essential documents" to "essential records" becomes operationally concrete. A site whose records infrastructure was designed around the E6(R2) essential documents paradigm -- even a well-designed one -- has structural gaps under E6(R3). Those gaps fall into predictable categories.

Electronic data in data acquisition tools. The Essential Records Table explicitly includes "Data and relevant metadata (including documentation of data corrections) in the data acquisition tools." Under a documents-only paradigm, a site might have procedures for filing the blank CRF template and the monitoring visit report confirming CRF completion -- but no infrastructure for managing the actual data within the electronic data capture system itself. That data, and the metadata documenting corrections to it, is now an essential record that the site must be able to access, maintain, and retain.

Audit trails and system metadata. When a coordinator enters data into an EDC system, every keystroke generates metadata: who entered the data, when, what was changed, what the prior value was, and the reason for change. Under the documents-only paradigm, sites generally relied on the sponsor's EDC system to maintain this metadata. Under E6(R3), the metadata is part of the essential record. The infrastructure question for the RC is not whether this metadata exists (it does, in the system) but whether the site's records infrastructure accounts for its retention -- particularly at the end of the trial, when sponsor system access may be terminated.

Non-document records from trial systems. Interactive response technology configuration files. Randomization algorithm parameters. Temperature monitoring data from investigational product storage units. Calibration records for laboratory equipment used in the trial. None of these are "documents" in the traditional sense. All of them potentially qualify as essential records under the E6(R3) definition, because they affect the evaluation of trial conduct and result reliability.

Non-trial-specific records. Section C.2.12 explicitly addresses records that "may not be specific to a trial but may be related to the investigational product, facilities or processes and systems, including computerised systems, involved in running multiple trials." A documents-only infrastructure typically organizes everything by study. But site-level SOPs, laboratory accreditation certificates, facility maintenance records, and system validation documentation apply across studies. Infrastructure must accommodate a dual-repository architecture: trial-specific records and site-level records, with cross-referencing between them.

Applying the expanded definition: what counts now that did not count before

The shift from "essential documents" to "essential records" is not merely theoretical. It changes what the RC must inventory, track, and retain. The following table illustrates the practical classification difference by applying the E6(R3) definition to items commonly found at investigator sites.

What this means for the regulatory coordinator

I have spent my career watching well-intentioned regulatory frameworks collide with operational reality, and I want to be direct about what this shift demands. The expansion from "essential documents" to "essential records" does not mean the RC must redesign everything from scratch overnight. But it does mean that every system the RC maintains or builds must be evaluated against the broader definition.

The inventory must expand. A site's records inventory -- the master list of what exists, where it is stored, and who is responsible for it -- must now include data and metadata, not only documents. Per C.2.4, the site must "maintain a record of where essential records are located, including source records." If the inventory only catalogs documents in the regulatory binder, it is incomplete.

The retention strategy must become format-agnostic. Documents have relatively straightforward retention requirements: keep the paper, or keep a certified copy. Data and metadata in electronic systems present different challenges. What happens to the site's access to EDC data when the study closes? Who retains the audit trails? How are wearable device data files preserved when the platform vendor changes its file format? These are infrastructure questions the RC must answer for every study.

The retrieval capability must cover all formats. Section C.2.6 specifies that essential records "remain complete, readable and readily available and are directly accessible upon request by regulatory authorities, monitors and auditors." Directly accessible. If an auditor asks for the audit trail entries associated with a specific participant's data corrections, the site must be able to produce them. If the data exists only in a sponsor-controlled system to which the site no longer has access, the site has a problem.

The repository architecture must accommodate dual structures. Trial-specific records and site-level records (SOPs, facility certifications, system validations) both qualify as essential records. The infrastructure must maintain both, with clear cross-referencing. Module 2 of this course will address this architectural challenge in detail.

What comes next

This lesson established the conceptual foundation: the shift from "essential documents" to "essential records" is a fundamental expansion of scope, not a terminological nicety. The definition in the E6(R3) glossary -- documents, data, and relevant metadata, in any format -- creates infrastructure obligations that a documents-only system cannot meet.

But knowing that the definition has expanded is only the first step. The next question is: how do you determine whether a specific record qualifies as essential? That is not a judgment call the RC makes by intuition. Appendix C, Section C.3.1, provides 28 distinct criteria -- from regulatory submissions (criterion a) to security breach procedures (criterion bb) -- that constitute the essentiality determination framework. That framework, and how to apply it as an infrastructure design tool, is the subject of Lesson 2.

For now, the takeaway is structural. The RC's job is not to file documents. The RC's job is to design, build, and maintain the systems that ensure every essential record -- document, data, or metadata, in whatever format it exists -- is captured, organized, version-controlled, retrievable, and retained. Everything in this course flows from that expanded mandate.

Key takeaways

The terminology shift is substantive, not cosmetic. E6(R3) replaced "essential documents" with "essential records" to capture a broader reality: what sites must retain now includes documents, data, and relevant metadata in any format. This is codified in the glossary definition and operationalized throughout Appendix C.

Three additions drive infrastructure change. The inclusion of data (not just documents), metadata (not just the records themselves), and any format (not just paper or conventional electronic documents) each creates distinct infrastructure obligations that a documents-only system cannot satisfy.

Appendix C restructured the framework. The old Section 8 was a list organized by trial phase. Appendix C provides a conceptual framework: C.1 establishes principles, C.2 specifies management requirements (including the critical C.2.4 requirements for identification, version history, search, and retrieval), and C.3 provides essentiality criteria. This structure treats essential records as a system design problem, not merely a filing exercise.

Non-trial-specific records are explicitly included. Section C.2.12 brings site-level SOPs, system validations, facility records, and cross-study documentation into the essential records framework. Infrastructure must accommodate both trial-specific and site-level records.

The RC's mandate is infrastructure, not filing. The shift from "essential documents" to "essential records" is fundamentally a shift in what the RC must design systems to accommodate. Every subsequent module in this course builds on this expanded foundation.