Skip to content

NIAD-3435: Documentation improvement #1254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ORybak5 merged 7 commits into from
Mar 23, 2026
Merged

NIAD-3435: Documentation improvement #1254

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
7c7ea37
Documentation improvement
ORybak5 Mar 19, 2026
10d1485
README.md improvement
ORybak5 Mar 20, 2026
e6942bf
README.md letter capitalization improvements
ORybak5 Mar 20, 2026
d90962c
README.md letter capitalization improvements
ORybak5 Mar 20, 2026
ca48350
REDACTIONS.md enhancements
ORybak5 Mar 20, 2026
8ce539c
getting-started-with-windows.md docs update
ORybak5 Mar 20, 2026
fbd84f9
GPC Consumer version adjustment
ORybak5 Mar 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 27 additions & 28 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,28 +3,27 @@ National Integration Adaptor - [GP2GP Requesting Adaptor](https://digital.nhs.uk

Incumbent providers (e.g. TPP, EMIS, SystemOne) would have to make changes to their GP Connect interface implementations
in order to deploy GP2GP Adaptor in their infrastructure to support the losing practice scenario - i.e. whereby a
different practice transfers patient data from the incumbent. In particular, they would need to implement 1.6.0 version
different practice transfers patient data from the incumbent. In particular, they would need to implement the 1.6.2 version
that is required by the GPC Consumer and GP2GP adaptors.

This business case is not always easy to be accepted by the incumbent providers, as they would have to invest time to
This business case is not always easy for the incumbent providers to accept, as they would have to invest time to
make those changes.

The motivation for the GP2GP FHIR Request Adaptor is to remove the dependency from incumbent providers to do that work.
The motivation for the GP2GP FHIR Request Adaptor is to remove the dependency on incumbent providers to do that work.
The idea is to build an adaptor that could be installed and configured in a New Market Entrant (NME) infrastructure,
and could work with the incumbent’s GPC < 1.6.0.
and could work with the incumbent’s GPC < 1.6.2.

Adaptor consists of two main components:
The Adaptor consists of two main components:
- GPC API Facade
- GP2GP Translator

Both are Java Spring Boot applications, released as separate docker images.

Both are Java Spring Boot applications, released as separate Docker images.

## Table of contents

1. [Guidance for setting up the GP2GP adaptors in INT](/getting-started-instructions.md)
1. [Guidance for operating the adaptor as a New Market Entrant](/OPERATING.md)
1. [Guidance on integrating with the adaptors APIs](#endpoints)
1. [Guidance on integrating with the Adaptor's APIs](#endpoints)
1. [Guidance for developing the adaptor](/developer-information.md)
1. [Documentation on how this adaptor maps GP2GP concepts to GPConnect concepts](https://github.com/NHSDigital/patient-switching-adaptors-mapping-documentation)

Expand All @@ -34,15 +33,15 @@ The Adaptor's facade provides two main endpoints for interacting with patient re

### POST /Patient/$gpc.migratestructuredrecord

The migratestructuredrecord endpoint is the primary endpoint for the adaptor.
The migratestructuredrecord endpoint is the primary endpoint for the Adaptor.
This endpoint initiates the electronic health record (EHR) transfer process.
To use this endpoint, you need to provide the following headers:

- TO-ASID : ASID identifier of the losing incumbent
- FROM-ASID : ASID identifier of the winning New Market Entrant (NME)
- TO-ODS : ODS identifier of the losing incumbent
- FROM-ODS : ODS identifier of the winning New Market Entrant (NME)
- ConversationId : A unique UUID for the request. If not provided, the adaptor will generate one and include it in the response headers.
- ConversationId : A unique UUID for the request. If not provided, the Adaptor will generate one and include it in the response headers.
It must be used for all further calls for the patient's NHS number.

If a `ConversationId` header is provided where the value is populated but does not contain a valid UUID, then the
Expand All @@ -64,7 +63,7 @@ following response will be returned:
"display": "Bad request"
}]
},
"diagnostics": "ConversationId header must be either be empty or a valid UUID"
"diagnostics": "ConversationId header must either be empty or a valid UUID"
}]
}
```
Expand All @@ -73,7 +72,7 @@ For more details on how to query the losing practice details, see the [requestin

[requesting site requirements]: https://nhse-dsic.atlassian.net/wiki/spaces/DCSDCS/pages/12512034968/GP2GP+Requesting+Adaptor#Registration-Process-&-EHR-Request

The endpoint also requires a JSON body that includes the needed patient NHS number.
The endpoint also requires a JSON body that includes the patient's NHS number.
Request Body Example:

```json
Expand Down Expand Up @@ -103,13 +102,13 @@ Request Body Example:
Responds with one of:

1. Initial request: If you successfully configure the endpoint described above and call it, you should receive a 202-accepted response. This means the adaptor has received the request and is making the relevant requests.
2. Polling the request: after receiving a 202 response, we recommend polling the endpoint at regular intervals using an
2. Polling the request: After receiving a 202 response, we recommend polling the endpoint at regular intervals using an
increasing call gap strategy until you get a 200 response.
Each poll can return one of the following responses:
- 204 No content: this response indicates that we are still processing the requests / waiting for the EHR message response.
- 200 Success: this response indicates we have successfully received and converted the EHR to JSON; you will also receive the FHIR bundle in the response's body.
An example of this response can be found within [expectedBundle.json](gp2gp-translator/src/integrationTest/resources/json/expectedBundle.json).
- 400,404,500,501: The endpoint can return all these possible error codes. These will all provide a detailed error with an operationOutcome JSON model response in the body. This looks like...
- 400,404,500,501: The endpoint can return all these possible error codes. These will all provide a detailed error with an OperationOutcome JSON response in the body. This looks like...

```json
{
Expand Down Expand Up @@ -145,7 +144,7 @@ Responds with one of:
### POST /$gpc.ack

This endpoint finalizes the EHR transfer process.
If you do not call this endpoint after receiving an EHR from the migratestructuredrecord enpoint, then you risk the losing practise triggering off the manual postal transfer.
If you do not call this endpoint after receiving an EHR from the migratestructuredrecord endpoint, then you risk the losing practice triggering the manual postal transfer.

To use this endpoint, you need to provide the following headers:

Expand All @@ -159,21 +158,21 @@ Endpoint calling:
This endpoint is a fire-and-forget endpoint.
- If your request is successful, you will get a 200: Success response.
- If your request is unsuccessful, you will get a 500: Server error response.
- If you receive a 500 response, you can retry again at any point, however, it should be noted that you must receive a 200: Success response from the migratestructuredrecord for the given conversation ID to receive a 200: Success from this endpoint.
- If you receive a 500 response, you can retry at any point, however, it should be noted that you must receive a 200: Success response from the migratestructuredrecord for the given conversation ID to receive a 200: Success from this endpoint.

## Licensing
This code is dual licensed under the MIT license and the OGL (Open Government License).
This code is dual-licensed under the MIT license and the OGL (Open Government License).
Any new work added to this repository must conform to the conditions of these licenses.
In particular this means that this project may not depend on GPL-licensed or AGPL-licensed libraries,
In particular, this means that this project may not depend on GPL-licensed or AGPL-licensed libraries,
as these would violate the terms of those libraries' licenses.

The contents of this repository are protected by Crown Copyright (C).
The contents of this repository are protected by Crown Copyright ©.

## Performance

Case 1: Performance Testing with JMeter

We conducted a performance test of the Adaptor using the JMeter tool.
A performance test of the Adaptor was conducted using the JMeter tool.
The use case focused on simulating a patient transfer request,
where Electronic Health Record (EHR) requests were sent to the Adaptor, expecting a bundle in return.
This test involved two text attachments with sizes of 2.44 MB and 0.7 MB, respectively.
Expand Down Expand Up @@ -202,7 +201,7 @@ indicating sufficient capacity for additional load.
Case 2: Performance Testing via TPP/EMIS and Medicus

In a separate series of tests, up to 10 concurrent patient transfers were completed,
involving varying attachment types (100, 500, 1000) and file sizes (1 KB, 100 KB, 500 KB, 3.5 MB, 5 MB).
involving varying attachment counts (100, 500, 1000) and file sizes (1 KB, 100 KB, 500 KB, 3.5 MB, 5 MB).
These tests were conducted with TPP/EMIS as the sending systems and Medicus as the receiving system.

Resource Allocation:
Expand All @@ -219,18 +218,18 @@ Message Queue:
Results:

A single patient record of 10 MB was processed in approximately 20 seconds.
On average, the transfer of up to 10 patients was completed within 1 to 1 minute and 40 seconds.
On average, the transfer of up to 10 patients was completed within 1 minute to 1 minute and 40 seconds.


![report1.jpg](test-suite%2Fnon-functional-tests%2Ftest-scenario%2Fperf_report%2Freport1.jpg)
![report1.jpg](test-suite/non-functional-tests/test-scenario/perf_report/report1.jpg)

Overall performance statistics:
![report2.png](test-suite%2Fnon-functional-tests%2Ftest-scenario%2Fperf_report%2Freport2.png)
![report2.png](test-suite/non-functional-tests/test-scenario/perf_report/report2.png)

Active transfers per one iteration was 400:
![report4.png](test-suite%2Fnon-functional-tests%2Ftest-scenario%2Fperf_report%2Freport4.png)
Active transfers per iteration were 400:
![report4.png](test-suite/non-functional-tests/test-scenario/perf_report/report4.png)

Response time:
![report5.png](test-suite%2Fnon-functional-tests%2Ftest-scenario%2Fperf_report%2Freport5.png)
![report5.png](test-suite/non-functional-tests/test-scenario/perf_report/report5.png)

Results can be seen in using graphs by importing results8.jtl into Jmeter.
Results can be visualised by importing results8.jtl into JMeter.
Loading
Loading