Highlights
New features
Data Snapshots and Reporting Moved To a Read Replica Database
We've updated various Report pieces, as well as Data Snapshots, Dashboards, and Timeline queries to run against a Read Replica database instead of the primary database. A Read Replica is a continuously updated copy of our database dedicated to handling read-only requests, separate from the primary database that handles all data entry and updates. By moving reporting and snapshot queries to the Read Replica, we reduce the load on the primary database, which is designed to prioritize the day-to-day actions you take in CMD. This change is designed to improve system performance and stability, particularly for reporting: Dashboards and Timeline data should load more consistently throughout the day, and Data Snapshots should be delivered earlier than before. This is part of an ongoing rollout, and we'll continue moving additional reporting and snapshot features to the Read Replica over the coming weeks to months as we monitor performance and results. No action is required on your part, as these improvements are applied automatically and will continue to roll out over time.
Enhancements
ERA Patient Matching No Longer Flags Middle Initial Mismatches
When reviewing an ERA, CMD previously still displayed a warning if a patient's middle initial did not match the file, even when the first and last names matched. This generated unnecessary warnings that did not indicate an actual patient matching issue. This update ensures that discrepancies in middle initials no longer trigger alerts. Warnings are now reserved for mismatches in first or last names, allowing you to focus on patient records that require genuine attention. 
New Tax ID Permission Level For Bill Pay Permission
Previously, if you wanted to allow someone such as a provider to add their own new Tax ID in the Provider section, you had to set their Bill Payment permission to Allow. The problem was that the "Allow" permission level also gave that person the ability to pay your entire monthly invoice and receive the monthly invoice email. In this release, we added a new permission level for Bill Payment called Tax ID Add-On. This allows a user to pay invoices related to adding a new Tax ID for a provider, without being able to view or pay any other invoices. This is especially relevant for billing services that want to let providers self-manage their own Tax ID setup.
The updated Bill Payment permission levels are now:
- Deny – User cannot make any bill payments.
- Tax ID Add-On (new) – User can pay invoices related to adding a new Tax ID in the Provider section only. They cannot view or pay any other invoices, and will not receive monthly invoice emails.
- Allow All – User has full access to view and pay any invoice, and will receive monthly invoice emails (same as the previous "Allow" permission).
Please note that if you previously had a user set to Allow, that user has automatically been updated to Allow All, so their access remains unchanged. Users previously set to Deny will remain unchanged.
Payer Alerts Now Show Immediately When Adding a Policy
Previously, when adding a new policy to a patient using a payer that has an Alert configured to display in the Patient section, the Alert would not appear immediately. This applied whether the policy was added to an existing patient or a brand-new patient, causing the Alert to only display after saving, closing, and reopening the patient record. This could be an issue in cases with alerts containing time-sensitive or critical information that needs to be reviewed immediately (for example, special billing instructions or requirements tied to that payer).
his release updates the Payer Alert to display immediately upon adding a policy with a configured alert, whether for a new or existing patient. It is no longer necessary to save and reopen the patient record.
Login Performance Improvement
We've improved login performance in CMD, especially for users associated with a large number of groups (users with access to hundreds of customers). If you're a user with access to a large number of groups or customers, you should notice faster, more efficient login times after this release.
Resolutions
Universal Import Improvements & Fixes
This release includes several improvements and resolved issues for Universal Import.
Bill Type Now Correctly Defaults on Institutional Claims
Issue: When importing a file containing Institutional claim data (such as revenue codes or admission date) that did not include a Bill Type column, the Bill Type was being incorrectly set to "1" instead of using the practice's default Bill Type — resulting in incomplete claims.
Resolution: This issue has been fixed. Universal Import now correctly applies the practice's default Bill Type to Institutional claims when the import file does not include a Bill Type column.
New: Admitting Diagnosis Code Support
Universal Import now supports mapping and importing Admitting Diagnosis codes, in addition to standard diagnosis codes.
Value Code Amounts with Dollar Signs or Commas Now Processed Correctly
Issue: Universal Import was not correctly processing Value Code Amount fields containing dollar signs or comma-formatted numbers (e.g., $5,321.34 was being incorrectly split into two separate values).
Resolution: This issue has been fixed. Value Code Amounts are now correctly interpreted, even when formatted with dollar signs or comma separators.
Organization Providers Now Mapped Correctly
Issue: Universal Import was not correctly identifying providers set up as organizations (rather than individuals) in CMD. As a result, organization provider names were not being mapped correctly, causing claims to fail with a "rendering provider can't be found" error instead of importing successfully.
Resolution: This issue has been fixed. Universal Import now correctly determines whether a provider is an individual or an organization and maps the provider name accordingly.
Date of Birth Validation Added
Issue: Universal Import was not validating the Date of Birth field for proper date format. As a result, an invalid or incomplete date value (e.g., "01/05/.1") could be imported and converted to an incorrect date, such as "0001," instead of triggering a validation error.
Resolution: This issue has been fixed. Universal Import now validates the Date of Birth field to ensure it matches an expected date format before import, flagging invalid values rather than converting them to an incorrect date.
Errors Switching Between Linked Patient Portal Accounts
We corrected an issue where patients with multiple Patient Portal accounts linked together (via matching email and password credentials) — including accounts belonging to different CMD customers, could experience errors when attempting to switch between those linked accounts or take certain actions in the Payment Portal. This occurred because the system could not properly locate the linked patient account within the currently logged-in customer.
This issue has been fixed and the Payment Portal now correctly handles patient account lookups, allowing patients with multiple linked accounts to switch between them without errors.
Resolved issue: Claims Incorrectly Submitted Electronically to Secondary Payers
Corrected an issue where claims were being submitted electronically through both Real-Time Claim Submission (RTCS) and regular claim submission to a secondary payer even when the Master Payer List indicated that the payer did not support electronic secondary claim submission. This could result in claims being immediately rejected or left unresolved, causing a delay before the claim could be corrected and resubmitted through the appropriate method.
Resolved Issue: Last Character of ICD Code Removed When Tabbing Out of Field
We've resolved an issue when setting up Patient Default ICD codes where, under certain circumstances, the last character of the ICD code would be removed when tabbing to the next field. This issue has been fixed. ICD codes entered in Patient Default settings will now retain all characters when tabbing to the next field.
Resolved Issue: Missing Validation for Some Value Codes During Import
We've resolved an issue where after importing claims, invalid or excessively long Value Codes could be passed through without validation, potentially resulting in a database constraint violation rather than a clear, actionable message.
This issue has been fixed. Value Codes are now validated during import, and a clear, actionable message will be displayed if a Value Code does not meet expected format or length requirements instead of an unexpected database error.
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.