
Questions we hear regularly from developers, architects, and technical leads evaluating Atomik for their projects.
A relational database stores data in tables and schemas that you define. You decide the column names, data types, and relationships — and when the requirements change, you write a migration and update your application code.
Atomik stores clinical data using openEHR templates, which means the data model is defined separately from the database schema. You can add new clinical concepts or modify existing ones without touching the database or deploying new code. The trade-off is that you need to understand the openEHR information model to work with Atomik effectively — it is not a drop-in replacement for a general-purpose database.
Yes — through a FHIR facade tailored to your project's specific clinical domains and use cases. Atomik supports FHIR R4/R5 by building a custom facade on top of your openEHR data model, with FHIR profiles designed to match your data structures.
We work with you to identify the domains you need to support via FHIR, design the corresponding profiles, and map them to your openEHR templates. The result is a FHIR API with full bidirectional support — create, update, read, and search — with no data duplication. The mapping happens at query time against the openEHR data store. Contact us to discuss your FHIR integration requirements.
Atomik's persistence layer uses Hibernate, which makes it compatible with any relational database that has a JDBC driver. PostgreSQL is the recommended database for production deployments. MySQL and Oracle are also supported.
The choice of database does not affect the API behavior or data model. Atomik abstracts the underlying storage through the ORM layer, so the same application code and openEHR templates work regardless of which database you use.
Yes. Atomik is mono-tenant by design — each instance serves a single organization. For production environments that require high availability, Atomik can be deployed as a cluster of nodes with automated redundancy and backups.
A clustered deployment keeps clinical data accessible even if individual nodes fail, with no manual intervention required.
Atomik implements the openEHR ITS REST specification and the openEHR Reference Model. It stores compositions that conform to operational templates, implements the openEHR versioning model for all stored clinical data, and includes a query engine with a visual query editor that supports a working subset of AQL. Full AQL compliance is on the roadmap.
Compliance details, including which parts of the specification are implemented and any known limitations, are documented in the Atomik documentation.
Integration typically involves three things:
For most projects, this takes days to weeks depending on the complexity of the data model and whether your team is already familiar with openEHR. The largest variable is usually the time needed to design and validate the operational templates, not the API integration itself.
Yes. We offer managed deployment for organizations that do not want to operate Atomik themselves. Under a managed deployment, CaboLabs handles infrastructure provisioning, application updates, monitoring, and initial configuration.
Contact us for details on availability, SLAs, and pricing for managed deployment. See also the Pricing page.
Contact us to arrange an evaluation. We can set up a demo environment with sample templates and data so your team can explore the platform — the Web Console, the REST API, AQL queries — before committing.
An evaluation works best when your team already has some familiarity with openEHR. If you are new to the standard, we recommend starting with the openEHR Foundations course first, then evaluating Atomik with that background.
Contact us directly and we will give you a straight answer.
Get in touchLet us know how we can help you.