You signed the lease. Or the letter of intent. Or you closed the acquisition. Maybe you just added a surgeon. Or an imaging center. Or a new service line.
Either way, your practice just got bigger.
Everyone celebrates. Leadership talks about capacity and market share. Marketing sends a press release.
And then, about sixty days before go-live, someone asks the question nobody thought to ask earlier: what are we doing about the technology for this new endeavor?
That question – usually asked late, answered fast, and executed under deadline pressure – is where most physician groups create a technical debt they might spend years paying off.
The Bolt-On Problem
The most common approach to practice growth is also the most expensive one: bolt it on. Take whatever infrastructure exists, connect it to what you already have, patch the gaps as they appear, and get clinical operations running as fast as possible.
It works, in the narrowest possible sense. Staff can log in. The EMR is accessible. Patients are seen.
What it creates underneath that is usually an increase in the patchwork quilt. Different hardware and network configurations. Undocumented workarounds because someone put something in place three years ago and nobody fully understands anymore. Different security postures.
And here is what most finance teams do not see: adding a new location, a new service line, an ASC, an imaging center, or even a new provider is not just a cabling and workstation exercise. Every one of those changes touches the technology environment. A new surgeon means new device integrations, new credentialing workflows, new EMR builds. A new service line may require entirely different imaging or diagnostic systems that need to talk to your existing infrastructure. An acquisition brings a full legacy environment – vendor contracts, potentially aging hardware, and a security posture that usually hasn’t been formally assessed – directly onto your network.
The people making growth decisions often think of technology as the last item on the checklist. The people responsible for that technology know it usually needs to be the earliest one.
What an Acquired Practice Brings With It
When you acquire a group, you are not just acquiring their providers and their patient panel. You are acquiring their vendor relationships, their legacy contracts, their hardware at whatever age it happens to be, and their security posture for better – or for significantly worse.
A practice that has been operating independently for fifteen years without a formal IT strategy has almost certainly accumulated real risk. Unpatched systems. Credentials that have never been rotated. Shared logins. HIPAA obligations that were technically acknowledged and operationally ignored.
When you bring that practice into your organization, you inherit every one of those risks. The breach that was their problem before the acquisition is now your problem afterwards. The acquiring group that completes careful clinical and financial due diligence but treats technology as a checklist item learns this the hard way – usually a few months months after close, when a security incident traces back to infrastructure that was already compromised before the ink dried.
The Timeline Problem
Here is how the timeline usually goes: leadership picks an opening date. That date gets communicated to staff, to patients, to the market.
Nobody asked the technology team whether that date is achievable.
Technology deployments take real time: procuring hardware, configuring infrastructure, establishing network connectivity, provisioning access, testing integrations with the EMR and practice management system, and training staff. That work cannot be compressed past a certain point without cutting corners, and the corners that get cut at go-live become the problems that surface six months later at the worst possible time.
The practices that handle growth well start the technology conversation the moment something new is seriously in play – not after the LOI, not after closing, and certainly not after the opening date is already on a press release. At the point where leadership says “we are pursuing this,” the technology team needs to be in the room.
What Getting It Right Looks Like
A well-executed technology deployment is not complicated. It is disciplined.
It starts with an honest assessment: what is there, what condition it is in, what needs to be replaced, and what risks need to be addressed before anything connects to your network. That assessment drives a realistic timeline – not a number pulled from the last project, but one specific to this new endeavor.
It builds toward a defined standard. Wherever possible every location, every service line, every new piece of the organization should run compatible hardware configurations, network architectures, security stack, and backup configurations. Variations should be documented exceptions, not undocumented drift. It doesn’t mean they need to be identical, however they need to be similar
Every addition made under deadline pressure without a standard creates technical debt. That debt compounds. The bolt-on that worked well enough for the second location is harder to maintain by the fifth. The security gap deferred at acquisition grows every year. Growth is worth protecting. The infrastructure that supports it should be treated accordingly.HealthSpaces is a co-sourced technology partner built exclusively for independent specialty physician groups. We work with growing practices to build technology standards that scale with them — not against them. Connect with our team to learn how we approach multi-site technology strategy
