Overview of the different types of deployment topologies for GP Connect clients
Important: The topologies depicted are illustrative rather than prescriptive, and a real world implementation may have a mix of styles.
Important: The Spine Security Proxy (SSP) includes a mechanism to filter out all requests between organisations that are not registered on the proxy as having a mutual data sharing agreement. Without this, all GP Connect consumers would be able to send requests to all GP Connect providers. For the filtering solution to work, each consumer/provider organisation needs an ASID registered on the SSP.
Consumer topologies
Simple model
A grouping of different GP Connect consumer systems, all connecting directly to GP Connect via the SSP. Each consumer in this example is registered as a CMA endpoint. The key point is that each consumer system has its own ASID.
Aggregator model
Several different consumer systems connecting to GP Connect via middleware (Message Handling Server / MHS)
Provider topologies
Single practice system
A discrete instance of a Primary Care System serving a single GP Practice.
Data centre hosted practice system
A GP Practice system instance hosted in a Primary Care System (PCS) supplier’s data centre. Note each individual practice has a logical CMA endpoint with its own ASID but sharing the Party Key.
Spine endpoint terms
| ASID | Accredited system identifier. A unique number allocated to a system on accreditation for connection to Spine. |
| CMA endpoint | Combined MHS and accredited system endpoint. An endpoint registered with Spine for a single system. |
| MHS | Message handling server. A middleware that handles messaging to/from Spine. |
| MHS endpoint | An endpoint registered with Spine for use with multiple systems via an MHS. Each system has its own ASID. |
| Party Key | The identity of a MHS handling messages for an Accredited System |
