Skip to main content

Data Access Agreement for the NHS OpenSAFELY Data Analytics Service

1: Purpose 

This document provides a set of policies that the OpenSAFELY User, named above, must adhere to. These policies are specifically applicable to the OpenSAFELY Service environment (the ‘Service). 

2: General

This Data Access Agreement must be read in full and signed by the User.

Projects must align with the Benefits to Health and Social Care as stated on page eight of the Requirements Specification for The NHS OpenSAFELY Data Analytics Service Pilot. The User must be approved by the Bennett Institute, and their project approved by NHS England, before they are permitted to run queries on pseudonymised GP and NHS England patient data; this data is held by GP IT system suppliers within the GP system suppliers environments for the purposes set out in the requirement specification of the NHS OpenSAFELY Data Analytics Service Pilot Directions 2025 

2.1 General conditions and OpenSAFELY User responsibilities

The following sections explain the commitment the OpenSAFELY Users must make before use of the OpenSAFELY environment is permitted.

2.1.1 The accessing organisation which maintains the NHS Data Sharing Framework Contract (DSFC) with NHS England understands that the organisation could be liable to penalties as outlined within this form and the attached policies which included unlimited liability, in the event of a breach by their OpenSAFELY Users.

2.1.2 OpenSAFELY Users using the Service are given access to datasets held by NHS England. These datasets cannot be published into the public domain.

2.1.3 This agreement expires after three years, at which point a new agreement must be completed. In addition, a new agreement must be completed if a User:

  • Changes employer;
  • Is involved in a data security incident, or;
  • Changes status from OpenSAFELY Collaborator to an OpenSAFELY Full User.

2.1.4 Completion of this document forms part of the OpenSAFELY User application process.

2.1.5 The OpenSAFELY User will act in accordance with the Research Code of Practice and Accreditation Criteria 

2.1.6 All OpenSAFELY Users must have read the Getting Started Tutorial. 

2.1.7 OpenSAFELY Users and Output Checkers must:

  1. ADHERE to the OpenSAFELY GitHub Organisation User Access Policy
  2. ADHERE to the OpenSAFELY Analytic Methods Policy, which outlines the analytic methods that are currently supported and not supported within OpenSAFELY. 
  3. ADHERE to the Permitted Study Results Policy 
  4. ADHERE to the Authorship Policy 
  5. ADHERE to the Information Governance and Ethics content Policy 
  6. ADHERE to the Acknowledgement and Sharing/Publication Policy 
  7. ADHERE to the OpenSAFELY principles
  8. ADHERE to the OpenSAFELY Research Ethics Compliance Policy
  9. ADHERE to the OpenSAFELY Incident Management Policy 

2.2 Additional connectivity conditions

2.2.1 Any access to aggregated outputs before they have been through the output-checking process must be made from within the UK.

2.2.2 All laptops used by the OpenSAFELY User for the purpose of the approved project must be kept up to date with the latest operating system and security updates.

2.2.3 Any correspondence with the OpenSAFELY team or associated activities by the OpenSAFELY User must be via the email address provided to them by their organisation.

2.2.4 OpenSAFELY Users must provide details of their GitHub account to the OpenSAFELY Service Team. 

3: Background

3.1 The OpenSAFELY Service enables research projects using data controlled by NHS England to be conducted in a safe and secure environment.

3.2 Data will only be made available to the OpenSAFELY Users working on NHS England-approved projects, and only within the scope of their approved projects.

3.3 Researchers working within the OpenSAFELY Service are bound by the UK General Data Protection Regulation, the Data Protection Act 2018 and the Directive relevant to the research they are conducting; NHS OpenSAFELY Data Analytics Service Pilot Directions 2025 or COVID-19 Public Health Directions 2020.

4: Security of data

4.1 Researchers, with full access (known as ‘Full Users’) to the Service, must have attended and completed a Safe Researcher Training course provided by ONS or the UK Data Service.

4.2 Output Checkers, must confirm their attendance at suitable accredited output checker training and adhere to new guidance for ongoing professional development and training for this role.

4.3 OpenSAFELY Users must: 

  • Complete all training provided by their organisation, in data protection and data security to the standard required, and will renew this training in the frequency required by their organisation. 
  • View, analyse, and process data only as permitted for the purpose of the approved project, and must not attempt to take out any information from the OpenSAFELY environment other than via the approved process.
  • Always preserve the confidentiality of the data.
  • Access the Service in a secure physical location where inadvertent disclosure can be prevented (for example, not in a public place where they can be overlooked).
  • Keep login details confidential and must not share their login with any other person. 

4.4 OpenSAFELY Users must not:

  • Leave their device unattended and unlocked while accessing the Service.
  • Use the Service to attempt to identify or to contact any individual using data in the Service.

4.5 Activity within the Service may be logged and recorded; this includes, but is not limited to access to data and any code submitted.

5: Incident management and reporting

All (suspected) security incidents MUST be immediately reported to the BI IG Team for further escalation and management, including: 

  • Accidental or unauthorised destruction
  • Loss
  • Alteration
  • Disclosure of or access to data by an unauthorised person;
  • Any potential breach of data in the OpenSAFELY Service, or
  • Any incident that may have compromised the security of the data, including a cyber security incident. 

This includes instances where any files are released to the JobServer site that have been insufficiently redacted and still contain sensitive information.

All OpenSAFELY Users involved, directly or indirectly, are required to engage fully and support enquiries into any incidents.

The incident must not be discussed with anybody other than those it is necessary to do so, i.e. those individuals dealing with the incident.

Any incidents or breaches of this DAA will be investigated and managed as per the OpenSAFELY Incident Management Policy.

OpenSAFELY Users must not share any results that have not been released through the official output checking process. If data has not been output-checked, OpenSAFELY Users are not permitted to discuss it verbally, allow others to view the screen while they are logged in to the VPN, or share it through screen-sharing or recording tools. 

OpenSAFELY Users must not record, copy or write down any information about the data. Researchers may, however, verbally discuss unreleased results (e.g. by phone or video call) when each researcher is individually logged in under their own authorised VPN access and viewing the data independently. If more detailed discussion or further analysis of the data is required, or if wider team members need to be involved, the result must first be submitted for output-checking.

Any data security incidents, or attempted breach of this Data Access Agreement, OpenSAFELY principles, OpenSAFELY policies, or rules for data release will result in suspension of the researcher’s access to the platform, while the potential breach is investigated. If that investigation concludes that a breach has occurred, further action may be taken. This action may include:

  • Extended suspension, or permanent removal, of access to the service;
  • Suspension or removal of access for the wider research team or organisation;
  • The ethics board that approved the research being notified and;
  • Where appropriate, professional regulatory bodies (e.g. GMC) may be informed.

6: Lawful access and data confidentiality

6.1 The signatory will inform the OpenSAFELY Service Team and their Co-Pilot immediately when:

  • They are leaving their project and/or organisation;
  • There is a change to the project members, where they are the Project Lead.

Access to the OpenSAFELY Service and associated services, such as the OpenSAFELY GitHub Organisation repository will be updated by the OpenSAFELY Service Team as necessary for the administration of the service.

6.2 Unlawful processing of data within the OpenSAFELY service may constitute a breach of multiple legal and regulatory frameworks. Researchers are bound by the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018, which require that all personal and pseudonymised data be processed lawfully, fairly, securely, and only for authorised purposes. Unauthorised access, use, disclosure, or re-identification of data may amount to offences under Section 170-171 of the Data Protection Act 2018, and could also breach the Computer Misuse Act 1990 and the common law duty of confidentiality. Such action may result in disciplinary, civil, or criminal consequences, and compromise NHS England’s compliance with statutory data protection obligations. All researchers must therefore ensure strict adherence to approved access controls, processing purposes, and audit requirements when using OpenSAFELY or any associated data environment.

6.3 Controlled access procedures:

6.3.1 An OpenSAFELY User with controlled access in the OpenSAFELY environment MUST:

  • Comply with all OpenSAFELY policies.
  • Read, understand and confirm acceptance of this Data Access Agreement by signing the Approval page of this document.
  • Retain a copy of this document for reference.
  • Where Full User access is required, successfully complete Safe Researcher Training as provided by the ONS or UK Data Service.
  • Lock the workstation when it is unattended.
  • Agree to activities within the OpenSAFELY service being audited for security purposes.
  • Only use the OpenSAFELY service for querying data which is relevant, necessary and proportionate for producing analyses for the project purpose(s).
  • Report any suspicious activity to the BI IG Team without delay.
  • Report any malfunctions to the Co-pilot or Tech Team in the first instance, using the methods agreed at their induction with the Co-Pilot.
  • Abide by the publication requirements of the OpenSAFELY service.
  • Access to the service will be terminated on expiry or termination of the Agreement or approved project.

6.3.2 OpenSAFELY Users MUST NOT:

  • Try and identify any individual, or organisation-type prohibited by the Permitted Outputs Policy, within the data made available.
  • Use the OpenSAFELY service for any work that is not part of the approved project.
  • Share, exchange or allow their environment credentials to be used to access their project or other areas of the environment, no matter what the circumstances. This includes another OpenSAFELY User, a family member, supervisor, project lead or mentor.
  • Attempt to use logon IDs or passwords belonging to other OpenSAFELY Users to access the service.
  • Auto save passwords.
  • Access or view the screen of the OpenSAFELY service or account that are not authorised to access or view.
  • Attempt to explore or exploit the security features of the OpenSAFELY environment.
  • No attempt will be made to access the service after authorisation has been withdrawn or access rights have expired.

Version: 6.0
Last updated: