Information Sharing Patterns Summary
- 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:
- 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:
- Send point-to-point / Broadcast
- 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.
Was this article useful?9