I didn’t notice it when the integration first shipped.
There was no outage. No postmortem. No dramatic failure.
What changed was the conversation.
Our product lead asked why onboarding a new dental customer was taking weeks instead of days.
Our data lead asked which system we should trust when numbers didn’t line up. Eaglesoft and Denticon felt like....
Someone else asked during our stand up whether a roadmap item needed to move because of an API change upstream.
The integration was technically “working.” But everyone had started working around it. Questions, no major changes though.
That’s the moment you realize you’re no longer just integrating a PMS.
You’re running infrastructure, and crossing more “that’s not my job” moments than anyone planned for.
This is the phase teams don't name.
Let’s rewind to how this started.
We know that multi-location dental data doesn’t break loudly. It drifts.
For leadership, this usually first appears as reporting caveats and timeline slippage...and hidden costs.
Scheduling behaves differently across locations, then patient identity fractures.
Providers span offices in ways the data model never anticipated.
Workflows that were clean in a single practice become ambiguous at scale.
None of this looks like a bug. It looks like slow adaptation.
Our conversations, our stand ups, our monthly check-ins started to center around either “it’s not my job to fix it” or “how can we duct tape this together before the next call?”.
We had normalization working just ok, product teams complacent with uncertainty, data teams adding verbal disclaimers to dashboards and our leadership team nervous but steady handed on our painfully slow project.
Nothing was broken enough to justify doing anything but rolling up our sleeves and fixing each issue. That’s when our organizational drag started to show up more often than I would have liked.
Somewhere along the way, I realized I wasn’t just integrating PMS systems anymore.
I was maintaining versioned behavior across PMSs.
Explaining in standups why downstream systems went down even though “nothing changed.”
Adding guardrails so retries didn’t corrupt state.
Writing code to compensate for behavior that was technically valid, but operationally unsafe.
None of this existed because the team over-engineered solutions. It existed because the EHR endpoints were intentionally incomplete.
Most dental EHR vendors:
- expose read-heavy endpoints
- restrict or omit write, update, or workflow-critical actions
- limit bulk operations, scheduling mutations, financial edits, or state changes
So you can see data, but you can’t act on it the same way the native UI or internal systems can.
That’s intentional.
What isn’t intentional, but happens anyway, is what this creates downstream.
When teams can’t rely on APIs to behave as stable contracts, engineering absorbs the gap. When engineering absorbs the gap, product timelines become conditional.
When timelines become conditional, teams start planning around uncertainty instead of capability.
This is where integration work quietly turns into organizational drag.
Not because anything is broken.
But because every team is compensating for constraints they don’t control, and no single system owns the risk.
From the business side, this looks like “extra time.” But from the engineering side, it’s necessary work. Both sides have requests that might seem unreasonable....I think both are right.
When integration risk becomes roadmap risk seems like something teams avoid. No one wants to say it out loud. Because delivery timelines stop being driven solely by engineering capacity and contingent on external systems.
Our adventure started when we realized that EHR vendors deprecate endpoints intentionally, or withholds functionality to support their own products. We were forced to ask:
Do we delay the roadmap?
Do we rebuild internally?
Do we scramble for an alternative?
This is where integration work stops being a technical concern and becomes a business one.
Our roadmap didn't slip because the team is slow.
It slipped because the system boundary was never stable.
Eventually, we stopped asking, how do we fix this integration?
And turned to:
Why are we asking product teams to own integration guarantees—retries, normalization, observability, PMS variance handling, that don’t differentiate the product but can absolutely derail it?
That’s not a tooling question.
That’s a system decision.
And it’s where buy-vs-build actually belongs.
We didn’t reach this conclusion because our engineers couldn’t build it.
We reached it because maintaining integrations across legacy and modern PMS systems was consuming bandwidth we needed for the product itself.
We needed:
- standardized data behavior across PMSs
- observable sync state and actionable logs
- safe retries and failure handling
- insulation from upstream API change
- the ability to scale without every team becoming PMS experts
So we adopted Synchronizer API by NexHealth.
Not as a shortcut. As infrastructure. Because whether we admit it or not, that’s what we were attempting to do anyway.
Synchronizer API by NexHealth didn’t replace engineering judgment. It removed undifferentiated integration work from the critical path so our teams could focus on what actually made the product better.
What Changed
- Devs stopped rebuilding the same guarantees.
- Integration bugs became diagnosable instead of mysterious.
- Onboarding timelines stabilized.
- Support load dropped.
- Product teams stopped planning around unknowns.
- Most importantly, the organization stopped compensating.
That’s the signal most teams miss.
If you’re a developer, engineering lead, product owner, or technical stakeholder reading this and thinking: “We’re already doing most of this ourselves.”
You are.
And that’s exactly the point. How's that going?
The question isn’t whether integration guarantees matter. It’s whether they should live everywhere, or somewhere intentional.
Once you see integration work turning into organizational drag, you can’t unsee it.
And once you name it, you can finally decide what to do about it.
The easiest way to understand how teams externalize this work is to look at the Synchronizer API by NexHealth Postman collection.
Developers can fork the collection into their own Postman workspace, which simply means making a private copy they can safely experiment with.
There’s no production impact, no setup to undo, and nothing shared back unless you choose to.
It’s a low-risk way for both technical and non-technical stakeholders to see what the integration contract actually looks like in practice.
You don’t have to commit to anything to explore it, forking the collection is just a way to understand behavior, guarantees, and edge cases before decisions get made.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.