From b4da4eaf4945616433c98b38aaa5aed9bf06cd2f Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 29 May 2026 16:51:14 +0100 Subject: [PATCH 01/10] Design history abt BSR work to date I kept it clear of any images for now, it's important to just get the message out for now --- .../index.md | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md new file mode 100644 index 000000000..e1d4d59fc --- /dev/null +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -0,0 +1,84 @@ +--- +title: The evolution of breast screening reporting +description: How the team’s understanding of breast screening reporting evolved from dashboard prototyping to NBSS data extraction and reconciliation +date: 2026-05-29 +tags: + - breast screening + - reporting + - BSIS + - NBSS + - data platform + - dashboards +author: + - Laboni Paul +--- + +# The evolution of breast screening reporting + +## Introduction + +Analysing breast screening performance has been difficult, relying on manually created, backdated data tables pulled from multiple systems that made it hard to get useful insights. + +This post captures key stages of the breast screening reporting team’s journey in modernising breast screening data reporting and what the team are doing next. + +## Laying the groundwork for data reporting + +Turning pre-aggregated data tables into new insights is like making a Victoria sponge by mashing up cupcakes – it doesn’t really work. Participant-level data provides the raw ingredients needed to mix up new metrics and visualisations from scratch. + +We planned automated pipelines and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: + +### Establishing ways of working + +The teams extracting data were separate from those analysing the data and working with users, making it difficult to ensure the work being done meets real user needs and justify the use of the data. To address this, we formed a multidisciplinary data product team bringing together analysts, engineers, and user-centred design to work together and understand requirements, owning the entire data pipeline from source to product. + +### Validating the top data requirements of breast screening office staff + +We visited breast screening offices to understand which automated insights would be most valuable. We found that, across screening units, commissioners, and digital teams, there is a shared need for easier-to-interpret oversight metrics that make it possible to assess the equity of breast screening. + +We also uncovered more complex problems to address in the future, such as the more accurate and scalable capture of Pathology BQA data. + +### Access to participant-level data and governance + +We planned to join participant-level data with other attributes, such as ethnicity data, to create datasets that could be queried to better understand inequalities and variation across services. + +To do this well, a data platform was required. However, we discovered a lack of clear legal basis to move participant-level data into modern analytical platforms. Our proposal supported a change in legal basis, unlocking the ability for all adult screening programmes to use record-level data for insights. + +## Prototyping the downstream reports + +Breast Screening Information Systems (BSIS) reports help Quality Assurance (QA) staff monitor and ensure the safety of breast screening services by identifying failures to comply with performance standards. While important, the reports are hard to access and use, and the platform will eventually be decommissioned. Running and maintaining BSIS helped us refine our goal: replacing BSIS reports with intuitive, automated dashboards. + +While we waited for access to real participant-level data, we used synthetic data that resembled the real data closely enough for testing and development. We created prototype dashboards to test with users, understand their needs, and explore platforms, ensuring what we intended to build was fit for purpose before extracting any real data. + +### Exploring reporting domains + +Ownership of BSIS provided an opportunity to gain a deeper understanding of the business logic underpinning key reports. We used short design sprints to explore each reporting domain and understand how it could be improved. + +We started with the simplest reports and found that improvements to infographics and metrics could replace and improve multiple BSIS reports with a single automated dashboard that offered better comparisons, visualisations, and user experience. + +### Testing data platforms + +Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain — image reading QA — as a stress test for the reporting roadmap. + +### Running and maintaining BSIS + +KC62 helps provide a national picture of breast screening activity and performance. The introduction of very high risk participants requires updates to the KC62 tables in BSIS. This work deepened our understanding of how breast screening services operate and the complexity of NBSS business logic. + +## Reconciling data upstream + +Each breast screening service operates its own NBSS instance, introducing variation and challenges in bringing data together. While some differences are reconciled through BS Select, many reporting domains — particularly image reading — depend solely on NBSS data. + +Having established a vision for the dashboards we wanted to build, our focus shifted upstream from reporting outputs to the source data itself. The reporting team was renamed the **NBSS Extraction team** to reflect this change. The goal remains the same: creating modern reporting products. Our immediate focus is creating the data foundations needed to support Rubie before returning to dashboard development. + +### Preparing a data platform + +A Databricks solution met the needs of the most complex reporting domains we intend to replace. We began establishing an environment that could both support future dashboards and provide a space to explore, analyse, and reconcile NBSS data. + +We explored role-based access controls, approaches to pseudonymising data, and built an automated pipeline into a sandbox environment. This provides a foundation for analysing NBSS data dumps and developing future reporting products. + +### NBSS data extraction + +The team is initially using dummy data to understand how data from different NBSS instances may need to be combined, reconciled, and standardised. + +The next step is to bring NBSS data from multiple services into Databricks, so the team can explore how the data works across service boundaries. For example, can we identify one participant’s journey across multiple services, and understand how that journey is recorded in each system? + +This work lays the foundations for the original reporting vision: intuitive, automated reporting built on a trusted understanding of the underlying data. From eccbc2479ab3c2991cecbe71aa37ccd6c3118fcd Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 29 May 2026 17:06:14 +0100 Subject: [PATCH 02/10] Updated hyperlinks --- .../index.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index e1d4d59fc..331db5a0c 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -25,7 +25,7 @@ This post captures key stages of the breast screening reporting team’s journey Turning pre-aggregated data tables into new insights is like making a Victoria sponge by mashing up cupcakes – it doesn’t really work. Participant-level data provides the raw ingredients needed to mix up new metrics and visualisations from scratch. -We planned automated pipelines and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: +We planned [automated pipelines](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/05/moving-source-system-event-data-through-nsp-and-into-fdp/) and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: ### Establishing ways of working @@ -35,13 +35,13 @@ The teams extracting data were separate from those analysing the data and workin We visited breast screening offices to understand which automated insights would be most valuable. We found that, across screening units, commissioners, and digital teams, there is a shared need for easier-to-interpret oversight metrics that make it possible to assess the equity of breast screening. -We also uncovered more complex problems to address in the future, such as the more accurate and scalable capture of Pathology BQA data. +We also uncovered more complex problems to address in the future, such as the more accurate and scalable capture of [Pathology BQA data](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/07/). ### Access to participant-level data and governance We planned to join participant-level data with other attributes, such as ethnicity data, to create datasets that could be queried to better understand inequalities and variation across services. -To do this well, a data platform was required. However, we discovered a lack of clear legal basis to move participant-level data into modern analytical platforms. Our proposal supported a change in legal basis, unlocking the ability for all adult screening programmes to use record-level data for insights. +To do this well, a data platform was required. However, we discovered a lack of clear legal basis to move participant-level data into modern analytical platforms. Our proposal supported a [change in legal basis](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/directions-and-data-provision-notices/secretary-of-state-directions/nhs-vaccination-and-screening-directions-2026), unlocking the ability for all adult screening programmes to use record-level data for insights. ## Prototyping the downstream reports @@ -51,13 +51,13 @@ While we waited for access to real participant-level data, we used synthetic dat ### Exploring reporting domains -Ownership of BSIS provided an opportunity to gain a deeper understanding of the business logic underpinning key reports. We used short design sprints to explore each reporting domain and understand how it could be improved. +Ownership of BSIS provided an opportunity to gain a deeper understanding of the business logic underpinning key reports. We used short [design sprints](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/12/using-design-sprints-to-help-us-learn-quickly/) to explore each reporting domain and understand how it could be improved. We started with the simplest reports and found that improvements to infographics and metrics could replace and improve multiple BSIS reports with a single automated dashboard that offered better comparisons, visualisations, and user experience. ### Testing data platforms -Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain — image reading QA — as a stress test for the reporting roadmap. +Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain — image reading QA — as a [stress test](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2026/04/re-designing-image-reading-data-reporting-to-stress-test-the-reporting-roadmap/) for the reporting roadmap. ### Running and maintaining BSIS @@ -77,8 +77,6 @@ We explored role-based access controls, approaches to pseudonymising data, and b ### NBSS data extraction -The team is initially using dummy data to understand how data from different NBSS instances may need to be combined, reconciled, and standardised. +The team is initially using dummy data to understand how data from different NBSS instances may need to be combined, reconciled, and standardised as a warm-up before bringing NBSS data from multiple services into Databricks. This will allow them to explore how the data works across service boundaries. For example, 'can we identify one participant’s journey across multiple services, and understand how that journey is recorded in each system?' -The next step is to bring NBSS data from multiple services into Databricks, so the team can explore how the data works across service boundaries. For example, can we identify one participant’s journey across multiple services, and understand how that journey is recorded in each system? - -This work lays the foundations for the original reporting vision: intuitive, automated reporting built on a trusted understanding of the underlying data. +This work allows critical operations to take place and helps bring to life the original reporting vision of intuitive, automated reporting built on a trusted understanding of the underlying data. From d9b2b0146ddfeef262bece9e0f0b68dbf9e76249 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 29 May 2026 17:13:29 +0100 Subject: [PATCH 03/10] Tweaked some punctuation --- .../index.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index 331db5a0c..29814963b 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -23,7 +23,7 @@ This post captures key stages of the breast screening reporting team’s journey ## Laying the groundwork for data reporting -Turning pre-aggregated data tables into new insights is like making a Victoria sponge by mashing up cupcakes – it doesn’t really work. Participant-level data provides the raw ingredients needed to mix up new metrics and visualisations from scratch. +Turning pre-aggregated data tables into new insights is like making a Victoria sponge by mashing up cupcakes - it doesn’t really work. Participant-level data provides the raw ingredients needed to mix up new metrics and visualisations from scratch. We planned [automated pipelines](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/05/moving-source-system-event-data-through-nsp-and-into-fdp/) and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: @@ -41,11 +41,11 @@ We also uncovered more complex problems to address in the future, such as the mo We planned to join participant-level data with other attributes, such as ethnicity data, to create datasets that could be queried to better understand inequalities and variation across services. -To do this well, a data platform was required. However, we discovered a lack of clear legal basis to move participant-level data into modern analytical platforms. Our proposal supported a [change in legal basis](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/directions-and-data-provision-notices/secretary-of-state-directions/nhs-vaccination-and-screening-directions-2026), unlocking the ability for all adult screening programmes to use record-level data for insights. +To create these products properly, a data platform is required. However, we discovered a lack of clear legal basis to move participant-level data into modern analytical platforms. Our proposal supported a [change in legal basis](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/directions-and-data-provision-notices/secretary-of-state-directions/nhs-vaccination-and-screening-directions-2026), unlocking the ability for all adult screening programmes to use participant-level data for insights. ## Prototyping the downstream reports -Breast Screening Information Systems (BSIS) reports help Quality Assurance (QA) staff monitor and ensure the safety of breast screening services by identifying failures to comply with performance standards. While important, the reports are hard to access and use, and the platform will eventually be decommissioned. Running and maintaining BSIS helped us refine our goal: replacing BSIS reports with intuitive, automated dashboards. +Breast Screening Information Systems (BSIS) reports help quality assurance staff monitor and ensure the safety of breast screening services by identifying failures to comply with performance standards. While important, the reports are hard to access and use, and the platform will eventually be decommissioned. Running and maintaining BSIS helped us refine our goal: replacing BSIS reports with intuitive, automated dashboards. While we waited for access to real participant-level data, we used synthetic data that resembled the real data closely enough for testing and development. We created prototype dashboards to test with users, understand their needs, and explore platforms, ensuring what we intended to build was fit for purpose before extracting any real data. @@ -57,7 +57,7 @@ We started with the simplest reports and found that improvements to infographics ### Testing data platforms -Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain — image reading QA — as a [stress test](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2026/04/re-designing-image-reading-data-reporting-to-stress-test-the-reporting-roadmap/) for the reporting roadmap. +Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain, image reading quality assurance, as a [stress test](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2026/04/re-designing-image-reading-data-reporting-to-stress-test-the-reporting-roadmap/) for the reporting roadmap. ### Running and maintaining BSIS @@ -65,18 +65,18 @@ KC62 helps provide a national picture of breast screening activity and performan ## Reconciling data upstream -Each breast screening service operates its own NBSS instance, introducing variation and challenges in bringing data together. While some differences are reconciled through BS Select, many reporting domains — particularly image reading — depend solely on NBSS data. +Each breast screening service operates its own NBSS instance, introducing variation and challenges in bringing data together. While some differences are reconciled through BS Select, many reporting domains, particularly image reading, depend solely on NBSS data. -Having established a vision for the dashboards we wanted to build, our focus shifted upstream from reporting outputs to the source data itself. The reporting team was renamed the **NBSS Extraction team** to reflect this change. The goal remains the same: creating modern reporting products. Our immediate focus is creating the data foundations needed to support Rubie before returning to dashboard development. +Having established a vision for the dashboards we wanted to build, our focus shifted upstream from reporting outputs to the source data itself. The reporting team was renamed the **NBSS Extraction team** to reflect this change. The goal remains the same: creating modern reporting products, but the immediate focus is reconciling the data needed to support Rubie before returning to the dashboard development that sits on top of this foundational work. ### Preparing a data platform -A Databricks solution met the needs of the most complex reporting domains we intend to replace. We began establishing an environment that could both support future dashboards and provide a space to explore, analyse, and reconcile NBSS data. +A Databricks solution met the needs of the most complex reporting domains we intend to replace, so we began establishing an initial environment that could both support future dashboards and provide a space to explore, analyse, and reconcile NBSS data. -We explored role-based access controls, approaches to pseudonymising data, and built an automated pipeline into a sandbox environment. This provides a foundation for analysing NBSS data dumps and developing future reporting products. +We explored role-based access controls, approaches to pseudonymising data, and built an automated pipeline into a test environment. This provides a foundation for analysing NBSS data dumps and developing future reporting products. ### NBSS data extraction -The team is initially using dummy data to understand how data from different NBSS instances may need to be combined, reconciled, and standardised as a warm-up before bringing NBSS data from multiple services into Databricks. This will allow them to explore how the data works across service boundaries. For example, 'can we identify one participant’s journey across multiple services, and understand how that journey is recorded in each system?' +The team is initially using dummy data to understand how data from different NBSS instances may need to be combined, reconciled, and standardised as a warm-up before bringing NBSS data from multiple services into Databricks. This will allow them to explore how the data works across service boundaries by answering key questions. For example, 'can we identify one participant’s journey across multiple services, and understand how that journey is recorded in each system?' This work allows critical operations to take place and helps bring to life the original reporting vision of intuitive, automated reporting built on a trusted understanding of the underlying data. From 76e11bddac728f12c26c0b820979d43081d4b2a1 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:28:20 +0100 Subject: [PATCH 04/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index 29814963b..be8f350a7 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -13,8 +13,6 @@ author: - Laboni Paul --- -# The evolution of breast screening reporting - ## Introduction Analysing breast screening performance has been difficult, relying on manually created, backdated data tables pulled from multiple systems that made it hard to get useful insights. From f061662f078d79e088e2da2a9746d27beb5d1b0b Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:28:36 +0100 Subject: [PATCH 05/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index be8f350a7..7f0184e71 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -33,7 +33,7 @@ The teams extracting data were separate from those analysing the data and workin We visited breast screening offices to understand which automated insights would be most valuable. We found that, across screening units, commissioners, and digital teams, there is a shared need for easier-to-interpret oversight metrics that make it possible to assess the equity of breast screening. -We also uncovered more complex problems to address in the future, such as the more accurate and scalable capture of [Pathology BQA data](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/07/). +We also uncovered more complex problems to address in the future, such as the more accurate and scalable capture of [Pathology BQA data](/breast-screening-reporting/2025/07/). ### Access to participant-level data and governance From 1cebfed25f3971509416dbb7fd9a01217ee2dfa8 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:28:43 +0100 Subject: [PATCH 06/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index 7f0184e71..f52886114 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -23,7 +23,7 @@ This post captures key stages of the breast screening reporting team’s journey Turning pre-aggregated data tables into new insights is like making a Victoria sponge by mashing up cupcakes - it doesn’t really work. Participant-level data provides the raw ingredients needed to mix up new metrics and visualisations from scratch. -We planned [automated pipelines](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/05/moving-source-system-event-data-through-nsp-and-into-fdp/) and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: +We planned [automated pipelines](/breast-screening-reporting/2025/05/moving-source-system-event-data-through-nsp-and-into-fdp/) and dashboards to extract and analyse granular data to replace the manual shifting of multiple data extracts from source systems. However, we first had to address some strategic challenges: ### Establishing ways of working From d3f25165a55c7525fca5a2de4aebb448fff10e99 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:28:51 +0100 Subject: [PATCH 07/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index f52886114..36d849e35 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -55,7 +55,7 @@ We started with the simplest reports and found that improvements to infographics ### Testing data platforms -Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain, image reading quality assurance, as a [stress test](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2026/04/re-designing-image-reading-data-reporting-to-stress-test-the-reporting-roadmap/) for the reporting roadmap. +Starting with an MVP was a useful way to learn how different data platforms worked, understand their tooling and processes, and test how users would interact with dashboards. Once we understood the basics, we explored the most complex reporting domain, image reading quality assurance, as a [stress test](/breast-screening-reporting/2026/04/re-designing-image-reading-data-reporting-to-stress-test-the-reporting-roadmap/) for the reporting roadmap. ### Running and maintaining BSIS From 4db53ec80d6848c9b909edd3efd7e0f692c61e6a Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:29:01 +0100 Subject: [PATCH 08/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index 36d849e35..a3cc08c46 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -49,7 +49,7 @@ While we waited for access to real participant-level data, we used synthetic dat ### Exploring reporting domains -Ownership of BSIS provided an opportunity to gain a deeper understanding of the business logic underpinning key reports. We used short [design sprints](https://design-history.prevention-services.nhs.uk/breast-screening-reporting/2025/12/using-design-sprints-to-help-us-learn-quickly/) to explore each reporting domain and understand how it could be improved. +Ownership of BSIS provided an opportunity to gain a deeper understanding of the business logic underpinning key reports. We used short [design sprints](/breast-screening-reporting/2025/12/using-design-sprints-to-help-us-learn-quickly/) to explore each reporting domain and understand how it could be improved. We started with the simplest reports and found that improvements to infographics and metrics could replace and improve multiple BSIS reports with a single automated dashboard that offered better comparisons, visualisations, and user experience. From 350eeb89778439356e22dee3a4f0baedd92c0fe8 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:29:40 +0100 Subject: [PATCH 09/10] Update app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md Co-authored-by: Frankie Roberto --- .../2026/05/volution-of-breast-screening-data-reporting/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index a3cc08c46..bf0becaa7 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -13,7 +13,6 @@ author: - Laboni Paul --- -## Introduction Analysing breast screening performance has been difficult, relying on manually created, backdated data tables pulled from multiple systems that made it hard to get useful insights. From e792c4a0d38cde4dbf889db84b76d336e6138611 Mon Sep 17 00:00:00 2001 From: Laboni Date: Fri, 5 Jun 2026 11:32:46 +0100 Subject: [PATCH 10/10] Update index.md As suggested, added a link to explain KC62 --- .../05/volution-of-breast-screening-data-reporting/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md index bf0becaa7..50e93afd7 100644 --- a/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md +++ b/app/breast-screening-reporting/2026/05/volution-of-breast-screening-data-reporting/index.md @@ -58,7 +58,7 @@ Starting with an MVP was a useful way to learn how different data platforms work ### Running and maintaining BSIS -KC62 helps provide a national picture of breast screening activity and performance. The introduction of very high risk participants requires updates to the KC62 tables in BSIS. This work deepened our understanding of how breast screening services operate and the complexity of NBSS business logic. +The [KC62 statutory report](https://archive.datadictionary.nhs.uk/DD%20Release%20May%202024/data_sets/central_return_data_sets/nhs_breast_screening_programme_central_return_data_set__kc62_.html) helps provide a national picture of breast screening activity and performance. The introduction of very high risk participants requires updates to the KC62 tables in BSIS. This work deepened our understanding of how breast screening services operate and the complexity of NBSS business logic. ## Reconciling data upstream