Skip to main content

Avatar PM 2023 Monthly Release 2023.02.02 Acceptance Tests

  1. Last updated
  2. Save as PDF
Update 58 Summary | Details
Avatar PM 'Benefit Enrollment and Maintenance (834)' Coverage Date Information
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Benefit Enrollment and Maintenance (834)
  • Benefit Enrollment and Maintenance (834) Compile/Post Report
Scenario 1: 'Benefit Enrollment and Maintenance (834)' - Verification of Effective Date/Expiration Date Information
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
  • 834 Benefit Enrollment Maintenance eligibility file for loading/compilation/posting in Avatar PM system, including one or more valid health coverage details
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form.
  2. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded - selecting inbound 834 file including one or valid more health coverage details.
  3. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation.
  4. Click 'Process File' button to compile inbound 834 file data.
  5. Select 'Run Report' in 'Options' field, and select compiled 834 file for report.
  6. Click 'Process File' button to open 834 inbound compile report.
  7. In 834 inbound compile report - ensure that in case where 2300-DTP Expiration Date is included without 2300-DTP Effective Date in health coverage detail and previously posted 834 coverage information for same Unique ID/Policy Number and Coverage Expiration Date exist in Avatar PM (existing information in SQL table 'SYSTEM.eligibility_dependent_cov'), inbound 834 health care coverage entry is successfully compiled.
  8. Note - 'Coverage Effective Date' and/or 'Coverage Expiration Date' values may also be determined by Avatar PM Guarantor/Payor in cases where not directly present in 834 file health coverage information (via 'Default Benefit Effective Date (2300-DTP-03)' and/or 'Default Expiration Date (2300-DTP-03)' fields in Avatar PM 'Guarantors/Payors' form, '270 / 271 / 834' section)
  9. In 834 inbound compile report - ensure that in case where 2300-DTP Effective Date and 2300-DTP Expiration Date are included for same Unique ID/Policy Number under separate/different 2000 loop sets, inbound 834 health care coverage entry is successfully compiled (using 2300-DTP Effective Date and 2300-DTP Expiration Date values from file where present).
  10. Select 'Post File' in 'Options' field, and select compiled 834 file for posting.
  11. Click 'Process File' button to post inbound 834 file data.
  12. Open Crystal Reports or other SQL reporting tool.
  13. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that 'eligibility_eff_date' and 'eligibility_exp_date' values from 834 file health coverage information (or defaulted by Avatar PM system per Guarantor configurations) are present for eligibility data row(s) created via 834 inbound file posting.
Avatar PM 'Use 2300-DTP with 303 Qualifier as Effective Date' Registry Setting
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Benefit Enrollment and Maintenance (834)
  • Benefit Enrollment and Maintenance (834) Compile/Post Report
Scenario 1: 'Benefit Enrollment and Maintenance (834)' - Verification of 'Use 2300-DTP with 303 Qualifier as Effective Date' Registry Setting
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
  • Avatar PM Registry Setting 'Use 2300-DTP with 303 Qualifier as Effective Date' must be enabled
  • 834 Benefit Enrollment Maintenance eligibility file for loading/compilation/posting in Avatar PM system, including one or more health coverage details where 2300-DTP*348 (Benefit Begin Date) is not included and 2300-DTP*303 (Maintenance Effective Date) is included
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form.
  2. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded - selecting inbound 834 file including one or more health coverage details where 2300-DTP*348 (Benefit Begin Date) is not included and 2300-DTP*303 (Maintenance Effective Date) is included.
  3. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation.
  4. Click 'Process File' button to compile inbound 834 file data.
  5. Select 'Run Report' in 'Options' field, and select compiled 834 file for report.
  6. Click 'Process File' button to open 834 inbound compile report.
  7. In 834 inbound compile report - ensure that in case where 2300-DTP*348 (Benefit Begin Date) is not included and 2300-DTP*303 (Maintenance Effective Date) is included in health coverage detail, 'Coverage Period Effective Date' (under 'Compiled Data' section of report) is defined with Maintenance Effective Date 2300-DTP*303 value from 834 information; ensure that where 2300-DTP*348 (Benefit Begin Date) is included in 834 health coverage detail, this value is used as 'Coverage Period Effective Date' over Maintenance Effective Date 2300-DTP*303 value.
  8. Select 'Post File' in 'Options' field, and select compiled 834 file for posting.
  9. Click 'Process File' button to post inbound 834 file data.
  10. Open Crystal Reports or other SQL reporting tool.
  11. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that 'eligibility_eff_date' value as determined by either 2300-DTP*303 (Maintenance Effective Date) or 2300-DTP*348 (Benefit Begin Date) value in health coverage detail is present for eligibility data row(s) created via 834 inbound file posting.
Scenario 2: Avatar PM Registry Settings - Verification of 'Use 2300-DTP with 303 Qualifier as Effective Date' Registry Setting
Steps
  1. Open 'Registry Settings' form.
  2. Enter search value 'Use 2300-DTP with 303 Qualifier as Effective Date' and click 'View Registry Settings' button.
  3. Ensure Registry Setting 'Use 2300-DTP with 303 Qualifier as Effective Date' is returned (under 'Avatar PM -> Billing -> Electronic Submissions -> Benefit Enrollment and Maintenance (834)' path).
  4. Ensure 'Registry Setting Details' field contains the following explanation text:

"When set to 'Y' if a date is found in the 2300-DTP segment with a qualifier of 303 and a date is not found in the 2300-DTP segment with a qualifier of 348 the date with qualifier of 303 will be used as the effective date.


Select 'N' for the default functionality."

'Default Benefit Effective Date (2300-DTP-03)' Function For 834 Processing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Benefit Enrollment and Maintenance (834)
  • Benefit Enrollment and Maintenance (834) Compile/Post Report
Scenario 1: 'Benefit Enrollment and Maintenance (834)' - Verification of 'Default Benefit Effective Date (2300-DTP-03)' Guarantor/Payor Setting
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
  • Avatar PM Registry Setting 'Use 2300-DTP with 303 Qualifier as Effective Date' may optionally be enabled/disabled
  • 'Beginning of the Expiration Date Month' must be selected/enabled in the 'Default Benefit Effective Date (2300-DTP-03)' field for applicable 834 Guarantor (via Avatar PM 'Guarantors/Payors' form, '270 / 271 / 834' section)
  • 834 Benefit Enrollment Maintenance eligibility file for loading/compilation/posting in Avatar PM system, including one or more health coverage details where 2300-DTP*348 (Benefit Begin Date) and/or 2300-DTP*303 (Maintenance Effective Date) are not included
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form.
  2. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded - selecting inbound 834 file including one or more health coverage detail where 2300-DTP*348 (Benefit Begin Date) and/or 2300-DTP*303 (Maintenance Effective Date) are not included.
  3. Note - Use of 2300-DTP*303 (Maintenance Effective Date) to determine Coverage Period Effective Date where included/not included is dependent on Avatar PM Registry Setting 'Use 2300-DTP with 303 Qualifier as Effective Date'
  4. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation.
  5. Click 'Process File' button to compile inbound 834 file data.
  6. Select 'Run Report' in 'Options' field, and select compiled 834 file for report.
  7. Click 'Process File' button to open 834 inbound compile report.
  8. In 834 inbound compile report - ensure that in case where 2300-DTP*348 (Benefit Begin Date) and/or 2300-DTP*303 (Maintenance Effective Date) are not included in health coverage detail, 'Coverage Period Effective Date' (under 'Compiled Data' section of report) is defined with beginning/first date of month from Coverage Period Expiration Date/Benefit End Date 2300-DTP*349 value from 834 information; ensure that where 2300-DTP*348 (Benefit Begin Date) and/or 2300-DTP*303 (Maintenance Effective Date) is/are included in 834 health coverage detail, this value is used as 'Coverage Period Effective Date' over 'Beginning of the Expiration Date Month' defaulting value.
  9. Examples:
  10. If 834 Coverage Information includes Coverage Expiration Date 2300-DTP*349 value '06/30/2023', '06/15/2023' or '06/01/2023'
  11. 'Coverage Period Effective Date' value under 'Default Benefit Effective Date (2300-DTP-03)'/'Beginning of the Expiration Date Month' function set to '06/01/2023'
  12. If 834 Coverage Information includes Coverage Expiration Date 2300-DTP*349 value '04/30/2023', '04/25/2023' or '04/02/2023'
  13. 'Coverage Period Effective Date' value under 'Default Benefit Effective Date (2300-DTP-03)'/'Beginning of the Expiration Date Month' function set to '04/01/2023'
  14. Select 'Post File' in 'Options' field, and select compiled 834 file for posting.
  15. Click 'Process File' button to post inbound 834 file data.
  16. Open Crystal Reports or other SQL reporting tool.
  17. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that 'eligibility_eff_date' value as determined by 'Default Benefit Effective Date (2300-DTP-03)'/'Beginning of the Expiration Date Month' function (or 2300-DTP*348 Benefit Begin Date / 2300-DTP*303 Maintenance Effective Date information) in health coverage detail is present for eligibility data row(s) created via 834 inbound file posting.
Scenario 2: 'Guarantors/Payors' - Form Verification
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
Steps
  1. Open the Avatar PM 'Guarantors/Payors' form.
  2. Select Add or Edit action in 'Add New or Edit Existing Guarantor' field.
  3. Enter new (or select existing) Guarantor Code.
  4. Complete all required/desired fields in main section of 'Guarantors/Payors' form.
  5. Navigate to '270 / 271 / 834' section of 'Guarantors/Payors' form.
  6. Ensure that the 'Default Benefit Effective Date (2300-DTP-03)' field is available in form, with 'Beginning of the Expiration Date Month' checkbox/selection available.
  7. If 'Beginning of the Expiration Date Month' is selected in this field, 834 Benefit Enrollment and Maintenance compilation/posting will use beginning/first day of Coverage Expiration Date month value from health coverage information detail as Coverage Effective Date where 2300-DTP*348 (Benefit Begin Date) and/or 2300-DTP*303 (Maintenance Effective Date) is/are not included.
  8. Select 'Beginning of the Expiration Date Month' value in 'Default Benefit Effective Date (2300-DTP-03)' field (and any other desired fields in '270 / 271 / 834' section of form).
  9. Navigate to main section of 'Guarantors/Payors' form.
  10. Click 'File' button to save/file Guarantor/Payor definition information.
  11. Select 'Edit' action and select previously filed Guarantor Code.
  12. Navigate to '270 / 271 / 834' section of 'Guarantors/Payors' form.
  13. Ensure that previously selected/filed value for 'Default Benefit Effective Date (2300-DTP-03)' field is present/selected in form.
Avatar PM 'Plan Coverage Description (2300-HD-04)' Registry Setting
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Benefit Enrollment and Maintenance (834)
  • Benefit Enrollment and Maintenance (834) Compile/Post Report
Scenario 1: 'Benefit Enrollment and Maintenance (834)' - Verification of SQL Data for Posted 834 File
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
  • 834 Benefit Enrollment Maintenance eligibility file for loading/compilation/posting in Avatar PM system
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form.
  2. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded.
  3. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation.
  4. Click 'Process File' button to compile inbound 834 file data.
  5. Select 'Run Report' in 'Options' field, and select compiled 834 file for report.
  6. Click 'Process File' button to open 834 inbound compile report.
  7. In 834 inbound compile report, ensure that one or more coverage periods from file are successfully compiled.
  8. Select 'Post File' in 'Options' field, and select compiled 834 file for posting.
  9. Click 'Process File' button to post inbound 834 file data.
  10. Close 'Benefit Enrollment and Maintenance (834)' form.
  11. Open Crystal Reports or other SQL reporting tool.
  12. In Avatar PM SQL table 'SYSTEM.eligibility_subscriber', ensure that values for following added fields are present/populated based on 834 inbound information/values (where values present in 834 file data):
  13. 'cust_par_comm_1' / 'cust_par_comm_2' / 'cust_par_comm_3'
  14. 'cust_par_comm_qua_1_code' / 'cust_par_comm_qua_2_code' / 'cust_par_comm_qua_3_code'
  15. 'cust_parent_contact_code'
  16. 'cust_parent_id' / 'cust_parent_id_code' / 'cust_parent_id_qua_code'
  17. 'cust_parent_name_first' / 'cust_parent_name_last' / 'cust_parent_name_mid'
  18. 'cust_parent_name_pre' / 'cust_parent_name_suf'
  19. 'cust_parent_type_qua_code'
  20. 'cust_par_address' / 'cust_par_address_2'
  21. 'cust_par_city' / 'cust_par_country' / 'cust_par_coun_sub_div'
  22. 'cust_par_state' / 'cust_par_zip'
  23. 'location_qualifier' / 'location_ident'
  24. 'health_related_code'
  25. 'resp_per_address' / 'resp_per_address_2'
  26. 'resp_per_city' / 'resp_per_country' / 'resp_per_coun_sub_div'
  27. 'resp_per_state' / 'resp_per_zip'
  28. In Avatar PM SQL table 'SYSTEM.eligibility_demographics', ensure that values for following added fields are present/populated based on 834 inbound information/values (where values present in 834 file data):
  29. 'date_of_death'
  30. 'language_desc'
  31. 'language_use_indicator'
  32. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that value for following added field is present/populated based on 834 inbound information/values (where values present in 834 file data):
  33. 'reference_identification'
  34. In Avatar PM SQL table 'SYSTEM.eligibility_dep_cov_cob', ensure that rows are filed/present based on 834 inbound information/values from 2320 Coordination Of Benefits loop (where 2320 loop/values present in 834 file data).
  35. In Avatar PM SQL table 'SYSTEM.eligibility_dep_cov_cobre', ensure that rows are filed/present based on 834 inbound information/values from 2330 Coordination Of Benefits Related Entity loop (where 2330 loop/values present in 834 file data).
Scenario 2: 'Benefit Enrollment and Maintenance (834)' - Verification of 'Plan Coverage Description (2300-HD-04)' Registry Setting
Specific Setup:
  • Avatar PM Registry Setting 'Enable 834 Transaction Set' must be enabled
  • Avatar PM Registry Setting 'Plan Coverage Description (2300-HD-04)' must be enabled with 1000B-N1/2300-HD ('B') or 2300-HD ('Y') value
  • Examples: 'B', 'B04', 'B04-5', 'B-4' ,' Y', 'Y04', 'Y04-5', 'Y-4'
  • 'Insurer Identifier Code (1000B-N1-04)' and/or 'Plan Coverage Description (2300-HD-04)' values must be defined for applicable 834 Guarantor (via Avatar PM 'Guarantors/Payors' form, '270 / 271 / 834' section)
  • 834 Benefit Enrollment Maintenance eligibility file for loading/compilation/posting in Avatar PM system, including one or more valid health coverage details
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form.
  2. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded - selecting inbound 834 file including one or valid more health coverage details.
  3. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation.
  4. Click 'Process File' button to compile inbound 834 file data.
  5. Select 'Run Report' in 'Options' field, and select compiled 834 file for report.
  6. Click 'Process File' button to open 834 inbound compile report.
  7. In 834 inbound compile report - Where Registry Setting 'Plan Coverage Description (2300-HD-04)' is enabled with value including 'B', ensure that Guarantor/Payor applicable to inbound 834 health coverage information/details is determined by both 834 Insurer Identifier Code (1000B-N1-04) and Plan Coverage Description (2300-HD-04) values compared to 'Insurer Identifier Code (1000B-N1-04)' and 'Plan Coverage Description (2300-HD-04)' values in Avatar PM 'Guarantors/Payors' form (respectively).
  8. In case where both 834 Insurer Identifier Code (1000B-N1-04) and Plan Coverage Description (2300-HD-04) values match 'Insurer Identifier Code (1000B-N1-04)' and 'Plan Coverage Description (2300-HD-04)' values for Guarantor, ensure that Guarantor is present in 834 inbound compile/post report data (under 'Compiled Data' section of report)
  9. Note - 834 file Plan Coverage Description (2300-HD-04) values will be parsed/extracted as detailed for 'Plan Coverage Description (2300-HD-04)' Registry Setting if parsing is enabled via additional entry beyond 'B' value in Registry Setting (Ex: 'B04', 'B04-5')
  10. Note - Where Registry Setting 'Plan Coverage Description (2300-HD-04)' is enabled with value including 'B' - In case where 834 Plan Coverage Description (2300-HD-04) value matches 'Plan Coverage Description (2300-HD-04)' value for Guarantor, 834 Insurer Identifier Code (1000B-N1-04) must also match 'Insurer Identifier Code (1000B-N1-04)' value for same Guarantor for 834 compilation/posting under Guarantor
  11. In case where 834 Plan Coverage Description (2300-HD-04) value does not match to any Guarantor but 834 Insurer Identifier Code (1000B-N1-04) value matches 'Insurer Identifier Code (1000B-N1-04)' value for Guarantor, ensure that Guarantor is present in 834 inbound compile/post report data (under 'Compiled Data' section of report)
  12. In case where 834 Plan Coverage Description (2300-HD-04) value matches 'Plan Coverage Description (2300-HD-04)' value for Guarantor but 834 Insurer Identifier Code (1000B-N1-04) value does not match to Guarantor, ensure that Error Message 'Unable to determine guarantor from loop 1000B or loop 2300 information' is returned by 837 compilation/posting (under 'Errors Associated With Compilation' section of report)
  13. In case where Guarantor cannot be determined by a match to both Insurer Identifier Code (1000B-N1-04) and Plan Coverage Description (2300-HD-04) values, ensure that Error Message 'Unable to determine guarantor from loop 1000B or loop 2300 information' is returned by 837 compilation/posting (under 'Errors Associated With Compilation' section of report)
  14. In 834 inbound compile report - Where Registry Setting 'Plan Coverage Description (2300-HD-04)' is enabled with value including 'Y', ensure that Guarantor/Payor applicable to inbound 834 health coverage information/details is determined by 834 Plan Coverage Description (2300-HD-04) value compared to 'Plan Coverage Description (2300-HD-04)' value in Avatar PM 'Guarantors/Payors' form (and Guarantor is only determined by 834 Insurer Identifier Code (1000B-N1-04) value where no Plan Coverage Description (2300-HD-04) Guarantor match is found).
  15. In case where 834 Plan Coverage Description (2300-HD-04) value matches 'Plan Coverage Description (2300-HD-04)' value for Guarantor, ensure that Guarantor is present in 834 inbound compile/post report data (under 'Compiled Data' section of report)
  16. Note - 834 file Plan Coverage Description (2300-HD-04) values will be parsed/extracted as detailed for 'Plan Coverage Description (2300-HD-04)' Registry Setting if parsing is enabled via additional entry beyond 'Y' value in Registry Setting (Ex: 'Y04', 'Y04-5')
  17. Note - Where Registry Setting 'Plan Coverage Description (2300-HD-04)' is enabled with value including 'Y' - In case where 834 Plan Coverage Description (2300-HD-04) value matches 'Plan Coverage Description (2300-HD-04)' value for Guarantor, 834 Insurer Identifier Code (1000B-N1-04) is not required to match 'Insurer Identifier Code (1000B-N1-04)' value for same Guarantor
  18. In case where 834 Plan Coverage Description (2300-HD-04) value does not match to any Guarantor but 834 Insurer Identifier Code (1000B-N1-04) value matches 'Insurer Identifier Code (1000B-N1-04)' value for Guarantor, ensure that Guarantor is present in 834 inbound compile/post report data (under 'Compiled Data' section of report)
  19. In case where Guarantor cannot be determined by a match to Plan Coverage Description (2300-HD-04) and/or Insurer Identifier Code (1000B-N1-04) values, ensure that Error Message 'Unable to determine guarantor from loop 1000B or loop 2300 information' is returned by 837 compilation/posting (under 'Errors Associated With Compilation' section of report)
  20. In 834 inbound compile report - Where Registry Setting 'Plan Coverage Description (2300-HD-04)' is disabled, ensure that Guarantor/Payor applicable to inbound 834 health coverage information/details is determined by 834 Insurer Identifier Code (1000B-N1-04) value compared to 'Insurer Identifier Code (1000B-N1-04)' value in Avatar PM 'Guarantors/Payors' form.
  21. In case where Guarantor cannot be determined by a match of Insurer Identifier Code (1000B-N1-04) value, ensure that Error Message 'Unable to determine guarantor from loop 1000B information' is returned by 837 compilation/posting (under 'Errors Associated With Compilation' section of report)
  22. Select 'Post File' in 'Options' field, and select compiled 834 file for posting.
  23. Click 'Process File' button to post inbound 834 file data.
  24. Open Crystal Reports or other SQL reporting tool.
  25. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that 'GUARANTOR_ID' value as determined by Insurer Identifier Code (1000B-N1-04) and/or Plan Coverage Description (2300-HD-04) in health coverage detail is present for eligibility data row(s) created via 834 inbound file posting.
Scenario 3: Avatar PM Registry Settings - Verification of 'Plan Coverage Description (2300-HD-04)' Registry Setting
Steps
  1. Open 'Registry Settings' form.
  2. Enter search value 'Plan Coverage Description (2300-HD-04)' and click 'View Registry Settings' button.
  3. Ensure Registry Setting 'Plan Coverage Description (2300-HD-04)' is returned (under 'Avatar PM -> Billing -> Electronic Submissions -> Benefit Enrollment and Maintenance' path).
  4. Ensure 'Registry Setting Details' field contains the following explanation text:

"Selecting 'Y' will activate the following logic: A new field 'Plan Coverage Description (2300-HD-04)' will be added to the '270/271/834' tab of the 'Guarantors/Payors' form. When an 834 file is processed, the value in the Plan Coverage Description (2300-HD-04) field in the file will be compared against the value in the 'Plan Coverage Description (2300-HD-04)' field on the form to determine the eligible guarantor(s) for the specified coverage.


The above logic will compare the entire value in the Plan Coverage Description (2300-HD-04) field. To compare a specific piece of data in Plan Coverage Description (2300-HD-04) in the 834 file against the entire value of the field on the form, the registry setting value can be defined as 'Y[D]elimiter[P]iece', where 'Y' enables the logic, 'Delimiter' determines the separator character between each piece of data, and 'Piece' determines the piece of the data to examine. If the 'Delimiter' is '0' (zero), then positional logic will be used and the 'Piece' portion will be the character position(s) to use.


Example:

'Y-2' will extract the string 'BBB' from a Plan Coverage Description (2300-HD-04) value of 'AAA-BBB-CCC-DDD' and compare against the field on the form.

'Y04' will extract the character 'D' from a value of 'ABCDEF'.

'Y04-5' will extract the string 'DE' from a value of 'ABCDEF'.


Selecting 'N' disables this logic and removes the field from the form.


Note: Enabling this registry setting and specifying a value in the 'Plan Coverage Description (2300-HD-04)' field on the 'Guarantors/Payors' form will override the logic to utilize the 'Insurer Identifier Code (1000B-N1-04)' field for guarantor determination. However, the 'Insurer Identifier Code (1000B-N1-04)' will still be used to specify the guarantor for any coverage levels where the 2300-HD-04 value does not have a match on file.


Note: Replace 'Y' with 'B' to determine guarantor using both 'Plan Coverage Description (2300-HD-04)' and 'Insurer Identifier Code (1000B-N1-04)'."
Topics
• Benefit Enrollment and Maintenance (834) • Registry Settings • NX • Guarantor/Payors
Update 85 Summary | Details
Client Ledger - Post Contractual Adjustments
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • System Task Scheduler
  • Client Ledger
  • Financial Eligibility
  • Diagnosis
  • Admission (Outpatient)
  • Client Charge Input
  • Quick Billing Rule Definition
  • Quick Billing
  • Contractual Allowance (Inpatient)
  • Change MR#
  • Delete Service
  • Delete Last Movement
Scenario 1: Quick Billing Post Contractual Adjustments Task - System Task Scheduler
Specific Setup:
  • Registry Setting:
  • The 'Enable New Quick Billing Format' registry setting is set to 'Y'.
  • Guarantors/Payors:
  • A guarantor is added or edited such that it is defined as a 'Contract' guarantor in the 'Guarantor Nature' field.
  • Service Codes:
  • Add or edit new professional services that are defined as 'Per Diem' services. (Please note: Any inpatient services processed for Contractual Adjustment Posting that are not defined as 'Per Diem' will have their charges completely written off, not just the charge amount over the per diem amount).
  • Admission:
  • Two test clients are admitted to outpatient programs.
  • Financial Eligibility:
  • Assign contract guarantor to the test client.
  • Make sure there is a per diem rate defined for the benefit plan and the benefit plan covers the service codes from above step (Insurance Charge Category).
  • Client Charge Input:
  • Rendered 6 services for the test clients in the same month.
  • Client Ledger:
  • Verify all the charges distributed to the contract guarantor identified above.
  • Quick Billing Rule Definition:
  • At least two quick billing rules defined in the system.
  • Quick Billing Group Definition:
  • A group definition is created that includes the quick billing rules defined above.
  • The 'Add Rule Group To Scheduler' is set to "Yes".
  • The 'Claim From Date For Scheduled Batch' and 'Claim Through Date' are populated correctly.
  • Select the following tasks in 'Tasks to Execute': 'Create Batch', 'Close Charges', 'Generate Bills', 'Create Claims', and 'Post Contractual Adjustments'.
Steps
  1. Open the "System Task Scheduler" form:
  2. In the "Schedules" field, select the quick billing group definition task created in the 'Quick Billing Group Definition' from the list.
  3. Select a recurrence type pattern from the "Recurrence Pattern" field. For example "Daily".
  4. Populate the "Task Occurrence Sequence". For example "1".
  5. Populate the "Start by" field.
  6. Populate the "Start Time" field.
  7. Click [Schedule Task]
  8. Wait until after the date and time that the task is scheduled to execute.
  9. Open the 'Client Ledger' form:
  10. Select desired client.
  11. Select "All Episode" from the 'Claim/Episode/All Episode' field.
  12. Select "Simple" from the 'Ledger Type' field.
  13. Select desired date in the 'From Date' and 'To Date' fields to include the service date range for the client.
  14. Click [Process].
  15. Verify the services selected by the quick billing group task closed, claimed and the contractual adjustments are posted correctly.
Scenario 2: Quick Billing - Execute quick billing group rule - Validating 'Post Contractual Adjustments' for the Inpatient clients - After Client Merge
Specific Setup:
  • Service Codes:
  • Add or edit service codes that are defined as 'Per Diem' services. (Please note: Any inpatient services processed for Contractual Adjustment Posting that are not defined as 'Per Diem' will have their charges completely written off, not just the charge amount over the per diem amount). Note the 'Insurance Charge Category'.
  • Service Fee/Cross Reference Maintenance:
  • Service fees are created for the service codes.
  • Note: The fee must be greater than the per diem amount/percentage defined in the benefit plan.
  • Benefit Plan:
  • A per diem rate is defined for the benefit plan that is less than the Service Fee/Cross Reference Maintenance Fee.
  • Guarantors/Payors:
  • A guarantor is added or edited that it is defined as a 'Contract' guarantor in the 'Guarantor Nature' field.
  • The above 'Benefit Plan' is the default plan.
  • 'Contractual Guarantor Information' section:
  • 'Contractual Allowance By Batch' option is selected for the 'Does This Guarantor Use Contractual Allowance By Batch Or Through Liability Distribution' field.
  • Required fields are populated as desired.
  • Admission:
  • Two new test clients are admitted to inpatient and outpatient programs. The client admitted in the inpatient program will be used as a source client and the client admitted in the outpatient program will be used as a target client. Note the client ids.
  • Financial Eligibility:
  • Assign contract guarantor to the test clients' inpatient episodes.
  • Make sure there is a per diem rate defined for the benefit plan and the benefit plan covers the service codes from above step (Insurance Charge Category).
  • Client Charge Input:
  • Rendered services for the test clients in the inpatient programs in same month.
  • Client Ledger:
  • Verify all the charges distributed to the contract guarantor identified above.
  • Quick Billing Rule Definition:
  • Create a rule for the Non-contract guarantor and outpatient services. Note the rule description.
  • Create a rule for the contract guarantor and inpatient services. Note the rule description.
  • A group definition is created that includes the quick billing rules defined above.
  • Select 'No' in Add Rule Group To Scheduler'.
Steps
  1. Open the 'Client Merge' form.
  2. Select desired client as a source client.
  3. Select desired client as a target client.
  4. Populate all other required fields.
  5. Verify the source client merged in to the target client successfully.
  6. Open the 'Client Ledger' for the target client.
  7. Verify all the merged services distributed correctly to the correct guarantor.
  8. Open the ‘Quick Billing’ form.
  9. Set the field ‘Add New Or Edit Existing Quick Billing Batch’ to "Add New".
  10. Set the field ‘First Date Of Service To Include’ to desired date based on the services rendered to the client in the setup section.
  11. Set the field ‘Last Date Of Service To Include’ to desired date based on the services rendered to the client in the setup section.
  12. Set the field ‘Billing Rule Group To Execute’ to desired rule group created in the setup section.
  13. Verify that "Create Batch, Close Charges, Generate Bills, Create Claims, Post Contractual Adjustments" auto populated in the ‘Quick Billing Tasks To Execute’ field as these tasks are selected in the quick billing rule definition.
  14. Set the field ‘Date Of Claim’ to desired date.
  15. Submit the form.
  16. Verify the 'Compile Complete' message. The message also contains the quick billing batch number, Interim Billing Batch number and contractual adjustment posted notification.
  17. Click [OK].
  18. Click [NO] to 'Form Return' message.
  19. Open the 'Client Ledger' form.
  20. Select desired client.
  21. Select 'All Episode' from the 'Claim/Episode/All Episode' field.
  22. Select 'Simple' from the 'Ledger Type' field.
  23. Select desired date in the 'From Date' and 'To Date' fields to include the service date range for the client.
  24. Click [Process].
  25. Verify the services selected by the quick billing group closed, claimed and the contractual adjustments are posted.
Scenario 3: Contractual Allowance (Inpatient) - Post Contractual adjustments for the client - After Change MR#
Specific Setup:
  • Service Codes:
  • Add or edit service codes that are defined as 'Per Diem' services. (Please note: Any inpatient services processed for Contractual Adjustment Posting that are not defined as 'Per Diem' will have their charges completely written off, not just the charge amount over the per diem amount). Note the service code and 'Insurance Charge Category'.
  • Service Fee/Cross Reference Maintenance:
  • Service fees are created for the service codes.
  • Note: The fee must be greater than the deductible amount defined in the benefit plan.
  • Benefit Plan:
  • A per diem rate is defined for the benefit plan that is less than the Service Fee/Cross Reference Maintenance Fee.
  • Guarantors/Payors:
  • A guarantor is added or edited that it is defined as a 'Contract' guarantor in the 'Guarantor Nature' field.
  • The above 'Benefit Plan' is the default plan.
  • 'Contractual Guarantor Information' section:
  • 'Contractual Allowance By Batch' option is selected for the 'Does This Guarantor Use Contractual Allowance By Batch Or Through Liability Distribution' field.
  • Required fields are populated as desired.
  • Admission:
  • A test client is admitted to inpatient program. Note the client id.
  • Financial Eligibility:
  • Assign contract guarantor to the test clients' inpatient episodes.
  • Make sure there is a per diem rate defined for the benefit plan and the benefit plan covers the service codes from above step (Insurance Charge Category).
  • Client Charge Input:
  • Rendered services for the test clients using the service code identified above.
  • Client Ledger:
  • Verify all the charges distributed to the contract guarantor identified above.
Steps
  1. Open the 'Contractual Allowance (Inpatient)' form.
  2. Select 'Compile' for the 'Compile, View or Post' field.
  3. Enter the month and year for the services rendered to the client.
  4. Fill out the remaining required fields.
  5. Click [Process].
  6. Verify the services displayed correctly in the report with the expected contractual adjustments.
  7. Select 'View' from the 'Compile, View or Post' field.
  8. Click [Process].
  9. Verify the services to be posted displayed correctly in the report with the expected contractual adjustments.
  10. Open the 'Change MR#' form.
  11. Select a client set up in the setup section.
  12. Click [Assign MR#].
  13. Verify the 'New Client ID#' field contains different id than the previous one. Note the client id.
  14. Click [Submit].
  15. Verify the form submits successfully.
  16. Open the 'Contractual Allowance (Inpatient)' form.
  17. Select 'Post' from the 'Compile, View or Post' field.
  18. Set the 'Month/Year To Run Report For' field to desired month and year such that it covers the services for the client.
  19. Enter the 'Posting Date'.
  20. Select all other required fields.
  21. Click [Process].
  22. Verify the services posted displayed correctly in the report with the expected contractual adjustments for the new client.
  23. Open 'Client Ledger' form.
  24. Verify the contractual adjustments are correctly posted for the services that are included in the batch.
  25. Close the form.
Scenario 4: Contractual Allowance (Inpatient) - Post Contractual adjustments for the client - After 'Client Delete'
Specific Setup:
  • Service Codes:
  • Add or edit service codes that are defined as 'Per Diem' services. (Please note: Any inpatient services processed for Contractual Adjustment Posting that are not defined as 'Per Diem' will have their charges completely written off, not just the charge amount over the per diem amount). Note the service code and 'Insurance Charge Category'.
  • Service Fee/Cross Reference Maintenance:
  • Service fees are created for the service codes.
  • Note: The fee must be greater than the deductible amount defined in the benefit plan.
  • Benefit Plan:
  • A per diem rate is defined for the benefit plan that is less than the Service Fee/Cross Reference Maintenance Fee.
  • Guarantors/Payors:
  • A guarantor is added or edited that it is defined as a 'Contract' guarantor in the 'Guarantor Nature' field.
  • The above 'Benefit Plan' is the default plan.
  • 'Contractual Guarantor Information' section:
  • 'Contractual Allowance By Batch' option is selected for the 'Does This Guarantor Use Contractual Allowance By Batch Or Through Liability Distribution' field.
  • Required fields are populated as desired.
  • Admission:
  • 1-2 test clients are admitted to inpatient program. Note the client ids.
  • Financial Eligibility:
  • Assign contract guarantor to the test clients' inpatient episodes.
  • Make sure there is a per diem rate defined for the benefit plan and the benefit plan covers the service codes from above step (Insurance Charge Category).
  • Client Charge Input:
  • Rendered services for the test clients using the service code identified above.
  • Client Ledger:
  • Verify all the charges distributed to the contract guarantor identified above.
Steps
  1. Open the 'Contractual Allowance (Inpatient)' form.
  2. Select 'Compile' for the 'Compile, View or Post' field.
  3. Enter the month and year for the services rendered to the client.
  4. Fill out the remaining required fields.
  5. Click [Process].
  6. Verify the services displayed correctly in the report with the expected contractual adjustments.
  7. Select 'View' from the 'Compile, View or Post' field.
  8. Click [Process].
  9. Verify the services to be posted displayed correctly in the report with the expected contractual adjustments.
  10. Delete all the services rendered to the client.
  11. Delete all the movements using 'Delete Last Movement' form.
  12. Open the 'Client Delete' form.
  13. Delete the client.
  14. Open the 'Contractual Allowance (Inpatient)' form.
  15. Select 'Post' from the 'Compile, View or Post' field.
  16. Set the 'Month/Year To Run Report For' field to desired month and year such that it covers the services for the client.
  17. Enter the 'Posting Date'.
  18. Select all other required fields.
  19. Click [Process].
  20. Verify the services posted displayed correctly in the report with the expected contractual adjustments for the new client.
  21. Open 'Client Ledger' form.
  22. Verify the contractual adjustments are correctly posted for the services that are included in the batch and the deleted client is not included in the posting.
  23. Close the form.
Functional Or Implementation Acknowledgement (997/999) - Compiling the 999 file created from the 270 file
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Eligibility Inquiry (270) Request
  • Eligibility Inquiry (270) Submission
  • Crystal Report Viewer
  • Functional or Implementation Acknowledgement (997/999)
Scenario 1: Functional or Implementation Acknowledgement (997/999) - Validating data retrieved after loading/compiling file
Specific Setup:
  • The 'Avatar PM > Billing > Electronic Billing > All 837 Submissions > Maintain Unique Functional Group Control Numbers By Root System Code' registry setting is set to "Y".
  • Eligibility Inquiry (270) Submission:
  • Compile a 270 transaction for a guarantor that is configured for 270 submissions.
  • Create/Update the included 999 file such that the values from GS-06 and ST-02 fields of the 270 file is included in the AK1-02 and AK2-02 fields of the 999 file.
  • GS-06 (270) --> AK1-02 (999)
  • ST-02 (270) --> AK2-02 (999)
Steps
  1. Open the 'Functional or Implementation Acknowledgement (997/999)' form.
  2. Load/ Compile the 999 file.
  3. Verify the file loads successfully.
  4. Compile the recently loaded file.
  5. Verify the file compiles successfully.
Eligibility Inquiry 270 Request - Delete inquiry
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Eligibility Inquiry (270) Request
Scenario 1: Eligibility Inquiry (270) Request - Add / Delete 'Generic' and 'Specific' inquiry
Specific Setup:
  • Guarantors/Payors:
  • An existing guarantor is identified to be used. Note the guarantors code/name.
  • Service codes:
  • An existing service code is identified to be used. Note the service code/description.
  • Service Fee/ Cross Reference Maintenance:
  • A fee definition is created for the service code identified in the ' Service Codes' form.
  • Admission:
  • An existing client is identified, or a new client is admitted. Note client id, admission program, admission date.
  • Financial Eligibility:
  • A guarantor identified in the 'Guarantors/Payors' form is assigned to the client as a primary guarantor.
  • Client Charge Input:
  • A service is rendered to the client. Note service date, service code.
  • Client Ledger:
  • A service distributed correctly to the assigned guarantor.
Steps
  1. Open the 'Eligibility Inquiry (270) Request' form.
  2. Create a generic request for a client and a guarantor.
  3. Make sure to use the same client/guarantor.
  4. Click [Select Pending Inquiry].
  5. Select the inquiry which is added in above steps.
  6. Click [Delete Inquiry].
  7. Review the pending inquiry again.
  8. Verify that the selected inquiry is deleted.
Service/Fee Cross Reference - CPT-4 / HCPCS Modifier If Not First Instance For Service Date
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Service Codes
  • Service Fee/Cross Reference Maintenance
  • Admission (Outpatient)
  • Financial Eligibility
  • Diagnosis
  • Client Charge Input
  • Client Ledger
  • Create Interim Billing Batch File
  • Electronic Billing
  • Individual Cash Posting (PM)
Scenario 1: 837 Professional - Validating the 'CPT-4 / HCPCS Modifier' and 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date'
Specific Setup:
  • Registry Settings:
  • The 'Include CPT-4 Modifier If Not First Instance For Service Date' registry setting is set to 'Y'.
  • Service Codes:
  • A professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance:
  • The 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date' field is populated with the two digit value for the service code. Note the value of the field.
  • Guarantors/Payors:
  • Two existing guarantors are identified to be used. Note the guarantor codes/names. Note the Guarantor name and ID.
  • Admission:
  • An existing outpatient client is identified, or a new client is admitted to the outpatient program. Note the client id.
  • Financial Eligibility:
  • The guarantors identified in the 'Guarantors/Payors' form are assigned to the client as a primary and secondary guarantor.
  • Diagnosis:
  • A diagnosis record is created for the client.
  • Client Charge Input:
  • 4-5 service(es) are rendered to the client. Note the service code and date of service.
  • Client Ledger:
  • Verify the service(es) distributed correctly to the primary guarantor assigned to the client.
  • Close the charges.
  • Create Interim Billing Batch:
  • An Interim billing batch is created that covers client, service(es) and the guarantor.
Steps
  1. Open the 'Electronic Billing' form.
  2. Compile the 837 Professional bill for the interim billing batch created in the setup section.
  3. Verify the file compiles successfully.
  4. Review the 837 file dump file.
  5. Locate the 2400-SV1 segment.
  6. Verify the SV1 segment does not include modifier from the 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date' field and it includes modifier from the 'CPT-4 / HCPCS Modifier' field.
  7. Verify the SV1 segment includes the modifier from the 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date' field for all the instances of the service code after the first instance of the service code.
  8. Open the 'Individual Cash Posting' form.
  9. Transfer the service from the primary guarantor to secondary guarantor.
  10. Submit the form.
  11. Open the 'Client Ledger' form.
  12. Verify the service correctly transferred to the secondary guarantor.
  13. Close the form.
  14. Open the 'Individual Cash Posting' form.
  15. Transfer all the service(es) from the secondary guarantor to the primary guarantor.
  16. Submit the form.
  17. Open the 'Client Ledger' form.
  18. Verify the service correctly transferred back to the secondary guarantor.
  19. Close the form.
  20. Open the 'Electronic Billing' form.
  21. Compile the 837 Professional bill again for the primary guarantor.
  22. Verify the bill compiles successfully.
  23. Review the 837 file dump file.
  24. Locate the 2400-SV1 segment.
  25. Verify the SV1 segment does not include modifier from the 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date' field and it includes modifier from the 'CPT-4 / HCPCS Modifier' field.
  26. Verify the SV1 segment includes the modifier from the 'CPT-4 / HCPCS Modifier If Not First Instance For Service Date' field for all the instances of the service code after the first instance of the service code.
  27. Close the form.
Topics
• Quick Billing • System Task Scheduler • NX • Contractual Allowance (Outpatient) • Contractual Allowance (Inpatient) • Functional or Implementation Acknowledgement (997/999) • Eligibility Inquiry (270) Request • 837 Professional
Update 88 Summary | Details
Registry Setting - Avatar PM - Billing - End Date California Billing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Create Interim Billing Batch File
  • Electronic Billing
  • Client Charge Input
  • Client Ledger
  • Print Bill
Scenario 1: Electronic Billing - Registry Setting 'Avatar PM - Billing - End Date California Billing'.
Specific Setup:
  • Note: This test is for agencies that use Avatar PM and have a 'Y' in the 'Enable California Billing' registry setting.
  • Do not enable the registry setting ‘Setting 'Avatar PM - Billing - End Date California Billing'.
  • Identify an active inpatient client that can be billed on the 837 Institutional (Client A).
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Identify an active outpatient client that can be billed on the 837 Professional (Client B).
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Group Registration: Identify an active group and the members within the group.
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Guarantors/Payors: 'Bill Cal Billing Units' has a value of 'Yes'.
  • Client Charge input:
  • Create a service for Client A and Client B. Use a service date of yesterday. Note the details of the service.
  • Progress Notes (Group and Individual):
  • Create a note for all clients in the group. Use a service date of yesterday. Note the details of the service.
  • Create Interim Billing Batch File: Create batches for Client A, Client B, and a batch for the clients it the group.
  • Close Charges is used to close the charges.
  • Electronic Billing:
  • Create unclaimed bills for each interim back. Export the dump file because it will be used later for comparison.
  • Only after completing the above items, set the registry setting ‘Setting 'Avatar PM - Billing - End Date California Billing' to contain a date value, noting that the date must be after the current date. Note the date.
  • Wait one day after the date entered in the registry setting to complete testing.
Steps
  1. Open ‘Electronic Billing’.
  2. Using the interim batch created in setup, create an unclaimed bill for client A.
  3. Export the dump file and compare it to the previous exported dump file to validate that the billing data remained the same.
  4. Using the interim batch created in setup, create an unclaimed bill for client B.
  5. Export the dump file and compare it to the previous exported dump file to validate that the billing data remained the same.
  6. Using the interim batch created in setup, create an unclaimed bill for the group.
  7. Export the dump file and compare it to the previous exported dump file to validate that the billing data remained the same.
  8. Open ‘Client Charge Input’ and create services, for Clients A & B, for today’s date, using the same service details as the services created in setup.
  9. Open ‘Progress Notes (Group and Individual) and create services for today’s date, using the same service details as the services created in setup.
  10. Open ‘Create Interim Billing Batch and created new batches for only today’s services, for Client A, Client B, and the group clients.
  11. Use ‘Close Charges’ to close the charges for the interim batches.
  12. Open ‘Electronic Billing’.
  13. Using the interim batch created above, create an unclaimed bill for client A.
  14. Export the dump file and compare it to the previous exported dump file to validate that the billing information is correct based on the new registry setting.
  15. Using the interim batch created above, create an unclaimed bill for client B.
  16. Export the dump file and compare it to the previous exported dump file to validate that the billing information is correct based on the new registry setting.
  17. Using the interim batch created above, create an unclaimed bill for the group clients.
  18. Export the dump file and compare it to the previous exported dump file to validate that the billing information is correct based on the new registry setting.
Scenario 2: Print Bill - Registry Setting 'Avatar PM - Billing - End Date California Billing'.
Specific Setup:
  • Note: This test is for agencies that use Avatar PM and have a 'Y' in the 'Enable California Billing' registry setting.
  • Do not enable the registry setting ‘Setting 'Avatar PM - Billing - End Date California Billing'.
  • Identify an active inpatient client that can be billed on the 837 Institutional (Client A).
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Identify an active outpatient client that can be billed on the 837 Professional (Client B).
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Group Registration: Identify an active group and the members within the group.
  • Financial Eligibility: Verify the guarantor that services will distribute to.
  • Guarantors/Payors: 'Bill Cal Billing Units' has a value of 'Yes'.
  • Client Charge input:
  • Create a service for Client A and Client B. Use a service date of yesterday. Note the details of the service.
  • Progress Notes (Group and Individual):
  • Create a note for all clients in the group. Use a service date of yesterday.
  • Create Interim Billing Batch File: Create batches for Client A, Client B, and a batch for the clients it the group.
  • Close Charges is used to close the charges.
  • Print Bill:
  • Create unclaimed bills for each interim back. Export the pages because they will be used later for comparison.
  • Only after completing the above items, set the registry setting ‘Setting 'Avatar PM - Billing - End Date California Billing' to contain a date value, noting that the date must be after the current date. Note the date.
  • Wait one day after the date entered in the registry setting to complete testing.
Steps

Open ‘Print Bill’.

Using the interim batch created in setup, create an unclaimed bill for client A.

Export the pages and compare to the previous exported pages to validate that the billing data remained the same.

Using the interim batch created in setup, create an unclaimed bill for client B.

Export the pages and compare to the previous exported pages to validate that the billing data remained the same.

Using the interim batch created in setup, create an unclaimed bill for the group.

Export the pages and compare to the previous exported pages to validate that the billing data remained the same.

Open ‘Client Charge Input’ and create services, for Clients A & B, for today’s date, using the same service details as the services created in setup.

Open ‘Progress Notes (Group and Individual) and create services for today’s date, using the same service details as the services created in setup.

Open ‘Create Interim Billing Batch and created new batches for only today’s services, for Client A, Client B, and the group clients.

Use ‘Close Charges’ to close the charges for the interim batches.

Open ‘Print Bill’.

Using the interim batch created above, create an unclaimed bill for client A.

Export the pages and compare it to the previous exported pages to validate that the billing information is correct based on the new registry setting.

Using the interim batch created above, create an unclaimed bill for client B.

Export the pages and compare it to the previous exported pages to validate that the billing information is correct based on the new registry setting.

Using the interim batch created above, create an unclaimed bill for the group clients.

Export the pages and compare it to the previous exported pages to validate that the billing information is correct based on the new registry setting.
Topics
• 837 Professional • 837 Institutional • NX • Print Bill
Update 89 Summary | Details
837 Billing - K3 segment
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Diagnosis
  • Financial Eligibility
  • Service Codes
  • Service Fee/Cross Reference Maintenance
  • Practitioner Numbers By Guarantor And Program
  • Client Charge Input
  • Electronic Billing
  • Admission (Outpatient)
Scenario 1: 837 Institutional - Report Only Guarantor - Validate (2010BA-REF) and (2300-K3) segments
Specific Setup:
  • Registry Settings:
  • Avatar PM->Billing->Electronic Billing->837 Report Only->->Include Subscriber Secondary ID Info (2010BA-REF) has a value of ‘Y’.
  • Dictionary Update:
  • Other Tabled Files:
  • ‘(12125) Specify Information To Include Subscriber Secondary ID Information (2010BA-REF) – Report Only’ has values of ‘Client Social Security Number’ and ‘Client Social Security Number (No Dashes, Only When Subscriber Equals Self)’.
  • Client: Dictionary:
  • ‘(350) State Reporting Ethnic Origin’ has desired values.
  • ‘(8) Ethnic Origin’ has extended dictionary values in ‘(350) State Reporting Ethnic Origin’.
  • ‘(351) State Reporting Client Race’ has desired values.
  • ‘(116) Client Race’ has extended dictionary values in ‘(351) State Reporting Client Race’.
  • ‘(247) Client's Relationship To Subscriber’ has extended dictionary value for the ‘Billing Patient's Relationship To Insured’.
  • Guarantors/Payors 1:
  • Has a value of ‘No’ or a null value in ‘Is This A Report Only Guarantor’, in the ‘837’ section.
  • Note the Financial Class.
  • Guarantors/Payors 2:
  • Has the same Financial Class as Guarantors/Payors 1.
  • Has a value of ‘Yes’ in ‘Is This A Report Only Guarantor’, in the ‘837’ section.
  • Has a value of Guarantors/Payors 1 in 'Only Include Services In The Report Only 837 If Liability For The Service Distributes To The Following Guarantor(s)', in the ‘837’ section.
  • Client 1:
  • Client is the subscriber and has values in ‘Race’, ‘Ethnicity’, and ‘Social Security Number’.
  • Note the client ID, admission date, and program.
  • Client is assigned Guarantors/Payors 1 in Financial Eligibility.
  • Client 2:
  • Client is not the subscriber and has values in ‘Race’, ‘Ethnicity’, and ‘Social Security Number’.
  • Note the client ID, admission date, and program.
  • Client is assigned Guarantors/Payors 1 in Financial Eligibility. The client is not ‘Self’ in ‘Client’s Relationship To Subscriber’. The ‘Subscriber’s Name’ and ‘‘Subscriber’s Social Security #’ contain values.
  • Guarantor/Program Billing Defaults:
  • Select templates for the selected guarantor(s) and the client program(s).
  • 837 Institutional section:
  • Select desired value in ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ noting the value.
  • Select desired value in ‘Include Race/Ethnicity/SSN in 2300-K3’, noting the value.
  • Service Codes:
  • Service Code must have a value of ‘Yes’ in ‘Include This Service For Report Only Guarantors’. Note the selected service codes.
  • Services:
  • Create services for the clients, noting the date of service.
  • Close Charges for the clients.
Steps
  1. Open ‘Electronic Billing’.
  2. Create an 837 Institutional for Guarantors/Payors 2.
  3. Review the dump file to validate that the following:
  4. If the billing template selection for ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ is 'Client Social Security Number’ the output in the REF segment will contain the following: ‘REF*SY*xxx-xx-xxxx, which represents the SSN with dashes. This segment will exist for Client 1 and Client 2.
  5. If the billing template selection for ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ is '‘Client Social Security Number (No Dashes, Only When Subscriber Equals Self)’ the output in the REF for Client 1 will contain the following: ‘REF*SY*xxxxxxxxx, which represents the SSN with no dashes. There will not be a ‘REF*SY* segment for Client 2.
  6. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘No’, there will be no ‘K3’ segment.
  7. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘Yes’ the ‘K3’ will include the following, if it exists for the client: Field 1 = the dictionary codes for ‘Ethnicity’. Field 2 = the dictionary codes for ‘RACE’. Field 3 = the ‘Social Security Number’ of the client, when the client is not the subscriber. No ‘Social Security Number’ is output when the subscriber is the client.
  8. Close the dump file.
  9. Close the form.
Scenario 2: 837 Professional - Report Only Guarantor - Validate (2010BA-REF) and (2300-K3) segments
Specific Setup:
  • Registry Settings:
  • Avatar PM->Billing->Electronic Billing->837 Report Only->->Include Subscriber Secondary ID Info (2010BA-REF) has a value of ‘Y’.
  • Dictionary Update:
  • Other Tabled Files:
  • ‘(12125) Specify Information To Include Subscriber Secondary ID Information (2010BA-REF) – Report Only’ has values of ‘Client Social Security Number’ and ‘Client Social Security Number (No Dashes, Only When Subscriber Equals Self)’.
  • Client: Dictionary:
  • ‘(350) State Reporting Ethnic Origin’ has desired values.
  • ‘(8) Ethnic Origin’ has extended dictionary values in ‘(350) State Reporting Ethnic Origin’.
  • ‘(351) State Reporting Client Race’ has desired values.
  • ‘(116) Client Race’ has extended dictionary values in ‘(351) State Reporting Client Race’.
  • ‘(247) Client's Relationship To Subscriber’ has extended dictionary value for the ‘Billing Patient's Relationship To Insured’.
  • Guarantors/Payors 1:
  • Has a value of ‘No’ or a null value in ‘Is This A Report Only Guarantor’, in the ‘837’ section.
  • Note the Financial Class.
  • Guarantors/Payors 2:
  • Has the same Financial Class as Guarantors/Payors 1.
  • Has a value of ‘Yes’ in ‘Is This A Report Only Guarantor’, in the ‘837’ section.
  • Has a value of Guarantors/Payors 1 in 'Only Include Services In The Report Only 837 If Liability For The Service Distributes To The Following Guarantor(s)', in the ‘837’ section.
  • Client 1:
  • Client is the subscriber and has values in ‘Race’, ‘Ethnicity’, and ‘Social Security Number’.
  • Note the client ID, admission date, and program.
  • Client is assigned Guarantors/Payors 1 in Financial Eligibility.
  • Client 2:
  • Client is not the subscriber and has values in ‘Race’, ‘Ethnicity’, and ‘Social Security Number’.
  • Note the client ID, admission date, and program.
  • Client is assigned Guarantors/Payors 1 in Financial Eligibility. The client is not ‘Self’ in ‘Client’s Relationship To Subscriber’. The ‘Subscriber’s Name’ and ‘‘Subscriber’s Social Security #’ contain values.
  • Guarantor/Program Billing Defaults:
  • Select templates for the selected guarantor(s) and the client program(s).
  • 837 Professional section:
  • Select desired value in ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ noting the value.
  • Select desired value in ‘Include Race/Ethnicity/SSN in 2300-K3’, noting the value.
  • Service Codes:
  • Service Code must have a value of ‘Yes’ in ‘Include This Service For Report Only Guarantors’. Note the selected service codes.
  • Services:
  • Create services for the clients, noting the date of service.
  • Close Charges for the clients.
Steps
  1. Open ‘Electronic Billing’.
  2. Create an 837 Professional for Guarantors/Payors 2.
  3. Review the dump file to validate that the following:
  4. If the billing template selection for ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ is 'Client Social Security Number’ the output in the REF segment will contain the following: ‘REF*SY*xxx-xx-xxxx, which represents the SSN with dashes. This segment will exist for Client 1 and Client 2.
  5. If the billing template selection for ‘Specify Information To Include In Subscriber Secondary ID Information (2010BA-REF) - Report Only’ is '‘Client Social Security Number (No Dashes, Only When Subscriber Equals Self)’ the output in the REF for Client 1 will contain the following: ‘REF*SY*xxxxxxxxx, which represents the SSN with no dashes. There will not be a ‘REF*SY* segment for Client 2.
  6. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘No’, there will be no ‘K3’ segment.
  7. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘Yes’ the ‘K3’ will include the following, if it exists for the client: Field 1 = the dictionary codes for ‘Ethnicity’. Field 2 = the dictionary codes for ‘Race’. Field 3 = the ‘Social Security Number’ of the client, when the client is not the subscriber. No ‘Social Security Number’ is output when the subscriber is the client.
  8. Close the dump file.
  9. Close the form.
Topics
• 837 Institutional • 837 Professional
Update 94 Summary | Details
Accounts Receivable Console - AR Console Configuration
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • AR Console Configuration
  • System Task Scheduler
  • AR Console User Defaults Setup
Scenario 1: PM - AR Console Configuration - field validation
Specific Setup:
  • The following registry setting has a value of Y: Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality.
  • User Defaults has been used to give the tester access to: Avatar PM / Billing / AR Management / AR Console Configuration.
  • User Defaults has been used to give the tester access to: Avatar PM / Billing / AR Management / AR Console User Defaults Setup.
  • The 'Accounts Receivable Console' widget is on the tester's homeview.
  • Financial Class 1: note all guarantors associated to the class.
  • Financial Class 2: note all guarantors associated to the class.
  • Financial Class 3: note all guarantors associated to the class.
  • Financial Class 4: note all guarantors associated to the class.
  • A client has a claim that was created in 'Print Bill' for a guarantor in Financial Class 3. Note the claim number.
Steps
  1. Open 'AR Console Configuration'.
  2. Select any value in 'Default Managed Care Authorization Form to Display'. Note the selected value.
  3. Select any value in 'Include AR Data from All Sub System Codes'. Note the selected value.
  4. Enter the desired value in 'AR Auto Batch Number of Days Prior to Current Date to Include'. The maximum allowable value is 1460, which represents four years. Note the value entered.
  5. Select 'Financial Class 1' and 'Financial Class 2' in 'Exclude Financial Class(es) from AR Console'.
  6. Note that access to the excluded financial classes and the associated guarantors will be immediately removed from 'AR Console User Defaults Setup' upon submission of the form.
  7. Note that access to the excluded financial classes and the associated guarantors will be removed from the ‘Accounts Receivable Console’ form after submission, when the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’ is processed and the user signs in.
  8. Select 'Yes' in 'Allow Re-bill Assignment of Paper Claims'.
  9. Select desired value in 'Maximum Number of Claims to Return in Search'.
  10. Select desired value in 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'. Note: Selecting 'No' causes system-generated follow-up notes to not be recognized as an existing follow-up for the purposes of the 'Claim Follow-Up Record Exists' filter.
  11. Select desired value in 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'. Note: Selecting 'No' causes system-generated follow-up notes to not be recognized as an existing follow-up for the purposes of the 'Claim Follow-Up Record Exists' filter.
  12. Click [Submit].
  13. Open 'AR Console Configuration'.
  14. Validate the 'Default Managed Care Authorization Form to Display' value.
  15. Validate the 'Include AR Data from All Sub System Codes' value.
  16. Validate the 'AR Auto Batch Number of Days Prior to Current Date to Include' value.
  17. Validate the 'Exclude Financial Class(es) from AR Console' values.
  18. Validate the 'Allow Re-bill Assignment of Paper Claims' value.
  19. Validate the 'Maximum Number of Claims to Return in Search' value.
  20. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'.
  21. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'.
  22. Close the form.
  23. Open 'AR Console User Defaults Setup'.
  24. Validate that the excluded financial class and the associated guarantors no longer display in the form. Give the tester access to Financial Class 3 and Financial Class 4, and all associated guarantors.
  25. Process the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’.
  26. Sign out and back in.
  27. Validate that the excluded financial class and the associated guarantors no longer display in the 'Accounts Receivable Console'.
  28. Validate that the tester has access to Financial Class 3 and Financial Class 4, and all associated guarantors in the 'Accounts Receivable Console'.
  29. Enter the 'Client' from 'SETUP'.
  30. Select 'No' in 'Claim Follow-Up Records Exist'.
  31. Click [Search].
  32. Select the claim in the 'Claims with Outstanding Receivables' grid.
  33. Click [Add/Claim Follow-Up Note].
  34. Click [OK].
  35. Set the section to 'Claim Follow-Up Entry'.
  36. Validate the claim number in the 'Services' grid.
  37. Enter the desired value in 'Payer ICN #'. Note the value.
  38. Enter the desired value in 'Claim Submission Reason Code'. Note the value.
  39. Click [File Updates].
  40. Set the section to 'AR List'.
  41. Select 'Yes' in 'Claim Follow-Up Records Exist'.
  42. Click [Search].
  43. Select the claim in the 'Claims with Outstanding Receivables' grid.
  44. Click [Add/Claim Follow-Up Note].
  45. Verify the value in 'Payer ICN #'.
  46. Verify the value in 'Claim Submission Reason Code'.
Scenario 2: AR Console User Defaults Setup - field validation
Specific Setup:
  • The following registry setting has a value of Y: Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality.
  • User Definition has been used to give the signed in user access to the form: Avatar PM / Billing / AR Management / AR Console User Defaults Setup.
  • View Definition / NX View Definition has been used to place the widget on the tester's home view.
  • Note the ID of at least two more users.
  • Guarantors/Payor: Multiple guarantors exist that contain different 'Financial Classes'.
  • AR Console Configuration: At least one 'Financial Class' is selected in 'Exclude Financial Class(es) from AR Console'.
  • System Task Scheduler:
  • The 'Auto AR Batch Update' was processed after the claims were created.
Steps
  1. Open ‘AR Console User Defaults Setup’.
  2. Click ‘New Row’ and add a row for the signed in user, or if the signed in user exists in a row select the row.
  3. Click ‘All’ in the following fields: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’.
  4. Add desired value to ‘Aged Over # Days’. Note the value.
  5. Add desired value to 'Allow 'Copy Note' from one client to another'.
  6. Click ‘New Row’ and add a row for the first additional user from ‘Setup’, or if the user exists in a row select the row.
  7. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’.
  8. Note the values of each field.
  9. Click ‘New Row’ and add a row for the second additional user from ‘Setup’, or if the user exists in a row select the row.
  10. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, ‘Aged Over # Days’ and 'Allow 'Copy Note' from one client to another'.
  11. Note the values of each field.
  12. Click [Submit].
  13. Open ‘AR Console User Defaults Setup’.
  14. Select the row for the signed in user.
  15. Validate that the following fields have every available item in the checklist selected: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’.
  16. Verify that ‘Aged Over # Days' contains the value entered above.
  17. Deselect one or more items in 'Financial Class(es)'.
  18. Select the row for the first additional user.
  19. Validate that the values that were submitted were retained.
  20. Select the row for the second additional user.
  21. Validate that the values that were submitted were retained.
  22. Click [Submit].
  23. Open ‘AR Console User Defaults Setup’.
  24. Select the row for the signed in user.
  25. Verify that the ‘Financial Class(es)’ does not contain the deselected items.
  26. Open the 'Account Receivable Console' widget for the signed in user.
  27. Verify that the ‘Financial Class(es)’ does not contain the deselected items.
  28. Close the widget.
Accounts Receivable Console - AR Console User Defaults Setup
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • AR Console Configuration
  • System Task Scheduler
  • AR Console User Defaults Setup
Scenario 1: PM - AR Console Configuration - field validation
Specific Setup:
  • The following registry setting has a value of Y: Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality.
  • User Defaults has been used to give the tester access to: Avatar PM / Billing / AR Management / AR Console Configuration.
  • User Defaults has been used to give the tester access to: Avatar PM / Billing / AR Management / AR Console User Defaults Setup.
  • The 'Accounts Receivable Console' widget is on the tester's homeview.
  • Financial Class 1: note all guarantors associated to the class.
  • Financial Class 2: note all guarantors associated to the class.
  • Financial Class 3: note all guarantors associated to the class.
  • Financial Class 4: note all guarantors associated to the class.
  • A client has a claim that was created in 'Print Bill' for a guarantor in Financial Class 3. Note the claim number.
Steps
  1. Open 'AR Console Configuration'.
  2. Select any value in 'Default Managed Care Authorization Form to Display'. Note the selected value.
  3. Select any value in 'Include AR Data from All Sub System Codes'. Note the selected value.
  4. Enter the desired value in 'AR Auto Batch Number of Days Prior to Current Date to Include'. The maximum allowable value is 1460, which represents four years. Note the value entered.
  5. Select 'Financial Class 1' and 'Financial Class 2' in 'Exclude Financial Class(es) from AR Console'.
  6. Note that access to the excluded financial classes and the associated guarantors will be immediately removed from 'AR Console User Defaults Setup' upon submission of the form.
  7. Note that access to the excluded financial classes and the associated guarantors will be removed from the ‘Accounts Receivable Console’ form after submission, when the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’ is processed and the user signs in.
  8. Select 'Yes' in 'Allow Re-bill Assignment of Paper Claims'.
  9. Select desired value in 'Maximum Number of Claims to Return in Search'.
  10. Select desired value in 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'. Note: Selecting 'No' causes system-generated follow-up notes to not be recognized as an existing follow-up for the purposes of the 'Claim Follow-Up Record Exists' filter.
  11. Select desired value in 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'. Note: Selecting 'No' causes system-generated follow-up notes to not be recognized as an existing follow-up for the purposes of the 'Claim Follow-Up Record Exists' filter.
  12. Click [Submit].
  13. Open 'AR Console Configuration'.
  14. Validate the 'Default Managed Care Authorization Form to Display' value.
  15. Validate the 'Include AR Data from All Sub System Codes' value.
  16. Validate the 'AR Auto Batch Number of Days Prior to Current Date to Include' value.
  17. Validate the 'Exclude Financial Class(es) from AR Console' values.
  18. Validate the 'Allow Re-bill Assignment of Paper Claims' value.
  19. Validate the 'Maximum Number of Claims to Return in Search' value.
  20. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'.
  21. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'.
  22. Close the form.
  23. Open 'AR Console User Defaults Setup'.
  24. Validate that the excluded financial class and the associated guarantors no longer display in the form. Give the tester access to Financial Class 3 and Financial Class 4, and all associated guarantors.
  25. Process the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’.
  26. Sign out and back in.
  27. Validate that the excluded financial class and the associated guarantors no longer display in the 'Accounts Receivable Console'.
  28. Validate that the tester has access to Financial Class 3 and Financial Class 4, and all associated guarantors in the 'Accounts Receivable Console'.
  29. Enter the 'Client' from 'SETUP'.
  30. Select 'No' in 'Claim Follow-Up Records Exist'.
  31. Click [Search].
  32. Select the claim in the 'Claims with Outstanding Receivables' grid.
  33. Click [Add/Claim Follow-Up Note].
  34. Click [OK].
  35. Set the section to 'Claim Follow-Up Entry'.
  36. Validate the claim number in the 'Services' grid.
  37. Enter the desired value in 'Payer ICN #'. Note the value.
  38. Enter the desired value in 'Claim Submission Reason Code'. Note the value.
  39. Click [File Updates].
  40. Set the section to 'AR List'.
  41. Select 'Yes' in 'Claim Follow-Up Records Exist'.
  42. Click [Search].
  43. Select the claim in the 'Claims with Outstanding Receivables' grid.
  44. Click [Add/Claim Follow-Up Note].
  45. Verify the value in 'Payer ICN #'.
  46. Verify the value in 'Claim Submission Reason Code'.
Scenario 2: AR Console User Defaults Setup - field validation
Specific Setup:
  • The following registry setting has a value of Y: Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality.
  • User Definition has been used to give the signed in user access to the form: Avatar PM / Billing / AR Management / AR Console User Defaults Setup.
  • View Definition / NX View Definition has been used to place the widget on the tester's home view.
  • Note the ID of at least two more users.
  • Guarantors/Payor: Multiple guarantors exist that contain different 'Financial Classes'.
  • AR Console Configuration: At least one 'Financial Class' is selected in 'Exclude Financial Class(es) from AR Console'.
  • System Task Scheduler:
  • The 'Auto AR Batch Update' was processed after the claims were created.
Steps
  1. Open ‘AR Console User Defaults Setup’.
  2. Click ‘New Row’ and add a row for the signed in user, or if the signed in user exists in a row select the row.
  3. Click ‘All’ in the following fields: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’.
  4. Add desired value to ‘Aged Over # Days’. Note the value.
  5. Add desired value to 'Allow 'Copy Note' from one client to another'.
  6. Click ‘New Row’ and add a row for the first additional user from ‘Setup’, or if the user exists in a row select the row.
  7. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’.
  8. Note the values of each field.
  9. Click ‘New Row’ and add a row for the second additional user from ‘Setup’, or if the user exists in a row select the row.
  10. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, ‘Aged Over # Days’ and 'Allow 'Copy Note' from one client to another'.
  11. Note the values of each field.
  12. Click [Submit].
  13. Open ‘AR Console User Defaults Setup’.
  14. Select the row for the signed in user.
  15. Validate that the following fields have every available item in the checklist selected: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’.
  16. Verify that ‘Aged Over # Days' contains the value entered above.
  17. Deselect one or more items in 'Financial Class(es)'.
  18. Select the row for the first additional user.
  19. Validate that the values that were submitted were retained.
  20. Select the row for the second additional user.
  21. Validate that the values that were submitted were retained.
  22. Click [Submit].
  23. Open ‘AR Console User Defaults Setup’.
  24. Select the row for the signed in user.
  25. Verify that the ‘Financial Class(es)’ does not contain the deselected items.
  26. Open the 'Account Receivable Console' widget for the signed in user.
  27. Verify that the ‘Financial Class(es)’ does not contain the deselected items.
  28. Close the widget.
Scenario 3: Account Receivable Console - Copy Claim Follow-Up/Notes
Specific Setup:
  • Guarantors/Payors:
  • Guarantor 1: The 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' fields contain an '&'.
  • Guarantor 2: The 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' fields do not contain an '&’.
  • Clients:
  • Client A: Has a minimum of two outstanding claims for Guarantor 1. Note the client’s last name and the program.
  • Client B: Has a minimum of two outstanding claims for Guarantor 2. Note the client’s last name and the program.
  • Tester has access to the AR Console.
  • AR Console User Defaults Setup:
  • Tester has been given access to both Guarantors/Payors, the client’s last name initials, and the client programs.
  • 'Allow 'Copy Note' from one client to another' has a value of 'Yes',
  • System Task Scheduler:
  • The 'Auto AR Batch Update' was processed after the claims were created.
Steps
  1. Open the ‘Account Receivable Console’ widget.
  2. Validate that the ‘Guarantor’ field contains the selected guarantors, including the guarantor with the ‘&’ in the 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup'
  3. Enter the ‘Client ID for Client A.
  4. Click [Search].
  5. Select a minimum of two clients, and two or more claims per client, in the ‘Claims with Outstanding Receivables’ gird.
  6. Click [Add Claim Follow-Up/Note].
  7. Validate the claim number in ‘Claim Follow-Up’ and note the client.
  8. Go to the Follow-Up Notes’ section.
  9. Validate the note created by the AR Console exists.
  10. Click [New Row].
  11. Enter desired ‘Follow-Up Date’, ‘Comments’ and any other desired data.
  12. Click [File Updates].
  13. Click [OK].
  14. Select the row that was added above.
  15. Click [Copy Note].
  16. Select the client/claim to copy the note to in ‘Copy Follow-Up Note’.
  17. Click [Save].
  18. Select the claim number in ‘Claim Follow-Up’ that was selected in ‘Copy Follow-Up Note’.
  19. Validate that the copy note, and the note created by the AR Console exist in ‘Claim Follow-Up’.
  20. Select the ‘AR List’ section.
  21. Repeat steps 3 - 20 for Client B.
  22. Close the widget.
Accounts Receivable Console - AR Console Configuration
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • AR Console User Defaults Setup
  • AR Console Configuration
  • System Task Scheduler
  • Electronic Billing
  • Claim Adjustment Group/Reason Code Definition
  • Crystal Report Viewer
  • Admission (Outpatient)
  • Diagnosis
  • Financial Eligibility
Scenario 1: Account Receivable Console - Copy Claim Follow-Up/Notes
Specific Setup:
  • Guarantors/Payors:
  • Guarantor 1: The 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' fields contain an '&'.
  • Guarantor 2: The 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' fields do not contain an '&’.
  • Clients:
  • Client A: Has a minimum of two outstanding claims for Guarantor 1. Note the client’s last name and the program.
  • Client B: Has a minimum of two outstanding claims for Guarantor 2. Note the client’s last name and the program.
  • Tester has access to the AR Console.
  • AR Console User Defaults Setup:
  • Tester has been given access to both Guarantors/Payors, the client’s last name initials, and the client programs.
  • 'Allow 'Copy Note' from one client to another' has a value of 'Yes',
  • System Task Scheduler:
  • The 'Auto AR Batch Update' was processed after the claims were created.
Steps
  1. Open the ‘Account Receivable Console’ widget.
  2. Validate that the ‘Guarantor’ field contains the selected guarantors, including the guarantor with the ‘&’ in the 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup'
  3. Enter the ‘Client ID for Client A.
  4. Click [Search].
  5. Select a minimum of two clients, and two or more claims per client, in the ‘Claims with Outstanding Receivables’ gird.
  6. Click [Add Claim Follow-Up/Note].
  7. Validate the claim number in ‘Claim Follow-Up’ and note the client.
  8. Go to the Follow-Up Notes’ section.
  9. Validate the note created by the AR Console exists.
  10. Click [New Row].
  11. Enter desired ‘Follow-Up Date’, ‘Comments’ and any other desired data.
  12. Click [File Updates].
  13. Click [OK].
  14. Select the row that was added above.
  15. Click [Copy Note].
  16. Select the client/claim to copy the note to in ‘Copy Follow-Up Note’.
  17. Click [Save].
  18. Select the claim number in ‘Claim Follow-Up’ that was selected in ‘Copy Follow-Up Note’.
  19. Validate that the copy note, and the note created by the AR Console exist in ‘Claim Follow-Up’.
  20. Select the ‘AR List’ section.
  21. Repeat steps 3 - 20 for Client B.
  22. Close the widget.
Scenario 2: AR Console - Validating follow-up entry and services tables for the client/claim selected
Specific Setup:
  • Note the tester's 'User Definition', 'User Description'.
  • Registry Setting:
  • Set the 'Avatar PM->Billing->Accounts Receivable Management->->->Enable Accounts Receivable Management Functionality' registry setting to "Yes".
  • Accounts Receivable functionality has been defined.
  • Guarantors/Payors:
  • An existing guarantor is identified to be used. Note the guarantor code/name.
  • Service codes:
  • An existing service code is identified to be used. Note the service code/description.
  • Service Fee/ Cross Reference Maintenance:
  • A fee definition is created for the service code identified in the ' Service Codes' form.
  • Admission:
  • An existing client is identified or a new client is admitted. Note client id, admission program, admission date.
  • Financial Eligibility:
  • A guarantor identified in the 'Guarantors/Payors' form is assigned to the client as a primary guarantor.
  • Recurring Client Charge Input:
  • 3-5 services are rendered to the client. Note service date, service code.
  • Client Ledger:
  • The service distributed correctly to the assigned guarantor.
  • Electronic Billing:
  • All the services are claimed. Note the claim numbers.
  • Use ‘AR Console User Defaults’ to give the tester access to the following:
  • First initial of the client's last name.
  • Admission program
  • Guarantor the claim liability distributed to.
  • Use ‘System Task Scheduler’ to process the ‘Auto AR Batch’ after the claims were created.
  • AR Console:
  • A claim follow up note is created for the first service of the client. Note the information of the claim follow-up note.
Steps
  1. Access the ‘AR Console’.
  2. Enter desired client in the ‘Client' search box.
  3. Select a client identified in the setup section.
  4. Click [Search].
  5. Validate all the claims for the client are displayed in the ‘Claims with Outstanding Receivables’ grid.
  6. Select one claim row, noting the claim number.
  7. Validate the 'Claim Service Information' table displays all the services of the client / claim selected.
  8. Click [Add Claim Follow-Up/Notes].
  9. Validate the user is navigated to the 'Claim Follow-Up Entry' tab.
  10. Validate the 'Client' drop down field is populated with the selected client.
  11. Validate that ‘Claim Follow-Up’ drop down field contains the selected claim number.
  12. Validate the 'Services' table displays all the services attached to the client/claim selected.
  13. Validate the 'Follow-Up Notes' table contains any follow-up note created for the client/claim selected.
  14. Click [New row].
  15. Add another follow-up note for the client/claim.
  16. Click [File Updates].
  17. Go back to 'AR List' tab.
  18. Click [Reset Defaults].
  19. Enter desired client in the ‘Client' search box.
  20. Select a client identified in the setup section.
  21. Click [Search].
  22. Validate all the claims for the client are displayed in the ‘Claims with Outstanding Receivables’ grid.
  23. Select one claim row, noting the claim number.
  24. Validate the 'Claim Service Information' table displays all the services of the client / claim selected.
  25. Click [Add Claim Follow-Up/Notes].
  26. Validate the user is navigated to the 'Claim Follow-Up Entry' tab.
  27. Validate the 'Client' drop down field is populated with the selected client.
  28. Validate that ‘Claim Follow-Up’ drop down field contains the selected claim number.
  29. Validate the 'Services' table displays all the services attached to the client/claim selected.
  30. Validate the 'Follow-Up Notes' table contains all the follow-up notes created for the client/claim selected.
Scenario 3: Accounts Receivable Console -• Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'.
Specific Setup:
  • AR Console Configuration:
  • Select any value in 'Default Managed Care Authorization Form to Display'. Note the selected value.
  • Select any value in 'Include AR Data from All Sub System Codes'. Note the selected value.
  • Enter the desired value in 'AR Auto Batch Number of Days Prior to Current Date to Include'. The maximum allowable value is 1460, which represents four years. Note the value entered.
  • Select 'Financial Class 1' and 'Financial Class 2' in 'Exclude Financial Class(es) from AR Console'.
  • Note that access to the excluded financial classes and the associated guarantors will be immediately removed from 'AR Console User Defaults Setup' upon submission of the form.
  • Note that access to the excluded financial classes and the associated guarantors will be removed from the ‘Accounts Receivable Console’ form after submission, when the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’ is processed and the user signs in.
  • Select 'Yes' in 'Allow Re-bill Assignment of Paper Claims'.
  • Select desired value in 'Maximum Number of Claims to Return in Search'.
  • Select desired value in 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'.
  • Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'.
  • Note the information directly following this applies to both prompts:
  • Note: Selecting 'Yes' (or leaving it blank) will cause follow-ups of the indicated 'type' to behave according to existing functionality, meaning the 'Claim Follow-Up Record Exists' filter in the widget will determine if records are returned in the search results.
  • If 'Yes' is selected in the 'Claim Follow-Up Record Exists' filter in the widget, only claims that have other types of follow-up notes recorded, whether or not they also have 'AR Console Follow-Up Created' follow-up notes recorded are returned in the search results.
  • If' 'No' is selected in the 'Claim Follow-Up Record Exists' filter in the widget, claims that have no follow-up notes are returned in the search results.
  • Note: Selecting 'No' causes system-generated follow-up notes to not be recognized as an existing follow-up for the purposes of the 'Claim Follow-Up Record Exists' filter. This occurs even if there is a note in the record.
  • If 'Yes' is selected in the 'Claim Follow-Up Record Exists' filter in the widget, only claims that have other types of follow-up notes recorded, whether or not they also have 'AR Console Follow-Up Created' follow-up notes recorded are returned in the search results.
  • If' 'No' is selected in the 'Claim Follow-Up Record Exists' filter in the widget, claims that have no follow-up notes or claims that only have 'AR Console Follow-Up Created' follow-up notes are returned in the search results.
  • AR Console User Defaults Setup exists for the signed in tester.
  • The 'Auto AR Batch Update' option has been processed in the 'System Task Scheduler' form.
  • Claims exist that were partially paid or fully denied in a posted 835 file.
  • Note the client/claim numbers.
Steps
  1. Access the ‘Accounts Receivable Console’ widget.
  2. Enter a value in ‘Claim #’ and/or ‘Client’.
  3. Select desired value in ‘Claim Follow-Up Record Exists’.
  4. Click [Search].
  5. Validate that the appropriate claims are returned in the ‘Claims with Outstanding Receivables’ grid based on the information provided in ‘Setup’.
  6. Select one or more claims in the grid.
  7. Click [Add Claim Follow-Up Notes].
  8. Validate the claim(s) information in the ‘Claim Follow-Up Entry’ section.
  9. Go to the ‘Follow-Up Notes’ section.
  10. Validate existing follow-up notes.
  11. If desired create a new row and add a new note.
  12. Click [File Updates].
  13. Return to the ‘AR List’ section.
  14. Change the value in’ Claim Follow-Up Record Exists’ and repeat the steps above.
Topics
• Accounts Receivable Management • NX
Update 96 Summary | Details
Client Demographic forms - Preferred Appointment Site
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Site Registration
  • Staff Members Hours And Exceptions
  • Pre Admit
  • Assign MR#
  • Pre Admit Discharge
  • Discharge Web Service
  • Discharge
  • SoapUI - ClientDemographics
  • SoapUI - UpdateAdmission
  • SOAPUI - ClientCallIntake - UpdateCallIntake
  • SQL Query/Reporting
  • Admission (Outpatient)
  • Leaves
Scenario 1: Validate the 'Admission' form for a new client
Specific Setup:
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Open the "Admission" form.
  2. Enter a new client into any episode.
  3. Populate the "Preferred Appointment Site" field.
  4. Submit to file the form.
  5. Open the "Admission" form.
  6. Edit the admission episode that was just entered.
  7. Validate the data re displays at it was originally entered.
Scenario 2: 'Update Client Data' - Verification of form filing
Specific Setup:
  • If custom Form Designer changes are present in 'Update Client Data' form, please use 'Form Designer' to revert to 'Netsmart Produced Changes'.
  • A client is enrolled in an existing episode (Client A).
  • The 'Enable Address Validation' registry setting must be enabled.
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Select "Client A" and access the 'Update Client Data' form.
  2. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key.
  3. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?"
  4. Click [No].
  5. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key.
  6. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?"
  7. Click [Yes].
  8. Validate a dialog stating: "Cancelled." and click [OK].
  9. Validate the 'Client's Address - Street' field is cleared.
  10. Enter a valid address and populate any desired fields.
  11. Enter a 'Place of Birth' value that contains 40 characters.
  12. Select a preferred site in the "Preferred Site" field.
  13. Click [Submit].
  14. Re-enter the form for the client and validate that the data submitted successfully.
Scenario 3: 'Pre Admit' form - Field Validation
Specific Setup:
  • A client is enrolled in an existing Pre Admit episode (Client A).
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Select "Client A" and access the 'Pre Admit' form.
  2. Select an existing episode and click [Edit].
  3. Select the "Demographics" section.
  4. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No".
  5. Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field.
  6. Select desired site in the "Preferred Appointment Site" field.
  7. Click [Submit].
  8. Select "Client A" and access the 'Pre Admit' form.
  9. Select an existing episode and click [Edit].
  10. Select the "Demographics" section.
  11. Validate "Yes" is selected in the 'Consent On File For Use of Integrated eSignature' field.
  12. Validate the site that was previously selected displays in the "Preferred Appointment Site".
  13. Close the form.
  14. Access Crystal Reports or other SQL reporting tool.
  15. Create a report using the 'SYSTEM.patient_current_demographics' SQL table.
  16. Navigate to the row for "Client A".
  17. Validate the 'esig_consent_on_file_code' field is present and contains "Y".
  18. Validate the 'esig_consent_on_file_value' field is present and contains "Yes".
  19. Close the report.
  20. Create a report using the 'SYSTEM.patient_demographic_history' SQL table.
  21. Navigate to the row for "Client A".
  22. Validate the 'esig_consent_on_file_code' field is present and contains "Y".
  23. Validate the 'esig_consent_on_file_value' field is present and contains "Yes".
  24. Close the report.
Scenario 4: 'Call Intake' form - Field Validation
Specific Setup:
  • A client is enrolled in an existing Call Intake program (Client A).
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Select "Client A" and access the 'Call Intake' form.
  2. Select the existing call intake record and click [Edit].
  3. Select the "Demographics" section.
  4. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No".
  5. Select "No" in the 'Consent On File For Use of Integrated eSignature' field.
  6. Select desired site from the "Preferred Site" field.
  7. Click [Submit].
  8. Select "Client A" and access the 'Call Intake' form.
  9. Select the existing call intake record and click [Edit].
  10. Select the "Demographics" section.
  11. Validate "No" is selected in the 'Consent On File For Use of Integrated eSignature' field.
  12. Validate the Preferred site from the "Preferred Site" field.
  13. Close the form.
  14. Access Crystal Reports or other SQL reporting tool.
  15. Create a report using the 'SYSTEM.patient_current_demographics' SQL table.
  16. Navigate to the row for "Client A".
  17. Validate the 'esig_consent_on_file_code' field is present and contains "N".
  18. Validate the 'esig_consent_on_file_value' field is present and contains "No".
  19. Close the report.
  20. Create a report using the 'SYSTEM.patient_demographic_history' SQL table.
  21. Navigate to the row for "Client A".
  22. Validate the 'esig_consent_on_file_code' field is present and contains "N".
  23. Validate the 'esig_consent_on_file_value' field is present and contains "No".
  24. Close the report.
Scenario 5: Pre Admit Discharge web service validation
Specific Setup:
  • Existing 'Pre Admit' client whose full name is longer than 40 characters.
  • Registry Setting 'Avatar PM->Client Information->Client Demographics->->->Allow Spaces in Client Name' is set to 'Y' to allow spaces. Note: Once enabled, the user will only be able to edit an existing client 'Client Name' field within 'Update Client Data' form.
  • Registry Setting 'Client Demographics - Additional Fields' must be set to include '3: 'Detailed Client Name' to enable this functionality. This setting will add the 'Detail Client Name' fields to the 'Demographics' section of Admission forms.
  • Access to, and understanding of, SoapUI or other Web Service tools.
Steps
  1. Using 'SoapUI' or another web service tool, consume the WSDL for the 'Pre Admit Discharge' form.
  2. Set the 'SystemCode' code to the agency system code for testing.
  3. Set the 'UserName' to the logged in user name.
  4. Set the 'Password' to the logged in user password.
  5. Set the 'DateOfDischarge' to the discharge date.
  6. Set the 'DischargeTime' to the time of discharge.
  7. Set the 'Discharge Practitioner' to a practitioner code (not the practitioner’s name).
  8. Set the 'Client ID' to the ID for the client to be discharged.
  9. Set the 'EpisodeNumber' to the client episode to be discharged.
  10. Set the "PreferredAppointmentSite" to the desired site.
  11. Click [Send].
  12. Review the response and verify the response message displays: <Message>Client Pre-Admit Discharge web service has been filed successfully.</Message>
  13. Open 'Pre Admit Discharge' in Avatar.
  14. Select the client discharged in the Web Service.
  15. Verify the 'Date of Discharge' is set to the date entered in the Web Service.
  16. Verify the 'Time of Discharge' is set to the time entered in the Web Service.
  17. Verify the 'Discharge Practitioner' is set to the practitioner entered in the Web Service.
  18. Verify the "Preferred Appointment Site" is set to the desired site.
  19. Click [Close Form].
Scenario 6: The 'ClientAdmission' - 'AddAdmission' web service: Admission of a new client
Specific Setup:
  • The 'Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields' registry setting must be set to "3" to include 'Detailed Client Name'.
Steps
  1. Access SoapUI for the 'ClientAdmission' - 'AddAdmission' web service.
  2. Enter the system code that will be used to log into Avatar in the 'SystemCode' field.
  3. Enter the user name that will be used to log into Avatar in the 'UserName' field.
  4. Enter the password that will be used to log into Avatar in the 'Password' field.
  5. Enter the desired date in the 'AdmissionDate' field.
  6. Enter the desired time in the 'AdmissionTime' field.
  7. Enter the desired practitioner in the 'AdmittingPractitioner' field.
  8. Enter the desired value in the 'ClientFirstName' field.
  9. Enter the desired value in the 'ClientLastName' field.
  10. Enter the desired value in the 'ClientMiddleName' field.
  11. Enter the corresponding name in the 'ClientName' field.
  12. Enter the desired value in the 'ESignatureConsentOnFile' field. Note: "Y" and "N" are accepted values.
  13. Enter the desired value in the 'Program' field.
  14. Enter the desired value in the 'Sex' field.
  15. Select the desired value in the "PreferredAppointmentSite".
  16. Populate any other required and desired fields.
  17. Click [Run].
  18. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #".
  19. Validate the 'Message' field contains: "Client Admission web service has been filed successfully".
  20. Select the client filed in the previous steps and access the 'Admission' form.
  21. Select the record filed in the previous steps and click [Edit].
  22. Validate all populated fields are displayed.
  23. Select the "Demographics" section.
  24. Validate the 'Client Last Name' field contains the value filed in the previous steps.
  25. Validate the 'Client First Name' field contains the value filed in the previous steps.
  26. Validate the 'Client Middle Name' field contains the value filed in the previous steps.
  27. Validate the 'Consent On File For Use of Integrated eSignature' field contains the value filed in the previous steps.
  28. Validate the "Preferred Appointment Site" contains the value filed in the previous steps.
  29. Close the form.
Scenario 7: Client Discharge Web Service - Verification of web service filing
Specific Setup:
  • Application utilizing the 'Client Discharge' web service (including Netsmart ProviderConnect).
  • Client record with one or more episodes eligible for 'Discharge' record entry.
Steps
  1. Using 'Client Discharge' web service submit 'Discharge' record for valid client and episode.
  2. Set "PreferredAppointmentSite" to the desired value.
  3. Ensure that Discharge records filed successfully return confirmation message via web service. (Example: <Confirmation>New discharge filed.</Confirmation> <Message>Client Discharge web service has been filed successfully</Message>)
  4. Open Avatar 'Discharge' form.
  5. Select client record/episode used in 'Client Discharge' web service filing.
  6. Ensure that 'Discharge' record filed via web service is present in Avatar Cal-PM with values filed via web service.
  7. Validate the "Preferred Appointment Site" displays the value that was previously filed with the web service filing.
Scenario 8: Client Demographic Web Service validation
Steps
  1. Using soapUI or some other web service tool, file the ClientDemographics web service.
  2. Set up a request to update the client demographic data.
  3. Include the field "Preferred Appointment Site" by populating it.
  4. Submit to file the request.
  5. Open the "Update Client Data" form.
  6. Validate the data that was just filed through the web service is now displayed on the form, including the "Preferred Appointment Site".
Scenario 9: The 'ClientAdmission' - 'UpdateAdmission' web service: Update Admission for an existing client
Specific Setup:
  • A client must be enrolled in an existing episode (Client A).
  • Include the "Detailed Client Name" functionality for Client Demographics - Additional Fields in the registry setting.
Steps
  1. Access SoapUI for the 'ClientAdmission' - 'UpdateAdmission' web service.
  2. Enter the system code that will be used to log into Avatar in the 'SystemCode' field.
  3. Enter the user name that will be used to log into Avatar in the 'UserName' field.
  4. Enter the password that will be used to log into Avatar in the 'Password' field.
  5. Populate all required and desired fields.
  6. Enter the desired value in the 'ClientDeclinedToProvideInfo' field.
  7. Enter the desired value in the 'MothersMaidenName' field.
  8. Enter the desired value in the 'NameQualifier' field.
  9. Enter the desired value in the 'OtherLanguages' field.
  10. Enter the desired value in the 'ProtectionIndicator' field.
  11. Enter the desired value in the 'ProtectionIndicatorDate' field.
  12. Enter "Client A" in the 'ClientID' field.
  13. Enter "Client A's" episode in the 'Episode' field.
  14. Enter the desired value in the "PreferredAppointmentSite" field.
  15. Click [Run].
  16. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #".
  17. Validate the 'Message' field contains: "Client Admission web service has been filed successfully".
  18. Select the client filed in the previous steps and access the 'Admission' form.
  19. Select the admission updated in the previous steps and click [Edit].
  20. Validate all populated fields are displayed.
  21. Validate the 'Client Declined To Provide Information On The Following' field contains the value entered in the previous steps.
  22. Validate the 'Mother's Maiden Name' field contains the value entered in the previous steps.
  23. Validate the 'Protection Indicator' field contains the value entered in the previous steps.
  24. Validate the 'Protection Indicator Effective Date' field contains the value entered in the previous steps.
  25. Validate the 'Name Qualifier' field contains the value entered in the previous steps.
  26. Validate the 'Other Language(s)' field contains the value entered in the previous steps.
  27. Validate the "Preferred Appointment Site" field contains the value entered in the previous steps.
  28. Close the form.
Scenario 10: 'ClientCallIntake' Web Service - Verification of 'UpdateCallIntake' Filing
Specific Setup:
  • One or more 'Call Intake' programs must be defined (via Avatar PM 'Program Maintenance' form).
  • Avatar PM Registry Setting 'Auto Assign Next ID' may be enabled or disabled.
  • Existing Avatar PM client/Call Intake record for edit via web service.
  • Application utilizing the Avatar PM 'ClientCallIntake' web service.
Steps
  1. Using Avatar PM 'ClientCallIntake' web service, submit request to 'UpdateCallIntake' method to edit existing Avatar PM Call Intake record, including value for 'SlidingFeeDivideNumFamMembers' ('Divide Sliding Fee Scale Amount by Number of Family Members Receiving Services') and 'SlidingFeeDivideNumFamMembersNum' ('Sliding Fee Scale - Number of Family Members Receiving Services'), PreferredAppointmenSite fields/segments,
  2. Confirm 'ClientCallIntake' web service responds with confirmation data/Client Unique ID on successful filing of 'UpdateCallIntake' method.
  3. Example:"<Confirmation>Client Unique ID : P26 Unique ID: CAL66110.001</Confirmation>"
  4. Confirm 'ClientCallIntake' web service responds with confirmation message on successful filing of 'UpdateCallIntake' method.
  5. Example:"<Message>Client Call Intake web service has been filed successfully.</Message>"
  6. Confirm 'ClientCallIntake' web service responds with successful status value on successful filing of 'UpdateCallIntake' method.
  7. Example:"<Status>1</Status>"
  8. Open Avatar PM 'Call Intake' form and select client/Call Intake record updated via web service for view/update.
  9. Confirm Call Intake record is updated in Avatar PM with values/data submitted via web service including 'Divide Sliding Fee Scale Amount by Number of Family Members Receiving Services' and 'Sliding Fee Scale - Number of Family Members Receiving Services', 'Preferred Appointment Site field values.
Scenario 11: Call Intake Web Service validation - ClientCallIntake
Specific Setup:
  • Any web service tool such as 'SoapUI'
  • Crystal Reports or other SQL tool.
Steps
  1. Using Avatar PM 'ClientCallIntake' web service, submit an Intake record for a 'Call Intake' client, including the 'Personal Pronouns' field and the "Preferred Appointment Site" field.
  2. Ensure that Call Intake record returns 'Client Call Intake web service has been filed successfully' message.
  3. Ensure that 'Call Intake' record/episode filed via web service is present with values filed via the web service, including the 'Personal Pronouns' and the 'Preferred Appointment Site".
Scenario 12: 'Admission (Outpatient)' - Verification of form filing
Specific Setup:
  • If custom Form Designer changes are present in 'Admission (Outpatient)' form, please use 'Form Designer' to revert to 'Netsmart Produced Changes'.
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Open Avatar PM 'Admission (Outpatient)' form.
  2. In 'Select Client' dialog, enter values for search criteria and click 'Search' button.
  3. Select existing client record to enter Admission record or click 'New Client' button to create new client record via Admission record entry.
  4. In 'Admission (Outpatient)' form, enter/select values for 'Preadmit/Admission Date', 'Preadmit/Admission Time', 'Program', 'Type of Admission', 'Admitting Practitioner' and any other required/desired fields.
  5. Navigate to 'Demographics' section of form.
  6. In 'Admission (Outpatient)' form 'Demographics' section, ensure that 'Client's Middle Initial' field is relabeled as 'Client Middle Name', and is updated to allow values/entries up to 50 characters in length.
  7. Verify that 'Communication Preference' contains the following: Email, Regular Mail, Home Phone, Text, Work Phone, Cell Phone, Do Not Contact, and Consumer Portal.
  8. Select any value in 'Communication Preference'.
  9. Select any value in "Preferred Site".
  10. Click 'Submit' button to file new Admission/episode for existing client/new client creation.
  11. In 'My Clients' Widget (or via 'Admission (Outpatient)'/'Update Client Data' forms), ensure that 'Client Middle Name', 'Communication Preference' and 'Preferred Site' values entered in 'Admission (Outpatient)' form is present.
Scenario 13: 'Pre Admit Discharge' - Verification of form filing
Specific Setup:
  • If custom Form Designer changes are present in 'Pre Admit Discharge' form, 'Client's Middle Initial'/'Client Middle Name' field label change may not be visible on update installation; in this case, any future reverting of form to 'Netsmart Produced Changes' copy (via 'Form Designer') would include this field label change
  • Client record with existing Pre Admit Discharge record or eligible for new Pre Admit Discharge record entry, where Client Demographic information includes 'Client Middle Name' value (formerly 'Client's Middle Initial')
  • Using the "Site Registration" form
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form
  • Enter hours for the staff member.
Steps
  1. Open Avatar PM 'Pre Admit Discharge' form.
  2. In 'Select Client' dialog, enter values for search criteria and click 'Search' button.
  3. Select existing client episode and click 'OK' button to enter new Pre Admit Discharge record or view/edit existing Pre Admit Discharge record.
  4. In 'Pre Admit Discharge' form, enter/select values for 'Date of Discharge', 'Discharge Time', 'Type of Discharge', 'Discharge Practitioner' and any other required/desired fields.
  5. Navigate to 'Demographics' section of form.
  6. In 'Pre Admit Discharge' form 'Demographics' section, ensure that 'Client's Middle Initial' field is relabeled as 'Client Middle Name', and is updated to display values/entries up to 50 characters in length (from current Client Demographic information).
  7. Select a site in the "Preferred Appointment Site" field.
  8. Click 'Submit' button to file Pre Admit Discharge record.
  9. Open the "Pre Admit Discharge" form.
  10. Bring up the same record and validate all fields display as they were data entered.
Scenario 14: 'Discharge' - Required/Full field validations
Specific Setup:
  • Client must be admitted to an active episode (Client A).
  • Using the "Site Registration" form:
  • Create additional sites.
  • Using the "Site Hours of Operation" button to enter in operating days/hours for the sites.
  • Using the "User Definition" form:
  • In the "Appointment Scheduling" section, give the user access to the new sites added.
  • Using the "Staff Members Hours and Exceptions" form:
  • Enter hours for the staff member.
Steps
  1. Open the "Discharge" form.
  2. Select a client to be discharged.
  3. Complete all required fields.
  4. Click [Submit]
Topics
• Admission • Update Client Data • Web Services • Pre Admit • Call Intake • Pre Admit Discharge • Discharge • Demographics • Admission (Outpatient) • NX
Update 97 Summary | Details
Compile/Edit/Post/Unpost Roll-Up Services Worklist
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Admission (Outpatient)
  • Financial Eligibility
  • Client Charge Input
  • Client Ledger
  • Compile/Edit/Post/Unpost Roll-Up Services Worklist
  • Roll-Up Services Definition
Scenario 1: Compile/Edit/Post/Unpost Roll-Up Services Worklist - Unpost Selected Roll-Up Services
Specific Setup:
  • Compile/Edit/Post/Unpost Roll-Up Services Worklist:
  • A minimum of two Roll-Up Services Worklists have been posted, containing a minimum of two clients.
  • Note the 'Roll-Up Posting Date', 'Roll-Up Dates of Service' and the client IDs.
  • Use ‘Client Ledger’ to validate that the rill-up service was created.
Steps
  1. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’.
  2. Select the ‘Unpost Selected Roll-Up Services’ section.
  3. Select desired value in ‘Select By Posting Date or Date of Service’.
  4. Enter desired value in ‘From Date’.
  5. Enter desired value in ‘To Date’.
  6. Select ‘Individual Client’ in ‘All or Individual Client’.
  7. Select the desired 'Client'.
  8. Select desired ‘Roll-Up Worklists’.
  9. Click [Select Roll-Ups to Unpost].
  10. Select desired rows in the ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’ grid.
  11. Click [Save].
  12. Click [Unpost Roll-Ups].
  13. Click [OK].
  14. Validate the date in the report and close the report.
  15. Close the form.
  16. Open ‘Client Ledger’.
  17. Process the ledger for the date range of the rolled-up services and the client that was selected to be unposted.
  18. Validate that the services are not rolled-up.
  19. Close the report.
  20. Process the ledger for the date range of the rolled-up services and the client that was not selected to be unposted.
  21. Validate that the services are rolled-up.
  22. Close the report.
  23. Close the form.
Scenario 2: Registry Setting - Allow Roll-Up Rule Selection During Compile - Single and Group Roll-Ups
Specific Setup:
  • Registry Setting: Allow Roll-Up Rule Selection During Compile has a value of ‘172’.
  • This value indicates that the option to select either individual or group 'Roll-Up Services Definitions' will be included on the form.
  • When an individual definition is selected the user will be unable to select a group definition, or when a group definition is selected the user will be unable to select an individual definition.
  • Roll-Up Services Definition:
  • At a minimum, two single and two group roll-up definitions exist. Note the component service codes and any requirements.
  • In the group definitions:
  • If 'No' is selected, each roll-up rule is compiled in the specified order of execution, then the entire compile is posted. This is the default behavior for roll-up processing.
  • If 'Yes' is selected, each roll-up rule is compiled and posted in order of execution before the next roll-up rule is compiled.
  • At a minimum, services that meet a single roll-up definition, and services that will meet a group definition, exist for a minimum of one client. Note the client ID. Note the dates of service.
Steps
  1. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’.
  2. Verify that the fields ‘Roll-Up Definitions’ and ‘Roll-Up Group’ are enabled.
  3. Enter the desired ‘From Date’ and ‘To Date’.
  4. Select a value in ‘Roll-Up Definitions’.
  5. Validate that no value can be selected in ‘Roll-Up Group’.
  6. Click [Compile Worklist].
  7. Click [OK].
  8. Select the ‘Post Roll-Up Services Worklist’ section.
  9. Select the desired ‘Through Date’.
  10. Select the desired 'Write Off Posting Code’.
  11. Click [Post Worklist].
  12. Click [OK].
  13. Close the form.
  14. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’
  15. Click [Process] and validate that the services for the rules within the rule group have the value of ‘Roll-Up’ in ‘CLAIM NUMBER’. Validate that the service created from the roll-up process has a value of ‘OPEN’ in ‘CLAIM NUMBER’.
  16. Close the report.
  17. Close the form.
  18. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’.
  19. Enter the desired ‘From Date’ and ‘To Date’.
  20. Select a value in ‘Roll-Up Group’.
  21. Validate that no value can be selected in ‘Roll-Up Definitions’.
  22. Click [Compile Worklist].
  23. Click [OK].
  24. If the group definition is set to roll-up the definition individually, the compile will be posted.
  25. If the group definition is not set to roll-up the definition individually, the compile will not be posted. Post the compile.
  26. Close the form.
  27. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’
  28. Click [Process] and validate that the services for the rules within the rule group have the value of ‘Roll-Up’ in ‘CLAIM NUMBER’. Validate that the service created from the roll-up process has a value of ‘OPEN’ in ‘CLAIM NUMBER’.
  29. Close the report.
  30. Close the form.
Topics
• Compile/Edit/Post/Unpost Roll-up Services Worklist • Roll-Up Services Definition • NX
Update 98 Summary | Details
'Service Codes' Form - 'Always Allow Overbooking' field
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Service Code Upload Process
  • Service Codes
  • Service Code Upload Accepted Codes
  • Service Code Upload Rejected Codes
  • Crystal Report Viewer
Scenario 1: 'Service Code Upload Process' - Upload Provider Only Service Code
Specific Setup:
  • Avatar PM Service Code Upload file for upload containing a valid row that includes "Provider" as the value for 'Service Provided By' and a value for 'Always Allow Overbooking' (File A).
Steps
  1. Access the 'Service Code Upload Process' form.
  2. Click [Select File].
  3. Select "File A" click [Open].
  4. Select "Compile" in the 'Compile Or Post' field.
  5. Select "No" in the 'Override Existing Service Codes' field.
  6. Click [Submit].
  7. Validate a message is displayed stating: Compile Completed. To view results review accepted and rejected reports.
  8. Click [OK] and leave the form opened.
  9. Access the 'Service Code Upload Accepted Codes' form.
  10. Select "File A" in the 'Select Desired Service Code Import File Name' field.
  11. Click [Process].
  12. Validate "File A" contents are displayed in the report.
  13. Validate the 'Always Allow Overbooking' field is populated with the value defined in the file.
  14. Close the report and the form.
  15. Navigate back to the 'Service Code Upload Process' form.
  16. Select "Post" in the 'Compile Or Post' field.
  17. Click [Submit].
  18. Validate a message is displayed stating: Posting completed.
  19. Click [OK] and close the form.
  20. Access the 'Service Codes' form.
  21. Select "Edit" in the 'Add New Or Edit Existing' field.
  22. Select the service code uploaded in the previous steps in the 'Service Code' field.
  23. Validate 'Always Allow Overbooking' field contains the uploaded value.
  24. Validate all other information displays as expected.
  25. Close the form
  26. Access Crystal Reports or other SQL reporting tool.
  27. Create a report using the 'SYSTEM.batchload_tx_accepted' SQL table.
  28. Validate a row is displayed for the service code uploaded in the previous steps.
  29. Validate the 'alwoverbook_code' field contains the uploaded value.
  30. Validate the 'alwoverbook_value' field contains the uploaded value.
  31. Close the report.
Scenario 2: 'Service Codes' - Add a Provider Only Service Code
Specific Setup:
  • Must have access to Crystal Reports or other SQL Reporting Tool.
Steps
  1. Access the 'Service Codes' form.
  2. Select "Add" in the 'Add New Or Edit Existing' field.
  3. Validate the 'Clinic Hours' field is displayed and disabled.
  4. Validate the 'Always Allow Overbooking' field is displayed and disabled.
  5. Populate the required and desired fields.
  6. Select "Provider" in the 'Service Required By' field.
  7. Validate the 'Clinic Hours' and 'Always Allow Overbooking' fields are now enabled. Note: These fields will only be enabled when "Provider" is selected in the 'Service Required By' field.
  8. Select "Yes" in the 'Clinic Hours' field.
  9. Select "Yes" in the 'Always Allow Overbooking' field.
  10. Click [Submit].
  11. Access Crystal Reports or other SQL reporting tool.
  12. Create a report using the 'SYSTEM.billing_tx_master_table' SQL table.
  13. Validate a row is displayed for the service code filed in the previous steps.
  14. Validate the 'clinic_hours_code' field contains "Y".
  15. Validate the 'clinic_hours_value' field contains "Yes".
  16. Validate the 'alwoverbook_code' field contains "Y".
  17. Validate the 'alwoverbook_value' field contains "Yes".
  18. Access the 'Service Codes' form.
  19. Select "Edit" in the 'Add New Or Edit Existing' field.
  20. Select the service code filed in the previous steps.
  21. Validate "Yes" is selected in the 'Clinic Hours' field.
  22. Select "No" in the 'Always Allow Overbooking' field.
  23. Click [Submit].
  24. Access Crystal Reports or other SQL reporting tool.
  25. Refresh the report using the 'SYSTEM.billing_tx_master_table' SQL table.
  26. Validate the 'alwoverbook_code' field contains "N".
  27. Validate the 'alwoverbook_value' field contains "No".
  28. Close the report.
Topics
• Service Codes • Service Code Upload Process
Update 101 Summary | Details
Accounts Receivable Console
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • AR Console export Form
Scenario 1: AR Console Export - Form and workflow validation
Specific Setup:
  • User Definition: The tester has been given access to all forms in this path: ‘Avatar PM > Billing > AR Management’.
  • Process 'Refresh Forms'.
  • AR Console Configuration: Form has been defined.
  • Claims: Claims with unpaid balances exists.
  • System Task Scheduler: Auto AR Batch Update has been processed.
Steps
  1. Open ‘AR Console Export’.
  2. Validate that the ‘AR Console Data to Export’ field defaults to ‘All’.
  3. Validate that only the ‘Export to CSV’ button is enabled.
  4. Click the ‘Export to CSV’ button.
  5. Validate that the file is created and available to download,
  6. Download the file.
  7. Open the file and validate that the file is a comma delimited text file that contains data for unpaid claims.
  8. In ‘AR Console Export’, change ‘ AR Console Data to Export’ to ‘Selected Values’.
  9. Validate that ‘Financial Class Selection’ and ‘Treatment Setting Selection’ are enabled and not required.
  10. Validate that ‘Guarantors’ and ‘Programs’ are enabled and required.
  11. Select a ‘Financial Class Selection’ that contains more than one ‘Guarantor’.
  12. Validate that only guarantors/payors in that class display in ‘Guarantors’.
  13. Select one value in ‘Guarantors’.
  14. Select one ‘Treatment Setting Selection’.
  15. Validate that only programs in that setting display in ‘Programs’.
  16. Select one value in ‘Programs’.
  17. Click the ‘Export to CSV’ button.
  18. Validate that the file is created and available to download,
  19. Download the file.
  20. Open the file and validate that the file contains claims for the selected guarantor and program.
  21. Close the form.
Topics
• Accounts Receivable Management • NX
Update 109 Summary | Details
Remittance Functionality
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Client Ledger
  • Create Interim Billing Batch File
  • Remittance Processing Widget
  • Quick Billing Rule Definition
  • Quick Billing
Internal Test Only
Topics
• Remittance Processing • NX
Update 125 Summary | Details
Remittance Processing widget
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Remittance Processing Widget
Scenario 1: Remittance Processing Widget - SQL Table 'SYSTEM.remittance_batch' Validation.
Steps

Internal Testing Only
Topics
• Remittance Processing • NX • Widgets • Spreadsheet Batch Remittance Posting
Update 127 Summary | Details
'ClientDischarge' and 'ClientPreAdmitDischarge' web services
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Discharge
  • Pre Admit Discharge
Scenario 1: Discharge a client via the 'ClientDischarge' web service
Specific Setup:
  • A client is enrolled in an existing episode (Client A).
  • Must have access to SoapUI or other web service tool.
Steps
  1. Access SoapUI for the 'ClientDischarge' - 'DischargeClient' web service.
  2. Enter the system code that will be used to log into Avatar in the 'SystemCode' field.
  3. Enter the user name that will be used to log into Avatar in the 'UserName' field.
  4. Enter the password that will be used to log into Avatar in the 'Password' field.
  5. Enter the desired date in the 'DateOfDischarge' field.
  6. Enter the desired practitioner in the 'DischargePractitioner' field.
  7. Enter the desired time in the 'DischargeTime' field.
  8. Enter the desired value in the 'TypeOfDischarge' field.
  9. Enter "Client A" in the 'ClientID' field.
  10. Enter the episode number to be discharged in the 'EpisodeNumber' field.
  11. Click [Run].
  12. Validate the 'Message' field contains: Client Discharge web service has been filed successfully.
  13. Select "Client A" and access the 'Discharge' form.
  14. Validate all populated fields are displayed as entered in the web service.
  15. Close the form.
Scenario 2: Discharge a client via the 'ClientPreAdmitDischarge' web service
Specific Setup:
  • A client is enrolled in an existing Pre Admit episode (Client A).
  • Must have access to SoapUI or other web service tool.
Steps
  1. Access SoapUI for the 'ClientPreAdmitDischarge' - 'PreAdmitDischargeClient' web service.
  2. Enter the system code that will be used to log into Avatar in the 'SystemCode' field.
  3. Enter the user name that will be used to log into Avatar in the 'UserName' field.
  4. Enter the password that will be used to log into Avatar in the 'Password' field.
  5. Enter the desired date in the 'DateOfDischarge' field.
  6. Enter the desired practitioner in the 'DischargePractitioner' field.
  7. Enter the desired time in the 'DischargeTime' field.
  8. Enter the desired value in the 'TypeOfDischarge' field.
  9. Enter "Client A" in the 'ClientID' field.
  10. Enter the Pre Admit episode number to be discharged in the 'EpisodeNumber' field.
  11. Click [Run].
  12. Validate the 'Message' field contains: Client Discharge web service has been filed successfully.
  13. Select "Client A" and access the 'Pre Admit Discharge' form.
  14. Validate all populated fields are displayed as entered in the web service.
  15. Close the form.
Topics
• Discharge • Web Services • Pre Admit Discharge
 

Avatar_PM_2023_Monthly_Release_2023.02.02_Details.csv