Atomik Features

Stores clinical data using openEHR compositions. Data structure is defined by operational templates, not by database schemas. You can change what you collect — adding new clinical concepts or modifying existing ones — without touching the database or redeploying the application.

This separation between the data model and the software is the core design principle of openEHR, and it is what makes Atomik suitable as a long-term clinical data store.

Atomik includes a built-in query engine with a visual query editor and query testing tool. Queries are defined, named, and managed through the Web Console, then called by name from your application — no SQL against an undocumented schema.

AQL (Archetype Query Language) is the openEHR standard for structured clinical queries. Atomik supports a working subset of AQL covering common retrieval patterns — filtering by patient, time range, template, or data point. Full AQL compliance is on the roadmap.

Atomik can expose clinical data as FHIR R4/R5 resources through a FHIR facade built on top of your openEHR data model. This is something we design and build for your specific use cases — not a generic automatic mapping.

The process starts with defining which clinical domains you need to support via FHIR. We then design the corresponding FHIR profiles and map them to the relevant openEHR templates in Atomik, enabling full bidirectional operations — create, update, read, and search — through a FHIR API. No data duplication: the mapping happens at query time against the openEHR data store.

Browser-based admin interface for managing operational templates, EHRs, compositions, stored queries, users, and audit logs. No command-line access required for day-to-day management.

The Web Console is also useful during development: you can upload templates, browse stored data, and inspect composition structure before writing a single line of application code.

Every composition stored in Atomik is versioned automatically. The full history of changes is preserved and queryable — including who made the change, when, and what the previous value was.

This is not optional behavior you need to implement. It is built into the openEHR specification and Atomik implements it by default, satisfying a core requirement for clinical record systems.

Atomik is designed as a mono-tenant system — each instance serves a single organization. For production deployments that require high availability, Atomik can be deployed as a cluster of nodes with automated redundancy and backups.

A clustered deployment distributes the load across nodes and ensures clinical data stays accessible even if individual nodes fail, with no manual intervention required.