Highlights
New features
New Feature: View Past Claim Submissions And Reorganized Print Menu
Billers working rejections, denials, and appeals need to know what the payer actually received. Before, you could print the claim or preview the electronic claim as it is now, but not as it was sent. If the claim had been edited since, those views no longer matched the submission.
With this release, you can now see exactly what was sent to the payer for any past claim submission. This feature is available in Claim Tracker and the Claim section, and it adds two ways to look at a past submission:
- View Electronic Claim: the claim exactly as it went to the payer, for any claim sent electronically. This is the best choice if you’re comfortable reading electronic claims.
- View Claim Form: the CMS-1500 or UB-04 form, as the clearinghouse interpreted the electronic claim. This is the best choice if you’re more familiar with paper claims. It preserves the patient name, each charge, and the amounts, codes, and units that were sent.
Both show the claim as it was when it was submitted so if you changed the claim afterward or resubmitted it, you still see what the payer originally received. This means that you can check what a payer received before you appeal or dispute a decision, and use it to support your case.
Please note that an electronic claim has more places to send information than a paper claim, so there isn’t an exact one-to-one match between the two. For example, an electronic claim can carry several CLIA numbers, and it can carry separate operating, ordering, referring, and PCP providers. The paper form can’t show all of that. If you need the full detail of what was sent electronically, use View Electronic Claim.
We also added an update to the Claim section, where the Print button is now Print and View. It brings together everything that was in the Print menu, the new past submission options, and the electronic claim preview that used to be in the More menu, so all previews are in one place. The menu is grouped like this:
- Claim Submissions: Print Claim, Print Claim with Form
- Claim Preview: Show Preview, Preview Electronic Claim
- Past Submissions: Claim Form, View Electronic Claim, EOB
- Payer Letters: Open Negotiation, Proof of Timely Filing, Appeal
- Transaction History: Claim Transaction History
For more information, please visit our Print & View Options Help Article.
New: Eligibility Billing Alerts in Claim Review
Most practices and billing services have a process for verifying benefits, but things can still slip through the cracks. This is especially true as more eligibility checks happen automatically, for example when a patient is created through an EHR integration, and nobody looks at the result.
With this release, the Claim Review results now include an Eligibility Coverage section. It shows errors and warnings when something may be wrong with a patient’s insurance eligibility, so you can fix it before the claim goes out. It checks every policy on the claim and runs wherever Claim Review runs, including the Claim screen, Claim Control, and the WebAPI. Claims that may have an eligibility problem are flagged before submission, so you can check coverage or update the policy and avoid a likely denial. 
Please note that if eligibility is turned off for your account, the Eligibility Coverage section will not appear on your claim review results.
New: E-Statements & Payment Portal Communications to Guarantor
Until now, all E-Statement and Payment Portal communications went to the patient’s own cell phone and email. But there are scenarios where they should go to a Guarantor instead. For example, a 17-year-old might have their own email in the system while a parent is the guarantor and should get all the payment messages.
With this release, you can now choose who the Payment Portal user is. A new Payment Portal User dropdown has been added to the Patient section, under Billing Info → Payment Portal Options. This allows you to select a different person (such as the Guarantor) as the user. CMD then uses that person’s email address and cell phone number for Payment Portal communications. This includes the Payment Portal invite, receipts, and statement notifications. 
Please note:
- The email only updates automatically for new registrations. If a patient is already registered with the Payment Portal, switching the Payment Portal user to the guarantor will not change the email on file. That email was set when the patient registered, and CMD doesn’t update it automatically. To send Payment Portal email to the guarantor, use the change email option to update it yourself. The email changes automatically only when the patient hasn’t registered yet.
- Changing the user changes the cell phone number. This includes switching a registered patient to the guarantor. Text message opt-ins belong to a specific phone number, so the guarantor’s number needs its own opt-in, even if the patient’s number has already opted in. Until the guarantor opts in, text messages won’t reach them.
For more information, please visit our Change Payment Portal User Help Article.
New Option: Separate Minimum Amounts for Paper and Electronic Statements
Previously a single field controlled the minimum amount for statements regardless if they were paper or electronic statements. Some practices want to have an option to send electronic statements for smaller balances than they would paper statements. Others require a high minimum payment in the Payment Portal, so they want a higher minimum for electronic statements. With this release, automated statements now have a separate minimum amount for paper and electronic statements. Since before, one minimum applied to both, we deployed the following changes:
- The existing minimum amount has moved to the Paper Statements tab.
- A new minimum amount field was added to the Electronic Statements tab.
- The Statement Options tab now has a note that the minimum can be set separately on each of those tabs.
For more information, please visit our Statement Automation Settings Help Article.
Run Reports in the Background
Running a report in the application has required an open network connection for the whole run. For some users, especially those far from our servers, that connection can be interrupted along the way. The interruption can be retried silently, and because reports take a long time and each user can run only one report at a time, they would see an error saying they were already running the report. Meanwhile, the original report kept running and its results were never used.
With this release, reports run in the CMD application can now run in the background. CMD saves the results, and you retrieve them when the report is done, so you don’t need to keep an open connection while it runs. This means that if If your connection drops while a report is running, you won’t get an “already running this report” error, and the work isn’t wasted.
Enhancements
Improvement: Statements, Estimates, and Payment Plans Now Appear Separately in the Payment Portal
Before, everything a patient owed was combined on one page. A patient with an estimate and a payment plan had to scroll through the whole page to work out which was which. With this release, and as part of our ongoing e-statement improvements, a patient’s electronic statements will now be split into separate statements in the Payment Portal. For example, if you create a payment plan for a patient, it appears as its own statement. It no longer sits alongside their other balances. With this cleaner layout, patients can find what they owe, and click through an upcoming estimate, or their payment plan without sorting through the others. 
Improvement: Standard “Select All” Checkbox Is Back in Batch Statements
To prevent out-of-memory errors when printing large volumes of statements, we had previously limited the number of selectable items within statement batch print. If you select more than 1,000 statements for printing or previewing, a warning will notify you that only the first 1,000 will be processed. After printing, the system automatically deselects those 1,000 statements, allowing you to repeat the process for the next set.
As part of that enhancement, we had also replaced the header checkbox with a "Select All Statements" button at the top of the screen. But after some customer feedback, we realized that that was an unfamiliar way to select statements for customers, so with this release, the batch statements screen now has the standard Select All checkbox in the table header again. The separate Select All Statements button at the top of the screen is gone. This update keeps the 1000 statements safeguard but puts back the familiar checkbox (which works the same way it does in Claim Control). 
Visit our Batch Print Statements Help Article for more information.
New Report Field: First Visit Date
Some practices treat patients over a long period for one reason, such as an inpatient psychiatric stay or treatment for an injury. Until now, there was no easy way to report on when a patient first came in.
In this release, we added a new First Visit Date report field within Patient Data. It shows the date of service of the patient’s earliest claim, ignoring deleted claims. With First Visit Date, you can see how long a patient has been in treatment, which can help you compare treatment length with what you’ve been paid. 
Visit our Patient Data Report Fields Help Article for more information.
Update: Payment Automations Now Follow the Order You Set
CMD used to check code types in a fixed order: remark codes first, then unpaid reason codes, then adjustment reason codes. The order of your automations only mattered within each type. That was hard to predict. A remark code on a charge could override an automation you had placed higher in your list. To get the result you wanted, you had to turn off automations you still wanted to use.
With this release, when more than one Payment Automation applies to a charge, CMD now uses the top-most automation in your list that matches any of the charge's remark, unpaid reason, or adjustment reason codes. This means that you can now control which automation wins by reordering your list, and moving the automation you want to apply first to the top. 
New WebAPI Capability: Update a Claim’s Follow-Up Date Without Adding a Note
The WebAPI’s follow-up note endpoint could already add a follow-up note and optionally change the follow-up date. This means that an integration could add a note and keep the current date since the date was optional, but it couldn’t do the reverse (update the follow-up date without adding a new note).
With this release, the WebAPI now lets an integration update a claim’s follow-up date without adding a note. By making the note now optional, a customers can push a claim’s follow-up date out when the claim hasn’t been worked yet, without adding a placeholder note.
Improvement: Formatting Is Now Kept When You Paste Text Into CMD Editors
Staff often move information between messages, patient notes, and patient alerts. Previously, a list, such as a refund request with the date of service, office, provider, patient, amount, and reason, was flattened into one block of plain text when pasted, so people had to reformat it by hand.
This issue has been fixed in this release so users can copy a list or other basic formatted text from a CMD message and paste it into a patient note, patient alert, or another message without redoing the formatting.
Resolutions
Resolved Issue: Expected Reimbursement on Denials
Resolved an issue where, the Expected Revenue was being set from the payer's allowed amount even when the claim had been denied. A denied claim then looked as if nothing more was expected, with $0.00 remaining even though in practice, you may still appeal the denial or fix and resubmit the claim and get paid. Until the charge is written off, there is still money you expect to collect, so the number should show it.
With this release, when a claim is denied, CMD no longer uses the primary payer's allowed amount to work out Expected Revenue. It now uses the contract amount for the procedure code if you have one. If there's no contract amount, it uses the charge amount. (A denied claim no longer shows $0.00 expected , so A/R stays visible while you appeal.
Resolved Issue: First Pass Resolution Rate Gadget Now Matches the First Pass Resolved Claims Report
Corrected an issue where the numbers in the First Pass Resolution Rate dashboard gadget didn’t match the First Pass Resolved Claims report. For the same month, the gadget could show a higher rate than the report. Clicking a point on the graph also opened the report for only part of the month, such as the first week, instead of the whole month.
Two causes were found:
- Not only first submissions were counted. A claim that wasn’t resolved on the first pass could count as “not resolved” across several days or months.
- Repeat submissions still counted as resolved. Claims were counted as resolved on the first pass even if they had been submitted to the primary payer more than once.
This issue has been fixed, and the gadget now uses the same data as the report, so the two agree for the same period.
Resolved Issue: Claim Rejections Gadget Acceptance Rate Was Too High and Didn’t Match Clean Claim Rate
The Acceptance Rate at the bottom of the Claim Rejections dashboard gadget was calculated from claim status messages, not from claim submissions. A single submission can have several status messages. For example, the clearinghouse might accept a claim and the payer might then reject it. That claim counted as both accepted and rejected, which inflated the Acceptance Rate. Customers who compared it to the Clean Claim Rate gadget saw two different numbers for what should be nearly the same measurement.
This issue has now been fixed, and the Acceptance Rate now counts each claim submission once. A submission counts as rejected if it has at least one rejection, and the rate is the share of all submissions that were not rejected. It should now be very close to the Clean Claim Rate.
Please note that the two can still differ if you filter the Claim Rejections gadget to Clearinghouse or Payer only.
Resolved Admission Issue: Overdue Tasks Count Not Matching the Task Search Report or My Tasks
Resolved an issue where, the Overdue Tasks count on the dashboard Timeline could differ from the number of tasks in the other places you check it within the application. The number of overdue tasks from the timeline could be different than the number from:
- The Task Search report, which opens when you click the Overdue Tasks Timeline item.
- Home → Tasks → My Tasks, when you filter by an end date of yesterday.
This issue has now been fixed, and the Overdue Tasks count on the Timeline now matches the Task Search report and My Tasks.
Resolved Issue: Claim Attachments Rejected Because the Provider NPI Didn’t Match
Corrected an issue where, some claims submitted with an attachment were rejected by the clearinghouse with an "attachment’s provider NPI did not match the claim’s NPI" error. This was triggered by the fact that ePS requires the NPI on the attachment to match the claim’s rendering provider. With this release, claim attachments will now send the claim’s rendering provider NPI. If the claim has no rendering provider, the attachment sends the billing provider NPI instead.
Resolved Issue: Claims for Providers Without an NPI Rejected by UHC Medicaid
Corrected an issue where, professional claims for rendering providers without an NPI (atypical providers) were rejected by the clearinghouse when billed to UHC Medicaid. CMD sent the rendering provider with an older ID type instead of the NPI type that current claim standards require. The rejection messages said the rendering provider's ID type must be “XX” and that the rendering provider's NPI was missing.
Now, when the rendering provider has no NPI, CMD no longer sends the invalid ID type and number. It sends the provider’s payer-specific ID in a separate reference segment instead. This now happens even when the provider is set to bill as an individual, ensuring that claims for providers without an NPI are no longer rejected for an invalid rendering provider ID type.
Resolved Admission Issue: Time Not Saved on Claims Created Through the WebAPI
Resolved an issue where, when an integration sent an admission time with a claim through the WebAPI, CMD left the claim’s admission time blank instead of saving it. For example, a request with an admission time of 10:00 AM created a claim with no admission time. This ensures that claims created by your integration show the admission time you send. You no longer need to enter it by hand after the claim arrives.