If you have tried to access the new system and receive the following message:
"Service access denied due to missing privileges."
It is likely that you have not yet enrolled in MFA. Multi-factory authentication (MFA) is required to access the new system. Please see instructions in the FAQ below.
SFU has introduced Multi-Factor Authentication (MFA) as an added layer of security for accessing the University’s online systems, which now includes the new Research Ethics Application System.
To ensure you can sign on successfully, please take a few minutes to enrol in MFA . Setup and enrolment take under 10 minutes; click here for instructions.
MFA Has Three Steps
To enroll in MFA successfully, make sure you complete all three steps:
- Part 1. Install a MFA mobile app
- Part 2. Set up mobile device with MFA
- Part 3. Print and store backup login codes
Need Further Assistance for MFA?
For troubleshooting and inquiries, please contact your department’s IT support staff.
The IT Service Desk is also available to assist you at firstname.lastname@example.org or 778-782-8888.
There are a number of automatic notifications that the system sends out, similar to the renewal notifications that you may have received from the old Ethics Database. The emails are sent by email@example.com <firstname.lastname@example.org> on behalf of Kuali Notifications <email@example.com>. These emails are not spam and the links are safe to click.
Kuali Protocols is a module within the Kuali Compliance system, that enables management of protocols related to human participants. The new Research Ethics Application System is our version of Kuali Protocols.
Please see the attached excel sheet for a list of all the notifications that the system sends, who receives the notifications and the base text the email contains.
|Role in Kuali||Automatic Notifications|
|Principal Investigator||PDF of sample notification trigger and text|
|Research Team Members||PDF of sample notification trigger and text|
|REB Members||PDF of sample notification trigger and text|
|Ancillary Reviewers||PDF of sample notification trigger and text|
Please note that to ensure historical applications with graduate student PIs and new applications with student leads all receive proper oversight and communication, most notifications are set to “all research personnel”. This may shift as new features become available.
Applications from the old system (Ethics Database)
Already Approved Studies
Approved applications that were submitted after 2014, open and in good standing with the SFU REB (i.e. it is not lapsed), have been moved to the new system. Please access the new Research Ethics Application System to confirm all of the information transferred is correct. Where there are discrepancies, please contact firstname.lastname@example.org
The converted applications have fewer form sections, the application continues to live in the supporting documents and study details document. You are welcome to update the application and complete the new form, but this is not required.
When making an amendment, focus on updating personnel, funding etc. in the form and then update the documents. Ensure changes in documents are highlighted using track changes.
Studies Approved BEFORE January 1, 2014
Historical ethics applications are no longer compliant with the current TCPS2 (2018) policy document, or with the SFU research policy R20.01. The SFU ORE is using the new system to bring pre-2014 Ethics applications in line with updated TCPS2 and R20.01 policy.
If your initial research ethics application was approved before January 1, 2014:
- You must submit a new application in the new Research Ethics Application System 6-8 weeks before the current expiry date if you wish to continue conducting research with human participants.
- Resubmissions cannot be made to the current Research Ethics Database.
It is the responsibility of the research team to manage their pre-2014 applications.
All course ethics approvals granted prior to November 23, 2020 have expired and are no longer valid.
Historical course applications did not contain enough information to migrate properly into the new system and as courses did not have expiry dates there was no continued review process. The ethics application system ensures that Course Ethics applications are in line with the current TCPS2 2018 policy document and the SFU R20.01 policy.
If you are an instructor and wish to have your students conduct human participant research as part of your course syllabus, you will need to submit a new course application in the Research Ethics Application System.
If you are the PI of the application
Applications converted from the old Ethics Database into the new Research Ethics Application System are set up so that the PI has full access to the application and other research team members have read only access. However, the PI may want to extend full access to the application. To do this, follow the steps below:
1. Create a new amendment submission (click here for the quick guide)
2. Fill out the amendment coversheet and then navigate to the Personnel section
3. Click the pencil icon next to the name of the research team member you would like to edit
4. In the Personnel pop-up window, scroll down to Permissions and select the desired access (full access)
5. Make any other desired changes to the application
6. Click submit
(If you are not the PI but a research team member with full access to the application, follow the steps above and then for #6 click Notify PI to Submit instead).
If you are NOT the PI of the application
If you are trying to open or access an application, and know you are listed but cannot see the application, you will need to ask the PI to give you at least read only or full access to the application through the steps above.
If you are trying to edit an application, make an amendment or a renewal submission, but these options are not available to you, you will need to ask the PI to give you full access to the application through the steps above.
Previously closed, withdrawn, suspended studies will not be migrated into the new Research Ethics Application System. The Office of Research Ethics will maintain a record of these studies, although it remains the responsibility of the research team to maintain their own study files and keep copies of all study documents.
The previous Research Ethics Database relied on Adobe Flash and was not usable beyond December 2020 as a result of Adobe Flash being decommissioned.
For graduate student researchers, there is no significant difference between a Student Lead and a PI. Graduate Students are still able to create, write, and edit their own ethics applications.
Graduate Students need to be listed as the Student Lead in the application. Faculty supervisors need to be listed as the PI as they are responsible for the application and guiding the Student Lead through the research ethics process. As the PI, Faculty Supervisors will have to log into the system, review the application, and press the submit button before the ORE will receive the application. No one but the PI can click submit for the application.
The Student Lead (when paired with graduate or undergraduate student appointment status at SFU) is understood to be conducting the research for their honours, thesis, capstone or similar and has developed, in consultation with their supervisor, the study. The student lead is one of the main team members in the project, one of the primary points of contact, and can be creators, under policy R30.03.
Your supervisor(s) is the Principal Investigator (PI) and is responsible for the ethical conduct of the research, as well as the actions of any member of the research team.
Being a Student Lead vs. a PI on a project does not impact intellectual property claims for work completed under an ethics application. Intellectual property (IP) is managed at SFU under policy R30.03, not within a research ethics application.
Please direct all questions about managing student/faculty relations to: Associate Dean, Students, Graduate & Postdoctoral Studies, email@example.com
Questions about technology and licensing can be directed to: TLO_admin@sfu.ca
Questions about contracts and research agreements can be directed to: firstname.lastname@example.org
Kuali System Security
Kuali Protocols (KP) has been approved by the SFU Privacy Office as compliant with BC’s Freedom of Information and Protection of Privacy (FIPPA) legislation. As with every major software acquisition, it was subject to an internal Privacy Impact Assessment (PIA) conducted by the SFU Privacy Office. PIAs are not blanket security assessments; they focus almost exclusively on regulating the disclosure of personal information. Assessing the overall security of the information thus requires a different lens.
The best way to secure sensitive information is to not make it part of an ethics application. The focus of the process is to ensure participant protection, so any specific examples that might expose personal information should be mockups. However, there may be instances where simply describing the methodology or the target population of a study could create circumstances that could be perceived as being detrimental to the participants. The following discussion therefore assumes that sensitive information is a vital component of the application, and is intended to assess and minimize the risks involved.
Storing sensitive information on a local server is not a panacea. Any server is potentially subject to being compromised, although SFU makes extensive efforts to minimize this risk through implementing information security best practises. Any data storage, local or otherwise, is potentially subject to unwanted disclosure to the Canadian government. Bill C-51, the Anti-terrorism Act, provides the Canadian Intelligence Security Service (CSIS) with the power to act disruptively to “reduce threats to the security of Canada”, so long as they obtain a judicial-based warrant in advance. Whether CSIS (for potential terrorism) or the RCMP (for potential criminal activity) are involved, a judical warrant is all that’s required to allow these Canadian governmental agencies to legally access data stored on SFU servers. In the case of CSIS, these actions can explicitly, and legally, breach any rights otherwise afforded to protecting any sensitive information, even protections under the Canadian Charter of Rights and Freedoms, leaving such information vulnerable to unwanted disclosure.
Cloud data storage provides numerous advantages to on-site, including redundancy, scalability, and reduced cost. In Canada – particularly BC – much of the concern about cloud-based activity relates to the potential for exposure to U.S. government intelligence agencies. Cloud-based data storage, and to a greater extent Software as a Service (SaaS) implementations, bring additional players to the table: cloud service providers and software companies.
The U.S. Patriot Act and the recent Clarifying Lawful Overseas Use of Data Act (CLOUD) govern U.S. authorities’ access to data held by Communication Service Providers (CSPs), which include software companies and cloud service providers. The Patriot Act provides U.S. authorities the ability to “conduct searches and to seize or compel the disclosure of records”. When U.S-based companies receive an order to disclose information or data from U.S. authorities, they are prohibited from informing the relevant customer or individual whose information or data is affected.
As part of efforts to address the complexity of conflict-of-law issues with CSP data and as a response to a challenge by Microsoft, the U.S. created the CLOUD Act in 2018. The CLOUD Act clarifies that “CSPs subject to U.S. jurisdiction must disclose data that is responsive to valid U.S. legal process, regardless of where the company stores the data”1. This means that if a U.S.-based CSP, such as Microsoft, utilizes a server in Canada and receives an order to provide data to U.S. authorities that is located in that server, they can be required to do so under CLOUD, even if the data are exclusively on Canadian soil.
How often does this happen? Unfortunately, U.S. law requires that CSPs not disclose how often they receive such requests for disclosure by U.S. authorities. One gets a hint from Google statistics, but few specifics. However, Amazon Web Services (AWS) notes that they regularly challenge law enforcement agencies who request data located outside of the U.S. Most software companies provide the same vague assurances.
Canada does not have federal legislation that mandates where data should be stored for Canadian companies and institutions. Provincially, British Columbia has the Freedom of Information and Protection of Privacy Act (FIPPA). Under FIPPA, for public bodies such as universities, there is a requirement that all public sector data reside in Canada. However, more recently, B.C. introduced Bill 35, the Miscellaneous Amendment Act, intended to “remove the barrier to adopting the next generation of cloud-based or cloud-enabled tools…”. It allows out-of-country data residency in specific circumstances2.
The focus of FIPPA and the Bill 35 amendments is personal information, not overall data security. Nevertheless, the requirements have served to limit exposure of academic data to US government intrusion, but does not address issues arising out of where our software comes from. There are few Canadian software providers that work at an enterprise scale that would meet the needs of a university. The sheer complexity of enterprise software and, in the research space, the limited market, means that only a small number of US or European-based firms provide such software. Further, on-premises software, as was previously used by ORE, is becoming a thing of the past; SaaS is now the norm. SaaS locates the software and the data in the cloud, meaning that the provider cannot be arm’s length from the data.
SFU has entered this SaaS space only recently, with the adoption of SalesForce as the corporate CRM solution, Taleo for HR, SurveyMonkey, and with Office 365 adoption in the near future. All of the above companies are located out-of-country.
As previously discussed, whether data are stored on on-site SFU servers, on the FIPPA-compliant AWS Canadian Cloud, or sitting on Google Drive, they are potentially subject to access by US or Canadian authorities under existing legislation. Furthermore, whether CSIS would act on a US request is undocumented, but past practise shows strong links between the two countries’ intelligence agencies.
In order to protect sensitive information as much as possible in the event of an information request, the only possible solution is to encrypt sensitive data, wherever it is stored. We have the following options available to do so:
- Place sensitive data in one or more files, upload to SFUVault, and share via link. Use a strong password. Provide the file link in the application, in place of the sensitive information. Send the password using a different method.
Security: all ethics reviewers on the system have easy access to the file, provided that they have an SFU login and administrator/reviewer rights as both are required. With the file on a local system and the password in the Cloud, a governmental agency would need to obtain a judicial warrant, perhaps in two countries, to obtain access to both.
- Manually encrypt the sensitive data file(s) and provide via attachment or link. Provide the file key (password) under separate cover. For example, Acrobat can natively encrypt a document using 256-bit AES encryption.
Security: reviewers will need to manually share the document’s key in order to access content. The mechanism for key sharing is the least secure aspect of the process. A one time self destructing link can be used as an option: https://secret.rcg.sfu.ca
Neither option is ideal, as reviews and processing will be slowed. However, where data security and participant protection are paramount, these techniques can be utilized to minimize exposure.
1 U.S. Department of Justice. (2019). Promoting public safety, privacy, and the rule of law around the world: The purpose and impact of the CLOUD Act. https://www.justice.gov/opa/press-release/file/1153446/download
2 Government of B.C. (n.d.). Secure Cloud. https://www2.gov.bc.ca/gov/content/governments/services-for-government/secure-cloud