AI-ready data for clinical trials is trial, submission and discovery data that carries the metadata, lineage and defined business terms an AI agent needs to use it correctly. Atlan, the Context Layer for AI, holds that context where your agents can query it. ICH E6(R3), adopted January 6, 2025, already asks for “relevant metadata” with acquired data, and CDISC, OHDSI, the FDA and EMA describe much of the rest.
Atlan’s business glossary holds owned definitions for terms such as “enrolled”, “evaluable” and “data cut”, and certificates mark each dataset Verified, Draft or Deprecated. Custom metadata records a study ID or data-cut date on any asset. Lineage covers connected platforms; SDTM-to-ADaM lineage from a separate statistical environment is a sponsor integration. Atlan MCP serves the glossary, lineage and asset metadata to agents.
- Each dataset an agent reads names its source system, owner and last refresh time, with timestamps as unambiguous as ICH E6(R3) section 4.2.2(d) asks for data entries and transfers.
- Submission data links to its Define-XML and Controlled Terminology release.
- Unblinded assets carry access policy context, so an agent working through MCP sees only the metadata the person asking is permitted to see.
| What it is | Clinical and R&D data with the metadata, lineage and defined terms an AI agent needs to use it correctly |
| Who sets the bar | ICH (E6(R3)), the FDA, EMA, PMDA, CDISC, OHDSI, and the FAIR principles for discovery data |
| Core standards | SDTM, ADaM, Define-XML, CDISC Controlled Terminology, OMOP CDM, ICH M11 |
| Key artifacts | Asset metadata, lineage, glossary terms, certification status, access policy context, pointers to source audit trails |
| Biggest risk | An agent answering from a pre-lock cut, a superseded protocol, or unblinded data |
| Recent and next dates | ICH M11 in effect in the EU since June 11, 2026 (EMA); E6(R3) Annex 2 in effect in the EU from January 15, 2027 (EMA) |
What makes clinical trial data AI-ready?
Clinical trial data is AI-ready when an agent can tell what each value means, where it came from, whether it is current and who may see it, without anyone re-explaining it.
Researchers also use “AI-ready” for benchmark sets: TrialBench offers “23 meticulously curated AI-ready datasets” built from ClinicalTrials.gov (Chen et al., arXiv, 2025). A sponsor means its own live trial and discovery data. According to Wilkinson et al. (Scientific Data, 2016), “ultimate machine-actionability occurs when a machine can make a useful decision regarding data that it has not encountered before.” Your agent meeting an ADaM dataset for the first time is that machine.
Regulators already ask for much of this context, in the data-integrity sense. ICH E6(R3) section 4.2.1 says acquired data “should be accompanied by relevant metadata” (ICH, 2025). The EMA’s guideline on computerised systems and electronic data in clinical trials (2023) is blunter: “Without the context provided by metadata, the data have no meaning.” Reading those clauses as a spec for agents is Atlan’s interpretation. The general case is covered in AI-ready data and trusted data for AI, and the role of metadata in enterprise AI explains why the metadata matters. Submission-grade data can still lack the operational meaning, version and access context an agent needs. That gap is one reason AI projects stall on data rather than models.
The scope here is sponsor-side. Provider-side care (HIPAA, FHIR, decision support) is covered in the context layer for provider-side healthcare AI, AI agents in healthcare and whether to build or buy a healthcare context layer. A context layer gives trial meaning one home. Each new agent then reads the same definitions an inspector reads, instead of carrying its own copy in a prompt.
Which clinical and R&D data domains need different context?
Trial operations, submission tabulation, analysis datasets, dataset metadata, terminology, real-world data, discovery assays and protocols each answer to a different standard, so each needs its own context before an agent can use it. Treating “clinical data” as one blob is a data architecture for AI mistake.
The standards column quotes each source; the last two columns are Atlan’s synthesis.
| Data domain | Typical content | Governing standard / reference | Context an agent needs before it can use the data | What goes wrong without it |
|---|---|---|---|---|
| Trial operational data (CTMS, EDC, IRT) | Site status, enrollment, queries, visits | ICH E6(R3) 4.2.1(b): acquired data “should be accompanied by relevant metadata” (ICH E6(R3)) | Status definitions (“enrolled”, “randomized”) per system; owner; last refresh; blinded fields | Agent mixes “enrolled” from one system with “randomized” from another and ranks sites wrongly |
| Submission tabulation data (SDTM) | Domains such as DM, AE, LB, EX | CDISC SDTM, “one of the required standards for data submission to FDA (U.S.) and PMDA (Japan)”; SDTM v2.1, June 10, 2024 (CDISC) | Study, data cut and lock status; Define-XML for variable meaning; Controlled Terminology version | Agent pulls a pre-lock cut or misreads a value coded under another CT version |
| Analysis datasets (ADaM) | ADSL, BDS, OCCDS datasets feeding TLFs | CDISC ADaM supports “traceability among analysis results, analysis data, and data represented in” SDTM (CDISC) | Lineage from ADaM back to SDTM; analysis population flags; SAP version | Agent reports an efficacy number from the wrong analysis population |
| Dataset-level metadata | Variable names, labels, codelists, origins | Define-XML “transmits metadata that describes any tabular dataset structure”; required by FDA and PMDA (CDISC) | The Define-XML, linked to the tables the agent queries | Agent sees column names but not derivation or codelist |
| Controlled terminology | Codelists and valid values | CDISC CT: “the set of codelists and valid values used with data items within CDISC-defined datasets”, released quarterly with NCI EVS; as of November 2, 2026, the latest release was September 25, 2026 (CDISC) | Which CT release each study used | Cross-study pooling silently mixes codelist versions |
| Real-world data (EHR, claims, registries) | Patient-level observational records | OMOP CDM, “designed to standardize the structure and content of observational data”, with the OHDSI standardized vocabularies as “a central component”; current version v5.5 (OHDSI) | Vocabulary version; concept sets per criterion; coverage period; consent and use restrictions | Feasibility counts reflect a phenotype that does not match the inclusion criteria |
| Lab, omics, assay data (discovery) | Assay results, sequencing, compound data | FAIR: “(meta)data are associated with detailed provenance” (R1.2) and “meet domain-relevant community standards” (R1.3) (Wilkinson et al., 2016) | Persistent identifiers (F1), units and assay protocol, sample provenance, license and usage terms (R1.1) | Target-ranking agent merges results with mismatched identifiers or units |
| Protocols and study documents (unstructured) | Protocols, SAPs, CSRs | ICH M11 CeSHarP structured protocol template (adopted by EMA December 11, 2025; in effect in the EU from June 11, 2026) (EMA) | Protocol version and amendment history, linked to the study’s data assets | Agent answers from a superseded protocol amendment |
OMOP vocabularies and CDISC Controlled Terminology fix what a code means across studies. Protocols, SAPs and CSRs are unstructured data for AI and need their version history attached before any agent quotes them.
What do the FDA, EMA and ICH expect from the data behind trial AI?
ICH E6(R3), the EMA reflection paper, the FDA’s draft guidance (January 2025) and the joint FDA and EMA guiding principles ask, in different words, for data whose source, processing and meaning are documented and traceable. The FDA draft “proposes a risk-based credibility assessment framework” for an AI model’s “particular context of use (COU)”, and it remains a draft on the Federal Register notice as of November 2, 2026.
Every regulatory and standards quote here is verbatim from the primary source linked beside it. The artifact and reader columns are Atlan’s mapping.
| Source and clause | What it asks for (verbatim) | Artifact that evidences it | Who reads it |
|---|---|---|---|
| ICH E6(R3) 4.2.1(b) | “Acquired data from any source … should be accompanied by relevant metadata.” | Asset metadata: source system, capture method, owner | Inspectors, agents |
| ICH E6(R3) 4.2.2(a)(ii) | “the initial data entry and any subsequent changes or deletions are documented” | Audit trail stays in the EDC; a custom metadata field records where it lives | Inspectors |
| ICH E6(R3) 4.2.2(d) | “date and time of data entries or transfer are unambiguous (e.g., coordinated universal time (UTC))” | Timestamps stay in source systems and transfer logs; lineage points to the transfer jobs | Inspectors, data engineering |
| ICH E6(R3) 4.2.5 | “The data exchange/transfer process or system migration should be documented to ensure traceability” | Lineage across transfer and migration jobs; reconciliation records | Data engineering, QA |
| ICH E6(R3) 4.2.6© | “determination of data analysis sets … should be documented” | Lineage from analysis set to SDTM and data cut, tied to SAP version | Biostatistics |
| ICH E6(R3) 4.1.2 | “procedures for access to unblinded information should be defined and documented” | Unblinded assets classified; data access enforced in source systems | Agents, IT |
| 21 CFR 11.10(e) | “secure, computer-generated, time-stamped audit trails” | The audit trail stays with the source system | Inspectors |
| EMA computerised systems guideline (2023), ALCOA++ | “attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, available when needed and traceable” | Owner, source and lineage support attributable and traceable; the rest stay with the source system | Inspectors, QA |
| FDA draft AI guidance (January 2025, docket FDA-2024-D-4689), Step 4 | data “should be fit for use … both relevant … and reliable (i.e., accurate, complete, and traceable)” | Dataset profile: population coverage, completeness checks, lineage | Credibility assessment plan authors |
| FDA draft AI guidance, Step 4 | “collected, processed, annotated, stored, controlled, and used for training and tuning of the AI model” | Lineage plus processing notes for training and tuning datasets | Regulatory, data science |
| FDA draft AI guidance, model evaluation | “how data independence was achieved between development … and test data” | Lineage shows which sources fed each split; subject-level non-overlap needs a documented split procedure | Data science |
| FDA draft AI guidance, background | “inputs differ from the data on which the model was trained (i.e., data drift)” | Data-quality alerts propagated downstream through lineage to the model’s input assets | MLOps |
| EMA reflection paper 2.5.1 | “any processing such as cleaning, transformation … should be documented in a detailed and fully traceable manner” | Lineage plus transformation descriptions per step | Regulatory, QA |
| EMA reflection paper 2.3.3, pivotal trials | “the data pre-processing pipeline and all models should be frozen and documented in a traceable manner” | Frozen in version control; a certificate and lock-date field point to it | Biostatistics |
| FDA/EMA guiding principles (January 2026), principle 6 | “Data source provenance, processing steps, and analytical decisions are documented” | Provenance, lineage and a decision log | All |
Almost every row asks for lineage, definitions or provenance, the material AI model governance runs on. The train, tune and test rows are a training data lineage problem, and principle 6’s “analytical decisions” are what decision traces record. Atlan holds that material; compliance stays with the sponsor’s validated processes.
Which AI uses fall outside the FDA draft’s scope?
The FDA draft excludes two kinds of use. It “does not address the use of AI models (1) in drug discovery or (2) when used for operational efficiencies (e.g., internal workflows, resource allocation, drafting/writing a regulatory submission) that do not impact patient safety, drug quality, or the reliability of results from a nonclinical or clinical study. We encourage sponsors to engage with FDA early if they are uncertain about whether or not their use of AI is within the scope of this guidance.” (FDA, January 2025)
Feasibility and site-selection agents may fall under the second exclusion, operational efficiencies. The credibility framework applies when a model is used “to produce information or data intended to support regulatory decision-making,” so read the FDA rows above with that line in mind.
The EMA draws the discovery line differently. According to the EMA reflection paper (2024), discovery AI “can be low regulatory impact if non-optimal performance only affects the developer. However, if results contribute to the total body of evidence presented for regulatory review, principles for non-clinical development (see below) should be followed.” The same section adds that “all models and datasets used should be reviewed by the sponsor” for bias and data quality. A discovery dataset whose results get cited as evidence needs provenance someone can show, and lineage for AI-ready data captured at creation is simpler than a reconstruction under a submission deadline.
What changed between 2024 and 2026?
| Date | Event | Source |
|---|---|---|
| Sep 9, 2024 | EMA reflection paper on AI in the medicinal product lifecycle adopted by CHMP; published September 30, 2024 | EMA |
| Jan 6, 2025 | ICH E6(R3) GCP adopted under Step 4 | ICH |
| Jan 2025 | FDA draft guidance on AI for regulatory decision-making, docket FDA-2024-D-4689 (still draft as of November 2026) | Federal Register |
| Jul 23, 2025 | E6(R3) principles and Annex 1 in effect in the EU | EMA |
| Sep 2025 | FDA announces E6(R3) GCP as final guidance, docket FDA-2023-D-1955 | Federal Register |
| Dec 11, 2025 | ICH M11 template adopted by EMA; EU effective June 11, 2026 | EMA M11 Step 5 template |
| Jan 14, 2026 | FDA and EMA publish 10 guiding principles of good AI practice | EMA |
| Jun 3, 2026 (ICH) / Jun 25, 2026 (CHMP) | ICH E6(R3) Annex 2 adopted; EU effective January 15, 2027 | EMA |
According to the EMA (2026), the two agencies “have jointly identified ten principles for good artificial intelligence (AI) practice in the medicines lifecycle,” and EU guideline work “is already underway.”
Where do AI agents fail on trial feasibility, site selection and target discovery?
Feasibility, site-selection and discovery agents fail in predictable ways without context. The ten failures below are Atlan’s scenarios, reasoned from the standards above rather than drawn from incident data; the clause column is sourced, or marked good practice where no clause applies.
The EMA’s 2023 guideline lists AI used “for trial participant recruitment, determination of eligibility, coding of events” in its scope. Coding and SDTM mapping agents need the same context: the CT release, the Define-XML and the protocol version.
| Use case | Failure mode | Why it happens | Fix (context the agent needs) | Clause it touches |
|---|---|---|---|---|
| Feasibility | Patient counts from RWD do not match protocol eligibility | Criteria coded ad hoc; vocabulary version unknown | Each criterion as an OMOP concept set, versioned with the protocol amendment | E6(R3) 4.2 “full data life cycle”; outside FDA draft scope when purely operational |
| Feasibility | Agent answers from a superseded protocol | Amendments not linked to data assets | Link each protocol version (ICH M11 structure where adopted) to its datasets and concept sets | E6(R3) 4.2 “full data life cycle” |
| Site selection | Sites ranked on inconsistent enrollment metrics | “Enrolled” means different things in two CTMS | Owned glossary term per status, linked to source columns | Good practice (Atlan’s reading of E6(R3) 4.2.1(b)) |
| Site selection | Agent exposes unblinded performance data to blinded staff | Agent has broader access than the people it serves | Unblinded assets classified; access enforced in source systems for agents and people alike | E6(R3) 4.1.2, 4.1.4 |
| Site selection | Stale operational data | No freshness signal | Source-update and sync timestamps checked before answering | Good practice |
| Target discovery | Assay results merged with mismatched IDs or units | No persistent IDs or shared vocabularies | FAIR F1 identifiers, I2 vocabularies, units as metadata | FAIR F1, I2, R1.3 |
| Target discovery | Finding later cited as evidence, but provenance is gone | Team assumed discovery AI is unregulated | Provenance from the start: the EMA applies non-clinical principles once results become evidence | EMA reflection paper 2.3.1; FDA draft (Jan 2025) scope |
| Model supporting a regulatory decision | Test-set leakage | Train and test drawn from overlapping upstream records | Lineage shows which sources fed each split; a documented split procedure covers subject overlap | FDA draft (Jan 2025) model evaluation |
| Pivotal-trial analytics | Pipeline changed after lock | Unversioned preprocessing | Pipeline frozen in version control; certificate and lock-date field point to it | EMA reflection paper 2.3.3 |
| Deployed model with regulatory use | Silent performance drift | Upstream source changed | Data-quality alerts propagated downstream through lineage to the model’s input assets | FDA draft (Jan 2025) data drift; FDA/EMA principle 9 |
Feasibility: counts that do not match the protocol
A feasibility agent is only as good as its translation of eligibility criteria into codes, and the OMOP CDM vocabularies let each criterion become a named concept set. The catch is context drift, or version drift in plain terms. Vocabularies get new releases. Protocols get amended. An unversioned concept set keeps answering for a protocol that no longer exists.
Site selection: inconsistent metrics and unblinded exposure
Define “enrolled” once, give it an owner, and link it to the columns in each CTMS. Then scope the agent. ICH E6(R3) section 4.1.2 asks for defined procedures for “access to unblinded information” (ICH, 2025). For an agent, that means agent access control: the agent inherits the requester’s permissions and follows the same data privacy for AI agents rules as people. A source-update timestamp checked before answering is basic data quality for AI agents.
Target discovery and deployed models
Discovery agents merge results from many assays, so FAIR’s persistent identifiers (F1), FAIR-compliant vocabularies (I2) and community standards (R1.3) decide whether a merge is valid (Wilkinson et al., 2016). A superseded or pre-lock asset feeding an agent is context poisoning, or stale input in plain terms, and the answer looks like agent hallucination even when the model did what its inputs allowed.
How does a context layer make clinical data usable for AI agents?
A context layer holds each dataset’s definitions, lineage, certification status and access policy context in one place and serves them to an agent at query time. An enterprise context layer does this across every system a sponsor runs, and the components of a context layer line up with the crosswalk rows above.
Much of the raw material already sits in sponsor tooling, starting with Define-XML. CDISC’s Analysis Results Standard aims to “Provide traceability to Protocol/Statistical Analysis Plan and to input ADaM data.” The USDM “will serve as a standard model for the development of conformant study definition technologies,” and CDISC Library delivers “CDISC standards metadata to software applications.” The EMA guideline counts CTMS and “statistical software” as in-scope computerised systems. A context layer sits on top, adding a cross-system index agents can query, joined to operational and RWD data.
Owned definitions for clinical terms
“Enrolled”, “evaluable”, “screen failure”, “data cut” and each endpoint become owned glossary terms linked to the columns that hold them. Managing business glossary definitions this way means a site-ranking agent and a biostatistician read one definition.
Lineage from source to submission
CDISC ADaM supports traceability from analysis results back to SDTM, and ICH E6(R3) section 4.2.5 asks that transfers be documented “to ensure traceability” (ICH, 2025). Atlan builds lineage from connected platforms. Where SDTM-to-ADaM derivations run in a separate statistical environment, the sponsor publishes that lineage with the Python SDK’s LineageProcess and owns the integration. Lineage from CROs and vendors reaches only as far as the transfer agreements document. Serving lineage over MCP lets an agent check which data cut it is reading before it answers.
Certification and study-level metadata
Certificates tell people and agents which datasets are ready to use. Verified is a data steward’s readiness label; validation status lives in the sponsor’s quality system. Custom fields can hold study ID, CDISC domain, data-cut date, lock date and a context-of-use tag.
Policy context for blinded and unblinded data
Unblinded assets carry access policy context. Atlan MCP “only returns metadata the connected user is permitted to see in Atlan” (Atlan docs), so an agent working for a blinded study team sees that team’s view. Access to the data itself stays enforced in the EDC or warehouse.
Cataloging unblinded data carries its own risk
ICH E6(R3) section 4.1.4 says “The potential for unblinding should be part of the risk assessment of a blinded trial” (ICH, 2025). A classification tag does not stop indirect unblinding. Row counts, profiles, sample values and lineage edges that touch randomization data can all reveal it. The segregated unblinded environment stays the primary control. The sponsor decides whether unblinded environments are crawled at all, or into a separately permissioned scope, and records that in the risk assessment.
Delivery to agents through MCP
Agents query all of this through the Model Context Protocol on the sponsor’s existing stack. Deciding what the agent sees, and in what form, is context engineering for trial data.
| Aspect | Specs and standards tooling you already run | Added by a context layer |
|---|---|---|
| Where context lives | Define-XML, SAPs, specifications, SOPs | One index across systems, queryable when an agent answers |
| Who reads it | Reviewers and inspectors | Agents as well as people |
| Definitions | SAP and specification documents | Owned glossary terms linked to columns |
| Lineage | ADaM traceability, program logs | Maintained graph, refreshed each time connectors sync |
| Freshness | Checked by hand | Source-update and last-sync timestamps on each asset |
| Unblinded access | Role lists in SOPs | Policy context scoped to the person the agent works for |
The left column stays in place. The right needs ongoing curation, and an agent can query it.
How to assess whether your clinical trial data is AI-ready
Thirteen questions, each tied to a clause or marked good practice, show how far a dataset is from being safe for an agent to read.
Step zero: classify each dataset by criticality and each agent by context of use. ICH E6(R3) section 4.2.2 frames its metadata expectations around “data of higher criticality” (ICH, 2025), and FDA/EMA principle 2 calls for “proportionate validation, risk mitigation, and oversight based on the context of use and determined model risk” (FDA/EMA, 2026). Questions 7, 8 and 11 apply only to models whose output supports a regulatory decision.
| # | Question | Clause it maps to |
|---|---|---|
| 1 | Can you name the source system, owner and last refresh time of each dataset an agent queries? | ICH E6(R3) 4.2.1(b) for source metadata; refresh time is good practice |
| 2 | Is every SDTM and ADaM dataset linked to its Define-XML and the CT release it used? | CDISC Define-XML, Controlled Terminology |
| 3 | Can you show lineage from an analysis output back to SDTM and the data cut? | CDISC ADaM traceability; ICH E6(R3) 4.2.6© |
| 4 | Are operational status terms (“enrolled”, “evaluable”) defined once, owned, and linked to columns? | Good practice (Atlan’s reading of E6(R3) 4.2.1(b)) |
| 5 | Are unblinded assets classified, and is data access for agents enforced in the source systems? | ICH E6(R3) 4.1.2, 4.1.4 |
| 6 | For each RWD feasibility query, is the concept set versioned with the protocol amendment? | OMOP standardized vocabularies |
| 7 | Can you describe how training and tuning data were “collected, processed, annotated, stored, controlled”? | FDA draft guidance (Jan 2025), Step 4; regulatory-use models only |
| 8 | Can you document test data independence from development data? | FDA draft guidance (Jan 2025), model evaluation; regulatory-use models only |
| 9 | Are pipeline and model assets frozen and documented at database lock? | EMA reflection paper 2.3.3 |
| 10 | Do discovery datasets carry persistent identifiers and provenance? | FAIR F1, R1.2 |
| 11 | Will you know when an upstream change affects a deployed model? | FDA draft guidance (Jan 2025) data drift; FDA/EMA principle 9; regulatory-use models only |
| 12 | Can people and agents tell certified datasets apart from drafts and deprecated ones? | Good practice (Atlan’s reading of FDA/EMA principle 6) |
| 13 | Are consent and use restrictions recorded on each patient-level dataset an agent may read? | Good practice |
Score yes = 1, partial = 0.5, no = 0. Low scores mark the rows to fix first.
Two questions sit outside the score. When an agent writes to a GxP system, how are its actions recorded? 21 CFR 11.10(e) expects audit trails of “operator entries and actions.” And is the context layer itself in GxP scope? The EMA guideline’s scope lists “Other computerised systems implemented by the sponsor holding/managing and/or analysing or reporting data relevant to the clinical trial.” The answer depends on intended use. The sponsor decides, and change-controls glossary and certificate edits to match.
Atlan’s recommendation: pick one use case, score only the datasets it reads, and fix definitions and lineage first. A good first candidate is patient-count feasibility for one protocol against one RWD source already mapped to OMOP. From there, the steps to implement an enterprise context layer apply, and bootstrapping context from existing metadata, lineage and query history spares your team from typing it in by hand. Pair it with AI agent governance, and reuse the checklist when evaluating AI readiness platforms.
How does Atlan support AI-ready data for clinical trials?
Atlan holds a sponsor’s lineage, glossary, certificates and custom metadata and serves them to agents over MCP. It is one input to compliance; the sponsor’s validated processes make the claim.
- Lineage. Teams use Atlan lineage to “perform root cause analysis, impact analysis, and automate metadata propagation” (Atlan docs), and alert propagation pushes data-quality alerts downstream through that lineage, so an upstream problem shows up on the assets it affects.
- Glossary. The business glossary “standardizes terminology across your organization and grounds AI in what each term actually means”, and terms link directly to assets (Atlan docs).
- Certificates and custom metadata. Verified, Draft or Deprecated certificates “help users quickly identify whether a data asset is ready to use, a work in progress, or has some issues” (Atlan docs) and can be set through the Python SDK. Custom metadata extends assets “with your own unique properties” (Atlan docs), such as study ID or data-cut date.
Through the Atlan MCP server, agents can “traverse end-to-end lineage, access governed data definitions and glossaries”; it is “a hosted server, available on every Atlan tenant with nothing to install” (Atlan docs).
Context Engineering Studio “generates the semantic layer AI agents need to answer questions accurately” (Atlan docs). You describe the use case, approve the assets it proposes, and get a context repository for the agent.
A custom metadata field on each dataset can record where its EDC or source-system audit trail lives; the sponsor’s validated systems keep those trails.
FAQs about AI-ready data for clinical trials
1. Is CDISC-formatted data automatically AI-ready?
No. SDTM organizes trial data into standard domains, which makes it easier to work with, but an agent still has to know which study and data cut it is reading, whether the database is locked, what each variable means in the Define-XML, and which Controlled Terminology release coded the values. Without that context, a well-formatted dataset can still produce a wrong answer.
2. What metadata does ICH E6(R3) expect with clinical trial data?
ICH E6(R3) section 4.2.1 says acquired data from any source should be accompanied by relevant metadata. Section 4.2.2 adds unambiguous date and time capture, with coordinated universal time given as an example, and audit trails for changes. Section 4.2.5 asks that data and metadata keep their integrity when transferred between systems, with the transfer documented for traceability.
3. What is the difference between FAIR data and AI-ready data?
FAIR is the baseline for discovery data: persistent identifiers, FAIR-compliant vocabularies, detailed provenance and community standards. AI-ready data, as this page uses the term, includes all of that and adds what an agent checks at the moment it answers: owned definitions for business terms, freshness timestamps, certification status and access rules. FAIR makes data findable and reusable. The extra context helps an agent answer correctly and within its permissions.
4. Does AI used in drug discovery need data provenance?
Yes, if its results might ever support a submission. The EMA reflection paper calls discovery AI potentially low regulatory impact when poor performance only affects the developer, but once results contribute to the evidence presented for regulatory review, non-clinical development principles apply. Capturing provenance when the data is created is simpler than rebuilding it after a finding moves toward an IND.
5. Does a context layer replace the EDC audit trail?
No. 21 CFR 11.10(e) and ICH E6(R3) section 4.2.2 place secure, time-stamped audit trails in the systems that create and change the records, such as the EDC. A context layer links each dataset to its source system and can record where that system’s audit trail lives, so an agent or reviewer can find it. The validated source system keeps the trail itself.
6. How does OMOP help AI-driven trial feasibility?
The OMOP Common Data Model standardizes the structure and content of observational data, and its OHDSI standardized vocabularies standardize medical terms across the model’s clinical domains, so conditions, drugs and measurements map to shared standard concepts. A feasibility agent can then express each eligibility criterion as a concept set. Versioning those concept sets with each protocol amendment keeps patient counts tied to the protocol actually in force.
7. Can a context layer make clinical AI GxP-compliant on its own?
No. GxP compliance rests on the sponsor’s validated systems, procedures and quality oversight, including the system validation 21 CFR 11.10(a) requires. A context layer supplies documented provenance, lineage and definitions for those processes to draw on. The joint FDA and EMA guiding principles ask for that material to be documented “in a detailed, traceable, and verifiable manner.”
Sources
Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products, draft guidance, January 2025, docket FDA-2024-D-4689, U.S. Food and Drug Administration (cited by name; the FDA site blocks automated link checks)
-
ICH E6 Good clinical practice - Scientific guideline, European Medicines Agency
-
Guideline on computerised systems and electronic data in clinical trials, European Medicines Agency
-
EMA and FDA set common principles for AI in medicine development, European Medicines Agency
-
Guiding principles of good AI practice in drug development, European Medicines Agency
-
21 CFR 11.10, Controls for closed systems, Electronic Code of Federal Regulations
-
The FAIR Guiding Principles for scientific data management and stewardship, Scientific Data
-
TrialBench: Multi-Modal Artificial Intelligence-Ready Clinical Trial Datasets, arXiv
-
Asset metadata available through Atlan MCP, Atlan Documentation
