This week (UCL’s Term 1 Reading Week), our team met over several calls spread at different times during the week to discuss the development process and to begin planning the system architecture.

The stack

We considered all our strengths and past experiences to decide on what tech stack to use for the system, in addition to research into available public resources for future support should we need it.

We decided on using a JavaScript-based stack:

  • Frontend: React (Next.js for server-rendered support)
  • Backend: Node.js (Express or similar)

We thought that using the same language in both the backend and frontend will help us focus our efforts on the quality of the project, rather than having to worry about switching between languages and learn different concepts/syntax for the different areas.

We also decided on using React as we were all most familiar with this, and it would be a good framework to create a user-friendly dynamically-updating interface. It is also extremely popular for building modern, maintainable interfaces with a ton of documentation and support available.

We also decided on using a relational database management system, e.g. PostgreSQL or MySQL. See the section on Storage later on for more details.

Frontend

We decided to use React over other web frameworks as most of us had prior experience with using it, so it would be easier to help each other out and again, focus on the quality instead of learning new frameworks.

We also researched other alternatives such as Svelte (Sapper), but determined that React had the most documentation and support available, and was relatively stable. This would be beneficial if we needed support whilst implementing the system.

Backend: login options

A key topic this week was discussing the login system for the platform. After meeting with our client it was clear that we needed to make the system as frictionless as possible for the highest chances of adoption by the NHS.

This meant that we needed a scalable, simple, and intuitive way to login and interact with the system. We discussed and researched various login options, as detailed below:

  • Users log in with unique pairs of IDs provided by their manager

    In this version, managers would maintain a list of clinicians in their department and assign them unique IDs, with their corresponding numeric Department ID, Hospital ID, and Health Board ID.

    Clinicians would then log in with these 4 IDs which were unique to them.

    Advantages:

    • Easy to implement

    Disadvantages:

    • Lack of security: anyone can login to a clinician’s account using brute force, testing different numeric ID combinations
    • Difficult to maintain: managers across hospitals/health boards would need to use the same ID for each department, etc. which requires additional communication and consistency
    • Difficult to remember: users need to remember 4 different numeric IDs to login

  • Users register with their NHS domain email address and create their own password, with credentials stored in our own database. Users can ‘join’ a department by clicking a unique URL their manager creates via the platform

    In this version, clinicians would be responsible for creating their own account with their own email address and password. Managers would send them a unique URL that identifies their department, and this would ‘assign’ the clinicians to the departments

    Advantages:

    • Relatively simply to implement
    • Familiarity: the majority of modern websites use an email-address/password to login, so this would be extremely familiar
    • Security: users would have their own passwords, which can be sufficiently more complex than simple numeric IDs

    Disadvantages:

    • URL approach to assign clinicians to departments may be less intuitive

  • We use an existing SSO (Single Sign On) platform to handle the user registration/login process (e.g. Shibboleth, Microsoft Azure Active Directory)

    In this version, we would use an external SSO service to maintain user details and handle registration/logins. Users would still need to register with their own email address and password.

    Advantages:

    • Familiarity: again, email-address/password login is the standard way to authenticate with modern websites
    • Security: security is managed by an existing tried-and-tested SSO system, e.g. password hashing/salting
    • Compatibility: if we were to use Microsoft’s SSO system (as used by the NHS), then theoretically in future it would be very easy to switch the SSO backend and integrate with the NHS’s SSO with little effort

    Disadvantages:

    • Some SSO providers cost money
    • Licensing issues when using 3rd-party systems
    • Difficult to implement: there would be a steep learning curve to implement a 3rd-party SSO system
    • Dependency on 3rd-party SSO system

  • Users log in via NHS’s SSO system, with their NHS email and password

    In this version, users simply authenticate with their NHS email and password to gain access to the website. They would not need to register themselves.

    Advantages:

    • Ease of use: no extra effort required by users to login, as they can use their existing credentials. Furthermore, they would not need to provide any details about themselves, as the platform could communicate with the NHS SSO to determine details such as: name, department, etc.
    • Familiarity: users already know their NHS credentials and use it on a daily basis to login to e.g. NHS email
    • Security: our platform would not need to store any passwords or sensitive information. All credentials would be managed by the NHS

    Disadvantages:

    • Implementation: NHS Identity requires an application to use their SSO system which is not guaranteed to be successful
    • Dependency on NHS network

We decided to further explore the latter 2 options (3rd party SSO or NHS Digital SSO). We hope to be able to write more about our findings next week!

Next steps

We will now begin the implementation process of the project.

At first, we will focus on the frontend: building out reusable React components that will be used throughout the system.

Alongside this, we will continue research and investigation into various backend decisions we need to make:

  • login options
  • storage requirements (for the database design)
  • data requirements (for the API design)

We aim to have started implementing the backend the week beginning 2020-11-30, if not earlier.