Skip to main content
Data sources are the authoritative entry points for everything you ingest into the Clinia registry. Each source captures where a record originates, which profiles it must respect, and how your upstream system pushes changes into Clinia.

What a data source governs

  • Provenance — Every record, relationship, and object references its originating source so you can audit lineage and route updates back to the right system of record.
  • Synchronization flow — The source declares how data arrives (currently API push) and which environments or jobs publish into it.
  • Processing boundary — Validation, ingestion pipelines, and access controls execute independently per source, allowing teams to tune quality gates without affecting other domains.
The Clinia platform currently only supports API-driven synchronization.

Configuration essentials

A data source definition consists of a unique key, metadata, and the profiles it owns. Keep keys stable because they appear in API paths, identifiers, and audit logs.
{
  "key": "ehr-prod",
  "type": "registry",
}
  • key — URL-safe identifier referenced across registry APIs and partitions. Must follow this pattern: ^[a-zA-Z0-9-][\w-]{0,61}$
  • type — Categorizes how data is managed. Use registry for resources written directly to the Clinia registry.
The Clinia platform only supports registry sources at this time.

Operating data sources

  • One source per schema — When upstream systems expose different schemas or lifecycle rules, create dedicated sources. This keeps validation strict and provenance clear.
  • Coordinate schema changes — Version profiles before pushing breaking changes so ingestion never fails unexpectedly.
  • Secure access — Tie API keys and IAM roles to specific sources to prevent accidental cross-domain writes.
  • Monitor freshness — Track ingestion timestamps to surface sources that stopped publishing data.

Keep exploring

I