Highlights
| New Features | Enhancements |
|---|---|
| Universal Import - BETA
|
New Option to Ignore Modifiers Received From The WebAPI
|
New features
Universal Import - BETA
These new import options are currently in BETA testing and will be available to all customers soon!
Our Universal Interface Import allows users with an EMR/EHR that has not built an interface with us to import encounter, claim, and patient data from any external system. Customers can now upload CSV, Excel, TSV, and pipe-delimited files using our Interface Import section. This new feature uses AI-powered field mapping to automatically interpret the structure of CSV/Excel files from other systems and map them into CMD. This feature allows customers who do not use our WebAPI to automatically import claims, and patients from any EMR/EHR via a report or export from their software. 
Customers can also manually import claims into our system in the HL7 format or claims from an 837 ANSI file format into CollaborateMD.
For more information visit our Universal Import Help Article.
Enhancements
New Option to Ignore Modifiers Received From The WebAPI
When configuring interfaces, we can currently set up the interface to ignore the price that comes over in the message and use our own pricing instead. This is necessary because CMD, as the billing system, houses the fee schedules and contracts. We also have many defaults & automations around modifiers (specifically situational modifiers), but those rules are not used if modifiers are received from your EMR. Some users do not want this since if the modifiers entered in the EMR are wrong, automations will not work.
In this release, we added new options to the Interface Settings screen (for WebAPI Interfaces) that allows you to ignore modifiers sent via the interface. The new setting "Set modifiers based on the modifiers received from the Interface?" will default to Yes to allow setting the modifiers based on the modifiers received from the interface (just like it does today). Even if this is set to Yes, default and situational modifiers will be used if they are not received from the Interface. When set to No it will ignore the modifiers sent from the interface.
For more information visit our Configure Interface Settings Help Article.
New Option To Get Current Claim Status Through The WebAPI
We previously introduced an API endpoint request that allows users to set the claim status. To allow API vendors to continue building on this capability, we added the ability to retrieve the current claim status. This will return an XML response that includes the Claim Status ID, Claim Location ID, and Claim Status Display value.
Resolutions
Report Performance Issue When Combining Results
We resolved an issue in our Report Viewer where reports, run for multiple customers with the "combine results" option selected, took longer to process compared to running the same report with separate results.
Mark as Fixed Issue in Claim Tracker
Corrected an issue within claim tracker where, when checking the Mark As Fixed checkbox on Intelligent Claim Rejection messages should also mark all of the hidden issues as fixed but instead was flagging issues as "Not Fixed."
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.
Highlights
| New Features | |
|---|---|
| New Interface Automations |
New features
New Interface Automations
Our CollaborateMD interface provides a powerful bridge to automatically create patients, appointments, and claims in the CMD application via interface messages (ADT, SIU, DFT). Previously, after a patient appointment or claim was received & created via the interface, users still had to perform manual work such as checking eligibility, reviewing/scrubbing claims, or address verification. Powerful add-on features like Eligibility, Claim Scrubbing, and Address Verification had to be used either through a separate integration with our WebAPI (for Eligibility only) or manually in the application. In this release, these actions can now be automated to occur as soon as the claim, patient, or appointment is received. For more information visit our Manage Interface Automations Help Article.
We added the following new automations that can be enabled and configured within the services section by Auth Reps:
Eligibility Interface Automation
We created 2 new eligibility settings to allow eligibility to be automatically checked when a patient, appointment, or claim is created via the interface:
Automatically check eligibility when an appointment or claim is created over an Interface?
Select Yes if you want an automatic eligibility check when creating an appointment or claim, from an SIU or DFT message received via the interface.
Automatically check eligibility when a patient is created or updated over an Interface?
Select Yes if you want an automatic eligibility check when creating a patient from an ADT message received via the interface.
Claim Scrubbing Interface Automation
We created a new claim scrubbing setting to automatically review claims created via the interface:
Automatically review and scrub new claims as they are entered through an Interface?
Select Yes if you want to automatically scrub new claims created from a DFT message received via the interface.
For more information visit our Manage Claim Scrubbing Help Article.
Address Verification Interface Automation
We created a new Address Verification setting to automatically scrub addresses when creating/editing a patient record via the interface:
Automatically scrub addresses when the above changes are made via Interface?
Select Yes if you want to automatically scrub addresses (based on your pre-selected options) when creating or editing a patient record from an ADT/DFT message received via the interface.
For more information visit our Manage Address Verification Help Article.
Coming Soon - Patient Estimates Interface Automation
The ability to automatically generate patient estimates upon appointment or claim creation via the interface will be added soon!
Resolutions
Claim Control for Large Batches
We resolved an issue within Claim Control that could prevent users from changing the status of more than one thousand claims at once. This action would cause a "Maximum call stack size exceeded" console error when updating the claim status. With this new update, when a user updates claim statuses, it is performed in batches of 1,000 and pre-selects all the remaining claims that exceed 1000 after in initial claim status update. If more than 1,000 claims are selected for saving, a modal will appear stating: "Only 1,000 claims can be saved at once. After the save is complete, the remaining X claims will be selected in the table and can then be saved." Following the save, the selections in the table will be updated accordingly.
Intelligent Claim Rejections Enabled by Default
The Intelligent Claim Rejection feature was enabled for most customers, but an issue prevented its automatic enablement for new submitters. This issue marked the submitter in CMD with the feature turned on without changing the submitter request sent to ePS. In this release, we corrected this issue to ensure that submitter registrations sent to ePS turns this feature flag on.
Intelligent Claim Rejections Enabled by Default
In this release, we corrected some appointment reminder issues where some appointments were not sent and others had expired confirmation tokens. This issue was causing the confirm & cancel links in the appointment reminder to stop working after an additional reminder was sent to the patient.
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.
Highlights
Enhancements
New "To Date" Optional Column
We have always displayed the "From" Date (Date of Service) as a column in our Claim Control, Claim Tracking, and Follow-Up Management tables. This represents the first date of service on the claim. Customers who treat patients for extended periods (especially those using Institutional claims) could not view the complete range of service dates in these tables. In this release, we added the "To" Date (representing the last date of service on the claim) as an optional, hidden-by-default column. 
New ERA Warning when Patient Name Doesn't Match
A new ERA Warning has been implemented for instances where the patient's first or last name on the ERA (EraClaim.plast and EraClaim.pfirst) does not match the name recorded in our application. The warning message, "Warning: The patient name as sent by the payer does not match your records," will alert users to this discrepancy.
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.
Highlights
| Enhancements | |
|---|---|
| New Referring Provider Note Report Field New Optional Columns in Claim Control & Follow Up Management ERA Claim-level Payments Now Evenly Applied |
Enhancements
New Referring Provider Note Report Field
In this release, we added a new report field for the Referring Provider’s Note text field. This new report field (available under Referring Data) is useful for recording various information. For example, users can note the name of the facility a referring provider is from, allowing them to report on the number of lab samples received from each facility. 
New Optional Columns in Claim Control & Follow Up Management
Some customers use the Account Type and Reference # fields in CMD to store information that does not fit elsewhere in the application. While integrating fields for workflows across different specialties would be ideal, many customer issues can be resolved by allowing them to view this information in various places. In this release, we added these two columns as optional (not visible by default) in both Follow Up Management and Claim Control. 
ERA Claim-level Payments are Now Evenly Applied
Some payers (particularly for institutional claims) send only a claim-level payment rather than line-item payments. Previously, our system applied these payments by distributing as much of the paid amount on each charge as possible, and then as much of the adjusted amount on each charge as possible, resulting in uneven claim application, and requiring users to manually correct the ERAs for institutional claims. With this release, these payments will now be applied evenly.
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.
Highlights
| New Features | Enhancements |
|---|---|
| Universal Import - BETA
|
New Option to Stop Showing the All-Inclusive Code Warning
|
New features
Universal Import Updated UI - BETA
Please be aware that the new universal import options are currently in BETA testing and will be available to all customers soon!
In this release, we updated the Universal Import user interface to simplify the process and improve readability. We enhanced it by removing unnecessary fields and clutter, renaming file naming conventions, automating the matching of existing templates, and converting mapped preview data into a table. This facilitates scanning either the header or CMD field to ensure accurate field matching.
For more information visit our Universal Import Help Article.
Enhancements
Claim: New Option to Stop Showing the All-Inclusive Code Warning
All-inclusive codes are common in Rural Health Clinics and Federally-Qualified Health Centers. In our system, entering a claim with an all-inclusive code triggers a warning. This notification indicates that an all-inclusive code has been selected and explains the impact on other charges. These charges will either not be billed or will be billed with a nominal amount, such as $0.00 or $0.01, depending on system configuration.
Because this all-inclusive code prevents users from editing other charges on the claim, the pop-up informs them that these are non-editable amounts. The problem is that this is inconvenient for some customers that work thousands of claims, when it happens for every claim.
To address this, a "Don't show this again" checkbox has been added to the All-Inclusive Code warning message in this release. Checking this box allows users to suppress the All-Inclusive Code warning dialog for the same user when editing or creating a new claim with an inclusive code.
We also added a tooltip under the procedure description so that the information is still available without disrupting or prompting the user to close the warning. 
TCN Search Now Ignores the TCN Prefix
We recently added the submitter-level TCN Prefix feature to help the clearinghouse ensure that ERAs are routed correctly and to facilitate ERA splits.
This feature has been very helpful, but it could be inconvenient for some users depending on their workflow because if the full TCN, including the prefix, was copied from a payer report or EOB, users could not search for the correct claim or patient within the application. They would have to carefully copy the number while omitting the prefix, which could be difficult due to the small font on some reports.
In this release, the submitter-level TCN Prefix was updated so the system ignores it when searching by TCN in the claim, claim tracker, patient, insurance check, and ERA searches. This means that copying a TCN number from an EOB will no longer require partial selection for the search to function. This update allows the system to locate claims that include the prefix when copied.
Resolutions
WebAPI: Payer & Patient Default Value Codes Not Set on Claims
We have systematically implemented the ability to use more default codes from interface claims (such as value codes from revenue codes), but patient default codes and payer default value codes were still missing.
In this release, we are adding both Patient and Payer default value codes. When a claim is received via the API, the system will now add the default value codes in the following priority order:
1. Value Codes from the interface message (if sent)
2. Payer Defaults
3. Patient Defaults
4. Revenue Code Defaults
At each priority step, the system will only add value codes that have not already been included. For example, if the interface message sends value code 16, and the patient defaults include value code 16 and value code 18, then the message's amount for value code 16 will be used, followed by the patient's amount for value code 18.
Practice email address is automatically set as the "Reply-To" address for electronic statements
Previously, the practice email address was automatically set as the Reply-To address for electronic statements. Users were often unaware that the practice email was used as the default Reply-To email address when setting up their electronic statements, as this option is part of the electronic statement options. To prevent user error, we updated this release to default the Reply-To address to "No Reply," even when a practice email address is available. This will ensure that any Reply-To address set for electronic statements is added intentionally by the customer. Please note that existing configurations will not change. This applies only to electronic statement setups moving forward.
ERA: Incorrect Claim Status
Resolved an ERA issue that caused a charge balance with no additional payers to display an incorrect claim status. It showed a "PAID" status instead of "BALANCE DUE PATIENT," despite an existing balance and no other payers.
ERA & EOB: Incorrect allowed amount on refund/reversal
We corrected an issue within our ERA/EOBs causing an incorrect auto-calculation of the allowed amount on some refund/reversals.
Universal Import: Support First and Last Names with Spaces
We corrected an issue within our universal import detected during testing where names containing spaces but no hyphens, apostrophes, or symbols (e.g., "De La Cruz," "Van Dyke," "Mary Jane") were not recognized correctly during import.
As part of this release, we are continuing our ongoing work to assess, monitor, and address any security vulnerabilities.