Fields and Patterns

Available Fields

Users can choose among the available upstream fields after selecting an object. Each such field is akin to a simple select clause of one of the properties of the object, passing through the field without transformation.

Users can manage published fields within a panel in the measure root screen of Measure Workshop. Users can see their published fields and can re-order to override the default way that they will be shown in Case Review within Analytics Portal. Users can also see the way that their fields will be grouped per the Field Group assigned to each field, and they can re-order the groups on a measure-by-measure basis.

An object can inherit the available fields en masse and verbatim from the backing object via the “Inherit Field Settings” checkbox. If this option is chosen, the Available Fields panel on that object becomes read only, and changes to the backing object will be immediately applied to the measure. If users want to clone the backing object’s fields but either make some changes or not keep the link between the two objects, they can simply un-click the checkbox. The imprint of the backing object’s fields remains, but subsequent changes to the underlying object will not automatically propagate to the measure.

Users can choose a field name for each field, but a sensible default (based on the column name of the upstream object) is provided as a placeholder. By entering a value into the “Prepend Text” box, users can add a qualifying description that will become part of all of the default field names for the fields on the object.

Analytic Fields and Pooling

Users can designate fields as being analytic. It is typically inappropriate to designate a field with a large number of distinct values, such as the patient ID, as being analytic. If an analytic field has over 500 distinct values (or 50 if the field is a numerator field), all but the top 500 (or 50) values will be pooled together into a value marked “[Pooled]”. It will be possible to see the raw values in Case Review.

Derived Fields, Restrictions, and Transformations

Once the object is chosen, users can also identify derived fields, restrictions, and transformations. Derived fields, restrictions, and transformations are built around a set of pre-profiled patterns that cover a great variety of data transformation needs. Users can see and search on a description for each pattern before selecting it, then must fill in the prescribed fields.

Each derived field is akin to a select clause with some sort of calculation. Users can select among several dozen different pre-programmed derived field patterns, such as “Date Offset” and “Concatenate.”

Each restriction is akin to a where clause. Users can select among several dozen different pre-programmed restriction patterns, such as “All Are True” or “Is In Value Set.”
Transformations involve a reshaping or similar modification of the form of the data.

Restrictions, derived fields, and transformations can be chained together. For example, a restriction can use as one of its inputs a derived field generated on the same object or on a different object.

Block Headers

By adding a block header to a pattern users can create a block of patterns that encompass that pattern down through the next pattern that itself has a block header. Blocks of patterns can be copy/pasted as a unit. They can also be collapsed. If all the blocks are collapsed, then dragging a block will move the entire block as a unit, unlike the current uncollapsed behavior of only moving the individual pattern.

Reshape Wide to Long

One of the available transformations is “Reshape Wide to Long”. It is used, for example, if you have an upstream table with columns such as

name
code_001
code_002
code_003
code_004

and you want to reshape the grain size of the table so that it has one row per code.

To reshape the upstream object, a user must identify which columns will be turned into rows—in the example above, the code columns 001 through 004.

It is possible to reshape with multiple parallel banks of fields at the same time. Consider the case where the columns of the upstream object are

name
code_001
description_001
code_002
description_002
code_003
description_003
code_004
description_004

By adding a second bank, a user captures the four descriptions alongside the codes. Note that for this to make sense, each description has to correspond to its related code.

After a reshaping pattern has been applied, all the original columns will still be available, and a new column for every bank will be added. Moreover, a column representing the line number of the wide-to-long transformation will be added.

Adding a reshape pattern to an object or measure will turn off the grain-explosion warnings, because grain explosion is typically the goal of a reshaping effort.