SENA Insights
Posted on October 28, 2026
By Anthony J. Wehbe, DO, MBA, FACOI | Founder & CEO, SENA Health | Practicing Internist, Senacare | Former Health-System Physician Executive
How workflow design — not staffing or software — determines access, experience, and cost
Physician enterprises have spent years trying to improve front-end performance by adding staff, centralizing functions, outsourcing work, buying new technology, or layering new tools onto old processes.
All of those responses can be reasonable. The problem is that they are often chosen before anyone answers a more basic question: what work are we actually asking the front end to do, and why did we design it this way?
I still see patients. Two weeks ago I was doing a house call for an 88-year-old widow with heart failure in Mullica Hill, New Jersey. After we finished with her legs and her weight, we spent the next ten minutes on speakerphone with her daughter, trying to figure out which of four different numbers would actually get her mother’s diuretic refilled before the weekend. Nothing about that problem was clinical. It was a workflow problem — and I have watched the identical problem from the other side of the table, in health-system leadership meetings, where the answer was almost always “we need to add headcount.”
I see this from both sides because I have lived on both sides. I still practice internal medicine for a mostly elderly, mostly home-bound population through Senacare — house calls, skilled nursing facilities, group homes, virtual visits — and I founded SENA Health to help clinical enterprises fix exactly the kind of access breakdown my patients and their families run into every week. Before that, I spent most of a decade as a hospitalist and then a physician executive at Kennedy Health System and Jefferson Health New Jersey, eventually running population health, medical group operations, and a several hundred-million-dollar annual operating budget across eight entities. The operational frustrations we debate in the boardroom are the same ones my patients describe from their kitchen tables.
As physicians, we are trained to understand the cause before choosing the treatment. In operations, we do not always show the same discipline. A backed-up call queue becomes a staffing problem. Rising administrative expense becomes an AI problem. Poor access becomes a scheduling-technology problem.
Sometimes those are the right answers. More often, they are incomplete ones.
Here is a concrete version of that mistake, and I made it myself. When I ran hospitalist services across three campuses at Kennedy, our workload would back up on nights and weekends, and our first instinct was to ask for more nocturnists. We got the budget, added coverage, and the workload barely moved. The real constraint wasn’t clinician hours. It was that nursing, case management, and the attending of record were each working from a different discharge checklist that didn’t talk to the other two, which meant every discharge generated three or four callbacks before it actually closed. Once we rebuilt that single hand-off workflow — the same redesign that helped take our average length of stay from 5.6 days to 3.3 days and strengthened the system’s bottom line by $7.5 million in one year — the staffing “shortage” mostly disappeared. We had not been short on hospitalists. We had been asking hospitalists to absorb a broken hand-off.
Much of physician office operations was never truly designed. It accumulated. A scheduling rule was added because of a problem years ago. A referral process grew around one office while a payer requirement created another hand-off. The EHR opened one inbox while a centralized team solved one bottleneck and created another.
Over time, those local fixes became the operating model.
The better starting point is to define the work differently. The unit of work is not the call, the text, or the portal message. It is the unmet patient need.
The organization sees scheduling, referrals, triage, portal messaging, prior authorization, call-center operations, and clinical escalation. The patient sees a problem. Their prescription ran out. Their knee pain is getting worse. Their child has a fever. Their physician said someone would call, and nobody did. Too often, they were discharged yesterday and do not know what happens next.
Those are not departmental issues to the patient. They are unresolved needs.
Yet we often organize the front end around our own structure and expect patients — or their exhausted adult children — to figure out how to navigate it. In effect, we ask people to understand our org chart in order to get care.
For physician enterprises, access increasingly has to mean more than answering the phone or scheduling an appointment. It has to mean understanding the need, finding the right next step, and moving the patient there with as little unnecessary delay, effort, and confusion as possible.
That is where workflow design becomes strategic.
Front-end performance is usually a combination of four things: demand, clinical capacity, workflow design, and execution capability. Not every access problem is a workflow problem — sometimes the real constraint is that there simply are not enough clinicians or appointments.
But most physician enterprises cannot create large amounts of new clinical supply quickly. They can improve how demand is understood, routed, prioritized, and matched to the capacity they already have.
That is a much bigger opportunity than answering calls faster. It’s also why I think technology has to be applied carefully. AI can increasingly answer a call, gather information, identify intent, summarize a request, and complete parts of a transaction. Those are real capabilities. But automating a task is not the same as redesigning an operation.
Here is the sharper version of that point, and it’s the one I think most boards get wrong: layering AI onto a broken workflow does not fix the workflow. It hides it, and it hides it at machine speed. If your call center misroutes referrals today, an AI agent will misroute them tonight, at 2 a.m., flawlessly and for free — and no one will notice until the leakage shows up in next quarter’s volumes. Automating a broken process isn’t modernization. It’s the fastest way I know to scale a mistake before anyone catches it.
A faster transaction is useful. It is not enough if the underlying workflow still creates unnecessary hand-offs, delays, callbacks, or rework.
That is why SENA Health starts with the workflow.
We begin by understanding what the patient is trying to accomplish, what work that creates, where it goes, where it stalls, which hand-offs add value, and which exist only because of legacy design.
Once you understand that, the choices become clearer.
Much of the work should be automated because it is predictable and repetitive. Some belongs with trained administrative staff. Some clearly requires clinical judgment. Some steps should disappear entirely.
The answer is not people versus technology. It is designing the workflow first, then applying the right combination of both.
The same logic applies to AI. If a patient says she needs to see a cardiologist, understanding that request is only the beginning. Can the system determine urgency, identify the right clinician, locate actual open capacity, account for insurance and geography, offer an alternative when the preferred office is full, recognize when symptoms require escalation, schedule the appointment, move the necessary information, and close the loop?
If not, we may have improved the interaction without meaningfully improving access.
The real opportunity is orchestration: taking patient intent and reliably moving it through the system to resolution.
That also changes how we should think about labor. The goal is not simply to remove people. It is to stop using scarce, expensive clinical people to compensate for bad process.
Physician enterprises still have nurses chasing forms, medical assistants returning avoidable calls, schedulers manually searching fragmented capacity, front-desk staff explaining organizational complexity, and physicians inheriting whatever remains unresolved at the end of the day.
People should be deployed where they add unique value: clinical judgment, empathy, exception handling, problem solving. The rest of the workflow should be designed around them.
For years, access was treated mainly as a service function. I think that view is now dangerously narrow, and I run both of my companies against a different framework — five levers that ultimately show up on the P&L:
At Jefferson, when we rebuilt front-end workflow around real referral tracking and a coordinated contact center instead of ad hoc call routing, network retention moved from roughly 30 percent to 80 percent over four years, the same infrastructure generated millions of dollars a year in value-based payments, and colon cancer screening rates for eligible patients rose from 30 percent to over 70 percent. None of that came from a new phone system. It came from redesigning the work.
That makes the front end part of the operating system of the physician enterprise, not a department hanging off the side of it.
Before adding more staff, buying another AI tool, or launching another access initiative, leadership should be able to answer:
The point is not that every physician enterprise needs the same operating model. It’s almost certainly the opposite — the right model depends on the market, the patients, the clinical capacity, the economics, and the work itself. What should be common is the sequence: understand the need, redesign the workflow, then decide where technology belongs, where people belong, and where neither should be necessary.
That is how access becomes more than a front-end function. It becomes strategy.
Want to talk through your organization’s front end? Schedule a conversation with Dr. Wehbe.
