Good Faith Estimate Software: How to Build Patient Cost Estimates That Hold Up Against the EOB

A Good Faith Estimate is the written estimate of expected charges that the No Surprises Act requires providers to give uninsured and self-pay patients before scheduled care, or on request. The rule sets deadlines measured in business days, a list of required contents, and a dispute right when the final bill exceeds the estimate by $400 or more. For insured patients the estimate problem is different: what the patient will owe depends on the payer's adjudication, so a useful estimate has to model benefits and then be measured against the explanation of benefits. This guide covers both, for software teams building Good Faith Estimate software and patient cost estimators into EHR and practice management products.

We draw on the patient responsibility estimator we built for a multi-clinic behavioral health platform, where estimates appear at booking, in the claim builder and in the client's billing view. The regulatory sections come from the federal rules themselves; this is engineering guidance, not legal advice.

Good Faith Estimate requirements in brief

The requirements for uninsured and self-pay individuals are in 45 CFR 149.610. The provider or facility that schedules the primary service, called the convening provider, is responsible for the estimate, including items from co-providers where applicable.

The estimate must include, among other items: the patient's name and date of birth; a description of the primary service; an itemized list of items and services expected with the primary service, by provider or facility; the applicable diagnosis and service codes with expected charges; provider identifiers and locations; and disclaimers explaining that it is an estimate, that the patient may dispute a bill substantially above it, and that it is not a contract. Estimates must be kept in the same manner as medical records, and copies of estimates issued within the last six years must be available on request.

Under 45 CFR 149.620, a bill is substantially in excess when it is at least $400 more than the total expected charges on the estimate, and the patient has 120 calendar days from receiving the initial bill to start patient-provider dispute resolution.

For insured patients, the statute also calls for a GFE sent to the plan and an advanced explanation of benefits from the plan. CMS has said enforcement of those requirements is deferred pending further rulemaking on the data exchange between providers and payers; its progress report on AEOB rulemaking describes where that stands. Build so the insured flow can be added, but check the current status before you ship anything that depends on it. CMS keeps an overview of No Surprises Act rules and fact sheets that is the right place to confirm it.

Why this is a product opportunity, not just a compliance box

Behavioral health, therapy and other outpatient specialties see a lot of self-pay care, and every self-pay booking can trigger an estimate. Practices that produce them by hand in a word processor miss deadlines, lose copies and cannot show what they sent. That is a compliance risk for the practice and a feature gap for the software they use.

For insured patients the value is financial. A patient who knows their likely cost before the visit is easier to collect from at the time of service, and has less reason to dispute afterwards. The front desk stops guessing copays. The billing team stops chasing balances that surprise the client. For a vendor, a trustworthy estimate at booking is one of the few billing features patients and front-desk staff both see, and it connects directly to collections, which we discuss in our guide to patient payments and revenue leakage.

There is also an evidence argument. When a patient disputes a bill, or a regulator asks how estimates are handled, the practice needs to show the exact estimate issued, when it was issued, how it was delivered and how it compared with the bill. A product that stores all four automatically turns that question from a scramble through shared drives into a report, which is a concrete reason for a practice to choose it.

The uninsured and self-pay flow: a regulated document

For self-pay patients, the Good Faith Estimate is a document with deadlines, so the system needs a workflow around it:

1. Trigger on scheduling or request. When a self-pay appointment is booked, or a patient asks, create an estimate task with a due date computed in business days from the scheduling or request date.
2. Price from the practice's self-pay fee schedule. Use the charges the practice will actually bill, per service code, including expected add-on items.
3. Collect co-provider items where another provider or facility is part of the care, with their identifiers.
4. Render the required contents and disclaimers from a template that compliance owns, so wording changes do not need a release.
5. Deliver and record delivery in the patient's preferred format, and store the exact issued document as part of the record.
6. Compare with the final bill. When charges post, compare them to the estimate and flag any bill $400 or more above it before it goes out.

Two details catch teams out. Business days are not calendar days, so the due-date calculation needs the practice's holidays. And the issued estimate is immutable: if the plan of care changes, issue a new estimate and keep the old one.

The insured flow: a patient cost estimator

For insured patients, what the patient owes depends on the plan: copay, coinsurance, deductible remaining, limits, and whether the service is covered at all. A patient cost estimator models that. Ours resolves an estimate in a fixed order:

Step five is the one most estimators skip. Coinsurance means nothing without an allowed amount, and a deductible estimate means nothing if you do not know how much has been met. Our estimator returns a "needs review" result in those cases, and on staff-facing screens that creates a review hold, rather than showing the patient a number nobody can stand behind. Eligibility data is the main input to steps two and four; our guide to automating eligibility verification covers how to get it reliably.

The estimate must always yield to the actual

An estimate is made before the payer decides. The 835 remittance is the payer's decision. Our rule, enforced in code: when adjudication exists, the actual always wins, and the estimate is never written into a balance, an EOB or a ledger record. The client's billing view shows both, clearly labeled, side by side: the pre-visit estimate and the payer's breakdown.

Keeping both has three uses. The client can see why their bill differs from what they were told. The practice can see which benefit rules produce estimates that drift from reality, and fix them. And when the estimate and the remittance conflict on a surface that staff act on, the system records a review item instead of letting one silently override the other.

Configurable benefit rules, and the data clinics really type

Benefit rules are maintained by clinic staff, not engineers: "for this plan, psychotherapy has a flat copay", "this plan covers telehealth at the same rate". That makes rule governance part of the estimator:

• A rule with no benefit values is refused.
• Two active rules over the same criteria, at the same priority, with overlapping effective dates are refused, because they could never be resolved. Deliberate overlaps use different priorities.
• Every change is audit logged per field, with user, time, old and new values, effective date and reason.
• Deactivating a rule stops it feeding new estimates, and leaves existing review holds and adjudicated records untouched.

The lesson we did not expect: what staff type into free-text criteria is not what a naive match accepts. We found rules whose service-code filter was the word "any", meaning no filter; a code prefix typed in quotation marks; and plan names entered as "Plan A OR Plan B" or as a comma-separated list. Each silently matched nothing, so the rule never applied and every visit fell through to review. We normalize those patterns at evaluation time, so existing rules started working without anyone re-entering them.

A benefit rule data model that works

The estimator is only as good as the rules behind it. The model we use keeps criteria, values and governance separate:

Telehealth deserves its own criterion. Place of service 02 and 10 identify telehealth on professional claims, and many plans pay telehealth differently from in-person care, so a rule that ignores modality will be wrong for a large share of visits in behavioral health.

Edge cases to design for

• Secondary coverage. The primary's estimate is only the first step; model what the secondary pays on the remainder, or route to review.
• Deductible resets. Estimates for January visits made in December need the new plan year's deductible, which the last eligibility response may not show.
• Visit limits. A plan that covers a fixed number of sessions per year turns the next visit into self-pay; count visits against the limit, including those at other practices when the payer reports them.
• Medicaid and no-collection plans. These override every rule. Our estimator checks them first, and the same guard stops collection attempts elsewhere in the product.
• Sliding-fee and discount programs. A self-pay estimate must use the price the patient will actually be charged, including any discount program the practice applies.

Each of those is a place where a confident number would be wrong. The estimator should know which inputs it is missing and say so. Remittance data is what tells you which edge cases matter most in your own mix; our guide to why claims get denied shows how coverage gaps surface on the 835, and our X12 developer guide covers the 271 benefit segments the estimator reads.

Presenting the estimate to patients

An accurate estimate that confuses the patient still fails. A few presentation rules make estimates useful at the front desk and in the portal:

• Label it as an estimate, every time, with the date it was made and the coverage information it used.
• Show what is included and what is not. For a self-pay GFE the regulation prescribes this; for insured estimates it prevents the most common complaint.
• Prefer a clear "we need to confirm" over a guess. When the estimator returns review, the patient-facing view should say the practice will confirm the amount, not show zero.
• Give the next step. Pay now, pay at the visit, or contact billing, with the amount the practice expects to collect at the time of service.
• Keep history visible. If the estimate changes because coverage changed, show both versions and why.

Staff screens need the opposite level of detail: which rule matched, which eligibility response supplied which value, and why a result went to review. That transparency is what lets billing staff fix rules instead of overriding numbers by hand.

What we learned

1. Estimates need an honest "I don't know". Review beats a confident wrong number, for the patient and for the practice.
2. Legal prohibitions go first. A plan where the client must not be charged overrides every rule.
3. Never overwrite the estimate with the actual, or the reverse. Both are records, and the gap between them is your quality metric.
4. Clinic-entered rules need validation and normalization, or they fail silently.
5. Keep the estimator pure. Ours has no side effects; separate code decides whether a result creates a review hold, so read-only screens never write anything.

Good Faith Estimate software checklist

1. Self-pay estimate tasks triggered on scheduling and on request, with business-day due dates and a holiday calendar.
2. Pricing from the self-pay fee schedule, including co-provider items.
3. A compliance-owned template with all required contents and disclaimers.
4. Delivery records and immutable storage of each issued estimate, retained with the medical record.
5. Automatic comparison of final charges with the estimate, flagging overages of $400 or more.
6. For insured patients, a benefit-rule estimator with a fixed resolution order.
7. Eligibility (271) data feeding missing values.
8. "Needs review" for unsafe inputs, with review holds on staff surfaces.
9. Estimate and adjudicated actual shown side by side; the actual always wins.
10. Rule validation, conflict detection, audit logging and input normalization.

Related guides: how to read an ERA explains the adjudicated side, and our posts on claim scrubbers and rendering vs billing provider cover the claim side of the same platform.