Skip to main content
MDM partitions deliver a consolidated view of entities that have been resolved, reconciled, and governed by the master data management (MDM) layer. They are the primary channel for applications that need a single source of truth instead of raw source-specific records. MDM partition data flow

​
How MDM partitions unify data

  • Entity resolution — Records coming from multiple data sources are matched and linked into unified records. The partition surfaces this unified identifier so downstream systems never have to duplicate reconciliation logic.
  • Reconciliation rules — Each unified resource or relationship applies reconciliation strategies to decide which properties win, how conflicts are resolved, and when to merge or split entities.
  • Relative identities — Unified records preserve lineage back to the source and any relative identities that must be tracked for compliance or downstream updates.
  • Search-ready aggregates — After reconciliation, the partition indexes the output so applications can query, facet, and include related information with the same APIs used by source partitions.
MDM partitions are built for decision support, analytics, and omni-channel experiences that require harmonized data. Keep a companion source partition when teams still need access to the untouched source payloads.

​
Configuration model

MDM partitions share the same Data Partition API as source partitions, with a few additional constructs:
  • source.type — Set to MDM to indicate the partition consumes unified data.
  • source.sources — Declares which source keys contribute records to the MDM collections exposed here.
  • collections — Each entry references an MDM resource key and specifies how to index it. Collections include:
    • mappings mapping MDM output back to source profiles to enrich unified records.
    • Optional reconciliationRules to select a SYSTEM strategy or a CLINIA_FUNCTION that encapsulates custom merge logic.
  • relationships — Unified relationships available for traversal. Like collections, they support mappings, reconciliationRules, and includeKey definitions for each side of the graph.
{
  "key": "provider-master",
  "modules": {
    "search": "STANDARD"
  },
  "source": {
    "type": "MDM",
    "sources": ["ehr-core", "claims-legacy"],
    "collections": [
      {
        "key": "mdm-provider",
        "mappings": [
          { "source": "ehr-core", "type": "provider" },
          { "source": "claims-legacy", "type": "physician" }
        ],
        "reconciliationRules": {
          "type": "SYSTEM"
        }
      }
    ],
    "relationships": [
      {
        "relationshipType": "provider-facility",
        "from": {
          "profileKey": "mdm-provider",
          "includeKey": "worksAt"
        },
        "to": {
          "profileKey": "mdm-facility",
          "includeKey": "employs"
        },
        "mappings": [
          { "source": "ehr-core", "type": "provider-facility" }
        ],
        "reconciliationRules": {
          "type": "CLINIA_FUNCTION",
          "name": "facility-link",
          "version": "v1.0.0"
        }
      }
    ]
  }
}
Use this configuration when you want consumers to interact exclusively with unified resource keys and relationship graphs produced by the MDM domain.

​
Collection and relationship connections

Collection and relationship connections define how unified MDM profiles or relationships appear inside a partition. They inherit the identities created by the MDM layer, describe the shape of the records that will be indexed, and map each property back to one or more contributing sources.

​
Collection connections

A collection connection links a partition collection to a unified MDM collection. It covers:
  • Identity binding — The connection chooses the unified collection whose identifiers the partition will surface.
  • Property shape — The properties block defines the fields and Clinia data types exposed to downstream queries.
  • Source mappings — Each entry in mappings attaches one or more source profiles and points their fields to the unified properties that should receive the values.
propertyMappings use the unified property path as the key (for example address.street) and the source property path as the value. This keeps the transformation declarative and avoids writing ad-hoc merge code.
The snippet below shows a partition collection that surfaces the unified-organization profile while reconciling attributes from three different source profiles: 
{
  "key": "unified-organization",
  "properties": {
    "name": {
      "type": "symbol"
    },
    "phone": {
      "type": "contactpoint"
    },
    "email": {
      "type": "contactpoint"
    },
    "address": {
      "type": "address"
    }
  },
  "mappings": [
    {
      "source": "source-1",
      "type": "clinic",
      "propertyMappings": {
        "name": "name",
        "address": "address",
        "phone": "phone"
      }
    },
    {
      "source": "source-2",
      "type": "organization",
      "propertyMappings": {
        "name": "name",
        "address": "address",
        "phone": "phone",
        "email": "email"
      }
    },
    {
      "source": "source-3",
      "type": "doctor-office",
      "propertyMappings": {
        "name": "name",
        "address": "address",
        "email": "email"
      }
    }
  ]
}

​
Relationship connections

Relationship connections extend the same concepts to graph edges. They ensure that unified relationship identities flow into the partition, expose the from and to sides using the unified profile keys and include paths, and map edge properties back to contributing sources. Use relationship connections when you want downstream applications to traverse the harmonized graph instead of rebuilding joins on raw source relationships. 
{
  "relationshipType": "provider-office",
  "from": {
    "profileKey": "unified-organization",
    "includeKey": "staff"
  },
  "to": {
    "profileKey": "unified-provider",
    "includeKey": "worksAt"
  },
  "properties": {
    "effective": {
      "type": "period"
    },
    "phone": {
      "type": "contactpoint"
    }
  },
  "mappings": [
    {
      "source": "source-1",
      "type": "provider-clinic",
      "propertyMappings": {
        "effective": "effectiveDate",
        "phone": "phoneNumber"
      }
    },
    {
      "source": "source-2",
      "type": "provider-organization",
      "propertyMappings": {
        "effective": "effective",
        "phone": "phone"
      }
    },
    {
      "source": "source-3",
      "type": "provider-office",
      "propertyMappings": {
        "effective": "effective",
        "phone": "phone"
      }
    }
  ]
}

​
Operational considerations

  • Latency trade-offs — Unified data becomes available after entity resolution and reconciliation complete. Monitor processing pipelines to understand when refreshed records appear in the partition.
  • Governance — Because MDM partitions represent system-of-record entities, manage access through IAM policies and auditing.
  • Schema stewardship — MDM profiles evolve independently from source schemas. Coordinate updates with MDM owners to avoid breaking reconciliation logic or downstream consumers.
  • Quality feedback — Pair partitions with workflows that push anomalies back to data stewards when reconciliation rules drop attributes or produce conflicting merges.

​
Traversed Properties

In MDM partitions, traversed properties expand a partition collection beyond the recipient resource. By indexing selected attributes from adjacent relationships and resources, searches can answer cross-entity questions without duplicating data or denormalizing schemas.
Traversed properties are a search-only construct. They are indexed with the recipient resource but are not returned by GET calls to the underlying partition APIs.

​
Configuring traversals

Traversed properties are declared on each collection inside an MDM partition: 
{
  "key": "unified-provider-directory",
  "modules": {
    "search": "STANDARD"
  },
  "source": {
    "type": "MDM",
    "sources": ["ehr-core", "claims-legacy"],
    "collections": [
      {
        "key": "mdm-provider",
        "mappings": [
          { "source": "ehr-core", "type": "provider" },
          { "source": "claims-legacy", "type": "physician" }
        ],
        "traversedProperties": [
          "@practices.startDate",
          "@practices.@mdm-facility.address.city"
        ]
      }
    ],
    "relationships": [
      {
        "relationshipType": "provider-facility",
        "from": {
          "profileKey": "mdm-provider",
          "includeKey": "practices"
        },
        "to": {
          "profileKey": "mdm-facility",
          "includeKey": "staff"
        }
      }
    ]
  }
}
  • traversedProperties lives under the collection entry in the partition configuration.
  • Each entry references an include configured in the partition (@practices above) and drills into relationship or resource properties using dot notation.
  • Only primitive and general-purpose complex Clinia data types are supported. Nested properties within custom types can still be reached with dots.

​
Traversed property notation

  • @{includeKey}.{propertyKey} — Targets a relationship property, such as @practices.startDate.
  • @{includeKey}.@{resourceType}.{propertyKey} — Targets a property on the adjacent resource, such as @practices.@mdm-facility.address.
  • @{includeKey}.@{resourceType}.{containedKey}.{propertyKey} — Targets a property on a contained resource under the adjacent resource, such as @practices.@mdm-facility.location.address.
The same notation is used consistently when declaring the partition configuration and when issuing queries.

​
Querying traversed properties

When searching a partition collection, use traversed property paths anywhere you would reference a standard property:
  • Filters — Narrow results to resources where the traversed attribute meets certain criteria.
  • Sorting — Order results based on relationship metadata or linked resource attributes.
  • Facets and aggregations — Build counts or distributions over traversed values.
curl -X POST "https://$CLINIA_WORKSPACE/partitions/unified-provider-directory/v1/search" \
  -H "X-Clinia-API-Key: $CLINIA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "collection": "mdm-provider",
    "filters": "@practices.@mdm-facility.address.city:\"Montréal\"",
    "sort": [{ "attribute": "@practices.startDate", "order": "desc" }]
  }'
Because traversed properties update whenever the linked relationships or resources change, search results stay aligned with the latest adjacent data without needing to reingest the recipient collection separately.

​
Example

Imagine a healthcare directory where providers are linked to facility profiles through a provider-facility relationship and exposed via the practices include:
  • The provider collection stores clinical specialties and licensing information.
  • The facility resource holds the location address and accessibility features.
  • The relationship captures the employment period and role.
By traversing the facility address and the relationship’s startDate, a single provider search can answer “Which providers accepting new patients work in Montréal right now?” without duplicating address data on every provider record. This approach keeps unified MDM schemas focused while still enabling rich, relationship-aware search experiences.

​
Keep exploring

MDM partitions

See how traversed properties apply when serving unified entities.

Traversed properties overview

Revisit the concepts behind traversed properties and traversal rules.

Traversed filters how-to

Put traversed filters to work in analytic and discovery scenarios.

​
Keep exploring

Entity resolution outcome

Dive into the reconciliation strategies that shape unified records.

Relative identities

See how lineage and external identifiers stay attached to unified entities.

Entity resolution preview

Understand how aggregated record previews guide stewarding decisions.

Traversed Properties

Learn how to configure related resource attributes directly in your MDM partition.
⌘I