Other Object Types

Single Stack

The single stack is a general-purpose tool to link multiple tables into a single table, using any of the restrictions and transformations of Object Workshop. Single stacks can be used in any layer.

Integrator

Integrator objects are used to generate the union of records from different “input” stacks. Users define a set of “output” fields, either manually or by selecting fields from among existing semantic mapping templates or objects; input object fields are then mapped to this standard, which become the fields for the resulting object. While the functionality of Integrator objects overlaps somewhat with the functionality of subpopulations, Integrator objects are intended to provide a more structured chassis -- e.g., having a fixed set of output fields -- for integrating objects containing similar data but from different sources, a common need for objects in the natural object layer. 

In integrator objects the two ways to "publish" a field is to map it to an output field, or define it at the root scope, which is "after" the integration step. Integrator output fields can also be set to "unpublished". Such fields could be used as inputs to root-scope derived fields, and allowing them not to be published will make it possible for the derived field to have the same label as the output field.

Once a field has been mapped, the typical indicators, a checked box in the Available Fields panel or the "Published" icon in a derived field pattern, will be visible. The field will also appear on the Published Fields panel in the root object properties page.

Integrator Objects have a Master Data Management Record Matching panel, used to fuzzy-match records based on a configurable rule set. Using this feature will generate a new Master Record ID field, which will be populated with the same value for "matching" cases. Record Matching also allows asymmetric field matching, in which field values might be compared to the values in a different field. Users can take implement asymmetric field matching by setting up families of mutually equivalent fields, and then adding that family to a record matching criteria set.

Simple Timeline

The simple timeline takes a single concept—either an event or an interval—and constructs an object whose instances, representing periods of time along an entity's timeline, are guaranteed to be non-overlapping.

Complex Timeline

The complex timeline is a flexible pattern that allows users to combine multiple intervals—including those defined by the user based on events—into a single timeline. The resulting timeline is guaranteed to have no overlapping periods for the same patient (or whatever entity is designated).

Attribution Timeline

Attribution timelines are used to identify a relationship between an attributed entity (e.g., a patient) and a single attributee entity (e.g., the primary care provider) from among many potential candidates (e.g., other physicians the patient has seen recently). The result is a set of records representing non-overlapping periods when the attributed entity on the record is attributed to the attributee on the record.

Simple Episode

A less specialized version of the Medication Therapy Episode object, Simple Episode objects take a stack of events-with-post-event-windows — analogous to pharmacy fills with days supply — or intervals, overlapping or not — and assign an "episode ID" that identifies all such component records that are part of a single continuous episode. 

Medication Therapy Episode

The medication therapy episode object represents a series of fills for the same type of medication with little or no gaps in time between the end of the last fill's supply and the next fill.

Ursa Standard Objects

Ursa Standard objects have healthcare-related business logic baked into them, as opposed to Object Workshop, which is a flexible and domain-agnostic tool for building objects.

Ursa Reference Objects

Ursa Reference objects load Ursa-curated reference data sets into the environment. These objects will typically be managed by Ursa Health, because they must link with Ursa Health Standard Reference files, which are kept in an Ursa-owned storage container.

Measure Object

Users can set a measure act like an object, via the "Replicate as Object" panel in Measure Workshop. Such measures will be given object metadata such as table name and layer visibility. They will furthermore inherit report metadata from a "Reference Report", designated in the same panel. Once a measure is replicated as an object, it will be available for ELT in Object Workshop and can be used in downstream development like any other object.

Measure objects should primarily be used if there is a need to create new downstream objects out of data frames that currently exist only as measures. If users are just looking for a way to e.g. find a stable way to connect a third-party tool such as Tableau to a measure's data frame, they should use the view that's automatically associated with the measure, whose details can be seen upon expansion of each measure in the report instance screen.