OpenEMR ClaimRev Connect Module

The ClaimRev Connect module integrates ClaimRev's clearinghouse services directly into OpenEMR, giving practices access to claims processing, eligibility verification, ERA downloads, payment posting, reconciliation, patient balance management, and analytics — all without leaving their EHR.

1. Download and Installation
2. Configuration
3. Features
   1. Dashboard (Home)
   2. Claims Submission
   3. Claims Tab
   4. Payment Advice
   5. Reconciliation
   6. Patient Balance
   7. Claim Status
   8. AR Aging Report
   9. Denial Analytics
   10. Recoupment Report
   11. Eligibility Verification
   12. ERA Downloads
   13. X12 Tracker
   14. Appointments
   15. Calendar Eligibility Indicators
   16. Eligibility Sweep
   17. Notifications
4. Compatibility
5. Troubleshooting
6. Support

—

• OpenEMR 7.0.0 or later (8.x recommended)
• PHP 8.2 or later
• An active ClaimRev account with API credentials

The ClaimRev Connect module is published on Packagist as claimrevolution/oe-module-claimrev-connect. Starting with v2.1.3 a single build runs on both OpenEMR 7.x and OpenEMR 8.x — runtime compatibility shims in src/Compat/ activate only when the host core lacks the newer APIs. Pick the install method that matches your environment.

Current Version: 2.1.3

If you have CLI access to your OpenEMR install:

cd /path/to/openemr
composer require claimrevolution/oe-module-claimrev-connect:^2.1
sudo systemctl reload php-fpm   # or restart Apache

Composer downloads the latest v2.1.x release, drops it into interface/modules/custom_modules/oe-module-claimrev-connect/, and updates the autoloader. Continue with Activation below.

To update the module later:

composer update claimrevolution/oe-module-claimrev-connect
sudo systemctl reload php-fpm

OpenEMR's Manage Modules page does not have a zip-upload feature for custom modules — it scans interface/modules/custom_modules/ on every page load and lists whatever directories it finds. For installs without CLI access (shared hosting, restricted environments), drop the files into place via SFTP/FTP:

1. Download the current release zip from the GitHub releases page.
2. Unzip it locally. You should see a folder named oe-module-claimrev-connect/ containing composer.json, info.txt, src/, public/, templates/, etc.
3. Connect to your OpenEMR server with SFTP, FTP, or your hosting control panel's file manager.
4. Upload the entire oe-module-claimrev-connect/ folder into interface/modules/custom_modules/ so the resulting path is interface/modules/custom_modules/oe-module-claimrev-connect/composer.json (and so on for the other files).
5. Continue with Activation below — OpenEMR will see the new directory on the next page load.

Note: Updates with this method are the same flow — replace the contents of the oe-module-claimrev-connect/ folder with the contents of the new zip. Method 1 (Composer) is much easier if you have any way to run shell commands on the server.

If you installed OpenEMR via an official release tarball that already bundles claimrevolution/oe-module-claimrev-connect in its composer.json, the module arrives pre-extracted at interface/modules/custom_modules/oe-module-claimrev-connect/. No additional download step.

1. In OpenEMR, navigate to Modules > Manage Modules.
2. Find ClaimRev Connect in the module list. Click Install, then Enable.
3. Navigate to ClaimRev Connect > Setup and click Run Upgrade to create the required database tables.

Note: If you do not yet have a ClaimRev account, visit claimrev.com or contact us at sales@claimrev.com to get started.

—

After enabling the module, you need to configure your ClaimRev API credentials.

1. Navigate to Admin > Config > Connectors.
2. Scroll to the ClaimRev Settings section.
3. Enter the following values provided by ClaimRev:
   • Client ID - Your ClaimRev API client ID
   • Client Secret - Your ClaimRev API client secret
   • API Server - The ClaimRev API endpoint URL
   • Client Authority - The OAuth token endpoint
   • Client Scope - The API scope (typically provided by ClaimRev)
4. Click Save to store your settings.

Tip: To verify your connection, navigate to the ClaimRev module and click the Connectivity tab for a connection status check. Contact ClaimRev support if you need your API credentials.

—

The Home tab is a KPI dashboard that gives billers a one-glance overview of the entire revenue cycle. It refreshes every time you open the module.

• Claims In Flight — Encounters billed and awaiting payer response
• Pending ERAs — ERAs received from ClaimRev but not yet posted to OpenEMR
• Rejected / Denied — Claims denied in the last 90 days
• Clean Claim Rate — Percentage of claims accepted on first pass (90-day window). Color-coded: green (≥95%), yellow (90-94%), red (<90%)

• Total AR — Sum of all outstanding balances, with the amount over 90 days shown below
• Avg Days in AR — Average age of outstanding balances. Color-coded: green (≤35 days), yellow (36-50), red (>50)
• Collections This Month — Total payments received this month, with last month shown for comparison
• Collections This Quarter — Quarterly total

• Denial Rate — Percentage of claims denied vs. total processed (90-day window)
• Top Adjustment Reasons — The five most common adjustment reasons from posted ERAs

• Patient AR — Total outstanding patient balances (encounters where insurance has responded)
• Need Statements — Encounters with a patient balance that have never had a statement sent

Direct links to Search Claims, Payment Advice, Reconciliation, Claim Status, and Denial Analytics.

The module enables electronic claim submission (837P/837I) to payers through ClaimRev.

• Claims are submitted from the OpenEMR billing manager
• Claim status and errors are viewable in the ClaimRev Claims tab
• Claims can be marked as worked after review
• CSV export of claim search results is available

The Claims tab provides a searchable view of claims submitted through ClaimRev, with integrated OpenEMR status tracking and actions.

Search for claims using any combination of:

• Patient name (first and/or last)
• Date range (service date or received date)
• Payer name or payer number
• Patient control number (PCN) — format is pid-encounter
• Claim status (e.g., Accepted, Rejected, Pending)
• Billing provider NPI

Each claim row displays the OpenEMR claim status alongside the ClaimRev status. This lets you see at a glance whether the two systems agree. OpenEMR statuses include:

Each claim row provides action buttons:

• Open Encounter (folder icon, blue) — Opens the OpenEMR encounter directly in a new tab, allowing you to review charges, notes, and clinical documentation.
• Sync Status (sync icon, red) — Appears when ClaimRev shows a claim as rejected but OpenEMR still shows it as billed. Clicking this updates the OpenEMR claim status to Denied and records the rejection reason from ClaimRev in the claim's process file. This saves manual data entry when payers reject claims.
• Requeue for Billing (redo icon, yellow) — Reopens the encounter for billing so it can be corrected and resubmitted. This resets the billing flags and creates a new claim version with status Unbilled, placing it back in the billing queue.

Click on any claim row to expand it and see:

• Full ClaimRev claim details (status, payer acceptance, ERA classification)
• OpenEMR status information
• Direct link to the encounter in OpenEMR
• Link to view the claim in the ClaimRev portal

The Payment Advice tab allows you to search for ERA (835) payment advice records from ClaimRev and post them directly into OpenEMR's payment system.

1. Navigate to the Payment Advice tab.
2. Enter search criteria (date range, payer, trace number, etc.).
3. Click Search to retrieve matching payment advice records.
4. Results show the payer name, check/trace number, payment date, total paid amount, and claim count.

Click on a payment advice record to expand it. Each claim line within the ERA shows:

• Patient name and control number
• Claim status (Paid, Denied, Reversed, Pended, etc.)
• Billed amount, allowed amount, paid amount, and adjustments
• Service line details with procedure codes and amounts

Payment advice records can be posted to OpenEMR to record payments, adjustments, and denials.

1. Expand a payment advice record to see its claim lines.
2. Click Preview on an individual claim to see exactly what will be posted.
3. The preview shows the session details, payment amounts, and adjustment codes that will be created.
4. Click Post to OpenEMR to post the payment.
5. After posting, the claim line is marked with a green checkmark.

1. Click Batch Post All to post all eligible claims in a payment advice at once.
2. The system processes each claim and shows a results summary with:
   • Posted — Successfully posted claims (green)
   • Skipped — Claims that were already posted or could not be matched (gray)
   • Errors — Claims that encountered an error during posting (red)
   • Needs Approval — Reversals and pended claims that require individual review (yellow, see below)

Some claim statuses require special attention before posting:

• Reversals (CLP02=22) — These represent a takeaway of a previous payment. Posting a reversal will create a negative payment in OpenEMR. When you click Post on a reversal, a confirmation dialog explains the impact and asks for approval before proceeding.
• Pended Claims (CLP02=5) — These indicate the payer is still processing the claim. Posting records the current adjudication info, but amounts may change. A confirmation dialog warns you of this before posting.

In batch mode, reversals and pended claims are not auto-posted. Instead, they are separated into a “Needs Approval” section in the batch results, where you can review each one individually and click Approve & Post to post them one at a time.

When an ERA is posted, the following data flows into OpenEMR:

• Payments — Insurance payments are recorded in ar_session and ar_activity
• Contractual Adjustments — CO (Contractual Obligation) group adjustments reduce the balance
• Patient Responsibility Memos — PR (Patient Responsibility) adjustments are recorded as zero-dollar memos with labels like Ins1 dedbl: 150.00, Ins1 coins: 45.00, Ins1 copay: 25.00. These memos are later parsed by the Patient Balance screen to show the PR breakdown.
• Insurance Level Close — The last_level_closed flag on the encounter is updated, indicating insurance has finished processing

When the Enable Test Mode global is on (Admin > Globals > ClaimRev Connect), the Payment Advice, ERA, and Reconciliation pages return mock data generated from local OpenEMR billing rows. Useful for demos, training, and posting-workflow rehearsal without hitting the live ClaimRev API.

• Posting still writes to OpenEMR — useful when running against a development database.
• Claims are not marked as worked in ClaimRev while the global is on.
• Reconciliation row actions (Sync rejected status, Requeue) short-circuit to a fake-success response.
• ERA Download returns a 0-byte placeholder file.

Important: Only enable the global in development or training environments. The global is the only switch — there is no longer a per-search checkbox.

The Reconciliation tab provides a side-by-side comparison of OpenEMR encounters against their status in ClaimRev, helping you identify claims that may need attention.

Reconciliation answers questions like:

• “Did all my billed claims actually reach ClaimRev?”
• “Are there claims rejected in ClaimRev that I haven't updated in OpenEMR?”
• “Do I have ERAs showing payment that haven't been posted?”
• “Are there denials in the ERA that OpenEMR doesn't reflect?”

1. Navigate to the Reconciliation tab.
2. Set your search filters:
   • Date Range — Filter encounters by service date
   • OpenEMR Status — Choose from:
     • Billed — Encounters marked as billed or crossover (default)
     • Denied — Encounters marked as denied
     • All Billed — All encounters that have entered the billing process
   • Patient Name — Filter by first and/or last name
   • Payer Name — Filter by insurance company
   • Discrepancies Only — Show only encounters where the OE and ClaimRev statuses don't match
3. Click Search to run the reconciliation.

At the top of the results, four summary cards show:

• Total Encounters — Number of OpenEMR encounters matching your filters
• Found in ClaimRev — How many of those encounters were found in ClaimRev
• Not in ClaimRev — Encounters that were not found (potential submission issues)
• Discrepancies — Encounters where the OE and ClaimRev statuses disagree

The comparison table shows each encounter with columns for:

The system automatically detects five types of discrepancies:

Rows are color-coded: red for danger-level discrepancies, yellow for warnings, and gray for encounters not found in ClaimRev.

Each row provides action buttons depending on the situation:

• Open Encounter — Navigate directly to the encounter in OpenEMR
• Sync Status — Update OpenEMR to match ClaimRev's rejection status (appears for rejected claims)
• Requeue for Billing — Put the claim back in the billing queue for correction and resubmission
• View in Portal — Open the claim in the ClaimRev portal for full details

Click on any row to expand a detailed comparison showing:

• OpenEMR Info — Claim status, bill time, process file
• ClaimRev Info — Claim status, payer acceptance, worked status
• ERA Info — ERA classification, payer paid amount

The Patient Balance tab surfaces encounters with outstanding patient responsibility after insurance has responded. It helps billers identify who owes money and manage the statement workflow.

An encounter appears in the Patient Balance queue when:

• Insurance has responded (last_level_closed >= 1 on the encounter)
• There is a remaining balance after all payments and adjustments (using the same formula as OpenEMR's collections report: charges + drug sales - payments - adjustments)

• Service Date Range — Filter by encounter date
• Patient Name — Search by patient first or last name
• Payer — Filter by primary insurance company
• Min Amount — Only show balances above a threshold (default: $0.01)
• Statement Status — Filter by:
  • All — Show everything
  • Never Sent — Encounters where no statement has been sent
  • Sent 1x — Exactly one statement sent
  • Sent 2+ — Two or more statements sent
  • In Collection — Encounters marked as in collection

• Total w/ Balance — Number of encounters with outstanding patient balances
• Total Amount — Sum of all outstanding patient balances
• Never Sent — Encounters needing their first statement
• Sent 1x / Sent 2+ — Statement frequency breakdown
• In Collection — Encounters flagged for collections

Click any row to expand and see:

• Patient Responsibility Breakdown — Parsed from the ERA posting memos. Shows the breakdown of why the patient owes money:
  • Deductible — Amount applied to the patient's deductible
  • Coinsurance — Patient's coinsurance portion
  • Copay — Copay amount
  • Pt Resp — Other patient responsibility amounts
• Per-Code Breakdown — Each procedure code with its charge, adjustment, and remaining balance (from OpenEMR's InvoiceSummary)
• Statement History — Log of all statements sent for this encounter, with date, method, amount, and who sent it

• Generate Statement (file icon) — Opens OpenEMR's built-in statement tool (sl_eob_search) where you can print or email patient statements
• Mark Sent (check icon) — Records that a statement was sent for this encounter. Logs the date, amount, and user to the statement history.
• Add Note (sticky note icon) — Add a free-text note to the encounter's statement history
• View Ledger (book icon) — Opens the OpenEMR payment ledger for the encounter
• Open Encounter (folder icon) — Opens the encounter in OpenEMR
• Generate via ClaimRev (cloud icon, disabled) — Placeholder for future ClaimRev statement generation integration

The module tracks statements in its own mod_claimrev_patient_statements table. The queue shows whichever count is higher: the module's own count or OpenEMR's native stmt_count on the encounter. This means statements sent through either system are reflected.

The Claim Status tab provides a work-queue style dashboard for tracking claims through their lifecycle, with real-time 276/277 status checks.

• Work Queue — Claims sorted by status, showing which need attention
• Timeline View — Click any claim to see its full event history: submitted, accepted, rejected, ERA received, payment posted, manual notes
• Real-Time Status Check — Send a 276 status inquiry to the payer and get a 277 response showing current claim status
• Batch Sync — Sync multiple claims from ClaimRev at once to update local tracking data
• Manual Notes — Add notes to any claim's timeline for team communication
• Dashboard Stats — Summary cards showing claims by status category

Claims are categorized into actionable groups:

• Needs Attention — Rejected, denied, stale (no update in 30+ days), or paid but not posted
• In Progress — Submitted, accepted by payer, awaiting adjudication
• Completed — Paid and posted, or worked and resolved

The AR Aging Report is found under the Analytics dropdown in the navigation bar. It provides a standard 30/60/90/120 day aging breakdown of accounts receivable, grouped by payer.

1. Click Analytics > AR Aging Report in the navigation bar.
2. Optionally filter by payer name, patient name, or minimum balance amount.
3. Click Run Report.

• Total AR — Sum of all outstanding balances
• Aging Buckets — Dollar amounts in each bucket: 0-30, 31-60, 61-90, 91-120, 120+ days
• Payer Count — Number of distinct payers with outstanding balances
• Encounter Count — Total encounters with balances

Each row represents a payer and shows:

Payers are sorted by total AR descending — the biggest balances appear first.

Click Export CSV to download the full encounter-level aging data as a spreadsheet. The CSV includes patient name, encounter, service date, payer, age in days, aging bucket, balance, insurance level, and statement count.

The Denial Analytics page is found under the Analytics dropdown. It analyzes adjustment and denial patterns to help identify systemic issues with specific payers or procedure codes.

1. Click Analytics > Denial Analytics in the navigation bar.
2. The report auto-runs on page load showing the last 12 months of data.
3. Optionally filter by date range or payer name.
4. Click Analyze to refresh.

• Total Adjustments — Number of individual adjustment line items in the period
• Total Adjusted — Dollar amount of all adjustments
• Encounters — Number of distinct encounters affected
• Payers — Number of distinct payers

The left panel shows the 20 most common adjustment reasons, with:

• Reason — The adjustment memo as recorded during ERA posting (e.g., “Adjust code 45”)
• CARC Code — The Claim Adjustment Reason Code number, if present
• CARC Description — Human-readable description (e.g., “Charge exceeds fee schedule/max allowable”). The module includes descriptions for 30+ common CARC codes.
• Count — How many times this adjustment appeared
• Amount — Total dollar amount adjusted
• Visual bar — Relative frequency compared to the top reason

The right panel shows adjustments grouped by payer:

• Which payers have the most adjustments
• Total adjusted amount per payer
• Number of encounters affected per payer

This helps identify payers that are consistently adjusting or denying claims.

Below the payer breakdown, a monthly trend table shows adjustment counts and amounts over time, with visual bars. This helps answer: “Are our denials getting better or worse?”

Click Export CSV to download the denial reason data as a spreadsheet for further analysis.

The Recoupment Report is found under the Analytics dropdown. It identifies claims where payments were reversed (recouped) — typically from Medicare reprocessing or payer take-backs — and tracks whether a reprocessed payment has been received.

When Medicare or another payer reprocesses a claim, they often reverse the original payment (a “recoupment”) and then issue a new payment at the adjusted amount. This report answers:

• “Which claims had payments taken back?”
• “Has the reprocessed payment come through yet?”
• “What is the net financial impact of these recoupments?”
• “Which recoupments are still pending a reprocessed payment?”

1. Click Analytics > Recoupment Report in the navigation bar.
2. Set your filters:
   • Date Range — Filter recoupments by post date (defaults to the last 6 months)
   • Payer — Filter by payer name
   • Patient — Filter by patient name
3. Click Run Report.

• Recoupments — Total number of recoupment events found
• Total Recouped — Dollar amount taken back by payers (shown in red)
• Reprocessed — Dollar amount received in reprocessed payments (shown in green)
• Net Impact — Difference between recouped and reprocessed amounts, shown as a gain or loss. The card border is color-coded: green if net positive, red if net negative.
• Pending Reprocess — Number of recoupments where no reprocessed payment has been received yet (shown in yellow)

Rows with a “Pending” status are highlighted with a yellow background to draw attention to claims still awaiting reprocessed payment.

Click any row to expand a three-column detail panel:

• Recoupment Details — The recoupment date, amount, check reference, check date, and memo from the ar_activity record
• Original Payments — Table of all positive payments posted before the recoupment, with date, amount, and reference number
• Reprocessed Payments — Table of positive payments posted after the recoupment date. If none exist, a warning message is shown: “No reprocessed payment found yet. Medicare may still be processing, or the new ERA has not been posted.”

The report queries ar_activity for records with a negative pay_amount (the recoupment). For each recoupment found, it then looks up:

1. All positive payments on the same encounter posted before the recoupment date → classified as “original” payments
2. All positive payments posted after the recoupment date → classified as “reprocessed” payments

This classification helps billers understand the full payment lifecycle for reprocessed claims.

Click Export CSV to download the report as a spreadsheet. The CSV includes: Patient, Encounter, Service Date, Payer, Code, Original Paid, Recoup Amount, Recoup Date, Reference, Reprocessed, Net Impact, Current Balance, and Status.

Real-time eligibility verification is available from the patient demographics page.

• Eligibility - Standard 270/271 eligibility check with benefit details
• Coverage Discovery - Find active coverage for a patient
• Demographics - Verify patient demographic information with the payer
• MBI Finder - Look up a patient's Medicare Beneficiary Identifier

Note: Eligibility, Coverage Discovery, and MBI Finder are mutually exclusive; only one of them can be selected at a time. Demographics can be combined with any of those three.

1. Open a patient's chart and navigate to the Demographics screen.
2. In the ClaimRev section, select the payer responsibility tab (Primary, Secondary, etc.).
3. Select one or more products to check using the checkboxes.
4. Click Check Now for immediate results, or Queue Check to process in the background.
5. Results appear in tabbed sections: Quick Info, Deductibles, Benefits, Medicare, and Validations. The same layout is used for both Eligibility and Coverage Discovery results, since the payer returns the same response shape for both.

Coverage Discovery, Demographics, and MBI Finder query the payer using patient demographic data and don't need an insurance row, so the eligibility tab is still available for patients who have no insurance entered. In that case the tab is labelled No Insurance, the Eligibility option is hidden, and Coverage Discovery is pre-selected. Add the matched coverage afterwards through the normal Insurance card workflow if you want to keep it.

A red Reset button next to Check Now clears every cached eligibility row for the current patient (across all payer responsibilities). Useful when re-testing a fresh check or after fixing patient demographics that produced a bad result. The button asks for confirmation before deleting.

The Conversation tab provides an AI-powered assistant that can answer questions about the eligibility response. Ask questions like:

• “What is the patient's deductible?”
• “Is this patient covered for outpatient services?”
• “Summarize the key benefits”
• “What are the co-pay amounts?”

Eligibility results can be synced to OpenEMR's native Insurance card Eligibility tab by clicking the Sync to Insurance Card button. This populates the standard eligibility verification and benefit tables so the data is visible on the patient dashboard.

Electronic Remittance Advice (ERA/835) files from payers can be downloaded and imported into OpenEMR.

• Search for available ERA files by date range
• Download individual files for import into the OpenEMR billing system
• When Enable Test Mode is on, the ERA tab returns mock search results from local billing data and the Download button returns a 0-byte placeholder file.

The X12 Tracker tab shows the history of X12 files (837, 835, 270/271, 276/277, etc.) that have been transmitted through ClaimRev.

• View submitted and received X12 files with timestamps
• Track file acceptance and rejection status
• Download original X12 files for review or troubleshooting

The Appointments tab provides a comprehensive view of upcoming appointments with integrated eligibility verification, allowing front-desk staff and billers to ensure patients have active coverage before their visit.

Filter appointments using any combination of:

• Date Range — Start and end date (defaults to today through 7 days out)
• Facility — Filter by service location
• Provider — Filter by rendering provider
• Eligibility Status — Filter by:
  • All — Show all appointments
  • Needs Attention — Appointments with no eligibility check, errors, or stale results
  • Active Coverage — Appointments where eligibility returned successfully
  • Not Checked — Appointments with no eligibility record at all
  • Stale — Appointments where the eligibility check is older than the configured stale threshold

Each appointment row displays:

• Check Now — Immediately runs an eligibility check for the appointment via AJAX and updates the status in-place without a page reload. Shows a spinner while processing.
• Queue — Queues the eligibility check for background processing by the send/receive service.
• Queue Selected — Queues all checked appointments (or all if none are checked) for background eligibility processing.
• Check Now Selected — Runs immediate eligibility checks for all checked appointments in parallel via AJAX, updating each row's status as results come back.

For appointments with completed eligibility results, an expandable detail row shows the full eligibility response including the quick info summary with benefit details parsed from the 271 response.

When enabled, color-coded indicators appear on appointment blocks in the main OpenEMR calendar, giving providers and staff an at-a-glance view of each patient's eligibility status.

The module hooks into the calendar's event rendering system and adds a colored left border to each appointment block based on the patient's primary insurance eligibility status:

Eligibility data for all patients visible on the calendar is loaded in a single batch query, minimizing database overhead. However, on very busy calendars with many appointments, enabling this feature may have a minor impact on calendar load time.

• Navigate to Admin > Config > Connectors > ClaimRev Connect
• Set Enable Calendar Eligibility Indicators to Yes
• The stale threshold is controlled by the Eligibility Age To Stale setting (in days)

The Eligibility Sweep is an automated background service that proactively queues eligibility checks for upcoming appointments on a scheduled basis, ensuring patients have current coverage verification before they arrive.

1. The sweep runs as a background service once per day (every 1440 minutes).
2. On each run, it checks whether today is one of the configured sweep days.
3. If it is a sweep day, it looks ahead N days for appointments where eligibility is:
   • Missing — No eligibility record exists (never checked)
   • In Error — Previous check returned an error
   • Stale — Results are older than the configured stale threshold
4. Appointments already queued (waiting or creating status) are skipped to avoid duplicates.
5. Matching appointments are queued for the existing eligibility send/receive background service to process.

Navigate to Admin > Config > Connectors > ClaimRev Connect and configure:

The stale threshold is shared with other eligibility features and is controlled by the Eligibility Age To Stale setting.

With the default settings (sweep on Monday and Thursday, 7-day lookahead):

• On Monday morning, the sweep queues eligibility checks for all appointments through the following Monday.
• On Thursday, it queues checks for appointments through the following Thursday.
• Appointments that already have fresh eligibility results are skipped.

This ensures that by the time a patient arrives, their eligibility has been verified within the last few days.

Portal notifications from ClaimRev are accessible within the module, keeping you informed of important updates about your claims and account.

—

The ClaimRev Connect module ships as a single binary covering:

• OpenEMR 8.x (master and the 8.0.x patch line) — verified against openemr/openemr:flex and openemr/openemr:8.0.0.3-2026-03-25.
• OpenEMR 7.x (7.0.0 and later) — verified against openemr/openemr:7.0.2.

The src/Compat/ shim layer activates per-host. On OE 8.x cores that already expose the modern APIs the shims are no-ops; on OE 7.x or older 8.0.x cores the shims provide OEGlobalsBag, CryptoInterface, and ServiceContainer via class_alias, and CsrfHelper detects the active CsrfUtils signature at runtime.

To verify the module works correctly on your OpenEMR version:

1. Navigate to ClaimRev Connect > Connectivity.
2. Click the Run Compatibility Check button.
3. A diagnostic page shows the status of each critical component:
   • OEGlobalsBag — Whether the native class or shim is in use
   • ServiceContainer — Whether the native class or shim is in use
   • LoggerInterface / ClockInterface / CryptoInterface — Whether native or shimmed
   • GlobalConfig and Bootstrap — Whether they instantiate successfully
   • OpenEMR version and PHP version

If all checks show green, the module is fully operational. If any check shows “Using ClaimRev shim”, the module is running with compatibility shims — all features work normally.

—

• Verify your API credentials in Admin > Config > Connectors
• Ensure your server can reach the ClaimRev API endpoint (check firewall rules)
• Check the OpenEMR error log for detailed error messages
• Use the Connectivity tab in the module to test your connection

• Verify the patient has insurance data entered with a valid payer
• Ensure the payer is enrolled for eligibility transactions — see Payer Enrollments
• Check that the subscriber ID and patient demographics are accurate

• Most common cause is the upstream ClaimRev API taking longer than the script's allowed run time. The 2.1.2 build raises the script time limit and adds OAuth retries — make sure you're on 2.1.2 or later.
• Click Reset next to Check Now to clear cached results and try again. A retry usually succeeds because the previous request finished server-side after the browser gave up.
• If the error reproduces every time on a specific patient, capture the OpenEMR error log entry around the failed check (see Connectivity for log location) and contact ClaimRev support.

• Confirm the claim was submitted through the OpenEMR billing manager
• Check the X12 Tracker tab to verify the 837 file was transmitted
• Use the Reconciliation tab to identify claims that were billed in OpenEMR but not found in ClaimRev

• Ensure the encounter exists in OpenEMR and the patient control number matches (format: pid-encounter)
• Check that the encounter has not already been fully paid
• Review the error message in the posting results for specific details
• If using test mode, remember that mock data may not match real encounters

• Make sure ERAs have been posted — the Patient Balance queue only shows encounters where last_level_closed >= 1 (insurance has responded)
• Navigate to Setup and click Run Upgrade to ensure the mod_claimrev_patient_statements table exists
• Try lowering the Min Amount filter or clearing all filters

• Verify the Enable Calendar Eligibility Indicators setting is turned on in Admin > Config > Connectors > ClaimRev Connect
• Make sure the module is fully configured (API credentials set) — calendar indicators only register when the module is configured
• Check that patients have eligibility records in the system — appointments for patients with no eligibility data will show a yellow (unchecked) indicator
• Clear your browser cache and reload the calendar

• Verify the Enable Eligibility Sweep setting is turned on
• Check that today is one of the configured Sweep Days (0=Sun through 6=Sat)
• Confirm the ClaimRev_Elig_Sweep background service is active in Admin > System > Background Services
• Check the OpenEMR error log for sweep-related messages (search for “ClaimRev Eligibility Sweep”)
• The sweep runs once per day (every 1440 minutes) — it will not re-run on the same day

• If you see SQL errors when clicking Run Upgrade on the Setup tab, check the OpenEMR error log for the specific query that failed
• The upgrade process is idempotent — it skips tables and rows that already exist, so it is safe to run multiple times

• Confirm the module is both installed and enabled in Modules > Manage Modules
• Clear your browser cache and reload the page

If you installed the OpenEMR 8.x build on a 7.x install (or vice versa), you may see:

• Fatal error: Class “OpenEMR\Core\OEGlobalsBag” not found when loading any module page on 7.x — uninstall and use the OpenEMR 7.x build.
• Call to undefined method … CsrfUtils::collectCsrfToken() with a different signature error — same fix; download the build that matches your OpenEMR major version.

—

• Now published on Packagist as claimrevolution/oe-module-claimrev-connect. Install via composer require claimrevolution/oe-module-claimrev-connect:^2.1. Replaces the previous May 12 (OE 7.x) and May 13 (OE 8.0.x rebuild) separate-zip builds with a single binary.
• Single-binary cross-version compatibility — the src/Compat/ shim layer lives in the module's own repo on GitHub, not duplicated across two build branches. Same code path runs on OE 8.x master, the OE 8.0.x patch line, and OE 7.x.
• Crypto helper hardened for cross-version — GlobalConfig::getClientSecret uses CryptoGen::decryptStandard (works on both OE 7.x and 8.x) instead of the OE 8.x-only decryptFromDatabase.
• X12_SFTP install fix — module enable no longer references the non-existent background_services.last_run column that had been breaking installs on OE 8.x master.

• OpenEMR 8.x build rebuilt from the release/v8-0 branch. The previous 8.x build assumed every 8.x core exposed OEGlobalsBag::getKernel, SessionWrapperFactory::getActiveSession, and CsrfUtils::collectCsrfToken(session, subject). The OE 8.0.x patch line has none of those — its OEGlobalsBag is thin, SessionWrapperFactory uses a different acquisition pattern, and CsrfUtils::collectCsrfToken takes (subject, ?session) with a $_SESSION fallback. The new build ships the src/Compat/ shim layer with runtime-detection for the divergent APIs so the same zip works on 8.0.0.3 and on newer 8.x / master.
• Verified against openemr/openemr:8.0.0.3-2026-03-25 with full patient + encounter + billing data copied from a flex install. Login, navigation, Claims tab, Reconciliation, Payment Advice, ERA, and Setup all load cleanly.
• Cross-core crypto handling — GlobalConfig::getClientSecret now prefers the newer CryptoGen::decryptFromDatabase (upstream PR #11956, May 2026) when present and falls back to decryptStandard transparently. The 2.1.3 hotfix-only revert in the original 8.x build (which always called decryptStandard) is no longer needed.
• Module version constant stays at 2.1.3; this is a rebuild of the same release for the actual 8.0.x patch line.

• Security release — Closes the ten findings raised by the Aisle security review on the upstream PR. The fixes are layered:
  • IDOR guards on eligibility endpoints — A new PatientContext helper resolves the session-active patient and the Check Now (eligibility_check_now), Reset (eligibility_clear), and AI chat (eligibility_chat) endpoints now refuse a pid that does not match. The chat endpoint additionally re-verifies the supplied sharpRevenueObjectId belongs to that patient via the stored response payload.
  • CSRF on appointment queue actions — appointments.php now verifies the existing eligibility CSRF token before either bulk or single Queue POST handler runs and emits the hidden token in #bulkForm.
  • Authoritative re-fetch for posting + status sync — payment_advice_post.php accepts only paymentAdviceId (single) or paymentAdviceIds (batch JSON) and re-fetches the authoritative ClaimPaymentAggregation from ClaimRev before posting. claim_sync_status.php accepts only claimrevObjectId and derives the status fields from a re-fetched claim. Browser-supplied amounts, encounter PCNs, or status codes can no longer drive an OE write.
  • Test-mode gating — The skipMarkWorked POST flag on payment posting is only honored when isTestModeEnabled() is true, so a regular user can't suppress the upstream mark-as-worked side effect.
  • Path traversal hardening — EligibilityTransfer allowlists claimRevResultId to [A-Za-z0-9_-] (with a server-generated fallback) before composing the raw 271 save path.
  • CSV export header sanitization — claim_export_csv basename-strips control characters and restricts the API-supplied filename to a conservative charset before emitting it in Content-Disposition. The header is no longer susceptible to CR/LF injection.
  • Module-enable consent — ClaimRevModuleSetup::ensureCoreSftpEnabled only flips the X12_SFTP background service to active = 1 on a truly fresh install (last_run IS NULL). An admin who deliberately disabled the service keeps that setting across module re-enables.
  • Payment posting race window — PaymentAdvicePostingService::post wraps the duplicate check and arPostSession insert in a MySQL named lock keyed by paymentAdviceId. Concurrent submits of the same advice can no longer post twice; the second call returns a clear concurrent post in progress message.
• Cross-core crypto compatibility — GlobalConfig::getClientSecret originally kept calling CryptoGen::decryptStandard (the legacy API) instead of the newer decryptFromDatabase that upstream PR #11956 introduced in May 2026. The new method does not exist on older OpenEMR cores most installs still run, and using it would break the Connectivity tab on those installs. (The May 13 rebuild above changes this to a runtime-detected fallback so the same module works on both.)

• Eligibility request body — Send serviceTypeCodes as a JSON array (List<string>) instead of a comma-separated string, and always emit isRevenueToolsPayerId: false on each payer entry. The ClaimRev API tightened request validation and started rejecting the older shape with HTTP 400, breaking Check Now. Empty service-type-code configuration still asks for all benefits.
• MBI Finder mutex + request shape — MBI Finder is now mutually exclusive with Eligibility (matching the existing Coverage Discovery / Eligibility mutex). The payers array is omitted when only non-eligibility products are selected, since the API ignores it for those products and its presence corrupts MBI Finder results. When MBI Finder is requested, the subscriber number is copied to the top-level subscriberId field where MBI Finder reads it.
• Coverage Discovery results render correctly — Coverage Discovery now renders with the full Quick Info / Deductibles / Benefits / Medicare / Validations layout. The API returns the same response shape as Eligibility, but the old Coverage Discovery view only showed the flat top-level coverage fields and dropped the nested benefit and deductible data.
• Run without insurance — Coverage Discovery, Demographics, and MBI Finder can now be run on patients who have no insurance entered. The eligibility tab shows a No Insurance view that hides the Eligibility option, pre-selects Coverage Discovery, and submits a request built from patient demographics alone.
• Stop “Error communicating with server” on slow checks — The eligibility AJAX endpoint can sit through a Cloud Run cold start (~60s) plus a retryLater poll loop (~60s) on Coverage Discovery, which exceeded PHP's default 30-second max_execution_time. The Check Now and Appointment Check Now endpoints now allow up to 180 seconds, the Guzzle clients have explicit connect_timeout / timeout set so a stuck call can't burn the whole budget, and the OAuth token POST is retried up to two extra times on transient B2C hiccups.
• Reset button — A red Reset button next to Check Now clears every cached eligibility row for the current patient (across all payer responsibilities) after a confirmation prompt. Useful when re-testing a check from a clean slate.

• Two-build distribution — The module now ships as separate downloads for OpenEMR 8.x and 7.x. The 8.x build targets the native 8.x classes directly; the 7.x build adds the compatibility shim layer. Pick the build that matches your OpenEMR major version.
• Hardening pass — CSRF verification added to all state-changing AJAX endpoints (eligibility check/sync/chat, appointment check, claim mark-worked, CSV export). Bootstrap stops issuing per-request UPDATE writes and respects an admin-disabled core SFTP setting. Watchdog excludes itself from the stuck-service reset query so a long-running watchdog can't clear its own running flag.
• Bug fixes — Eligibility Sweep now correctly includes Sunday (0) in the configured sweep days. claim_export_csv parses request input through the typed boundary helper rather than passing raw $_POST to the service. Menu entry hidden from users without acct/bill access. Migration runner uses QueryUtils::escapeTableName/escapeColumnName for schema-validated identifier escaping.
• Standards — All module PHP files declare strict_types=1 to catch type coercion bugs at the boundary.
• Internal — PaymentAdvicePostingService and ReconciliationService refactored to expose pure helpers (idempotency-reference building, PCN parsing, claim status labels, service-line aggregation, discrepancy classification) with PHPUnit isolated test coverage.

• KPI Dashboard — Home tab replaced with a full revenue cycle dashboard showing claim pipeline, AR metrics, collections, denial rates, and patient responsibility at a glance
• Patient Balance Queue — New tab showing encounters with outstanding patient responsibility after insurance has responded. Includes PR breakdown (deductible/coinsurance/copay parsed from ERA memos), per-code detail, statement tracking, and actions to generate statements or mark as sent
• Claim Status Dashboard — New work-queue tab with claim lifecycle timeline, real-time 276/277 status checks, batch sync, and manual notes
• Claim Lifecycle Tracking Tables — New mod_claimrev_claims and mod_claimrev_claim_events database tables for tracking claim status, payer acceptance, ERA classification, paid amounts, and a full event audit trail (submitted, rejected, accepted, denied, ERA received, payment posted, etc.)
• AR Aging Report — New analytics page with 30/60/90/120 day aging buckets grouped by payer, distribution visualization, and CSV export
• Denial Analytics — New analytics page analyzing adjustment patterns by reason code, payer, and monthly trend with CARC code descriptions and CSV export
• Recoupment Report — New analytics page identifying claims with reversed/recouped payments (e.g., Medicare reprocessing). Shows original payment, recoupment, reprocessed payment, net impact, and pending status with CSV export
• Analytics Dropdown — AR Aging Report, Denial Analytics, and Recoupment Report grouped under an “Analytics” dropdown in the navigation bar
• Appointments Page Enhancements — Added facility, provider, and eligibility status filters. Eligibility status filter supports All, Needs Attention, Active Coverage, Not Checked, and Stale views. Added “Check Now” and “Check Now Selected” buttons for real-time AJAX eligibility checks without page reload. Expandable detail rows show full eligibility response for completed checks.
• Calendar Eligibility Indicators — Color-coded left borders on appointment blocks in the main OpenEMR calendar showing eligibility status at a glance (green=active, red=inactive/error, yellow=unchecked/stale, blue=pending). Uses batch query for performance. Enable via the new “Enable Calendar Eligibility Indicators” global setting.
• Eligibility Sweep Background Service — New ClaimRev_Elig_Sweep background service that proactively queues eligibility checks for upcoming appointments on configured days of the week. Configurable sweep days (default Monday and Thursday) and lookahead window (default 7 days). Skips appointments with fresh results or already-queued checks.
• OpenEMR 7.x Compatibility — Built-in compatibility shims (OEGlobalsBag, ServiceContainer, LoggerInterface, ClockInterface, CryptoInterface) allow the module to run on OpenEMR 7.x without modification
• Compatibility Check — New diagnostic page (Connectivity > Run Compatibility Check) verifies all module dependencies resolve correctly
• Statement Tracking Table — New mod_claimrev_patient_statements database table for tracking statement history per encounter

• Claims Tab — Added OpenEMR claim status display, encounter links, status sync (ClaimRev rejected → OE denied), and requeue-for-billing action
• Payment Advice — New tab for searching, previewing, and posting ERA/835 payment advice to OpenEMR (single and batch), with approval workflows for reversals and pended claims
• Payment Advice Test Mode — Mock data mode for testing the posting workflow without live API calls
• Reconciliation — New tab that compares OpenEMR encounters against ClaimRev statuses with automatic discrepancy detection
• X12 Tracker — File transmission history and download

• Initial release
• Claims submission (837P/837I)
• Real-time eligibility verification (Eligibility, Coverage Discovery, Demographics, MBI Finder)
• AI-powered eligibility assistant
• ERA file downloads
• Portal notifications
• Native OpenEMR eligibility sync