fix communicationRelatesTo expression to stop double-indexing careTeam/episodeOfCare extensions - #336
Open
OliverDueNielsen wants to merge 1 commit into
Open
Conversation
…m/episodeOfCare extensions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
###The problem:
HAPI FHIR logged "inefficient query" warnings during Communication search pagination (category & _tag & status & communicationRelatesTo & subject). Root cause traced via table stats (no pg_stat_statements, no EXPLAIN needed):
The communicationRelatesTo search parameter is a union FHIRPath expression covering 5 reference paths (recipient, sender, senderCareTeam ext, recipientCareTeam ext, episodeOfCare ext) — built as an "all-purpose" narrowing filter. Three of those five paths duplicate facts already indexed by separate, partner-facing search parameters (careTeamSender, careTeamRecipient, episodeOfCare), but written with different FHIRPath syntax (.extension.where(url=...).value vs .extension('url')).
HAPI dedupes indexed reference links via a Set, keyed partly on the literal FHIRPath string that produced them (ResourceLink.equals()).
Different syntax → no dedup, even though both resolve to the identical value. Result: ~899K duplicate rows in hfj_res_link (~39% of the whole table), almost all of it Communication reference indexing. Every Communication search touching communicationRelatesTo scans that inflated index before intersecting with the other filters — sparse joint matches then trigger HAPI's pagination retry warning.
##Fix: rewrite communicationRelatesTo's expression to use the same syntax as the standalone params — same values, same search results, dedup collapses the duplicate rows on reindex.
NOTE: We will need to run a reindex after the IG is used by the patient.
Aims at fixing this issue