Defining services, products and platforms in health & care

Following my earlier blog post describing a model to map journeys in health & care,the inevitable question that arose in discussions was “what are the services we should be providing, and where does NHS Digital fit in as a national health service provider?”

This led to realisation, that when we are talking about services, products or platforms we don’t necessarily always mean the same things. When terms like this become interchangeable, they lose their meaning and become flexible. This doesn’t just mean it’s impossible to define them, but it’s also very difficult to define their component parts, structures, or crucially their outcomes.

In her 2017 blog article, Kate Tarling described a common language of terms, a taxonomy, to help us communicate clearer about services, and Ben Holliday described how Futuregov had built on Kate’s work in their ‘service-oriented’ approach to organisation design.

These models were fundamental building blocks I used when starting to define the taxonomy for health & care, and the public facing services NHS Digital provides.

Service & platform taxonomy for health & care

Building blocks of our taxonomy

Life stage and life event

These are the high-level phases and are way too big to design for, but they are fundamental to provide us with context where the services are needed in people’s life.

User journey

This is the user journey from the people’s point of view, which we can map out based on user research. It should give us the various steps the user goes through in their given life event, the pain points and their goals.There are likely to be number of user journeys within a life event.

A service

This is the health & care system’s response to the user journey and users’ needs and helps users achieve a goal as described by Stephanie Marsh as ‘a whole service’. I have slightly amended this description to suit health & care:

“This is everything the user needs to do to achieve a goal, including non-transactional things, such as research and choosing how to achieve their goal; a whole service is also everything the health & care system needs to do to achieve a health outcome, including delivering and supporting the service.”

Only a whole end-to-end service can help users achieve a goal and help the system in achieving a health outcome. The services in health & care are very rarely provided by a single provider, but often multiple local and national providers are involved to deliver the outcome.

Service patterns

When we find that multiple similar services use similar ways to achieve parts of the service, we should consider wrapping them up as a service pattern. Rather than building them using different technologies and platforms, we should aim for repeatable service components. These are difficult to define, but we are now starting to see these to emerge from our service design work.

Products and digital services

This is where our patient facing ‘services’ are at NHS Digital. For example, our Electronic Referral Service, Electronic Prescription Service, book a GP appointment, sign in using NHS Login, etc. They are digital or enabling services which are contributing to the successful delivery of a whole service, but by themselves do not deliver a health outcome.

We can also describe the NHS App or NHS website as products, which provide an entry point to access the digital services via different channels, including web, mobile and voice.

These products or digital services are also provided by other service providers than NHS Digital. We integrate some of those to our services, some are just linked to. Some of these 3rdparty services use our enabling services like NHS Login to provide secure access to their own services.

Like our own products and digital services, also those provided by others can access our platforms and data via our APIs.

Common components

These are components we have built and could use across multiple digital services to create consistency and save time and effort. These could be for example our components in our design system, which is open for anyone to use.

Capability platforms

Behind an API and access control layer are our capability platforms, which are supporting and delivering platform services to ours and 3rd party digital services. These in turn are supported by technical services, data layers and infrastructure.

Why does this matter?

It’s not only helpful to have agreed definitions for the terms we use, so we know we mean the same things when we talk about them, but it’s also important for us to know where does the thing we’re working on fit in with the wider context.

For example, a whole service “Receive a diagnosis” includes multiple possible sub-services, some of which are digital, but some are via a telephone or physical appointments. In this example, the darker blue ones are national services provided by NHS Digital, and the light grey ones are local services provided by e.g. hospitals or GP.

Example of a potential whole service, it’s enabling parts and how those may be accessed by national and local serviced, products, or providers.

Providing context

If we don’t know what we are enabling ‘above’ us, we cannot effectively design our part, nor can we truly measure whether we are making a real difference to the service we’re enabling. The taxonomy also helps us to have meaningful discussions about what components, platforms, or infrastructure we need to enable our products, so we can effectively enable the whole service. Having a two-way conversation with technical architects in this way, means we’re designing for the outcome, not just a platform, or a feature.

Sophie Dennis using the taxonomy to provide context for the service she is designing.

Connecting services and technology

During the creation of this model, I have had interesting conversations with our enterprise and technical architects to discuss how the APIs, platforms and technical components link in with the services and products.

Technology is often leading our discussions and planning, but this model describes the whole picture from user needs, to services, digital products, and platforms. None of these can exist in isolation and we agreed that platforms should be built based on user needs, and not just because we can build them; they are enabling the delivery of valuable services to meet the user needs.

This taxonomy diagram is not an outcome by itself, but a tool we can use to enable meaningful conversations about context and focus, relationships between the end users, service outcomes, products and platforms.

Highlighting ownership

Inevitable it does raise the question of who does own the whole services in health & care? Who is accountable for delivering the health outcome and can conduct the design of the whole service through multiple providers?

It also clearly demonstrates how we must work together to deliver the services to the public — and these must be designed and delivered as services and not let them happen simply by an accident.

What’s next for this

I’m interested to hear how the health and care services delivered locally would fit into this taxonomy. Is this helpful in identifying how, e.g. national platforms, or digital services can support those services?

You can download the full taxonomy diagram as a PDF from Dropbox.

Head of Design at NHS Digital, an introvert, a photographer & an artist.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store