Unexpected response from SDS FHIR API

Other services Spine Directory Service (SDS)
,
1

We are using SDS FHIR API. Our regression tests have recently started failing in the INT environment.

When requesting Device resources for organisation YES:

GET Device?organization=https://fhir.nhs.uk/Id/ods-organization-code|YES&identifier=https://fhir.nhs.uk/Id/nhsServiceInteractionId|urn:nhs:names:services:nrl:DocumentReference.content.read

The response includes 3 resources.

2 have owner.identifier.value of YES, as expected.

The response also includes a resource where owner.identifier.value of YEA, which doesnā€™t meet the expectation in the FHIR specification which defines a match against Device.owner. We note that this resource has an identifier using the same MHS Party Key as the resources owned by YES:

{
  "system": "https://fhir.nhs.uk/Id/nhsMhsPartyKey",
  "value": "YES-0000806"
}

Is this an expected behaviour of the SDS FHIR API?

2

Hi @dunmail, thanks for posting on the Community. This has been flagged to the SDS team and they should respond shortly.

3

Do you know when the SDS team are likely to respond?

1 Like
4

@jenna.hartley-smith Weā€™ve assumed that the SDS team arenā€™t going to reply and we will implement a workaround

5

Hereā€™s a response from one of our engineers:

ā€˜I am not entirely sure. I think the quick answer is that YES and YEA are test codes. The SDS FHIR API on INT is communicating with INT LDAP. Thatā€™s where the data is coming from. But I am not sure why it is returning both codes in the same request without spending more time looking at the code.

My guess would be that the data is not correct in LDAP
Perhaps for that record the nhsIDCode has been set to YEA but the identifier has been set to ā€œvalueā€: ā€œYES-0000806ā€ā€˜

Hope that helpsā€¦and apologies for the delay in getting back to you.

6

Thanks.

As a workaround, weā€™ve implemented a proxy adapter that applies additional filtering.