How this service works

This service enables systems to request and exchange information across organisational boundaries. Rather than storing data centrally, it connects systems so that information can be requested from the system that holds it at the point it is needed, and returned in a consistent format.

This approach ensures that systems are working with up-to-date information from the original source. It reduces duplication and helps organisations maintain control of their own data while making it available to others when needed.

You can also explore when to use this service to understand how it applies in practice.

System architecture and key components

At a high level, the service consists of:

• consumer systems that request and use data
• producer systems that provide data
• shared services that support routing, lookup or messaging
• standard interfaces (APIs) that define how systems connect and communicate

These components work together to allow information to be accessed consistently across organisations and care settings, without requiring direct connections between every system.

This diagram shows how systems connect and how requests are routed and responses returned.

The service supports a request-and-response model for accessing information between systems.

This would typically follow this pattern:

1. A consumer system requests information about a patient or event.
2. The service uses supporting services to identify the correct source system.
3. The request is routed to the relevant producer system.
4. The producer system returns the requested data.
5. The response is returned to the consumer system in a consistent format.

This allows systems to access information directly from the source system at the point of need, rather than relying on locally stored copies.

Depending on the use case, this process may include additional steps such as validating the request, handling different types of data, or interacting with more than one source system.

Systems interact with the service through standard interfaces (such as APIs), which define how requests and responses are structured and exchanged.

This allows:

• consistent communication between different systems
• secure exchange of information between organisations
• independent systems to work together without tightly coupling to each other

Typical interaction patterns include:

• requesting information from another system at the point of need
• sending updates or notifications between systems
• exchanging structured messages as part of a workflow across organisations

These interaction patterns support services that operate across organisational boundaries rather than within a single system.

Example interaction

For example, a system used by a clinical team may need to access patient information held in another organisation’s system.

In this case the:

• consuming system sends a request through the service
• service identifies which system holds the required information
• data is retrieved from that system
• response is returned and used as part of the clinical workflow

This allows teams to access relevant information from other organisations without needing direct point-to-point integrations between systems.

To deliver a complete solution, most use cases require integration with other NHS services and APIs. These services typically work together to support different parts of the process, such as identifying patients, locating systems, and exchanging information.

The examples below show common dependencies, how they are used, and where you may need to combine or choose between them depending on your use case. You can explore how these services work together in practice in the implementation and integration guidance.

You may also want to consider other services that perform similar functions to this, depending on your use case.

• What this service does
• When to use this service
• Service availability
• Implementation and integration