This week, we reached out to the NHS Wales contact we were provided with, rescheduled our meeting with Digital Health Ecosystem Wales, and worked on the development of the Statistics and Manage URLs page.

We also decided on what work we want to achieve over the Christmas holidays, and assigned issues to the three of us so we are aware of what we need to accomplish going into the holiday period.

Project rename

Following discussions with our client, we’ve now formally renamed the project to the Care Quality Dashboard.

All usages of ‘NHSW Self Assessment Tool’ or the like have been removed from our interface and codebase.

Login system

NHS Identity

We are currently researching our other options following last week’s call with NHS Identity.

This week, we emailed the NHS Wales contact that NHS Identity provided us with, and hope to receive more information from them soon.

Digital Health Ecosystem Wales

Unfortunately our meeting was cancelled shortly before it was due to occur.

We’ve rescheduled this meeting with the team for the first week of January, where we hope to learn more about their login system.

Keycloak

We’ve made various changes to our database design this week (see below). As part of these changes, we improved our login system with Keycloak.

One of the problems we were facing was determining how to integrate the Keycloak database with our own database. For example, a user registers and is stored in Keycloak — how do we store their user ID and other information (e.g department/hospital/health board ID) in our database to tie their responses, scores, etc. to?

After significant research we decided on the following:

  • Whenever a user logs in to our platform via the web-app, we check to see if the Keycloak-generated user ID exists in our own database.
    • If it is, we update our users.user_type field to make sure we’re in sync with the Keycloak role.
    • If it isn’t, we insert a new record into our users table with the Keycloak-generated user ID and the corresponding role.
  • We no longer store department/hospital/health board IDs for users in our own database. This is all delegated to Keycloak in the form of User Attributes, enabling us to separate the user-related storage and our platform-related storage more obviously.
    • We will use the Keycloak Admin REST API to communicate between our API and Keycloak, to update these IDs when needed. In practice, this should only really be when users register/join a new department/hospital/health board.

The above has now been implemented.

Development: frontend

Statistics page

This week, we continued working on styling for the statistics page and began to implement the word cloud component. As a reminder for what this is: in the self assessment, the clinician writes 3 positive and 3 negative words concerning the overall standards, which are to be visualised.

We also started working on the responsiveness of the statistics page, as we know many users will be using the platform via a mobile device, with smaller screens.

For the Word Cloud component, we used the open-source [react-wordcloud](https://www.npmjs.com/package/react-wordcloud) component which is based on the d3-cloud layout. We chose this component because it was developer-friendly with a simple API to produce fairly complicated word clouds.

We also worked on the styling of the filter, for example, aligning it to the left hand side of the graph, and working on the responsiveness of the statistics page via CSS.

Manage Questions page

This week following our big discussion about our database (as described below in the backend section) we decided the next thing that needs to be implemented is the admin page to manage questions.

We have made an initial plan on how to achieve this and have started implementing this this week. We have realised this is very similar to the manage URL’s page therefore this will use the same concepts in the most part however it will require some tweaks as now three columns will need to be updated, the question body, standard and default URL’s, instead of just one column like in the manage URL’s page. We have planned to do this by using reacts state feature and hopefully this will allow us to update two columns simultaneously and make the user experience as smooth and easy as possible.

We have also realised that due to the similarities of the manage page (the URL one for departments and the questions one for admins) we can just switch between components on the manage page depending on the user type of the current user, so will not need to have two sperate standalone manage pages, which means avoiding unnecessary code duplication.

Development: backend

New database design

This week, we had an important team meeting via Teams where we discussed plans for user registration, and support for storing different training URLs per department, as in our MoSCoW requirements.

We’ve decided to make the following changes:

  • Add a new question_urls table, so we can store URLs per-department.
  • Rename questions.url to questions.default_url to make this distinction more evident.
  • Consistently name field names, e.g. changing question_body to just body in the questions table, and rename abbreviations like dept to e.g. department across the database.
  • Remove the users.password field — this is irrelevant as Keycloak stores our user credentials.

  • Remove the *user_type tables. This is because we want to separate the logic between authentication/users and the actual platform as much as possible, to make it as easy as we can to switch out authentication mechanisms at a later date (e.g. if the NHS decide to use their own login system after we hand it over).

    We will now be storing department, hospital, and/or health board IDs via Keycloak, in our Keycloak database.

Our new schema with all these changes is shown below:

API Support for storing URLs per-question

We’ve updated the GET /api/questions API endpoint to allow for different departments to set different training URLs for the questions.

The API now joins with the question_urls table (via Prisma) and still returns a single URL. However, if a department has overridden the URL, then that URL is returned, rather than the default URL for the question.

This meant that we did not need to change how the client consumes the API very much at all — only the field names were changed which we hope to now keep constant!

Project Management

Our team met this week over Teams to decide on a plan for the Christmas holidays, and deciding what work we would like to complete.

Throughout the project, we’ve heavily used GitHub for project management: GitHub Issues for individual tasks that we can assign to our team members, and GitHub Projects to keep track of the project as a whole, and see how we’re progressing.

At the time of writing, our list of Issues and assignments look like the following:

As you can see, we have created different milestones for project. We have completed the “Term 1” milestone.

We now have “MVP” and “Polishing” milestones, which are due in a few weeks, and then a few weeks after that.

By the start of Term 2, we hope to have a functioning MVP with all the core functionality working and deployed.

Next steps

Following our team meeting this week, we have decided on the tasks we want to accomplish over the Christmas holidays, before Term 2 starts.

Much of this can be seen in the earlier GitHub issues screenshot, however a high-level summary and our assignments is listed below:

  • Complete the Statistics page, and integrate it with the backend → Matthieu
  • Implement the Manage Questions page and integrate it with the backend (also integrate the Manage URLs page with the backend) → Mateusz
  • Further develop the API to support all frontend features → Shubham
  • Implement the user registration related UI (Matthieu and Mateusz) and backend (Shubham)