The Hardest Part of Care Gap Closure Isn’t Finding the Gap
Any tool can find a care gap. Knowing which ones have already been handled — before the provider ever sees the list — is the part that decides whether the tool works at all.

Most integration calls I’m on open with the same question: what data can you get out of the EHR?
It’s a fair question, and it’s the one I can answer fastest. The harder question, and the one that actually predicts whether a deployment works, usually doesn’t come up until month three: how does the tool know the gap is still open?
I’ve spent about twenty years moving healthcare data between systems that were never designed to talk to each other. In value-based care, the part everyone evaluates is the part I worry about least. Putting a diagnosis gap or an open care gap in front of a provider is close to a solved problem. Finishing one — the code in the progress note, the orders generated, the status back to the payer — used to be what separated products, and a few years ago that’s the argument I’d have made. Similar tools clear that bar now. What still separates them is the step before the list ever reaches the provider: deciding what not to put on it.
The list is only as good as what you took off it
Give a provider a list of ten items where the first three are already done, and you haven’t given them a list. You’ve given them a reason to distrust the next one.
This is the failure I see most often, and it’s rarely diagnosed correctly. It gets reported upward as a provider engagement problem — adoption is low, the clinicians aren’t using the tool, maybe we need more training. But a provider who stops opening a report that has burned them three times is behaving rationally. The tool spent their attention on work that didn’t exist. They adjusted.
And the damage isn’t proportional. A list that’s 70% accurate doesn’t get 70% of the engagement. It gets almost none, because the cost of checking is paid on every item and the benefit only shows up on some of them. Suppression isn’t a refinement on top of gap identification. It’s the thing that determines whether gap identification has any value at all.
Claims tell you what was billed, not what was done
So why is it hard? Because the sources that are easy to reach are the ones that don’t know.
Claims data is the most available and the most stale — three months behind is normal, and it only ever knew about the things that got billed. Payer and ACO portals are closer to current but reflect the payer’s view, which is a downstream view. HIE feeds are useful and partial; they cover the encounters that made it into the exchange and are quiet about the rest.
Run suppression on those three sources alone and you will confidently tell a provider that a mammogram is outstanding when the result came back nine days ago and is sitting in the chart they have open.
The only source that knows what was actually done is the clinic’s own documentation. That’s the one behind the hardest door.
Reading the chart is the expensive part
This is the same wall I described in a piece I wrote earlier this year about interoperability strategy, and it applies with more force here.
The evidence that a gap is closed is frequently not a discrete field. It’s a line in a progress note. It’s a scanned result from an outside lab. It’s a report faxed back by a specialist outside your ACO. A standard API extract pulls structured elements and returns exactly the fields someone decided to expose — which means a tool built on discrete data alone can only suppress the gaps that happened to be closed in a structured way.
That’s a meaningful fraction of them. It is nowhere near all of them, and the ones it misses are disproportionately the ones that make a provider give up on the tool, because they’re the gaps the provider personally remembers handling.
Doing this properly means reading the chart the way a person would — including the unstructured parts — and doing it before the encounter opens rather than reconciling afterward. Afterward is just the administrative queue again, with extra steps.
It has to work at the clinic you acquire next quarter
The multi-EHR problem used to be an edge case. Consolidation made it the default. PE-backed platforms and MSOs are growing by acquisition, and acquired clinics arrive running whatever they were already running. I’ve onboarded groups where one of the smaller practices ran an EHR nobody who worked on the acquisition had heard of. Those patients are still attributed to the ACO, and their gaps still count toward the contract.
This hits suppression hardest. Showing a gap takes data from outside the clinic — claims, a payer list, an attribution file. Suppressing one takes that same outside data reconciled against what the clinic documented in the EHR. Getting at that documentation is the hard part, in any EHR and especially a small one. A vendor serving a few hundred practices has no commercial reason to build that access for you, and no roadmap slot to put it in.
So the tool suppresses accurately at the sites running the group’s main EHR and falls back to claims-based guessing everywhere else. The providers who get the worst lists are usually at the practices acquired most recently — the people with the least reason yet to trust the parent organization’s technology.
Accuracy that varies by site doesn’t average out to acceptable. It teaches the clinics on the wrong side of that line to ignore the tool, and they don’t come back when you fix it.
Coverage you don’t have to ask permission for
This is why Smartlink’s integration engine works the way it does. It connects across 90+ EHRs through whichever surface is available — API where one exists, HL7 where that’s the practical route, and the EHR’s own interface when there’s no API or HL7 feed to work with. That last method is patented, and it’s the one that makes the coverage math work, because it gets at what the system actually holds rather than what a vendor chose to expose, and it doesn’t require EHR vendor involvement or a formal partnership to begin.
I want to be precise, because this gets overstated in our category. It doesn’t mean integration is effortless. All integration has friction, and anyone who tells you otherwise hasn’t done one. It means the friction is ours to manage rather than a dependency on someone else’s release schedule, and it means suppression quality doesn’t fall off a cliff at your smaller sites.
The back half still matters, and we do it — the confirmed diagnosis added to the progress note, the associated orders generated, the portal status transmitted back.
What this looked like in practice
Cary Medical Management is our sister MSO — same ownership, seven primary care clinics. What CMM gives us that an arm’s-length reference doesn’t is visibility into the deployment from the inside, including the parts that went badly.
Before DxInsight and GapCheck, portal reconciliation across those clinics consumed the equivalent of three full-time staff. After, it was less than one — roughly $150,000 a year that stopped being spent on retyping. I’ll defend that figure because it measures one thing: how much manual reconciliation the previous setup required.
Shared savings over the same period went from $700,000 in 2023 to $1.9 million in 2024. I’m not suggesting that our products did that. CMM was rebuilding transitional care management and referral workflows in the same window, and either of those could move a number that size on its own. What I’d claim is narrower: the reconciliation work was a real constraint on how much of that other work the clinics had capacity to take on, and removing it lifted the ceiling.
The demo to ask for
Every demo shows gap identification, because gap identification demos well. A list appears. It looks complete.
Ask for the harder one. Bring a panel where you know several gaps were closed recently — closed in ways that never became a discrete field, ideally at a clinic running your least common EHR. Then ask to see the list the provider would get.
Every vendor can show you what their tool found. Ask what it decided not to show you, and how it knew.
Your providers will answer that question for themselves within a few visits. They won’t tell you the answer. They’ll just stop opening the list.
Naveen Vangipurapu, VP Software Development
Table of Contents

