“Can we just buy the raw claims data?”
It’s a common refrain we’ve heard from prospective Komodo customers for years. Many teams have invested heavily in their own infrastructure, analytic tools, personnel, and data pipelines. In Life Sciences, this infrastructure powers daily workflows across commercial, HEOR/RWE, R&D, and Medical Affairs. Our partners in financial services, healthcare providers, payers, and consultancies echo this same sentiment.
To build on these investments, many customers choose direct data delivery rather than using Komodo software. However, a growing number take a hybrid approach that preserves existing workflows via data delivery and uses Marmot™, our agentic AI platform, to help analysts do more, faster.
Regardless of whether a customer consumes data within our software or in their own environment, what we don’t talk about enough is this: what’s delivered is far more refined than ‘raw claims’ data!
I know what you’re thinking: “What do you mean, Paul? We get the raw data from Komodo, load it into our data lake, and run our analytics on it.”
What Komodo actually delivers is a highly curated set of medical and pharmacy events derived from raw claims. Turning one into the other takes a lot of work. Komodo does that work, so your analysts and data scientists skip weeks or months of data preparation. One Komodo customer described working with another data vendor as “a miserable process.” They received piecemeal data from myriad sources, with little done to resolve the overlap among them.

In recent years, other data companies have begun offering open (provider-derived) and closed (payer-derived) claims deliverables. They’ve reached the same conclusion we did: together, the two are worth more than either alone. Those datasets often arrive as separate deliverables or are poorly integrated. Komodo has unified open and closed claims for nearly our entire 12-year history. That expertise translates to a cleaner, higher-quality data product. Here’s what that looks like in practice.
How Do You Reconcile Conflicting Claims Data Sources?
Redundancy is built into Komodo’s Healthcare Map®. Approximately 40% of the medical and pharmacy events we observe come from multiple data sources! That redundancy helps the Map withstand source-level impacts and market changes more readily than if more records were sole-sourced. In addition, having more than one view on the same clinical event allows us to collect more information than would be available from a sole-sourced event alone.
It also means conflicts happen often. Each source has its own schema, naming conventions, and quirks. A “fill_date” column in one source can mean something different from a “fill_date” column in another.

First, we prove that two fields mean the same thing. Before merging records from different sources, we check that their columns line up. Take the date a prescription was filled. Across four different sources, we compared overlapping claims for the same patient and drug. Three fill-date columns agreed 98-99% of the time. A fourth source’s “serviced date” matched only 54-70% of the time. So we swapped in an alternate column from that source, which matched the others 98-99% of the time. We’ve built concordance checks and logic like this across more than 10,000 fields before the data ever reaches you.
Second, we decide which source to trust, and when. A few of the rules we’ve built:
- Insurance type. An open claim may list a patient’s payer as “Commercial.” But open claims don’t always tell the full story. The payer’s own enrollment file may show a Medicare Advantage plan for that same period. We trust the enrollment file and correct the event, so a Medicare patient isn’t incorrectly counted as Commercial.
- Birth year. De-identification can shift a birth year by one or two years. When a patient’s recorded birth years fall within two years of each other, we keep the most recent. If they’re further apart (under 1% of cases), we suppress the value to keep a likely error out of your analysis.
- Where a patient lives. Patients move, and sources update addresses at different times. We build day-by-day location windows from every event and enrollment record. When two locations overlap, the one with more observations wins. This filters out spurious records and gives the clearest picture of a patient’s geography by ZIP3 and state.
Each rule grew out of years of watching how specific sources behave when taken at face value.
How Is Claims Data Deduplicated?
When you combine open and closed claims, the same real-world event often arrives from several places. A pharmacy, a Pharmacy Benefit Manager (PBM), and a claims processor may each report the same prescription fill. How many prescriptions were actually filled? One. How many records arrived? Three.
Count all three, and you’ve tripled a patient’s visits, inflated a drug’s market share, and skewed every downstream analysis. Our deduplication process turns those overlapping records into one, complete event:
- Standardize everything first. Komodo maps every source to one common schema and cleans each field. Drug codes become 11-digit NDCs, diagnosis codes are standardized without decimals, and revenue codes become four digits. Records need a shared language before they can be compared.
- Group records that might be the same event. For each patient and claim type, we gather records that fall within the same date window.
- Fill in what’s missing so we can compare fairly. About 5% of medical records arrive without a claim type, and some are missing a provider or facility ID. We infer these from that same patient’s matching records using overlapping dates, procedure codes, and diagnoses.
- Pick the best record as the anchor. We favor records with original (not inferred) information and supplement with the most complete one: the most distinct revenue codes, then procedure codes, then diagnoses.
- Enrich the anchor record with the others. Details from redundant records join the anchor when they fit. For example, on medical events, an NDC is added to supplement the anchor record only when it matches the HCPCS “J” code billed on the claim.
This process repeats with every new data load. Each load is checked against what’s already in the Healthcare Map and all records are logged and time-stamped so each event can be traced back to its source.
So, Should You Buy the Raw Claims Data?
You could. You’d also inherit every problem above: mismatched columns, conflicting insurance details, and triple-counted visits. Data teams already spend an inordinate amount of time preparing and connecting data before any real analysis begins.
At Komodo, we’d rather your analysts spend that time on the questions that matter. That’s also true for AI. A model is only as good as the data it draws from, and general-purpose AI doesn’t understand the nuances of healthcare data on its own. Clean, standardized, consistent data is what makes an AI strategy work, whether that’s Marmot or a model you build yourself.
The hardest work in data should be invisible. When a Komodo delivery lands in your warehouse, it should be ready for analysis upon arrival. Getting it there isn’t simple, and that’s the point. We’ve spent more than a decade doing it, so your team can focus on the answers.
Evaluating a data partner? Ask how it resolves conflicting sources, deduplicates overlapping records, and how each event traces back to its source. Talk with our team to hear how we answer each one.
About the Author
Paul Zakas is Data Strategist at Komodo Health, where he has worked since 2018. Before Komodo, he held a commercial technology role at a large biopharma company. Today, he helps customers get the most value from Komodo’s Healthcare Map, explaining how claims data is built, refined, and put to work across the patient journey. Connect with Paul
Claims Data FAQs
Why Does Claims Data Need Deduplication?
The same real-world event often arrives from several sources. A pharmacy, a Pharmacy Benefit Manager (PBM), and a claims processor may each report one prescription fill, so three records describe one event. Counting all three inflates visit counts and market share and skews downstream analysis. Deduplication merges overlapping records into one complete event before the data reaches analysts.
How Do You Resolve Conflicts Between Claims Data Sources?
Resolving conflicts takes two steps. First, confirm that fields from different sources mean the same thing by comparing overlapping records. In Komodo Health’s comparison of fill-date columns across four sources, three agreed 98–99% of the time, and a fourth matched only 54–70%. Second, set rules for which source to trust. For example, a payer’s enrollment file outranks an open claim when the two list different insurance types for the same period.
Can You Buy Raw Claims Data?
Yes, though raw claims data needs significant preparation before analysis. Teams that buy it take on schema mapping, code standardization, conflict resolution between sources, and deduplication of overlapping records. Many teams choose curated data delivery instead, which loads medical and pharmacy events already standardized and deduplicated into their own data environment and preserves their existing workflows.
What Should You Ask a Claims Data Vendor?
Ask three questions: how the vendor resolves conflicting sources, how it deduplicates overlapping records, and how each event traces back to its source. Clear answers show how much preparation work the vendor has already done. Vague answers usually mean your analysts will do that work themselves after delivery.