Digital is gold, but data is the new currency

A transformation architecture for regional health and care systems

Alastair Allen
10 min readMar 22, 2022

At this year’s Digital Health Rewired I delivered a talk on the role of digital and data to support transformation at an Integrated Care System (ICS) level. While my talk was delivered in the context of an NHS ICS, the approach and much of the architecture should apply to any regional health and care system. This article is the written version of my talk.

The challenges of delivering integrated care across large, and often fragmented health and care landscapes is huge.

Unfortunately, as we look to the future, I believe this challenge will only continue to increase in size as we face new and emerging streams of data that are collected by, and on behalf of the individual. As people continue to become more engaged with their health we will see a shift to a “wellness” model of health and care delivery — as opposed to a traditional “sickness” model — giving rise to huge new streams of data from the so-called Internet of Medical Things (IoMT). This behavioural data will also be accompanied by a whole suite of other data, including social and environmental.

We need to find a way to organise and share this information, alongside the health and care data we see today to ensure we can maintain the innovation precedent set by Covid and deliver better health and care outcomes.

To achieve this, I believe we will need to revisit our delivery approach, while also adopting a new information architecture — one that realises the immense value of health and care data and is able to use it to accelerate transformation across integrated care systems.

Isn’t that what we call digital transformation?

Like many large, complex problems that involve technology, the conversation is very quickly tagged with the “digital transformation” moniker. Unfortunately, this (important) term is now becoming so over-used it is starting to lose its value. In a similar way to how many people now use the term “agile” to describe any form of software development (including waterfall), we now see digital transformation used to describe almost any kind of IT project.

I think (hope) what everyone actually wants when they talk about digital transformation is the transformation bit. I.e., What is the change we are going to initiate? How will we deliver health and care differently? What are the outcomes we are going to deliver?

There are many pieces that will need to be considered when approaching change in this way — including cultural, commercial, and educational. While these are outside the scope of this article, the idea of starting with an outcome is really important when thinking about delivering new or improved digital experiences.

When we think in this way, it forces us to really understand the problem we need to solve. And the only way to understand the problem is to engage with users and identify their needs. But while this is a great start, it is not enough to ensure we can scale the delivery of digital experiences across an entire region. We need to complement this approach with good data that flows easily within and across all digital experiences across a region.

Your digital experience is only as good as the user input you get, but equally the same digital experience is only as good as the data that is available. Tackle both together to accelerate transformation.

So, if we agree on the need for good data to support transformation then how do we make this happen?

I think we can all agree that data is not the new oil. Oil is finite, can be used only once and creates huge wealth for a small number of individuals. In contrast, data is infinite, can be re-used for many different purposes and should ultimately be owned by the individual.

Instead, we need to think of data as the new currency.

When I say currency, I am not thinking in the monetary sense — this definition from the Cambridge dictionary is one that I really like.

If we look at this definition with a data lens, we can start to think about what we need to do at an ICS level to get data to the state where it is commonly known and is being used in many places.

However, when talking about difficult data problems like this, we typically do that with several technologists (of which I am one, so I can say this) in the room. This can often lead to a conversation exploring who the producers and consumers of data are. There will probably be lots of discussion about APIs, ETLs and other three-letter acronyms too.

But, at a regional level, we need to talk about ICSs as facilitators of data.

I believe they need to do this in three ways — by creating parameters, by providing platforms that promote data as a currency and by leading from the front.

  1. Creating parameters — As a partnership bringing together providers and commissioners of NHS services with local authorities and other local partners, ICSs comprise a large and diverse collection of users and organisations. It is essential that the right parameters and guardrails are in place that can foster a culture and environment where innovation is promoted — while ensuring services are delivered in a way that is safe, secure and respects people's privacy. Establishing the right balance between getting value from data — for both direct care and secondary use — and these non-functional concerns isn’t easy, but putting the right parameters in place that allow innovation to flourish is key.
  2. Providing platforms — “ Platform” is another word that is often overused — similar to “digital transformation — to describe any kind of IT system. However, in this ICS context, it is a crucial component that needs to be provided. Specifically, we need open platforms that will allow data to flow easily throughout all digital experiences within the health and care system. Additionally, these platforms need to be flexible, providing organisations with the tools that will allow them to use this data to create applications and services in a safe, yet autonomous way. Doing so will loosen dependencies on third-party vendors and allow transformation to come outside of the IT department and into the hands of the real change agents who exist all across the health and care landscape. As we move to a world of “EPR convergence” this capability becomes even more important and presents the opportunity to act as a layer of abstraction that will facilitate this change.
  3. Leading from the front — ICSs are intended to bring about major changes in how health and care services are planned, paid for and delivered and are a key part of the future direction of the NHS. However, we need to ensure that this change is not delivered as a series of IT projects with technical outputs. Looking ahead, ICSs need to ensure the focus is on delivering services with business or user-focused outcomes — ensuring that feedback is continually measured and the service is iterated on an ongoing basis. It’s not about delivering a BI Report, or an AI model, or even a Shared Care Record. It is about how to solve an entire problem for a given population of people. If we establish the right parameters and provide the necessary platform components, this will allow ICSs to completely revisit traditional expectations around delivery cadence and move to a world where outcome timelines are measured in weeks, not months.

Without facilitating data in this way and combining it with the user-centred approach outlined above many ICSs will be left frustrated as they embark on their transformation journey. ICSs can bring order and direction to this landscape by leading from the front — providing an example to guide others on what good looks like.

So, what does good look like?

I have covered in other articles the importance of separating data from applications and using standards such as openEHR and FHIR (see Why openEHR is Eating Healthcare and FHIR + openEHR). These concepts all still apply but I won't repeat them here. Instead, when I look at an ICS and consider what good looks like, I think of the following.

1. Start with user needs

Really, you need to do this.

2. Be pragmatic

There are a lot of really great applications and services already deployed across every ICS in the country — from large EPRs through to small disease-specific applications. We need to embrace and re-use the good stuff that already exists but acknowledge that individually while each of these applications is important, none of them can solve all the problems that exist.

We are also seeing a lot of attention recently on this idea of EPR convergence, where Tim Ferris has outlined a primary focus to “to achieve universal EPR coverage across all ICSs”. The idea that we will move to a single EPR and that this will solve all the problems is a noble one, but not one that I think will happen. Instead, I think there will definitely be a level of convergence, with a reduction in the overall number of EPRs, but we will still see individual EPRs used across acute care, community services, social care etc.

There is only one way to make this happen in a coherent way.

We need to establish the foundational platforms and data services that will allow data to be commonly known and be used in many places across an ICS — a data currency if you like.

3. Design for the future transformation

There have been many great applications and digital services created that exist as independent entities. While this may be good to solve a one-off problem it does not establish a systemic design where the core building blocks exist to support transformation at scale.

I am currently working on two transformation projects — one for the One London ICS and one for Suffolk and North East Essex ICS. What we are building is, I believe, a systemic architecture that will allow us to initially solve an entire problem (end of life care planning), but also put in place the building blocks to support future transformation.

The architecture is summarised in the diagram below.

There are many components to this architecture, many of which are not detailed in the drawing, but the following components are core to what we are doing.

  1. A longitudinal health and care record — this is based on openEHR and provides a robust modelling framework that allows complex health and care information to be precisely defined and easily processed by other IT applications. This will ensure data can be easily understood and reused across the system. This is the foundation to establishing data as a new currency.
  2. Low code development functions — this will allow ICSs to move away from platforms that only third-party vendors can change, enabling so-called “citizen developers” to create applications and deliver end to end services across an ICS. This will allow ICSs to establish a core set of parameters that govern how applications can be created in a safe, secure and compliant way without compromising on speed of delivery. See my recent article on low code development for more information on this emerging approach to software development.
  3. A community of shared content — the content that is created — from simple applications to shared ICS services — needs to be published in an open way that encourages agility and maximises re-use, both within and across ICS boundaries.
  4. Build applications centrally but deliver locally — this idea of application-level integration will avoid complex integration and increased training overhead. With emerging pathways that span many different care settings, we need a way to deliver services that provide a joined-up experience across the entire patient journey. As outlined in his post “Turning IT architectures inside out”, Tomaž Gornik proposes “Instead of capturing data locally and then sharing some of it centrally, begin with a shared care record, build applications on top, and then push the applications out to the providers in the region….This approach automatically creates a patient-centric care record, simplifies governance of data formats and terminologies, and speeds up application distribution and updates immensely”.
  5. Provide open APIs to facilitate data exchange — of course allowing structured data to flow easily across the various systems connected to a data platform like this is crucial. Open APIs based on FHIR and openEHR allow this to happen with API management enabling the appropriate parameters to be implemented and controlled.

So, for me, it is not a case of does the technology or the healthcare standard exist to support this idea of scaled transformation. Instead, it is a question of how can ICSs provide the leadership that facilitates data to flow freely as a new currency, together with the parameters that will allow ICSs to accelerate the transformation and deliver better patient outcomes.

Credits

  • Thanks for the contributions and review from Matt Cox — Better UK Managing Director.
  • Concept of data facilitators adapted from 2013 Deloitte Report

--

--

Alastair Allen

Football fan and Partner at EY | Board Member @openEHR_UK