DSTU2 Condition Performance degrades as condition count increases

[Michael Ericksen]

Hello,

We've observed that the number of results in a FHIR searchset bundle has an inverse relationship to performance. As the number of results increases, performance degrades.

The p50 and p99 latency thresholds for 0-100 conditions are 800 ms and 3200 ms, respectively. At greater than 200 conditions, the p50 and p99 latency thresholds increase to 4700 ms and 12000 ms, respectively.

From my readings of the Cerner Millenium DSTU2 implementation, filtering by encounter and server-side pagination are not currently supported for the condition resource.

Are there other recommendations for optimizing application performance as the number of conditions increases that we should consider?

Thanks!
Michael

[Benjamin Eichhorn (Cerner)]

Hi Michael,

You should attempt to leverage all query parameters we support to limit the results as necessary. For example, if your app only requires current Condition's that are active, consider utilizing the clinicalstatus query parameter to limit the results to only those. In addition, you can also consider using the category query parameter to limit the results additionally. Limitting your requests to only the category your app is concerned about will help increase performance.

Outside of the built in capabilities for the Condition resource in DSTU2, if possible, please consider upgrading your app to utilize the Condition resource in R4. We have made some improvements to the resource that should improve the performance of the resource.

Thank you,

Ben (Cerner)

[Michael Ericksen]

Thanks for the information, Ben. At this point we're filtering to category = `diagnosis` with a clinical status of `active,relapse,remission,resolved`. We don't have any telemetry at this point for the distribution of conditions across those clinical statuses, but it should be relatively straightforward to add and report back.

In terms of the migration from DSTU2 to R4, do you have any quantitative benchmarks across the two versions?

[Benjamin Eichhorn (Cerner)]

Hi,

Unfortunately I do not have any specific official measures in terms of the difference you will see between DSTU2 and R4. I can say that the improvement in times should be somewhat significant and relatively noticable due to the overall nature of the changes we made between our implementation of the resource in DSTU2 and R4. And, as always, we are looking to improve the performance of our APIs across the board. I'll be sure to communicate your concerns internally through the proper channels.

Thank you,

Ben (Cerner)

[Michael Ericksen]

I had a chance to finally benchmark performance between the DSTU2 and R4 environments using fhir-open.cerner.com and I actually see the inverse behavior: most condition calls actually perform slower for DSTU2 vs. R4.

DSTU request parameters:

Category=Diagnosis

ClinicalStatus=active,relapse,remission,resolved

R4 request parameters

Category=encounter-diagnosis

ClinicalStatus=active,relapse,remission,resolved

Attaching the comparison since I don't see an easy way in Google Groups to display a data table. The R4 API calls consistently return more items (I assume they're pointed to different databases), but not a sufficiently larger volume of items that it would change performance. And in no cases does the R4 API perform significantly faster (or even faster) than the DSTU2 API that we currently implement.