Anti-patterns

The default implementation pattern for request/response are synchronous interactions (RESTFul APIs over HTTPs). An asynchronous interaction should only be implemented in circumstances where a request requires manual fulfilment before a response can be returned.

The main advantages of implementing a synchronous interaction are that it:

• promotes design of the underlying systems/business processes to provide instant 'answers' to queries
• supports easier application flow and simpler integration
• is a simpler pattern for supplier to implement

An asynchronous interaction can be implemented using HTTP (via short or long polling) but adds complexity and potential performance constraints to consumers and is therefore considered an anti-pattern. Implementation of the pattern should only be considered as part of a roadmap towards the delivery of a synchronous HTTP interaction. That is, as an interim workaround whilst technical constraints requiring an asynchronous interaction are being resolved.

Batch transfers data are used on occasion used to support direct care. Examples include:

• bulk upload of changes into a shared repository, such as load of all vaccinations carried out in a day by a specific service into a central repository
• sharing of data with external systems, such as data propagation to synchronise copies of data held across a number of systems

Disadvantages with this approach are that:

• it is not suitable where a real or near real-time view of data is required - there will always be a period of time where the central repository does not hold an accurate and complete view of records
• it can encourage data proliferation with multiple copies of the same data which is contrary to the NHS Architecture Principles as it generates an overhead in having to maintain multiple copies of data and can lead to data synchronisation issues with different views of data being presented to users
• it adds complexity to exception handling - for example, a single record failure can lead to the failure of an entire batch process

Due to these disadvantages the use of use Bulk Transfers for direct care is not an approved approach.

Publish/Subscribe can be used to propagate changes in data to external systems. Whilst publish/subscribe is a suitable approach for sending out notifications of changes in information to potentially multiple systems it is not a recommended approach for keeping multiple versions of the same data synchronised.

Disadvantages with this approach are that:

• it can lead to potential synchronisation issues - Publish/Subscribe does not guarantee delivery of messages and in the event of non-delivery data repositories will become out of sync
• it can encourage data proliferation with multiple copies of the same data being held which is contrary to the NHS Architecture Principles that digital services should only store data once (usually where collected) - it also adds a digital overhead in terms of the processing required to maintain multiple copies of the same data
• there are potential information governance implications of sending information to an organisation which might not need it and therefore the sharing is disproportionate to the need

Screen scraping is the process of collecting screen display data from one application and translating it so that it can be accessed by another application.

Although screen scraping is a quick and inexpensive approach to integration there are a number of disadvantages to the pattern that preclude it from being an approved pattern. For example:

• changes to the user interface being scraped can lead to failures with the interface
• only information displayed on screen can be accessed and, in many cases, this will only be the information presented to users - for example, the display form, not the underlying structured values/codes of this information
• it tightly couples the interface to the application which adds an additional dependency if the application needs to be replaced at a future date