Skip to main content
Profiles are the contracts that govern every resource stored under a data source. They define which properties exist, how values are validated, and which contained structures travel with each record. Each ingested resource must reference a profile key, making profiles essential for data quality and interoperability.

​
Profile types

  • ROOT profiles — Represent top-level resources (for example provider, facility, plan). Each ROOT profile becomes its own collection inside the source and can be exposed directly through partitions.
  • CONTAINED profiles — Represent reusable components that live inside a parent resource, such as operating hours, licensing details, or addresses with additional metadata. They are versioned alongside the parent record and are not addressable on their own.
When deciding between ROOT and CONTAINED, ask whether the data should be queryable on its own or shared across multiple parents. If it should be queryable on its own, create a ROOT profile and connect records with relationships instead.

​
Anatomy of a profile

A profile describes its type, properties, optional contained components, and any validation rules. The example below highlights common patterns. 
{
  "type": "ROOT",
  "description": "Healthcare provider practicing within the network",
  "properties": {
    "name": {
      "type": "humanname",
      "rules": [{ "required": true }]
    },
    "specialties": {
      "type": "array",
      "items": {
        "type": "code",
        "binding": {
          "vocabulary": {
            "key": "medical-specialty",
            "strength": "preferred"
          }
        }
      }
    },
    "acceptingNewPatients": {
      "type": "boolean"
    }
  },
  "contained": {
    "openingHours": {
      "types": ["weekly-hours-of-operation"],
      "cardinality": "0:1"
    }
  }
}
  • properties — List each attribute and its data type. Use validation rules to enforce required fields, ranges, enums, or vocabulary bindings.
  • contained — Declare embedded components by referencing other profile keys and their cardinality.
  • description — Document the business meaning so stewards understand how the schema should evolve.

​
Designing robust profiles

  • Start with shared components — Model reusable structures (addresses, hours, identifiers) as contained profiles so you can embed them consistently across ROOT profiles.
  • Validate early — Use rules and vocabularies to fail fast when data violates expectations. This keeps ingestion clean and downstream reconciliation easier.
  • Plan for evolution — Introduce new optional properties before deprecating old ones. Coordinate schema updates with upstream producers to prevent ingestion failures.
  • Document relationships — Capture how profiles connect using relationship definitions so downstream consumers understand the graph.

​
Keep exploring

Data sources

Understand how profiles attach to the systems that publish data.

Relationships

Learn how profiles connect to form the registry graph.

MDM partitions

See how unified views consume profile-defined schemas downstream.
⌘I