Avatar PM 2022 Monthly Release 2022.03.00 Acceptance Tests

Last updated
Save as PDF

Update 11 Summary \| Details Quick Billing - Auto Upload to RevConnect Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Program Maintenance Admission (Outpatient) Financial Eligibility Diagnosis Client Ledger Quick Billing Rule Definition Quick Billing Scenario 1: Quick Billing - Verify that 837 file is not auto uploaded to RevConnect when the 'Auto Upload To RevConnect' = 'No' in the Quick Billing Rule Definition Specific Setup: Netsmart Client Alignment Associate has been contacted to enable 'RevConnect'. Netsmart Avatar support has completed the following: Enabled the 'Enable RevConnect' registry setting. Completed & submitted the 'RevConnect Configuration' form. 'System Generated Email Settings' has been used to add the tester’s email to enable notification verification. Registry Setting: The 'Enable New Quick Billing Format' registry setting is set to 'Y'. Facility Defaults: In the 'Output Path on Server For Electronic Files' field, enter the directory path to store electronic files. Note the path to see the file created after quick billing process. Guarantors/Payors: An existing guarantor is identified. Admission: The client is admitted to the inpatient or outpatient program or an existing client is identified. Note client id/name, admission date/program. Financial Eligibility: The guarantor is assigned to client. Client Charge Input: 5 Services are rendered to the client in the first episode. Be sure to use service codes that are covered by the benefit plan (insurance charge category). Client Ledger: Verify the charges are correctly distributed to the contract guarantor, and they are in 'Open' status. Unclaimed services that meet the 'Quick Billing Rule Definition' exist. Tester knows the date range of services. Quick Billing Rule Definition: The quick Billing Rules are created to include service(s) distributed to the client. The 'Auto Upload To RevConnect' field is set to "No". Steps Open 'Quick Billing Rule Definition'. Edit the definition by adding a value of 'No' to 'Auto Upload To RevConnect'. Click [Submit]. Open 'Quick Billing'. Enter the date range of services. Select the 'Billing Rule To Execute', which is the 'Quick Billing Rule Definition'. Select 'Create Batch', 'Close Charges', 'Generate Bills' and 'Create Claims' in 'Quick Billing Tasks to Execute'. Enter a 'Date of Claim'. Click [Submit]. Click [OK]. Click [No]. Verify an 837 billing file is created and stored in the location that is specified in the 'Facility Defaults'. Verify that no email is received stating: 'RevConnect uploaded 837 files successfully'. Scenario 2: Quick Billing - Verify that 837 file is not auto uploaded to RevConnect when the 'Auto Upload To RevConnect' = 'Null' in the Quick Billing Rule Definition Specific Setup: Netsmart Client Alignment Associate has been contacted to enable 'RevConnect'. Netsmart Avatar support has completed the following: Enabled the 'Enable RevConnect' registry setting. Completed & submitted the 'RevConnect Configuration' form. 'System Generated Email Settings' has been used to add the tester’s email to enable notification verification. Registry Setting: The 'Enable New Quick Billing Format' registry setting is set to 'Y'. Facility Defaults: In the 'Output Path on Server For Electronic Files' field, enter the directory path to store electronic files. Note the path to see the file created after quick billing process. Guarantors/Payors: An existing guarantor is identified. Admission: The client is admitted to the inpatient or outpatient program or an existing client is identified. Note client id/name, admission date/program. Financial Eligibility: The guarantor is assigned to client. Client Charge Input: 5 Services are rendered to the client in the first episode. Be sure to use service codes that are covered by the benefit plan (insurance charge category). Client Ledger: Verify the charges are correctly distributed to the contract guarantor, and they are in 'Open' status. Unclaimed services that meet the 'Quick Billing Rule Definition' exist. Tester knows the date range of services. Quick Billing Rule Definition: The quick Billing Rules are created to include service(s) distributed to the client. Do not select any value in the 'Auto Upload To RevConnect' field. Steps Open 'Quick Billing'. Enter the date range of services. Select the 'Billing Rule To Execute', which is the 'Quick Billing Rule Definition'. Select 'Create Batch', 'Close Charges', 'Generate Bills' and 'Create Claims' in 'Quick Billing Tasks to Execute'. Enter a 'Date of Claim'. Click [Submit]. Click [OK]. Click [No]. Verify an 837 billing file is created and stored in the location that is specified in the 'Facility Defaults'. Verify that no email is received stating: 'RevConnect uploaded 837 files successfully'.	Topics • NX • Quick Billing • RevConnect
Update 35 Summary \| Details System Task Scheduler - processes Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: System Task Scheduler Task Scheduler Status - Widget Scenario 1: 'System Task Scheduler' - Task Process(s) validation Specific Setup: 'View Definition' form has been used to add the ‘Task Scheduler Status’ widget to Home View for the logged in user In form "System Task Scheduler", have or create a task [TaskA] that can be selected in "Schedules" field. For this test, a "State Form Definition" form file was created that selects all records in the "SYSTEM.patient_current_demographics" table and the definition was then set up in the "State Form Task Scheduler" as a task. Steps Open form "System Task Scheduler". Select [TaskA] from the "Schedule(s)" field Select "Hourly" in the "Recurrence Pattern" field Enter "1" in "Task Occurrence Sequence" field Select today's date [DateA] in the "Range of Occurrence", "Start By" field Select the desired start time in the "Range of Occurrence", "Start Time" field, note the time entered [StartTime] Select tomorrows date [DateB] in the "Range of Occurrence", "End By" field Set the desired end time in the "Range of Occurrence", to be after "3:00 AM" the next day, for example "4:00AM". Note the end time entered [EndTime] Click "Schedule Task" At the home screen, refresh the ‘Task Scheduler Status’ widget Ensure [TaskA] is listed with the expected "Last Run Date" [DateA] and "Last Run Time" [StartTime] noted in step 1 Refresh the widget periodically, for example every 5 or 10 minutes before another hour has passed Ensure just one row is listed for [TaskA] and it still displays the same "Last Run Date" [DateA] and "Last Run Time" as in step 2a Wait till one hour has passed since the [StartTime] Click to refresh the "Task Scheduler Status" widget Ensure there is still just one entry for [TaskA] and the task now displays the expected "Last Run Date" as today's date [DateA] and the "Last Run Time" equates to [StartTime] plus 1 hour Wait until another hour has passed since the [StartTime] Click to refresh the "Task Scheduler Status" widget Ensure there is still just one entry for [TaskA] and the task now displays the expected "Last Run Date" as today's date [DateA] and the "Last Run Time" equates to [StartTime] plus 2 hours Repeat step 4 periodically, for example every 3 hours up till before the [EndTime] Ensure there is still just one entry for [TaskA] and the task now displays the expected "Last Run Date" still as today's date [DateA] and the "Last Run Time" equates the [StartTime] plus the number hours that have passed since the [StartTime] Wait till the next day and when [EndTime] noted in step 1 has passed Ensure there is still just one entry for [TaskA] and the task now displays the expected "Last Run Date" as the [DateB] and the "Last Run Time" is equal to [End Time] noted in step 1	Topics • System Task Scheduler
Update 48 Summary \| Details The 'CareConnect HIE Configuration' and 'Query For External CCD' forms Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareConnect HIE Configuration Scenario 1: Query for External CCD - Search, Preview, Save CCD's and validate SDK actions are triggered Specific Setup: A client must be enrolled in an existing episode (Client A). Steps Access the 'Query for External CCD' form. Select "Client A" in the 'Client Search' field. Select an organization in the 'Organization Name or Zip' field. Click [Search CCDs]. Select a CCD in the 'Available CCDs' field. Enter the desired provider in the 'Provider Referred To' field. Click [Preview]. Validate the CCD is displayed and close it. Click [Save]. Validate an "Information" message is displayed stating: Saved. Click [OK] and close the form. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Enter "Client A" in the 'Client ID' field. Enter "ExternalDataAckowledgementCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains an 'ExternalDataAcknowledgementCreated' record. Click [Click To View Record]. Validate the 'referredToProviderID' - 'id' field contains the provider ID selected in the previous steps. Close the report and the form. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'SYSTEM.ccd_tempstorage' table. Validate a row is displayed for the CCD saved in the previous steps. Validate the 'PATID' field contains "Client A". Validate the 'provider_referred_to' field contains the provider ID selected in the previous steps. Validate the 'provider_referred_to_name' field contains the provider name selected in the previous steps. Close the report. Scenario 2: CareConnect HIE Configuration - Carequality Configuration - Search Carequality Organizations Steps Access the 'CareConnect HIE Configuration' form. Select the "Carequality Configuration" section. Enter the desired zip code in the 'Organization Name or Zip' field. Validate the 'Within N Miles of Zip' field is displayed. Select the 'Within N Miles of Zip' help message. Validate the following message is displayed: This field can be used to further limit the external provider results when a zip code is entered. Close the help message. Enter the desired value in the 'Within N Miles of Zip' field. Click [Search]. Validate the applicable organizations are displayed in the 'Select Organization(s)' field. Select the desired organization in the 'Select Organization(s)' field. Validate the selected organization is now listed in the 'Organization: Exceptions and Favorites' grid. Select the desired value in the 'Status' field for the new organization. Click [Submit]. Scenario 3: Query For External CCD - Field Validations Specific Setup: A client is enrolled in an existing episode (Client A). Steps Access the 'Query for External CCD' form. Select "Client A" in the 'Client Search' field. Enter the desired zip code in the 'Organization Name or Zip' field. Validate the 'Within N Miles of Zip' field is displayed. Select the 'Within N Miles of Zip' help message. Validate the following message is displayed: This field can be used to further limit the external provider results when a zip code is entered. Close the help message. Enter the desired value in the 'Within N Miles of Zip' field. For Avatar NX users only, please note: due to a known issue with the field display in Avatar NX, please populate the text box below the 'Miles of Zip' field and disregard the text box below the 'Within' field. Click [Search]. Validate the applicable organizations are displayed in the 'Organizations' grid. Click [Clear]. Validate the organizations are no longer displayed in the 'Organizations' grid. Close the form.	Topics • CareConnect HIE Configuration • Query for External CCD
Update 60 Summary \| Details Diagnosis/Enrollment Diagnosis - Future Estimated Onset Date Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Admission Diagnosis Problem List Registry Settings (PM) Program Maintenance Enrollment Diagnosis Scenario 1: Diagnosis / Add to Problem List Specific Setup: Admit a new client. Steps Open the 'Diagnosis' form for the client. Add a diagnosis. Note the value of the 'Diagnosis Search’ field, and the 'SNOMED' value in the 'Code Crossmapping' field. Set the value of 'Add To Problem List' to "Yes". Set the "Estimated Onset Date" to a future date. Click [Submit]. Validate a message pops up indicating that a "Future Onset Date not added to the Problem List" Edit the "Estimated Onset Date": to a past date. Click {Submit}. Close the form. Open 'Problem List' for the client. Select 'Active' from the 'Status' field. Click [View Problems]. Validate the report contains the problem added via the Diagnosis form. Close the report. Close the form. Scenario 2: Enrollment Diagnosis - - Add to Problem List Specific Setup: Set Registry Setting "Enable Enrollments" to "2". Admit a new client into 2 separate episodes. Assign then both to the same "Enrollment". Steps Open the "Enrollment Diagnosis" form. Select the enrollment for the client. Enter a diagnosis for the client's enrollment. Select "Yes" for "Add to Problem List". Set the "Estimated Date of Onset" to a future date. Validate a message pops up indicating "Future Estimated Onset Date cannot be added to the Problem List". Filing won't continue without resolving the future date issue. Set the "Estimated Date of Onset" to a past date. File the diagnosis. Open the "Problem List" form. Validate the diagnosis is added to the problem list.	Topics • Diagnosis • NX • Problem List
Update 65 Summary \| Details The 'Monthly Bed Days' widget is modified to display correct data. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Monthly Bed Days Widget Scenario 1: 'Monthly Bed Days' widget update process Specific Setup: 'Monthly Bed Days' widget must be on the user's Home View Steps Verify that the widget is displaying 'Compare From Previous Year' and 'Last 12 Months' data accurately. Note that prior to the install of Avatar PM 65, the Monthly Bed Days widget was prevented from being updated nightly due to an error in the background processing. No error would display to the user. Once Avatar PM 65 is installed, the counts for previous and current year data will be adjusted as all charges are now being included in the widget display when the nightly widget update process completes.	Topics • Monthly Bed Days Widget
Update 82 Summary \| Details 'Current Unit Census' report is modified to omit Units flagged as inactive. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Unit Verification Report Current Unit Census Scenario 1: 'Verify Unit Census' field validation with 'Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' Specific Setup: Registry Setting 'Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' One or more Units have been associated to a Program using Program Maintenance One or more or the Units have been set as inactivated in Dictionary Update. Steps Open 'Verify Unit Census' form. Set the 'Date Verified From' field to any date. Set the 'Date Verified Through' to any date. Review the 'Unit' field and verify that no inactivate Unit are included in the display. Select one or more Units form in the 'Unit' field. Click [Yes] in the 'Census Verified (Y/N)' field. Click [Submit]. Click [OK] on the message 'Verifying census data for the following unit(s):' Verify the form closes. Scenario 2: 'Unit Verification Report' - field validation with 'Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' Specific Setup: Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' One or more Units have been associated to a Program using Program Maintenance One or more or the Units have been set as inactivated in Dictionary Update. Steps Open the 'Unit Verification Report'. Set the 'From Date Of Verification' field to any date. Set the 'Through Date Of Verification' field to any date. Click [Individual] in the 'For Individual Unit Or All' field. Verify no deactivated units are displayed in the 'Select Unit(s)' field. Select any unit in the list. Click [Both] in the 'Unverified/Verified/Both' field. Click [Launch Unit Verification Report]. Verify the report displays accurately. Close the report. Close the form. Scenario 3: 'Current Unit Census' - field validation with 'Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' Specific Setup: Must have one or more Units defined, associated to a program in Program Maintenance, and deactivated in the Dictionary Update form. Registry Setting 'Avatar PM->System Maintenance->Program Maintenance->>>Activate Program/Unit Filter' registry setting set to 'Y' Steps Open the 'Current Unit Census' form. Click [Individual] in the 'For Individual Unit Or All' field. Click the drop down in 'For Unit' field. Verify that the inactivated Units are not displayed in the drop down. Note that if any deactivated units were ever used for bed assignments, they will display in the drop down for reporting purposes. Click [Close Form].	Topics • Current Unit Census • NX • Verify Unit Census
Update 84 Summary \| Details Registry Setting - Enable Payment Acknowledgement Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) User Definition Posting/Adjustment Codes Definition General Ledger Payment Acknowledgement Interface Components General Ledger Payment Acknowledgement Account Numbers Dictionary Update (PM) Form and Table Documentation (PM) Table Import For General Ledger Account Numbers Scenario 1: Enable Payment Acknowledgement - Forms, Fields and Table validation Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is not available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are not available under the 'General Ledger Interface' item. Click [OK]. Click [Select Tables for Product SQL Access]. Verify the 'payack_account_numbers' sql table is not available under 'GL' database and in the Avatar PM namespace. Click [OK]. Click [Submit]. Click [No]. Open the ‘Posting/Adjustment Code Definition’ form. Select ‘Edit’ and select any posting code. Verify that the 'Payment Acknowledgement Type' field is not displayed on the form. Close the form. Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'Y'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are available under the 'General Ledger Interface' item. Select the 'Payment Acknowledgement', 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms. Click [OK]. Click [Select Tables for Product SQL Access]. Verify the 'payack_account_numbers' sql table is available under 'GL' database and in the Avatar PM namespace. Select the 'payack_account_numbers' sql table. Click [OK]. Click [Submit]. Click [No]. Verify the 'Payment Acknowledgement', 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are accessible from the menu. Open the ‘Posting/Adjustment Code Definition’. Select ‘Edit’ and select any posting code. Verify that the 'Payment Acknowledgement Type' field is displayed on the form. Close the form. Scenario 2: General Ledger Payment Acknowledgement Account Numbers - Workflow Specific Setup: System is updated for General Ledger module. Registry Setting: The ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ registry setting is set to ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. Steps Open the 'Payment Acknowledgement General Ledger Interface Components' form. Select components. Submit the form. Open the 'General Ledger Payment Acknowledgement Account Numbers' form. Select component and the component value for each of the components. Select credit and debit account numbers. File Account numbers for each component and date range (optional) combination. Repeat adding account numbers with different component combinations. Repeat adding account numbers with different component combinations with date ranges. Verify the overlapping date range not allowed for the same component combinations. Close the form. Open 'General Ledger Payment Acknowledgement Account Numbers' form. Go to section 'G/L Payment Acknowledgement Defaults'. Add default account numbers. File Default account numbers. Close the form. Open the 'General Ledger Payment Acknowledgement Account Numbers' form. Click [Print Table]. Verify the crystal report of payment acknowledgement account numbers is generated. Close the report. Open the 'Form and Table Documentation' form. Click [Table]. Filter by Billing -> General Ledger Interface -> General Ledger Payment Acknowledgement Account Numbers. Select GL.payack_account_numbers table. Validate SQL documentation displays all the fields added to the 'General Ledger Payment Acknowledgement Account Numbers' form. Close the form. Use Crystal Reports or any other SQL data viewer. Validate the SQL Table GL.payack_account_numbers displays data as they entered in the 'General Ledger Payment Acknowledgement Account Numbers' form. Scenario 3: Table Import For General Ledger Account Numbers - Payment Acknowledgement Account Numbers - Append To Existing Table Specific Setup: System is updated for General Ledger module. Registry Setting: The ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ registry setting is set to ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. File Explorer: First file is created to add general ledger 'Payment Acknowledgement Account Number' without any dates specified in the file. Second file is created to add general ledger 'Payment Acknowledgement Account Number' with the start/end dates specified in the file. Third file is created to add overlapping general ledger 'Payment Acknowledgement Account Number'. Steps Open the 'Table Import For General Ledger Account Numbers' form. Verify the selection for 'GL Payment Acknowledgement Account Numbers' is available. Select the 'GL Payment Acknowledgement Account Numbers'. Select the 'Append to Existing Table'. Select the first file identified in the setup section. Click [Import GL Account Numbers]. Verify the data generated was imported based on the criteria previously selected and correctly displays the 'Total Number of Rows in File'. Click [Close Report]. Select the first file identified in the setup section again. Click [Import GL Account Numbers]. Verify the system prevents the account numbers to add because of duplicate existing records. Click [Close Report]. Select the second file identified in the setup section. Click [Import GL Account Numbers]. Verify the data generated was imported based on the criteria previously selected and correctly displays the 'Total Number of Rows in File'. Click [Close Report]. Select the third file identified in the setup section. Click [Import GL Account Numbers]. Verify the data generated was imported based on the criteria previously selected and correctly displays the 'Total Number of Rows in File'. Verify the system prevents the account numbers to add because of duplicate existing records. Click [Close Report]. Scenario 4: Table Import For General Ledger Account Numbers - Payment Acknowledgement Account Numbers -Override an existing table Specific Setup: System is updated for General Ledger module. Registry Setting: The ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ registry setting is set to ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface 204 - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. 205 - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. File Explorer: First file is created to add general ledger 'Payment Acknowledgement Account Number' without any dates specified in the file. Note the values specified in the file. Second file is created with the different component value for the component one. Note the values specified in the file. Steps Open the 'Table Import For General Ledger Account Numbers' form. Verify the selection for 'GL Payment Acknowledgement Account Numbers' is available. Select the 'GL Payment Acknowledgement Account Numbers'. Select the 'Over-Ride Existing Table' from the 'Load Option' field. Select the first file identified in the setup section. Click [Import GL Account Numbers]. Verify the data generated was imported based on the criteria previously selected and correctly displays the 'Total Number of Rows in File'. Click [Close Report]. Select the first file identified in the setup section again. Click [Import GL Account Numbers]. Verify the system overrides an existing record. Click [Close Report]. Select the second file identified in the setup section. Click [Import GL Account Numbers]. Verify the SQL table displays a record that is recently imported and overrides an existing record of the file. Click [Close Report]. Select the third file identified in the setup section. Click [Import GL Account Numbers]. Verify the data generated was imported based on the criteria previously selected and correctly displays a row that overrides an existing record of the file. Click [Close Report]. Click [Close Form].	Topics • NX • Payment Acknowledgement
Update 88 Summary \| Details 835 Health Care Claim Payment/Advice - Check / EFT # Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Claim Adjustment Group/Reason Code Definition Registry Settings (PM) Guarantors/Payors Dictionary Update (PM) Admission (Outpatient) Default Guarantor Assignment Financial Eligibility Posting/Adjustment Codes Definition Diagnosis Client Ledger Create Interim Billing Batch File Electronic Billing Payment Acknowledgement 835 Health Care Claim Payment/Advice (PM) Client Charge Input Scenario 1: 835 Health Care Claim Payment/Advice - Partial posting of an 835s - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=1&2&3 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 date of payment column contains the posting date from the '835 Health Care Claim Payment/Advice' form. Scenario 2: 835 Health Care Claim Payment/Advice - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=0* 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 '0'. The 'Check Number' 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 date of payment column contains the posting date from the '835 Health Care Claim Payment/Advice' form. Scenario 3: 835 Healthcare Claim Payment/Advice - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=1 and the 'Check Number' = 1* 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. 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. Scenario 4: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Validating check Date - 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: Two existing guarantor are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor codes/names. 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. 835 Health Care Claim Payment/Advice - Registry Setting 'Posting Date for Automated 835s'* Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Charge Input Client Ledger Diagnosis Create Interim Billing Batch File Electronic Billing Claim Adjustment Group/Reason Code Definition 835 Health Care Claim Payment/Advice (PM) Payment Acknowledgement Registry Settings (PM) Guarantors/Payors Dictionary Update (PM) Admission (Outpatient) Default Guarantor Assignment Financial Eligibility Posting/Adjustment Codes Definition Scenario 1: 835 Healthcare Claim Payment/Advice - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=1 and the 'Check Number' = 1 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. 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. Scenario 2: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Validating check Date - 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: Two existing guarantor are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor codes/names. 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. Scenario 3: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Validating Processing Date - 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&2'. 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. 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 Files\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 Files\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 Files\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: Two existing guarantor are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor codes/names. 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 processing date when the 835 file is posted. 835 Health Care Claim Payment/Advice - ‘Check/EFT #’ drop down Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Claim Adjustment Group/Reason Code Definition Registry Settings (PM) Guarantors/Payors Dictionary Update (PM) Admission (Outpatient) Default Guarantor Assignment Financial Eligibility Posting/Adjustment Codes Definition Diagnosis Client Ledger Create Interim Billing Batch File Electronic Billing Payment Acknowledgement 835 Health Care Claim Payment/Advice (PM) Client Charge Input Scenario 1: 835 Health Care Claim Payment/Advice - Partial posting of an 835s - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=1&2&3 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 date of payment column contains the posting date from the '835 Health Care Claim Payment/Advice' form. Scenario 2: 835 Health Care Claim Payment/Advice - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=0* 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 '0'. The 'Check Number' 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 date of payment column contains the posting date from the '835 Health Care Claim Payment/Advice' form. Scenario 3: 835 Healthcare Claim Payment/Advice - Registry setting 'Prevent Posting Payments Unless Payment has been Acknowledged'=1 and the 'Check Number' = 1* 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. 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. Scenario 4: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Validating check Date - 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: Two existing guarantor are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor codes/names. 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. Batch Cash Posting - Payment Acknowledgement* Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Guarantors/Payors Dictionary Update (PM) Admission (Outpatient) Default Guarantor Assignment Financial Eligibility Client Charge Input Client Ledger Posting/Adjustment Codes Definition Batch Cash Posting Payment Acknowledgement Scenario 1: Prevent Posting Payments Unless Payment has been Acknowledged - Batch Cash Posting - Posting payment 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&2'. Admission: Admit a client into an outpatient episode. Note the Client id/name, Admission date/program. Guarantor/Payors: An existing guarantor is identified who has a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Validate the 'Posting Type' field exists and it marks as required field. Valid values: Payment, Adjustment. Validate the 'Payment Acknowledgement' field exists and it initially disabled. It becomes enable and required when the 'Payment' is selected for the 'Posting Type'. Valid values: Yes, No. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgement' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Validate 'Filter Payment Acknowledgments' button exists. Enter desired amount in the 'Amount to Post' field. Validate the system defaults an amount of $0 because the ‘Posting Type’ is Payment and ‘Payment Acknowledgment’ is set to No. Enter desired non-zero amount in the 'Amount to Post' field. Verify the error message - 'Payment Acknowledgment is required for non-zero dollar payments.' Click [Discard]. Open ‘Payment Acknowledgment’ form. 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’. 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 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select 'Individual' in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter desire Check/EFT # in the 'Check #' field. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - SYSTEM.billing_pay_adj_history Locate to the SQL Editor Query 'select * from SYSTEM.billing_pay_adj_history where PATID=614' Validate the ID cell is equal to '98\|\|614\|\|B66169.001\|\|CR66169.001' Validate the FACILITY cell is equal to '98' Validate the 1st PATID cell is equal to '614' Validate the EPISODE_NUMBER column is equal to '1' Validate the GUARANTOR_ID cell is equal to '100' Validate the date_of_payment cell is equal to '2022-03-01' Validate the payment_type_code cell is equal to '6001' Validate the payment_type_value cell does not contain 'PAY ACKNOWLEDGEMENT - CHECK' Validate the payment_amount cell does not contain '50.00' Validate the check_number cell is equal to '96979353397' Validate the date_of_receipt cell is equal to '2022-03-01' Validate the date_of_service column is equal to '2022-03-01' Validate the option_desc cell is equal to 'Batch Cash Posting' Validate the type_of_payment cell is equal to 'PAYMENT' Close the SQL data viewer. Scenario 2: Prevent Posting Payments Unless Payment has been Acknowledged - Batch Cash Posting - Posting Adjustments and $0.00 payment with Write-Off Steps Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select 'Individual' in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter desire Check/EFT # in the 'Check #' field. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - SYSTEM.billing_pay_adj_history Locate to the SQL Editor Query 'select * from SYSTEM.billing_pay_adj_history where PATID=614' Validate the ID cell is equal to '98\|\|614\|\|B66169.001\|\|CR66169.001' Validate the FACILITY cell is equal to '98' Validate the 1st PATID cell is equal to '614' Validate the EPISODE_NUMBER column is equal to '1' Validate the GUARANTOR_ID cell is equal to '100' Validate the date_of_payment cell is equal to '2022-03-01' Validate the payment_type_code cell is equal to '6001' Validate the payment_type_value cell does not contain 'PAY ACKNOWLEDGEMENT - CHECK' Validate the payment_amount cell does not contain '50.00' Validate the check_number cell is equal to '96979353397' Validate the date_of_receipt cell is equal to '2022-03-01' Validate the date_of_service column is equal to '2022-03-01' Validate the option_desc cell is equal to 'Batch Cash Posting' Validate the type_of_payment cell is equal to 'PAYMENT' Close the SQL data viewer. Registry Setting - Prevent Posting Payments Unless Payment has been Acknowledged Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Guarantors/Payors Dictionary Update (PM) Admission (Outpatient) Default Guarantor Assignment Financial Eligibility Client Charge Input Client Ledger Posting/Adjustment Codes Definition Batch Cash Posting Payment Acknowledgement Claim Adjustment Group/Reason Code Definition Create Interim Billing Batch File Electronic Billing 835 Health Care Claim Payment/Advice (PM) Diagnosis Scenario 1: Registry Setting validation - Prevent Posting Payments Unless Payment has been Acknowledged Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'Registry Setting' 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 and/or 3. 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. 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'. 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 '1&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 '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 '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 '1&2&3'. Click [Submit]. Click [OK]. Click [No]. Scenario 2: Prevent Posting Payments Unless Payment has been Acknowledged - Batch Cash Posting - Posting payment 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&2'. Admission: Admit a client into an outpatient episode. Note the Client id/name, Admission date/program. Guarantor/Payors: An existing guarantor is identified who has a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Validate the 'Posting Type' field exists and it marks as required field. Valid values: Payment, Adjustment. Validate the 'Payment Acknowledgement' field exists and it initially disabled. It becomes enable and required when the 'Payment' is selected for the 'Posting Type'. Valid values: Yes, No. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgement' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Validate 'Filter Payment Acknowledgments' button exists. Enter desired amount in the 'Amount to Post' field. Validate the system defaults an amount of $0 because the ‘Posting Type’ is Payment and ‘Payment Acknowledgment’ is set to No. Enter desired non-zero amount in the 'Amount to Post' field. Verify the error message - 'Payment Acknowledgment is required for non-zero dollar payments.' Click [Discard]. Open ‘Payment Acknowledgment’ form. 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’. 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 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select 'Individual' in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter desire Check/EFT # in the 'Check #' field. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - SYSTEM.billing_pay_adj_history Locate to the SQL Editor Query 'select * from SYSTEM.billing_pay_adj_history where PATID=614' Validate the ID cell is equal to '98\|\|614\|\|B66169.001\|\|CR66169.001' Validate the FACILITY cell is equal to '98' Validate the 1st PATID cell is equal to '614' Validate the EPISODE_NUMBER column is equal to '1' Validate the GUARANTOR_ID cell is equal to '100' Validate the date_of_payment cell is equal to '2022-03-01' Validate the payment_type_code cell is equal to '6001' Validate the payment_type_value cell does not contain 'PAY ACKNOWLEDGEMENT - CHECK' Validate the payment_amount cell does not contain '50.00' Validate the check_number cell is equal to '96979353397' Validate the date_of_receipt cell is equal to '2022-03-01' Validate the date_of_service column is equal to '2022-03-01' Validate the option_desc cell is equal to 'Batch Cash Posting' Validate the type_of_payment cell is equal to 'PAYMENT' Close the SQL data viewer. Scenario 3: Prevent Posting Payments Unless Payment has been Acknowledged - Batch Cash Posting - Posting Adjustments and $0.00 payment with Write-Off Steps Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select 'Individual' in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter desire Check/EFT # in the 'Check #' field. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - SYSTEM.billing_pay_adj_history Locate to the SQL Editor Query 'select * from SYSTEM.billing_pay_adj_history where PATID=614' Validate the ID cell is equal to '98\|\|614\|\|B66169.001\|\|CR66169.001' Validate the FACILITY cell is equal to '98' Validate the 1st PATID cell is equal to '614' Validate the EPISODE_NUMBER column is equal to '1' Validate the GUARANTOR_ID cell is equal to '100' Validate the date_of_payment cell is equal to '2022-03-01' Validate the payment_type_code cell is equal to '6001' Validate the payment_type_value cell does not contain 'PAY ACKNOWLEDGEMENT - CHECK' Validate the payment_amount cell does not contain '50.00' Validate the check_number cell is equal to '96979353397' Validate the date_of_receipt cell is equal to '2022-03-01' Validate the date_of_service column is equal to '2022-03-01' Validate the option_desc cell is equal to 'Batch Cash Posting' Validate the type_of_payment cell is equal to 'PAYMENT' Close the SQL data viewer. Scenario 4: 835 Healthcare Claim Payment/Advice - Automated 835s posting - Validating Processing Date - 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&2'. 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. 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 Files\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 Files\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 Files\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: Two existing guarantor are identified who have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. financial class of 'Self Pay'. Note the guarantor codes/names. 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 processing date when the 835 file is posted. Scenario 5: Registry Setting validation - Prevent Posting Payments Unless Payment has been Acknowledged Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'Registry Setting' 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 and/or 3. 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. 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'. 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 '1&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 '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 '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 '1&2&3'. Click [Submit]. Click [OK]. Click [No].	Topics • 835 Health Care Claim Payment/Advice • NX • Batch Cash Posting • Payment Acknowledgement • Registry Settings
Update 94 Summary \| Details Edit Service Information - Admission vs. Service Program Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Program Maintenance Admission (Outpatient) Client Charge Input Program Transfer (OutPatient) Client Ledger Service Codes Scenario 1: Edit Service Program - Editing the service information after program transfer - Enable 'Admission vs. Service Program' Functionality registry setting Specific Setup: Registry Setting: The "Enable 'Admission vs. Service Program' Functionality" registry setting is set to 'Y'. Program Maintenance: Two new outpatient admission programs are created such that there is no overlap of the associated service programs between the two admission programs. Note the admission programs and associated service programs. Admission (Outpatient): The client is admitted into the first admission program. Client Charge Input: A service is rendered to the client under one of the associated service programs. Note the service date and service code. Program Transfer (Outpatient): The client is transferred into the second admission program. Steps Open the 'Edit Service Information' form. Fill in all required fields. Click [Select Service(s) to Edit]. Verify the 'Select Service(s) to Edit' dialog box launched with all the services rendered to the selected client. Select desired service to edit. Verify the 'Program' field is populated with the service programs that was associated with the admission program at the time of service creation. Submit the form. Verify the form submits successfully. 835 Crossover Logic - Posting Code = Transfer Type - Redistribute (Close) Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Guarantors/Payors Service Codes Practitioner Enrollment Program Maintenance Admission (Outpatient) Diagnosis Financial Eligibility Client Charge Input Practitioner Numbers By Guarantor And Program Client Ledger Posting/Adjustment Codes Definition Claim Adjustment Group/Reason Code Definition Electronic Billing 835 Health Care Claim Payment/Advice (PM) Scenario 1: Crossover Claims - Allow Billing Next Guarantor Specific Setup: The following registry setting has a value of 'Y': Avatar PM->Billing->Electronic Billing->All 837 Submissions->->Enable Support For Crossover Claims. Practitioner Enrollment is used to identify desired service practitioner and the ‘Practitioner Categories for Coverage’. Service Code: Identify a service code that will be used to create services. Note the service code fee in Service Fee/Cross Reference Maintenance. Benefit Plan: All benefit plans contain ‘Practitioner Categories for Coverage’ in ‘Covered Charge Categories’. Plan for Guarantor 1 will fully cover the service fee. Plan for Guarantor 2 contains a value in ‘Monthly Maximum Responsibility’. Note the value. Plan for Guarantor 3 will fully cover the service fee. Guarantors/Payors: Three guarantors are identified that do not share the same ‘Default Guarantor Plan’. Admit a new client: Note the admission date and program. Add a diagnosis record. Add a financial eligibility record: Guarantor #1 = Guarantor 1. Guarantor #2 = Guarantor 2. Guarantor #31 = Guarantor 3. Guarantor/Program Billing Defaults: Edit the template for the secondary guarantor, section 837 Professional or 837 Institutional. Select Guarantor(s) Responsible For Crossover Claim Submission = Primary Guarantor. Number of Days to Hold Billing of Claim = 15. Note: Zero is a valid value for this field and if used the primary and secondary guarantors can be billed immediately. Client Charge Input is used to create two services 25 and 26 days in the past, ensuring they are in the same month. Client Ledger is used to validate that the charge distributed full liability to Guarantor 1. Close Charges is used to close the charge. Electronic Billing: Guarantor 1: has been used to create a claim 19 days in the past. An '835 Health Care Claim Payment/Advice’ exists that pays each of the two services, minus the ‘Monthly Maximum Responsibility’ amount noted above, for each service. Note the Claim Adjustment Group/Reason Code used in the ‘CAS’ segment. Verify the that ‘Claim Adjustment Group/Reason Code Definition’ exists for the guarantors and that the posting code = 'Transfer – Redistribute (Close)’. Steps Open ‘835 Health Care Claim Payment/Advice’. Load, compile and post the '835 Health Care Claim Payment/Advice’. Close the form. Open ‘Client Ledger’ and validate that Guarantor 2 has a ‘LINE BALANCE’ equal to the ‘Monthly Maximum Responsibility’ amount due to the transfer. Also, validate that Guarantor 3 has a ‘LINE BALANCE’ equal to the ‘Monthly Maximum Responsibility’ amount due to the transfer. If desired post an ‘835 Health Care Claim Payment/Advice’ files for Guarantor 2 and Guarantor 3. Close the form. 835 Crossover Logic - CCBHC guarantors Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Guarantors/Payors Service Codes Claim Adjustment Group/Reason Code Definition Posting/Adjustment Codes Definition Practitioner Numbers By Guarantor And Program Practitioner Enrollment Program Maintenance Dictionary Update (PM) Admission (Outpatient) Diagnosis Financial Eligibility Client Charge Input Client Ledger Electronic Billing 835 Health Care Claim Payment/Advice (PM) Scenario 1: Crossover Claims - Allow Billing Next Guarantor - Primary Guarantor is not CCBHC - Secondary Guarantor is CCBHC Specific Setup: The following registry setting has a value of 'Y': Avatar PM->Billing->Electronic Billing->All 837 Submissions->->Enable Support For Crossover Claims. Practitioner Enrollment is used to identify desired service practitioner and the ‘Practitioner Categories for Coverage’. Service Code: Identify a CCBHC service code that will be used to create a service. Note the service code fee in Service Fee/Cross Reference Maintenance. Benefit Plan: All benefit plans contain ‘Practitioner Categories for Coverage’ in ‘Covered Charge Categories’. Plan for Guarantor 1 will fully cover the service fee. Plan for Guarantor 3 will fully cover the service fee. Guarantors/Payors: Guarantor 1 is not a CCBHC guarantor. Guarantor 2 is a CCBHC guarantor. Admit a new client that bills CCBHC services. Note the admission date and program. Add a diagnosis record. Add a financial eligibility record: Guarantor #1 = Guarantor 1. Guarantor #2 = Guarantor 2. Guarantor/Program Billing Defaults: Edit the CCBHC template for the secondary guarantor, section 837 Professional or 837 Institutional. Select Guarantor(s) Responsible For Crossover Claim Submission = Primary Guarantor. Number of Days to Hold Billing of Claim = 15. Note: Zero is a valid value for this field and if used the primary and secondary guarantors can be billed immediately. Client Charge Input is used to create two services 25 and 26 days in the past, ensuring they are in the same month. Client Ledger is used to validate that the charge distributed full liability to Guarantor 1. Close Charges is used to close the charges. Electronic Billing: Guarantor 1: has been used to create a claim 19 days in the past. An '835 Health Care Claim Payment/Advice’ exists that pays the service, minus $10.00. Note the Claim Adjustment Group/Reason Code used in the ‘CAS’ segment. Verify the that ‘Claim Adjustment Group/Reason Code Definition’ exists for the three guarantor and that the posting code = 'Transfer – Redistribute (Close)’. Steps Open ‘835 Health Care Claim Payment/Advice’. Load, compile and post the '835 Health Care Claim Payment/Advice’. Close the form. Open ‘Client Ledger’ and validate that Guarantor 2 has a ‘LINE BALANCE’ equal to $10.00 due to the transfer. If desired post an ‘835 Health Care Claim Payment/Advice’ file for Guarantor 2. Close the form. Web Service - Edit Service Information - Practitioner Disciple Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Registry Settings (PM) Practitioner Enrollment Client Ledger SQL Query/Reporting Admission Financial Eligibility Scenario 1: 'Edit Service Information' web service - Editing 'Open' services Specific Setup: Practitioner Enrollment is used to validate the 'Discipline' of the desired practitioner. Service Code 1: Is a service code that does not contain the practitioner's discipline in 'Discipline(s)'. Service Code 2: Is a service code that does contain the practitioner's discipline in 'Discipline(s)'. Identify an existing client that has at least one existing open service for Service Code 2 and the practitioner. Note the client's id/name, service code, practitioner's id, and the service date. Steps Open the SoapUI or any other web service testing tool. Create a web service request to edit the service information, using ‘WEBSVC.EditServiceInformation:EditServiceInformationICD10'. The 'SystemCode' will be equal to the value used when logging into myAvatar. The 'UserName' will be equal to the value used when logging into myAvatar. The 'Password' will be equal to the value used when logging into myAvatar. Enter values for all required fields. Select Service Code 1 in ‘ServiceCode’. Submit the request. Verify the response message contains: Discipline : No common disciplines found for Practitioner and Service code selected. Change the service code to Service Code 2. Add data to one field that had no date or change existing data for a field. Submit the request. Verify the message: "Edit Service Information web service has been filed successfully". If desired, open 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Query the 'SYSTEM.billing_tx_history' SQL table. Validate the 'PATID' column is equal to the correct client id identified in the setup. Validate the 'date_of_service' column is equal to correct date of service rendered to the client. Validate the 'Service Code' column contains correct service code entered in the web service request. Validate the 'data_entry_source' column contains 'WEBSVC.EditServiceInformation:EditServiceInformationICD10'.	Topics • Edit Service Information • Practitioner • Program Transfer • 835 Health Care Claim Payment/Advice • NX • Web Services
Update 97 Summary \| Details Enhanced 'Address' information in several forms. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Admission (Outpatient) Discharge Call Intake Admission Update Client Data Pre Admit Pre Admit Discharge Client Admission Web Service Scenario 1: 'Admission (Outpatient)' - field validation Steps Open 'Admission (Outpatient)' form for an existing client. Ensure that 'Address Start Date' field is present in 'Admission (Outpatient)' form. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM 'Admission (Outpatient)' form for filed record. Ensure 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Admission (Outpatient)' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Admission (Outpatient)' form is present in 'address_start_date' field. Scenario 2: 'Discharge' form field validation Steps Open 'Discharge' form for an existing client. Ensure that 'Address Start Date' field is present in 'Discharge' form. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM 'Discharge' form for filed record. Ensure 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Discharge' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Discharge' form is present in 'address_start_date' field. Scenario 3: 'Call Intake' - field validation Steps Open 'Call Intake' form. Set 'Last Name' to any client name. Set 'First Name' to any client name. Set 'Sex' to client gender. Click [Search] Click [New Client]. Enter data in all required fields. Click [Demographics]. Ensure that 'Address Start Date' field is present in 'Call Intake' form. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open 'Call Intake' form for filed record. Ensure 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Call Intake' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Call Intake' form is present in 'address_start_date' field. Scenario 4: 'Admission' form - Field Validation Steps Open 'Admission' form for existing client. Ensure that 'Address Start Date' field is present in 'Admission' form 'Demographics' section. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM 'Admission' form for filed record. In 'Admission' form, ensure that 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Admission' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Admission' form is present in 'address_start_date' field. Scenario 5: 'Update Client Data' form - Verification of 'Client Demographics' form fields Specific Setup: Existing client record eligible for 'Update Client Data' entry/filing. Crystal Reports or other SQL Reporting tool. Steps Open Avatar PM 'Update Client Data' form. Select existing client for update/entry. Ensure that 'Address Start Date' field is present in 'Update Client Data' form. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter value in 'Address Start Date' field. Enter/select values for all other required/desired fields in form. Click 'Submit' button to file Client Data update. Re-open Avatar PM 'Update Client Data' form for filed record. In 'Update Client Data' form, ensure that 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Update Client Data' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Update Client Data' form is present in 'address_start_date' field. Scenario 6: 'Pre Admit' form - field validation Specific Setup: Client is admitted as a Pre Admit client. Steps Open 'Pre Admit' form for an existing Pre Admit client. Ensure that 'Address Start Date' field is present in 'Pre Admit' form. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM ''Pre Admit'' form for filed record. Ensure 'Address Start Date' field displays 'Address Start Date' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in ''Pre Admit'' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in ''Pre Admit'' form is present in 'address_start_date' field. Scenario 7: 'Pre Admit Discharge' - field validation Steps Open 'Pre Admit Discharge' form for an existing client. Complete required fields as needed. Ensure that 'Address Start Date' field is present in the 'Client Demographics' section. Enter a value in 'Address Start Date' field. Note that entering future dates will generate a pop up message indicating future dates are not allowed. Invalid dates will generate a pop-up message indicating the format is not valid. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open the 'Pre Admit Discharge' form for the same client. Ensure the 'Address Start Date' field is populated with the date entered on discharge. Close the form. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Address Start Date' value filed in 'Pre Admit Discharge' form is present in 'address_start_date' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Address Start Date' value filed in 'Pre Admit Discharge' form is present in 'address_start_date' field. Scenario 8: Client Admission Web Service - Add Admission field validation Steps Internal testing only.	Topics • Admission • Admission (Outpatient) • Call Intake • Discharge • NX • Pre Admit • Pre Admit Discharge • Update Client Data • Web Services
Update 99 Summary \| Details File Import - Payment/Adjustment Posting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) Create Interim Billing Batch File Electronic Billing Posting/Adjustment Codes Definition Client Ledger File Import Dynamic Form Delete File Payment Acknowledgement Scenario 1: Registry Setting validation - Prevent Posting Payments Unless Payment has been Acknowledged Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'Registry Setting' 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 and/or 3. 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. 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'. 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 '1&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 '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 '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 '1&2&3'. Click [Submit]. Click [OK]. Click [No]. Scenario 2: File Import - Validate Payment/Adjustment import files 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 = 3, at a minimum. Avatar PM->System Maintenance->File Import->->->Import File Delimiter – note the value to be used when creating the file to import. Posting/Adjustment Codes Definition has been used to note a payment code. Client A: Client is identified that has multiple unpaid claims. Note the guarantor, service code, service date, claim number and the line balance. Payment Acknowledgement has been used to create a minimum of one acknowledged payment for the same guarantor as the client’s guarantor. Note the transaction number this is included in the ‘Payment Acknowledgement’ message. Create a file to import to the Payment/Adjustment Posting option and includes the transaction number. The File Import spreadsheet will be included in the zip file. Steps 1. Open the "File Import" form. 2. Select "File Type" of "Payments/Adjustment Posting". 3. Select "Action" of "Upload New File". 4. Click "Process Action". 5. Select "Action" of "Compile/Validate File". 6. Select the file that was just uploaded in "File(s)". 7. Click "Process Action". 8. Click “OK” on the “Compiled” message. 9. Select "Action" of "Post File". 10. Select the file that was just compiled in "File(s)". 11. Click "Process Action". 12. Click “OK” on the “Posted” message. 13. Close the form. 14. Open the "Client Ledger" form. 15. Process the client ledger. 16. Validate the payment information is reflected in the client's ledger. 17. Close the form. Scenario 3: Registry Setting validation - Prevent Posting Payments Unless Payment has been Acknowledged Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'Registry Setting' 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 and/or 3. 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. 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'. 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 '1&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 '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 '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 '1&2&3'. Click [Submit]. Click [OK]. Click [No].	Topics • NX • Payment Acknowledgement • Registry Settings
Update 100 Summary \| Details Personal Pronouns may be included on client demographic forms and in client headers. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Lookup/Header Configuration Manager Update Client Data Progress Notes (Group and Individual) Admission Admission (Outpatient) Pre Admit Pre Admit Discharge Call Intake Entity Information Display Discharge Admission Web Service Client Search SQL Query/Reporting Scenario 1: Client Lookup/Header Configuration Manager - Client Header Specific Setup: RADplus 2022 Update 109 is required for full functionality. Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" must include a value of '10'. Steps Open 'Client Lookup/Header Configuration Manager'. Click 'Client Header' section. Click [Add New Item]. Select 'Personal Pronouns' from the 'Field to Include in Client Header' drop down list. Select any available location in the 'Field Order'' drop down list. Click [Submit]. Display the client Chart for any client where 'Personal Pronouns' have been entered via an admission form. Verify the 'Personal Pronouns' column displays as defined. Verify the client's preferred pronoun(s) are displayed. Open 'Client Lookup/Header Configuration Manager'. Click 'Client Header Override' section. This will allow setup of the 'Personal Pronouns' to display based on the client's admission program. Click [Add New Item]. Select 'Personal Pronouns' from the 'Field to Include in Client Header' drop down list. Select any program from the 'Program' drop down list. Select any available location in the 'Field Order'' drop down list. Click [Submit]. Open any form such as Progress Notes (Group and Individual) for a client assigned to the selected program and who has 'Personal Pronouns' setup in an admission form. Verify the Client Header displays the 'Personal Pronouns' in the location defined for the program. Close the form. Open the same form for a client who has 'Personal Pronouns' setup in an admission form, but who is not in the selected program. Verify the Client Header displays the 'Personal Pronouns' in the location defined for the 'Client Header' without a program associated. Close the form. Scenario 2: 'Admission' form - Field Validation Specific Setup: RADplus 2022 Update 109 is required for full functionality. Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" must include a value of '10'. Steps Open 'Admission' form for existing client. Ensure that 'Personal Pronouns' field is present in 'Admission' form 'Demographics' section. Enter a value in 'Personal Pronouns' field. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM 'Admission' form for filed record. In 'Admission' form, ensure that 'Personal Pronouns' field displays 'Personal Pronouns' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in 'Admission' form is present in 'personal_pronouns' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in 'Admission' form is present in 'personal_pronouns' field. Scenario 3: 'Update Client Data' form - Verification of 'Client Demographics' form fields Specific Setup: Existing client record eligible for 'Update Client Data' entry/filing. Crystal Reports or other SQL Reporting tool. Steps Open Avatar PM 'Update Client Data' form. Select existing client for update/entry. Ensure that 'Personal Pronouns' field is present in 'Update Client Data' form. Enter value in 'Personal Pronouns' field. This is a free text field, allows alphanumeric characters as well as special characters. Maximum length is 40 characters. Enter/select values for all other required/desired fields in form. Click 'Submit' button to file Client Data update. Re-open Avatar PM 'Update Client Data' form for filed record. In 'Update Client Data' form, ensure that 'Personal Pronouns' field displays 'Personal Pronouns' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in 'Update Client Data' form is present in 'personal_pronouns' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in 'Update Client Data' form is present in 'personal_pronouns' field. Scenario 4: 'Admission (Outpatient)' - field validation Specific Setup: RADplus 2022 Update 109 is required for full functionality. Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" must include a value of '10'. Steps Open 'Admission (Outpatient)' form for an existing client. Ensure that 'Personal Pronouns' field is present in 'Admission (Outpatient)' form. Enter a value in 'Personal Pronouns' field. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM 'Admission (Outpatient)' form for filed record. Ensure 'Personal Pronouns' field displays ''Personal Pronouns' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in 'Admission (Outpatient)' form is present in 'personal_pronoun' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in 'Admission (Outpatient)' form is present in 'personal_pronoun' field. Scenario 5: 'Pre Admit' form - field validation Specific Setup: RADplus 2022 Update 109 is required for full functionality. Steps Open 'Pre Admit' form for an existing Pre Admit client. Ensure that 'Personal Pronouns' field is present in 'Pre Admit' form. Enter a value in 'Personal Pronouns' field. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open Avatar PM ''Pre Admit'' form for filed record. Ensure 'Personal Pronouns' field displays 'Personal Pronouns' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in ''Pre Admit'' form is present in 'personal_pronouns' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in ''Pre Admit'' form is present in 'personal_pronouns' field. Scenario 6: 'Pre Admit Discharge' - field validation Specific Setup: RADplus 2022 Update 109 is required for full functionality Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" must have value of '10' added in order to display the Personal Pronouns to client demographics forms. Steps Open 'Pre Admit Discharge' form for an existing client. Complete required fields as needed. Ensure that 'Personal Pronouns' field is present in the 'Client Demographics' section. Enter a value in 'Personal Pronouns' field. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open the 'Pre Admit Discharge' form for the same client. Ensure the 'Personal Pronouns' field is populated with the date entered on discharge. Close the form. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in 'Pre Admit Discharge' form is present in 'personal_pronouns' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in 'Pre Admit Discharge' form is present in ;personal_pronouns; field. Scenario 7: 'Call Intake' - field validation Specific Setup: RADplus 2022 Update 109 is required for full functionality. Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" must include a value of '10'. Steps Open 'Call Intake' form. Set 'Last Name' to any client name. Set 'First Name' to any client name. Set 'Sex' to client gender. Click [Search] Click [New Client]. Enter data in all required fields. Click [Demographics]. Ensure that 'Personal Pronouns' field is present in 'Call Intake' form. Enter a value in 'Personal Pronouns' field. This is a free text alphanumeric field which also allows special characters. Maximum length is 40 characters. Enter/select values for all other required/desired fields in form. Click [Submit]. Re-open 'Call Intake' form for filed record. Ensure 'Personal Pronouns' field displays 'Personal Pronouns' value from previously filed record. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.patient_current_demographics', ensure that 'Personal Pronouns' value filed in 'Call Intake' form is present in 'personal_pronouns' field. In Avatar PM SQL table 'SYSTEM.patient_demographic_history', ensure that 'Personal Pronouns' value filed in 'Call Intake' form is present in 'personal_pronouns' field. Scenario 8: 'Entity Information Display' - 'Personal Pronouns'. Specific Setup: RADplus 2022 Update 109 is required for full functionality. Registry Setting "Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields" is set to include a value of "10" for the Personal Pronouns field to be added to client demographics in various forms. Steps To add the 'Personal Pronouns' to client search windows: Open 'Entity Information Display' form. Select 'Client' from the 'Entity Database' drop down list. Select 'One' in the 'Number of Additional Columns to Display' field. Note that depending on your setup, if there are entries already defined, you may need to select 'Two' or 'Three'. Set the 'Entity name Header Text' to any description. Set the 'Approximate Number of Characters to Display for Entity Name' to any numeric. This will be the number of characters to display in the entity column in the search window. Select 'Personal Pronouns' from the 'Entity Information Display Column 1' drop down list. Set the 'Entity Information Display Column 1 Header Name' to 'Personal Pronouns' or any other description you require. Set the 'Approximate Number of Characters to Display for Entity Lookup Column 1' to any value. Click [Submit]. Open any form where a client search window will pop-up such as 'Update Client Data'. Set the 'Select Client' field to any existing client to search for. When the search selections display, verify the 'Personal Pronouns' column is displayed. This column may be blank at this time. Select any client from the list. In the selected form, 'Update Client Data' was used for this test, navigate to the 'Personal Pronouns' field. This may be at the bottom of the form. Enter any 'Personal Pronouns' as appropriate. This is a free form text field and will accept numbers and letters, as well as special characters. Maximum length is 40. Click [Submit]. Open the same form again. Search for the same client. Verify that the 'Personal Pronouns' column on the search window is now populated with the value entered in the form. Close the form. Scenario 9: Client Discharge web service Specific Setup: SoapUI or other web service tool. 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 'PersonalPronouns' to any text value, maximum 40 characters. Set 'ClientID' to the client id to be discharged. 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 'Personal Pronouns' display the value entered in the Web Service. Close the form. Scenario 10: Client Admission Web Service - Verification of web service filing Specific Setup: Any Web Service tool such as 'SoapUI'. Steps Using Avatar PM 'Client Admission' web service, submit an 'Admission' record for a client and episode, including the 'Personal Pronouns' field. Ensure that Admission record returns a confirmation message in the web service of successful filing. Open Avatar PM 'Admission' form. Select client record used in 'Client Admission' web service filing. Ensure that 'Admission' record/episode filed via web service is present with values filed via web service, including the 'Personal Pronouns'. Scenario 11: Call Intake Web Service validation - Intake, Update, Delete records Specific Setup: Any web service tool such as 'SoapUI' Crystal Reports or other SQL tool. Steps Using Avatar PM 'ClientCallIntake' web service, submit an Intake record for a 'Call Intake' client, including the 'Personal Pronouns' field. Ensure that Call Intake record returns 'Client Call Intake web service has been filed successfully' message. Open Avatar PM 'Call Intake' form. Select client the record used in web service filing. Ensure that 'Call Intake' record/episode filed via web service is present with values filed via the web service, including the 'Personal Pronouns'. Using Avatar PM 'UpdateCallIntake' web service, submit an updated record for a 'Call Intake' client, including the 'Personal Pronouns' field. Ensure that the Update Call Intake record returns 'Update Call Intake web service has been filed successfully' message. Open Avatar PM 'Call Intake' form. Select client the record used in web service filing. Ensure that 'Call Intake' record/episode filed via web service is present with values filed via the web service, including the 'Personal Pronouns'. Using Avatar PM 'DeleteCallIntake' web service, submit a delete record for a 'Call Intake' client. Ensure that Call Intake record returns 'Delete Client Call Intake web service has been filed successfully' message. Using Crystal reports, or other SQL reporting tool, create a report against SYSTEM.patient_current_demographics. Include, at a minimum, the following fields: PATID personal_pronouns patient_name Run the report. Verify the above records filed via web services are displayed. Close the report. Scenario 12: Client Demographics Web Service validation Specific Setup: SoapUI or other web service tool. Steps Using SoapUI or any other Web Service tool, consume the WSDL for WEBSVC.ClientDemographics.cls In the Request, set the SystemCode, UserName, and Password to the correct value. Set the 'PersonalPronouns' field to any characters (up to 40 maximum characters). Set the 'Sex' field to the gender for the selected client. Set the ClientID to any client number. Complete other fields as desired. Click the Send button. Validate the Response message displays : 'Client Demographics web service has been filed successfully.' In 'Avatar PM', open the 'Update Client Data' form for the client used in the web service. Navigate to the 'Personal Pronouns' field. Validate that the data displays as entered in the Web Service. Close the form.	Topics • Admission • Admission (Outpatient) • Call Intake • NX • Pre Admit • Pre Admit Discharge • Update Client Data • Web Services
Update 103 Summary \| Details Practitioner Enrollment - The 'Staff EVV Type' and 'Email Address' fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Enrollment Practitioner Enrollment (Brief) Scenario 1: 'ClinicianServicesV2' Web Service - Verification Of 'putClinicianCreation' Filing Specific Setup: Application utilizing the Avatar PM 'ClinicianServicesV2' web service Steps Using the 'ClinicianServicesV2' web service, submit a request using the 'putClinicianCreation' method to create new 'Practitioner Enrollment' record (and optionally Avatar MSO Performing Provider Registration record), including values for the 'EmailAddress' and 'StaffEVVType' fields/segments. Confirm the 'ClinicianServicesV2' web service responds with confirmation data on successful filing of 'putClinicianCreation' method. Example: "<Confirmation>Practitioner ID:000017\|\|\|\|First Name:FIRSTNAME\|\|Last Name:LASTNAME\|\|Registration Date:01/01/2022\|\|NPI:123456789</Confirmation>" Confirm the 'ClinicianServicesV2' web service responds with confirmation message on successful filing of 'putClinicianCreation' method. Example: "<Message>Clinician Services web service has been filed successfully.</Message>" Confirm the 'ClinicianServicesV2' web service responds with successful status value on successful filing of 'putClinicianCreation' 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 Enrollment' record is created in Avatar PM, with values/data submitted via web service including 'Email Address' and 'Staff EVV Type' field values (as well as values assigned for Avatar MSO 'Performing Provider' and 'Performing Provider Registration' practitioner association/link fields if enabled). Scenario 2: 'ClinicianServicesV2' Web Service - Verification Of 'putClinicianUpdate' Filing Specific Setup: Application utilizing the Avatar PM 'ClinicianServicesV2' web service. Steps Using the 'ClinicianServicesV2' web service, submit a request using the 'putClinicianUpdate' method to edit/update a 'Practitioner Enrollment' record (and optionally Avatar MSO Performing Provider Registration record if linked), including values for the 'EmailAddress' and 'StaffEVVType' fields/segments. Confirm the 'ClinicianServicesV2' web service responds with confirmation data on successful filing of 'putClinicianUpdate' method. Example: "<Confirmation>Practitioner ID:000017\|\|\|\|First Name:FIRSTNAME\|\|Last Name:LASTNAME\|\|Registration Date:01/01/2022\|\|NPI:123456789</Confirmation>" Confirm the 'ClinicianServicesV2' web service responds with confirmation message on successful filing of 'putClinicianUpdate' method. Example: "<Message>Clinician Services web service has been filed successfully.</Message>" Confirm the 'ClinicianServicesV2' web service responds with successful status value on successful filing of 'putClinicianUpdate' method. Example: " <Status>1</Status>" Access the 'Practitioner Enrollment' form and select the 'Practitioner Enrollment' record filed via web service for view/update. Confirm the 'Practitioner Enrollment' record is updated in Avatar PM, with values/data submitted via web service including 'Email Address' and 'Staff EVV Type' field values. Scenario 3: '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 values for the 'EmailAddress' and 'StaffEVVType' fields/segments. 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 'Email Address' and 'Staff EVV Type' field values. Scenario 4: '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 values for the 'EmailAddress' and 'StaffEVVType' fields/segments. 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 'Email Address' and 'Staff EVV Type' values. Scenario 5: '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 'Staff EVV Type' and 'Email Address' fields are displayed. Enter any value in the 'Staff EVV Type' field. Enter any value in the 'Email Address' 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 'Staff EVV Type' field contains the value filed in the previous steps. Validate the 'Email Address' 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 'Staff_EVV_Type' field contains the value filed in the previous steps. Validate the 'email_address' field contains the value filed in the previous steps. Close the report. Scenario 6: '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 'Staff EVV Type' and 'Email Address' fields are displayed. Enter any value in the 'Staff EVV Type' field. Enter any value in the 'Email Address' 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 'Staff EVV Type' field contains the value filed in the previous steps. Validate the 'Email Address' 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 'Staff_EVV_Type' field contains the value filed in the previous steps. Validate the 'email_address' field contains the value filed in the previous steps. Close the report.	Topics • Practitioner • Web Services
Update 108 Summary \| Details Registry Setting - Enable Payment Acknowledgement Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Registry Settings (PM) User Definition Posting/Adjustment Codes Definition General Ledger Payment Acknowledgement Interface Components General Ledger Payment Acknowledgement Account Numbers Compile General Ledger Payment/Adjustment Interface File Dictionary Update (PM) General Ledger Payment/Adjustment Account Numbers General Ledger Charge Account Numbers Admission (Outpatient) Financial Eligibility Client Ledger Payment Acknowledgement Batch Cash Posting Compile General Ledger Charge Interface File Scenario 1: Enable Payment Acknowledgement - Forms, Fields and Table validation Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is not available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are not available under the 'General Ledger Interface' item. Click [OK]. Click [Select Tables for Product SQL Access]. Verify the 'payack_account_numbers' sql table is not available under 'GL' database and in the Avatar PM namespace. Click [OK]. Click [Submit]. Click [No]. Open the ‘Posting/Adjustment Code Definition’ form. Select ‘Edit’ and select any posting code. Verify that the 'Payment Acknowledgement Type' field is not displayed on the form. Close the form. Open the ‘Compile General Ledger Payment/Adjustment Interface File’ form. Verify that the ‘Include Payments Acknowledgments’ field not displayed on the form. Close the form. Open the 'Registry Settings' form. Select the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting. Verify the registry setting is set to '0' and system does not allow to make any selections other than zero. Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'Y'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are available under the 'General Ledger Interface' item. Select the 'Payment Acknowledgement', 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms. Click [OK]. Click [Select Tables for Product SQL Access]. Verify the 'payack_account_numbers' sql table is available under 'GL' database and in the Avatar PM namespace. Select the 'payack_account_numbers' sql table. Click [OK]. Click [Submit]. Click [No]. Verify the 'Payment Acknowledgement', 'General Ledger Payment Acknowledgement Interface Components' and 'General Ledger Payment Acknowledgement Account Numbers' forms are accessible from the menu. Open the ‘Posting/Adjustment Code Definition’. Select ‘Edit’ and select any posting code. Verify that the 'Payment Acknowledgement Type' field is displayed on the form. Close the form. Open the ‘Compile General Ledger Payment/Adjustment Interface File’ form. Verify that the ‘Include Payments Acknowledgments’ field displayed on the form with two options: 1. Payment Acknowledgement 2. Post Payment Entry Close the form. Open the 'Registry Settings' form. Select the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting. Verify the system allows user to select any value from the available values. Close the form. Scenario 2: Payment Acknowledgement - Compile General Ledger Payment/Adjustment Interface File-Batch Cash Posting Specific Setup: System updated with Avatar GL module. General Ledger Charge Account Numbers and default account numbers are defined. General Ledger Payment/Adjustment components and account numbers are defined. 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&2'. Dictionary Update: File: Client (101) - Treatment Service - enter a code/value and then select the Program extended dictionary and enter desired value (i.e. 000111). Note dictionary code/value. Please note - The value entered here will also need to be added to the 'Program (5521)' dictionary in other tabled files for testing the GL compile. File: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Add the extended dictionary value from the '(101) Client' file and 'Treatment Service' dictionary. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. Admission: A client is identified with charges that resulted in payments, and/or adjustments being posted to the charges. Guarantor/Payors: An existing guarantor is identified who does not have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Note the guarantor's code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open the 'Payment Acknowledgement General Ledger Interface Components' form. Select components. Submit the form. Open the 'General Ledger Payment Acknowledgement Account Numbers' form. Select component and the component value for each of the components. Select credit and debit account numbers. File Account numbers for each component and date range (optional) combination. Go to section 'G/L Payment Acknowledgement Defaults'. Add default account numbers. File Default account numbers. Submit the form. Use Crystal Reports or any other SQL data viewer. Validate the SQL Table GL.payack_account_numbers displays data as they entered in the 'General Ledger Payment Acknowledgement Account Numbers' form. Open ‘Payment Acknowledgment’ form. 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’. Note the Check/EFT number to be used in the 'Batch Cash Posting'. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Please note: The treatment service used must have program extended dictionary setup in the setup section. Select desired ‘Category’ from 'Account' dictionary. 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]. Add the new row for post payment accounting entry. File the form. Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'No' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select desired value in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field if the 'Client ID' field is marked as the required field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter the same Check/EFT # in the 'Check #' field that is entered in the 'Payment Acknowledgement'. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open the 'Compile General Ledger Payment/Adjustment Interface File' form. Select dates that cover the transactions above and select 'no' for pre compile. Do not select anything in the new 'Include Payment Acknowledgements' field. Click [Process]. Verify it generates the payment adjustment GL strings. Return to the form. Select 'Payment Acknowledgements' in the new field. Click [Process]. Verify the GL strings for the Payment Acknowledgement GL Account Numbers are generated. Return to the form. Select 'Post Payment Entry' in the new field. Click [Process]. Verify the GL strings for the Post Payment Entry account numbers are generated. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - GL.comp_pay_ack_int_detail Locate to the SQL Editor Query 'Select * from GL.comp_pay_ack_int_detail WHERE PATID=[Desired ClientId]. Validate the FACILITY cell is equal to '98' Validate the 1st PATID cell is equal to the client id identified in the setup section. Validate the EPISODE_NUMBER column displays correct value. Validate the GUARANTOR_ID column displays correct value. Validate the 'amount 'cell displays the correct amount from the payment acknowledgement form. Validate the gl_credit_number cell displays the correct account number set up. Validate the gl_debit_number cell displays the correct account number set up. Validate the 'interface_component_1_cd' displays the correct value from the setup.	Topics • 835 Health Care Claim Payment/Advice • NX • Payment Acknowledgement
Update 110 Summary \| Details Extended dictionaries are added to 'Type of Discharge' (970). 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 (PM) - validate extended dictionary codes Steps Open "Dictionary Update" for the Avatar PM product Click [Print Dictionary]. Select "Client" from the "File" field drop down Select "individual Data Element" in the "individual or All Data Elements" Select "Data Element Number" in the "Data Element" field Enter '970' in the "Data Element" field and select "(970) Type of Discharge" Click [Print Dictionary]. Validate the following codes are displayed: aadvice = Left Against Advice alt-home = Alternative Home exp = Expired home = Home hosp = Hospice long = long-ter oth - other other-hcf = Other Healthcare Facility psy = Psychiatric Facility rehab = Rehabilitation snf = Skilled Nursing Facility. Select "Data Element Number" in the "Data Element" field Enter '740' in the "Data Element" field and select "(740) Program (FHIR)" Click [Print Dictionary]. Validate the following codes are displayed: 1 = Acquired Brain Injury (ABI) Program 2 = ABI Slow To Recover (ABI STR) Program 3 = Access Programs 4 = Adult and Further Education (ACFE) Program 5 = Adult Day Activity and Support Services (ADASS) Program 6 = Adult Day Care Program 7 = ATSS (Adult Training Support Service) 8 = Community Aged Care Packages (CACP) 9 = Care Coordination & Supplementary Services (CCSS) 10 = Cognitive Dementia Memory Service (CDAMS) 11 = ChildFIRST 12 = Children's Contact Services 13 = Community Visitors Scheme 14 = CPP (Community Partners Program) 15 = Closing the Gap (CTG) 16 = Coordinated Veterans' Care (CVC) Program 17 = Day Program 18 = Drop In Program 19 = Early Years Program 20 = Employee Assistance Program 21 = Home And Community Care (HACC) 22 = Hospital Admission Risk Program (HARP) 23 = Hospital in the Home (HITH) Program 24 = ICTP (Intensive Community Treatment Program) 25 = IFSS (Intensive Family Support Program) 26 = JPET (Job Placement, Education and Training) 27 = Koori Juvenile Justice Program 28 = Language Literacy and Numeracy Program 29 = Life Skills Program 30 = LMP (Lifestyle Modification Program) 31 = MedsCheck Program 32 = Methadone/Buprenorphine Program 33 = National Disabilities Insurance Scheme (NDIS) 34 = National Diabetes Services Scheme (NDSS) 35 = Needle/Syringe Program 36 = nPEP Program 37 = Personal Support Program 38 = Partners in Recovery (PIR) Program 39 = Pre-employment Program 40 = Reconnect Program 41 = Sexual Abuse Counselling and Prevention Program (SACPP) 42 = Social Support Programs 43 = Supported Residential Service (SRS) 44 = Tasmanian Aboriginal Centre (TAC) 45 = Victim's Assistance Program Select "Data Element Number" in the "Data Element" field Enter '741' in the "Data Element" field and select "(741) Service Type (FHIR)" Click [Print Dictionary]. Validate the following codes are displayed: 1 = Adoption/Permanent Care Info/Support 2 = Aged Care Assessment 3 = Aged Care Information/Referral 4 = Aged Residential Care 5 = Case Management for Older Persons 6 = Delivered Meals (Meals On Wheels) 7 = Friendly Visiting 8 = Home Care/Housekeeping Assistance 9 = Home Maintenance and Repair 10 = Personal Alarms/Alerts 11 = Personal Care for Older Persons 12 = Planned Activity Groups 13 = Acupuncture 14 = Alexander Technique Therapy 15 = Aromatherapy 16 = Biorhythm Services 17 = Bowen Therapy 18 = Chinese Herbal Medicine 19 = Feldenkrais 20 = Homoeopathy 21 = Hydrotherapy 22 = Hypnotherapy 23 = Kinesiology 24 = Magnetic Therapy 25 = Massage Therapy 26 = Meditation 27 = Myotherapy 28 = Naturopathy 29 = Reflexology 30 = Reiki 31 = Relaxation Therapy 32 = Shiatsu 33 = Western Herbal Medicine 34 = Family Day care 35 = Holiday Programs 36 = Kindergarten Inclusion Support 37 = Kindergarten/Preschool 38 = Long Day Child Care 39 = Occasional Child Care 40 = Outside School Hours Care 41 = Children's Play Programs 42 = Parenting/Family Support/Education 43 = Playgroup 44 = School Nursing 45 = Toy Library 46 = Child Protection/Child Abuse Report 47 = Foster Care 48 = Residential/Out-of-Home Care 49 = Support - Young People Leaving Care 50 = Audiology 51 = Blood Donation 52 = Chiropractic 53 = Dietetics 54 = Family Planning 55 = Health Advocacy/Liaison Service 56 = Health Information/Referral Click [Close Form]	Topics • Dictionary • NX
Update 111 Summary \| Details Select reports are modified to prevent overlapping data displays. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Claim Follow-Up Productivity Report Client Ledger Unbilled Services Report Service Fee Definition Report Scenario 1: 'Claim Follow-Up Productivity' Report Steps Open the "Claim Follow-Up Productivity Report" form. Set the "Summary or Detail Report" field to "Detail Report". Leave the "User" field blank. This will pick up all rows for the report. Enter the "Start Date" and "End Date". Process the report. Validate the 'Guarantor' name field does not overlap with the 'Follow-Up Note Entry Date' field. Validate the 'Follow-Up Note' field displays text as entered in the 'AR Console'. Click [Close Report]. Return to the form. Click [Close form]. Scenario 2: 'Client Ledger' report - validate fields have no overlaps. Specific Setup: Client with a Guarantor and Services filed. Steps Open the 'Client Ledger' report from 'Client Ledger Avatar PM / Billing / Remittance Processing'. Select a client in the 'Client ID' field. The selected client should have a guarantor assigned and several services filed. Select 'All Episodes' in the 'Claim/Episode/All Episodes' field. Select 'Crystal' in the 'Ledger Type' field. Set the 'From Date' to a date when the services were rendered. Set the 'To Date' to a date through which services were rendered. Click [Process]. Review the report and verify the following: 'Service Description' field does not overlap with 'Units' field. 'Guarantor' field does not overlap with 'Guarantor Liability'. Close the report. Scenario 3: 'Unbilled Services Report' - validation no fields overlap. Steps Open the 'Unbilled Services Report'. Set 'Service Start Date' to any date where services were rendered. Set 'Service End Date' to any date to include services. Select 'All' in the 'Financial Class(es)' field. Select 'All' in the 'Program(s)' field. Select 'All' in the 'Service Status' field. Select 'No' in the 'Include 0 Liability' field. Click [Process]. Review the report and note the following: 'Guarantor' field data does not overlap with the 'FE Expired?' field. A long Guarantor name wraps to prevent overlapping other fields. Close the report. Close the form. Scenario 4: Service Fee/Cross Reference Definition Report - field validation Steps Open the 'Service Fee/Cross Reference Maintenance' form. Click [Service Fee/Cross Reference Definition Report]. Validate 'Practitioner' field does not overlap the 'Location' field. Validate 'Location' field does not overlap the 'Program' field. Validate 'Program' field does not overlap the 'Duration' field. Click [Close Report]. Click [Close Form].	Topics • Client Ledger • NX • Service Fee/Cross Reference Maintenance
Update 112 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: Delete Last Practitioner Termination Date Practitioner Termination CareFabric Monitor Scenario 1: Delete Last Practitioner Termination Date - Validate form functionality Specific Setup: A practitioner has been terminated in the 'Practitioner Termination' form (Practitioner A). Steps Access the 'Delete Last Practitioner Termination Date' form for "Practitioner A". Validate the 'Termination Date' field contains the termination date. Click [Submit]. Validate a message is displayed stating: Are you sure you want to delete termination date ##/##/#### for practitioner "Practitioner A". Click [Yes]. Access the 'Practitioner Termination' form for "Practitioner A". Validate the 'Termination Date' field does not contain a value. Validate the 'Reason For Termination' field does not contain a value. Close the form. Scenario 2: Delete Last Practitioner Termination Date - Validate the 'ProviderUpdated' SDK event Specific Setup: An active practitioner is defined that has hours for scheduling in the 'Staff Members Hours and Exceptions' form (Practitioner A). Steps Access the 'Practitioner Termination' form for "Practitioner A". Enter the desired date in the 'Termination Date' field. Populate any other desired fields. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "ProviderUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "ProviderUpdated" event triggered from the 'Practitioner Termination' form. Click [Click To View Record]. Validate the 'isActive' field contains "false". Close the report and the form. Access the 'Delete Last Practitioner Termination' form for "Practitioner A". Validate the 'Termination Date' field contains the termination date. Click [Submit]. Validate a message is displayed stating: Are you sure you want to delete termination date ##/##/#### for practitioner "Practitioner A". Click [Yes]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "ProviderUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "ProviderUpdated" event triggered from the 'Delete Last Practitioner Termination' form. Click [Click To View Record]. Validate the 'isActive' field contains "true". Close the report and the form. Scenario 3: Delete Last Practitioner Termination Date - Validate the 'StaffMemberUpdated' SDK event Specific Setup: An active practitioner is defined in 'Practitioner Enrollment' (Practitioner A). Steps Access the 'Practitioner Termination' form for "Practitioner A". Enter the desired date in the 'Termination Date' field. Populate any other desired fields. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "StaffMemberUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "StaffMemberUpdated" event triggered from the 'Practitioner Termination' form. Click [Click To View Record]. Validate the 'terminatedDate' field contains the 'Termination Date' filed. Close the report and the form. Access the 'Delete Last Practitioner Termination' form for "Practitioner A". Validate the 'Termination Date' field contains the termination date. Click [Submit]. Validate a message is displayed stating: Are you sure you want to delete termination date ##/##/#### for practitioner "Practitioner A". Click [Yes]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "StaffMemberUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "StaffMemberUpdated" event triggered from the 'Delete Last Practitioner Termination' form. Click [Click To View Record]. Validate the 'terminatedDate' field contains "null". Close the report and the form. Scenario 4: Delete Last Practitioner Termination Date - Validate the 'EvvResourceUpdated' SDK event Specific Setup: Avatar is configured to integrate with Mobile CareGiver+. Please note: This must be done by a Netsmart Representative. One or more program(s) is defined with a value populated in the 'EVV Provider Organization ID' field in the 'Program Maintenance' form. A service code must be defined that has "Yes" selected in the 'Does This Service Require Electronic Visit Verification' field in the 'Service Codes' form and must be assigned to "Program A". An active practitioner is defined in 'Practitioner Enrollment' with the following on file: 'Name', 'Date Of Birth', 'Cellular Telephone', 'Staff EVV ID', 'Email Address', 'Staff EVV Type'. Steps Access the 'Practitioner Termination' form for "Practitioner A". Enter the desired date in the 'Termination Date' field. Populate any other desired fields. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "EvvResourceUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "EvvResourceUpdated" event triggered from the 'Practitioner Termination' form. Click [Click To View Record]. Validate the 'isActive' field contains "false". Close the report and the form. Access the 'Delete Last Practitioner Termination' form for "Practitioner A". Validate the 'Termination Date' field contains the termination date. Click [Submit]. Validate a message is displayed stating: Are you sure you want to delete termination date ##/##/#### for practitioner "Practitioner A". Click [Yes]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Search for and select "EvvResourceUpdated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' contains a "EvvResourceUpdated" event triggered from the 'Delete Last Practitioner Termination' form. Click [Click To View Record]. Validate the 'isActive' field contains "true". Close the report and the form.	Topics • CareFabric • Electronic Visit Verification • Practitioner
Update 113 Summary \| Details PM UTC functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Enrollment Admission Client Charge Input Client Ledger Scenario 1: Validating Practitioner Enrollment with UTC Enabled - data entry time after midnight Specific Setup: The system must be configured to use UTC. Data entry needs to occur after midnight. A practitioner must be enrolled in the system. Steps Open the "Practitioner Enrollment" form. Select the practitioner from setup and update their enrollment. Click "Submit" to file the data. Using the preferred method to validate SQL tables, validate the following columns exist in the SQL table SYSTEM.sfaff_category_history: data_entry_offset (e.g -4), data_entry_time_j (e.g. 0:02:12), data_entry_timezone_info_all (e.g. EDT;Eastern Daylight Time;-0400), data_entry_timezone_short (e.g EDT), data_entry_utc (e.g. 9/21/2022 4:02). Scenario 2: Validating Practitioner Enrollment with UTC disabled - data entry time after midnight Specific Setup: Data entry needs to occur after midnight. A practitioner must be enrolled in the system. Steps Open the "Practitioner Enrollment" form. Select the practitioner from setup and update their enrollment. Click "Submit" to file the data. Using the preferred method to validate SQL tables, validate the following columns do not exist in the SQL table SYSTEM.sfaff_category_history: data_entry_offset, data_entry_time_j, data_entry_timezone_info_all, data_entry_timezone_short, data_entry_utc. Using the preferred method to validate SQL tables, validate the value in the data_entry_time column in the SYSTEM.staff_category_history table appropriately reflects the time of data entry, which would be after midnight. Scenario 3: Validating Client Charge Input with UTC enabled - data entry after midnight Specific Setup: The system must be configured to use UTC. Data entry needs to occur after midnight. Admit a new client or select an existing client for the test client. Steps Open the "Client Charge Input" form. Enter a service charge for the test client. Using the "Client Ledger" form, validate the service was generated. Using the preferred method to validate SQL tables, validate the following columns in the SYSTEM.billing_tx_history table: data_entry_offset (e.g. -4), data _entry_time_j (e.g. 0:02:04), data_entry_timezone_info_all (e.g. EDT;Eastern Daylight Time;-0400), data_entry_timezone_short (e.g. EDT), data_entry_utc (e.g. 9/21/2022 4:02). Using the preferred method to validate SQL tables, validate the data_entry_time column in the SYSTEM.billing_tx_history table:reflects the time of service entry after midnight. Scenario 4: Validating Client Charge Input with UTC disabled - data entry after midnight Specific Setup: Data entry needs to occur after midnight. Admit a new client or select an existing client for the test client. Steps Open the "Client Charge Input" form. Enter a service charge for the test client. Using the "Client Ledger" form, validate the service was generated. Using the preferred method to validate SQL tables, validate the following columns don't exist in the SYSTEM.billing_tx_history table: data_entry_offset, data _entry_time_j, data_entry_timezone_info_all, data_entry_timezone_short, data_entry_utc. Using the preferred method to validate SQL tables, validate the data_entry_time column in the SYSTEM.billing_tx_history table:reflects the time of service entry after midnight. Scenario 5: Validating Practitioner Enrollment with UTC Enabled Specific Setup: The system must be configured to use UTC. A practitioner must be enrolled in the system. Steps Open the "Practitioner Enrollment" form. Select the practitioner from setup and update their enrollment. Click "Submit" to file the data. Using the preferred method to validate SQL tables, validate the following columns exist in the SQL table SYSTEM.sfaff_category_history: data_entry_offset (e.g -4), data_entry_time_j (e.g. 12:26:13), data_entry_timezone_info_all (e.g. EDT;Eastern Daylight Time;-0400), data_entry_timezone_short (e.g EDT), data_entry_utc (e.g. 9/21/2022 16:26). Using the preferred method to validate SQL tables, validate the data_entry_time (e.g. 12:26 PM) in the SQL table SYSTEM.sfaff_category_history appropriately reflects the time of data entry. Scenario 6: Validating Practitioner Enrollment with UTC disabled Specific Setup: A practitioner must be enrolled in the system. Steps Open the "Practitioner Enrollment" form. Select the practitioner from setup and update their enrollment. Click "Submit" to file the data. Using the preferred method to validate SQL tables, validate the following columns don't exist in the SQL table SYSTEM.sfaff_category_history: data_entry_offset, data_entry_time_j, data_entry_timezone_info_all, data_entry_timezone_short), data_entry_utc. Using the preferred method to validate SQL tables, validate the data_entry_time (e.g. 12:26 PM) in the SQL table SYSTEM.sfaff_category_history appropriately reflects the time of data entry. Scenario 7: Validating Client Charge Input with UTC enabled Specific Setup: The system must be configured to use UTC. Admit a new client or select an existing client for the test client. Steps Open the "Client Charge Input" form. Enter a service charge for the test client. Using the "Client Ledger" form, validate the service was generated. Using the preferred method to validate SQL tables, validate the following columns in the SYSTEM.billing_tx_history table: data_entry_offset (e.g. -4), data _entry_time_j (e.g. 12:26:13), data_entry_timezone_info_all (e.g. EDT;Eastern Daylight Time;-0400), data_entry_timezone_short (e.g. EDT), data_entry_utc (e.g. 09/20/2022 16:26) Using the preferred method to validate SQL tables, validate the data_entry_time column in the SYSTEM.billing_tx_history table:reflects the time of service entry. Scenario 8: Validating Client Charge Input with UTC disabled Specific Setup: Admit a new client or select an existing client for the test client. Steps Open the "Client Charge Input" form. Enter a service charge for the test client. Using the "Client Ledger" form, validate the service was generated. Using the preferred method to validate SQL tables, validate the following columns don't exist in the SYSTEM.billing_tx_history table: data_entry_offset, data _entry_time_j, data_entry_timezone_info_all, data_entry_timezone_short, data_entry_utc. Using the preferred method to validate SQL tables, validate the data_entry_time column in the SYSTEM.billing_tx_history table:reflects the time of service entry.	Topics • Client Charge Input • NX • Practitioner