Data Mapping & Migration
Every integration project, technology migration, and standards adoption effort eventually comes down to the same question: how do we get data from the model we have into the model we need? That question sounds simple. In practice, it is where most projects lose time, introduce errors, and accumulate technical debt. We specialize in getting it right.
Where data mapping goes wrong
The most common failure mode is treating data mapping as a technical task rather than a design task — jumping straight to writing transformation code without first understanding what the data actually means in each system.
Structural match, semantic mismatch
Two systems may store what looks like the same field with the same name, but represent different concepts, use different units, or follow different coding conventions. Field-to-field mappings that ignore semantics produce data that looks correct but means something different in the destination.
Data quality problems found after migration
Incomplete records, duplicated entries, and values that failed to transform correctly are often discovered weeks after a migration goes live — when clinicians or administrators start using the new system and notice the data does not look right.
No documentation of the mapping
Mappings built without formal documentation become black boxes. When the data does not look right in the destination, nobody can trace the transformation rules to find out why. Every future change to either system risks breaking the mapping silently.
How we help
We approach data mapping as a design discipline: concepts first, data second. We analyze what each field means in context, identify semantic gaps, and produce mappings that are documented, testable, and maintainable — whether your team implements them or we do.
Source Model Analysis
Before any mapping can be designed, the source model must be understood. We analyze existing data sources — including systems with no formal documentation — and produce a clear description of the data model: what each entity and field represents, what values are valid, how records relate to each other, and where the data quality issues are. This is the foundation everything else is built on.
Conceptual Mapping Design
We map concepts before we map data. This means identifying which concept in the source corresponds to which concept in the destination, resolving terminology differences, handling missing or split concepts, and documenting every decision. Conceptual mappings are the specification that technical mappings must implement — and the audit trail that explains why the data looks the way it does after transformation.
Transformation Rules and Implementation
From the conceptual mapping we derive precise transformation rules: how each field is converted, what happens to missing values, how coded concepts are translated, and how structural differences between models are resolved. We deliver the rules as formal documentation. We can also implement them — delivering a working, tested data mapper that your team can operate and extend.
Data Migration
When a technology switch or consolidation requires moving historical data to a new system, we design and execute the full migration: source analysis, conceptual mapping, transformation design, staging and load, and post-migration verification. We handle migrations to standards-based targets such as openEHR and FHIR, where the destination model has specific structural and semantic requirements.
Post-Migration Audit
After data is loaded into the destination system, we verify it. We check completeness (no records lost), uniqueness (no duplicates introduced), consistency (related records remain coherent), and semantic correctness (values mean what they should in the target model). We deliver an audit report that gives the organization confidence the migration succeeded — and documents anything that could not be fully resolved.
Standards-Based Mapping
Mapping to openEHR, FHIR, or HL7 requires more than knowing the target specification. It requires understanding the clinical semantics behind the standard's data structures and making defensible decisions when the source does not fit neatly. We have done this across multiple projects and standards, and we document every mapping decision so it can be reviewed and reproduced.
Do you have any questions?
Let us know how we can help you.