Upload
others
View
8
Download
1
Embed Size (px)
Citation preview
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.
2014
Nicki Grose
Netsmart Technologies Inc.
10/27/2014
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 1 | P a g e
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 ................................................................................................................................... 11
Service History .................................................................................................................................... 11
Phase 2 Widgets ...................................................................................................................................... 12
Definitions and SQL ................................................................................................................................. 12
Open Services by Guarantor ............................................................................................................... 13
Unbilled Services by Guarantor .......................................................................................................... 14
Billed Services by Guarantor (Last 7 Days) .......................................................................................... 15
Billed Services by Guarantor (Current Month) ................................................................................... 16
Billed Services by Guarantor (Previous Month) .................................................................................. 17
Phase 3 Widgets ...................................................................................................................................... 18
Definitions and SQL ................................................................................................................................. 18
Claims Payment Posted ....................................................................................................................... 19
Claim Follow-up .................................................................................................................................. 20
Advanced Billing Rule Failed Compliance ........................................................................................... 21
Rebilled Claims 3+ Times with an Outstanding Balance ..................................................................... 23
Clients with Expired Eligibility ............................................................................................................. 24
Key Performance Indicators ................................................................................................................ 25
Net Collections Rate ............................................................................................................................ 27
Charges by Month ............................................................................................................................... 28
Collections by Month .......................................................................................................................... 29
Console Home Views .................................................................................................................................. 30
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 2 | P a g e
Create a Billing Console .......................................................................................................................... 30
Registry Setting ................................................................................................................................... 33
Assign Access to the Console Widget Configuration Form ................................................................. 34
Widget Creation .................................................................................................................................. 34
View Definition .................................................................................................................................... 41
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 3 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 4 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 5 | P a g e
"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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 6 | P a g e
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)
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 7 | P a g e
• 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,
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 8 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 9 | P a g e
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:
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 10 | P a g e
• 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" <=
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 11 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 12 | P a g e
• 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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 13 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 14 | P a g e
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 =
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 15 | P a g e
'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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 16 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 17 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 18 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 19 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 20 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 21 | P a g e
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:
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 22 | P a g e
• 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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 23 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 24 | P a g e
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 #
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 25 | P a g e
• 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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 26 | P a g e
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 year-
to-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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 27 | P a g e
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 45-50 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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 28 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 29 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 30 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 33 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 34 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 35 | P a g e
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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 36 | P a g e
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
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 37 | P a g e
– 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)
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 38 | P a g e
– 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.)
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 39 | P a g e
• 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
• Allows users to select multiple forms to be used in a single Widget
– Add New or Open Existing
Double click row to
select
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 40 | P a g e
Multiple Form Widget
- Double click on a record in the grid to display the applicable form.
Multiple Form
Selection
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 41 | P a g e
• 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.
MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE
Last Updated: 10/27/2014 42 | P a g e
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.