This content originally appeared on DEV Community and was authored by CAmador
Look, I get it.
I really do.
I saw a messy multi location dental PMS and thought, I can slay this dragon.
I’ve merged PRs at 3am that saved production from total collapse.
How hard could a few dental systems be?
Turns out: very.
What I thought was a dragon was actually a hydra whose heads each ran a different PMS, with different schemas, timezones, identity models, and philosophical beliefs about how appointments should exist.
And I, the sweet summer child that I was, thought I could unify it all.
This article is the tale of how that confidence evaporated, how the integration imploded, and why I’m sharing my mistakes.
If you’re somewhere in that same fight right now, consider this your field guide, written by someone who learned every lesson the hard way.
How The First Dental Location Created a False Sense of Security
Every doomed journey begins with something deceptively functional.
For me, it was locations.
I genuinely thought every location would look like this. That was adorable.
{
"code": false,
"description": "Description",
"error": "Error",
"data": {
"id": 7,
"name": "Default",
"institution_id": 1,
"street_address": "123 Law St",
"street_address_2": "85335, North East",
"city": "New York",
"state": "NY",
"zip_code": "54700",
"country_code": "US",
"created_at": "2020-06-05T20:16:57.007Z",
"updated_at": "2020-06-05T20:16:57.007Z",
"latitude": 37.7775028,
"longitude": -122.3970603,
"phone_number": "8888750851",
"foreign_id": "1",
"foreign_id_type": "--DataSource-",
"email": "defaultLocation@nexhealth.com",
"tz": "America/Los_Angeles",
"last_sync_time": "2020-06-17T19:23:49.176Z",
"insert_appt_client": "true",
"map_by_operatory": "true",
"set_availability_by_operatory": false,
"inactive": "false"
},
"count": 2
}
Source: https://docs.nexhealth.com/reference/locations-1#/
Clean. Predictable. Rational.
Could I normalize this for every location? Absolutely……not.
- The IDs didn’t line up
- Timezones fought like my cats at 2am
- Entities didn’t share a universal structure
- Some fields appear only on Tuesdays. Because Tuesday.
This is where I learned that dental PMS systems each hold their own metaphysical stance on time.
Example A:
"start_time": "2025-01-14T09:00:00.000Z"
Example B:
"start_time": "2025-01-14T09:00:00-08:00"
Same company.
Same appointment template.
Completely different physics.
I wrote a function called: normalizeTimeButGently()
It worked 20% of the time.
Which is… not great.
Especially in healthcare.
Here’s the fun part of multi-location setups:
Each location might run a different PMS version.
Which means I quickly learned:
- Location A returned fields B and C
- Location B returned fields A and C
- Location C returned field A but formatted completely differently
- Location D returned nothing but errors unless I queried a hidden legacy endpoint someone swore “no one uses anymore”
My codebase slowly evolved into something that looked like this:
// if location is 2 use schema B
// if location uses PMS v14.2, patch the timezone
// if location matches this UUID, trust nothing
// if location is "Eastside", good luck
This is when I finally admitted the truth:
I didn’t build a unified API. I built a location arbitration layer.
The first location?
Easy.
The second?
Harder. But sure.
The third?
Because each new location brought its own:
- data quirks
- PMS configuration surprises
- naming conventions
- timezone philosophies
- metadata chaos
- and brand-new behaviors no one had documented since the Bush presidency
By the time I onboarded location #4, my “clean internal API” was being held together by conditional logic that read like a choose-your-own-adventure novel.
Except none of the endings were good.
Why My Plan Imploded (Gracefully, Eventually)
I started this process with confidence. I ended it with several thousand lines of normalization code and the kind of humility only multi-location dental data can teach you.
If you’re trying to stitch together multiple PMS systems across multiple locations:
- you’re not imagining the chaos
- you’re not doing it wrong
- and you’re definitely not underqualified
The systems themselves are inconsistent, unpredictable, and occasionally from another timeline. And honestly, none of this is your fault, the legacy systems you’re building on weren’t designed for the scale or complexity you’re dealing with today.
This article is everything I wish someone had told me before I ever tried to build a unified layer for multi-location dental data.
If this saves you even one late night? Or going from six months to 2 weeks? Worth it.
But choose your own adventure.
If you’re wondering how I eventually solved it, the actual approach I used (the one that finally stopped the location drift and version chaos), check out the comments.
This content originally appeared on DEV Community and was authored by CAmador
CAmador | Sciencx (2025-11-26T02:48:42+00:00) Multi-Location Dental Integration: Why My “I’ll Just Build It Myself” Plan Imploded. Retrieved from https://www.scien.cx/2025/11/26/multi-location-dental-integration-why-my-ill-just-build-it-myself-plan-imploded/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.