Data Model

The data model that DaRIS uses (i.e. the way that the data are organised in a hierarchy) is called PSSD and puts the Project as the highest level entity.

A Project is a targeted scientific experiment operated by a finite collection of people. Each Project has a number of Subjects. Subjects may be animal (e.g. human or mouse) or non-animal (e.g. a contrast-agent sample). Each Subject has a number (usually one, but sometimes more) of ExMethods (Ex for Executable). An ExMethod describes an experimental method (e.g. acquire a mouse, put it to sleep, make an MR scan, wake it up, kill it, remove its brain etc). Except for some specific projects, we are using very simple ExMethods at the moment (e.g. acquire some data). Each ExMethod has a number of Studies. A Study is an acquisition of data (e.g. MR or other). A Study contains a number of DataSets. For an MR, a DataSet is equivalent to a Series (image volume).

Thus the hierarchy is Project.Subject.ExMethod.Study.DataSet

Citable Identifiers (CIDs)

1. Objects with CIDS

Whenever you create objects (information) in its data model structure, DaRIS will assign those objects citable identifiers (CIDs). These will allow you to refer to objects in a reasonably human-friendly way, especially when referencing them externally in research papers and so on.

DaRIS creates CIDs in the form of hierarchical numbering. For example, a CID of 23.4.1.3.10 would be the tenth DataSet of the third Study of the first ExMethod of the fourth Subject of the twenty third Project. In this way, DaRIS CIDs are like Internet addresses which also use hierarchy (a domain hierarchy) for their formation.

Additionally, CIDs are prefixed by two more numbers: (i) the Mediaflux system that allocated them, and (ii) the type of object that the proceeding number refers to (i.e. an object type separator).

So the full form is UUID.OTS.P.S.ExM.St.DS making the full CID for the example above potentially something like 1024.2.23.4.1.3.10 where the UUID of the Mediaflux server is 1024 and the .2 happens to mean, on this specific system, that the object that follows is a Project. As another example, a CID of 1024.3.10 might be the tenth Method and the .3 means that the object that comes next is a Method. The object type separators vary from Mediaflux system to Mediaflux system, but each respective system can tell you what kind of object has what separator.

You can see that within a Mediaflux federation, the citable ID is unique. These citable IDs are extensible in both directions meaning that additional numbers could prefix the CID and allow uniqueness in some wider federations (e.g. international community).

Note that the CID root is actually separable from the server UUID. In some early Mediaflux systems, they are different values. In later systems, the UUID is always the CID root.

2. Objects with no CIDS

DaRIS can associate attachments with primary objects. These assets don't get assigned CIDs, they just get associationally related to primary objects to enable their discovery and management.

3. CIDs for DICOM ingests

The DICOM server needs to know the citable ID the object that the data should be uploaded to. Generally, this means that the CID must be drawn from object drawn from the set [Project, Subject, ExMethod, Study].

Imagine a valid Subject is supplied. The DICOM server will proceed to then validate that the Method with which this Subject was created contains a Study creation step of the DICOM modality of the data (if not it will reject the data).

It may be that the Method has only one Study creation step in which case there is no ambiguity. However, if there are multiple Study making steps (consistent with the modality) the ambiguity needs to be resolved. This is done by

• Pre-creating the Study from the correct step and supplying the CID of the Study

• Extending the expected CID layout to <cid>_<step>

In this way the correct Step from the Method will be used when auto-creating the Study and DataSets

Methods, Metadata and ExMethods

Please read here about the basics of Methods and meta-data. This is of central importance to how DaRIS works so please take the time to read.

End-to-End Process Example

Here is an example of a simple end-to-end work flow to acquire some MRI data in DaRIS:

• To initiate your project and its subjects, use the DaRIS web portal to:

  • generate a Project object

  • select the Method(s) you will use with the project

  • assign the team that should have access to the project

  • receive the project’s CID assigned by the system

  • before data are acquired, generate your required amount of Subjects and receive their CIDs

  • acquire data for the respective subjects

• Upload the data to the desired subjects

  • use a DICOM client and overload the appropriate DICOM element (usually the Patient name; see your DaRIS administrator) with the Subject CID

  • drag-and-drop in the DaRIS web portal

• Access the newly arrived data with the DaRIS web portal and download (with format conversion) to your compute platform

Ethics and Consent Considerations

Data usage types

This section pertains to Australian ethics processes (although the categories are fairly generic).

It is necessary to supply information (to the Department of Human Services) about how human data will be stored in a data repository. Department guidelines indicate that subject consent falls into one of three categories:

1. Specific - data will be used only for the original purpose for which it was acquired

2. Extended - data will be used for both the original and related projects

3. Unspecified - data will be used for any research purpose

Your ethics application and patient consent form must clearly specify this usage, and subsequently you must adhere to this specification.

Designating data usage in DaRIS

The conditions under which data were acquired (i.e. the subject consent specifications detailed above) MUST be honoured.

Subjects will have signed an agreement specifying how their data can be used. Usually, you will have one agreement for all subjects, but subjects may specify their consent individually. For example, the project as a whole may be designated extended, but an individual subject may require that their data can only be used for specific use. Therefore, a subject's consent may over-ride that of the project, provided it does not widen the usage. For example, we do not allow project wide consent of specific and a subject to specify extended.

Project-wide data use specification

If you are the project administrator (the senior scientist, or their delegate, who created the project in DaRIS) then you have the primary responsibility to ensure that the agreed data usage is adhered to.

When you create a Project with the DaRIS web portal, there is some mandatory meta-data that you must fill in:

• Locate data-use in the Interface tab

• Select a value from the list of: specific, extended, and unspecified that is consistent with your project's ethics agreement

Granting user access to projects

Whenever a user applies to join a project team that can access your project's data, you MUST establish if they intend to use the data in a way that is consistent with the project's agreed data use specification (look up the Project object in the DaRIS web portal to check its designated subject consent specification). If they not, you MUST DENY their request to access the project data.

For example, a project’s data use specification might be specific. If a user applies for extended use then they are not allowed to gain access. The following table shows the access pattern:

By definition, any user that you grant project access to MUST use the data consistently with the project's data use specification. It is your responsibility as a project admin to manage this.

Subject over-ride

Sometimes, regardless of the overall project data use specification, a respective subject may not agree to an extended or unspecified use of their data. To handle this, we must know both:

• how the subject in question has specified that their data can be used

• how the team member wants to use it

Team member specification

Recall that when you create a Project, you assign team members with a role selected from the list of: project admin, subject admin, member and guest, as well as a data use specification (for how they will use data in the project). Of course, you will have already verified that their usage is consistent with the project-wide data use specification before agreeing that they can access the project; this just codifies it. If you specify a team member data use that is not consistent, it will be silently set to the Project data use specification.

This data use specification is only relevant to member and guest roles. By definition, a project admin must be able to access all data. By definition, a subject admin role is specific use (i.e. they are acquiring data for a specific intent). If a user who is a subject administrator decides that they want to use the data for extended purposes, their role should be changed to member status.

Subject specification

When you create a Subject in the DaRIS web portal, you can optionally set the data use specification for that subject. This allows over-ride of the project-wide specification. For example, the Subject can over-ride a Project specification of extended to specific. If you specify a subject data use that is not consistent, it will be silently set to the project data use specification.

If you don't set the data use on a Subject, then no additional restrictions apply and any team member who has been granted access to the Project can access that Subject's data.

Example

Consider a Project with data-use=extended and a Subject with data-use=specific. This will mean:

• A team member with member role and data-use=extended (which is consistent with the Project specification) will not be able to access that Subject’s data.

• However, a team member with data-use=specific will be able to access that Subject's data.