System Architecture

The platform is a Next.js application. The following is a System Architecture diagram showing a high-level overview of the various parts and how they are connected together:

The entire system is containerised via Docker for ease of deployment and configuration. You can find the web-app's Dockerfile and Docker Compose configuration in the GitHub repository.

The system's backend consists primarily of Next.js API routes to create a REST API that is consumed by the React-based frontend. Prisma is used as an object-relational mapper (ORM) to interact with a PostgreSQL database. We use an ORM to provide important safety mechanisms such as automatic query sanitisation, and to simplify the Development Experience (DX) by enabling IDE features such as automatic code completion, type checking, etc.

The REST API documentation exists in the form of an OpenAPI 3 (Swagger) specification. The JSON OpenAPI specification file can be found on GitHub, and the rendered documentation can be found here.

The frontend documentation exists as JSDoc in the source code, and a Docz-rendered component-level documentation which can be found here.

Keycloak is used as the identity and access management tool, with a single instance hosted alongside the web-app on the same server. NextAuth.js facilitates interaction between the web-app and the Keycloak OpenID Connect interface. In addition, various API routes internally use the Keycloak Admin REST API to interact with Keycloak when certain actions are performed.

On the production server (a Linode Virtual Private Server, VPS, instance provided to us by our client), we use Caddy server as a web server that acts as a reverse proxy for our Next.js app. It also handles HTTPS automatically for the domain name.

Site map

The following is a site map of the web-application:

All users arrive on the Home page, then depending on their user type (see the requirements page for more details), they can access the other pages of the system relevant to them: Statistics page, Self-reporting page, Manage page, Admin page and the User manual.

Data storage & Schema

The system contains 2 PostgreSQL databases, both within a single dockerised PostgreSQL instance: care_quality_dashboard and keycloak:

  • The keycloak database is entirely managed by Keycloak in the Keycloak Docker Container

  • The care_quality_dashboard database is the system's own database storing information such as responses, questions, departments, hospitals, etc. An ER-UML diagram is below, which also shows the relationships between each table:

Prisma is used as an ORM to communicate with the care_quality_dashboard database; the Prisma schema can be found in the GitHub repository.

Note: Secret environment variables are stored in a .env file in the root of the project. See .env.example as a template for this.

Keycloak (identity and access management)

Keycloak is configured as a standalone server running in a Docker container on the same machine, with Realm-level roles, in a sort-of hierarchy: clinician, department_manager, hospital, health_board, platform_administrator.

No identity providers have been configured via identity brokering. It is hoped that this could be used if an official NHS login system is used for the platform, as it can be simply connected to the same Keycloak instance via OpenID connect or SAML. See the research page for more details on the NHS Single Sign-On (SSO) research.

More details pertinent for development are provided in the GitHub repository.

Prisma (database ORM)

All database interactions are performed solely through Prisma, as it provides type enforcement, automatic query sanitisation, and simplifies the development experience.

The Prisma Client is generated through the Prisma Schema file which is stored in the GitHub respository.

More details pertinent for development are provided in the GitHub repository.