Patient Registration

Requirement ID

GP2GP_Req_01

Only Patients registering for GMS1 Permanent registrations qualify for the electronic transfer of Patient records (GP2GP). Any other Patient registration type (e.g. temporary/private) does not qualify for GP2GP.

MUST

GP2GP_Req_02

If the Patient was registered at the Requesting site under any other registration status (e.g. private or temporary) and then applies to become a GMS1 Permanent Patient, it is necessary for the Requesting system to still initiate the request for the EHR from the Sending site.

MUST

GP2GP_Req_03

The Requesting System will limit access to perform permanent Patient registrations, PDS Advanced Trace and PDS General Update interactions to only users who have the appropriate RBAC permissions as defined in the PDS requirements.

MUST

GP2GP_Req_04

If there is no response from PDS (it is unavailable and error has been received) then the user would benefit from being prompted to contact the National Help Desk or their Clinical System Supplier Help Desk to resolve the issue.

The GP2GP process will end until such time is PDS available and a user with appropriate permissions logs in again to perform a PDS trace to find and register the Patient.

SHOULD

GP2GP_Req_05

In the exceptional scenario where PDS is unavailable, and there is a critical need to record information about the Patient, functionality is accessible to allow a user to electronically record information about the Patient until such time as PDS is available so as to provide continuity of care.

MUST

PDS Trace

Requirement ID

GP2GP_Req_06

The user will now need to search for the Patient on PDS in line with their guidance:

Personal Demographics Service - FHIR API

MUST

GP2GP_Req_07

The Requesting system will not automatically select a Patient from the search results, irrespective of the number of results.

i.e. if only one Patient is returned they should not be auto-selected.

MUST

GP2GP_Req_08

The user needs to select a Patient from the PDS trace results if they wish to continue the registration.

If the PDS search fails to identify the Patient then then there is no previous registration available and no transfer of an EHR is possible.

MUST

GP2GP_Req_09

If the PDS record is flagged as ‘sensitive’ then it cannot be updated and the electronic transfer of the EHR cannot proceed. There is a separate manual process via National Back Office and PCSE to deal with the transfer of Patients records who are flagged as sensitive.

MUST

Lookup previous ODS code

Requirement ID

GP2GP_Req_10

If the user identifies and selects a Patient from the PDS trace that is unique and not ‘sensitive’ then the Requesting System will need to store and persist the data item generalPractitioner field on PDS. This is the ODS code of the Patients current registered GP Practice and this will be used to identify and make the electronic request for the transfer from that site.

MUST

 GP2GP_Req_11

If the generalPractitioner ODS Code is the same as the Requesting Site then the electronic transfer of the EHR process ends. This is because the Patient is already registered at the practice.

MUST

GP2GP_Req_12

If the generalPractitioner ODS Code of the Sending Site is identified as a GP Practice on the same GP Clinical System as the Requesting Site, then the Requesting System will follow the requirements as described in the ‘Internal Transfers’ requirements found on this page.

MUST

GP2GP_Req_13

Should the generalPractitioner data item be null, then the Requesting System queries the PDS managingOrganisation field. If this is populated with an ODS code, it will then store this value. This will be the ODS code of either the Patients last previous registered GP Practice or the NHS England repository (Please see Appendix C for more details).

MUST

Lookup previous ODS code

Requirement ID

GP2GP_Req_14

The Requesting System will now retrieve the following details of the previous GP Practice using the ODS API:

• Practice Name

• Practice Address

• Practice Telephone number

This is purely so the user has access to information that may help them in contacting the Sending System in case of any issues with the EHR transfer.

MUST

 GP2GP_Req_15

The Requesting System will display the previous practice details obtained to the user registering the Patient.

MUST

GP2GP_Req_16

This information needs to be cached and the most up to date details made available. This is to allow any necessary follow up should the user need to contact the previous GP Practice.

MUST

GP2GP_Req_17

The failure to obtain the previous GP Practice details from ODS does not prevent the Requesting System from initiating the electronic transfer of the EHR from the Sending Site.

MUST

Update PDS

Requirement ID

GP2GP_Req_18

Once the user has selected a Patient to be registered the Requesting System will update PDS (after obtaining the Sending Practice ODS code from PDS as in Step 3). This will set the Patients GP Practice code to that of the Requesting System (the GP Practice the Patient is registering at) on PDS and the registration date.

MUST

 GP2GP_Req_19

The PDS update interaction is an synchronous transaction and the Requesting System waits for a PDS Successful Update Response.

MUST

GP2GP_Req_20

If an error is received indicating a failure to update PDS, then the GP2GP process ends as the Patient has not been registered.

MUST

GP2GP_Req_21

If an error is encountered updating PDS the user is to be prompted to contact the National Help Desk or their Clinical System Supplier Help Desk to resolve the issue.

Note: PDS system retries are not possible, but if the user is present and logged in with the appropriate RBAC permissions they may attempt to re-register the Patient.

SHOULD

GP2GP_Req_22

On receiving a PDS Successful Update Response the following steps are now triggered by the Requesting System to transfer the EHR using the GP2GP Requesting Adaptor

MUST

Retrieve ASID details

Requirement ID

GP2GP_Req_23

The Requesting System performs the GP2GP process only with the previously registered GP Practice ODS details retrieved in Step 3 obtained from PDS.

MUST

 GP2GP_Req_24

The Requesting System queries SDS for the Patients previous GP Practice ASID (Accredited System Identifier) which is needed to create the request to the GP2GP Requesting Adaptor GPC API Facade endpoint.

To query SDS for the Provider ASID it will need

• The previous GP Practice ODS code obtained from PDS in Step 3

• The GP2GP Service Identifier: urn:nhs:names:services:gp2gp:RCMR_IN010000UK05

Further detail on the SDS API can be found here Spine Directory Service - FHIR API

MUST T

GP2GP_Req_25

If the lookup to SDS fails or no ASID exists for any reason (e.g. the previous practice was a Defence Medical Services that does not support GP2GP) then the GP2GP process cannot proceed as the Sending Site end point has not been identified. The GP2GP status for this transfer in the workflow will be marked as ‘failed’ and will indicate that the user must contact the Sending Site as no GP2GP request was made.

MUST

GP2GP_Req_26

The Requesting System is permitted to perform a retry of the lookup to SDS if the error returned is a timeout.

MAY

GP2GP_Req_27

If the error persists the user is to be prompted that an error has occurred and the GP2GP process will not proceed until the system issue has been resolved.

SHOULD

GP2GP_Req_28

The failure to perform the lookup on SDS results in the automatic generation of a ticket to the Requesting System Service Desk

SHOULD

GP2GP_Req_29

If the SDS lookup is successful then the Requesting System will need to build the request for the GP2GP Requesting Adaptor

MUST

Retrieve ASID details

Requirement ID

GP2GP_Req_30

The Requesting System now constructs and posts the bespoke migratestructuredrecord request to the Requesting Adaptor GPC API Facade endpoint URL (POST /Patient/$gpc.migratestructuredrecord)

The following is required to call this endpoint

• TO_ASID: The ASID identifier of the Requesting Site

• FROM_ASID: The ASID identifier of the Sending Site

• TO_ODS: The ODS identifier of the Requesting Site

• FROM_ODS: the ODS identifier of the Sending Site

• ConversationId : A unique GUID for each request; if a ConversationId is not provided, the Requesting Aadaptor will create one and return it in the response headers.

MUST

GP2GP_Req_31

The Requesting System uses only the Sending System (Providers) ASID as obtained from the SDS Query in Step 6 and the Sending System (Providers) ODS code obtained from Step 3.

MUST

GP2GP_Req_32

The ConversationId is retained by the Requesting System and used for all further calls for the Patient’s NHS number (this EHR transfer)

MUST

 GP2GP_Req_33

The endpoint also requires a JSON body that includes the Patient NHS number. The format of the body is as follows:

{
"resourceType": "Parameters",
"parameter": [
{
"name": "PatientNHSNumber",
"valueIdentifier": {
"system": "https://fhir.nhs.uk/Id/nhs-number",
"value": "{{nhs-number-test-group-8}}"
}
},
{
"name": "includeFullRecord",
"part": [
{
"name": "includeSensitiveInfomation",
"valueBoolean": true
}
]
}
]
}

MUST

GP2GP_Req_34

As soon as the Requesting System has posted the GP C 1.6 migratestructuredrecord request to the Requesting Adaptor GPC API Facade endpoint URL it should receive a 202-accepted response. This means the adaptor has received the request and is validating and making the relevant requests. The Requesting System now begins to poll the endpoint for a response. Polling details are set out in Step 14.

MUST

Retrieve ASID details

Requirement ID

GP2GP_Req_35

It is the responsibility of the Requesting System to ensure that the GP2GP Requesting Adaptor is monitored and available at all times so as to process any GP2GP EHR requests and responses.

MUST

GP2GP_Req_36

As described in Step 7, once the request has been made the Requesting System polls the GP C Façade endpoint of the GP2GP Requesting Adaptor. This is done initially at a a maximum timeframe of 120 seconds

MUST

GP2GP_Req_37

If a HTTP code 204 response is returned the request is in progress and the Requesting Site polls again at regular intervals.

The following are suggested intervals but these can be agreed at the time of assurance:

• 5 minutes

• 10 minutes

• 20 minutes

• 40 minutes

• 60 minutes

• 120 minutes

• 240 minutes

Then continually every 480 minutes.

MUST

GP2GP_Req_38

If a 200 OK/completed GP C HTTP response has been returned and the EHR payload has been successfully delivered then the Requesting System now follows the requirements in Step 15

MUST

GP2GP_Req_39

If the Requesting System identifies any Operational Outcome (error) then it must mark the transfer as failed and the GP2GP process ends. Please see Appendix A (Negative Acknowledgments) for further information.

MUST

GP2GP_Req_40

The Requesting System must make the user aware that the process has failed for this GP2GP transfer and whether they should expect the printed EHR from the Sending Site via PCSE. Please see Appendix A (Negative Acknowledgments) for further information.

MUST

GP2GP_Req_101

Where a GP2GP transfer has failed, the Sending Site may attempt a re-send of the EHR. The Requesting System will need to allow receipt of a re-sent EHR that has the same Conversation ID of the EHR that previously failed. The Requesting System will also update its GP2GP workflow associated with the outcome of the resend (if it fails again or is successful).

must

Validation

Requirement ID

GP2GP_Req_41

When the Requesting System polls the GP C Facade endpoint of the GP2GP Requesting Adaptor and received a 200 completed HTTP Operational Outcome it will then retrieve the FHIR structured record from the GP2GP Requesting Adaptor.

MUST

GP2GP_Req_42

The Requesting System validates the incoming EHR and retrieves all documents before committing the EHR to its database

MUST

GP2GP_Req_43

The Requesting System ensures the structured record bundle is well formed and contains all the necessary resources/profiles

MUST

GP2GP_Req_44

For the avoidance of doubt the validation does not involve any user involvement, it is strictly a system based validation.

MUST

GP2GP_Req_45

The Requesting System ensures that any validation on the incoming record bundles Patient profile does not prevent it from accepting the record without the Patient name*

MUST

GP2GP_Req_46

If the initial validation is successful the Requesting System now identifies and retrieve all associated documents.

MUST

GP2GP_Req_47

If the Requesting System identifies any issues with the GP C structured record bundle provided it will provide the following error to the GP2GP Requesting Adaptor

Endpoint facadelocation/$gpc.ack

With the following:

header fields: confirmationResponse : “failed_to_integrate“, conversationID: “string“

The GP2GP Requesting Adaptor will then convert this to the appropriate HL7 negative acknowledgment:

Error code: 11 [Failed to successfully integrate EHR Extract]

MUST

GP2GP_Req_48

In the case of failure the Requesting System updates the GP2GP transfer status as failed

MUST

GP2GP_Req_49

In the case of failure the Requesting System makes the user aware that validation has failed and no EHR will be available and a printed EHR and attachments will be provided by the Sending Site via PCSE.

MUST

Identify attachments

Requirement ID

GP2GP_Req_50

Having checked that this is a well formed structured record the Requesting System then parses the file and identifies if there are any document references.

MUST

GP2GP_Req_51

The Requesting System now establishes the number of documents within the structured record bundle and creates a cached status against each document.

MUST

GP2GP_Req_52

The Requesting System now attempts to retrieve each document using the URL supplied in the "DocumentReference". This URL will point to the the GP2GP Requesting Adaptor File Storage.

MUST

GP2GP_Req_53

The Requesting System attempts to retrieve all attachments regardless of the size of the attachment (no upper limits are to be set). Please see the section on file size below in Appendix D.

MUST

GP2GP_Req_54

The Requesting System keeps track of each documents status. A document transfer can have a status of

• Completed (successfully retrieved)

• Failed (error)

• In Progress (no outcome has been received or the migrate document request is in progress)

MUST

GP2GP_Req_55

If the Requesting System identifies that either:

• all documents where successfully retrieved

• there are no documents contained in the structured record "DocumentReference"

Then it proceeds to Step 17 (Prepare to integrate)

MUST

GP2GP_Req_56

If the Requesting System encounters an error when trying to retrieve an attachment(s) from the GP2GP Requesting Adaptor storage then it creates an automatic Service Desk alert/ticket for the Requesting System support team.

SHOULD

GP2GP_Req_57

If the issue cannot be resolved within 1 hour, then the Requesting System creates a placeholder. This is so as not to delay the integration of the EHR because of a failed document(s)

MUST

GP2GP_Req_58

The placeholder is a file that is text with a ‘txt’ suffix and MIME type text/plain.

MUST

GP2GP_Req_59

The file is named as follows:

AbsentAttachment_[description]_[Owning Organisation ODS Code]_[Date created].txt

Where [id] is the GP Connect ‘Document Reference Id’ and [description] is the Document Reference ‘Description’.

For example: AbsentAttachment_discharge summary_A12345_18012022.txt

The title is labelled with these data items to make it clear what the document is, when it was created and who was the original owner. This is to help users identifying attachments, especially with the pain point where a record moves from A-B-C, where B has missing attachments from A and then C has missing attachments from both A and B and needs to be able to clearly identify where the missing attachments came from originally.

MUST

GP2GP_Req_60

Within the placeholder file the text is as set out in Appendix D - GP C placeholder.

An example is provided here

Open

MUST

GP2GP_Req_61

Once all placeholders have been created the Requesting System proceeds to Step 17

MUST

GP2GP_Req_62

The Requesting System alerts its users to any placeholders it has created (i.e. document could not be retrieved) and that the user will need to contact the Sending Site should they want a copy. Further information can be found in Appendix D.

MUST

GP2GP_Req_63

If after the record has been integrated (the completion of Step 17) either

• the Requesting System reaches a resolution on the service incident raised in requirement GP2GP_Req_56 and is able to successfully retrieve the attachment

• The user is able to obtain an electronic copy of an attachment from the Sending Site

The Requesting System has the functionality to allow the user to delete the .txt placeholder and insert the retrieved document it related to.

This is because it is preferable to have a placeholder replaced with the actual document so as not to ensure the attachment is available and to prevent the propagation of placeholders in onward transfers

SHOULD

Integrate the EHR

Requirement ID

GP2GP_Req_64

EHRs are automatically integrated by the Requesting system immediately, without delay after they have been received. (As a performance measure, EHRs are to be integrated within 20 minutes of receipt).

MUST

GP2GP_Req_65

Automatic integration is a System based activity, there is no user involvement in triggering the integration task.

MUST

GP2GP_Req_66

Requesting System Users are not prevented from accessing and using the Requesting System whilst the integration system task is being processed.

For example: A User must be able to use the Requesting System to book an appointment, open a EHR or add a consultation whilst the Requesting System is performing integration processes.

MUST

GP2GP_Req_67

The Requesting System handles the following scenarios in such a way as to prevent loss of data during automatic integration:

• The local EHR for a Patient is being accessed or updated by a Requesting System User when a GP2GP EHR is received for the same Patient.

• A Requesting System User attempts to access a local EHR whilst the automatic integration is in progress.

MUST

GP2GP_Req_68

The Requesting System only performs a full integration, there is no concept of a partial integration of the Patients EHR. (e.g. integrating Observations, Medications and not integrating Allergies is not allowed)

MUST

GP2GP_Req_69

If the integration of the record is successful then the Requesting System provides the following success message to the GP2GP Requesting Adaptor:

Endpoint facadelocation/$gpc.ack/

With the following:

header fields: confirmationResponse : “accepted“, conversationID: “string”

The GP2GP Requesting Adaptor will then convert this to the appropriate HL7 Positive acknowledgment

<acknowledgement typeCode = “AA”>

MUST

GP2GP_Req_70

If the automatic integration system task cannot be started, completed or fails to integrate, the Requesting System creates an automatic Service Desk alert/ticket for the Requesting System support team.

SHOULD

GP2GP_Req_71

The Requesting System creates an alert for the user to let them know that the integration has failed and is being investigated along with the ticket ID.

SHOULD

GP2GP_Req_72

The failure to integrate means losing the EHR and fall back to the off system process. To avoid this the Requesting System assigns the issue as a priority and looks to re-integrate the EHR within 72 hours.

SHOULD

GP2GP_Req_73

If no resolution can be found to the issue within 72 hours then the Requesting System will automatically provide the following error to the GP2GP Requesting Adaptor

Endpoint facadelocation/$gpc.ack

With the following:

header fields: confirmationResponse : “failed_to_integrate“, conversationID: “string“

The GP2GP Requesting Adaptor will then convert this to the appropriate HL7 negative acknowledgment

Error code: 11 [Failed to successfully integrate EHR Extract]

This will trigger the Sending Site to print the EHR and all attachments for sending off system via PCSE.

MUST

GP2GP_Req_74

If the 72 hours has eclipsed the Requesting System updates the GP2GP transfer status as failed and makes the user aware that no EHR will be available as integration failed and a printed EHR and attachments will be provided by the Sending Site via PCSE.

MUST

GP2GP_Req_102

When the Requesting System is integrating a re-send of an EHR, it must not overwrite any data that has been entered since the Patient has been registered.

must