Avatar PM 2022 Quarterly Release 2022.04 Acceptance Tests

Last updated
Save as PDF

Update 19 Summary \| Details Enhanced internal utilities Scenario 1: File Import - [Support Only] Appointment Scheduling/Mark Appointments Posted Steps Internal Testing Only	Topics • Appointment Management
Update 53 Summary \| Details Follow Up Entry (Edit) - Follow Up Notes report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors Financial Eligibility Create Interim Billing Batch File Electronic Billing Follow Up Entry Follow Up Entry (Edit) Dictionary Update (PM) Scenario 1: Follow Up Entry (Edit) - Follow Up Notes Report - Validating notes filed through 'Follow Up Entry' by multiple login users Specific Setup: Identify two login users for the test system. Note the login information for both. Guarantors/Payors: An existing guarantor is identified to be assigned as the primary guarantor. Note the guarantor's code / value / financial class. Dictionary Update: File - Client Data Element - Collection Note Type - 1 to 2 dictionary codes/values are added. Note the Dictionary codes/values. Admission: A new client is admitted, or an existing client is identified. Note the client id, admission date, and admission program. Financial Eligibility: The guarantor identified above is assigned to the client as the primary guarantor. Diagnosis: The diagnosis record is created for the client. Client Charge Input: 2 or 3 services are rendered to the client. Note the service date and service code. Client Ledger: The services distributed to the guarantor assigned to the client. Close Charges: The services rendered to the client are closed. Create Interim Billing Batch: Create an interim billing batch to cover client/services/guarantor. Electronic Billing: Services are claimed. Steps Login as a one of the login users identified above. Open the 'Follow Up Entry' form. Enter/select client for Follow Up Entry in 'Client ID' field. Navigate to 'Follow Up Entry' section of form. Enter/select values for 'Contact Date', 'Contact Time', 'Episode Number', 'Guarantor', 'Guarantor Representative' and 'Collection Note Type' fields. Enter value for 'Follow Up Note' field, and any other desired fields. Click [File Follow Up Entry]. Verify 'Filing Completed' dialog is presented. Click 'OK' button to close dialog. Navigate to 'Review Follow Up Entries' section of form. Ensure that Follow Up Entry filed in form is displayed in the 'Previous Follow Up Notes' text display field. Close the form. Log out from the system. Login as the other login user identified above. Open the 'Follow Up Entry' form. Enter/select the same client for Follow Up Entry in 'Client ID' field. Navigate to 'Follow Up Entry' section of form. Enter/select values for 'Contact Date', 'Contact Time', 'Episode Number', 'Guarantor', 'Guarantor Representative' and 'Collection Note Type' fields. Enter value for 'Follow Up Note' field, and any other desired fields. Click [File Follow Up Entry]. Verify 'Filing Completed' dialog is presented. Click 'OK' button to close dialog. Navigate to 'Review Follow Up Entries' section of form. Ensure that Follow Up Entry filed in form is displayed in the 'Previous Follow Up Notes' text display field. Close the form. Open the 'Follow Up Entry (Edit)' form. In the 'Client ID' field, enter the client's name or ID, and select. In the 'Filter By Guarantor(s)' field, select the guarantor. For the 'Filter By Guarantor Representative(s)' field, select the guarantor representatives. In the 'Filter By Episode(s)' field, select the client episodes. In the 'Filter By Collection Note Type(s)' field, select the collection note types. The 'Previous Follow Up Notes' field displays an overview of the client’s follow up notes. Click [Print Current Follow Up Notes]. Verify it generates a report that details the client's current follow up notes. Click [Follow Up Notes Report]. Verify it generates follow up notes report that details all notes for the client. Close the report. Close the form. Scenario 2: Follow Up Entry (Edit) - Follow Up Notes Report - Validating notes filed through 'Follow Up Entry' by single login user Specific Setup: Guarantors/Payors: An existing guarantor is identified to be assigned as the primary guarantor and the financial class is not a self pay. Note the guarantor code / value / financial class. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Dictionary Update: File - Client Data Element - Collection Note Type - 1 to 2 dictionary codes/values are added. Note the Dictionary codes/values. Admission: A new client is admitted, or an existing client is identified. Note the client id, admission date and admission program. Financial Eligibility: The guarantor identified above is assigned to the client as the primary guarantor. Diagnosis: The diagnosis record is created for the client. Client Charge Input: 2 or 3 service are rendered to the client such that it comes prior to coverage effective date of the primary guarantor. Note the service date and service code. Client Ledger: The services distributed to the self pay guarantor. Close Charges: The services rendered to the client are closed. Create Interim Billing Batch: Create an interim billing batch to cover client/services/guarantor. Electronic Billing: Services are claimed. Steps Open the 'Follow Up Entry' form. Enter/select client for Follow Up Entry in 'Client ID' field. Navigate to 'Follow Up Entry' section of form. Enter/select values for 'Contact Date', 'Contact Time', 'Episode Number', 'Guarantor', 'Guarantor Representative' and 'Collection Note Type' fields. Enter value for 'Follow Up Note' field, and any other desired fields. Click [File Follow Up Entry]. Verify 'Filing Completed' dialog is presented. Click 'OK' button to close dialog. Navigate to 'Review Follow Up Entries' section of form. Ensure that Follow Up Entry filed in form is displayed/included in the 'Previous Follow Up Notes' text display field. Close the form. Open the 'Follow Up Entry (Edit)' form. In the 'Client ID' field, enter the client's name or ID, and select. In the 'Filter By Guarantor(s)' field, select the guarantors. For the 'Filter By Guarantor Representative(s)' field, select the guarantor representatives. In the 'Filter By Episode(s)' field, select the client episodes. In the 'Filter By Collection Note Type(s)' field, select the collection note types. The 'Previous Follow Up Notes' field displays an overview of the client’s follow up notes. Click [Print Current Follow Up Notes]. Verify it generates a report that details the client's current follow up notes. Click [Follow Up Notes Report]. Verify it generates follow up notes report that details all notes for the client. Close the report. Close the form.	Topics • Follow Up • NX
Update 58 Summary \| Details Prevent use of certain special characters in the 'Financial Eligibility' form. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Financial Eligibility Web Service Scenario 1: Validating address fields in Financial Eligibility form to prevent entries with certain special characters. Steps Open the 'Financial Eligibility' form to add a new guarantor to a test client. Complete required fields. Enter a value containing a special character (List of special characters not permitted: `!$%^~@) in any of the following fields: Guarantor's Address - Line 1 Guarantor's Address - Line 2 Guarantor's Address - City Subscriber Address - Street Line 1 Subscriber Address - Street Line 2 Subscriber Address - City Subscriber Employer 's Add - Street Subscriber Employer 's Add - City As the user tabs or clicks away from the field, the following message will display: "<Field Name> should not contain any of the following symbols: 'backtick', exclamation, dollar sign, percent, asterisk, caret, tilde, at sign." Click [OK] on the message. The invalid special characters will be removed from the field. Type the correct information into the field. No further messages regarding special characters will display. Click [Submit]. Scenario 2: Financial Eligibility Web Service - validate special characters are not permitted in select fields.* Specific Setup: User must have knowledge of web service set and use in SoapUI or other web service tool. Steps Consume the web service for 'Financial Eligibility': WEBSVC.FinancialEligibility.cls Open the 'AddFinancialElig' request. Populate required fields: SystemCode UserName Password Set the following fields to have at least one special character from the list: ` ! $ % * ^ ~ @. Example: 1 Maple Lane@Green Street Guarantor's Address - Line 1 Guarantor's Address - Line 2 Guarantor's Address - City Subscriber Address - Street Line 1 Subscriber Address - Street Line 2 Subscriber Address - City Subscriber Employer 's Add - Street Subscriber Employer 's Add - City Complete other required fields. Click [Send]. Verify the Response contains the following for each line item from above: <Message>Web service request failed with error : Guarantor: 1 - GuarantorsAddress1 contains an invalid character. Guarantor: 1 - GuarantorsAddress2 contains an invalid character. Guarantor: 1 - GuarantorsAddressCity contains an invalid character. Guarantor: 1 - SubscriberAddress1 contains an invalid character. Guarantor: 1 - SubscriberAddress2 contains an invalid character. Guarantor: 1 - SubscriberCity contains an invalid character. Correct the issues by removing the invalid special characters from each field. Click [Send]. Verify the Response message is now "<Confirmation>Unique ID: 1075~1</Confirmation> <Message>Financial Eligibility web service has been filed successfully.</Message>" Open the 'Financial Eligibility' form for the same client. Verify the data sent in the Web Service is correct.	Topics • NX • Financial Eligibility • Web Services
Update 73 Summary \| Details Site Specific Section Modeling - Demographic fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (PM) Discharge Call Intake Scenario 1: Site Specific Section Modeling - Validation of Site Specific Demographic fields Steps Open the 'Site Specific Section Modeling' form. Select "PATIENT510 (Admission) Demographics" in the drop-down. Click [OK]. Select the 'Prompt Definition' section. Select desired site specific prompt to add to the 'Demographic' section of the form. Note the name of the fields. Select 'No' in the 'Exclude from Data Collection Instrument' field. Submit the form. Open the 'Admission' or 'Admission(Outpatient)' form. Select the 'Demographics' section of the form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Discharge' form. Go to the 'Demographics' section of the 'Discharge' form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Call Intake' form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Site Specific Section Modeling' form. Select "PATIENT510 (Admission) Demographics" in the drop-down. Click [OK]. Select the 'Prompt Definition' section. Select desired site specific prompt to remove from the 'Demographic' section of the form. Note the name of the fields. Select 'Yes' in the 'Exclude from Data Collection Instrument' field. Submit the form. Open the 'Admission' or 'Admission(Outpatient)' form. Select the 'Demographics' section of the form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form. Open the 'Discharge' form. Go to the 'Demographics' section of the 'Discharge' form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form. Open the 'Call Intake' form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form.	Topics • Site Specific Section Modeling • NX
Update 75 Summary \| Details File Import - Client Charge Input group services Scenario 1: File Import Client Charge Input - Remove group # requirement on group services Specific Setup: Create a Client Input Charge import file that has a group service code with the group number omitted from field 7. Create a Client Input Charge import file that has a group service code with the group number populated in field 7. Steps Open the "File Import" form. Import a "Client Charge Input" type of file. Use the file that has a row for a group service and the group number is omitted form field 7 of the row. Select "Upload New File" and process that action. Browse to the location the file resides on the server and select the desired file to upload. Select the "Compile/Validation" action and process that action. Validate that a message indicating the file "Compiled" is received. Select the "Print File" action and validate the contents of the data in the file. Select the "Post" action to create new services based on data in the import file. Open the "Client Ledger" and validate the service created. Open the "File Import" form. Import a "Client Charge Input" type of file. Use the file that has a row for a group service and the group number is populated in field 7 of the row. Select "Upload New File" and process that action. Browse to the location the file resides on the server and select the desired file to upload. Select the "Compile/Validation" action and process that action. Validate that a message indicating the file "Compiled" is received. Select the "Print File" action and validate the contents of the data in the file. Select the "Post" action to create new services based on data in the import file. Open the "Client Ledger" and validate the service created. Client Charge Input - Prolonged services Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (PM) Client Charge Input Scenario 1: Client Charge Input - Service Duration < Duration Range in the Fee record. Specific Setup: Registry setting "Enable Multiple Add-On Code Per Primary" must be enabled. Using "Dictionary Update", add an extended data dictionary element (295) Allow Multiple Add-On Code Definition" set to "Yes" to the Dictionary Code "5" in the "Other Tabled Files" file. Using "Service Codes", add an add-on code. Set it up as "User Defined" code. Assign "Other" to the "Service Code Type". Using "Service Codes", add a primary service code, set up as "User Defined". Assign "Other" to the "Service Type Code". Using "Service Fee/Cross Reference", set up fees for the new service codes created for this test. Admit a new client or select an existing one with one outpatient episode. Steps Open the "Client Charge Input" form. Add a primary service for the test client. Set "Duration (Minutes)" to a value of "54" or less. Validate the primary code is populated with an add-on code in the "Selected Add-On Services" text field. Submit the service. Open the "Client Ledger" form. Validate one service was created. Scenario 2: Client Charge Input - Service Duration > Duration Range in the Fee record. Specific Setup: Registry setting "Enable Multiple Add-On Code Per Primary" must be enabled. Using "Dictionary Update", add an extended data dictionary element (295) Allow Multiple Add-On Code Definition" set to "Yes" to the Dictionary Code "5" in the "Other Tabled Files" file, Using "Service Codes", add an add-on code. Set it up as "User Defined" code. Assign "Other" to the "Service Code Type". Using "Service Codes", add a primary service code, set up as "User Defined". Assign "Other" to the "Service Type Code". Using "Service Fee/Cross Reference", set up fees for the new service codes created for this test. Admit a new client or select an existing one with one outpatient episode. Steps Open the "Client Charge Input" form. Add a primary service for the test client. Set "Duration (Minutes)" to a value greater than or equal to "55". Validate the primary code has an add-on code in the "Selected Add-On Services" text field. Submit the service. Open the "Client Ledger" form. Validate two services were created. One for 54 units and the other for the number of units over 54. Disclosure Management - Discharge data Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Disclosure Management Disclosure Management Configuration Discharge Scenario 1: Disclosure Management - Field Validations Specific Setup: Using the "Disclosure Management Configuration" form, set up the first page image, watermark, and forms to associate to set up Disclosure Management. Steps Open the "Disclosure Management" form. Populate all required and desired fields in the request, authorization, and the disclosure sections. Select "Electronic" in the "Disclosure Method" field. Click the "Process" button. Validate the appropriate items are included in the disclosure packet. Click "Disclose". Click the PDF download icon. Browse to the location to store the file on the server. Provide the file name with a .pdf file extension. Click the "Cancel" button. Click "Submit". Scenario 2: Disclosure Management - Discharged Client Specific Setup: Using the "Configuration Management Configuration" form, configure the disclosure management form. Admit or select a test client. Steps Using the "Diagnosis" form, give the client or validate the client has a diagnosis. Open the "Discharge" form and discharge the client. Ensure the "Discharge Remarks/Comments" is populated. Ensure the "Hospital Discharge Instructions" is populated. Submit the data. Open the "Disclosure Management" form. Populate the Request section, Authorization section and Disclosure sections. Populate the "Disclosure Date" and "Disclosure Time" fields. On the preview of the disclosure packet, view the Discharge form and validate the "Discharge Remarks/Comments" and "Hospital Discharge Instructions" is included in the output. Disclosure Management - Request Information Specify Other Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Disclosure Management Disclosure Management Configuration Scenario 1: Disclosure Management - Field Validations Specific Setup: Using the "Disclosure Management Configuration" form, set up the first page image, watermark, and forms to associate to set up Disclosure Management. Steps Open the "Disclosure Management" form. Populate all required and desired fields in the request, authorization, and the disclosure sections. Select "Electronic" in the "Disclosure Method" field. Click the "Process" button. Validate the appropriate items are included in the disclosure packet. Click "Disclose". Click the PDF download icon. Browse to the location to store the file on the server. Provide the file name with a .pdf file extension. Click the "Cancel" button. Click "Submit". Scenario 2: Disclosure Management - Request Information - Specify Other Specific Setup: Using the "Disclosure Management Configuration" form, configure the "Disclosure Management" form. Admit or select a test client. Steps Open the "Disclosure Management" form. Populate the fields on the "Request" section of the form. Ensure to populate the "Request Information - Specify Other" has multiple lines of data in the text box. Click "Submit" to save the data. Return to the Pre-Display. Add an additional disclosure row for the same client. Populate the fields on the "Request" section of the form. Ensure to populate the "Request Information - Specify Other" has 1 line of data in the text box. Return to the Pre-Display. Edit the 2nd row added during this session. Validate the "Request Information - Specify Other" only has one row of data. Submit the form. Return to the Pre-Display. Edit the 1st row added during this session. Validate the "Request Information - Specify Other" only has multiple rows of data. Submit the form.	Topics • Client Charge Input • File Import • Disclosure • Discharge
Update 78 Summary \| Details myHealthPointe Payments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (CFMS) Credit Card Configuration Posting/Adjustment Codes Definition Deposit Entry System Task Scheduler CareFabric Monitor Front Desk Dictionary Update (PM) Payment Acknowledgement Scenario 1: Credit Card Configuration Specific Setup: Please contact your Netsmart representative for assistance to enable credit card functionality. The following registry setting has a value of 'Y': Avatar PM--->Billing->Remittance Processing->->->Enable Credit Card Processing. General Information regarding credit card payments: At the current time, payments can be accepted from 'Deposit Entry', 'Front Desk - Check in' section only, and 'Scheduling Calendar - Check in' section only. In the 'Credit Care Device Setup' section: Note: Only one device can have a value of 'Yes' in 'Is this a Back Office MID?' and a value of 'Yes' in 'Active Device'. Note: Each device must have a unique 'Device Name'. Note: No grid rows may be deleted. Use the 'Active Device' field to set the value to 'Yes' or 'No'. Devices with either value will continue to display in the grid. Note: The grid displays inactive devices first, followed by active devices sorted by 'Device Name'. Note: The grid may be sorted by double clicking any column header in the grid. Note: The value of any submitted field, except device name, may be changed by clicking on the row in the grid and changing the value in the data entry fields. No changes can be made to a submitted device name. If needed, make the device inactive and create a new device. Note: The following special characters may not be used in the 'Device Name', 'Merchant ID (MID)', or 'Device Serial Number' fields: & - ampersand < - less than > - greater than ' - single quote " - double quote Steps Open 'Credit Card Configuration’. Enter the desired value in 'Populate Receipt Number with Credit Card Payment Reference Number'. Enter the desired value in 'Default User ID for myHealthPointe Credit Card and ACH Payments'. Enter the desired value in 'Default Posting Code for myHealthPointe Credit Card Payments'. Enter the desired value in 'Default Posting Code for myHealthPointe ACH Payments'. Select the desired value in 'Payments Received From myHealthPointe'. Set the section to 'Credit Card Device Setup'. Click [New Row]. Enter the desired value in 'Device Name'. Enter the desired value in 'Device Description'. Enter the desired value in 'Merchant ID (MID)'. Select 'Yes' in 'Is this a Back Office MID?'. If desired, enter the desired value in 'Device Serial Number'. If desired, select the desired value in 'Site'. Select 'Yes' in 'Active Device'. Click [New Row]. Enter the desired value in 'Device Name'. Enter the desired value in 'Device Description'. Enter the desired value in 'Merchant ID (MID)'. Select 'No' in 'Is this a Back Office MID?'. Enter the desired value in 'Device Serial Number'. Select the desired value in 'Site'. Select 'Yes' in 'Active Device'. Click [Submit]. Repeat steps 16 - 23 for each additional device. If desired, select the row for the device with 'Yes' in 'Is this a Back Office MID?' and select 'No' in 'Active Device'. Click [New Row]. Enter the desired value in 'Device Name'. Enter the desired value in 'Device Description'. Enter the desired value in 'Merchant ID (MID)'. Select 'Yes' in 'Is this a Back Office MID?'. Do not enter a value in 'Device Serial Number'. Do not enter a value in 'Site'. Select 'Yes' in 'Active Device'. Click [Submit]. Scenario 2: CareFabric - Send 'Self Pay Balance' to myHealthPointe Specific Setup: Please review the 'Credit Card Processing' configuration guide which will be located on the Netsmart Wiki, in myAvatar, Avatar Training Guides. Credit Card Processing Configuration has been used to create ‘Device 1’ with a value of ‘No’ in ‘Is this a Back Office MID?’. Credit Card Processing Configuration has been used to create ‘Device 2’ with a value of ‘Yes’ in ‘Is this a Back Office MID?’. 'Service Code 1': configure a service code that will be used as the 'Pre Payment Service Code'. The 'Group Code' and 'Covered Charge Category should both be non-billable. There will be no 'Service Fee/Cross Reference Maintenance' record. 'Posting/Adjustment Codes Definition 1': configure a payment posting code with a value of 'Credit Card Posting Code in 'Is this a Credit Card or ACH Posting Code'. The following registry setting has a value of 'Y': Avatar PM--->Billing->Remittance Processing->->-> Enable Credit Card Processing Functionality. The following registry setting has a value of ‘Service Code 1’: Avatar PM->Scheduling->Front Desk->->->Pre Payment Service Code. The following registry setting has a value of 'Y': Avatar PM->Scheduling->Front Desk->->->Allow Using Front Desk With Scheduling Calendar. Guarantors/Payors 1: Has a 'Financial Class' of 'Self Pay'. Client 1: Note the client ID. Client has one episode/program. Is assigned Guarantors/Payors 1 in 'Financial Eligibility, with a daily deductible of $10.00. Use 'Client Ledger' to verify that client has a positive amount for 'Guarantors/Payors 1 in 'TOTAL BALANCE BY GUARANTOR (last page of the report). Note the amount. Client has an appointment on the current date that is paid, using a credit card, in the amount of $10.00, during 'Scheduling Calendar Check In'. Client 2: Note the client ID. Client has one episode/program. Is assigned Guarantors/Payors 1 in 'Financial Eligibility, with a daily deductible of $10.00. Use 'Client Ledger' to verify that client has a negative amount for Guarantors/Payors 1 in 'TOTAL BALANCE BY GUARANTOR (last page of the report) Note the amount. Client has an appointment on the current date that is paid, using a credit card, in the amount of $10.00, during 'Front Desk Check In'. Client 3: Note the client ID. Client has one episode/program. Is assigned Guarantors/Payors 1 in 'Financial Eligibility, with a daily deductible of $10.00. Use 'Client Ledger' to verify that client has a positive amount for Guarantors/Payors 1 in 'TOTAL BALANCE BY GUARANTOR (last page of the report). Note the amount. A credit card payment is processed in ‘Deposit Entry’ in the amount of $10.00. Steps Open CareFabric Monitor'. Set 'From Date' to current date. Set ''Through Date' to current date. Select 'Client 1' in 'Client ID'. Click 'Click To View Record'. Select the 'CardConnectBalanceUpdated' event. Validate that the 'accountID' is equal to 'Client 1'. Validate that 'cardConnectPayment' is equal to 'null'. Validate that 'currentBalance' is equal to $10.00 less than the 'Client Ledger' amount notes for 'Client 1'. Click [X] on the report. Select 'Client 2' in 'Client ID'. Click 'Click To View Record'. Select the 'CardConnectBalanceUpdated' event. Validate that the 'accountID' is equal to 'Client 2'. Validate that 'cardConnectPayment' is equal to 'null'. Validate that 'currentBalance' is a negative amount that is $10.00 more than the 'Client Ledger' amount notes for 'Client 2'. Click [X] on the report. Select 'Client 3' in 'Client ID'. Click 'Click To View Record'. Select the 'CardConnectBalanceUpdated' event. Validate that the 'accountID' is equal to 'Client 3'. Validate that 'cardConnectPayment' is equal to 'null'. Validate that 'currentBalance' is equal to $10.00 less than the 'Client Ledger' amount notes for 'Client 1'. Click [X] on the report. Click [X] on the form. Scenario 3: CareFabric – Receive ‘Payment Information’ from myHealthPointe - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘0'. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: 'Payment' definitions exist. The 'Payment' definition may be a 'Credit' (payment) or a 'Debit' (reversal). The definitions may have a value in the ‘Payment Acknowledgement Type’ field. Only 'Payment' definitions will be available in the 'Payment Acknowledgement' section of the 'Payment Acknowledgement' form. 'Adjustment' definitions exist. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Adjustment’ and 'Payment' definitions will be available in the ‘Payment Acknowledgement’ form in the ‘Post Payment Accounting Entry' section of the 'Payment Acknowledgement' form. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Agency uses the myHealthPointe payment portal to accept patient electronic payments. Clients: Client 1: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Client 2: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Tester can create a query of SQL tables. Steps Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 1' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Open 'Registry Settings'. Change the value of the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting to include minimum values of '5&6', Click [Submit]. Click [OK]. Click [No]. A payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2, using the 'PATID'. Validate that payment data is correct. Save the query. Open 'Client Ledger' and process the report. Validate that the payment does not display in the report. Close the report. Close the form. Open the 'Payment Acknowledgement' form. Select the 'Post Front Office and myHP Payments' section. Click 'T' in 'Payment Collection Date'. Select desired value in 'Treatment Service'. Select 'myHP' in 'Type'. Click [Review]. Select the row specific to 'Client 2'. Click [OK]. Enter desired 'Batch Number'. Enter desired 'Deposit Date'. Select desired 'Category'. Enter desired 'Bank Ref#'. Enter desired 'Comments'. Click [Post]. Refresh the query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2. Validate that the table no longer contains data for 'Client 2'. Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 2' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Scenario 4: CareFabric – Receive ‘Payment Information’ from myHealthPointe Specific Setup: Agency uses the myHealthPointe payment portal to accept patient electronic payments. Client is enrolled in myAvatar and has an outstanding Self-Pay balance. Payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Tester can create a query of SQL tables Steps Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to the client using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID" Scenario 5: CareFabric – Receive ‘Payment Information’ from myHealthPointe - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘0'. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: 'Payment' definitions exist. The 'Payment' definition may be a 'Credit' (payment) or a 'Debit' (reversal). The definitions may have a value in the ‘Payment Acknowledgement Type’ field. Only 'Payment' definitions will be available in the 'Payment Acknowledgement' section of the 'Payment Acknowledgement' form. 'Adjustment' definitions exist. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Adjustment’ and 'Payment' definitions will be available in the ‘Payment Acknowledgement’ form in the ‘Post Payment Accounting Entry' section of the 'Payment Acknowledgement' form. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Agency uses the myHealthPointe payment portal to accept patient electronic payments. Clients: Client 1: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Client 2: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Tester can create a query of SQL tables. Steps Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 1' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Open 'Registry Settings'. Change the value of the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting to include minimum values of '5&6', Click [Submit]. Click [OK]. Click [No]. A payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2, using the 'PATID'. Validate that payment data is correct. Save the query. Open 'Client Ledger' and process the report. Validate that the payment does not display in the report. Close the report. Close the form. Open the 'Payment Acknowledgement' form. Select the 'Post Front Office and myHP Payments' section. Click 'T' in 'Payment Collection Date'. Select desired value in 'Treatment Service'. Select 'myHP' in 'Type'. Click [Review]. Select the row specific to 'Client 2'. Click [OK]. Enter desired 'Batch Number'. Enter desired 'Deposit Date'. Select desired 'Category'. Enter desired 'Bank Ref#'. Enter desired 'Comments'. Click [Post]. Refresh the query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2. Validate that the table no longer contains data for 'Client 2'. Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 2' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form.	Topics • Credit Card Processing • CareFabric Monitor • CareFabric
Update 80 Summary \| Details Accounts Receivable Management Widget - Financial Classes, Guarantors and Claims Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: View Definition NX View Definition Dynamic Form - NX View Definition AR Console Configuration AR Console User Defaults Setup System Task Scheduler Guarantors/Payors Revenue Code Definition (PM) CPT Code Definition (PM) Dictionary Update (PM) Service Codes Program Maintenance Practitioner Enrollment Failed Authentication - Input Dialog Financial Eligibility Client Charge Input Electronic Billing Dynamic Form - Non-Caseload Access Scenario 1: Accounts Receivable Console - AR List - Search Filters Specific Setup: Agency uses the 'Accounts Receivable Console'. 'AR Console User Defaults Setup' has been used to give the test access: Select All 'Financial Classes', All 'Guarantors', All 'Treatment Settings', All 'Programs', All 'Client Last Name Initials to be Worked'. The 'Accounts Receivable Console' widget has been added to the tester's home view. Client 1, note the following: The clients last name initial, Note the client’s program, has three unpaid claims, Use 'Client Ledger' to note the 'Guarantor', 'Claim Numbers', 'Date' (service date), 'Date Billed', 'Total amount due for each claim'. A 'Claim-Follow-Up' record has been created for the first claim in the Accounts Receivable Console. Add values to the following fields, noting the values 'Follow-Up Date', 'Next Follow-Up Date', 'Follow-Up Status', 'Comments', 'Followed-Up' = Yes. Client 2, note the following, clients last name initial, the client’s program, has three unpaid claims. Use 'Client Ledger' to note the 'Guarantor', 'Claim Numbers', 'Date' (service date which should be after the service date for Client 1), 'Date Billed', 'Total amount due for each claim'. The 'System Task Scheduler' has been used to process the 'Auto AR Batch Update' after the claims were created. Steps Access the 'Accounts Receivable Console'. Verify that 'User Defaults' is the signed in user. Verify that 'Financial Classes' has all items selected. Verify that 'Treatment Settings' has all items selected. Verify that 'Client Last Name Initials to be Worked' has all items selected. Verify that 'Guarantors' has all items selected. Verify that 'Programs' has all items selected. Verify that 'Aged over # Days' is null. Verify that 'Claim #' is null. Verify that 'Client' is null. Verify that 'Service Date From' is null. Verify that 'Service Date From' is null. Verify that 'Service Date To' is null. Verify that 'Next Follow-Up Date From' is null. Verify that 'Next Follow-Up Date To' is null. Verify that 'Exclude Claims with Last Follow-Up Date Within Past # Days' is null. Verify that 'Claim Follow-Up Record Exists' is null. Verify that 'Claim Follow-Up Status' is null. Verify existence of 'Reset Default' button. Verify existence of 'Search' button. Deselect the 'Financial Class' for the guarantor of Client 1. Validate that 'Guarantors' does not contain the guarantor of Client 1. Deselect the 'Treatment Setting' for the program of Client 1. Validate that 'Programs' does not contain the program of Client 1. Click [Reset Default]. Verify that 'Financial Classes' has all items selected. Verify that 'Treatment Settings' has all items selected. Verify that 'Guarantors' has all items selected. Verify that 'Programs' has all items selected. Deselect the 'Client Last Name Initials to be Worked' for Client 2. Click [Search]. Verify that no claims for Client 2 are included in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Enter a value in 'Aged Over # Days' that would allow the oldest claim for the test clients to display. The 'Date Billed' determines the number of aged days. Click [Search]. Validate that the claims for client 1 and the claims for client 2 are included in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Set 'Claim #' to a claim number for Client 2. Click [Search]. Verify that only that claim for Client 2 is included in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Set 'Client' to Client 1. Click [Search]. Verify that no claims for Client 2 are included in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Set 'Service Date From' to the fist service date for 'Client 1'. Set 'Service Date From' to the second service date for 'Client 1'. Click [Search]. Verify that only claims 1 and 2 are included for Client in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Enter the 'Next Follow-Up Date' from Setup. Click [Search]. Verify that the first claim for Client 1 is included in the 'Claims with Outstanding Receivables' grid. Click [Reset Default]. Enter a value in 'Exclude Clients with Last Follow-Up Date Within the Past # Days that would include the 'Follow-Up Date' from Setup. Click [Search]. Verify that the 'Claims with Outstanding Receivables' grid does not include the first claim for Client 1. Click [Reset Default]. Set 'Claim Follow-Up Record' Exists' to 'Yes'. Click [Search]. Click [Reset Default]. Set 'Claim Follow-Up Record' Exists' to 'Yes'. Click [Search]. Verify that the 'Claims with Outstanding Receivables' grid includes the first claim for Client 1. Click [Reset Default]. Set 'Claim Follow-Up Status' to value from SETUP. Click [Search]. Verify that the 'Claims with Outstanding Receivables' grid includes the first claim for Client 1. Click [Reset Default]. Verify that the following fields are null: 'Aged over # Days', 'Claim #', 'Client', 'Service Date From', 'Service Date To', 'Next Follow-Up Date From', 'Next Follow-Up DateTo', Exclude Claims with Last Follow-Up Date Within Past # Days', Claim Follow-Up Record Exists' and Claim Follow-Up Status'. Click [Reset Default]. Set "Claim Balance From" to a minimum claim balance amount to filter on. Set "Claim Balance To" to a maximum claim balance amount to filter on. Click [Search]. Validate the "Claim Balance" columns in the "Claims with Outstanding Receivables" table contains balances that are between the "Claim Balance From - Claim Balance To" range. Double click on the column heading for "Claim Balance" column. Validate the rows are sorted in "Claim Balance" order. Scenario 2: Accounts Receivable Console - Multi System Codes Specific Setup: This update should be tested in systems where there are multiple root system codes. Must designate 2 root systems codes. One of the root system codes must be a system code of 98. The other system code must be something other than 98. Each system code must have a guarantor with the same Guarantor ID but with different names, and different financial classes than the other system code. The Accounts Receivable Console must be enabled by enabling the registry setting "Enable Accounts Receivable Management Functionality". The Accounts Receivable Console must be placed on the user's home view. The Accounts Receivable Console must be configured using the "AR Console User Defaults Setup" and "AR Console Configuration" forms. Admit a test client into each system code, and in financial eligibility, assign them the guarantors with the same IDs, but different names and different financial classes. Steps Log into the 98 system code. Using the "Client Charge Input" form, create charge(s) for this system code's test client. Using "Client Ledger", validate the charge is affiliated with the guarantor from setup. Using the "Close Charges" form close charges for that client. Using a program such as "Electronic Billing", turn the charge into a claim for the test client. Using "System Task Scheduler", schedule an "Auto AR Batch Update" for today in a few minutes. Sign out of the 98 system code. Log into the non 98 system code. Using the "Client Charge Input" form, create charge(s) for this system code's test client. Using "Client Ledger", validate the charge is affiliated with the guarantor from setup. Using the "Closed Charges" form, close charges for that client. Using a program such as "Electronic Billing", turn the charge into a claim for the test client. Using "System Task Scheduler", schedule an "Auto AR Batch Update" for today in a few minutes. Using the Accounts Receivable Console, validate the guarantors appear as appropriate when the financial class for the guarantor is selected/not selected. Validate the claims appear in the "Claims with Outstanding Receivables" if the financial class and/or guarantor is selected in the filters.	Topics • Accounts Receivable Management • NX
Update 92 Summary \| Details Key Performance Indicators widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Key Performance Indicators (Home View) View Definition Scenario 1: The 'Key Performance Indicators' widget - Validating widget when the WIDGET.collection_values' contains data Specific Setup: Ensure the MW build 2086 is installed. The 'Key Performance Indicators' widget is added to the Home View using the 'View Definition' form. The WIDGET.collection_values table contains data where Collection_Type ='TotalLiability' and Collection_Freq ='M'. The WIDGET.collection_values table contains data where Collection_Type ='TotalPaymentsByServiceDate' and Collection_Freq ='M'. Steps Login to Avatar system. Locate to the 'Key Performance Indicators' widget. Verify the widget displays data under 'Measure' column successfully. Verify the last row of the 'Value' column displays desired number because the table contains data. Scenario 2: The 'Key Performance Indicators' widget - Validating widget when there is no data in the WIDGET.collection_values' Specific Setup: The 'Key Performance Indicators' widget is added to the Home View using the 'View Definition' form. There must be no data in WIDGET.collection_values where Collection_Type ='TotalLiability' and Collection_Freq ='M'. There must also be no data in WIDGET.collection_values where Collection_Type ='TotalPaymentsByServiceDate' and Collection_Freq ='M'. Steps Login to Avatar system. Locate to the 'Key Performance Indicators' widget. Verify the widget displays data under 'Measure' column successfully. Verify the last row of the 'Value' column displays as unknown% because there is no data in the table.	Topics • Widgets
Update 93 Summary \| Details NCPDP Enhancements Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Orders This Episode RxConnect Avatar eMAR Launch RxConnect Compile Inbound HL7 Charge Batch File Post Inbound HL7 Charge Batch File Compile/Edit/Post/Unpost Roll-Up Services Worklist NCPDP Intermediary Authorizations Electronic Billing Scenario 1: NCPDP enhancements: support added for 'Quantity Dispensed' but limited to Schedule II meds, 'NCPDP Intermediary Authorizations' and ensuring charges are not included when an order was not active Specific Setup: Avatar must be configured to communicate with RxConnect via Avatar HL7. Configuration must exist for all RxConnect connections. CE2000 must be configured on the server where the application resides, but it must not be started. The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y". The user logged into the application must have access to the 'NCPDP Intermediary Authorizations' form and the 'SYSTEM.ncpdp_intermediary_auths' table. Please log out of the application and log back in after completing the above configuration. A client must have an active inpatient episode. (Client A) "Client A" must have an active 'Diagnosis' and must be associated with an NCPDP guarantor. Steps Select "Client A" and access the Order Entry Console. Create an order for a Schedule II order code (OXYCODONE HCL), ensuring that a 'Frequency Code' of "TWICE A DAY", with a 'Duration' of "28 Days", with a 'Start Date' of "05/01/2022" and a 'Start Time' of "0700". Create a second order for a non-controlled substance (IBUPROFEN) with a 'Frequency Code' of "AS NEEDED", with a 'Duration' of "30 Days", with 'Start Date' of "05/01/2022" and a 'Start Time' of "0700". Access the 'Launch RxConnect' form. Click [Launch RxConnect]. Click the 'RxSummary' tab. Process the "OXYCODONE HCL" order for "Client A" and receive "Rx#1". Process the "IBUPROFEN" order for "Client A" and receive "Rx#2". Close the application and the form. Validate that "Client A" is selected and click on the 'eMAR' widget. Set the 'Administration Date' field to "05/01/2022" and click [Refresh]. Validate the "OXYCODONE HCL" order is displayed with "0900" and "2100" in the cells under date columns for "05/01/2022" through "05/28/2022". Validate the "IBUPROFEN" order is displayed with no scheduled administration times. Administer the "OXYCODONE HCL" for the exact day at the correct time for "05/01/2022" through "05/30/2022". Administer the "IBUPROFEN" order for each day between "05/01/2022" through "05/30/2022". Note: Charges will be batched on a daily basis. The following steps are after the charges have been batched. Compile and Post the Inbound HL7 Charge Batch File. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form and compile the worklist for a 'Through Date' of "05/31/2022". Validate the 'Roll-Up Service Worklist' report is displayed and contains the following: A 'Date' of "05/01/2022" for the "OXYCODONE HCL" order with a 'Quantity' of "56" and a 'Fill#' of "0" containing two rows for each date ranging from "05/01/2022" through "05/28/2022". A 'Date' of "05/29/2022" for the "OXYCODONE HCL" order with a 'Quantity' of "4" and a 'Fill#' of "1" containing two rows for each date ranging from "05/29/2022" through "05/30/2022". A 'Date' of "05/01/2022" for the "IBUPROFEN" order with a 'Quantity' of "28" and a 'Fill#' of "0" containing two rows for each date ranging from "05/01/2022" through "05/28/2022". A 'Date' of "05/29/2022" for the "OXYCODONE HCL" order with a 'Quantity' of "2" and a 'Fill#' of "1" containing two rows for each date ranging from "05/29/2022" through "05/30/2022". Post the worklist and close the form. Close the charges. Validate that "Client A" is selected and access the 'NCPDP Intermediary Authorizations' form. Set the 'Intermediary Authorization ID' field to "123ABC". Select "Intermediary Authorization" in the 'Intermediary Authorization Type' field. Set the 'Effective Date' field to "01/01/2022". Search for and select "OXYCODONE HCL" in the 'Select Service' field. Validate the 'Selected Service(s)' field contains "OXYCODONE HCL" with the checkbox checked. Set the 'Prescription Number' field to the 'Rx#' received when processing the order, "Rx#1". Click [Submit]. Validate that "Client A" is selected and access the 'NCPDP Intermediary Authorizations' form. Validate a pre-display is displayed that contains the previous data entered. Click [Add]. Set the 'Intermediary Authorization ID' field to "BC". Select "Not Specified" in the 'Intermediary Authorization Type' field. Set the 'Effective Date' field to "01/01/2022". Set the 'Expiration Date' field to "01/01/2023". Search for and select "IBUPROFEN" in the 'Select Service' field. Validate the 'Selected Service(s)' field contains "IBUPROFEN" with the checkbox checked. Validate the 'Prescription Number' field does not contain a value. Click [Submit]. Access he 'Electronic Billing' form. Create a claim for "NCPDP" for a date range of "05/01/2022" through "05/31/2022" and click [Process]. Validate the 'Compile Complete' message is displayed and click [OK]. View the report and validate the 'NCPDP Claim Submission Data' report contains the following: A 'Service Date' of "05/01/2022" for a 'Service' of "OXYCODONE HCL" for 'Rx# (Actual)' of "206" with a 'Fill#' of "0" with a 'Days Supply' of "28" and a 'Quantity Dispensed' of "56". A 'Service Date' of "05/01/2022" for a 'Service' of "IBUPROFEN" for 'Rx# (Actual)' of "207" with a 'Fill#' of "0" with a 'Days Supply' of "28" and a 'Quantity Dispensed' of "28". Go back to the main page of the report and click 'NCPDP' Error Report'. Validate the report contains an 'Error Message' of "OE Order# was no longer active as of the date of service : OXYCODONE HCL - service date: 05/29/2022". Close the report. Create a file on the server. The file created would contain two messages: The first message is for the "OXYCODONE HCL" order and contains the following: A value of "56" in the 120th segment for 'Quantity Prescribed', because it is a Schedule II medication. A value of "1" in the 123rd segment for 'Intermediary Auth Type', which is the code for the value that was selected in the 'NCPDP Intermediary Authorizations' form. A value of "123ABC" in the 124th segment for 'Intermediary Auth ID', which was entered in the 'NCPDP Intermediary Authorizations' form. The second message is for the "IBUPROFEN" order and contains the following: No value in the 120th segment for 'Quantity Prescribed', because it is not a Schedule II medication. A value of "0" in the 123rd segment for 'Intermediary Auth Type', which is the code for the value that was selected in the 'NCPDP Intermediary Authorizations' form. A value of "BC" in the 124th segment for 'Intermediary Auth ID', which was entered in the 'NCPDP Intermediary Authorizations' form.	Topics • HL7 • NX • NCPDP
Update 104 Summary \| Details SYSTEM.billing_guar_table_270 - fields added Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form and Table Documentation (PM) Guarantors/Payors Scenario 1: SYSTEM.billing_guar_table_270 - Validating 'Create Single File Per Interchange Control Header (ISA)' in the 'Guarantors/Payors' form - Editing an existing guarantor Specific Setup: Registry Setting: The 'Enable 270/271 Transaction Sets' registry setting is set to 'Y'. The 'Create Single File Per Interchange Control Header (ISA)' registry setting is set to 'Y'. Guarantors/Payors: An existing guarantor is identified. Note the Guarantor code/ value. Steps Open the 'Guarantors/Payors' form. Select a guarantor to edit. Note the guarantor code. Navigate to the 270/271/834 tab. Select 'Yes' for the 'Create Single File Per Interchange Control Header (ISA)' field. Note the value. File the form. Open the 'Crystal Report' or any other SQL Data Viewer tool. Query the 'billing_guar_table_270' table for the guarantor identified above. Verify the 'single_file_isa_code' and 'single_file_isa_value' fields exist. Verify the 'single_file_isa_code' contains 'Y' and the 'single_file_isa_value' field contains 'Yes' when 'Yes' is selected in the 'Create Single File Per Interchange Control Header (ISA)' field. Open the 'Guarantors/Payors' form. Select a guarantor to edit. Note the guarantor code. Navigate to the 270/271/834 tab. Select 'No' for the 'Create Single File Per Interchange Control Header (ISA)' field. Note the value. File the form. Open the 'Crystal Report' or any other SQL Data Viewer tool. Query the 'billing_guar_table_270' table for the guarantor identified above. Verify the 'single_file_isa_code' contains 'N' and the 'single_file_isa_value' field contains 'No' when 'No' is selected in the 'Create Single File Per Interchange Control Header (ISA)' field. Scenario 2: SYSTEM.billing_guar_table_270 - Validating 'Create Single File Per Interchange Control Header (ISA)' in the 'Guarantors/Payors' form - Adding a new guarantor Specific Setup: Registry Setting: The 'Enable 270/271 Transaction Sets' registry setting is set to 'Y'. The 'Create Single File Per Interchange Control Header (ISA)' registry setting is set to 'Y'. Steps Open the 'Guarantors/Payors' form. Select 'Add' in the 'Add New or Edit Existing Guarantor' field to add a guarantor. Enter a numeric value as the guarantor code in the 'New Guarantor Code' field. Note the guarantor code/value to be used for further testing. Enter desired value in the 'Guarantor Name' field. Enter desired value in the 'Guarantor Name For Alpha Lookup' field. Enter desired value in the 'Guarantor's Address - Zip Code' field. Select desired class from the 'Financial Class' field. Select desired value from the 'Guarantor Nature' field. Navigate to the 270/271/834 tab. Select 'Yes' in the 'Support 270/271 Transaction Sets' field. Select 'No' to 'Skip Liability Update Process If No Valid Response (271) Received For An Inquiry (270)' field. Set the 'Real Time 270/271 Access Point' to desired value. Select 'Yes' in the 'Create Single File Per Interchange Control Header (ISA)' field. File the form. Open the 'Crystal Report' or any other SQL Data Viewer tool. Query the 'billing_guar_table_270' table for the guarantor identified above. Verify the 'single_file_isa_code' and 'single_file_isa_value' fields exist. Verify the 'single_file_isa_code' contains 'Y' and the 'single_file_isa_value' field contains 'Yes' because 'Yes' is selected in the 'Create Single File Per Interchange Control Header (ISA)' field. Open the 'Guarantors/Payors' form. Select the same guarantor to edit. Note the guarantor code. Navigate to the 270/271/834 tab. Select 'No' in the 'Create Single File Per Interchange Control Header (ISA)' field. File the form. Open the 'Crystal Report' or any other SQL Data Viewer tool. Query the 'billing_guar_table_270' table for the guarantor identified above. Open the 'Crystal Report' or any other SQL Data Viewer tool. Query the 'billing_guar_table_270' table for the guarantor identified above. Verify the 'single_file_isa_code' contains 'N' and the 'single_file_isa_value' field contains 'No' because 'No' is selected in the 'Create Single File Per Interchange Control Header (ISA)' field.	Topics • Database Tables • NX
Update 105 Summary \| Details Internal Client Referral - Internal Referral Type Category Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Table Definition (PM) Internal Referral Type Maintenance Group Member Assignment Internal Client Referrals Process Internal Referrals Review To Do Item (PM) Scenario 1: Internal Referral Type Maintenance - Validating all the 'Internal Referral Type Category' Specific Setup: Have a system with RAD 2015 Update 60 installed. Form Definition: Create or identify an existing a user-defined (modeled) form that collects the additional referral information needed to approve or reject a referral. Note the form name and Table name. The form must contain a Non Scrolling Free Text data element that has been configured in Table Definition as a Referral Group. Note the field name. Table Definition: A Non Scrolling Free Text data element that has been configured as a Referral Group. Note the field name. Admission: Create a new client or identify an existing client. Note the client id, name. Steps Open the 'Internal Referral Type Maintenance' form. Select 'Add Internal Referral type' in the 'Add Or Edit Internal Referral Type' field. Verify the 'Internal Referral Type Code' field displays the identification code assigned to the referral type. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Program' in the 'Internal Referral Type Category' field. Select desired program from the 'Program' field. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Group' in the 'Internal Referral Type Category' field. Select desired group from the 'Group' field. Note the group name/code. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Team' in the 'Internal Referral Type Category' field. Select desired team from the 'Team' field. Note the team name/code. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Other' in the 'Internal Referral Type Category' field. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'No' to 'Form Return' Message. Open the 'Internal Client Referral' form. Select desired client in the 'Client Being Referred' field. Select 'Program' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Program' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The Internal Referral Type Description field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Program' field is marked as a required field and it is auto populated with the program selected in the 'Internal Referral Type Maintenance' form. Select 'Group' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Group' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The Internal Referral Type Description field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Group' field is marked as a required field and it is auto populated with the group selected in the 'Internal Referral Type Maintenance' form. Select 'Team' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Team' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The 'Internal Referral Type Description' field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Team' field is marked as a required field and it is auto populated with the team selected in the 'Internal Referral Type Maintenance' form. Close the form. Scenario 2: Internal Client Referrals - Internal Referral Type Category = None Specific Setup: Form Definition: Create or identify an existing a user-defined (modeled) form that collects the additional referral information needed to approve or reject a referral. Note the form name and Table name. The form must contain a Non Scrolling Free Text data element that has been configured in Table Definition as a Referral Group. Note the field name. Table Definition: A Non Scrolling Free Text data element that has been configured as a Referral Group. Note the field name. Admission: Create a new client or identify an existing client. Note the client id, name. Steps Open the 'Internal Referral Type Maintenance' form. Select 'Add Internal Referral type' in the 'Add Or Edit Internal Referral Type' field. Verify the 'Internal Referral Type Code' field displays the identification code assigned to the referral type. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Do select any category in the 'Internal Referral Type Category' field. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Open the 'Internal Client Referral' form. Select desired client in the 'Client Being Referred' field. Select desired referral type from the 'Internal Referral Type Being Requested' field. Select the client episode for which the referral is being made in the 'Episode' field. The Internal Referral Type Description field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Verify the 'Internal Referral Group' field is not marked as a required field. Verify the 'Internal Referral Program' field is not marked as a required field. Verify the 'Internal Referral Team' field is not marked as a required field. Click [Initiate Referral Process]. Verify the modeled form associated with this referral will open automatically. Enter the appropriate information in the form. Click [Submit]. Close the 'Internal Client Referral' form. Open the 'Process Internal Referral' form. Verify the 'Internal Referral' grid displays all referrals with an open status that have been assigned to the user. Verify the 'Internal Referral Information' field displays additional details about the referral. Select desired status from the 'Internal Referral Status' field. Enter desired comments in the 'Internal Referral Comments' field. Note the comment. Click [Process Internal Referral]. Locate to the To Do widget. Verify the to do is generated for the client. Review the To Do item. Verify the comments appears in the To-Do alert for the user who initiated the referral.	Topics • Referral • NX
Update 107 Summary \| Details Crystal Self Pay Bill - Support 'System Financial Class' extended dictionary Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Guarantors/Payors Financial Eligibility Client Charge Input Crystal Self Pay Bill Inhibited Services For Billing Report Dictionary Update (PM) Progressive Self Pay Dunning Messages Update Client Data Form and Table Documentation (PM) Individual Cash Posting (PM) Scenario 1: Crystal Self Pay Bill - Billing a Self Pay guarantor - Validating 'Allow For Number of Days Since Last Claim' registry setting Specific Setup: Registry Settings: Set the 'Allow For Number Of Days Since Last Claim' set to 'I'. Guarantors/Payors: A self pay guarantor is identified. Note the guarantor code/value. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Admission: A new client is admitted. Note the client id, admission date and admission program. Financial Eligibility: The self pay guarantor is assigned to the client. Note the guarantor code. Diagnosis: The diagnosis record is created for the client. Client Charge Input: A service is rendered to the client. Note the service date and service code. Client Ledger: The service distributed to the self pay guarantor. Close charges: The charges distributed to the guarantor are closed. Steps Open the 'Crystal Self Pay Bill' form. Enter a value for 'Print Charges Thru' field that will include the service rendered to the client. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired 'Date Of Claim'. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displays. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select desired value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Validate that the Self Pay Bill report displays. In the Self Pay Bill report ensure that the 'Current Charges' section includes claim/service information for all services meeting bill generation criteria selection, with service date/description/amount values, as well as charge total information. Open the 'Client Charge Input' form. Render a service to the client. Note the date of the service. Verify the service distributed correctly to the self pay guarantor assigned to the client. Close charges. Open the 'Crystal Self Pay Bill' form. Enter a value for 'Print Charges Thru' field that covers the service rendered to the client and it is within the number of days since last claim defined in the 'Guarantors/Payor' from the claim date. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the previous claim date. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'No Information Found. Cancel OK No Information Was Found For Inclusion On The Bill.' message displayed. Click [Close Report]. Click [Discard]. Open the 'Inhibited Services For Billing Report' form. Enter 'Start Date'. Enter 'End Date'. Select the client from the previous steps. Click [Process report]. Verify the report contains all the services for the client for the episode inhibited from the billing. Close the report. Open the 'Crystal Self Pay Bill' form. Enter a value for 'Print Charges Thru' field that covers the service rendered to the client and it is after the number of days defined in the 'Number Of Days Since Last Claim' field in the 'Guarantors/Payors. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the service date. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Ensure that it displays the Self Pay Bill report/information. Verify the report displays the recently claimed service in the report. Close the report. Close the form. Scenario 2: Crystal Self Pay Bill - Billing a guarantor that has the system financial class dictionary set to Self Pay - Validating 'Allow For Number of Days Since Last Claim' registry setting Specific Setup: Registry Settings: Set the 'Allow For Number Of Days Since Last Claim' set to 'I'. Guarantors/Payors: An existing guarantor is identified to be assigned to the client as a primary guarantor and the financial class is not a self pay but is a different financial class. Note the guarantor code / value / financial class. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Dictionary Update: File - Payor Data Element - (1000) Financial Class Dictionary Code - The dictionary code for the financial class of the guarantor identified above. Extended Dictionary Data Element - (1500) System Financial Class Extended Dictionary Value - Self Pay Admission: A new client is admitted, or an existing client is identified. Note the client id, admission date and admission program. Financial Eligibility: The guarantor identified above is assigned to the client as a primary guarantor. Diagnosis: The diagnosis record is created for the client. Client Charge Input: The service is rendered to the client such that it comes prior to coverage effective date of the primary guarantor. Note the service date and service code. Client Ledger: The service distributed to the self pay guarantor. Close Charges: The services rendered to the client are closed. Steps Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the service date. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select desired guarantor that is identified and setup to have system financial class of Self-Pay. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Validate that the Self Pay Bill report displays. In the Self Pay Bill report/information display, ensure that the 'Current Charges' section includes claim/service information for all services meeting bill generation criteria selection, with service date/description/amount values, as well as charge total information. Open the 'Client Charge Input' form. Render a service to the client. Note the date of the service. Verify the service distributed correctly to the self pay guarantor assigned to the client. Close charges. Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client and it is within the number of days since last claim defined in the 'Guarantors/Payor' from the claim date. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the previous claim date. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'No Information Found. Cancel OK No Information Was Found For Inclusion On The Bill.' message displayed. Click [Close Report]. Click [Discard]. Open the 'Inhibited Services For Billing Report' form. Enter 'Start Date'. Enter 'End Date'. Select the client from the previous steps. Click [Process report]. Verify the report contains all the services for the client for the episode inhibited from the billing. Close the report. Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field that covers the service rendered to the client and it is after the number of days defined in the 'Number Of Days Since Last Claim' field in the 'Guarantors/Payors. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the service date. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Validate that the Self Pay Bill report displays. Verify the report displays the recently claimed service in the report. Close the report. Close the form. Scenario 3: Progressive Self Pay Dunning Messages - Validating SQL Table and Crystal Self Pay Bill for a guarantor with a system financial class of Self-Pay Specific Setup: Registry Settings: The registry setting 'Enable Progressive Self-Pay Dunning Messages' is set to 'Y'. The registry setting 'Allow For Number Of Days Since Last Claim' set to 'I'. User Definition: Verify the form 'Progressive Self Pay Dunning Messages' is added to the system. Select the form and submit the user definition. Form Search: Verify the form 'Progressive Self Pay Dunning Messages' is available in the system. Guarantors/Payors: A self pay guarantor is identified to assign to the client's first episode. Note the guarantor code/value. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Another existing guarantor is identified to be assigned to the client as a primary guarantor of the second episode and the financial class is not a self pay but is a different financial class. Note the guarantor code / value / financial class. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Dictionary Update: File - Payor Data Element - (1000) Financial Class Dictionary Code - The dictionary code for the financial class of the guarantor identified above to be assigned to the client's second episode. Extended Dictionary Data Element - (1500) System Financial Class Extended Dictionary Value - Self Pay Admission: A new client is admitted in two admission episodes. Note the client id, admission date and admission program. Financial Eligibility: A self pay guarantor is assigned to the client as a primary guarantor of episode 1. Note the guarantor code. The other guarantor identified is assigned to the client as a primary guarantor of episode 2. Note the guarantor code. Diagnosis: The diagnosis record is created for the client for both episodes. Client Charge Input: 3-4 services are rendered to the client for each episode. Note the service date and service code. Client Ledger: The services distributed to the self pay guarantor for episode 1. The services from the second episode are distributed to the assigned guarantor. Close Charges: Services are closed. Steps Open the 'Progressive Self Pay Dunning Messages' form. Select the guarantor. Verify the first message field is enabled. Verify that each subsequent message field enables when the prior field has a value. File desired messages for all the message fields. Print the information for the selected guarantor. Verify the report includes data filed for the selected guarantor. Open the 'Crystal Report' or any other SQL Data Viewer. Query the SQL table SYSTEM.billing_prog_sp_dunn_msg. Verify the length of the statement messages fields increased to 350 characters. Verify the data files successfully and correctly as entered through the form. Open the 'Crystal Self Pay Bill' form. Enter/select values for 'Print Charges Thru' field such that it covers the service rendered to the client. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the service date. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support batch. Select desired guarantor that is set up to have system financial class of self pay. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Ensure that it displays the first message defined in the form in the Self Pay Bill report/information. Run the bill for the second service. Ensure that it displays the second message defined in the form in the Self Pay Bill report/information. Run the bill for the second service. Ensure that it displays the third message defined in the form in the Self Pay Bill report/information. Run the bill for the second service. Ensure that it displays the fourth message defined in the form in the Self Pay Bill report/information. Run the bill for the second service. Ensure that it displays the fifth message defined in the form in the Self Pay Bill report/information. Close the report. Close the form. Scenario 4: Crystal Self Pay Bill - - Validating services that distributed to a guarantor with the system financial class of Self-Pay - Previous claim date within the 'Number Of Days Since Last Claim' Specific Setup: Registry Settings: Set the 'Allow For Number Of Days Since Last Claim' set to 'I'. Guarantors/Payors: The self pay guarantor is identified to be assigned to the client as a primary guarantor. Note the guarantor code/value. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Another existing guarantor is identified to be assigned to the client as a secondary guarantor and the financial class is not a self pay but is a different financial class. Note the guarantor code / value / financial class. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Dictionary Update: File - Payor Data Element - (1000) Financial Class Dictionary Code - The dictionary code for the financial class of the guarantor identified above to be used as secondary guarantor. Extended Dictionary Data Element - (1500) System Financial Class Extended Dictionary Value - Self Pay Admission: A new client is admitted, or an existing client is identified. Note the client id, admission date and admission program. Financial Eligibility: The guarantors identified above are assigned to the client as primary and secondary guarantors. Diagnosis: The diagnosis record is created for the client. Client Charge Input: The service is rendered to the client such that it comes prior to coverage effective date of the primary guarantor. Note the service date and service code. Client Ledger: The service distributed to the secondary guarantor. Close Charges: The service rendered to the client are closed. Steps Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim'. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select the secondary guarantor. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Validate that the Self Pay Bill report displays. In the Self Pay Bill report, ensure that the 'Current Charges' section includes claim/service information for all services meeting bill generation criteria selection, with service date/description/amount values, as well as charge total information. Scenario 5: Crystal Self Pay Bill - Billing a guarantor with the system financial class set to Self Pay - New billing cycle upon updating client's address using the 'Update Client Data' form Specific Setup: Registry Settings: Set the 'Allow For Number Of Days Since Last Claim' set to 'I'. Guarantors/Payors: The self pay guarantor is identified to be assigned to the client as a primary guarantor. Note the guarantor code/value. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Another existing guarantor is identified to be assigned to the client as a secondary guarantor and the financial class is not a self pay but is a different financial class. Note the guarantor code / value / financial class. Enter desired days in the 'Number Of Days Since Last Claim' field. Note the number of days. Dictionary Update: File - Payor Data Element - (1000) Financial Class Dictionary Code - The dictionary code for the financial class of the guarantor identified above to be used as secondary guarantor. Extended Dictionary Data Element - (1500) System Financial Class Extended Dictionary Value - Self Pay Admission: A new client is admitted, or an existing client is identified. Note the client id, admission date and admission program. Financial Eligibility: The guarantors identified above are assigned to the client as primary and secondary guarantors. Diagnosis: The diagnosis record is created for the client. Client Charge Input: The service is rendered to the client such that it comes prior to coverage effective date of the primary guarantor. Note the service date and service code. Client Ledger: The service distributed to the secondary guarantor. Close Charges: The service rendered to the client are closed. Steps Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field such that it is after the service date. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Validate that the Self Pay Bill report displays. In the Self Pay Bill report/information display, ensure that the 'Current Charges' section includes claim/service information for all services meeting bill generation criteria selection, with service date/description/amount values, as well as charge total information. Open the 'Client Charge Input' form. Render a service to the client. Note the date of the service. Verify the service distributed correctly to the self pay guarantor assigned to the client. Close charges. Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client and it is within the number of days since last claim defined in the 'Guarantors/Payor' from the claim date. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim' field that it is after the previous claim date. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'No Information Was Found For Inclusion On The Bill.' message displayed. Click [Close Report]. Click [Discard]. Open the 'Inhibited Services For Billing Report' form. Enter 'Start Date'. Enter 'End Date'. Select the client from the previous steps. Click [Process report]. Verify the report contains all the services for the client for the episode inhibited from the billing. Close the report. Open the 'Update Client Data' form for the client. Navigate to 'Demographics' section of form. Change any of the Client's Address field. Click [Submit]. Open the 'Crystal Self Pay Bill' form. Enter values for 'Print Charges Thru' field such that it covers the service rendered to the client and it is within the number of days defined in the 'Number Of Days Since Last Claim' field in the 'Guarantors/Payors. Note the date. Select 'Yes' in the 'Create Claims Y/N' field. Enter desired date to the 'Date Of Claim'.. Note the claim date for further testing. Select 'No' in the 'Print for Interim Batch' field. Please note the 'Number Of Days Since Last Claim' functionality does not support interim batch. Select 'All Clients' in the 'Print For An Individual Or All Clients'. Click [Compile Self Pay Bill]. Verify the 'Compile Complete' message displayed. Navigate to the 'Print Crystal Self Pay Bill' section of the form. Select value for 'Select By Client Or File' field. Select compiled bill file or client record for bill data display. Click [Print Self Pay Bill]. Ensure that it displays the Self Pay Bill report/information. Verify the report displays the recently claimed service in the report. Close the report. Close the form.	Topics • Registry Settings • Inhibit Billing • NX • Crystal Self Pay Bill • Database Tables
Update 109 Summary \| Details Service Entry - After Treatment Plan Intervention Assigned Services Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Treatment Plan Program Maintenance Site Specific Section Modeling (CWS) Client Charge Input Scenario 1: Treatment Plan (Interventions) - "Assigned Services" grid functionality Specific Setup: Client must be admitted to an active episode. (Client A). Registry setting 'Avatar CWS->Treatment Plan->->->->Enable Service Entry Restriction by Client Treatment Plan' must be enabled. Steps Select "Client A" and access the 'Treatment Plan' form. Click [Add]. Set the 'Plan Date' field to the current date. Select any value in the 'Plan Type' field. Select any value from 'Problem List'. Enter any value in the 'Strengths' field. Enter any value in the 'Weakness' field. Enter any value in the 'Discharge Planning' field. Select "Draft" in the 'Draft/Final' field. Click [Launch Plan]. Select the problem from the 'Tree View'. Select any value from the 'Status' field. Click [Add New Goal]. Enter any value in the 'Goal' field. Select any value from the 'Status' field. Click [Add New Objective]. Enter any value in the 'Objective' field. Select any value from the 'Status' field. Click [Add New Intervention]. Enter any value in the 'Intervention' text field. Select any value from the 'Status' field. Click [Add Service] in the 'Assigned Services' field. Populate the 'Service Program' field. Enter a search value in the 'Service Code' field to bring up the listing of service code values. Select any service code. Validate the service code field is populated as expected in the 'Service Code' field. Select any value in the 'Frequency' field. Select any value in the 'Duration' field. Click [Return To Plan]. Click [Submit]. Validate the plan submits successfully. Select "Client A" and access the 'Treatment Plan' form. Click to edit the row just submitted. Click [Launch Plan]. Click the 'Interventions' item on the plan tree Click [Add New Intervention]. Enter any value in the 'Intervention' text field. Select any value from the 'Status' field. In the 'Assigned Services' grid, click [Copy Service]. In the 'Add Services From Other Intervention's' dialog, choose the service added in the intervention previous submitted. Click [Copy]. Validate the 'Assigned Services' grid columns are populated with the service information, as expected. Select the 'Assigned Services' row just added. Click the [Delete Service] button. Validate the service row is removed from the 'Assigned Services' grid, as expected. Click [Return to Plan]. Click [Submit]. Validate the plan submits successfully. Scenario 2: Client Charge Input After Treatment Plan - Enable Service Entry Restrictions by Client Treatment Plan is enabled Specific Setup: Enable "Enable Service Entry Restriction by Client Treatment Plan" by setting it to "E". After enabling the registry setting, log off Avatar and sign back in again. Admit a test client into any program. Using "Program Maintenance", edit the program the test client was admitted to, and set the "Enable Service Entry Restriction for Program" to "Yes". Using "Program Maintenance", edit another program the test client is not admitted to and set the "Enable Service Entry Restriction for Program" to "Yes". Using "Site Specific Section Modeling", add the "Assigned Services" to the Treatment Plan Interventions section. Steps Open the "Treatment Plan" form. Begin a new treatment plan for the test client. Set it to Draft status. Add a problem, goal, objection, and intervention. In the intervention section, Click the "Add Services" button. Select the program the test client is enrolled in the "Service Program" field. Select a service code, frequency, duration, service mode, place of service, amount, agency, and staff responsible. Click "Add Services" button to add another row to the table. Select the program from setup that the client isn't enrolled in. Select a different service code than the first row. Fill out the rest of the fields. Click the "Return To Plan" button. Mark the plan as Final. Click "Submit" button. Sign or Sign and Route the document. If routed, sign on as the user document was routed to and from the "ToDos" widget, Accept the document. Open the "Client Charge Input" form. Select the test client. Set the "Service Code" field to the service code that was assigned to the program the test client is not enrolled in on the "Treatment Plan" form. Validate the drop down list doesn't contain the service code since it's not assigned to the program the client is enrolled in. Set the "Service Code" field to the service code that was assigned to the program the test client is enrolled in on the "Treatment Plan" form. Validate the service code listed in the drop down list is the one that is affiliated to the program the client is enrolled in. Complete the form by filling out all other required fields. Advanced Billing Rules - Site Specific Section Modeling integer fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (PM) Financial Eligibility Client Charge Input Advanced Billing Rule Definition Posting/Adjustment Codes Definition Individual Cash Posting (PM) Scenario 1: Advanced Billing Rule - based on Site Specific Section Modeling Integer value > 16 Specific Setup: Add a Site Specific Section Modeling Treatment Integer field to the "Client Charge Input" form. Admit a test client. Add financial eligibility information to the client for two guarantors. Using the "Advanced Billing Rule Definition" form, set up an advanced billing rule for a specific service code and a specific guarantor. It should be set up for all genders, not associated with age and select "Compliance" in the "Rule Defines Conditions" field. Then select the "Event Rules" section and select "Site Specific Treatment History" from the Event Table drop down, select the site specific field that was added to "Client Charge Input" via Site Specific Section Modeling in setup, and set the Specific Value (Other) to a threshold level Such as ">= 16", Using the "Posting/Adjustment Codes Definition" form, set the "Adjustment, Payment or Transfer" field to "Transfer" and set the "Transfer Type" to "Redistribute - Open". Steps Using the "Client Charge Input" form, add a service for the client from the advanced billing rule setup, be sure to populate the Site Specific Section Modeling Integer field added in setup with a value that is equal to or greater than the threshold established in setup. Using "Client Ledger", validate the service went to the guarantor #1 for the test client. Using "Individual Cash Posting", apply a payment and transfer the balance to the other guarantor that was set up for the test client using the transfer code from setup. Using "Close Charges", update the liability for the client. Using "Client Ledger", validate the balance of the service was transferred to the other guarantor. Scenario 2: Advanced Billing Rule - based on Site Specific Section Modeling Integer value < 16 Specific Setup: Add a Site Specific Section Modeling Treatment Integer field to the "Client Charge Input" form. Admit a test client. Add financial eligibility information to the client for two guarantors. Using the "Advanced Billing Rule Definition" form, set up an advanced billing rule for a specific service code and a specific guarantor. It should be set up for all genders, not associated with age and select "Compliance" in the "Rule Defines Conditions" field. Then select the "Event Rules" section and select "Site Specific Treatment History" from the Event Table drop down, select the site specific field that was added to "Client Charge Input" via Site Specific Section Modeling in setup, and set the Specific Value (Other) to a threshold level. Such as "< 16", Using the "Posting/Adjustment Codes Definition" form, set up a transfer code and set the "Adjustment, Payment or Transfer" field to "Transfer" and set the "Transfer Type" to "Redistribute - Open". Steps Using the "Client Charge Input" form, add a service from the advanced billing rule from setup for the client, be sure to populate the Site Specific Section Modeling Integer field added in setup with a value that is less than the threshold. Using "Client Ledger", validate the service went to the guarantor #1 for the test client. Using "Individual Cash Posting", apply a payment and transfer the balance to the other guarantor that was set up for the test client using the transfer code from setup. Using "Close Charges", update the liability for the client. Using "Client Ledger", validate the balance of the service was transferred to the default guarantor (9999) because it was under the threshold for the Advanced Billing Rule from setup. Compile and Post Partial Hospitalization/Day Treatment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Compile Partial Hospitalization/Day Worklist Post Partial Hospitalization/Day Worklist Attending Practitioner Scenario 1: Compile Partial Hospitalization/Day Worklist - Validate change in practitioner Specific Setup: Using "Maintain Hospital Bed File", add a test room to an existing unit. Admit a test client into a partial hospitalization or day treatment program. Using the "Diagnosis" form, assign a diagnosis to the test client. Using the "Financial Eligibility" form, assign a guarantor to the test client. Steps Open the "Compile Partial Hospitalization/Day Worklist" form. Create a new worklist and validate the test client is included on the report. Open the "Post Hospitalization/Day Worklist" form. Select the program that test client is enrolled in. Validate the test client is included on the report generated. Change the attending practitioner to a different practitioner using the "Attending Practitioner" form. Open the "Compile Partial Hospitalization/Day Worklist" form. Create a new worklist for a different date range and validate the test client is included on the report. Open the "Post Hospitalization/Day Worklist" form. Select the program that test client is enrolled in. Validate the test client is included on the report generated. Open the "Client Ledger" form. Validate the charges generated are included on the client's ledger. Using the preferred method to validate SQL tables, validate the v_provider_name column of the SYSTEM.billing_tx_history table contains the name of the attending practitioner the client was switched to. Scenario 2: Compile Partial Hospitalization/Day Worklist Specific Setup: Using "Maintain Hospital Bed File", add a test room to an existing unit. Admit a test client into a partial hospitalization or day treatment program. Using the "Diagnosis" form, assign a diagnosis to the test client. Using the "Financial Eligibility" form, assign a guarantor to the test client. Steps Open the "Compile Partial Hospitalization/Day Worklist" form. Create a new worklist and validate the test client is included on the report. Open the "Post Hospitalization/Day Worklist" form. Select the program that test client is enrolled in. Validate the test client is included on the report generated. Open the "Compile Partial Hospitalization/Day Worklist" form. Create a new worklist for a different date range and validate the test client is included on the report. Open the "Post Hospitalization/Day Worklist" form. Select the program that test client is enrolled in. Validate the test client is included on the report generated. Open the "Client Ledger" form. Validate the charges generated are included on the client's ledger. Service Code Upload - Error Handling Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Code Upload Process Service Code Upload Accepted Codes Service Codes Dynamic Form Service Code Upload Scenario 1: 'Service Code Upload Process' - Verification of Service Code Upload Specific Setup: Avatar State Forms Registry Setting 'Enable Texas TMHP Billing' must be enabled Avatar PM Service Code Upload file containing one or more valid rows/entries including values for 'TMHP Type Of Service' field (Import File Segment/Location 134) and 'Line Item Control Number - Positions 5 to 20 (2400-REF)' (Import File Segment/Location135) Please refer to updated 'Avatar_PM_Service_Code_Upload_Layout.xls' document included in the zip file for this update. Steps Open Avatar PM 'Service Code Upload Process' form. Click 'Select File' button and select Avatar PM Service Code Upload file containing one or more valid rows/entries including values for 'TMHP Type Of Service' and 'Line Item Control Number - Positions 5 to 20 (2400-REF)' fields/segments. Select 'Compile' in 'Compile Or Post' field. Select Yes or No value for 'Override Existing Service Codes' field. Click 'Submit' button to file form/compile Service Code Upload file. Ensure that dialog noting 'Compile Completed' is presented; click 'OK' button to close dialog/proceed. Open Avatar PM 'Service Code Upload Accepted Codes' form. Select compiled file in 'Select Desired Service Code Import File Name' field. Click 'Process' button to file form/display Service Code Upload Accepted Codes report. Ensure 'TMHP Type Of Service' and 'Line Item Control Number - Positions 5 to 20 (2400-REF)' fields are included in Service Code Upload Accepted Codes report display, and contains value filed for 'TMHP Type Of Service'/'Line Item Control Number - Positions 5 to 20 (2400-REF)' fields/segments for valid compiled rows/entries. Close Service Code Upload Accepted Codes report. Return to Avatar PM 'Service Code Upload Process' form. Select 'Post' in 'Compile Or Post' field to post compiled Service Code Upload file row(s). Click 'Submit' button to file form/post Service Code Upload file. Ensure that dialog noting 'Posting Completed' is presented; click 'OK' button to close dialog/proceed. Return to Avatar PM 'Service Code Upload Accepted Codes' form. Select posted file in 'Select Desired Service Code Import File Name' field. Click 'Process' button to file form/display Service Code Upload Accepted Codes report. Ensure 'TMHP Type Of Service' and 'Line Item Control Number - Positions 5 to 20 (2400-REF)' fields are included in Service Code Upload Accepted Codes report display, and contains value filed for 'TMHP Type Of Service'/'Line Item Control Number - Positions 5 to 20 (2400-REF)' fields/segments for valid/posted rows/entries. Open Avatar PM 'Service Codes' form. Select 'Edit Existing' action and select Service Code filed via 'Service Code Upload Process' file posting. Ensure that value for 'TMHP Type Of Service' field is present/selected in form as defined in Service Code Upload file row/entry. Ensure that value for 'Line Item Control Number - Positions 5 to 20 (2400-REF)' field is present/selected in form as defined in Service Code Upload file row/entry. Scenario 2: Service Code Upload - Validate Discipline string with an & Specific Setup: Create a test service code upload file that contains an extra "&" in the Discipline field, e.g. 10&11&. Designate this "File A". Create a test service code upload file that contains the following in the Discipline field. e.g. 10&11. Designate this "File B". Please refer to updated 'Avatar_PM_Service_Code_Upload_Layout.xls' document included in the zip file for this update. Steps Open the "Service Code Upload Process" form. In the "Select File" drop down list, select the file designated as "File A". Select "Compile" in the "Compile or Post" field. Select "Yes" in the "Override Existing Service Codes" field. Click "Submit" button. Validate a "Filing Error" message displays indicating "No accepted data compiled. To view results review rejected report". Open the "Service Code Upload Rejected Codes" form. Select "File A" from the "Select Desired Service Code Import File Name" drop down list. Validate the report contains "Invalid Dictionary Code" error message. Exit the form. Open the "Service Code Upload Process" form. In the "Select File" drop down list, select the file designated as "File B". Select "Compile" in the "Compile or Post" field. Select "Yes" in the "Override Existing Service Codes" field. Click "Submit" button. Validate the message "Compile completed. To view results review accepted and rejected reports" displays. Open the "Service Code Upload Accepts Codes" form. Select "File B" from the "Select Desired Service Code Import File Name" drop down. Click "Process" button. Validate the report indicates the service codes that will be uploaded. Open the "Service Code Upload Process File" form. Select "File B" in the "Select File" field. Select "Post" in the "Compile or Post" field. Click "Submit". Validate the message displays that indicates "Posting Completed". Open the "Service Codes" Form. Click the "Service Code Report" section. Select a service code that was uploaded when the file was posted. Click "Display Service Codes" button. Validate the service code was uploaded. Electronic Billing - 837 Institutional Non Covered Days Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Electronic Billing Financial Eligibility Client Charge Input Dictionary Update (PM) Leaves Discharge Create Interim Billing Batch File Scenario 1: 837 Institutional - Non Billable Leave Days Specific Setup: Using the "Dictionary Update" form under the PM namespace, edit the "Client" data element "Type of Leave From", add desired dictionary code, and a value similar to "Non-Billable Leave". Set the Extended Dictionary Data Element "(10031) Chargeable Leave Y/N" to "No". Admit a client into an inpatient program. Note the admission date. Using the "Financial Eligibility" form, add a guarantor for the client. Using the "Diagnosis" form, enter an admission diagnosis for the client. Using "Client Charge Input", enter in 10 days of partial hospitalization/day charges. (Example: 8/01 - 8/10). Using "Client Ledger", validate there are 10 days of partial hospitalization/day charges. Using the "Leaves" form, put the client on non billable leave on the day after the 10 hospitalization/day charges. (Example: 8/11). Open the "Return From Leaves" form and set the return date to 4 days after the Leave Date. (Example: 8/15). Using the "Discharge" form, discharge the client on the day they are returning from leave (Example: 8/15). Using the "Close Charges" form, close the charges for the date range (Example: 8/1 - 8/15). Using the "Create Interim Billing Batch File" form, create an interim billing batch for the test client. Steps Open the "Electronic Billing" form. Process an 837 Institutional bill for the guarantor, program and test client that was put on non-billable leave and subsequently discharged on the date of return from leave. The date range would be from the day the client was admitted until to the day the client was discharged. (Example 8/1 - 8/15). Print the dump file for the 837 Institutional and validate the file contains a line similar to "HIBE:80:::10BE:81:::4" with 4 being the days of non billable leave. Scenario 2: 837 Institutional - Billable Leave Days Specific Setup: Using the "Dictionary Update" form under the PM namespace, edit the "Client" data element "Type of Leave From", add a dictionary code, and a value would similar to Billable Leave". Set the Extended Dictionary Data Element "(10031) Chargeable Leave Y/N" to "Yes". Admit a client into an inpatient program. Note the admission date. Using the "Financial Eligibility" form, add a guarantor for the client. Using the "Diagnosis" form, enter an admission diagnosis for the client. Using "Client Charge Input", enter in 10 days of partial hospitalization/day charges. (Example: 8/01 - 8/10) Using "Client Ledger", validate there are 10 days of partial hospitalization/day charges. Using the "Leaves" form, put the client on billable leave on the day after the 10 hospitalization/day charges. (Example: 8/11). Open the "Return From Leaves" form and set the return date to 4 days after the Leave Date. (Example: 8/15). Using the "Discharge" form, discharge the client on the day they are returning from leave (Example: 8/15). Using the "Close Charges" form, close the charges for the date range (Example: 8/1 - 815). Using the "Create Interim Billing Batch File" form, create an interim billing batch for the test client. Steps Open the "Electronic Billing" form. Process an 837 Institutional bill for the guarantor, program and test client that was put on billable leave and subsequently discharged on the date of return from leave. The date reange will bw from the day the client was admitted until to the day the client was discharged. (Example 8/1 - 8/15). Print the dump file for the 837 Institutional and validate the file contains a line similar to "HIBE:80:::10BE:81:::0" with 0 being the days of non billable leave.	Topics • Treatment Plan • Client Charge Input • NX • Advanced Billing Rule Definition • Inpatient Worklist • Registry Settings • Service Codes • Service Code Upload Process • Electronic Billing • Leaves
Update 114 Summary \| Details Payment Acknowledgment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Payment Acknowledgement Dictionary Update (PM) Posting/Adjustment Codes Definition Financial Eligibility Program Maintenance Deposit Entry Scenario 1: Payment Acknowledgement - form & field validation Specific Setup: Registry Setting: ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ has a ‘Registry Setting Value’ of ‘Y’. ‘Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged’ has a ‘Registry Setting Value’ of 5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: 'Payment' definitions exist. The 'Payment' definition may be a 'Credit' (payment) or a 'Debit' (reversal). The definitions may have a value in the ‘Payment Acknowledgement Type’ field. Only 'Payment' definitions will be available in the 'Payment Acknowledgement' section of the 'Payment Acknowledgement' form. 'Adjustment' definitions exist. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Adjustment’ and 'Payment' definitions will be available in the ‘Payment Acknowledgement’ form in the ‘Post Payment Accounting Entry' section of the 'Payment Acknowledgement' form. Client to use in the 'Post Front Office and myHP Payments' section of the 'Payment Acknowledgement' form: Client 1: A client with a self-pay balance is identified. Note the program. Program Maintenance is used to identify the 'Treatment Service'. Deposit Entry’ is used to create a payment for the self-pay guarantor. Note the data entry date. Query the ‘SYSTEM.unacknowledged_payments’ table, specific to the client. Validate that the deposit entry payment information is correct. Client Ledger is used to validate that the payment was not applied to the client's account. Steps Open ‘Payment Acknowledgement’ form. Verify that ‘Action’ defaults to ‘New’. Verify that ‘Transaction Number’ is read only. Verify that ‘Entered By’ is read only and defaults to the signed in user. Verify that ‘Batch Number’ is required. Verify that ‘Posting Code’’ is required. Verify that ‘Amount’ is required. Verify that ‘Guarantor’ is required. Verify that ‘Receipt Date’ is required. Verify that ‘Deposit Date’ is required. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Include in Category Dictionary: Yes' the dictionary item will be available for selection. No = not available for selection. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Require Name/Source in Payment Acknowledgement', has a value of 'Y' the 'Name/Source' field will become required. No = not required. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is 6. Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Clicking [No] returns the user to the ‘Payment Acknowledgement’ section to enter additional payments. Clicking [Yes] allows the user to post payments in 'Post Payment Accounting Entry'. Click [Yes]. Click [New Row] in ‘Post Payment Accounting Entry’. Select desired ‘Treatment Service’. It will default if filed in the ‘Payment Acknowledgement’. Select desired ‘Program’. This is from ‘Other Table Files: (5521) Program’, not a program in ‘Program Maintenance’. Select desired ‘Account’. Select desired ‘Amount’. Validate that the ‘Posting Code; defaulted from the ‘Payment Acknowledgement’. Select desired ‘Posting Date’. Validate that the ‘Posting Summary’ is correct. If desired, and first row partially posts the 'Amount', click [New Row] and repeat the steps. If desired, click [Delete Row]. A ‘Confirm Delete’ message will be displayed. Select desired value. Click [File]. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? Click [Yes]. Click the ‘Reverse’ checkbox in one row of the ‘Post Payment Accounting Entry’. Enter desired ‘Reversal Posting Date’. Enter desired ‘Reversal Reason’. Click [Reverse]. Validate that a new row was added to the ‘Post Payment Accounting Entry’ grid and that it mirrors the row that was selected to reverse, except for ‘Amount’ displays in parentheses, indicating a negative amount. If desired, add a new row to post and additional payment. Close the form. Open ‘Payment Acknowledgement’ form. Select ‘Edit or View’ in ‘Action, which will enable the ‘Payment Acknowledgement Search’ section. Enter data from the ‘Payment Acknowledgement’, filed above, into desired search fields. The ’Transaction Number’ and ‘Batch Number’ are specific to only one ‘Payment Acknowledgement’. The following fields may return results for more than one ‘Payment Acknowledgement’ when applicable: ‘Client’, ‘Guarantor’, ‘Amount Type’, ‘Check/EFT #’, ‘Check/EFT From Date’, ‘Check/EFT To Date’, ‘Deposit From Date’, and ‘Deposit To Date’. Click [Search]. Select the desired item in the ‘Payment Acknowledgement’ grid. Click [OK] to continue or [Cancel] to end the search. Click [OK]. The following ‘Payment Acknowledgement’ displays: Do you need to continue to Post Payment Accounting Entry? Validate the ‘Post Payment Accounting Entry' contains the previously filed data. Close the form. Open ‘Payment Acknowledgement’ form. Select the 'Post Front Office and myHP Payments. Set the 'Payment Collection’ date to the current date. Select the 'Treatment Service' if desired. Select the 'Type'. Click [Review]. Select the Deposit Entry item in the 'Unacknowledged Payments' checklist for Client 1. Click [OK]. Enter desired 'Batch Number'. Enter desired 'Deposit Date'. Select the desired 'Category'. Enter the desired 'Bank Ref #'. Enter 'Comments' if desired. Click [Post]. Click [OK]. Close the form. Open the 'Client Ledger' for the client. Process the report. Verify the client ledger displays the deposit entry correctly. Close the Report. Close the form. Deposit Entry Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Deposit Entry Service Codes Financial Eligibility Program Maintenance Posting/Adjustment Codes Definition Payment Acknowledgement Guarantors/Payors Scenario 1: Deposit Entry web service validation Specific Setup: Select a client to use for a payment through a 'Deposit Entry' web service request. Note the guarantor assigned to the client. Steps SoapUI or other web service tool is used to create a request for Deposit Entry. Use the client ID and guarantor from setup. Note amount of payment, date of payment, and any other desired information. Process the request and validate that it completed successfully. Open ‘Client Ledger’ for the client. Process the report and validate that the web service deposit entry payment displays in the client’s record and that the submitted data was retained. Close the report. Close the form. Scenario 2: PM - Deposit Entry - field, error messages, and process validation Specific Setup: This can be tested with and without credit card functionality. If credit card functionality is not enabled, please use non-credit card posting codes. For our testing credit card functionality is enabled. The following registry setting has a value of 'Y': Avatar PM--->Billing->Remittance Processing->->->Enable Credit Card Processing. 'Receipt Definition' has been defined. 'Service Code 1, will be used to accept client payments in the 'Deposit Entry' form: Service Code = any value. Service Code Definition = any value. Service Required By = Client Only. Type of Service = Individual. Type of Fee = any value. Group Code = any value, typically meaning non-billable. Covered Charge Category = any value, typically meaning non-billable. Is This A Balance Forward Service Code = No. Does This Code Have A Professional Component = any value. Is This Service A Visit = No. Is This Service An Intervention = No. 'Service Code 2: Service Code = any value. Service Code Definition = any value. Service Required By = Both or Provider. Type of Service = Individual. Type of Fee = any value. Group Code = any value. Covered Charge Category = any value. Is This A Balance Forward Service Code = No. Does This Code Have A Professional Component = any value. Is This Service A Visit = any value. Is This Service An Intervention = any value. 'Posting/Adjustment Codes Definition 1': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Credit'. ‘Is this a Credit Card or ACH Payment Code’ = 'No' or is blank. After creating 'Posting/Adjustment Codes Definition 2', return to this code in ‘Edit’ mode and add a value of ‘Yes’ to ‘Generate Receipt’ and a value of 'Posting/Adjustment Codes Definition 2' to ‘Void Receipt Posting Code'. Posting/Adjustment Codes Definition 2': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Debit'. ‘Is This a Reversal Code’ = 'Yes’. 'Which Pym/Adj Code Is This A Reversal For' = 'Posting/Adjustment Codes Definition 1'. 'Posting/Adjustment Codes Definition 3': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Credit'. ‘Is this a Credit Card or ACH Payment Code’ = 'Yes'. After creating 'Posting/Adjustment Codes Definition 4', return to this code in ‘Edit’ mode and add a value of ‘Yes’ to ‘Generate Receipt’ and a value of 'Posting/Adjustment Codes Definition 4' to ‘Void Receipt Posting Code'. Posting/Adjustment Codes Definition 4': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Debit'. ‘Is This a Reversal Code’ = 'Yes’. 'Which Pym/Adj Code Is This A Reversal For' = 'Posting/Adjustment Codes Definition 3'. The following registry setting has a value of 'Service Code 1': Avatar PM->Services->Ancillary/Ambulatory Services->Deposit Entry->->Default Service Code. The following registry setting has a value of 'Posting/Adjustment Codes Definition 1': Avatar PM->Scheduling->Front Desk->->->Pre Payment Default Posting Code. Credit Card Configuration: Has 'No' in 'Populate Receipt Number with Credit Card Payment Reference Number'. Enter desired values for the other fields. In the 'Credit Card Device Setup' section: ' Credit Card Device 1': Has a value of 'No' in 'Is this a Back Office MID?'. Note the device name. Enter desired values for the other fields. 'Credit Card Device 2': Has a value of 'Yes' in 'Is this a Back Office MID?'. Note the device name. Enter desired values for the other fields. 'Guarantors/Payors 1': Has a 'Financial Class' of 'Self Pay'. 'Client 1': Note the episode/program. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. 'Client 2': Note the episode/program. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. 'Client 3': Note the episode/program. There is no 'Attending Practitioner' in the admission record. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. Steps Open 'Deposit Entry'. Validate 'Date Of Receipt Or Adjustment' is equal to "required". Validate 'Client ID' is equal to "required". Validate 'Episode Number' is equal to "required". Validate 'Guarantor' is equal to "required". Validate 'Service Code' is equal to "required". Validate 'Amount To Post' is equal to "required". Validate 'Posting Code' is equal to "required". Validate 'Receipt' is "enabled". Validate 'Check #' is equal to "enabled". Validate 'Program Of Service' is equal to "required". Validate 'Location' is equal to "required". Validate 'Transaction Type' is equal to "disabled". Validate 'Select Credit Card Device' is equal to "disabled". Validate 'Pay With Credit Card button is equal to "disabled". Click [Submit]. Validate that a 'Submitting' message is received stating: The following fields are missing: Amount To Post, Client ID, Date of Receipt Or Adjustment, Episode Number, Guarantor, Location, Posting Code, Program Of Service, Service Code. Click [OK]. Click the 'Y - Date Of Receipt Or Adjustment' button. Validate 'Date Of Receipt Or Adjustment' is equal to "yesterday's date". Click the 'T - Date Of Receipt Or Adjustment' button. Validate 'Date Of Receipt Or Adjustment' is equal to "current date". Set 'Client ID' to "Client 1". Select desired 'Episode Number'. Validate 'Program Of Service' is equal to "Client 1 program of service". Validate 'Location' is equal to "Client 1 program of service default location". Set 'Service Code' to "Service Code 1". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 1" in 'Posting Code'. Click [Submit]. Validate the receipt is generated and contains data including: 'Payment Received For ' = Client 1, 'The Sum of $5.00' and 'Type of Payment:' = ‘'Posting/Adjustment Codes Definition 1', Code Definition’. Note the value of 'Receipt #'. Close the receipt. Open 'Deposit Entry'. Click the 'T - Date Of Receipt Or Adjustment' button. Set 'Client ID' to "Client 2". Select desired 'Episode Number'. Set 'Service Code' to "Service Code 1". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 3" in 'Posting Code'. Validate 'Pay With Credit Card' is equal to "enabled". Validate 'Transaction Type' is equal to "enabled and required". Validate 'Transaction Type' is equal to "Insert/Swipe Card". Validate 'Select Credit Card Device' is equal to "enabled and required". Click [Submit]. Validate the 'Error' message is equal to: Please use the 'Pay With Credit Card' command button to process a credit card posting code or select a different code. Click [OK]. Select the desired 'Transaction Type'. Click [Pay With Credit Card] and follow the prompts to process the payment. Review the 'Card Connect Payment' message. A successful payment will generate a receipt. Click [OK] on the 'Card Connect Payment' message. Validate the receipt, if generated, contains data including: 'Payment Received For' = Client 2, 'The Sum of $5.00' and 'Type of Payment' = ‘'Posting/Adjustment Codes Definition 3', Code Definition’. Note the value of 'Receipt #'. Click the 'T - Date Of Receipt Or Adjustment' button. Set 'Client ID' to "Client 3". Select desired 'Episode Number'. Set 'Service Code' to "Service Code 2". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 1" in 'Posting Code'. Click [Submit].' Validate the 'Error' message is equal to "Attending Practitioner Is Not Assigned. Process Aborted". Click [OK]. Select "Posting/Adjustment Codes Definition 3" in 'Posting Code'. Click [Submit].' Validate the 'Error' message is equal to "Attending Practitioner Is Not Assigned. Process Aborted". Click [OK]. Click [X] to close the form. Open 'Client Ledger' for 'Client 1'. Validate that a $5.00 payment was made on the current date for "Posting/Adjustment Codes Definition 1", and 'Service Code 1'. Update the 'Client Ledger' to 'Client 2'. Validate that a $5.00 payment was made on the current date for "Posting/Adjustment Codes Definition 3", and 'Service Code 1'. Update the 'Client Ledger' to 'Client 3'. Validate that no payment was made on the current date. Scenario 3: File Import - Deposit Entry' - file with all the required/optional fields Specific Setup: Registry Setting: Set the 'Avatar PM->System Maintenance->File Import->->->Import File Delimiter' registry setting to the desired value. Guarantors/Payor: An existing guarantor is identified to be assigned to the client. Note the guarantor code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Identify the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the Client id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. File Import: An import file is created to process the deposit entry. Ensure that the file contains all required fields and desired optional fields. Note the file name / location of the file. Steps 1. Open the 'File Import' form. 2. Select the 'Deposit Entry' from the File Type field. 3. Upload the file Import file created in the setup section. 4. Compile the file. 5. Verify the file compiles successfully. 6. Post the compiled file. 7. Verify the file posted successfully. 8. Open the 'Client Ledger' for the client. 9. Process the report. 10. Verify the client ledger displays the deposit entry correctly. 11. Close the Report. 12. Close the form. Scenario 4: Registry Setting validation - Prevent Posting Payments Unless Payment has been Acknowledged Steps Open the 'Registry Settings' form. Set the Limit Registry Settings to 'Enable Payment Acknowledgement' Set the Registry Setting Value input box to ‘N’. Click [Submit]. Click [OK]. Click [Yes]. Submit the form. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Validate the Registry Setting input box contains 'Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged'. Validate the Registry Setting Details text area contains: [FACILITY SPECIFIC] - The 'Enable Payment Acknowledgement' registry setting must be enabled to select any values. The valid values are: 0 or 1, 2, 3, 4, 5 and/or 6. Multiple values can be selected. They will be separated by ampersands. Example: 1&2. When '1' is selected, it will restrict the ability to post payments in the '835 Health Care Claim Payment/Advice' form to only payments that have been acknowledged in the 'Payment Acknowledgement' form. When '2' is selected, it will restrict the ability to post payments in the 'Batch Cash Posting' form to only payments that have been acknowledged in the 'Payment Acknowledgement' form. When '3' is selected, it will restrict the ability to post payments in the "Payment/Adjustment Posting" 'File Import' to only payments that have been acknowledged in the 'Payment Acknowledgement' form. When '4' is selected, it will prevent the system from applying payments entered in 'Scheduling Calendar - Check In' until those payments have been acknowledged in the 'Payment Acknowledgement' form. This will also add the 'Name on Card' field to 'Scheduling Calendar - Check In'. When '5' is selected, it will prevent the system from applying payments entered in 'Deposit Entry' until those payments have been acknowledged in the 'Payment Acknowledgement' form. This will also add the 'Name on Card' field to 'Deposit Entry'. When '6' is selected, it will prevent the system from applying payments entered in myHealthPointe until those payments have been acknowledged in the 'Payment Acknowledgement' form. Selecting '0' will remove this functionality. This is the default behavior. Set the Registry Setting Value input box to '1'. Validate the error message dialog contains 'The selected value is not valid in the current system code for the following reason: The 'Enable Payment Acknowledgement' registry setting must be enabled to make any selections other than zero.' Set the Limit Registry Settings to 'Enable Payment Acknowledgement'. Set the 'Enable Payment Acknowledgement' registry setting to 'Y'. Click [Submit]. Click [OK]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Validate that the Registry Setting Value defaults to ‘0’. Set the Registry Setting Value input box to 'Y'. Click [TAB]. Validate the error message dialog contains 'The selected value is not valid in the current system code for the following reason: Invalid selection found (Y).' Set the Registry Setting Value input box to 'N'. Click [TAB]. Validate the error message dialog contains 'The selected value is not valid in the current system code for the following reason: Invalid selection found (N).' Set the Registry Setting Value input box to '1'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '2'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '3'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '4'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '5'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '6'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Set the Registry Setting Value input box to '1&2&3&4&5&6'. Click [Submit]. Click [OK]. Click [Yes]. Set the Limit Registry Settings to 'Prevent Posting Payments Unless Payment has been Acknowledged'. Validate the Registry Setting Value input box contains '1&2&3&4&5&6'. Close the form. Scenario 5: File Import - Deposit Entry - Registry Setting = Prevent Posting Payments Unless Payment has been Acknowledged Specific Setup: Registry Setting: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = 'Y'. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = '5', at a minimum, but may contain any combination of '1&2&3&4&5&6'. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Guarantors/Payors: An existing guarantor is identified to be assigned to the client. Note the guarantor's code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Note the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the client's id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Note the guarantor's code/name. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. File Import: An import file is created to process the deposit entry. Ensure that the file contains all required fields and desired optional fields. Note the file name / location of the file. Steps Open the 'File Import' form. Select the 'Deposit Entry' from the File Type field. Upload the file Import file created in the setup section. Compile the file. Verify the file compiles successfully. Post the compiled file. Verify the file posted successfully. Open the 'Client Ledger' for the client. Process the report. Verify the client ledger does not display the deposit entry payment. Close the Report. Close the form. If desired, query the ‘SYSTEM.unacknowledged_payments’ table, specific to the client. Verify that the query results display the Deposit Entry item correctly. Close the query. Open 'Payment Acknowledgement'. Select the 'Post Front Office and myHP Payments. Set the 'Payment Collection’ date to the current date. Select the 'Treatment Service' if desired. Select the 'Type'. Click [Review]. Select the Deposit Entry item in the 'Unacknowledged Payments' checklist. Click [OK]. Enter desired 'Batch Number'. Enter the 'Deposit Date' which would the 'Date Of Receipt Or Adjustment' in the Deposit Entry file. Select the desired 'Category'. Enter the desired 'Bank Ref #'. Enter 'Comments' if desired. Click [Post]. Click [OK]. Close the form. Open the 'Client Ledger' for the client. Process the report. Verify the client ledger displays the deposit entry correctly. Close the Report. Close the form. Scenario 6: PM - Deposit Entry - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Admit a new test client or select an existing self-pay client. Note the client’s ID. Assign a self-pay Financial Eligibility record to the client. Use 'Deposit Entry' to post a payment to the client. Note the details of the payment. Use 'Client Ledger' to validate that the payment did not post to the account. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client. Validate that payment data is correct. Save the query. Steps Open ‘Payment Acknowledgement’. Select the ‘Post Front Office and myHP Payments’ section. Click [T] on ‘Payment Collection Date’. Select ‘Front Office’ in ‘Type’. Click [Review]. Select the row with the 'Deposit Entry' payment for the client. Click [OK]. Enter desired ‘Batch Number’. Enter desired ‘Deposit Date’. Select desired ‘Category’. Enter desired ‘Bank Ref #’. Enter desired ‘Comments. Click [Post]. Open ‘Client Ledger’ for the client. Process the ‘Simple’ ledger report. Validate that the 'Deposit Entry' payment posted to the client’s account. Close the report. Close the form. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client. Validate that no results are returned. Scenario 7: Deposit Entry web service validation - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Setting: ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ has a ‘Registry Setting Value’ of ‘Y’. ‘Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged’ has a ‘Registry Setting Value’ of 5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Select a client to use for a payment through a 'Deposit Entry' web service request. Note the guarantor assigned to the client. Steps SoapUI or other web service tool is used to create a request for Deposit Entry. Use the client ID and guarantor from setup. Note amount of payment, date of payment, and any other desired information. Process the request and validate that it completed successfully. Open ‘Client Ledger’ for the client. Process the report and validate that the web service deposit entry payment is not included in the client’s account. Close the report. Close the form. Query the ‘SYSTEM.unacknowledged_payments’ table, specific to the client. Verify that the query results display the web service deposit entry item correctly. Close the query. Open 'Payment Acknowledgement'. Select the 'Post Front Office and myHP Payments. Set the 'Payment Collection’ date to the current date. Select the 'Treatment Service' if desired. Select the 'Type'. Click [Review]. Select the web service deposit entry item in the 'Unacknowledged Payments' checklist. Click [OK]. Enter desired 'Batch Number'. Enter the 'Deposit Date' which would the 'Date Of Receipt Or Adjustment' in the Deposit Entry file. Select the desired 'Category'. Enter the desired 'Bank Ref #'. Enter 'Comments' if desired. Click [Post]. Click [OK]. Close the form. Query the ‘SYSTEM.unacknowledged_payments’ table, specific to the client. Verify that no query results are returned. Close the query. Open the 'Client Ledger' for the client. Process the report. Verify the client ledger displays the deposit entry correctly. Close the Report. Close the form. SQL - 'SYSTEM.unacknowledgement_payments’ table added to system. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Deposit Entry Service Codes Financial Eligibility Program Maintenance Claim Adjustment Group/Reason Code Definition Guarantors/Payors Dictionary Update (PM) Default Guarantor Assignment Posting/Adjustment Codes Definition 835 Health Care Claim Payment/Advice (PM) Create Interim Billing Batch File Electronic Billing Payment Acknowledgement Client Charge Input Delete Service Delete Last Movement Change MR# Scenario 1: PM - Deposit Entry - field, error messages, and process validation Specific Setup: This can be tested with and without credit card functionality. If credit card functionality is not enabled, please use non-credit card posting codes. For our testing credit card functionality is enabled. The following registry setting has a value of 'Y': Avatar PM--->Billing->Remittance Processing->->->Enable Credit Card Processing. 'Receipt Definition' has been defined. 'Service Code 1, will be used to accept client payments in the 'Deposit Entry' form: Service Code = any value. Service Code Definition = any value. Service Required By = Client Only. Type of Service = Individual. Type of Fee = any value. Group Code = any value, typically meaning non-billable. Covered Charge Category = any value, typically meaning non-billable. Is This A Balance Forward Service Code = No. Does This Code Have A Professional Component = any value. Is This Service A Visit = No. Is This Service An Intervention = No. 'Service Code 2: Service Code = any value. Service Code Definition = any value. Service Required By = Both or Provider. Type of Service = Individual. Type of Fee = any value. Group Code = any value. Covered Charge Category = any value. Is This A Balance Forward Service Code = No. Does This Code Have A Professional Component = any value. Is This Service A Visit = any value. Is This Service An Intervention = any value. 'Posting/Adjustment Codes Definition 1': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Credit'. ‘Is this a Credit Card or ACH Payment Code’ = 'No' or is blank. After creating 'Posting/Adjustment Codes Definition 2', return to this code in ‘Edit’ mode and add a value of ‘Yes’ to ‘Generate Receipt’ and a value of 'Posting/Adjustment Codes Definition 2' to ‘Void Receipt Posting Code'. Posting/Adjustment Codes Definition 2': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Debit'. ‘Is This a Reversal Code’ = 'Yes’. 'Which Pym/Adj Code Is This A Reversal For' = 'Posting/Adjustment Codes Definition 1'. 'Posting/Adjustment Codes Definition 3': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Credit'. ‘Is this a Credit Card or ACH Payment Code’ = 'Yes'. After creating 'Posting/Adjustment Codes Definition 4', return to this code in ‘Edit’ mode and add a value of ‘Yes’ to ‘Generate Receipt’ and a value of 'Posting/Adjustment Codes Definition 4' to ‘Void Receipt Posting Code'. Posting/Adjustment Codes Definition 4': Note the ‘Code Definition’. 'Adjustment, Payment or Transfer’ = 'Payment'. ‘Credit or Debit’ = 'Debit'. ‘Is This a Reversal Code’ = 'Yes’. 'Which Pym/Adj Code Is This A Reversal For' = 'Posting/Adjustment Codes Definition 3'. The following registry setting has a value of 'Service Code 1': Avatar PM->Services->Ancillary/Ambulatory Services->Deposit Entry->->Default Service Code. The following registry setting has a value of 'Posting/Adjustment Codes Definition 1': Avatar PM->Scheduling->Front Desk->->->Pre Payment Default Posting Code. Credit Card Configuration: Has 'No' in 'Populate Receipt Number with Credit Card Payment Reference Number'. Enter desired values for the other fields. In the 'Credit Card Device Setup' section: ' Credit Card Device 1': Has a value of 'No' in 'Is this a Back Office MID?'. Note the device name. Enter desired values for the other fields. 'Credit Card Device 2': Has a value of 'Yes' in 'Is this a Back Office MID?'. Note the device name. Enter desired values for the other fields. 'Guarantors/Payors 1': Has a 'Financial Class' of 'Self Pay'. 'Client 1': Note the episode/program. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. 'Client 2': Note the episode/program. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. 'Client 3': Note the episode/program. There is no 'Attending Practitioner' in the admission record. Use 'Program Maintenance' to note the program default location. Is assigned Guarantors/Payors 1 in 'Financial Eligibility. Use 'Client Ledger' client to note the balance for 'Guarantors/Payors 1' in 'TOTAL BALANCE BY GUARANTOR. Steps Open 'Deposit Entry'. Validate 'Date Of Receipt Or Adjustment' is equal to "required". Validate 'Client ID' is equal to "required". Validate 'Episode Number' is equal to "required". Validate 'Guarantor' is equal to "required". Validate 'Service Code' is equal to "required". Validate 'Amount To Post' is equal to "required". Validate 'Posting Code' is equal to "required". Validate 'Receipt' is "enabled". Validate 'Check #' is equal to "enabled". Validate 'Program Of Service' is equal to "required". Validate 'Location' is equal to "required". Validate 'Transaction Type' is equal to "disabled". Validate 'Select Credit Card Device' is equal to "disabled". Validate 'Pay With Credit Card button is equal to "disabled". Click [Submit]. Validate that a 'Submitting' message is received stating: The following fields are missing: Amount To Post, Client ID, Date of Receipt Or Adjustment, Episode Number, Guarantor, Location, Posting Code, Program Of Service, Service Code. Click [OK]. Click the 'Y - Date Of Receipt Or Adjustment' button. Validate 'Date Of Receipt Or Adjustment' is equal to "yesterday's date". Click the 'T - Date Of Receipt Or Adjustment' button. Validate 'Date Of Receipt Or Adjustment' is equal to "current date". Set 'Client ID' to "Client 1". Select desired 'Episode Number'. Validate 'Program Of Service' is equal to "Client 1 program of service". Validate 'Location' is equal to "Client 1 program of service default location". Set 'Service Code' to "Service Code 1". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 1" in 'Posting Code'. Click [Submit]. Validate the receipt is generated and contains data including: 'Payment Received For ' = Client 1, 'The Sum of $5.00' and 'Type of Payment:' = ‘'Posting/Adjustment Codes Definition 1', Code Definition’. Note the value of 'Receipt #'. Close the receipt. Open 'Deposit Entry'. Click the 'T - Date Of Receipt Or Adjustment' button. Set 'Client ID' to "Client 2". Select desired 'Episode Number'. Set 'Service Code' to "Service Code 1". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 3" in 'Posting Code'. Validate 'Pay With Credit Card' is equal to "enabled". Validate 'Transaction Type' is equal to "enabled and required". Validate 'Transaction Type' is equal to "Insert/Swipe Card". Validate 'Select Credit Card Device' is equal to "enabled and required". Click [Submit]. Validate the 'Error' message is equal to: Please use the 'Pay With Credit Card' command button to process a credit card posting code or select a different code. Click [OK]. Select the desired 'Transaction Type'. Click [Pay With Credit Card] and follow the prompts to process the payment. Review the 'Card Connect Payment' message. A successful payment will generate a receipt. Click [OK] on the 'Card Connect Payment' message. Validate the receipt, if generated, contains data including: 'Payment Received For' = Client 2, 'The Sum of $5.00' and 'Type of Payment' = ‘'Posting/Adjustment Codes Definition 3', Code Definition’. Note the value of 'Receipt #'. Click the 'T - Date Of Receipt Or Adjustment' button. Set 'Client ID' to "Client 3". Select desired 'Episode Number'. Set 'Service Code' to "Service Code 2". Select "Guarantors/Payors 1" in 'Guarantor'. Set 'Amount To Post' to "5". Select "Posting/Adjustment Codes Definition 1" in 'Posting Code'. Click [Submit].' Validate the 'Error' message is equal to "Attending Practitioner Is Not Assigned. Process Aborted". Click [OK]. Select "Posting/Adjustment Codes Definition 3" in 'Posting Code'. Click [Submit].' Validate the 'Error' message is equal to "Attending Practitioner Is Not Assigned. Process Aborted". Click [OK]. Click [X] to close the form. Open 'Client Ledger' for 'Client 1'. Validate that a $5.00 payment was made on the current date for "Posting/Adjustment Codes Definition 1", and 'Service Code 1'. Update the 'Client Ledger' to 'Client 2'. Validate that a $5.00 payment was made on the current date for "Posting/Adjustment Codes Definition 3", and 'Service Code 1'. Update the 'Client Ledger' to 'Client 3'. Validate that no payment was made on the current date. Scenario 2: 835 Health Care Claim Payment/Advice - Three checks per file - Posting Acknowledged, Unacknowledged and Zero dollar payments Specific Setup: Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting includes value '1'. The 'Check Number' registry setting is set to '1'. The 'Posting Date for Automated 835s' registry setting is set to '1'. Claim Adjustment Group/ reason code Definition: A group code is selected for the credit adjustment code and debit adjustment reversal code. Note the adjustment codes and group code setup. Admission: Admit a client into an outpatient episode. Note the Client id/name, Admission date/program. Guarantor/Payors: Two existing guarantors are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Financial Eligibility: The desired guarantors identified above are assigned to the client. Note the primary and secondary guarantor. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to one of the guarantors assigned to the client. Close charges. Electronic Billing: Claim the service using the 837 Professional bill for the guarantor. Create an 835 file based on the claim information found in the 837 professional bill. Steps Open the '835 Health Care Claim Payment/Advice' form. Load and compile the 835 file created that includes the claim for the defined guarantor in the setup. Verify the 835 file loads/compiles successfully. Select 'Post File' option. Select the compiled file. Populate all the required fields with desired value. Verify the Check/EFT# is populated correctly with the status of acknowledged or unacknowledged in the 'Check/EFT#' checkbox. Check the Check/EFT# that is unacknowledged. Click [Process File]. Verify the message: 'Selecting Unacknowledged Check/EFT numbers is not permitted.' Click [OK]. Close the form. Open the ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’ from the TRN02 segment of the 835 file created in the setup. Enter desired value in ‘Amount’ that matches the amount entered in the CLP04 segment of the 835 file. Select desired ‘Guarantor’ set up in the setup section. Note: If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’ that matches the date entered in the BPR16 segment of the 835 file. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgment’ message is received and states the following: Filed successfully. The Transaction Number is [number] Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Click [No]. Close the form. Open the '835 Health Care Claim Payment/Advice' form. Select 'Post File' option. Select the compiled file. Populate all the required fields with desired value. Verify the Check/EFT# is populated correctly with the status of acknowledged or unacknowledged in the 'Check/EFT#' checkbox. Check the Check/EFT# that acknowledged in above steps. Click [Process File]. Verify the file posts successfully. Open the 'Client Ledger' for the client. Verify the payments are posted correctly on the ledger. Open the 'Crystal Report' or any other SQL Data viewer. Create a query to retrieve data from the SYSTEM.billing_pay_adj_history table. Validate the check number field contains check number from the TRN-02 segment of the 835 file. Validate the 'pay_acknowledge_trans_num' column contains the transaction number from the 'Payment Acknowledgement' form for the Check/EFT. Scenario 3: 835 Healthcare Claim Payment/Advice - One check per file - Posting acknowledged payments and adjustments* Specific Setup: Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting includes value '1'. The 'Check Number' registry setting is set to '1'. The 'Posting Date for Automated 835s' registry setting is set to '1'. Claim Adjustment Group/ reason code Definition: A group code is selected for the credit adjustment code and debit adjustment reversal code. Note the adjustment codes and group code setup. Admission: Admit a client into an outpatient episode. Note the Client id/name, Admission date/program. Guarantor/Payors: Two existing guarantors are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Financial Eligibility: The desired guarantors identified above are assigned to the client. Note the primary and secondary guarantor. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to one of the guarantors assigned to the client. Close charges. Electronic Billing: Claim the service using the 837 Professional bill for the guarantor. Create an 835 file based on the claim information found in the 837 professional bill. Steps Open the '835 Health Care Claim Payment/Advice' form. Load and compile the 835 file created that includes the claim for the defined guarantor in the setup. Verify the 835 file loads/compiles successfully. Select 'Post File' option. Select the file that is recently compiled successfully. Populate all the required fields with desired value. Verify the Check/EFT# is populated correctly with the status of acknowledged or unacknowledged in the 'Check/EFT#' checkbox. Check the Check/EFT# that is unacknowledged. Click [Process File]. Verify the message: 'Selecting Unacknowledged Check/EFT numbers is not permitted.' Click [OK]. Close the form. Open the ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’ from the TRN02 segment of the 835 file created in the setup. Enter desired value in ‘Amount’ that matches the amount entered in the CLP04 segment of the 835 file. Select desired ‘Guarantor’ set up in the setup section. Note: If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’ that matches the date entered in the BPR16 segment of the 835 file. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgment’ message is received and states the following: Filed successfully. The Transaction Number is [number] Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Note the transaction number. Click [No]. Close the form. Open the '835 Health Care Claim Payment/Advice' form. Select 'Post File' option. Select the file that is recently compiled successfully. Populate all the required fields with desired value. Verify the Check/EFT# is populated correctly with the status of acknowledged or unacknowledged in the 'Check/EFT#' checkbox. Check the Check/EFT# that acknowledged in above steps. Click [Process File]. Verify the file posts successfully. Open the 'Client Ledger' for the client. Verify the payments are posted correctly on the ledger. Open the 'Crystal Report' or any other SQL Data viewer. Create a query to retrieve data from the SYSTEM.billing_pay_adj_history table. Validate the check number field contains check number from the TRN-02 segment of the 835 file. Validate the date of payment column contains the posting date from the '835 Health Care Claim Payment/Advice' form. Validate the 'pay_acknowledge_trans_num' column contains the transaction number from the 'Payment Acknowledgement' form for the Check/EFT. Scenario 4: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Acknowledged payments* Specific Setup: Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting is set to '1'. The 'Check Number' registry setting is set to '1'. The 'Posting Date for Automated 835s' registry setting is set to '2'. Claim Adjustment Group/ reason code Definition: A group code is selected for the credit adjustment code and debit adjustment reversal code. Note the adjustment codes and group code setup. Facility Defaults: The 'File Input Path On Server For 835 Files' input box set to desired path. The 'Output Path On Server For Electronic Files' input box set to the location where electronic files are saved. 835 Import/Export File Configuration: The 'Process File Path' input box set to desired location to be used to store the 835 file which is ready to process (i.e. "c:\Billing\835 \proc\"). The 'Successful File Path' input box set to desired location to be used to store the 835 file which is successfully processed (i.e. "c:\Billing\835 \succ\"). The 'Error File Path input box set to desired location to be used to store the 835 file which is not processed successfully (i.e. "c:\Billing\835 \error\"). The 'Default 835 Filing User' input box is set to desired username. The 'Processing Interval' input box is set to desired value. The 'Interval Units' radio button is set to desired value. Admission: Admit a client into an outpatient episode. Note the Client id/name, Admission date/program. Guarantor/Payors: An existing guarantor is identified who have a Financial Class that has the Extended Data Element for '(1500) System Financial Class' set to 'Self Pay'. Note the guarantor codes/names. 837 section: Set the Submitter Payer Identification Code (1000A-N1-04) input box to the value that match with the N1PR-04 segment of the 835 file (i.e.N1PR1000A-N1-2XV1000A-N1-04~). Financial Eligibility: The desired guarantors identified above are assigned to the client. Note the primary and secondary guarantor. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to one of the guarantors assigned to the client. Close charges. Electronic Billing: Claim the service using the 837 Professional bill for the guarantor. Create an 835 file based on the claim information found in the 837 professional bill. Steps Place the 835 file created in the setup section in the Process File Path folder identified in the 'Facility Defaults' form (i.e. "c:\Billing\835 Files\proc\"). Wait for desired time set up in the 'Facility Defaults' form. Verify that the file will be removed from the Process file folder and added to the Success folder. Open the '835 Health Care Claim Payment/Advice' form. Select 'Post File' option. Select the file that is recently moved to Success folder. Verify the status of the file is 'Partial-Posted'. Verify the Check/EFT# is populated correctly with the status of unacknowledged in the 'Check/EFT#' checkbox. Close the form. Open the ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’ from the TRN02 segment of the 835 file created in the setup. Enter desired value in ‘Amount’ that matches the amount entered in the CLP04 segment of the 835 file. Select desired ‘Guarantor’ set up in the setup section. Note: If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’ that matches the date entered in the BPR16 segment of the 835 file. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgment’ message is received and states the following: Filed successfully. The Transaction Number is [number] Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Click [No]. Close the form. Wait for desired time set up in the 'Facility Defaults' form. Open the 'Client Ledger' for the client. Verify the payments are posted correctly on the ledger. Open the 'Crystal Report' or any other SQL Data viewer. Create a query to retrieve data from the SYSTEM.billing_pay_adj_history table. Validate the check number field contains check number from the TRN-02 segment of the 835 file. Validate the date of payment column contains the check date as 'date of payment' when the 835 file is posted. Validate the 'pay_ack_transaction_num' displays correct transaction number for the check which is acknowledged in the 'Payment Acknowledgement' form. Scenario 5: Client Merge - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->System Maintenance->Client Merge->->->Allow Merging Into Existing Episode = Y. Avatar PM->System Maintenance->Client Merge->->->Allow Merging Of All Client Data Through Single Filing = Y. Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Program Maintenance: Program 1 exists. Program 2 exists. Client 1: Is enrolled in Program 1. Note the client ID. Financial Eligibility record is for a self-pay guarantor. Client Charge Input has been used to create a charge that distributed to the self-pay guarantor. Deposit Entry has been used to make a payment for the self-pay guarantor. Note the date and amount. Crystal Reports or other SQL reporting tool has been used to create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 1. The query results have been validated and saved. Client 2: Is enrolled in Program 2. Note the client ID. Steps Open ‘Client Merge’. Enter ‘Client 1’ in ‘Source Client’. Enter ‘Client 2’ in ‘Target Client’. Select ‘Yes’ in ‘Merge All Client Data Through Single Filing’. Select ‘Yes’ in ‘Create New Episode On Merge’. Click [File]. Click [Yes]. Click [OK]. Close the form. Use Crystal Reports or other SQL reporting tool to create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 1. Validate that no results are returned. Use Crystal Reports or other SQL reporting tool to create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2. Validate that the query results are equal to the saved results from setup, except for the ‘Episode_Number’, which will be ‘2’, and the ‘PATID’ field, which will be the ID of Client 2. Close the query results. Scenario 6: Client Delete - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Admit a new test client that will be used in the ‘Client Delete’ form. Note the client’s ID. Assign a Financial Eligibility record to the client. Use 'Deposit Entry' to post a payment to the client. Note the details of the payment. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client. Validate that payment data is correct. Save the query. Steps Open ‘Delete Service’ Select the desired ‘Client ID’. Enter the desired ‘Start Date’. Click the ‘End Date’ ‘T’ button. Select ‘No’ in ‘Would You Like To Post A Charge Reversal Against The Selected Services’. Click [Display Client]. Select the payment in the ‘Service Delete’ checklist. Click [OK]. Click [Delete]. Click [OK]. Click [Yes]. Click [OK]. Close the form. Open ‘Delete Last Movement’. Enter desired client in ‘Select Client’. Click [OK]. Click [OK]. Click [OK]. Select the ‘Episode Number’. Click [Submit]. Click [Yes]. Open ‘Client Delete’. Click [OK]. Enter the desired ‘Client ID’. Click [Submit]. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client. Validate that no results are returned. Scenario 7: Change MR# - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘5’ at a minimum. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Admit a new test client that will be used in the ‘Change MR#’ form. Note the client’s ID. Assign a Financial Eligibility record to the client. Use 'Client Charge Input' to place a charge on the client's account. Use 'Deposit Entry' to post a payment to the client. Note the details of the payment. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client. Validate that payment data is correct. Save the query. Steps Open ‘Change MR#’. Select the client admitted above. Click [Assign MR#]. Validate that the ‘New Client ID#’ contains a different client ID noted in setup. Note the ID. Click [Submit]. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client ID noted in setup. Validate that no results are returned. Use Crystal Reports or other SQL reporting tool to query the 'SYSTEM.unacknowledged_payments' table, specific to the client ID noted in ‘Change MR#’. Validate that the results data is the same as the saved query, except for ‘PATID’, which will contain the ID noted in ‘Change MR#’. Close the query. myHealthPointe payments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Credit Card Configuration Deposit Entry System Task Scheduler CareFabric Monitor Dictionary Update (PM) Payment Acknowledgement Scenario 1: CareFabric – Receive ‘Payment Information’ from myHealthPointe - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘0'. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: 'Payment' definitions exist. The 'Payment' definition may be a 'Credit' (payment) or a 'Debit' (reversal). The definitions may have a value in the ‘Payment Acknowledgement Type’ field. Only 'Payment' definitions will be available in the 'Payment Acknowledgement' section of the 'Payment Acknowledgement' form. 'Adjustment' definitions exist. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Adjustment’ and 'Payment' definitions will be available in the ‘Payment Acknowledgement’ form in the ‘Post Payment Accounting Entry' section of the 'Payment Acknowledgement' form. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Agency uses the myHealthPointe payment portal to accept patient electronic payments. Clients: Client 1: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Client 2: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Tester can create a query of SQL tables. Steps Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 1' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Open 'Registry Settings'. Change the value of the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting to include minimum values of '5&6', Click [Submit]. Click [OK]. Click [No]. A payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2, using the 'PATID'. Validate that payment data is correct. Save the query. Open 'Client Ledger' and process the report. Validate that the payment does not display in the report. Close the report. Close the form. Open the 'Payment Acknowledgement' form. Select the 'Post Front Office and myHP Payments' section. Click 'T' in 'Payment Collection Date'. Select desired value in 'Treatment Service'. Select 'myHP' in 'Type'. Click [Review]. Select the row specific to 'Client 2'. Click [OK]. Enter desired 'Batch Number'. Enter desired 'Deposit Date'. Select desired 'Category'. Enter desired 'Bank Ref#'. Enter desired 'Comments'. Click [Post]. Refresh the query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2. Validate that the table no longer contains data for 'Client 2'. Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 2' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Scenario 2: CareFabric – Receive ‘Payment Information’ from myHealthPointe - Validate 'SYSTEM.unacknowledged_payments' table. Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement = Y. Avatar PM->Billing->Remittance Processing->->->Prevent Posting Payments Unless Payment has been Acknowledged = ‘0'. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: 'Payment' definitions exist. The 'Payment' definition may be a 'Credit' (payment) or a 'Debit' (reversal). The definitions may have a value in the ‘Payment Acknowledgement Type’ field. Only 'Payment' definitions will be available in the 'Payment Acknowledgement' section of the 'Payment Acknowledgement' form. 'Adjustment' definitions exist. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Adjustment’ and 'Payment' definitions will be available in the ‘Payment Acknowledgement’ form in the ‘Post Payment Accounting Entry' section of the 'Payment Acknowledgement' form. User Definition has been used to give the tester access to the 'Payment Acknowledgement' form and the ‘SYSTEM.unacknowledged_payments’ table. Agency uses the myHealthPointe payment portal to accept patient electronic payments. Clients: Client 1: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Client 2: Is enrolled in myAvatar and has an outstanding Self-Pay balance. Tester can create a query of SQL tables. Steps Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 1' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form. Open 'Registry Settings'. Change the value of the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting to include minimum values of '5&6', Click [Submit]. Click [OK]. Click [No]. A payment is made in the myHealthPointe payment portal. Note all information regarding the payment. Create a query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2, using the 'PATID'. Validate that payment data is correct. Save the query. Open 'Client Ledger' and process the report. Validate that the payment does not display in the report. Close the report. Close the form. Open the 'Payment Acknowledgement' form. Select the 'Post Front Office and myHP Payments' section. Click 'T' in 'Payment Collection Date'. Select desired value in 'Treatment Service'. Select 'myHP' in 'Type'. Click [Review]. Select the row specific to 'Client 2'. Click [OK]. Enter desired 'Batch Number'. Enter desired 'Deposit Date'. Select desired 'Category'. Enter desired 'Bank Ref#'. Enter desired 'Comments'. Click [Post]. Refresh the query of the 'SYSTEM.unacknowledged_payments' table, specific to Client 2. Validate that the table no longer contains data for 'Client 2'. Create a query of the 'SYSTEM.billing_pay_adj_history' table, specific to 'Client 2' using the 'PATID'. Validate the data for the following fields and any other desired fields: 'GUARANTOR_ID', 'date_of_payment', 'payment_amount', and 'option_id' which will contain 'PatientPortal' indicating that the payment was made in the myHealthPointe payment portal. Open 'CareFabric Monitor'. Validate the PatientPortalPaymentProcessed dialog contains "1. Payment Amount 2. Payment method: ACH or CC 3. Account ID 4. Transactional ID". Open 'Client Ledger' and process the report. Validate that the payment displays in the report. Close the report. Close the form.	Topics • Payment Acknowledgement • Deposit Entry • Web Services • File Import • Registry Settings • 835 Health Care Claim Payment/Advice • Database Tables • Client Management • CareFabric Monitor • CareFabric
Update 117 Summary \| Details Consent For Access - Consent For Network / Organization Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareConnect HIE Configuration Refresh HIE List Consent For Access Scenario 1: Consent For Access - CareConnect HIE Configuration - Consent Model = Query Specific Setup: Admission: An existing client is identified, or a new client is created. Note the client's id/name. Steps Open the 'CareConnect HIE Configuration' form. Validate the 'Consent Model' field is displayed and contains the following options: "Opt In", "Query", and "Opt Out". Select 'Query' in the 'Consent Model' field. Validate the 'Content' box on the first section. Select desired values. Click [Submit]. Open the 'Crystal Report' or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.ccd_upload_config' table. Validate the table contains '2' in the 'consent_req_for ' column. Close the report. Select a client identified in the setup section. Open the 'Consent For Access' form. Click [Add New Item]. Select 'Network' in the 'Consent For' field. Select 'Carequality' network in the 'Network' field. Verify the 'Consent To Query' field is disabled. Click [Lightbulb]. (The help message icon). Verify the help message displays "The 'Consent to Query' field will be enabled if the 'Consent Model' field on the 'CareConnect HIE Configuration' form has been submitted with a value of "Query"." Verify the 'Consent To Opt In/Opt Out' field is enabled. Select desired value from the field. Enter desired date to the 'Start Date'. Click [Submit].Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.consent_for_access' table. Validate the table contains a row for the client with the information filed in the previous steps. Close the report. Open the 'Consent For Access' form. Click [Add New Item]. Select 'Network' in the 'Consent For' field. Select Non-Carequality network in the 'Network' field. Verify the 'Consent To Query' field is enabled. Select desired value from the field. Click [Lightbulb]. (The help message icon). Verify the help message displays "The 'Consent to Query' field will be enabled if the 'Consent Model' field on the 'CareConnect HIE Configuration' form has been submitted with a value of "Query"." Verify the 'Consent To Opt In/Opt Out' field is disabled. Click [Lightbulb]. (The help message icon). Verify the help message displays "The 'Consent to Query' field will be enabled if the 'Consent Model' field on the 'CareConnect HIE Configuration' form has been submitted with a value of "Query"." Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.consent_for_access' table. Validate the table contains a row for the client with the information filed in the previous steps. Close the report. Open the 'Consent For Access' form. Click [Add New Item]. Select 'Organization' in the 'Consent For' field. Select any organization in the 'Network' field. Verify the 'Consent To Query' field is disabled. Click [Lightbulb]. (The help message icon). Verify the help message displays "" Verify the 'Consent To Opt In/Opt Out' field is enabled. Select desired value from the field. Enter desired date to the 'Start Date'. Click [Submit].Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.consent_for_access' table. Validate the table contains a row for the client with the information filed in the previous steps. Close the report. Open the "CareConnect HIE Configuration" form. Validate the 'Content' box on the first section. Validate all data displays as it was data entered. Close the form. Scenario 2: CareConnect HIE Configuration - Consent Model = Opt In/Opt Out Specific Setup: Admission: An existing client is identified, or a new client is created. Note the client's id/name. Steps Open the 'CareConnect HIE Configuration' form. Validate the 'Consent Model' field is displayed and contains the following options: "Opt In", "Query", and "Opt Out". Select 'Opt In' in the 'Consent Model' field. Validate the 'Content' box on the first section. Select desired values. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.ccd_upload_config' table. Validate the table contains '1' in the 'consent_req_for ' column. Close the report. Select a client identified in the setup section. Open the 'Consent For Access' form. Click [Add New Item]. Select any value in the 'Network' field. Validate the 'Consent To Query' field is disabled. Validate the 'Consent To Opt In/Opt Out' field is enabled and required. Click [Lightbulb]. (The help message icon). Validate the help message displays "The 'Consent to Opt In/Opt Out' field will be enabled if the 'Consent Model' field on the 'CareConnect HIE Configuration' form has been submitted with a value of "Opt In" or "Opt Out". When using this field for Carequality, it functions as a 'consent to release information'." Select the desired value in the 'Consent To Opt In/Opt Out' field. Enter the current date in the 'Start Date' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.consent_for_access' table. Validate the table is populated and contains a row for the client with the information filed in the previous steps. Close the report. Open the "CareConnect HIE Configuration" form. Select 'Opt Out' in the 'Consent Model' field. Validate the 'Content' box on the first section. Select desired values. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.ccd_upload_config' table. Validate the table contains '3' in the 'consent_req_for ' column. Close the report. Select a client identified in the setup section. Open the 'Consent For Access' form. Click [Add New Item]. Select any value in the 'Network' field. Validate the 'Consent To Query' field is disabled. Validate the 'Consent To Opt In/Opt Out' field is enabled and required. Click [Lightbulb]. (The help message icon). Validate the help message displays "The 'Consent to Opt In/Opt Out' field will be enabled if the 'Consent Model' field on the 'CareConnect HIE Configuration' form has been submitted with a value of "Opt In" or "Opt Out". When using this field for Carequality, it functions as a 'consent to release information'." Select the desired value in the 'Consent To Opt In/Opt Out' field. Enter the current date in the 'Start Date' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the PM namespace. Create a report using the 'SYSTEM.consent_for_access' table. Validate the table is populated and contains a row for the client with the information filed in the previous steps. Close the report.	Topics • Consent for Access • NX
Update 118 Summary \| Details Avatar PM is modified to increase length of client name and allow spaces to be included. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Update Client Data Chart View (Client Header) Pre Admit Discharge Cross Episode Financial Eligibility Discharge Financial Eligibility Scenario 1: Admission - validate Registry setting 'Allow spaces in Client Name'. Specific Setup: Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open 'Admission (Outpatient)' form. Set the 'Last Name' on the 'Select Client' popup window to any name value. Set the 'First Name' on the 'Select Client' popup window to any name value. Select the gender in the 'Sex' drop down list. Click [Search]. Click [OK] on the 'Search Results' popup window: 'No matches found'. Click [New Client]. Click [Yes] on the 'Auto Assign Next ID Number' popup window. Click on the 'Demographics' section. Set the 'Client Last Name' to any name including one or more spaces. i.e.: 'Last Name'. Set the 'Client First Name' to any name including one or more spaces. i.e.: 'First Name' Set the 'Client Middle Name' to any name including one or more spaces. i.e.: 'Middle Name'. Complete any required fields. Click the 'Admission' section. Verify the 'Client Name' field contains the full name, including spaces. Click [Submit]. Right click on the client name in the 'Recent Clients' section. Click 'Display Chart'. Verify the client name displays all characters entered in the 'Admission' form. Note that the user may need to place the cursor over the client name and review the 'hover help' as it will display the client name. Scenario 2: Update Client Data - Validate client name allows spaces and client middle name displays up to 25 characters. Specific Setup: Avatar RADplus 2022 Update 126 is required for full functionality. Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open 'Update Client Data' form for an existing client. Set the 'Client Last Name' field to a last name which includes spaces in the name i.e.: 'FRANKLIN MILLER MOTT' Set the 'Client First Name' field to a first name which includes spaces in the name i.e: 'BENJAMIN WALLY' Set the 'Client Middle Name' field to a middle name which includes spaces and is maximum of 25 characters i.e: 'BILL ED MIDDLE NAME LONG' Click [Submit]. Right click on the client name in the 'Recent Clients' list. Select 'Display Chart'. Verify the name displays in the client banner, including all spaces and a maximum of 25 characters for the middle name. Close the client chart. Scenario 3: Pre Admit Discharge web service validation Specific Setup: Existing 'Pre Admit' client whose full name is longer than 40 characters. Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. RADplus 2022 Update 126 is required for full functionality. Access to, and understanding of, SoapUI or other Web Service tools. Steps Using 'SoapUI' or another web service tool, consume the WSDL for the 'Pre Admit Discharge' form. Set the 'SystemCode' code to the agency system code for testing. Set the 'UserName' to the logged in user name. Set the 'Password' to the logged in user password. Set the 'DateOfDischarge' to the discharge date. Set the 'DischargeTime' to the time of discharge. Set the 'Discharge Practitioner' to a practitioner code (not the practitioner name). Set the 'Client ID' to the ID for the client to be discharged. Set the 'EpisodeNumber' to the client episode to be discharged. Click [Send]. Review the response and verify the response message displays: <Message>Client Pre-Admit Discharge web service has been filed successfully.</Message> Open 'Pre Admit Discharge' in Avatar. Select the client discharged in the Web Service. Verify the 'Date of Discharge' is set to the date entered in the Web Service. Verify the 'Time of Discharge' is set to the time entered in the Web Service. Verify the 'Discharge Practitioner' is set to the practitioner entered in the Web Service. Click [Close Form]. Scenario 4: Cross Episode Financial Eligibility - validate client name display with spaces and up to 100 characters in the name Specific Setup: A client (Client A) is admitted where the first name, middle name, and last name combined is up to 100 characters and spaces are included in the name. Note that a space will count as a character. Avatar PM 2022 Update 118 is required for full functionality. RADplus 2022 Update 126 is required for full functionality. Steps Open 'Cross Episode Financial Eligibility' form for Client A. Click 'Guarantor Selection' section. Click [Add New Item]. Select any value in the 'Guarantor #' field. Click [OK] on the 'Selecting This Guarantor Will Over-Write Any Previous Plan Information' pop up window. Complete remaining required fields as needed. Select 'Self' in the 'Client's Relationship to Subscriber' field. Verify the 'Subscriber's Last Name' field is populated with up to 40 characters. Verify the 'Subscriber's First Name' field is populated with up to 40 characters. Verify the 'Subscriber's Middle Name' field is populated with up to 25 characters. Click 'Cross Episode Financial Eligibility' section. Select a value from the 'Guarantor #1' drop down list. Click [Submit]. Scenario 5: Client Discharge web service Specific Setup: SoapUI or other web service tool. Client admitted with a long first and last name of up to 40 characters, and middle name of up to 25 characters. Spaces can be included. Avatar RADplus 2022 Update 126 is required for full functionality. Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open SoapUI or another web service tool. Consume the WebSvc.ClientDischarge.cls wsdl. Set the 'SystemCode', 'UserName', and 'Password' to correct values. Set 'DateofDischarge' field to the client discharge date. Set 'DischargePractitioner' to the discharging practitioner ID. Set 'DischargeReferral Type' to the Type code for the discharge. Set 'DischargeTime' to the time of the discharge. Set 'ClientID' to the client id to be discharged. This client should have a long last name and first name of up to 40 characters. Set 'EpisodeNumber' to the client episode to be discharged. Click 'Send' request. Validate the response displays 'Client Discharge web service has been filed successfully'. Open the 'Discharge' form in Avatar PM. Select the client discharged in the web service. Verify the data entered in the web service is correct. Close the form. Scenario 6: Validate Client Demographics web service updates the Update Client Data fields. Specific Setup: SoapUI or other web service tool. Client admitted with a long first and last name of up to 40 characters, and middle name of up to 25 characters. Spaces can be included. Avatar RADplus 2022 Update 126 is required for full functionality. Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open SoapUI or another web service tool. Consume the WebSvc.ClientDemographics.cls wsdl. Set the 'SystemCode', 'UserName', and 'Password' to correct values. Set 'ClientFirstName' to the first name of the client with a long first name, up to 40 characters. Set 'ClientMiddleName' to the middle name of the client with a long middle name, up to 25 characters. Set 'ClientName' to the <client last name,client first name>. Set 'ClientID' to the client id for the test client. Set any other field to the appropriate data such as ClientEmailAddress. Click 'Send'. Review the Response. Verify the message displays: <Message>Client Demographics web service has been filed successfully.</Message> Open the 'Update Client Data' form for the same client. Verify the data filed in the web service displays as entered. Close the form. Scenario 7: Financial Eligibility web service - validate client names with spaces and the name contains a maximum of 100 characters. Specific Setup: UP / PERMISSIONS Access to, and a working understanding of, SoapUI or other web service tool. Avatar RADplus 2022 Update 126 is required for full functionality. Client admitted where the client last and first names are maximum of 40 characters, including space(s). The client middle name should be a maximum of 25 characters, including spaces(s). Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open SoapUI or another web service tool. Consume the Websvc.FinancialEligibility.cls wsdl. Expand the WEBSVC.FinancialEligibility item. Expand FinancialEligibilitySoap item. Expand 'AddFinancialElig' item. Double click on 'Request 1'. Set the 'SystemCode', 'UserName', and 'Password' to correct values. Set 'ClientsRelationship' to any value such as '1'. Set 'CoverageEffectiveDate' to the date coverage started for the client. Set 'CustomizeGuarantorPlan' to '1'. Set 'GuarantorName' to the name of the guarantor being assigned. Set 'GuarantorNumber' to the ID number of the guarantor. Set 'GuarantorOrderNumber' to the number where the guarantor is to be listed. Use '1' if there is just one guarantor. Set 'GuarantorPlan' to any value such as '1'. Set 'EligibilityVerified' to 'Y'. Set 'MaximumCoveredDollars' to any dollar value. Set 'SubscribersName' to the full name of the client, up to 100 characters. Format is 'LastName,FirstName'. Set 'ClientID' to the ID number for the test client. Click 'Send'. Review the Response text. Complete any additional required fields. Click 'Send' again. Verify the Response states : <Message>Financial Eligibility web service has been filed successfully.</Message> Open 'Financial Eligibility' form in Avatar PM for the same client. Verify 'Guarantor #1' field is populated with the guarantor submitted in the web service. Click 'Guarantor Selection' tab. Verify the information sent thru the web service is populated correctly. Close the form. Scenario 8: Cross Episode Financial Eligibility web service - validate client names with spaces and the name contains a maximum of 100 characters. Specific Setup: Access to, and a working understanding of, SoapUI or other web service tool. Avatar RADplus 2022 Update 126 is required for full functionality. Client admitted where the client last and first names are maximum of 40 characters, including space(s). The client middle name should be a maximum of 25 characters, including spaces(s). Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form. Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms. Steps Open SoapUI or another web service tool. Consume the Websvc.CrossFinancialEligibility.cls wsdl. Expand the WEBSVC.CrossEpisodeFinancialEligibility item. Expand CrossEpisodeFinancialEligibilitySoap item. Expand 'AddCrossEpisodeFinancialElig' item. Double click on 'Request 1'. Set the 'SystemCode', 'UserName', and 'Password' to correct values. Set 'ClientsRelationship' to any value such as '1'. Set 'CoverageEffectiveDate' to the date coverage started for the client. Set 'CustomizeGuarantorPlan' to '1'. Set 'GuarantorName' to the name of the guarantor being assigned. Set 'GuarantorNumber' to the ID number of the guarantor. Set 'GuarantorOrderNumber' to the number where the guarantor is to be listed. Use '1' if there is just one guarantor. Set 'GuarantorPlan' to any value such as '1'. Set 'EligibilityVerified' to 'Y'. Set 'MaximumCoveredDollars' to any dollar value. Set 'SubscribersName' to the full name of the client, up to 100 characters. Format is 'LastName,FirstName'. Set 'ClientID' to the ID number for the test client. Click 'Send'. Review the Response text. Complete any additional required fields. Click 'Send' again. Verify the Response states : <Message>Cross Episode Financial Eligibility web service has been filed successfully.</Message> Open 'Cross Episode Financial Eligibility' form in Avatar PM for the same client. Verify 'Guarantor #1' field is populated with the guarantor submitted in the web service. Click 'Guarantor Selection' tab. Verify the information sent thru the web service is populated correctly. Close the form.	Topics • Registry Settings • Admission (Outpatient) • NX • Update Client Data • Financial Eligibility • Cross Episode Financial Eligibility
Update 119 Summary \| Details Client Ledger - Re-billed claims Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Financial Eligibility Create Interim Billing Batch File Electronic Billing Individual Cash Posting (PM) Client Charge Input Electronic Re-Billing Service Assignment Scenario 1: Client Ledger - Validating 'Claim' crystal report for payment/adjustments /transfers posted to client account Specific Setup: Posting/Adjustment Codes Definition: Identify an existing payment, adjustment and/or transfer codes. Note the codes/values for further testing. Admission: A new client is admitted in the inpatient program. Note the client's id/name, admission program, admission date. Guarantor/Payors: An existing guarantor is identified to assign to the client. Financial Eligibility: The existing guarantor is assigned to the client. Note the Guarantor code/value. Service Codes: An existing room and board service code is identified to render services to the client. Note the service code. Client Charge Input: 5-6 days of the room and board services are rendered to the client. Close Charges: The charges rendered to the client are closed. Steps Open the 'Electronic Billing' form. Run an 837 Institutional bill for the client. Verify the bill compiles successfully. Claim the services. Verify the bill compiles successfully. Open the 'Client Ledger' form. Process the report using 'Claim' ledger type and validate that the claim based report displays all the claim specific information. Open the ‘Individual Cash Posting’ form. Select the ‘Client’. Select desired value in the ‘Post By’ field. Click [Select Item(s) To Post Against]. A grid opens containing a row for all services. Select a desired row. Click [OK] when all desired rows have been selected. Note the ‘Information’ message and the current balance for the guarantor. Click [OK]. Enter desired value in ‘Posting Date’. Enter desired value in ‘Date of Receipt’. Validate that the ‘Guarantor’ defaulted to the guarantor in the current balance message. Enter desired value in ‘Dollar Amount To Be Posted’. Amount entered can be the full amount due or a partial amount due. Enter desired value in ‘Posting Code’. If desired, enter a value in ‘Check #’. Enter desired value in ‘Action For Remaining Balance If Applicable’. Click [Update Temporary File]. If desired, continue to add payment/adjustments/transfers using the steps above for all other services. Click [Submit] when all payment/adjustments/transfers have been completed. Open ‘Client Ledger’ for the client’. Process the report using ‘Simple' ledger type and validate that the payment/adjustments/transfers posted correctly. Process the report using ‘Claim' ledger type and validate that the payment/adjustments/transfers posted correctly specific to claim. Close the form. Scenario 2: Client Ledger - Validating Simple/ Crystal/ Claim types of the ledger for Re-bill claims Specific Setup: Admission: A new client is admitted, or an existing client is identified. Note the client's id/name, admission program, admission date. Guarantor/Payors: An existing guarantor is identified to assign to the client. Financial Eligibility: The existing guarantor is assigned to the client. Note the Guarantor code/value. Service Codes: An existing service code is identified to render services to the client. Note the service code. Client Charge Input: A service is rendered to the client. Client Ledger: The service distributed to the guarantor assigned to the client in the financial eligibility. Close Charges: The service rendered to the client is closed. Create Interim Billing Batch File: An interim file is created which covers client, guarantor and service distributed to the guarantor. Note the batch file number/name. Electronic Billing: An 837 bill is created and claimed for the service. Note the claim number. Electronic Re-Billing Assignment: The claim created above is re-billed. Electronic Billing: An 837 bill is created and claimed for the re-bill service created in above step. Steps Open the 'Client Ledger' form. Enter desired client in the 'Client ID' field. Select 'Claim' from the 'Claim/Episode/All Episodes' field. Select desired claim # created in the setup section. Click [Process]. The crystal report launched successfully. Verify the report displays correct re-bill information. Close the report. Select 'Crystal' from the 'Claim/Episode/All Episodes' field. Select desired claim # created in the setup section. Click [Process]. The crystal report launched successfully. Verify the report displays correct re-bill information. Close the report. Select 'Simple' from the 'Claim/Episode/All Episodes' field. Select desired claim # created in the setup section. Click [Process]. The crystal report launched successfully. Verify the report displays correct re-bill information. Close the report.	Topics • Client Ledger • NX
Update 120 Summary \| Details Dictionary Update - 'Location' dictionary Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (PM) Scenario 1: Dictionary Update - Validate the 'Location' dictionary Steps Access the 'Dictionary Update' form. Select "Client" in the 'File' field. Select "Data Element Number" in the 'Data Element' field. Select "(10006) Location" in the 'Data Element' field. Enter the desired value in the 'Dictionary Code' field. Enter the desired value in the 'Dictionary Value' field. Validate the 'Extended Dictionary Data Element' field contains "(1684) Time Zone". Select "(1684) Time Zone" in the 'Extended Dictionary Data Element' field. Select "US/Central" in the 'Extended Dictionary Value (Single Dictionary)' field. Click [Apply Changes] & Click [OK]. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Data Element Number" in the 'Data Element' field. Select "(10006) Location" in the 'Data Element' field. Click [Print Dictionary]. Validate the location dictionary is displayed with the time zone selected. Click [Close] and close the form. Program Maintenance - 'Time Zone' field Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: SoapUI - ProgramMaintenance SoapUI - ProgramMaintenance - AddProgramMaintenance Program Maintenance Scenario 1: 'WEBSVC.ProgramMaintenance' - add a program Steps Access SoapUI for the 'ProgramMaintenance' - 'AddProgramMaintenance' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter "Y" in the 'Active' field. Enter the desired value in the 'Description' field. Enter the desired value in the 'Location' field. Enter the desired value in the 'Program' field. Enter the desired value in the 'ProgramCode' field. Enter the desired value in the 'ProgramType' field. Enter the desired value in the 'RRG' field. Enter the desired value in the 'ReqAdmitPract' field. Enter the desired value in the 'TreatmentService' field. Enter the desired value in the 'TreatmentSetting' field. Enter the desired value in the 'Time Zone' field. Enter the desired value in the 'UsageType' field. Enter the desired value in the 'EVVProviderOrgID' field. Click [Run]. Validate the response contains: Program Maintenance web service has been filed successfully. Access the 'Program Maintenance' form. Select "Edit" in the 'Add Or Edit Program' field. Select the program added in the previous steps in the 'Program' field. Validate all previously filed data is displayed. Close the form. Scenario 2: File Import - 'Program Maintenance' file - Add program. Specific Setup: A 'Program Maintenance' file import file is created with the required field values. Steps Open the "File Import" form. Select the "Program Maintenance" in the 'File Type' field. Select "Upload New File" in the 'Action' field. Click [Process Action]. Select the "File A". Select "Compile/Validate File" in the 'Action' field. Select the "File A" in the 'Files(s)' field. Click [Process Action]. Validate an Information message is displayed stating: Compiled Click [Ok]. Select "Print File" in the 'Action' field. Select the "File A" in the 'Files(s)' field. Click [Process Action]. Validate the Report Viewer displays the contents of the file. Click [Close Report]. Select "Post File" in the 'Action' field. Click [Process Action]. Select the "File A". Validate an Information message is displayed stating: Posted. Click [Ok] and close the form. Open the "Program Maintenance" form. Click [Edit]. Validate the form is filed with the data based on the uploaded file. Close the form. Scenario 3: File Import - 'Program Maintenance' file - Edit program. Specific Setup: A 'Program Maintenance' file import file is created that contains the information for the 'Billing Provider NPI' and ‘Type of Bill (First Two Digits)’ fields along with all other required fields. Steps Open the "File Import" form. Select the 'Program Maintenance' File Type. Compile the program maintenance file import file created in the setup section. Verify that the file compiles successfully. Select the 'Print File' option and review the report. Verify that the ‘Billing Provider NPI’ and ‘Type of Bill (First Two Digits)’ fields are added to the report and it displays the correct data entered in the file import file. Post the file which is compiled successfully in step #1c. Verify that the file posts successfully. Select the "Print File" option and review the report. Verify that the ‘Billing Provider NPI’ and ‘Type of Bill (First Two Digits)’ fields are added to the report and it displays the correct data entered in the file import file. Open the 'Program Maintenance' form. Click "Edit" in the 'Add/Edit' field to edit the program imported in step #1. Verify the ‘Billing Provider NPI’ and ‘Type of Bill (First Two Digits)’ fields are added to the program correctly. Scenario 4: Program Maintenance - Add/Edit program Steps Access the 'Program Maintenance' form. Select "Add" in the 'Add Or Edit Program' field. Enter the desired value in the 'Program Code' field. Enter the desired value in the 'Description' field. Select the desired value in the 'Treatment Setting' field. Select the desired value in the 'RRG' field. Select the desired value in the 'Treatment Service' field. Select the desired value in the 'Program Type' field. Select the desired value in the 'Location' field. Validate the 'Time Zone' field is displayed. Select the desired value in the 'Time Zone' field. Click [File Program] and stay in the form. Select "Edit" in the 'Add Or Edit Program' field. Select the program added in the previous steps in the 'Program' field. Validate all previously filed data is displayed. Validate the 'Time Zone' field contains the value selected in the previous steps. Click [Discard] and close the form, Avatar PM is enhanced to support future functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Charge Input Dictionary Update (PM) Program Maintenance Scenario 1: Validate the 'Time Zone Determination for UTC Service Entry' registry setting Steps Access the 'Registry Settings' form. Enter "Time Zone Determination for UTC Service Entry" in the 'Limit Registry Settings to the Following Search Criteria' field. Select "Yes" in the 'Include Hidden Registry Settings' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains: "RADplus->General->Facility->->->Time Zone Determination for UTC Service Entry". Validate the 'Registry Setting Details' field contains: "Define the priority order by which Time Zone should be assigned for populating the Service UTC time at time of filing a service record in a UTC enabled system. Enter the corresponding number(s) separated by an '&' to determine the time zone for Service Entry: 1:'User/User Role' 2:'Location' 3:'Program'. Example: '3&2' would define the priority to check the Program level for a Time Zone and if one is not configured then look at the associated Location for the Service Entry. If the Service is generated by an Appointment, the Appointment Site Time Zone will take precedence over this registry setting. If nothing is entered in this registry setting or the specified option(s) do not have a Time Zone defined, Service Record UTC values will not be stored. Enter the desired value(s) in the 'Registry Setting Value' field. Click [Submit]. Validate a message is displayed stating: "Successful filing". Click [OK] and close the form.	Topics • Dictionary • Program Maintenance • Registry Settings
Update 122 Summary \| Details "Enable Multiple Add-On Code Per Primary Code " Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (CWS) Progress Notes (Group and Individual) Site Specific Section Modeling Import/Export (CWS) Scenario 1: 'Site Specific Section Modeling' - Validate 'Add-On' fields enabled/disabled via the "Enable Multiple Add-On Code Per Primary Code" registry setting Specific Setup: Have a system with a copy of the "Progress Note (Group and Individual)" form, created via the "Create New Progress Note" form. [PNCopy1] Have registry setting 'Enable Multiple Add-On Code Per Primary Code Functionality' set to "N". Steps Open form "Site Specific Section Modeling" Select the "Progress Note (Group and Individual)" form Select the "Prompt Definition" section In the "Prompt Definition" grid, Locate and select the 'Add-On Service' field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the 'Add-On Duration', field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the 'Add-On Service Notes', field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the 'Save Add-On Service Notes' field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the 'Selected Add-On Services' field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the ''Select Add-On Service Entry to Edit/Remove' field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Locate and select the 'Remove Add-On Service' field for edit, Verify the 'Exclude from Data Collection Instrument' field is disabled Close the form Repeat step 1 for the progress note form copy [PNCopy1] Validate results are as expected Open form "Progress Note (Group and Individual)" Validate fields 'Add-On Service', 'Add-On Duration', 'Add-On Service Notes', Save Add-On Services, 'Selected Add-On Services', 'Select Add-On Service Entry to Edit/Remove' and 'Remove Add-On Service', are not present on the form as expected Repeat step 3 for the progress note form copy [PNCopy1] Validate results are as expected Open form "Registry Settings" Search for registry setting " 'Enable Multiple Add-On Code Per Primary Code Functionality' Click to edit the registry setting and set the "Registry Setting Value" field to "Y" Submit the form Open form "Site Specific Section Modeling" Select the "Progress Note (Group and Individual)" form Select the "Prompt Definition" section In the "Prompt Definition" grid, Locate and select the 'Add-On Service' field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the 'Add-On Duration', field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the 'Add-On Service Notes', field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the 'Save Add-On Service Notes' field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the 'Selected Add-On Services' field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the ''Select Add-On Service Entry to Edit/Remove" field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Locate and select the 'Remove Add-On Service' field for edit, Verify the 'Exclude from Data Collection Instrument' field is enabled and set the value to "No" Submit the form Return to form "Progress Note (Group and Individual)" Validate fields 'Add-On Service', 'Add-On Duration', 'Add-On Service Notes', Save Add-On Services, 'Selected Add-On Services', 'Select Add-On Service Entry to Edit/Remove' and 'Remove Add-On Service' are now present and enabled on the form, as expected Repeat step 6 and 7 for the progress note form copy [PNCopy1] Validate results are as expected	Topics • Site Specific Section Modeling
Update 123 Summary \| Details Support is added for other products and modules Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Client Charge Input Guarantors/Payors Managed Care Authorizations Scenario 1: Client Charge Input - Validate error message when authorizations are required Specific Setup: A guarantor is defined that requires authorizations and will disallow service if missing (Guarantor A). A client has "Guarantor A" selected as their guarantor in 'Financial Eligibility' (Client A). "Client A" does not have any valid authorizations on file in 'Managed Care Authorization'. Steps Access the 'Client Charge Input' form. Enter the current date in the 'Date Of Service' field. Select "Client A" in the 'Client ID' field. Select the desired value in the 'Service Code' field. Select the desired practitioner in the 'Practitioner' field. Validate an error message is displayed stating: No valid authorizations found on file. Click [OK] and close the form. Scenario 2: Client Charge Input - Validate warning message when authorizations are required Specific Setup: A guarantor is defined that requires authorizations and will warn if missing (Guarantor A). A client has "Guarantor A" selected as their guarantor in 'Financial Eligibility' (Client A). "Client A" does not have any valid authorizations on file in 'Managed Care Authorization'. Steps Access the 'Client Charge Input' form. Enter the current date in the 'Date Of Service' field. Select "Client A" in the 'Client ID' field. Select the desired value in the 'Service Code' field. Select the desired practitioner in the 'Practitioner' field. Validate a warning message is displayed stating: No valid authorizations found on file. Click [OK] and [Submit]. Please note: since this is just a warning, the user can proceed without authorization, if desired. Access the 'Client Ledger' form. Select "Client A" in the 'Client ID' field. Select "All Episodes" in the 'Claim/Episode/All Episodes' field. Select "Simple" in the 'Ledger Type' field. Select "Yes" in the 'Include Zero Charges' field. Click [Process]. Validate the report contains the service filed in the previous steps. Close the report and the form.	Topics • Client Charge Input • Client Ledger • Managed Care Authorizations
Update 125 Summary \| Details Dictionary Update - Client file Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (PM) Scenario 1: Dictionary Update - Client file - Add/Edit/Print dictionary Steps Open the 'Dictionary Update' form. Select 'Client' in the 'File' field. Select 'Claim Follow-Up Status' in the 'Data Element' field. Enter desired code to the 'Dictionary Code' field. Note the code. Enter desired value to the 'Dictionary Value' field. Note the value. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Enter desired code to the 'Dictionary Code' field. Note the code. Enter desired value to the 'Dictionary Value' field. Note the value. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Claim Follow-Up Status' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values added in previous step display correctly. Close the report. Select 'Input Dictionary Code(s)' section. Verify the 'File' field contains 'Client'. Verify the 'Data Element' is set to the 'Claim Follow-Up Status'. Select desired code which is added in previous step in the 'Dictionary Code' field. Verify the correct 'Dictionary Value' displays for the selected code. Update the value in the 'Dictionary Value' field. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Claim Follow-Up Status' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values updated in previous step display correctly. Close the report. Close the form. Quick Billing Rule Definition - Include "errors.txt" File Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors Financial Eligibility Quick Billing Rule Definition Client Charge Input Quick Billing Scenario 1: Qucik Billing Rule Definition - 'Include "errors.txt" File' and 'File Location' for "errors.txt". Specific Setup: Registry Setting: The 'Enable New Quick Billing Format' registry setting is set to 'Y'. Facility Defaults: Set the path to store the quick billing file in the 'Output Path On Server For Electronic Files' field. Note the path. Please note: This path will be used in the 'File Location' field of the 'Quick Billing Rule Definition' form. File Explorer: A physical location is created in the system which is defined in the 'Facility Defaults' form. Another location is created under the folder which is defined for the 'File Location'. Guarantors/Payors: An existing guarantor is identified. Note the guarantor code/value. Client: Select a client that has missing data that will prevent it from being billed or create a new client. This example will use a missing ‘Policy Number’ in Financial Eligibility’. Note the guarantor. Financial Eligibility: A guarantor is assigned to the client identified above. Client Charge Input: Rendered services that distributed to guarantor. Client Ledger: Verify all the charges distributed to the guarantor identified above. Quick Billing Rue Definition: A quick billing rule definition is defined that will include the guarantor, service code, and program. ‘Send Generated Bill To' = File. Note the ‘File Location’ value. ‘Include “errors.txt” File’ = ‘No’. Steps Open ‘Quick Billing’. Select ‘Add’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter desired ‘First Date Of Service To Include’. Enter desired ‘Last Date Of Service To Include’. Select desired ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges ’, and ‘Generate Bills’ in ‘Quick Billing Tasks to Execute’. Enter desired ‘Date Of Claim‘. Validate that the file does not compile successfully because of the missing policy number in the financial eligibility. Close the form. Go to the ‘File Location’ and verify that no error file was created. Open ‘Quick Billing Rule Definition’ and edit the rule from ‘Setup’. Change the ‘Include “errors.txt” File’ to ‘Yes’. Submit the form. Open ‘Quick Billing’. Select ‘Add’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter desired ‘First Date Of Service To Include’. Enter desired ‘Last Date Of Service To Include’. Select desired ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges’, and ‘Generate Bills’ in ‘Quick Billing Tasks to Execute’. Enter desired ‘Date Of Claim‘. Validate that the file does not compile successfully because of the missing policy number in the financial eligibility. Close the form. Go to the ‘File Location’ and verify that the error file was created. Open ‘Quick Billing Rule Definition’ and edit the rule from ‘Setup. Change the ‘Include “errors.txt” File’ to ‘In Separate Location’. Enter a value in ‘File Location for "errors.txt" File’ that differs from the ‘File Location’ value’. Submit the form. Open ‘Quick Billing’. Select ‘Add’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter desired ‘First Date Of Service To Include’. Enter desired ‘Last Date Of Service To Include’. Select desired ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges’, and ‘Generate Bills’ in ‘Quick Billing Tasks to Execute’. Enter desired ‘Date Of Claim‘. Validate that the file does not compile successfully because of the missing policy number in the financial eligibility. Close the form. Go to the ‘File Location for "errors.txt" File’ and verify that the error file was created. Fix the client data, in this example the missing ‘Policy Number’ in Financial Eligibility’. Open ‘Quick Billing’. Select ‘Add’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter desired ‘First Date Of Service To Include’. Enter desired ‘Last Date Of Service To Include’. Select desired ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges’, ‘Generate Bills’, and 'Create Claims' in ‘Quick Billing Tasks to Execute’. Enter desired ‘Date Of Claim‘. Validate that the ‘Compile Complete’ message indicates that no errors were found. Go to the ‘File Location’ and verify that the billing file was created. Open 'Client Ledger' for the client and validate that the claim number displays.	Topics • Dictionary • Quick Billing
Update 126 Summary \| Details Guarantor/Program Billing Defaults - Select Segments To Suppress Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Program Maintenance Guarantors/Payors Site Specific Section Modeling (PM) Practitioner Enrollment Practitioner Numbers By Guarantor And Program Financial Eligibility Dictionary Update (PM) Client Charge Input Create Interim Billing Batch File Electronic Billing Scenario 1: Guarantor/Program Billing Defaults - 837 Professional - Select Segments To Suppress Specific Setup: Site specific Section Modeling: A site specific Practitioner field (SS Treatment Practitioner 1) is set up on the 'Client Charge Input' via site specific section modeling as the Ordering Provider. Check the 'Use As Ordering Provider (837P-2420E)' in the 'Product Custom Logic Definition' field. Please note :The 'Client Charge Input' form use the Practitioner which is specified in the 'Practitioner Enrollment' as the ordering provider. Practitioner Enrollment: Create a new or identify an existing practitioner to be used as an ordering practitioner. Note the Practitioner id, Name, NPI Number, Taxonomy Code. Guarantors/Payors: Identify an existing guarantor or create a new guarantor. Note the guarantor's code/name. Program Maintenance: Identify an existing outpatient program to be used for the client's admission. Note the program code/name. Practitioner Numbers By Guarantor and Program: Create a record using a practitioner, guarantor and program identified above. Service Codes: A professional service code is identified. Note the service code. Dictionary Update: Following loop-segments set up in the 'Other Tabled Files' and dictionary 13150 'Select Segment's to Suppress' Dictionary: 2420E-N3 - Ordering Provider Address (2420E-N3) 2420E-N4 - Ordering Provider City (2420E-N4) 2420E-REF - Ordering ProviderSec. Info (2420E-REF) 2420E-PER - Ordering Provider Contact (2420E-PER) Guarantor/Program Billing Defaults template: Edit an existing template to assign the guarantor identified above. Note the template name. 837 Professional section: Following items are selected in the 'Select Segments To Suppress': 2420E-N3 - Ordering Provider Address (2420E-N3) 2420E-N4 - Ordering Provider City (2420E-N4) 2420E-REF - Ordering ProviderSec. Info (2420E-REF) 2420E-PER - Ordering Provider Contact (2420E-PER) Admission: A new client is admitted in the outpatient program with attending practitioner. Financial Eligibility: The guarantor assigned to the template configured in the 'Guarantor/Program Billing Defaults' is assigned to the client. Diagnosis: An admission diagnosis record is created for the client. Client Charge Input: A professional service is rendered to the client on the admission date. An ordering practitioner is added for these charges. Charges are closed. An interim billing batch is created to include client, services, and guarantor. Steps Open the 'Electronic Billing' form. Compile the 837 Professional for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Verify the segments display the attending provider identification information from the 'Practitioner Enrollment' form. Close the report. Close the form. Open the 'Guarantor/Program Billing Defaults' form. Go to '837 Professional section'. Select '2420E-N3 - Ordering Provider Address (2420E-N3)', '2420E-N4 - Ordering Provider City (2420E-N4)', '2420E-REF - Ordering ProviderSec. Info (2420E-REF)' and '2420E-PER - Ordering Provider Contact (2420E-PER)' in the 'Select Segments To Suppress' checklist. Submit the form. Open the 'Electronic Billing' form. Compile an 837 Professional bill for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Locate the 2420E loop. The 2420E loop starts with NM1DK. Verify the following segments are suppressed correctly from the 2420E loop of the bill. 2420E-N3 - Ordering Provider Address (2420E-N3) 2420E-N4 - Ordering Provider City/State/Zip Code (2420E-N4) 2420E-REF - Ordering ProviderSec. Info (2420E-REF) 2420E-PER - Ordering Provider Contact (2420E-PER) Close the report. Close the form. Open the 'Guarantor/Program Billing Defaults' form. Go to the '837 Professional section'. Deselect '2420E-N3 - Ordering Provider Address (2420E-N3)', '2420E-N4 - Ordering Provider City (2420E-N4)', '2420E-REF - Ordering ProviderSec. Info (2420E-REF)' and '2420E-PER - Ordering Provider Contact (2420E-PER)' in the 'Select Segments To Suppress' checklist. Submit the form. Open the 'Electronic Billing' form. Compile an 837 Professional bill for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Locate to the 2420E loop. The 2420E loop starts with NM1DK. Verify the following segments are not suppressed and included in the 2420E loop of the bill. 2420E-N3 - Ordering Provider Address (2420E-N3) 2420E-N4 - Ordering Provider City/State/Zip Code (2420E-N4) 2420E-REF - Ordering ProviderSec. Info (2420E-REF) 2420E-PER - Ordering Provider Contact (2420E-PER) Close the report. Close the form. Open the 'Guarantor/Program Billing Defaults' form. Go to the '837 Professional section'. Select '2420E-N3 - Ordering Provider Address (2420E-N3)', and '2420E-PER - Ordering Provider Contact (2420E-PER)' in the 'Select Segments To Suppress' checklist. Submit the form. Open the 'Electronic Billing' form. Compile an 837 Professional bill for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Locate the 2420E loop. The 2420E loop starts with NM1*DK. Verify the following segments are suppressed correctly and not included in the 2420E loop of the bill. 2420E-N3 - Ordering Provider Address (2420E-N3) 2420E-PER - Ordering Provider Contact (2420E-PER) Verify the following segments are not suppressed and included in the 2420E loop of the bill. 2420E-N4 - Ordering Provider City/State/Zip Code (2420E-N4) 2420E-REF - Ordering ProviderSec. Info (2420E-REF) Close the report. Close the form.	Topics • 837 Professional • Guarantor / Program Billing Defaults • NX
Update 130 Summary \| Details Guarantor/Program Billing Defaults - Select Segments To Suppress Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Client Charge Input (Charge Fee Access and Diagnosis Entry) Create Interim Billing Batch File Practitioner Enrollment Practitioner Numbers By Guarantor And Program Program Maintenance Guarantors/Payors Dictionary Update (PM) Electronic Billing Scenario 1: Guarantor/Program Billing Defaults - 837 Institutional - Select Segments To Suppress Specific Setup: Practitioner Enrollment: Create a new or identify an existing practitioner to be used as an attending practitioner. Note the Practitioner id, Name, NPI Number, Taxonomy Code. Guarantors/Payors: Identify an existing guarantor or create a new guarantor. Note the guarantor's code/name. Program Maintenance: Identify an existing inpatient program to be used for the client's admission. Note the program code/name. Practitioner Numbers By Guarantor and Program: Create a record using a practitioner, guarantor and program identified above. Dictionary Update: Add/ Edit dictionary code/value for the 'Attending Provider Specialty Information' segment which is 2310A-PRV. Add/Edit dictionary code/value for the 'Attending Provider Name' segment which is 2310A-NM1. Guarantor/Program Billing Defaults template: Edit an existing template to assign the guarantor identified above. Note the template name. 837 Institutional section: Select Segments To Suppress: The 2310A-PRV (Attending Provider Specialty Information) segment and 2310A segments is available in the checklist. Nothing is selected in the 'Select Segments To Suppress' dictionary Admission: A new client is admitted in the inpatient program with attending practitioner. Financial Eligibility: The guarantor assigned to the template configured in the 'Guarantor/Program Billing Defaults' is assigned to the client. Recurring Client Charge Input: 5-6 room and board charges are rendered beginning on the admission date. A rendering practitioner is added for these charges. Charges are closed. An interim billing batch is created to include client, services, and guarantor. Steps Open the 'Electronic Billing' form. Compile the 837 Institutional for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Verify the NM171 and PRVAT segments display the attending provider identification information from the 'Practitioner Enrollment' form. Close the report. Close the form. Open the 'Guarantor/Program Billing Defaults' form. Go to '837 Institutional section'. Select the 2310A-PRV (Attending Provider Specialty Information) segment in the 'Select Segments To Suppress' checklist. Submit the form. Close the form. Open the 'Electronic Billing' form. Compile the 837 Institutional for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Verify the NM171 segments display the attending provider identification information from the 'Practitioner Enrollment' form and suppress the PRV-AT segment to include in the bill. Close the report. Close the form. Open the 'Guarantor/Program Billing Defaults' form. Go to '837 Institutional section'. Select the 2310A (Attending Provider Name) segment in the 'Select Segments To Suppress' checklist. Submit the form. Close the form. Open the 'Electronic Billing' form. Compile the 837 Institutional for the interim billing batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Verify the NM171 segment and PRV*AT segments are suppressed and not included in the bill. Close the report. Close the form.	Topics • 837 Institutional • NX
Update 132 Summary \| Details Avatar PM 'Summary Trial Balance Report' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Summary Trial Balance Report Scenario 1: 'Summary Trial Balance Report' - Verification of report results Steps Open Avatar PM 'Summary Trial Balance Report' form (under 'Avatar PM / Billing / Billing Reports / Monthly Closeout Reports' menu). Enter/select values for 'Summary Balance As Of ', 'Aging Category' and 'Include Bad Debt Information' report criteria fields. Click 'Process' button to run report/render result data. Ensure that 'Summary Trial Balance Report' results are rendered/displayed in the default report format within myAvatar/Avatar NX. In 'Summary Trial Balance Report' results display, ensure that the following information fields are present: 'Run Date' (current date) 'As Of' (from 'Summary Balance As Of' report criteria field) 'Revenue Group' 'Unbilled' report information 'Financial Class' 'In-House' (with dollar values) 'Disc' (discharged; with dollar values) 'Days' (with value) 'Total'/'Totals' (with dollar values) 'Billed' report information 'Financial Class' Aging Categories (default or custom entered/edited values as defined in 'Aging Category' report criteria field; '0', '30', '120', etc; with dollar values) 'Total'/'Totals' (with dollar values) Ensure that 'Summary Trial Balance Report' results display includes information/dollar values for all fields/groupings noted above with expected values based on unbilled/billed services and payments present in Avatar PM system for selected 'Summary Balance As Of' report criteria date, including 'Total'/'Totals' calculated values. Ensure that Summary Trial Balance Report' results display includes 'ALL' Revenue Group summary information (summary totals for report information); ensure that 'ALL' Revenue Group summary information includes information/dollar values for all fields/groupings noted above display with expected values based on unbilled/billed services and payments present in Avatar PM system for selected 'Summary Balance As Of' report criteria date, including 'Total'/'Totals' calculated values. In 'Summary Trial Balance Report' results display, click 'Print All Pages', 'Print Page', 'Export All Pages' and/or 'Export Page' button to print or export/save report data as desired. Click 'Close' button to close 'Summary Trial Balance Report' results display. Scenario 2: 'Summary Trial Balance Report' - Verification of .CSV format report results Steps Open Avatar PM 'Summary Trial Balance Report' form (under 'Avatar PM / Billing / Billing Reports / Monthly Closeout Reports' menu). Enter/select values for 'Summary Balance As Of ', 'Aging Category' and 'Include Bad Debt Information' report criteria fields. Ensure 'Export Detail Information to CSV' field is present in form, with 'Yes' checkbox/selection available. No selection in the 'Export Detail Information to CSV' field will render report results in the default report format Selecting 'Yes' in the 'Export Detail Information to CSV' field will display report results in CSV (comma-separated value) format (allowing user to export/save 'Summary Trial Balance Report' results for external use) Click 'Process' button to run report/render result data. If no value is selected in 'Export Detail Information to CSV' field, ensure that 'Summary Trial Balance Report' results are rendered/displayed in the default report format. If 'Yes' is selected for 'Export Detail Information to CSV' field, ensure that 'Summary Trial Balance Report' results are rendered/displayed in .CSV format within myAvatar/Avatar NX, with following header and individual data rows present: 'Summary Trial Balance Report' .CSV format data header (first row in report data results) will contain the following data elements: 'RRG' 'RRG Description' 'Financial Class' 'Financial Class Description' 'Unbilled In-House' 'Unbilled Disch' 'Days' Aging Categories (default or custom entered/edited values as defined in 'Aging Category' report criteria field; 'Aging 0', 'Aging 30', 'Aging 60', 'Aging 120', etc.) Header row examples: "RRG,RRG Description,Financial Class,Financial Class Description,Unbilled In-House,Unbilled Disch,Days,Billed/Aging Category 0,Billed/Aging Category 30,Billed/Aging Category 60,Billed/Aging Category 90,Billed/Aging Category 120,Total" "RRG,RRG Description,Financial Class,Financial Class Description,Unbilled In-House,Unbilled Disch,Days,Billed/Aging Category 5,Billed/Aging Category 10,Billed/Aging Category 20,Billed/Aging Category 30,Billed/Aging Category 40,Billed/Aging Category 50,Billed/Aging Category 60,Total" 'Total' 'Summary Trial Balance Report' .CSV format individual data rows (second and all subsequent rows in report data results) will contain report data for each element, one row per result. Data row examples: "5,Outpatient Substance Abuse,7,Medicare Part A,2397.15,0.00,0,1181.21,0.00,0.00,0.00,815.00,4393.36" "1,Inpatient Psychiatric,10,Non-Recoverable,18635.12,6000.50,0,3360.52,88.00,1500.00,200.00,6526.80,40022.44" "5,Outpatient Psychiatric,3,Blue Cross,1176903.89,0.00,0,1476.11,0.00,0.00,0.00,0.00,0.00,12365.15,1190745.15" In 'Summary Trial Balance Report' results display, click 'Export All Pages' or 'Export Page' button to export/save .CSV format report data to file. Open/review exported .CSV format file, ensuring that data header and all individual data rows are present in file as displayed/defined above.	Topics • Summary Trial Balance Report • NX
Update 135 Summary \| Details Validate the 'Problem Classification' field in 'Diagnosis' form populates with selections. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (CWS) Scenario 1: 'Diagnosis' form 'Problem Classification' field validation when defaulting diagnosis from a previous episode. Specific Setup: Avatar CWS->Problem List->->->->Problem Classification Required A new code has been added to the Avatar CWS 'Dictionary Update' file 'Problem Classification'. This is in field 16250. Steps Open 'Diagnosis' for any client. Add a new diagnosis for the client. Note the episode selected as it will be used in later steps. Complete required fields as needed. Select 'Y' in the 'Add to Problem List' field. Do not populate the 'Problem Classification' field at this time. Click [Submit]. Enter the 'Diagnosis' form again for the same client. Select 'Add' on the pre-display. Do not select the existing diagnosis. Select the episode used in the above steps in the 'Select Episode To Default Diagnosis Information From' field. Select the diagnosis entered in the above steps in the 'Select Diagnosis To Default Information From' field. Click on the existing diagnosis row to populate the detail fields. Click on the 'Problem Classification' field. Verify that all codes for selection display in the drop down list, including the newly added code (see Setup section). Select a code from the drop down list. Click [Submit]. Click [No] on the 'Pre-Display Confirmation: Do you want to return to Pre-Display?' pop up window.	Topics • Diagnosis • NX
Update 137 Summary \| Details Avatar PM is enhanced to capture additional information Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Enrollment Practitioner Enrollment (Brief) Dictionary Update (PM) Scenario 1: 'Facility Defaults' form - field validations Steps Access the 'Facility Defaults' form. Populate any desired fields. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Create a report using the 'SYSTEM.table_facility_defaults' SQL table. Validate a row is displayed for the data on file. Validate the following audit fields are displayed and are populated accordingly: data_entry_by data_entry_by_option data_entry_date data_entry_time data_entry_user_id data_entry_user_name option_id option_desc The following audit fields will only be populated in a UTC enabled system: data_entry_utc data_entry_timezone_info_all data_entry_time_j data_entry_offset data_entry_timezone_short Close the report. Scenario 2: 'PractitionerRegister' Web Service - Verification Of 'PractitionerRegister' Filing Steps Using the 'PractitionerRegister' web service, submit a request using the 'PractitionerRegister' method to create a new 'Practitioner Enrollment' record, including a value for the 'OfficeAddressDate' field/segment. Confirm the 'PractitionerRegister' web service responds with confirmation data/ID on successful filing of 'PractitionerRegister' method. Example:"<Confirmation>Unique ID : 000056</Confirmation>" Confirm the 'PractitionerRegister' web service responds with confirmation message on successful filing of 'PractitionerRegister' method. Example:"<Message>Practitioner Enrollment web service has been filed successfully.</Message>" Confirm the 'PractitionerRegister' web service responds with successful status value on successful filing of 'PractitionerRegister' method. Example:" <Status>1</Status>" Access the 'Practitioner Enrollment' form and select the 'Practitioner Enrollment' record filed via web service for view/update. Confirm new Practitioner/Practitioner Enrollment record is created in Avatar PM, with values/data submitted via web service including 'Office Address - Start Date' field value. Scenario 3: 'PractitionerRegister' Web Service - Verification Of 'EditPractitionerRegister' Filing Specific Setup: A practitioner must be defined in 'Practitioner Enrollment'. Steps Using the 'PractitionerRegister' web service, submit a request using the 'EditPractitionerRegister' method to edit/update a 'Practitioner Enrollment' record, including a value for the 'OfficeAddressDate' field/segment. Confirm the 'PractitionerRegister' web service responds with confirmation data/ID on successful filing of 'EditPractitionerRegister' method. Example:"<Confirmation>Unique ID : 000056</Confirmation>" Confirm the 'PractitionerRegister' web service responds with confirmation message on successful filing of 'EditPractitionerRegister' method. Example:"<Message>Practitioner Enrollment web service has been filed successfully.</Message>" Confirm the 'PractitionerRegister' web service responds with successful status value on successful filing of 'EditPractitionerRegister' method. Example:" <Status>1</Status>" Access the 'Practitioner Enrollment' form and select the 'Practitioner Enrollment' record filed via web service for view/update. Confirm Practitioner/Practitioner Enrollment record is updated in Avatar PM, with values/data submitted via web service including the 'Office Address - Start Date' value. Scenario 4: 'Practitioner Enrollment' - Form Verification Specific Setup: Crystal Reports or other SQL Reporting Tool. Steps Access the 'Practitioner Enrollment' form. Select any existing practitioner for view/update. Validate the 'Office Address - Start Date' field is displayed. Enter any value in the 'Office Address - Start Date' field. Populate any other required and desired fields. Click [Submit]. Access the 'Practitioner Enrollment' form. Select the same practitioner from the previous steps. Validate the 'Office Address - Start Date' field contains the value filed in the previous steps. Validate any other previously field data is displayed. Close the form. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'SYSTEM.staff_enrollment_history' SQL table. Navigate to the row for the practitioner used in the previous steps. Validate the 'office_add_date' field contains the value field in the previous steps. Close the report. Create a report using the 'SYSTEM.staff_current_demographics' SQL table. Navigate to the row for the practitioner used in the previous steps. Validate the 'office_add_date' field contains the value field in the previous steps. Close the report. Scenario 5: 'Practitioner Enrollment (Brief)' - Form Verification Specific Setup: Crystal Reports or other SQL reporting tool. Steps Access the 'Practitioner Enrollment (Brief)' form. Select any existing practitioner for view/update. Validate the 'Office Address - Start Date' field is displayed. Enter any value in the 'Office Address - Start Date' field. Populate any other required and desired fields. Click [Submit]. Access the 'Practitioner Enrollment (Brief)' form. Select the same practitioner from the previous steps. Validate the 'Office Address - Start Date' field contains the value filed in the previous steps. Validate any other previously field data is displayed. Close the form. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'SYSTEM.staff_enrollment_history' SQL table. Navigate to the row for the practitioner used in the previous steps. Validate the 'office_add_date' field contains the value field in the previous steps. Close the report. Create a report using the 'SYSTEM.staff_current_demographics' SQL table. Navigate to the row for the practitioner used in the previous steps. Validate the 'office_add_date' field contains the value field in the previous steps. Close the report. Scenario 6: Dictionary Update - Validate the 'Treatment Service' dictionary Steps Access the 'Dictionary Update' form. Select "Client" in the 'File' field. Select "(101) Treatment Service" in the 'Data Element' field. Enter an existing code in the 'Dictionary Code' field. Validate the 'Dictionary Value' field populates accordingly. Validate the 'Extended Dictionary Data Element' field contains "(742) Encounter Code (FHIR)". Select "(742) Encounter Code (FHIR)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Click [Apply Changes]. Validate a message is displayed stating: Filed! Click [OK]. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Individual Data Element" in the 'Individual or All Data Elements' field. Select "(101) Treatment Service" in the 'Data Element' field. Click [Print Dictionary]. Validate the report displays the updated dictionary with the "Encounter Code (FHIR)" extended dictionary value populated. Close the report and the form.	Topics • Facility Defaults • Query/Reporting • Practitioner • Web Services • Dictionary
Update 139 Summary \| Details Payor Based Authorizations Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors Program Maintenance Service Codes Dictionary Update (PM) Payor Based Authorizations Financial Eligibility Client Charge Input Practitioner Numbers By Guarantor And Program Electronic Billing Scenario 1: PM - File Import - Payor Based Authorizations Specific Setup: Registry Settings: Enable Payor Based Authorizations = 'Y' Enable CPT Based Payor Authorizations = desired value. Require Authorizations At Guarantors/Payors Level = desired value. File Import: A file has been created for testing. Note the values of all fields in the file for later comparison The 'Avatar_PM_File_Import_Record_Layouts' is included in the update zip file to assist in creating the file. Steps Open ‘File Import’ form. Select ‘Payor Based Authorizations’ in ‘File Type’. Upload the file. Compile the file. Print the file and validate the data. Post the file. Close the form. Open ‘Payor Based Authorizations’ form. Select ‘Edit’ in ‘Add/Edit/Delete’. Select the ‘Guarantor’ that was used in the import file. Click [Select Authorization To Edit/Delete]. Select the desired row in the ‘Edit Entry’ table. Click [OK]. Validate that ‘Effective Date’ contains the value in the import file. Validate that ‘Expiration Date’ contains the value in the import file. Validate that ‘Practitioner Category’ contains the value(s) in the import file. Validate that ‘Location’ contains the value(s) in the import file. Validate that ‘Authorization Group’ contains the value in the import file. Validate that ‘Service Code(s) ’ contains the value(s) in the import file. Validate that ‘Authorization Number’ contains the value in the import file. Close the form. Scenario 2: PM - Payor Based Authorization - Location Specific Setup: Registry Settings: Enable Payor Based Authorizations = 'Y'. Enable CPT Based Payor Authorizations = desired value. Require Authorizations At Guarantors/Payors Level = desired value. Dictionary Update: Client File (10006) Location = note active locations. Staff File (79) Practitioner Category = note active categories. Guarantors/Payors: Guarantor A: Identify a guarantor to be used with 'Payor Based Authorizations'. Note the values in the 'Authorization Section'. Verification Level For Authorizations For Client Charge Input and Verification Level For Authorizations For Appointment Scheduling: 'Disallow Service If Authorization Is Missing' will not allow the service to be submitted. 'Warn User If Authorization Is Missing' will allow the service to be submitted. Verification Level For Authorizations For 837 Electronic Billing: 'None' will allow services that were submitted and closed to be billed. 'Report As Error And Include On Bill' will allow services that were submitted and closed to be billed. An error message will be included in the 837 Billing report. 'Report As Error And Do Not Include On Bill' will not allow services that were submitted and closed to be billed Payor Based Authorizations: Create or edit a definition to include desired 'Locations' and any other desired fields. An error message will be included in the 837 Billing report. Client A: Identify an active client that is assigned to the guarantor above. Steps Open ‘Scheduling Calendar’. Create an appointment for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Charge Input’. Create a service for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open 'Close Charges’ and close charges for Client A if submission was allowed. Close the form. Open ‘Electronic Billing’ if submission was allowed. Create the bill for Client A and validate that the appropriate billing action occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Ledger’ for Client A if submission was allowed. Review the ‘Simple’, ‘Ledger Type’ to confirm the billing activity. Close the form.	Topics • Payor Based Authorizations • File Import • NX • Client Charge Input
Update 140 Summary \| Details Diagnosis - 'SearchDiagnosisCodes' web service Scenario 1: Diagnosis - Validate the 'SearchDiagnosisCode' web service Steps Access SoapUI for the 'DiagnosisV2' - 'SearchDiagnosisCodes' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired diagnosis search term in the 'ClinicalSearchTerm' field. Click [Run]. Validate the 'SearchDiagnosisCodeResult' field contains all related diagnosis codes. Dictionary Update - 'Pregnancy Status' dictionary Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Women's Health History CareFabric Monitor Dictionary Update (PM) Scenario 1: Women's Health History - Validate the 'PregnancyCreated' and 'PregnancyUpdated' SDK events Specific Setup: The following extended dictionaries must be defined for the "(357) Pregnancy Status" PM dictionary values: (70492) Clinical Status - Pregnancy (FHIR) (70493) Verification Status (FHIR) A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Women's Health History' form. Enter the desired date in the 'Assessment Date' field. Enter the desired date in the 'Pregnancy Start Date' field. Select the desired value in the 'Pregnant Status' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "PregnancyCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'clinicalStatusCode' - code' field contains the "Clinical Status - Pregnancy (FHIR)" extended dictionary code defined for the status selected. Validate the 'clinicalStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.164". Validate the 'clinicalStatusCode' - 'codeSystemName' field contains "Condition-Clinical". Validate the 'clinicalStatusCode' - 'displayName' field contains the "Clinical Status - Pregnancy (FHIR)" extended dictionary value defined for the status selected. Validate the 'verificationStatusCode' - code' field contains the "Verification Status (FHIR)" extended dictionary code defined for the status selected. Validate the 'verificationStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.166". Validate the 'verificationStatusCode' - 'codeSystemName' field contains "Condition-Ver-Status". Validate the 'verificationStatusCode' - 'displayName' field contains the "Verification Status (FHIR)" extended dictionary value defined for the status selected. Close the report and the form. Select "Client A" and access the 'Women's Health History' form. Select the record filed in the previous steps and click [Edit]. Enter the desired value in the 'Pregnancy End Date' field. Select any new value in the 'Pregnant Status' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "PregnancyUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'clinicalStatusCode' - code' field contains the "Clinical Status - Pregnancy (FHIR)" extended dictionary code defined for the status selected. Validate the 'clinicalStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.164". Validate the 'clinicalStatusCode' - 'codeSystemName' field contains "Condition-Clinical". Validate the 'clinicalStatusCode' - 'displayName' field contains the "Clinical Status - Pregnancy (FHIR)" extended dictionary value defined for the status selected. Validate the 'endDate' field contains the 'Pregnancy End Date'. Validate the 'startDate' field contains the 'Pregnancy Start Date'. Validate the 'verificationStatusCode' - code' field contains the "Verification Status (FHIR)" extended dictionary code defined for the status selected. Validate the 'verificationStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.166". Validate the 'verificationStatusCode' - 'codeSystemName' field contains "Condition-Ver-Status". Validate the 'verificationStatusCode' - 'displayName' field contains the "Verification Status (FHIR)" extended dictionary value defined for the status selected. Close the report and the form. Scenario 2: Dictionary Update - Validate the 'Pregnancy Status' dictionary Steps Access the 'Dictionary Update' form. Select "Client" in the 'File' field. Select "(357) Pregnancy Status" in the 'Data Element' field. Enter an existing code in the 'Dictionary Code' field. Validate the 'Dictionary Value' field populates accordingly. Validate the 'Extended Dictionary Data Element' field contains the following: "(70492) Clinical Status - Pregnancy (FHIR)" "(70493) Verification Status (FHIR)" Select "(70492) Clinical Status - Pregnancy (FHIR)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Select "(70493) Verification Status (FHIR)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Click [Apply Changes]. Validate a message is displayed stating: Filed! Click [OK]. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Individual Data Element" in the 'Individual or All Data Elements' field. Select "(357) Pregnancy Status" in the 'Data Element' field. Click [Print Dictionary]. Validate the report displays the updated dictionary with the "(70492) Clinical Status - Pregnancy (FHIR)" and "(70493) Verification Status (FHIR)" extended dictionary values populated. Close the report and the form. Dictionary Update - 'Diagnosis Status' dictionary Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (PM) CareFabric Monitor Scenario 1: Dictionary Update - Validate the 'Diagnosis Status' dictionary Steps Access the 'Dictionary Update' form. Select "Client" in the 'File' field. Select "(1800) Status" in the 'Data Element' field. Enter an existing code in the 'Dictionary Code' field. Validate the 'Dictionary Value' field populates accordingly. Validate the 'Extended Dictionary Data Element' field contains the following: "(70494) Clinical Status - Diagnosis (FHIR)" "(70493) Verification Status (FHIR)" Select "(70494) Clinical Status - Diagnosis (FHIR)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Select "(70493) Verification Status (FHIR)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Click [Apply Changes]. Validate a message is displayed stating: Filed! Click [OK]. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Individual Data Element" in the 'Individual or All Data Elements' field. Select "(357) Pregnancy Status" in the 'Data Element' field. Click [Print Dictionary]. Validate the report displays the updated dictionary with the "(70494) Clinical Status - Diagnosis (FHIR)" and "(70493) Verification Status (FHIR)" extended dictionary values populated. Close the report and the form. Scenario 2: Diagnosis - Validate the 'DiagnosisCreated' and 'DiagnosisUpdated' SDK events Specific Setup: The following extended dictionaries must be defined for the "(1800) Status" PM dictionary values for 'Diagnosis Status': (70494) Clinical Status - Diagnosis (FHIR) (70493) Verification Status (FHIR) A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Diagnosis' form. Select the desired value in the 'Type Of Diagnosis' field. Enter the desired date in the 'Date Of Diagnosis' field. Enter the desired time in the 'Time Of Diagnosis' field. Click [New Row]. Select the desired value in the 'Diagnosis Search' field. Select "Active" in the 'Status' field. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "DiagnosisCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'clinicalStatusCode' - code' field contains the "Clinical Status - Diagnosis (FHIR)" extended dictionary code defined for the status selected. Validate the 'clinicalStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.164". Validate the 'clinicalStatusCode' - 'codeSystemName' field contains "Condition-Clinical". Validate the 'clinicalStatusCode' - 'displayName' field contains the "Clinical Status - Diagnosis (FHIR)" extended dictionary value defined for the status selected. Validate the 'programAdmissionID' - 'id' field contains the program admission ID for "Client A". Validate the 'programCode' - 'code' field contains the program code "Client A" is enrolled in. Validate the 'programCode' - 'displayName' field contains the program name "Client A" is enrolled in. Validate the 'statusCode' - 'code' field contains "1". Validate the 'statusCode' - 'displayName' field contains "Active". Validate the 'verificationStatusCode' - code' field contains the "Verification Status (FHIR)" extended dictionary code defined for the status selected. Validate the 'verificationStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.166". Validate the 'verificationStatusCode' - 'codeSystemName' field contains "Condition-Ver-Status". Validate the 'verificationStatusCode' - 'displayName' field contains the "Verification Status (FHIR)" extended dictionary value defined for the status selected. Close the report and the form. Select "Client A" and access the 'Diagnosis' form. Select the diagnosis record filed in the previous steps and click [Edit]. Select "Resolved" in the 'Status' field. Enter the desired date in the 'Resolved Date' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "DiagnosisUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'clinicalStatusCode' - code' field contains the "Clinical Status - Diagnosis (FHIR)" extended dictionary code defined for the status selected. Validate the 'clinicalStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.164". Validate the 'clinicalStatusCode' - 'codeSystemName' field contains "Condition-Clinical". Validate the 'clinicalStatusCode' - 'displayName' field contains the "Clinical Status - Diagnosis (FHIR)" extended dictionary value defined for the status selected. Validate the 'programAdmissionID' - 'id' field contains the program admission ID for "Client A". Validate the 'programCode' - 'code' field contains the program code "Client A" is enrolled in. Validate the 'programCode' - 'displayName' field contains the program name "Client A" is enrolled in. Validate the 'statusCode' - 'code' field contains "4". Validate the 'statusCode' - 'displayName' field contains "Resolved". Validate the 'verificationStatusCode' - code' field contains the "Verification Status (FHIR)" extended dictionary code defined for the status selected. Validate the 'verificationStatusCode' - 'codeSystem' field contains "2.16.840.1.113883.4.642.3.166". Validate the 'verificationStatusCode' - 'codeSystemName' field contains "Condition-Ver-Status". Validate the 'verificationStatusCode' - 'displayName' field contains the "Verification Status (FHIR)" extended dictionary value defined for the status selected. Close the report and the form.	Topics • Diagnosis • Web Services • CareFabric • Women's Health History • Dictionary • CareFabric Monitor
Update 141 Summary \| Details Data Management Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Update (PM) Update Client Data Scenario 1: PM - Gender Identity and Sexual Orientation - dictionary validation Specific Setup: Dictionary Update: Print ‘Client (730) Gender Identity’. Save for later comparison. Print ‘Client (731) Sexual Orientation’. Save for later comparison. Client: Select an existing client to use in ‘Update Client Data’. Steps Open ‘Update Client Data’ for the client. Go to the ‘Gender Identity’ field. Validate that all dictionary values printed above are available in the dropdown list. Select the desired value in ‘Gender Identity’. Go to the ‘Sexual Orientation’ field. Validate that all dictionary values printed above are available in the dropdown list. Select the desired value in ‘Sexual Orientation’. Submit the form. Reopen ‘Update Client Data’ for the client. Validate that the values selected in ‘Gender Identity’ and ‘Sexual Orientation’ display. Close the form.	Topics • Demographics • NX
Update 143 Summary \| Details Facility Defaults - 'Provider Country' field Scenario 1: Validate the 'GetOrganization' payload Steps Internal testing only. Scenario 2: 'Facility Defaults' form - field validations Steps Access the 'Facility Defaults' form. Populate any desired fields. Validate the 'Provider Country' field is displayed. Select the desired value in the 'Provider Country' field. Note: this field is populated based off the dictionary values under the 'Client' file, '(150) Country Of Origin' data element in 'Dictionary Update'. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Create a report using the 'SYSTEM.table_facility_defaults' SQL table. Validate a row is displayed for the data on file. Validate the 'provider_country_code' field contains the code associated to the 'Provider Country' selected. Validate the 'provider_country_value' field contains the value associated to the 'Provider Country' selected. Close the report.	Topics • Facility Defaults • Query/Reporting
Update 144 Summary \| Details Call Intake - Demographic fields - Add Demographics to 'Call Intake' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (PM) Discharge Call Intake Scenario 1: Site Specific Section Modeling - Validating Site Specific Demographic fields - Registry Setting 'Add Demographics to Call Intake' Specific Setup: Registry Setting 'Add Demographics to Call Intake' is set to 'Y'. Steps Open the 'Site Specific Section Modeling' form. Select "PATIENT510 (Admission) Demographics" in the drop-down. Click [OK]. Select the 'Prompt Definition' section. Select desired site specific prompt to add to the 'Demographic' section of the form. Note the name of the fields. Select 'No' in the 'Exclude from Data Collection Instrument' field. Submit the form. Open the 'Admission' or 'Admission(Outpatient)' form. Select the 'Demographics' section of the form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Discharge' form. Go to the 'Demographics' section of the 'Discharge' form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Call Intake' form. The correct site specific fields are added which are set to 'No' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Open the 'Site Specific Section Modeling' form. Select "PATIENT510 (Admission) Demographics" in the drop-down. Click [OK]. Select the 'Prompt Definition' section. Select desired site specific prompt to remove from the 'Demographic' section of the form. Note the name of the fields. Select 'Yes' in the 'Exclude from Data Collection Instrument' field. Submit the form. Open the 'Admission' or 'Admission(Outpatient)' form. Select the 'Demographics' section of the form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form. Open the 'Discharge' form. Go to the 'Demographics' section of the 'Discharge' form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form. Open the 'Call Intake' form. The correct site specific fields are removed which are set to 'Yes' in the 'Exclude from Data Collection Instrument' field of the 'Site Specific Section Modeling' form from the above step. Close the form. Scenario 2: Call Intake - Demographics section - Registry setting 'Add Demographics to Call Intake' Specific Setup: Registry Setting: The 'Add Demographics to Call Intake' is set to 'Y'. Please note: Selecting 'Y' adds the 'Demographics' tab and the prompts, 'Sex', 'Age' and 'Date Of Birth', to the 'Call Intake' form. Steps Open 'Call Intake' form. Verify the form contains 'Demographics' section. Set 'Last Name' to any last name (not an existing client). Set 'First Name' to any first name. Select any gender in the 'Sex' drop down list Click [Search]. Click [New Client]. Click [Call] in the 'Call Or Walk-in' field. Set the 'Caller Name' to any LastName, FirstName. Set the 'Call Date' to any date. Set the 'Call Time' to any time. Select any value from the 'Program' drop down list. Select any value from the 'Disposition' drop down list. Enter any text in the 'Comments for the call intake' text box. Set the 'Date of Birth' to any date in the past. Set the 'Social Security Number' to any SSN. Click the 'Demographics' tab. Select any value in the 'Prefix' drop down list. Set the 'Client's Address - Street' to any address. Set the 'Client's Address - Zipcode' to any Zipcode. Set the 'Client's Home Phone' to any phone number. Set the 'Client's Work Phone' to any phone number. Set the 'Client's Cell Phone' to any phone number. Set the 'Client's Email Address' to any email address. Select any value in the 'Communication Preference' field. Select any value in the 'Primary Language' drop down list. Select any value in the 'Client Race' drop down list. Select any value in the 'Other Race(s)' list. Select any value in the 'Ethnic Origin' drop down list. Select any value from the 'Religion' drop down list. Set the 'Place of Birth' to any value. Select any value from the 'Marital Status' drop down list. Select any value from the 'Education' drop down list. Select any value from the 'Employment Status' drop down list. Select any value from the 'Occupation' drop down list. Select any value from the 'Are you heterosexual, lesbian, gay, bisexual, transgender or do you question your sexual orientation?' field. Select any value from the 'Smoker' drop down list. Set the 'Smoking Status Assessment Date' to any date. Set the 'Client's Mailing Address - Street' to any address. Set the 'Client's Mailing Address - Street 2' to any address. Set the 'Client's Mailing Address - Zipcode' to any Zipcode. Set the 'Client's Mailing Address - City' to any City. Set the 'Client's Mailing Address - State' to any State. Select any value from the 'Client's Mailing Address - County' field. Click [Submit]. Open the 'Call Intake' form for the same client. Verify the Demographic data is retained and correct. Close the form. Open the 'Registry setting' Form. Set the 'Add Demographics to Call Intake' to 'N'. Submit the form. Open 'Call Intake' form. Verify the form does not contain 'Demographics' section. Submit the form.	Topics • Site Specific Section Modeling • NX • Call Intake
Update 147 Summary \| Details AR Console User Defaults Setup Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors AR Console Configuration AR Console User Defaults Setup System Task Scheduler Scenario 1: AR Console User Defaults Setup - field validation Specific Setup: The following registry setting has a value of Y: Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality. User Definition has been used to give the signed in user access to the form: Avatar PM / Billing / AR Management / AR Console User Defaults Setup. View Definition / NX View Definition has been used to place the widget on the tester's home view. Note the ID of at least two more users. Guarantors/Payor: Multiple guarantors exist that contain different 'Financial Classes'. AR Console Configuration: At least one 'Financial Class' is selected in 'Exclude Financial Class(es) from AR Console'. System Task Scheduler: The 'Auto AR Batch Update' was processed after the claims were created. Steps Open ‘AR Console User Defaults Setup’. Click ‘New Row’ and add a row for the signed in user, or if the signed in user exists in a row select the row. Click ‘All’ in the following fields: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Add desired value to ‘Aged Over # Days’. Note the value. Click ‘New Row’ and add a row for the first additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’. Note the values of each field. Click ‘New Row’ and add a row for the second additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’. Note the values of each field. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Validate that the following fields have every available item in the checklist selected: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Verify that ‘Aged Over # Days' contains the value entered above. Deselect one or more items in 'Financial Class(es)'. Select the row for the first additional user. Validate that the values that were submitted were retained. Select the row for the second additional user. Validate that the values that were submitted were retained. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Open the 'Account Receivable Console' widget for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Close the widget.	Topics • Accounts Receivable Management
Update 150 Summary \| Details Spreadsheet Charge Input - Form validation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Client Charge Input With Diagnosis Entry Spreadsheet Edit Service Information Scenario 1: Spreadsheet Edit Service Information - Registry setting 'Allow Only Active Diagnoses' and 'Hide Medical Diagnosis Fields' Specific Setup: Registry Setting: The Avatar PM \ Services \ Ancillary/Ambulatory Services \ Spreadsheet Edit Service Information \ Hide Medical Diagnosis Fields' registry setting is set to "Y". Admission: An existing client is identified or a new client is admitted. Client Charge Input with Diagnosis Entry Three charges are added for the client. Enter a diagnosis for two of the charges. Steps Open 'Spreadsheet Edit Service Information' form. Select "All" in the 'Individual Or All Practitioners' field. Select "All" in the 'Individual Or All Programs' field. Select the client from the setup section in the 'Individual Or All Clients' field. Enter the date rage to include all three services created in the setup section in the 'Begin Date Of Service' and 'End Date Of Service' fields. Select "No" in the Only Show Services That Require A Diagnosis Or Are Primary Medical Program Services field. Select all the options in the 'Only Load Services With This Status' field. Click 'Edit Service Information' button to display the Spreadsheet Edit Service Information grid. Verify that all Diagnosis fields are hidden. Scenario 2: Spreadsheet Charge Input - Registry setting 'Allow Only Active Diagnoses' and 'Hide Medical Diagnosis Fields' = Y Specific Setup: Registry Setting: Set the 'Allow Only Active Diagnoses' registry setting to "Y". Set the 'Avatar PM->Services->Ancillary/Ambulatory Services->Spreadsheet Charge Input->->Hide Medical Diagnosis Fields' registry setting to "Y". Admission: Add a new client or identify an existing client. Note the client id/ name. Financial Eligibility: Assign an existing guarantor to the client. Service Code: Identify an existing service code to be used. Note the service code. Steps Open the 'Spreadsheet Charge Input' form. Verify the form opens successfully. Render a service to the client using the service code identified in the setup. Save the grid. Submit the form. Open the 'Client Ledger' form. Verify the service displays correctly and charges distributed correctly to the guarantor assigned to the client.	Topics • NX • Spreadsheet Charge Input
Update 151 Summary \| Details Payor Based Authorizations Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors Financial Eligibility Program Maintenance Client Charge Input Payor Based Authorizations Practitioner Numbers By Guarantor And Program Electronic Billing Scenario 1: PM - Payor Based Authorization - Location Specific Setup: Registry Settings: Enable Payor Based Authorizations = 'Y'. Enable CPT Based Payor Authorizations = desired value. Require Authorizations At Guarantors/Payors Level = desired value. Dictionary Update: Client File (10006) Location = note active locations. Staff File (79) Practitioner Category = note active categories. Guarantors/Payors: Guarantor A: Identify a guarantor to be used with 'Payor Based Authorizations'. Note the values in the 'Authorization Section'. Verification Level For Authorizations For Client Charge Input and Verification Level For Authorizations For Appointment Scheduling: 'Disallow Service If Authorization Is Missing' will not allow the service to be submitted. 'Warn User If Authorization Is Missing' will allow the service to be submitted. Verification Level For Authorizations For 837 Electronic Billing: 'None' will allow services that were submitted and closed to be billed. 'Report As Error And Include On Bill' will allow services that were submitted and closed to be billed. An error message will be included in the 837 Billing report. 'Report As Error And Do Not Include On Bill' will not allow services that were submitted and closed to be billed Payor Based Authorizations: Create or edit a definition to not include a 'Locations' and any other desired fields. An error message will be included in the 837 Billing report. Note the value of each field. Client A: Identify an active client that is assigned to the guarantor above. Steps Open 'Payor Based Authorizations'. Create a new record that matches the record from setup. Validate that the following message displays: An authorization already exists for this date range. Overlapping authorizations are not allowed. Remove the 'Expiration Date'. Select a 'Location'. Enter an 'Expiration Date'. Submit the form and validate that it files successfully. Open ‘Scheduling Calendar’. Create an appointment for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Charge Input’. Create a service for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open 'Close Charges’ and close charges for Client A if submission was allowed. Close the form. Open ‘Electronic Billing’ if submission was allowed. Create the bill for Client A and validate that the appropriate billing action occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Ledger’ for Client A if submission was allowed. Review the ‘Simple’, ‘Ledger Type’ to confirm the billing activity. Close the form.	Topics • Client Charge Input • Payor Based Authorizations • NX