Slow response time in patient search

[aa and]

Hello,

I am noticing some pretty slow response times in our production environment when looking up patients via FHIR client... time ranges from 15 to 30 seconds on some instances. This is causing a timeout issue with a bot that we use to query with. Is this to be expected or is there something that can be done to improve these response times?

Here are some X-request-IDs that had slow response times:

X-Request-Id: efb2e53b-7db3-44ed-adfd-2d2a73a1c65b

X-Request-Id: 01f6c269-6c2e-49fa-bcb7-8dd28304cc9d

X-Request-Id: 327bc8ea-7dad-42ae-b840-0adc46064f7e

[Ray]

Hi,

Interested in your bot.  Can you share some details?

Thank you

Sent from my iGizmo

On Aug 25, 2021, at 10:43 AM, aa and <aand...@gmail.com> wrote:

Hello,

--
You received this message because you are subscribed to the Google Groups "Cerner FHIR Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cerner-fhir-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cerner-fhir-developers/4ff72245-0617-4dcc-8684-fe38e0b595b4n%40googlegroups.com.

[Fenil Desani (Cerner)]

Hello,

The increase in response time can be attributed to multiple factors, such as slow underlying services, DB connection issues, computing power issues, poor API call, networking issues, size of the response, and/or more.

Can you please log a ticket to Cerner Ignite APIs for Millennium for further detailed investigation on this.

Thanks,

Fenil

[aa and]

Thanks i've already logged a ticket but am awaiting a response in regards to the response time... Service Record 438877528

[Fenil Desani (Cerner)]

Thanks for that information. I gave our support team a heads-up about this and they will be working with you to investigate and resolve the issue.

From the initial look, it seems the underlying service is slow. We have engaged the relevant team for further troubleshooting.

[aa and]

Would you be  able to provide mroe info on using the nameKey? they mentioned that the underlying problem is that we are using a "currentGivenNameKey" key and a "anyCurrentNameKey"... we're using the c# fhirClient and in our query params we include "name" and "given" which seem to correlate with those two keys. She suggested using the key "nameKey" but i'm not sure what that corresponds with from the DSTU2 documentation as it only mentions "name" and "given" as name keys to use in querying... I'm thinking the "name" key from the dstu2 docs would be closest to this "nameKey", and an attached image mentioned the service will accept name criteria in the form: "firstName$middleName$lastName$nameTypeCd" but i'm not sure how that translates to the fhir client in c#... 

it sounds like i should be able to search for a patient by the name of "John Smith" with just the name key rather than using both the "name" and "given" keys, but if i were to use just the name key, how would i format the value to use the first and last name? could i just do "name=John Smith"?

[Fenil Desani (Cerner)]

Hello,

So there is a known issue of slowness when searching by more than one name param. Can you try searching by only  first/last name and DOB and see if that improves results?