how Foresight Automates rcm: What Actually Works

There is no prize for choosing between rules and AI. There is a prize for getting claims paid cleanly, quickly, and with a defensible audit trail.

That matters even more in telehealth, where small operational details turn into expensive billing mistakes. Was the patient at home or in a clinic? Was the visit audio-only or audio-video? Was the rendering provider licensed in the patient’s state? Does the chart actually support the ICD-10 and CPT codes someone wants to bill? Is the member ID real, current, and attached to the right payer? Is the provider truly credentialed for that line of business, or does the EHR just happen to say they are?

This is why "rules vs AI" is the wrong framing for telehealth RCM. The best systems use deterministic logic for the black-and-white parts, chart-aware clinical intelligence for the gray areas, and human escalation when the cost of guessing is too high. That is how we designed Foresight.

Clean data first

Most automation projects fail before they ever get to coding logic. They fail at the input layer.

EHR and EMR data is messy. The same payer can appear under multiple names. Subscriber identifiers show up in different fields depending on the system. A diagnosis might be documented in a note, in a structured problem list, or nowhere reliable at all. Some systems store provider credential details cleanly. Others bury them in free text, outdated records, or partial integrations.

So the first job is not "run AI on claims." The first job is normalization.

During onboarding, Foresight maps each client's source data into canonical fields we can trust across workflows. That means we normalize payer names, member IDs, visit types, provider identifiers, place-of-service context, diagnosis sources, and other fields that have to be consistent before automation becomes safe. We also apply validation rules at the mapping layer, because bad input creates fake confidence downstream.

Here is the basic idea:

const claimInput = {
  payer: normalizePayer(raw.plan_name),
  memberId: cleanMemberId(raw.subscriber_id ?? raw.policy_number),
  placeOfService: visit.location === 'home' ? '10' : '02',
};

if (!claimInput.memberId) return 'PAUSE_FOR_REVIEW';

In plain English: clean the source data, map it to a standard structure, and stop early if a critical field is missing.

That sounds obvious, but this is where a lot of real improvement comes from. If your automation is built on top of inconsistent plan labels, malformed member IDs, or half-mapped clinical data, you do not have an automation system. You have a denial generator that happens to run fast.

Clean canonical data is what lets later steps behave predictably. Without it, review queues mean different things across different EHRs, downstream analytics become decorative, and every layer above the data—claim creation, prior auth automation, submission gating—inherits the mess.

Actionable review should happen before the claim becomes a problem

A common mistake in healthcare automation is treating review as a last resort—after a claim already exists, or worse, after a denial comes back.

In practice, the highest-value review items surface much earlier.

Sometimes the issue is administrative. A member ID is missing. The payer match is weak. The provider appears not to be credentialed for the service. Eligibility cannot be confirmed for the date of service. A telehealth encounter should carry POS 10 and modifier 95, but the source data is incomplete or contradictory.

Sometimes the issue is clinical and coding-related. The notes say "follow-up, patient doing okay" and someone wants to assign a more specific ICD-10 or CPT code than the documentation really supports. That is not the kind of ambiguity you want to discover after submission.

In Foresight, these items can surface before final claim assembly and again before submission. The point is not just to say "something might be wrong." The point is to make the issue actionable.

That can mean:

• pausing work because a member ID is missing or malformed
• flagging a diagnosis or procedure code when the chart support is too generic
• surfacing telehealth modifier or place-of-service issues
• stopping submission when credentialing or enrollment guardrails fail
• routing the item to a reviewer with the missing field or conflicting fact spelled out

Deterministic review states matter here. We do not want a fuzzy percentage that leaves the team guessing whether a claim is safe enough to send. Operationally, the workflow should answer a simpler question:

• proceed
• pause for review
• block

That is more actionable for a billing team, more defensible to an auditor, and much easier to wire into real work queues.

And when human review is needed, Foresight does not stop at handing someone a vague warning banner. We can route that work into managed review staffed by experienced US-based RCM operators who can resolve missing information, validate assumptions, and move work forward without forcing the client to build a whole exception-handling layer themselves.

The medical necessity engine is where the story gets more interesting

This is the part that used to get described too loosely in a lot of automation conversations.

The old mental model was: use a specialty-specific prompt, feed in a chart, and hope the system recognizes the right payer logic. That is not enough for production-grade RCM. Telehealth billing decisions need to be tied to the actual service code, the relevant clinical guidelines, and the evidence that exists or does not exist in the chart.

Foresight's medical necessity engine does this.

For a given service, lab, drug, or procedure, the engine starts with a guideline-backed decision tree tied to the code being billed. Those trees are represented as structured clinical clauses. You can think of them as a set of ways a service can be justified, where each path requires a specific combination of facts to be true. The engine then evaluates those conditions against the patient chart: diagnoses, labs, medications, procedures, note text, and other structured evidence.

The output is deterministic:

• APPROVE when the documented evidence satisfies a valid path
• REVIEW when a material condition is still indeterminate or missing
• DENY when the documented evidence fails the criteria or hits a hard stop

Just as important, the engine keeps an evidence chain. It is not just saying "we think this will pass." It can point to the facts that supported the outcome and the facts that were missing.

At a conceptual level, the core loop looks like this:

for (const clause of policy.clauses) {
  const results = clause.conditions.map(checkChartEvidence);
  if (results.every((r) => r === 'true')) return 'APPROVE';
  if (results.some((r) => r === 'unknown')) return 'REVIEW';
}

return 'DENY';

That is the entire philosophy in a few lines: if the chart clearly supports a valid path, approve it; if the chart clearly does not, deny it; if something material is still unknown, stop and review instead of pretending uncertainty is certainty.

Take a straightforward example like viral load monitoring in HIV care. There are situations where monitoring is clearly supported, like an initial treatment period or a medication change within a defined interval. There are other situations where routine monitoring is appropriate only if timing and treatment status line up with guideline expectations. If the chart clearly shows the diagnosis, treatment context, and required interval, the engine can approve. If the chart suggests the service is reasonable but the timing of the last test is unclear, it can return review and tell the team exactly what is missing. If the underlying prerequisite is not there at all, it can deny.

The same pattern applies to code-level billing decisions more broadly. If a service has diagnosis prerequisites, timing requirements, or documentation conditions that need to be satisfied together, the system does not blur those into a vague "probably fine." It checks whether the supporting facts are actually present. If they are, the claim can move forward. If one key condition is still unknown, the engine surfaces that exact gap for review before submission.

That matters because medical necessity review is not the same thing as completeness review.

Completeness review asks: do we have the fields, and do they look structurally valid?

Medical necessity review asks: if we send this to the payer, why are they likely to deny it, and what chart support is missing or weak?

Those are different questions, and mature RCM systems need both.

We do not think of clinical intelligence as a pure after-the-fact denial defense tool. In telehealth, it is more valuable as a pre-submission gate. If a claim is technically complete but clinically thin, you want the system to catch that before it turns into avoidable rework.

Why deterministic logic beats hand-wavy scoring

Under the hood, this is an application of Kleene's three-valued logic.

For any material condition, the system should be able to say one of three things:

• true
• false
• unknown

That sounds academic until you compare it to the way many automation tools behave in the real world. A lot of products produce a floating-point score, a colored badge, or an opaque "confidence" label that still leaves the operator asking the only question that matters: should I submit this or not?

Three-valued logic is better for operations because it forces the system to be explicit.

If the evidence is present and satisfies the rule, move forward.

If the evidence is present and fails the rule, stop.

If the evidence is incomplete, contradictory, or not strong enough to support a safe conclusion, route it to review with a concrete reason.

That creates a better audit trail, but it also creates better behavior. Teams do not waste time arguing over whether a claim is "probably okay." Reviewers see the exact gap they need to resolve. Automation does not quietly smuggle uncertainty into production. And the product can expose decisions in a way that is operationally useful instead of statistically decorative.

The same logic applies outside the medical-necessity engine. A missing member ID should pause work. A generic note that does not support a specific CPT assignment should pause work. A credentialing mismatch for a payer should block submission. These are not problems that improve because we assign them prettier decimals.

Analytics should improve the front door, not just explain the back end

The best analytics in RCM do more than tell you what went wrong last month. They change intake, workflow design, and data collection upstream so the same mistakes stop happening.

In one client environment, our analytics surfaced a repeated pattern: prior authorization approvals were underperforming not because the team was submitting the wrong medication or using the wrong payer forms, but because the intake flow was not capturing comorbidities that payers were actively weighing in their medical necessity decisions. For certain drug classes, cardiovascular history is a material factor in whether a PA gets approved, but the clinic was not collecting that information in a structured way. Once we mapped those data points and the client updated their intake to ask about cardiovascular conditions, the result was a 56% increase in PA approval rates—validated through a controlled A/B test across roughly 190,000 patients.

That is the kind of improvement people mislabel as "better AI." It is usually better system design—better mappings, better intake questions, better visibility into what the payer was actually reacting to.

In another case, analytics surfaced a suspiciously large cluster of denials tied to credentialing issues for a provider who was supposedly credentialed with the affected payers. On paper, that should not have been happening. But once we traced the signals through the workflow, the real issue was not abstract at all: her license appeared expired in the EHR, and there was also a tax ID mismatch. Without a joined-up view of denial patterns, credentialing status, and source-system data quality, that kind of issue can linger for months while everyone assumes "the payer is being difficult."

This is why we think analytics belongs in the operational loop, not in a reporting tab that leadership checks once a quarter.

Used correctly, analytics helps answer questions like:

• Which missing fields are creating the most rework?
• Which payer edits should become deterministic gates?
• Which clinical facts need to be captured earlier in intake?
• Which denials are really documentation problems versus enrollment problems versus data quality problems?
• Which fixes should happen in the EHR mapping layer instead of the billing team doing manual cleanup forever?

That feedback loop is where telehealth RCM compounds. Cleaner source data makes automation more reliable, which produces fewer preventable denials, which gives you better operational data about what to fix upstream. Each cycle makes the next one easier.

The real goal

The goal is not to build a magical black box that claims to automate revenue cycle management. It is to build a system that knows where deterministic logic ends, where clinical reasoning begins, and where human judgment is still the right call.

When those layers work together on top of normalized data, you get something much more useful than "AI for billing." You get an operational system that helps clinics submit cleaner work, catch risk earlier, explain its decisions, and get better over time without surrendering control.