myavatar Billing Widgets & Console Training Guide

Transcription

1 2014 myavatar Billing Widgets & Console Training Guide Netsmart Technologies, Inc. NOTICE: This document will be updated as additional functionality is released and any given version may not contain all of the information across all of the myavatar components. Please refer to last updated notation to determine when document was last updated. Nicki Grose Netsmart Technologies Inc. 10/27/2014

2 Table of Contents Overview... 3 Widget Repository... 3 Phase 1 Widgets... 3 Definitions and SQL... 3 Missing Authorizations... 4 Expiring Authorizations... 5 Clients Requiring Insurance Verification... 6 Financial Eligibility... 8 Authorization Reviews... 9 Follow-up Entry Service History Phase 2 Widgets Definitions and SQL Open Services by Guarantor Unbilled Services by Guarantor Billed Services by Guarantor (Last 7 Days) Billed Services by Guarantor (Current Month) Billed Services by Guarantor (Previous Month) Phase 3 Widgets Definitions and SQL Claims Payment Posted Claim Follow-up Advanced Billing Rule Failed Compliance Rebilled Claims 3+ Times with an Outstanding Balance Clients with Expired Eligibility Key Performance Indicators Net Collections Rate Charges by Month Collections by Month Console Home Views P a g e

3 Create a Billing Console Registry Setting Assign Access to the Console Widget Configuration Form Widget Creation View Definition P a g e

4 Overview In Avatar, there are many ways that billing and billing activities can be accomplished. In order to streamline the billing process and guide users through the billing workflow, the concept for creating a new Billing Console for various user roles was developed. Billing Specialists, AR Specialists, and Billing Supervisors or Managers all have different roles, requiring different information be readily available. For example, a Billing Specialist might want to see a Billing Dashboard that contain the widgets to be able to complete Quick Billing, as well as some key information that billers would need to easily view as part of the billing process in the form of additional widgets. This might include widgets that show the claims that are being generated, total amounts of liability by guarantor, batches created, etc. For Billing Managers and Supervisors, they would want to see much different information. For example, they might want the ability to easily monitor key performance indicators to measure the success of their billing processes. This document will provide Netsmart clients instructions on creating useful Billing Consoles for their organizations. Widget Repository In order to assist Netsmart clients with developing a Billing Console to meet their needs, a set of billing widgets are being developed for clients. This document will contain all the widgets that are being developed along with the SQL for each so that they can modified by clients to meet the needs of their organization. This document is a living document and as new widgets are released, the document will be updated accordingly. Phase 1 Widgets The following widgets were developed and released in Avatar PM 2014 Update 67 and CAL-PM 2014 Update 65. Additional fixes were released in Avatar PM 2014 Update 99 and CAL-PM 2014 Update 77. Missing Authorizations Expiring Authorizations Clients Requiring Insurance Verification Financial Eligibility Authorization Reviews Follow-up Entry Service History Definitions and SQL This section provides a description of each Phase 1 widget and how it could be used on a Console View. It also contains the SQL statement defined for the applicable so that clients may create new customized widgets that meet the billing workflow needs for their organization. For example, you might want to 3 P a g e

5 change the sort order or column ordering, add additional columns or modify the result set being returned. Missing Authorizations The Missing Authorizations widget shall display all clients for which no authorization exists and the guarantor requires an authorization. This is set up in 'Guarantors/Payors', on the 'Authorization Information' tab, by checking off at least one value for 'Verify Services and Appointments Against Available Authorizations' option. This will include clients who have financial eligibility information entered through financial eligibility or Cross-episodic financial eligibility. The following fields should be displayed in the widget: Client (Last, First, MR#) Guarantor Episode If the user clicks on the Client link in the list, the Managed Care Authorizations form is displayed for the selected client. Widget SQL Statement Because this widget was modified to include all the different financial eligibility types, it was handled in Cache code and therefore no SQL code is available. However, you want to use the queries to create separate individual widgets (Standard FE, Cross Episode FE, Family FE) you could use the following SQL statements to create your own widget to meet your organization s needs. Episodic SELECT "billing_guar_order_current"."patid", "billing_guar_order_current"."guarantor_name", "billing_guar_order_current"."episode_number", "billing_guar_order_current"."guarantor_id" FROM (("SYSTEM"."billing_guar_order_current" "billing_guar_order_current" INNER JOIN "SYSTEM"."billing_guar_table" "billing_guar_table" ON ("billing_guar_order_current"."guarantor_id" = "billing_guar_table"."guarantor_id" AND "billing_guar_order_current"."facility" = "billing_guar_table"."facility" AND "billing_guar_table"."verify_svcapp_auth_code" IS NOT NULL)) LEFT OUTER JOIN 4 P a g e

6 "SYSTEM"."history_managed_care_auths" "history_managed_care_auths" ON (("billing_guar_order_current"."patid"="history_managed_care_auths"."patid") AND ("billing_guar_order_current"."guarantor_id"="history_managed_care_auths"."guarantor_id")) AND (("billing_guar_order_current"."episode_number"="history_managed_care_auths"."episode_number") OR "history_managed_care_auths"."episode_number" IS NULL)) WHERE "history_managed_care_auths"."guarantor_id" IS NULL AND "billing_guar_order_current"."facility"=?facility Non-Episodic / Cross-Episode SELECT "billing_guar_order_no_ep"."patid", "billing_guar_order_no_ep"."guarantor_name", "billing_guar_order_no_ep"."guarantor_id" FROM (("SYSTEM"."billing_guar_order_no_ep" "billing_guar_order_no_ep" INNER JOIN "SYSTEM"."billing_guar_table" "billing_guar_table" ON ("billing_guar_order_no_ep"."guarantor_id" = "billing_guar_table"."guarantor_id" AND "billing_guar_order_no_ep"."facility" = "billing_guar_table"."facility" AND "billing_guar_table"."verify_svcapp_auth_code" IS NOT NULL)) LEFT OUTER JOIN "SYSTEM"."history_managed_care_auths" "history_managed_care_auths" ON (("billing_guar_order_no_ep"."patid"="history_managed_care_auths"."patid") AND ("billing_guar_order_no_ep"."guarantor_id"="history_managed_care_auths"."guarantor_id")) AND ("history_managed_care_auths"."episode_number"is NULL)) WHERE "history_managed_care_auths"."guarantor_id" IS NULL AND "billing_guar_order_no_ep"."facility"=?facility Expiring Authorizations The Expiring Authorizations (Review 10 days / Units-Visits 5) widget shall display all authorizations that are expiring in the next 10 days or have less than 5 visits or units remaining. This will display both managed care authorizations and cross episodic managed care authorizations. When the authorization expires it will no longer display in the widget. The following fields should be displayed in the widget: MR # Client (Last, First) Episode Guarantor Auth # Next Review Date Auth End Date Visits Remaining Units Remaining Dollars Remaining The records should be displayed in order by Auth End Date Client Name, and Client MR#, Guarantor Name. 5 P a g e

7 If the user clicks on the Client link in the list, the applicable Managed Care Authorizations or Cross Episodic Managed Care Authorizations form is displayed for the selected client. Note: If a client has both a cross episode authorization and a regular managed care authorization, the units/visits and dollars used are only applied to the regular managed care authorization. Widget SQL Statement SELECT "history_managed_care_auths"."cer_uniqueid" <HIDE>, "history_managed_care_auths"."option_id" AS "OPTIONNAME" <HIDE>, "history_managed_care_auths"."episode_number" AS "Ep" <HIDE>, "history_managed_care_auths"."patid" as "MR#", "patient_current_demographics"."patient_name" as "Client" <LINK:OPTIONNAME:MR#:CER_uniqueid:Ep>, CASE WHEN "history_managed_care_auths"."episode_number" IS NULL THEN 'Non-episodic' ELSE "history_managed_care_auths"."episode_number" END as "Episode", "history_managed_care_auths"."guarantor_name" as "Guarantor", "history_managed_care_auths"."authorization_number" as "Auth #", "history_managed_care_auths"."next_auth_review_date" as "Next Review Date", "history_managed_care_auths"."auth_end_date" as "Auth End Date", "history_managed_care_auths"."calc_rem_units" as "Units Remaining", "history_managed_care_auths"."calc_rem_visits" as "Visits Remaining", "history_managed_care_auths"."calc_rem_dollar_amount" as "Dollars Remaining" FROM "SYSTEM"."patient_current_demographics" "patient_current_demographics" INNER JOIN "SYSTEM"."history_managed_care_auths" "history_managed_care_auths" ON ("patient_current_demographics"."facility"="history_managed_care_auths"."facility" AND "patient_current_demographics"."patid"="history_managed_care_auths"."patid") WHERE ("history_managed_care_auths"."auth_end_date">=getdate()) AND (("history_managed_care_auths"."auth_end_date" < DATEADD(dd, 10, GETDATE())) OR "history_managed_care_auths"."calc_rem_visits"<'5') ORDER BY "history_managed_care_auths"."auth_end_date" ASC, "patient_current_demographics"."patient_name", "patient_current_demographics"."patid", "history_managed_care_auths"."guarantor_name" Clients Requiring Insurance Verification The Clients Requiring Insurance Verification widget displays all clients who still require insurance verification (meaning the Verify Eligibility flag is set to N ). This widget will include financial eligibility, cross episodic financial eligibility, and family financial eligibility records. The following fields should be displayed in the widget: MR # Client Name (Last, First) 6 P a g e

8 Episode # Admit Date Guarantor Policy Sub SSN Guarantor Phone Patient DOB Patient SSN The items should be listed in order by MR#, Client Name. If the user clicks on the Guarantor link in the list, the applicable Financial Eligibility, Cross Episode Financial Eligibility, or Family Financial Eligibility form will be displayed for the selected client. Widget SQL Statement Because this widget was modified to include all the different financial eligibility types, it was handled in Cache code and therefore no SQL code is available. However, you want to use the queries to create separate individual widgets (Standard FE, Cross Episode FE, Family FE) you could use the following SQL statements to create your own widget to meet your organization s needs. Standard Financial Eligibility SELECT EP.PATID, EP.EPISODE_NUMBER, EP.program_value, GOEP.guarantor_order_number, GOEP.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, SUBS.subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, DEMO.patient_ssn, DEMO.date_of_birth, EP.preadmit_admission_date, GOEP.e_unique_id FROM SYSTEM.episode_history EP INNER JOIN SYSTEM.patient_current_demographics DEMO ON ((EP.PATID=DEMO.PATID) AND (EP.FACILITY=DEMO.FACILITY)) WHERE EP.FACILITY=?FACILITY AND EP.date_of_discharge IS NULL AND EP.user_row_access_code = '1' AND GEMP.eligibility_verified_code='N' ORDER BY EP.EPISODE_NUMBER DESC, GOEP.guarantor_order_number Cross-Episode Financial Eligibility SELECT GONOEP.PATID, GONOEP.guarantor_order_number, GONOEP.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, SUBS.subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, 7 P a g e

9 DEMO.patient_ssn, DEMO.date_of_birth, '' as preadmit_admission_date, GONOEP.por_unique_id FROM SYSTEM.billing_guar_order_no_ep GONOEP WHERE GONOEP.FACILITY=?FACILITY AND GEMP.eligibility_verified_code='N' ORDER BY GONOEP.guarantor_order_number Family Financial Eligibility SELECT GOF.FAMID, GOF.PATID, GOF.guarantor_order_number, GOF.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, GOF.policy_number AS subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, DEMO.patient_ssn, DEMO.date_of_birth, '' as preadmit_admission_date, GOF.por_unique_id FROM SYSTEM.patient_family_history FAMH INNER JOIN SYSTEM.family_member_guar_order GOF ON (GOF.PATID=FAMH.PATID AND GOF.FAMID=FAMH.FAMID AND GOF.FACILITY=FAMH.FACILITY) WHERE GOF.FACILITY=?FACILITY AND FAMH.start_date_of_member <= CURRENT_DATE AND (FAMH.end_date_of_member IS NULL OR FAMH.end_date_of_member >=CURRENT_DATE) AND GEMP.eligibility_verified_code='N' ORDER BY GOF.guarantor_order_number Financial Eligibility The Financial Eligibility widget displays all of the financial eligibility records entered for the specified client. This will include financial eligibility, cross episodic financial eligibility, and family financial eligibility records. The following fields should be displayed in the widget: Order (aka Billing Order) Guarantor Episode Number Program Verify (Yes or No to indicate FE verification) Start End End Date Policy # (indicator if missing info or blank and plan is billable for the financial class) The items should be listed in order by Episode Number, Billing Order, and Guarantor. If the user clicks on the Guarantor link in the list, the applicable Financial Eligibility, Cross Episode Financial Eligibility, or Family Financial Eligibility form will be displayed for the selected client. Any fields missing required information will be indicated in red to alert user. 8 P a g e

10 Widget SQL Statement Because this widget was modified to include all the different financial eligibility types, it was handled in Cache code and therefore no SQL code is available. However, you want to use the queries to create separate individual widgets (Standard FE, Cross Episode FE, Family FE) you could use the following SQL statements to create your own widget to meet your organization s needs. Standard Financial Eligibility SELECT EP.PATID, EP.EPISODE_NUMBER, EP.program_value, GOEP.guarantor_order_number, GOEP.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, SUBS.subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, DEMO.patient_ssn, DEMO.date_of_birth, EP.preadmit_admission_date, GOEP.e_unique_id FROM SYSTEM.episode_history EP INNER JOIN SYSTEM.patient_current_demographics DEMO ON ((EP.PATID=DEMO.PATID) AND (EP.FACILITY=DEMO.FACILITY)) WHERE EP.FACILITY=?FACILITY AND EP.date_of_discharge IS NULL AND EP.user_row_access_code = '1' AND EP.PATID =?PATID ORDER BY EP.EPISODE_NUMBER DESC, GOEP.guarantor_order_number Cross-Episode Financial Eligibility SELECT GONOEP.PATID, GONOEP.guarantor_order_number, GONOEP.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, SUBS.subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, DEMO.patient_ssn, DEMO.date_of_birth, '' as preadmit_admission_date, GONOEP.por_unique_id FROM SYSTEM.billing_guar_order_no_ep GONOEP WHERE GONOEP.FACILITY=?FACILITY AND GONOEP.PATID =?PATID ORDER BY GONOEP.guarantor_order_number Family Financial Eligibility SELECT GOF.FAMID, GOF.PATID, GOF.guarantor_order_number, GOF.GUARANTOR_ID, GEMP.eligibility_verified_value, GUAR.customize_guar_plan_value, GEMP.cov_effective_date, GEMP.cov_expiration_date, GOF.policy_number AS subs_policy, SUBS.subs_ss_number, GUAR.guar_phone_number, DEMO.patient_ssn, DEMO.date_of_birth, '' as preadmit_admission_date, GOF.por_unique_id FROM SYSTEM.patient_family_history FAMH INNER JOIN SYSTEM.family_member_guar_order GOF ON (GOF.PATID=FAMH.PATID AND GOF.FAMID=FAMH.FAMID AND GOF.FACILITY=FAMH.FACILITY) WHERE GOF.FACILITY=?FACILITY AND FAMH.start_date_of_member <= CURRENT_DATE AND (FAMH.end_date_of_member IS NULL OR FAMH.end_date_of_member >=CURRENT_DATE) AND FAMH.PATID =?PATID ORDER BY GOF.guarantor_order_number Authorization Reviews The Authorizations Due for Review widget displays all authorizations that are due for review within the next 30 days. This will include both managed care authorization and cross episodic managed care authorizations. Once the Next Review Date has passed, the authorization will no longer be displayed in the widget. The following fields should be displayed in the widget: 9 P a g e

11 Auth # Client (Last, First, MR#) MC (Guarantor) Expires (Auth End Date) Units (Remaining) Visits (Remaining) Dollars (Remaining) Review (Date) Staff (Utilization Review Staff) The items should be listed in order by Next Auth Review Date. If the user clicks on the Client link in the list, the applicable Managed Care Authorizations or Cross Episodic Managed Care Authorizations form is displayed for the selected client. Note: If a client has both a cross episode authorization and a regular managed care authorization, the units/visits and dollars used are only applied to the regular managed care authorization. Widget SQL Statement SELECT "history_managed_care_auths"."option_id" AS "FORMID" <HIDE:FORMID>, "history_managed_care_auths"."patid" AS "ClientID" <HIDE:ClientID>, "history_managed_care_auths"."cer_uniqueid" AS "AUTHID" <HIDE:AUTHID>, "history_managed_care_auths"."episode_number" AS "Episode" <HIDE:Episode>, "history_managed_care_auths"."authorization_number" AS "Auth", STRING("patient_current_demographics"."patient_name", ' (', "patient_current_demographics"."patid", ')') AS "Client" <LINK:FORMID:ClientID:AUTHID:Episode::Client>, "history_managed_care_auths"."guarantor_name" as "MC", TO_CHAR("history_managed_care_auths"."auth_end_date",'MM-DD-YYYY') as "Expires", "history_managed_care_auths"."rem_units" as "Units", "history_managed_care_auths"."rem_visits" as "Vists", "history_managed_care_auths"."rem_dollar_amount" as "Dollars", TO_CHAR("history_managed_care_auths"."next_auth_review_date",'MM-DD-YYYY') as "Review", "history_managed_care_auths"."u_r_staff_person_name" as "Staff" FROM "SYSTEM"."history_managed_care_auths" "history_managed_care_auths" INNER JOIN "SYSTEM"."patient_current_demographics" "patient_current_demographics" ON ("history_managed_care_auths"."patid" = "patient_current_demographics"."patid" AND "history_managed_care_auths"."facility" = "patient_current_demographics"."facility") WHERE ("history_managed_care_auths"."next_auth_review_date" IS NOT NULL) AND ("history_managed_care_auths"."next_auth_review_date" >= CURRENT_DATE) AND ("history_managed_care_auths"."next_auth_review_date" <= 10 P a g e

12 CONVERT(DATE,DATEADD(dd,30,CURRENT_DATE),1)) ORDER BY "history_managed_care_auths"."next_auth_review_date" ASC Follow-up Entry The Follow Up Entry widget displays the most recent 30 contacts or follow up records by guarantor for the specified client. The following fields should be displayed in the widget: Data Entry Date Data Entry By Guarantor Name Note Type (collection) Note The items should be listed in descending order by Date Entered. Widget SQL Statement SELECT TOP 30 SYSTEM.history_follow_up_entry.data_entry_date as "Data Entry Date", SYSTEM.history_follow_up_entry.data_entry_by as "Data Entry By", SYSTEM.history_follow_up_entry.guarantor_name as "Guarantor Name", SYSTEM.history_follow_up_entry.collection_note_typ_value as "Note Type", SYSTEM.history_follow_up_entry.follow_up_note as "Note" FROM SYSTEM.history_follow_up_entry WHERE (SYSTEM.history_follow_up_entry.FACILITY=?FACILITY) AND (SYSTEM.history_follow_up_entry.PATID=?PATID) ORDER BY SYSTEM.history_follow_up_entry.data_entry_date DESC Service History The Service History widget displays the most recent 30 services entered for the specified client. The following fields should be displayed in the widget: Service Date Status (Appointment status) Start Time End Date Staff Name Program Service Code Duration 11 P a g e

13 Costs (Charge) Location (Site) The items should be listed in descending order by Service Date. Widget SQL Statement SELECT TOP 30 TO_CHAR(date_of_service,'MM-DD-YYYY') as "Date", SYSTEM.billing_tx_history.appointment_status_value as "Status", SYSTEM.billing_tx_history.appt_start_time as "Start Time", SYSTEM.billing_tx_history.appt_end_time as "End Time", SYSTEM.billing_tx_history.v_PROVIDER_NAME as "Staff Name", SYSTEM.billing_tx_history.program_value as "Program", SYSTEM.billing_tx_history.SERVICE_CODE as "Service Code", SYSTEM.billing_tx_history.duration as "Duration", SYSTEM.billing_tx_history.cost_of_service as "Cost", SYSTEM.billing_tx_history.location_value as "Location" FROM SYSTEM.billing_tx_history WHERE (SYSTEM.billing_tx_history.FACILITY=?FACILITY) AND (SYSTEM.billing_tx_history.PATID=?PATID) ORDER BY SYSTEM.billing_tx_history.date_of_service DESC Phase 2 Widgets The following widgets were developed and released in Avatar PM 2014 Update 115 and CAL-PM 2014 Update 108. Open Services by Guarantor Unbilled Services by Guarantor Billed Services by Guarantor (Last 7 Days) Billed Services by Guarantor (Current Month) Billed Services by Guarantor (Previous Month) Definitions and SQL This section provides a description of each Phase 2 widget and how it could be used on a Console View. The purpose of the widgets in this Phase are to show the number of services and expected revenue by Guarantor as services move through the billing process. This will allow billers to ensure that as services are entered in the system, they can be generally tracked as they are closed and billed to ensure all services are picked up on a bill. The Phase 2 widgets all have a complex calculation for Expected Revenue and will take longer to run than the allowed time. Because of this, the data to be displayed for these widgets will run during the nightly compile. Therefore, they cannot be refreshed throughout the day. For each of these widgets, we did include the SQL used during the nightly compile in their respective sections to aid in your testing. The Expected Revenue calculation is really geared toward contract providers; however the standard fee will be used when no contracted rate is found for the service. We intentionally did not include Gross 12 P a g e

14 Charges because for services distributed across multiple guarantors, it was including the gross charge for all guarantors, therefore inflating the gross charges. Open Services by Guarantor The Open Services by Guarantor widget shall display, by guarantor, the number of services, and expected revenue amount for all OPEN services. The following fields should be displayed in the widget: Guarantor Name Guarantor ID Number of Open Services Expected Revenue Note: The Expected Revenue will be calculated for each service as the lesser of the following: (billing.tx.charge.detail.guarantor_liability billing.tx.charge.detail.guarantor_total_payments) Maximum Amount to Distribute from Service Fee/Cross Reference definition for the applicable guarantor Note: If the Maximum Amount to Distribute is blank, then use Standard fee. The items will be listed in order by Guarantor Name. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. The SQL below is the query run during the nightly compile. SELECT billing_guar_table.guarantor_name As "Guarantor Name", billing_guar_table.guarantor_id As "Guarantor ID", SUM(collection1.Collection_Value) As "Number of Open Services", {fn CHAR(36)} SUM(collection3.Collection_Value) As "Expected Revenue" FROM (WIDGET.collection_values collection1 INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.facility = collection1.facility AND billing_guar_table.guarantor_id = collection1.collection_key)) LEFT OUTER JOIN WIDGET.collection_values collection3 ON (collection1.collection_key = collection3.collection_key AND collection1.collection_date = collection3.collection_date AND collection1.collection_freq = collection3.collection_freq AND collection1.facility = collection3.facility) WHERE collection1.collection_freq='m' AND 13 P a g e

15 collection1.collection_type = 'CountByPayorOpenService' AND collection3.collection_type = 'TotalExpectedRevenueByPayorOpenService' GROUP BY collection1.collection_key ORDER BY billing_guar_table.guarantor_name Unbilled Services by Guarantor The Unbilled Services by Guarantor widget shall display, by guarantor, the number of services, and expected revenue amount for all UNBILLED services. The following fields should be displayed in the widget: Guarantor Name Guarantor ID Number of Unbilled Services Expected Revenue Note: The Expected Revenue will be calculated for each service as the lesser of the following: (billing.tx.charge.detail.guarantor_liability billing.tx.charge.detail.guarantor_total_payments) Maximum Amount to Distribute from Service Fee/Cross Reference definition for the applicable guarantor Note: If the Maximum Amount to Distribute is blank, then use Standard fee. The items will be listed in order by Guarantor Name. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. The SQL below is the query run during the nightly compile. SELECT billing_guar_table.guarantor_name As "Guarantor Name", billing_guar_table.guarantor_id As "Guarantor ID", SUM(collection1.Collection_Value) As "Number of Unbilled Services", {fn CHAR(36)} SUM(collection3.Collection_Value) As "Expected Revenue" FROM (WIDGET.collection_values collection1 INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.facility = collection1.facility AND billing_guar_table.guarantor_id = collection1.collection_key)) LEFT OUTER JOIN WIDGET.collection_values collection3on (collection1.collection_key = collection3.collection_key AND collection1.collection_date = collection3.collection_date AND collection1.collection_freq = collection3.collection_freq AND collection1.facility = collection3.facility) WHERE collection1.collection_freq='m' AND collection1.collection_type = 'CountByPayorUnbilledService' AND collection3.collection_type = 14 P a g e

16 'TotalExpectedRevenueByPayorUnbilledService' GROUP BY collection1.collection_key ORDER BY billing_guar_table.guarantor_name Billed Services by Guarantor (Last 7 Days) The Billed Services by Guarantor (Last 7 Days) widget shall display the number of claims, and expected revenue amount by guarantor billed in the last 7 calendar days. The following fields should be displayed in the widget: Guarantor Name Guarantor ID Number of Services Expected Revenue Note: The Expected Revenue will be calculated for each service as the lesser of the following: (billing.tx.charge.detail.guarantor_liability billing.tx.charge.detail.guarantor_total_payments) Maximum Amount to Distribute from Service Fee/Cross Reference definition for the applicable guarantor Note: If the Maximum Amount to Distribute is blank, then use Standard fee. The items will be listed in order by Guarantor Name. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. The SQL below is the query run during the nightly compile. SELECT billing_guar_table.guarantor_name As "Guarantor Name", billing_guar_table.guarantor_id As "Guarantor ID", SUM(collection1.Collection_Value) As "Number of Services", {fn CHAR(36)} SUM(collection3.Collection_Value) As "Expected Revenue" FROM (WIDGET.collection_values collection1 INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.facility = collection1.facility AND 15 P a g e

17 billing_guar_table.guarantor_id = collection1.collection_key)) LEFT OUTER JOIN WIDGET.collection_values collection3 ON (collection1.collection_key = collection3.collection_key AND collection1.collection_date = collection3.collection_date AND collection1.collection_freq = collection3.collection_freq AND collection1.facility = collection3.facility) WHERE collection1.collection_freq='d' AND collection1.collection_type = 'CountByPayorClaimedService' AND collection3.collection_type = 'TotalExpectedRevenueByPayorClaimedService' AND collection1.collection_date > CONVERT(DATE,DATEADD(day,- 7,GETDATE()),1) GROUP BY collection1.collection_key ORDER BY billing_guar_table.guarantor_name Billed Services by Guarantor (Current Month) The Billed Services by Guarantor (Current Month) widget shall display the number of claims, and expected revenue amount by guarantor for services billed during the current calendar month. The following fields should be displayed in the widget: Guarantor Name Guarantor ID Number of Services Expected Revenue Note: The Expected Revenue will be calculated for each service as the lesser of the following: (billing.tx.charge.detail.guarantor_liability billing.tx.charge.detail.guarantor_total_payments) Maximum Amount to Distribute from Service Fee/Cross Reference definition for the applicable guarantor Note: If the Maximum Amount to Distribute is blank, then use Standard fee. The items will be listed in order by Guarantor Name. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. The SQL below is the query run during the nightly compile. 16 P a g e

18 SELECT billing_guar_table.guarantor_name As "Guarantor Name", billing_guar_table.guarantor_id As "Guarantor ID", SUM(collection1.Collection_Value) As "Number of Services", {fn CHAR(36)} SUM(collection3.Collection_Value) As "Expected Revenue" FROM (WIDGET.collection_values collection1 INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.facility = collection1.facility AND billing_guar_table.guarantor_id = collection1.collection_key)) LEFT OUTER JOIN WIDGET.collection_values collection3 ON (collection1.collection_key = collection3.collection_key AND collection1.collection_date = collection3.collection_date AND collection1.collection_freq = collection3.collection_freq AND collection1.facility = collection3.facility) WHERE collection1.collection_freq='m' AND collection1.collection_type = 'CountByPayorClaimedService' AND collection3.collection_type = 'TotalExpectedRevenueByPayorClaimedService' AND collection1.collection_date > CONVERT(DATE,DATEADD(day,- 1*(DATEPART(day,GETDATE())+1),GETDATE()),1) GROUP BY collection1.collection_key ORDER BY billing_guar_table.guarantor_name Billed Services by Guarantor (Previous Month) The Billed Services by Guarantor (Previous Month) widget shall display the number of claims, and expected revenue by guarantor for services billed in the previous calendar month. The following fields should be displayed in the widget: Guarantor Name Guarantor ID Number of Services Expected Revenue Note: The Expected Revenue will be calculated for each service as the lesser of the following: (billing.tx.charge.detail.guarantor_liability billing.tx.charge.detail.guarantor_total_payments) Maximum Amount to Distribute from Service Fee/Cross Reference definition for the applicable guarantor Note: If the Maximum Amount to Distribute is blank, then use Standard fee. The items will be listed in order by Guarantor Name. 17 P a g e

19 Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. The SQL below is the query run during the nightly compile. SELECT billing_guar_table.guarantor_name As "Guarantor Name", billing_guar_table.guarantor_id As "Guarantor ID", SUM(collection1.Collection_Value) As "Number of Services", {fn CHAR(36)} SUM(collection3.Collection_Value) As "Expected Revenue" FROM (WIDGET.collection_values collection1 INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.facility = collection1.facility AND billing_guar_table.guarantor_id = collection1.collection_key)) LEFT OUTER JOIN WIDGET.collection_values collection3 ON (collection1.collection_key = collection3.collection_key AND collection1.collection_date = collection3.collection_date AND collection1.collection_freq = collection3.collection_freq AND collection1.facility = collection3.facility) WHERE collection1.collection_freq='m' AND collection1.collection_type = 'CountByPayorClaimedService' AND collection3.collection_type = 'TotalExpectedRevenueByPayorClaimedService' AND collection1.collection_date > CONVERT(DATE,DATEADD(month,-1,DATEADD(day,-1*(DATEPART(day,GETDATE())+1),GETDATE())),1) AND collection1.collection_date < CONVERT(DATE,DATEADD(day,-1*(DATEPART(day,GETDATE())-1),GETDATE()),1) GROUP BY collection1.collection_key ORDER BY billing_guar_table.guarantor_name Phase 3 Widgets The following widgets were developed and released in Avatar PM 2014 Update 133. These widgets also require RADPlus 2014 Update 192. Claims Payments Posted Claim Follow-up Records Advanced Billing Rule Failed Compliance Rebilled Claims 3+ Times with an Outstanding Balance Clients with Expired Eligibility Key Performance Indicators o Gross Average Daily Revenue (MTD) o Expected Average Daily Revenue (MTD) o Gross Average Daily Revenue (YTD) o Expected Average Daily Revenue (YTD) o Days in Receivables Outstanding (DRO) o Receivables Outstanding > 90 Days Net Collections Rate Charges by Month Collections by Month Definitions and SQL This section provides a description of each Phase 3 widget and how it could be used on a Console View. It also contains the SQL statement defined for the applicable widget, when possible, so that clients may create new customized widgets that meet the billing workflow needs for their organization. For 18 P a g e

20 example, you might want to change the sort order or column ordering, add additional columns or modify the result set being returned. Claims Payment Posted The Claims Payments Posted widget shall display all remittance batches posted on current date to allow posters to balance the amount posted with the paper remittance. The widget will sum all the claims payments associated with the check number and guarantor, so the poster can manually compare the amount posted with the actual check amount. If the amounts do not match, this will alert the payment poster to review the information and correct the issue. The widget shall have a drop-down allow users to select filter option. Filter options are: Check Number and Posted by: An entry field is required to allow user to enter a value associated with the filter option selected. The following fields should be displayed in the widget: Guarantor Check Number Posting Date Receipt Date Posted By Amount Posted The items in the list should be listed by Receipt Date. Note: This widget will only include payments for paper remittance and will exclude 835 and deposits from the list. Widget SQL Statement This widget contains a filter which can t be replicated by creating a new widget, however, we are including the SQL for those clients who want to create a customized Claims Posted Widget without filtering capabilities. 19 P a g e

21 SELECT %NOLOCK billing_pay_adj_history.guarantor_id, billing_pay_adj_history.check_number, billing_pay_adj_history.date_of_payment,billing_pay_adj_history.date_of_receipt, billing_pay_adj_history.data_entry_user_id, billing_pay_adj_history.data_entry_user_name, SUM(billing_pay_adj_history.payment_amount) As Payment FROM SYSTEM.billing_pay_adj_history billing_pay_adj_history INNER JOIN SYSTEM.billing_posting_codes billing_posting_codes ON (billing_posting_codes.posting_code = billing_pay_adj_history.payment_type_code AND billing_posting_codes.facility = billing_pay_adj_history.facility) WHERE billing_pay_adj_history.facility=? AND NOT(billing_pay_adj_history.check_number IS NULL) AND billing_posting_codes.posting_type_code = 'PAY' AND NOT(billing_pay_adj_history.option_id = 'BILLING207' OR billing_pay_adj_history.option_id = 'BILLING39') AND billing_pay_adj_history.data_entry_date = CONVERT(DATE,GETDATE(),1) GROUP BY billing_pay_adj_history.guarantor_id, billing_pay_adj_history.check_number, billing_pay_adj_history.date_of_payment, billing_pay_adj_history.date_of_receipt, billing_pay_adj_history.data_entry_user_id ORDER BY billing_pay_adj_history.date_of_receipt Claim Follow-up The Claim Follow-up Records widget shall display all claims for the selected guarantor that have a claim follow up record, but have not yet been flagged for electronic rebilling (i.e. the record does not have Claim Submission Reason Code selected). This widget will only include records that were submitted via an 837, regardless of how the remittance was received. The widget shall have a drop-down list to allow users to filter by: A specified Guarantor or All A specified Denial Reason or All. All Guarantors and Denial Reasons will display by default. The following fields should be shown in the widget: Guarantor Client Name (Last, First) Client ID Program Claim # Service Date CPT Denial Reason (Code and Description) The items should be listed in order by Guarantor, Client Name Client ID, and Program. If a user double clicks on a record in the list, the Claim Follow up form for the selected record shall be displayed. 20 P a g e

22 Widget SQL Statement This widget contains a filter which can t be replicated by creating a new widget, however, we are including the SQL for those clients who want to create a customized Claim Follow-up Widget without filtering capabilities. SELECT %NOLOCK claim_follow_up.patid, claim_follow_up.episode_number, patient_current_demographics.patient_name, claim_follow_up.guarantor_id, billing_guar_table.guarantor_name, claim_follow_up.claim_number, billing_tx_history.date_of_service, claim_follow_up.den_reas_835_code, claim_follow_up.den_reas_835_value_long, billing_tx_history.join_to_tx_history, billing_tx_history.service_code, billing_tx_history.duration, billing_tx_history.duration, billing_tx_history.program_code, billing_tx_history.program_value FROM ((((SYSTEM.claim_follow_up claim_follow_up INNER JOIN SYSTEM.claim_follow_up_svcs claim_follow_up_svcs ON (claim_follow_up_svcs.patid = claim_follow_up.patid AND claim_follow_up_svcs.den_stuff = claim_follow_up.den_stuff AND claim_follow_up_svcs.facility = claim_follow_up.facility)) INNER JOIN SYSTEM.billing_tx_history billing_tx_history ON (billing_tx_history.patid = claim_follow_up_svcs.patid AND billing_tx_history.join_to_tx_history = claim_follow_up_svcs.join_to_tx_history AND billing_tx_history.facility = claim_follow_up_svcs.facility)) INNER JOIN SYSTEM.patient_current_demographics patient_current_demographics ON (patient_current_demographics.patid = claim_follow_up.patid AND patient_current_demographics.facility = claim_follow_up.facility)) INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.guarantor_id = claim_follow_up.guarantor_id AND billing_guar_table.facility = claim_follow_up.facility)) LEFT OUTER JOIN SYSTEM.billing_rebill_tx_assign billing_rebill_tx_assign ON (billing_rebill_tx_assign.patid = claim_follow_up.patid AND billing_rebill_tx_assign.claim_number = claim_follow_up.claim_number AND billing_rebill_tx_assign.join_to_tx_history= claim_follow_up_svcs.join_to_tx_history AND billing_rebill_tx_assign.facility = claim_follow_up.facility) WHERE claim_follow_up.facility=? AND billing_rebill_tx_assign.id IS NULL ORDER BY billing_guar_table.guarantor_name, patient_current_demographics.patient_name, claim_follow_up.patid, billing_tx_history.program_value Advanced Billing Rule Failed Compliance The Advanced Billing Rule Failed Compliance widget shall display all the services that failed an advanced billing rule that stops the claim from being billed during the billing process. The widget shall have a drop-down list to allow users to filter by a specified Failed Reason or All. All Failed Reasons will display by default. The following fields should be displayed in the widget: 21 P a g e

23 Client Name (Last, First) Client ID Service Date CPT Guarantor Number of Units Program Policy Number Practitioner Practitioner NPI Dx Code Rule Description Failed Reason The items should be listed in order by Client Name Client ID, and Guarantor. Widget SQL Statement This widget contains a filter which can t be replicated by creating a new widget, however, we are including the SQL for those clients who want to create a customized Advanced Billing Rule Failed Compliance without filtering capabilities. SELECT %NOLOCK billing_tx_failed_compliance.patid, patient_current_demographics.patient_name, billing_tx_history.date_of_service, billing_tx_failed_compliance.guarantor_id, billing_tx_failed_compliance.guarantor_name, billing_tx_history.units_of_service, billing_tx_history.program_code, billing_tx_history.program_value, billing_tx_history.provider_id, billing_tx_history.v_provider_name, billing_tx_failed_compliance.v_patient_svc_diagnosis_code, billing_tx_failed_compliance.v_patient_svc_diagnosis_value, billing_tx_failed_compliance.fail_reason_code, billing_tx_failed_compliance.fail_reason_value, billing_tx_history.service_code, billing_tx_history.duration, billing_tx_failed_compliance.join_to_tx_history, billing_tx_history.episode_number, billing_tx_failed_compliance.v_rule_description FROM (SYSTEM.billing_tx_failed_compliance billing_tx_failed_compliance INNER JOIN SYSTEM.billing_tx_history billing_tx_history ON (billing_tx_history.patid = billing_tx_failed_compliance.patid AND billing_tx_history.join_to_tx_history = billing_tx_failed_compliance.join_to_tx_history AND billing_tx_history.facility = billing_tx_failed_compliance.facility)) INNER JOIN SYSTEM.patient_current_demographics patient_current_demographics ON (patient_current_demographics.patid = billing_tx_failed_compliance.patid AND patient_current_demographics.facility = billing_tx_failed_compliance.facility) WHERE billing_tx_failed_compliance.facility=? ORDER BY patient_current_demographics.patient_name, billing_tx_failed_compliance.patid, billing_tx_failed_compliance.guarantor_name 22 P a g e

24 Rebilled Claims 3+ Times with an Outstanding Balance The Rebilled Claims 3+ Times with an Outstanding Balance widget shall display all claims that have been billed at least 3 times and still have a balance and no payment or write off recorded. These are claims that need to be further investigated before the claim is submitted again or written off. Services with only a contractual adjustment will be displayed in the widget. The widget shall have a drop-down list to allow users to filter by guarantor or All. All Guarantors will display by default. The following fields should be shown in the widget: Client Name (Last, First) Client ID Episode Guarantor (Name and ID) Service Date Service Code Bill Date Claim # Original Claim # The items should be listed in order by Client Name Client ID, Guarantor Name, Service Date, Service Code, Bill Date, and Claim Number. Widget SQL Statement This widget contains a filter which can t be replicated by creating a new widget, however, we are including the SQL for those clients who want to create a customized Rebilled Claims 3+ Times with an Outstanding Balance Widget without filtering capabilities. SELECT %NOLOCK billing_rebill_claim_hist1.rebill_claim_number, billing_claim_history_tx_detail.patid, patient_current_demographics.patient_name, billing_claim_history_tx_detail.episode_number, billing_claim_history_tx_detail.guarantor_id, billing_guar_table.guarantor_name, billing_tx_history.date_of_service, billing_tx_history.service_code, billing_claim_history_tx_detail.claim_date FROM ((((SYSTEM.billing_rebill_claim_hist billing_rebill_claim_hist1 INNER JOIN 23 P a g e

25 SYSTEM.billing_claim_history_tx_detail billing_claim_history_tx_detail ON (billing_claim_history_tx_detail.claim_number = billing_rebill_claim_hist1.rebill_claim_number AND billing_claim_history_tx_detail.facility = billing_rebill_claim_hist1.facility)) INNER JOIN SYSTEM.billing_tx_history billing_tx_history ON (billing_tx_history.patid = billing_claim_history_tx_detail.patid AND billing_tx_history.join_to_tx_history = billing_claim_history_tx_detail.join_to_tx_history AND billing_tx_history.facility = billing_claim_history_tx_detail.facility)) INNER JOIN SYSTEM.patient_current_demographics patient_current_demographics ON (patient_current_demographics.patid = billing_claim_history_tx_detail.patid AND patient_current_demographics.facility = billing_claim_history_tx_detail.facility)) INNER JOIN SYSTEM.billing_guar_table billing_guar_table ON (billing_guar_table.guarantor_id = billing_claim_history_tx_detail.guarantor_id AND billing_guar_table.facility = billing_claim_history_tx_detail.facility)) LEFT OUTER JOIN (SYSTEM.billing_pay_adj_history billing_pay_adj_history INNER JOIN SYSTEM.billing_posting_codes billing_posting_codes ON (billing_posting_codes.facility = billing_pay_adj_history.facility AND billing_posting_codes.posting_code = billing_pay_adj_history.payment_type_code AND (billing_posting_codes.posting_type_code = 'PAY' OR billing_posting_codes.is_this_a_contractual_code='n'))) ON (billing_pay_adj_history.patid = billing_claim_history_tx_detail.patid AND billing_pay_adj_history.join_to_tx_history = billing_claim_history_tx_detail.join_to_tx_history AND billing_pay_adj_history.join_to_payment_history = billing_claim_history_tx_detail.join_to_payment_history AND billing_pay_adj_history.facility = billing_claim_history_tx_detail.facility) WHERE billing_pay_adj_history.unique_row_id2 IS NULL AND (SELECT billing_rebill_claim_hist2.original_claim_number FROM SYSTEM.billing_rebill_claim_hist billing_rebill_claim_hist2 WHERE billing_rebill_claim_hist2.original_claim_number = billing_rebill_claim_hist1.rebill_claim_number) IS NULL ORDER BY patient_current_demographics.patient_name, billing_claim_history_tx_detail.patid, billing_guar_table.guarantor_name, billing_tx_history.date_of_service, billing_claim_history_tx_detail.claim_date, billing_rebill_claim_hist1.rebill_claim_number Clients with Expired Eligibility The Clients with Expired Eligibility widget shall display all clients who have a service with a date after the expiration date for the payer. Records will be removed from the list when the current date is over 30 days past the expiration date. This shall only include applicable financial classes that are submitted to payers (i.e. Do not include self-pay). This will include financial eligibility, cross episodic financial eligibility, and family financial eligibility records. The widget shall have a drop-down list to allow users to filter by Guarantor or All. All guarantors will display by default. The widget shall have a drop-down list to allow users to filter by Programs or All. All programs will display by default. The following fields should be displayed in the widget: Client Name (Last, First) Client ID Episode # 24 P a g e

26 Guarantor Program Policy # Coverage Expiration Date The items should be listed in order by Client Name, Client ID, and Guarantor. If a user double clicks on a record in the list, the Financial Eligibility, Cross Episodic Financial Eligibility, or Family Financial Eligibility form for the selected client shall be displayed. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. Any meaningful SQL cannot be provided. Key Performance Indicators The Key Performance Indicators widget will display the values for several key performance indicators that every organization should be monitoring. They include the following: Gross Average Daily Revenue (MTD) Expected Average Daily Revenue (MTD) Gross Average Daily Revenue (YTD) Expected Average Daily Revenue (YTD) Days in Receivables Outstanding (DRO) Receivables Outstanding > 90 Days The values in this widget will be included in the nightly compiles and will be updated daily. Users will not be able to refresh these due to the high volume of data that is processed by this widget. 25 P a g e

27 Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. Any meaningful SQL cannot be provided. Gross Average Daily Revenue (MTD) The Gross Average Daily Revenue (MTD) widget shall display a numerical value of the calculated month-to-date gross average daily revenue. The calculation shall be: Gross Charges Entered # of Days Elapsed in Current Month Gross Charges Entered should be calculated as the Gross Charges dropped/entered during current month. Expected Average Daily Revenue (MTD) The Expected Average Daily Revenue (MTD) widget shall display a numerical value of the calculated month-to-date average daily revenue based upon expected revenue. The calculation shall be: Expected Payment # of Days Elapsed in Current Month Expected Payment should be calculated as the total expected payment for the charges dropped/entered during current month. Gross Average Daily Revenue (YTD) The Gross Average Daily Revenue (YTD) widget shall display a numerical value of the calculated yearto-date gross average daily revenue. The calculation shall be: Gross Charges Entered # of Days Elapsed in Current Year Gross Charges Entered should be calculated as the Gross Charges dropped/entered during current month. Expected Average Daily Revenue (YTD) The Expected Average Daily Revenue (YTD) widget shall display a numerical value of the calculated year-to-date average daily revenue based upon expected revenue. 26 P a g e

28 The calculation shall be: Expected Payment_ # of Days Elapsed in Current Year Expected Payment should be calculated as the total expected payment for the charges dropped/entered during current month. Days in Receivables Outstanding (DRO) The Days in Receivables Outstanding (DRO) widget shall display the current average number of days in A/R. Days in receivables outstanding (DRO). The best overall indicator of billing performance, DRO must be measured consistently in order to be meaningful. Calculate DRO by adding your current total receivables outstanding and the sum of your credit balances. (Adjusting for credits is important, as credits offset receivables, thus masking performance.) Divide that figure by your average daily charge. You can calculate your average daily charge by taking the previous three months worth of charges, and dividing by 90. Although you can determine the average daily charge based on 365 days, using 90 days accounts for seasonality, growth and other fluctuations in business. Best practice of days should be notated in the widget. Any value less than 50 days should be displayed in green. Any value between 50 and 60 days should be displayed in yellow. Any value greater than 60 should be displayed in red. Receivables Outstanding > 90 Days The Receivables Outstanding > 90 Days widget shall display the percentage of all claims with an A/R balance where the A/R balance is greater than 90 days. The calculation should done as follows: Calculate by adding your current total receivables outstanding over and the sum of your credit balances over 90 days outstanding. (Adjusting for credits is important, as credits offset receivables, thus masking performance.) Divide that figure total accounts receivable adjusting for credits. Best practice of 20 % should be notated in the widget. Any value of 20% or less should be displayed in green. Any value between20 % and 25% should be displayed in yellow. Any value of 25% or greater should be displayed in red. Net Collections Rate The Net Collections Rate widget shall display a graphical view of the net collections rate each month for the most current 12-month period (based upon date of service) in a bar chart. Although it s good to measure your collections as a percent of gross charges, you can t use the result to judge the 27 P a g e

29 performance of your organization. Because every organization s fee schedules, payer mix, and contracts differ, your gross collection rate also will be different. To account for this variance, you should net, also known as adjusted, collection rate. For each dollar your organization is allowed to collect, what percentage of it do you actually collect? The net collection rate reflects your ability to collect the contracted allowable rate, which is a combination of payments made from both the payer and the guarantor. The calculation should done as follows: Total Payments Expected Revenue The collections will be applied to the month in which the service was rendered. For billing performance monitoring, we need to compare apples to apples. Organizations need to know how much of the services rendered in a given month were actually paid. For example, if an organization saw 500 patients in October and generated $100,000 worth of charges for those visits, they need to know how much of the $100,000 was paid so far, regardless of when the money was posted. Any month that has a collection rate over 95% shall be highlighted in green. Any month that has a collection rate between 91% and 95% shall be highlighted in yellow. Any month that has a collection rate less than 91% shall be highlighted in red. Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. Any meaningful SQL cannot be provided. Charges by Month The Charges by Month widget shall display a graphical view of gross charges and expected charges submitted during the calendar month in a Bar Chart for the latest 12 month period. Charges should be calculated as the Gross Charges dropped/entered during each calendar month. 28 P a g e

30 Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. Any meaningful SQL cannot be provided. Collections by Month The Collections by Month widget shall display a graphical view of payments posted during the calendar month in a Bar Chart for the latest 12 month period. Collections should be actual payments received for the charges dropped/entered during the applicable month. 29 P a g e

31 Widget SQL Statement Due to the complexity of this widget, the SQL had to be added to the Nightly Compile. Any meaningful SQL cannot be provided. Console Home Views In RAD 2014 Enhancement #85, Netsmart released the ability to create a Console Home View. A Console Home View is a user Home View that has been assigned multiple views. Users can switch views by clicking on the appropriate view button. Widgets can be added to the views and organized workflow. Also, separate Console Home Views can be setup and displayed based upon user roles. Create a Billing Console Below is an example of a Billing Console comprised of multiple views. In the sections below, we will provide detailed instructions to aid you in building these easy-to-use dashboards. 30 P a g e

32 31 P a g e

33 32 P a g e

34 Registry Setting You must first enable the following registry setting in order to Enable the Console Widgets and Views. RADplus->General->->->->Enable Console Widgets/Views 33 P a g e

35 Assign Access to the Console Widget Configuration Form Assign access to the Console Widget Configuration form for applicable users via the User Definition form. If the user who is adding access for the users wants to use the form, they will need to refresh the forms list first. Widget Creation There are three ways to create widgets with the myavatar design tools. You are able to leverage the Widget Wizard, Wizard Definition and Console Widget Definition. 34 P a g e

36 Widget Wizard Easily define and create widgets with the use of an easy to use wizard. Define widgets easily by selecting a table and the fields you would like to display on the widget. Identify sort columns and fields to associate with hyperlinks Once you select Submit the widget will be available for selection in the Widget Library that resides in View Definition. Widget Definition Using HTML and/or SQL statements, develop a widget to display information that is client specific or for a defined group of clients. 35 P a g e

37 Console Widget Configuration This is a new form in myavatar. Allows users to quickly create Widgets to be displayed on Console Views Select client forms with a Pre-Display Widgets will provide edit/add capabilities Edit Default Configuration 36 P a g e

38 Default the fields to display in the Widget Fields can be added, deleted or copied SQL Query Override Override the fields selected in the Edit Default Configuration Write your own Query Time Limit (seconds) 37 P a g e

39 Netsmart recommends Widgets have a time limit of 1.0 second if it will be placed on many Home Views This prevents a scenario where long running Widgets processing at the same time slows system performance. Table Widgets display with pre-display columns Rows will sort with the newest records on top Clicking on any column header will resort the table by that column (Note: This functionality is only available for widgets created via Widget Console Definition.) 38 P a g e

40 Episode selection is provided so user can filter by episode "All Episodes" will default Double-click on a row to view the form No patient lookup or pre-display needed A New Record button allows addition of data Double click row to select Allows users to select multiple forms to be used in a single Widget Add New or Open Existing 39 P a g e

41 Multiple Form Widget Multiple Form Selection - Double click on a record in the grid to display the applicable form. 40 P a g e

42 New tab labeled Site Smart Search by Site or Unit Scrolling list box of patients from that Site (Unit) Home View Widgets refresh with selected client View Definition To create a Console Home View Use the form View Definition to associate multiple views to the Home View Widgets are managed in the View Definition form when you launch the View designer. Available widgets can be assigned to a user in the User Definition, and User Role Definition forms. Widgets must be associated with a user, or user role before they can be accessed in the Home View. Once a widget is assigned to a user (or user role), the user can add the widget to their Home or Chart View. 41 P a g e

43 View Designer In the Available column, select a widget and click. These widgets can be added to the Default Role Layout section. Note: Once the new view is assigned, you can use User Role Definition to assign the view to a specific role. 42 P a g e