Migrating Relative Identity Identifiers

Relative Identity Collection (RIC) can be leveraged to ensure that data migrated to the Clinia Platform continues to generate the same type of identifiers as a legacy system. In this scenario, the RIC will start generating new identifiers starting from the offset value but won't account for pre-existing identifiers unless users migrate those identifiers to the platform.

To do so, users can leverage source record external identifiers. Since sets of differentiator properties are evaluated based on source data, it makes sense that migrating relative identity identifiers happens through source records.

*System-generated relative identities will never be available on a source record due to being an MDM-level construct. Only user-provided relative identity identifiers used for migration will be available.

How does it work?

Using Historical Import and the meta.identifier section for external identifiers, users can migrate a relative identity identifier to be assigned to a unified record once the MDM module processes the source record. The identifier should be formatted as such:

{
  "system": "clinia-relative-identity",
  "value": "<identifier-value>",
  "use": "<relative-identity-collection-key>"
}

The Clinia Platform will recognize the reserved system and process the external identifier accordingly. To ensure a successful migration, users should make sure that:

1. The value complies with the RIC identifier configuration. This means it should respect the format set in the configuration and be lower than the offset value.
2. The use references a valid RIC.
3. The migrated identifier is unique within its data source. No two source records can share a relative identity identifier.

If 1. or 2. happens, the system will create a queue item in the External Identifier Queue with relevant issues for Data Stewards to resolve.

📘

Migrated Identifiers are considered legacy

Migrated relative identity identifiers will not be inserted directly into the existing sequence for a given RIC. Rather, they will be made legacy to existing relative identities. If no relative identity exists for a given set of differentiator properties, it will be created and the migrated identifiers made legacy to that new relative identity.

Determining the closest composite property context for an RI

When migrating relative identity identifiers, external identifiers are not inherently associated with specific differentiator properties. To ensure migrated identifiers are correctly assigned to a specific set, make sure to use the right composite property context.

If the RIC differentiator properties are mapped to properties of a root source profile, use the top-level resource meta.identifier for migrated identifiers.

JSON

{
  "id": "<resource-id>",
  "type": "<root-profile-key>",
  "meta": {
    "identifier": [
      {
        "system": "clinia-relative-identity",
        "value": "100",
        "use": "object-id"
      }
    ]
  },
  "data": {
    // ...
  },
  "contained": {
    // ...
  }
}

If the RIC differentiator properties are mapped to properties of a contained source profile, use the contained resource meta.identifier for migrated identifiers.

JSON

{
  "id": "<resource-id>",
  "type": "<root-profile-key>",
  "data": {
    // ...
  },
  "contained": {
    "<contained-key>": [
      {
        "id": "<contained-resource-id>",
        "type": "<contained-profile-key>",
        "meta": {
          "identifier": [
            {
              "system": "clinia-relative-identity",
              "value": "100",
              "use": "object-id"
            }
          ]
        },
        "data": {
          // ...
        }
      }
    ]
  }
}

📘

Migrated Relative identity identifier Fallback

If the system is unable to assign a single set of differentiator properties to a migrated relative identity identifier, that identifier is going to be assigned to the default relative identity for the unified record.