CSC Handbook


The CSC Handbook is intended to act as an encyclopedia for all activities inside CSC. If you work in CSC, if you're a CSC collaborator, if you're new to the CSC Team, or if you're interested in joining CSC then the information you seek should be in here somewhere.

Who we are

Our mission

The CSC mission statement is: developing people, platforms and policy for digital health. Our objectives are to develop the NHS digital workforce of tomorrow, to create and support innovative new software and to advise on policy relating to software as a medical device.

Our values

The CSC team values reflect the values of Guy’s and St Thomas’ NHS Foundation Trust. Our values are at the heart of everything we do. They are to:

  • Put patients first
  • Take pride in what we do
  • Respect others
  • Strive to be the best
  • Act with integrity

Our purpose

The CSC Team supports clinical teams within GSTT to evaluate or develop AI which addresses a clinical need or clinical pathway. We can support projects of varying sizes and at various stages of the project lifecycle. Typically, we will be engaged in projects for their entire lifecycle and a CSC member would be assigned to individual projects(as the CSC Lead) to provide a single point of contact clinical leads on the project.

Team organisation

The CSC Team is small group of individuals from a variety of backgrounds, ranging from radiology and nuclear medicine to data science and genomics. The team is made up of 7 full time members and 3 part-time members. The team is part of the Medical Physics department within the Guy’s and St Thomas’ Hospitals NHS Trust.

The diagram below illustrates the relationship of the CSC Team with the Medical Physics department at GSTT.

Working in the CSC Team

Bi-weekly standups

The CSC Team hosts Standup meetings every Tuesday and Thursday from 9.30–10.00am.

The first part of the meeting is devoted to news pertinent to the entire CSC Team. The second part of the Standup is dedicated to individual members of the team summarising work from the previous days and detailing their plans for the next few days. This is also an opportunity to appraise anything noteworthy or raise any concerns which might be a barrier to progress.

Fortnightly workshops (10x)

On fortnightly Wednesdays, the CSC Team hosts a 10x Workshop. Within this space, we discuss new topics surrounding the implementation of AI within the healthcare sector, we have group discussions about current practices, and we discuss new AI ideas and AI policies pertinent to the NHS.

The 10x Workshops are also an opportunity for CSC Team members to present their projects to the wider Team. We also invite external parties to share knowledge. If you are from an external organisation and you are interested in discussing your work at one of our 10x Workshops, please get in touch!

We also use the 10x Workshops to hold regular Retrospective exercises. These quarterly group exercises allow CSC Team members to raise and discuss positive experiences, as well as any difficulties, barriers or delays to working that they have experienced. We conclude these Retrospective sessions by creating actions focused on improving our working practices moving forward.

A list of previous and forthcoming 10x Workshops can be found on the CSC Team Sharepoint here: CSC Workshops Agenda

Quality Management System

The CSC Quality Management System has been developed in-house and applies to all standalone software medical devices developed by the Clinical Scientific Computing team at Guy’s & St Thomas’ NHS Foundation Trust.

The team are committed to complying with all applicable legal requirements in order to facilitate the translation of software medical devices from R&D into routine clinical care. This is balanced with a need to adopt modern processes of the internet-era to respond to people’s raised expectations and the rise of data-driven technologies.

As developers of software medical devices that could have an impact on safety, we commit to minimising clinical risks in compliance with appropriate legal and professional standards to ensure we support safe and effective care. In order to facilitate this, we commit to a radically open and transparent development process that allows scrutiny from all stakeholders and encourages a culture of honesty, inclusiveness and collaboration.

In the spirit of continuous improvement, we will review this quality policy on an annual basis to ensure we continue to effectively communicate with everyone within our organisation the goal of the QMS as well as to ensure it is fit for purpose on top of the shifting landscape of digital health.

Processes and procedures relating to the Clinical Scientific Computing QMS are designed with a risk-based approach and are continually reviewed and improved as a result of GitHub issues, CAPAs, Internal and External Audits, and Management Reviews

CSC onboarding

Desk Area

The CSC team is based at St Thomas’ Hospital (part of GSTT), however we mostly work remotely via Microsoft Teams, using Github and our website. The CSC team mainly resides on the 10th Floor in the Education Centre (also referred to as York Road), but can also be granted access to:

  • Tabard House (near Guy’s Hospital)
  • The 5th (“Big Ben” side) and 9th floor (meeting rooms) in Becket House
    • For access, please email the Operations Assistant for the Biomedical Engineering department for the necessary forms, training, KCL card issuance, and guidance.

Access to these sites should be requested and approved by your line manager, and implemented so you can simply swipe your card at the entrance.

While we have a flexible work schedule, team members should be available to meet during standard working hours, where required, such as for stakeholder meetings, CSC Standups and our 10x Workshops.

Equipment provided

New members of the CSC Team are provided with a brand new Apple MacBook Pro to perform their work. If additional equipment or software is required for your work, this can be arranged with the Head of the CSC Team.

Meeting invites

New starters should organise with the Head of CSC or CSC staff to be added to the following meetings, groups, and Microsoft Teams:

  • KCL Microsoft Teams i.e., to access main CSC chat, MT-CSC OneDrive, KCL calendar, etc.
  • GSTT Microsoft Teams i.e., to access secondary CSC chat, GSTT-shareable only files, GSTT calendar, etc.
  • 10X Workshops meeting series (fortnightly in-person sessions 3 - 5:30PM, every other Wednesday)
  • Bi-weekly stand-ups (9:30 - 10AM on Tuesdays and Thursdays)
  • Quality Management System (QMS) audits (internal and external)
  • Interesting project meetings
  • Upcoming conferences

Arrange 1-2-1’s with all CSC Staff

New starters will be expected to arrange 30-minute meetings with each staff member of the CSC, on Teams or in-person, for introductions as early familiarity with the team encourages a supportive working culture. The meetings should discuss:

  • Career to date (new starter and current staff member)
  • Length of new-starters time with the CSC

For trainees and elective staff, the meetings should also discuss:

  • Experiences you wish to gain with the CSC
  • Competencies that could be completed

Access to our GitHub

The CSC team uses GitHub for code storage and version control for all applications built in-house, as well as the team’s QMS. Each new staff member must create a GitHub account and get the Head of CSC to add them to the GSTT-CSC GitHub organisation.

The new starter should search for issues with the “Good First Issue” tag to contribute to current projects and to become familiar with CSC software development process. You can read more about version control with git here

Create “Team-Member” Website Profile

All new staff and trainees must create a new page and profile on the “Meet the Team” page on the website, along with a picture (250x250px) and any social media links e.g., GitHub, LinkedIn, etc. To do so, please refer to the README on the website’s GitHub repository here.

STP Trainee On-boarding Tasks

In addition to all of the above, STP trainees must:

  • Create a blog posts outlining an interesting project completed or 10X, and an account of the experience of their duration with the CSC Team, with feedback. Examples of blog posts created by STPs include:
  • Communicate wanted experience (as opposed to needed experience) to separate out the trainees’ interests from tasks required by the competencies and/or CSC workload.
  • Get assigned 1st and 2nd Supervisor
  • Organise weekly check-in sessions with supervisors
  • Confirm a schedule for completing projects, competencies, DOPS, OCE’s, etc.

The general purpose CSC Team email address is cscteam@gstt.nhs.uk.

NHS staff information

All new members of the CSC team will complete a Trust Corporate Induction, including any upfront training required for their role and primary work site. Each member will be provided with a GSTT account and corresponding GSTT email address e.g., FirstName.LastName@gstt.nhs.uk. This will give you access to the Trust’s intranet and services, including the Human Resources (HR) Portal, IT ServiceNow Portal (for IT support), and the College of Healthcare Learning Hub (COHLH) portal for completing mandatory training and educational courses.

Admin portals

New starters should ensure they register and have access to:

  • Electronic Staff Record (EST) i.e., to access payslips, P60 forms, pension contributions, etc.
    • Click on “Unlock Account” to register for the first time.
  • HR Portal** i.e., to raise and manage HR requests/transactions, access HR policies, etc.
  • IT Service Centre** i.e., to raise and manage IT requests/incidents, access the IT system catalogue, etc.
  • MICAD room booking system* i.e., to book meeting rooms across GSTT sites. More details about the process here

Work expenses

If you require a work travel budget to be authorised and paid for by the NHS, the first step is to email the CSC team lead for authorisation.

Once it has been authorised, you will then need to book your travel arrangements with Clarity BT by either:

* Accessible only via the Trust VPN i.e., either on-site or whilst logged into Citrix (see below for how to set up this remote desktop and application access).

** The usernames used to logged into these websites are either your GSTT email address or GSTT username, and the password used will be the password you use to login to your email and desktop on-site.

NHS staff policies

Remote Working

The CSC team generally work both remotely within the UK and on-site, with the proportion of time spent in each subject to the nature of work, individual member responsibilities, and Line Manager approval. Generally, in-person attendance at the fortnightly 10x workshops is required but team members may join remotely if necessary.

Remote working overseas, however, is not permitted by the Trust due various tax and legal requirements.

Annual Leave

As per Trust policy, requests for annual leave, as well as other forms of leave, should be raised with your Line Manager for approval.

The annual leave balance is renewed in April, and there are certain periods within the UK fiscal year in which you can sell/buy annual leave (see HR Portal for more information) subject to approval. If you find you expect to have a remaining unused annual leave balance and do not wish to sell these days, carry over into the next fiscal year is typically approved if it is 5 days or less, whereas more than 5 days will require Line Manager approval. In either case, we recommend you speak to your Line Manager as soon as possible to request formal approval and discuss leave scheduling.

Performance Development Review (PDR)

Members of the CSC Team undergo a yearly Performance Development Review (PDR) with their Line Manager, as well as a follow-up mid-year review. This is an opportunity for members of the team to set personal development goals and objectives, reflect on their ongoing progress, and highlight any outstanding areas where additional training and/or support may be required. It is also an opportunity to discuss your career progression, health and well-being concerns or changes in working hours.

For more information on the PDR process, please refer to the Trust HR Portal.

Access GSTT IT platforms

Remote desktop and applications i.e., via the Trust VPN on Citrix

New starters should ensure they set up and can access their remote Trust desktop and applications.

  1. Set up SafeNet Mobile Pass for One Time Passcodes (OTP) to use in conjunction with your GSTT account password
    • Submit the “Remote access request” form on the IT Service Centre website and request that the setup guide be sent to you by IT once the ticket has been completed.
    • Download the SafeNet Mobile Pass application on an easily accessible device e.g., phone or tablet.
  2. Set up Citrix either by:
    • Installing the Citrix Workspace app from here and connecting to GSTT’s server i.e., https://connect.gstt.nhs.uk (recommended)
    • Bookmarking the Citrix login website here
      • This will require you to download the images of your remote desktop and/or application(s) to open them and you will need to manually delete these files from your Downloads folder.

After completing the above steps, you should be able to access your GSTT applications remotely by logging onto Citrix with your GSTT username and password, and OTO generated on the SafeNet Mobile Pass application. If you require access to your GSTT desktop i.e., a single remote desktop window with multiple applications contained therein, and this has not been automatically enabled in your Citrix, please contact IT.

GSTT data platforms

Depending on the projects you will be involved in, you may also need to request access for and familiarise yourselves with the following data platforms to collaborate with the rest of the project team.

  • The Clinical Analytics team’s enterprise data warehouse (EDW) (also referred to as Health Catalyst or HC)
    • Email the Head of the Clinical Analytics team to request for access to this SQL server data warehouse and provide:
      • The date of your most recent Information Governance (IG) training
      • Details on what type of data you require and why
      • Any IG and project approvals relevant to your project
  • CRIS*
    • Email the Head of CSC for request for access to the application and up-to-date guidance on who to directly contact, if applicable.
  • XNAT

* To be updated post-Epic go live in October 2023.

In terms of technical skills required to interact with these platform, there is often a Graphical User Interface (GUI) available but some familiarity with Python and SQL is recommended.

Hackathon Planning Kit

CSC hackathons are an internal event where the CSC team and collaborators work together to solve a clinical problem with the aim to speed up innovation, complete work or to produce a prototype. Other hackathons are also held, such as hackathons to speed up project progress. The planning kit here only discusses the former type of a hackathon: where a clinical problem is being solved, usually by means of AI model training.

This guide aims to provide the hackathon organiser with the tools to set up and carry out a multi-day hackathon.


Before the hackathon

Consider your problem

The clinical problem being solved must be appropriate for the hackathon format. For example, training an AI model is an appropriate problem to solve as a team, whereas ingesting data into XNAT is not.

Governance

Ensure your project has the correct governance in place, including ethics approvals if this is a research project, or QIPS registration and approval if this is a service evaluation or a service improvement.

Key Objectives

Set the key objectives by outlining the work that has already been done and the work that must be done to consider the project completed. Write those out.

Data

The quality, quantity and accessibility of your data will define the success of your hackathon. This is particularly true for AI projects. Data collection is a long process from data curation, data labelling and data retrieval. This part must be done in advance of the hackathon.

Gather volunteers

A hackathon is a team effort: find out who is available and who wishes to participate and create a list of stakeholders, including the clinical team you’re collaborating with and any external collaborators that wish to contribute. You will need to use this list repeatedly to inform everyone on details - keep it handy.

To ensure the success of your hackathon you must identify all the key staff you need, e.g. QMS expert and MLOps expert. Make sure they are available on the selected dates, as the hackathon cannot go ahead without them.

Pre-hackathon meetings

You should organise at least 2 pre-hackathon meetings which cover the topics needed to ensure the success of the hackathon (e.g. clinical pathway you’re trying to improve). These will give you a chance to present the problem to your collaborators, present the data you have gathered (including data quality and demographics), and discuss the aims for the hackathon. It will give you a chance to conduct any training necessary, including refresher on MLOps, on XNAT, on medical imaging, or similar. If tools are used as part of the hackathon, such as the QMS or Voxel5, discussion and training on setting those up will also be vital.

If your objectives aim to improve or affect a clinical pathway, you must understand the current method of work well. If possible, it is recommend you organise to follow the whole pathway end to end by either shadowing or by performing interviews or similar research to map the pathway in detail.

Finally, once the user requirements are gathered, you must translate those into technical requirements and establish a traceable pathway between your goals during the hackathon and the user requirements. This can be done in the form of a pre-hackathon meeting or it can be performed in group at the start of the hackathon.


During the hackathon

Your hackathon should begin with an introduction at the start of the day and a clearly set out agenda. The agenda should include the summary of the clinical problem including the affected clinical pathway, it should include the summary of your data and the clearly stated purpose and aims of the hackathon. It should state the expected deliverables.

If you’re working in teams, create those teams at the start of the day. Otherwise, assign roles and duties as appropriate - consider both the expertise of your team members and what they wish to gain from the hackathon.

Each hackathon participant should have a clear aim of what they are trying to achieve and know who to turn to when they run into issues.

In your agenda, you should set aside time for:

  • check points
  • stand ups
  • lunch / refreshment break
  • team photo
  • synchronisation times (if multiple teams working on similar problems)
  • end of day demos

Agree on a GitHub branch naming convention - best practice is to create branches out of issues to ensure consistent naming and linking between requirements and features.

There should be a scrum master whose task is to ensure team members are on track to deliver on the aims set out. This includes walking around and seeing what individuals are doing, how they are approaching it, as well as being available for those who seek help. The scrum master should also monitor the repository, review changes to merge into main, and review branch naming.

If the team members writing the documentation are separate from those doing the programming or training, it is essential they work together closely to ensure the documentation reflects the solution which reflects the user and CSC requirements. There must be traceability of every feature in the solution to the CSC or user requirement.


After the hackathon

Immediately after the hackathon it is useful to gather feedback on the process. Best time to do so is immediately after the hackathon is done. It’s also worth considering organising a celebration of completing the hackathon.

In the week after the hackathon, review the GitHub repository and clean it up - there will be a lot of unfinished or half-finished work.

Set out a plan with your team on how to continue the development and how to continue to improve AI performance. The plan should reflect the size of the work.

Communicate the outcome of the hackathon to the clinical team and ask them to review any relevant work (such as reports or similar).


Other things to consider

The following are other pieces of advice collected from feedback from previous hackathons:

  • Setting up tiers of achievement / milestones - this helps teams understand where they are in the process and brings a sense of achievement as progress is made
  • Consider asking for creative input such as AI model naming
  • Consider the optimal ways of working: some people thrive in paired work, some thrive in tackling problems solo. The best way to get most out of your team is to facilitate both.
  • It is important each day ends with a show and tell where some piece of work or progress is demonstrated - not only described. Hyper-focus should be on showing a tangible step of progress towards the final solution. This will help at the end too when tying loose ends.
  • It is always easier to improve an existing solution that works than create a perfect solution from scratch.

Below is a handy checklist to keep tabs of your preparation. Each section corresponds to the advice above.


CSC hackathon planning checklist


Before the hackathon: preparation

  • Clinical problem to solve is clear and defined
  • Project has all relevant approvals
  • Key objectives have been defined in writing
  • Ensured clinical pathway is well understood
  • Data is ready, it has been:
    • collected / identified
    • labelled
    • imported into XNAT
  • Participants have been identified
    • Participants include key staff

Before the hackathon: pre-hackathon meetings

  • Organised all pre-hackathon meetings needed
  • Wrote the agenda for each pre-hackathon meeting
  • Sent out meeting invite to all participants for pre-hackathon meetings

Before the hackathon: organisation

  • Duration of the hackathon agreed
  • Dates of the hackathon agreed
  • Rooms for the hackathon booked
  • GitHub repository for project created
  • QMS templates added to the GitHub repository

  • User requirements gathering meeting organised
  • Written the agenda for the meeting
  • Written a list of specific questions for the clinical team (you can use the CSC template)
  • Made the user requirements identified in meeting into GitHub issues
  • Translated user requirements into technical requirements
  • Made technical requirements into GitHub issues

  • Wrote the hackathon agenda for each day and included:
    • Start and end times
    • Check points
    • Stand ups
    • Break times
    • Team photo time
    • Synchronisation time (if multiple teams)

  • Prepared an introduction presentation
  • Sent a final reminder of the hackathon to all participants