XNAT Development

Best Practices for Development


Other topics

[Edit Nav]

XNAT Feature Requests : Project Relationship Model

ID: 1314
Module: XNAT
Source: CNDA (Dan Marcus & Jenny Gurney)
Creation Date: 5/3/2010

Authors: Tim Olsen, John Paulett

Background: There are often relationships between projects which are not captured by the current XNAT xml model. There are often certain requirements regarding subject and data ownership which are defined by these relationships between projects. There are two common models for these kinds of relationships in the CNDA:

  • Multi-site studies: To model a multi-site study in XNAT, users often create separate projects for each site in the study. The goal is that each site should have ownership of its own data, and not the ability to modify data from other sites. However, the overall project administrators often want access to all of the data over all of the sites. Additionally, there are sometimes some assessments created that don't belong at the site, but rather are for the overall project (phone encouter logs). (Jenny: I don't know of a need for this -- is this Dan's?) For this situation, an overall 'umbrella' project is created. The data (often just the subjects) from each of the sites is shared into the umbrella project for the benefit of project administrators, and some unique assessments may be assigned to this umbrella project.
  • Subject Pool: In a lab setting, the same subjects are often recruited to participate in different studies. To model this, a lab wide project is often created. Subjects are owned by this lab project and shared into the relevant projects that the subject participated in. This allows a single person (or persons) to be in charge of the demographic data for the subject, but still allows for the experiments to be owned by the relevant project.

These are only two examples of how the relationship between projects can effect data ownership. In effect, these relationships determine a sharing policy between two ( or more ) projects. This could be referred to as an auto-share feature, in that one project would want to make sure that all of its data is shared into another project. The level of data shared could be quite dynamic based on the nature of the relationship between projects. Some projects may want to share all subjects to another project. Other projects may want to share all subjects and MR sessions. Other projects may want to share everything. The types of data shared based on a relationship are dynamic. What is static is that all data of the specified data type should be shared to the other project. (Jenny: This is not correct in the PCB_PIB case. I sometimes need to share only certain instances of a data type).

Issues: The sharing of subjects into child or parent projects is often not performed by users. Instead, subjects are often duplicated into the child or parent projects. This leads to the need to merge the subjects later on (usually when processing needs access to data from multiple projects).

Notes: I think the sharing behavior would need to support either a push or a pull model. Initially we thought a push model might be adequate. But, in the subject pool model, the sub-project may not want all of the subjects from the lab to be included in the sub-project. Rather, it wants to make sure that all of the subjects in the sub-project (child) are defined in the lab project (parent). In this model, the subject could be viewed as being pushed from the sub-project to the parent project, but that is a little odd since the subject may already exist in the parent project (even before the sub-project exists).

  1. Model these relationships between projects in the XSD.
  2. Enable the REST API to allow auto-sharing of one projects data to another (of particular data-types) (Jenny: this would be a very helpful feature for DIAN_ALL)
    1. The REST API should persist the relationship according to the model defined in Step 1.
  3. This feature should include the sharing of any existing data. This would include adding the relevant <sharing> elements to existing data that is missing it. Existing data that is 'owned' by the wrong project (child) should be corrected to be owned by the parent project, unless there are other relationships involved or there is a pre-existing data element of with the same label (then a merge is necessary).
  4. This feature should also include the ability to unshare the data. This would remove the <sharing> tags from the relevant entries.
  5. All save points for subjects and experiments will need to review the defined relationships for their relevant projects, and adjust their project and shared projects accordingly.
  6. OPTIONAL: There should be a web based interface to facilitate the auto-share feature.

Implementation Notes:
  • The preSave() method on the xnat:subjectData and xnat:experimentData can easily support the needed save point logic modifications.
  • The xnat:projectData element in xnat.xsd should probably contain the auto-sharing restrictions.
  • The unshare feature can probably be supported via a DELETE call to the same REST resource.
  • Proposal 3 could be skipped. This would mean that preexisting data would need to be manually shared by the user. Or, just the ability to fix data that is owned by the child project, but should be owned by the parent project could be skipped.

RED Issues should be resolved before the Feature Request is considered complete.