Ethics/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) now about how human
data will be stored in a data repository (data bank). The department guidelines indicate that
that subject consent falls into one of three categories:
- Specific - use data only for the original purpose for which it was acquired
- Extended - use data for original and related projects
- Unspecified - use data for any research purpose
Your ethics application and patient consent form must clearly specify this usage, and subsequently you
must adhere to this specification. The following section describes how to do this
with a DaRIS data repository.
Working with Ethics in DaRIS
It is essential that the conditions under which data were acquired (subject consent as
listed above) are 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 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
Projects are created in the system by senior scientists or their delegate. These people have the primary responsibility to ensure that the consent is adhered to.
When you create a Project with the portal, there is some mandatory meta-data that you must fill in. It is labelled data-use in the Interface TAB.
You must select a value from the list of: specific, extended, and unspecified that
is consistent with your Project's ethics agreement.
Granting User Access to the Project
When a user applies to join the Project team that can access your Project's data, you must establish if they want to use the data in a way that is consistent with the Project's ethics (look at the Project object with the portal to see the ethics specification again). If it is not, you must deny their
request to access the data.
For example, the Project 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.
Project Data-Use | User Data-Use Request | User Access |
Specific | Specific | Yes |
Specific | Extended | No |
Specific | Unspecified | No |
Extended | Specific | Yes |
Extended | Extended | Yes |
Extended | Unspecified | No |
Unspecified | Specific | Yes |
Unspecified | Extended | Yes |
Unspecified | Unspecified | Yes |
By definition, any user that you grant access to the Project must use the data consistently with the Project's data-use specification. It is your responsibility to manage this.
Subject Over-ride
It is possible that regardless of the overall Project data-use specification, that a Subject will not agree to an extended or unspecified use of their data.
To handle this, we must know how a specific Subject has specified their data can be used and 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. When you do this, you must also provide that member's data-use specification (how they will use the data) for this Project. Of course, you have already verified that their usage is consistent with the Project-wide data-use 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 the team-member roles member and guest. 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 team-role should be changed to member status.
Subject Specification
When you create a Subject with the 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
.
Then a team-member who has the role member and data-use=extended
(which is consistent with the Project specification) will not be able to access that Subject. However, a team-member with data-use=specific
will be able to access that Subject's data.