Closed lmsurpre closed 3 years ago
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.
As written, this requires support for "implicit value sets".
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.
Reduced points because bulk of the work was done with #1980
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:
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.
from https://www.hl7.org/fhir/R4/search.html#token
example: