Multi-Site Clinical Research Cohort

Sector: Academic medical centers, research consortia

The scenario

Imagine a consortium of three medical centers planning a five-year study of patients with type 2 diabetes and at least one cardiovascular comorbidity. Data must be updated every quarter as patients move through treatment. Each site keeps its records in a different EMR, and the protocol may change during the study, for example adding a chronic kidney disease cohort.

What goes wrong without the right tool

• Each site exports in a different format, and the same-looking field means different things: "encounter date" can be the appointment, the discharge or the billing date.
• Diagnoses are coded with ICD-10 at some sites and SNOMED CT at others, so the same population query returns different results per site.
• Months pass harmonizing data before the first analysis runs, and a protocol change means repeating part of that work.
• Cohort criteria live in scripts that are hard to re-run, explain or audit.
• Reproducibility depends on knowing which version of which record was used.

How Atomik can be used

1. Agree on the model first. Clinical informaticists define openEHR templates for the study's domains (diabetes management, cardiovascular history, lab results, medications), reusing existing archetypes where possible.
2. Map each site once. Each site maps its EMR export to the shared templates and commits to a shared Atomik instance.
3. Express the cohort as a query. In the Query Builder, use a SNOMED CT expression for type 2 diabetes in one composition query and one for cardiovascular disease in another, and combine them (Combined Queries, a premium feature) so both must hold for the same EHR. New subtypes added to the terminology are matched by the expression without editing the query.
4. Absorb protocol changes. Adding a CKD cohort means adding a query, not repeating the harmonization.
5. Update every quarter. New results are committed as new versions linked to the patient's EHR, and the full timeline is queryable through one API.
6. Keep provenance. Every version records who committed it and when, and stored queries are named artifacts, so results can be re-run and explained.
7. Prepare data for sharing. Identity lives in the demographic layer and clinical content in the clinical records, which gives a clean boundary for de-identification or pseudonymization.

How CaboLabs can help

Atomik was built by CaboLabs, a company specialized in healthcare systems integration, data migration and consolidation, and clinical data management and audit. Besides the software, CaboLabs offers services that fit this scenario:

• openEHR modeling. Designing the study templates from existing archetypes, documented and versioned. See openEHR Implementation.
• Data mapping per site. Mapping each site's EMR export to the shared templates. See Data Mapping & Migration.
• Data quality assessment. Checking completeness, consistency and uniqueness of each site's data before it enters the study. See Clinical Data Quality Assessment.

None of this is required to use Atomik; you can do it with your own team or another provider. If you'd like to talk about your case, get in touch with CaboLabs.

What this gives you

A shared definition of the data, cohorts that are stored questions instead of scripts, and a traceable record of what was used for each result.

Why Atomik fits

The real cost in multi-site research is agreeing on what the data means. Atomik makes each data point's definition explicit and shared, and turns a study criterion into a saved, reusable query.

Going deeper

The Atomik Approach to Research Data

High-quality clinical data is the foundation of research and education — but gathering, harmonizing, and querying it across heterogeneous systems is where most projects stall. The first blocker is always the same: proprietary information models that make every source incompatible with every other.

Atomik normalizes clinical data to openEHR on ingestion — vendor-neutral, semantically correct, and queryable without custom transformation per source. Store any clinical structure without touching source code or database schemas. Integrate data from as many sources as needed. Query it all through one consistent API.

Research Scenarios

Multi-site Clinical Studies

Aggregating data across hospitals is where most research infrastructure breaks down. Each site runs a different EHR — different vendor, different version, different local customizations. A "diagnosis" field at Site A is coded in ICD-10. At Site B it's free text. At Site C it doesn't exist at all because that data lives in a separate departmental system.

With Atomik, each site maps its local data to a shared openEHR template defined upfront by the research team. Once mapped, data from all sites lands in a single repository with a uniform structure. Cohort queries run once and return consistent results regardless of origin — no post-hoc reconciliation, no per-site analysis scripts.

Retrospective Cohort Studies

Retrospective research depends on historical records — often years of accumulated data locked inside legacy systems. The challenge isn't just extraction; it's that historical records weren't collected with your research question in mind. Fields are missing, inconsistently coded, or structured for clinical workflow rather than analysis.

Atomik's schema-free storage means historical data can be loaded incrementally as it's cleaned and mapped, without committing to a fixed database schema upfront. As the canonical model evolves with the research, new templates can be added without breaking existing records or rewriting existing queries.

Longitudinal Studies

Tracking patients across months or years requires that records remain consistent, traceable, and temporally queryable — even as data continues arriving from multiple sources over time. A patient's HbA1c values from 2019 and their wearable glucose readings from 2024 need to be comparable, co-queryable, and unambiguously linked to the same person.

Atomik's built-in data versioning and demographic repository handle both sides: clinical records accumulate with immutable version history, and patient identity is managed separately from clinical content — enabling longitudinal queries without coupling research data to proprietary identity systems.

Population Health & Epidemiology

Epidemiological research requires aggregating large volumes of data across heterogeneous populations, then slicing by demographic, geographic, or clinical criteria that weren't anticipated when the data was first collected. Proprietary stores make ad-hoc cross-cutting queries expensive or impossible — you get the slices the vendor designed for, not the ones your research needs.

Atomik's query engine operates on the semantic model, not on table structure. Any combination of clinical and demographic criteria can be queried without schema changes or database administrator involvement. New research questions don't require new infrastructure.

Common Challenges & Tips

Define the canonical model before touching source data

The single biggest mistake in research data projects: starting the ETL before agreeing on the target model. Teams end up mapping to an evolving target, redoing work every time the model changes.

Tip: Use the openEHR Clinical Knowledge Manager (CKM) to find existing archetypes for your data concepts before building custom ones. Most common clinical concepts — vital signs, diagnoses, medications, lab results — already have peer-reviewed archetypes. Build your research template from those, define the OPT, load it into Atomik, and only then start mapping sources to it.

Start with a minimum dataset

Scope creep kills research data projects. The impulse is to model everything — every field, every edge case — before committing any data. By the time modeling is done, the project has lost momentum.

Tip: Identify the 5–10 data elements that are strictly necessary to answer your primary research question. Model those first. Get them into Atomik. Run your first queries. Then expand incrementally. Atomik's schema-free design means adding new data types later never breaks what's already there.

Reproducibility requires provenance, not just data

A finding is only reproducible if someone can reconstruct exactly which records were included, which version of those records was used, and what query was run. Most research data pipelines have no answer for any of these questions once the study is published.

Tip: Atomik's audit trail and data versioning give you the provenance layer for free. Store your query definitions as named queries in Atomik. When a record is updated after your analysis, the version you queried is still accessible. The full chain — who committed what, when, from which source — is always available.

De-identification for research compliance

Research data almost always needs to be de-identified before it can be shared with external collaborators, submitted alongside publications, or used for model training. De-identification on proprietary formats is fragile — you need to know every field that could contain PHI across every source schema.

Tip: Because Atomik separates clinical content (stored in the CDR) from patient identity (stored in the Demographic Repository), de-identification has a clean boundary. Strip or pseudonymize the demographic layer; the clinical records remain structurally intact and fully queryable. No PHI scattered across arbitrary JSON blobs or proprietary columns.

Education Use Cases

Medical and health informatics programs face a persistent problem: students need to work with realistic clinical data structures, but production patient data is off-limits. The result is either toy datasets that teach the wrong mental models, or complicated data governance agreements that take a semester to negotiate.

Atomik supports education environments through synthetic data generation — realistic clinical records built against real openEHR templates, structurally identical to production data but containing no real patient information. Students interact with the same API, the same query engine, and the same data model they'd encounter in production — without any HIPAA or GDPR exposure.

Curriculum ideas that work well with Atomik:

• Health informatics fundamentals: model a clinical concept as an openEHR archetype, build a template, commit a record, retrieve it.
• Interoperability exercises: take data from two fictional "source systems" with different formats and harmonize them into a single Atomik repository.
• Research methods: assemble a synthetic cohort, write queries, export results, analyze — full research pipeline on safe data.
• Data governance: explore audit trails, version history, and access control as practical exercises rather than theory.

CaboLabs can assist with integration, data mapping, synthetic data generation, and building analysis or educational applications on top of Atomik.

← All use cases