Why Pathways Need Orchestration Before They Can Scale
By Dr. Charles Accurso and Praveen Suthrum
Chapter 4 moved from procedures to pathways.
That shift matters because procedures are events, while digestive diseases are journeys. Colon cancer screening and surveillance, fatty liver, IBS, GERD, Barrett’s, IBD, celiac disease, motility disorders, chronic constipation, and other digestive conditions do not fit neatly into one visit or one procedure. They require intake, triage, testing, diagnosis, patient communication, scheduling, treatment, follow-up, partner coordination, recall, surveillance, and at times, re-entry into the system years later.
That is easy to say.
It is much harder to run.
A pathway on paper is not a care model. A practice can define a fatty liver pathway, an IBS pathway, a CRC pathway, or an IBD pathway, but the moment it tries to make that pathway work, it discovers a more basic problem. The infrastructure underneath the practice is fragmented.
The data is in one place. Scheduling is in another. The EHR does not always connect with the hospital. The surgery center may use a different system. The referring physician may use another EHR. The patient may bring labs from a portal, an image from a hospital, a paper referral, or nothing at all. The recall list may exist, but no one may know how well it works. The phone system may be disconnected from scheduling. The RCM system may be disconnected from clinical operations. The partner who can help with nutrition, behavioral health, microbiome testing, obesity, remote monitoring, or virtual care may not fit cleanly into the practice workflow.
The pathway may be clinically sound. But the system beneath it cannot carry the work.
That is why the next step after pathways is not simply more partners, more technology, or more AI tools. The next step is the foundational layer that allows a practice to coordinate care across fragmented systems.
That layer is orchestration.
The EHR Is Necessary, but Insufficient
The EHR does several things well.
It stores clinical information. It organizes the chart. It allows the clinician to see medications, diagnoses, notes, orders, results, and past history once those items are inside the system. It supports documentation, billing, compliance, and continuity. It became the official record of the patient’s care.
That matters. The EHR is not irrelevant.
But the EHR was not designed to orchestrate modern GI care across patients, referring physicians, hospitals, surgery centers, payers, AI agents, digital partners, remote monitoring, diagnostics companies, nutrition services, behavioral health, RCM vendors, and longitudinal disease pathways.
It is mainly a system of record.
GI 2.0 requires a system of action.
A system of record stores what happened. A system of action helps the work move. It notices that a patient is due. It triggers outreach. It checks eligibility. It identifies missing labs. It routes the referral. It schedules the appointment. It sends prep instructions. It follows up when the patient does not respond. It updates the chart. It alerts a human when the case is unusual. It communicates back to the referring
physician. It shows leadership what is working and what is not.
Most EHRs were not built for that kind of orchestration.
This is not a small inconvenience. It is now a strategic constraint.
For years, physicians and staff have adapted themselves to the EHR. They learned where to click, how to enter orders, how to find scanned documents, how to use templates, how to route messages, how to complete documentation, and how to survive inside systems that were often built more for recordkeeping than for care flow.
That adaptation had a cost.
Physicians became typists. Staff became manual connectors between systems that should have connected themselves. Patients waited. Referrals stalled. Prior authorizations consumed days. Recalls depended on letters, calls, lists, and staff capacity. Data moved by fax, portal, PDF, phone call, and human persistence.
The original promise of digitization was that information would move more easily. In practice, many systems became digital silos.
This is why a practice can have an EHR and still lack modern infrastructure.
The Real Problem Is Flow
The issue is not only where the data sits. The issue is whether the data, the patient, the task, and the responsibility move at the right time.
Consider a patient with elevated liver enzymes.
The patient sees a primary care physician. The PCP orders labs and perhaps an ultrasound. The patient is referred to GI. Depending on the systems involved, the GI practice may or may not receive the labs. It may or may not receive the ultrasound. The referral may arrive by fax. It may sit in a queue. The patient may not be scheduled quickly. When the patient finally arrives, the gastroenterologist may still be missing key information. More labs may need to be ordered. Imaging may need to be
repeated or retrieved. The visit becomes less productive because the pathway failed
before the patient entered the exam room.
The gastroenterologist knows what to do clinically. The problem is that the necessary information was not assembled in time.
Now consider IBS.
A practice may decide that it does not want to build the entire IBS support model internally. It may want to partner with a nutritionist, behavioral health provider, gut-brain program, virtual GI company, or digital therapeutic. That may be the right strategy. But then the question becomes: how does information move between GI, the partner, the patient, and the referring physician? What does the partner send back? Who reviews it? Does insurance cover the partner? Does the PCP understand
why this lowers cost rather than adding another layer? How does the patient know who is responsible for what?
The more partner-enabled the pathway becomes, the more important orchestration becomes.
Now consider IBD.
IBD patients may be among the sickest patients in the practice. Crohn’s disease can progress subclinically. A patient can worsen between visits. If the practice is relying only on episodic visits and old data, it is documenting history more than monitoring the current state. A modern IBD pathway needs timely signals: symptoms, labs, medication adherence, biologic status, infusion data, flare access, prior authorization
status, and follow-up.
Documentation records what happened.
Monitoring helps the practice know what is happening.
That is the difference between an EHR-centered model and an orchestrated care model.
GI pathways fail when information and responsibility are scattered across systems that do not talk to one another. The solution is not simply to add one more tool. The solution is to create a layer that helps the work move.
Replacement Is Hard. Overlay Is Practical.
In an ideal world, the practice would have one open, flexible, intelligent operating platform that connects all the pieces of care. It would integrate clinical data, scheduling, billing, patient communication, payer workflows, partner communication, dashboards, and AI agents. It would be easy to switch, easy to connect, and easy to build on top of.
That is not the world most practices live in.
Most GI practices will not replace their EHR immediately. The cost, disruption, retraining, physician resistance, staff anxiety, data migration risk, and operational complexity are too high. Many physicians already feel burdened by the systems they use. The thought of relearning every click, every order, every template, and every workflow is enough to stop change before it begins.
This is why the near-term answer is likely not full EHR replacement.
It is an intelligent layer on top.
On the clinical side, ambient AI is beginning to create that layer. Ambient AI refers to technology that listens during the patient encounter, captures the conversation, and helps create documentation or suggested next steps. The physician should not have to spend the encounter serving the EHR. The physician should be able to look at the patient, listen, ask questions, examine, explain, decide, and speak the plan. The system should capture the encounter, draft the note, suggest orders, prepare follow-up, and reduce the need for manual clicking.
But ambient documentation alone is not enough.
The next step is ambient action.
If a patient is diagnosed with IBS, the physician should be able to say that the patient needs specific labs, an abdominal ultrasound, a follow-up visit in three months, and patient education. The system should not merely write those words into a note. It should help move the work forward.
On the administrative side, AI agents and automation agents can become a similar layer above existing systems. An AI agent is software that can perform a defined task, such as calling a patient, checking a payer portal, preparing an appeal, or updating a work queue, based on rules set by the practice.
A recall agent can identify patients due for colonoscopy and contact them. A referral agent can process incoming referrals and help schedule patients. A prep agent can call patients before a procedure. A prior authorization agent can gather data, check payer rules, and prepare submissions. A claim-status agent can check payer portals. A denials agent can help route appeals. A patient re-engagement agent can find people who fell out of care.
The EHR remains important.
But the daily interface begins to change.
Ambient AI reduces the physician’s need to click. AI agents reduce the staff’s need to chase. Together, they begin to turn the EHR from a daily burden into an underlying record.
That is the practical path for many practices.
The practice does not need to wait passively for its EHR vendor to solve everything. If a useful AI tool exists today, and if it can be implemented safely around a well-defined workflow, the practice can begin to benefit now. If the EHR later catches up and offers a better solution, the practice can reassess. AI tools are not EHR migrations. They can be tested, replaced, improved, or retired more easily than the core EHR.
The practical question is not, “Which vendor should we trust forever?”
The better question is:
What problem do we need to solve now, and what is the safest, most measurable way to begin?
What Orchestration Means
Orchestration is not the same as automation.
Automation completes a task.
Orchestration moves the work through the pathway.
A single automation may check insurance eligibility. Another may call a patient. Another may generate a letter. Another may check claim status. Another may send a reminder. Each may be useful. But if each one stands alone, the practice may simply replace one kind of fragmentation with another.
Orchestration connects the pieces.
It defines what happens first, what happens next, what data is needed, which system is used, when a human must review, when a patient must be contacted, when the PCP must be updated, when a task is complete, when an exception is created, and how success is measured.
In a back-office workflow, orchestration may connect eligibility, benefits verification, prior authorization, coding, charge entry, claim submission, payment posting, EOB review, denials, appeals, AR follow-up, and claim status checks.
In a referral workflow, orchestration may connect the PCP, the GI practice, the patient, scheduling, clinical records, insurance, the surgery center, and follow-up communication.
In a recall workflow, orchestration may connect the recall list, outreach, patient response, scheduling, prep, procedure completion, pathology, surveillance interval, and future recall.
In a disease pathway, orchestration may connect diagnosis, monitoring, labs, imaging, medications, partner services, patient-reported data, PCP communication, and escalation.
The practice does not need to solve all of this at once. But it needs to understand the difference between a tool and a layer.
A tool solves a task.
A layer connects the work.
GI 2.0 will not be built by stacking disconnected tools on top of disconnected systems. It will be built by creating an orchestration layer that allows patients, data, tasks, partners, communication, and accountability to move through the practice.
Minimum Viable Orchestration
A GI practice does not need to replace its EHR or build a perfect digital platform before it begins.
It needs to choose one workflow.
That workflow should be specific, repeatable, measurable, financially meaningful, operationally painful, and low enough risk to supervise safely. The practice should define the rules, connect the necessary data, automate the repeatable steps, route exceptions to humans, measure the results, and improve the process over time.
This is minimum viable orchestration.
The first workflow will not be the same for every practice.
For many GI practices, the best place to begin will be referral intake, scheduling, and recall. These workflows bring patients into the practice and keep them connected. They also connect directly to growth, access, patient care, and procedure volume.
For another practice, the right starting point may be prior authorization, prep calls, missed calls, eligibility verification, denials, claim status, AR follow-up, or RCM workflow. A small practice may start with recall because it already has the patient list and does not need to persuade outside physicians to participate. A large group may start with RCM because the savings are immediate and measurable. A PE-backed group may focus on cost reduction and standardization. A hospital-owned group may be constrained by enterprise systems. An independent group may have more flexibility but fewer internal technical resources.
There is no universal first workflow.
There is a universal principle:
Start where pain, repeatability, safety, and ROI intersect.
Do not start by automating judgment.
Start by automating movement.
Do not start with a use case that puts the patient, physician, or cash flow at risk. Do not begin with autonomous clinical decisions. Do not begin by disrupting the revenue cycle in ways the practice cannot control. Do not begin with a complex disease model that requires every partner and every system to be integrated before anything works.
Begin with one workflow that already exists, already matters, and can be improved.
The First Layer: Referral Intake, Scheduling, and Recall
For many practices, the most natural first layer is referral intake, scheduling, and recall.
These are not glamorous workflows. But they are the front door of the practice.
A GI practice can have excellent physicians, a strong ASC, good outcomes, and a respected reputation. But if referrals sit in a queue, if patients cannot get scheduled, if recall lists are not actively managed, or if the referring physician does not hear back, the practice loses value before the clinical encounter begins.
A referral should not be a piece of paper.
It should be the beginning of an orchestrated pathway.
Imagine a patient sitting in the primary care physician’s office with elevated liver enzymes. The PCP determines that the patient should see GI. Today, that referral may become a fax, a portal message, a printed instruction, or a task that depends on the patient calling later. The patient may delay. The referral may be incomplete. The GI practice may receive it without the right labs or imaging. The first visit may happen weeks later, with missing information.
Now imagine a different model.
The PCP initiates the GI referral while the patient is still in the room. The necessary clinical information moves to the GI practice. The patient is scheduled or contacted immediately. If labs or imaging are needed before the GI visit, the protocol identifies them. The patient receives instructions. The GI practice receives the relevant context. The PCP remains in the communication loop.
That is not simply faster referral intake.
That is orchestration.
The same principle applies to recall. Many practices have a recall system. But the more important question is: how well does it actually work?
How many patients are on the list? How many are contacted? How many respond? How many schedule? How many complete the procedure? How many are sent letters but never reached? How many have surveillance intervals that need updating? How many patients fall off the pathway entirely?
The problem is that the practice does not know how well the recall system performs.
A recall system is both a business engine and a clinical safety net. It brings patients back into the practice, protects procedure volume, supports surveillance, and helps prevent patients from being forgotten. It also allows the practice to say, with documentation and confidence, that it made a real effort to bring the patient back.
When recall, scheduling, and referral intake are orchestrated well, the practice begins to protect its core while building the foundation for future pathways.
Start With Trusted Referrers
Referral orchestration should not begin with every referring physician.
It should begin with trust.
The first PCP or referring group should ideally have a long-standing relationship with the GI practice, clinical trust in the GI group, a personal relationship between leaders, geographic proximity, meaningful volume, and managers who are willing to coordinate. The physician leaders on both sides should understand the purpose. The operational leaders should know each other or be willing to build that relationship. Staff on both sides should understand the workflow.
This is not only a technical project.
It is a human behavior project.
A PCP group will not change its referral process simply because a GI practice sends a new link or asks for a new workflow. People change behavior when they understand the value, trust the people leading the change, and believe the new process will make life easier rather than harder.
Technology may connect the systems.
Trust gets people to use the connection.
The first pilot should probably not start with the largest referral source if that relationship is weak. It should start with the most trusted referral source that has enough volume to make the pilot meaningful.
That is how the practice learns.
The 90-Day Minimum Viable Orchestration Pilot
A 90-day pilot should be a framework, not a rigid prescription.
Each practice must choose the workflow that fits its own pain, capacity, and opportunity. But the structure should be disciplined.
First, choose one workflow.
Do not choose five. Do not try to rebuild the practice. Choose recall, referral intake, scheduling, prep calls, prior authorization, eligibility, denials, or another high-value workflow.
Second, establish the baseline.
Before the practice changes anything, it should know what is happening now. How many patients are identified? How many are contacted? How many respond? How many schedule? How many complete the visit or procedure? How long does referral to-appointment take? How much staff time is involved? What is the current drop-off rate? What is the current revenue impact? What data is missing? Who owns the workflow today?
Many practices will discover that the workflow exists, but performance is not being actively monitored.
Third, assign a physician champion and an operational owner.
The physician champion does not need to manage every task. But the physician champion must understand the clinical and strategic purpose of the pilot and be able to explain it to the group. The operational owner ensures the daily work happens. For larger groups, this may involve an administrator, operations leader, CIO, AI leader, RCM leader, or project manager. For smaller groups, it may involve the practice administrator and one motivated physician.
Fourth, involve the staff who do the work today.
Schedulers know where scheduling breaks. Billers know where claims get stuck. Referral coordinators know which PCP offices send incomplete information. Nurses know which prep instructions confuse patients. Front-desk staff know where patients get lost. These people should not be treated as obstacles to automation. They are workflow experts. If staff believe they are being asked to train their own replacement, they will resist. If they understand that AI and automation can reduce repetitive burden and allow them to move into higher-value work, they are more likely to help build the system
correctly.
The people doing the work today know where the workflow breaks. If they are excluded, the AI may automate the wrong version of the process.
Fifth, define the rules and exceptions.
What should the automation do? What should it not do? When should a human be alerted? What language should the AI use? What data can be updated? What requires clinical review? What happens if the patient is confused, angry, silent, or asks a question outside the script? What happens if data is missing? What happens if there is a mismatch between systems?
Trust in AI should be earned through supervision, not assumed through enthusiasm.
Sixth, select the tool or partner.
This should come after the workflow is defined, not before. A practice should not buy a tool and then search for a use case. It should define the workflow, rules, data, metrics, and accountability first. Then it can select the right automation, AI agent, dashboard, integration partner, or service.
Seventh, supervise closely.
In the early phase, humans should review calls, edge cases, failed interactions, write backs, and escalations. The goal is not to slow everything down permanently. The goal is to learn quickly, catch errors early, and improve the system before it scales.
Eighth, measure weekly.
A dashboard should show the practice whether the workflow is actually improving. For recall and referral intake, it may show patients identified, contacted, scheduled, completed, pending, escalated, dropped, and converted. For RCM, it may show charges, payments, unposted claims, denials, AR, claim status, appeals, and payer bottlenecks.
The staff may use the dashboard daily. Leadership may review it weekly. The practice may do a deeper review monthly and quarterly.
A dashboard turns orchestration from invisible automation into visible management.
Ninth, decide after 90 days.
The practice should ask: Did more patients get scheduled? Did more patients complete visits or procedures? Did staff burden decrease? Did the PCP relationship improve? Did the workflow become easier? Did the economics improve? Did the practice reduce leakage? Did patients experience less friction? Did errors remain within acceptable limits? Did the pilot create confidence?
If the answer is yes, scale carefully.
If the answer is no, redesign or stop.
An orchestration layer that adds work is not orchestration. It is another burden.
Business ROI and Clinical ROI
Every pilot should be measured in two ways.
There is business ROI, and there is clinical ROI.
Business ROI is easier to see. More patients scheduled. More visits completed. More procedures completed. Fewer dropped referrals. Better use of capacity. Less staff time spent chasing patients. More reliable revenue. Better conversion of existing demand.
Clinical ROI is equally important. Patients receive appropriate follow-up. Surveillance intervals are implemented. Updated standards can be reflected in recalls. Patients feel remembered. Referring physicians see that the GI practice is organized and responsive. Fewer patients fall through the cracks.
A practice should not separate these too cleanly. In GI, the business and clinical logic often reinforce each other. A well-run recall system protects revenue and protects patients. A well-run referral workflow increases volume and improves access. Better scheduling helps the practice and helps the patient. Faster communication with PCPs strengthens the referral relationship and improves care continuity.
The point is not to make everything financial.
The point is to measure what matters.
If a recall pilot identifies 1,000 patients, contacts 700, schedules 300, and completes 200 procedures, that matters. If the old process scheduled 50, the difference is not theoretical. It affects revenue, capacity, staffing, patient care, and long-term trust.
The first 90 days should make the invisible visible.
RCM as a Second Example of Orchestration
Referral intake, scheduling, and recall show how orchestration brings patients into the
practice.
RCM shows how orchestration can improve the back office.
RCM stands for revenue cycle management. It is the set of activities that turns care delivered by the practice into payment received by the practice. It includes checking insurance, getting authorizations, coding, submitting claims, posting payments, following up on denials, and collecting what is owed.
Many practices already automate one piece of this. A bot may check claim status. A tool may verify eligibility. A report may show AR. A staff member may manually generate appeals. Another person may work denials. Another may post payments.
But the workflow may still depend on manual handoffs.
Orchestration asks a different question: can the work move from one step to the next based on payer rules, workflow logic, status, exceptions, and human review?
For example, for a specific payer, the system may check eligibility, identify whether prior authorization is needed, gather the relevant information, trigger submission, check claim status, identify denial patterns, prepare appeal letters, and route exceptions to the right person. The agent does not need to make every decision independently. It needs to move the work and bring humans in where judgment is
required.
That is the difference between isolated automation and orchestration.
The same thinking applies across the practice.
The workflow should not depend on one heroic employee remembering every rule, checking every portal, and manually moving every task. The system should carry more of the routine movement, while humans manage exceptions, judgment, and relationships.
API Access Is Helpful, but Not the Starting Point
Some systems make integration easier. Some make it harder.
One term that often comes up is API. An API is a secure doorway that allows one software system to communicate with another. If an EHR offers useful API access, another approved system may be able to retrieve information from it or write information back into it without a staff member manually copying and pasting.
For example, an API may allow an automation to check whether a patient has an
appointment, update a status, send information to another system, or pull a report.
That kind of access is helpful.
But it is not always available. Some systems provide strong API access. Some provide access only through partner programs. Some are more closed. Some make data access difficult.
That unevenness is part of the problem.
Still, the absence of perfect API access cannot become an excuse for doing nothing.
Depending on the workflow, practices may still use reports, exports, secure file transfer, RPA, computer-use agents, middleware, structured queues, staff-supervised updates, limited write-back, or integration services that connect with existing EHRs and practice management systems.
RPA stands for robotic process automation. It is software that performs repetitive computer tasks the way a staff member might: opening a screen, clicking a button, copying information, checking a portal, or moving data from one place to another.
A computer-use agent is a newer version of that idea. It is an AI system that can use a computer interface to complete tasks, such as navigating a portal or working through a queue, under defined rules and supervision.
Middleware is connecting software that sits between systems and helps them exchange information.
None of these approaches should be used casually. Security, compliance, vendor rules, patient privacy, audit trails, and data accuracy matter. But practices should not assume that every orchestration effort requires a full EHR replacement or perfect API access.
The less the system integrates, the more important it becomes to choose a narrow, supervised, low-risk workflow first.
At an industry level, however, this issue cannot be ignored.
GI needs more open standards so innovation can compete on value, not on who controls the data. If EHRs and other systems block connection, the entire specialty suffers. Pathways become harder. Partner integration becomes harder. Value-based contracts become harder. AI tools become fragmented. Practices become dependent on closed systems that do not move at the speed of clinical and operational need.
The goal should not be to make one vendor the winner.
The goal should be to let the best solutions connect safely, compete fairly, and improve care.
Avoiding the Next Fragmentation Trap
GI should learn from the EHR era.
The next mistake would be to recreate the same fragmentation with AI.
That risk is real. AI point solutions are multiplying. There are tools for prior authorization, call centers, voice agents, prep calls, ambient documentation, denials, scheduling, eligibility, coding, clinical documentation, patient engagement, and more. Some will be valuable. Some will not. Some will understand GI deeply. Many will not. Some will be built by people who only recently learned the workflows they are trying to automate.
The danger is not that these tools exist.
The danger is that practices adopt them without a larger architecture.
If each AI tool solves one small problem but does not connect with the rest of the practice, the result will be more fragmentation, not less. The practice may end up with one AI tool for calls, one for prior auth, one for scribing, one for prep, one for RCM, one for referrals, one for scheduling, and no unified view of the patient journey.
Then the next complaint will not be, “Our EHR does not work.”
It will be, “Our AI tools do not talk to each other.”
That is why orchestration matters.
The goal is not a mushrooming of point solutions. The goal is a foundational AI and automation layer with clear inputs, outputs, rules, escalation protocols, dashboards, accountability, and human oversight.
Before adopting any AI tool, the practice should ask:
What workflow does this improve?
What data does it need?
What happens before it acts?
What happens after it acts?
Where does the output go?
Who supervises it?
How does it escalate?
How will we measure success?
Does it reduce work, or merely move work elsewhere?
Does it strengthen the patient relationship?
Does it strengthen the referring physician relationship?
Does it become part of our orchestration layer, or is it another disconnected tool?
These questions matter more than the demo.
AI Is Not an IT Project
This transition cannot be delegated only to IT.
Technology teams are essential. They manage systems, security, devices, access, networks, integrations, vendors, and implementation details. But AI in GI is not merely a network decision or software decision. It is clinical, operational, financial, strategic, cultural, and patient-facing.
AI is not just a tool.
It is a new form of intelligence entering the practice.
That does not mean physicians need to become engineers. They do not need to learn programming. They do not need to write code. They do not need to understand every technical architecture.
But they do need to become AI-literate.
AI literacy means knowing enough to ask better questions, evaluate use cases, guide workflows, protect patients, lead staff, challenge vendors, and decide where AI should and should not enter the practice.
Physician leaders cannot remain passive and expect the right model to emerge.
If physicians do not lead, others will. EHR vendors will define the model. AI startups will define the model. Payers will define the model. Hospitals will define the model. Private equity platforms will define the model. Technology teams will define the model. Some of those players will add value. But none of them can replace the role of the gastroenterologist in understanding the patient, the procedure, the referral relationship, the disease pathway, and the economics of the practice.
Physicians should not take a back seat in the intelligence layer.
They should guide it.
The future of GI should not be anti-technology. It should be physician-guided technology.
The Human Encounter Should Not Be Automated Away
There is one more boundary.
AI should automate the work that gets in the way of medicine. It should not automate
away the heart of medicine.
Patients rarely come to GI with only a symptom. They come with fear, family history, embarrassment, anxiety, pain, confusion, and questions they may not say immediately. A patient who asks about colonoscopy may be thinking about a sibling who died of colon cancer. A patient with IBS may be carrying years of frustration from not being believed. A patient with reflux may fear cancer. A patient with IBD may be worried about losing control of life.
An AI agent can explain a prep instruction. It can remind a patient of an appointment. It can collect information. It can help schedule. It can check eligibility. It can draft documentation. It can monitor routine responses.
But the physician must still listen.
The physician must observe body language, hear the unsaid concern, examine the patient, interpret the story, reassure when appropriate, and make decisions in context. The goal of automation is not to remove the physician from the patient. It is to remove the screen, the clicks, and the clerical burden from the physician-patient relationship.
In that sense, AI may help medicine recover something it has been losing.
If routine work can be absorbed by intelligent systems, physicians may have more room to be present. The best future is not one where AI makes medicine less human. The best future is one where AI removes enough friction that physicians can practice more human medicine again.
From Workflow Orchestration to Disease Pathways
Chapter 4 described disease pathways.
Chapter 5 explains the foundation needed to run them.
Once a practice learns to orchestrate one workflow, it begins to see other workflows differently. The practice may start with recall. Then it sees scheduling. Then referral intake. Then prep calls. Then prior authorization. Then RCM. Then PCP communication. Then partner integration. Eventually, the same foundational layer can support disease pathways.
A fatty liver pathway needs longitudinal tracking of labs, imaging, fibrosis assessment, weight, metabolic risk, follow-up, PCP communication, and possibly nutrition, obesity medicine, endocrinology, or cardiology collaboration.
An IBS pathway needs diagnosis, education, APP follow-up, dietary support, gut-brain partners, behavioral health, symptom tracking, and communication back to PCPs.
An IBD pathway needs monitoring, labs, biologic tracking, infusion coordination, flare access, prior authorization, remote signals, and timely outreach.
A GERD and Barrett’s pathway needs sorting, surveillance, testing, escalation, and disciplined referral back when GI no longer adds value.
A CRC pathway needs screening eligibility, recall, positive-test follow-up, colonoscopy scheduling, prep support, pathology, surveillance intervals, and re-engagement when patients disappear.
None of these pathways can scale if every step is manual and fragmented.
A disease pathway is not isolated care.
It is coordinated care over time.
The first orchestration pilot may look administrative. It may involve recalls, scheduling, referrals, prep calls, or denials. But if done correctly, it builds the muscle that later allows the practice to run more sophisticated care models.
This is why the foundational layer matters.
It is not only about reducing cost.
It is not only about saving staff time.
It is not only about improving scheduling.
It is the beginning of a new way to operate.
The First Step Changes How the Practice Thinks
Once a practice starts thinking in terms of orchestration, it becomes difficult to go
back.
The practice begins to ask different questions.
Where does this patient enter the system?
What data is needed before the visit?
What should happen automatically?
What requires human judgment?
Where do patients drop off?
Where does the PCP need an update?
What is the next step after diagnosis?
Which partner needs to be involved?
What comes back from the partner?
What do we measure?
Who owns the outcome?
These questions are different from the questions most practices have historically asked.
They shift the practice from episodic care to pathway care. They shift the practice from isolated tools to connected workflows. They shift the practice from passive records to active systems. They shift the practice from reacting to what shows up to designing how care should move.
This shift will also open clinical possibilities.
Fatty liver is not only fatty liver. It connects to metabolic disease. It may involve obesity, diabetes, cardiovascular risk, endocrine collaboration, women’s health issues, nutrition, lifestyle, and long-term monitoring. Gut-brain care is not only IBS. It connects to behavior, stress, diet, neurogastroenterology, psychology, and chronic symptom management. CRC is not only colonoscopy. It is screening, navigation,completion, surveillance, prevention, and re-engagement.
As GI becomes more digital and AI-enabled, the specialty may expand far beyond the boundaries of today’s procedure-centered model. But that expansion will not happen by accident. It will require a foundation.
The practice that learns to orchestrate one workflow begins building that foundation.
A Practical Place to Begin
The practical instruction is simple.
Do not wait for the perfect EHR.
Do not wait for every vendor to integrate.
Do not wait for AI to become flawless.
Do not wait for a society guideline to tell you exactly what to do.
Do not buy five tools because everyone else is talking about AI.
Choose one workflow.
Measure the current state.
Assign ownership.
Involve the people doing the work.
Define what should happen.
Automate the repeatable steps.
Supervise the exceptions.
Track the results.
Then decide whether to scale, redesign, or stop.
For many practices, that first workflow should be recall, referral intake, or scheduling. For others, it may be prior authorization, prep calls, eligibility, denials, or another pain point. The specific starting point matters less than the discipline of starting correctly.
This is the foundational layer of GI 2.0.
It is how the practice moves from procedures to pathways without collapsing under complexity.
It is how the practice prepares to integrate partners without losing control.
It is how the practice prepares for AI without becoming fragmented.
It is how the practice prepares for clinical innovation without waiting for the EHR to solve everything.
Before GI can become the coordinator of digestive health, it must build the infrastructure to coordinate.
That infrastructure does not have to begin as a grand platform.
It can begin with one workflow that works better tomorrow than it does today.
But once that begins, the direction changes.
The practice is no longer simply digitizing old work.
It is learning how to move care.
That is the beginning of GI 2.0.