Browse and search developer information

Information Sharing Patterns Summary

Introducing Patterns

  • A “pattern” is a formal way of documenting a solution to a design problem in a particular field of expertise – this case sharing clinical information between systems.
  • Patterns are not mutually exclusive: many real solutions will use more than one pattern.
  • Solutions may evolve from simpler to more complex patterns over time.
  • Some patterns will be better for specific sharing needs than others – there is no “one size fits all”.
  • Some patterns will scale better to larger populations.
  • Some patterns require additional capabilities or services to be in place.

Summary of Patterns

Click on the below patterns for a description of each:

tn_SharedApplication  tn_Portal

tn_ClickThrough  tn_StoreAndNotify

tn_PointToPoint  tn_Repository

tn_Broker  tn_RegistryRepository


Scaling Patterns

  • Any of the patterns described can support local sharing within an organisation, or between a small number of organisations
  • There are likely to be many cases where wider sharing is required:
    • When a patient receives treatment in a neighbouring organisation.
    • When a patient accesses services from an ambulance trust or other organisation whose boundaries differ from the local sharing boundary.
    • When a patient falls ill away from home.
  • Some patterns are able to scale better to these wider sharing scenarios than others.
  • Local sharing is likely to include larger more detailed data about patients, with wider sharing focused on simpler “core” data-sets agreed across a wider community (or nationally).

The n*(n-1)/2 Problem (Spaghetti)

  • The “single shared application” approach was the original approach of the National Programme for IT – which had limited success.
  • Some of the patterns discussed rely on point-to-point integrations between pairs of systems. This includes:
    • Click-Through
    • Send point-to-point / Broadcast
    • Portal
  • These patterns often suffer from the n*(n-1)/2 problem:


  • Every node has to be able to connect to every other node
  • As the number of nodes (n) grows, the number of links grows rapidly
  • This can rapidly become difficult to manage

Moving from “Push” to “Pull”

  • Some patterns allow information to be stored and retrieved when required – e.g. :
    • Store and Notify
    • Shared Repository
    • Registry Repository
  • This means the sender only needs to know about the repository it is sending information to.
  • A system wanting to retrieve information may use a registry to locate the relevant repository – this may also be federated.