Configure and run the patient and provider mastering objects

Background and Strategy

As noted earlier, the Ursa Health Core Module includes pre-configured objects for mastering patients and providers (Source Local Patient ID Crosswalk to Data Model Patient ID and Source Local Provider ID Crosswalk to Data Model Provider ID, respectively). If patients or providers were identified as concepts where mastering was needed, these objects should be updated to draw from the relevant source objects (typically Semantic Mapping or Registered Table objects) and execute the desired matching logic.

In addition to the matching criteria described in the prior task, there are some other aspects of the master data management – mainly dealing with how the new master identifier values are generated – that should be reviewed and possibly updated.

After all the groups of matching records have been identified – including singleton groups consisting of just one record with no matches – a new, unique Master Record ID value is generated for each group. This new field – whose name can be modified by the Master Record Label control – is added to every record in the table, and takes its value from the first-ranked record in each group, with the ranking order defined by the Master Record ID Ranking control. The value that is populated in this field is determined by the Master Record Values Source control, which defaults to the primary key of the object – typically, the natural key composed of the Source ID and the appropriate “Source Local” identifier.

Examples

Example 1: Patient mastering using the Source Local Patient ID Crosswalk to Data Model Patient ID object

To illustrate how all this might work in practice, consider the Source Local Patient ID Crosswalk to Data Model Patient ID object – i.e., the standard patient mastering object. As configured out of the box, the Master Record ID Value Source is set to the default setting, Case ID (meaning whatever field or fields are defined as the object’s Case ID in the Object Metadata panel: in this case, the Source ID-Source Local Patient ID pair); the Master Record ID Label is set to "Matched Patient ID"; and the Master Record ID Ranking is set to favor the record with the earlier Documentation Datetime value (with ties broken to favor the record with the earliest Source Data Effective Datetime). If we had, for example, the following four matching records:

…the mastering would add a new field, Matched Patient ID, with values as shown here:

This example helps illustrate the benefit of favoring the oldest record when generating the Matched Patient ID: favoring the newest record instead would mean that every time a new record with a more recent documentation datetime was matched, the assigned Matched Patient ID value would change for that patient; which might be disruptive for analysts looking at downstream results. (Note that using the oldest record’s identifier does not imply that the patient demographics and other characteristics must be taken from that record as well – that processing, which is independent of this, favors the newer record’s values.)

This example is also a useful reminder that mastering should be performed on data from all sources simultaneously, and should not just be limited to the current source being integrated.