Patient Opportunity Intelligence Examples: Five Patients, Five Next Actions

Patient opportunity intelligence is easiest to understand through examples: a GI patient with an unbooked EGD and an overdue colonoscopy recall, a referral nobody called, an MRI result nobody reviewed. In each case the output is the same. One patient, every open care need behind them, the evidence for each, an estimated value, and one next action with one owner, closed only when the care is completed.

These examples show the patient-level output of healthcare revenue leakage intelligence. Healthcare revenue leakage is revenue a practice should have earned but didn't, because a patient dropped out between steps of care: a referral never scheduled, a procedure ordered and never completed, a follow-up past due. Leakage measurement counts those gaps; patient opportunity intelligence turns them into a ranked list of people for staff to work. For the product itself, see the patient opportunity intelligence platform. This article stays with worked cases.

How should you read these patient opportunity intelligence examples?

Every example below follows the same seven steps, run nightly against the practice's own data.

For each patient we show what the record contains, what happens when separate lists are worked by separate people, and what the combined view changes. All five are illustrative composites, not real patients, and none of them involves a clinical decision by software. The provider's orders and intervals drive everything, and the practice's clinicians sign off the rules.

Example 1: A GI patient who sits on two lists

What the record shows. An EGD order placed several weeks ago with nothing booked, a surveillance colonoscopy recall that is now past due, and a routine office visit already scheduled for later this month.

Worked from separate lists, the procedure scheduler calls about the EGD and the recall scheduler calls a few days later about the colonoscopy, while the upcoming visit goes unused.

Worked as one patient, the two open items appear on one row with a note that a visit is coming. One owner decides whether to call now or raise both items at the visit. When the EGD is completed, that item closes. The recall stays open until the colonoscopy is completed.

Example 2: A referral that was never called

What the record shows. A cardiology referral arrived by fax three weeks ago and was filed to the referral queue. No contact attempt is logged and no appointment exists.

The evidence is strong. There is a clear trigger, the practice's contact window has passed, and nothing in the schedule or encounter history suggests the patient was seen. Confidence is high, so the patient goes straight to the referral coordinator's list rather than to review.

The next action is a call, and the item does not close when the patient books. It closes when the consult visit is completed. The reasons referrals stall like this are covered in why referrals don't get scheduled.

Example 3: An order that looks open but probably is not

What the record shows. A stress test order is still open in the EHR. There is no booking at the practice. But an HIE notification shows the patient had an outpatient cardiac test at a local hospital two weeks after the order.

Worked from an open-orders report, this patient gets a call about a test they may already have had. That is the call that teaches staff to distrust the list.

Worked with confidence attached, the item is marked low confidence and routed to records staff, not schedulers. They request the outside report, and if it confirms the test, they close the order as completed elsewhere with a reason. The cardiology version of this sorting is in finding echo and stress test orders that were never scheduled.

Example 4: Booked, then canceled, then forgotten

What the record shows. A patient overdue for a follow-up visit was reached by the recall team and booked. Two days before the visit, the appointment was canceled through the reminder system. Nothing has been booked since.

Worked from a contact log, this recall looks finished: the patient was contacted and scheduled. The reminder tool did its job by protecting an appointment that then disappeared.

Worked as an expected event, the booking only paused the item. The cancellation reopened it automatically, with the cancellation reason attached, and it returns to the top of the recall list. The division of labor between the two tools is explained in patient recall software vs. reminder software.

Example 5: An imaging result nobody reviewed

What the record shows. A sports medicine physician ordered a knee MRI. It was performed at an outside imaging center, and the report arrived by fax and was filed to the chart. No follow-up visit, phone review or portal note followed.

The next action is a conversation, not a procedure. An MA calls to offer a visit to go over the result. If the patient says they feel better, that is documented and routed to the provider, who decides whether anything else is needed. The item closes on a completed results visit or a documented decision.

How do the five examples compare?

What do the examples have in common?

Staff will only work a list they believe. Across all five examples, that trust rests on the same properties:

• Booked patients are removed. Anyone already scheduled for the same service inside the window never appears.
• Rules are approved by clinicians. Intervals and windows come from the practice, not a vendor default. No tool decides eligibility or medical necessity.
• Ranking is explainable. A supervisor can see why a patient ranks where they do.
• Closure means completion. Items close on completed care, not on a logged call. A reached patient is not a finished item, which is the point of why contact status does not prove completed care.
• Results are measured honestly. Care completed after detection is compared with a baseline and reported as correlation with outreach, not proof of cause.

Why can't a dashboard or an engagement tool produce these examples?

A dashboard could show that referral conversion dropped last quarter, but not that the patient in example 2 needs a call today. Dashboards count; these examples name a patient and a task. The difference is covered in EHR analytics vs. revenue leakage intelligence.

An engagement tool could send the message in examples 1, 2 and 4 once someone decides who should get it. It would not, on its own, know that example 3 probably needs no call, or that example 4's canceled visit put the patient back on the list. Engagement executes; the opportunity view decides who needs outreach and checks whether care followed.

How does Nuvory produce these examples?

Nuvory, a HealthArc product, builds this view every night from the EHR, adds claims or HIE evidence where an organization connects it, and ranks each patient's open items by estimated value, urgency and confidence, with one owner per patient. More reading on the data side is in EHR & data intelligence.

Frequently asked questions

Is patient opportunity intelligence the same as population health management?

They overlap but are not the same. Population health tools usually focus on quality measures and risk across a panel. Patient opportunity intelligence focuses on operational follow-through: specific referrals, orders, recalls and cancellations that did not become completed care, ranked for the staff who can act on them today.

Does patient opportunity intelligence decide what care a patient needs?

No. It works from orders, referrals, recalls and intervals that clinicians already set. Rules are signed off by a clinical reviewer, and any care management candidate is routed to clinician review. Clinicians make every clinical decision.

Can a practice build these examples with EHR reports and spreadsheets?

Partly. Many practices start that way. The hard parts are removing booked patients nightly, combining items per patient, ranking consistently and closing items only when care is completed. Those steps are tedious to repeat by hand and tend to drift as staff change.

What data does it need to start?

Usually orders, referrals, recalls or care-plan intervals, appointments, and completed encounters and procedures, read from the EHR through standard routes such as FHIR R4 and bulk data export. Claims and health information exchange feeds are optional extras that make it easier to confirm care completed at another facility, as in the third example.

Why show one row per patient instead of one row per order or recall?

Because the patient is who staff call. When each order, referral and recall sits on its own list, the same patient can get several calls from several people in one week, while an upcoming visit that could handle everything goes unused. One row per patient, with one owner, avoids both.