Getting 403 NO_RELATIONSHIP error while retrieving attachment(A042)

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

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:

  1. API Name:
    A042 – Retrieve Attachment

  2. Organization:
    TD008463 TEST TRUST 001

  3. Request URI:
    https://int.api.service.nhs.uk/referrals/FHIR/R4/Binary/dacf8b90-9379-4931-93d3-b55530891003

  4. 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": "\*/\*"

}

  1. 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.

2

Hi Vaibhav, im looking into it :slight_smile:

3

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.

4

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?

5

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.

6

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?

7

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:

  • The ODS code for Service A (the receiving/provider organisation Z9X9M) and (if user restricted)…

  • a user/workgroup that has access to that service within e-RS

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

8

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?

9

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:

  1. 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.

  2. 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

10

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:

  • nhsd-end-user-organisation-ods: Z9X9M

  • nhsd-ers-business-function: REFERRING_CLINICIAN

  • user-id: 555340925109

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:

  1. The referral created using the referring organisation ODS (C84665)

  2. We then attempt retrieval using the provider organisation ODS (Z9X9M)

  3. 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)

11

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

12

Hi Lucy,

Apologies for the delayed response.

I investigated the issue and tested the following provider-side Business Functions. I have also attached a screenshot of the provider-side Business Function configuration.

  • SERVICE_DEFINER

  • SERVICE_PROVIDER_CLINICIAN

  • SERVICE_PROVIDER_ADMIN

  • SERVICE_PROVIDER_CLINICIAN_ADMIN

    image
    image1095×545 59.8 KB

However, I am receiving the following error responses:

1. SERVICE_PROVIDER_CLINICIAN_ADMIN

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "forbidden",
      "diagnostics": "On Behalf Of User ID must be provided for Business Function (SERVICE_PROVIDER_CLINICIAN_ADMIN)."
    }
  ]
}

2. SERVICE_DEFINER

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "forbidden",
      "diagnostics": "Endpoint not authorised for Business Function (SERVICE_DEFINER)."
    }
  ]
}

3. SERVICE_PROVIDER_ADMIN

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "forbidden",
      "diagnostics": "Endpoint not authorised for Business Function (SERVICE_PROVIDER_ADMIN)."
    }
  ]
}

4. SERVICE_PROVIDER_CLINICIAN

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "forbidden",
      "diagnostics": "No Legitimate Relationship for Binary with ID e6f2d117-fc01-4872-a630-59477cbbc391."
    }
  ]
}

Could you please confirm whether any additional permissions, endpoint authorisation, legitimate relationship setup, or other configuration changes are required for these Business Functions?

13

Hi Lucy,

I hope you’re doing well.

I just wanted to follow up on the above issue and check if you’ve had a chance to review it.

I tested the provider-side Business Functions (SERVICE_DEFINER, SERVICE_PROVIDER_CLINICIAN, SERVICE_PROVIDER_ADMIN, and SERVICE_PROVIDER_CLINICIAN_ADMIN) and encountered the authorisation errors outlined below. Could you please let me know if any additional configuration is required, such as endpoint authorisation, legitimate relationship setup, On Behalf of User configuration, or any other permissions?

If there are any changes needed on our side, please let us know.

Looking forward to your guidance.

Thank you!

14

Hello,

This is a little difficult to answer definitively, as suppliers often change their test configurations, and only your team and end users will have full visibility of the specific testing scenarios being undertaken and the state in which records currently sit.

The responses you are receiving are meaningful and, from what you’ve described, may indicate a need to step back and review the overall design approach, along with a deeper understanding of both the e-RS APIs and the underlying e-RS business processes used by customers.

You haven’t specified which endpoint(s) are being called, but the API specification clearly lists the permitted roles for each endpoint:

e-RS FHIR API Specification

This does not appear to be a permissions issue. The error indicates that the endpoint is being called using a role that is not permitted for that operation.

For example, if you are calling an endpoint that only allows the following roles:

  • REFERRING_CLINICIAN
  • REFERRING_CLINICIAN_ADMIN
  • SERVICE_PROVIDER_CLINICIAN
  • SERVICE_PROVIDER_CLINICIAN_ADMIN

then calls made using roles such as Service Definer or Service Provider Admin will be rejected, as those roles are not permitted for that endpoint and are not listed in the specification.

Regarding the “legitimate” error, this indicates that the context of the API call (the user or organisation on whose behalf the information is being retrieved) has been lost. We’ve previously provided a summary of this behaviour in earlier posts.

Similarly, the “on behalf of” error is indicating that required context is missing from the request. This behaviour and the associated requirements are also explained within the API specification.

My recommendation would be to pause further troubleshooting for a moment and for your team to take a step back, review the API design, role mappings, and user workflows with your customer and end users. At present, the errors suggest there may be some gaps in understanding around how the e-RS APIs operate and how they align to e-RS roles and business processes. Addressing that understanding first will likely make the subsequent troubleshooting much more straightforward.

15

Hello Tony,
Thanks for support, I will pass this info to my team.