Epic MyChart Integration: Fixing the Data Normalization Problem

During a recent Iguana demo, one of the developers shared a story from a past project. It explained why he had been looking for a better way to manage integrations.

He had tried to connect Epic MyChart to a smaller clinic system his organization uses. It is a local setup that works fine on its own, but it was never designed for the kind of integrations he needed to build. The plan looked simple: pull patient data from MyChart, pass it into the clinic system, and match it by a few key fields.

Once he started working with the real messages, he realized the project was not going to go the way he expected.

When data exists, but never matches the way you need

He described the experience in a way that most developers would understand right away. In his words, "The amount of data appraising I had to do… it was crazy."

On paper, both systems supported the same formats. In practice, the details were completely different.

• Names were structured differently

• Health card numbers followed different patterns

• Phone numbers varied

• Fields existed but did not line up cleanly

None of this caused errors. The data was simply inconsistent. And because of that inconsistency, he had to rebuild most of the mapping by hand. The work took far more time than it should have, and every change felt fragile.

This is a common issue in healthcare integration. Systems say they speak the same language, but as he explained later, "Everybody defines their data differently… it always looks different."

Why his team depends on one stable patient identifier

His organization works across several clinics. Each clinic uses slightly different structures. To match a patient, they rely on four fields: first name, last name, phone number, and the provincial health card number.

The health card number is the only stable identifier. Names and phone numbers change. The health card number does not. But for it to work cleanly, every system needs to represent and store it in a predictable way, which was not the case in his earlier MyChart project.

What changed when he saw how Iguana handles the messy parts

During the demo, he watched how Iguana's built-in APIs parsed HL7 and JSON into clear structures. The annotation view showed each field in context. Autocomplete made coding the mappings less tedious.

It was the first time he saw the cleanup process handled in a way that was visible and repeatable. Instead of writing one off fixes, he could map the data once and reuse it across every clinic.

Iguana did not remove the complexity of healthcare data. It simply gave him a place to manage it without feeling overwhelmed by it.

Why this matters for any team working across multiple systems

Many teams fall into the same pattern. They connect two systems directly. It works, but only at first. Once real data starts flowing, the mismatches start to show up.

This is not a coding failure. It is a data structure problem.

Iguana gives teams a central place to clean and normalize data before it reaches their product. It keeps the logic organized. It makes mappings easier to understand. And it gives developers a predictable way to handle new sites and new systems without rewriting everything from scratch.

Once the data structure becomes consistent, the rest of the work becomes much easier.

The lesson behind that MyChart integration

The experience taught his team something many others eventually learn. Direct connections look simple, but they often hide the real effort. The hard part is not getting data from one system to another. It is getting that data into a shape the receiving system can actually use.

A dedicated integration layer solves that problem by keeping the messy pieces in one place and handling them in a transparent way. It keeps your main system focused on what it is meant to do.

His story highlights a simple truth about healthcare data: it almost always looks different than you expect. Once you account for that reality, and build around it, integration becomes far more manageable.