When the Work Moves, Can Your Technology Move With It?
Part Three of MissionViewpoint's series: The Unbundling of Work
Part Two ended with a practical problem.
If some work belongs inside the provider, some belongs in its core systems, and some can increasingly be purchased as an external capability, the operating environment has to accommodate all three.
More importantly, those boundaries have to be able to move.
A provider might perform a workflow internally today, buy much of its execution tomorrow, and eventually decide to bring some of it back. The right answer can change as technology improves, economics shift, and capabilities that once differentiated the organization become broadly available.
That creates a different requirement for the technology stack.
The question isn't simply whether all of those capabilities can connect.
It's whether the provider can change where the work happens without having to change everything around it.
When a Good Operating Decision Becomes a Constraint
Go back to eligibility verification.
A provider might reasonably have an intake coordinator perform eligibility checks using information and functionality inside its practice management platform. The data is already there. Employees know the workflow. The process works.
Introducing another system simply because a specialized alternative exists would add complexity without necessarily adding enough value to justify it.
Then the economics change.
An external capability becomes substantially better at the mechanical work surrounding eligibility. It can receive the patient information, perform the verification, handle routine discrepancies and follow-up, escalate the unusual cases, and return the completed result.
The provider now has a choice it didn't have before: keep performing the work internally or move much of the execution elsewhere.
But only if its operating environment allows it.
If the necessary data can't get out of the core platform, if an external capability can't know when work needs to happen, or if the completed result can't return to the systems employees use, the provider doesn't really have that choice.
Its architecture has made the decision for it.
The System of Record Doesn't Have to Be the System of Work
A practice management platform may remain the authoritative home for client information, authorizations, appointments, clinical documentation, claims, and other critical transactions.
There is enormous value in that.
But the place where authoritative information lives doesn't necessarily have to be the place where every activity involving that information occurs.
The system of record and the system of work can be different.
Eligibility information might remain authoritative in the practice management platform while the work required to verify it happens somewhere else. The completed result can return to the provider without creating another authoritative version of the patient record.
That distinction matters because an extensible operating environment isn't one in which every application maintains its own version of reality.
It's one in which the role of each component is clear.
The core platform can remain the system of record. Another capability can perform a bounded piece of work. The provider can still see what happened, manage the exceptions, and remain accountable for the result.
An API can help make that possible. But having an API isn't the same thing as having an extensible operating model.
Two systems can technically exchange data and still leave employees reconciling statuses, entering information twice, chasing exceptions, or trying to determine which system is actually correct.
Technical integration is not operational integration.
Extensibility Isn't About Having More Vendors
There will almost always be a specialized application capable of doing some narrow piece of work better than a broad platform.
That doesn't mean a provider should use it.
Every additional capability creates another relationship to manage, another integration to maintain, another security consideration, another workflow boundary, and another place something can fail.
Complexity has an economic and operational cost.
If the core platform performs a workflow well enough, keeping the work there may be the better answer even when a specialized alternative is somewhat better.
A specialized capability has to earn the complexity it introduces.
That could happen because it materially reduces cost. It could improve speed, reliability, capacity, or an outcome the provider considers strategically important. But "there is a better point solution" isn't enough.
Extensibility therefore shouldn't mean using more vendors.
It means retaining the ability to use a different capability when the benefit becomes large enough to justify the additional boundary.
The Capability You Choose Can Change Too
Suppose our provider moves eligibility verification to the external capability.
The implementation works. Data moves from the practice management platform to the capability, the work gets performed, and the result returns. The provider has successfully separated the system holding the information from the capability performing the work.
It would be easy to think the architecture problem is solved.
But the external capability isn't a permanent feature of the landscape.
Its product can change. Its economics can change. Its access to the provider's core systems can change.
And its ownership can change.
That last possibility matters particularly for capabilities whose value depends on extracting data from the core platform. A bounded capability may sit outside the practice management system while depending heavily on access to the information inside it. Over time, that capability could be built into a larger platform or absorbed into one.
The provider doesn't need to predict whether that will happen, or to whom.
It needs to understand what happens if it does.
A capability selected partly because it gave the provider an alternative to the core platform can eventually become part of a platform itself. The economics, access model, product priorities, or strategic interests surrounding it may then be different from the ones the provider originally evaluated.
The boundary the provider deliberately moved can be redrawn by a decision the provider didn't make.
That's why the objective isn't simply to connect an external capability successfully.
It's to avoid replacing one rigid boundary with another.
Optionality at the Capability Level
This is a different way to think about technology optionality.
Historically, providers have often treated the practice management decision as a very large architectural choice. Select the platform and you also select, explicitly or implicitly, much of the environment in which scheduling, authorizations, billing, documentation, and other work will occur.
There are good reasons for that. Broad platforms reduce complexity.
But the unbundling of work creates pressure to make some operating boundaries smaller.
A provider may want to change how one capability is performed without changing the systems surrounding it. Eligibility could move outside when an external capability becomes substantially better.
But movement doesn't only go outward.
Suppose the provider adopts that specialized eligibility capability and, two years later, its practice management platform introduces functionality that is now just as good. Or another vendor already embedded in the provider's operation expands its capability enough to perform the same work.
Now the economics may reverse.
The specialized capability that once justified another vendor, integration, and workflow boundary may no longer earn that complexity. The provider may want to consolidate the work back into its core platform or into a broader capability it already uses.
That's another form of substitutability.
An extensible stack isn't one designed to keep adding specialized capabilities. It's one that lets the provider unbundle when specialization creates enough value — and rebundle when it no longer does.
The operating stack doesn't need to make those changes effortless.
It needs to make them possible.
That means the provider has to be able to reach the information required to perform the work, know when something needs to happen, return the result to the appropriate system, preserve a clear source of truth, and maintain visibility across the workflow.
Those sound like technology requirements.
They're really requirements for operating choice.
The Real Test Isn't Whether You Have an API
This is why I wouldn't evaluate extensibility primarily by counting integrations or asking a platform vendor whether it has an API.
Those things matter. But they're mechanisms.
The more useful executive question is:
If we decided someone or something else should perform this work, how difficult would that decision be to execute?
Could another capability get the information it needs?
Could it perform the work without creating a parallel source of truth?
Could the result return to the operating environment in a usable form?
Could employees and leadership still see what happened?
And if that capability later stopped being the right answer, could the provider substitute another one?
That last question is the one traditional integration thinking can miss.
A provider can build an excellent connection to an external capability and still create a new form of lock-in if the workflow becomes inseparable from that vendor's interfaces, data model, or operating assumptions.
The first substitution worked.
The second one may not.
The architecture therefore needs enough separation between the authoritative data, the workflow being performed, and the capability performing it that one can change without unnecessarily destabilizing the others.
Not everywhere. Not frictionlessly. And not for free.
Where substitution matters, it should remain possible.
Architecture Defines the Choices You Get to Make
The first article in this series argued that providers can increasingly buy work rather than merely buying software that helps their employees perform it.
The second argued that execution can move without necessarily moving the differentiation with it.
But neither choice matters much if the operating environment prevents the work from moving.
A provider may decide strategically that a capability should sit outside the organization and discover technically that it can't. It may find a substantially better way to perform a workflow and discover that adopting it requires replacing the system of record around which the rest of the organization operates. Or a capability it already depends on may change around it, leaving the provider with no practical substitute.
At that point, architecture is defining the range of operating models available to the organization.
That doesn't make the core practice management platform less important.
It may make its role clearer.
Providers still need durable systems of record, reliable transactions, coherent data, and broad functionality that handles work effectively without unnecessary complexity. If the core platform performs a workflow well, there may be no reason for that work to happen anywhere else.
But the system that holds the data doesn't have to determine who performs every piece of work around it.
As the boundary between internal employees, software, AI, and external operating capabilities continues to move, providers won't know in advance where every piece of work should eventually sit.
Their operating architecture shouldn't decide for them.
