Atomik Integrations

Atomik is designed to integrate. It does not try to be a monolithic system that handles everything — it is a data platform that connects to the tools your organization already uses. Integration is handled through published standards wherever possible, so you are not locked into proprietary connectors.

Standards Atomik Supports

Using published standards means less custom code on the integration layer and fewer decisions that only your team understands.

openEHR REST API

Atomik implements the openEHR ITS REST specification. Any openEHR-compliant client can interact with it without modification — storing and retrieving EHRs, compositions, and demographic data through the same interface.

This means applications written against another openEHR CDR will work with Atomik without changes to the integration code.

FHIR R4/R5

Atomik supports FHIR R4/R5 integration through a custom FHIR facade built on top of your openEHR data model. This is designed and built for your specific clinical domains — not a generic automatic mapping.

We work with you to identify the use cases and domains you need to support via FHIR, design the corresponding FHIR 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.

Terminology Services (SNOMED CT)

Atomik integrates with SNOMED CT terminology services to support semantic querying. When querying clinical data, Atomik can expand SNOMED CT expressions — so you filter by a clinical concept and its subtypes without listing every individual code in the query.

This is relevant when your data model uses SNOMED CT codes and you need queries that respect the SNOMED CT hierarchy rather than matching exact code values.

Integration Patterns

The right approach depends on what your environment already looks like.

Direct API Integration

Your application calls Atomik's REST API directly to store and retrieve clinical data. This is the simplest pattern and works well for new projects where you control the full stack.

The openEHR REST API is well-documented and there are client libraries available in several languages. You send compositions over HTTPS and get back structured JSON responses.

No middleware required
Straightforward to test and debug
Recommended for greenfield projects

Integration Engine

For environments with existing integration infrastructure — HL7 v2 message feeds, legacy EMR connections, or messaging systems — Atomik connects through an integration engine such as Mirth Connect.

The engine handles message routing, transformation between formats (HL7 v2, FHIR, openEHR), and orchestration. Atomik's role is clinical data persistence — it receives already-transformed compositions through its REST API.

Handles legacy message formats upstream
Centralizes transformation logic
Works with Mirth Connect and similar engines

Practical Considerations

You need openEHR operational templates

Before storing data in Atomik, you need to define what data you are collecting using openEHR operational templates. Templates are built from archetypes published in the openEHR Clinical Knowledge Manager. If you are new to this, our training programs cover it from the ground up.

Authentication

Atomik's APIs use token-based authentication. Each organization has its own set of users and roles. For production deployments, it is common to put an API gateway or reverse proxy in front of Atomik to handle TLS termination and token validation.

Testing integrations

Atomik's openEHR Toolkit companion tool can generate synthetic compositions from your templates. This gives you realistic test data to validate your integration layer before connecting real clinical systems.

API documentation

Full API reference documentation is available at atomik.app/documentation. It includes request and response examples, authentication instructions, and error codes for all API endpoints.