[OHI-1357] feat(static-wado): add support for case-insensitive searching

[IbrahimCSAE]

Context

This adds the option to filter static-wado results without being case-sensitive. You need to set the caseSensitive property on your static wado dataSource to false, the default is true.

Orthanc and other sources support case insensitive searching already.

Fixes OHI-1357
Close #4522

[netlify]

✅ Deploy Preview for ohif-platform-docs ready!

Name	Link
🔨 Latest commit	31c006b
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-platform-docs/deploys/6797a6eb0283d70008d1b281
😎 Deploy Preview	https://deploy-preview-4603--ohif-platform-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for ohif-dev canceled.

Name	Link
🔨 Latest commit	31c006b
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-dev/deploys/6797a6eb0a61a300089f3efc

[sedghi]

we should make it per qido call and not global

[cypress]

Viewers    Run #4780

Run Properties:   Passed #4780  •  31c006b091: fixes

Project	Viewers
Branch Review	feat/case-insensitive-searching-for-static-wado
Run status	Passed #4780
Run duration	02m 10s
Commit	31c006b091: fixes
Committer	Ibrahim
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	2
Skipped	0
Passing	44
View all changes introduced in this branch ↗︎

[sedghi]

Can you try it in Orthanc too please?

[IbrahimCSAE]

Can you try it in Orthanc too please?

I did, it works fine

[sedghi]

@wayfarer3130 can you take a look at this please

[wayfarer3130]

Just a couple of small changes.

[wayfarer3130]

Also, please change the default.js and e2e.js configurations to set this on by default - you may need to modify an integration test to support that.

[IbrahimCSAE]

Just a couple of small changes.

thanks Bill, I'll do them as soon as I can

[sedghi]

wait a minute does this only work on static wado backends? what happened to orthanc testing? did you do it?

[IbrahimCSAE]

wait a minute does this only work on static wado backends? what happened to orthanc testing? did you do it?

orthanc case sensitivity is server side, OHIF doesn’t control it. I tested what orthanc does server side and that this doesn’t break or interfere with it

[sedghi]

I thought the filtering happens client side when we looked at the code

[IbrahimCSAE]

I thought the filtering happens client side when we looked at the code

It only happens if it's a static wado datasource, otherwise it calls the super method, we don't control or filter anything there, so it's all up to backend (orthanc in this case) what to return

See here

Viewers/extensions/default/src/DicomWebDataSource/utils/StaticWadoClient.ts

Lines 101 to 123 in a863808

	async searchForStudies(options) {
	if (!this.staticWado) {
	return super.searchForStudies(options);
	}
	const searchResult = await super.searchForStudies(options);
	const { queryParams } = options;
	if (!queryParams) {
	return searchResult;
	}
	const lowerParams = this.toLowerParams(queryParams);
	const filtered = searchResult.filter(study => {
	for (const key of Object.keys(StaticWadoClient.studyFilterKeys)) {
	if (!this.filterItem(key, lowerParams, study, StaticWadoClient.studyFilterKeys)) {
	return false;
	}
	}
	return true;
	});
	return filtered;
	}

  async searchForStudies(options) {
    if (!this.staticWado) {
      return super.searchForStudies(options);
    }

    const searchResult = await super.searchForStudies(options);
    const { queryParams } = options;

    if (!queryParams) {
      return searchResult;
    }

    const lowerParams = this.toLowerParams(queryParams);
    const filtered = searchResult.filter(study => {
      for (const key of Object.keys(StaticWadoClient.studyFilterKeys)) {
        if (!this.filterItem(key, lowerParams, study, StaticWadoClient.studyFilterKeys)) {
          return false;
        }
      }
      return true;
    });
    return filtered;
  }

[sedghi]

I'm hesitant to merge this PR if it's only for static WADO. Sorry if that wasn't clear from the start.

Based on my research, the standard doesn't specify anything about this.

As you mentioned, Orthanc has a setting called CaseSensitivePN. DCM4CHEE treats all caps as case insensitive, so searching for FIRSTNAMELASTNAME is case insensitive. I'm still trying to determine how the Google Healthcare API handles it.

Then we can decide how to proceed.

[sedghi]

I think the way forward is to add fuzzyMatching to our static wado, since that seems to be wildly supported by lots of dicom servers, see https://cloud.google.com/healthcare-api/docs/dicom#search_transaction fuzzyMatching section.

Right now it is set in the config file as supportsFuzzyMatching:false

From the link
fuzzymatching: If set to true, fuzzy matching will be applied to the PatientName tag. Fuzzy matching will perform tokenization and normalization of both the value of PatientName in the query and the stored value. It will match if any search token is a prefix of any stored token. For example, if PatientName is "John^Doe", then "jo", "Do" and "John Doe" will all match. However "ohn" will not match.

[IbrahimCSAE]

I think the way forward is to add fuzzyMatching to our static wado, since that seems to be wildly supported by lots of dicom servers, see https://cloud.google.com/healthcare-api/docs/dicom#search_transaction fuzzyMatching section.

Right now it is set in the config file as supportsFuzzyMatching:false

From the link fuzzymatching: If set to true, fuzzy matching will be applied to the PatientName tag. Fuzzy matching will perform tokenization and normalization of both the value of PatientName in the query and the stored value. It will match if any search token is a prefix of any stored token. For example, if PatientName is "John^Doe", then "jo", "Do" and "John Doe" will all match. However "ohn" will not match.

I implemented it according to the definition from GCP. please take another look now, thanks

[sedghi]

See Bill's comment and it is good to go thanks

[wayfarer3130]

If you supported wildcard matching here too, with prefix/suffix, then you can support fuzzy matching for names, and wildcard start/ends with for other fields. I would suggest changing the support of supportsWildcard to suffix, to automatically have the wildcard added only at the end, although doing a full contains works as well for client side matching.

[IbrahimCSAE]

I think this implementation is sufficient for now. We can dedicate more time to implementing proper server-side filtering logic for static wado using lamdas or something similar then we can avoid all of this in the frontend.