Filter Control

Every screen has some access to the filter control, although some screens have more items in the filter control than others. The dashboard screens, for example, only allow filtering on fields that exist in every constituent measure. Splitting is only possible in Measure Explorer and Table Dashboard; whereas sorting is only available in Case Review.

Every screen has access to quick filter and date range controls. These are profiled within the report to drive specific filters. The specific filter setup with a quick filter or scope will be enumerated with the other filters.

Measure-specific screens also have access to the “Filters” section of the filter control, which allows fine-grained control over which data is being viewed. Multiple filters can be added at a time and are allowed to work in an “AND” or in an “OR” capacity with each other.

The IN operator accepts an operand with commas and interprets the comma-separated values as being independent search terms. The = operator, by contrast, interprets commas literally, so that an = search for the patient ID 123,456 will look for a patient ID that actually has a comma in it.

Measure Explorer also allows for the selection of splits from within the filter control. Splits disaggregate measure results into subgroups based on the selected field(s). For some chart types, users will only be allowed to split on fields that have been marked as analytic in the measure. However, for the bar and dot chart types, users can also split on any denominator field, or on any field on a count measure.

Case Value and Case Percentile Filters

The filter control features a special Case Value filter, which can interact with the other filters and splits of Case Review and Measure Explorer. The Case Value filter is applied after the date range filter and other denominator filters, but before denominator splits and numerator filters and splits. To take a few examples, imagine a PMPM measure.

1. If the user has two filters -- Claim Type = Pharmacy and Case Value > $6000 -- Measure Explorer will show the PMPM of the pharmacy claims for patients whose total monthly spend is > $6000, and not the PMPM of the pharmacy claims for patients whose monthly pharmacy spend is > $6000.
2. If the user has a filter and a split -- Case Value > $6000, Split on Claim Type -- Measure Explorer will show the PMPM of each claim type for patients whose total monthly spend is > $6000, and not the PMPM of each claim type for patients whose monthly spend within that claim type is > $6000.
3. If the user has two filters -- Date range is January 2019-December 2019 and Case Value > $6000 -- Measure Explorer will show 2019 data for the PMPM for patients whose 2019 PMPM > $6000, and not the 2019 data whose PMPM across the whole reporting period PMPM > $6000.
   If the user is viewing Results over Time with one filter -- Case Value > $6000 -- Measure explorer will show the data for the PMPM for patients whose PMPM across the whole reporting period > $6000.
4. Note the different treatment of 1 and 3. The claim type filter is applied after the Case Value filter, whereas the date range filter is applied before the Case Value filter. The operative difference between date range and claim type is that the former is a denominator field whereas the latter is a numerator field. Treating these differently will best match user expectations for each type of field.

Note also the different treatment of 3 and 4. Indeed, if a user were to drag-select a single month from the results-over-time chart and apply a filter to isolate that month, the application of the Case Value filter might change, because when the month is shown as a series we consider the PMPM across the entire period, but when the month is isolated in a filter then we only consider the PMPM for that month.

Users can similarly filter by case percentile in analytics portal. This filter operates along the same mechanism as the case value filter, but takes a value between 0 and 100, which represents the percentile of the case value within the scope of the analysis.

Ad-Hoc Derived Fields

Users can create derived fields in Analytics Portal, using the derived field patterns available in Object and Measure Workshop. These "ad-hoc" derived fields can be seen and managed in the filter control of Measure Explorer and Case Review, and any derived fields so created can be used as filters and splits in subsequent analyses. As in Object and Measure workshop, the output from one derived field can be used as an input in another derived field.

Ad-hoc derived fields that have been invalidated (e.g. via a naming change to their inputs) will disappear from the filter and split controls, and will be marked as having an error in the derived field editor until they have been repaired.

Users can create an ad-hoc derived field representing the current filter contents using the CASE WHEN pattern, including the date filter if it is set to something other than earliest / latest. A filter state that includes case value filters or "OR" filters cannot be converted into an ad-hoc derived field.

Cohorts

Users in Case Review and Measure Explorer can save the distinct values of any text column of a measure with the current filter applied into a "cohort", which will be stored as a set of distinct values and can be used via the "Is In Cohort" and "Is Not In Cohort" filter operators in any measure on the same report. Cohorts can be managed via the hamburger menu item in Case Review or Measure Explorer.

Cohorts defined on a report can be used by any other measure on the same report; cohorts defined in data review of an object can be used within any other object’s data review.

Both the creation of cohorts and the creation of ad-hoc derived fields from the current filters are driven by the save icon-button in the filter control.