Usage examples

Seeing how pieces fit together is often more useful than reading about them separately. These examples show real patterns for building on Atomik — what data flows look like, what APIs you call, and how openEHR structures map to clinical scenarios.

Patient dashboard

A patient dashboard displays demographic information alongside clinical summaries — vital signs, active conditions, recent medications. It's typically the first screen a clinician sees when opening a patient record, and the starting point for recording a visit or reviewing history.

In Atomik, this is built by querying the patient's EHR for specific composition types (vital signs, conditions, medications) and combining that with the patient's demographic Actor record. The result set can be scoped to the most recent entry per type, or time-bounded for trend views.

The same pattern extends to any clinical summary: immunization history, last lab results, chronic diseases, current pregnancy status, allergies, surgical history. Each is a separate composition query against the same EHR.

Integration of radiology flows

A patient moving through a radiology workflow generates data at multiple checkpoints: scheduling and admission (administrative), images (DICOM via WADO/WADO-RS), and the radiology report (clinical). Each comes from a different system in a different format.

Atomik's role in this flow is to receive and store the clinical data — primarily the structured radiology report as a COMPOSITION, with DV_MULTIMEDIA references pointing to the DICOM images in the imaging repository. This keeps the structured clinical record queryable in Atomik while leaving bulk image storage where it belongs. The result: a fully paperless, queryable radiology workflow where the report and the image reference are always together and versioned.

Cohort design

A cohort is a set of patients who meet a defined set of clinical criteria — age range, sex, active diagnoses, current medications, recent lab results, overdue screenings. Selecting that cohort manually is impractical at scale. Automating it with hardcoded SQL is a maintenance liability every time the criteria change.

With Atomik's combined queries, each criterion becomes a stored composition query. The combined query ANDs them together across all EHRs — returning only the patients who meet every condition simultaneously. The result set feeds into downstream systems: a CDS alert dashboard, a care plan enrollment workflow, a clinical trial pre-screening list.

Because the individual queries are stored and named, updating criteria means editing a query in the Web Console — not modifying application code or redeploying anything.