Replacing an Old EMR Without Losing the Past

Sector: Hospitals, clinic networks

The scenario

Imagine a hospital whose EMR is fifteen years old. The vendor has stopped adding features, and maybe stopped answering calls. The database holds a decade and a half of clinical history that clinicians still need, and nobody is sure how to get it out.

The question that has stalled every replacement attempt is: what happens to the old data? Clinicians have a simpler fear: that the discharge summary from 2014 that explains a patient's allergy will be unreachable the day after go-live.

What Atomik is, and what it isn't, in this scenario

Atomik is not the new EMR and not a clinical-facing application. It has no screens for doctors and nurses. It is the data management layer behind the applications: a backend that stores the clinical and demographic data in a standardized, consistent way and gives every application the same way to read and write it, through the same API.

The screens clinicians use (the EMR front-end, a lab system, a patient portal, a reporting tool) are separate applications that connect to Atomik. That is what makes the replacement easier: you can change or add those applications without touching the data underneath.

What goes wrong without the right tool

  • Convert everything into the new vendor's format: you are locked in again, and the next replacement has the same problem.
  • Keep the old system running read-only forever: you keep paying for, patching and worrying about a system nobody trusts.
  • Archive to PDF: the history is preserved but can't be queried.
  • The data belongs to the application, so changing the application means moving the data with it.

How Atomik can be used

  1. Separate the two decisions. Which application clinicians use, and where the record lives, don't have to be the same decision. Atomik holds the record in an open standard, independent of any application. It doesn't replace the EMR's user interface; you still choose, buy or build that.
  2. Model by domain. Define openEHR templates for the domains to migrate: encounters, allergies, medications, results, and so on.
  3. Map and migrate in phases. Map the legacy data to the templates and commit it through the REST API, starting with the data clinicians need most and verifying against the source before moving on. This is a migration project (CaboLabs can help), not a button.
  4. Keep the history intact. Data committed to Atomik is versioned and audited. Patient identity is managed in the demographic repository, and where legacy duplicates exist the Master Patient Index capabilities help resolve them.
  5. Connect the applications to the same record. The new clinical application, and every other system after it (lab, portal, reporting), reads and writes the same data through the same API.
  6. Switch off the old system once its data is in Atomik and verified, and query the history with the same tools as new data.

The hard part: making sense of the legacy data

Loading data into Atomik is the easy step. The hard part is knowing what the old data means, and that is where migrations usually go wrong:

  • Same field name, different meaning. A value that looks equivalent in the old system and in the new model can use another unit, another code system or another convention, so the data looks right and means something else.
  • Quality problems discovered after go-live. Duplicated patients, incomplete records and values that failed to transform tend to be noticed when clinicians start using the new system.
  • Mappings nobody can explain. If the transformation rules aren't documented, nobody can trace why a value looks the way it does, and every later change risks breaking them silently.
  • Little or no documentation of the old database. Fifteen-year-old systems often have none.

Atomik is the destination and the ongoing data management layer. Analyzing the legacy data, designing the mapping and running the migration is a project, and it is where an experienced team makes the difference.

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 the services around it, so you don't have to work out the legacy side alone:

  • Source model analysis. Understanding the legacy data model, including systems with no formal documentation: what each field represents, which values are valid, how records relate, and where the quality problems are.
  • Conceptual mapping design. Mapping concepts before mapping data, documenting every decision, so there is an explanation for why the data looks the way it does after the migration. See Data Mapping & Migration.
  • Transformation rules and implementation. Formal, documented rules, and a working, tested data mapper that your team can operate and extend, if you want it implemented.
  • Data migration. Source analysis, transformation design, staging and load, and post-migration verification, to standards-based targets such as openEHR, with audit trails and rollback plans for when things don't go as expected.
  • Database audit and data quality review. Finding duplicates, inconsistent values and structural problems in the legacy database before they reach the new one. See Database Audit & Optimization.
  • Integration of the surrounding systems. Connecting the lab, imaging, pharmacy and other systems to the shared record (HL7 v2, FHIR, DICOM). See services for hospitals and clinics.
  • Architecture assessment. A review of the current architecture and a phased roadmap, so the replacement doesn't disrupt ongoing operations.

You can do this work with your own team or with another provider; nothing in Atomik requires CaboLabs services. If you'd like to talk about your case, get in touch with CaboLabs.

What this gives you

A record that isn't owned by any application, and one consistent way for all of them to access it. The next time the front-end changes, the data doesn't have to move with it.

Why Atomik fits

The core problem in an EMR replacement isn't the new application, it's that the data belongs to the old one. Atomik stores the record in an open standard the hospital owns, which makes the next replacement a smaller decision.

← All use cases