Briefly describe the initiative/ project/service; please include your aims and objectives

A D2I-API solution for the DfE’s transformative Early Adopter’s CSC API pipeline pilot.

The SSD is providing the standardised middleware enabling a cross-platform, system agnostic solution and our new D2I-SSD-API solution will soon be deployed into 13 more local authorities.

CSC SSD API Dataflow : (https://data-to-insight.github.io/dfe-csc-api-data-flows/)

SSD Data Model Next : (https://data-to-insight.github.io/ssd-data-model-next/)

We have previously submitted(2024/25) the Standard Safeguarding Dataset (SSD), as being a transformative middleware solution, designed to enhance how Children’s Social Care (CSC) data can be standardised for local authorities, and across local authorities. The SSD works in parallel with existing case management systems (CMS) to unlock ‘open, standard and extensible’ access to a focused range of key raw reporting data. Thus enabling local authorities towards better benchmarking, and importantly, open and enhanced reporting or development collaboration across local authorities.

(SSD Data Model Legacy https://data-to-insight.github.io/ssd-data-model/)

This new groundbreaking CSC API pipeline project has the potential to alleviate LA’s significant overheads for CSC statutory returns, enables via the DfE both a private live view of data quality against DfE validators and daily data benchmarking via DfE’s shared dashboard for an extended data timeframe (rolling two year window). Our SSD-API solution provides the middleware and plug-in pipeline into these new LOCAL AUTHORITY standards focused DfE tools.

Using the SSD’s standardised CSC data points, our API solution accesses cross-system data in MOSAIC and SystemC CMSwe have been able to create a standard ‘returns payload’(Eclipse, Azeus pipeline also in progress). As such we’ve been able to evidence a successful live trials of the extensible nature of the SSD and on the back of that, rapidly build and deploy compatible data tooling to provide a daily flow of data between local authorities and the DfE’s Childrens Social Care DataBenchmarking|QA Dashboard. A first for the sector.

Key developments:

• SSD (open-source standardised CMS middleware for every local authority)
• SSD+API extension (open-source payload builder and local authority audit mechanism)
• D2I API solution (open-source pipeline tool to enable agreed daily data flows to DfE)

Suggested key outcomes:

• Pilot local authorities now have the possibility for a plug-in API pipeline(automated if desired) for a CSC stat-return thus removing annual burdens
• Our SSD-API pipeline could be re-purposed locally for connecting to other services
• Our SSD-API data staging process can be repurposed for easier local reporting on child-level changes within stat-return dataeven without front-end access to CMS system
• DfE enabled – Live data quality oversight via DfE’s private QA/LA dashboard
• DfE enabled – Current point-in-time and extended data benchmarking for participating local authorities.

What are the key achievements?

From the D2I API solution:

• Enabled by the SSD layer, an open-source standard plug-and-play data pipeline for all local authorities
• Optimised/minified returns-data footprint for child-level DfE defined data points
• Positive buy-in by ~17 local authorities with the first stages working directly with 4 (MOSAICx1, SystemCx2, OLMx1)
• Multi-approach API offer maximises compatibility and ease for local authority deployment
• Successful pipeline deployment(and sending!) of CSC data between multiple LA’s and the DfE

Recap from stand-alone SSD (2024/25 submission):

• Mapping the core and high-value data points critical to Children’s Services intelligence work. The mapping of these 340 datapoints underpins the SSD to support and enhance analytical and business intelligence capabilities within local authorities. TheSSD was designed as a broader dataset that extends beyond existing statutory requirements, providing both more granular insights into Children’s Social Care data and an extended time-frame beyond Statutory Returns.
• Convening 97 stakeholders from 38 local authorities to drive the dataset design. These participants represented a wide range of roles, including data leads, team managers, QA managers, and senior strategic leads. Their input helped define the most pressing data challenges and opportunities for improvement, ensuring the SSD meets the diverse needs of local authorities.
• Reaching beyond LA tech communities to engage the wider academic research community (CSDUG) and social work experts (BASW). These workshops explored the current limitations in CSC data reporting and identified difficult-to-tell data stories that could benefit from the enhanced data accessibility provided by the SSD.
• Improving key data-point visibility, and providing increased human readable/navigable routes beyond internal CMS limitations and statutory reporting structures.; The SSD improves access for local authorities to conduct more detailed and meaningful analysis.

How Innovative is your initiative?

In this system, the modular elements themselves are not the innovation; however, the SSD-D2I API solution is a first crucial step towards wide-adoption, cross-system data compatibility and pipelines for local authority safeguarding services. A recurring time saving potential year on year, a proof-of-concept solution that can easily be taken and further developed locally for new data pipelines at a fraction of the otherwise needed time-cost overheads. We’re seeing this already from LA’s who have used the D2I API solution as the building block for their own bespoke solutions as well as those local authorities who have similarly used the SSD schema|structure as the core to their new data lake model. The combination(s) working incrementally towards improved standardisation across the sector. Innovation within a flexible solution to fit non-standard LA requirements out-of-the-box; a platform agnostic open-source approach providing a tested solution that has potential far beyond the initial offering.

Replicability and Scalability

Both the SSD and the API solution have been designed to facilitate wide adoption, with support from DfE to explore deployment to a pilot group of local authorities (~17) with the potential for all statutory safeguarding authorities in England. Learning from the project is also assisting DfE’s wider work on improving case management, data flows and data quality overheads in the sector.

From the D2I API solution:

• Our API solution is flexible and developing alongside the needs of local authorities to provide the broadest possible plug-and-play capabilities. Varied tech-stacks has being catalyst being able to offer alternatives; working with local authorities to deploya PowerShell version, a flattened Python version for Fabric and a modular (CLI)Python based approach of the API tooling.
• The solution as provided can be locally modified
• We have done time-cost investigations to ensure that both the SSD and the API solution has an optimised|minifiedfootprint(+run time to avoid conflict with existing overnight processes).
• Initial deployment/testing can actually be achieved by colleagues using only Analyst level permissions (obviously with prior agreement regarding script running/DPO/Info-Sec) to provide truly rapid early testing and data signposting, without the need to immediately deploy on-server.

Recap from stand-alone SSD (2024/25 submission):

• The SSD’s middleware concept ensures it can be implemented on top of existing CMS systems without requiring significant changes. This makes it easy for local authorities to adopt the SSD, and gain highly refined/LA focused access to existing data.
• The SSD’s link table towards connecting additional data sources (e.g., Single Unique Identifier(SUI), NHS Number, UPN)ensures that it can evolve both as local authorities expand their cross-data-source capabilities, or to maximise available data in more connected LA systems where the additional data is already within accessible systems. This makes the SSD a solution with scope to grow alongside the LA/sector’s changing needs.

What are the key learning points?

1. We have used an open and cyclic feedback and development loop from the initial 4 local authorities to improve the SSD deployment and our understanding of the underlying data estates that populate it. Concurrently the API solution has, through LA observations and efforts, been improved (both at a granular level but also identifying alternative needs such as the flattened API version for Fabric as a deployment alternative).
2. The varied data teams within each of the initial pilot local authorities have given us a much improved on-the-ground perspective of such as restrictions/constraints, ways of working, varied tech-stacks, data team sizes and local knowledge.
3. The input from 4 initial local authorities during the API design process has been instrumental in shaping and testing the API solution, but also further data testing on the SSD. This has enabled us to now roll out to a further 13 local authorities Jan-Sept2026.
4. The project has and continues to enable learning for all stakeholders, not least the DfE. For the DfE this project has provided a unique, and again sector first view of both on the ground LA constraints, raw insights of LA data teams’ overheads in data management and varied tech-stacks and of course how sending raw, no-intervention data direct comes with new insights regarding low-level (often manual) data overheads of statutory returns.
5. The SSD’s ability to integrate non-CMS data sources, positions it as a long-term solution for safeguarding data management. Such flexibility will allow the dataset to evolve alongside local authority needs, making it a scalable and future-robust tool. The project’s script driven internal-workings is the realisation of more than just proof-of-concept scaled change management for some areas of the project. With some of the CMS systems, there remains a complex set of problems to address before this scaled change management is realised for all, and we’re working on those.
6. The SSD has been developed to fit into most local authorities refresh processes, with a low runtime-cost overhead and footprint (typically 12mins+500MB footprint for LiquidLogic/SystemC). Or, with an adapted implementation method with suchas the East Sussex team towards live reporting. Which when combined with integration into their Tableau workflow, highlights potential for exciting further work and ability to potentially pivot the project into real-time dashboard reporting, streamlining data processes and reducing reliance on more static/manual data manipulation(e.g. Excel) by harnessing recent tools(e.g.PowerBI).
7. In both the SSD and the API solution, we’re learning directly from local authority colleagues about how best to centrally manage the continuous change integration process to enable future development and deployment. This becomes particularly complex across the multiple CMS systems combined with a multi-stream API solution into varied local authority tech-stacks/teams. We’re utilising a self-contained Github code distribution model that effectively enables both multi-team concurrent development, version control, support/ticket logging, open access and complete oversight for all local authority deployment teams. With what we currently know, this is working but we’re reflecting and learning from these decisions as we scale up and collaborate with increasing numbers of colleagues on this.
8. We’re also expecting learning points that we(as D2I) won’t ever have direct sight of(data moving only LA to DfE, not D2I).For those within the pilot data benchmarking, and between the individual local authority and the DfE’s QA dashboard, ‘what does my raw data look like against the DfE validators’ will be a topic for discussion. The existing returns process being rarely an ideal nor simple one; the raw pipeline is likely going to highlight and invite a potentially disruptive and uncomfortable further shift in data standards culture within the sector.