Skip to main content
Clinia data sources are the administrative boundary for everything you ingest into the registry. They capture where a record originates, which schemas it must respect, and how upstream systems are allowed to mutate it. Every workspace can declare multiple sources to mirror each operational system of record you need to consolidate.

​
Source fundamentals

Each source is both a contract and a container:
  • Contract — Sources reference the profiles and relationship definitions that data must respect. They define which data types, validation rules, and vocabularies are allowed.
  • Container — Sources persist the raw resources and relationships exactly as they were ingested, including source-specific metadata needed for traceability.
  • Processing boundary — Pipelines, processors, and validation rules execute per source so that each system can keep autonomous data quality guardrails.
Because all write APIs target a specific source, the registry always tracks provenance and can trace which upstream system produced a given record.

​
Resources

A resource is a record stored under a source that conforms to one of its profiles. Resources include:
  • Data — Properties defined by the associated profile, including nested object and array structures.
  • Meta — System-managed attributes such as identifiers, timestamps, and ingestion receipts.
  • Contained resources — Optional embedded structures declared by the profile. They are versioned together with the parent resource and never queried independently.
Resources are one of the units you search, filter, and surface to downstream applications through partitions.

​
Relationships

Relationships capture graph structure between resources:
  • Definition — A relationship definition declares allowed from/to resource types and the properties carried on each edge.
  • Instances — Each stored relationship references two resource identifiers, its key (the relationship type), optional data payload, and metadata.
  • Traversal — Partitions can traverse relationships so that related properties become available for querying without denormalizing data.
Use relationships to express ownership, participation, service availability, or any link that drives navigational queries across datasets.

​
Objects

Objects let you store binary assets—documents, images, transcripts—next to structured resources while keeping unified governance:
  • They are scoped by source, just like resources and relationships.
  • Each object request produces a task that orchestrates storage, OCR, and downstream processors.
  • Objects participate in partitions through the same query DSL (for example when joining report metadata with structured encounters).
Learn how OCR transforms are executed in the ingestion pipeline basics.

​
Ingesting data into a source

Decide how much coordination each integration requires, then pick the ingestion workflow that matches: Each ingestion option ultimately writes into the same source boundary, so you can mix strategies per integration without fragmenting your registry.

Profiles & Relationships Definitions

Understand how to define your data models

Data Ingestion

Learn how to ingest resources or relationships in bulk

Bundle Ingestion

Learn how to group multiple writes in a single transaction

File Ingestion

Learn how to ingest and process binary objects into searchable content
⌘I