NIAD-2873: Change how we query the persist duration from SDS

[ole4ryb]

What

By this PR we are adapting the way how we query SDS service to avoid getting a broken response.

Why

For one of our test ODS codes, C88046, we've observed that we've been unable to retrieve the "persist duration" from the SDS API. The persist duration is fetched for each ODS code during the transfer timeout functionality, to ascertain whether the transfer has timed out or not.

Within the SDS FHIR API, there are two endpoints:

• endpoint
• device

When calling the endpoint API with the test ODS code, it is returning nothing, but when calling the device endpoint using the ODS to get the PartyID, and then calling the endpoint API using that PartyID we get the persist duration.

We believe that the original behaviour to use the ODS code by itself should work, but have been unable to get a definitive answer from ITOC as to whether there is a data issue within SDS for our ODS code.

Example error log entry seen previously

docker-gp2gp_translator-1  | 2023-10-17 11:33:42.092 Level=ERROR Logger=u.n.a.p.t.t.s.EHRTimeoutHandler ConversationId=A6FDC87D-68AB-4F6E-8370-524D8EBC209E Thread="scheduling-1" Message="Error retrieving persist duration: [sds response doesn't contain any results]"

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Internal change (non-breaking change with no effect on the functionality affecting end users)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• I have performed a self-review of my code
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have updated the Changelog with details of my change in the UNRELEASED section if this change will affect end users

[benhession]

Minor comment around constant name, but otherwise looks good!

[benhession]

Because this is the device endpoint I don't think is should be called "Routing and reliability" the docs call it Get Accredited System Details