Topic 4.1 — Platforms & Shared Services

In health and care, a shared platform is not a cost-saving convenience but a way to make safety, equity, and trust repeatable — so that every team inherits them instead of reinventing them, often badly.

Why this matters in health and care#

When you run digital delivery across a health and care system, you quickly notice the same capabilities being rebuilt again and again. Every service wants to authenticate a patient, look up a demographic record, send a notification, record an audit trail, or check a clinician's role. Left alone, each team builds its own version. You end up with a dozen login screens, a dozen ways of handling a patient's identity, a dozen audit logs of varying quality — and a dozen places where a safety defect can hide.

This duplication is expensive, but the deeper problem is that it is dangerous and inequitable. In health and care, the plumbing carries clinical risk. If one team's patient-matching logic is weaker than another's, a patient can be given the wrong record. If one service's accessibility is poorer, some people are quietly excluded. If audit trails differ, an information-governance investigation stalls. A shared platform lets you build a capability once, to a high standard, with clinical-safety and accessibility work done properly, and then let many teams inherit that standard rather than each gambling on getting it right alone.

Platforms also shape the pace of the whole system. A good platform means a new service can reach patients in weeks rather than years, because the hard, generic parts already exist. A bad or absent platform means every team carries the full weight of infrastructure, and delivery slows to the speed of the least-resourced team. In a sector under sustained financial and workforce pressure, where the same national and local capabilities are needed by hundreds of organizations, getting platforms right is one of the highest-leverage decisions you will make. This topic is about how to build and run them well — as products with real users, not as mandated infrastructure nobody loves.

Core concepts#

A platform, in this context, is a set of capabilities that other teams build on rather than build themselves. The most useful modern framing is that a platform is a product with internal users. Its customers are your own developers, delivery teams, and partner organizations, and its success is measured the way any product's is: by adoption, by the experience of the people who use it, and by the outcomes it enables.

Several related ideas sit underneath this. Shared services is the older organizational pattern of providing a capability once for many parts of an organization instead of duplicating it in each. Digital public infrastructure extends this to the level of a whole society — the shared, reusable, interoperable building blocks (identity, payments, data exchange) that public and private services are built upon. "Government as a platform", a phrase coined by Tim O'Reilly and taken up by digital-government teams worldwide, applies the same logic to the state: government provides common components, and departments compose services from them rather than each building the full stack.

Technically, platforms often expose their capabilities through an application programming interface (API) — a defined contract that lets one system use another's capability without knowing its internals. They frequently draw on cloud platform as a service (PaaS) models, and shared national platforms typically rely on multitenancy, where a single instance serves many organizations while keeping their data and configuration separate.

Three concepts govern whether a platform helps or harms. The first is cognitive load: a good platform reduces the amount a delivery team must hold in its head, so the team can concentrate on the clinical or care problem it exists to solve. The second is the "paved road" or "golden path" — a well-supported, opinionated default way of doing a common task that is easier to follow than to avoid, offered through self-service rather than gatekeeping. The third is the avoidance of vendor lock-in, which is why platforms should be built on open standards so that organizations can move between suppliers without prohibitive switching costs.

In health specifically, national shared services are already part of the landscape. Historic programs such as NHS Connecting for Health established the NHS Spine, a set of national services carrying core data such as the Personal Demographics Service. Modern equivalents include national APIs, NHS login for citizen authentication, and NHS Notify for messaging — capabilities offered so that individual services need not rebuild them. Where a platform provides a common way to prove who someone is, it often exposes single sign-on so a clinician authenticates once rather than repeatedly. This topic concerns how to build and run such platforms; the details of who you are and what you may do belong to Topic 4.2 — Identity & Access Management, and the standards that let systems exchange data belong to Topic 4.3 — Interoperability & Data Standards.

Best practices#

1. Treat the platform as a product, not a project. A platform has a roadmap, a product manager, ongoing funding, and users whose satisfaction you measure — not an end date and a handover. Projects finish and decay; platforms must be run indefinitely because teams come to depend on them. Fund and staff accordingly, and see Topic 5.0 — Product-Led Work for the operating discipline this implies.

2. Start with the thinnest viable platform. Build the smallest set of shared capabilities that genuinely relieve teams, and add more only when real demand and real pain justify it. This "thinnest viable platform" idea, introduced in Topic 1.1 — The Operating Model, guards against the commonest failure: an ambitious central platform that tries to do everything, arrives late, and fits no one. Let the platform grow from evidence of use, not from architectural aspiration.

3. Make the paved road the easy road. A platform earns adoption by making the supported path faster and simpler than building your own — through self-service onboarding, clear documentation, sandboxes, and sensible defaults with clinical safety and accessibility built in. If using the platform is slower or more painful than going around it, teams will go around it, and you will have spent money to create a bottleneck. Design for the developer's first hour and their worst day.

4. Measure success by adoption and user experience, not by existence. The right metrics are how many teams use the platform willingly, how long onboarding takes, how often the platform is available, and how its users rate the experience. Vanity metrics such as number of services deployed tell you nothing about whether teams are helped. Instrument the platform, run regular research with the teams that build on it, and treat a falling or stagnant adoption curve as a product problem to fix, not a compliance problem to enforce.

5. Build on open standards and keep exit cheap. Prefer open, widely-adopted standards and interfaces so that neither you nor the teams on your platform are trapped. Document how a team would leave, and make sure they could. Paradoxically, making it easy to leave is what makes teams comfortable to arrive, and it keeps the platform honest because it must earn its place rather than rely on captivity. This directly reduces vendor lock-in across the wider estate discussed in Topic 4.0 — Technical Architecture, Cloud & Legacy.

6. Be explicit about who pays and who decides. A shared platform needs a funding model and a governance model agreed up front: whether it is centrally funded, charged back to users, or a hybrid, and how its roadmap is prioritized across competing tenants. Ambiguity here is what turns platforms into political battlegrounds. Publish the model, give users a real voice in the roadmap, and revisit it as the platform grows.

7. Run the platform team with clear responsibilities and boundaries. Organize around a dedicated platform team whose job is to enable stream-aligned delivery teams through self-service, as described in the Team Topologies patterns in Topic 7.0 — Team Structures, Roles & Responsibilities. Keep the interface between platform and consumers explicit — what the platform promises, what it does not, and how to get support — so the platform enables rather than gatekeeps.

8. Design for multi-tenancy, isolation, and safety from the start. If many organizations will share one platform, separation of their data, configuration, and failure domains is a foundational requirement, not a later feature. In health and care this is also an information-governance and clinical-safety requirement: one tenant's incident must not expose or endanger another's patients. Bake in isolation, per-tenant observability, and a clinical-safety case for the platform itself under DCB0129.

Questions to discuss with your team#

1. What is the thinnest platform that would genuinely relieve our teams, and what are we tempted to build that we should not? It is easy to design an expansive platform on a whiteboard and hard to ship one teams love. Start from the real, repeated pain your delivery teams feel today — the capability three or more teams are each rebuilding — and resist adding anything that only one team needs or that no one has asked for yet. Ask which capabilities are genuinely common versus which merely look similar from a distance but differ in the details that matter clinically. Consider the cost of getting it wrong: a premature shared capability that teams must work around is worse than no platform at all. Agree an explicit line between what the platform will own now and what it will deliberately defer. Revisit that line on a schedule, moving items across only when demand and pain are demonstrated. The discipline is saying no to good ideas that are not yet earning their place.

2. How will we fund the platform and decide its roadmap when tenants disagree? A platform serves many teams with competing priorities, and the moment two important tenants want incompatible things, your governance is tested. Decide now whether the platform is centrally funded, charged back to users, or hybrid, and be honest about the incentives each model creates: chargeback can suppress adoption, while central funding can detach the platform from user need. Decide who holds the roadmap, how tenants influence it, and how you arbitrate between a large organization's urgent need and a small one's basic need. Consider equity explicitly, because a chargeback model can price smaller or poorer organizations out of shared safety capabilities. Agree how you will handle a tenant who wants to fund a feature the others do not. Write the model down and publish it, so that decisions feel like governance rather than favouritism. Then commit to revisiting it as the platform and its user base grow.

3. How will we know the platform is loved rather than merely mandated, and what will we do if it is not? A platform can be technically sound, officially required, and quietly hated — and a mandated-but-unloved platform accumulates workarounds, shadow systems, and resentment. Decide up front which signals tell you the truth: willing adoption where teams have a choice, time-to-first-success for a new team, availability and incident history, and direct feedback from the developers who use it. Talk about how you will gather honest feedback when you also hold power over your users, since people are reluctant to criticize a platform they are required to use. Agree what a healthy adoption curve looks like and what threshold would trigger a serious rethink. Decide whether you would ever be willing to retire or replace the platform if the evidence demanded it. Being willing to hear that your platform is not working is what keeps it working. The alternative is discovering the truth only when a major service routes around you.

4. How will we keep exit cheap, and could a team on our platform actually leave if they needed to? It is easy to claim you are built on open standards and quite another thing to prove a team could walk away without a prohibitive rewrite. Talk honestly about where lock-in is creeping in — a proprietary interface, an undocumented data format, a national dependency with no alternative — and whether the cost of leaving is rising quietly over time. Decide who is responsible for documenting and periodically testing an exit path, rather than assuming one exists. Consider that in health and care the lock-in risk compounds: a national platform built on captivity can trap an entire system for a generation, and the teams least able to absorb switching costs are usually the smallest providers. An honest answer names the specific dependencies you would struggle to unwind, describes a concrete exit for at least one real tenant, and treats portability as a feature you maintain rather than a slogan you repeat. Remember that making it easy to leave is often what makes teams comfortable to arrive.

5. Does the platform carry its own clinical-safety case, and how do we keep one tenant's failure from harming another's patients? When many organizations share one platform, its plumbing carries clinical risk on behalf of every service built on it, so a defect in patient-matching or a leak between tenants is not one team's problem but everyone's. Decide whether the platform has its own DCB0129 safety case that consuming teams can genuinely rely on, or whether each service is silently re-assessing the same shared risk. Discuss how you isolate tenants' data, configuration, and failure domains, and how you would know if that isolation were breached — per-tenant observability is the difference between containing an incident and discovering it late. Consider the information-governance consequences too: an investigation into one tenant must not require exposing another's records. An honest answer can point to a maintained safety case, a tested isolation boundary, and a clear account of what the platform promises about safety versus what remains each service's responsibility. Treating safety and isolation as foundational, not as later features, is what lets teams inherit assurance rather than gamble on it.

6. Where is the line between the platform team and the teams it serves, and how do we stop the platform becoming a bottleneck? A shared platform can accelerate every team or slow all of them to the speed of one central queue, and the difference lies in how sharply you have drawn the interface between platform and consumers. Decide what the platform owns and promises, what it explicitly does not, and how a team gets support without waiting on a ticket for routine work. Talk about self-service as the default: if onboarding, provisioning, or a common change all require the platform team to act by hand, you have built a gate rather than a paved road. Consider the cognitive-load bargain at the heart of a good platform — it should reduce what a delivery team must hold in its head so they can concentrate on the clinical problem, not add a new layer to negotiate. An honest answer names the tasks that still funnel through the platform team as a bottleneck, sets a direction for making them self-service, and is candid about where the platform is enabling versus where it is gatekeeping.

In practice: a health & care example#

An Integrated Care System (ICS) covering several NHS trusts, community providers, and a county council's adult social care service keeps hitting the same wall. Each new digital service — a virtual ward, a self-referral form for community physiotherapy, a care-home oversight tool — spends its first three months rebuilding the same foundations: proving who the patient is, checking the professional's role, sending SMS reminders, and writing an audit trail. The virtual-ward team's patient-matching turns out to be weaker than the physiotherapy team's, and a near-miss occurs when a reminder is sent to the wrong person. The ICS's digital leadership recognizes the pattern: they are paying many times over for capabilities that should exist once, and the variation is a safety risk.

Rather than commission a grand ICS platform, they start thin. They stand up a single shared service that does one thing well: it wraps NHS login and the national Personal Demographics Service behind a clean, documented API with a sandbox, so any team can verify a citizen's identity and retrieve a confirmed demographic record through one supported path. A small platform team of five treats it as a product. They publish a paved-road guide, offer self-service onboarding, and set a target that a new team should make its first successful call within a day. Crucially, they do not mandate it. They make it the easiest option and let the virtual-ward team be the first willing adopter.

The funding model is agreed openly: the ICS centrally funds the platform's core for its first two years so that adoption is not suppressed by chargeback, with a review at eighteen months. A cross-provider group, including the council, holds the roadmap and meets monthly. When the physiotherapy team asks for a notifications capability next, the platform team adds a thin wrapper around NHS Notify rather than building messaging from scratch — build once, use many. Within a year, six teams have adopted the identity service willingly, onboarding has dropped from months to days, and the platform team publishes its availability and adoption figures openly. When one trust's bespoke system routes around the platform, the team treats it as research rather than defiance, learns the friction that drove the decision, and fixes it. The platform grows because teams choose it, and the ICS inherits a single, well-tested, accessible way of doing the risky, common things.

Sector lenses#

Startup#

A health-tech startup rarely builds platforms for others; it builds on them. Your leverage comes from consuming national and cloud platforms — NHS login, national APIs, a cloud provider's managed services — so your small team spends its energy on the clinical problem, not on reinventing identity or messaging. Watch for lock-in even so: choose open standards and keep your data portable, because the capability you rent cheaply today can become the dependency that constrains you tomorrow. Internally, keep your own "platform" thin to the point of near-invisibility; a two-person team does not need a golden-path abstraction, it needs to ship. The discipline is knowing when you have grown enough that a shared internal capability is worth extracting.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, or a single-site clinic — is almost always a platform consumer with little or no digital capability of its own, so the platforms it depends on effectively set its safety and equity floor. Your practical task is to choose supported shared services over bespoke builds you cannot staff or maintain, favoring national capabilities such as NHS login, demographic lookup, and NHS Notify that already carry accessibility and clinical-safety work you could never fund alone. Insist on genuine self-service onboarding and clear documentation, because you have no platform team to escalate to and cannot afford a lengthy integration project. Watch the funding model closely: a chargeback platform can price a small provider out of the very safety capabilities it most needs, so press for equitable access and raise it in any roadmap governance you can reach. Keep an eye on exit too, since a proprietary supplier lock-in is hardest to escape when you have no in-house technical staff to migrate you. The gain is that a good shared platform lets you inherit standards you could not build, meeting the same duties as large organizations without their resources.

Enterprise#

A large trust or national body has the scale to justify real platforms and the bureaucracy to ruin them. The risk is a central platform team that becomes an ivory tower — architecturally elegant, slow to respond, and detached from the delivery teams it supposedly serves. Counter this by funding platforms as long-lived products with their own roadmaps and user research, and by measuring them on adoption and developer experience rather than on mandate compliance. Multi-tenancy, isolation, and a clinical-safety case for the platform itself become essential at this scale. The prize is enormous: a capability built once to a high standard and inherited by dozens of services, raising the floor for the whole organization.

Government#

At national and system level, the framing is digital public infrastructure and government as a platform: build common components — identity, notifications, demographic lookup, data exchange — that hundreds of organizations compose into services. The stakes for openness are highest here, because a national platform built on proprietary lock-in can trap an entire health system for a generation. Governance and funding must be worked out in the open, with real influence for the smaller and poorer organizations that shared platforms exist partly to protect. The temptation to mandate is strongest and most dangerous at this level; a national platform that is required but unloved breeds shadow systems across the country. Earn adoption through quality and support, and treat every workaround as a signal to improve.

Common failure modes#

• The bottleneck. Every team must wait on the central platform team to do anything, so the platform slows delivery instead of accelerating it. The cure is self-service: teams should be able to onboard and act without a ticket.
• The ivory tower. The platform is designed by people distant from delivery, is technically admirable, and fits no real team's needs. The cure is running the platform as a product with continuous user research.
• Mandated but unloved. The platform is required by policy but worked around in practice, accumulating shadow systems and resentment. The cure is to earn adoption through quality and to listen when teams route around you.
• The everything platform. An over-ambitious scope means the platform arrives late, does too much, and does none of it well. The cure is the thinnest viable platform, grown from evidence of demand.
• Lock-in by stealth. The platform quietly ties teams to a proprietary supplier or interface, and the cost of leaving becomes prohibitive. The cure is open standards and a documented, tested exit path.
• Funding ambiguity. No one agreed who pays or who decides, so the platform starves or becomes a political battleground. The cure is an explicit, published funding and governance model.
• Safety as an afterthought. The platform has no clinical-safety case of its own, so every consuming service inherits unassessed risk. The cure is to treat the platform's DCB0129 safety case as foundational.

Maturity model#

Checklist#

• The platform has a named product manager, a roadmap, and ongoing (not project) funding.
• You started from the thinnest viable platform and can name what you deliberately deferred.
• The supported path is genuinely faster and easier than teams building their own.
• New teams can onboard through self-service, with a sandbox and clear documentation.
• You measure adoption, time-to-first-success, availability, and developer experience.
• The funding model (central, chargeback, or hybrid) is agreed and published.
• Roadmap governance gives tenants, including smaller organizations, a real voice.
• The platform is built on open standards and a documented exit path exists.
• Multi-tenant data and failure isolation are designed in, not bolted on.
• The platform has its own clinical-safety case (DCB0129) that consuming teams can rely on.
• You treat teams routing around the platform as research, not defiance.

Key sources#

• GOV.UK Service Manual and the Government Digital Service writing on government as a platform and common components.
• Matthew Skelton and Manuel Pais, Team Topologies — platform teams, thinnest viable platform, and cognitive load.
• NHS England developer and API guidance (NHS login, NHS Notify, national APIs, and the Spine services).
• DCB0129 and DCB0160 clinical risk management standards for health IT systems.
• The World Bank and United Nations writing on digital public infrastructure and reusable public building blocks.
• Tim O'Reilly, "Government as a Platform", in Open Government (O'Reilly Media).

References#

1. Digital public infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipedia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipedia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipedia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipedia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipedia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation