Skip to main content
Relative identities allow unique identifiers to be generated across multiple data sources based on predetermined, user-defined sets of differentiator data points. This allows for contextual identity to be assigned to a record depending on the lens through which a user views it. This is useful for users who want to supplement the Clinia Platform’s system-generated identifiers with user-defined identifiers and for the platform to manage their lifecycle (generation, merge, deletion).

​
What is it?

A relative identity (RI) has two main components:
  1. A string-based identifier, unique within its relative identity collection.
  2. A set of differentiator properties that set the data context around this RI.
Their lifecycle is system-managed and follows simple rules:
  1. RIs are an MDM-level construct (not available in data sources).
  2. A RI is always attached to one-and-only-one unified record.
  3. A default RI is created for every unified record, without differentiator property attached. This default RI is leveraged in some specific migration use cases
  4. A RI is generated for every set of differentiator property attached to a unified record.
    1. Differentiator properties are formed using source record properties.
    2. Sets of differentiator properties are evaluated based on their closest composite property context.
    3. Sets of differentiator properties are unique per unified record.
  5. When unified records are merged, relative identities are preserved and attached to the surviving record.
    1. Duplicate sets of differentiator properties are merged together. Merged relative identities are preserved as legacy identities to the surviving relative identities.
    2. Unique sets of differentiator properties are preserved with the surviving unified record.
  6. RIs are only deleted when the unified record they are attached to is completely deleted (does not apply to merge). Even though deleted, newly generated RIs will not reuse previously generated RI identifiers, preserving the unicity of the RI sequence.
To further illustrate, let’s use a concrete example.

​
Example

​
Context

As an organization that processes transactions between various health organizations and their patient, I need to reliably and consistently identify the physical location where a service was provided for claim adjudication purposes. The data I possess on health organizations is pushed to my Clinia Platform workspace via multiple data sources and is often repeated across sources. Using the MDM module, I am able to resolve source records for health organizations and assign them a unique identity using unified records. Because the claim adjudication systems consider every health organization and its location unique, a health organization with many service locations needs multiple system-generated identifiers, one for each org/location combination. Additionally, I know every health organization I work with has only one physical service location per state.

​
Solving using Relative Identities

Considering my sources configured with organization profiles that look like:
JSON
{
  "key": "clinic",
  "properties": {
    "name": {
      "type": "symbol",
    },
    "address": {
      "type": "array",
      "items": {
        "type": "address"
      }
    },
	}
}
I can configure a Relative Identity Collection (address-identifier) that looks at an organization’s address information and generates a new identifier for every set of the following differentiator properties:
  1. address.state
  2. address.country
Because this happens within the MDM, identities are only generated after source records are resolved, so if two source records have the same address, a single relative identity exists for that specific address.

​
Relative Identities in Action

  1. An external system pushes information about a new health organization to one of my data sources. It is a net new record, and a new unified record is created in the MDM. The source record has a single address, located in Ontario, Canada.
Unified Record IDDifferentiator Property SetRelative Identity
2ktZXqwTeJrU5XjTjHARvq2f0M6{"state":"ON","country":"CA"}1
  1. Another external system pushes information about the same health organization, but to a different source. The MDM recognizes they are the same real-world entity and links them together. The source record has a two addresses, one in Ontario, the other one in Alberta. Because there is already a relative identity for the {ON:CA} differentiator property set, only one new relative identity is created for the new address in Alberta.
Unified Record IDDifferentiator Property SetRelative Identity
2ktZXqwTeJrU5XjTjHARvq2f0M6{"state":"ON","country":"CA"}1
2ktZXqwTeJrU5XjTjHARvq2f0M6{"state":"AB","country":"CA"}2
  1. A third system pushes information about a new health organization, again to a different source. and a new unified record is created in the MDM. The source record has a single address, located in Ontario, Canada.
Unified Record IDDifferentiator Property SetRelative Identity
2ktZXqwTeJrU5XjTjHARvq2f0M6{"state":"ON","country":"CA"}1
2ktZXqwTeJrU5XjTjHARvq2f0M6{"state":"AB","country":"CA"}2
4ktZXqUwMpZ7jqL3aRfmDJ2an28{"state":"QC","country":"CA"}3
As we can see, the relative identities remain unique across all unified records and differentiator property sets. Ultimately, when retrieving data through an MDM data partition, information about the relative identities for a given record is available to the user. Using the reconciled representation of the data, we have the following partition record.
JSON
{
  "id": "2ktZXqwTeJrU5XjTjHARvq2f0M6",
  "type": "unified-clinic",
  "meta": {
    "identifier": [
      {
        "system": "source-1",
        "value": "2ktbhGtOJeEXA0XT4WkXNa6mlX8",
        "use": "source"
      },
      {
        "system": "source-2",
        "value": "2ktbhMovO8iy9rnIr1GmwLvUwbj",
        "use": "source"
      },
      {
        "system": "clinia-relative-identity",
        "value": "1",
        "use": "address-identifier"
      },
      {
        "system": "clinia-relative-identity",
        "value": "2",
        "use": "address-identifier"
      }
    ]
  },
  "relativeIdentities": {
    "address-identifier": [
      {
        "id": "1",
        "data": {
          "state": "ON",
          "country": "CA"
        }
      },
      {
        "id": "2",
        "data": {
          "state": "AB",
          "country": "CA"
        }
      }
    ]
  },
  "data": {
    "name": "Clinic Smith",
    "address": [
      {
        // ...
        "state": "ON",
        "country": "CA"
      },
      {
        // ...
        "state": "AB",
        "country": "CA"
      }
    ]
  }
}
Using this information, the claim adjudication systems can use the 1 and 2 relative identities as unique identifiers to process claims.

​
Use Relative Identities

Relative identities are most useful inside a partition record. Because they are placed as external identifiers, a record partition record can be retrieved using relative identities and the identifier notation described in Retrieve a resource from a data partition. Furthermore, the relativeIdentities section of a partition record provides users with both active and legacy relative identities, along with their sets of differentiator properties. This allows users to quickly understand the context that surrounds a relative identity and the data tied to it.
⌘I