ODM Version Changes: When to Quarantine a Clinical Data Transfer

Quarantine an unexpected ODM 2.0 extract when the receiving pipeline is approved only for ODM-XML 1.3.2. Passing an XML parser or even the producer’s schema test does not establish that your loader can interpret the file. Accept it for the agreed processing step only after the version, schema, header, metadata dependencies and required audit information match the receiving contract.

Consider a synthetic scenario: an electronic data capture (EDC) vendor upgrades its platform, and tonight’s endpoint-data transfer changes version. The data manager must decide whether to accept the extract, hold it for investigation, or reject that delivery and request a replacement. The proposed procedure below makes that decision before production ingestion. It is an editorial implementation framework; the study’s approved procedures determine ownership and release authority.

The Clinical Data Interchange Standards Consortium (CDISC) Operational Data Model (ODM) represents clinical study data together with metadata, administrative data, reference data and audit information for exchange and archiving. CDISC explicitly documents a backward-compatibility break in ODM 2.0. A version transition therefore needs evidence for the receiving system’s intended use. ODM v2.0 (CDISC standards page); cdisc-org/DataExchange-ODM: ODM repository.

CDISC published ODM 2.0 on 23 August 2023, and its repository describes that version as replacing 1.3.2. The archived 1.3.2 specification is dated 1 December 2013. Its compatibility statement says files conforming to the 1.2, 1.2.1, 1.3.0 or 1.3.1 schemas also conform to the 1.3.2 schema. That statement about schema compatibility does not establish that every receiving application supports every historical payload. ODM v2.0 (CDISC standards page); cdisc-org/DataExchange-ODM: ODM repository; ODM 1.3.2 Final Specification (CDISC-hosted archive copy).

For a file conforming to ODM 1.3.2, section 2.2 specifies the namespace http://www.cdisc.org/ns/odm/v1.3 and ODMVersion="1.3.2". The public ODM 2.0 schema set instead targets http://www.cdisc.org/ns/odm/v2.0 and defines a 2.0-based ODMVersion pattern. A generic XML parser may read either namespace successfully; a receiver still has to recognize and support the declared model. Do not change the namespace or version attribute to make a file appear compatible. ODM 1.3.2 Final Specification (CDISC-hosted archive copy); ODM 2.0 XML schema set (DataExchange-ODM/schema).

CDISC says ODM 2.0 can be serialized as XML, JSON or other formats and links an XML schema. That establishes a representation choice, not that an XML receiving system can consume JSON. This article’s checks concern an agreed XML exchange. A move to JSON needs its own approved representation and receiver tests. ODM v2.0 (CDISC standards page).

Audit information requires particular care. CDISC’s January 2023 public-review slides list AuditRecords and Annotations among deprecated constructs. Those slides predate the final release and do not establish that a final ODM 2.0 file necessarily lacks audit data or needs a separately bundled audit supplement. The public schema set includes AuditRecord references, including within Query. Assess the actual schema profile, supported structures and delivered history rather than inferring completeness from a version number or an old slide. ODM v2.0: Public Review (CDISC, 2023-01-12); ODM 2.0 XML schema set (DataExchange-ODM/schema).

The practical distinction is between a documented model change and a demonstrated implementation failure. The version-family warning justifies stopping an unapproved transition. It does not prove that a named vendor crashes, silently drops fields or corrupts a database. Those behaviors require implementation-specific testing.

The cases in this matrix are synthetic. They are proposed operational decisions, not CDISC-defined error codes or regulator-prescribed dispositions. The version row illustrates the documented compatibility break. Other rows illustrate failures that can occur within either generation, including well-formed XML that is unacceptable for the agreed purpose. The syntax row is deliberately identified as a syntax failure.

The matrix draws on the published compatibility warning, public schema artifacts and the archived 1.3.2 rules. For 1.3.2, section 2.2 distinguishes syntactic and semantic conformity; section 2.8 addresses linked files and archival content; section 3.1 defines the header. The recommended acceptance and quarantine actions are applications of that evidence. ODM v2.0 (CDISC standards page); ODM 2.0 XML schema set (DataExchange-ODM/schema); ODM 1.3.2 Final Specification (CDISC-hosted archive copy).

FileType distinguishes Snapshot from Transactional. Granularity describes scope, such as Metadata, AllClinicalData or SingleSubject, when supplied. In the public 2.0 XSD, FileType, FileOID and CreationDateTime are required while Granularity is optional. A local agreement may require additional header fields, but the validation report should distinguish a schema requirement from a study-specific requirement. Check Originator, SourceSystem and SourceSystemVersion against the delivery specification where those fields are agreed.

Acceptance requires every applicable row to pass and an attributable release decision under the study procedure. A schema pass cannot override an unresolved metadata dependency. Equally, a routine extract need not carry an entire study archive if that is outside its agreed purpose and the required source records remain retained and retrievable.

In this synthetic case, the producer supplies an XML extract using the v2.0 namespace and ODMVersion="2.0". Its own validation report records a pass against its selected 2.0 schema set. The receiving contract specifies 1.3.2, and the receiving loader has no approved 2.0 configuration. The discrepancy is already sufficient to quarantine the delivery. There is no need to run it against production to discover how an unsupported loader behaves.

The data manager records the received file identifier, receipt time, checksum, declarations and producer report, then links the discrepancy to the receiving-contract revision. The producer can supply the agreed 1.3.2 export, if its qualified export process supports it, or the system owner can assess a planned transition. A locally rewritten version attribute is not a conversion. Any adapter needs documented mappings and evidence that it preserves the content and context required by the receiving workflow.

For a transition, include representative clinical values, references and required history in the test package. Define expected results before running the receiver. Compare those results with what the receiving system actually stores and makes available for review. Approval of the change and successful reprocessing should be linked to the original held delivery so that the eventual disposition remains traceable.

In a second synthetic case, a 1.3.2 delivery is well-formed and passes its selected XSD. Its header records CreationDateTime="2026-10-21T14:15:00Z" and AsOfDateTime="2026-10-21T15:00:00Z". Section 3.1 of the 1.3.2 specification makes an AsOfDateTime later than CreationDateTime an error. The timestamps can each be lexically valid while their relationship fails this semantic rule. Check the relationship separately rather than treating an XSD pass as full conformity. ODM 1.3.2 Final Specification (CDISC-hosted archive copy).

Assume the same delivery is marked Archival="Yes" and FileType="Transactional". Section 2.8 requires archival files to be Transactional and addresses completeness across a file or linked collection, including available source audit and signature information. Section 2.10 adds ordering rules for transactions, signatures and audit records associated with an entity. A Snapshot containing only current values is not an adequate substitute for this declared archival purpose. ODM 1.3.2 Final Specification (CDISC-hosted archive copy).

Suppose the producer confirms historical audit records exist, but the delivered collection omits them. That confirmation makes the deficiency concrete. Counting zero AuditRecord nodes alone would not establish missing history: the check must use the correct namespace, inspect the agreed structures and collection, and compare with what is available in the source. Record the timestamp error and the missing-history discrepancy separately, request correction, and repeat both checks before release. Neither error by itself establishes a legal finding of Part 11 noncompliance.

For electronic records within Part 11’s scope and a closed-system context, 21 CFR 11.10 addresses system validation in paragraph (a), accurate and complete human-readable and electronic copies in paragraph (b), and secure time-stamped audit trails with retention and review availability in paragraph (e). Applicability depends on the regulated records and predicate requirements. These provisions do not prescribe an ODM version or the six-row matrix above. 21 CFR 11.10 - Controls for closed systems; Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (Final, October 2024).

FDA’s final October 2024 electronic-systems Questions and Answers, Procedural Revision 1, recommends risk-based validation. Q7 explicitly includes data transfers and interfaces and says changes should be evaluated and validated depending on risk. Q7 and Q14 also discuss enforcement discretion for certain Part 11 provisions while applicable predicate rules continue to matter. The guidance contains nonbinding recommendations; the intake procedure is a way to organize implementation evidence, not an FDA certification. Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (Final, October 2024).

Operational intake and submission metadata are separate decisions. On 21 October 2026, CDISC’s Define-XML version table paired Define-XML v2.1.11, dated 6 April 2026, with ODM-XML v1.3.2. CDISC describes Define-XML as metadata for tabular datasets. FDA’s Data Standards Catalog page identifies the March 2025 final Level 2 guidance; the catalog should be checked for the standards applicable to a particular submission. The publication of ODM 2.0 does not itself establish an obligation to accept it or demonstrate submission readiness. Define-XML (CDISC standards page); Data Standards Catalog (FDA, March 2025).

A specification that says only “daily CDISC ODM transfer” leaves the receiving decision unresolved. Use the matrix to define an agreement between the producer, data management and the receiving-system owner. The following are proposed contract fields rather than universal mandated terms:

• Generation and representation: identify the approved ODM release, XML serialization, encoding and exact namespace. List supported alternatives explicitly; do not interpret a schema’s version pattern as approval for every point release.

• Schema baseline: retain the selected XSD set, its includes and imports, approved extension schemas and a stable release or repository revision. Record digests so the validation report can identify the actual artifacts used. A changing main branch is not a pinned baseline.

• Header and scope: define expected FileType, Granularity when needed, file identification, sequence handling and timestamp rules. Separate the applicable standard’s requirements from extra requirements chosen for the study.

• Metadata dependencies: identify how StudyOID and MetaDataVersionOID resolve, which versions the receiver supports, and how prior-file dependencies are supplied and retained. An older approved metadata version need not be rejected merely because a newer one exists.

• Audit and signature scope: distinguish a routine exchange from an archival deliverable. Identify the source inventory and how required history, signatures and referenced administrative data will be available. Evaluate completeness across the agreed delivery or linked collection.

• Disposition and ownership: name who investigates each failure, who authorizes reprocessing and who approves release. Define notification and correction targets appropriate to the study rather than borrowing arbitrary fixed deadlines.

• Change control: define advance notice, test deliveries and approval before changing the producer export or receiving configuration. Assess affected mappings and retained history as part of the change; link the resulting evidence to the contract revision.

The acceptance record should identify the original delivery, producer, receipt time, file checksum, contract revision, schema artifacts, individual check outcomes, discrepancies, decision time and responsible role. A checksum supports identification of the received bytes; it does not independently prove who sent them, that their content is correct or that the source history is complete.

For quarantine, preserve the original and prevent its release to the production import step. Investigate a failed export through the established incident or discrepancy process. If resolution requires changing the approved interface, invoke system change control; a routine malformed delivery does not automatically require redesigning the system. Rejection and replacement should retain the connection between the original file, the correction request and the replacement’s fresh acceptance results.

Passing this procedure establishes only the documented checks for the agreed exchange purpose. It does not certify clinical values, endpoint validity, statistical analysis or submission readiness. Continue with participant, visit and timestamp reconciliation, resolve discrepancies through clinical data management queries, and retain the required evidence before database lock.

The broader computerized-system validation lifecycle and CDISC QRS mapping decisions remain separate workstreams. This article provides a receiving decision, not vendor qualification or instrument-validation evidence. No vendor systems were tested; all worked deliveries are hypothetical.

The detailed ODM 2.0 specification is linked through a CDISC Wiki that requires registration. Public pages, schema artifacts, the archived 1.3.2 specification and historical slides support the bounded claims here. Verify the final specification and the exact artifacts selected for your implementation before cutover. A version name, a readable file and an XSD pass are useful evidence, but none alone authorizes a changed transfer contract.