In my earlier posts, I described what federated learning is and reflected on how mission-oriented innovation thinking might apply to this context. Now, a few months into the work, I want to think through what FL would actually require in practice - and why I'm increasingly concerned that the question itself may be premature.
Working Backwards
The standard way to approach a technology implementation is to start with the technology and work forward: what can FL do, and how might we apply it?
But after several months of trying to understand the Swedish vocational rehabilitation context, I've found it more useful to work backwards: what would FL require, and do those requirements exist?
This reversal is clarifying. It's helping me see what might be a gap between the technological imaginary and the material conditions I'm encountering.
The Pyramid of Requirements
FL sits at the apex of a pyramid of requirements. Each layer presupposes the ones below it.
Layer 1: Data That Exists
Before any analysis can happen, there must be data to analyse. This sounds obvious, but it's worth being explicit about what this means in vocational rehabilitation:
What data? Outcome data for rehabilitation is inherently difficult. When someone moves from welfare services to employment, the "outcome" is distributed across time (did they stay employed?), across definitions (what counts as success?), and across jurisdictions (different agencies hold different pieces).
Who collects it? In Sweden, vocational rehabilitation involves coordination between the Employment Service (Arbetsförmedlingen), the Social Insurance Agency (Försäkringskassan), regional health services, and municipal social services. Each has their own data systems, their own definitions, their own purposes for data collection.
In what format? Even where data exists, it exists in forms shaped by administrative purposes, not analytical ones. Case notes. Eligibility determinations. Service delivery records. These are not straightforwardly convertible into training data for ML.
Layer 2: Data Infrastructure
Having data is not the same as having data infrastructure - systems that can capture, store, process, and make data available for analysis.
Storage and access: Where does the data live? Who can access it? Through what interfaces?
Processing capability: Can the data be queried, transformed, and prepared for ML workflows?
Integration: For FL specifically, each federated node needs infrastructure capable of running local training and communicating with a central aggregator.
Layer 3: Technical Capacity
Infrastructure without people who can operate it is inert.
ML expertise: Someone must understand how to prepare data, train models, evaluate performance, and iterate.
Systems expertise: FL systems require deployment, monitoring, debugging.
Integration expertise: Connecting ML systems with operational workflows requires understanding both domains.
Layer 4: Governance Frameworks
Technical possibility is constrained by legal and institutional frameworks.
Legal basis: GDPR and Swedish law govern how personal data can be processed. What lawful basis exists for using rehabilitation data for ML training?
Organisational agreements: FL requires multiple parties to agree not just to participate, but to align their technical systems, synchronise their processes, and trust the federated model.
Ethics review: Research involving personal data, especially sensitive welfare data, requires ethical scrutiny.
Layer 5: Organisational Readiness
Even with everything above in place, organisations must be ready to absorb ML into their operations.
Leadership understanding: Decision-makers must grasp what ML can and cannot do, and commit resources accordingly.
Professional acceptance: Caseworkers and other staff must see value in ML-supported tools and integrate them into practice.
Change management: New tools change workflows. Someone must manage that transition.
Greenhalgh's NASSS framework identifies precisely these multiple domains of complexity - technology, value proposition, adopter system, organisation, wider system, embedding, and adaptation over time - that determine whether health technologies get adopted or abandoned (Greenhalgh, 2018). Her research concludes that "the overarching reason why technology projects in health and social care fail is multiple kinds of complexity occurring across multiple domains" (Greenhalgh, 2018, p. 4). FL multiplies this complexity across federated partners.
Layer 6: Federated Learning
Only now, with all the preceding layers in place, does FL become a coherent option. FL is the answer to a specific question: given that multiple parties have ML-ready data infrastructure, governance frameworks, and technical capacity, how can they collaborate on a shared model without pooling raw data?
If the earlier layers don't exist, does FL still make sense? It seems to be a solution to a specific problem - one that assumes you've already solved the more basic ones.
The Deflationary Move
This analysis leads to a deflationary realisation: before FL, you would need basic data science. And before basic data science, you would need data infrastructure. And before data infrastructure, you would need data.
Consider what would be required to do even the simplest data analysis on vocational rehabilitation in the Swedish context:
- A computer with analytical software
- Data in a format that software can process
- Someone who knows how to use that software
- A question worth answering with data
- Permission to access and use the data
- A way to share findings with people who could act on them
This is not FL. This is spreadsheet-level work. And in my conversations so far, I'm finding that even this is not straightforwardly achievable in the organisations I'm working with.
Why Was FL Proposed?
If FL requires so much groundwork, I'm trying to understand why it was proposed for this context. I don't think anyone was being dishonest. But I'm curious about the dynamics that led here.
The innovation imperative: A PhD requires novelty. "Exploring basic data practices in Swedish welfare services" is less compelling - less fundable, less publishable - than "Exploring federated learning for vocational rehabilitation". I wonder whether academic-practitioner partnerships can create pressure to promise more than contexts can deliver.
The privacy solution: The privacy problem in welfare data is real. FL appears to solve it elegantly - you can collaborate without sharing sensitive data. This makes FL appealing in the abstract. But did anyone examine the concrete requirements?
The transferability assumption: The UK research group had a working algorithm - the Pathway Generator, trained on Icelandic data. FL seemed to offer a way to "transfer" this to Sweden without recreating the entire data pipeline from scratch. Greenhalgh and Robert (2004) emphasise that successful technology transfer requires careful attention to how knowledge and practices can be adapted from one context to another. I'm starting to wonder whether the assumption was that advanced technology transcends local conditions - when actually, context shapes everything.
Distance from implementation: From a UK university, "Swedish vocational rehabilitation" is an abstraction. It's easy to imagine that somewhere in that abstraction, the necessary conditions exist. Being here, on the ground, forces specificity.
A Pattern I'm Noticing
There's something I'm trying to articulate here - a pattern where advanced technological solutions get proposed as a way of avoiding confrontation with more fundamental problems.
If you don't have data, the problem is organisational, political, and practical: how do you get people to collect useful information, in useful formats, and make it available for analysis? This is hard, slow work involving many stakeholders with competing interests.
FL seems to promise a way around this. It offers collaboration across boundaries without the messy work of actually building shared data infrastructure. The algorithm will come to the data, wherever it is.
Wastell, writing about public sector technology projects, warns against treating technology as a magic bullet. He argues that doing design well "depends on our attitude to technology. A magical attitude will not do. Hard work is required and authentic engagement" (Wastell, 2011, p. 3). I'm wondering whether the appeal of FL in this context might be precisely this kind of magic - a promise to solve problems without addressing their foundations.
But FL cannot conjure data into existence. It cannot create infrastructure. It cannot resolve governance questions. It cannot build technical capacity. It cannot make organisations ready for ML.
I'm starting to think that proposing advanced solutions might sometimes be a way of avoiding the harder, slower work of building basic capabilities. But I'm still working this out.
Alternative Framings
I should note that there are more charitable interpretations of how this project was conceived.
Aspirational framing: Perhaps the project was always understood as exploratory - a way to investigate what would be needed, rather than a commitment to deliver FL immediately. The PhD could be preparatory work for future implementation.
Catalytic function: Sometimes ambitious technology proposals serve to catalyse conversations and build relationships, even if the specific technology doesn't materialise. The collaboration itself may have value beyond its stated deliverables.
Learning through doing: One way to discover what's missing is to attempt implementation. The "failure" to implement FL could be reframed as successful discovery of preconditions.
These framings aren't wrong, exactly. But they sit uneasily with the job description I was hired against, which specifies concrete deliverables around FL and AI-assisted decision tools. There's a gap between exploratory framing and the promises that secured funding and created positions.
What Now?
This leaves my PhD in an awkward position. I was hired to explore FL for rehabilitation. I'm finding that FL is several layers removed from what's actually achievable.
The honest question is whether any data science is possible in this context. And the honest answer, so far, is: I don't know yet. The preconditions may not exist.
What I can do is:
- Map what actually exists (data, infrastructure, capacity, governance)
- Identify the gaps between current state and ML-readiness
- Surface these findings with the stakeholders involved
- Contribute to understanding why there's a gap between the technological imaginary and material conditions
This might not look like FL research. But it might be more useful than pretending the conditions for FL exist when they don't.
References
Greenhalgh, T. (2018). How To Improve Success Of Technology Projects In Health And Social Care. Public Health Research & Practice, 28(3), e2831815.
Greenhalgh, T. and Robert, G. (2004). Diffusion of Innovations in Service Organizations: Systematic Review and Recommendations. Milbank Quarterly, 82(4), 581-629.
Wastell, D. (2011). Managers as Designers in the Public Services: Beyond Technomagic. Triarchy Press.