No response from e-RS Reject API call

e-Referral Service (e-RS) e-Referral Service FHIR API
1

We’re experiencing an issue with e-RS actioning/triage in a customers TEST ring, it works fine in our DEV ring. See the below test case for a e-RS Reject for the following referral. To the best of my knowledge we’re not receiving a response to this message, ok 200 or error, and we’re wondering whether you can let us know firstly whether you’re receiving this message and secondly whether you’re responding to us.
We’re unsure whether it could be the TEST ring blocking the message or the NHS not responding.

Patient: Olaf Hopley
UBRN - 0000 4983 1871
e-RS Service: Ophthalmology Service - Test MTUK - MEH - RP6
Service ID: 6711431

Our outbound message:

POST /referrals/FHIR/STU3/ReferralRequest/000049831871/$ers.rejectReferral HTTP/1.1accept: application/fhir+jsonContent-Type: application/fhir+jsonNHSD-End-User-Organisation-ODS: RP6NHSD-eRS-Business-Function: SERVICE_PROVIDER_CLINICIANIf-Match: W/"7
"X-Correlation-ID: e6880921-63e2-4236-b383-cde099ed9ce9Authorization: **[MASKED]**Bearer Nz0RGeFqAuKnYjNlGGNOAifw48R5Host: int.api.service.nhs.ukContent-Length: 398{“resourceType”:“Parameters”,“parameter”:[{“valueCoding”:{“system”:“https://int.api.se
rvice.nhs.uk/referrals/FHIR/STU3/CodeSystem/APPOINTMENT-CANCELLATION-REASON”,“code”:“SERVICE_INAPPROPRIATE”},“name”:“rejectionReason”},{“name”:“rejectionComments”,“valueString”:“Out of the area unfortunately.”}],“meta”:{“profile”:[“https://fhir.nhs.u
k/STU3/StructureDefinition/eRS-RejectReferral-Parameters-1”]}}

2

Hi Stuart,

Thanks for your query.

I can confirm we are receiving your reject referral message and are responding with an HTTP 200. The logs show the request was successfully processed and the referral was rejected.

However, I did see a “Connection reset by peer” error in our gateway logs at the time of your request, which indicates your client closed the connection before our response was delivered.

The $ers.rejectReferral operation involves a synchronous PAS message exchange as part of the rejection workflow, which means it can take longer than other API calls. This is likely why it works in your DEV ring but not TEST as the timeout configuration may differ between the two.

Could you let us know what HTTP client timeout is currently n your test ring?

To confirm, the reject was actioned and the referral is now in a rejected state.

Kind regards,

George

3

Hi,
In both our DEV and the customer TEST rings Accept has a 10 second timeout and Reject has a 30 second timeout. DEV and TEST don’t share the same machines though so it could be hardware differences causing the different results

4

Hi Stuart,

Thanks for confirming. That explains the issue. Your reject request took ~35 seconds to complete on our side, therefore exceeding your 30-second timeout causing the connection to drop before the response.

The $ers.rejectReferral operation can often exceed 30 seconds, therefore we’d recommend increasing your reject timeout to >60 seconds to accommodate these longer operations.

Hope this helps,

Kind regards,

George Craft

5

Thanks for the information. Can I double check two things with you, we have the legacy HL7 interface for booking/cancellation:

  1. Is the $ers.rejectReferral response withheld until the appointment cancellation has completed; does your reject workflow exchange an appointment cancellation message and wait on our response before replying to the reject?
    i.e.
    US YOU
    Reject →
    ← Appt Cancel
    Appt Cancel Response →
    ← Reject response

  2. For our request (X-Correlation-ID e6880921-63e2-4236-b383-cde099ed9ce9), can you see from your logs whether the ~35 s was spent waiting on that cancellation exchange with us, versus internal e-RS processing?

6

Hi Stuart,

To answer your questions:

  1. Yes that flow is exactly right. The reject response is held until the appointment cancellation exchange has completed.

  2. For your specific request, the ~35 seconds breaks down as:

  • eRS internal processing before sending the Appt cancellation: ~0.2 seconds
  • Waiting for your PAS endpoint to respond with Appt cancellation confirmation: ~33.6 seconds
  • eRS internal processing after recieving the confirmation: ~0.9 seconds

So the vast majority of the time was spent waiting for the PRSC_IN140000UK06 response from your PAS endpoint (RP6-824686). Essentially your xAPI client timed out at 30 seconds while waiting for eRS, but eRS was in turn waiting for your own PAS system to confirm the cancellation.

Hope this helps,

George