Hello,
We are currently experiencing an issue while retrieving attachments using the NHS e-Referral Service APIs.
Please find the request and response details below:
-
API Name:
A042 – Retrieve Attachment
-
Organization:
TD008463 TEST TRUST 001
-
Request URI:
https://int.api.service.nhs.uk/referrals/FHIR/R4/Binary/dacf8b90-9379-4931-93d3-b55530891003
-
Request Data:
-
referralAttachmentId - dacf8b90-9379-4931-93d3-b55530891003
-
Headers:
{
"Authorization": "Bearer FUJhOQ68hGBwO0TYk9fOyE3G7ih8",
"NHSD-End-User-Organisation-ODS": "Z9X9M",
"NHSD-eRS-Business-Function": "SERVICE_PROVIDER_CLINICIAN",
"user-id": "555340925109",
"x-correlation-id": "28203cee-be7b-4e81-b691-76ba04d96830",
"accept": "\*/\*"
}
-
Response Data:
{
"resourceType": "OperationOutcome",
“meta”: {
“lastUpdated”: “2026-04-23T05:32:47.753Z”,
“profile”: [
https://www.hl7.org/fhir/R4/operationoutcome.html
]
},
“issue”: [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "No Legitimate Relationship for Binary with ID dacf8b90-9379-4931-93d3-b55530891003.",
"details": {
"coding": \[
{
"system": [https://fhir.nhs.uk/CodeSystem/ers-error-codes](https://fhir.nhs.uk/CodeSystem/ers-error-codes),
"code": "NO_RELATIONSHIP"
}
\]
}
}
]
}
Observed Issue:
The API returns a NO_RELATIONSHIP error, indicating that there is no legitimate relationship between the requesting user/organisation and the specified attachment.
We would appreciate it if you could investigate this issue and advise on the next steps to resolve it.
Please let us know if any further information or logs are required from our side.
Hi Vaibhav, im looking into it 
I believe I have found what could be causing this issue from the logs.
The attachment you’re trying to retrieve belongs to a referral that sits under ODS code C84665, not Z9X9M. When your application sends Z9X9M in the NHSD-End-User-Organisation-ODS header, the system correctly returns a NO_RELATIONSHIP error because that organisation has no link to this referral.
Looking at your recent activity, I can see the same user successfully retrieved this referral 15 times within ~15 minutes using ODS code C84665. The 2 failures are the only times Z9X9M was used instead.
Interestingly, the successful and failed requests alternate within seconds of each other meaning your application is switching between the two ODS codes very quickly. This suggests your application may sometimes be picking up the wrong organisation when making the call, rather than this being a deliberate change by the user.
To resolve this, please ensure your application is using ODS code C84665 in the NHSD-End-User-Organisation-ODS header when accessing this referral and its attachments. If your user works across multiple organisations, the ODS code used in each request should match the organisation that the referral belongs to.
Hope this helps.
Hi George,
Thanks for the analysis.
In our flow, we are sending all required headers such as Organisation Authorization Bearer Token, Request ID, Correlation ID, Business Function, and End User Organisation ODS.
Our understanding is that:
-
The referral is created using the supplier ODS (C84665)
-
The referral is then accessed and processed (accept/reject, etc.) using the provider ODS (Z9X9M)
This is because the referral is made from one organisation to another. The referring organisation and receiving organisation are different, so their ODS codes are also different.
If attachments must always be accessed using the supplier ODS (C84665), then it raises a question:
- Should the provider organisation not use its own ODS (Z9X9M) while working on the referral?
Also, if Z9X9M must always be used, then logically the referral itself should have been created using Z9X9M, which is not the case in cross-organisation referrals.
In our scenario, one service refers to another service, so both organisations are involved and their ODS codes will differ. The same user may operate in both contexts.
Could you please confirm the correct approach for handling ODS in this case, especially for attachment retrieval?
Hi @Vaibhav_Salunkhe
I think the issue may be that the attachment you’re trying to retrieve belongs to a referral associated with a different organisation (ODS code) than the one being sent in your request header. Because of this, eRS correctly returns a “no relationship” error — it’s effectively saying that the organisation in the request doesn’t have a valid link to that referral - in e-RS terms a ‘legitmate relationship’
What’s making this confusing is that some of your requests are succeeding and some are failing. From the logs, it looks like your application is alternating between the correct and an incorrect organisation code when making calls. So the successful calls are using the right organisation, and the failed ones aren’t.
In practical terms, this points to a consistency issue in how your system is selecting or passing the organisation context, rather than a permissions problem or an eRS defect.
e-RS is effectively a worklow system, so the calls will only work effectively when they are made on behalf of the organisation/user that has the legitimate relationship to do so - this changes as the patients referral/A&G works through the system.
In the context of ERS for a supplier organization, we understand the following scenario:
-
Service A is the receiving (supplier) service.
-
Service B is the referring service that has sent the patient to Service A.
-
Both services have different ODS codes.
In this case, Service A needs to retrieve the patient’s attachments that were originally shared by Service B in order to determine the next steps for the patient.
Our use case is similar, and we are currently testing these scenarios. At the moment, we are trying requests using both ODS codes (Service A(Z9X9M) and Service B(C84665)) to understand the expected behavior.
Could you please confirm which ODS code should be included in the request header in this situation?
Hi Vaibhav,
Good question
In your scenario, although the attachment was originally added by Service B, once the referral has been sent to Service A, the legitimate relationship sits with the provider side of the workflow.
So for retrieving attachments (A042), you should be using:
Using the referring organisation (Service B) won’t establish a valid relationship at that stage in the workflow, even though they originally supplied the attachment.
In short, the request needs to reflect the organisation and user that currently “owns” the referral in the e-RS workflow. This is what we refer to as legitimate relationship (LR).
I think in the examples we’re talking about the use of Service might get confusing, so think of it as two organisations, GP has legitmate relationship, until they send to the NHS Trust (Z9X9M), at which point the Trust has legitmate relationship.
Then, within the organisation, there is further constraint, depending on the Professional role, do they have the correct roles, are they in the service workgroup etc.
Thanks,
Tony