Define Measure Properties

At the root configuration screen of the measure, the user can identify measure metadata, such as the measure unit (e.g., percentage, number) and the case field(s). Descriptions of the meaning of each metadata property are shown by hovering over the question mark beside each field.

The measure root configuration screen is also the place to define the denominator and numerator contribution, a process very similar to the creation of a derived field in an object.

Component Class

All measures must be marked as having a component class of either long form or normal form. Long-form measures have multiple rows of data that roll up to the observation level. For example, a measure describing patients who have more than one home health visit after a surgery will be long form because the grain of the observation is each surgery, but the raw measure data will be one per home health visit.

If a measure is marked as being normal form but in practice has more than one row for observation (as adjudicated by the measure’s case fields), the measure will error during instantiation. Similarly, if a measure is marked as being long form, there is a report-run-time validation to make sure that no denominator field varies within a case. Measures with such a setup will show an error in the report instance screen. The appropriate remediation is to choose a denominator case field such that all denominator fields are unvarying within each case, or to change the origin of the field from denominator to numerator.

Effective Dates

The effective date pins the measure to the timeline. For example, if you're examining analytics on a monthly basis, you'll have a new data point for each month that represents the state of the measure at that specific time. The effective date you choose will depend on the temporal structure of the measure.

In an event measure, the effective date is typically the event date. However, for an entity measure, which is often used for patient populations operating over time, the effective date is determined by taking snapshots at regular intervals (e.g., monthly or quarterly). These snapshots are used to pin the measure to the timeline. The effective date for an entity measure typically involves the period start and end date.

Numerator and Denominator Contributions

Numerator and denominator contributions determine how the measure value will be calculated. The numerator contribution is what you're actually measuring. For example, if the measure is the elapsed time for a primary care visit after discharge, you'd likely use the elapsed time pattern for the numerator contribution. On the other hand, if the measure is the count of primary care visits within the next 12 months, the numerator contribution would be the count of those visits.

The denominator contribution is often one per case, though it doesn't always have to be. In some cases, like in PMPM (Per Member Per Month) measures, the denominator can be a period or an elapsed time between the period start and end.

It's important to note that in the Analytics Portal, you can swap out the numerator contribution with any other numeric field on the measure using measure expressions. This allows users to adapt the measure at an ad hoc analytics level to suit their specific needs.

Fully Collapsed Optimization

Users can reduce storage size, instantiation time, and request time for very large measures by choosing fully collapsed optimization. For such measures, the details are stored on an aggregate level, summarized by the cross product of all the analytic fields. Because case detail is lost, Case Review will be unavailable. Filtering on non-analytic fields is similarly disabled, and confidence intervals will not calculate. Otherwise, the measures will appear in Analytics Portal as normal.

Primary Keys

Primary keys will be added whenever possible to measures upon report run. Generally, users will be able to dictate whether or not the primary key will be naturally derived from the case field, or whether the primary key will be a new autonumber field named ursa_serial_id, by means of a checkbox in the "Configuration" panel of measures, immediately below the control to dictate the case field.

This checkbox will be checked by default for measures with a case field defined, which means that the tables will default to using the case field to drive the primary key.

When being driven by the case field, the primary key is not necessarily the same as the case field. For entity measures, the primary key will be the case field plus the snapshot date. For interval measures, the primary key will be the case field plus the period start and end dates.

For long-form, count, and fully collapsed measures it is impossible for the primary key to be reliably derived from the case field. For these measures the checkbox will be hidden and the primary key will always be ursa_serial_id.

For all these permutations, a tooltip alongside the checkbox will explain the primary key that will result by following the above rules.

For views and RDBMSes that do not support primary keys, it will not be possible to add a primary key, but validation will be performed during report run to verify that the fields chosen as the primary key are unique.

These primary keys represent an added rigor into the ELT process that might cause measures to fail the validation/post-processing step. Generally, this will be because the case field on the measure is not unique or non-nullable as it should be, and the error will be an opportunity to inspect the construction of the measure. However, for users in a hurry, the escape hatch of unchecking the new checkbox will cause the object or measure to fall back to the use of ursa_serial_id as the primary key, which should cause the measure to run without error.