1 of 17

OPENSAFELY CO-PILOT INTRODUCTORY MEETING

2 of 17

OVERVIEW

  • Introductions
  • OpenSAFELY concepts
  • Co-piloting process
  • Project aims and current progress
  • Co-pilot admin
  • AOB

3 of 17

INTRODUCTIONS

4 of 17

PROJECT AIMS AND CURRENT PROGRESS

  • Project background/aims
    • Share protocol (particularly useful for copilots when helping to review study definitions)
  • Documentation/Getting started guide

​

​

5 of 17

KEY CONCEPTS IN OPENSAFELY

  • Available datasets

​

​

  • Github organisation

​

  • ehrQL

​

  • Project pipeline/Actions

OpenSAFELY documentation

https://docs.opensafely.org/

​

  • Codelists
      • https://www.opencodelists.org/
  • ​
  • Code review

​

  • Job server

​

      • Releasing outputs

​

6 of 17

Datasets

Two core primary care EHR systems are available inside OpenSAFELY:

​

  • OpenSAFELY-TPP
  • OpenSAFELY-EMIS

​

External datasets imported to the secure EHR environment:

​

​

​

​

https://docs.opensafely.org/dataset-intro/

​

7 of 17

GITHUB ORGANISATION

  • OpenSAFELY uses GitHub (based on git) to store the code used to create and analyse the study data
    • Git is a version control software that basically allows multiple people to work in parallel
    • It also tracks what changes were made, who made the change, when they made the change, and why they made the change
  • All OpenSAFELY research projects are located inside the OpenSAFELY github organisation
    • You can use the research template to get started

https://docs.opensafely.org/en/latest/repositories/

​

8 of 17

GITHUB ORGANISATION

  • Repos can be private during development but all OpenSAFELY projects must be made public when complete (or one year after they begin)
    • Consider working in public from the start
    • See OpenSAFELY docs for more information

​

  • Git tour of an existing repository
    • Branches (main and development)
    • Pull requests (PRs)
    • Commits
    • Actions/workflows
    • Issues

https://docs.opensafely.org/en/latest/repositories/

​

9 of 17

ehrQL

  • The Electronic Health Records Query Language (ehrQL) is a query language that we designed for the working with EHR data
  • A dataset definition is written in ehrQL and specifies the data that you want to extract from the OpenSAFELY database

https://docs.opensafely.org/ehrql/

10 of 17

PROJECT PIPELINE/ACTIONS

  • Analytic code can be divided up into logical units:
    • Extract data
    • Prepares and clean data
    • Descriptive table.
  • In OpenSAFELY, each logical unit is called an action and is store in the project.yaml file

https://docs.opensafely.org/actions-intro/

​

11 of 17

CODELISTS

  • List of alphanumerical codes that are attached to a clinical or event description
  • Several different code systems such as SNOMED and CTV3
  • Codelists that are hosted on this website can be used directly in the Study Definition
    • This means there is no need to download or alter these codelists in the study definition, and they can be reused.

https://www.opencodelists.org/

​

12 of 17

CODE REVIEW

  • All code should be reviewed before running on real data
    • Dataset definitions
    • Codelists
    • Analysis scripts
  • Co-pilots can review some code initially but only from an OpenSAFELY perspective, i.e. making sure the platform is being “used correctly” 
  • For clinical and scientific aspects researchers should have at least one member of their team or other colleague available to conduct code reviews
  • Github makes code reviews easy through the use of branches/pull requests

https://docs.opensafely.org/code-reviews/

13 of 17

JOB SERVER

https://docs.opensafely.org/job-server/

​

14 of 17

RELEASING OUTPUTS

  • To view results run on real data you will need to set up the VPN to access the server
    • TPP/EMIS server access will be initiated once booked onto schedule
  • Outputs can only be released by specific members of the OpenSAFELY team
  • Form for release request

​

​

​

​

​

​

​

https://docs.opensafely.org/releasing-files/

​

You MUST NOT share any results that have not been released through the official output checking process. This includes:

  • verbal sharing
  • allowing someone to look over your shoulder
  • transcribing (e.g., to paper or email)
  • using screen sharing software or any recording device/software

15 of 17

CO-PILOTING PROCESS

  • All new users of the OpenSAFELY platform get offered access to our co-pilot programme
    • New researchers paired with an OpenSAFELY researcher to help with the onboarding process
    • Up to 5 days (spread over 4 weeks) of dedicated support (i.e. a a direct line of communication for non Q&A forum questions or issues when using the platform

​

  • By the end of the 4 week period, researchers should:
    • Be familiar with the core OpenSAFELY concepts
    • Be able to run the OpenSAFELY environment locally and on the job server.
    • Have generated the study population for their project
    • Run analysis scripts on the population
    • Generated outputs ready for review.

​

16 of 17

ADMIN

  • Authorship on papers
    • Expectation is that co-pilots and other OS team e.g. coders should be offered authorship on papers
    • Authorship policy
  • 1:1 Meetings
    • Weekly progress form
    • GitHub review to be scheduled
  • Preferred method of communication
    • Q&A forum
    • Slack/email/teams
  • Start date

17 of 17

AOB