Registered Table Objects

Overview

Registered table objects serve as an integration point to database tables that exist outside of Ursa Studio. Any pre-existing client database table that Ursa Studio has access to may be registered. This allows the table to be included in the Ursa ELT process, although the table itself will not be affected by an ELT. Accordingly, registered objects only give the option to "build downstream" during ELT.

To create a registered table object users should navigate to the Object Workshop home screen and click the plus sign icon in the upper right corner. In the Create New Object screen, select the Registered Table tile. In the Registered Table object screen, update the parameters listed in the panels detailed below. When the registered table object's parameters have been specified, select the save icon in the upper right corner of the screen. The browser then redirects back to the Object Workshop home screen and the process is complete.

Naming

Object Namespace: Namespaces contain different information about data assets depending on the asset type, and in the case of objects, the associated data model layer. An registered table object's namespace typically describes the data’s source, e.g., BCBS, Humana; etc.

Object Name: The object name is how the object will be referenced throughout Ursa Studio. The convention used by the Ursa Health team for naming registered table objects has three parts, [“Source”]+[Namespace]+[Table Description]. First, the word “Source” is used to indicate the object is associated with the Source Data layer of the data model. Second, the object’s namespace is included. Third, a brief description of the table is included. “Source ACMEHEALTH-BCBS Membership” is an example of how most registered table objects are named.

Object Description: The object's description provides a brief explanation on the contents of the object. The convention used by the Ursa Health team is to describe the grainsize of the table being registered in this field, e.g., “One row per member.” However, it is common for object descriptions to contain more than this minimum information.

Table Name: This field is where the schema and name of the table being registered is entered, e.g., schema.table_name. Mixed-case table names are allowed for databases whose tables are case-sensitive, whereas table names of other Ursa-managed objects are required to be lowercase.

Tags: Tags are general purpose labels that can be applied to a variety of data assets in Ursa Studio for identification and categorization. For example, the Ursa Health team uses an "In Development" tag to identify objects and measures that are currently under development.

Object Metadata

Layer: This field captures the data model layer the object is associated with. For registered table objects this will typically be the “Source Data” layer, which indicates the table being registered is in the initial stage of integration.

Is Dedicated Precursor: This option allows the object to be set as a dedicated precursor to a terminal object. It is atypical to select this option for a registered table object.

Is Visible to Layers / Use Layer Default: This option specifies the object's visibility in the data model, i.e., which layers in the data model the object will be visible to. Registered tables can be made visible to Object Workshop and Measure Workshop. Unless there is a specific reason for altering the default visibility, which is uncommon, users should leave the default layers selected.

Temporal Class: Select the appropriate, temporal class for the object. Temporal class is a categorical description of an object’s relationship to time. Object can have a temporal class of event, interval, or entity. If a table’s records represent a moment in time, e.g., claims or an ED visit, then select event. If a table’s records represent a period of time with a start and end date, e.g., episodes, then select interval. If a table’s records do not represent a moment in time or a period of time, e.g., a list of health plans or providers, then select entity.

Case ID: Select the field or fields that uniquely identify each record in the table. 

Validate Case ID is Unique: Select this option to validate the field or fields selected in the previous option do in fact uniquely identify each record in the table.

Patient ID: If the table contains a field that identifies patients or members, select that field here.

Once a table is specified in the Naming panel, the tables fields will be listed in a two-column table at the bottom of this panel. The table’s first column, “Column” lists all columns in the table being registered along with each column’s data type. The second column, “Label” shows how the column will appear throughout Ursa Studio. Users have the opportunity to overwrite each column’s default label, however if the table being registered is going to serve as an input into a semantic mapping object, which will generally be the case, there is no need to update the labels. 

Terms

Users have the option of associating terms with the registered table object by selecting terms from the dropdown in this panel. If the table being registered is going to serve as an input into a semantic mapping object, typically terms will be associated with the object during the mapping process.

Incremental Load

Registered table objects can support incremental loads meaning that downstream objects can incrementally pull data from the registered table. To enable incremental loads, select the checkbox and a tracking field, which is a date or datetime field representing when each updated tranche of data was processed.