Run Natural objects and validate results

Background and Strategy

Once the upstream, source-specific objects have been connected to all the appropriate Natural objects -- most likely, as described earlier, to a Dedicated Precursor object -- the affected Natural objects should be run in an ELT to generate data.

Running the ELT will also execute any validation rules associated with each object.

Note that Natural objects may receive data from multiple sources, and that records from all sources will be generated when the Natural object is run.

Once run, the validation results of the ELT should be reviewed. Warnings will turn the object's container box yellow in the ELT Progress blade, while errors will turn it red and halt the ELT. Many validation failures will provide a "go to" icon that, when clicked, brings the user to a Case Review screen with the appropriate filters applied to isolate the records that caused the validation failure.

Additionally, the contents of each terminal Natural object should be inspected via Case Review.

Detailed Implementation Guidance

1. For Natural objects that use a Dedicated Precursor object to collect records from all sources, both the precursor and the terminal Natural object should be included in the ELT. However, because Ursa Studio automatically selects all precursor objects to be included in an ELT when their terminal object is selected, it is only necessary to manually select the terminal object. (Selecting both manually will do no harm.)

2. The Category Filter control on the Object Workshop zone landing page can be used to quickly narrow down the selection to non-precursor Natural objects, like so:

3. To the extent it is desirable to run an isolated ELT on only a single source -- for example, to temporarily reduce run times during the validation of a newly integrated source -- the Dedicated Precursors might be updated to include with a restriction to a particular Source ID value. A variant of this is to create a value set of Source ID values to be included and implement these restrictions using an Is In Value Set pattern that invokes that value set; this approach takes a little bit longer to set up initially but allows the data flow into the Natural object layer to be toggled on and off very easily through a single value set, without the continued need to update the affected objects.

4. When performing case review on a Natural object, special attention should be paid to data model key fields -- for example, Patient ID, the various Provider ID fields, Payor ID, Plan ID, etc. -- checking for inconsistencies in how the identifiers are constructed, or whether those fields contain an unexpected quantity of NULL values.

5. When reviewing claims or billing objects, users should also confirm that no records have negative charge, allowed, or paid amount field values.