You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Incumbent providers (e.g. TPP, EMIS, SystemOne) would have to make changes to their GP Connect interface implementations
5
5
in order to deploy GP2GP Adaptor in their infrastructure to support the losing practice scenario - i.e. whereby a
6
-
different practice transfers patient data from the incumbent. In particular, they would need to implement 1.6.0 version
6
+
different practice transfers patient data from the incumbent. In particular, they would need to implement the 1.6.2 version
7
7
that is required by the GPC Consumer and GP2GP adaptors.
8
8
9
-
This business case is not always easy to be accepted by the incumbent providers, as they would have to invest time to
9
+
This business case is not always easy for the incumbent providers to accept, as they would have to invest time to
10
10
make those changes.
11
11
12
-
The motivation for the GP2GP FHIR Request Adaptor is to remove the dependency from incumbent providers to do that work.
12
+
The motivation for the GP2GP FHIR Request Adaptor is to remove the dependency on incumbent providers to do that work.
13
13
The idea is to build an adaptor that could be installed and configured in a New Market Entrant (NME) infrastructure,
14
-
and could work with the incumbent’s GPC < 1.6.0.
14
+
and could work with the incumbent’s GPC < 1.6.2.
15
15
16
-
Adaptor consists of two main components:
16
+
The Adaptor consists of two main components:
17
17
- GPC API Facade
18
18
- GP2GP Translator
19
19
20
-
Both are Java Spring Boot applications, released as separate docker images.
21
-
20
+
Both are Java Spring Boot applications, released as separate Docker images.
22
21
23
22
## Table of contents
24
23
25
24
1.[Guidance for setting up the GP2GP adaptors in INT](/getting-started-instructions.md)
26
25
1.[Guidance for operating the adaptor as a New Market Entrant](/OPERATING.md)
27
-
1.[Guidance on integrating with the adaptors APIs](#endpoints)
26
+
1.[Guidance on integrating with the Adaptor's APIs](#endpoints)
28
27
1.[Guidance for developing the adaptor](/developer-information.md)
29
28
1.[Documentation on how this adaptor maps GP2GP concepts to GPConnect concepts](https://github.com/NHSDigital/patient-switching-adaptors-mapping-documentation)
30
29
@@ -34,15 +33,15 @@ The Adaptor's facade provides two main endpoints for interacting with patient re
34
33
35
34
### POST /Patient/$gpc.migratestructuredrecord
36
35
37
-
The migratestructuredrecord endpoint is the primary endpoint for the adaptor.
36
+
The migratestructuredrecord endpoint is the primary endpoint for the Adaptor.
38
37
This endpoint initiates the electronic health record (EHR) transfer process.
39
38
To use this endpoint, you need to provide the following headers:
40
39
41
40
- TO-ASID : ASID identifier of the losing incumbent
42
41
- FROM-ASID : ASID identifier of the winning New Market Entrant (NME)
43
42
- TO-ODS : ODS identifier of the losing incumbent
44
43
- FROM-ODS : ODS identifier of the winning New Market Entrant (NME)
45
-
- ConversationId : A unique UUID for the request. If not provided, the adaptor will generate one and include it in the response headers.
44
+
- ConversationId : A unique UUID for the request. If not provided, the Adaptor will generate one and include it in the response headers.
46
45
It must be used for all further calls for the patient's NHS number.
47
46
48
47
If a `ConversationId` header is provided where the value is populated but does not contain a valid UUID, then the
@@ -64,7 +63,7 @@ following response will be returned:
64
63
"display": "Bad request"
65
64
}]
66
65
},
67
-
"diagnostics": "ConversationId header must be either be empty or a valid UUID"
66
+
"diagnostics": "ConversationId header must either be empty or a valid UUID"
68
67
}]
69
68
}
70
69
```
@@ -73,7 +72,7 @@ For more details on how to query the losing practice details, see the [requestin
73
72
74
73
[requesting site requirements]: https://nhse-dsic.atlassian.net/wiki/spaces/DCSDCS/pages/12512034968/GP2GP+Requesting+Adaptor#Registration-Process-&-EHR-Request
75
74
76
-
The endpoint also requires a JSON body that includes the needed patient NHS number.
75
+
The endpoint also requires a JSON body that includes the patient's NHS number.
77
76
Request Body Example:
78
77
79
78
```json
@@ -103,13 +102,13 @@ Request Body Example:
103
102
Responds with one of:
104
103
105
104
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.
106
-
2. Polling the request: after receiving a 202 response, we recommend polling the endpoint at regular intervals using an
105
+
2. Polling the request: After receiving a 202 response, we recommend polling the endpoint at regular intervals using an
107
106
increasing call gap strategy until you get a 200 response.
108
107
Each poll can return one of the following responses:
109
108
- 204 No content: this response indicates that we are still processing the requests / waiting for the EHR message response.
110
109
- 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.
111
110
An example of this response can be found within [expectedBundle.json](gp2gp-translator/src/integrationTest/resources/json/expectedBundle.json).
112
-
- 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...
111
+
- 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...
113
112
114
113
```json
115
114
{
@@ -145,7 +144,7 @@ Responds with one of:
145
144
### POST /$gpc.ack
146
145
147
146
This endpoint finalizes the EHR transfer process.
148
-
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.
147
+
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.
149
148
150
149
To use this endpoint, you need to provide the following headers:
151
150
@@ -159,21 +158,21 @@ Endpoint calling:
159
158
This endpoint is a fire-and-forget endpoint.
160
159
- If your request is successful, you will get a 200: Success response.
161
160
- If your request is unsuccessful, you will get a 500: Server error response.
162
-
- 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.
161
+
- 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.
163
162
164
163
## Licensing
165
-
This code is duallicensed under the MIT license and the OGL (Open Government License).
164
+
This code is dual-licensed under the MIT license and the OGL (Open Government License).
166
165
Any new work added to this repository must conform to the conditions of these licenses.
167
-
In particular this means that this project may not depend on GPL-licensed or AGPL-licensed libraries,
166
+
In particular, this means that this project may not depend on GPL-licensed or AGPL-licensed libraries,
168
167
as these would violate the terms of those libraries' licenses.
169
168
170
-
The contents of this repository are protected by Crown Copyright (C).
0 commit comments