...

Introduced in Core i2b2 Version 1.4

© Shawn Murphy 2010

When the set finder algorithm creates an SQL query, it does so one panel at a time.  First, the SQL is created for the first panel and it runs against the star schema to find a set of patients or encounters.  This set is stored in a temporary table.  The SQL is then created for the second panel and it runs against the star schema, and before a new temporary table is created it is joined to the temporary table of the prior panel.  The resulting join will thus always yield an equal size or smaller patient set, and this is stored in the temporary table.  Successive panels continue to be processes in this manner, each time creating an equal-sized or smaller temporary table.  When there are no more panels to process, the last resulting temporary table is used to find the number of patients satisfying the query, or is output as a permanent patient set, or is used immediately for further analysis.

...

In Version 1.6, the set-finder begins to support the option of performing a query to find items occurring in the same encounter, besides just occurring in the same patient.  The temporary tables may now contain encounter numbers rather than just patient numbers.  If many of these types of queries are anticipated, an optimization strategy may include number of encounters for each concept in the total_num field rather than the number of patients.

© Shawn Murphy 2010