Regional Health Information Exchange

Sector: Regional health authority, hospital network

The scenario

Imagine a health authority responsible for several hospitals, each running a different EMR: some from established vendors, one custom-built and close to end of life. Each has its own data format and its own patient identifiers.

A patient treated for diabetes in one hospital arrives at another with a cardiac event. The admitting physician can't see the earlier history. Two specialists treat the same patient without seeing each other's decisions. Leadership sees duplicate tests, missed medication interactions and gaps at discharge, and wants a shared longitudinal record.

What goes wrong without the right tool

  • Point-to-point integration between N systems needs N×(N-1) interfaces, and each one breaks when either side changes.
  • When an old system is retired, its history is stranded or lost, so retiring it feels too risky.
  • The same person has a different identifier in each system, so "all data for this patient" is a manual search.
  • Regional questions ("patients with several chronic conditions across all hospitals") can't be answered by any single system.

How Atomik can be used

  1. Start with what matters most. Pick a small shared domain: encounters, vital signs, active medications, allergies. Model it as openEHR templates.
  2. Map each system once. Each EMR gets one mapping into the shared templates (N mappings instead of N×(N-1) interfaces), implemented with an integration engine or the tools of your choice. CaboLabs can help with this.
  3. Commit to a shared repository. Atomik acts as the shared clinical and demographic repository next to the EMRs.
  4. Unify identity. Each patient has a demographic record in Atomik with their identifiers from each system linked to it. Where the same person was registered more than once, the Master Patient Index capabilities help find and resolve those records.
  5. Show the shared view where clinicians already work. A thin viewer, or a query, brings the longitudinal record into the existing EMR workflow.
  6. Retire systems safely. A retiring system's history, already in Atomik, stays queryable after it is switched off.
  7. Ask regional questions. Stored and combined queries (premium) work across all committed records.
  8. Plan for availability. Clusters & Sync (premium) adds a secondary instance for read load and failover.

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:

  • Data centralization and integration design. Deciding which system is the authoritative source for each data element, and designing the integrations with the EMRs. See HIS Integration.
  • Data mapping and migration. Mapping each EMR to the shared templates, and migrating the history of the system being retired. See Data Mapping & Migration.
  • openEHR modeling. Designing the shared templates for encounters, vital signs, medications and allergies. See openEHR Implementation.
  • Data quality assessment. Finding duplicates and inconsistencies in the source systems before they are consolidated. 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

One longitudinal record across hospitals, a path to retire legacy systems without losing history, and every change traceable through the audit information that comes with each version.

Why Atomik fits

A shared record only works if the data means the same thing everywhere and doesn't depend on any one vendor staying in the game. Atomik stores data in an open standard, so each source needs one mapping and the record outlives any single system.

Going deeper

A Unified Clinical Data Backbone

Modern healthcare organizations rarely suffer from a lack of data — they suffer from fragmentation. Clinical information is distributed across EHRs, departmental systems, labs, imaging platforms, and patient-generated sources, making it impossible to build a complete, trustworthy view of the patient.

Atomik Server acts as the single source of truth for shared health records — an openEHR‑compliant clinical and demographic repository that aggregates data from any source and makes it queryable by any authorized consumer: clinicians, analytics tools, decision support engines, patient portals.

The usual process for aggregating patient data that resides on different isolated data silos, following the openEHR model, includes the following steps:

  1. Analyze which data should be shared between your systems, start small, focus on the basics: general encounters, vital signs, allergies and other diagnosis, family history, immunizations, etc.
  2. Model that information using openEHR representations as archetypes and templates. Check the openEHR basics guide to understand how openEHR models clinical information. This will serve as a canonical model that will standardize the information coming from different systems.
  3. Transform your data sources into canonical model instances, from designing the data mappings to actually generating valid openEHR data instances. We have tools to help with that process. Also, an integration engine like Mirth Connect, or Open Integration Engine (OIE), can help you on the transformation task. Of course, from CaboLabs we can help with this process.
  4. Commit data instances to the Atomik to be persisted as part of each patient's EHR. Repeat until your current data is committed. At this stage this will be a batch process to load historical data from your current data sources, later it can be a real time process that records whatever data is newly generated. Now the data is ready for querying!
  5. Query and access the data from any external system, even from systems that are not part of the data sources! Create some basic queries over your data, like get all the vital signs from an EHR. That can be done easily using the Query Builder from the Web Console. The result of each query will be consistent, openEHR compliant, and ready for processing. You can do things like evaluate rules for clinical decision support that generate alerts and recommendations, data analysis and reporting, or just feed the data into a nice visualization for a user. If you don't want to query, you can get full clinical documents by their id in JSON format.
  6. Integrate this solution into your environment to synchronize data regularly, so you get current data when your systems and apps execute the queries. The first 'loading' phase is the heavy loading, when you are done with that, it's time to receive data in real time instead of from a batch process.

Why Clients Choose This Approach

Interoperability by Design

Using openEHR ensures long‑term semantic interoperability across vendors, regions, and evolving standards.

Vendor Independence

Data is no longer locked inside proprietary schemas — applications can be replaced without migrating clinical history.

Faster Innovation

New clinical use cases can be delivered by defining templates instead of redesigning databases.

Clinical and Demographic Data Together

Atomik Server manages patient identity and clinical content in a single, coherent model.

Compliance and Traceability

Full audit trails and version history support regulatory and medico‑legal requirements.

Integration Architecture

graph TB subgraph Sources direction TB EHR[EHR Systems] LIS[Labs and Imaging] DEV[Devices and Wearables] EXT[External Systems] end subgraph Integration ETL[ETL or Middleware] MAP[openEHR Models] end subgraph Atomik CDR[Clinical Data Repository openEHR] DDR[Demographic Repository] AUD[Versioning and Audit Trail] end subgraph Consumers direction TB CLIN[Clinical Applications] BI[Analytics and Population Health] CDS[Clinical Decision Support] PORT[Patient Portals] APP[Patient Apps] end Sources --> Integration ETL --> MAP Integration --> CDR Integration --> DDR Atomik --> Consumers

Open a world of possibilities

With a Shared Health Records solution you don't just load data into another database, you standardized and integrated data from heterogeneous, and maybe inconsistent / incompatible clinical systems, into a single standardized, vendor-neutral, Clinical Data Repository.

Sharing clinical data between systems is the foundation. Once it's in place, every new use case — an alert dashboard, a patient portal, a population health report, a CDS rule — is an API query away, not another integration project. Each new application draws from the same standardized store without rebuilding the data layer.

The platform also scales incrementally: start with the highest-value data (encounters, vitals, allergies), validate the integration, then extend the canonical model to include more clinical domains as your team is ready. Every expansion adds capabilities across all consuming applications simultaneously.

mindmap root((Shared Health Records)) Clinical Care Longitudinal Patient View Care Coordination Decision Support Analytics Population Health Quality Metrics Research Digital Health Patient Portals Mobile Applications Remote Monitoring Platform Benefits Vendor Independence openEHR Interoperability Audit and Compliance
Capability Map

In Summary

Atomik Server enables healthcare organizations to build shared health records that are interoperable, scalable, and reusable over time. By acting as a central openEHR‑compliant data backbone, it unlocks new clinical, analytical, and digital health capabilities — without locking you into a single vendor or application.

One patient. One record. Many possibilities.

← All use cases