We put our eRS FHIR API integration live at York and Scarborough Teaching Hospitals yesterday. The application restricted auth requests are succeeding, however we are getting generic http 400 errors from the worklist endpoint (A008) /referrals/FHIR/STU3/ReferralRequest/$ers.fetchworklist
Application ID
9e4048d0-2ade-42f5-93bc-01c336700556
X-Correlation-ID
Unsure what this field is
X-Request-ID
Not provided by response
Date and time the call was made
08/11/2024
Hi @simrit.bains,
We can’t see any traffic from that Application ID in production. It may be the error you are seeing is authentication related, which may stop us identifying the Application ID it was sourced from.
Could you please provide the full request and response details please? i.e. Request URL, Request/Response headers and payload.
@tony.marsh1 is also going to get in touch to arrange a call this morning to get this resolved if we can.
Regards,
Adam.
Also FYI:
The X-Correlation-ID is a tracing identifier that is passed as a Request header, that allows the caller to provide a unique tracing identifier in the request. This identifier is then echoed back in the response.
This identifier helps us find a specific request for investigation.
The X-Correlation-ID is documented on every request, but for referrence you can see it in the Request Headers section of Retrieve referral worklist (A008, FHIR STU3).
The X-Request-ID is a server (i.e. e-RS) assigned identifier returned in the response (assuming the request made it through to the e-RS back-end).
Hi,
The following headers were used:
| Header | Value |
|---|---|
| Authorization | Bearer XXXXXXXXXXXX |
| Host | sprvorac1a or sprvorac1b or sprvorac1c |
| Content-Type | application/fhir+json |
| Accept | application/fhir+json |
The following requests were made:
| API Reference | Base URL | Endpoint | Org Used (User Restricted) | Role Used (User Restricted) | Response | Service Name | X-Request-ID |
|---|---|---|---|---|---|---|---|
| A008 | https://ers-prod-api.ydh.yha.com:6443/referrals/FHIR | /STU3/ReferralRequest/$ers.fetchworklist | 400 | Paediatrics - General Ophthalmology - Malton | |||
| A008 | https://ers-prod-api.ydh.yha.com:6443/referrals/FHIR | /STU3/ReferralRequest/$ers.fetchworklist | 400 | Surgery - Pilonidal Sinus (DB) Scarborough |
Note:
The Payload would be:
{ "resourceType": "Parameters", "meta": { "profile": [ "https://fhir.nhs.uk/STU3/StructureDefinition/eRS-FetchWorklist-Parameters-1" ] }, "parameter": [ { "name": "listType", "valueCodeableConcept": { "coding": [ { "system": "https://fhir.nhs.uk/STU3/CodeSystem/eRS-ReferralListSelector-1", "code": "REFERRALS_FOR_REVIEW" } ] } }, { "name": "service", "valueIdentifier": { "system": "http://fhir.nhs.net/Id/ers-service", "value": "SERVICE ID" } } ] }
Thanks @simrit.bains.
Can you please include details of the e-RS response headers and body?
The response was the following:
400 Bad Request400 Bad Request
nginx
Im not sure about the header as we dont log this
Thanks for you time to discuss the issue earlier @simrit.bains. I just wanted to put outcomes on this thread so it didn’t remain unanswered.
During the call you were able to successfully call A008 locally from Postman.
Therefore the issue looks like the issue is possibly with your proxy service.
Please let us know if we can be of any further assistance.
Hi Adam,
After some further investigations we found that we were able to get a “200 OK” when routing the request via the proxy using postman however the same exact request seems to be returning a 400 when sending it using the database.
When looking at a TCP dump it seems that the 400 request hits
the NHS API Services server and returns a 400 back to us.
Hi @simrit.bains,
Just so my understanding is clear. You have had a successful call from Postman (locally) via your proxy.
However, the same call made from “the database” is returning a 400 response. When you say “the database” I assume this is a call coming from a database server somewhere (and not actually from the database)?
Looking at the logs for yesterday we can see:
I don’t see any 400 responses.
I don’t quite follow your screenshot but you are seeing the call leave your proxy and hitting api.service.nhs.uk which returns a HTTP 400?
If so we may need to involve someone from the APIM team.
Regards,
Adam.
Just so my understanding is clear. You have had a successful call from Postman (locally) via your proxy.
However, the same call made from “the database” is returning a 400 response. When you say “the database” I assume this is a call coming from a database server somewhere (and not actually from the database)?
Yes, your understanding is correct that an Oracle database server is making the call via stored procedures which is failing (400 response) while the call is successful via postman on a local machine.
I don’t quite follow your screenshot but you are seeing the call leave your proxy and hitting api.service.nhs.uk which returns a HTTP 400?
If so we may need to involve someone from the APIM team.
Yes, this is the case. It would be helpful if someone from the APIM team investigated the 400 response.
Thanks for confirming @simrit.bains.
@tony.marsh1 can you request assistance from the APIM team on this?
In the mean-time, if possible it would aid this and future investigation if you could update your solution so it passes a unique X-Correlation-ID header with each request.
Also it would be worth you comparing the raw HTTP request (i.e. headers/body) for both the local call (from Postman) and the call from the database server to see if you can spot any subtle differences.
Regards,
Adam.
York and Scarborough Teaching Hospitals traced the issue to their internal proxy. This has now been resolved with no changes to e-RS.
