Before the note is signed

A physician finishes a visit. The documentation supports a higher level of service, but they choose the level below it anyway. They aren’t trying to leave money on the table. They’re trying to stay well clear of a code they might someday have to defend.

The rules don’t make that choice easier. In a 2014 study, 32 family physicians described the documentation rules for most visit types as unnecessarily complicated and unclear, which led them to document and code by heuristics and patterns rather than by the rules themselves (source: Family Medicine, via PubMed).

Weeks later, a review finds the mismatch. The work was done and documented, but the easiest opportunity to correct the code is gone. Now someone has to bring the case back to a physician who has already moved on.

That gap exposes an important distinction in clinical AI: some answers arrive while a decision is still open, and others arrive after the workflow has ended.

The window closes at the signature

While the encounter is open, the physician is already in the chart and thinking about the patient. A diagnosis can be changed, a referral can be placed, a care gap can be addressed, and a code can be corrected.

The signature is not an absolute technical boundary. Notes and claims can sometimes be amended later. It is an operational one. After the physician moves on, changing the outcome usually requires a second workflow: a report, a message, a queue or a follow-up conversation.

That is a very different product from helping the physician get it right while they are already there.

Retrospective AI solves a different problem

AI can do useful work against filed notes, claims and downstream data. It can find patterns, exceptions and missed opportunities across thousands of encounters.

But when one of those findings requires a physician to do something differently, the analysis creates another job. Someone has to surface the finding, get the physician’s attention and ask them to revisit a decision that may have been made weeks earlier.

The analysis may be excellent. Its timing limits what it can change.

The same AI, before the signature

One of our earliest AI customers built a coding assistant on Bridge. It evaluates the encounter while the physician is still working and surfaces its recommendation beside the chart.

The physician sees the recommendation in the workflow, checks it against the documentation and decides whether to accept it. The physician stays in control, and the decision takes seconds rather than becoming a case for someone to revisit later.

Bridge is not the coding model. It gives the app live context about the patient and encounter the physician is viewing and a place to present the result inside the EHR workflow.

The model does not have to become smarter for the product to become more useful. The analysis has moved into the window when it can still affect the decision.

It isn’t only coding

The same principle applies to much of what clinical AI is supposed to help with.

A trial match is more useful before the treatment plan is set than after it. A care gap is easier to close while the patient is still being seen than when it appears on a report weeks later. A referral is easier to place while the physician is deciding what happens next than after the patient has gone home.

Retrospective analysis still matters for auditing, benchmarking and work that is intentionally back-office. But when the desired outcome depends on a clinician acting on a specific patient, timing becomes part of the product.

Which side of the signature

When evaluating clinical AI, ask how good the model is. Then ask when its answer arrives.

For decisions that belong in the encounter, an answer delivered afterward is information for the next workflow. An answer delivered while the decision is still open has a chance to change this one.

The model can be identical. The product is not.