One woman's extraordinary cancer journey raises a bigger question for healthcare leaders: Are we using technology to make room for human care—or making physicians and patients work harder to navigate the system?
“These tools should help physicians practice medicine in
the way they want to, spend more time on the work that matters most, and
deliver better care and outcomes for patients.” — Jennifer
Goldsack, inaugural leader of the American Medical Association’s Center
for Digital Health and AI.
The patient has cancer. The system has paperwork.
At 78, Mary Ann Thomas had already lived a long life. Then,
in June 2025, an abnormal mammogram set off a chain of medical evaluations that
led to news almost no one is prepared to hear.
She had three separate cancers: breast cancer,
endometrial cancer, and lymphoma in her fallopian tubes.
Her first question was understandably difficult: How could
three distinct cancers appear at the same time?
There was some relief in learning that none had
metastasized. But relief did not make the road ahead easy. Her treatment
included six sessions of chemotherapy and vaginal radiation therapy.
Through it all, her wife, Shelley, stayed by her side.
Support from the Canopy Cancer Survivorship Center at Memorial Hermann The
Woodlands Medical Center also helped Mary Ann feel informed, supported, and
cared for. She participated in nutrition classes, received prosthetic services,
and took part in wellness activities.
In an interview published by PEOPLE on October 17,
2026, Mary Ann reported that she was in complete remission.
Her story deserves to be told first as a story about a
person—not as a business case, a technology advertisement, or a convenient
metaphor for healthcare software.
There is no evidence that billing problems caused her
cancers, affected her treatment, or changed her outcome. We should not pretend
otherwise.
But her experience raises a question that reaches beyond
oncology:
When someone is fighting for their health, how much of
the surrounding system should require them—or the people caring for them—to
fight the system, too?
Patients may have to navigate referrals, insurance
requirements, eligibility checks, authorizations, appointment scheduling,
forms, records, bills, and explanations that seem to have been written for
someone who already understands the system.
Physicians and their teams face another version of the same
burden. They are expected to deliver excellent care while also ensuring that
clinical documentation, orders, coverage requirements, coding, and claims
satisfy multiple systems that do not always communicate cleanly.
The result can be absurd.
A physician spends years learning to diagnose disease. A
medical assistant learns how to keep a clinic moving. A medical biller learns
the complicated language of payer rules. Then the whole operation can be slowed
by a missing field, an outdated insurance detail, an unclear note, or a
requirement discovered after everyone thought the work was finished.
We have built extraordinary tools for diagnosing the human
body.
Why do we still struggle to get the information around that
body to move reliably?
A quote worth putting on the wall—and into the product
requirements
At an Axios Live event in October 2026, Judd Semingson,
president and CEO of Community Clinic, described what he wants technology to
accomplish:
“I'm looking for technology to enhance the science of
medicine so that I can lean into the art of medicine.”
— Judd Semingson, president and CEO of Community
Clinic, quoted by Axios, October 12, 2026.
That is a powerful standard for healthcare technology.
Not more screens for the sake of screens. Not artificial
intelligence added to a workflow simply because the word AI attracts
attention. Not another dashboard that tells an exhausted practice what went
wrong yesterday.
Technology should help clinicians spend more attention on
people and less on preventable administrative friction.
And here is the contrarian part: the most valuable
healthcare AI may not be the AI that produces the most impressive answer. It
may be the intelligence that prevents a preventable question from being created
in the first place.
That is the problem OnnX 2.0 is being built to address.
Not by promising to eliminate every denial. Not by claiming
that software can replace the judgment of physicians, billers, or practice
administrators. And not by suggesting that every administrative requirement is
unnecessary.
The ambition is more practical: improve the quality,
continuity, and usefulness of information before small gaps turn into expensive
downstream problems.
Because the claim is not where every problem begins.
Often, it is simply where the problem finally becomes
visible.
1. The healthcare industry has mistaken the smoke alarm
for the fire.
Imagine a claim being denied because a required
authorization was missing.
The denial appears in the billing system. Someone opens the
account, investigates, contacts the payer, checks the record, messages the
clinic, and starts a chain of corrections.
The claim has now become a task.
But rewind the story.
Was the authorization requirement identified when the
appointment was scheduled? Did the team know which service was planned? Was the
payer information current? Was the referral available? Did the authorization
record follow the patient and encounter as the work moved from one person to
another? Was responsibility clearly assigned?
Perhaps the problem began days or weeks before the claim
existed.
The denial is the smoke alarm. The original
information gap may have been the fire.
Yet healthcare often invests heavily in responding to the
alarm: denial work queues, claim-scrubbing tools, coding reviews, follow-up
teams, and increasingly sophisticated analytics.
Those capabilities can be valuable. A practice still needs
to detect and correct problems that escape upstream controls.
But there is a fundamental difference between getting better
at processing errors and reducing the number of errors that enter the process.
One approach improves the cleanup crew.
The other asks why the kitchen keeps catching fire.
A mature revenue-cycle strategy needs both. It needs
downstream recovery because healthcare is complex, payer rules change, and no
control catches everything. But it also needs upstream intelligence to
recognize the conditions that make errors more likely.
Consider a few familiar scenarios:
- Eligibility:
The insurance card was copied correctly, but the patient's coverage had
changed.
- Authorization:
The team obtained approval, but the record did not clearly connect it to
the planned service or encounter.
- Documentation:
The clinician recorded the relevant clinical facts, but the note did not
clearly support the information required for coding.
- Referral:
A referral existed somewhere in the system, but the next person could not
easily determine whether it was valid for the intended service.
- Charge
capture: A service was performed, but a key detail did not travel from
the clinical encounter to the billing process.
- Claim
follow-up: Staff had to investigate a problem that might have been
detected before submission.
These examples are not all the same problem. Some are
data-quality issues. Some are communication failures. Others reflect payer
requirements, unclear ownership, software limitations, or genuine clinical
complexity.
Treating them as interchangeable would be another mistake.
But they share an important question:
What did the organization know, when did it know it, and
was that information available to the person who needed to act?
That question is more useful than simply asking how quickly
a denial can be appealed.
It moves the discussion from blame to system design.
And it changes the technology requirement from “show me
another report” to “help me recognize and resolve the gap before it travels.”
2. The numbers are uncomfortable. The interpretation
should be even more uncomfortable.
Let's move beyond anecdotes.
The American Medical Association's 2026 report on its prior
authorization survey found that:
- 95%
of surveyed physicians said prior authorization delays access to
necessary care.
- 79%
reported that patients abandon treatment because of authorization
challenges.
- Physicians
complete an average of 40 prior authorizations per week.
- Physician
and staff time spent on prior authorization averages 13 hours per week.
- 94%
said prior authorization contributes to physician burnout.
- Only one
in three physicians believed the latest insurer reform pledge would
make a meaningful difference.
These findings reflect physicians' reported experiences and
perceptions; they are not proof that every authorization causes harm or that
every payer requirement is unnecessary.
Still, the pattern is hard to ignore.
Thirteen hours per week is not an abstract efficiency
metric. It is time that a practice could otherwise devote to patients, clinical
coordination, staff development, or simply keeping the workday from becoming a
second shift.
And if the first reaction to that figure is, “We need
another tool,” I would ask a more irritating question:
What if the next tool merely helps us process the burden
faster without reducing the burden itself?
A faster fax is still a fax. A beautifully designed queue is
still a queue. An AI assistant that drafts an appeal after an avoidable
information gap has already created rework may be useful—but it has not
necessarily solved the upstream problem.
Technology can automate a bad process, and automation can
make a bad process more efficient at producing the wrong result.
That is not a reason to reject automation. It is a reason to
ask better questions before buying it.
A separate 2026 PatientPoint Physician Confidence Index
identified time constraints, EHR documentation burdens, and prior
authorizations among physicians' leading day-to-day challenges.
The implication is not that technology is useless. It is
that technology must be judged by what it removes from the workload—not by how
much technology it adds to the workflow.
The contrarian metric: work that never had to happen
Healthcare commonly measures what it can easily count:
denial rate, days in accounts receivable, clean-claim rate, first-pass
acceptance, staff productivity, and reimbursement.
Those metrics matter. But a practice should also ask:
- How
many billing questions were created because required information was
missing upstream?
- How
often did staff re-enter information already available elsewhere?
- How
many tasks bounced between clinical, front-office, authorization, and
billing teams?
- How
often did the team discover a problem only after submission?
- How
much work was repeated because the first correction did not reach the next
person or system?
These are not merely productivity questions. They are
questions about the design of the information system.
The most useful metric may be the amount of avoidable work a
practice no longer has to perform.
No denial is not always possible. No rework is not always
realistic. But fewer preventable gaps, fewer duplicate touches, and earlier
identification of problems are measurable goals.
And if a technology vendor cannot explain how its product
affects those measures, ask what exactly you are buying.
A feature list is not an outcome.
3. Three perspectives healthcare technology should take
seriously
The healthcare system does not need another argument about
whether administration matters. It needs better agreement on what to improve
and how to measure improvement.
Three perspectives help frame the problem.
Perspective 1: Bobby Mukkamala, MD — reform must change
what physicians experience
Bobby Mukkamala, MD, the American Medical Association's
immediate past president, wrote in 2026 about the gap between insurers' public
promises and the reality physicians continue to report.
The AMA's survey found that only one in three physicians
expected the latest insurer pledge to make a meaningful difference. The
organization also reported continuing burdens involving authorization delays,
denials, staff time, and physician burnout.
The lesson for practice owners: a promise to simplify
a process is not the same as a measurable reduction in work.
When evaluating a new tool, do not settle for a
demonstration showing that it can create a task, draft a message, or display a
warning. Ask whether it reduces the time required to resolve the task, prevents
recurrence, and makes the relevant information available to the next person.
Ask for baseline measures. Ask for pilot results. Ask which
workflows must change. Ask what happens when the system is wrong.
And ask what the product does not do.
A serious vendor should be able to describe its limits
without changing the subject.
Perspective 2: Judd Semingson — technology should make
more room for the human side of care
Semingson's October statement about using technology to
enhance the science of medicine so clinicians can lean into the art of medicine
provides a useful north star.
Medicine is not just the correct execution of a protocol. It
involves judgment, trust, explanation, uncertainty, compassion, and decisions
made in the context of an individual patient's life.
The same principle applies to administrative technology.
The objective should not be to make a physician behave more
like a data-entry clerk. It should be to make the information surrounding
clinical care more reliable, so clinicians and staff have fewer preventable
distractions.
That means technology should support—not obscure—human
accountability.
An algorithm may flag a missing authorization. A qualified
staff member may need to determine what action is appropriate. A system may
identify a documentation inconsistency. The clinician remains responsible for
the clinical truth of the record.
The right question is not, “Can AI do this?”
It is: “Can AI help the right person make the right
decision, with better information and less unnecessary work?”
Perspective 3: Physician-burden findings — trust is
strong, but time is not unlimited
The PatientPoint research found that most surveyed
physicians believed their patients trusted them, while its research also
identified substantial pressures involving time, documentation, and
authorization.
That combination matters.
The relationship between patient and physician remains a
powerful asset. Yet the administrative environment can consume the time and
attention needed to sustain that relationship.
The answer is not to blame physicians for being busy, staff
for making mistakes, or patients for struggling to navigate complicated
systems.
It is to design operations that support the people doing the
work.
Trust is human. Reliability is operational. Good
healthcare needs both.
4. The hidden assumption: the claim is the center of the
revenue cycle
Many systems are organized around the claim because the
claim is visible, standardized, and measurable.
But the claim is the output of a long chain of decisions and
information exchanges.
Before a claim exists, a practice may need to identify the
patient, confirm coverage, understand the intended service, determine whether a
referral or authorization is required, gather clinical information, document
the encounter, apply coding rules, and capture the charges.
A defect at any stage can affect later stages.
That does not mean every claim problem is preventable
upstream. Payer policies may be unclear or change unexpectedly. Clinical care
is not always predictable. A payer may reject a claim despite reasonable
efforts. Human judgment is sometimes needed because the record does not fit a
simple rule.
But if a practice treats the claim as the first meaningful
moment to inspect the quality of its information, it is beginning its
investigation late.
Consider the difference between two operating models.
Model A: Reactive cleanup
A problem reaches the claim. The claim is rejected, denied,
or delayed. Staff investigate what happened. Someone contacts another
department or payer. The record is corrected, the claim resubmitted, or an
appeal prepared. The team moves on—sometimes without preventing the same issue
from recurring.
Model B: Upstream intelligence
Relevant information is captured as early as practical.
Information is structured so it can be checked and reused. Missing,
conflicting, or stale information is identified. The appropriate person
receives a specific, actionable signal. The issue is resolved—or explicitly
accepted as an exception—before it travels further when possible. The outcome
informs future prevention, with an audit trail and human oversight.
The second model is not magic. It requires reliable data,
appropriate integrations, sensible rules, clear ownership, and ongoing
maintenance.
It also requires discipline: a warning that nobody can act
on is just another notification. A system that flags everything teaches staff
to ignore it.
The goal is not to produce more alerts. The goal is to
produce fewer surprises.
That is why the future of billing intelligence should be
less about adding another isolated feature and more about preserving context
across the steps that lead to a claim.
The handoff is where context goes to disappear
Imagine a front-desk employee learns that a patient's
insurance has changed. The information is entered in one place, mentioned in a
message, and perhaps written on a sticky note that has somehow survived three
generations of office technology.
The authorization team may not see it. The clinical team may
still use the old information. The biller may discover the discrepancy after
the service.
Every person may have done their job reasonably well within
the information available to them.
The system still failed.
That distinction is important. Healthcare organizations
often respond to these situations with reminders: Be more careful.
Double-check. Communicate better.
Reminders have a role. But if the same information must be
manually rediscovered and re-entered at every handoff, the process is relying
on human memory to compensate for a structural weakness.
Human attention is valuable. It should not be the only
integration layer.
A more resilient design preserves the relevant information,
makes its source and timing clear, identifies conflicts, and routes the issue
to someone who can resolve it.
That is an information-design problem before it is a
productivity problem.
And it is one reason the next generation of healthcare
software should be evaluated on context continuity, not simply on the
number of tasks it can automate.
5. What a physician-owned practice can do before buying
another system
The answer is not to rebuild the entire revenue cycle on
Monday morning.
Start with one recurring problem. Make it visible. Find
where it begins. Measure the work it creates. Then test whether a change
reduces that work.
Step 1: Choose one expensive recurring problem
Do not begin with “We need to improve billing.” That is too
broad to investigate and too vague to measure.
Choose one specific pattern, such as claims delayed by
missing or incorrect insurance information, authorization issues discovered
after the service, repeated requests for documentation clarification, charges
that fail to reach the billing team, denials associated with recurring
documentation or coding issues, or staff repeatedly contacting the same payer
to resolve similar questions.
Review a manageable sample of recent cases. Start with 20–50
examples if the volume allows; this is a practical starting point, not a
statistically validated sample size.
For each case, record what happened, when the problem was
first detectable, what information was missing or inconsistent, who discovered
it, and how much work was required to resolve it.
Do not assume the initial explanation is the root cause.
“Missing authorization” describes the condition. It does not
explain why the authorization was missing, why nobody recognized the gap, or
why the issue was not visible to the next person.
The useful question is not only what failed, but when the
failure first became preventable.
Step 2: Map the information, not just the workflow
Traditional process mapping asks who does what, and in what
order.
That matters. But add a second layer: what information does
each person need, where does it come from, how current is it, and what happens
when it is absent?
At registration, verify identity, demographics, and
coverage. At scheduling, clarify the planned service, provider, and location.
During eligibility checks, confirm active coverage and relevant plan details.
For authorization, verify the requirement, status, approved service, and
validity. During the encounter, ensure that clinical facts and documentation
accurately reflect care. At coding and charge capture, check that
documentation, applicable rules, and services rendered are consistent. Before
submission, identify required data and relevant supporting information. During
follow-up, preserve the correction history and payer response.
This is a general diagnostic framework, not a universal
checklist of payer requirements. Actual requirements depend on the service,
payer, plan, jurisdiction, contract, and applicable rules.
The purpose is to make invisible dependencies visible.
Step 3: Separate missing information from conflicting
information
These are different problems and deserve different
responses.
Missing information means a required detail cannot be
found.
Conflicting information means two sources disagree.
Stale information means a detail may once have been
correct but may no longer be valid.
Unstructured information means the detail exists, but
it is difficult to locate, interpret, compare, or use reliably.
Unavailable context means the information may exist
somewhere, but the person making the decision cannot access it at the moment it
matters.
A generic alert saying “check the record” is unlikely to
solve these problems consistently.
A useful signal should identify the issue, show the relevant
source and timing, explain why it matters, and tell the responsible person what
needs review.
The system should not manufacture certainty when the record
is incomplete. Sometimes the correct output is simply: “Insufficient
information. Human review required.”
That is not a failure of intelligence. It is a sign of
restraint.
Step 4: Assign ownership before automating the task
A recurring issue can bounce between departments because
everyone sees it but nobody owns the resolution.
A small practice does not need a complicated governance
committee to address this.
It needs clear answers to three questions:
- Who is
responsible for resolving the issue?
- Who is
responsible for confirming that it was resolved?
- Who
reviews the pattern if it happens again?
The answer may differ by issue. Front-office staff may own
certain registration corrections. Authorization staff may own authorization
follow-up. Clinicians must retain responsibility for clinical accuracy. Billing
staff may identify the problem but not have the authority to change its
clinical source.
Do not automate an unclear handoff. First define the
handoff.
Otherwise, the software will simply move confusion from one
inbox to another—at machine speed.
Step 5: Fix the source where possible
When an error recurs, ask whether the source can be
corrected and whether that correction can be carried forward safely.
If the same demographic detail is repeatedly re-entered,
examine the data flow.
If authorization requirements are repeatedly discovered
late, investigate whether the requirement can be identified earlier.
If a documentation issue recurs, determine whether the
solution is better clinical guidance, a clearer template, improved information
retrieval, or an appropriate coding review.
Do not respond to every problem by adding a required field.
Too many mandatory fields can slow care, encourage meaningless entries, and
create the appearance of completeness without improving accuracy.
A required box that everyone fills with “N/A” is not data
quality. It is bureaucracy with a checkbox.
Step 6: Pilot the smallest useful intervention
Before deploying a platform across an entire practice, test
one well-defined use case.
A sensible pilot should specify the problem being addressed,
the patient encounters or claims included, the baseline frequency of the
problem, the current staff time required, the proposed intervention, the role
of human review, the criteria for success, and the conditions under which the
pilot should stop or be revised.
Where feasible, compare results with a similar period or an
appropriate comparison group. Account for changes in payer mix, patient volume,
staffing, and service mix.
Do not call a pilot successful because staff liked the
demonstration. Measure what changed after the demonstration ended.
Step 7: Build a learning loop
A correction should do more than repair one claim.
When the same issue occurs repeatedly, the organization
should ask whether a change to data capture, validation, routing, or staff
guidance could prevent recurrence.
That does not mean every case should trigger a new rule. An
exception may be unusual, unavoidable, or too ambiguous for automation.
But repeated patterns should become visible.
A useful learning loop records the original issue, the
decision made, the person or process responsible, the outcome, and whether the
intervention reduced recurrence.
The aim is not an AI that makes increasingly confident
guesses.
It is a system that becomes more useful because it has
better evidence about what happens in the practice.
6. The OnnX approach: move intelligence upstream
OnnX 2.0 is being developed around a simple premise:
Many downstream billing problems become visible only
after upstream information has already failed to travel, remain consistent, or
reach the right person.
OnnX is an upstream intelligence platform for healthcare,
built by physicians and medical billers to reduce downstream administrative and
billing noise so physicians can focus on clinical care.
Built by physicians and medical billers since 1995, the OnnX
concept is informed by the practical reality that clinical work and
revenue-cycle work depend on the same underlying information—but do not always
see it in the same way.
The platform's intended approach follows six stages.
Capture
Gather relevant clinical, administrative, coverage, and
encounter information from appropriate sources.
The goal is to reduce avoidable gaps at the point where
information enters the process.
Structure
Organize information so relevant details can be found,
compared, checked, and used consistently.
The goal is to make useful information more than a
collection of disconnected fields and notes.
Preserve
Retain relevant context, provenance, and history so
important details do not disappear between steps.
The goal is to reduce repeated investigation and ambiguity.
Propagate
Make relevant information available to the appropriate
downstream workflow or person, subject to permissions and system constraints.
The goal is to prevent each handoff from becoming a fresh
investigation.
Act
Identify meaningful gaps, prioritize issues, and support the
appropriate next action.
The goal is to deliver actionable signals, not another flood
of alerts.
Learn
Use reviewed outcomes to understand recurring patterns,
improve controls, and identify where human judgment remains necessary.
The goal is to learn from recurring problems without
treating historical patterns as unquestionable truth.
These six stages describe the intended operating model,
not a claim that every capability is already deployed or validated in
production.
The hard work lies in making the model reliable: integrating
with existing systems, distinguishing high-value signals from noise, protecting
sensitive data, maintaining traceability, and ensuring that the people
responsible for decisions remain in control.
OnnX is not being positioned as a traditional revenue-cycle
management service that takes over a clinic's billing operation. Nor is it a
promise that every denial can be prevented.
The opportunity is to help practices improve the information
and decisions that shape the revenue cycle before the claim becomes a problem.
Why this is different from simply adding AI
AI can summarize a note, draft an appeal, identify a
potential coding issue, or classify a denial. Those uses may be valuable.
But an isolated AI feature does not necessarily preserve
context across the whole process.
If the system does not know which information is current,
where it came from, what it applies to, and who is responsible for acting on
it, a sophisticated model may still produce a sophisticated mistake.
The more consequential question is whether intelligence can
be placed where it changes the outcome—not merely where it makes a compelling
demonstration.
For OnnX, the hypothesis is that upstream context,
structured information, and appropriate decision support can reduce avoidable
downstream administrative work.
That hypothesis needs to be tested in real practice
environments, with clear measures and honest reporting. The product must earn
trust through evidence, not adjectives.
7. The metrics that matter: stop counting activity as if
it were progress
A practice can become very good at processing work that
should never have existed.
That is why activity metrics need to be balanced with
measures of prevention and quality.
Useful measures include:
- Denial
rate by reason: Reveals recurring payer or documentation patterns,
although changes in payer mix can affect the results.
- First-pass
acceptance: Indicates whether submitted claims meet relevant initial
checks, but acceptance does not guarantee payment or clinical
appropriateness.
- Rework
touches per claim: Shows how often staff revisit or transfer an issue.
Define a “touch” consistently.
- Time
to resolve a billing issue: Measures how long problems remain open,
though faster closure does not always mean a correct resolution.
- Upstream
detection rate: Tracks how often known issues are identified before
submission. Define which issues were reasonably detectable upstream.
- Repeat-error
rate: Indicates whether the same issue recurs after correction.
Separate unavoidable exceptions from preventable patterns.
- Duplicate
data-entry frequency: Measures how often the same information must be
re-entered, while recognizing that some repeated confirmation may be
required for safety or compliance.
- Staff
time per issue: Estimates the labor associated with investigation and
correction, without double-counting work across departments.
- Unresolved
exceptions: Highlights problems that still require human judgment or
external action. A low count may reflect under-reporting rather than
improvement.
Establish a baseline before introducing a new tool. Track
both operational results and unintended effects.
For example, a system might reduce the number of manual
reviews but increase the number of incorrect alerts. It might speed up claim
preparation while shifting more work to clinicians. It might reduce one
category of denial while making another harder to detect.
Measure the whole effect, not just the most flattering
number.
And keep the financial analysis honest.
If a tool saves 10 staff hours per week, those hours have
economic value. But the value depends on what the practice can actually do with
the recovered time. If the clinic cannot redeploy the capacity, the savings may
be less direct than the headline suggests.
The best business case connects measured operational
improvement to a credible financial outcome.
It does not multiply a hypothetical time saving by an
optimistic hourly rate and call the result guaranteed ROI.
8. Five traps that can make an “intelligent” billing
system less intelligent
Trap 1: Automating before understanding the root cause
If a clinic has not investigated why a problem recurs,
automation may standardize the wrong response.
Start with the pattern. Then choose the intervention.
Trap 2: Confusing more data with better information
A system can collect thousands of fields and still fail to
answer a simple question: Which detail is relevant to this encounter, and can
it be trusted?
Data volume is not the same as data quality.
Trap 3: Creating alert fatigue
When every discrepancy is labeled urgent, nothing feels
urgent.
Alerts should be prioritized by relevance, consequence, and
actionability. Low-value notifications should be removed, consolidated, or
routed differently.
Trap 4: Treating the algorithm as the final authority
A model may identify a potential inconsistency, but a
potential inconsistency is not automatically an error.
Clinical judgment, payer rules, coding requirements, and
case-specific context matter. Human review must be available where appropriate,
and decisions should be traceable.
Trap 5: Measuring the software instead of the practice
Logins, clicks, completed tasks, and generated summaries can
indicate use. They do not prove better care, fewer errors, or improved
financial performance.
Measure the outcome the practice actually wants.
A product that is used every day but does not reduce a
meaningful problem may be popular, inconveniently embedded, or simply difficult
to remove. Usage is evidence of usage.
It is not proof of value.
9. Myth busters: what better billing intelligence can—and
cannot—do
Myth: Every denial is preventable.
No. Payer decisions, policy interpretation, clinical
complexity, and incomplete external information can create problems even when a
practice follows a sound process. The goal is to reduce preventable failures
and improve the handling of unavoidable ones.
Myth: AI will eliminate the need for experienced billers.
Experienced billers understand payer behavior, exceptions,
documentation patterns, and the practical difference between a theoretical rule
and a real-world problem. That expertise is valuable for designing, evaluating,
and supervising intelligent systems. Automation should reduce avoidable manual
work—not erase the judgment that makes the work reliable.
Myth: A clean claim means the entire process is healthy.
A claim can pass initial edits and still be denied, delayed,
or paid incorrectly. A clean-claim measure is useful, but it cannot tell the
whole story about upstream data quality, authorization, payment accuracy, or
rework.
Myth: The problem is always the front desk.
Sometimes an error begins at registration. Sometimes it
begins with unclear payer requirements, fragmented software, poor handoffs,
clinical documentation, or a process that assigns responsibility to nobody.
Blaming one employee is easy. Identifying the system condition that allowed a
problem to recur is more useful.
Myth: More automation always means more efficiency.
Automation can reduce repetitive work, but it can also
amplify incorrect assumptions, generate false alerts, or create a new exception
queue. A task is not improved simply because a machine performs it.
Myth: The best AI system is the one that makes the most
decisions.
In healthcare, the best system may be the one that
recognizes when it lacks enough information to decide. Knowing when to escalate
is a capability, not a defect.
Myth: A practice needs a complete technology overhaul to
improve.
Not necessarily. One carefully measured improvement to a
recurring problem may be more valuable than a costly system-wide transformation
with unclear goals.
Myth: Administrative work is separate from patient care.
Administrative tasks can affect whether care is authorized,
scheduled, documented, billed, or financially sustainable. Not every
administrative problem harms a patient, and not every billing issue is a
clinical issue. But the boundary between operations and care is not as clean as
a spreadsheet might suggest.
10. Legal, ethical, and clinical guardrails: intelligence
needs boundaries
A system that touches healthcare information and billing
decisions must be designed around more than efficiency.
The following considerations should be part of any
implementation plan. They are general principles, not legal advice;
requirements depend on the organization, use case, contracts, jurisdiction, and
applicable law.
Protect patient information
Determine what information the system needs, why it needs
it, who can access it, how it is transmitted, and how long it is retained.
Where applicable, assess HIPAA obligations, business
associate relationships, security safeguards, and contractual responsibilities.
Use the minimum necessary information where that standard applies. Avoid
placing protected health information into unapproved AI tools or consumer
services.
Privacy should not be added after the prototype becomes
popular. It should shape the design from the beginning.
Keep clinical documentation truthful
AI-generated documentation must not invent findings,
examinations, services, or clinical reasoning. A clinician should be able to
review and correct relevant content before it is finalized.
A system should distinguish between what the source record
says, what a model infers, and what remains unknown.
That distinction becomes especially important when
documentation is used to support coding, medical necessity, or reimbursement.
Do not let revenue incentives distort clinical judgment
Clinical decisions must remain grounded in the patient's
needs and applicable standards of care—not in a model's desire to maximize
reimbursement.
Coding and documentation support should help represent the
services actually provided. It should not encourage upcoding, unsupported
diagnoses, or the addition of documentation merely to produce a desired
financial result.
Preserve accountability
If an AI system flags an issue, someone must know who is
responsible for reviewing it. If it recommends an action, the system should
preserve the basis for that recommendation to the extent appropriate for the
use case.
Organizations should be able to investigate errors, correct
information, document exceptions, and determine when a human decision overrode
an automated recommendation.
Test for uneven performance
Payer rules, clinical specialties, patient populations, and
practice settings differ. A system that works well in one environment may
perform poorly in another.
Evaluate performance across relevant scenarios. Monitor
false positives and false negatives. Provide a route for staff to challenge
incorrect outputs and escalate uncertainty.
Be honest about what has been validated
A prototype, a successful demonstration, a pilot, and a
proven production system are different things.
Vendors and practices should state which capabilities are
available, which are being tested, what evidence supports them, and what
limitations remain.
For OnnX, this distinction matters. The upstream
intelligence thesis is a direction to build and validate—not permission to
claim outcomes that have not yet been demonstrated.
Trust is not a marketing feature. It is the operating
requirement.
11. Recent healthcare signals point toward a larger shift
Three recent developments reinforce why the administrative
side of healthcare deserves serious attention.
The prior authorization reform credibility gap
In May 2026, the AMA reported that only one in three
physicians surveyed expected the latest insurer pledge to meaningfully improve
prior authorization. The report also described continued delays, staff burden,
and physician concerns.
The implication for practice leaders is straightforward:
voluntary promises and broad commitments should be evaluated against actual
changes in daily work.
If requirements are simplified, measure whether they are
simpler. If turnaround times improve, measure whether care and workflow
improve. If automation is introduced, examine whether it reduces friction or
merely moves it.
Physicians continue to report time and documentation
pressure
The 2026 PatientPoint Physician Confidence Index identified
time constraints, EHR documentation, and prior authorization among the most
frequently reported daily challenges.
That should influence technology purchasing decisions.
A product should not be evaluated only by whether it works
technically. It should be evaluated by whether it fits the realities of
clinical practice, respects staff capacity, and reduces work that does not need
to exist.
Healthcare leaders are asking technology to serve the
human relationship
At the October 2026 Axios Live event, Judd Semingson
emphasized technology's potential to enhance medical science while allowing
clinicians to focus more on the human art of medicine.
That is a useful test for the next wave of healthcare AI.
Does it make the human encounter better, or does it create
another layer of administration around it?
Does it help people understand what needs attention, or does
it add more noise?
Does it reduce unnecessary work, or does it simply make the
work look modern?
The opportunity is not to digitize every existing process
without question. It is to decide which processes deserve to be improved, which
information needs to travel, and which decisions require human judgment.
The future belongs neither to blind automation nor to
nostalgia for paper charts.
It belongs to systems that use technology deliberately.
12. The future: from reactive revenue cycle to more
predictable operations
Imagine a practice in which important information is
captured once where practical, checked when it matters, preserved with its
context, and made available to the next person who needs it.
Imagine a potential authorization issue being surfaced early
enough for staff to investigate it before it disrupts the workflow.
Imagine recurring documentation questions being categorized
and traced to their source instead of appearing as an endless stream of
unrelated tasks.
Imagine a biller spending less time searching for
information and more time handling the exceptions that genuinely require
experience.
These are not promises that any one product can deliver
universally. They are design goals worth testing.
The longer-term opportunity is a shift from reactive
revenue-cycle work toward more predictable operations.
That shift may involve context-aware checks that identify
missing or conflicting information at the appropriate stage; structured data
that makes relevant details easier to retrieve and compare; workflow-aware
intelligence that understands where an issue belongs and who can act on it;
human-supervised recommendations that make uncertainty visible and preserve
accountability; longitudinal learning that identifies recurring problems
without blindly treating historical outcomes as correct; and auditability that
allows practices to understand why a system produced a signal or
recommendation.
The central challenge is not just building a clever model.
It is creating a reliable operating layer around fragmented information,
changing requirements, and real human decisions.
And the business opportunity is not limited to reducing the
cost of billing labor.
A practice that spends less time correcting avoidable
problems may have more capacity for patient care, better visibility into
operational risk, and more time to focus on its core clinical mission.
Those benefits should be measured rather than assumed.
Why independent practices matter
Small and medium-sized physician-owned practices operate
under constraints that large health systems may be better positioned to absorb.
They may have fewer specialized staff, less technical
capacity, limited negotiating leverage, and less room to absorb delayed
reimbursement or repeated administrative work.
A solution designed for a large enterprise may be too
costly, too complex, or too demanding to implement in a smaller practice.
That creates a specific design challenge: make
intelligence practical enough for the clinics that cannot afford to maintain a
department just to manage their technology.
The product must be understandable, affordable, secure, and
useful within existing operations. It must not assume that a small practice has
a dedicated data engineer, an integration team, or spare hours for an elaborate
implementation.
A system that works only after a practice hires additional
staff to manage it has an awkward definition of efficiency.
For OnnX, this is part of the intended direction: upstream
billing intelligence for physician-owned practices, designed around the
information that connects clinical work to administrative and revenue-cycle
decisions.
The goal is not to replace the people who understand
healthcare operations. It is to give those people better information and fewer
avoidable problems to chase.
13. A practical 30-day experiment for clinic owners
A practice does not need to wait for a new platform to begin
learning from its own operations.
A 30-day experiment can establish whether a recurring issue
is worth solving.
Week 1: Establish the baseline
Choose one recurring billing or administrative issue. Define
it clearly. Review a sample of cases and record the frequency, point of
discovery, resolution time, and departments involved.
Week 2: Trace the cause
Map where the relevant information originated, where it
became incomplete or inconsistent, and when the issue could first have been
detected. Ask staff who perform the work; they often know where the process
breaks.
Week 3: Test one change
Introduce a small intervention: clarify ownership, improve a
data field, add a targeted check, change a handoff, or create a clear
escalation rule. Do not change five things at once if you want to learn which
one mattered.
Week 4: Evaluate honestly
Compare the results with the baseline. Did the issue occur
less often? Was it identified earlier? Did staff spend less time resolving it?
Did another problem appear? Decide whether to keep, revise, or abandon the
intervention.
This experiment will not prove that an intervention works in
every setting. Thirty days may be too short for low-volume problems or seasonal
patterns. But it can help a practice move from general frustration to a
testable operational question.
If the experiment reveals a persistent issue that requires
more complex information handling, that finding can inform a technology
decision.
If a simple process change solves it, that is a successful
outcome too.
The objective is not to buy software.
The objective is to stop paying repeatedly for the same
avoidable problem.
14. Questions physicians and clinic owners should ask
before buying billing AI
Before signing a contract, ask the vendor these questions.
1. What specific problem does this product solve?
Ask for a concrete workflow and a measurable outcome. “We
use AI to improve efficiency” is a category description, not a business case.
2. At what point in the process does it intervene?
Does it help identify a problem before submission, or does
it help manage the problem after a denial? Both may be useful, but they solve
different problems.
3. What information does it need, and where does that
information come from?
Understand the data dependencies, integration requirements,
freshness, and limitations. Ask what happens when the information is missing or
contradictory.
4. What evidence supports the claimed results?
Ask whether the evidence comes from a demonstration,
internal testing, a pilot, or a controlled evaluation. Request relevant
definitions, time periods, and limitations.
5. What happens when the system is wrong?
Understand how users can correct the output, override a recommendation,
escalate an exception, and review the decision history.
6. Does it create more work for clinicians or staff?
Include training, data entry, exception handling,
monitoring, and ongoing maintenance in the cost of adoption.
7. How does it protect patient information?
Review security, privacy, access controls, retention,
subcontractors, and applicable contractual obligations.
8. Can the practice measure the outcome independently?
The practice should be able to track whether the product
improves the metrics that matter. Avoid relying entirely on a vendor's
proprietary score.
9. What does it cost to implement and maintain?
Include integration, configuration, training, staff time,
support, and any charges that scale with usage.
10. What would make us stop using it?
Define the failure conditions before implementation. A
credible evaluation includes the possibility that the product does not work
well enough for the intended use case.
These questions are not anti-technology. They are how
responsible buyers distinguish useful technology from expensive theater.
15. Frequently asked questions
What is upstream billing intelligence?
Upstream billing intelligence is an approach to identifying
and addressing relevant information gaps, inconsistencies, and operational
risks before they create downstream billing problems where possible.
Rather than focusing only on claims, denials, and payment
follow-up, it examines the information and decisions that shape the claim
before submission.
Does every denial start upstream?
No. Some denials arise from payer decisions, changing
policies, contractual issues, clinical complexity, or circumstances that a
practice could not reasonably identify beforehand. The goal is to prevent
avoidable problems, detect other issues earlier where possible, and handle
exceptions more effectively.
Is upstream billing intelligence the same as
revenue-cycle management?
No. Revenue-cycle management is a broad set of operational
and financial activities spanning registration, eligibility, authorization,
documentation, coding, claims, payment, and follow-up.
Upstream billing intelligence focuses on the quality,
continuity, and use of information that supports those activities. It can
complement existing RCM systems without necessarily replacing them.
Can AI replace medical billers?
AI can assist with certain repetitive information tasks, but
healthcare billing involves interpretation, exceptions, payer-specific
knowledge, communication, and accountability. Experienced billers can help
identify useful patterns, validate system outputs, and handle cases that
require judgment.
The practical objective should be to reduce avoidable manual
work while preserving appropriate human review.
How can a small medical practice start reducing billing
rework?
Start by selecting one recurring problem, measuring its
frequency and resolution time, tracing it to the earliest point where it could
have been detected, and testing a targeted change. Establish a baseline and
evaluate the results before expanding the intervention.
What should a clinic measure besides its denial rate?
Useful complementary measures include rework touches per
claim, time to resolve an issue, upstream detection rate, repeat-error rate,
duplicate data-entry frequency, staff time per issue, and unresolved
exceptions. Define each measure consistently and account for changes in volume
and case mix.
Does OnnX guarantee fewer denials or higher
reimbursement?
No such guarantee should be made without validated evidence
supporting the specific claim. OnnX's intended focus is upstream healthcare
billing intelligence: helping practices improve information quality and
identify avoidable problems earlier. Its performance must be established
through appropriate testing and real-world measurement.
Why focus on physician-owned practices?
Independent and smaller practices may have limited staff and
technical resources while still facing complex administrative requirements.
Practical, affordable tools that reduce avoidable work could be especially
valuable in those environments, provided implementation does not create more
complexity than it removes.
What is the biggest mistake practices make when adopting
AI?
One common mistake is buying a tool before clearly defining
the problem. Without a baseline, a specific use case, and measurable success
criteria, it is difficult to know whether the technology actually improved the
operation.
16. The question we should be asking
Mary Ann Thomas's story is a reminder that healthcare is
ultimately about people: patients facing uncertainty, family members providing
support, clinicians making difficult decisions, and staff helping the system
function.
Her recovery should not be turned into an unsupported
argument about billing technology. It stands on its own as a human story of
treatment, support, and remission.
But it also invites a broader reflection.
When people enter the healthcare system, they should not
have to become experts in its administrative architecture just to receive care.
Physicians should not have to spend so much of their professional attention
compensating for fragmented information. Medical billers should not have to
reconstruct the same facts repeatedly because context failed to travel.
And technology companies should not celebrate every
automated task without asking whether the task needed to exist in the first
place.
We have spent decades getting better at documenting,
transmitting, processing, and correcting information.
The next challenge is to make that information reliable,
connected, timely, and useful before it becomes a problem.
That is the difference between digitizing a mess and
redesigning the conditions that produce it.
The future of healthcare technology should not be measured
by how many clicks it can eliminate in a demonstration. It should be measured
by the unnecessary work it helps remove from real practice—and the human
attention that work gives back.
Judd Semingson's words offer a worthy standard: technology
should enhance the science of medicine so clinicians can lean into the art of
medicine.
For OnnX, that means building upstream intelligence around
the information that connects clinical care to operational and billing
decisions.
Not replacing the physician. Not replacing the experienced
biller. Not promising a frictionless healthcare system that will never exist.
Making the system less dependent on people repeatedly
fixing problems that better information could have helped prevent.
Because the physician's job is to care for the patient—not
to become the unpaid integration layer between a dozen disconnected systems.
And the biller's job should not be to solve the same mystery
every Tuesday.
Let's start a more useful conversation
Physicians, clinic owners, practice administrators, and
medical billers:
If you could eliminate one recurring administrative or
billing problem from your practice—not merely process it faster, but prevent it
from happening so often—what would you choose?
Would it be eligibility errors? Authorization delays?
Documentation gaps? Repeated payer calls? Information that disappears between
departments? Or something the rest of the industry has overlooked?
Share your perspective in the comments. The problems
practitioners encounter every day can reveal where better information, better
processes, and better technology are most needed.
If this perspective challenges how you think about
healthcare administration, share or repost it with a physician, clinic
owner, practice manager, or medical biller who is wrestling with these issues.
Visit the Featured section of my LinkedIn profile for
a free resource—no signup required.
OnnX 2.0 is being built around a simple idea: better
decisions begin before the claim becomes a problem.
About the author
Dr. Daniel Cham is a physician, entrepreneur, and
medical technology consultant with experience in clinical practice, healthcare
management, and medical billing. His work focuses on practical solutions to
operational challenges facing physicians and independent medical practices.
As founder of OnnX 2.0, he explores how upstream
intelligence, better information quality, and responsible AI can help
physician-owned clinics reduce avoidable administrative work and make better
billing decisions.
Connect with Dr. Cham on LinkedIn.
References and further reading
- Nicholas
Rice, PEOPLE. “After an Abnormal Test Result, Woman, 78,
Learned She Had Breast and Endometrial Cancer, Plus Lymphoma.” October 17,
2026. Read
the article.
- American
Medical Association. “AMA Survey: Prior Authorization Reform Pledge
Falls Short with Physicians.” May 13, 2026. Read
the report.
- PatientPoint.
“Physicians Are Under Pressure, Their Confidence in the Patient
Relationship Isn’t.” September 2026. Read
the findings.
- Axios.
“Axios Live: How Health Care Providers Can Reach Patients in an Era of
Mistrust.” October 12, 2026. Read
the article.
Disclaimer
This article is for general educational and informational
purposes only. It does not constitute medical, legal, coding, reimbursement,
compliance, or financial advice. Healthcare requirements vary by payer,
service, jurisdiction, and organization. Practices should consult qualified
professionals and verify applicable requirements before changing clinical,
billing, privacy, or compliance processes. Statements about OnnX describe its
intended approach and development direction, not a guarantee of product performance
or financial results.
Continue the conversation
Knowledge creates possibilities. Practical insight turns
them into progress. Start learning, share your perspective, and help build a
healthcare system that works better for the people who depend on it.
#HealthcareInnovation #MedicalBilling
#RevenueCycleManagement #HealthcareAI #PhysicianEntrepreneur
#HealthcareTechnology #IndependentPractices #MedicalPracticeManagement
#AdministrativeBurden #OnnX #OnnX2.0 #UpstreamIntelligence
