Support token modifiers ':in' and ':not-in'

[lmsurpre]

from https://www.hl7.org/fhir/R4/search.html#token

The search parameter is a URI (relative or absolute) that identifies a value set, and the search parameter tests whether the coding is in the specified value set. The reference may be literal (to an address where the value set can be found) or logical (a reference to ValueSet.url). If the server can treat the reference as a literal URL, it does, else it tries to match known logical ValueSet.url values.

example:

Search for any condition in the SNOMED CT value set "http://snomed.info/sct?fhir_vs=isa/126851005" that includes all descendants of "Neoplasm of liver"

GET [base]/Condition?code:in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F126851005

[lmsurpre]

The implementation to this one probably would vary a lot based on the size of the valuesets.

For "small to medium" size valuesets, we could probably piggy-back on our existing ValueSet expansion support. For example, we expand the ValueSet if needed, then pass the list of systems+codes into the db as a list of literals via an IN clause.

At some point, you run into limits on either the query size or on the IN list of literals. Something like 2,000 or 20,000 on DB2 :-)

Therefor, for larger valuesets, you probably need something more sophisticated where you store cached representations of valuesets.

[JohnTimm]

As written, this requires support for "implicit value sets".

[csandersdev]

For the CQL Engine evaluation, we are assuming that ValueSet resources will be defined as extensional resources. We believe that support for the :in operator could greatly improve the overall performance of the system because we wouldn't have to move as much data over the wire and would be happy with a first cut that only supports extensional ValueSets.

[lmsurpre]

Reduced points because bulk of the work was done with #1980

[lmsurpre]

I uploaded two condition resources to my local server. One with a code of http://snomed.info/sct|30832001 (Rupture of patellar tendon) and one with http://snomed.info/sct|10509002 (Acute bronchitis).

Then I configured the fhir-term-graph with SNOMED CT, which supports implicit valuesets.

Next I issued the following two queries:

• https://localhost:9443/fhir-server/api/v4/Condition?code:in=http://snomed.info/sct?fhir_vs=isa/32398004
• https://localhost:9443/fhir-server/api/v4/Condition?code:not-in=http://snomed.info/sct?fhir_vs=isa/32398004

As expected, the former returned just the Acute bronchitis diagnosis and the latter returned just the patellar tendon rupture one.

Next I'd like to check the performance in a more sizable environment, but so far its looking good.