A talk I presented in May 2026 to the NHS DPSP team.

Original Deck: docs.google.com

Extracted via: github.com/olizilla/slides-out

Published: 2026-05-28

Our digital NHS health records are routinely degraded when a GP or Hospital Trust migrates from one EPR to another. "We couldn't map that" gets coded as:

[XaLGM] - Transfer - degraded record entry

In some cases the data is lost altogether. So I'm piecing together how we went from manila "Lloyd George" envelopes of paper records with a standard format, clear legal ownership, and a default 30-year retention policy to this.

Data in the abstract is conceptually slippery, so let's go over the ground rules:

1. You can't "own" data - in 1976 a Liverpool University student stole an exam paper that he intended to return without being detected. He was detected. The court ruled that "Information is not intangible property". Facts are not property. They can't be stolen or damaged.
2. You can "own" a physical expression of data, like a doctors note. Copyright law lives here.

Just from point 1 we can already see where this is going. If no one owns the data like property, then there is no criminal defacement when my medical records are degraded or lost. Even if there was, they have always been owned by the GP or Trust who created them. Unfortunately, you remain free to deface your own property.

When we had an envelope of paper medical records, we had a physical expression of data.

Now we have something much more diffuse.

• The EPR provider, e.g. Oracle Health owns the Copyright of the database schema - the shape of the data
• The NHS Trust owns the collection of records under Sui Generis Database rights

Then at the level of a single row in the database:

• The NHS Trust owns the copyright for free text "doctors notes" in a given row
• Other observation data or "facts" are unowned.

What obligations does the NHS have to the data? What rights do you have?

• The NHS is the Data controller.
• It is required under data protection laws to maintain accurate and complete records, though systemic transitions often challenge this duty.

Future work

Some questions that are rattling around my head:

What if the NHS was a Data Trust?

What if health records were co-created & co-owned by patient and clinician?

Privacy as a rivalrous good? If you reveal my data, you remove my ability to reveal it rivalrous digital assets can be recognised as property.

The Department of Health owned the Lloyd George envelope!

the State provided the stationery, the doctor provided the ink and was guardian of the record until the patient died, at which point the stationery became the property of the State again. https://medconfidential.org/wp-content/uploads/2015/02/2015-02-16-A-modern-Lloyd-George-Envelope.pdf

Readme: A Blueprint for a Co-Produced Personal Health Record (CoPHR) - by the Apperta Foundation

The NHS "owns" the Canonical Data Model (CDM), the interface to the Federated Data Platform that all existing systems are to integrate with and that new systems should build on. This is what the CDM interface looks like today.

It's good that we own the CDM. But this is autogenerated from Palantir tooling. A key plank of the "we're not getting locked in" argument is that another provider could implement this interface. It's technically true, but what does it really mean to "own" a custom interface to proprietary platform?

We're on pay-as-you-go access to Foundry. Each trust gets access to it's own isolated cloud env. A data collection agent runs inside the trust and copies data to their Foundry account. The data transforms and dashboards that we build in there are only available as long we keep paying the bill.

The project could well fail like many before it thanks to the quiet resistance of staff who reject it. Or it succeeds and creates a difficult to unpick dependency and a new monopoly provider of access to NHS information. Much of the value of this massive integration work will accrue in Foundry, and it will be hard to move it to a competitor.

We can assume that it provides some appealing tooling for the price tag. Can we get some of the benefit and push back on the lock in? What are our options?

• Build and open implementation of the CDM API?
  It's unattractive but we need provide an alternative target to write to, and have place to iterate on that API.

• Capture work done in Foundry in portable formats where possible?
  E.g. use PySpark and SQL where you can. This will remove some of the benefits of the tooling, and for no-code pipeline and dashboard builders is likely not be possible, but it's worth defining the features that create more lock in.

• Burn it all? Build one to throw away? Is this just a test run to figure out what we really need?

What do you think? We need some work here fast.

Scotland is building their own National Digital Platform and building on OpenEHR which looks much more appealing as a strategy from where we are.

Original thread on Bluesky: https://bsky.app/profile/oli.zilla.org.uk/post/3m6zfgerb3k2i

Sources

Dunscombe, R. (2025). Maximising the impact of the NHS Federated Data Platform. Public Policy Project. https://publicpolicyprojects.com/wp-content/uploads/2025/09/PPP_DDT-RT2-Report_06_25.pdf

NHS England » Contract explainer. Retrieved 5 December 2025, from https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/security-privacy/contract-explainer/

Federated Data Platform and Associated Services—Contracts Finder. (n.d.). Retrieved 5 December 2025, from https://www.contractsfinder.service.gov.uk/Notice/0f8a65b5-23a2-4294-abb1-a7fd8efb3ad0

GS1 UK (Director). (2025, June 4). Ming Tang | Defining the technology strategy for a digital first health system [Video recording]. https://www.youtube.com/watch?v=E-moLtLdLJA

Kerasidou, A., & Kerasidou, C. (Xaroula). (2023). Data-driven research and healthcare: Public trust, data governance and the NHS. BMC Medical Ethics, 24(1), 51. https://doi.org/10.1186/s12910-023-00922-z

Lovell, T. (2025, May 19). NHSE quizzed on the link between single patient record and FDP. Digital Health. https://www.digitalhealth.net/2025/05/nhse-quizzed-on-the-link-between-single-patient-record-and-fdp/

Moss, B. (2025, February 26). Chief Data and Analytical Officer Network position on the Federated Data Platform (FDP). AphA - Association of Professional Healthcare Analysts. https://www.aphanalysts.org/cdao-network-news/chief-data-and-analytical-officer-network-position-on-the-federated-data-platform-fdp/

Palantir Foundry. (n.d.). Palantir. Retrieved 2 December 2025, from https://www.palantir.com/platforms/foundry/

So you wanna procure some software? A firms oft stated goal is to maximise profit. The lesser spoken goal is to control its environment, to reduce risk, to persist (Galbraith). Your needs are considered in so far as they can be profitably engaged. Profit is deployed to eliminate uncertainty.

Yes, some people within firms really do want to deliver value to customers. They are typically deployed towards the front. You get to talk to them. Their empathy weaponised by nothing more malevolent than individuals preferring roles that resonate with them. Relationships with these specific trustworthy individuals only gets you so far. They leave. Or they stay while the firm does things they disagree with, but lack the control to prevent. (Co-operatives help here, an open standard for corporate behaviour.)

Once you sign the contract your needs are a cost to be managed. In the case of Electronic Patient Record systems used in the NHS, this becomes more obvious towards the end of a 10 year contract cycle when the clamour from the actual users to improve the app tips the threshold and a new system is courted. The decade of existing data must be migrated. Per the terms of the contact a file is handed over. It's multiple spreadsheets with no data linking. It both fulfils the contract obligation and is unusable.

Yet another difficult choice falls on the Trust. Do we pay to do the one off complicated task of trying to salvage meaning from the export? Do we give up and pay to keep the old system available as a legacy store? No. Neither. There is no more money for this. The migration does not happen. The history is lost but the warnings were there. The 10 year old existing system has no records from before it was launched either. The cycle repeats.

Bombastic? Yes. Based on multiple actual events? Also yes.

You are never more powerful than the moment before you sign the contract. Take a moment. Wield the curious power of procurement. Look for firms that explicitly constrain their future behaviour, by demonstrably committing to building on open standards (like a ships mast to Odysseus, for the Greeking Out crew).

Open standards offer a place to convert the energy of competition into useful collaboration. They are where difficult conversations about how things should work, happen. Haggling and consensus building. They can feel like a burden to the participants. They should! The alternative is each product imposes its incompatible opinions directly on the users rather than working through the trade-offs with competitors first.

At the very least the you want every contact point between a public entity like the NHS and the private market of software providers to be extremely well defined. We may tolerate that the firms take the profits but the public must claim and share the intangible value it pays for. Do not give away both.

All data generated from a public investment should be held safely in public benefit, in perpetuity. Before we even get to secondary uses, records about us, co-created with us, must remain legible for us, regardless of which tech company currently holds the contract. Heck, all software paid for by public money should be open source by default, but we're on a journey.

Our physical paper medical records were slow to search and difficult to share but we didn't periodically bin them. We now have the worst of both worlds. Our new digital systems are still slow to search and without a shared standard for what the "not paper" format actually is, they can be impossible to share.

At it's most dysfunctional we've swapped a Lloyd George envelope of notes and sharing at the speed of the postal system, for clinicians remotely operating other clinicians over a weekly MS Teams call to plug numbers into incompatible systems to bridge gaps in trust at unintentional system boundaries.

An open standard for medical records gives us a foothold. A place to build from. It is hard to get them off the ground, and good ones, like openEHR and FHIR should be cherished and supported. That means showing up. Visibly participating and financially sponsoring, no strings attached.

As a "rules of engagement that allow diverse and heterogeneous actors to interact constructively over prolonged timespans" (Ferraro et al.), the open standards process offers a path forwards, a "robust action" to a complex, uncertain problem, rather than a prisoners dilemma to overcome. We do not have to wait for everyone to be convinced. Each system built on open standards by people willing to negotiate and trade some implementation freedom for coherent, reusable, interoperable output is a win.

An essay for the IIPP Innovation and Public Purpose MPA: Digital Transformation module.

The ask was to "Write an extended policy memo to your head of government explaining the risks and opportunities associated with adopting the X-Road for your country."

That felt like the cart leading the horse, so I framed the memo around "Demonstrating progress on interoperability" reducing the time-tax of government services on users. Leadership should focus on defining desired outcomes rather than dictating the implementation.

My aim is to indulge the interest in X-Road, but position our current national focus on public APIs as the way to get the benefits of X-Road without the disruption. Combining it with open logging and auth standards gives us a way to demonstrate progress quickly, and preserves flexibility to change our minds later.

Acknowledgments

Specific thanks go to Petteri Kivimäki, CTO of NIIS, who fielded my questions in the X-Road Community Slack, and whose extensive and open blogging about X-Road and clarity on what it does and does not do has been extremely helpful in forming this memo.

I acknowledge a fascinating conversation with Google's Gemini LLM chatbot about X-Road and delegated auth strategies that brought RFC 8693 for OAuth 2.0 Token Exchange to my attention. I assert that all the writing and summarising here is my own. No generated content has been included in this work.

Demonstrating progress on interoperability

To: Rt Hon Sir Keir Starmer
From: Chief Digital Advisor

Per the blueprint we must demonstrate progress on interoperability and reducing the time-tax of government services on users.

I propose creating a dashboard to show reductions in this time-tax, focusing on API utilisation and performance, as well as reductions in service complexity tracking total questions asked to achieve an outcome, percentage of questions that can be pre-filled thanks to interoperable APIs, and tracking the failure cost for each service in terms of time spent resolving issues via our call-centres and online help to ensure progress is not at the cost of leaving some behind.

To get there we will need every department to present their service as an API with clear metrics on usage and performance, and a technology foundation that catalyses cross-department data sharing in a safe and legible way.

X-road has pedigree here, but there are significant challenges to adopting it in the UK given our existing platforms, discussed in option 1.

I recommend continuing with our current strategy: building public APIs on open standards, along with the adoption of key learnings from X-Road, as discussed in option 2.

Option 1: X-Road

X-Roads responsibilities are authentication: asserting which departments may access data from which others; and logging: recording all data that passes between systems. It can lift bureaucratic concerns out from the implementation details of APIs, making legible "who has access to what", and ensuring consistent records of that access are kept.

Overview: How X-Road works today

Every department that has data to offer (provider) or needs data from another (consumer) must run a "Security Server" to represent them on the X-Road network. A data provider's Security Server implements authentication by defining which other Security Servers on the network may request data from it.

Membership of the network is controlled by the X-Road Central Server. A Security Server and hence the department (or business) it represents may only participate if blessed by the Central Server.

A request for data is sent from the consumer system to its local Security Server and is relayed on to the providers Security Server. If the request is from a department that the provider allows, then the request is relayed on to the providers API which then sends a response back through both Security Servers. The request and response may be logged in both Security Servers.

Key points

• All data transferred over X-Road is proxied through 2 Security Servers and logged at each.
• Access control is per department not per user.
• API consumers must run X-Road software or have that service provided to them.

Context: A product of its time

X-Road was started in 2001 when Estonia had few APIs and many data silos.

Also in 2001 Java became the most popular programming language (X-Road is written in Java), and auto-generating "Simple Object Access Protocol" (SOAP) APIs from your existing codebase was a hot topic in that ecosystem. Enterprise developers were not used to thinking in terms of public APIs. Generating the interface from the code they had already saved expensive developer time.

In 2002 X-Road adopted SOAP as it's API standard. To add an information system to an X-Road network it had to expose a SOAP API. In return, X-Road would handle the request logging and authentication logic, essential functions that are critical to get right.

Where you had no APIs previously, there was now a clear path where each data silo only needed to generate a rudimentary SOAP interface, and have X-Road take on cross-cutting, high stakes issues around trust, access control, and observability.

But SOAP lost the API race. Everything is HTTP and REST now. In 2019 X-road added support for proxying RESTas well as SOAP interfaces. It does not translate between the two. You must guide your many data providers to standardise on one. If left unmanaged you have two parallel networks with no interoperability between systems expecting to talk SOAP and those expecting HTTP.

Where it's heading: Standardisation

X-Road is under active development by Nordic Institute of Interoperability Solutions (NIIS), a partnership between Estonia and Finland. It was published as open source and moved to a compatible MIT license in 2015.

To date X-Road has been developed as a product based on standards rather than a standard itself. This means there are currently no competing compatible alternatives to X-Road and NIIS has complete control over the direction of the project.

The next major release (version 8 aka "Spaceship") aims to replace X-Road's custom protocols with standardised ones from the EU Gaia-X endeavour. This will allow it to interoperate with other nation's data-exchange systems and pave the way for alternative X-Road implementations. It will also reduce the control that NIIS has over the details of the subsystems that move to standards defined by other agencies.

Benefits of adopting X-Road

In an ideal deployment X-Road is fully responsible for authentication, providing strong cryptographic guarantees that the data consuming system and the provider are both trusted, and allowed to share data.

A data provider only has to make their API available to their local Security Server and there is then a clear path for many other departments to make use of that data. Once there is a MoU between the departments, it can be codified in X-Road config, and the consumer can start working on integrating the providers data into their system.

New APIs can be developed quickly with less pressure to write bespoke access control code. The non-repudiable access logging encourages data providers to share everything, All the data is available, but consumers accessing data they should not will be evident in the logs.

Challenges to adopting X-Road in the UK today

• Multiple sources of truth for authentication logic risks data security errors.
• X-Road logs must either contain PII and auth tokens or have the non-repudiable aspect disabled.
• Data consumers required to run unfamiliar software to access APIs.

Authentication: The UK has hundreds of published APIs already. (243 under gov.uk alone.) Each API has its own authentication and authorisation flow established. If we roll out X-Road today, we would likely have to avoid using X-Roads support for the same features to ensure we retain a single source of truth. This reduces the value of one of X-Roads main features.

Alternatively we would have to devote engineering time to removing auth logic from existing APIs and replacing it with the equivalent X-Road config. This would involve significant, high skill work, with no immediate improvement to end-user experience.

Logging: X-Roads non-repudiable logs that can be used as evidence under eIDAS are another key feature. That requires full message body logging to be enabled. This means the X-Road logs will contain PII data and any authentication tokens required for the consumer to access the provider system. This makes those logs a GDPR and security risk.

This problem is common enough that X-Road makes it simple to disable message body logging, such that only the metadata of the interaction is recorded, but this also means the logs are no longer verifiable. Their primary use becomes tracking metrics as they are no longer a strong deterrent to unauthorised data access. This diminishes the value of the other key feature.

Alternatively if we require each API provider to take ownership of the Security Server such that it is deployed as part of their information system, we can avoid creating a separate PII repository. Combine that with doing the work to move all auth logic for each existing API into X-Road, and we can avoid the security hazard of logging auth tokens. But again this is nuanced work that would not deliver visible improvements to end-users.

Data consumers must run unfamiliar software: Per our API technical guidelines most of our APIs are already available directly over HTTP. This is familiar to developers and every language ecosystem has robust tooling to for that job. We want to encourage people to experiment and build on our APIs. Requiring every org that wants to consume data from our APIs to run an X-Road server is a high bar; direct access is the norm, and there are very few developers who have worked with X-Road. There is also evidence that a Security Server is not currently a lightweight process to run. 1 2

On the other hand if we limit the use of X-Road only to internal inter-government use cases then we reduce another of X-Roads key value propositions of cross-sector and cross-border federated access.

Adopting X-Road for existing APIs would be a very visible change with many stakeholders: every government department with an API and the many businesses who consume those services. It is also notable that a Security Server is not a transparent proxy. It changes the shape of the APIs it proxies, prefixing the target information system in all URL paths. Every consumer of the APIs would have to update their existing integration code too.

Option 2: Public APIs (recommended)

The purpose of an API is to be accessed by other systems. They should be designed to do that job well. This includes being very clear about who should be allowed to access the data, as well as recording access, performance, and observability metrics.

This is our current strategy, and with very little additional work we can quickly demonstrate progress on interoperability, adopting ideas from X-Road to strengthen our position on authentication and logging.

Authentication: The GOV.UK One Login service solves end-user authentication for our APIs, and conforms to well adopted standards (OpenID, OAuth). By clearly documenting auth delegation patterns we can also use it to solve system-to-system auth at a granular level by relaying the end user information between systems. It is a well documented issue and RFC 8693 Token Exchange is the standard extension to OAuth to converge on for system-to-system auth.

APIs are not freed from having to decide which users should have access to what data, and we must continue to support that work with clear guidance, training, and rules on data governance.

Logging: An API gateway is a transparent proxy that sits in front of the data providers API. Using an API gateway to manage common deployment issues is already part of our recommendations. Systems using one will already have access logs in a standard format. Those that don't already can adopt one with no impact on existing integrations. There are many open source options for aggregating logs to derive performance metrics, and the problem is well contained so we retain the flexibility to adapt how we do it in the future.

Comparison

Recommendation

• Continue to invest in GOV.UK One Login. Document delegated access patterns that work today. Work on adding RFC 8693 Token Exchange support as the standard to converge on for system-to-system auth.
• Require collection of common access logging across all APIs, either via an API Gateway or a shared logging module.
• Use the data to create a dashboard to visualise reductions in the time-tax of our services in terms of system performance metrics
  • Also include data on reductions in service complexity in terms of total questions asked per service, percentage of questions that can now be pre-filled thanks to interoperable APIs.
  • Track the failure cost for each API in terms of minutes spent resolving issues via our call-centres and online help, so we can verify that increased digitalisation is not at the cost of leaving some behind.

This will show visible progress quickly, retains the flexibility for future, and aligns well with our published digital priorities points 3, and 6:

• Strengthen and extend our digital public infrastructure: expanding GOV.UK One Login and other common components.
• Commit to transparency, drive accountability: publishing and acting more on performance data.

Sincerely,

Chief Digital Advisor

Footnotes

1. X-road is not a light: "even if the Security Server is containerized, the footprint of the Sidecar container is still relatively massive compared to the footprint of average containers." - https://www.niis.org/blog/2020/9/1/security-server-sidecar-part-3
2. X-road 8 promises a "light context" to reduce the burden on consumers : https://x-road.global/development-roadmap

Bibliography

A blueprint for modern digital government (HTML). (2025, January 21). GOV.UK. https://www.gov.uk/government/publications/a-blueprint-for-modern-digital-government/a-blueprint-for-modern-digital-government-html

API technical and data standards. (2024, July 19). GOV.UK. https://www.gov.uk/guidance/gds-api-technical-and-data-standards

Blake Jackson, E., Dreyling, R., & Pappel, I. (2021, October). A historical analysis on interoperability in Estonian data exchange architecture: perspectives from the past and for the future. In Proceedings of the 14th international conference on theory and practice of electronic governance (pp. 111-116).

Centre for Public Impact. (2024, September 18). e-Estonia, the information society since 1997 - Centre for Public Impact. https://centreforpublicimpact.org/public-impact-fundamentals/e-estonia-the-information-society-since-1997

Estonia’s X-Road: data exchange in the world’s most digital society. (n.d.). https://govinsider.asia/intl-en/article/estonias-x-road-data-exchange-in-the-worlds-most-digital-society

How GOV.UK One Login works - One Login. (n.d.). One Login. https://tech-docs.account.gov.uk/how-gov-uk-one-login-works/

Kivimäki, P. (2019a, October 28). Nordic Institute for Interoperability Solutions — Get some more REST. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2019/10/6/get-some-more-rest

Kivimäki, P. (2019b, October 29). Nordic Institute for Interoperability Solutions — X-Road Logs Explained – Part 3. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2018/6/12/x-road-logs-explained-part-3

Kivimäki, P. (2019c, October 31). Nordic Institute for Interoperability Solutions — X-Road Logs Explained – Part 1. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2018/5/27/x-road-logs-basics

Kivimäki, P. (2019d, October 31). Nordic Institute for Interoperability Solutions — X-Road Logs Explained – Part 2. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2018/6/3/x-road-logs-explained-part-2

Kivimäki, P. (2022a, January 18). Nordic Institute for Interoperability Solutions — Message Logging in X-Road 7. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2021/9/29/message-logging-in-x-road-7

Kivimäki, P. (2022b, January 18). Nordic Institute for Interoperability Solutions — Protecting Data at Rest in X-Road 7. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2021/10/2/protecting-data-at-rest-in-x-road-7

Kivimäki, P. (2022c, April 11). Nordic Institute for Interoperability Solutions — Interoperability puzzle. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2020/1/20/interoperability-puzzle

Kivimäki, P. (2025, January 8). Nordic Institute for Interoperability Solutions — X-Road Myth Busting – Part 1. Nordic Institute for Interoperability Solutions. https://www.niis.org/blog/2018/9/3/x-road-myth-busting-part-1

Manage your data for access and reuse. (2020, November 27). GOV.UK. https://www.gov.uk/guidance/manage-your-data-for-access-and-reuse

Nordic APIs. (2019, November 5). X-Road – Open source Data Exchange Layer [Video]. YouTube. https://www.youtube.com/watch?v=YWWknjpZCLs

nordic-institute. (2025, April 11). X-Road/doc/Architecture/arc-sec_x_road_security_architecture.md at develop · nordic-institute/X-Road. GitHub. https://github.com/nordic-institute/X-Road/blob/develop/doc/Architecture/arc-sec_x_road_security_architecture.md

In January 2025, GDS & DSIT published A blueprint for modern digital government, a 6 point plan for digital reform.

It's fantastic. It's also very long, and you have much to do. Here are 3 of the 33 "priority reforms" that stand out, ordered from the achievable to the transformative.

• A GOV.UK app will be rolled out this year with a digital driving license as a headline feature.
• Every department must publish an open API for their service.
• They intend to fix how the treasury funds digital projects.

If you like to skim, I've collated the list of just the 33 reforms as a separate post.

Despite it's length the blueprint is surprisingly coherent, tackling the problem from many angles. Channelling Wardley, if we begin with the publicly visible part, the GOV.UK app, and trace it's dependencies we can start to see how the reforms serve to reinforce each other.

The GOV.UK App

In the blueprints own words, the government will:

Introduce a Digital Wallet to store government credentials, and require services to issue a digital verified credential alongside any paper/card based credential or proof of entitlement eligibility by the end of 2027. — Blueprint: Point 1. Join up public sector services

...but this doesn't give the full story. The launch event video goes into more detail: the Digital Wallet will be rolled out as a feature of the new GOV.UK app. [source]. It also offers a bold statement of intent:

"We are going to transform the relationship between citizen and the state." — Rt Hon Peter Kyle MP

Why an app, why now?

The app aims to provide the visible value to us, the users. If it's useful it will give legitimacy to the other policy goals.

The justification given in the launch video is that todays' 18 year olds (newly minted voting citizens) were born in 2007, the same year the iPhone was launched (😱). It is reasonable to assume that, to them, apps are the default. It's how we do everything from banking to socialising already. And GDS doesn't assume. Point 1 of the Service Standard is "Understand users and their needs" by doing the user research.

From the private sector point of view, offering an app is the UK skating to where the puck has been sitting for the last 10 years. But there is a proper order of events to nation-scale digital transformation, and you don't get to skip web day.

A small app on a huge web platform

The solid foundations of the GOV.UK web platform is exactly why Peter Kyle can promise that the 6 month old app will be ready for public use by June this year.

The android app is a thin wrapper around the existing website; like a personalisable version of the https://gov.uk home page.

The search feature is using a gov.uk API to do the work of fetching search results. It's open source and published on github, so let's take a look.

# Be Neo and see past the code. We're going to pick some words out, nothing more. Hold on.

object SearchConfig {
    const val BASE_URL = "https://www.gov.uk"
    const val API_BASE_URL = "https://search.publishing.service.gov.uk"
    const val SEARCH_PATH = "/v0_1/search.json"

Source: github.com/alphagov/govuk-mobile-android-app

This tells us the current version of the app pulls search results from an API at:

You can click that link and try it. The response won't be pretty but it will be data that you (or an app) can use:

  "results": [{
      "title": "Sign in to your Universal Credit account",
      "link": "/sign-in-universal-credit",

The title for the first search result is "Sign in to your Universal Credit account" which is text the app will show for this search result and the link is /sign-in-universal-credit.

If you select that item, it will open the https://gov.uk/sign-in-universal-credit web page as a view in the app, just as you would see it in your mobile web browser.

There is work to do to make this feel seamless, but the point is that the app gets a huge speed boost by reusing the web platform and the Design System that allows the app builders to add new features that match the gov.uk web pages.

This saves years of work. The task is not "rebuild all 700,000 web pages as features of the app", but instead "do the work that makes apps interesting".

Just moving the gov.uk homepage into an app could have been a hard sell but following the growth-hacking, value-propositioning playbook, they are launching with a killer app exciting initial use-case: a digital drivers license. It will include an eKYC feature that will let you prove that you are, for example, old enough to buy fireworks and alcohol without having to also share the other details on your license, like the address of that party.

The alpha/beta release pattern card is ticked too! Before it's rolled out across the country, 250,000 UK Veterans will get access to the digital wallet feature to make it easier to access their veteran card and the benefits it offers. Just pause and admire that framing for a second. Honouring heros with early access and also finding a beta test group of the right scale that may also be more willing than average to report back on their early adopter experiences.

And they stick the landing, with a clear statement that it will be available by the end of 2025.

APIs Everywhere

Mandate the publication of a standard set of APIs and events by public sector organisations. Starting with an expectation that every new service in central government departments will have an open API. — Blueprint: Point 3. Strengthen and extend our digital and data public infrastructure

Apps use APIs to get things done. The gov.uk app needs departments to offer APIs so it can connect users with the service they provide. In return The app will give the new APIs an in-house customer that can provide early feedback. Meanwhile, reframing departments around open, documented APIs nudges them towards digital-first and service-first delivery. Hey, it worked for Amazon.

To calibrate how significant a change "APIs for everything" could be at this point in 2025, it's worth noting that the current Disability Living Allowance form is 40 pages long, emotionally draining, and still paper-only. There is no option to fill it out online. You have to post that physical bundle to a doctor, who may or may not post it back with their part completed, before you get to post it to the DWP and wait for at least 17 weeks for the verdict.

Digital transformation represents an opportunity to redesign government around providing services that work well for the users who need it most. The section in the blueprint that proposes a performance metric around reducing the 'time tax' of public services will hopefully focus the effort where it is most needed.

Modern digital government should reduce the 'time tax' on people using public services. Not just the time it takes to use a service, but the time to understand what needs to be done. — Blueprint: What we want to deliver

Fixing funding

...OK But what about treacherous operating conditions for running digital projects in a government setting?

Just last week Mike Bracken reminded us that HM Treasury's process still strongly favours large up-front capital expense projects with a 3 to 5 year plan they can do the cost-benefit analysis on, and is completely at odds with the need to quickly spin up small teams for test-and-learn digital projects that may last months, or if successful, require on-going revenue funding.

This mismatch either kills agile projects before they start or forces them to role-play a waterfall project and pretend they can predict what they will need in 3 years time before they've even started talking to users.

They want to fix that too!

The digital centre will work with HM Treasury to reform the government's funding approach...

Launch tailored funding models for digital products and services, legacy remediation and risk reduction, and staged, agile funding that better enables exploratory work with new technologies. — Blueprint: Point 5. Fund for outcomes, procure for growth and innovation

And more...

The promise of 'digital ready' legislation, a line about trialing a new unique identifier on children that would benefit from more context …there really is something for everyone. I encourage you to give the blueprint a read.

Thoughts? Hurl them at @oli.zilla.org.uk on bluesky

For those that like their data dense, this is all 33 priority reforms scraped from the GDS & DSIT blueprint for modern digital government.

1. Introduce a Digital Wallet to store government credentials, and require services to issue a digital verified credential alongside any paper/card based credential or proof of entitlement eligibility by the end of 2027.
2. Establish a ‘once only’ rule, so that if people have provided information to one service, it can be reused by others with appropriate safeguards. It will start with central government services and commonly reused data, but be designed to scale over time to the broader public sector and more information.
3. Work towards all legislation being ‘digital ready’ to reduce complexities in service delivery and improve efficiencies, drawing on Denmark’s approach.
4. Stand up a new Service Transformation Team to look at whole public sector service transformation and the improvement of priority services, accelerating delivery of the Plan for Change.
5. Save money and effort by streamlining the procurement and provision of devices and tools – and cloud and compute resources in the future – and enabling public servants to work easily across organisations and at different security levels.
6. Build on the work of the Incubator for AI (i.AI) to provide rapid prototyping and innovation, identifying and buying or building solutions focused on public sector productivity including customer service, casework, prevention and policy work, working with other departments and public bodies who will continue to deliver the majority of AI solutions.
7. Offer specialist assurance support, including a service to rigorously test models and products before release. 
8. Create an external Responsible AI Advisory Panel and a dedicated in-house team. The Panel will bring together expert insight from the public sector (including frontline workers), industry, academia and civil society groups to provide constructive challenge and advice, and shape standards based on best practice. 
9. Build and regularly convene AI and data communities of practice across the public sector, to further shape our response to fast growing technology, and support practitioners across government by providing expert advice on AI and reusable technical solutions.
10. Build up a strong technical market intelligence capability to inform procurement and design decisions, recognising that AI and its uses are evolving rapidly.
11. Develop a sourcing and procurement framework for AI, including rapid procurement and mission-focused national tenders.
12. Create the National Data Library, making it easier to find and reuse data across public sector organisations; this supports better prevention, intervention and detection, and opens up data to industry, the voluntary sector, start-ups and academics to accelerate AI-driven innovation and boost growth.
13. Introduce a Digital Backbone: the integration, orchestration and instrumentation technology needed to share capabilities and build true end-to-end journeys, such as exposing, creating, processing and maintaining APIs across the public sector. We intend to open up the Backbone for industry to publish services and products for use across the public sector, providing a streamlined way to consume services from the market.
14. Mandate the publication of a standard set of APIs and events by public sector organisations. Starting with an expectation that every new service in central government departments will have an open API. 
15. Develop and implement a more interventionist model for cyber security and technical resilience, acting as one to tackle severe and systemic risks, and help prioritise and identify the required funding for remediation, including legacy technology.
16. Deploy a new vulnerability scanning service for the public sector, to detect weaknesses and take preventative action on them.
17. Set up a Technical Design Council led by expert technology, data and AI practitioners, to tackle the toughest and most strategic technical decisions with the needs of the whole sector in mind.
18. Develop and assess the optimum employment models to attract, grow and mobilise expert digital talent.
19. Assess the overall package for digital and data professionals, including remuneration, with a view to ensuring our offer is competitive within the market, making the UK public sector an attractive and viable place for digital specialists.
20. Work with the Government Property Agency to establish a Digital Hub in Manchester, building on its already thriving tech sector and a number of existing public sector digital teams in the city.
21. Require that all public sector organisations have a digital leader on their executive committee and a digital non-executive director on their board by 2026 at the latest and publish this information publicly.
22. Establish a dotted reporting line to the Government Chief Digital Officer (GCDO) for all CDIOs in central government, including input into recruitment decisions, coaching support and feedback on performance.
23. Raise the status of the GCDO role to Second Permanent Secretary-level.
24. Launch tailored funding models for digital products and services, legacy remediation and risk reduction, and staged, agile funding that better enables exploratory work with new technologies.
25. Expand use of performance-based, outcomes-focused funding models that tie funding to metrics and accelerate the shift from ‘boom and bust’ transformation programmes to continuous funding of persistent, multidisciplinary product teams. 
26. Define a comprehensive sourcing strategy for what we build, what we buy and how we partner, helping to drive greater efficiency across the £26 billion the UK government spends annually on digital technology.
27. Launch work on a Digital Commercial Centre of Excellence to identify opportunities for further reform and improvements needed to enable tech startups, scaleups and SMEs to access government contracts.
28. Empower public servants to work in the open to improve our services and build public trust. This means giving hard-working teams credit for their achievements, while being open about the challenges and learning in public from each other and from the wider world.
29. Create an inventory of services to measure the progress of service modernisation and publish a version of this in the open.
30. Set an expectation that all central government departments publish their public-facing product roadmaps at least annually and talk about what services they’re working on and why. Encourage other public sector organisations to do the same.
31. Co-develop a methodology for measuring the administrative burden including the ‘time tax’ government places on people, and track progress on reducing it, involving civil society groups in the design.
32. Require departments to publish metrics at least annually on the outcomes they achieve, including service performance, value for money, resilience, digital inclusion and AI adoption.
33. Hold Secretaries of State accountable for their department’s performance against these measures, including through regular reviews with the Digital Inter-Ministerial Group (annually for the largest operational departments).

Method

I scraped and transformed the nicely structured HTML from https://www.gov.uk/government/publications/a-blueprint-for-modern-digital-government/a-blueprint-for-modern-digital-government-html by running the following in the browser console on that page

$$('[id^=priority-reforms]').map(x => {
  const url = `${window.location}#${x.id}`
  const items = document.querySelectorAll(`[id=${x.id}]~ul li`)
  return [...items].map(i => `<li><a href=${url}>${i.innerHTML}</a></li>`).join('')
}).join('')

and pasting the output into an <ol>

What's next

When I get time I'll turn this into a dashboard where we can track the progress on each one.

If it gives you other ideas let me know at https://bsky.app/profile/olizilla.bsky.social