I've recently started a research position exploring machine learning and design for Swedish vocational rehabilitation services - specifically, the possibility of using federated learning to support decision-making for people navigating the welfare system back towards work or education.
This post gathers my early reading on federated learning as a technology. As I go deeper into the fieldwork, I'll need to understand what implementing FL would actually require, and whether those conditions exist in the context I've entered.
What is Federated Learning?
Federated learning emerged from Google's work on mobile device prediction, addressing a specific problem: how do you train machine learning models on data that can't (or shouldn't) be centralised?
The foundational idea is architectural. Rather than bringing data to the model (the traditional approach), FL brings the model to the data. Each participant - a phone, a hospital, an organisation - trains a local model on their local data, then shares only the model updates (not the underlying data) with a central server that aggregates them.
This creates a federated system: multiple parties collaborating on a shared model while retaining control of their own data.
The Promise
Yang et al. describe FL as emerging from concerns over "data fragmentation, data silos, user privacy leakage, and data shortage problems" (Yang et al., 2019, p. 6). The technology promises to address a fundamental tension: how can organisations collaborate on data-intensive problems without surrendering control of sensitive information?
The values embedded in FL discourse are telling: collaboration and data sharing, while simultaneously preserving privacy and autonomy. FL appears to resolve a tension that has blocked data-intensive work in sensitive contexts - particularly healthcare and welfare services, where data about individuals is distributed across institutions with legitimate reasons not to share it.
Yang et al. suggest that FL "allows multiple parties to hold their own data privately while building a machine learning model collaboratively and securely" (Yang et al., 2019, p. 6). For healthcare contexts, they argue FL provides "excellent technical support" for overcoming data silos while maintaining privacy protections.
This is the imaginative space FL occupies: a technology that transcends the collaboration/privacy trade-off, enabling organisations to work together on problems that require distributed data without anyone surrendering control.
How FL Entered This Story
I should explain how I came to be researching federated learning for Swedish vocational rehabilitation.
The position I've taken connects a Swedish coordination association (samordningsförbund) with Linköping University and a research group at a UK university. The UK team had developed what they call the "Pathway Generator" - an algorithm trained on Icelandic data to predict favourable rehabilitation pathways for individuals with complex needs.
Someone in this constellation suggested that federated learning might allow the Swedish organisations to benefit from the algorithm without sharing sensitive individual data. The consortium found this compelling. A PhD position was created.
The job description I applied for states that the tool "uses machine learning and artificial intelligence to make predictions about the most favourable choices along the way, based on historical data". It requires candidates to have "good understanding of federated learning" alongside design expertise.
This pattern - where technology proposals emerge from academic contexts at some remove from implementation sites - is worth noting. I'm curious whether the gap between where ideas are generated and where they must be implemented creates space for proposals that may not survive contact with local conditions.
I'm a designer with some technical background. I was attracted to the interesting juxtaposition of design methods with emerging ML techniques, and the chance to work on public services that genuinely matter.
What FL Actually Requires
Reading the technical literature, what strikes me is how much FL presupposes.
Yang et al. note the disciplinary breadth required:
"To develop a federated learning system, multiple disciplines are needed, including ML algorithms, distributed machine learning, cryptography and security, privacy-preserving data mining, game theory and economic principles, incentive mechanism design, laws and regulatory requirements, etc. It is a daunting task for someone to be well-versed in so many diverse disciplines". (Yang et al., 2019, p. 2)
FL doesn't simplify the machine learning problem - it adds layers. Beyond the already-demanding requirements of building any ML system (data, labelling, training infrastructure, evaluation, deployment), FL adds communication challenges, temporal coordination requirements, and context-specific adaptations.
The Category Problem
I'm starting to wonder whether FL might be a category error in this context. Reading the literature, it seems like FL is not an alternative to having data infrastructure - it's a way of connecting data infrastructures that already exist.
If organisation A and organisation B both have:
- Databases capturing relevant information
- Technical systems capable of running ML training
- Data in formats that can be processed algorithmically
- Governance frameworks allowing this use
- Staff who understand what they're participating in
...then FL provides a method for them to collaborate without pooling their raw data.
But what if these preconditions don't exist? If there's no database, no training infrastructure, no standardised data, no governance framework, no technical capacity - can FL still be a solution? I don't know yet. This is what I need to find out through the fieldwork.
This relates to what Nieusma, writing about technology transfer more broadly, describes as the importance of recognising that context suitability should be central to technology design and deployment (Nieusma, 2004). Technologies developed in one context don't automatically transfer to another. The conditions that made something work there may not exist here.
Questions I'm Taking Into the Field
As I begin this research, I'm carrying questions that the FL literature doesn't answer:
- What data actually exists in Swedish vocational rehabilitation contexts?
- Who collects it, in what formats, for what purposes?
- What would "outcome data" even mean for people navigating welfare services toward employment?
- What technical infrastructure exists in the organisations involved?
- What governance frameworks would enable (or prevent) this kind of data use?
- What do different stakeholders think "data science for rehabilitation" means?
The literature on FL is extensive and technically sophisticated. But I'm realising I need to understand the local context before I can assess whether any of this applies. Before asking "how could FL work here?", I need to understand what data infrastructure actually exists in the organisations I'll be working with.
References
Nieusma, D. (2004). Alternative Design Scholarship: Working Toward Appropriate Design. Design Issues, 20(3), 13-24.
Yang, Q., Liu, Y., Chen, T., Cheng, Y. and Zhang, H. (2019). Federated Learning. Morgan & Claypool.