athenahealth vs CureMD for FQHC Sliding-Fee Data, 2026

athenahealth can store poverty-based and non-poverty-based sliding-fee plans and, if enabled, pick a plan from family size and income against HHS poverty guidelines. CureMD publishes automatic sliding-fee eligibility and co-pay calculation at arrival. Neither vendor page opened September 1, 2026 published a numbered intake that files income proof in the EHR before the visit. Keep athenahealth as the system of record; this page is the data-collection job, not an EHR replacement.

Key Takeaways

• Sliding Fee Programs is on for all FQHCs by default, and the income-level notification threshold is 200 percent for all FQHCs by default, on the athenahealth help page opened September 1, 2026 (last updated 28 August 2026).

• Basic sliding fee adjusts when the claim is created; post-adjudication waits until payer adjudication and needs written authorization plus a Technical Request and Waiver Form — do not turn that mode on from a blog post.

• The missing piece is nine numbered intake steps that collect family size, income, and proof of income before the visit, then let athenahealth calculate the plan.

• CureMD’s FQHC page opened September 1, 2026 publishes auto eligibility, co-pays at arrival, household-assessment renewal notices, and adjustments even when primary insurance exists; public list price is UNKNOWN.

• Public list prices for both EHRs are UNKNOWN on the pages opened; federal poverty guideline dollars are UNKNOWN here; do not invent UDS rates or promise a HRSA audit outcome.

• Pilot one department, new self-pay and sliding-fee patients only, for two weeks, with post-adjudication left off; kill the pilot if front desk still uses a paper calculator after the plan exists in athenahealth.

Who this page is for

Revenue-cycle and front-desk leads at FQHCs and community health centers already on athenahealth still collect sliding-fee income and household size on paper, then type a discount into the visit after the patient is in the chair.

The legal duty is not optional. HRSA-funded centers must run a sliding-fee schedule, and that duty traces to section 330 of the Public Health Service Act, 42 USC 254b, according to Cornell Law School, which is the same statute athenahealth’s sliding-fee help cites.

This is not a rip-and-replace guide. If the center wants to leave athenahealth, stop here. If the center wants post-adjudication turned on as the first move, stop here and call the customer success manager instead.

Red flags: a spreadsheet of poverty cutoffs that does not match the ranges in athenahealth; a paper calculator at checkout after a plan already exists on the account; a request to “just enable post-adjudication” without a signed waiver; any dollar figure for HHS poverty guidelines invented in a meeting because nobody opened ASPE.

Who this is not for: a hospital-owned clinic whose sliding-fee policy is owned by a parent compliance office that has already banned local plan edits; a private practice that is not a section 330-funded center and is shopping for a courtesy discount; a center whose inbound request is “migrate us off athenahealth.” Those are different jobs.

The originating health-center enquiry is treated as private research context. No person, email, or company is named here as a customer or case study. Examples in this article are hypothetical or composite.

How we evaluated

We scored the two named products only on the sliding-fee data job: can the EHR store the plan, can it pick a plan from family size and income, what does post-adjudication actually require, and what still has to happen at registration.

Weights below are a transparent rubric for this page, not a purchased benchmark. Vendor pages were opened September 1, 2026. Where a public number was missing we wrote UNKNOWN.

A center that already paid for athenahealth does not need a second EHR to collect income. It needs a registration flow that feeds the plans athenahealth already knows how to calculate.

For the wider operations stack around the visit — reviews, recalls, and result notices — see reputation software for medical practices, patient follow-up automation, and the healthcare automation benchmark report.

Direct answer

athenahealth Sliding Fee Programs can hold poverty-based plans and non-poverty-based plans. When the feature is enabled, the EHR can select a plan from family size and income against HHS poverty guidelines. CureMD’s FQHC page says the product can automatically determine sliding-fee eligibility, determine co-pays at arrival, auto-notify when the Household Assessment must be renewed, and auto-compute sliding-fee adjustments even when primary insurance exists.

The income-level notification threshold is 200 percent for all FQHCs by default according to athenahealth help opened September 1, 2026 and last updated 28 August 2026, and Sliding Fee Programs is on for all FQHCs by default on that same page.

What neither page published on that date is the numbered intake: who asks for household size, who stores proof of income, when the patient sees the nominal fee, and what happens when the plan expires. That is the job on this page.

Do not treat CureMD as a reason to rip out athenahealth. Treat it as a feature matrix so a center can see what athenahealth already does versus what still needs an intake flow.

What post-adjudication mode actually requires

Basic sliding fee and post-adjudication sliding fee are not the same switch. Basic sliding fee adjusts when the claim is created. Post-adjudication waits until the payer has adjudicated, then applies the sliding-fee adjustment.

athenahealth help is explicit that Post-Adjudication Sliding Fees needs written authorization and a Technical Request and Waiver Form because misuse has compliance implications. This article does not tell a center to turn that mode on.

A hypothetical composite: a front-desk supervisor sees “post-adjudication” in a settings menu and assumes it is a cleaner way to wait for Medicaid. That is exactly the path the waiver exists to stop. Misuse has compliance implications; the help page says so; a blog post is not a CSM.

Leave post-adjudication off for the two-week pilot described below. If the center later wants it, that is a signed-waiver conversation with athenahealth, not a workflow toggle.

Billing staff sometimes want post-adjudication because the payer’s allowed amount is the number they trust. That instinct is understandable and still not a reason to flip the mode from a public article. Basic sliding fee writes the adjustment when the claim is created, which is the mode the two-week pilot uses. Post-adjudication waits, then adjusts, and the vendor’s own help treats that wait as a compliance-sensitive exception.

If a payer later recoups a sliding-fee claim, the center will be asked what the actual charge was. That is the same “actual” charge problem the help page flags. Keep the nominal fee, the plan, and the proof of income aligned in athenahealth before anyone debates adjudication timing.

Numbered sliding-fee data collection on athenahealth

The EHR can calculate a plan only after registration has the inputs. Skip proof of income and you have a discount with no file. Invent a self-attestation rule in a blog post and you have overridden the center’s own sliding-fee policy. Point at that policy; do not rewrite it here.

US Tech Automations routes intake family-size and income into the athenahealth registration step and flags a missing proof-of-income document before the visit.

Step 1 is a confirmation, not a project. On the help page opened September 1, 2026, Sliding Fee Programs is already on for all FQHCs by default. If a clinic turned it off, turn it back on with the center’s own change control, then continue.

Step 2 splits poverty-based programs from non-poverty-based programs because athenahealth recommends that split. Mixing them in one list is how a non-poverty discount overwrites a poverty plan.

Step 3 is where paper calculators usually hide. Enter the poverty level ranges with no gaps. Do not type HHS poverty guideline dollars into this article; those dollars are UNKNOWN here. Open HHS ASPE on the writing date, or write UNKNOWN, according to HHS ASPE as the public poverty-guideline publisher — this writing pass does not invent a federal poverty line dollar.

Step 4 is registration, not checkout. Collect family size and income before the visit so the plan exists on the account when the patient arrives.

A hypothetical composite registration desk still hands the patient a clipboard in the waiting room and types household size during rooming. That is too late for a plan that is supposed to exist before the visit. Move the two fields into pre-visit registration: phone, portal, or a front-desk script before check-in. If the patient cannot complete the fields, park the visit in a hold queue rather than inventing a household size so the schedule stays full.

Step 5 stores proof of income. Do not skip it. Do not invent a self-attestation shortcut. If the center’s own sliding-fee policy allows a signed attestation in a defined case, follow that policy; this page does not create a new one.

Proof of income is a file, not a checkbox. Pay stub, benefit letter, or whatever the center’s policy lists should sit on the account next to family size. A signed “I have no income” line is only valid if that same policy says it is. Do not copy another center’s attestation language into athenahealth because it looked faster.

Step 6 is the EHR’s job. Let athenahealth calculate the plan from family size and income against the ranges you entered. Front desk should not re-run a paper percentage after the plan exists.

Step 7 shows the patient the nominal fee before the visit. A fee announced after the exam is how disputes start.

The default expiration warning is 30 days according to athenahealth help opened September 1, 2026, which is why step 8 re-verifies instead of letting a stale plan ride.

Step 9 reports from Report Builder sliding-fee fields. If the only report is a spreadsheet on a shared drive, the EHR is not the system of record yet.

US Tech Automations queues that 30-day re-verification and monitors the expiration warning so a plan does not silently lapse while front desk still trusts last year’s paper card.

CureMD comparison, dated

CureMD is in this article so a center can see a published FQHC auto-adjustment next to athenahealth’s published sliding-fee setup. It is not a migration pitch.

CureMD’s FQHC page, opened September 1, 2026, says the product can automatically determine sliding-fee eligibility, determine co-pays at arrival, auto-notify when the Household Assessment must be renewed, and auto-compute sliding-fee adjustments even when primary insurance exists, according to CureMD. Public list price on that page: UNKNOWN.

Read those claims as vendor copy from that date, not as an independent time-and-motion study. The useful comparison is which of those jobs athenahealth already covers when Sliding Fee Programs is on, and which jobs still need the numbered intake above.

If a center is already on CureMD, this page is the wrong page. If a center is on athenahealth and someone is waving a CureMD screenshot in a meeting, use the feature matrix rather than a rip-and-replace argument.

Dated comparison rules for this section: quote only what the CureMD FQHC page published on September 1, 2026; write UNKNOWN for list price; do not import a third-party “CureMD vs athenahealth” score; do not invent a UDS submission rate for either product. Auto-notify on household assessment renewal is a vendor-published behavior, not proof that a named center’s front desk stopped using paper.

The arrival-time co-pay claim is the closest CureMD analogue to step 7 on athenahealth (show the nominal fee before the visit). If athenahealth already displays that fee once the plan exists, the CureMD screenshot is not new information. The remaining work is still steps 4 and 5: family size, income, and proof of income in the record before the patient is called.

Feature matrix and the limitation both vendors leave open

The limitation both pages leave open is the same: a plan engine without a numbered intake still leaves income proof on paper. Buying a second EHR does not fix a registration desk that never files the document.

Sliding-fee is also a charge-representation problem, not only a discount problem. Practices must represent charges accurately, including sliding-fee charges, and there is a long history of misrepresenting the “actual” charge — that is the athenahealth help sentence, and it belongs in the article, not in a footnote.

A sliding-fee schedule is a HRSA program requirement for section 330-funded centers, not a local courtesy discount, according to HRSA (checked September 1, 2026), which is why a paper calculator after the plan exists is an operations failure, not a style choice.

Pricing and TCO

Contact the vendor for a quote. A blog post that invents EHR list prices is worse than UNKNOWN.

Do not reuse TCO figures from older posts. Do not invent UDS submission rates. Do not promise that a cleaner intake will pass a HRSA site visit.

Review traffic after the visit is a different job; automated reputation management for medical practices covers that rail, and lab result notification automation covers result notices — neither replaces sliding-fee proof of income.

Two-week pilot

Run the smallest test that proves the plan exists before the visit.

Do not touch post-adjudication mode in the pilot. Do not onboard the whole health center in week one. Do not change poverty ranges mid-pilot unless the center’s written policy changed.

Success is a plan on the account before the visit. Kill the pilot if front desk still uses a paper calculator after that plan exists in athenahealth. A second calculator means the EHR is not trusted, and more training on a dead flow will not fix it.

US Tech Automations connects the stored proof file to the encounter and reconciles Report Builder sliding-fee fields after the visit so the pilot does not end in a shadow spreadsheet.

When the remap of ranges, the proof-of-income file, and the pre-visit fee display are working in that one department, configure the same intake on US Tech Automations. That homepage link is the product path for the numbered steps; it is not a claim that a named health center is a customer.

When not to use this playbook

Do not use this page to migrate off athenahealth. Do not use it to enable post-adjudication. Do not use it to invent federal poverty guideline dollars. Do not use it as a UDS filing guide.

If the center will not store proof of income, stop. If the only “policy” is a laminated card at checkout, write the sliding-fee policy first, then come back to step 3.

If someone wants a full-center go-live in one weekend, that is not this pilot. One department, two weeks, new sliding-fee patients only.

A DIY no-code form that emails a PDF to the billing inbox is not this playbook either. Email is not an athenahealth plan. If a person still opens the PDF and types household size into the EHR, the numbered intake did not run. Build the nine steps against the registration fields and Report Builder, or do not call the project connected.

When the only tool on the desk is a laminated poverty card, write the sliding-fee policy, enter the ranges with no gaps, and store proof of income. Software cannot honest-up a discount that the record does not support. Practices must represent charges accurately, including sliding-fee charges; repeating that sentence is cheaper than explaining an inflated “actual” charge later.

Frequently Asked Questions

Does athenahealth already run sliding-fee plans for FQHCs?

Yes. Sliding Fee Programs is on for all FQHCs by default on the help page opened September 1, 2026, last updated 28 August 2026, and the default income-level notification threshold is 200 percent. The EHR can store poverty-based and non-poverty-based plans and, if enabled, pick a plan from family size and income. The gap is collecting those inputs, plus proof of income, before the visit.

Should we turn on post-adjudication sliding fees from this article?

No. Post-adjudication waits until payer adjudication, unlike basic sliding fee, which adjusts when the claim is created. athenahealth help requires written authorization and a Technical Request and Waiver Form because misuse has compliance implications. Leave the mode off in the two-week pilot. If the center still wants it later, that is a CSM and waiver conversation.

Do we need to replace athenahealth with CureMD to automate sliding-fee discounts?

No. CureMD’s FQHC page publishes auto eligibility, co-pays at arrival, household-assessment renewal notices, and adjustments even when primary insurance exists. That is a dated feature contrast, not a migration case. If you already run athenahealth, collect income and household data into that EHR. Public prices for both products are UNKNOWN on the pages opened September 1, 2026.

What poverty guideline dollars should we type into the ranges?

UNKNOWN in this article. Open the HHS ASPE poverty-guidelines page on the day you enter ranges, or write UNKNOWN until someone does. Do not invent a federal poverty line dollar in a meeting. Enter the center’s own policy ranges with no gaps, and keep proof of income on file per that policy, not per a blog attestation rule.

How do we know the two-week pilot worked?

Success is a sliding-fee plan on the account before the visit for new self-pay and sliding-fee patients in one department. Kill the pilot if front desk still uses a paper calculator after that plan exists. Leave post-adjudication off. Report from Report Builder sliding-fee fields, not from a side spreadsheet.

Can we skip proof of income if the patient signs a form at the window?

Only if the center’s own written sliding-fee policy says so. This page does not invent a self-attestation rule. Step 5 is store proof of income. Skipping the file is how a discount becomes an undocumented write-off, and athenahealth help already warns there is a long history of misrepresenting the actual charge.