New Features, Fixes, and Enhancements

This release includes the following enhancements:

Ability to Generate a Collections By Provider Report Based on Distribution Date  

Improvements have been made to the Collections By Provider Report (Location or All Locations > Financials > Report Generator) to allow for greater transparency and tracking of how payments are distributed to providers for their services. In addition to the existing Acceptance and Transaction Date options, you can now select to generate a report based on Distribution Date.  

The new functionality to run the report using the Distribution date basis enables you to incorporate all Distribution activity from Payments that occurred during the defined reporting period, regardless of when the payment was accepted or posted. 

As such, a report ran by Distribution Date takes into account:

• Delayed distributions (i.e., distributions that are made potentially months after the payment was posted)
• Modifications to existing distributions (e.g., changing the provider)
• Distribution Reversals resulting from Transaction Adjustments or the issuance of Refunds

There is also a new Distribution Date column included in the report output, regardless of which date basis is selected upon report generation.

Distribution Date Basis

When Distribution Date is the selected date basis, the Collections By Provider Report returns all Distribution activity (associated with payments from any date / time period) that occurred during the defined reporting period. Provider-based data will reflect the time-bound (based on the Reporting Period) net Distribution activity (Distributions or Reversals) associated with the Provider or their Services. 

Note: The Unallocated data will reflect the remaining unallocated / undistributed funds from those Payments that had Distribution activity during the defined Reporting Period.

• If your office uses the Collections By Provider Report to pay providers, it is recommended that you run the report based on the Distribution Date for the most accurate report output.
• You can follow the payment every step of the way, accounting for any changes that are made, eliminating the need to re-run previous month's reports to account for retroactive changes. 
• Run the report for a distinct time period to ensure exact calculations and prevent over (or under) paying for distributions to providers.
• Note: The Distribution date cannot be manually edited by your practice.

Acceptance or Transaction Date Basis

When Acceptance Date is selected, the report returns the to-date (all time) Distribution activity from payments that were accepted by the Office during the defined Reporting period (e.g., the date when the office physically received a check).

When Transaction Date is selected, the report returns the to-date (all time) Distribution activity from payments that were posted by the Office during the defined Reporting period  (i.e., when the payment was typed into the Sensei Cloud software). 

• IMPORTANT: When run by Acceptance or Transaction Date, the report returns the accumulated Distribution Activity - as of the moment of running the report - for the time-bound (based on the Reporting Period) set of Payments. In effect, this is only a current snapshot and will not reflect subsequent Distribution activity that may occur later (new distributions, re-distributions, or reversals). The report must be re-run for the same Reporting Period to get the current Distribution activity for the Payments.
• Changes such as if a payment was distributed, redistributed, or a refund processed, outside of the selected reporting period, could ultimately be missed if you do not return and re-run the report for the same reporting period again.
• Note: The Acceptance date for a payment can be manually defined by practices at the time of posting.
• Note: The Transaction date cannot be manually defined and reflects the current date at the time of posting. 

Note: For practices that consistently take a payment, post the payment, and distribute the payment all on the same date, and do not make subsequent adjustments to the associated Transactions or Distributions, you can use the Acceptance or Transaction date basis without missing any changes and accidentally over or under paying providers.

See How to Create a Collections By Provider Report for more information.

Procedure Display Options for Statement and Account History 

For US practices, to help fit more data on a single page and decrease the overall page count for Statements and Account Histories, you can now opt to use the Office Codes / Descriptions for procedures rather than the default Authority Codes / Descriptions (i.e., CDT Nomenclature or CPT Description).

Manage the Procedure Description Basis from the Statement Defaults settings (Administration > Practice Settings > Financial Rules > Statement Defaults).

The Procedure Description Basis setting controls the information (code and description) that is displayed for Statements, Account History, and for transaction descriptions in the Patient Ledger.

Procedure Description Basis

• Office Code / Description: This is the internal office code and description which you can edit to say whatever you would like. 
  For example, you could shorten the CDT nomenclature description of periodic oral evaluation - established patient to simply say "Exam" or "Periodic Exam" in the Office Description, etc.  
  Note: Changing the procedure description basis to Office Code / Description will not impact insurance claims; they will still use the authority codes ( CDT or CPT nomenclature) regardless of the Statement Default Settings.
• Authority Code / Description: This is the official code and description (CDT or CPT) that is used for insurance claims.

Cross-Coded Preference (Available for Oral Surgery Practices): Select whether you want to default to Dental Code (CDT) or Medical Code (CPT) descriptions in Statements and Account Histories.

Note:  Sensei Cloud will use the chosen basis, including the dental (CDT) or medical (CPT) preference, for the Code and Description when defined for the Procedure. If or when undefined (i.e., Procedure not cross-coded or associated with an CDT or CPT billing code), then it will fall back to the next available option.

Updating Office Codes and Descriptions

The default code set that is included with Sensei Cloud automatically uses the traditional CDT language in the Office Code / Description, but you have the ability update the office descriptions on a procedure-by-procedure basis. Enter brief descriptions for the office codes to help decrease the overall page count and increase patient understanding when sharing Statements and Account Histories.  

The Office Code and Office Description for a procedure can be managed from the Procedure List & Fee Schedule list (Administration > Procedures & Fees > Procedure List & Fee Schedule). 

To edit the Office Code and Description for a procedure: 

1. Select a procedure.
2. Under Actions, click Edit Selected Procedure. The Update Procedure window is displayed.
   
3. Change either the Office Code, Office Description, or both. You can make the Office Description a shorter, but easily identifiable, version of the CDT nomenclature.
4. Click Update.

IMPORTANT: 
-- To help ensure accuracy of historical records, updating a Procedure in Sensei Cloud effectively creates a new version of the Procedure that is used going forward. As such, any existing instances of the Procedure - posted in Ledgers, scheduled on Appointments, added to Treatment Plans - continue to reflect the version of the Procedure at the time of its use. 
-- Accordingly, while the Statement Defaults settings will still apply to existing records - displaying the preferred basis for the Code and Description - the labels displayed will be based on the information defined for the Procedure at the time of its use (not the latest changes that were made to the Office Code and Description or authority code mapping).

See How to Manage Statement Default Settings and How to Create or Edit a Procedure Code for more information.

Defects and Small Enhancements

28 defects and small enhancements were addressed.