EHR for FQHC

What makes an EHR fit an FQHC?

An EHR fits an FQHC when it captures the data HRSA's Uniform Data System asks for, bills Medicare encounters with the FQHC PPS payment codes, applies the health center's sliding fee discount schedule from verified income and family size, and gives the 340B program a clean record of which prescriptions belong to health center patients.

Each of those duties starts at the front desk. Income, family size, insurance, housing status and language are collected at registration, and every later report, claim and discount depends on them being current. A record built for a private practice often treats these as optional demographics.

The clinical side looks familiar: problem lists, immunizations, chronic disease follow-up and behavioral health. The difference is that the same encounter feeds a federal grant report, a cost-based payment system and a drug pricing program.

Which record data feeds UDS reporting?

Nearly every UDS table is built from registration fields, encounter records and clinical quality measures held in the EHR. HRSA's UDS guidance gives 15 February as the deadline for the full annual report covering the previous calendar year, submitted through HRSA's Electronic Handbooks.

• Patients by ZIP code and Tables 3A and 3B: age, sex, race, ethnicity and preferred language, counted once per patient per year.
• Table 4: income as a percentage of the federal poverty guidelines, insurance source and special populations such as agricultural workers, people experiencing homelessness and veterans.
• Tables 6A and 6B: diagnoses, services and quality of care measures, which depend on coded diagnoses and procedures rather than note text.
• Table 7: health outcomes measures, such as blood pressure and diabetes control, which depend on discrete vitals and lab results.

Visit counts need the same structure. UDS reports staffing and utilization by service category, so each encounter must carry the rendering clinician's discipline and the type of service, not only a provider name on a note.

HRSA's UDS Modernization work adds UDS+, a de-identified patient-level submission for those same tables sent through FHIR R4 APIs using the UDS+ FHIR Implementation Guide. HRSA has postponed at least one additional UDS+ submission, so check its UDS Modernization page for the current cycle before planning the build.

The engineering lesson is that a UDS report is only as good as the registration data behind it. A health center that cannot say when each patient's income was last verified ends up reconciling Table 4 by hand before the deadline.

How does encounter billing work under the FQHC PPS?

Medicare pays FQHCs a per-visit rate under the FQHC prospective payment system, so the record must turn each qualifying visit into an encounter claim rather than a line-by-line fee claim. CMS requires an FQHC payment code on every encounter billed on a 77X type of bill.

• G0466: medical visit for a new patient, meaning a patient with no professional service from the FQHC or any of its sites within the past three years.
• G0467: medical visit for an established patient.
• G0468: visit that includes an initial preventive physical examination or an annual wellness visit.
• G0469 and G0470: mental health visits for new and established patients.

CMS compares the adjusted PPS rate with the charges reported on the payment code line, so the charge master and code mapping matter. A medical visit and a mental health visit on the same day are reported with separate payment codes.

The PPS rate is adjusted for geography and for visits that involve a new patient, an initial preventive physical examination or an annual wellness visit. The charge capture screen should therefore know which visit type it is producing before the clinician signs.

Medicaid works differently. State Medicaid programs pay FQHCs under a prospective payment system or an approved alternative method under section 1902(bb) of the Social Security Act, and when a Medicaid managed care plan pays less than that rate, the state makes a supplemental payment for the difference. The billing engine needs payer-specific rules, not one encounter template.

How should sliding fee logic work in the record?

Sliding fee logic should compute a patient's discount class from verified income and family size, store the evidence and its date, and apply the class to every charge the patient owes. The rules come from the Health Center Program and its regulations.

• Full discount: patients with annual income at or below 100 percent of the current federal poverty guidelines receive a full discount, unless the center sets a nominal charge, according to HRSA's Health Center Program Compliance Manual (Chapter 9).
• Partial discounts: patients above 100 percent and at or below 200 percent receive discounts that step with income, in at least three discount pay classes.
• No discount: patients above 200 percent of the poverty guidelines receive no sliding fee discount, consistent with 42 CFR 51c.303(f).
• Insured patients: an eligible patient with third-party coverage is charged no more out of pocket than their discount pay class would allow.
• Ability to pay: no one may be denied service because of inability to pay (42 CFR 51c.303(u)).

Two build details cause most trouble. The poverty guideline table changes every year, so the schedule must be versioned by effective date. And the discount must apply to the patient's share after insurance, which means the billing engine and the sliding fee module have to agree on the order of operations.

Re-screening frequency is a policy the health center sets, not a single federal number. The system should let administrators record that policy and flag every patient whose income evidence is older than it allows.

Where does 340B touch the EHR?

The EHR supplies the evidence that a 340B prescription went to a health center patient. FQHCs are covered entities under section 340B(a)(4)(A) of the Public Health Service Act, and the program's two main compliance risks both depend on record data.

• Diversion: a covered entity may not resell or transfer a 340B drug to a person who is not its patient (42 U.S.C. 256b(a)(5)(B)). The encounter, the prescriber and the site of care show the patient relationship.
• Duplicate discounts: a covered entity may not receive a 340B price and also let the state collect a Medicaid rebate on the same drug (256b(a)(5)(A)), so payer status on the prescription must be accurate.
• Audits: HRSA and manufacturers may audit records that pertain to those rules (256b(a)(5)(C)), which makes prescription and encounter history evidence.

Contract pharmacies and third-party administrators usually match dispensed claims against an extract from the EHR. That extract should carry the encounter date, rendering prescriber, location and payer, and it should be reproducible for any past date an auditor names.

Location data matters as well. Each location in the EHR should map to a site the center has registered in HRSA's 340B Office of Pharmacy Affairs Information System, so an extract can show where each prescription was written.

A pre-selection checklist for health centers

• UDS output: can the system produce each UDS table from discrete data, and does its vendor have a stated plan for UDS+ FHIR submissions?
• Encounter rules: does billing support FQHC payment codes on a 77X claim, same-day medical and mental health visits, and state Medicaid PPS rules?
• Sliding fee module: are discount classes versioned by poverty guideline year, and is income evidence stored with its verification date?
• 340B extract: can the system export encounters, prescribers, sites and payer status for the 340B administrator on a schedule?
• Enabling services: can staff record case management, translation and transportation help that the center reports?
• Interfaces: are lab, immunization registry, health information exchange and pharmacy interfaces included, and in which HL7 v2 or FHIR form?
• Certification: is the product on the Certified Health IT Product List, certified to the criteria the center's quality programs require?

Ask each vendor to run the checklist on a test patient in a live demonstration rather than answer it on paper.

Where FQHC implementations break

• Income captured once: the discount class stays fixed after a job change, and the UDS income table drifts from reality.
• Encounter logic copied from fee-for-service: claims go out without the FQHC payment code and return unpaid.
• Payer status updated late: a Medicaid prescription is filled at a 340B price, and the duplicate discount risk is found at audit.
• Quality measures built on free text: blood pressure or A1c values typed into notes never reach the outcome tables.
• Multiple sites, one location code: the 340B extract cannot prove which registered site served the patient.

How Agnotic can help

Health centers rarely need a new EHR to fix these problems. They need the data between systems to line up. Agnotic Technologies builds the connecting work for the client: UDS extracts and validation reports, FHIR exports for UDS+, encounter billing rules, versioned sliding fee logic and the 340B data feeds administrators match against.

Where a center is choosing a new system, Agnotic can turn the checklist above into scripted test cases and build the interfaces the chosen EHR does not include.

Sources

• HRSA Health Center Program Compliance Manual, Chapter 9: Sliding Fee Discount Program
• 42 CFR 51c.303: Project elements, community health centers
• HRSA: UDS Modernization Frequently Asked Questions
• CMS: FQHC PPS specific payment codes
• CMS Medicare Claims Processing Manual, Chapter 9: RHCs and FQHCs
• 42 U.S.C. 256b: 340B drug pricing program