Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

System topologies

Overview of the different types of deployment topologies for GP Connect providers and consumers

Consumer topologies

Consumer system - shared MHS

Consumer topology 2

Several consumer systems connecting to GP Connect via a shared message handling server.

This is a typical deployment for an area based or regional portal, where a central system/TIE (Trust Integration Engine) acting as the message handling server connects to Spine for multiple organisations.

Please note:

  • each consumer system using GP Connect MUST have a unique ASID for each organisation that is using it, in order that messages flowing through Spine can be correctly identified back to the originating organisation
  • consumer systems in the shared MHS topology have one Party Key shared amongst connecting organisations

Consumer system - separate MHS

Consumer topology 1

Several consumer systems connecting to GP Connect via their own message handling servers.

This could be different types of consumer systems, or the same type of consumer system deployed as separate instances.

Please note:

  • each consumer system using GP Connect MUST have a unique ASID for each organisation that is using it, in order that messages flowing through Spine can be correctly identified back to the originating organisation
  • consumer systems using the separate MHS topology each have their own Party Key

Provider topologies

Provider system - shared MHS

Provider topology 2

Multiple GP practice systems using a shared message handling server.

This is a typical deployment for a multi-tenanted data centre hosted GP system serving multiple organisations.

Please note:

  • each provider system using GP Connect MUST have an ASID AND Party Key for each organisation that is using it, in order that messages flowing through Spine can be routed to the correct destination organisation
  • each Party Key/ASID combination MUST be registered in SDS as a CMA endpoint

Provider system - separate MHS

Provider topology 1

Discrete instances of GP practice systems each serving a single GP practice, and each with their own message handling server.

Please note:

  • each provider system using GP Connect MUST have an ASID AND Party Key for each organisation that is using it, in order that messages flowing through Spine can be routed to the correct destination organisation
  • each party key/ASID combination MUST be registered in SDS as a CMA endpoint

Spine/SDS terminology

LDAP Lightweight Directory Access Protocol. A protocol for accessing directory services
SDS Spine Directory Service. A directory held in Spine containing accredited Spine system identifiers, endpoints, and other reference information; accessed by LDAP
MHS Message handling server. Middleware that handles messaging to/from Spine. See System topologies for more information
MHS record LDAP object of type nhsMhs in SDS, uniquely identified by Party key, and representing a message handling server
Party key The unique identifier of an MHS record
AS record LDAP object of type nhsAs in SDS, uniquely identifier by ASID, and representing a Spine connected system deployed at an organisation
ASID Accredited system identifier. A unique identifier allocated to a system at an organisation for connection to Spine. Uniquely identifies an AS record in SDS
CMA type endpoint A way of registering MHS and AS record for a system at a single organisation which creates a Party Key and ASID for use only at that organisation
MHS type endpoint An endpoint registered with Spine for use with multiple systems via an MHS. Each system has its own ASID
Tags: integration

All content is available under the Open Government Licence v3.0, except where otherwise stated