Atomik Architecture

Atomik is designed as a backend service — a persistence layer for clinical data that sits between your applications and the data store. It does not impose a frontend or a particular clinical workflow. You connect whatever applications you are building to its REST API.

Deployment Model

Atomik runs as a Java/Grails application on the JVM. It can be deployed on-premises, on a private cloud, or on any public cloud provider. The persistence layer uses Hibernate, making it compatible with any relational database that has a JDBC driver.

Supported databases include PostgreSQL (recommended for production), MySQL, Oracle, and SQL Server. The choice of database does not affect the API behavior or data model — Atomik abstracts that through the ORM layer.

Atomik is distributed as a self-contained application package. Docker-based deployment is also available — contact us to discuss your containerization requirements and we will provide the appropriate image.

On-premises

Run Atomik on your own hardware or data center. Full control over the environment and data residency.

Cloud deployment

Deploy on AWS, Azure, GCP, or any VPS provider. No cloud-specific dependencies.

Docker

Docker-based deployment available on request. We provide the container image based on your requirements — there is no public registry.

Managed by CaboLabs

We also offer managed deployment for organizations that do not want to operate Atomik themselves.

API Layers

Atomik exposes four categories of REST APIs. Each serves a distinct function in the overall system.

openEHR REST API

The primary API for clinical data. Implements the openEHR ITS REST specification for storing and retrieving EHRs, compositions, and demographic data. Any openEHR-compliant client can interact with this API without modification.

Standard-compliant

Admin API

For managing users, organizations, templates, stored queries, and system configuration. Used by the Web Console and available for automation scripts and CI/CD pipelines that need to configure Atomik programmatically.

Management

Sync / Cluster API

Enables multiple Atomik instances to synchronize state for high-availability deployments. Used when you need to run Atomik behind a load balancer with more than one active node, or just to have a full backup of your data in a secondary location.

High availability

Monitoring API

Provides health check endpoints and operational metrics. Compatible with standard infrastructure monitoring tools. Useful for uptime checks, capacity planning, and alerting integrations.

Operations

Integration Patterns

How applications typically connect to Atomik depends on what is already in your environment.

Direct API Integration

Applications call Atomik's REST API directly to store and retrieve clinical data. This is the simplest integration pattern and works well for greenfield projects where you control the full stack.

Integration Engine

For environments with existing integration infrastructure — HL7 v2 feeds, FHIR servers, messaging systems and other data sources — Atomik sits behind an integration engine such as Mirth Connect. The engine handles message routing and transformation; Atomik handles clinical data persistence.

API Gateway

In more complex deployments, an API gateway sits in front of Atomik to handle authentication, rate limiting, and routing. Atomik's stateless API layer is compatible with standard gateway configurations.

Shared CDR in a Multi-Application System

When several clinical applications need to share the same patient data, Atomik acts as the shared persistence layer. Each application reads and writes through the same openEHR API, and the data model is governed by shared operational templates.

Scalability

Atomik supports horizontal scaling through its cluster API. Multiple Atomik instances can be synchronized to share state. The stateless REST API layer allows load balancing across instances without session affinity requirements.

For most deployments — a single organization or a small number of tenants — a single Atomik instance with a well-provisioned database is sufficient. Cluster configuration becomes relevant when you need high availability or are handling high write volumes across many tenants simultaneously.

The database is the primary scaling constraint. PostgreSQL's performance characteristics are well-documented, and the Atomik data model is designed to work with standard indexing strategies on the underlying relational schema.