Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions app/_layouts/product.njk
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@
{% set sections = [
{ title: "Screening", services: [
"Bowel screening",
"Cohort manager",
"Explore team",
"HPV Self-Sampling",
"Manage breast screening",
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
10 changes: 10 additions & 0 deletions app/posts/cohort-manager.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
---
layout: collection
title: Cohort manager
description: A service that helps ensure the right people are selected for invitation to screening
pagination:
data: collections.cohort-manager
reverse: true
size: 50
permalink: "cohort-manager/{% if pagination.pageNumber > 0 %}page/{{ pagination.pageNumber + 1 }}{% endif %}/"
---
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
title: Diabetic eye screening - start with what we know
description: How we approached understanding the service
date: 2025-06-06
author: Sakshi Lamba Jhanji
tags:
- discovery
- cohort manager diabetic eye screening
---

Digital screening teams have set out to work on the digital transformation of national screening programmes. The [review of the breast screening services in 2018 (pdf)](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/764413/independent-breast-screening-review-report.pdf) resulted in breast screening being prioritised for this enormous task. Next in line was the diabetic eye screening (DES) programme; the discovery work for which had been paused in early 2024. Diabetic eye screening is an important test for people with diabetes to check for diabetic retinopathy, a condition that can lead to irreversible sight loss if not detected and treated early. This screening is usually offered for free and is an essential part of diabetes care to help prevent vision loss. Learn more about [diabetic eye screening](https://www.nhs.uk/tests-and-treatments/diabetic-eye-screening/).

The commercial contracts for cohorting and quality assurance (QA) services with third-party providers for DES expire in 2026, presenting a strong commercial and business case for the digital screening programme to consider DES.

Team Select is the first team in the value chain for digital screening and is working on the cohort manager product. Cohort manager aims to ensure the right people are selected for invitation to screening.

## What was the ask?

As team select is the first team looking at the diabetic eye screening programme, we were tasked with looking at the end-to-end journey of the screening programme and brainstorming on how we can leverage the capabilities we are building in digital screening to help DES.

The work was led by a user centered design (UCD) squad and supported by a technical architect. A multidisciplinary team with UCD professionals ensured that we championed a user-centred approach to looking at the users’ journey within DES.

We started with a focus on looking at the entire end-to-end journey for the programme before jumping into studying how the cohorting product by our team would assist in resolving the challenges and pain points of DES.

## Our approach

Our approach to this work was to ‘Start with what we know’. Before us, several other teams had done discoveries for DES therefore we used the previous discoveries to take up this task. We reviewed the existing artefacts and documentation to build our understanding so we could make use of the existing wealth of knowledge.

We reflected on the lessons we had learned from breast screening to identify the gaps in our knowledge and the existing documentation we had.

We leveraged the expertise of our colleagues working on the digital strategy and policy for DES to understand aspirations and key milestones for the programme.

As screening programmes have complex journeys with several staff users, public users, legacy systems and processes to capture, we decided to summarise all our learnings visually. We worked on achieving a visual output on Mural to enable others to engage at a high level with what happens today and how tomorrow could potentially look.

We examined and synthesised the pain points identified in the programme by different users involved. We gathered pain points that had already been identified in the previous discovery, analysed them and prioritised them. After this exercise, we then looked at different products and capabilities available in digital screening and how they could meet these needs.

## Output

We produced a high-level artefact of the DES as-is and desired to-be end-to-end screening journey.

![The high level end-to-end desired journey for diabetic eye screening](end-to-end-journey.png)
[Download the image as a PDF (102 KB)](/pdfs/cohort-manager/2025/06/start-with-what-we-know/diabetic-eye-desired-end-to-end-journey.pdf)

We started with bringing together various teams and professions to engage with the artefact so all teams could have a shared understanding of DES and our to-be desired state. Moreover, getting more teams and professions involved meant more perspectives and ideas to examine a possible vision for DES.

The artefact has become a starting point for various outcome teams who can start visualising the end-to-end user journeys, systems and processes and then zoom into their specific service offerings and products.

We validated the high-level and key pain points with the DES programme to make sure we were on the right track and looking to solve the right problems for the programme.

Whilst this ask of our team had a tangible output, the outcomes of this work are even more valuable. One of the foremost reflections by Lou Downe in their blog about [‘What is a service?’](https://good.services/blog/what-is-a-service): ‘Just because you don’t provide the whole service, doesn’t mean you’re not responsible for the outcome.’ This exercise brought to the foreground the importance of understanding the whole DES service and not just focusing on the cohorting service we are working on. It also reiterated the role digital teams play by breaking the silos and initiating important conversations.

## Outcomes

We saved time and resources by reviewing existing documentation and validating information, needs and pain points. This helped us start the process early and build on what we knew already.

We looked at the end-to-end journey to understand how our product fits into the wider service, thus being able to consider the impact and value of the proposition of our product on the wider journey. This gave us an opportunity to consider transformations which would have a wide-ranging impact on the service. By understanding the landscape and broader journey, we were able to ensure that service changes would mean more people will get invited for diabetic eye screening, reducing the chance of people losing their sight due to diabetic retinopathy. We learned that it was important to check the integrity of the DES cohort at 2 key stages to help us provide assurance early on, minimising manual tasks and reconciliation efforts.

Relationships with stakeholders were built on a solid foundation. Rather than having them reiterate what they had already shared with previous teams, we took the initiative to enhance our understanding as much as possible before we went to them with questions. This showed respect for their time and helped to quickly build social capital.

As we continue our work on DES, the next step for us was to zoom in on cohorting in DES.
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: Breast screening - our first prototype
description: Exploring the first design of our user interface
date: 2025-06-11
author: Kieron Bradshaw
tags:
- prototype
- alpha
- cohort manager breast screening
---

Cohort manager is being developed to help identify, receive and correct the demographic details for eligible participants of a screening service, so they are correctly selected for invitation. It's initially being built for use with the breast screening programme, with the intent that it will be available for use by any screening programme in the future.

Please note that this post provides the early design of our user interface. We'll be sharing updated versions soon and exploring how it has been developed to align with changes in our user group and the tasks they will complete.

## Improving the quality of screening data

To begin, imagine a person whose NHS record has been selected as being eligible for routine breast screening.

If their record contains even small errors or missing information, a data exception will be generated, meaning their screening invitation could be delayed while staff work hard to manually investigate and fix the problem.

To support this process and ensure that errors are picked up early and quickly resolved, cohort manager will apply a series of validation rules to each record entering the screening pathway.

It automatically identifies invalid or missing information (data exceptions) and can resolve many data issues, such as transformations, without staff intervention.

For cases that need manual intervention by staff, the system provides an interface that visualises the data exception and enables users to quickly direct it to the appropriate team for resolution.

## Our first design of the user interface

Our first prototype was based on our understanding of the work of participant index (PI) bureau colleagues. This is the team that manages data quality for routine breast screening cohorts in existing live systems.

Although the specific staff group using the interface has changed since this first design, its purpose was the same: to enable users to view any data exceptions that require manual intervention.

The long-term ambition is for cohort manager to raise all exceptions with the appropriate teams automatically. As the user interface is only intended to be an interim solution, decisions made around meeting each user need have been balanced against the time and resource it would take to build functionality.

Throughout this section we'll explore each screen of our initial prototype.

### Overview screen

![A screenshot of cohort manager's overview page. It uses mock data to demonstrate the total number of exceptions currently identified, and then has 2 further placeholder cards to show how the screen would work as both a home page and a dashboard for the user.](overview.png)

This is the first screen that a user sees when they log into cohort manager. It uses the [card component](https://service-manual.nhs.uk/design-system/components/card) to provide a simple overview of data exceptions that require manual intervention.

Our hope was that this component would provide structure for the landing page whilst also serving as a dashboard. Each card is configured to display the number of outstanding exceptions for a particular category and provides users with a snapshot of tasks to help prioritise their workload. The user can click each one to navigate to more detail.

### Summary screen

![A screenshot of cohort manager's summary page, complete with mock participant data and a short descriptoin of the exception.](summary.png)

Depending on which card the user clicks on the previous screen, they will be taken to a summary screen that provides a quick view of all open exceptions for that category.

The intention is that by presenting the information in a [basic table](https://service-manual.nhs.uk/design-system/components/table), it's easier for users to compare and scan the data when prioritising their tasks.

Other key design components included on the summary page are:

#### Snapshots of key information for each exception

From our research with users, we knew that information they looked for to help prioritise and carry out their tasks effectively were:

* the participant's NHS number
* the date the exception was created
* a short description of the problem

#### Unique identifier for each exception

Each exception has a unique ID. We used this as the point of navigation for the user to find more detail about an exception.

### Participant details screen

Please note: the data shown in the image below is for demonstration purposes and is not a real person.

![A screenshot of cohort manager's participant information screen. It displays the first tab of the screen that contains mock demographic details for a participant. This gives an idea of the level of detail that the page will provide, including: name, date of birth, NHS number, address, contact details and GP practice details.](participiant-information.png)

This is our final screen, where we provide more detail about each data exception.

In our initial design, this information intended to support the participant index (PI) bureau user to understand the problem with the record, whilst providing enough data about the participant to support any investigation needed to correct it.

The level of detail included was based on our research with this user group. We needed to find the right balance between:

* ensuring the user had enough detail to carry out their task
* avoiding overloading them with information
* preventing information governance issues that may arise from revealing more personal data than is needed for a task

To keep the layout simple, we used a summary list to pair related information and used [tabs](https://service-manual.nhs.uk/design-system/components/tabs) to separate the participant data from the details of the exception that has occurred. Our intention was to structure the information in a way that places the least strain possible on the user.

## Next steps

Our prototype is constantly improving as we test it with users, and we will highlight other useful information about the development of the interface in future posts.
5 changes: 5 additions & 0 deletions app/posts/cohort-manager/cohort-manager.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
{
"eleventyNavigation": {
"parent": "Cohort manager"
}
}
12 changes: 8 additions & 4 deletions eleventy.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,14 @@ module.exports = function (eleventyConfig) {


// Screening collections
eleventyConfig.addCollection("bowel-screening", (collection) => {
return collection.getFilteredByGlob("app/posts/bowel-screening/**/*.md")
})

eleventyConfig.addCollection("cohort-manager", (collection) => {
return collection.getFilteredByGlob("app/posts/cohort-manager/**/*.md")
})

eleventyConfig.addCollection('explore-team', collection => {
return collection.getFilteredByGlob('app/posts/explore-team/**/*.md')
})
Expand All @@ -67,10 +75,6 @@ module.exports = function (eleventyConfig) {
return collection.getFilteredByGlob('app/posts/manage-breast-screening/**/*.md')
})

eleventyConfig.addCollection("bowel-screening", (collection) => {
return collection.getFilteredByGlob("app/posts/bowel-screening/**/*.md")
})

eleventyConfig.addCollection("manage-your-screening", (collection) => {
return collection.getFilteredByGlob("app/posts/manage-your-screening/**/*.md")
})
Expand Down