XCEDE: an extensible schema for biomedical data

Abstract

The XCEDE (XML-based Clinical and Experimental Data Exchange) XML schema, developed by members of the BIRN (Biomedical Informatics Research Network), provides an extensive metadata hierarchy for storing, describing and documenting the data generated by scientific studies. Currently at version 2.0, the XCEDE schema serves as a specification for the exchange of scientific data between databases, analysis tools, and web services. It provides a structured metadata hierarchy, storing information relevant to various aspects of an experiment (project, subject, protocol, etc.). Each hierarchy level also provides for the storage of data provenance information allowing for a traceable record of processing and/or changes to the underlying data. The schema is extensible to support the needs of various data modalities and to express types of data not originally envisioned by the developers. The latest version of the XCEDE schema and manual are available from http://www.xcede.org/ .

Figure 1. XCEDE Hierarchy Levels

A conceptual representation of the levels of the XCEDE hierarchy, in the context of a research study with clinical and imaging data.

Figure 2. XCEDE Hierarchy example

Hierarchy “level” elements are bold-faced for clarity. Note that level elements include attributes linking the elements to related elements in the hierarchy (e.g. ‘subjectID’ in ‘visit’ links to ‘subject’). The linked item is not required to be defined within the same document.

Figure 3. Binary Data Resource example

The children of the element are shaded to indicate the (ancestor) type providing those elements. Note that the element name is “resource” but the xsi:type attribute indicates that the content is of the derived type mappedBinaryDataResource_t, which inherits from and adds to the content model of its parent types.

Figure 4. Protocol example

The two components in this (reduced) example are a clinical assessment (Edinburgh Handedness Inventory) and a T1-weighted MR scan, with constraints on timing between the components and on acquisition parameters.

Figure 5. Assessment Item Definition example

The upper section shows how the XCEDE assessment item (shown in the lower section) might be presented in a form. The highlighted portion shows one of five valid options for the edhandinv_writing item (a stored instance of this particular choice is shown in Figure 6).

Figure 6. Assessment Data example

This fragment encodes values from a portion of an assessment based on the Edinburgh Handedness Inventory. The highlighted assessment item labeled edhandinv_writing has a value of 4, which corresponds to the item with itemCode 4 in the edhandinv_writing assessment item definition (Figure 5), which represents “Mostly Right”.

Figure 7. Events example

This XCEDE fragment records audio and visual stimuli, and subject response data (several events are not represented in the XML due to space constraints).

Figure 8. Analysis example

FreeSurfer segmentation statistics represented in XCEDE. Each measurement group contains observations in the context of an anatomical entity (highlighted) representing the objects or concepts referenced by the given term IDs in the given nomenclature (in this case both entities are described by links to FreeSurfer and NeuroLex terminologies).

Figure 9. Catalog example

A file listing annotated with metadata, such as data format identifiers.

Figure 10. Provenance example

One component of a potential multi-step pipeline.

Figure 11. DICOM terminology example

In this example, the DICOM specification is used as a terminology source via fixed attributes in the schema. Top example is the raw XML instance. Bold strings in the lower example show the fixed attributes (from the schema) that might be automatically added by schema-aware XML readers.