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 then the GP2GP process cannot proceed as the Sending Site end point has not been identified.

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

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

Post integration checks

Requirement ID

GP2GP_Req_75

All problem links, where possible, are to be retained. Further information can be found in the GP Connect Linkages

MUST

GP2GP_Req_76

All incoming clinical codes from that of the Sending system to that of the Receiving system are converted (using approved mapping tables or use of translations as instructed by the Authority’s interoperability team.)

MUST

GP2GP_Req_77

The Requesting System degrades appropriately, codes for which a mapping does not exist (please refer to the ‘Handling Degrades section of this document for further information)

MUST

GP2GP_Req_78

The Requesting System de-activates all active repeat medications on import into the active record and flags them for manual processing. Such flags are readily visible to, and/or brought to the attention of, clinicians processing the medication records so that they take responsibility for any re-authorisations and if necessary be validated with the Patient.

MUST

GP2GP_Req_79

The Requesting System flags any current medications that have been degraded on import into the active record so that clinicians can re-code any that are clinically appropriate.
Further information can be found in the GP Connect Medication Guidance

MUST

GP2GP_Req_80

Where any Drug Allergies have been degraded on import into the active record, the Requesting System flags these and prevents the prescribing of any medication for the Patient until the degraded items have been either re-coded or removed from the record.
Further information can be found in the GP Connect Allergies Guidance

MUST

GP2GP_Req_81

Following a successful automatic integration, the Requesting System adds an administrative entry to the current EHR, advising Users who view the EHR that a GP2GP EHR has been automatically integrated. The timestamp for the administrative entry will match the time and date at which the automatic integration was completed. This entry will be carried forward to new transfers. It will drop down the journal view over time and become less prominent.

The following SNOMED CT code should be used for this administrative entry

SCTID: 715411000000103; Record transfer administration (record artifact)

MUST

GP2GP_Req_82

The Requesting System could implement other optional post integration actions/workflow beyond those listed in these requirements, for example:

• Alerts to all, or other degraded items such as observations, referrals etc.

• Alerts to failed documents

• Alerts to any chronic conditions

These could be configurable for the user(s) at the Requesting Site (i.e. turned on or off at GP Practice level)

MAY

Returning Patients

Requirement ID

GP2GP_Req_83

The Requesting system identifies a returning Patient (known as an A-B-A scenario) by using the local index(es), not PDS. A Returning Patient is defined as:

A Patient who has an existing permanent Patient record within the system prior to this registration.

MUST

GP2GP_Req_84

For returning Patients, when an EHR is received from the Sending System, then any new information that has been added to the EHR since the Patient last left the practice is to be copied into the record that already exists in the Requesting System

MUST

GP2GP_Req_85

The Requesting system, when copying content added to a returning Patient’s record since the Patient’s record last left the practice, copy additions to the Patient’s record based on comparing date of the addition with date of the record leaving the practice.

MUST

GP2GP_Req_86

For returning Patients, in addition to the administrative entry requirement in Step 17 SCTID: 715411000000103; Record transfer administration (record artifact), the Requesting System advises Users who view the record that:

●       The GP2GP record has been automatically integrated for a returning Patient.

●       A summary of what information will have been copied into the local EHR and what would not.

●       The user should check the received GP2GP EHR for information that has not been imported into the core record with a prompt on how to access the information.

Note: The administrative entry content will be the same static text for all returning GP2GP EHRs and is not expected to be detailed information that is unique to each Patient record.

MUST

GP2GP_Req_87

The Requesting system provides the user with the ability to view both the received EHR Extract and the Patient’s previous record in a suitably rendered form (i.e. not raw XML) for the user to review.

MUST

GP2GP_Req_88

The Requesting system provides the user with the ability to compare the received EHR Extract and the Patient’s previous record in a suitably rendered form (i.e. not raw XML) for the user to review.

SHOULD

Handling Degrades

Requirement ID

GP2GP_Req_89

The Requesting system handles degrades as set out in the GP2GP “NPFIT-PC-BLD-0132.03 GP2GP Supplementary Specification on Structured Degrade Handling”.

Open

MUST

Audit

Requirement ID

GP2GP_Req_90

Following an automatic integration, the Requesting System adds an entry to the Audit trail as a system action to record that the GP2GP record has been automatically integrated.

MUST

GP2GP_Req_91

The Requesting System retains the EHR received from the GP2GP Requesting Adaptor in its entirety for audit purposes (the below is from the existing GP2GP requirements, 5.6 Processing and Acknowledging a Received EHR Extract, from GP2GP Requirements Specification 2.2)

This is defined more specifically as:

·       3 years on-line

·       A further 4 years off-line recoverable within 1 working day (yrs 4 – 10)

·       A further 20 years off-line recoverable within 1 working week (years 11 – 30)

The system supplier shall ensure that the Audit Trail is retained for the entire retention period of the records audited, to enable investigations to be carried out when necessary and provide evidence where required by the Authority.

MUST

Internal Transfers

Requirement ID

GP2GP_Req_92

Where a clinical system is installed at more than one GP Practice it has a method agreed with NHS England that allows an internal transfer of a Patients record that results in a lossless native transfer.

MUST

GP2GP_Req_93

All the requirements in Steps 1, 2, and 5 apply to any internal transfer (Registration, PDS Trace and PDS Update respectively)

MUST

GP2GP_Req_94

The requirements in Step 4 apply but may be sourced from the clinical system rather than the ODS API

MUST

GP2GP_Req_95

It is assumed that the requirements in Step 18 (post integration actions) regards degrades should be irrelevant if this is a native lossless transfer, but the de-activation of all active repeat medications and the creation of tasks is still mandatory so as not to introduce any clinical risk.

MUST

User Experience

Requirement ID

GP2GP_Req_96

It is not possible to either delete or archive the mandatory tasks generated via the GP2GP process detailed in these requirements for the user .

This is because all tasks detailed in these requirements relate to clinical safety of continuity of care for the Patient and the safe movement of their record.

MUST

GP2GP_Req_97

Where a clinical system supplier provides a dashboard/report of all registrations and deductions it would be beneficial to include the GP2GP status alongside any NHAIS registration status

SHOULD

The following requirements and user stories are taken from the GP2GP Automatic Integration Specification and support the user stories below this table which are also taken from the requirements.

GP2GP_Req_98

The Requesting System provides a facility that allows a User, should they need to, to easily identify records that are new to their practice and have not been reviewed by a user.

See existing requirement IDs S75, S76, S77 HSCIC-PC-BLD-0068 26 GP2GP R2 2 Requirements Specification v7.2

MUST

GP2GP_Req_99

The Requesting System provides a facility that allows a User to mark that a record has been reviewed post automatic integration.

MUST

GP2GP_Req_100

The Requesting System provides, within the record, an indicator on whether or not a record has been reviewed post automatic integration. This is be visible to all users accessing the record. The indicator doesn't obstruct the user from viewing/using the record i.e. must not be a popup that requires the user to dismiss. The indicator is not be included in future GP2GP transfers.

MUST

Row 1

Header

The following attachment could not be retrieved via GP2GP when the Patient registered

N/A

Name

Element

Resource

Row 2

Internal Supplier ID:

id

Record Bundle Document Reference

Row 3

GPC Document Identifier:

identifier

Record Bundle Document Reference

Row 4

Document Description:

description

Record Bundle Document Reference

Row 5

Patient NHS no.

nhs-number

Patient Resource Reference

Row 6

Date created:

created

Record Bundle Document Reference

Row 7

Author:

author (name of)

Organisation and Practitioner Reference

Row 8

Owning organisation:

custodian (ODS code and name of GP Practice)

Organisation and Practitioner Reference

Row 9

Size

content.attachment.size

Record Bundle Document Reference

Row 10

Content

content.format

Record Bundle Document Reference

1

2

3

4

The following file could not be included with the Electronic Record:

[Original filename and suffix]

[ODS Code of practice generating attachment]:[ConversationID for that transfer]

Reason:[Reason Code]:[Reason Description]

The following file could not be included with the Electronic Record:

Smith_Edward_1999_Oct_12_R46TW39.doc

P86001:21EC2020-3AEA-1069-A2DD-08002B30309D

 Reason:03:File not found

Items on the Roadmap which impact or relate to this Standard