How Do We Successfully Deliver Interoperability Across the NHS and Social Care?

A Background to Discussion for Digital Health Rewired 2021

Lead Author: David Hancock, Vendor Co-Chair, INTEROPen


Purpose of Document

The NHS has been grappling with the interoperability problem for as long as healthcare providers have had more than one IT system.  The problem increases exponentially the more systems we have supporting administrative and clinical processes within a healthcare provider and further increases as these providers need to share information with each other.  Tackling interoperability becomes even more important as we move to Integrated Care Systems existing on a statutory basis, as the planned parliamentary legislation published on the 11th February 2021 wants to do.  Whilst we have had some great successes in limited, specific areas, finding solutions for the majority of interoperability challenges continues to evade us – as it has for over 30 years.

The purpose of this document is to 

  • Summarise the challenges to delivering interoperability
  • Analyse some of the achievements made to date  
  • Identify the next set of interoperability challenges we have to solve and what we need to do to overcome these – with evidence of what works.

INTEROPen Position

Options for Digital Transformation


Digital transformation in health and social care is one of the most complex adaptive change problems that entails both technical and transformational change.  Adaptive change involves substantial, long-lasting engagement between the leaders implementing the changes and the individuals on the front lines who are tasked with making them work. For this reason, it is in many ways more a social problem than a mere technical problem.  Complex adaptive change problems can only be solved by all those sharing the problem, creating the solutions; true co-production.  This is why INTEROPen does not believe that interoperability standards that are there to support digital transformation can be imposed top-down; it is not, at its core, a technical problem

Enterprise EPR or Multiple Systems

Many professionals working in health and social care know that their fundamental transformation cannot be achieved without the application of digital technology which, at its simplest, may be approached in one of two ways:

  1. One single EPR system; an Enterprise EPR
  2. Multiple interoperating systems

However, the reality is that even though buying a single Enterprise EPR has certain advantages for the ready support of end to end clinical and administrative processes within an organisation, it would be a mistake to think it can therefore remove the need for interoperability.  Interoperability is still a huge issue for the following reasons:

  • No site is a Green Field and there are always systems that need to be, or want to be, retained
  • Within many acute hospitals, tertiary services are provided by other organisations on site, but these tertiary services are supported by the tertiary providers IT and not the IT of the acute hospital within which it is being provided.  However these systems need to share information.
  • Treating more patients in the community requires collaboration across multi-disciplinary teams from different organisations, all of whom could be using different clinical or care systems.  
  • Payment models, and Integrated Care Systems are changing the behaviour and focus of providers.  A provider is no longer an island whose success is mainly measured on their individual financial performance.  Instead a provider has to work seamlessly with other providers, Local Government and the 3rd sector to support an Integrated Care System and will have to support payment based on value and collaboration.  Changes in models of care will be continual and they have to be able to adapt and play their part in this.
    • There is an example of an Integrated Care System looking to buy a single core EPR for all the Acute Hospitals in the system, however, it still wants to standardise on specialist departmental application too, reflecting the fact that for the vast majority of organisation and systems, one vendor just cannot provide all the functionality/capability required.
  • It is impossible to implement all the functionality of a single EPR in one single phase, so there needs to be a progressive migration to a target end-state, which also has a large dependency on delivering the necessary interoperability to support the changing way that applications support both clinical and administrative processes.

The attraction of having multiple interoperating systems is that not only can you focus on a more best of breed applications strategy, but you are able to have far more control of your roadmap and your data.  To be successful this has to be underpinned by a strong interoperability strategy and a robust integration architecture delivering that strategy.  It is obvious that this is reliant on interoperability standards.

Issues with Interoperability Standards

Variability of End Points

Defining interoperability standards based on best clinical practice is laudable, but the difficulty with interoperability comes at its implementation.  Many systems in use do not support the defined interoperability standards. Not only that, many are so old they may well not have an Application Programming Interface (API).  Applications can also be so old that they have been “sunsetted” by their suppliers which means that no development work will be undertaken along with only minimal bug fixing so that they will never be upgraded to support new interoperability mechanisms or standards.  Defining standards without basing them on what is implementable leaves standards developers and enforcers as a hostage to fortune and experience here in the UK and worldwide shows that fortune never favours them.

Ensuring the Right Interoperability Problems are Being Solved

Interoperability standards will not be adopted unless they are solving a clear and pressing problem faced by the service. If the standards are not solving a compelling problem faced by the service in a way that they can implement, then it will simply not be used and will be “left on the shelf”.  THe NHS has many examples of this including many of the ITK standards.

Getting Suppliers to Support Them

Suppliers of systems to Health and Social Care have finite resources for development and support of their products.  They face many issues:

  • Many programmes from the NHS mandate standards, but there is no function that works across the programmes to apply relative priority of standards across programmes.  This makes it difficult for suppliers to deal with the large numbers of regulations and standards they are expected to conform to. With no function to go to, suppliers decide for themselves what they can do and wait for any repercussions of them not supporting certain standards and regulations.  As it happens, with many there are no sanctions imposed, so suppliers develop a learned behavior that these may not be important and they’ll do something about it only when it gets escalated with the threat of a sanction that is real and will hurt them..
  • Building support for interoperability standards has to be planned and incorporated into a supplier’s development roadmap for their products.  To be included, they need to be sure that it will be used by customers, as suppliers have an opportunity cost of what else they could use their resources for that they know their customers want and will use.   

Methodology and Philosophy of Standards Development Process

The current process for defining interoperability standards is one where a considerable amount of time is spent getting a solution to a reasonable level of detail before it is released.  This more cautious approach is then reinforced by standards being given status of:

  • Alpha
  • Beta
  • Release Candidate
  • Available/Released

The fact is that for many suppliers (and the service), if an API is not available/released they will believe that it has not been finalised, may be changed or worse withdrawn.  They therefore do not want to commit resources to developing something that they fear may be withdrawn.  This is exacerbated with a lack of transparency on available standards, lack of clarity on their roadmap and status and what their planned future state is going to be.  The lack of a fit for purpose standards registry is holding their adoption back.

Furthermore if much of this work has been undertaken without co-production with all groups who share the problem, it is highly likely that the decision not to work on it is backed up by it being extremely difficult for suppliers to support it.  If the standard is being imposed, with little or no input from suppliers, then there will be little trust between the suppliers and the definers of the standards as there will have been no basis on which to build trust – such as through co-developing the standard.  Using a technology-driven transformation process that is agile involving co-production of deliverables may well be a better way of defining interoperability standards than getting a solution to a reasonable level before release.  For example  it is better to say “use free text” than to say “standard in development” as at least it provides real implementation guidance for system providers and users.

Good Things That Have Been Achieved

For all the difficulties identified to get interoperability standards defined and adopted, there have been successes:

We have been successful integrating clinical information from disparate systems “at the glass”.  At its most basic, this can be through context launch and single sign on of one application from another to view data within the application and to act upon it.  This still does not solve a usability issue for clinicians, where they want to see patient centric records made up of data about a patient from a variety of systems.  This is the viewing of consolidated records and this typically does not have to rely on the consumption of structured data that the system can reason on.  Instead a clinician has to interpret the data and then act upon that.  There are many successful projects that work this way including LHCRs and Shared Care Record programmes.

Whilst GP Connect has taken much longer to develop than initially planned, and even though it is still suffering delays, what has been delivered using standard FHIR interoperability standards has been a great success.  Being able to make appointments in GP systems from Out of Hours and NHS111, to be able to access Patient Summary data free of charge and now being able to get more and more structured data from the patient summary is adding huge value as we move to Shared Care Records and making primary care data available to other points of care using open standards.  

We have also seen improvements in relationships with certain key stakeholders in the last 9 months, especially with the way NHS Digital is working across the digital care landscape.

What Next?

Exchanging Structured and Coded Data to support Transactional Services

The next stage in increasing the maturity of or interoperability is building on the interoperability achieved with GP Connect allowing structured and coded data to be exchanged using request-response transactions.  This is the model of interoperability detailed in the Secretary of States Technology Vision of 2018 where data should be left in the systems in which it is created and using record locators data is found and then accessed using open APIs.  It is also the type of interoperability required to support the proposed Health and Care legislation ”Integration and Innovation: working  together to improve health and social care for all” published on Feb 11th 2021.  This type of interoperability allows data consumed by systems to be reasoned on for such things as clinical decision support, rather than allowing us to just view the data.  For clinicians, it will allow them to combine the “Viewing” and “Doing” within their primary clinical application, reducing the number of clicks clinicians require to access the data they need and being able to record what they are doing.  This relies not only on the exchange of structured data but the move to exchange coded data.  This more sophisticated interoperability has many more challenges

Challenges and How We Overcome Them

Not having a bottleneck at the centre

If we have to wait for every interoperability standard to be defined by “the centre”, then the service will not get the interoperability capabilities it needs to meet its requirements in a timely manner.  Local health economies have different priorities for interoperability, so they will want to be able to define standards based on their local needs.  Therefore, whilst there is likely to be a set of Core FHIR Profiles (UK Core), the system must be flexible enough to allow local health economies to define standards they want to use based on the Core Profiles and developed according to some set of guidelines.  In this way, these local interoperability standards can be shared and can potentially move from “Local” to National”, by being used by all regions

Defining data to a more granular level of detail

We need precise definitions of data items using a common language that all vendors and suppliers of systems can understand and make it easy to map to their data structures in their solutions.  The PRSB standards are excellent clinical definitions of what should make up a particular clinical record, but as they are, they are unimplementable by system suppliers from an interoperability perspective.  Basically the PRSB standards are not defined to a level that data in source systems or shared care records can be mapped to.  A likely way to overcome this is to develop  “Logical Models” for the content that needs to be exchanged; logical models of the PRSB (and any other ) clinical standards.  A logical model is an expression of a set of content in an implementation-neutral style that helps implementers understand the content is a single package. For FHIR, this logical model can be turned into a FHIR Logical Model.  Because of the way FHIR works, a single logical model may be actually represented during exchange by a set of resources, including a series of observations and questionnaires. Typically, profiles that define how the resources are used are derived from the logical model, so it also allows us to more effectively bridge from the clinical requirement to how it is implemented using a universally understood language.  These models are not necessarily “Right” or “Wrong”; rather “more or less useful” as they are a representation of a requirement.  If these Logical Models are delivered as a joint piece of work by the PRSB, industry and the service, we should be able to arrive at models that are useful and usable to both suppliers and the service which means that they are more likely to be implemented successfully.

Complexity of Interoperability

The interoperability we are wanting to implement today is far more complex that what we have done previously especially real time pulling of structured and coded data and when FHIR Profiles, Implementation Guides and APIs are defined we cannot assume that they are readily understandable by developers.  If these are co-produced, developers can work with these APIs and standards to ensure they understand them, that they actually work for how they want to use them and there are no errors or mistakes in them.  It is also why Hackathons are important, where developers can work with them hands-on and try to build interoperability with developers of other solutions. If they are given some documentation and then have to work on it, they are likely to have questions and find out that parts of the specification may well not work for them in the way it has been implemented.  There may even be errors in it.  All of this creates barriers to adoption, and these barriers could well be too high for many suppliers to overcome.  By running hackathons as part of the standards development process we will drive adoption and allow system providers to understand more about what is involved to implement a standard so they can more accurately and predictably plan it into their roadmaps

Top Down Enforcement and Incentivisation

In INTEROPEN’s view, top down enforcement does not work.  NHS and social care organisations are given many priorities, yet these are often prioritised in isolation so there is little understanding of the relationship between interoperability priorities and others.  Implementing these standards is extremely difficult given that they require complex adaptive change; they are not just a technical problem.  The NHS Contract of 2018/19 mandated that NHS organisations use the new PRSB Transfer of Care standard by end of September 2018 and Care Connect API standards by December 2018 and, more than 2 years after this date, fewer than five organisations are using the Transfer of Care standard; for Care Connect, only GP Connect is being used and adoption is still low.  Much of the delay has been due to waiting for GP supplier systems to be able to support this.

INTEROPen is also concerned about  incentivisation because the NHS (in particular) appears well practiced in gaming measurement to give the measurers the results they want to see and hear, but without actually making the necessary changes or seeing through the changes to any required level of effectiveness.  INTEROPen and its members readily understand that “Culture eats Strategy for Breakfast” and without getting the culture right, any strategy will not be successful.  The approach of co-production to solve this complex adaptive change problem addresses the culture issue, builds trust across all parties who share the problem, and therefore creates an environment within which a “carrot and stick approach” can work.  We strongly believe it gives us the best chance of driving adoption of interoperability standards across health and social care.

Interoperability will always be difficult if we continue to view it as a technical problem because it is much more of a social problem.  We must heed the wisdom of our dear friend Professor Joe McDonald who would always remind us of the need to solve “collective action dilemmas”.

In order to successfully solve an interoperability problem, one organisation has to do the work, incur cost and make changes to the way they work, but they get no benefit from this as it is the receiving organisation that gets the benefit.  Whilst there is good for the overall system, it is not good for the individual organisation that has to incur the cost and the change.  This is what sociologists call “Collective Action Dilemmas”.

A collective action dilemma is a situation in which all individuals would be better off cooperating but fail to do so because of conflicting interests between individuals that discourage joint action.  This is why it is so vital to engender trust and enter corridors of uncomfortable conversations (thanks to Joe again!) for the necessary discussion around, and resolution of, conflict so that we can work through these fundamental issues. 

No Consideration of Defining and Getting Interoperability Standards Adopted as a Holistic Process

One of the biggest barriers to getting standards adopted is the need for the skills and knowledge of multi-disciplinary teams from different organisations, including those with clinical expertise, clinical informaticians, technical architects, product managers, standards specialists from standards organisations, etc. However, we find that many who are part of the standards definition process are just focussing on their part and behave as if successful adoption is not their responsibility.  We created INTEROPen in an attempt to solve this problem, but INTEROPen has not been involved in any co-production of standards since March 2018 when we completed the first version of Care Connect.  

We need everybody who is part of the process to recognise that it is their responsibility to drive adoption and minimise time to peak usage and to help everyone understand their role; we need to define an end to end process that starts with requirements definition and prioritisation and ends with adoption and continual improvement.  Without having an agreed scope of the work to define and get standards adopted and having it defined in a series of steps where everyone involved understands their part of the overall process, there will be misalignment making successful adoption far more reliant on luck than anything else, and in this respect, the NHS has been very unlucky so far.

Our Proposal

INTEROPen does not have all the answers, but we believe that the key to unlocking the problem of interoperability needs to turn many levers.  We have to get all the stakeholders who share the problem to work together to co-produce solutions and INTEROPen was created to be an umbrella for all of those stakeholders.  As a start, we believe there are some key changes we all need to make to deliver interoperability.  These include

  • Define an End to End Process for interoperability standards.  This must cover how we identify problems to solve, their prioritisation, how we develop the standards and fail fast (if we have to), how we test them out and then drive adoption.
  • Once we have an End to End Process agreed we should agree the tooling we need to support the End to End Process as there is a danger that the tooling used is, rather ironically, not interoperable
  • Create a backlog based on real, compelling interoperability problems faced by the service
  • Regularly revisit and (re-)prioritise the backlog
  • Commission work to co-produce interoperability standards, starting with requirements (clinical, workforce, etc.), and work this through to create interoperability standards
    • Work from Clinical Modelling (where appropriate) through to Logical Modelling (Implementation Neutral) and then FHIR Logical Models to allow stakeholders to understand how to implement them
    • Use a technology-driven transformation process that is agile involving co-production of deliverables rather than getting a solution to a reasonable level before release
    • Set this expectation of agile iterative development with system suppliers, so they understand that it is not a one-shot effort
    • Work with the service to understand feasible timescales for adoption (bearing in mind the variability of their endpoints and different priorities)
  • Use a combination of incentives and sanctions to drive the adoption of the standards with realistic timescales
  • Focus on implementation support of standards to drive adoption – making this easier for the service and system suppliers to implement standards.
    • In particular ensure standards are recorded on a single Standards registry which is a single version of the truth for standards, their status and roadmap
    • Provide proper collaboration areas to support and curate  feedback on usage of these standards from system suppliers and the service

We call on all stakeholders, including NHSX / NHSE Improvement, NHS Digital, and PRSB, to work with INTEROPen as the umbrella under which we can solve the Interoperability problem.  We all need to leave our business cards at the door along with any vested interests we may have to work collaboratively on this.

As the business writer Patrick Lencione said

“Remember, teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”


There are no comments yet

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.