Introduction

Every time your data requirements change, how long does it take your team to ship the update?

A new vital sign to capture. A new device to integrate. A new field a regulator requires. In most healthcare systems the answer is the same: database migration, back-end changes, updated APIs, new UI — a full dev cycle, QA included, for what should be a data definition change.

Atomik is built around a different premise: data definitions live outside your software. When requirements change, you update the model — not the code. Your persistence layer, APIs, and business logic stay untouched. That's the core of what these docs explain.

Questions? Email info@cabolabs.com anytime.

What Atomik Is

Atomik is a Clinical Data Repository (CDR) and Demographic Data Repository (DDR) — a persistence component you drop into your healthcare software architecture to handle clinical and demographic data storage, versioning, audit, and query.

It is purpose-built for healthcare: patient records, clinical documents, vital signs, diagnoses, medications, demographics, and the governance layer that clinical data requires. Not designed for financial, administrative, or inventory data.

What you get out of the box — so you don't build it yourself:

  • Schema-free clinical storage — add new data types via openEHR templates, no code or DB migration needed
  • Automatic data versioning — every change creates an immutable new version; nothing is overwritten
  • Full audit trail — every API interaction logged with user, timestamp, and resource
  • openEHR compliant — data is portable across any openEHR-conformant system; no vendor lock-in
  • FHIR interoperability available — a FHIR Server facade can be connected to Atomik for bidirectional operations, adapted to your specific FHIR profiles and openEHR models
  • Dual repository — clinical and demographic data in one deployment
  • Database-agnostic — swap the underlying relational DB without touching application code
  • Web Console — manage templates, queries, and audit logs without writing code
  • REST API — integrate from any stack via standard openEHR REST endpoints

Where to Start

Building a new healthcare app from scratch?

  1. Getting Started — store your first clinical record in under 30 minutes
  2. openEHR basics — understand the data model Atomik is built on
  3. Managing data models — define the clinical structures your app needs
  4. Storing data — commit records via API
  5. Querying and retrieving data — get data back out

Integrating Atomik into an existing system?

  1. openEHR basics — understand how Atomik models data
  2. Managing data models — map your existing data structures to openEHR templates
  3. Storing data — integrate your write path
  4. Integrations — connecting legacy systems and live data sources to Atomik

Evaluating Atomik for a specific use case?