myAvatar Billing Widgets Console Training Guide - Updated ...api.ning.com/files/vlkw1OAAX7kUDxwq8V8oc4HpNyvFAXqvEQkzqf… · MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE Last

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



Create a Billing Console .......................................................................................................................... 30

Registry Setting ................................................................................................................................... 33

Assign Access to the Console Widget Configuration Form ................................................................. 34

Widget Creation .................................................................................................................................. 34

View Definition .................................................................................................................................... 41



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



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



"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


(("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.


• 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.



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.


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


("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.


• MR #

• Client Name (Last, First)



• 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.






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,



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.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.


• 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.








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.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.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.




• 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.


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" <=



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.


• Data Entry Date

• Data Entry By

• Guarantor Name

• Note Type (collection)

• Note

The items should be listed in descending order by Date Entered.


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.


• Service Date

• Status (Appointment status)

• Start Time

• End Date

• Staff Name

• Program

• Service Code

• Duration



• Costs (Charge)

• Location (Site)

The items should be listed in descending order by Service Date.


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


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



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.


• 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.


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



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.


• Guarantor Name

• Guarantor ID

• Number of Unbilled Services





guarantor







"Guarantor ID", SUM(collection1.Collection_Value) As "Number of Unbilled Services", {fn CHAR(36)} ||




collection3ON (collection1.Collection_Key = collection3.Collection_Key AND collection1.Collection_Date =



collection1.Collection_Type = 'CountByPayorUnbilledService' AND collection3.Collection_Type =



'TotalExpectedRevenueByPayorUnbilledService' GROUP BY collection1.Collection_Key ORDER BY


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.


• Guarantor Name

• Guarantor ID

• Number of Services





guarantor







"Guarantor ID", SUM(collection1.Collection_Value) As "Number of Services", {fn CHAR(36)} ||








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.


• Guarantor Name

• Guarantor ID






guarantor

















'TotalExpectedRevenueByPayorClaimedService' AND collection1.Collection_Date > CONVERT(DATE,DATEADD(day,-

1*(DATEPART(day,GETDATE())+1),GETDATE()),1) GROUP BY collection1.Collection_Key ORDER BY


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.


• Guarantor Name

• Guarantor ID






guarantor

















'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


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



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.


• 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.


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.



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 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.





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.





• 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.



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



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 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.



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



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.



• Client ID

• Episode #



• 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.


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.






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.


___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.


___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.




___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



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.




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.






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.






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.







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



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.



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.



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



– 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)



– 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.)



• 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



Multiple Form Widget

- Double click on a record in the grid to display the applicable form.

Multiple Form

Selection



• 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.



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.

myAvatar Billing Widgets Console Training Guide - Updated ...api.ning.com/files/vlkw1OAAX7kUDxwq8V8oc4HpNyvFAXqvEQkzqf… · MYAVATAR BILLING WIDGETS & CONSOLE TRAINING GUIDE Last

Documents