Internal Error Message 403 when using API A042

We are testing API A042 in our INT environment but we keep getting the error ‘The remote server returned an error: (403) Forbidden’.’ Referral attachments are not pulling through even when trying to re sync. Please can our end points & ASIDs be checked to ensure there are no gaps or errors? We haven’t done any other internal config which we would anticipate causing this error to appear.

SPINE ERS API APPLICATION ENDPOINT-RH8]

SPINE ERS API USER ENDPOINT-RH8

SPINE ERS API APPLICATION ENDPOINT-RA9

SPINE ERS API USER ENDPOINT-RA9

Hey Abbey,

Could you provide the application ID’s being used to make the calls please?

Have you previously successfully used this endpoint call in the environment before?

Tony

Hi Tony,

RH8 Epic e-RS RAS - INT - e-Referral Service, Application Restricted - 548a2f33-d9e9-4745-b193-acdf454aa8ae

RH8 Epic e-RS RAS - INT - e-Referral Service, Healthcare Worker - 274b4d29-e75c-460f-a33c-5cd753541ea1

RA9 Epic e-RS RAS - INT - e-Referral Service, Application Restricted -c618c1ab-d3b8-4194-a739-6e237bf9f8c9

RA9 Epic e-RS RAS - INT - Healthcare Worker -b0e595e5-4532-4e71-a5d4-3ade921344ab

Hi Tony,

We reached out to EPIC looking at some of the trace files. They have noted this:

<diagnostics>**The ASID (200000002257) does not have the interaction (urn:nhs:names:services:ers:READ_BINARY_R4_V001) required to call this endpoint.**</diagnostics>

This ASID returning in the trace files does not match what we have been told are in INT for RH8/RA9:

all the ASIDs you have attached to your apps have the latest product, therefore contain A042.

200000002740
200000002739
200000002744
200000002745

Hi Abbey,

Thanks for updating me - I will look into this tomorrow morning - but that trace has certainly uncovered something.

Perhaps I made a mistake in investigation - I will keep you updated.

Tony

@Abbey_Deakin

This is my mistake. For some reason, I checked details for Plymouth (RK9) - (which you did not even ask me to!) and not Royal Devon - which you’ve correctly identified is failing (and that asid is attached to the RH8 app)

I have sent a request to amend this, I’m really sorry.

Hi Tony,

No worries at all and thank you so much for checking. Please can you check API A042 is enable for RA9 as well as we will want to test both RH8 & RA9 in our INT environment. Does RK9 also have this API enabled? We will want to start testing for that Trust as well.

Hi Abbey

It was just the failing ASID that is currently being checked. The other x4 asids associated with the other 2 organisations have been checked and have it on :slight_smile:

I still haven’t heard back from the team on the one causing the issue but i’ll see where they are with it in the morning - if I havent heard from them before.

RA9/RK9 should both work currently.

@Abbey_Deakin - ASID has been updated - might want to give it till the morning, to allow synchs to happen in Spine.

Hi Tony, the 403 issues is resolved however, we are getting a time out issue now.

we’re hitting the default .NET timeout of 100 seconds when making a request from interconnect to https://int.api.service.nhs.uk/referrals/FHIR/R4/Binary/421e8d83-b587-469c-b03c-0b07bb195df4 with X-Correlation-Id = 0000000002EB95418849829327F1FC01.

System.Net.WebException

The operation has timed out’

Can you guys check the following? Our firewall/Illumio isn’t blocking the requests

Are you seeing this request on your side and is it taking > 100 sec? We can look at increasing the timeout but we think we should only do that once we’ve determined that the request is supposed to take a long time.

Hey Abbey,

No worries we’ll pick this up next week for you - can I ask is this all endpoints or just A042?

just A042 is the only change we are seeing this with. When we have A006 active in our test environment we do not have this issue

Hi Abbey, I’m having a look at the logs now. I know you confirmed it was just A042 but could I ask if it is for different attachments (binary ID) or just the one in the example you gave?

From the logs I can see that the request does reach us and is responded to in 80ms with the expected 307 redirect to an S3 URL containing the content. Therefore this suggest that the timeout is coming from this redirect to https://nhs-ers-eu-west-2-int-attachments.s3.eu-west-2.amazonaws.com/… . I understand you have already looked at the firewall but it would be good just to check if it allows HTTPS to the address above. I have also seen that it is somewhat common that .Net does have issues with these types of requests, so I will continue to look into this issue.