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
user_roles_json.txt (6.4 KB)
Hi Tony,
Thank you for your response.
We did not fully understand the point regarding the service workgroup. Could you please clarify this further or share any relevant documentation regarding workgroups?
Also, we have attached the user roles response JSON from our system for reference.
For attachment upload, we are using the referring organisation ODS (C84665) with the role General Medical Practitioner. For attachment retrieval, we are using provider-side roles/users under Z9X9M (Consultant / General Medical Practitioner).
We have tried retrieving the attachment using both of these user roles, but we are receiving the same error response in both cases.
Could you please confirm whether this issue could be related to the user roles/workgroup permissions, or if there are any additional role or access configuration changes required for attachment retrieval?
Hi Vaibhav,
Thanks for sharing the roles JSON.
From what you’ve provided, your roles and activities look appropriate on both the referring (C84665) and provider (Z9X9M) side.
Just to clarify the earlier point — workgroups control access to services within an organisation. They don’t override the “legitimate relationship” check itself, but this is dependant on whether you’re making a user restricted call or app restricted call.
For A042, the key requirement is that the request is made using the organisation and user that currently has a legitimate relationship to the referral. This is determined by where the referral sits in the e-RS workflow at that moment, not who originally uploaded the attachment.
Before attempting A042, I’d recommend confirming:
-
Using the same headers (ODS + user), are you able to successfully retrieve the referral (e.g. via A005)?
- If not, this indicates the organisation/user does not currently have a legitimate relationship, and A042 will also fail.
-
That your application is consistently sending the same NHSD-End-User-Organisation-ODS for a given referral. From earlier logs, we observed requests alternating between ODS codes, which would result in intermittent success/failure.
Trying both ODS codes for the same request will not resolve the issue — the correct ODS is the one that currently “owns” the referral in the workflow.
If helpful, please share:
-
the referral ID
-
whether A005 succeeds under each ODS
-
Try again with the PROVIDER ODS code (with a referral you are sure has been sent to provider)
-
Share the correlation ID so this can be reviewed in the logs
Additional info on workgroup and setup can be found here:
https://digital.nhs.uk/services/path-to-live-environments/guide-to-creating-services-in-path-to-live-nhs-e-referral-service/creating-a-new-workgroup
Hi Tony,
We tested A005 using the provider organisation ODS (Z9X9M) and the same provider-side user, but we are still receiving the “no legitimate relationship” error response.
Below are the request details we are currently using:
We would like to confirm whether the business function REFERRING_CLINICIAN is valid for provider-side retrieval requests using the provider organisation ODS (Z9X9M), or whether a different provider-side business function should be used for A005/A042 retrieval.
For our testing:
-
The referral created using the referring organisation ODS (C84665)
-
We then attempt retrieval using the provider organisation ODS (Z9X9M)
-
A005 return the “no legitimate relationship” error
Referral ID: 000049828752
Correlation ID: 6c23a1bb-461d-4e7f-8957-2e6a66230332
Please find the attached files for reference:
A005_Response.txt (589 Bytes)
A005_Request.txt (390 Bytes)
Hi Vaibhav, Tony is on leave at the moment so I’ve just taken a look at this for you - The “no legitimate relationship” error occurs because the request is being made using a REFERRING_CLINICIAN business function with a provider organisation ODS.
For provider retrieval (A005/A042), the request must use a provider-side business function (e.g. SERVICE_PROVIDER_CLINICIAN).
In addition, the referral must already be associated with the provider organisation (e.g. booked or on the provider worklist).
I hope this helps,
Lucy