Highlights
New features
New Resource: WebAPI Documentation Site
Previously, WebAPI documentation was distributed manually as a ZIP file of Word documents, which meant developers had to remember to check for and request updated versions, and there was no guarantee everyone was working from the most current documentation.
In this release, we've launched a new, dedicated WebAPI Documentation site, replacing the previous method of distributing API documentation. Our new documentation site solves previous documentation issues by automatically updating with every new WebAPI release, ensuring you always have access to the latest information. It includes items such as API references detailing available API calls and how to use them, common workflow guides, and answers to frequently asked questions.
Our documentation site is also fully accessible to AI coding tools (such as Claude or ChatGPT). If you or your development team use AI-assisted coding, these tools can now reference our documentation directly to help build accurate integrations with CMD's WebAPI. 
Enhancements
Universal Import: Ability to Match Patients by Name Alone
Some EHR systems export limited patient information, sometimes just a patient's name, without a Date of Birth or identifier. Previously, this could prevent Universal Import from successfully matching a patient. In this release, Universal Import now supports importing claims, matching patients by name alone, for situations where an import file doesn't include a Date of Birth or a patient identifier. This update adds name-only matching as an additional option to help these imports succeed.
How It Works
Universal Import will always attempt matching in this order:
- Patient identifier (if available)
- Date of Birth
- Name only (new) — used only as a last resort, when no identifier or Date of Birth is available.

Patient-only updates will still require the date of birth. If a name-only match finds more than one patient with the same name, Universal Import will not create or update a patient or match the claim, since it cannot reliably determine which patient is correct. In this scenario, the import file will need to include a Date of Birth for each patient to allow proper matching.
Remittance Codes Can Now Be Added Without a TCN
Previously, the system required a TCN in order to add remittance codes, since Claim Tracker relies on TCNs to show claim submissions for denial management. However, this created a challenge for customers importing older, historical claims. For example, using Universal Import to bring in past claims and then posting payments via an 835/ERA upload. Without a TCN, denial reason codes from these older ERAs couldn't be posted, making it difficult to fully work historical AR.
With this release, CMD now supports adding remittance and denial codes on an EOB even when there is no TCN (activity ID) associated with the claim. If you're importing older claims and posting payments via an 835 file, you can now fully post remittance and denial codes even when the claim has no TCN.

While this scenario is still not the ideal way to bring claims into CMD, this update ensures denial details are captured and available in denial reporting, rather than being lost.
New Report Field: Charge-Level Primary Payer "Allowed Amount"
The Primary Payer Allowed Amount field was previously added at the Claim level dataset. In this release, we added this report field to the Charge level, found under Charge/Debit Data → Charges → Primary Payer → Allowed Amount. This update provides more flexibility by allowing you to report on the Primary Payer Allowed Amount at either the Claim level or the Charge level, whichever best fits your reporting needs. 
Provider Adjustments Now Matched by Payer Claim Number
Previously, Provider Adjustments were matched to a claim only by TCN number. However, some payers send their own internal claim number instead of CMD's TCN, which could prevent a Provider Adjustment from being correctly matched to the corresponding claim. With this release, Provider Adjustments can now be matched to a claim using the Payer Claim Number, in addition to the existing TCN (activity ID) matching.
This means that Provider Adjustments should now match more reliably to the correct claim, even when a payer references their own internal claim number instead of the TCN, making it easier to track and report on these adjustments.
New Payer Enrollment Enhancement Ensures Correct Tax Id is Sent
Previously, if a provider's Tax ID was updated in CMD after a payer enrollment (agreement) had already been created, that enrollment could sometimes still go out to EPS with the old Tax ID, rather than the corrected one (potentially causing delays in getting claims set up correctly with the payer).
This release ensures that payer enrollment requests always include the current Tax ID on file, guaranteeing that submissions contain accurate information. So if you need to correct a provider's Tax ID after initially entering it incorrectly, new payer enrollments will now go out with the updated Tax ID, helping avoid delays in claim setup with that payer.
Search Added to Update Status Dropdown in Claim Control
Some practices have a large number of claim statuses configured (sometimes 50, 100, or more) making it difficult to scroll through and locate the correct one. In this release, the Update Status dropdown on the Claim Control results screen now includes a search field, making it easier to find and select a claim status. With the new search field, you can simply type into the search field to quickly filter and find the status you're looking for, rather than scrolling through the full list. 
Request Customer Name Change in Customer Management
Previously, customers requesting a name change would need to call Support, and the change would be made manually with no formal tracking or auditing. This update automates the process while ensuring every name change request is fully tracked within CMD. A new "Request Customer Name Change" option is now available within Account Administration → Customer Management. Authorized representatives can now submit a customer name change request directly within Account Administration. The change is processed automatically, and a complete history of the request is tracked in the system. 
Resolutions
Resolved Issue: Practice Fusion Co-Pay Not Applying Without Pre-Configured Amount
Previously, if a patient's co-pay amount was not already configured in CMD, a co-pay received from Practice Fusion along with a claim would not be applied.
This issue has been fixed. Co-pays received from Practice Fusion will now be applied to the claim automatically, even if a co-pay amount was not pre-configured on the patient.
More Reliable ERA Patient Matching When TCN Is Not Present
When an ERA payment doesn't include a TCN, CMD attempts to match the payment to a patient already in the system. We've made improvements to this matching process to make it more reliable. This is especially helpful when importing historical claims into CMD — for example, when a customer imports older claims via Universal Import and then posts payments from an 835/ERA upload where no TCN is available. More reliable patient matching in these scenarios helps ensure ERA payments are correctly applied.
Resolved Issue: Accident Information Not Copying to Institutional Claims via WebAPI
When claims were created via the WebAPI, Accident-related information, including the Auto Accident indicator and Accident State was correctly copying to Professional claims, but not to Institutional claims. This issue has been fixed. Accident information sent via the WebAPI now correctly copies to Institutional claims, consistent with how it already worked for Professional claims.
Please note that for accident and illness information to copy over via the WebAPI or Universal Import, the Practice-level claim setting "Include Accident and Illness Information on Claims for All Patients" must be enabled. If this setting is not enabled, accident and illness information will not be set on claims created via the API or Universal Import, regardless of this fix. 