Create Natural objects for new source system concepts

Background and Strategy

In rare cases, a data source will contain information for which no appropriate Natural object exists. (This scenario was introduced in an earlier task; see Create or extend Semantic Mapping Templates, scenario 3.) If that information is needed for analytic purposes, one or more new Natural objects will need to be created.

The mechanics of creating a new Natural object are relatively straightforward. In most cases, the most straightforward approach will likely be to find and clone a similar Natural object (including its Dedicated Precursor, if one exists), then modify the clone.

New Natural objects taking the form of a timeline are probably an exception to this; in those cases, users should consult with Ursa Health staff to identify the best configuration for the object.

If desired, Natural objects are an appropriate time in the data journey to look up descriptions of coded values or identifiers. For example, Natural objects related to claims look up and publish the names of individual and organizational providers referenced on the claim, as well as the natural language descriptions of ICD-10-CM codes, MS-DRG codes, Type of Bill codes, etc.

For source systems that flag records as deleted rather than actually removing them from their import feed (e.g., to support incremental loading of new data), the standard convention is to remove those deleted records in the Natural object layer. (Among other things, keeping those "deleted" records in the upstream layers provides a clear audit trail of how those records were handled.)

In rare cases it may be appropriate to impute missing values in the Natural object logic. For example, a professional or institutional claim with the same Claim Covered Start Date and Claim Covered End Date values can be assumed to contain only services performed on that date, and therefore the Service Start Date and Service End Date values may be imputed if they were not populated in the source data.

This kind of imputation should be done sparingly, however: Natural objects are meant to represent the plain facts of the data, without any logic that could be taken as an "interpretation" of the data or is at all controversial to any downstream consumer of the data. It would not be appropriate, for example, in the Institutional Claim Service Line Items Natural object, to impute missing revenue center code values from a CPT code. (Application-specific interpretations of that sort should be performed downstream, in the Namespace for the appropriate constituency or application.)

Finally, some Natural objects generate a Document ID, which is a universal record identifier used throughout the data model. Document IDs are particularly useful when records from different objects might need to be collected together for some purpose (in which case the Document ID can be used as a unique identifier).

If it seems likely that records from the new Natural object will need to be collected together with records from other objects, it is probably appropriate to generate a Document ID, which can be done by prepending a token unique to that object to the object's primary key.

Detailed Implementation Guidance

1. A best practice is to only delete a record if the Is Record Deleted field contains a 1; i.e., to consider a NULL value to be equivalent to False in this case. (It's easy to forget to populate the Is Record Deleted field for data sources that don't handle deletions in this way, and so this approach avoids the unintended deletion of records.)