SOA in the National NHS IT Services

Written by Joseph Waller, 14/12/2014

Further to last month’s post on Service Oriented Architectures I wanted to follow up with a few words on how SOA has been implemented in the NHS. This is also an opportune moment to confess that my own responsibilities for the creation of some of the NHS services I describe below was not insubstantial, hence I report these observations in the manner of a kindly parent wishing the family of NHS IT professionals to learn from our mistakes. It is a review of some of the programmes oversights and thus neglects the positive elements – yes, there were a few – of this large programme.

The history of SOA in the National Programme for IT.

The National Programme for IT provided a number of large scale systems to the NHS including national systems for maintaining patient identity, systems for managing electronic prescriptions and national electronic booking systems. This troubled programme is deemed to have made some mistakes in its implementation and a number of these can be traced back to the poor implementation of SOA and its associated elements.

Poorly designed interfaces to the Spine

The interfaces to the Spine  were built in a manner that provided limited anticipation of re-use. Messages of large granularity often meant that client systems requiring a simple piece of data were required to construct large complex messages.

Rarely implemented internal canonical formats

In the example of the Spine, although an internal canonical format was designed, commercial pressures often meant that use of this standard was eschewed in preference for the most rapid (or just the most easily understood) implementation. On a number of occasions inside Spine and on other programmes, a single supplier building two systems within the overall estate chose to communicate directly using underlying proprietary messaging formats. These limitations meant that systems became tightly coupled. The arrival of additional consumers of a service often required the building of an entirely new interface with the associated additional integration testing and then the additional regression testing on every new release. At each point in time the “most appropriate” solution for that next consuming system seemed like the most cost and time efficient architectural decision, but overall this produced a system that was cumbersome and expensive to change, expensive to transition and difficult to replace. In addition the architecture stifled the innovative utilisation of services and numerous potential improvements for the business were lost.

Lack of reuse across programmes

The high level functionality of systems across the national programmes was often poorly understood.  This meant that large scale, multi-million pound systems were often rebuilt when functionality in currently existed systems could have been used. Although the responsibility for such mistakes is largely a feature of poor enterprise architecture, the discipline of a national service orientated architecture would have avoided most of these instances.

The Interoperability Toolkit

The Interoperability Toolkit (ITK) was an attempt to introduce a canonical format for the NHS and to that extent to support SOA. Specifically the hope was to “unlock the data” currently stored in siloed healthcare systems.

The implementation of the interoperability toolkit progresses today and may still produce benefits for the NHS. However, it is increasingly recognised that the ITK may not qualify as a suitably usable canonical format for the NHS.

The ITK canonical format still requires a number of unnecessary additional data items adding complexity to the message. Many implementers report that the specifications describing the ITK seem overly complex. To succeed, a SOA standard should be less effort for the implementer to use that it would take to devise their own interfaces. It is not clear that the ITK fulfils that criterion. Most crucially the ITK implemented a different canonical format to that created for use on the national services. This created an immediate diversion of strategy for implementers in the NHS. Do they learn to use the national service interfaces or do they learn to do ITK?

Finally the ITK did not provide the ‘supporting services’ required for SOA to succeed. There was no standardised endpoint discovery, no directories and the initially proposed security infrastructure was not part of the final implementations.

The principles behind the ITK were correctly identified. Thus great potential for an updated ITK standard to support more re-use and innovation in the NHS remains. However, there is a danger that suitable efforts to improve ITK may not be made. Previous tendencies in the NHS to avoid consolidation of standards onto one canonical format remain and new national systems may not make suitable efforts to converge.

Summary

Benefits

In the case of the NHS, national solutions based on service oriented architecture could enable:

  1. Functions to be-re-used between national solutions rather than being re-built for every new system. This includes:
    1. Avoiding repetition of design effort and code;
    2. Avoiding repetition of operational servicing of that capability;
  2. Interoperability to occur as a normal by-product of delivery, more cheaply with reduced reliance on middleware products;
  3. Simplified cost effective testing using common testing tools and methods (in particular for integration testing) re-used with less preparation and overhead;
  4. Service and operations teams who are familiar with an established shared canonical format reducing the complexity and cost of problem diagnosis. Simplified and improved message monitoring;
  5. Shorter architecture and design cycles where standards and patterns are well known and used by default;
  6. New uses of current data created and accessed more rapidly through service re-use and composition also benefiting from consolidated service discovery;

Challenges

The challenges to implementing SOA are:

  1. Additional effort and thinking is required around service design and granularity;
  2. The need to create a shared canonical format;
  3. The need for a disciplined approach to supplier engagement which includes SOA considerations;
  4. The initial additional effort / cost required which includes development concerns as well as and effort and commitment from the wider organisation.
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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