Avatar PM 2023 Quarterly Release 2023.03 Acceptance Tests

Last updated
Save as PDF

Update 1 Summary \| Details Avatar PM 2023 is Installed Scenario 1: Validate Upgrading Avatar PM 2022 to 2023 is successful when 2022.04.00 is loaded Specific Setup: Latest Monthly Release is installed. Steps Open the "Product Updates" form. Select the appropriate [Namespace] from the Application dropdown list Click [Select Update/Customization Pack]. Browse to the location for the updates and select the Update 1. Click [OK] on the "File Upload Complete" window. Click [Review Update/Customization Pack Contents]. Verify Update 1 is included. Click [Install Update/Customization Pack]. Click [OK] when the install completes. Click [Close Form].	Topics • Upgrade
Update 2 Summary \| Details Roll-Up service definition - Component modifiers Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Compile/Edit/Post/Unpost Roll-Up Services Worklist Service Codes Financial Eligibility Roll-Up Services Definition Posting/Adjustment Codes Definition SQL Query/Reporting Scenario 1: Compile/Edit/Post/Unpost Roll-Up Services Worklist - 'Do Not Include Component Modifiers in Roll-Up Service' registry setting = 'Y' Specific Setup: Registry Setting: The 'Do Not Include Component Modifiers in Roll-Up Service' registry setting is set to 'Y'. Posting/Adjustment Code Definition: An existing Write off posting code is identified or a new posting code is created to use for Write-Off Posting code. Service Codes: At least one Roll-Up and two component service codes are created. Note the service codes. Service Fee/Cross Reference Maintenance: A fee definition is created for each service code. Admission: An existing client is identified or a new client is admitted. Note the client id, Admission date/program. Diagnosis: A diagnosis record is created for the client. Financial Eligibility: An existing guarantor is assigned to the client. Note the guarantor code/name. Roll-Up Definition: Edit an existing or create a new 'Roll-Up Services Definition' with the following criteria: A 'Roll-Up Description'. A 'Roll-Up Service'. Component Services. 'Is This Roll-Up Service Dependent On Units, Duration Or None' = None. A value is entered in 'Minimum Duration Required'. A value is entered in 'Maximum Duration' that is greater than the value in 'Minimum Duration Required'. A value is selected in 'Calculate Unit Charge By'. A value is entered in 'Component Service Date Rules'. 'Date Of First Component Service' is selected in 'Date Of Service For Roll-Up Service'. 'Date Of First Component Service' is selected in 'Date To Bill Roll-Up Service'. Client Charge Input: A minimum of two component services have been rendered with the same modifiers to the client that will meet the 'Component Service Date Rules'. Note the service date and service code. Client Ledger: The services distributed correctly to the guarantor assigned to the client. Steps Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Verify that the fields ‘Roll-Up Definitions’ and ‘Roll-Up Group’ are enabled. Enter the desired ‘From Date’ and ‘To Date’. Select a Roll-Up definition created during setup in the ‘Roll-Up Definitions’. Validate that no value can be selected in ‘Roll-Up Group’. Click [Compile Worklist]. Click [OK]. Close the form. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Select the ‘Post Roll-Up Services Worklist’ section. Select the desired ‘Through Date’. Select the desired 'Write Off Posting Code’. Click [Post Worklist]. Click [OK]. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. Close the form. Open the 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_tx_history' table. Verify the modifiers included with the component service are not included with the Roll-Up service. Scenario 2: Compile/Edit/Post/Unpost Roll-Up Services Worklist - 'Do Not Include Component Modifiers in Roll-Up Service' registry setting = N Specific Setup: Registry Setting: The 'Do Not Include Component Modifiers in Roll-Up Service' registry setting is set to 'N'. Service Codes: At least one Roll-Up and two component service codes are created. Note the service codes. Service Fee/Cross Reference Maintenance: A fee definition is created for each service code. Admission: An existing client is identified or a new client is admitted. Note the client id, Admission date/program. Diagnosis: A diagnosis record is created for the client. Financial Eligibility: An existing guarantor is assigned to the client. Note the guarantor code/name. Roll-Up Definition: Edit an existing or create a new 'Roll-Up Services Definition' with the following criteria: A 'Roll-Up Description'. A 'Roll-Up Service'. Component Services. 'Is This Roll-Up Service Dependent On Units, Duration Or None' = None. A value is entered in 'Minimum Duration Required'. A value is entered in 'Maximum Duration' that is greater than the value in 'Minimum Duration Required'. A value is selected in 'Calculate Unit Charge By'. A value is entered in 'Component Service Date Rules'. 'Date Of First Component Service' is selected in 'Date Of Service For Roll-Up Service'. 'Date Of First Component Service' is selected in 'Date To Bill Roll-Up Service'. Client Charge Input: A minimum of two component services have been rendered to the client that will meet the 'Component Service Date Rules'. Desired value entered to the 'Modifier' field of all the component services. Note the service date/code and modifier entered for each of the service. Client Ledger: The services distributed correctly to the guarantor assigned to the client. Steps Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Verify that the fields ‘Roll-Up Definitions’ and ‘Roll-Up Group’ are enabled. Enter the desired ‘From Date’ and ‘To Date’. Select a Roll-Up definition created during setup in the ‘Roll-Up Definitions’. Validate that no value can be selected in ‘Roll-Up Group’. Click [Compile Worklist]. Click [OK]. Select the ‘Post Roll-Up Services Worklist’ section. Select the desired ‘Through Date’. Select the desired 'Write Off Posting Code’. Click [Post Worklist]. Click [OK]. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. Close the form. Open the 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_tx_history' table. Verify the modifiers included with the component service are included with the Roll-Up service when all the component services have same modifiers. Scenario 3: Compile/Edit/Post/Unpost Roll-Up Services Worklist - 'Do Not Include Component Modifiers in Roll-Up Service' registry setting - Group Roll-Up definition Specific Setup: Registry Setting: The 'Do Not Include Component Modifiers in Roll-Up Service' registry setting is set to 'Y'. Allow Roll-Up Rule Selection During Compile has a value of ‘2’. Service Codes: At least two Roll-Up and two component service codes for each roll-up service code are created. Note the service codes. Service Fee/Cross Reference Maintenance: A fee definition is created for each service code. Admission: An existing client is identified or a new client is admitted. Note the client id, Admission date/program. Diagnosis: A diagnosis record is created for the client. Financial Eligibility: An existing guarantor is assigned to the client. Note the guarantor code/name. Roll-Up Definition: Edit an existing or create at least two new 'Roll-Up Services Definition' with the following criteria. Open the 'Roll-Up Services Definition' section, select edit and note the value of 'Existing Roll-Up Definition' for at least two definition. A 'Roll-Up Description'. A 'Roll-Up Service'. Component Services. 'Is This Roll-Up Service Dependent On Units, Duration Or None' = None. A desired value is entered in 'Minimum Duration Required'. A desired value is entered in 'Maximum Duration' that is greater than the value in 'Minimum Duration Required'. A desired value is selected in 'Calculate Unit Charge By'. A desired value is entered in 'Component Service Date Rules'. A desired value is selected in 'Date Of Service For Roll-Up Service'. A desired value is selected in 'Date To Bill Roll-Up Service'. Open the 'Roll-Up Group Definition' section: A 'Roll-Up Group Definitions' is created. Select desired value in the ‘Post Roll-Up Rule Individually’. Client Charge Input: At a minimum, services that meet group roll-up definition exist for a minimum of one client. Note the client ID. Note the dates of service. Client Ledger: The services distributed correctly to the guarantor assigned to the client. Steps Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Verify that the only roll-up definitions that can be selected are group definitions. Enter the desired ‘From Date’ and ‘To Date’ for the group definition with a value of 'Yes' in ‘Post Roll-Up Rule Individually’. Select the group definitions with a value of 'Yes' in ‘Post Roll-Up Rule Individually’. Click [Compile Worklist]. Click [OK]. Based on the light bulb message when 'Yes' is in ‘Post Roll-Up Rule Individually’, each roll-up rule is compiled and posted in order of execution before the next roll-up rule is compiled. This means that the user does not use the 'Post Roll-Up Services Worklist' section of the form. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. Close the form. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Enter the desired ‘From Date’ and ‘To Date’ for the group definition with a value of 'No' in ‘Post Roll-Up Rule Individually’. Select the group definitions with a value of 'Yes' in ‘Post Roll-Up Rule Individually’. Click [Compile Worklist]. Click [OK]. Based on the light bulb message when 'No' is in ‘Post Roll-Up Rule Individually’, each roll-up rule is compiled in the specified order of execution, then the entire compile is posted. Select the ‘Post Roll-Up Services Worklist’ section. Select the desired ‘Through Date’. Click [Post Worklist]. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. Close the form. Open the 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_tx_history' table. Verify the modifiers included with the component service are not included with the Roll-Up service. Scenario 4: Registry setting validation - Do Not Include Component Modifiers in Roll-Up Service Steps Open the 'Registry Setting' form. Set the 'Limit Registry Settings to the Following Search Criteria' input box to "Do Not Include Component Modifiers in R" Click [View Registry Settings]. Validate the Registry Setting input box contains "Avatar PM->Billing->Roll-Up Billing->->->Do Not Include Component Modifiers in Roll-Up Service" Validate the Registry Setting Details text area contains "[FACILITY SPECIFIC] -------------------------------------------------------------------------------When set to 'Y' Roll-Up Services will not include the component Modifiers. Select 'N' for the default functionality." Set the Registry Setting Value input box to "0". Verify the error dialog contains "The selected value is not valid in the current system code for the following reason: Invalid Response - Example: 'Y' or 'N'. Click the [OK]. Set the Registry Setting Value input box to "1". Validate the error dialog contains "The selected value is not valid in the current system code for the following reason: Invalid Response - Example: 'Y' or 'N'. Set the Registry Setting Value input box to "NO" Click [Submit]. Validate the error dialog contains 'The selected value is not valid in the current system code for the following reason: More than 1 characters'. Click [OK]. Set the Registry Setting Value input box to "Yes" Validate the error dialog contains 'The selected value is not valid in the current system code for the following reason: More than 1 characters'. Click [OK]. Set the Registry Setting Value input box to "X". Validate the error dialog contains "The selected value is not valid in the current system code for the following reason: Invalid Response - Example: 'Y' or 'N'. Click [OK]. Set the Registry Setting Value input box to "". Click [Submit]. Validate the Filing Error dialog contains "The following fields are missing: Registry Setting Value" Click [OK]. Set the Registry Setting Value input box to "N". Click [Submit]. Validate the Filing Results text area contains "Results filing value N to Avatar PM->Billing->Roll-Up Billing->->->Do Not Include Component Modifiers in Roll-Up Service Successful filing in System Code SBOX." Click [OK]. Set the Registry Setting Value input box to "Y". Click [Submit]. Validate the Filing Results text area contains "Results filing value N to Avatar PM->Billing->Roll-Up Billing->->->Do Not Include Component Modifiers in Roll-Up Service Successful filing in System Code SBOX." Click [OK]. Validate the Form Return dialog contains 'Registry Settings has completed. Do you wish to return to form?'. Click the [No].	Topics • Compile/Edit/Post/Unpost Roll-up Services Worklist • Roll-Up Services Definition • NX • Registry Settings
Update 5 Summary \| Details SYTEM.billing_guar_table - Require Subscriber Group Number Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form and Table Documentation (PM) SQL Query/Reporting Financial Eligibility Service Codes Electronic Billing Scenario 1: 837 Professional - Validating ‘Require Group #’ workflow of the 'Guarantors/Payor' - Guarantor assignment through 'Financial Eligibility' form. Specific Setup: Guarantors/Payors: A new guarantor is created or an existing guarantor is identified. The 'Require Group #' field is set to "No". Note the guarantor code/name to be used during creating financial eligibility record for the client. Admission: The client is admitted to the outpatient program or an existing outpatient client is identified. Note client id/name and admission date/program. Diagnosis: An admission diagnosis record is created for the client. Financial Eligibility: The guarantor identified above is assigned to the client. The 'Subscriber Group #' field is not marked as a required field in the form for the guarantor. Leave the 'Subscriber Group #' field blank. Service Codes: An existing professional service code is identified. Note the service code. Service Fee/Cross reference maintenance: Make sure the fee definition is created for the service code and CPT code is assigned to the service code. Client Charge Input: A service is rendered to the client in the first episode. Be sure to use service codes that are covered by the benefit plan (insurance charge category). Note the date of the service. Close Charges: Charges are closed. Client Ledger: Verify the charges are correctly distributed to the desired guarantor, and they are in 'Unbill' status. Create Interim Billing Batch: An interim billing batch is created to cover the client, guarantor and services rendered to the client. Note the interim billing batch number and name. Steps Open an 'Electronic Billing' form. Compile an '837 Professional' bill for the interim batch created in the setup section. Verify the bill compiles successfully. Review the dump file. Verify the dump file includes the service(s) rendered to the client correctly. Open the 'Guarantors/Payor' form. Set the 'Require Group #' field to "Yes". Open an 'Electronic Billing' form. Compile an '837 Professional' bill for the interim batch created in the setup section. Verify the bill does not compile successfully. Review the error report. Verify the report displays the 'Missing Subscriber Group #' error on the report for the guarantor/client/service. Open the 'Financial Eligibility' form for the client. Verify the 'Subscriber Group #' field is marked as required field. Make sure the 'Subscriber Group #' field is empty. Submit the form. Verify the missing field error message for the 'Subscriber Group #' field. Enter desired group number in the 'Subscriber Group #' field. Submit the form. Open an 'Electronic Billing' form. Compile an '837 Professional' bill for the interim batch created in the setup section. Verify the bill compiles successfully. Claim the service. Review the dump file. Verify the dump file includes the service rendered to the client correctly. Verify the SBR segment contains the 'Subscriber Group #' assigned to the client from the 'Financial Eligibility' form. Close the form. Open the 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_guar_table' sql table. Verify the req_sub_group_num_code and req_sub_group_num_value columns are added to the table and displays correct data from the 'Guarantors/Payors' form for the identified guarantor. Query the 'SYSTEM.billing_guar_subs_data' table. Verify the 'subs_group' field populated with the 'Subscriber Group #' field from the 'Financial Eligibility' form. Program Transfer - Inpatient and outpatient episode Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Program Transfer Program Transfer (OutPatient) Scenario 1: Program Transfer - Validating program transfer for an inpatient and outpatient episode Specific Setup: Admission: A new inpatient client is admitted or an existing inpatient client is identified. Note the client id/name, admission date/admission program. A new outpatient client is admitted or an existing outpatient client is identified. Note the client id/name, admission date/admission program. Steps Select the 'Program Transfer' form. Select the inpatient client identified in the setup section. Validate the 'Program Transferred From' field contains the admission program of the client. Select desired program different from the admission program in the 'Program' field. Enter desired date in the 'Date Of Transfer' field. Enter desired time in the 'Time Of Transfer' field. Select desired 'Unit'. Select desired 'Room'. Select desired 'Bed' Click [Submit]. Verify the form submits successfully. Verify the client transferred to the correct program. Select the 'Program Transfer (Outpatient)' form. Select the outpatient client identified in the setup section. Validate the 'Program Transferred From' field contains the admission program of the client. Select desired program different from the admission program in the 'Program' field. Enter desired date in the 'Date Of Transfer' field. Enter desired time in the 'Time Of Transfer' field. Click [Submit]. Verify the form submits successfully. Verify the client transferred to the correct program.	Topics • Guarantor/Payors • Database Tables • Program Transfer
Update 6 Summary \| Details The 'Disable Demographics Section On Discharge Form' registry setting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Discharge Scenario 1: Registry Setting - Disable Demographics Section On Discharge Form Specific Setup: A client must have an active episode (Client A). Steps Access the 'Registry Settings' form. Enter "Disable Demographics Section on Discharge Form" in the 'Limit Registry Settings to the Following Search Criteria ' field. Click [View Registry Settings]. Validate that the 'Registry Setting' field is equal to "Avatar PM->Client Information->Client Demographics->->->Disable Demographics Section On Discharge Form". Enter "N" in the 'Registry Setting Value' field. Click [Submit] and close the form. Select "Client A" and access the 'Discharge' form. Enter the required details in the 'Discharge' section. Select the 'Demographics' section. Validate fields in the 'Demographics' section are not disabled. Close the form. Select "Client A" and access the 'Admission' form. Select the 'Demographics' section. Validate fields in the 'Demographics' section are not disabled. Close the form. Access the 'Registry Settings' form. Enter "Disable Demographics Section on Discharge Form" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate that the 'Registry Setting' field is equal to "Avatar PM->Client Information->Client Demographics->->->Disable Demographics Section On Discharge Form". Enter "Y" in the 'Registry Setting Value' field. Click [Submit] and close the form. Log out of the application and log back in. Select "Client A" and access the 'Discharge' form. Select the 'Demographics' section. Validate all fields are disabled. Close the form. Select "Client A" and access the 'Admission' form. Select the 'Demographics' section. Validate fields in the 'Demographics' section are not disabled. Close the form.	Topics • Registry Settings • Admission • Discharge
Update 7 Summary \| Details Web services - WEBSVC.AppointmentScheduling V2 Scenario 1: Load & Go update - Verify successful installation Steps Internal Testing Only	Topics • Web Services • Problem List
Update 8 Summary \| Details Avatar PM 'Summary Trial Balance Report' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Summary Trial Balance Report Scenario 1: 'Summary Trial Balance Report' - Verification of report results Steps Open Avatar PM 'Summary Trial Balance Report' form (under 'Avatar PM / Billing / Billing Reports / Monthly Closeout Reports' menu). Enter/select values for 'Summary Balance As Of ', 'Aging Category' and 'Include Bad Debt Information' report criteria fields. Click 'Process' button to run report/render result data. Ensure that 'Summary Trial Balance Report' results are rendered/displayed in the default report format within myAvatar/Avatar NX. In 'Summary Trial Balance Report' results display, ensure that the following information fields are present: 'Run Date' (current date) 'As Of' (from 'Summary Balance As Of' report criteria field) 'Revenue Group' 'Unbilled' report information 'Financial Class' 'In-House' (with dollar values) 'Disc' (discharged; with dollar values) 'Days' (with value) 'Total'/'Totals' (with dollar values) 'Billed' report information 'Financial Class' Aging Categories (default or custom entered/edited values as defined in 'Aging Category' report criteria field; '0', '30', '120', etc; with dollar values) 'Total'/'Totals' (with dollar values) Ensure that 'Summary Trial Balance Report' results display includes information/dollar values for all fields/groupings noted above with expected values based on unbilled/billed services and payments present in Avatar PM system for selected 'Summary Balance As Of' report criteria date, including 'Total'/'Totals' calculated values. Ensure that Summary Trial Balance Report' results display includes 'ALL' Revenue Group summary information (summary totals for report information); ensure that 'ALL' Revenue Group summary information includes information/dollar values for all fields/groupings noted above display with expected values based on unbilled/billed services and payments present in Avatar PM system for selected 'Summary Balance As Of' report criteria date, including 'Total'/'Totals' calculated values. In 'Summary Trial Balance Report' results display, click 'Print All Pages', 'Print Page', 'Export All Pages' and/or 'Export Page' button to print or export/save report data as desired. Click 'Close' button to close 'Summary Trial Balance Report' results display. Scenario 2: 'Summary Trial Balance Report' - Verification of .CSV format report results Steps Open Avatar PM 'Summary Trial Balance Report' form (under 'Avatar PM / Billing / Billing Reports / Monthly Closeout Reports' menu). Enter/select values for 'Summary Balance As Of ', 'Aging Category' and 'Include Bad Debt Information' report criteria fields. Ensure 'Export Detail Information to CSV' field is present in form, with 'Yes' checkbox/selection available. No selection in the 'Export Detail Information to CSV' field will render report results in the default report format Selecting 'Yes' in the 'Export Detail Information to CSV' field will display report results in CSV (comma-separated value) format (allowing user to export/save 'Summary Trial Balance Report' results for external use) Click 'Process' button to run report/render result data. If no value is selected in 'Export Detail Information to CSV' field, ensure that 'Summary Trial Balance Report' results are rendered/displayed in the default report format. If 'Yes' is selected for 'Export Detail Information to CSV' field, ensure that 'Summary Trial Balance Report' results are rendered/displayed in .CSV format within myAvatar/Avatar NX, with following header and individual data rows present: 'Summary Trial Balance Report' .CSV format data header (first row in report data results) will contain the following data elements: 'RRG' 'RRG Description' 'Financial Class' 'Financial Class Description' 'Unbilled In-House' 'Unbilled Disch' 'Days' Aging Categories (default or custom entered/edited values as defined in 'Aging Category' report criteria field; 'Aging 0', 'Aging 30', 'Aging 60', 'Aging 120', etc.) Header row examples: "RRG,RRG Description,Financial Class,Financial Class Description,Unbilled In-House,Unbilled Disch,Days,Billed/Aging Category 0,Billed/Aging Category 30,Billed/Aging Category 60,Billed/Aging Category 90,Billed/Aging Category 120,Total" "RRG,RRG Description,Financial Class,Financial Class Description,Unbilled In-House,Unbilled Disch,Days,Billed/Aging Category 5,Billed/Aging Category 10,Billed/Aging Category 20,Billed/Aging Category 30,Billed/Aging Category 40,Billed/Aging Category 50,Billed/Aging Category 60,Total" 'Total' 'Summary Trial Balance Report' .CSV format individual data rows (second and all subsequent rows in report data results) will contain report data for each element, one row per result. Data row examples: "5,Outpatient Substance Abuse,7,Medicare Part A,2397.15,0.00,0,1181.21,0.00,0.00,0.00,815.00,4393.36" "8,Outpatient Psychiatric,3,Blue Cross,1176903.89,0.00,0,1476.11,0.00,0.00,0.00,0.00,0.00,12365.15,1190745.15" "IP,Inpatient Psychiatric,10,Non-Recoverable,18635.12,6000.50,0,3360.52,88.00,1500.00,200.00,6526.80,40022.44" In 'Summary Trial Balance Report' results display, click 'Export All Pages' or 'Export Page' button to export/save .CSV format report data to file. Open/review exported .CSV format file, ensuring that data header and all individual data rows are present in file as displayed/defined above.	Topics • Summary Trial Balance Report
Update 9 Summary \| Details Quick Billing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Purge Billing Files Quick Billing Rule Definition Quick Billing Scenario 1: Quick Billing workflow for existing unbilled services Specific Setup: Quick Billing Rule Definitions exist that allows the system to bill many services. Unbilled services exist in the system that can be billed through the definitions. Note the dates of service. Steps Open ‘Quick Billing’. Select ‘Add New’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter desired value in ‘First Date Of Service To Include’. Enter desired value in ‘Last Date Of Service To Include’. Select desired value in ‘Billing Rule Group To Execute’ or ‘Billing Rule To Execute’. Select values in ‘Quick Billing Tasks to Execute’. Click [Submit]. Validate that the ‘Compile Complete’ message is received. Print the 837 report and validate the data.	Topics • Quick Billing • NX
Update 10 Summary \| Details Avatar PM 'Enable Submitter Identification Definition' Registry Setting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Submitter Identification Definition Electronic Billing Scenario 1: 'Submitter Identification Definition' - Form Verification Specific Setup: Avatar PM Registry Setting 'Enable Submitter Identification Definition' must be enabled/include value '3' Crystal Reports or other SQL reporting tool Steps Open Avatar PM 'Submitter Identification Definition' form (under 'Avatar PM / System Maintenance / System Definition' menu). Select value in 'Program' field. Select 'Add' in 'Add or Edit' field (or select 'Edit' and click 'Select Existing Submitter Identification Definition' button to select/view/update existing definition entry). Enter value for 'Effective Date' (and 'Expiration Date' if desired). Enter/select value in 'Guarantor' field. Enter/select value in 'Client' field if Submitter Identification Definition entry should be client-specific. If 'Client' value is defined, Submitter Identification Definition entry will apply only to services for selected client in Electronic Billing 837 file sorting/creation Ensure the following 'Authorization Number' Submitter Identification criteria field is present in 'Submitter Identification Definition' form where Avatar PM Registry Setting 'Enable Submitter Identification Definition' includes configuration value '3': Enter/select value in 'Authorization Number' field if Submitter Identification Definition entry should be Managed Care Authorization-specific or Payor Based Authorization-specific. If 'Authorization' value is defined, Submitter Identification Definition entry will apply only to services valid for selected Managed Care Authorization or Payor Based Authorization in Electronic Billing 837 file sorting/creation Note - Submitter Identification Definition requirement for Authorization is only applicable where Authorization is required for Electronic Billing service inclusion (via Avatar PM 'Guarantors/Payors' form 'Authorization Information' section for selected Guarantor). Enter/select service code(s) for Submitter Identification Definition in 'Service Code' field. Ensure the following 837 Submitter Identification Information fields are present in 'Submitter Identification Definition' form where Avatar PM Registry Setting 'Enable Submitter Identification Definition' includes configuration value '3': 'Program Taxonomy 2000A-PRV-03' 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' 'Billing Provider Primary Identification # (2010AA-NM1-09)' 'Billing Provider Secondary Identification Number (2010BB-REF-02)' 'Facility Identification Code Qualifier (837P-2310C / 837P-2420C / 837I-2310E-NM1-08)' 'Facility Identification Code (837P-2310C / 837P-2420C / 837I-2310E-NM1-09)' 'Facility Reference Identification Qualifier (837P-2310C / 837P-2420C / 837I-2310E-REF-01)' 'Facility Reference Identification (837P-2310C / 837P-2420C / 837I-2310E-REF-02)' Enter desired values for 837 Submitter Identification Information fields listed above (as well as 'Submitter Identification Code Qualifier', 'Submitter Identification Number' and 'Billing Provider Secondary ID Code Qualifier' fields as required/desired). Click 'File Definition' button to file/save Submitter Identification Definition entry. Ensure user is presented with confirmation dialog noting 'Definition Filed'; click 'OK' button to return to form. Select same/previously used value in 'Program' and/or 'Guarantor' fields. Select 'Edit' in 'Add or Edit' field and click 'Select Existing Submitter Identification Definition' button to select/view previously filed Submitter Identification Definition entry. Ensure all fields are populated with/display previously entered and filed values (including Submitter Identification Information fields listed above). Click 'Display Submitter Identification Definitions' button to open report for display of Submitter Identification Definition entries (for selected Program and/or Guarantor if value selected in form, or for all Programs/Guarantors if no criteria values). In the 'Display Submitter Identification Definitions' report display/results, ensure that Submitter Identification Definition entry/information values are displayed as previously entered/filed in system. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.table_submitter_id_def', ensure that data row(s) are added/updated on filing of 'Submitter Identification Definition' form and contain values/information filed via form for all applicable fields (including Submitter Identification Information fields listed above). Scenario 2: 'Electronic Billing' - Verification Of 'Submitter Identification Definition' Values (837 Professional) Specific Setup: Avatar PM Registry Setting 'Enable Submitter Identification Definition' must be enabled/include value '3' Acceptance Testing Scenario includes 837 loops/segments for Registry Setting value '1&2&3' 'Guarantor/Program Billing Defaults' template/entry applicable to Guarantor/Program for 837 service inclusion where 'Provider Taxonomy Code to Display (2000A-PRV-03)' is set to 'Submitter Identification Definition' ('837 Professional' section) 'Guarantor/Program Billing Defaults' template/entry applicable to Guarantor/Program for 837 service inclusion where one or more of the following '837 Professional' section configuration fields are set to Dictionary Code value 'ZZZ': 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' 'Other Tabled Files' Indirect, Dictionary Data Element 1187, Code 'ZZZ' must be defined 'Billing Provider Secondary Identification Code Qualifier' 'Other Tabled Files' Indirect, Dictionary Data Element 13535, Code 'ZZZ' must be defined 'Facility Identification Code Qualifier' 'Other Tabled Files' Indirect, Dictionary Data Element 12066, Code 'ZZZ' must be defined 'Facility Reference Identification Qualifier' 'Other Tabled Files' Indirect, Dictionary Data Element 12068, Code 'ZZZ' must be defined 'Submitter Identification Definition' record applicable to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) One or more 837 Professional /HCFA 1500 service(s) eligible for Electronic Billing 837 inclusion Steps Open Avatar PM 'Electronic Billing' form. Note, acceptance testing may also be confirmed via Avatar PM 'Quick Billing' form/functionality Select '837 Professional' in the 'Billing Form' field. Select 'Sort File' in the 'Billing Options' field. Enter/select 837 Professional file sorting criteria. Click 'Process' button to sort/generate 837 Professional file. Select 'Dump File' in the 'Billing Options' field (or select 'Create File On Server' to review output file directly). Select 'Print' in the 'Print Or Delete Report' field. Select 837 Professional file sorted which includes services(s), and click 'Process' button to display 837 Professional outbound file data. Submitter Name Identification Code Qualifier/Code 1000A NM1-08/NM1-09 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Submitter Name Identification Code Qualifier/Code 1000A NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 1000A NM1-08/NM1-09 segments are populated from the 'Submitter Identification Code Qualifier' and 'Submitter Identification Number' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 1000A NM1-08/NM1-09 segments are populated from Guarantor information and do not use values from 'Submitter Identification Definition' record Billing Provider Specialty Information Reference Identification 2000A PRV-03 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Billing Provider Specialty Information Reference Identification 2000A PRV-03 information as follows: Where 'Submitter Identification Definition' is selected in the Guarantor/Program Billing Defaults 'Provider Taxonomy Code To Display (2000A-PRV-03)' field, 2000A PRV-03 segment is populated from the 'Program Taxonomy 2000A-PRV-03' field in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates(and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Program Taxonomy 2000A-PRV-03' value is not defined in Submitter Identification Definition information, 2000A PRV-03 segment is populated from Program or Guarantor/Program information Where 'Program Maintenance' or 'Guarantor/Program Billing Defaults' is selected in the Guarantor/Program Billing Defaults 'Provider Taxonomy Code To Display (2000A-PRV-03)' field, 2000A PRV-03 segment is populated from Program or Guarantor/Program information and does not use value from 'Submitter Identification Definition' record Billing Provider Name Identification Code Qualifier/Code 2010AA NM1-08/NM1-09 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Billing Provider Name Identification Code Qualifier/Code 2010AA NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' field, 2010AA NM1-08/NM1-09 segments are populated from the 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' and 'Billing Provider Primary Identification # (2010AA-NM1-09)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' / 'Billing Provider Primary Identification # (2010AA-NM1-09)' values are not defined in Submitter Identification Definition information, 2010AA NM1-08/NM1-09 segments are populated from Guarantor/Program, Program or Facility Defaults information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' field, 2010AA NM1-08/NM1-09 segments are populated from Guarantor/Program, Program or Facility Defaults information and do not use values from 'Submitter Identification Definition' record Payer Secondary Identification Code Qualifier/Code 2010BB REF-01/REF-02 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Payer Secondary Identification Code Qualifier/Code 2010BB REF-01/REF-02 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 2010BB REF-01/REF-02 segments are populated from the 'Billing Provider Secondary ID Code Qualifier' and 'Billing Provider Secondary Identification Number (2010BB-REF-02)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) Note - The 'Submitter Identification Definition' record 'Billing Provider Secondary Identification Number (2010BB-REF-02)' field/value will override the 'Submitter Identification Number' field/value in same record where '2' is selected/included in the 'Enable Submitter Identification Definition' Registry Setting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Billing Provider Secondary Identification Number (2010BB-REF-02)' value is not defined in Submitter Identification Definition information, 2010BB REF-02 is populated from the 'Submitter Identification Number' field in the corresponding 'Submitter Identification Definition' record (where '2' is selected/included in the 'Enable Submitter Identification Definition' Registry Setting) or from Guarantor/Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 2010BB REF-01/REF-02 segments are populated from Guarantor/Program information and do not use values from 'Submitter Identification Definition' record Service Facility Location Name Identification Code Qualifier/Code 2310C and 2420C NM1-08/NM1-09 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Service Facility Location Name Identification Code Qualifier/Code 2310C and 2420C NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Identification Code Qualifier' field, 2310C and 2420C NM1-08/NM1-09 segments are populated from the 'Facility Identification Code Qualifier (837P-2310C / 837P-2420C...' and 'Facility Identification Code (837P-2310C / 837P-2420C...' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Facility Identification Code Qualifier (837P-2310C / 837P-2420C...' / 'Facility Identification Code (837P-2310C / 837P-2420C...' values are not defined in Submitter Identification Definition information, 2310C and 2420C NM1-08/NM1-09 segments are populated from Guarantor/Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Identification Code Qualifier' field, 2310C and 2420C NM1-08/NM1-09 segments are populated from Guarantor/Program information and do not use values from 'Submitter Identification Definition' record Service Facility Location Secondary Identification Code Qualifier/Code 2310C and 2420C REF-01/REF-02 In Avatar PM 837 Professional format outbound electronic billing file data - ensure that 837 Professional includes Service Facility Location Secondary Identification Code Qualifier/Code 2310C and 2420C REF-01/REF-02 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Reference Identification Qualifier', field, 2310C and 2420C REF-01/REF-02 segments are populated from the 'Facility Reference Identification Code Qualifier (837P-2310C / 837P-2420C...' and 'Facility Reference Identification (837P-2310C / 837P-2420C...' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Professional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Facility Reference Identification Code Qualifier (837P-2310C / 837P-2420C...' and 'Facility Reference Identification (837P-2310C / 837P-2420C...' values are not defined in Submitter Identification Definition information, 2420C REF-01/REF-02 segments are populated from Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Reference Identification Qualifier' field, 2420C REF-01/REF-02 segments are populated from Program information and do not use values from 'Submitter Identification Definition' record Scenario 3: 'Electronic Billing' - Verification Of 'Submitter Identification Definition' Values (837 Institutional) Specific Setup: Avatar PM Registry Setting 'Enable Submitter Identification Definition' must be enabled/include value '3' Acceptance Testing Scenario includes 837 loops/segments for Registry Setting value '1&2&3' 'Guarantor/Program Billing Defaults' template/entry applicable to Guarantor/Program for 837 service inclusion where 'Provider Taxonomy Code to Display (2000A-PRV-03)' is set to 'Submitter Identification Definition' ('837 Institutional' section) 'Guarantor/Program Billing Defaults' template/entry applicable to Guarantor/Program for 837 service inclusion where one or more of the following '837 Institutional' section configuration fields are set to Dictionary Code value 'ZZZ': 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' 'Other Tabled Files' Indirect, Dictionary Data Element 12009, Code 'ZZZ' must be defined 'Billing Provider Secondary Identification Code Qualifier (2010BB-REF-01)' 'Other Tabled Files' Indirect, Dictionary Data Element 12157, Code 'ZZZ' must be defined 'Facility Identification Code Qualifier (2310E-NM1-08)' 'Other Tabled Files' Indirect, Dictionary Data Element 12052, Code 'ZZZ' must be defined 'Facility Reference Identification Qualifier (2310E-REF-01)' 'Other Tabled Files' Indirect, Dictionary Data Element 12054, Code 'ZZZ' must be defined 'Submitter Identification Definition' record applicable to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) One or more 837 Institutional / UB-04 service(s) eligible for Electronic Billing 837 inclusion Steps Open Avatar PM 'Electronic Billing' form. Note, acceptance testing may also be confirmed via Avatar PM 'Quick Billing' form/functionality Select '837 Institutional' in the 'Billing Form' field. Select 'Sort File' in the 'Billing Options' field. Enter/select 837 Institutional file sorting criteria. Click 'Process' button to sort/generate 837 Institutional file. Select 'Dump File' in the 'Billing Options' field (or select 'Create File On Server' to review output file directly). Select 'Print' in the 'Print Or Delete Report' field. Select 837 Institutional file sorted which includes services(s), and click 'Process' button to display 837 Institutional outbound file data. Submitter Name Identification Code Qualifier/Code 1000A NM1-08/NM1-09 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Submitter Name Identification Code Qualifier/Code 1000A NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier (2010BB-REF-01)' field, 1000A NM1-08/NM1-09 segments are populated from the 'Submitter Identification Code Qualifier' and 'Submitter Identification Number' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 1000A NM1-08/NM1-09 segments are populated from Guarantor information and do not use values from 'Submitter Identification Definition' record Billing Provider Specialty Information Reference Identification 2000A PRV-03 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Billing Provider Specialty Information Reference Identification 2000A PRV-03 information as follows: Where 'Submitter Identification Definition' is selected in the Guarantor/Program Billing Defaults 'Provider Taxonomy Code To Display (2000A-PRV-03)' field, 2000A PRV-03 segment is populated from the 'Program Taxonomy 2000A-PRV-03' field in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates(and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Program Taxonomy 2000A-PRV-03' value is not defined in Submitter Identification Definition information, 2000A PRV-03 segment is populated from Program or Guarantor/Program information Where 'Program Maintenance' or 'Guarantor/Program Billing Defaults' is selected in the Guarantor/Program Billing Defaults 'Provider Taxonomy Code To Display (2000A-PRV-03)' field, 2000A PRV-03 segment is populated from Program or Guarantor/Program information and does not use value from 'Submitter Identification Definition' record Billing Provider Name Identification Code Qualifier/Code 2010AA NM1-08/NM1-09 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Billing Provider Name Identification Code Qualifier/Code 2010AA NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' field, 2010AA NM1-08/NM1-09 segments are populated from the 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' and 'Billing Provider Primary Identification # (2010AA-NM1-09)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' / 'Billing Provider Primary Identification # (2010AA-NM1-09)' values are not defined in Submitter Identification Definition information, 2010AA NM1-08/NM1-09 segments are populated from Guarantor/Program, Program or Facility Defaults information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' field, 2010AA NM1-08/NM1-09 segments are populated from Guarantor/Program, Program or Facility Defaults information and do not use values from 'Submitter Identification Definition' record Payer Secondary Identification Code Qualifier/Code 2010BB REF-01/REF-02 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Payer Secondary Identification Code Qualifier/Code 2010BB REF-01/REF-02 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 2010BB REF-01/REF-02 segments are populated from the 'Billing Provider Secondary ID Code Qualifier' and 'Billing Provider Secondary Identification Number (2010BB-REF-02)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) Note - The 'Submitter Identification Definition' record 'Billing Provider Secondary Identification Number (2010BB-REF-02)' field/value will override the 'Submitter Identification Number' field/value in same record where '2' is selected/included in the 'Enable Submitter Identification Definition' Registry Setting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Billing Provider Secondary Identification Number (2010BB-REF-02)' value is not defined in Submitter Identification Definition information, 2010BB REF-02 is populated from the 'Submitter Identification Number' field in the corresponding 'Submitter Identification Definition' record (where '2' is selected/included in the 'Enable Submitter Identification Definition' Registry Setting) or from Guarantor/Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Billing Provider Secondary Identification Code Qualifier' field, 2010BB REF-01/REF-02 segments are populated from Guarantor/Program information and do not use values from 'Submitter Identification Definition' record Service Facility Location Name Identification Code Qualifier/Code 2310E NM1-08/NM1-09 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Service Facility Location Name Identification Code Qualifier/Code 2310E NM1-08/NM1-09 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Identification Code Qualifier (2310E-NM1-08)' field, 2310E NM1-08/NM1-09 segments are populated from the 'Facility Identification Code Qualifier (...837I-2310E-NM1-08)' and 'Facility Identification Code (...837I-2310E-NM1-09)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Facility Identification Code Qualifier (...837I-2310E-NM1-08)' / 'Facility Identification Code (...837I-2310E-NM1-09)' values are not defined in Submitter Identification Definition information, 2310E NM1-08/NM1-09 segments are populated from Guarantor/Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Identification Code Qualifier' field, 2310E NM1-08/NM1-09 segments are populated from Guarantor/Program information and do not use values from 'Submitter Identification Definition' record Service Facility Location Secondary Identification Code Qualifier/Code 2310E REF-01/REF-02 In Avatar PM 837 Institutional format outbound electronic billing file data - ensure that 837 Institutional includes Service Facility Location Secondary Identification Code Qualifier/Code 2310E REF-01/REF-02 information as follows: Where 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Reference Identification Qualifier (2310E-REF-01)', field, 2310E REF-01/REF-02 segments are populated from the 'Facility Reference Identification Code Qualifier (...837I-2310E-REF-01)' and 'Facility Reference Identification (...837I-2310E-REF-02)' fields in the 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified in the 'Submitter Identification Definition' record) In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is not found, claim(s)/service(s) will not be included in 837 Institutional file sorting In case where 'Submitter Identification Definition' record corresponding to Program/Guarantor/service dates (and Client/Authorization if specified) is found but 'Facility Reference Identification Code Qualifier (...837I-2310E-REF-01)' and 'Facility Reference Identification (...837I-2310E-REF-02)' values are not defined in Submitter Identification Definition information, 2310E REF-01/REF-02 segments are populated from Program information Where a value other than 'ZZZ' is defined/selected in the Guarantor/Program Billing Defaults 'Facility Reference Identification Qualifier (2310E-REF-01)' field, 2310E REF-01/REF-02 segments are populated from Program information and do not use values from 'Submitter Identification Definition' record Scenario 4: Avatar PM Registry Settings - Verification of 'Enable Submitter Identification Definition' Registry Setting Steps Open 'Registry Settings' form. Set 'Include Hidden Registry Settings' field to 'Yes'. Enter search value 'Enable Submitter Identification' and click 'View Registry Settings' button. Ensure Registry Setting is returned (under 'Avatar PM -> Billing -> Electronic Billing -> All 837 Submissions- > Enable Submitter Identification Definition' path). Ensure 'Registry Setting Details' field contains the following explanation text: "Enabling this functionality gives an end-user the ability to optionally specify identification information based on guarantor, program, service code, and client combination for a specific date range. This is accomplished by adding the 'Submitter Identification Definition' form under 'Avatar PM->System Maintenance->System Definition'. In addition, the following 837 logic is enabled: When generating a version 4010 837 bill, a check will be made to see if a value of 'ZZZ' is in 'Billing Provider Secondary Identification Code Qualifier 1 (2010AA-REF-01)', or 'Billing Provider Secondary Identification Code Qualifier 2 (2010AA-REF-01)' or 'Billing Provider Secondary Identification Code Qualifier 3 (2010AA-REF-01)' in the 'Guarantor/Program Billing Defaults' form. For version 5010, the system will check the 'Billing Provider Secondary Identification Code Qualifier (2010BB-REF)' field. If '1' is selected, the 'Submitter Primary Identification Qualifier (1000A-NM1-08)' and 'Submitter Primary Identification Number (1000A-NM1-09)' will be populated with the values specified in the 'Submitter Identification Code Qualifier' and 'Submitter Identification Number' fields of the above form respectively. This functionality is available in both version 4010 and 5010. If '2' is selected, for version 4010 the 'Billing Provider Secondary Identification Code Qualifier (2010AA-REF-01)' and 'Billing Provider Secondary Identification # (2010AA-REF-02)' will be populated with the values specified in the 'Billing Provider Secondary Identification Code Qualifier' and 'Submitter Identification Number' fields specified for any iteration that contains the 'ZZZ' dictionary code. For version 5010, the 'Billing Provider Secondary Identification Code Qualifier (2010BB-REF-01)' and 'Billing Provider Secondary Identification # (2010BB-REF-02)' will be populated with the same values specified for any iteration that contains the 'ZZZ' dictionary code. If '3' is selected the ability to optionally specify identification information based on authorization number is added and if "ZZZ" is selected in the following 'Guarantor/Program Billing Defaults' fields on the left then the appropriate 837 fields will be populated with the 'Submitter Identification Definition' fields on the right: 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' -- 'Billing Provider Primary Identification Code Qualifier (2010AA-NM1-08)' and 'Billing Provider Primary Identification # (2010AA-NM1-09)' Note: The 'Submitter Identification Definition' 'Billing Provider Secondary Identification Number (2010BB-REF-02)' field will override the 'Submitter Identification Number' field that is used if "2" is selected. 'Facility Identification Code Qualifier'/'Facility Identification Code Qualifier (2310E-NM1-08)' -- 'Facility Identification Code Qualifier (837P-2310C / 837P-2420C / 837I-2310E-NM1-08)' and 'Facility Identification Code (837P-2310C / 837P-2420C / 837I-2310E-NM1-09)' 'Facility Reference Identification Qualifier'/'Facility Reference Identification Qualifier (2310E-REF-01)' -- 'Facility Reference Identification Qualifier (837P-2310C / 837P-2420C / 837I-2310E-REF-01)' and 'Facility Reference Identification (837P-2310C / 837P-2420C / 837I-2310E-REF-02)' 'Provider Taxonomy Code to Display (2000A-PRV-03)' -- 'Program Taxonomy 2000A-PRV-03' Note: The "ZZZ=Submitter Identification Definition" dictionary code/value will be added to the 'Provider Taxonomy Code to Display (2000A-PRV-03)' dictionary. For version 5010, the same code would need to be added to the 'Billing Provider Secondary Code Qualifier (2010BB-REF-01)'. This also necessitates that the bills will be sorted by submitter identification number. Selecting '1&2&3' will add all of the functionality listed above. Selecting '0' will remove the form from the menu and disable the 837 logic. Note: This functionality is used to meet a PA State requirement."	Topics • Registry Settings • Electronic Billing • NX • 837 Professional • 837 Institutional
Update 11 Summary \| Details Spreadsheet Batch Remittance Posting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Posting/Adjustment Codes Definition Claim Adjustment Group/Reason Code Definition Practitioner Enrollment Practitioner Numbers By Guarantor and Program Financial Eligibility Electronic Billing Spreadsheet Batch Remittance Posting Batch Remittance Posting Report Facility Defaults 835 Health Care Claim Payment/Advice (PM) Scenario 1: Spreadsheet Remittance Batch Posting - Validating financial eligibility data upon hover over the 'Transfer Guar' field. Specific Setup: Posting/Adjustment Codes Definition has been used to create desired definitions. Claim Adjustment Group/Reason Code Definition has been used to create desired definitions. An existing client is identified. Three or more guarantors are assigned to the client using 'Financial Eligibility' form. Note the liability order for the guarantors. Services are rendered to the client so that at least one of the guarantors has no liability. Client Ledger is used to validate that liability distributed to the guarantors based on the setup in the 'Financial Eligibility' form. An Interim billing batch is created in the 'Create Interim Billing Batch File' form which includes the client / guarantor and services. Steps Open the 'Spreadsheet Remittance Batch Posting' form. Select 'Create Batch' in the 'Create, Edit Or Delete Remittance Batch' field. Enter the 'Batch Description'. Select the interim billing batch created in the setup section in the 'Interim Batch Number' field. Enter desired date in the 'Posting Date' field. Enter desired date in the 'Date Of Receipt' field. If desired, enter/select values in 'Receipt'. If desired, enter/select values in 'Check #' If desired, enter/select values in 'Default Guarantor'. If desired, enter/select values in 'Default Payment Code'. If desired, enter/select values in 'Default Adjustment Code'. If desired, enter/select values in 'Default Transfer Code'. If desired, enter/select values in 'Service Start Date'. If desired, enter/select values in 'Service End Date'. Click [Launch Work Screen]. Validate that the 'Client' defaults. Validate that other entered/selected data defaults. Enter a 'Transfer Amount'. Enter a 'Transfer Code'. Hover over the 'Transfer Guar' field. Verify that a mini table will be displayed containing a list of guarantors that are assigned to the client's episode via 'Financial Eligibility' (excluding the current guarantor) and active for the selected date of service in the same order as they set up in the 'Financial Eligibility' form. Select the desired guarantor to transfer to in the mini table. Click [Accept]. Click [Submit]. Click [OK]. Click [No]. Open the 'Client Ledger' form. Select the 'Client ID' Select 'All Episodes' in 'Claim/Episode/All Episodes'. Enter the desired 'From Date'. Enter the desired 'To Date'. Select 'Simple' in 'Ledger Type'. Click [Process]. Validate the payment and transfer activity. Click [Dismiss]. Close the form. Scenario 2: Spreadsheet Batch Remittance Posting - Guarantor/Payors - 835 - Allow Adjustment Reversals' Specific Setup: Registry Settings: Avatar PM->Billing->Financial Eligibility->->->Enable Automatic Contractual Adjustment Based On Fee Table = 'O' or 'A'. Avatar PM->Billing->Remittance Processing->835 Health Care Claim Payment/Advice->->Compile But Don't Post Adjustments (CAS) = Y. Posting/Adjustment Codes Definition has been used to create desired definitions. Guarantors/Payors: Select a guarantor that will be the primary guarantor for the client. 'Contractual Guarantor Information' section: All required fields are enabled. Enable Modified Contractual Allowance Calculation has desired value. '835' section: 'Allow Adjustment Reversals' = Yes. Help message = If "Yes" is selected the '835 Health Care Claim Payment/Advice' and 'Spreadsheet Batch Remittance Posting' will: 1) Determine amount of any credit contractual allowance adjustments that were automatically posted for the Guarantor during liability distribution. 2) If there is a positive amount and a 'Contractual Adjustment Code (Debit)' code is selected in the 'Guarantors/Payors' (Contractual Guarantor Information) form a debit adjustment will be automatically posted to reverse the credit adjustments. Service Fee/ Cross Reference Maintenance: Identify a service code with a standard fee and a 'Guarantor Definition' for the above guarantor with the following: Standard Fee: Fee is active based on the dates in 'From Date' and 'End Date'. Note the fee. Guarantor Definition: Note the value in 'Maximum Amount To Distribute Per Service'. It should be less than the standard fee. Write-off Remaining Balance (Contract Guarantors Only) = Yes. A new client is added, or an existing client is identified. Note the Client ID/name. The financial eligibility record is created for the client. The client is assigned two or more guarantors. The primary guarantor is the guarantor that has the fee definition. Services are rendered to the client for the service code with the fee definitions. Note the service start / end date and service code used. The 'Client Ledger' report for the client is processed. Save the report for comparison. Note that a portion of each has service has been adjusted off. Close Charges is used to close the charges. The services do not have to be claimed to complete testing, however if preferred, create an interim billing batch, and use Electronic Billing to create claims. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Select "Create Batch" in the 'Create, Edit Or Delete Remittance Batch' field. Enter a description in the 'Batch Description' field. Enter a date in the 'Posting Date' field. Note the date. Enter a date in the 'Date Of Receipt' field. If desired, enter a value in 'Receipt'. If desired, enter a value in 'Check #' If desired, select a value in 'Default Guarantor'. If desired, select a value in 'Default Payment Code'. If desired, select a value in 'Default Adjustment Code'. If desired, select a value in 'Default Transfer Code'. If desired, enter a value in 'Service Start Date'. If desired, enter a value in 'Service End Date'. Same service dates allow easier review of the Client Ledger. Click [Launch Work Screen]. Select the 'Client'. Select the 'EP #'. If desired, select the 'Claim'. Select the 'Payor' or verify it defaulted. Enter an 'Adjust Amount'. Select an 'Adjustment Code' of verify existence if a 'Default Adjustment Code' was selected. Click [Accept]. Click [Submit]. Validate that the message contains 'Remittance batch 'XX' posted'. Click [OK]. Click [No]. Open ‘Client Ledger’ for the client and process the report for the desired date range of services. Validate that the services that were adjusted contain a reversal of the original adjustment, and the new adjustment entered in 'Spreadsheet Batch Remittance Posting'. Close the report. Close the form. Open 'Guarantors/Payors'. Edit the guarantor that was selected as the primary guarantor in Setup. Select the '835' section'. Change the value of 'Allow Adjustment Reversals' to 'No'. Select the 'Guarantors/Payors' section. Click [File]. Close the form. Repeat steps 1 - 27. Validate that the services that were adjusted do not contain a reversal of the original adjustment and do contain the new adjustment entered in 'Spreadsheet Batch Remittance Posting'. Close the report. Close the form. Scenario 3: Spreadsheet Batch Remittance Posting - Allow Posting of Zero Dollar Payment Specific Setup: Registry Settings: Registry Setting: Avatar PM->Billing->Remittance Processing->->->Allow Posting of Zero Dollar Payment = No. Posting/Adjustment Codes Definition has been used to create desired definitions. A new client is added, or an existing client is identified. Note the Client ID/name. The financial eligibility record is created for the client. Services are rendered to the client. Note the service start / end date and service code used. The 'Client Ledger' report for the client is processed. Note the details of the report. An interim billing batch is created to include client, guarantor, and services. Electronic Billing is used to create claims. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Select "Create Batch" in the 'Create, Edit Or Delete Remittance Batch' field. Enter a description in the 'Batch Description' field. Enter a date in the 'Posting Date' field. Note the date. Enter a date in the 'Date Of Receipt' field. If desired, enter a value in 'Receipt'. If desired, enter a value in 'Check #' Select a value in 'Default Guarantor'. If desired, enter a value in 'Service Start Date'. If desired, enter a value in 'Service End Date'. Click [Launch Work Screen]. Select the 'Client'. Select the 'EP #'. If desired, select the 'Claim'. Select the 'Payor' or verify it defaulted. Click the '+' object. Verify that the correct service rows display. Enter a 'Payment Amount' of '0.00'. Select a 'Payment Code'. Verify that 'Payment Amount' displays as required. Verify that the 'Accept button is disabled. Click [Cancel]. Click [Yes]. Close the form without submitting. Open 'Registry Settings' and change the 'Allow Posting of Zero Dollar Payment' setting to 'Y'. Click [Submit]. Click [OK]. Click [No]. Repeat steps 1 -19. Verify that 'Payment Amount' does not display as required Verify that the 'Accept button is enabled. Click [Accepts]. Click [Submit]. Click [OK]. Click [No]. Scenario 4: Spreadsheet Batch Remittance Posting - Distribute Claim/Service Level Adjustments (2100/2110-CAS) Across All Services Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->835 Health Care Claim Payment/Advice->->Distribute Claim/Service Level Adjustments (2100/2110-CAS) Across All Services = N. Avatar PM->Billing->Remittance Processing->835 Health Care Claim Payment/Advice->->Compile But Don't Post Adjustments (CAS) = Y. Posting/Adjustment Codes Definition has been used to create desired definitions. Claim Adjustment Group/Reason Code Definition has been used to create desired definitions. When the ‘Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’ field has a value of 'Yes' the adjustment will not post. When the ‘Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’ field has a value of 'No' the adjustment will post. Guarantors/Payors: Select a guarantor that will be the primary guarantor for the client. A new client is added, or an existing client is identified. Note the Client ID/name. The financial eligibility record is created for the client. The client is assigned two or more guarantors. The primary guarantor is the guarantor that has the fee definition. Services are rendered to the client. Note the service start / end date and service code used. The 'Client Ledger' report for the client is processed to validate that the services distributed liability correctly. Close Charges is used to close the charges. The services do not have to be claimed to complete testing, however if preferred, create an interim billing batch, and use Electronic Billing to create claims. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Select "Create Batch" in the 'Create, Edit Or Delete Remittance Batch' field. Enter a description in the 'Batch Description' field. Enter a date in the 'Posting Date' field. Note the date. Enter a date in the 'Date Of Receipt' field. If desired, enter a value in 'Receipt'. If desired, enter a value in 'Check #' If desired, select a value in 'Default Guarantor'. If desired, select a value in 'Default Payment Code'. If desired, select a value in 'Default Adjustment Code'. If desired, select a value in 'Default Transfer Code'. If desired, enter a value in 'Service Start Date'. If desired, enter a value in 'Service End Date'. Same service dates allow easier review of the Client Ledger. Click [Launch Work Screen]. Select the 'Client'. Select the 'EP #'. If desired, select the 'Claim'. Select the 'Payor' or verify it defaulted. Click the ‘+’ item. Click [Enter CARCS]. Create Entries for adjustments and transfers: Select desired value in ‘CAS Adjustment Group Code’. Select desired value in ‘CAS Adjustment Reason Code’. Enter an ‘Adjustment Amount’. Verify that ‘Post’ is checked on unchecked based on the value of ‘ ‘Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’. Highlight a row and click 'Copy/Paste Row'. Select desired value in ‘CAS Adjustment Group Code’. Select desired value in ‘CAS Adjustment Reason Code’, selecting a code that is not associated to the group code. Verify that an error message s received stating: The Group and Reason Codes highlighted are not currently setup and cannot be saved. Select the copied row and click 'Delete Row'. Confirm that a confirmation message is received. Click desired value to delete or retain the row. If the row is retained, change the ‘CAS Adjustment Reason Code’ to a code that is associated to the group code. Click [New Row]. Validate that the row is added. Delete the row or add data to it. Click [Close/Cancel]. Verify a 'Cancel Confirmation' is received. Click [No]. Click [Save] when all desired rows have been added Validate that the 'Adjust Amount' contains the total of all adjustments entered. Validate that the 'Transfer Amount' contains the total of all adjustments entered. Validate that the 'Adjust Amount' applies to the services rows, beginning with row 1, and pays each row in full until the full amount has been used. Validate that the 'Transfer Amount' applies to the services rows, beginning with the row that the 'Adjust Amounts' ended in if not paid in full. If it was paid in full the 'Transfer Amount' begins in the next row, and pays each row in full until the full amount has been used. If the 'Adjustment Code' was not defaulted, please select a value. If the 'Transfer Code' was not defaulted, please select a value. If the 'Transfer Guar' was not defaulted, please select a value. Enter a 'Payment Amount'. Validate that the 'Payment Amount' applies to the services rows, beginning with the row that the 'Transfer Amounts' ended in if not paid in full. If it was paid in full the 'Payment Amount' begins in the next row, and pays each row in full until the full amount has been used. Click [Accept]. Click [Submit]. Click [OK]. Click [No]. Open ‘Client Ledger’ for the client and process the report for the date range of services with activity. Validate the data for the services that were paid, adjusted, and transferred. Close the report. Close the form. Open 'Registry Settings'. Change the 'Distribute Claim/Service Level Adjustments (2100/2110-CAS) Across All Services' setting to Y. Click [Submit]. Click [OK]. Click [No]. Repeat steps 1 - 50. Note the validation for the 'Adjust Amount', Transfer Amount' and 'Payment Amount' will be different because the amount will be divided evenly among all service rows. The final row may contain an amount that is different by a few cents. Scenario 5: Spreadsheet Batch Remittance Posting - Select Client Specific Setup: Registry Settings: Avatar PM->Billing->Remittance Processing->835 Health Care Claim Payment/Advice->->Compile But Don't Post Adjustments (CAS) = Y. Posting/Adjustment Codes Definition has been used to create desired definitions. Claim Adjustment Group/Reason Code Definition has been used to create desired definitions. Note the value in 'Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’. A value of 'No' allows the entry to be posted in the 'Enter CARCs' section of the 'Spreadsheet Batch Remittance Posting' form. A value of 'Yes' does not allow the entry to be posted in the 'Enter CARCs' section of the 'Spreadsheet Batch Remittance Posting' form. A new client is added, or an existing client is identified. Note the Client ID/name. The financial eligibility record is created for the client. The client is assigned two or more guarantors. Services are rendered to the client. Note the service start / end date and service code used. The 'Client Ledger' report for the client is processed. Note the details of the report. An interim billing batch is created to include client, guarantor, and services. Electronic Billing is used to create claims. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Select "Create Batch" in the 'Create, Edit Or Delete Remittance Batch' field. Enter a description in the 'Batch Description' field. Enter a date in the 'Posting Date' field. Note the date. Enter a date in the 'Date Of Receipt' field. If desired, enter a value in 'Receipt'. If desired, enter a value in 'Check #' If desired, select a value in 'Default Guarantor'. If desired, select a value in 'Default Payment Code'. If desired, select a value in 'Default Adjustment Code'. If desired, select a value in 'Default Transfer Code'. If desired, enter a value in 'Service Start Date'. If desired, enter a value in 'Service End Date'. Click [Launch Work Screen]. Select the 'Client'. Select the 'EP #'. If desired, select the 'Claim'. Select the 'Payor' or verify it defaulted. Click [Enter CARCs]. Select a 'CAS Adjustment Group Code' to create an adjustment. Select a 'CAS Adjustment Reason Code' that is not associated to the 'CAS Adjustment Group Code'. Enter an 'Adjustment Amount'. Validate that an error is received stating: The Group and Reason codes highlighted are not currently setup and cannot be saved. Change the 'CAS Adjustment Reason Code' to one the is associated to the 'CAS Adjustment Group Code'. Validate that the 'Post' checkbox is checked when the group/reason code contains a 'No' in 'Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’. Validate that the 'Post' checkbox is not checked when the group/reason code contains a 'Yes' in 'Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’. Select a 'CAS Adjustment Group Code' to create a transfer. Select a 'CAS Adjustment Reason Code' that is associated to the 'CAS Adjustment Group Code'. Enter an 'Adjustment Amount'. Validate that the 'Post' checkbox contains the correct value for the group/reason code. If desired, enter additional adjustments and transfers. Note the total amounts for each. Click [Save]. Validate that 'Adjust Amount' contains the total adjustment amounts. Select an 'Adjustment Code' of verify existence if a 'Default Adjustment Code' was selected. Validate that 'Transfer Amount' contains the total transfer amounts. Select a 'Transfer Code' of verify existence if a 'Default Transfer Code' was selected. Validate that 'Transfer Guar' is required'. Hover over the 'Transfer Guar' field to view the table of the client's guarantors, excluding the current 'Payor'. Select the desired 'Transfer Guar'. Enter a 'Payment Amount'. Select a 'Payment Code' of verify existence if a 'Default Payment Code' was selected. Click [Accept]. Click [Submit]. Validate that the message contains 'Remittance batch 'XX' posted'. Click [OK]. Click [No]. Open ‘Client Ledger’ for the client and process the report for the date range of services with activity. Validate the data for the services that were paid, adjusted, or transferred. Close the report. Close the form. Scenario 6: Spreadsheet Batch Remittance Posting - Create Claim Follow-Up Specific Setup: User Definition has been used to give the user access to the Avatar Pm > Billing > Remittance Posting > Spreadsheet Batch Remittance Posting form. Identify at least one client with open claims. Posting/Adjustment Codes Definition: Create a transfer code that has values in ‘Claim Adjustment Group Code (837-2430-CAS)’ and ‘Claim Adjustment Reason Code (837-2430-CAS)’. Note the values of each field. Claim Adjustment Group/Reason Code Definition: Create an entry using the same 'Claim Adjustment Group Code', and 'Claim Adjustment Reason Code' used above. The ‘Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835’ field had a value of 'Yes'. Select desired values for the 'Transfer Guarantor Rules'. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Select "Create Batch" in the 'Create, Edit Or Delete Remittance Batch' field. Enter a description in the 'Batch Description' field. Enter a date in the 'Posting Date' field. Note the date. Enter a date in the 'Date Of Receipt' field. If desired, enter a value in ‘Receipt'. If desired, enter a value in ‘Check #’. Note the value. Select a payment code in the 'Default Payment Code' field Select an adjustment code in the 'Default Adjustment Code' field Select the transfer from setup in the 'Default Transfer Code' field. Select a guarantor in the Default Trans. To Guarantor' field. If desired, enter a 'Service Start Date'. If desired, enter a 'Service End Date'. Click the "Launch Work Screen" button. Select the 'Client'. Select the 'Ep #'. Select the 'Claim'. Select the 'Payor'. Validate that 'Total Charges' contains a value. Validate that 'Liability' contains a value. Validate that 'Payment Amount' is '0.00'. Validate that 'Adjust Amount' is '0.00'. Validate that Transfer Amount' is '0.00'. Click [Enter CARC(s)]. Select the ’Claim Adjustment Group Code’ from setup. Select the ‘Claim Adjustment Reason Code' from setup. Enter an amount in ‘Adjustment’. Validate that the ‘Post’ checkbox is unchecked. Click [Save]. Click [Accept]. Click [Submit]. Click [Yes]. Click [OK]. Click [No]. Open ‘Claim Follow-Up’. Select the desired ‘Client’. Select ‘Edit’ in ‘Add, Edit Or Delete Claim Follow-Up’. Select the claim in ‘Select Claim Follow-Up To Edit Or Delete’. Validate that ‘Denial Type’ contains a value. Validate that the ‘Service(s) box contains service dates and there are checked. Validate the ‘Amount Billed’ equals the amount entered in ‘Adjustment’. Select ‘Edit’ in ‘Add, Edit Or Delete Row’. Select the desired row in ‘Select Row To Edit Or Delete’. Validate the ‘Comments’ contains ‘Spreadsheet Batch Remittance’. Validate the ‘Date Of Entry’ equals the current date. Click [Update Row]. Click [Submit]. Click [No]. Scenario 7: Spreadsheet Batch Remittance Posting - Security Level - Allow User To Continue Filing With Mismatch In Amounts To Post Specific Setup: Registry Setting: Allow User To Continue Filing With Mismatch In Amounts To Post = Y. Posting/Adjustment Codes Definition has been used to create desired definitions. User Definition: Signed in user has a security level of '2'. Client: Identify a client with unpaid claims. Note the dates of services and the guarantor liability has distributed to. Verify if the client has additional guarantors in the financial eligibility record. Steps Open the 'Spreadsheet Remittance Batch Posting' form. Select 'Create Batch' in the 'Create, Edit Or Delete Remittance Batch' field. Enter the 'Batch Description'. Enter desired date in the 'Posting Date' field. Enter desired date in the 'Date Of Receipt' field. If desired, enter/select values in 'Receipt'. If desired, enter/select values in 'Check #' If desired, enter/select values in 'Default Guarantor'. If desired, enter/select values in 'Default Payment Code'. If desired, enter/select values in 'Default Adjustment Code'. If desired, enter/select values in 'Default Transfer Code'. If desired, enter/select values in 'Service Start Date'. If desired, enter/select values in 'Service End Date'. Click [Launch Work Screen]. Select the 'Client'. Select the 'EP #'. Validate that other entered/selected data defaults. Click the '+' item. Review the balance due for the first service row. Enter a partial payment amount in 'Payment Amount', noting the amount. If not defaulted, select a 'Payment Code'. Enter a partial adjustment amount in 'Adjust Amount', noting the amount. If not defaulted, select a 'Adjust Code'. Enter a partial transfer amount in 'Adjust Amount', noting the amount. If not defaulted, select a 'Transfer Code'. If not defaulted, select a 'Transfer Guar'. Validate the amount in the 'New Balance' field. Click [Accept]. Select the 'Remittance Totals' section. Validate that 'Payment Amount Posted' contains the amount entered. Validate that 'Adjustment Amount Posted' contains the amount entered. Validate that 'Transfer Amount Posted' contains the amount entered. Enter a value that differs from the payment amount in 'Payment Amount Total'. Note the value in 'Payment Amount Remaining'. Enter a value that differs from the adjustment amount in 'Adjustment Amount Total'. Note the value in 'Adjustment Amount Remaining'. Enter a value that differs from the transfer amount in 'Transfer Amount Total'. Note the value in 'Transfer Amount Remaining'. Click [Submit]. Validate that the message dialog contains Remittance is not balanced. Do you wish to continue posting? Click [Yes]. Click [OK]. Click [No]. Open 'Registry Settings'. Set 'Limit Registry Settings to the Following Search Criteria' to 'Allow User To Continue Filing With'. Click [View Registry Settings]. Validate that the 'Registry Setting' contains 'Avatar PM->Billing->Remittance Processing->->->Allow User To Continue Filing With Mismatch In Amounts To Post'. Set the 'Registry Setting Value' to 'N'. Click [Submit]. Click [OK]. Click [No]. Repeat steps 2 - 39. Validate that the message dialog contains 'Remittance is not balanced'. Click [OK]. Click [Discard]. Click [Yes]. Open 'Registry Settings'. Set 'Limit Registry Settings to the Following Search Criteria' to 'Allow User To Continue Filing With'. Click [View Registry Settings]. Validate that the 'Registry Setting' contains 'Avatar PM->Billing->Remittance Processing->->->Allow User To Continue Filing With Mismatch In Amounts To Post'. Set the 'Registry Setting Value' to 'S'. Click [Submit]. Click [OK]. Click [No]. Repeat steps 2 - 39. Validate that the message dialog contains 'Remittance is not balanced'. Click [OK]. Click [Discard]. Click [Yes]. Scenario 8: Spreadsheet Batch Remittance Posting - Validate excluded posting codes are not included in the 'Payment Code' dropdown list. Specific Setup: An existing client with unpaid claims is identified (Client A). Note the guarantor that liability is distributed to. Posting/Adjustment Codes Definition: A payment posting code is defined to 'Exclude Guarantors' for the client's liability guarantor. Note the code/description. An additional payment posting code is defined to not exclude the client's liability guarantor. Note the code/description. User Definition': The user has access to the 'Spreadsheet Batch Remittance' form. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Click the 'Create Batch' field. Enter the 'desired value' in the 'Batch Description' field. Select the 'desired value' in 'Default Payment Code' field. Enter the desired 'Posting Date'. Enter the desired 'Date Of Receipt'. Click [Launch Work Screen]. Select "Client A" in the 'Client' field. Select the 'desired episode'. Validate there is Liability to be remitted against. Select the "excluded" guarantor from the 'Payor' field. Enter the 'desired value' in the 'Payment Amount' field. Double Click the 'Payment Code' field and validate it does not contain the "excluded" payment code. Select the "non-excluded" payment code. Click [Accept]. Click [Submit]. Click [OK]. Click [Yes]. Scenario 9: Spreadsheet Batch Remittance Posting - Validating remittance batch posting using 'Interim Billing Batch' Specific Setup: Posting/Adjustment Codes Definition has been used to create desired definitions. Claim Adjustment Group/Reason Code Definition has been used to create desired definitions. A new client is added, or an existing client is identified. Note the Client ID/name. The financial eligibility record is created for the client. Note the Guarantor code/name. The client is assigned two or more guarantors. Services are rendered to the client. Note the service start / end date and service code used. The 'Client Ledger' report for the client is processed. Note the details of the report. An interim billing batch is created to include client, guarantor, and services. Electronic Billing is used to create claims. Steps Open the 'Spreadsheet Remittance Batch Posting' form. Select 'Create Batch' in the 'Create, Edit Or Delete Remittance Batch' field. Enter the 'Batch Description'. Select the interim billing batch created in the setup section in the 'Interim Batch Number' field. Enter desired date in the 'Posting Date' field. Enter desired date in the 'Date Of Receipt' field. Enter desired value in ‘Receipt’. Enter desired value in ‘Check #’. Select the ‘Default Guarantor’. Select the ‘Default Payment Code’. Select the ‘Default Adjustment Code. Select the ‘Default Transfer Code. If desired, enter a 'Service Start Date'. If desired, enter a 'Service End Date'. Click [Launch Work Screen]. Validate that the data from the interim batch defaults. Click [Enter CARC(s)]. Select desired value in 'CAS Adjustment Group Code'. Select desired value in 'CAS Adjustment Reason Code'. Enter an amount in 'Adjustment'. Validate that the 'Post' field is checked if the group/reason code has a value of 'No' in 'Compile but do not post adjustments (CAS) associated with the indicated Claim Adjustment Group/Reason codes when processing an 835. Enter additional CARC(s) as desired. Click [Save]. Validate that the 'Adjust Amount' contains the total of the adjustments. Validate that the 'Adjust Code' contains the default value. If a transfer CARC was added, validate that the 'Transfer Amount' contains the total of the transfers. Validate that the 'Transfer Code' contains the default value. Hover over the 'Transfer Guar' to validate the table displays the client's guarantors, excluding the guarantor in 'Payor'. Select a 'Transfer Guar'. Enter a 'Payment Amount'. Validate that the 'Payment Code' contains the default value. If desired, click the '+' item to display the individual services. Validate the payments, adjustments, and transfers within the individual services, noting the date range of services with activity. Click [Accept]. Click [Submit]. Validate that the message contains 'Remittance batch 'XX' posted'. Click [OK]. Click [No]. Open ‘Client Ledger’ for the client and process the report for the date range of services with activity. Validate the data for the services that were paid, adjusted, or transferred. Close the report. Close the form. Scenario 10: Batch Remittance Posting Report Specific Setup: User Definition has been used to give two users access to the Avatar Pm > Billing > Remittance Posting > Spreadsheet Batch Remittance Posting form and the Avatar PM > Billing > Billing Reports > Batch Remittance Posting Report form. Note the User IDs and User Descriptions. Posting/Adjustment Codes Definition has been used to create desired definitions. Claim Adjustment Group/Reason Code Definition has been used to create desired definitions. Identify at least one client with open claims. Spreadsheet Batch Remittance Posting has been used to create at least one batch per user. Use different values in 'Posting Date', and 'Check #'. Note the value and the signed in user. Note the details of the batches. 835 Health Care Claim Payment/Advice has been used to post at least one 835 file. Note the details of the file. Steps Open 'Batch Remittance Posting Report' form. Enter the desired value in the required 'Posting Date' field. If desired, enter a value in the 'Posting End Date' field. If desired, enter a value in the 'Check/EFT #' field. If desired, enter a value in the 'Remittance File By User'. Click [Process]. Validate that the 'Batch Remittance Posting Report' report opens and contains the following fields: Batch Status Posting Option Posting Date Check/EFT Number Description Filed By Patient Ep # Claim Payor Total Charges Liability Payment Amount Payment Code Adjust Amount Adjust Code Transfer Amount Transfer Code Transfer Guar New Balance. Validate that the data in the fields is correct based on the selection criteria. Close the report. Close the form.	Topics • Spreadsheet Batch Remittance Posting • Claim Follow-up
Update 12 Summary \| Details 'Client Admission' web service Scenario 1: 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 Access SoapUI for the 'ClientAdmission' - 'AddAdmission' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Populate all required and desired fields. Enter the desired value in the 'ClientFirstName' field. Enter the desired value in the 'ClientLastName' field. Enter a value containing an invalid character in the 'ClientMiddleName' field. (Ex. T#ST!) Enter the corresponding name in the 'ClientName' field. Click [Run]. Validate the 'Message' field contains: "Middle name contains invalid characters. Valid symbols are '-_.". Enter the desired value in the 'ClientMiddleName' field, removing the invalid characters. Enter the corresponding name in the 'ClientName' field. Click [Run]. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #". Validate the 'Message' field contains: "Client Admission web service has been filed successfully". Select the client filed in the previous steps and access the 'Admission' form. Select the record filed in the previous steps and click [Edit]. Validate all populated fields are displayed. Select the "Demographics" section. Validate the 'Client Last Name' field contains the value filed in the previous steps. Validate the 'Client First Name' field contains the value filed in the previous steps. Validate the 'Client Middle Name' field contains the value filed in the previous steps. Close the form.	Topics • Admission
Update 13 Summary \| Details SQL table - RADplus_IMO_Results table Scenario 1: Load & Go update - Verify successful installation Steps Internal Testing Only	Topics • Problem List
Update 14 Summary \| Details Claim Follow-Up Scenario 1: 'Claim Follow-Up' - Verification of Submission Specific Setup: Avatar PM Registry Setting 'Claim Follow-Up' must be enabled. Client with claim(s)/service(s) eligible for 'Claim Follow-Up' entry. Steps Open Avatar PM 'Claim Follow-Up' form; select client record for Claim Follow-Up entry. Select 'Add' in 'Add, Edit Or Delete Claim Follow-Up' field (or select 'Edit' for review/update of existing entry). Select value in 'Guarantor' field. Select value in 'Claim' field. Select value in 'Denial Type' field. Select value in 'Service(s)', 'Insurance Based Denial Reason' and '835 Denial Reason' if desired. Select value in 'Assign Claim For Electronic Re-Billing' field (and 'Claim Submission Reason Code' field if applicable). In Follow-Up Status/Comments form sub-section, select 'Add' in 'Add, Edit or Delete Row' field (or select 'Edit' for view/update of existing Follow-Up Status/Comments entry). Select value in 'Follow-Up Status' and 'Followed Up' fields. Enter/select values in 'Denial CRN#', 'Current CRN#', 'Next Follow-Up Date' and 'Completion Date' fields if desired. Enter value in 'Comments' field. Click 'Update Row' button to save Follow-Up Status/Comments entry. Click 'Submit' button to file 'Claim Follow-Up' form/record. Ensure filing confirmation dialog noting 'Claim Follow-Up has completed. Do you wish to return to form?' is presented; click 'Yes' button to return to 'Claim Follow-Up' form. Select 'Edit' in 'Add, Edit Or Delete Claim Follow-Up' field for review of existing entry. Select existing entry in 'Select Claim Follow-Up To Edit Or Delete' field. Ensure values for all fields are present in 'Claim Follow-Up' form as previously entered/field for selected entry, including rows/entries in the Follow-Up Status/Comments form sub-section.	Topics • Claim Follow-up
Update 15 Summary \| Details HCFA 1500 Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Client Charge Input With Diagnosis Entry Print Bill Referral Source Maintenance Scenario 1: Print Bill - HCFA-1500-NPI Version - Sorting Specific Setup: Registry Setting: Avatar PM->Billing->Paper Billing->HCFA-1500->->Enable Select Type Of Information To Include For Locator 17 = Y. Avatar PM->Billing->Client Charge Input->Fields To Retain After Filing->->Fields to Retain After Filing Client Charge Input = 18 at a minimum. Guarantor/Program Billing Defaults - ‘Paper HCFA-1500’ section: Include a value in ‘Referring Provider Or Other Source Code Qualifier (Form Locator 17)’. Select 'Referring Provider/Practitioner' in ‘Select Type Of Information To Include In Name Of Referring Physician Or Other Source (Form Locator 17)’. Select 'Referring Practitioner' in 'Sort Paper HCFA-1500 Claims By'. Note the guarantors and programs assigned to the template. Clients: Identify two clients with multiple unclaimed services that can be billed from the above template. Each client should have services that are provided by different practitioners. Note the last service date. Create Interim Billing Batch File is used to create a batch for the services. Close Charge is used to close the charges for the interim batch. Steps Open ‘Print Bill’. Enter the last service date in ‘Print Charges Thru’. Select ‘No’ in ‘Create Claims Y/N’. If the services were created with a diagnosis entry, select ‘HCFA-1500-NPI-Vesrion (Diagnosis Entry’ in ‘Print On What Form’. Select ‘Yes’ in ‘Print For Interim Batch’. Select the ‘Interim Batch Number’ created in Setup. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. Select ‘HCFA-1500-NPI-Vesrion (Sort By Practitioner/Service Consolidation/Diagnosis Entry)’ in ‘Print On What Form’. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. Select ‘HCFA-1500-NPI-Vesrion (Sort By Service Consolidation/Diagnosis Entry)’ in ‘Print On What Form’. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. If the services were created without a diagnosis entry, select ‘HCFA-1500-NPI-Vesrion (Sort By Practitioner)’ in ‘Print On What Form’. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. Select ‘HCFA-1500-NPI-Vesrion (Sort By Practitioner/Service Consolidation)’ in ‘Print On What Form’. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. Select ‘HCFA-1500-NPI-Vesrion (Sort By Service Consolidation)’ in ‘Print On What Form’. Click [Process]. Verify that the bill contains the correct information and is sorted correctly. Close the report. Close the form. Open 'Client Charge Input'. Create a service for a client that includes a referring practitioner with an ID code higher than '1'. Note the date of service. Create an additional service for the same client that includes a referring practitioner with an ID code that is lower than the ID code in the first service and the service date is after the first service date. Close the form. Create an 'Interim Billing Batch File' for the two services. Close the charges for the interim batch. Open 'Print Bill'. Enter the last service date in ‘Print Charges Thru’. Select ‘No’ in ‘Create Claims Y/N’. Select ‘HCFA-1500-NPI-Vesrion’ in ‘Print On What Form’. Select ‘Yes’ in ‘Print For Interim Batch’. Select the ‘Interim Batch Number’ created in Setup. Click [Process]. Verify that the bill contains the correct information and is sorted by the referring practitioner ID, starting with the lowest ID number. Close the report. Close the form.	Topics • Print Bill • NX
Update 16 Summary \| Details Progress Notes (Group and Individual) Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Payor Based Authorizations Practitioner Numbers By Guarantor And Program Electronic Billing Scenario 1: PM - Payor Based Authorization - Location Specific Setup: Registry Settings: Enable Payor Based Authorizations = 'Y'. Enable CPT Based Payor Authorizations = desired value. Require Authorizations At Guarantors/Payors Level = desired value. Dictionary Update: Client File (10006) Location = note active locations. Staff File (79) Practitioner Category = note active categories. Guarantors/Payors: Guarantor A: Identify a guarantor to be used with 'Payor Based Authorizations'. Note the values in the 'Authorization Section'. Verification Level For Authorizations For Client Charge Input and Verification Level For Authorizations For Appointment Scheduling: 'Disallow Service If Authorization Is Missing' will not allow the service to be submitted. 'Warn User If Authorization Is Missing' will allow the service to be submitted. Verification Level For Authorizations For 837 Electronic Billing: 'None' will allow services that were submitted and closed to be billed. 'Report As Error And Include On Bill' will allow services that were submitted and closed to be billed. An error message will be included in the 837 Billing report. 'Report As Error And Do Not Include On Bill' will not allow services that were submitted and closed to be billed Client A: Identify an active client that is assigned to the guarantor above. Payor Based Authorizations: Create or edit a definition to not include a 'Locations' and any other desired fields. An error message will be included in the 837 Billing report. Note the value of each field. Steps Open 'Payor Based Authorizations'. Create a new record that matches the record from setup. Validate that the following message displays: An authorization already exists for this date range. Overlapping authorizations are not allowed. Remove the 'Expiration Date'. Select a 'Location'. Enter an 'Expiration Date'. Submit the form and validate that it files successfully. Open ‘Scheduling Calendar’. Create an appointment for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Charge Input’. Create a service for Client A. Validate that the appropriate submission event occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open 'Close Charges’ and close charges for Client A if submission was allowed. Close the form. Open ‘Electronic Billing’ if submission was allowed. Create the bill for Client A and validate that the appropriate billing action occurs based on the values in the ‘Guarantors/Payors’, 'Authorization Section'. Close the form. Open ‘Client Ledger’ for Client A if submission was allowed. Review the ‘Simple’, ‘Ledger Type’ to confirm the billing activity. Close the form.	Topics • Payor Based Authorizations • NX
Update 17 Summary \| Details The 'BedAssignment' web service Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: SOAPUI - BedAssignment SOAPUI - BedAssignment - AddBedAssignment SOAPUI - BedAssignment - DeleteBedAssignment SOAPUI - BedAssignment - EditBedAssignment SOAPUI - BedAssignment - GetDictionaryItems Delete Bed Assignment Scenario 1: Validate the 'BedAssignment' - 'AddBedAssignment' web service Specific Setup: A client is enrolled in an existing inpatient episode (Client A). Steps Access SoapUI for the 'BedAssignment' - 'AddBedAssignment' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired date in the 'DateOfAssignment' field. Enter the desired time in the 'TimeOfAssignment' field. Enter the desired unit in the 'Unit' field. Enter the desired room in the 'Room' field. Enter the desired bed in the 'Bed' field. Enter the desired value in the 'RoomAndBoardBillingCode' field. Enter the desired value in the 'AdmissionChargeCode' field. Enter the desired value in the 'DailyChargeCode' field. Enter the desired value in the 'DailyChargeCode2' field. Enter the desired value in the 'DailyChargeCode3' field. Enter the desired value in the 'DailyChargeCode4' field. Enter the desired value in the 'DailyChargeCode5' field. Enter "Client A" in the 'ClientID' field. Enter the existing episode in the 'EpisodeNumber' field. Click [Run]. Validate the 'AddBedAssignmentResult' field contains the following: 'Confirmation' field containing a unique ID for the record. 'Message' field containing: Bed Assignment web service has been filed successfully. Select "Client A" and access the 'Bed Assignment' form. Validate the 'Date Of Bed Assignment' field contains the date filed in the previous steps. Validate the 'Time Of Bed Assignment' field contains the time filed in the previous steps. Validate the 'Unit' field contains the unit filed in the previous steps. Validate the 'Room' field contains the room filed in the previous steps. Validate the 'Bed' field contains the bed filed in the previous steps. Validate the 'Room And Board Billing Code' field contains the value filed in the previous steps. Validate the 'Admission Charge Code' field contains the value filed in the previous steps. Validate the 'Daily Charge Code' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 2' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 3' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 4' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 5' field contains the value filed in the previous steps. Close the form. Scenario 2: Validate the 'BedAssignment' - 'DeleteBedAssignment' web service Specific Setup: A client has an existing inpatient episode with a current & previous bed assignment record. The previous bed assignment must be available (Client A). Steps Select "Client A" and access the 'Bed Assignment' form. Validate the 'Unit' field contains the unit for the current bed assignment. Validate the 'Room' field contains the room for the current bed assignment. Validate the 'Bed' field contains the bed for the current bed assignment. Validate all other fields contain the values for the current bed assignment. Close the form. Access SoapUI for the 'BedAssignment' - 'DeleteBedAssignment' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter "Client A" in the 'ClientID' field. Enter the existing episode number in the 'EpisodeNumber' field. Enter the unique ID for the current bed assignment record in the 'UniqueID' field. Click [Run]. Validate the 'DeleteBedAssignmentResult' field contains the following: 'Confirmation' field containing the unique ID for the deleted record. 'Message' field containing: Bed Assignment web service has been filed successfully. Select "Client A" and access the 'Bed Assignment' form. Validate the 'Unit' field contains the unit from the previous bed assignment. Validate the 'Room' field contains the room from the previous bed assignment. Validate the 'Bed' field contains the bed from the previous bed assignment. Validate all other fields contain the values from the previous bed assignment. Close the form. Scenario 3: Validate the 'BedAssignment' - 'EditBedAssignment' web service Specific Setup: A client is enrolled in an existing inpatient episode (Client A). Steps Access SoapUI for the 'BedAssignment' - 'EditBedAssignment' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired time in the 'TimeOfAssignment' field. Enter the desired value in the 'RoomAndBoardBillingCode' field. Enter the desired value in the 'AdmissionChargeCode' field. Enter the desired value in the 'DailyChargeCode' field. Enter the desired value in the 'DailyChargeCode2' field. Enter the desired value in the 'DailyChargeCode3' field. Enter the desired value in the 'DailyChargeCode4' field. Enter the desired value in the 'DailyChargeCode5' field. Enter "Client A" in the 'ClientID' field. Enter the existing episode in the 'EpisodeNumber' field. Enter the unique ID for the existing record in the 'UniqueID' field. Click [Run]. Validate the 'EditBedAssignmentResult' field contains the following: 'Confirmation' field containing the unique ID for the record. 'Message' field containing: Bed Assignment web service has been filed successfully. Select "Client A" and access the 'Bed Assignment' form. Validate the 'Time Of Bed Assignment' field contains the time filed in the previous steps. Validate the 'Room And Board Billing Code' field contains the value filed in the previous steps. Validate the 'Admission Charge Code' field contains the value filed in the previous steps. Validate the 'Daily Charge Code' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 2' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 3' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 4' field contains the value filed in the previous steps. Validate the 'Daily Charge Code 5' field contains the value filed in the previous steps. Close the form. Scenario 4: Validate the 'BedAssignment' - 'GetDictionaryItems' web service Steps Access SoapUI for the 'BedAssignment' - 'GetDictionaryItems' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Click [Run]. Validate the 'GetDictionaryItemsResponse' field is populated with the defined dictionary values for the 'Bed Assignment' form.	Topics • Bed Assignment • Web Services • Delete Bed Assignment
Update 18 Summary \| Details SQL Table - SYSTEM.billing_tx_master_table Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Form and Table Documentation (PM) Scenario 1: billing_tx_master_table - Validating field length of the 'discipline_code' field Specific Setup: Registry Setting: The 'Fields to Include in Client Charge Input' registry setting is set to the value that includes '2'. Service Codes: Create a new service code or identify an existing service code. Note the service code. Select all the disciplines in the discipline field. Note all the disciplines selected. Steps Open the 'Crystal Report' or any other SQL data viewer. Query the SYSTEM.billing_tx_master_table for the discipline_code. Verify the 'discipline_code' field displays all the discipline codes for the selected disciplines in the 'Service Codes' form. Verify the 'discipline_value' field displays all the discipline values for the selected disciplines in the 'Service Codes' form.	Topics • Database Tables • NX
Update 20 Summary \| Details Site Specific Section Modeling - Add-On Service fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (CWS) Service Codes Clinical Document Viewer Scenario 1: Progress Note (Group and Individual) - Validating Add-On fields in the 'Site Specific Section Modeling' form when the 'Enable Multiple Add-On Code Per Primary Code Functionality' registry setting="Y". Specific Setup: The 'Enable Multiple Add-On Code Per Primary' registry setting is set to "Y". Using the "Service Codes" form, create 3 group service codes. Two of them must be primary add on codes and one of them must be a primary code. Admit a client into an outpatient episode. Steps Open the 'Site Specific Section Modeling (CWS)' form. Select 'CWSPN22000 (Progress Notes (Group and Individual)) Individual Progress Notes' in 'Site Specific Section'. Select the 'Prompt Definition' section. Select the 'Add-On Service' field. Click [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Select the 'Add-On Duration' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Select the 'Save Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Select the 'Selected Add-On Services' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Select the 'Select Add-On Service Entry to Edit/Remove' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Select the 'Remove Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "Yes". Submit the form. Open the 'Progress Notes (Group and Individual)' form. Validate the 'Add-On Service' field doesn't exist. Validate the 'Add-On Duration' field doesn't exist. Validate the 'Remove Add-On Service Entry to Edit/Remove' field doesn't exist. Validate the 'Remove Add-On Service' field doesn't exist. Validate the 'Selected Add-On Services' field doesn't exist. Validate the 'Save Add-On Service' field doesn't exist. Open the 'Site Specific Section Modeling (CWS)' form. Select the 'Prompt Definition' section. Select the 'Add-On Service' field. Click [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Select the 'Add-On Duration' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Select the 'Save Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Select the 'Selected Add-On Services' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Select the 'Select Add-On Service Entry to Edit/Remove' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Select the 'Remove Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is enabled. Set the 'Exclude from Data Collection Instrument' field to "No". Submit the form. Open the 'Progress Notes (Group and Individual)' form. Generate a "Group Default Note". Add the test client to the group using the Add Client fields on the form. File the Group Default Note. Select the test client from the "Select Group Note to Edit" field. Verify the 'Add-On Service' field exists. Verify the 'Add-On Duration' field exists. Verify the 'Select Add-On Service Entry to Edit/Remove' exists. Verify the 'Remove Add-On Service' button exists. Verify the 'Selected Add-On Services' field exists. Verify the 'Save Add-On Service' button exists. Individualize the progress note for the test client and populate the Add on service fields. Finalize and sign the document. Open the 'Progress Notes (Group and Individual)' form. Select the test client from the "Select Group Note to Edit" field. Verify the 'Add-On Service' field exists. Verify the 'Add-On Duration' field exists. Verify the 'Select Add-On Service Entry to Edit/Remove' exists. Verify the 'Remove Add-On Service' button exists. Verify the 'Selected Add-On Services' field exists. Verify the 'Save Add-On Service' button exists. Create the progress note for the test client and populate the Add on service fields. Finalize and sign the document. Using the "Client Ledger" form, validate the primary and add on services are on the client's ledger. Using the "Clinical Document Viewer" form, validate the documents display. Scenario 2: Progress Note (Group and Individual) - Validating Add-On fields in the 'Site Specific Section Modeling' form when the 'Enable Multiple Add-On Code Per Primary Code Functionality' registry setting="N" Specific Setup: The 'Enable Multiple Add-On Code Per Primary' registry setting is set to "N". Steps Open the 'Site Specific Section Modeling (CWS)' form. Select 'CWSPN22000 (Progress Notes (Group and Individual)) Individual Progress Notes' in 'Site Specific Section'. Select the 'Prompt Definition' section. Select the 'Add-On Service' field. Click [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Select the 'Add-On Duration' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Select the 'Save Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Select the 'Selected Add-On Services' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Select the 'Select Add-On Service Entry to Edit/Remove' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Select the 'Remove Add-On Service' field. Click the [Edit Selected Item]. Verify the 'Exclude from Data Collection Instrument' field is set to 'Yes' and disabled. Submit the form. Open the 'Progress Notes (Group and Individual)' form. Verify the 'Add-On Service' field does not exist. Verify the 'Add-On Duration' field does not exist. Verify the 'Select Add-On Service Entry to Edit/Remove' does not exist. Verify the 'Remove Add-On Service' button does not exist. Verify the 'Selected Add-On Services' field does not exist. Verify the 'Save Add-On Service' button does not exist. Click [Close Form].	Topics • Site Specific Section Modeling • Progress Notes
Update 21 Summary \| Details Client Search - Search on subscriber policy # or Medicaid # Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Scenario 1: Financial Eligibility - Client Search Change Subscriber Policy# Specific Setup: Admit a test client. Using the "Financial Eligibility" form: Populate all required fields. Populate "Subscriber Policy#. Note the data. Populate "Subscriber Medicaid#". Note the data. Steps Using the "Financial Eligibility" form: Change the "Subscriber Policy#" and "Subscriber Medicaid# values. Note the values. File the form. From the Home View, enter the value that was entered into "Subscriber Policy#" from Step 1. Validate it returns the correct result from the search on that value. From the Home View, enter the value that was entered into "Subscriber Medicaid#" from Step 1. Validate it returns the correct result from the search on that value. Scenario 2: Financial Eligibility - Add/Edit/Delete financial eligibility record Specific Setup: Guarantor/Payors: An existing guarantor is identified. Note the guarantor’s code/name. Admission: A new client is created, or an existing client is identified who does not have 'Fast Financial Eligibility', 'Family Financial Eligibility', 'Financial Eligibility', or 'Cross Episode Financial Eligibility' records created (Client A). Steps Select "Client A" and open the 'Financial Eligibility' form. Validate the 'Admission Date', 'Episode Number', 'Program', and 'Social Security Number' fields are populated, disabled, and readable. Select the 'Guarantor Selection' tab. Validate the 'Guarantor Information' grid is required. Validate the 'Guarantor #' field is required. Select any value from the 'Guarantor #' field. Validate the 'Guarantor Plan' field is required. Select any value from the 'Guarantor Plan' field. Validate the 'Customize Guarantor Plan' field is required. Select any value from the 'Customize Guarantor Plan' field. Validate the 'Eligibility Verified' field is required. Select any value from the 'Eligibility Verified' field. Validate the 'Coverage Effective Date' field is required. Set the 'Coverage Effective Date' field to any value. Validate the 'Client's Relationship To Subscriber' field is required. Select "Self" from the 'Client's Relationship To Subscriber' field. Validate the 'Subscriber's Name', the 'Subscriber's Address - Street Line 1', the 'Subscriber Address - Zip', the 'Subscriber Address - City', the 'Subscriber Address - State', the 'Subscriber's Social Security #', and the 'Subscriber Sex' fields are required and populate with "Client A". Tab down until the 'Subscriber Address - County' field is in focus. Press the 'space' key. Validate the search field is in focus. Enter any value and validate the expected search results display. Click the 'Subscriber Address - County' field so it is in focus again. Press any letter and validate the expected result displays. Validate the 'Subscriber Assignment Of Benefits' field is required. Select any value from 'Subscriber Assignment Of Benefits' field. Validate the 'Subscriber Release of Info' field is required. Select any value from the 'Subscriber Release of Info' field. Validate the 'Subscriber's Covered Days' field is required. Validate the 'Maximum Covered Dollars' field is required. Select the 'Financial Eligibility' tab. Select the Guarantor previously defined in the 'Guarantor #1' field. Click [Submit]. Select "Client A" and open the 'Financial Eligibility' form. Edit the financial eligibility record that was entered. Validate the data entered is retrieved and displayed. Click [Add New Item]. Validate that a new blank row is added. Click [Delete Selected Item]. Validate the "Are you Sure?" dialogue. Click [Yes]. Validate that the blank row is deleted successfully. Exit the form.	Topics • Admission • Financial Eligibility
Update 22 Summary \| Details 'Account Receivable Console' widget - 'Claim Follow-Up Entry' section Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Practitioner Numbers By Guarantor And Program Electronic Billing System Task Scheduler Service Codes AR Console User Defaults Setup AR Console Configuration 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. System Task Scheduler: The 'Auto AR Batch Update' was processed after the claims were created. Steps Open the ‘Account Receivable Console’ widget. Validate that the ‘Guarantor’ field contains the selected guarantors, including the guarantor with the ‘&’ in the 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' Enter the ‘Client ID for Client A. Click [Search]. Select a minimum of two claims in the ‘Claims with Outstanding Receivables’ gird. Click [Add Claim Follow-Up/Note]. Validate the claim number in ‘Claim Follow-Up’. Go to the Follow-Up Notes’ section. Validate the note created by the AR Console exists. Click [New Row]. Enter desired ‘Follow-Up Date’, ‘Comments’ and any other desired data. Click [File Updates]. Click [OK]. Select the row that was added above. Click [Copy Note]. Select the claim to copy the note to in ‘Copy Follow-Up Note’. Click [Save]. Select the claim number in ‘Claim Follow-Up’ that was selected in ‘Copy Follow-Up Note’. Validate that the copy note, and the note created by the AR Console exist in ‘Claim Follow-Up’. Select the ‘AR List’ section. Repeat steps 3 - 20 for Client B. Close the widget.	Topics • Accounts Receivable Management
Update 23 Summary \| Details Dictionary Update - Print dictionary Scenario 1: Dictionary Update - Client file - Add/Edit/Print dictionary Steps Open the 'Dictionary Update' form. Select 'Client' in the 'File' field. Select 'Location' in the 'Data Element' field. Enter desired code to the 'Dictionary Code' field. Note the code. Enter desired value to the 'Dictionary Value' field. Note the value. Enter in extended data elements as necessary. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Location Status' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values added in previous step display correctly. Close the report. Select 'Input Dictionary Code(s)' section. Verify the 'File' field contains 'Client'. Verify the 'Data Element' is set to the 'Location'. Select desired code which is added in previous step in the 'Dictionary Code' field. Verify the correct 'Dictionary Value' displays for the selected code. Update the value in the 'Dictionary Value' field. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Location' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values updated in previous step display correctly. Close the report. Close the form. Open the "Scheduling Calendar" form. Select an open time slot on the calendar and RightClick. Select "Add Appointment" from the dropdown. Note that the "Location" field contains the dictionary code(s)/value(s) entered in previous steps.	Topics • Dictionary
Update 24 Summary \| Details Program Transfer & Program Transfer (Outpatient) Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Program Transfer (OutPatient) Service Codes Program Transfer Scenario 1: Edit Service Program - Editing the service information after program transfer - Enable 'Admission vs. Service Program' Functionality registry setting Specific Setup: Registry Setting: The "Enable 'Admission vs. Service Program' Functionality" registry setting is set to 'Y'. Program Maintenance: Two new outpatient admission programs are created such that there is no overlap of the associated service programs between the two admission programs. Note the admission programs and associated service programs. Admission (Outpatient): The client is admitted into the first admission program. Client Charge Input: A service is rendered to the client under one of the associated service programs. Note the service date and service code. Program Transfer (Outpatient): The client is transferred into the second admission program. Steps Open the 'Edit Service Information' form. Fill in all required fields. Click [Select Service(s) to Edit]. Verify the 'Select Service(s) to Edit' dialog box launched with all the services rendered to the selected client. Select desired service to edit. Verify the 'Program' field is populated with the service programs that was associated with the admission program at the time of service creation. Submit the form. Verify the form submits successfully. Scenario 2: Program Transfer and Re-Admission - Validate that a client can no longer be actively admitted to the same outpatient program more than once. Specific Setup: Client was admitted to an outpatient program and then transferred to another outpatient program. Note the program the client was transferred to and the date of transfer. Steps Open 'Admission (Outpatient)' for the client. Set the 'Preadmit/Admission Time' to a date before the transfer date. Set the 'Program' to the program the client was transferred to. An error is correctly received because the client is currently enrolled in the program. Set the 'Preadmit/Admission Time' to a date after the transfer date. Set the 'Program' to the program the client was transferred to. An error is correctly received because the client is currently enrolled in the program. Scenario 3: File the 'Program Transfer' form Specific Setup: A client must be enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Program Transfer' form. Validate a Pre-Display is displayed. Select "Episode 1" in the Pre-Display and click [OK]. Enter the current date in the 'Date Of Transfer' field. Enter the current time in the 'Time of Transfer' field. Validate the 'Program Transferred From' field contains the program "Client A" is enrolled in. Select any outpatient program in the 'Program' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Create a query, specific to "Client A", using the 'SYSTEM.history_program_transfer' table. Validate that the data in the query is correct. Close the report. Scenario 4: Program Transfer - Validating program transfer for an inpatient and outpatient episode Specific Setup: Admission: A new inpatient client is admitted, or an existing inpatient client is identified. Note the client’s id/name, admission date/admission program. A new outpatient client is admitted, or an existing outpatient client is identified. Note the client’s id/name, admission date/admission program. Steps Select the 'Program Transfer' form. Select the inpatient client identified in the setup section. Validate the 'Program Transferred From' field contains the admission program of the client. Select desired new program from the admission program in the 'Program' field. Enter desired date in the 'Date Of Transfer' field. Enter desired time in the 'Time Of Transfer' field. Select desired 'Unit'. Select desired 'Room'. Select desired 'Bed' Click [Submit]. Open the 'Admission form' for the client. Verify the client transferred to the correct program. Close the form. Select the 'Program Transfer (Outpatient)' form. Select the outpatient client identified in the setup section. Validate the 'Program Transferred From' field contains the admission program of the client. Select the new program from the admission program in the 'Program' field. Enter desired date in the 'Date Of Transfer' field. Enter desired time in the 'Time Of Transfer' field. Click [Submit]. Open the 'Admission' or 'Admission (Outpatient)' form for the client. Verify the client transferred to the correct program. Close the form.	Topics • Edit Service Information • Program Transfer
Update 25 Summary \| Details SQL Table - SYSTEM.inhibit_billing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Inhibit Billing By Service Change MR# Electronic Billing Dynamic Form - Un-Inhibit services - Please review your selections to Un-Inhibit service Scenario 1: Inhibit Billing By Service - Validate billing inhibited / uninhibited service Specific Setup: A practitioner must be associated to the user that is logged into the application (Practitioner A). Admission: An existing client is identified in the system or create a new client. Note the client id, admission program/date. Guarantors/Payors: An existing guarantor is identified to be used as a primary guarantor. Note the guarantor code. Financial Eligibility: The guarantor identified above is assigned to the client as a primary guarantor. Diagnosis: Client has an admission diagnosis record. Service Codes: An existing service code is identified. Note the service codes / value. Service fee/Cross Maintenance: The fee definition is created for the service code to be used. Client Charge Input: A service is rendered to the client using the service code identified above. Client Ledger: The liability distributed to the primary guarantor of the client. Steps Open the 'Inhibit Billing By Service' form. Enter the practitioner associated to the logged in user in the 'Rendering Practitioner' field. Select any value from the 'Select Service(s) To Mark Billing-Inhibited' field. Click [Submit]. Validate a "Please review your selections" dialog is displayed. Click [OK]. Validate a "File Service Inhibit Information" dialog is displayed stating: Continue Filing? Click [Yes]. Validate a "Form Return" message is displayed stating: Submitting has completed. Do you wish to return to form? Click [No]. Open the 'Crystal report' or any other SQL data viewer. Run the 'Select * from SYSTEM.billing_tx_history where PATID=604'. Verify the 'billable_code' field displays 'X'. Run the 'Select * from SYSTEM.inhibit_billing where PATID=604'. Verify the data is filed in this table for the client. Open the 'Change MR #' form. Perform a Change MR # for this client to assign a new MR #. Run the 'Select * from SYSTEM.inhibit_billing where PATID=604'. Verify the table is updated with the new MR #. Close the report. File Import - Client Charge Input Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility File Import Electronic Billing Inhibited Services For Billing Report Client Inhibited Services (Service Date Less Than 1 Year Old) Service Codes Scenario 1: File Import - 'Client Charge Input' file type - Render a service to the client that is marked as a billing inhibited Specific Setup: Registry Settings: The registry setting 'Import File Delimiter' is set to desired value. Home View: The 'CLIENT INHIBITED FROM BILLING (SERVICE DATE LESS THAN 1 YEAR)' widget available on the home view. Program Maintenance: Identify an existing program code / name. Note the program code. Admission: An existing client is identified. Note the client id/name, admission date, admission program code/name. A 'Client Charge Input' import file is created to render a service to the client and mark that service billing inhibited. The predefined client, episode number, practitioner id, service code, admission program and cost of the service are entered in the file. Steps Open the 'File Import' form. Select the 'Client Charge Input' from the 'File Type' field. Upload the file Import file created in the setup section to mark a service as a billing inhibited. Compile the file. Verify that the file compiles successfully. Select the 'Print File' option. Review the information on compile report. Verify that all the information entered through the 'File Import' file displayed correctly in the specific field. Post the compiled file. Verify that the file posted successfully. Open the 'Crystal Report' or any other SQL data viewer. Run the query against SYSTEM.billing_tx_history table. Verify the 'billable_code' displays 'X'. Run the query against SYSTEM.inhibit_billing SQL table. Verify the inhibited service record is added in this table. Close the Crystal Report or the SQL Data Viewer. Locate to the 'CLIENT INHIBITED SERVICES (SERVICE DATE LESS THAN 1 YEAR OLD)' WIDGET. Verify the 'Client Name' and 'Episode' column displays the client name and episode for the client for whom the inhibited service is rendered through file import. Open the 'Inhibited Services For Billing report' form. Enter desired date in the 'Start Date' field. Enter desired date in the 'End Date' field. Select desired client in the 'Client' field. Click [Process Report]. Verify the inhibited service record displays in the report correctly. Close the report. Scenario 2: File Import - 'Client Charge Input' file type - Render a service to the client that is marked as a billing non inhibited Specific Setup: Registry Settings: The registry setting 'Import File Delimiter' is set to desired value. Program Maintenance: Identify an existing program code / name. Note the program code. Admission: An existing client is identified. Note the client id/name, admission date, admission program code/name. A 'Client Charge Input' import file is created to render a service to the client and mark that service billing non inhibited. The predefined client, episode number, practitioner id, service code, admission program and cost of the service are entered in the file. Steps Open the 'File Import' form. Select the 'Client Charge Input' from the 'File Type' field. Upload the file Import file created in the setup section to mark a service as a billing inhibited. Compile the file. Verify that the file compiles successfully. Select the 'Print File' option. Review the information on compile report. Verify that all the information entered through the 'File Import' file displayed correctly in the specific field. Post the compiled file. Verify that the file posted successfully. Open the 'Crystal Report' or any other SQL data viewer. Run the query against SYSTEM.billing_tx_history SQL table. Verify the 'billable_code' code column is blank for the service. Run the query against SYSTEM.inhibit_billing SQL table. Verify the table does not contain the non inhibited service record of the client. Close the Crystal Report or the SQL Data Viewer. Locate to the 'CLIENT INHIBITED SERVICES (SERVICE DATE LESS THAN 1 YEAR OLD)' WIDGET. Verify the 'Client Name' and 'Episode' column does not display the client name and episode for the client for whom the non inhibited service is rendered through file import. Open the 'Inhibited Services For Billing Report' form. Enter desired date in the 'Start Date' field. Enter desired date in the 'End Date' field. Select desired client in the 'Client' field. Click [Process Report]. Verify the non inhibited service record does not display in the report. Close the report.	Topics • Inhibit Billing • File Import • Database Tables
Update 26 Summary \| Details Scheduling Calendar - Group Appointment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dynamic Form - Group Member Selection Dynamic Form Group Group Registration Scenario 1: 'Scheduling Calendar': Add New, Check- In, and Check Out Individual and Group Appointments Specific Setup: A client must be enrolled in an existing episode (Client A). A group must exist with at least two group members (Group A). The 'Receipt Definition' form is configured. The posting codes being used must have "Yes" selected in the 'Generate Receipt' field in the 'Post/Adjustment Codes Definition' form. Steps Access the 'Scheduling Calendar' form. Right click in any available time slot and click [Add Appointment]. Enter the desired value in the 'Service Code' field. Enter "Client A" in the 'Client' field. Select the desired episode in the 'Episode Number' field. Select the desired value in the 'Program' field. Click [Submit]. Validate the 'Appointment Grid' contains the appointment created in the previous steps. Right click on the appointment and click [Check In]. Validate the 'Scheduling Calendar - Check In' window is displayed. Enter the desired value in the 'Amount Received At Check In' field. Select the desired value in the 'Payment Code' field. Click [Submit]. Validate a receipt is displayed for the payment collected. Validate the 'Appointment Grid' contains the checked in appointment. Right click on the appointment and click [Check Out]. Validate the 'Scheduling Calendar - Check Out' window is displayed. Enter the desired value in the 'Amount Received At Check Out' field. Select the desired value in the 'Payment Code' field. Click [Submit]. Validate a receipt is displayed for the payment collected. Validate the 'Appointment Grid' contains the checked out appointment. Right click in any available time slot and click [Add Appointment]. Enter any group service code in the 'Service Code' field. Enter "Group A" in the 'Group #' field. Select the desired program in the 'Program' field. Select the 'Group Members' item. Validate the 'Current Group Appointment Members' field contains all group members. Click [Submit]. Validate the 'Appointment Grid' contains the group appointment created in the previous steps. Right click on the group appointment and click [Check In]. Select all group members. Validate the 'Scheduling Calendar - Check In' window is displayed. Enter the desired value in the 'Amount Received At Check In' field. Select the desired value in the 'Payment Code' field. Click [Submit]. Note: this will need to be submitted for all group members. Validate a receipt is displayed for the payment collected. Right click on the group appointment and click [Check Out]. Select all group members. Validate the 'Scheduling Calendar - Check Out' window is displayed. Enter the desired value in the 'Amount Received At Check Out' field. Select the desired value in the 'Payment Code' field. Click [Submit]. Note: this will need to be submitted for all group members. Validate a receipt is displayed for the payment collected. Validate the 'Appointment Grid' contains the checked out group appointment. Click [Dismiss].	Topics • Appointment Management
Update 27 Summary \| Details Default Guarantor Assignment - Cross Episode Financial Eligibility Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Family Registration Family Financial Eligibility Financial Eligibility Cross Episode Financial Eligibility Default Guarantor Assignment Financial Eligibility Web Service Scenario 1: Registry Setting - Enable Default Guarantor Assignment Specific Setup: Registry Setting - Enable Default Guarantor Assignment = N. Family Registration: Family 1 has no ‘Family Financial Eligibility’ record. Family 2 has a Family Financial Eligibility’ record. Note the assigned guarantors. Client: Client 1: Is admitted in one episode and has no ‘Financial Eligibility’ record. Client 2: Is admitted in one episode and has a Financial Eligibility’ record. Note the assigned guarantors. Client 3: Is admitted in multiple episodes and has no ‘Cross Episode Financial Eligibility’ record. Client 4: Is admitted in multiple episodes and has a ‘Cross Episode Financial Eligibility’ record. Note the assigned guarantors. Guarantors/Payors: Guarantors are identified that will be added to ‘Guarantor Order’ in the ‘Default Guarantor Assignment’ form. The guarantors that were noted in the financial eligibility records will be added and guarantors that were not in the financial eligibility records will also be added. Steps 1. Open ‘Registry Settings’. 2. Add a value of ‘Y’ to the ‘Enable Default Guarantor Assignment’ setting. 3. Click [Submit]. 4. Close the form. 5. Open ‘Default Guarantor Assignment’. 6. Click [Clear Guarantor Oder], if the ‘Guarantor Order’ text box contains data. 7. In ‘Select Guarantor to Default‘ field select guarantors in the order that will default into the financial eligibility records. Note the values. 8. Select ‘Entry to Financial Eligibility Forms’ in ‘Default the Guarantor(s) During’. 9. Select ‘Family Financial Eligibility’ in ‘Add the Guarantor(s) to Which Form’. 10. Select ‘None Exists’ in ‘Default the Guarantor(s) Only If’. 11. Click [Submit]. 12. Open ‘Family Financial Eligibility’ for Family 1. 13. Select the ‘Guarantor Selection’ item. 14. Validate that a ‘Guarantor Selection’ row exists for each of the guarantors in the ‘Guarantor Order’ and that row 1 contains the first guarantor in the order, row 2 contains the second guarantor in the order, and so forth. 15. If desired, select the ‘Guarantor Assignment’ item and assign desired guarantors to the family members. 16. Close the form. 17. Open ‘Default Guarantor Assignment’. 18. Select ‘Not a Part of Financial Eligibility/Cross Episode Financial Eligibility/Family Financial Eligibility’ in ‘Default the Guarantor(s) Only If’. 19. Open ‘Family Financial Eligibility’ for Family 2. 20. Select the ‘Guarantor Selection’ item. 21. Validate that a ‘Guarantor Selection’ row exists for each of the guarantors in the ‘Guarantor Order’ and that the existing guarantor is in row 1. 22. If desired, select the ‘Guarantor Assignment’ item and assign desired guarantors to the family members. It will be necessary to click [Clear Current Assignments] after selecting the family member. 23. Close the form. 24. Repeat steps 4 - 22 for the 'Financial Eligibility’ form and Client 1, and Client 2. 25. Repeat steps 4 - 22 for the 'Cross Episode Financial Eligibility’ form and Client 3, and Client 4. 26. Open ‘Default Guarantor Assignment’. 27. Select 'Filing of Admission' in 'Default the Guarantor(s) During' 28. Select 'Financial Eligibility' in 'Add the Guarantor(s) to Which Form'. 29. Click [Submit]. 30. Enroll Client 1 in a new episode. 31. Open ‘Financial Eligibility’ for Client 1. 32. Validate that a ‘Guarantor Selection’ row exists for each of the guarantors in the ‘Guarantor Order’ and that row 1 contains the first guarantor in the order, row 2 contains the second guarantor in the order, and so forth. 33. Click [Discard]. 34. Open 'Cross Episode Financial Eligibility' for Client 3. 35. Delete all guarantors. 36. Click [Submit]. 37. Open ‘Default Guarantor Assignment’. 38. Select 'Filing of Admission' in 'Default the Guarantor(s) During' 39. Select 'Cross Episode Financial Eligibility' in 'Add the Guarantor(s) to Which Form'. 40. Click [Submit]. 41. Enroll Client 3 into another episode, 42. Open 'Cross Episode Financial Eligibility'. 43. Validate that a ‘Guarantor Selection’ row exists for each of the guarantors in the ‘Guarantor Order’ and that row 1 contains the first guarantor in the order, row 2 contains the second guarantor in the order, and so forth. 44. Click [Discard]. Scenario 2: PM - Financial Eligibility Web Service - Verification of web service filing Specific Setup: Client A: Has one or more episodes eligible for a Financial Eligibility record. The 'FinancialEligibility' web services has been used to add a Financial Eligibility record and used to update the added record. Note the field values when the record is added. Validate that a successful filing message is received. Change at least one field. Note the field values for all changed fields. Validate that a successful filing message is received. Steps Open ‘Financial Eligibility’ for Client A, selecting the episode if needed. Verify that the guarantor order is correct. Select the ‘Guarantor Selection’ section. Select the desired guarantor in ‘Guarantor Information’ Click [Edit Selected Item]. Verify that the values filed in the web service application are correct, and that the fields that were changed contain the new value. Repeat steps 4 & 5 for additional guarantors if more than one guarantor was added through the web service request. Close the form. Financial Eligibility - Web Services Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Cross Episode Financial Eligibility Web Service Cross Episode Financial Eligibility Scenario 1: 'CrossEpisodeFinancialEligibility' Web Service - Verification of 'AddCrossEpFinancialElig' Filing Specific Setup: Application utilizing the Avatar PM 'CrossEpisodeFinancialEligibility' web service. Steps Using Avatar PM 'CrossEpisodeFinancialEligibility' web service, submit request to 'AddCrossEpFinancialElig' method to create new Avatar PM Cross Episode Financial Eligibility record. Confirm 'CrossEpisodeFinancialEligibility' web service responds with confirmation data on successful filing of 'AddCrossEpFinancialElig' method. Example: "<Confirmation>Unique ID: 123~POR.00001</Confirmation>" Confirm 'CrossEpisodeFinancialEligibility' web service responds with confirmation message on successful filing of 'AddCrossEpFinancialElig' method. Example: "<Message>Cross Episode Financial Eligibility web service has been filed successfully.</Message>" Confirm 'CrossEpisodeFinancialEligibility' web service responds with successful status value on successful filing of 'AddCrossEpFinancialElig' method. Example: " <Status>1</Status>" Open Avatar PM 'Cross Episode Financial Eligibility' form and select client filed via web service for view/update. Confirm new Cross Episode Financial Eligibility record is created in Avatar PM, with values/data submitted via web service. Scenario 2: 'CrossEpisodeFinancialEligibility' Web Service - Verification of 'UpdateCrossEpFinancialElig' Filing Specific Setup: Application utilizing the Avatar PM 'CrossEpisodeFinancialEligibility' web service. Steps Using Avatar PM 'CrossEpisodeFinancialEligibility' web service, submit request to 'UpdateCrossEpFinancialElig' method to update existing Avatar PM Cross Episode Financial Eligibility record. Confirm 'CrossEpisodeFinancialEligibility' web service responds with confirmation data on successful filing of 'UpdateCrossEpFinancialElig' method. Example: "<Confirmation>Unique ID: 123~POR.00001</Confirmation>" Confirm 'CrossEpisodeFinancialEligibility' web service responds with confirmation message on successful filing of 'UpdateCrossEpFinancialElig' method. Example: "<Message>Cross Episode Financial Eligibility web service has been filed successfully.</Message>" Confirm 'CrossEpisodeFinancialEligibility' web service responds with successful status value on successful filing of 'UpdateCrossEpFinancialElig' method. Example: " <Status>1</Status>" Open Avatar PM 'Cross Episode Financial Eligibility' form and select client filed via web service for view/update. Confirm Cross Episode Financial Eligibility record is updated in Avatar PM, with values/data submitted via web service.	Topics • Registry Settings • Financial Eligibility • NX • Default Guarantor Assignment • Web Services • Cross Episode Financial Eligibility
Update 28 Summary \| Details Admission - 'Activate Program/Service Code Filter' registry setting Scenario 1: Admission - Validate the 'Activate Program/Service Code Filter' registry setting Specific Setup: The 'Activate Program/Service Code Filter' registry setting is set to "Y". An inpatient program is defined with associated services in the 'Program Maintenance' form (Program A). Steps Access the 'Admission' form. Verify the 'Select Client' dialog is displayed. Enter any new value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [Search]. Validate a "Search Results" message is displayed stating: No matches found. Click [New Client]. Validate a "Client" message displays indicating "Auto Assign Next ID Number?" Click [Yes]. Enter the current date in the 'Preadmit/Admission Date' field. Enter the current time in the 'Preadmit/Admission Time' field. Select "Program A" in the 'Program' field. Select any value in the 'Type Of Admission' field. Select any value in the 'Source Of Admission' field. Enter the desired practitioner in the 'Admitting Practitioner' field. Enter the desired practitioner in the 'Attending Practitioner' field. Select the 'Inpatient/Partial/Day Treatment' section. Select any value in the 'Unit' field. Select any value in the 'Room' field. Select any value in the 'Bed' field. Select any value in the 'Licensed/Unlicensed' field. Validate only services assigned to "Program A" display in the 'Room And Board Billing Code' field. Validate only services assigned to "Program A" display in the 'Daily Charge Code' field. Validate only services assigned to "Program A" display in the 'Admission Charge Code' field. Click [Submit]. Select the client admitted in the previous steps and access the 'Admission' form. Validate the new episode is displayed and click [Edit]. Validate all previously filed admission data is displayed. Close the form.	Topics • Registry Settings • Admission
Update 29 Summary \| Details Web Services - PostingAdjustmentCodes Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Scenario 1: 'PostingAdjustmentCodes' Web Service - Verification Of 'AddPostingAdjustmentCodes' and 'UpdatePostingAdjustmentCodes' filing Specific Setup: Web service testing tool: SoapUI or any other web service testing tool needs to be set up to test this scenario. Steps Create a SoapUI project for Avatar PM 'PostingAdjustmentCodes' web service. Submit a request for 'AddPostingAdjustmentCodes' method to add new posting adjustment code. Note the posting code/definition. Verify the 'PostingAdjustmentCodes' web service files successfully and responds with confirmation message for 'AddPostingAdjustmentCodes' method. <Message>Posting/Adjustment Codes Input web service has been filed successfully.</Message>. Verify the 'PostingAdjustmentCodes' web service responds with successful status value on successful filing of 'AddPostingAdjustmentCodes' method. Example: <Status>1</Status>. Open 'Posting/Adjustment Codes Definition' form. Verify the newly added posting adjustment code displays correctly with all the values entered through web service. Note the posting code and code definition. Navigate to the SoapUI. Submit a request for 'UpdatePostingAdjustmentCodes' method to update a code definition for the recently added posting adjustment code in above steps. Enter different code definition for the posting code added above. Note the posting definition. Verify the 'PostingAdjustmentCodes' web service files successfully and responds with confirmation message for 'UpdatePostingAdjustmentCodes' method. <Message>Posting/Adjustment Codes Input web service has been filed successfully.</Message> Verify the 'PostingAdjustmentCodes' web service responds with successful status value on successful filing of 'UpdatePostingAdjustmentCodes' method. Example: <Status>1</Status>. Open 'Posting/Adjustment Codes Definition' form. Verify the recently updated posting adjustment code displays correct code definition updated through web service. Registry Settings - Enable Alternative Service Location Fields - Electronic billing validation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Electronic Billing Scenario 1: 837 Error Report - Items outside of date range selected for billing Specific Setup: Registry Setting: 'Enable Alternative Service Location Fields' is enabled. Note the fields that will be added to 'Edit Service Information'. Identify a client with unbilled services. Note the service date range and the guarantor. Edit the last service to add data for only the fields enabled by the above registry setting. Steps Open ‘Electronic Billing’. Create a bill for the services that does not include the date of services for the edited service. Print the report. Validate that no error is reported for the date of service of the edited bill. Close the report. Close the form. Scenario 2: Registry Settings - Enable Alternative Service Location Fields - Validating electronic billing Specific Setup: Registry settings: The 'Avatar PM->Billing->Client Charge Input->->->Enable Alternative Service Location Fields' registry setting is enabled. Please note: This is a hidden registry setting and may require a Netsmart Support Associate's assistance in checking and setting. Guarantors/Payors: An existing guarantor is identified to be used. Note the guarantor's 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. Diagnosis: An admission diagnosis record is created for the client. Client Charge Input: 5-6 services are rendered to the client in one month and other 5-6 services in another month. Note service dates, service code. Client Ledger: A service distributed correctly to the assigned guarantor. Steps Open the 'Edit Service Information' form. Select a desired client. Validate the alternative service location fields listed on the form are. Facility Location Name, Facility Location State, Facility Location Code Qualifier, Facility Location Code Identifier, Facility Location Address Street, Facility Location City, Facility Location Zip Code. Click [Select Services to Edit]. Select one of the service from the second month to be edited. Select / enter desired values for one of the new fields added via the registry setting. Leave other fields blank. File the form. Open the 'Electronic Billing' form. Select 837 Professional or 837 Institutional in 'Billing Form' field. Select values for 837 bill generation in the 'Type of Bill', 'Individual or All Guarantors' and 'Billing Type' fields. Select 'Sort File' in the 'Billing Options' field. Select/enter values for service inclusion in 'All Clients or Interim Billing Batch' and 'Program(s)' fields. Select only first month of service to bill. Select/enter values for 'Create Claims' (and 'Date of Claim' if 'Yes'), 'First Date of Service to Include' and 'Last Date of Service to Include' fields. Select/enter values for any other bill sorting criteria fields as required/desired. Click [Process]. Verify the bill compiles successfully. Guarantors/Payors - Database Management Scenario 1: 'Guarantors/Payors' - Form Verification Specific Setup: Avatar State Forms Registry Setting 'Enable Texas TMHP Billing' must be enabled. Steps Open the Avatar PM 'Guarantors/Payors' form. Select Add or Edit action in 'Add New or Edit Existing Guarantor' field. Enter new (or select existing) Guarantor Code. Complete all required/desired fields in main section of 'Guarantors/Payors' form. Navigate to '837' section of 'Guarantors/Payors' form. Ensure that the 'TMHP Waiver Skip 2300-REF Segment' field is available in form. If 'Yes' is selected in this field, 837 Professional files sorted/created for this Guarantor via 'Electronic Billing' forms/functions (and subject to 'Enable Texas TMHP Billing' functionality/values) will conditionally skip/omit the 2300-REF segment/value for 'TMHP Waiver Reference Number'. Select value for 'TMHP Waiver Skip 2300-REF Segment' field (and any other desired fields in '837' section of form). Navigate to main section of 'Guarantors/Payors' form. Click 'File' button to save/file Guarantor/Payor definition information. Select 'Edit' action and select previously filed Guarantor Code. Navigate to '837' section of 'Guarantors/Payors' form. Ensure that previously selected/filed value for 'TMHP Waiver Skip 2300-REF Segment' field is present/selected in form. Managed Care Authorizations - Monthly Limitation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Service Codes Managed Care Authorizations Scenario 1: Managed Care Authorizations - Monthly Limitations - Scheduling Calendar Specific Setup: Managed Care Authorizations: Identify a client with a 'Managed Care Authorization’ that contains a monthly limitation. Note the guarantor that the authorization is for. Note the limitation and if any of the units/dollars or visits have been used. Guarantors/Payors: Note the value of the ‘Verification Level For Authorizations For Appointment Scheduling’. ‘Warn User If Authorization Is Missing’ will display a warning in scheduling but allow the user to file the appointment. Disallow Service If Authorization Is Missing’ will display an error message and prevent the appointment from being filed. Steps Open ‘Scheduling Calendar’. Schedule an appointment that will not cause the service to be over the monthly limitation. Validate that the appointment files successfully. Schedule an appointment on the same day, with a different service code, or on the following day that will cause the service to be over the monthly limitation. Validate that the appropriate warning message or error message displays. If the warning message displays, click [OK] and [Submit]. Verify that the appointment filed successfully. If the error message displays, click [OK] and validate that the ‘Service Code’ field is null and discard the form. Validate that the ‘Are you sure you want to Close without saving’ message is received. Click [Yes]. Click [Dismiss].	Topics • Web Services • 837 Professional • 837 Institutional • NX • 835 • Guarantor/Payors • Managed Care Authorizations
Update 30 Summary \| Details 99999 Services Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility 99999 Services Report Scenario 1: 99999 Services Report - Validating liability distribution failure message when the full liability distributes to the default guarantor Specific Setup: Guarantors/Payors: Identify an existing guarantor with the financial class of Non-recoverable to be used as a default guarantor. Note the guarantor’s id/name. Registry Setting: The 'Track Services That Failed Liability Distribution' registry setting is set to "Y". Admission: An existing client is identified, or a new client is admitted. Note the client id, name, and admission date. Financial Eligibility: The financial eligibility record is created for the client so that the coverage effective date is after date of services to be rendered to the client. Note the 'Coverage Effective Date'. Client Charge Input: A service is rendered to the client such that it is prior to the 'Coverage Effective Date' set up in the client's 'Financial eligibility'. Note the date of service. Make sure the service is in open state. Client Ledger: The service rendered to the client are distributed to the default guarantor (99999). Steps Open the '99999 Services Report' form. Verify the 'Run Report By' field exists on the form and is required. This is a single-select field and defaults to ''All Services", and contains "Service Dates", and "Accounting Period". Verify that the ‘Export’ button fields is enabled. Verify that the following fields are disabled: ‘Service From Date’, ‘Service To Date’, Month/Year of Accounting Period Close'. Verify that the 'Include Closed Services' exists and defaults to "No". Select "Yes" in 'Include Closed Services'. Click [Export]. Verify that the exported file was saved to the desktop. Open the file. Verify the file displays all the open/closed services that distributed to the Default Guarantor and lists the reason the services failed liability distribution for all guarantors from the client’s applicable Financial Eligibility list. Return to the '99999 Services Report' form. Select "Service Dates" in 'Run Report By' field. Verify that 'Service From Date' and 'Service To Date' are required. Enter first date of service rendered to client in 'Service From Date' field. Enter last date of service rendered to client in 'Service To Date' field. Select "No" in the 'Include Closed Services' field. Click [Export]. Verify that the exported file was saved to the desktop. Open the file. Verify the file displays all the open/closed services that distributed to the Default Guarantor and lists the reason the services failed liability distribution for all guarantors from the client’s applicable Financial Eligibility list. Return to the '99999 Services Report' form. Select "Accounting Period" in 'Run Report By' field. Verify that 'Month/Year of Accounting Period Close' is required. Enter the desired month/year as MM/YY. Click [Export]. Verify that the exported file was saved to the desktop. Open the file. Verify the file displays all the open/closed services that distributed to the Default Guarantor and lists the reason the services failed liability distribution for all guarantors from the client’s applicable Financial Eligibility list. Return to the '99999 Services Report' form. Close the form. Open 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_tx_dist_fail_reason' SQL table. Validate the 'PATID' column is equal to the client id identified in the pre-conditions. Validate the 'date_of_service' column is equal to the service dates for the services rendered to the client. Validate the 'reason' column contains the reason the service failed liability distribution. Validate the 'GUARANTOR_ID' column is equal to the guarantor assigned to the client in the financial eligibility. Open the 'Financial Eligibility' form. Update client's eligibility record and set up the coverage effective date so that it covers all the services rendered to the client. Open the 'Close Charges' form. Run the liability update for the client. Open the 'Client Ledger' for the client. Verify that the services are distributed to the correct guarantor assigned to the client in financial eligibility. Open 'Crystal Report' or any other SQL data viewer. Query the 'SYSTEM.billing_tx_dist_fail_reason' SQL table for the desired client setup. Verify there are no services found in the table for the desired client. Return to the '99999 Services Report' form. Select "Service Dates' in 'Run Report By' field. Enter first date of service rendered to client in 'Service From Date' field. Enter last date of service rendered to client in 'Service To Date' field. Select "Yes" in 'Include Closed Services'. Click [Export]. Validate that a message is received stating: No data found to export. Close the form.	Topics • Financial Eligibility • Database Management
Update 31 Summary \| Details Web Service - WEBSVC.AppointmentScheduling.CLS Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: SOAPUI - FileClientChargeInputICD10 SOAPUI - AddAppointment Scenario 1: Client Charge Input - Validate the 'FileClientChargeInputICD10' web service Specific Setup: 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. Steps Open SoapUI or any other web service tool. Set up the 'FileClientChargeInputICD10' method of the 'ClientChargeInput' web service. Create a new Client Charge Input request for a desired client by specifying the Date of Service, ClientID, Episode Number, diagnosis information and service code within quotes. Verify the web service displays error message: The following fields are invalid : Service Code : Invalid Service code : "[SERVICE CODE]". Remove the quotes from the web service request. File the request again. Verify the web service files successfully and displays confirmation message: "Client Charge Input web service has been filed successfully." Login to Avatar. Open the 'Edit Service Information' form. Select desired client. Select desired service. Verify the service details are correct as filed via web service request. Click [Submit]. Click [No]. Scenario 2: Appointment Scheduling Web Services - Validating 'AddAppointment' method Specific Setup: Practitioner Enrollment: An existing practitioner is identified. Note practitioner code/name. Staff Members Hours and Exceptions: The practitioner identified above is defined with hours. 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. Steps Access SOAPUI or any other web service tool. File the 'AddAppointment' method of the Appointment Scheduling web service. Login to Avatar. Open the 'Scheduling Calendar' form. Verify that the appointment is on the calendar and the appointment details are correct as filed in the web service. Edit Service Information - Editing service for the client Scenario 1: Edit Service Information - Field Validation Specific Setup: Registry Setting: The 'Enable Program Filter By Facility Identification Code' registry setting is enabled. 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. 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 Open the 'Edit Service Information' form. Select the desired client in the 'Client ID' field. Select desired episode from the 'Episode Number' field. Click [Select Service(s) To Edit]. Verify the 'Select Service(s) To Edit' dialog is displayed. Select desired service from the 'Select Service(s) To Edit' dialog. Enter a different value in the 'Duration (Minutes)' field. Select a new service code in the 'Service Code' field. Click [OK]. Submit the form. Validate a "Form Return" message is displayed stating: Submitting has completed. Do you wish to return to form? Click [No]. Query the 'SYSTEM.billing_tx_history' SQL table. Validate the 'PATID' column is equal to the correct client id identified in the setup. Validate the 'date_of_service' column is equal to correct date of service rendered to the client. Validate the 'duration' column is equal to the correct duration added in the 'Edit Service Information' form. Validate the 'Service Code' column contains correct service code submitted in the 'Edit Service Information' form. Validate the 'option_desc' column contains 'Edit Service Information'. Close the crystal report. Widget - Advanced Billing Rule Failed Compliance Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Advanced Billing Failed Compliance Report Service Codes Advanced Billing Rule Definition Advanced Billing Rule Failed Compliance widget Financial Eligibility Advanced Billing Rule Failed Compliance Scenario 1: Advanced Billing Rule - Advanced Billing Failed Compliance Report Specific Setup: A service code with a code length of 20 characters exists. An Advanced Billing Rule Definition exists for the above service code. Note the conditions that will allow the service code to fail compliance. Note the 'Reason For Failed Compliance'. Create a service for a client that will cause the service code to fail compliance. Note the service date. Steps Open 'Advance Billing Failed Compliance Report'. Enter the 'Client'. Enter the service date in 'Service From Date' and Service Through Date'. Click [Launch Failed Compliance Report]. Validate the 'Client'. Validate the 'Service Code'. Validate the 'Rule Description'. Validate the 'Reason for Failed Compliance'. Close the report. Close the form. Scenario 2: Advanced Billing Rule - Verify the Advanced Billing Rule Failed Compliance widget Specific Setup: Home View: The 'Advanced Billing Rule Failed Compliance' widget is available on the home view. Admission: An existing client is identified in the system or create a new client with an outpatient episode. Note the client id, admission program/date. Guarantors/Payors: An existing guarantor is identified to be used as a primary guarantor. Note Guarantor code/Id. Financial Eligibility: The guarantor identified above is assigned to the client as a primary guarantor. Diagnosis: Client has an admission diagnosis record. Note the ICD 10 code of the diagnosis. Service Codes: Two existing service code are identified. Note service codes. Service fee/Cross Maintenance: The fee definitions are created for the service codes. Advanced Billing Rule Definition: Advanced Billing Rule Description - Desired value Active - Yes Service Code = desired service code Select Service(s) That Must Also Be Rendered For Distribution = desired service code Guarantor = Primary guarantor assigned to the client Effective date = desired date Gender = All Genders Associated To Age = No Rule Defines Condition For = Compliance Rule Result In = Message Only Client Charge Input: A service is rendered to the client using the service code identified above. Client Ledger: The liability distributed to the primary guarantor of the client. Steps Locate To the 'Advanced Billing Rule Failed Compliance' widget. Verify the client is added in the widget and the diagnosis listed under 'Dx Code' column is ICD10 code of the diagnosis. File Import - Roll-Up Services Definition Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Roll-Up Services Definition Scenario 1: Roll-Up Services Definition - File Import Specific Setup: File Import: Import files have been created to add, edit, and delete a Roll-Up Services Definition that contains multiple practitioner categories. Steps Open ‘File Import’. Select 'Roll-Up Services Definition' in ‘File Type’. Click [Upload New File] in ‘Action’. Click [Process Action]. Upload the file that will add the 'Roll-Up Services Definition'. Click [Compile/Validate File] in ‘Action’. Select the uploaded file. Click [Process Action]. If there are errors, click [Print Errors] in ‘Action’. Select the compiled file. Click [Process Action]. Review the report and upload and compile again to resolve the errors. Click [Print File] in ‘Action’. Click [Process Action]. Review the report to validate the data. Click [Post File] in ‘Action’. Select the compiled file. Click [Process Action]. If desired, Click [Delete File] in ‘Action’. Select the posted file. Click [Process Action]. The ‘Delete File’ message will display. Click desired value. If [Yes], the ‘Confirm message will display. Click [OK]. If [No], the ‘Delete File’ message is removed. Close the form. Open 'Roll-Up Services Definition'. Validate that the definition imported with the correct values. Close the form. Repeat steps 1-24 for the file that will edit the 'Roll-Up Services Definition'. Open 'Roll-Up Services Definition'. Validate that the edited definition contains the correct values in the edited fields. Close the form. Repeat steps 1-24 for the file that will delete the 'Roll-Up Services Definition'. Open 'Roll-Up Services Definition'. Validate that the deleted definition does not exist. Close the form.	Topics • Add New Appointment • Web Services • Edit Service Information • NX • Advanced Billing Rule Definition • File Import • Roll-Up Services Definition
Update 32 Summary \| Details File Import - Deposit Entry Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Posting/Adjustment Codes Definition File Import Roll-Up Services Definition Scenario 1: File Import - Deposit Entry' - file with all the required/optional fields Specific Setup: Registry Setting: Set the 'Avatar PM->System Maintenance->File Import->->->Import File Delimiter' registry setting to the desired value. Guarantors/Payor: An existing guarantor is identified to be assigned to the client. Note the guarantor code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Identify the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the Client id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. File Import: An import file is created to process the deposit entry. Ensure that the file contains all required fields and desired optional fields. Note the file name / location of the file. Steps 1. Open the 'File Import' form. 2. Select the 'Deposit Entry' from the File Type field. 3. Upload the file Import file created in the setup section. 4. Compile the file. 5. Verify the file compiles successfully. 6. Post the compiled file. 7. Verify the file posted successfully. 8. Open the 'Client Ledger' for the client. 9. Process the report. 10. Verify the client ledger displays the deposit entry correctly. 11. Close the Report. 12. Close the form. Scenario 2: Roll-Up Services Definition - File Import Specific Setup: File Import: Import files have been created to add, edit, and delete a Roll-Up Services Definition. Steps Open ‘File Import’. Select 'Roll-Up Services Definition' in ‘File Type’. Click [Upload New File] in ‘Action’. Click [Process Action]. Upload the file that will add the 'Roll-Up Services Definition'. Click [Compile/Validate File] in ‘Action’. Select the uploaded file. Click [Process Action]. If there are errors, click [Print Errors] in ‘Action’. Select the compiled file. Click [Process Action]. Review the report and upload and compile again to resolve the errors. Click [Print File] in ‘Action’. Click [Process Action]. Review the report to validate the data. Click [Post File] in ‘Action’. Select the compiled file. Click [Process Action]. If desired, Click [Delete File] in ‘Action’. Select the posted file. Click [Process Action]. The ‘Delete File’ message will display. Click desired value. If [Yes], the ‘Confirm message will display. Click [OK]. If [No], the ‘Delete File’ message is removed. Close the form. Open 'Roll-Up Services Definition'. Validate that the definition imported with the correct values. Close the form. Repeat steps 1-24 for the file that will edit the 'Roll-Up Services Definition'. Open 'Roll-Up Services Definition'. Validate that the edited definition contains the correct values in the edited fields. Close the form. Repeat steps 1-24 for the file that will delete the 'Roll-Up Services Definition'. Open 'Roll-Up Services Definition'. Validate that the deleted definition does not exist. Close the form.	Topics • Deposit Entry • File Import • Roll-Up Services Definition • NX
Update 33 Summary \| Details Dictionary Update - Payor Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Practitioner Numbers By Guarantor And Program CCBHC PPS Service Definition Financial Eligibility CCBHC PPS Compile Electronic Billing Scenario 1: CCBHC Billing - 837P - Exclude from check for remittance from private insurance. Specific Setup: CCBHC functionality is enabled and setup. Dictionary Update: Payor Print Dictionary - 1000 – Financial Class Validate that the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance' has a value of ‘Y’ for the following financial classes: 3 (Medicaid), 6 (Self Pay), 7 (Medicare A), 8 (Medicare B). Any financial class that has the ‘System Financial Class set to a value of 3 (Medicaid), 6 (Self Pay), 7 (Medicare A), 8 (Medicare B), will also have a value of ‘Yes’ in the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance'. Input Dictionary - 1000 – Financial Class Select a financial class for a non CCBHC guarantor that does not have a value for the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance' and set the value to 'No'. This will be the client's primary guarantor. Service Codes Identify a code that is a CCBHC service and a CCBHC Enumerated Service. Identify a code that is a CCBHC service and is not a CCBHC Enumerated Service. Client: Identify an outpatient client with the following: Financial Eligibility: Client is assigned the guarantor with the 'CCBHC Billing - Exclude from check for remittance from private insurance' dictionary value of 'No' as the primary guarantor. Setup will cover the enumerated service and force the non enumerated service to the secondary guarantor. Client is assigned a CCBHC guarantor as the secondary guarantor. Services: Client has one or more services for the code that is a CCBHC service and a CCBHC Enumerated Service. The services must be closed. Client Ledger was used to verify that the services distributed to the primary guarantor. Steps Open 'CCBHC PPS Compile' and process the compile for the client. Print the report and validate that the non-enumerated service was created and distributed to the secondary guarantor. If desired, open ‘Client Ledger’ and verify that the non-enumerated service distributed to the secondary guarantor. Open ‘Close Charges’ and close the charges for the client. Open ‘Electronic Billing’. Select '837-Professional' in 'Billing Type'. Process the bill for the primary funding source. The services can be claimed or unclaimed. If necessary, include CCBHC services. Validate that the ‘Compile Complete’ message is received. If desired, review the dump file or print the report. Process the bill for the secondary guarantor. Do not create claims. Include CCBHC services. Validate that the ‘No Valid Information Found. Please Check The Error Report’ message is received. Print the report to review the error message. Click the ‘Required Data Missing: Header and/or Billing/Pay-to Provider Data’ link and verify that the message is: Service ‘xxx’ Service Code (xxx) [date] is still awaiting remittance from private insurance. Click the Required Data Missing: Patient Claim Data link and verify that the message is: PPS service ‘xxx (1250) [date] cannot be billed until all associated enumerated services are ready to bill. Close the report. Close the form. Open ‘Dictionary Update’ Select the ‘Payor’ file. Select dictionary ‘Financial Class’, # 1000. Access the financial class for the primary guarantor. Change the 'CCBHC Billing - Exclude from check for remittance from private insurance' value to ‘Yes’. Apply the changes. Exit the form. Open ‘Electronic Billing’. Process the bill for the secondary guarantor. The services can be claimed or unclaimed. Validate that the ‘Compile Complete’ message is received. If desired, review the dump file or print the report. Scenario 2: CCBHC Billing - 837I - Exclude from check for remittance from private insurance. Specific Setup: CCBHC functionality is enabled and setup. Dictionary Update: Payor Print Dictionary - 1000 – Financial Class Validate that the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance' has a value of ‘Y’ for the following financial classes: 3 (Medicaid), 6 (Self Pay), 7 (Medicare A), 8 (Medicare B). Any financial class that has the ‘System Financial Class set to a value of 3 (Medicaid), 6 (Self Pay), 7 (Medicare A), 8 (Medicare B), will also have a value of ‘Yes’ in the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance'. Input Dictionary - 1000 – Financial Class Select a financial class for a non CCBHC guarantor that does not have a value for the extended dictionary 'CCBHC Billing - Exclude from check for remittance from private insurance' and set the value to 'No'. This will be the client's primary guarantor. Service Codes Identify a code that is a CCBHC service and a CCBHC Enumerated Service. Identify a code that is a CCBHC service and is not a CCBHC Enumerated Service. Client: Identify an outpatient client with the following: Financial Eligibility: Client is assigned the guarantor with the 'CCBHC Billing - Exclude from check for remittance from private insurance' dictionary value of 'No' as the primary guarantor. Setup will cover the enumerated service and force the non enumerated service to the secondary guarantor. Client is assigned a CCBHC guarantor as the secondary guarantor. Services: Client has one or more services for the code that is a CCBHC service and a CCBHC Enumerated Service. The services must be closed. Client Ledger was used to verify that the services distributed to the primary guarantor. Steps Open 'CCBHC PPS Compile' and process the compile for the client. Print the report and validate that the non-enumerated service was created and distributed to the secondary guarantor. If desired, open ‘Client Ledger’ and verify that the non-enumerated service distributed to the secondary guarantor. Open ‘Close Charges’ and close the charges for the client. Open ‘Electronic Billing’. Select '837-Institutional' in 'Billing Type'. Process the bill for the primary funding source. The services can be claimed or unclaimed. If necessary, include CCBHC services. Validate that the ‘Compile Complete’ message is received. If desired, review the dump file or print the report. Process the bill for the secondary guarantor. Do not create claims. Include CCBHC services. Validate that the ‘No Valid Information Found. Please Check The Error Report’ message is received. Print the report to review the error message. Click the ‘Required Data Missing: Header and/or Billing/Pay-to Provider Data’ link and verify that the message is: Service ‘xxx’ Service Code (xxx) [date] is still awaiting remittance from private insurance. Click the Required Data Missing: Patient Claim Data link and verify that the message is: PPS service ‘xxx (1250) [date] cannot be billed until all associated enumerated services are ready to bill. Close the report. Close the form. Open ‘Dictionary Update’ Select the ‘Payor’ file. Select dictionary ‘Financial Class’, # 1000. Access the financial class for the primary guarantor. Change the 'CCBHC Billing - Exclude from check for remittance from private insurance' value to ‘Yes’. Apply the changes. Exit the form. Open ‘Electronic Billing’. Process the bill for the secondary guarantor. The services can be claimed or unclaimed. Validate that the ‘Compile Complete’ message is received. If desired, review the dump file or print the report.	Topics • 837 Professional • CCBHC • 837 Institutional
Update 34 Summary \| Details File Import - [Support Only] Guarantor Nature Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Guarantor Nature File Import Financial Eligibility Cross Episode Financial Eligibility Family Financial Eligibility Family Registration Scenario 1: File Import - [Support Only] Guarantor Nature – Non-contract guarantor to Contract - 'If Customized Retain Customization' = 'Y' in File Import and client has two guarantors Steps **Internal testing only	Topics • Guarantor/Payors • Guarantor • NX • File Import
Update 35 Summary \| Details 837 Institutional Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Discharge Electronic Billing Scenario 1: 837 Institutional - Test Patient Status Code (2300-CL1-03) and Statement Date (2300-DTP) Specific Setup: Client A: Client was admitted to an inpatient program. Note the admission date. Client has a diagnosis record. Client has a financial eligibility record. Client has closed, unclaimed services that include Roll-Up services. Client Ledger is used to note the dates of service, and the guarantor the liability distributed to. Guarantor/Payors is used to note the financial class of the guarantor the liability distributed to. Client was discharged from the episode on the day after the last day of service. Note the discharge date and type. Dictionary Update: Client file: Dictionary:970: Type Of Discharge Print the dictionary and note the extended dictionary value for 'Patient Status Over-Ride (2300-CL1-03)' for the discharge type noted above. Steps Open ‘Electronic Billing’. Select ‘837-Institutional’ in ‘Billing Form’. Select the desired ‘Financial Class in ‘Type Of Bill’. Select ‘Individual’ in ‘Individual Or All Guarantors’. Select the desired guarantor in ‘Guarantor’. Select ‘Inpatient’ in ‘Billing Type’. Select ‘Sort File’ in ‘Billing Options’. Enter the desired value in ‘File Description/Name’. Select ‘All Clients’ in ‘All Clients Or Interim Billing Batch’. Select desired value in ‘Program(s)’. Select ‘No’ in ‘Create Claims’. Enter the desired value in ‘First Date Of Service To Include’. Enter the desired value in ‘Last Date Of Service To Include’. Select ‘All in ‘Include Primary and/or Secondary Billing. Click [Process]. Validate the ‘Processing Report’ message contains ‘Compile Complete’. Click [OK]. Select ‘Dump File’ in ‘Billing Options’. Select ‘Print’ in ‘Print Or Delete Report’. Select the desired report in ‘File’. Click [Process]. Validate that the ‘DTP434’ segment includes the admission date and the discharge date. Validate that the ‘CL1’ segment contains the correct value in the third position. Close the report. Close the form. Create an SQL query, specific to the client, for the 'SYSTEM.billing_tx_history table' and validate the date in the 'the date_to_bill_rollup_service' field. Close the query.	Topics • 837 Institutional • NX
Update 36 Summary \| Details Diagnosis Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Diagnosis Pre-display IMO Diagnosis Search Scenario 1: Diagnosis form - Adding multiple diagnoses at one time - Registry settings "Default 'Add To Problem List' to "Yes" on New Diagnosis" and "Enable Multiple Diagnosis Search" are enabled. Specific Setup: Registry Settings: "Default 'Add To Problem List' to "Yes" on New Diagnosis" is set to "Y". "Enable Multiple Diagnosis Search" is set to "Y". Client: Client is identified with no existing Diagnosis record. Steps Open "Diagnosis" form. Select desired client in the "Select Client" field and click "Select". When records are on file, the Diagnosis Pre-display will display. Click "Add". Select a "Type of Diagnosis". Enter a "Date of Diagnosis". Enter a "Time of Diagnosis". To add more than one diagnosis at a time, click [Add Multiple]. The "Powered by IMO Problem(IT) Terminology" search will display. Enter a practitioner to assign to all selected diagnosis in the "Default Diagnosing Practitioner" field (optional) Select a "Status" to default for all entries (optional) In the "Powered by IMO Problem(IT) Terminology" search box, enter a diagnosis code or description. Either press [Enter] or click the search icon to the right of the field to initiate the search. A list of diagnoses matching the search criteria will display. To view a description of the diagnosis, click anywhere on the line item. Click on the "+" plus sign to select the diagnosis. It will be added to the "Conditions" column. Continue to search and select diagnosis. Up to 12 diagnoses can be added to the list at one time. Click 'OK' to accept the list and return to the "Diagnosis" display. Verify the selected diagnoses populate the "Diagnosis" grid. Edit each diagnosis as desired to validate that the ‘Diagnosis’, ‘Add to Problem List’; and ‘Diagnosis Practitioner’ are correct and to select the ‘Ranking. Click [Submit]. Return to the form to validate that the selected diagnoses exist. Close the form.	Topics • Diagnosis
Update 37 Summary \| Details Women's Health History Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: HomeView.Women's Health History SQL Query/Reporting Tool Women's Health History Scenario 1: Women's Health History - Master Patient Index Historic Sync Specific Setup: User with Provider credentials User with access to Women's Health History form Female Client with "expected due date" filed via the "Admission" form Steps Log into Avatar with a Provider login. Open "Women's Health History" form. Enter values for the following fields (Pregnancy Status, Expected Due Date, and Lactating Status). Add desired values to the 'Para and Gravida' section. Click [Add/Update]. Click [File Para Records]. Click [Submit]. Click [Yes]. Open "Women's Health History" form. Select 'Edit' on the record that was added. Validate that all the data that was entered displays correctly in the form. Close the form. Open 'Crystal Reports' or another SQL reporting tool. Execute the query: 'SELECT * FROM SYSTEM.client_condition_preg where PATID=client id AND assessment_date =current date'. Validate the table cells "pregnancy_status", "expected_due_date", "lactating_status" match the inputted values from the "Women's Health History" form. Open 'Crystal Reports' or another SQL reporting tool. Execute the query: 'SELECT * FROM SYSTEM.patient_demographic_history where PATID=client id'. Validate the table cells "pregnancy_status", "expected_due_date", "lactating_status" match the values from the ‘SYSTEM.client_condition_preg' table.	Topics • Women's Heath History
Update 39 Summary \| Details Disclosure Management - Filter document images Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Disclosure Management Disclosure Management Configuration Create New Treatment Plan Document Routing Setup (PM) Treatment Plan Clinical Document Viewer Treatment Plan Number 8 Scenario 1: Disclosure Management - Field Validations Specific Setup: Using the "Disclosure Management Configuration" form, set up the first page image, watermark, and forms to associate to set up Disclosure Management. Steps Open the "Disclosure Management" form. Populate all required and desired fields in the request, authorization, and the disclosure sections. Select "Electronic" in the "Disclosure Method" field. Click the "Process" button. Validate the appropriate items are included in the disclosure packet. Click "Disclose". Click the PDF download icon. Browse to the location to store the file on the server. Provide the file name with a .pdf file extension. Click the "Save" button. Scenario 2: Disclosure Management - Apply Filter to Document Images Specific Setup: Using the "Create New Treatment Plan" form, create a non episodic copy of the Treatment Plan form. Using the "Document Routing Setup" form, enable the new Treatment Plan form for document routing, the Treatment Plan and Progress Notes (Group and Individual) forms. Using "User Definition" ensure the user has access to the above forms. Admit or select a test client into multiple episodes. Generate a couple of Non Episode Treatment Plans for different dates. Finalize and route to an approver. Log in as the approver and approve the document by signing. Generate a couple of episodic Treatment Plans for different dates and different episodes. Finalize and route to an approver. Log in as the approver and approve the document by signing. Generate a couple of Progress Notes (Group and Individual) for different dates and different episodes. Finalize and route to an approver. Log in as the approver and approve the document by signing. Using the "Document Management Configuration" form, set up disclosure management by setting up an image to include in each packet, a disclosure statement, a watermark and to identify valid types of forms to attach to a disclosure. An Organization must be created in the 'Disclosure Management' form (Organization A). Steps Open the 'Disclosure Management' form for the same client selected above. Click [Add] if this form has ever been filed for the client before. Set the 'Request Date' field to the current date. Select desired episode(s) from the 'Request Episode(s)' field. Select desired chart items from the 'Requested Chart Items' field. Validate non episodic forms are included regardless of the episode selected. Click [Apply Filter To Document Images]. Validate the Document Images listed in the "Requested Document Images" are filtered by the episode(s) and Request Start/End dates. Set the 'Requesting Organization or Individual' field to "Organization A" Select the 'Authorization' section. Set the 'Authorization Start Date' field to desired date. Set the 'Authorization End Date' field to desired date. Select the episode(s). Click [Apply Filter To Document Images]. Validate the Document Images listed in the "Requested Document Images" are filtered by the episode(s) and Authorization Start/End dates. Select "Yes" in "Default all Chart Items to Yes". Click [Update Chart Items Authorized for Disclosure]. Validate the 'Authorized' cell for all rows is set to "Y". Click [Save]. Click [Refresh Chart Items]. Verify the Chart Items Authorized for Disclosure' field is updated. Click [Apply Filter to Document Images]. Select "Yes" in "Default all Document Images to Yes". Click [Update Chart Items Authorized for Disclosure]. Validate the 'Authorized' cell for all rows is set to "Y". Click [Save]. Select the 'Disclosure' section. Set the 'Disclosure Date' field to the current date. Select all chart items and all document images. Select the method to report. Click [Process]. Click [View]. Verify the chart items and document images to be included are the items that were chosen. Verify the disclosure file includes the image, disclosure statement, watermark and the chosen chart items and document images. Disclosure Management - Items for Disclosure with no data Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Disclosure Management Disclosure Management Configuration Create New Treatment Plan Document Routing Setup (PM) Treatment Plan Clinical Document Viewer Treatment Plan Number 8 Scenario 1: Disclosure Management - Field Validations Specific Setup: Using the "Disclosure Management Configuration" form, set up the first page image, watermark, and forms to associate to set up Disclosure Management. Steps Open the "Disclosure Management" form. Populate all required and desired fields in the request, authorization, and the disclosure sections. Select "Electronic" in the "Disclosure Method" field. Click the "Process" button. Validate the appropriate items are included in the disclosure packet. Click "Disclose". Click the PDF download icon. Browse to the location to store the file on the server. Provide the file name with a .pdf file extension. Click the "Save" button. Scenario 2: Disclosure Management - Apply Filter to Document Images Specific Setup: Using the "Create New Treatment Plan" form, create a non episodic copy of the Treatment Plan form. Using the "Document Routing Setup" form, enable the new Treatment Plan form for document routing, the Treatment Plan and Progress Notes (Group and Individual) forms. Using "User Definition" ensure the user has access to the above forms. Admit or select a test client into multiple episodes. Generate a couple of Non Episode Treatment Plans for different dates. Finalize and route to an approver. Log in as the approver and approve the document by signing. Generate a couple of episodic Treatment Plans for different dates and different episodes. Finalize and route to an approver. Log in as the approver and approve the document by signing. Generate a couple of Progress Notes (Group and Individual) for different dates and different episodes. Finalize and route to an approver. Log in as the approver and approve the document by signing. Using the "Document Management Configuration" form, set up disclosure management by setting up an image to include in each packet, a disclosure statement, a watermark and to identify valid types of forms to attach to a disclosure. An Organization must be created in the 'Disclosure Management' form (Organization A). Steps Open the 'Disclosure Management' form for the same client selected above. Click [Add] if this form has ever been filed for the client before. Set the 'Request Date' field to the current date. Select desired episode(s) from the 'Request Episode(s)' field. Select desired chart items from the 'Requested Chart Items' field. Validate non episodic forms are included regardless of the episode selected. Click [Apply Filter To Document Images]. Validate the Document Images listed in the "Requested Document Images" are filtered by the episode(s) and Request Start/End dates. Set the 'Requesting Organization or Individual' field to "Organization A" Select the 'Authorization' section. Set the 'Authorization Start Date' field to desired date. Set the 'Authorization End Date' field to desired date. Select the episode(s). Click [Apply Filter To Document Images]. Validate the Document Images listed in the "Requested Document Images" are filtered by the episode(s) and Authorization Start/End dates. Select "Yes" in "Default all Chart Items to Yes". Click [Update Chart Items Authorized for Disclosure]. Validate the 'Authorized' cell for all rows is set to "Y". Click [Save]. Click [Refresh Chart Items]. Verify the Chart Items Authorized for Disclosure' field is updated. Click [Apply Filter to Document Images]. Select "Yes" in "Default all Document Images to Yes". Click [Update Chart Items Authorized for Disclosure]. Validate the 'Authorized' cell for all rows is set to "Y". Click [Save]. Select the 'Disclosure' section. Set the 'Disclosure Date' field to the current date. Select all chart items and all document images. Select the method to report. Click [Process]. Click [View]. Verify the chart items and document images to be included are the items that were chosen. Verify the disclosure file includes the image, disclosure statement, watermark and the chosen chart items and document images.	Topics • Disclosure
Update 41 Summary \| Details SYSTEM.billing_271_bene_fino table - Data validation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Purge Billing Files Scenario 1: Load & Go - Install update and verify successful installation Specific Setup: N/A Steps N/A Scenario 2: Validate 'Purge Billing Files' when '271 Batch' is selected to purge. Specific Setup: At least two 271 batch(es) are identified. Note the batch numbers. Steps Open 'Purge Billing Files'. Select '271 Batch' in 'Billing List to Purge'. Enter a date in 'Date Created Start Date'. Enter a date in 'Date Created End Date'. Select 'None' in 'File Selection Default'. Click [Select File(s) to Purge]. Select the first row, noting the 'Date Created' and 'Batch Name'. Click [OK]. Click [Submit]. Click [OK]. Repeat steps 1 - 7. Verify that the batch that was deleted is not present by confirming that the deleted 'Date Created' and 'Batch Name' are not included in the grid. Eligibility Response Report - Run report Scenario 1: Load & Go - Install update and verify successful installation Specific Setup: N/A Steps N/A	Topics • Database Management • Purge Billing Files
Update 42 Summary \| Details Quick Actions - Update Client Data Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick Actions Page Scenario 1: Quick Action - Update Client Data - Validate name change Specific Setup: User Definition: Identify a home view and chart view set up for the logged in user. View Definition: The 'Quick Actions' widget is added to the user's HomeView. NX View Definition: The Quick Action for 'Update Client Data' is added for your user, home view and chart view. Admission: A new client is admitted. Note the client id/name. Steps Select the test client. Navigate to the 'Quick Actions' widget. Locate the 'Update Client Data' Quick Action. Click 'Add' button. Change the client's first and last name. Fill in all other fields. Click 'Save'. Open the 'Update Client Data' form. Validate the first and last name are changed. Using SQL, validate the name change is reflected in the columns, patient_name, patient_name_first, patient_name_last in SYSTEM.patient_current_demographics SQL. Scenario 2: 'Update Client Data' Form - Validate the 'SYSTEM.client_curr_demographics' SQL table Specific Setup: A client must be enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Update Client Data' form. Enter the desired value in the 'Client Middle Name' field. Enter the desired value in the 'Alias' field. Enter the desired value in the 'Alias 2' field. Enter the desired value in the 'Alias 3' field. Enter the desired value in the 'Alias 4' field. Enter the desired value in the 'Alias 5' field. Enter the desired value in the 'Alias 6' field. Enter the desired value in the 'Alias 7' field. Enter the desired value in the 'Alias 8' field. Enter the desired value in the 'Alias 9' field. Enter the desired value in the 'Alias 10' field. Select the desired value in the 'Gender Identity' field. Populate any other desired fields. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Select the CWS namespace. Create a report using the 'SYSTEM.client_curr_demographics' SQL table. Navigate to the row for "Client A". Validate the 'client_alias' fields 1-10, 'patient_middle_name', 'gender_identity_code', and 'gender_identity_value' fields are displayed. Validate the 'client_alias' fields 1-10 contains the value filed in the previous steps. Validate the 'gender_identity_code' field contains the code associated to the value filed in the previous steps. Validate the 'gender_identity_value' field contains the value filed in the previous steps. Validate the 'patient_middle_name' field contains the value filed in the previous steps. Select "Client A" and access the 'Update Client Data' form. Enter any new value in the 'Client Middle Name' field. Enter any new value in the 'Alias' field. Enter any new value in the 'Alias 2' field. Enter any new value in the 'Alias 3' field. Enter any new value in the 'Alias 4' field. Enter any new value in the 'Alias 5' field. Enter any new value in the 'Alias 6' field. Enter any new value in the 'Alias 7' field. Enter any new value in the 'Alias 8' field. Enter any new value in the 'Alias 9' field. Enter any new value in the 'Alias 10' field. Select any new value in the 'Gender Identity' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'SYSTEM.client_curr_demographics' SQL table. Navigate to the row for "Client A". Validate the 'client_alias' fields 1-10, 'patient_middle_name', 'gender_identity_code', and 'gender_identity_value' fields are displayed. Validate the 'client_alias' fields 1-10 contains the updated value filed in the previous steps. Validate the 'gender_identity_code' field contains the code associated to the updated value filed in the previous steps. Validate the 'gender_identity_value' field contains the updated value filed in the previous steps. Validate the 'patient_middle_name' field contains the updated value filed in the previous steps. Close the report. Scenario 3: Quick Action - Update Client Data - Validate name change Specific Setup: Using the "View Definition" form, add the "Quick Actions" widget to the user's HomeView. Using the "NX View Definition" form, add the Quick Action for "Update Client Data". Admission: A new client is admitted. Note the client id/name. Steps Select the test client. Navigate to the 'Quick Actions' widget. Locate the 'Update Client Data' Quick Action. Click 'Add' button. Change the client's first and last name. Fill in all other fields. Click 'Save'. Open the 'Update Client Data' form. Validate the first and last name are changed. Using SQL, validate the name change is reflected in the columns, patient_name, patient_name_first, patient_name_last in SYSTEM.patient_current_demographics SQL.	Topics • Update Client Data
Update 43 Summary \| Details Compile/Edit/Post/Unpost Roll-Up Services Worklist Internal Test Only	Topics • Compile/Edit/Post/Unpost Roll-up Services Worklist
Update 44 Summary \| Details Avatar PM - support for Integrated eSignature functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Discharge Pre Admit Pre Admit Discharge Scenario 1: 'Admission' form - Field Validation Specific Setup: A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Admission' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "No" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Admission' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate "No" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Scenario 2: 'Update Client Data' form - Verification of 'Client Demographics' form fields Specific Setup: A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Update Client Data' form. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Update Client Data' form. Validate "Yes" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Scenario 3: 'Admission (Outpatient)' form - Field Validation Specific Setup: A client is enrolled in an existing outpatient episode (Client A). Steps Select "Client A" and access the 'Admission (Outpatient)' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Admission (Outpatient)' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate "Yes" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Scenario 4: 'Discharge' form - Field Validation Specific Setup: A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Discharge' form. Select an existing episode and click [Edit]. Enter the desired date in the 'Date Of Discharge' field. Enter the desired time in the 'Discharge Time' field. Select the desired value in the 'Type Of Discharge' field. Select the desired practitioner in the 'Discharge Practitioner' field. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Discharge' form. Select the discharged episode and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field contains "Yes". Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Scenario 5: 'Pre Admit' form - Field Validation Specific Setup: A client is enrolled in an existing Pre Admit episode (Client A). Steps Select "Client A" and access the 'Pre Admit' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Pre Admit' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate "Yes" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Scenario 6: 'Pre Admit Discharge' form - Field Validation Specific Setup: A client is enrolled in an existing Pre Admit episode (Client A). Steps Select "Client A" and access the 'Pre Admit Discharge' form. Select an existing episode and click [Edit]. Enter the desired date in the 'Date Of Discharge' field. Enter the desired time in the 'Discharge Time' field. Select the desired value in the 'Type Of Discharge' field. Select the desired practitioner in the 'Discharge Practitioner' field. Populate any other desired fields. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "No" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Pre Admit Discharge' form. Select the previously discharged Pre Admit episode and click [Edit]. Select the "Demographics" section. Validate "No" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Scenario 7: 'Call Intake' form - Field Validation Specific Setup: A client is enrolled in an existing Call Intake program (Client A). Steps Select "Client A" and access the 'Call Intake' form. Select the existing call intake record and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "No" in the 'Consent On File For Use of Integrated eSignature' field. Click [Submit]. Select "Client A" and access the 'Call Intake' form. Select the existing call intake record and click [Edit]. Select the "Demographics" section. Validate "No" is selected in the 'Consent On File For Use of Integrated eSignature' field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Scenario 8: 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 Access SoapUI for the 'ClientAdmission' - 'AddAdmission' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired date in the 'AdmissionDate' field. Enter the desired time in the 'AdmissionTime' field. Enter the desired practitioner in the 'AdmittingPractitioner' field. Enter the desired value in the 'ClientFirstName' field. Enter the desired value in the 'ClientLastName' field. Enter the desired value in the 'ClientMiddleName' field. Enter the corresponding name in the 'ClientName' field. Enter the desired value in the 'ESignatureConsentOnFile' field. Note: "Y" and "N" are accepted values. Enter the desired value in the 'Program' field. Enter the desired value in the 'Sex' field. Populate any other required and desired fields. Click [Run]. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #". Validate the 'Message' field contains: "Client Admission web service has been filed successfully". Select the client filed in the previous steps and access the 'Admission' form. Select the record filed in the previous steps and click [Edit]. Validate all populated fields are displayed. Select the "Demographics" section. Validate the 'Client Last Name' field contains the value filed in the previous steps. Validate the 'Client First Name' field contains the value filed in the previous steps. Validate the 'Client Middle Name' field contains the value filed in the previous steps. Validate the 'Consent On File For Use of Integrated eSignature' field contains the value filed in the previous steps. Close the form.	Topics • Admission • Update Client Data • Admission (Outpatient) • Discharge • Pre Admit • Pre Admit Discharge • Call Intake • Web Services
Update 46 Summary \| Details Form Bundler - CWS Scenario 1: Form Bundler: Create and File a New Sequential Bundle Specific Setup: User must have access to the form 'Form Bundler' in 'User Definition'. A client must be admitted to an active episode (Client A). Steps Access the 'Form Bundler' form. Validate a "Form Bundler" dialog is displayed stating: Edit Existing Form Bundle or Create New Form Bundle. Click [Create New] and [Print Current Menu]. Validate a "Form Bundler" menu is displayed. Click [Dismiss]. Enter any value (Form Bundle A) in the 'Form Bundle Description' field. Select "Sequential" from the 'Type of Bundle' field. Select any value from the 'Menu to Place Form Bundle Under' field. Select the 'Included Forms' tab. Click [Add New Item]. Select any value (ex. 'Call Intake') from the 'Form' field. Click [Add New Item]. Select any value of the same entity database as the one selected in the previous step (ex. 'Assign Permanent MR#') from the 'Form' field. Click [Submit]. Access the 'Display Form Bundle' form. Select "All" from the 'Individual or All Form Bundles' field. Click [Process]. Validate a Display Form Bundle report is displayed Validate the report displays "Form Bundle A". Click [Dismiss]. Validate a "Form Return" dialog is displayed stating: Processing report has completed. Do you wish to return to form? Click [No]. Select "Client A" and access the form bundle. Select any value from the 'Select Episode' field. Click [Add]. Validate that the first form in the bundle opens. Complete the required fields and click [Submit]. Validate that the next form in the bundle opens for "Client A" with the episode that was selected upon entering the first form of the bundle. Click [Add] Complete the required fields and click [Submit]. Validate that the next form in the bundle opens for "Client A" with the episode that was selected upon entering the first form of the bundle Click [Add] Complete the required fields and click [Submit]. Compete each of the remaining forms in the bundle and click [Submit]. Validate each form files successfully. CCBHC PPS Compile Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CCBHC PPS Compile Financial Eligibility Service Codes CCBHC PPS Service Definition Scenario 1: CCBHC PPS Compile - field validation Specific Setup: The agency processes CCBHC billing and the CCBHC setup is complete. Client 1 has the following: Is enrolled in a program on or after the CCBHC PPS Service Definition effective date. A financial eligibility record for a CCBHC guarantor. Three closed PPS non-enumerated services after the CCBHC PPS Service Definition effective date. Note each date of service. Client 2 has the following: Is enrolled in a program on or after the CCBHC PPS Service Definition effective date. A financial eligibility record for a CCBHC guarantor. Three closed PPS non-enumerated services after the CCBHC PPS Service Definition effective date, and after the dates of service for Client 1. Note each date of service. Client Ledger is viewed to ensure the service distributed to the correct guarantor. Steps Open 'CCBHC PPS Compile'. Validate the 'Client ID' field exists. Enter the first date of service for Client 1 in 'Start Date'. Enter the last date of service for Client 1 in 'End Date'. Enter the 'Client ID' for Client 1. Click [Compile & Post Services]. Validate that the 'CCBHC Compile Complete' message is received. Click [OK]. Select the 'PPS Compile Report' section. Enter the first date of service for Client 1 in 'Start Date'. Enter the last date of service for Client 1 in 'End Date'. Enter the 'Client ID' for Client 1. Click [Run Report]. Validate that the report contains only data for Client 1 and the services are within the 'Start Date' to 'End Date' range. Close the report. Select the 'PPS Compile' section. Enter the first date of service for Client 1 in 'Start Date'. Enter the last date of service for Client 2 in 'End Date'. Click [Compile & Post Services]. Click [OK]. Select the 'PPS Compile Report' section. Enter the first date of service for Client 1 in 'Start Date'. Enter the last date of service for Client 2 in 'End Date'. Click [Run Report]. Validate that the report contains data for Client 1 and Client 2 and the services are within the 'Start Date' to 'End Date' range. Client Charge Input - Incident-to-Practitioner Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Enrollment Practitioner Termination Scenario 1: Client Charge Input - Incident-to-Practitioner - Terminated Practitioner Specific Setup: Registry Setting: Enable Incident-To Practitioner = Y. Practitioner: Identify a terminated practitioner. Steps Open ‘Client Charge Input’. Create a charge for any client using desired data. Enter the terminated practitioner in ‘Practitioner’. Validate that an error message is received. Click [OK]. Enter an active practitioner in ‘Practitioner’. Enter the terminated practitioner in ‘Incident-to-Practitioner’. Validate that an error message is received. Click [OK]. Enter an active practitioner in ‘Incident-to-Practitioner’. Click [Submit]. Close the form. Client Account Service Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Account Services Report Financial Eligibility Electronic Billing Service Codes Front Desk Information Scenario 1: Client Account Services Report - process and validate fields Specific Setup: User Definition has been used to give the tester access to the report: Avatar PM > Client Management > Account Management > Client Payment History Report. Note the ‘User Description’. Client: In 'Financial Eligibility' the client is assigned a 'Self-Pay' guarantor and at least one non 'Self-Pay' guarantor. The client has services have been claimed by the non 'Self-Pay' guarantor and a portion has been distributed to the 'Self-Pay' guarantor. Note the 'Service Code Definition'. Note the service fees. Note the claim number and the date of the claim. Payments have been made on the services by the non 'Self-Pay' guarantor and the client. Note system date the payments were applied. Note the amounts applied and by which guarantor, And the amounts. Note the 'Posting/Adjustment Code Definition'. Use ‘Admission’ or ‘Admission (Outpatient)’ to note: ‘Episode’ ‘Admit Date’ 'Discharge Date’ ‘Program’ ‘Type of Admission’ Steps Open 'Client Account Services Report'. Enter the 'Client'. Enter the desired 'Service Start Date'. Enter the desired 'Service End Date'. Click [Process]. Validate the admission information, which includes the 'Episode', Admit Program', 'Admit Type', 'Admit Date', and 'Discharge Date'. Validate the report data for the 'Client 'Payments', which includes the 'Payment Date', 'Description', 'Amount' and 'Notes'. Validate the service information, which includes the 'Service Date', 'Service Code Definition', 'Staff', 'Episode', 'Transaction Date', 'Transaction Type', 'Transaction Amount', 'Client Responsibility', 'Insurance Responsibility', 'Guarantor', 'Claim #' and 'Claim Date'. Scenario 2: Client Account Services Report - Validating payment amount Specific Setup: Guarantors/Payor: A self pay guarantor is identified. Note the guarantor's code/value. Client: An existing client, with the above guarantor in Financial Eligibility, is selected, or a new client is admitted and assigned the above guarantor in Financial Eligibility. Note the client's id, admission date and admission program. A diagnosis record is created for the client. Service Code: Select a service code that has a Service Fee/Cross Reference Maintenance record, noting the 'Fee’. Recurring Client Charge Input: Services are rendered to the client that will create charges that total more than $10,000.00. Note the service date range. Client Ledger: The service distributed to the self pay guarantor. Steps Open desired form and post a payment greater than $10,000.00 to the client. Note the payment date. Validate that the generated receipt displays the full payment amount. Close the receipt. Close the form. Open the 'Client Ledger' for the client / payment date and validate that the full payment amount displays. Close the report. Close the form. Open 'Client Account Services Report'. Select the client and the payment date. Click [Process]. Validate that the report displays the full payment amount. Close the report. Close the form. Repeat steps 1 -13 with a payment amount of less than $1,000.00.	Topics • Diagnosis • Chart View • CCBHC • Client Charge Input • Practitioner • NX • Billing
Update 48 Summary \| Details Remittance Posting - future date error Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Spreadsheet Remittance Posting Posting/Adjustment Codes Definition Spreadsheet Batch Remittance Posting Remittance Post Confirmation Scenario 1: 'Spreadsheet Remittance Posting' form - Validate 'Launch Work Screen'. Specific Setup: Payment/Adjustment Code definition: Identify an existing adjustment code. Note the code value / name. Admission: An existing client is identified, or a new client is admitted. Note the client id. Financial Eligibility: Two guarantors are assigned to the client and a coverage effective date is entered. Note the guarantor codes / names. Recurring Client Charge Input: 5-6 services are rendered to the client. Please note, The service dates are in the coverage effective range. Note service start date/ end date. Client Ledger: The services are distributed to the primary guarantor. Steps Open the 'Spreadsheet Remittance Posting' form. Select a date range for a client that contains services. Populate all required fields. Select the 'Guarantor To Post For'. Click [OK] on the guarantor balance message. Enter a 'Posting Date'. Enter a 'Date of Receipt'. Select a valid entry for 'Default Payment/Adjustment Code For Amount To Post' field. Click [Launch Work Screen]. Hover over the 'Transfer Guar' field. Select a row associated with client. Verify a mini-table containing a list of guarantors that are assigned to the client's episode via 'Financial Eligibility' (excluding the current guarantor), that are active for the selected date of service, in the same order as they appear in 'Financial Eligibility'. Enter an 'Adjustment Amount'. Tab out of the field. Verify the adjustment amount does not change when tabbing out of the field. Select desired adjustment code in the 'Adjustment Code'. Tab out of the field. Verify the adjustment amount does not change when tabbing out of the field. Click [Accept]. Click [Submit]. Verify the payment posted successfully. Click [No]. Scenario 2: Spreadsheet Batch Remittance Posting - Validate excluded posting codes are not included in the 'Payment Code' dropdown list. Specific Setup: An existing client with unpaid claims is identified (Client A). Note the guarantor that liability is distributed to. Posting/Adjustment Codes Definition: A payment posting code is defined to 'Exclude Guarantors' for the client's liability guarantor. Note the code/description. An additional payment posting code is defined to not exclude the client's liability guarantor. Note the code/description. User Definition': The user has access to the 'Spreadsheet Batch Remittance' form. Steps Open the 'Spreadsheet Batch Remittance Posting' form. Click the 'Create Batch' field. Enter the 'desired value' in the 'Batch Description' field. Select the 'desired value' in 'Default Payment Code' field. Enter the desired 'Posting Date'. Enter the desired 'Date Of Receipt'. Click [Launch Work Screen]. Select "Client A" in the 'Client' field. Select the 'desired episode'. Validate there is Liability to be remitted against. Select the "excluded" guarantor from the 'Payor' field. Enter the 'desired value' in the 'Payment Amount' field. Double Click the 'Payment Code' field and validate it does not contain the "excluded" payment code. Select the "non-excluded" payment code. Click [Accept]. Click [Submit]. Click [OK]. Click [Yes].	Topics • Spreadsheet Remittance Posting • Spreadsheet Batch Remittance Posting
Update 49 Summary \| Details Quick Billing / Electronic Billing - File Names Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick Billing Rule Definition Quick Billing Electronic Billing Scenario 1: File Names are consistent in Quick Billing and Electronic Billing Specific Setup: Quick Billing Rule Definition: Note the ‘File Description’ of a rule that has services to bill. Note the ‘Financial Class’, ‘Guarantor(s)’ and the ‘Billing Form’. Quick Billing: Process the above definition for the desired date range. Select ‘Edit’ and select the ‘File’ that was created. Validate that the ‘File Description’ displays after the date range. Steps Open ‘Electronic Billing’. Select the desired ‘Billing Form’. Select the desired ‘Financial Class’. Select the desired value in ‘Individual Or All Guarantors’. If ‘Individual’ was selected above, select the desired ‘Guarantor’. Select ‘Run Report’ in ‘Billing Options’. Select ‘Print’ in ‘Print Or Delete’. Select the file that was created in ‘Quick Billing’. Validate that the ‘File Description’ matches the ‘Quick Billing Rule Definition’, ‘File Description'. Close the form.	Topics • Electronic Billing • Quick Billing • NX
Update 52 Summary \| Details 'Client Ledger' report Scenario 1: 'Client Ledger' report - validate fields have no overlaps Specific Setup: Client with a Guarantor and Services filed (Client A). Steps Access the 'Client Ledger' form. Select "Client A" in the 'Client ID' field. Select "All Episodes" in the 'Claim/Episode/All Episodes' field. Select "Crystal" in the 'Ledger Type' field. Click [Process]. Review the report and verify the following: 'Service Description' field does not overlap with 'Units' field. 'Guarantor' field does not overlap with 'Guarantor Liability' field. Validate the 'Line Balance' field is not cut off. Close the report.	Topics • Client Ledger • NX
Update 53 Summary \| Details Client Ledger - Ledger Type = Claim Scenario 1: Client Ledger - Ledger Type = 'Claim' - report field validations Specific Setup: Posting/Adjustment Codes Definition: Identify an existing payment, adjustment and/or transfer codes. Note the codes/values for further testing. Admission: A new client is admitted in the inpatient program. Note the client's id/name, admission program, admission date. Guarantor/Payors: An existing guarantor is identified to assign to the client. Financial Eligibility: The existing guarantor is assigned to the client. Note the Guarantor code/value. Service Codes: An existing room and board service code is identified to render services to the client. Note the service code. Client Charge Input: 5-6 days of the room and board services are rendered to the client. Close Charges: The charges rendered to the client are closed. Steps Open the 'Electronic Billing' form. Run an 837 Institutional bill for the client. Verify the bill compiles successfully. Claim the services. Verify the bill compiles successfully. Open the 'Client Ledger' form. Process the report using 'Claim' ledger type and validate that the claim based report displays all the claim specific information. Open the ‘Individual Cash Posting’ form. Select the ‘Client’. Select desired value in the ‘Post By’ field. Click [Select Item(s) To Post Against]. A grid opens containing a row for all services. Select a desired row. Click [OK] when all desired rows have been selected. Note the ‘Information’ message and the current balance for the guarantor. Click [OK]. Enter desired value in ‘Posting Date’. Enter desired value in ‘Date of Receipt’. Validate that the ‘Guarantor’ defaulted to the guarantor in the current balance message. Enter desired value in ‘Dollar Amount To Be Posted’. Amount entered can be the full amount due or a partial amount due. Enter desired value in ‘Posting Code’. If desired, enter a value in ‘Check #’. Enter desired value in ‘Action For Remaining Balance If Applicable’. Click [Update Temporary File]. If desired, continue to add payment/adjustments/transfers using the steps above for all other services. Click [Submit] when all payment/adjustments/transfers have been completed. Open ‘Client Ledger’ for the client’. Process the report using ‘Simple' ledger type and validate that the payment/adjustments/transfers posted correctly. Process the report using ‘Claim' ledger type and validate that the payment/adjustments/transfers posted correctly specific to claim. Close the form.	Topics • Client Ledger
Update 54 Summary \| Details Process Internal Referrals Form: Internal Referral Information Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Table Definition (PM) Internal Referral Type Maintenance Group Member Assignment Internal Client Referrals Process Internal Referrals Scenario 1: Internal Referral Type Maintenance - Validating all the 'Internal Referral Type Category' Specific Setup: Form Definition: Create or identify an existing a user-defined (modeled) form that collects the additional referral information needed to approve or reject a referral. Note the form name and Table name. The form must contain a Non Scrolling Free Text data element that has been configured in Table Definition as a Referral Group. Note the field name. Table Definition: A Non Scrolling Free Text data element that has been configured as a Referral Group. Note the field name. Admission: Create a new client or identify an existing client. Note the client id, name. Steps Open the 'Internal Referral Type Maintenance' form. Select 'Add Internal Referral type' in the 'Add Or Edit Internal Referral Type' field. Verify the 'Internal Referral Type Code' field displays the identification code assigned to the referral type. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Program' in the 'Internal Referral Type Category' field. Select desired program from the 'Program' field. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Group' in the 'Internal Referral Type Category' field. Select desired group from the 'Group' field. Note the group name/code. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Team' in the 'Internal Referral Type Category' field. Select desired team from the 'Team' field. Note the team name/code. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'Yes' to 'Form Return' Message. Enter desired name in the 'Internal Referral Type Name' field. Note the name. Select 'Other' in the 'Internal Referral Type Category' field. Select the modeled form created or identified in the setup section to associate with this referral type in the 'Assessment Associated With Internal Referral Type' field. Select 'No' in the 'Does This Internal Referral Type Have A Waitlist?' field. Enter desired description of this referral for use in displays and reporting in the 'Internal Referral Type Description' field. Select desired user from the 'Select User' search box. Click [Add User]. Verify the 'User(s) To Receive Internal Referrals' field displays a list of users who are assigned to this referral. Click [Submit]. Select 'No' to 'Form Return' Message. Open the 'Internal Client Referral' form. Select desired client in the 'Client Being Referred' field. Select 'Program' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Program' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The Internal Referral Type Description field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Program' field is marked as a required field and it is auto populated with the program selected in the 'Internal Referral Type Maintenance' form. Select 'Group' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Group' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The Internal Referral Type Description field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Group' field is marked as a required field and it is auto populated with the group selected in the 'Internal Referral Type Maintenance' form. Select 'Team' in the 'Internal Referral Type Category' field. Validate the 'Internal Referral Type Being Requested' field displays only the 'Team' type referrals. Select desired referral type from the 'Internal Referral Type Being Requested' field. Validate the 'Episode' field is enabled and the client episode for which the referral is being made is auto populated in the 'Episode' field. The 'Internal Referral Type Description' field displays the detailed referral description that was entered on the Internal Referral Type Maintenance form. Validate the 'Internal Referral Team' field is marked as a required field and it is auto populated with the team selected in the 'Internal Referral Type Maintenance' form. Close the form. Scenario 2: Internal Referral - Process Internal Referrals Specific Setup: Form Definition: Create or identify an existing a user-defined (modeled) form that collects the additional referral information needed to approve or reject a referral. Note the form name and Table name. The form must contain a Non Scrolling Free Text data element that has been configured in Table Definition as a Referral Group. Note the field name. Table Definition: A Non Scrolling Free Text data element that has been configured as a Referral Group. Note the field name. Admission: Create a new client or identify an existing client. Note the client id, name, admission program value/code. Internal Referral type maintenance: Desired internal referral type is created to be used for the client. Note the referral type. Internal Client Referral : Internal client referral created for the desired client using the referral type created. Steps Open the 'Process Internal Referrals' form. Verify that the form lists initiated referrals ready to be processed in a grid. From the list to be processed the user will be able to assign a new status of 'Accepted', 'Rejected', 'Rejected – More Information Needed' or 'Waitlist' as well. Select desired internal referral in the grid. Verify the fields listed in the 'Internal Referral Information' section contains code and value of the field. Select desired status. Click [Process internal referral]. Verify the referral processed successfully. Ensure it is removed from grid(even if it’s the only one in the grid left). Ensure that a to do item sent back to user that filed 'Internal Client Referrals' form.	Topics • Internal Client Referrals • Internal Referral Type Maintenance • NX • Process Internal Referrals
Update 55 Summary \| Details Daylight Savings - Timestamps Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareFabric Monitor Discharge Scenario 1: 'Admission' form - Validate the 'ProgramAdmissionCreated' payload Steps Access the 'Admission' form. Verify the 'Select Client' dialog is displayed. Enter any new value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [Search]. Validate a "Search Results" message is displayed stating: No matches found. Click [New Client]. Validate a "Client" message displays indicating "Auto Assign Next ID Number?" Click [Yes]. Enter a date prior to daylight savings time in the 'Preadmit/Admission Date' field (Ex. 03/10/2023). Enter "10:00 AM" in the 'Preadmit/Admission Time' field. Select the desired program in the 'Program' field. Enter any value in the 'Type Of Admission' field. Enter the desired practitioner in the 'Admitting Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter the client admitted in the previous steps in the 'Client ID' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' is displayed. Select the 'ProgramAdmissionCreated' activity type. Click [Click to View Record]. Validate all filed information is populated. Validate the 'admissionDate' field contains the 'Preadmit/Admission Date' and 'Preadmit/Admission Time' populated in the previous steps with the correct time zone offset prior to daylight savings time (Ex: 2023-03-01T10:00:00.000-05:00). Close the report and the form. Access the 'Admission' form. Verify the 'Select Client' dialog is displayed. Enter any new value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [Search]. Validate a "Search Results" message is displayed stating: No matches found. Click [New Client]. Validate a "Client" message displays indicating "Auto Assign Next ID Number?" Click [Yes]. Enter a date during daylight savings time in the 'Preadmit/Admission Date' field (Ex. 05/01/2023). Enter "10:00 AM" in the 'Preadmit/Admission Time' field. Select the desired program in the 'Program' field. Enter any value in the 'Type Of Admission' field. Enter the desired practitioner in the 'Admitting Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter the second client admitted in the previous steps in the 'Client ID' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' is displayed. Select the 'ProgramAdmissionCreated' activity type. Click [Click to View Record]. Validate all filed information is populated. Validate the 'admissionDate' field contains the 'Preadmit/Admission Date' and 'Preadmit/Admission Time' populated in the previous steps with the correct time zone offset during daylight savings time (Ex: 2023-05-01T10:00:00.000-04:00). Close the report and the form. Scenario 2: 'Discharge' form - Validate the 'ProgramDischargeCreated' payload Specific Setup: Two clients must be enrolled in existing episodes (Client A & Client B). Steps Select "Client A" and access the 'Discharge' form. Enter a date prior to daylight savings time in the 'Date Of Discharge' field (Ex. 03/10/2023). Enter "10:00 AM" in the 'Discharge Time' field. Select any value in the 'Type Of Discharge' field. Enter the desired practitioner in the 'Discharge Practitioner' field. Select the desired value in the 'Discharge Client Living Arrangement' field. Enter the desired value in the 'Hospital Discharge Instructions' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter "Client A" in the 'Client ID' field. Click [View Activity Log]. Select "ProgramDischargeCreated" in the 'Activity Type' field. Click [Click to View Record]. Validate all filed information is populated. Validate the 'dischargeDate' field contains the 'Date Of Discharge' and 'Discharge Time' populated in the previous steps with the correct time zone offset prior to daylight savings time (Ex: 2023-03-01T10:00:00.000-05:00). Close the report and the form. Select "Client B" and access the 'Discharge' form. Enter a date during daylight savings time in the 'Date Of Discharge' field (Ex. 05/01/2023). Enter "10:00 AM" in the 'Discharge Time' field. Select any value in the 'Type Of Discharge' field. Enter the desired practitioner in the 'Discharge Practitioner' field. Select the desired value in the 'Discharge Client Living Arrangement' field. Enter the desired value in the 'Hospital Discharge Instructions' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter "Client B" in the 'Client ID' field. Click [View Activity Log]. Select "ProgramDischargeCreated" in the 'Activity Type' field. Click [Click to View Record]. Validate all filed information is populated. Validate the 'dischargeDate' field contains the 'Date Of Discharge' and 'Discharge Time' populated in the previous steps with the correct time zone offset during daylight savings time (Ex: 2023-05-01T10:00:00.000-04:00). Close the report and the form. Scenario 3: Diagnosis - Validate the 'DiagnosisCreated' and 'DiagnosisUpdated' SDK events Specific Setup: A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Diagnosis' form. Select the desired value in the 'Type Of Diagnosis' field. Enter a date prior to daylight savings time in the 'Date Of Diagnosis' field (Ex. 03/10/2023). Enter "10:00 AM" in the 'Time Of Diagnosis' field. Click [New Row]. Select the desired value in the 'Diagnosis Search' field. Select "Active" in the 'Status' field. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "DiagnosisCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'startDate' field contains the 'Date Of Diagnosis' and 'Time Of Diagnosis' populated in the previous steps with the correct time zone offset prior to daylight savings time (Ex: 2023-03-10T10:00:00.000-05:00). Close the report and the form. Select "Client A" and access the 'Diagnosis' form. Click [Add] to add a new diagnosis record. Select the desired value in the 'Type Of Diagnosis' field. Enter a date during daylight savings time in the 'Date Of Diagnosis' field (Ex. 05/01/2023). Enter "10:00 AM" in the 'Time Of Diagnosis' field. Click [New Row]. Select the desired value in the 'Diagnosis Search' field. Select "Active" in the 'Status' field. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "DiagnosisCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'startDate' field contains the 'Date Of Diagnosis' and 'Time Of Diagnosis' populated in the previous steps with the correct time zone offset during daylight savings time (Ex: 2023-05-01T10:00:00.000-04:00). Close the report and the form.	Topics • Admission • Discharge • Diagnosis
Update 56 Summary \| Details Demographics - Client Declined To Provide Information On The Following Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Pre Admit Crystal Reports or other SQL Reporting tool (PM Namespace) Scenario 1: Pre Admit Client - Add Client Specific Setup: There must be a practitioner defined (Practitioner A). Steps Access the 'Pre Admit' form. Enter any value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [New Client] and [Yes]. Validate the form displays the values populated in the previous steps. Enter the desired value in the 'Date of Birth' field. Enter the desired value in the 'Preadmit/Admission Date' field. Enter the desired value in the 'Preadmit/Admission Time' field. Select any value in the 'Program' field. Select any value in the 'Type of Admission' field. Enter and select "Practitioner A" in the 'Admitting Practitioner' field. Click [Expected Date of Admission T]. Enter and select "Practitioner A" in the 'Scheduled Admitting Practitioner' field. Enter any value in the 'Social Security Number' field. Enter any value in the 'Pre-Admission Diagnosis' field and press the "Enter" key. Validate "Powered By IMO Terminology" displays below the search results. Select the desired value. Populate any desired fields. Select 'Demographics'. Select 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Click [Submit]. Access the 'Pre Admit' form for the same client in 'Edit' mode. Select 'Demographics'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Deselect 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are enabled. Select desired values for 'Primary Language', 'Client Race', and 'Ethnic Origin'. Click [Submit]. Access the 'Pre Admit' form for the same client in 'Edit' mode. Select 'Demographics'. Validate that the submitted data was retained in 'Primary Language', 'Client Race', and 'Ethnic Origin'. Close the form. Scenario 2: Admission - Inpatient - Admit New Client Steps Access the 'Admission' form. Enter the desired value in the 'Last Name' field. Enter the desired value in the 'First Name' field. Select any value in the 'Sex' field. Click [Search], [New Client], and [Yes]. Enter any value in the 'Date of Birth' field. Enter any value in the 'Preadmit/Admission Date' field. Enter any value in the 'Preadmit/Admission Time' field. Select any value in the 'Type of Admission' field. Select any value in the 'Source Of Admission' field. Enter / Select data for required fields. Select the 'Demographics' section. Select 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Enter other desired data. Click [Submit]. Access the 'Admission' form for the same client. Select the 'Demographics' section. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Deselect 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are enabled. Select desired values for 'Primary Language', 'Client Race', and 'Ethnic Origin'. Click [Submit]. Access the 'Admission' form for the same client. Select the 'Demographics' section. Validate that the submitted data was retained in 'Primary Language', 'Client Race', and 'Ethnic Origin'. Close the form. Scenario 3: Update Client Data form - field validations Specific Setup: Select a client to use in 'Update Client Data' that has no values in 'Primary Language', 'Client Race', or 'Ethnic Origin'. Steps Access the 'Update Client Data' form. Validate the following fields: 'Last Name'. 'First Name'. 'Sex'. Select 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Click [Submit]. Access the 'Update Client Data' form. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Deselect 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are enabled. Select desired values for 'Primary Language', 'Client Race', and 'Ethnic Origin'. Click [Submit]. Access the 'Update Client Data' form. Select 'Demographics'. Validate that the submitted data was retained in 'Primary Language', 'Client Race', and 'Ethnic Origin'. Close the form. Scenario 4: Admission (Outpatient) - Admit New Client Steps Access the 'Admission (Outpatient)' form. Enter the desired value in the 'Last Name' field. Enter the desired value in the 'First Name' field. Select any value in the 'Sex' field. Click [Search], [New Client], and [Yes]. Enter any value in the 'Date of Birth' field. Enter any value in the 'Preadmit/Admission Date' field. Enter any value in the 'Preadmit/Admission Time' field. Select any value in the 'Type of Admission' field. Select any value in the 'Source Of Admission' field. Enter / Select data for required fields. Select the 'Demographics' section. Select 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Enter other desired data. Click [Submit]. Access the 'Admission (Outpatient)' form for the same client. Select the 'Demographics' section. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are disabled. Deselect 'Ethnic Origin', 'Race', and 'Language' in 'Client Declined To Provide Information On the Following'. Validate that 'Primary Language', 'Client Race', and 'Ethnic Origin' are enabled. Select desired values for 'Primary Language', 'Client Race', and 'Ethnic Origin'. Click [Submit]. Access the 'Admission (Outpatient)' form for the same client. Select the 'Demographics' section. Validate that the submitted data was retained in 'Primary Language', 'Client Race', and 'Ethnic Origin'. Close the form.	Topics • Pre Admit • Admission • Update Client Data • NX • Admission (Outpatient)
Update 57 Summary \| Details 837 Professional - Payer Identifier segment (2010BB-NM1-09) Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Numbers By Guarantor And Program Service Codes Financial Eligibility Electronic Billing Scenario 1: 837 Professional - 2010BB Specific Setup: Registry Settings: ‘Avatar PM->System Maintenance->Guarantors/Payors->->->Specify Report Only Guarantors’ = ‘Y’. Guarantors/Payors: There is a minimum of two guarantors in the same ‘Financial Class’: One guarantor has a value of ‘Yes’ in ‘Is This A Report Only Guarantor?’. Note the guarantor name. The other guarantor has a value of ‘No’ in ‘Is This A Report Only Guarantor?’. Note the guarantor name. Guarantor/Program Billing Defaults: The 837 Professional Template has a value of ‘Yes’ in ‘Include This Guarantor and Program Combination For Report Only Guarantors’. Client A: Note the episode program. Financial Eligibility: Is assigned the guarantor that has a value of ‘No’ in ‘Is This A Report Only Guarantor?’. Services have been provided to the client. Client Ledger: Is used to validate that the liability correctly distributed to the guarantor. Note the dates of service and guarantor. Close Charges: Is used to close the charges. Create Interim Billing Batch File to create a batch for the client, guarantor and service date range. Steps Open ‘Electronic Billing’. Create an unclaimed bill for the 837 Professional using all guarantors in ‘Type of Bill’, the interim batch that was created, the service date range. Review the dump file to validate that the 2010BB contains the guarantor’s name for the guarantor with ‘Yes’ in ‘Is This A Report Only Guarantor?’. Close the report. Change the Type of Bill’ to ‘Individual’ and select the guarantor with ‘No’ in ‘Is This A Report Only Guarantor?’. Process the bill. Review the dump file to validate that the 2010BB contains the guarantor’s name for the guarantor with ‘No’ in ‘Is This A Report Only Guarantor?’. Close the report. Close the form.	Topics • 837 Professional • NX
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 Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form. 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. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation. Click 'Process File' button to compile inbound 834 file data. Select 'Run Report' in 'Options' field, and select compiled 834 file for report. Click 'Process File' button to open 834 inbound compile report. 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. 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) 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). Select 'Post File' in 'Options' field, and select compiled 834 file for posting. Click 'Process File' button to post inbound 834 file data. Open Crystal Reports or other SQL reporting tool. 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-DTP348 (Benefit Begin Date)* is not included and 2300-DTP303 (Maintenance Effective Date)* is included Crystal Reports or other SQL reporting tool Steps Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form. 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-DTP348 (Benefit Begin Date)* is not included and 2300-DTP303 (Maintenance Effective Date)* is included. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation. Click 'Process File' button to compile inbound 834 file data. Select 'Run Report' in 'Options' field, and select compiled 834 file for report. Click 'Process File' button to open 834 inbound compile report. In 834 inbound compile report - ensure that in case where 2300-DTP348 (Benefit Begin Date)* is not included and 2300-DTP303 (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-DTP303 value from 834 information; ensure that where 2300-DTP348 (Benefit Begin Date) is included in 834 health coverage detail, this value is used as 'Coverage Period Effective Date' over Maintenance Effective Date 2300-DTP303 value. Select 'Post File' in 'Options' field, and select compiled 834 file for posting. Click 'Process File' button to post inbound 834 file data. Open Crystal Reports or other SQL reporting tool. In Avatar PM SQL table 'SYSTEM.eligibility_dependent_cov', ensure that 'eligibility_eff_date' value as determined by either 2300-DTP303 (Maintenance Effective Date) or 2300-DTP348 (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 Open 'Registry Settings' form. Enter search value 'Use 2300-DTP with 303 Qualifier as Effective Date' and click 'View Registry Settings' button. 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). 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-DTP348 (Benefit Begin Date)* and/or 2300-DTP303 (Maintenance Effective Date)* are not included Crystal Reports or other SQL reporting tool Steps Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form. 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-DTP348 (Benefit Begin Date)* and/or 2300-DTP303 (Maintenance Effective Date)* are not included. Note - Use of 2300-DTP303 (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' Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation. Click 'Process File' button to compile inbound 834 file data. Select 'Run Report' in 'Options' field, and select compiled 834 file for report. Click 'Process File' button to open 834 inbound compile report. In 834 inbound compile report - ensure that in case where 2300-DTP348 (Benefit Begin Date) and/or 2300-DTP303 (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-DTP349 value from 834 information; ensure that where 2300-DTP348 (Benefit Begin Date) and/or 2300-DTP303 (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. Examples: If 834 Coverage Information includes Coverage Expiration Date 2300-DTP349 value '06/30/2023', '06/15/2023' or '06/01/2023' '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' If 834 Coverage Information includes Coverage Expiration Date 2300-DTP349 value '04/30/2023', '04/25/2023' or '04/02/2023' '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' Select 'Post File' in 'Options' field, and select compiled 834 file for posting. Click 'Process File' button to post inbound 834 file data. Open Crystal Reports or other SQL reporting tool. 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-DTP348 Benefit Begin Date / 2300-DTP303 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 Open the Avatar PM 'Guarantors/Payors' form. Select Add or Edit action in 'Add New or Edit Existing Guarantor' field. Enter new (or select existing) Guarantor Code. Complete all required/desired fields in main section of 'Guarantors/Payors' form. Navigate to '270 / 271 / 834' section of 'Guarantors/Payors' form. 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. 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-DTP348 (Benefit Begin Date) and/or 2300-DTP303 (Maintenance Effective Date) is/are not included. 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). Navigate to main section of 'Guarantors/Payors' form. Click 'File' button to save/file Guarantor/Payor definition information. Select 'Edit' action and select previously filed Guarantor Code. Navigate to '270 / 271 / 834' section of 'Guarantors/Payors' form. 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 Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form. Select 'Load File' in 'Options' field, and enter 'File Path/Name' value for 834 file to be loaded. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation. Click 'Process File' button to compile inbound 834 file data. Select 'Run Report' in 'Options' field, and select compiled 834 file for report. Click 'Process File' button to open 834 inbound compile report. In 834 inbound compile report, ensure that one or more coverage periods from file are successfully compiled. Select 'Post File' in 'Options' field, and select compiled 834 file for posting. Click 'Process File' button to post inbound 834 file data. Close 'Benefit Enrollment and Maintenance (834)' form. Open Crystal Reports or other SQL reporting tool. 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): 'cust_par_comm_1' / 'cust_par_comm_2' / 'cust_par_comm_3' 'cust_par_comm_qua_1_code' / 'cust_par_comm_qua_2_code' / 'cust_par_comm_qua_3_code' 'cust_parent_contact_code' 'cust_parent_id' / 'cust_parent_id_code' / 'cust_parent_id_qua_code' 'cust_parent_name_first' / 'cust_parent_name_last' / 'cust_parent_name_mid' 'cust_parent_name_pre' / 'cust_parent_name_suf' 'cust_parent_type_qua_code' 'cust_par_address' / 'cust_par_address_2' 'cust_par_city' / 'cust_par_country' / 'cust_par_coun_sub_div' 'cust_par_state' / 'cust_par_zip' 'location_qualifier' / 'location_ident' 'health_related_code' 'resp_per_address' / 'resp_per_address_2' 'resp_per_city' / 'resp_per_country' / 'resp_per_coun_sub_div' 'resp_per_state' / 'resp_per_zip' 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): 'date_of_death' 'language_desc' 'language_use_indicator' 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): 'reference_identification' 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). 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 Open Avatar PM 'Benefit Enrollment and Maintenance (834)' form. 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. Select 'Compile File' in 'Options' field, and select loaded 834 file for compilation. Click 'Process File' button to compile inbound 834 file data. Select 'Run Report' in 'Options' field, and select compiled 834 file for report. Click 'Process File' button to open 834 inbound compile report. 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). 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) 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') 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 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) 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) 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) 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). 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) 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') 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 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) 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) 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. 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) Select 'Post File' in 'Options' field, and select compiled 834 file for posting. Click 'Process File' button to post inbound 834 file data. Open Crystal Reports or other SQL reporting tool. 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 Open 'Registry Settings' form. Enter search value 'Plan Coverage Description (2300-HD-04)' and click 'View Registry Settings' button. Ensure Registry Setting 'Plan Coverage Description (2300-HD-04)' is returned (under 'Avatar PM -> Billing -> Electronic Submissions -> Benefit Enrollment and Maintenance' path). 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 59 Summary \| Details File Import - 'Deposit Entry' file type Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Recurring Client Charge Input (Charge Fee Access) Discharge File Import Service Codes Posting/Adjustment Codes Definition Deposit Entry Scenario 1: File Import - Deposit Entry - Posting a deposit for a discharged client /episode Specific Setup: Registry Setting: Set the 'Avatar PM->System Maintenance->File Import->->->Import File Delimiter' registry setting to the desired value. Guarantors/Payor: An existing guarantor is identified to be assigned to the client. Note the guarantor code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Identify the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the Client id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. Discharge: Client is discharged after 5 days from admission date. Note the discharge date. File Import: An import file is created to process the deposit entry. Ensure that the 'Date of Receipt or adjustment' is greater than discharge date. The file contains all required fields and desired optional fields. Ensure Note the file name / location of the file. Steps Open the 'File Import' form. Select the 'Deposit Entry' from the File Type field. Upload the file Import file created in the setup section. Compile the file. Verify the file compiles successfully. Post the compiled file. Verify the file posted successfully. Open the 'Client Ledger' for the client. Process the report. Verify the client ledger displays the deposit entry correctly. Close the Report. Close the form. Scenario 2: File Import - Deposit Entry' - Posting a file for the active client/episode Specific Setup: Registry Setting: Set the 'Avatar PM->System Maintenance->File Import->->->Import File Delimiter' registry setting to the desired value. Guarantors/Payor: An existing guarantor is identified to be assigned to the client. Note the guarantor code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Identify the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the Client id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. File Import: An import file is created to process the deposit entry. Ensure that the file contains all required fields and desired optional fields. Note the file name / location of the file. Steps 1. Open the 'File Import' form. 2. Select the 'Deposit Entry' from the File Type field. 3. Upload the file Import file created in the setup section. 4. Compile the file. 5. Verify the file compiles successfully. 6. Post the compiled file. 7. Verify the file posted successfully. 8. Open the 'Client Ledger' for the client. 9. Process the report. 10. Verify the client ledger displays the deposit entry correctly. 11. Close the Report. 12. Close the form. Scenario 3: Deposit Entry - Submitting deposit entry using 'Deposit Entry' form for discharged client Specific Setup: Guarantors/Payor: An existing guarantor is identified to be assigned to the client. Note the guarantor code/value. Program Maintenance: Identify an existing program code / value to be used for client's admission. Identify the location of the program to be used for Client's admission. Admission: An inpatient or outpatient client is created using the program identified above or an existing client is identified. Note the Client id/name, admission date/program. Financial Eligibility: The existing guarantor is assigned to the client. Service code: An existing service code to be used with inpatient/ outpatient program is identified. Note the service code for further validation. Posting/Adjustment Code Definition: An existing payment, adjustment or transfer code is identified to be used. Note the code and type of the code. Discharge: Client is discharged after 5-6 days from admission date. Note the discharge date. Steps Open the 'Deposit Entry' form. Enter desired date that is greater than discharge date in the 'Date Of Receipt Or Adjustment' field. Validate the system accepts the date outside of the episode. Enter desired client in the 'Client ID' field. Select the desired episode in the 'Episode Number' field. Validate the 'Program Of Service' field contains the correct value. Validate the 'Location' field contains the associated locations defined in the 'Program Maintenance' from for the admission program. Enter the desired value in the 'Service Code' field. Select the desired value in the 'Guarantor' field. Enter the desired value in the 'Amount To Post' field. Select the desired value in the 'Posting Code' field. Click [Submit]. Open the 'Client Ledger' form. Verify the deposit entry displays in the form correctly. Close the report. Close the form.	Topics • Deposit Entry • File Import • NX
Update 60 Summary \| Details Update Client Data - Change client name Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick Actions Page Scenario 1: Quick Action - Update Client Data - Validate name change Specific Setup: Using the "View Definition" form, add the "Quick Actions" widget to the user's HomeView. Using the "NX View Definition" form, add the Quick Action for "Update Client Data". Admission: A new client is admitted. Note the client id/name. Steps Select the test client. Navigate to the 'Quick Actions' widget. Locate the 'Update Client Data' Quick Action. Click 'Add' button. Change the client's first and last name. Fill in all other fields. Click 'Save'. Open the 'Update Client Data' form. Validate the first and last name are changed. Using SQL, validate the name change is reflected in the columns, patient_name, patient_name_first, patient_name_last in SYSTEM.patient_current_demographics SQL.	Topics • Update Client Data
Update 61 Summary \| Details 'External Documents' widget - Search process Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareConnect HIE Configuration Consent For Access External Documents Scenario 1: 'External Documents' widget - Validation when 'Carequality' is enabled and 'Consent Model' is "Opt Out" Specific Setup: Carequality is enabled in the 'CareConnect HIE Configuration' form. One or more organizations are defined as favorites in the 'Organization: Exceptions and Favorites' field. "Query" is selected in the 'Consent Model' field in the 'CareConnect HIE Configuration' form. A client is enrolled in an active episode with consent granted to a network and an organization in 'Consent For Access' (Client A). The logged in user must have a view configured with the 'External Documents' widget and the 'Console Widget Viewer'. Steps Select "Client A" and navigate to the 'External Documents' widget. Click [Search]. Validate the 'External Documents' widget contains CCDs from: Any organization(s) defined as "Favorite" in the 'Carequality Configuration' section of the 'CareConnect HIE Configuration' form Any organization with consent granted in 'Consent for Access' All networks in the Network List Click [View] for any CCD. Validate the CCD displays in the 'Console Widget Viewer', Click [Close All]. Scenario 2: 'External Documents' widget - Validation when 'Carequality' is enabled and 'Consent Model' is "Query" Specific Setup: Carequality is enabled in the 'CareConnect HIE Configuration' form. One or more organizations are defined as favorites in the 'Organization: Exceptions and Favorites' field. "Query" is selected in the 'Consent Model' field in the 'CareConnect HIE Configuration' form. A client is enrolled in an active episode with consent granted to a network and an organization in 'Consent For Access' (Client A). The logged in user must have a view configured with the 'External Documents' widget and the 'Console Widget Viewer'. Steps Select "Client A" and navigate to the 'External Documents' widget. Click [Search]. Validate the 'External Documents' widget contains CCDs from: Any organization(s) defined as "Favorite" in the 'Carequality Configuration' section of the 'CareConnect HIE Configuration' form Any organization with consent granted in 'Consent for Access' All networks in the Network List Click [View] for any CCD. Validate the CCD displays in the 'Console Widget Viewer', Click [Close All]. Scenario 3: 'External Documents' widget - Validation when 'Carequality' is disabled and 'Consent Model' is "Opt In" Specific Setup: Carequality is disabled in the 'CareConnect HIE Configuration' form. "Opt In" is selected in the 'Consent Model' field in the 'CareConnect HIE Configuration' form. A client is enrolled in an active episode with consent granted to a network (Network A) in 'Consent For Access' (Client A). The logged in user must have a view configured with the 'External Documents' widget and the 'Console Widget Viewer'. Steps Select "Client A" and navigate to the 'External Documents' widget. Click [Search]. Validate the 'External Documents' widget contains a CCD from "Network A". Click [View]. Validate the CCD displays in the 'Console Widget Viewer', Click [Close All]. Scenario 4: 'External Documents' widget - Validation when 'Carequality' is enabled and 'Consent Model' is "Opt In" Specific Setup: Carequality is enabled in the 'CareConnect HIE Configuration' form. One or more organizations are defined as favorites in the 'Organization: Exceptions and Favorites' field. "Opt In" is selected in the 'Consent Model' field in the 'CareConnect HIE Configuration' form. A client is enrolled in an active episode with consent granted to a network and an organization in 'Consent For Access' (Client A). The logged in user must have a view configured with the 'External Documents' widget and the 'Console Widget Viewer'. Steps Select "Client A" and navigate to the 'External Documents' widget. Click [Search]. Validate the 'External Documents' widget contains CCDs from: Any organization(s) defined as "Favorite" in the 'Carequality Configuration' section of the 'CareConnect HIE Configuration' form Any organization with consent granted in 'Consent for Access' Any network with consent granted in 'Consent for Access' Click [View] for any CCD. Validate the CCD displays in the 'Console Widget Viewer', Click [Close All]. Scenario 5: Dictionary Update - Validate the 'Network' dictionary Specific Setup: The 'CareConnect HIE Configuration' form must be configured to upload CCDs to a Health Information Exchange. Steps Access the 'Dictionary Update' PM form. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Individual Data Element" in the 'Individual or All Data Elements' field. Select "(36020) Network" in the 'Data Element' field. Click [Print Dictionary]. Validate the report displays all configured networks. Close the report and the form. 'External Documents' widget - 'Organization' column Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form and Table Documentation (PM) Scenario 1: Form and Table Documentation - Validate the 'SYSTEM.external_documents' table Specific Setup: Crystal Reports or other SQL reporting tool is required. Steps Access the 'Form and Table Documentation' PM form. Select "Table" in the 'Type of Documentation' field. Select "SYSTEM.external_documents" in the 'Table(s) to be Documented' field. Click [Process]. Validate the 'SQL Table Documentation' window is displayed for the 'SYSTEM.external_documents' SQL table. Validate the 'organization' column has a max length of "4096". Click [Dismiss] and close the form.	Topics • Consent for Access • External Document Widget • Dictionary • Query/Reporting • Form and Table Documentation
Update 62 Summary \| Details 837 Professional - SV1 segment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility MODIFIERS BY PRACTITIONER CATEGORY Electronic Billing Practitioner Enrollment Practitioner Numbers By Guarantor And Program Scenario 1: 837 Professional - Enable Duplicate Service Modifiers Specific Setup: Registry Setting: ‘Enable Duplicate Service Modifiers’ = ‘Y’. Modifiers By Practitioner Category: Verify a definition the contains values in the ‘Modifier’ and ‘Duplicate Service Modifiers’ fields. Note the values in ‘Modifier’, ‘Duplicate Service Modifiers’, ‘Guarantor ID’, ‘Program’ and ‘Practitioner Category’. Unclaimed services that can be billed on the 837 Professional for the ‘Guarantor ID’, ‘Program’ and ‘Practitioner Category’ are identified. At least one occurrence of a duplicated service occurs, or a service that was transferred to another guarantor exists. Steps Open ‘Electronic Billing’. Create an 837 Professional for the services. Review the ‘Dump File’ Validate that the SV1 segment contain the appropriate modifiers for non-duplicated services. Validate that the SV1 segment contain the appropriate modifiers for duplicated services. Close the report. Close the form. 837 Professional - CLM segment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Financial Eligibility Electronic Billing Scenario 1: PM - Electronic Billing - 837 Professional - Include primary and associated add-on services in the same claim Specific Setup: System is set up to allow ‘Add-On’ services to the primary services. Service Codes: Use ‘Service Code Category’ to note the ‘Primary Code’. Note the associated add-on codes. Guarantors/Payors: Guarantor 1: Note the ‘Financial Class’. This will be the client’s primary guarantor. Guarantor 2: Note the ‘Financial Class’. This will be the client’s secondary guarantor. Guarantor/Program Billing Defaults: The ‘Maximum Service Information Per Claim Information (Maximum LX Per CLM)’ = 1. Clients: Client 1: Is enrolled in an outpatient program. Note the program. Client has an active diagnosis record. Client has an active financial eligibility record with the above guarantors. Services have been provided for the above ‘Primary Code’ that include add-on codes. Close Charges was used to close the charges. Client Ledger has been used to verify that the liability distributed to the primary guarantor, and note the dates of service for closed, unclaimed services for the above service codes. Client 2: Is enrolled in an inpatient program. Note the program. Client has an active diagnosis record. Client has an active financial eligibility record with a primary and secondary guarantor. Services have been provided for the above ‘Primary Code’ that include add-on codes. Close Charges was used to close the charges. Client Ledger has been used to verify that the liability distributed to the primary guarantor, and note the dates of service for closed, unclaimed services for the above service codes. Steps Open ‘Electronic Billing’. Select ‘837-Professional’ in ‘Billing Form’. Select the primary guarantor ‘Financial Class in ‘Type Of Bill’. Select ‘Individual’ in ‘Individual Or All Guarantors’. Select the primary guarantor in ‘Guarantor’. Select ‘Outpatient’ in ‘Billing Type’. Select ‘Sort File’ in ‘Billing Options’. Enter the desired value in ‘File Description/Name’. Select ‘All Clients’ in ‘All Clients Or Interim Billing Batch’. Select desired value in ‘Program(s)’. Select ‘No’ in ‘Create Claims’. Enter the desired value in ‘First Date Of Service To Include’. Enter the desired value in ‘Last Date Of Service To Include’. Select ‘All in ‘Include Primary and/or Secondary Billing. Click [Process]. Validate the ‘Processing Report’ message contains ‘Compile Complete’. Click [OK]. Select ‘Dump File’ in ‘Billing Options’. Select ‘Print’ in ‘Print Or Delete Report’. Select the desired report in ‘File’. Click [Process]. Validate that there is one ‘CLM’ segment per service, Close the report. Close the form. If desired, use 'Individual Cash Posting' to transfer the services to the secondary guarantor, transferring an add-on code before the transferring the primary code. If the transfer was performed, process the ‘837-Professional’ again to validate that only one claim is created for the service.	Topics • 837 Professional • NX
Update 63 Summary \| Details Document Routing - Replace ‘Date Created’ with ‘Date Signed’ on Document Routing Images. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Document Routing Setup (PM) Client Disclosure Management Disclosure Management Configuration Treatment Plan Clinical Document Viewer Scenario 1: Disclosure Management - Date Created vs. Date Signed - Document Routing disabled Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be enabled. Using the "Document Routing Setup" form, disable document routing for Progress Notes (Group and Individual), Treatment Plan and a user modeled form. Using "Disclosure Management Configuration", include "Progress Notes (Group and Individual), Treatment Plan and a user modeled form among the forms available to the "Disclosure Management" form. Steps Using the "Progress Notes (Group and Individual)" form: Generate a progress note. Finalize the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using the "Treatment Plan" form: Generate a new treatment plan. Finalize the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using a user modeled form: Generate a new form. Finalize the form. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Open the "Disclosure Management" form: Generate a disclosure packet. On the Request section, select the client, episode and Request Information Start and End Dates that will encompass the forms previously generated for this test. Click "Apply Filters to Document Images" button. In the "Requested Chart Items" box, select "Progress Notes (Group and Individual)", Treatment Plan, user modeled forms you want to include in the disclosure packet. In the "Requested Document Images" box, select the forms for Progress Notes (Group and Individual), Treatment Plan and user modeled form you want to include in the disclosure packet. Navigate to the "Authorization" section. Select the same Episode and the Authorization Start and End Dates. Click "Yes - Default All Chat Items to Yes" radio button. Click "Update Chart Items Authorized for Disclosure" button. Click "Save" button. Click "Refresh Chart Items" button. Click "Yes - Default All Document Items To Yes" radio button. Click the "Update Document Images Authorized for Disclosure" button. Click "Save" button. Click "Refresh Document Images" button. Navigate to the "Disclosure" section. Populate the "Disclosure Date" and "Disclosure Time". Select all items in the "Chart Disclosure Information" box. Select all items in the "Disclosure Images" box. Select "Electronic" in the "Disclosure Method" field. Click "Process" button. Select various forms and then press "View". Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Disclose" button. The final disclosure packet is presented. Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Save" to generate the disclosure packet into a PDF document to be provided for the request, authorization and disclosure. Open the "Disclosure Management" form: Select to edit the disclosure that was just filed. Validate it displays as it was previously saved. Scenario 2: Disclosure Management - Form Validations Specific Setup: In the 'View Attachment Types field on the 'Disclosure Management Configuration' form, select various modeled and product form type attachments to include for requesting and authorizing document images for disclosure. In the product and modeled forms selected in the previous step, have documents generated for a client in multiple episodes (Client A). The 'Sort Episodes by Admission Date' registry setting must be enabled. Steps Select "Client A" and access the 'Disclosure Management' form. Enter a date in the 'Request Date' field. Enter a date in the 'Request Information Start Date' field. Enter a date in the 'Request Information End Date' field. In the 'Requested Episode(s)' field, validate all episodes are listed and displayed in a readable format. Select the desired episodes to include. Click [Apply Filter to Document Images]. Select the desired items in the 'Requested Chart Items' field. Select the desired documents in the 'Requested Document Images' field. Enter an organization name in the 'Organization' field. Go to the 'Authorization' section. Select "Yes" in the 'Signed Authorization On File' field. Enter a date in the 'Authorization Start Date' field. Enter a date in the 'Authorization End Date' field. Validate all episodes are listed and displayed in a readable format in the 'Authorization Episode(s)' field. Select desired episodes to include in the 'Authorization Episode(s)' field. Click [Update Chart Items Authorized For Disclosure]. Validate all items are set to "Yes" in the 'Authorized' field. Click [Save]. Click [Refresh Chart Items]. Click [Apply Filter to Document Images]. Click [Update Document Images Authorized for Disclosure]. Validate all items are set "Yes" in the 'Authorized' field. Click [Save]. Click [Refresh Document Images]. Go to the 'Disclosure' section. Enter a date in the 'Disclosure Date' field Enter a time in the 'Disclosure Time' field. Select "Electronic" in the 'Disclosure Method' field. Click [Process]. Validate the items list in the 'Disclosure Management' panel are as expected. Select the item and click [View]. Validate the documents displays as expected. Click [Disclose]. Validate the disclosure displays as expected and 'Save' displays. Click [Save]. Validate a 'Confirm' dialog stating: "Save PDF on your computer?" and click [OK]. Validate the file downloads. Validate a 'Disclosure' dialog stating: "Once this Disclosure Management record is filed with a Disclosure Date entered it will no longer be available for edit. This record will be available to view and print items." and click [Cancel]. Validate a dialog stating: "Filing cancelled." and click [OK]. Click [Save]. Validate a 'Confirm' dialog stating: "Save PDF on your computer?" and click [Cancel]. Validate nothing downloads. Validate a 'Disclosure' dialog stating: "Once this Disclosure Management record is filed with a Disclosure Date entered it will no longer be available for edit. This record will be available to view and print items." and click [OK]. Validate the form closes. Scenario 3: Registry Setting - Replace 'Date Created' with 'Date Signed' Steps Open the "Registry Setting" form. Set the "RADplus->Document Routing->Document Routing Setup->->->Replace 'Date Created' with 'Date Signed' on Document Routing Images' to any value other than "Y" or "N". Validate the error message "The selected value is not valid in the current system code for the following reason: Please enter "Y" or "N". Set registry setting to "N". Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form, Open the "Progress Notes (Group and Individual)" form. File an individual progress note. Finalize and route the note. Navigate to the "ToDo" widget for the approver. Validate the first line of every page of the document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Using the "Clinical Document Viewer", validate the document displays as it was filed with "Date Crated" on the first line of every page. Open the "Registry Setting" form. Set registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" to "Y". Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form, form. Open the "Progress Notes (Group and Individual)" form. File and individual progress note. Finalize and route the note. Navigate to the "ToDo" widget for the approver. Validate the first line of every page of the document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Using the "Clinical Document Viewer", validate the document displays as it was filed with "Date Signed" on the first line of every page. Scenario 4: Progress Notes (Group and Individual) - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form. Using "Disclosure Management Configuration", the "Progress Notes (Group and Individual)" form among the forms available to the "Disclosure Management" form. Steps Open the "Progress Notes (Group and Individual) form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the "Progress Notes (Group and Individual)" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 5: Treatment Plan - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for the "Treatment Plan" form. Using "Disclosure Management Configuration", the "Progress Notes (Group and Individual)" form among the forms available to the "Disclosure Management" form. Steps Open the "Treatment Plan" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the "Treatment Plan" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 6: User Modeled Form - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for a user modeled form. Using "Disclosure Management Configuration", the user modeled form among the forms available to the "Disclosure Management" form. Steps Open the user modeled form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the user modeled form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 7: Disclosure Management - Date Created vs. Date Signed - Document Routing Enabled Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be enabled. Using the "Document Routing Setup" form, enable document routing for Progress Notes (Group and Individual), Treatment Plan and a user modeled form. Using "Disclosure Management Configuration", include "Progress Notes (Group and Individual), Treatment Plan and a user modeled form among the forms available to the "Disclosure Management" form. Steps Using the "Progress Notes (Group and Individual)" form: Generate a progress note. Finalize and route the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using the "Treatment Plan" form: Generate a new treatment plan. Finalize and route the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using a user modeled form: Generate a new form. Finalize and route the form. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Open the "Disclosure Management" form: Generate a disclosure packet. On the Request section, select the client, episode and Request Information Start and End Dates that will encompass the forms previously generated for this test.. Click "Apply Filters to Document Images" button. In the "Requested Chart Items" box, select "Progress Notes (Group and Individual), Treatment Plan, user modeled forms you want to include in the disclosure packet. In the "Requested Document Images" box, select the forms for Progress Notes (Group and Individual), Treatment Plan and user modeled form you want to include in the disclosure packet. Navigate to the "Authorization" section. Select the same Episode and the Authorization Start and End Dates. Click "Yes - Default All Chat Items to Yes" radio button. Click "Update Chart Items Authorized for Disclosure" button. Click "Save" button. Click "Refresh Chart Items" button. Click "Yes - Default All Document Items To Yes" radio button. Click the "Update Document Images Authorized for Disclosure" button. Click "Save" button. Click "Refresh Document Images" button. Navigate to the "Disclosure" section. Populate the "Disclosure Date" and "Disclosure Time". Select all items in the "Chart Disclosure Information" box. Select all items in the "Disclosure Images" box. Select "Electronic" in the "Disclosure Method" field. Click "Process" button. Select various forms and then press "View". Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Disclose" button. The final disclosure packet is presented. Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Save" to generate the disclosure packet into a PDF document to be provided for the request, authorization and disclosure. Open the "Disclosure Management" form ; Select to edit the disclosure that was just filed. Validate it displays as it was previously saved.	Topics • Disclosure • NX • Progress Notes (Group And Individual) • Treatment Plan • Modeling
Update 64 Summary \| Details CareConnect HIE Configuration - 'Progress Notes Available in Carequality' help message Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareConnect HIE Configuration CareFabric Monitor Scenario 1: CareConnect HIE Configuration - Field Validations Specific Setup: Carequality is enabled in the 'CareConnect HIE Configuration' form. Steps Access the 'CareConnect HIE Configuration' form. Select the "Carequality Configuration" section. Click the help message for the 'Progress Notes Available in Carequality' field. Validate the help message contains: "The most recently signed progress notes specified here will be available via Carequality queries to outside providers. Only product progress notes or copies of product progress notes are available. The only information included in Carequality Response is the Notes Section of the progress note. No site specific fields will be included. Please note: This functionality was released prior to and is completely separate from the clinical note mapping capabilities that were released to support clinical notes mapping required with the ONC Certification and Cures Update." Click [OK]. Select the desired form(s) in the 'Progress Notes Available in Carequality' field. Click [Submit]. Access the 'CareConnect HIE Configuration' form. Select the "Carequality Configuration" section. Validate the 'Progress Notes Available in Carequality' field contains the form(s) selected in the previous steps. Close the form.	Topics • CareConnect
Update 65 Summary \| Details File Import - [Support Only] Guarantor Nature Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility File Import Guarantor Nature File Import Cross Episode Financial Eligibility Family Financial Eligibility Scenario 1: File Import - [Support Only] Guarantor Nature – Non-contract guarantor to Contract - 'If Customized Retain Customization' = 'Y' in File Import and client has two guarantors Steps Internal testing only File Import - Service Authorization - Member Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Service Authorization Financial Eligibility Guarantor Nature File Import Cross Episode Financial Eligibility Family Financial Eligibility Scenario 1: File Import - Service Authorization - Verification of Member Service Authorization Specific Setup: Registry Setting: The 'Avatar MSO->Membership Management->Member Enrollment->->->Require Member Enrollment' registry setting is set to 'Y'. The 'Avatar PM->System Maintenance->File Import->->->Import File Delimiter' is set to '2'. Member Enrollment: An existing member is identified, or a new member is created who has a 'Funding Source' record in 'Member Specific Information' and has no 'Service Authorization' record for the 'Funding Source'. Note the member id and funding source. The 'File Import' file is created to add an 'MSO - Service Authorization - Member' for Member and the 'Funding Source. Access to 'Crystal Reports' or other SQL reporting tool. User Definition: Access permission to Avatar MSO SQL table 'SYSTEM.file_import_mem_svc_auth'. Steps Open the 'File Import' form in Avatar PM. Select File Type '[Avatar MSO] Service Authorization - Member'. Validate ‘Upload File’ is selected in the ‘Action’. Select ‘[Avatar MSO] Service Authorization – Member’ in ‘File Type’. Click [Process Action]. Select the file that will add the authorization for the member. Verify the file uploads successfully. Select ‘Compile/Validate File’ in ‘Action’. Select the file that is recently uploaded successfully. Click [Process Action]. Verify the file compiles successfully. Select ‘Post File’ in ‘Action’. Select the file that is recently compiled successfully. Click [Process Action]. Verify the file posted successfully. Open the 'Service Authorization' form. Select a client that is used in the file import file. Verify the new authorization record is created. Validate all the information entered during file import are displayed correctly in the form. Scenario 2: File Import - [Support Only] Guarantor Nature – Non-contract guarantor to Contract - 'If Customized Retain Customization' = 'Y' in File Import and client has two guarantors Steps Internal testing only	Topics • Guarantor/Payors • File Import • NX
Update 66 Summary \| Details Quick Billing - 837 Error Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick Billing Rule Definition Financial Eligibility Quick Billing Scenario 1: Quick Billing 837 Error Report form Specific Setup: Quick Billing Rule Definition: Rule 1: A definition is defined with a value of ‘837 Professional’ in ‘Billing Form'. Note the 'Rule Description'. Note the values in definition that would allow for a client/service to be selected for the rule. Rule 2: An identical rule exists except the value of ‘Billing Form' is '837 Institutional'. Client A: Identify a client that has unclaimed services that would be selected for the rule based on the field values. Note the dates of service. The client does not have a 'Diagnosis' record. Steps Open ‘Quick Billing’. Select ‘Add New’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter the ‘First Date Of Service To Include’. Enter the ‘Last Date Of Service To Include’. Select the ‘Rule 1’ in ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges’, and ‘Generate Bills’ in ‘Quick Billing Tasks to Execute’. Enter a ‘Date Of Claim’. Click [Submit]. Validate that the ‘Compile Complete’ dialog contains ‘Errors Found’. Click [OK]. Click [Yes]. Select ‘Edit Existing’ in ‘Add New Or Edit Existing Quick Billing Batch’. Select the ‘File’ that was created with the errors. Click [Print 837 Report]. Validate that the ‘Required Data Missing: Subscriber and/or Patient Name Data’ link is enabled. Click the link. Validate that the error message contains ‘No Diagnosis Information Found’. Close the report. Select ‘Add New’ in ‘Add New Or Edit Existing Quick Billing Batch’. Enter the ‘First Date Of Service To Include’. Enter the ‘Last Date Of Service To Include’. Select the ‘Rule 2’ in ‘Billing Rule To Execute’. Select ‘Create Batch’, ‘Close Charges’, and ‘Generate Bills’ in ‘Quick Billing Tasks to Execute’. Enter a ‘Date Of Claim’. Click [Submit]. Validate that the ‘Compile Complete’ dialog contains ‘Errors Found’. Click [OK]. Click [Yes]. Select ‘Edit Existing’ in ‘Add New Or Edit Existing Quick Billing Batch’. Select the ‘File’ that was created with the errors. Click [Print 837 Report]. Validate that the ‘Required Data Missing: Patient Claim Data’ link is enabled. Click the link. Validate that the error message contains ‘No Diagnosis Information Found for Service’ and provides service description and date. Close the report. Close the form.	Topics • Quick Billing • NX
Update 67 Summary \| Details Remittance Functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Remittance Processing Widget Financial Eligibility Electronic Billing Payment Acknowledgement Scenario 1: Remittance Processing widget - Create/Edit/Delete Batch Steps Internal Testing Only.	Topics • NX
Update 68 Summary \| Details CPT Code Definition - Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CPT Code Definition (PM) Scenario 1: CPT Code Definition - Print CPT code Steps Open the 'CPT Code Definition' form. Add desired CPT code. Click [File Codes]. Edit the same code. Click [File Codes]. Click [Print CPT Codes]. Validate that the report displays correctly and does not overlap the fields. Search for the code added above and validate the data. Close the report. Close the form.	Topics • CPT Codes • NX
Update 69 Summary \| Details Diagnosis - 'Default 'Add To Problem List' to "Yes" on New Diagnosis' registry setting Scenario 1: Diagnosis - Validate the 'Default 'Add To Problem List' to "Yes" on New Diagnosis' registry setting Specific Setup: The 'Default 'Add To Problem List' to "Yes" on New Diagnosis' registry setting is set to "Y". A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Diagnosis' form. Select the desired value in the 'Type Of Diagnosis' field. Enter the desired date in the 'Date Of Diagnosis' field. Enter the desired time in the 'Time Of Diagnosis' field. Click [New Row]. Search for and select the desired diagnosis in the 'Diagnosis Search' field. Select "Active" in the 'Status' field. Validate the 'Add To Problem List' field contains "Yes" by default. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [New Row]. Search for and select the desired new diagnosis in the 'Diagnosis Search' field. Select "Rule-out" in the 'Status' field. Validate the 'Add To Problem List' field is disabled and does not contain a value. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Select "Client A" and access the 'Problem List' form. Click [View/Enter Problems]. Validate only the active diagnosis filed in the previous steps displays in the 'Problem List'. Close the form. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'SYSTEM.client_diagnosis_entry' SQL table. Validate two rows are displayed for the diagnosis records added in the previous steps. Validate that the active diagnosis has "Yes" in the 'add_prob_list_value' field. Validate the ruled-out diagnosis has "No Entry" in the 'add_prob_list_value' field. Close the report.	Topics • Registry Settings • Diagnosis • Problem List
Update 70 Summary \| Details Payment By Posting Date Report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Payment by Posting Date Scenario 1: Payment by Posting Date - Field Validations Specific Setup: There must be payments posted within the date range entered. Steps Access the 'Payment by Posting Date' form. Validate the 'User' field is empty. Select "All Users" in the 'Report Type' field. Validate the 'User' field is disabled. Validate the 'Receipt Number' field is disabled. Validate the 'Check Number' field is disabled. Validate the 'Client' field is disabled. Enter the desired value in the 'Start Date' field. Enter the desired value in the 'End Date' field. Click [Process]. Validate the crystal report displays the report data. If desired, note a 'User', 'Receipt Number', 'Check Number' and 'Client' to process other 'Report Type' options. Close the report. If desired, process reports by 'User', 'Receipt Number', 'Check Number' and 'Client' and validate the data. Close the form.	Topics • Billing
Update 71 Summary \| Details Financial Eligibility options - customize plan. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Select Plan Level To Default Cross Episode Financial Eligibility Family Financial Eligibility Scenario 1: Financial Eligibility options - Default Guarantor Plan into new plan level Specific Setup: Benefit Plan: Identify a plan that contains values in ‘Program Association’ at a minimum. Note the value for all other fields. Guarantors/Payors: Identify a guarantor that contains the above plan in ‘Default Guarantor Plan’ and ‘Yes in ‘Allow Customization Of Guarantor Plan’. Client 1: A client is identified that has a ‘Financial Eligibility’ record with the above guarantor. Client 2: A client is identified that has more than one episode, and a ‘Cross Episode Financial Eligibility’ record with the above guarantor. Family 1: A registered family has a ‘Family Financial Eligibility’ record with the above guarantor. Steps Open ‘Financial Eligibility’ for Client 1. Select the ‘Guarantor Selection’ section. Select the guarantor from setup. Click [Edit ‘Selected Item]. Select the ‘Customize Plan’ section. Click [Add New Item]. Click [Select Plan Level To Default]. Select the plan from setup. Validate that all data defaulted into the added item. Click [Submit]. Open ‘Cross Episode Financial Eligibility’ for Client 2. Select the ‘Guarantor Selection’ section. Select the guarantor from setup. Click [Edit ‘Selected Item]. Select the ‘Customize Plan’ section. Click [Add New Item]. Click [Select Plan Level To Default]. Select the plan from setup. Validate that all data defaulted into the added item. Click [Submit]. Open ‘Family Financial Eligibility’ for the registered family. Select the ‘Guarantor Selection’ section. Select the guarantor from setup. Click [Edit ‘Selected Item]. Select the ‘Customize Plan’ section. Click [Add New Item]. Click [Select Plan Level To Default]. Select the plan from setup. Validate that all data defaulted into the added item. Click [Submit].	Topics • Financial Eligibility • Cross Episode Financial Eligibility • NX
Update 72 Summary \| Details Database Management - Tables Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Electronic Billing Scenario 1: 837 Professional billilng when 'Enable Multiple Add-On Code Per Primary Code Functionality' = Y. Specific Setup: The following registry setting has a value of 'Y': Avatar PM->System Maintenance->Service Code Maintenance->->->Enable Multiple Add-On Code Per Primary Code Functionality. Dictionary Update has been used to update 'Other Tabled File, 291, Service Code Type' to have a value of 'Yes' in the extended dictionary 'Allow Multiple Add-On Code Definition' for all dictionary codes. A 'Service Code' identified with a 'Service Code Category' of 'Primary Code' has at least two values selected in 'Select Multiple Add-On Code'. An outpatient client is identified. Note the program. The client has an active diagnosis record, and an active financial eligibility record, noting the financial class. A service has been created for the above 'Service Code'. Note the date of service. The service has been closed. Use 'Client Ledger' to note the fee for the 'Service Code' and for each 'Add-On Code'. Note the total fee. Steps Open 'Electronic Billing'. Create an '837 Professional' bill for the service. Review the dump file to validate that the amount in the 'CLM' is equal to the total fee and that the amounts in the 'SV1' segments is equal to the total fee. Close the dump file. Close the form. Query the SYSTEM.billing_tx_master table. Locate the 'Service Code' selected in Setup. Validate that the 'multi_addon_svc_code' displays all add-on service code numbers selected in the primary service code . Validate that the 'multi_addon_svc_value' displays all add-on service code descriptions selected in the primary service code .	Topics • Database Management
Update 73 Summary \| Details Registry Settings - Enable BBH Service Modifiers Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: BBH Setup Scenario 1: Registry Setting - Enable BBH Service Modifiers Steps Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Validate the 2 forms "BBH Setup" and "Adult/Child Eligibility Category" are visible. Give the user access to the "BBH Setup" form and the "Adult/Child Eligibility Category" form. Refresh menus. Validate the "BBH Setup" form can be opened. Validate the "Adult/Child Eligibility Category" form can be opened. Open the "Registry Settings" form. Disable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Validate the 2 forms "BBH Setup" and "Adult/Child Eligibility Category" are no longer visible. Refresh menus. Validate the "BBH Setup" form is no longer available. Validate the "Adult/Child Eligibility Category" is no longer available. BBH Setup - Update BBH modifiers included on 837 Professional and HCFA bills. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: BBH Setup Scenario 1: BBH Setup Form - Field Validations Specific Setup: Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Give the user access to the "BBH Setup" form. Refresh menus. Steps Open the "BBH Setup" form. Populate each field on the form. Add multiple rows in the "Certification Category" table. File the form. Open the "BBH Setup" form. Validate the fields re display as they were previously filed. Edit one of the rows in the "Certification Category" table. Delete a row from the table. Open the "BBH Setup" form. Ensure that a default eligibility category of "Not Eligible" is established. Adult/Child Eligibility Category form - BBH functionality for 837 Professional and HCFA-1500 bills. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Adult/Child Eligibility Category Scenario 1: Adult/Child Eligibility Category - Field validations Specific Setup: Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Give the user access to the "BBH Setup" form and the "Adult/Child Eligibility Category" form. Refresh menus. Open the "BBH Setup" form. Select the "Guarantor(s)" to include.in BBH processing by selecting them in the "Avatar Guarantors for BBH". Select any service codes desired to be excluded from BBH processing. Select any programs to excluded from BBH processing. Navigate to the "Certification Category Setup" section and enter all certification categories that apply. Establish effective and lapse dates of this eligibility category. Establish "Modifier 1" and "Modifier 2" for the certification category. At a minimum, establish a "No Eligibility" category to avoid any billing issues with any client assigned to a guarantor that is included in BBH Setup, but for whom there is no specific BBH setup. . Admit a test client into any episode that is not excluded in the "BBH Setup" form. Steps Open the "Adult/Child Eligibility Category" form. Add a row by filing in all required fields and submitting the form. Submit the form. Add another row. Edit a row by changing some data. Retrieve the edited row and validate the changes are reflected. Delete a row and validate it's been removed. 837 Professional/HCFA-1500 Bills - BBH Service Modifiers functionality. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: BBH Setup Adult/Child Eligibility Category Financial Eligibility Electronic Billing Print Bill Clinical Document Viewer Scenario 1: 837P - BBH Modifiers Specific Setup: Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Give the user access to the "BBH Setup" form and the "Adult/Child Eligibility Category" form. Refresh menus. Open the "BBH Setup" form. Select the "Guarantor(s)" to include.in BBH processing by selecting them in the "Avatar Guarantors for BBH". Select any service codes desired to be excluded from BBH processing. Select any programs to excluded from BBH processing. Set any modifiers that must be first position modifiers in the SV1 segment of the 837 Professional file. Set any modifiers that must be last position modifiers in the SV1 segment of the 837 Professional file. Navigate to the "Certification Category Setup" section and enter all certification categories that apply. Establish effective and lapse dates of this eligibility category. Establish "Modifier 1" and "Modifier 2" for the certification category. At a minimum, establish a "No Eligibility" category to avoid any billing issues with any client assigned to a guarantor that is included in BBH Setup, but for whom there is no specific BBH setup. . Admit a test client into any program. Using the "Adult/Child Eligibility Category" form. Add a row of data for the test client. Select an episode to assign this data to. Select "Adult" in the "Adult or Child" field. Enter a Start date and an End Date. Select a "Certification Category". Using the "Financial Eligibility" form. Assign the test client to a guarantor. Select a guarantor selected in the "BBH Setup" form. Be sure to fill out all required fields. Populate the "Social Security Number" and "Subscriber Policy" fields. Using the "Diagnosis" form. Add diagnosis data for the test client. Using "Client Charge Input" form. Enter in at least one service. Be sure to use a service code that is specified in the "BBH Setup" form. Using the "Close Charges" form. Close charges for the test client. Steps Using the "Electronic Billing" form. Generate an 837 Professional file that includes the BBH covered guarantor, service and program. Validate the modifiers in the SV1 segment, where the first modifier is equal to Modifier 1 from the appropriate certification category as set up in "BBH Defaults" form. Also, validate the modifiers in the SV1 segment, where the last modifier is equal to Modifier 2 from the appropriate certification category as set up in "BBH Defaults" form. Using the "BBH Setup" form. Edit an existing row to add a value to the "First Modifier" and for the "Last Modifier". Using the "Electronic Billing" form. Generate an 837 Professional file that includes the BBH covered guarantor, service and program. Validate the modifiers in the SV1 segment, where the first modifier is equal to a modifier from the "First Position Modifiers" field from the appropriate certification category as set up in "BBH Defaults" form. Validate the modifiers in the SV1 segment, where the last modifier is equal to a modifier from the "Last Position Modifiers" field from the appropriate certification category as set up in "BBH Defaults" form. Open the "Registry Settings" form. Disable the registry setting "Enable BBH Service Modifiers" by setting it to "N" for "No". Open the "Electronic Billing" form. Generate an 837 Professional file for the client and service created for this test. Validate there are no modifiers from any "BBH Setup" in the SV1 segment. Scenario 2: HCFA 1500 - BBH Modifiers Specific Setup: Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Give the user access to the "BBH Setup" form and the "Adult/Child Eligibility Category" form. Refresh menus. Open the "BBH Setup" form. Select the "Guarantor(s)" to include.in BBH processing by selecting them in the "Avatar Guarantors for BBH". Select any service codes desired to be excluded from BBH processing. Select any programs to excluded from BBH processing. Navigate to the "Certification Category Setup" section and enter all certification categories that apply. Establish effective and lapse dates of this eligibility category. Establish "Modifier 1" and "Modifier 2" for the certification category. At a minimum, establish a "No Eligibility" category to avoid any billing issues with any client assigned to a guarantor that is included in BBH Setup, but for whom there is no specific BBH setup. . Admit a test client into any program. Using the "Adult/Child Eligibility Category" form. Add a row of data for the test client. Select an episode to assign this data to. Select "Adult" in the "Adult or Child" field. Enter a Start date and an End Date. Select a "Certification Category". Repeat these steps to enter all desired adult/child certification categories needed for testing. Using the "Financial Eligibility" form. Assign the test client to a guarantor. Select a guarantor selected in the "BBH Setup" form. Be sure to fill out all required fields. Populate the "Social Security Number" and "Subscriber Policy" fields. Using the "Diagnosis" form. Add diagnosis data for the test client. Using "Client Charge Input" form. Enter in at least one service. Be sure to use a service code that is specified in the "BBH Setup" form. Using the "Close Charges" form. Close charges for the test client. Steps Using the "Print Bill form. Generate a printed bill that includes the BBH covered guarantor, service and program. Validate the modifiers in the service row, where the first modifier is equal to Modifier 1 from the appropriate certification category as set up in "BBH Defaults" form. Also, validate the modifiers in the service row where the last modifier is equal to Modifier 2 from the appropriate certification category as set up in "BBH Defaults" form. Using the "BBH Setup" form. Edit an existing row to add a value to the "First Modifier" and for the "Last Modifier". Using the "Print Bill" form. Generate a printed bill that includes the BBH covered guarantor, service and program. Validate the modifiers in the service row, where the first modifier is equal to a modifier from the "First Position Modifiers" field from the appropriate certification category as set up in "BBH Defaults" form. Validate the modifiers in the service row, where the last modifier is equal to a modifier from the "Last Position Modifiers" field from the appropriate certification category as set up in "BBH Defaults" form. Open the "Registry Settings" form. Disable the registry setting "Enable BBH Service Modifiers" by setting it to "N". Open the "Print Bill" form. Generate a printed bill for the client and service created for this test. Validate there are no modifiers from any "BBH Setup" in the service row. Scenario 3: Progress Notes - BBH Modifiers Specific Setup: Open the "Registry Settings" form. Enable the registry setting "Enable BBH Service Modifiers". Open the "User Definition" form. Give the user access to the "BBH Setup" form and the "Adult/Child Eligibility Category" form. Refresh menus. Open the "BBH Setup" form. Select the "Guarantor(s)" to include.in BBH processing by selecting them in the "Avatar Guarantors for BBH". Select any service codes desired to be excluded from BBH processing. Select any programs to excluded from BBH processing. Navigate to the "Certification Category Setup" section and enter all certification categories that apply. Establish effective and lapse dates of this eligibility category. Establish "Modifier 1" and "Modifier 2" for the certification category. At a minimum, establish a "No Eligibility" category to avoid any billing issues with any client assigned to a guarantor that is included in BBH Setup, but for whom there is no specific BBH setup. . Admit a test client into any program. Using the "Adult/Child Eligibility Category" form. Add a row of data for the test client. Select an episode to assign this data to. Select "Adult" in the "Adult or Child" field. Enter a Start date and an End Date. Select a "Certification Category". Steps Open the desired progress note form. Create a progress note for a New Service. Be sure the service chosen is set to be included in BBH processing by including the service code in the "Select Service Code(s) That Progress Notes Cannot Be Entered For With this Category". Finalize the progress note. Filing will be prevented because the service code is excluded. Open the "Registry Settings" form. Disable the registry setting "Enable BBH Service Modifiers. Open the desired progress note form. Create a progress note for a New Service. Be sure the service chosen is set to be included in BBH processing by including the service code in the "Select Service Code(s) That Progress Notes Cannot Be Entered For With this Category". Finalize the progress note. Filing will be permitted as the BBH Service Modifiers logic isn't enabled.	Topics • 837 Professional • NX • HCFA-1500 • Progress Notes
Update 74 Summary \| Details Client Name display Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: MPI Search Scenario 1: Admission - Admit a new client when MPI is enabled and the 'Client Demographics - Additional Fields' registry setting does not include "Detailed Client Name" Specific Setup: 'Master Patient Index' must be enabled and configured. Please note: this must be done by a Netsmart Representative. The 'Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields' does not include "3 - Detailed Client Name". User must have access to the 'SYSTEM.patient_demographic_history' and 'SYSTEM.patient_current_demographics' SQL tables. Steps Access the 'Admission' form. Validate the 'Client Search' dialog is displayed. Enter "Nonsense" in the 'Last Name' field. Enter "Nonsense" in the 'First Name' field. Select the desired value in the 'Sex' field. Click [Search] and [New Client]. Validate the 'Master Patient Index Search' dialog is displayed. Enter "NONSENSE" in the 'Last Name' field. Click [Search MPI] and [Add New Client]. Validate the 'Admission' form is displayed. Validate the 'Client Name' field contains "NONSENSE,NONSENSE". Enter "NAME,TEST" in the 'Client Name' field. Enter the desired date in the 'Preadmit/Admission Date' field. Enter the desired time in the 'Preadmit/Admission Time' field. Select the desired value in the 'Program' field. Select the desired value in the 'Type Of Admission' field. Populate any other required and desired fields. Click [Submit]. Validate the 'Recent Clients' field contains "TEST NAME". Access the 'Update Client Data' form. Validate the 'Client Header' contains "TEST NAME". Validate the 'Client Name' field contains "NAME,TEST". Close the form. Access Crystal Reports or other SQL Reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Be sure to include the 'patient_name', 'patient_name_first', 'patient_name_last' fields. Navigate to the row for the client admitted in the previous steps. Validate the 'patient_name' field contains "NAME,TEST". Validate the 'patient_name_last' field contains "NAME". Validate the 'patient_name_first' field contains "TEST". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Be sure to include the 'patient_name', 'patient_name_first', 'patient_name_last' fields. Navigate to the row for the client admitted in the previous steps. Validate the 'patient_name' field contains "NAME,TEST". Validate the 'patient_name_last' field contains "NAME". Validate the 'patient_name_first' field contains "TEST". Close the report. Scenario 2: Admission - Admit a new client when the 'Client Demographics - Additional Fields' registry setting does not include "Detailed Client Name" Specific Setup: The 'Avatar PM->Client Information->Client Demographics->->->Client Demographics - Additional Fields' does not include "3 - Detailed Client Name". User must have access to the 'SYSTEM.patient_demographic_history' and 'SYSTEM.patient_current_demographics' SQL tables. Steps Access the 'Admission' form. Validate the 'Client Search' dialog is displayed. Enter "Nonsense" in the 'Last Name' field. Enter "Nonsense" in the 'First Name' field. Select the desired value in the 'Sex' field. Click [Search], [New Client], and [Yes]. Validate the 'Admission' form is displayed. Validate the 'Client Name' field contains "NONSENSE,NONSENSE". Enter "NAME,TEST" in the 'Client Name' field. Enter the desired date in the 'Preadmit/Admission Date' field. Enter the desired time in the 'Preadmit/Admission Time' field. Select the desired value in the 'Program' field. Select the desired value in the 'Type Of Admission' field. Populate any other required and desired fields. Click [Submit]. Validate the 'Recent Clients' field contains "TEST NAME". Access the 'Update Client Data' form. Validate the 'Client Header' contains "TEST NAME". Validate the 'Client Name' field contains "NAME,TEST". Close the form. Access Crystal Reports or other SQL Reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Be sure to include the 'patient_name', 'patient_name_first', 'patient_name_last' fields. Navigate to the row for the client admitted in the previous steps. Validate the 'patient_name' field contains "NAME,TEST". Validate the 'patient_name_last' field contains "NAME". Validate the 'patient_name_first' field contains "TEST". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Be sure to include the 'patient_name', 'patient_name_first', 'patient_name_last' fields. Navigate to the row for the client admitted in the previous steps. Validate the 'patient_name' field contains "NAME,TEST". Validate the 'patient_name_last' field contains "NAME". Validate the 'patient_name_first' field contains "TEST". Close the report.	Topics • Registry Settings • Admission
Update 75 Summary \| Details Chart View - Consent For Access Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Consent For Access Scenario 1: Consent For Access - Validating chart view - Add/edit consent for access Specific Setup: Have the 'Consent For Access' form added to a user's 'Chart View'. Have client with a record filed in form 'Consent For Access' form. Steps Open the ‘Consent For Access’ form. Select the ‘External Network’ section. Click [Add A New Item]. Select ‘Network’ in the ‘Consent For’ field. Select desired network in the ‘Network’ dropdown. Select desired value in the 'Consent to Opt In/ Opt Out' field. Set ‘Start Date’ to desired date. Select the ‘Referral’ section. Click [Add A New Item]. Select desired value in the 'Provider' field. Select ‘Network’ in the ‘Consent For’ field. Select desired value in the 'Consent to Opt In/ Opt Out' field. Set ‘Start Date’ to desired date. Click [Submit]. Open the ‘Consent For Access’ form. Validate the data displays as it was entered. Select the client that has a record filed in the 'Consent For Access' form. Open 'Chart View' for that client. Validate a 'Consent For Access' form is displayed in the left pane of the chart view. Click on the 'Consent For Access' form name. Validate all the information entered in the 'External Network' and 'Referral' tab of the 'Consent For Access' form are displayed correctly. Open the ‘Consent For Access’ form. Select the ‘External Network’ section. Add/update information for the client. Select the ‘Referral’ section. Add/update information for the client. Click [Submit]. Open 'Chart View' for that client. Validate a 'Consent For Access' form is displayed in the left pane of the chart view. Click on the 'Consent For Access' form name. Validate all the information entered / updated in the 'External Network' and 'Referral' tab of the 'Consent For Access' form are displayed correctly.	Topics • Consent for Access • NX
Update 76 Summary \| Details Client Search - 'Alternate Lookup By Room' registry setting Scenario 1: Validate the 'Alternate Lookup By Room' registry setting Specific Setup: Two clients (Client A & Client B) must be admitted into inpatient episodes in the same room (Room A). The registry setting "Include Active Room Number with Client" is set to "1". Steps Access the 'Registry Settings' form. Enter "Alternate Lookup By Room" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains: Avatar PM->Client Information->Client Lookup->->->Alternate Lookup By Room. Validate the 'Registry Setting Detail' field contains: Selecting 'Y' will add an alternate search for clients by room number in the My Clients widget and Client Search. This must be an exact match and will look at the 'Include Active Room Number With Client Name' registry setting to potentially parse the room number. Select 'N' to disable this functionality. Enter "Y" in the 'Registry Setting Value' field. Click [Submit] and close the form. Search for "Room A" in the 'Search Clients' field. Validate both "Client A" and "Client B" are displayed. Access the 'Progress Notes (Group and Individual)' form. Enter "Room A" in the 'Select Client' field. Validate "Client A" and "Client B" are displayed. Close the form. Access the 'Client Ledger' form. Enter "Room A" in the 'Client ID' field. Validate "Client A" and "Client B" are displayed. Close the form. Access the 'Account Registration' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are displayed. Click [Cancel]. Access the 'Service Authorization' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are displayed. Click [Cancel]. Access the 'Registry Settings' form. Enter "Alternate Lookup By Room" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains: Avatar PM->Client Information->Client Lookup->->->Alternate Lookup By Room. Enter "N" in the 'Registry Setting Value' field. Click [Submit] and close the form. Search for "Room A" in the 'Search Clients' field. Validate "Client A" and "Client B" are not displayed. Access the 'Progress Notes (Group and Individual)' form. Enter "Room A" in the 'Select Client' field. Validate "Client A" and "Client B" are not displayed. Close the form. Access the 'Client Ledger' form. Enter "Room A" in the 'Client ID' field. Validate "Client A" and "Client B" are not displayed. Close the form. Access the 'Account Registration' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are not displayed. Click [Cancel]. Access the 'Service Authorization' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are not displayed. Click [Cancel].	Topics • Registry Settings • Client Search
Update 77 Summary \| Details ‘Inhibit Billing By Service’ and ‘File Import' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Inhibit Billing By Service Inhibited Services For Billing Report Financial Eligibility File Import Electronic Billing Client Inhibited Services (Service Date Less Than 1 Year Old) Scenario 1: Inhibited Services For Billing Report Specific Setup: Inhibit Billing by Service has been used to inhibit at least one service for a client. Note the field values. Steps Open ‘Inhibited Services For Billing Report’. Process the report for the client. Validate that the correct data displays in the report. Close the report. Close the form. Scenario 2: File Import - 'Client Charge Input' file type - Render a service to the client that is marked as a billing inhibited Specific Setup: Registry Settings: The registry setting 'Import File Delimiter' is set to desired value. Home View: The 'CLIENT INHIBITED FROM BILLING (SERVICE DATE LESS THAN 1 YEAR)' widget available on the home view. Program Maintenance: Identify an existing program code / name. Note the program code. Admission: An existing client is identified. Note the client id/name, admission date, admission program code/name. A 'Client Charge Input' import file is created to render a service to the client and mark that service billing inhibited. The predefined client, episode number, practitioner id, service code, admission program and cost of the service are entered in the file. Steps Open the 'File Import' form. Select the 'Client Charge Input' from the 'File Type' field. Upload the file Import file created in the setup section to mark a service as a billing inhibited. Compile the file. Verify that the file compiles successfully. Select the 'Print File' option. Review the information on compile report. Verify that all the information entered through the 'File Import' file displayed correctly in the specific field. Post the compiled file. Verify that the file posted successfully. Open the 'Crystal Report' or any other SQL data viewer. Run the query against SYSTEM.billing_tx_history table. Verify the 'billable_code' displays 'X'. Run the query against SYSTEM.inhibit_billing SQL table. Verify the inhibited service record is added in this table. Close the Crystal Report or the SQL Data Viewer. Locate to the 'CLIENT INHIBITED SERVICES (SERVICE DATE LESS THAN 1 YEAR OLD)' WIDGET. Verify the 'Client Name' and 'Episode' column displays the client name and episode for the client for whom the inhibited service is rendered through file import. Open the 'Inhibited Services For Billing report' form. Enter desired date in the 'Start Date' field. Enter desired date in the 'End Date' field. Select desired client in the 'Client' field. Click [Process Report]. Verify the inhibited service record displays in the report correctly. Close the report.	Topics • Inhibit Billing • File Import
Update 78 Summary \| Details Avatar PM - Support for Mobile CareGiver+ Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Alternate Addresses Scenario 1: Client Alternate Addresses - Form Validations Specific Setup: The 'Enable Client Alternate Addresses' registry setting must be set to "Y". A client is admitted in an existing episode (Client A). Steps Access the 'Client Alternate Addresses' form. Select "Client A" in the 'Client' field. Select "Add" in the 'Add/Edit' field. Enter the desired value in the 'Description' field. Enter the desired date in the 'Address Start Date' field. Enter the desired date in the 'Address End Date' field. Enter the desired value in the 'Address Line 1' field. Enter the desired value in the 'Address Line 2' field. Enter the desired value in the 'Zip' field. Enter the desired value in the 'City' field. Select the desired value in the 'State' field. Enter the desired value in the 'Contact Name field. Enter the desired value in the 'Contact Phone' field. Enter the desired value in the 'Address Notes' field. Select "Yes" in the 'Enabled' field. Click [File]. Validate a message is displayed stating: Saved. Click [OK]. Validate the 'Client' field contains "Client A". Select "Edit" in the 'Add/Edit' field. Validate the 'Select Existing Address' field contains the alternate address filed in the previous steps with the 'Address Start Date', 'Address End Date', and 'Description'. Select the address filed in the previous steps in the 'Select Existing Address' field. Validate all previously filed data is displayed. Close the form. Access Crystal Reports or other SQL Reporting Tool. Select the PM namespace. Create a report using the 'SYSTEM.client_alternate_address' SQL table. Validate there is a row for "Client A" will all previously filed data. Close the report. Scenario 2: Validate the 'Enable Alternate Client Addresses' registry setting Steps Access the 'Registry Settings' form. Enter "Client Alternate Addresses" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains "Avatar PM->Client Management->Client Information->->->Enable Client Alternate Addresses". Validate the 'Registry Setting Detail' field contains "Selecting 'Y' will add the 'Client Alternate Addresses' form to the menu. Selecting 'N' will remove the form from the menu." Validate the 'Registry Setting Value' field contains "N" by default. Enter "Y" in the 'Registry Setting Value' field. Click [Submit] and close the form. Access the 'User Definition' form. Select the logged in user in the 'Select User' field. Select the "Forms and Tables" section. Click [Select Forms for User Access]. Validate the 'Client Alternate Addresses' form is available for selection under "Avatar PM". Select read/write permissions for the form. Click [OK] and [Submit]. Refresh forms. Access the 'Client Alternate Addresses' form. Validate the form displays as expected. Close the form. Access the 'Registry Settings' form. Enter "Client Alternate Addresses" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains "Avatar PM->Client Management->Client Information->->->Enable Client Alternate Addresses". Enter "N" in the 'Registry Setting Value' field. Click [Submit] and close the form. Refresh forms. Validate the 'Search Forms' search no longer returns the 'Client Alternate Addresses' form since disabling the registry setting removes the form from the menu. Scenario 3: Dictionary Update - Validate the 'Location' dictionary Steps Access the 'Dictionary Update' form. Select "Client" in the 'File' field. Select "Data Element Number" in the 'Data Element' field. Select "(10006) Location" in the 'Data Element' field. Enter the desired value in the 'Dictionary Code' field. Enter the desired value in the 'Dictionary Value' field. Validate the 'Extended Dictionary Data Element' field contains "(587) Place Of Service (Mobile CareGiver+)". Select "(587) Place Of Service (Mobile CareGiver+)" in the 'Extended Dictionary Data Element' field. Select the desired value in the 'Extended Dictionary Value (Single Dictionary)' field. Click [Apply Changes] & Click [OK]. Select the "Print Dictionary" section. Select "Client" in the 'File' field. Select "Data Element Number" in the 'Data Element' field. Select "(587) Place Of Service (Mobile CareGiver+)" in the 'Data Element' field. Click [Print Dictionary]. Validate the location dictionary is displayed with the place of service filed in the previous steps. Click [Close] and close the form.	Topics • Registry Settings • Client Alternate Addresses • Dictionary
Update 79 Summary \| Details 837 Billing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Electronic Billing Spreadsheet Remittance Posting Scenario 1: 837 Institutional Bill - - Running a bill for the PPS guarantor when the services are transferred to the PPS guarantor Specific Setup: Client A: Has closed services that will bill to a primary guarantor that is not a PPS Guarantor. The client’s secondary guarantor is a PPS Guarantor. Crete Interim Billing Batch File is used to create a batch to use in billing. Steps Open an 'Electronic Billing' form. Compile a Claimed 837 Institutional using the interim billing batch for the primary guarantor. Open the 'Spreadsheet Remittance Posting' for the client. Post a transfer service from the primary guarantor to the PPS guarantor. Open an 'Electronic Billing' form. Run an 837-Institutional bill for the PPS guarantor and the program. Fill out the date of service fields with the first date of service and the last date of service for the client's episode. Process the EB837 billing. Verify the bill compiles successfully. Verify that the correct services are contained in the dump file. Close the form.	Topics • 837 Institutional • NX
Update 81 Summary \| Details File Import - Electronic Re-Billing Service Assignment Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Electronic Re-Billing Service Assignment Scenario 1: File Import - Verification of 'Electronic Re-Billing Service Assignment' file type import, 'Add' record Specific Setup: Previously generated bills containing one or more valid claim(s). 'Electronic Re-Billing Service Assignment' File Import file containing one or valid import rows for 'Add' record type (value 'ADD' in segment 4). Note - Values '3' and '4' for 'Service Inclusion/Exclusion Default' (segment 5) are only allowed where Registry Setting 'Multiple Claim Original Reference Number/Claim Submission Reason Code' is enabled. Note - Allowed values for ' Claim Submission Reason Code' (segment 8) in import file may be restricted based on Registry Setting 'Claim Submission Reason Codes'. Note - Allowed values for 'Claim Original Reference Number' (segment 9) in import file may be required based on Registry Setting 'Require Claim Original Reference Number'. Steps Open 'File Import' form. Select File Type 'Electronic Re-Billing Service Assignment'. Click 'Process Action' button. Select Avatar Cal-PM 'Electronic Re-Billing Service Assignment' import file and click 'Open' button. Select 'Compile/Validate File' in 'Action' field. Select loaded import file and click 'Process Action' button. Ensure that 'Compile/Validate File' action completes. Select 'Print File' in 'Action' field. Select compiled import file and click 'Process Action' button. In 'Electronic Re-Billing Service Assignment File Import Report', ensure that all valid import row(s) are included in report results, with values from import file. Select 'Post File' in 'Action' field. Select compiled import file and click 'Process Action' button. Ensure that 'Post File' action completes. Open 'Electronic Re-Billing Service Assignment' form. Enter 'Client ID' and/or 'Claim Number' value(s) from 'Electronic Re-Billing Service Assignment' import file. Click 'Display Re-Bill Information' button. In 'Electronic Re-Billing Service Assignment Report', ensure that all re-billing records/data filed via 'File Import' are included in report results, with values from import file. In 'Electronic Re-Billing Service Assignment Report', ensure that if 'Service Inclusion/Exclusion Default' field/segment in import file is set to '1' ('Include All'), '3' ('Include All Assigned Services for Re-bill') or '4' ('Include all Un-Assigned Services For Re-Bill'), all services from claim (or assigned/unassigned services from claim) are selected/filed for re-billing inclusion. In 'Electronic Re-Billing Service Assignment Report', ensure that if 'Service Inclusion/Exclusion Default' field/segment in import file is set to '2' ('Exclude All'), only service IDs identified in import file are selected/filed for re-billing inclusion with claim. In 'Electronic Re-Billing Service Assignment Report', ensure that fields are filed with data values from import file ('Billing Form', 'Claim Submission Reason Code', 'Claim Original Reference Number'). In 'Electronic Re-Billing Service Assignment Report', ensure that if 'Claim Submission Reason Code' segment/value is not included in import file row(s), value '6' ('Corrected Adjustment of Prior Claim') is filed as default. In 'Electronic Re-Billing Service Assignment Report', ensure that if 'Add' type record is filed via 'File Import' where an unbilled 'Electronic Re-Billing Service Assignment' entry already exists, the data from most recent file import is present/replaces previously filed entries. Scenario 2: File Import - Verification of 'Electronic Re-Billing Service Assignment' file type import, 'Delete' record Specific Setup: Previously generated bills containing one or more valid claim(s). Previously filed and unbilled 'Electronic Re-Billing Service Assignment' information for one or more valid claim(s)/service(s). 'Electronic Re-Billing Service Assignment' File Import file containing one or valid import rows for 'Delete' record type (value 'DEL' in segment 4). Steps Open 'File Import' form. Select File Type 'Electronic Re-Billing Service Assignment'. Click 'Process Action' button. Select 'Electronic Re-Billing Service Assignment' import file and click 'Open' button. Select 'Compile/Validate File' in 'Action' field. Select loaded import file and click 'Process Action' button. Ensure that 'Compile/Validate File' action completes. Select 'Print File' in 'Action' field. Select compiled import file and click 'Process Action' button. In 'Electronic Re-Billing Service Assignment File Import Report', ensure that all valid import 'Delete' row(s) are included in report results, with values from import file. Select 'Post File' in 'Action' field. Select compiled import file and click 'Process Action' button. Ensure that 'Post File' action completes. Open 'Electronic Re-Billing Service Assignment' form. Enter 'Client ID' and/or 'Claim Number' value(s) from 'Electronic Re-Billing Service Assignment' import file. Click 'Display Re-Bill Information' button. In 'Electronic Re-Billing Service Assignment Report', ensure that all re-billing records/data deleted via 'File Import' are deleted/not present in report results.	Topics • File Import • Re-Bill
Update 83 Summary \| Details PM - CPT Codes Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CPT Code Definition (PM) Scenario 1: 'CPT Code Definition' - Verification of American Medical Association-Provided CPT Code Values Steps Open 'CPT Code Definition' form. Select 'Edit' action in 'Add/Edit/Delete CPT Code' field. In 'CPT Service Code' field, enter search term using CPT Code Description (AMA 'Consumer Descriptor' term) or CPT Code. Ensure 'CPT Service Code' field search results include American Medical Association-provided CPT Service Code(s) for search term/code entered. Select CPT Code from 'CPT Service Code' search results. Confirm value in 'CPT Code Description' field for selected CPT Service Code (from AMA 'Consumer Descriptor' term). Note - location of AMA copyright form field/labels may be affected by any Form Designer changes present for form Scenario 2: 'CPT Code Definition' - Verification of American Medical Association Trademark/Copyright Notice Display Steps Open 'CPT Code Definition' form. Verify the 'CPT Service Code' field in form contains the AMA Trademark 'CPT® Codes' label. Verify the following AMA copyright notice is displayed at the bottom of the form: 'CPT copyright 2021 American Medical Association. All rights reserved.' Note - location of AMA copyright form field/labels may be affected by any Form Designer changes present for form	Topics • CPT Codes
Update 84 Summary \| Details Roll-up Services Definition Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Roll-Up Services Definition Scenario 1: Roll-Up Services Definition - Form / Field Validation Specific Setup: Many fields on the 'Roll-Up Services Definition' form are controlled by registry settings. To review the fields selected by your agency search 'Roll-Up' in the registry setting form. Service Codes: Service Code 1: Roll-Up service code. 'Type of 'Fee' = desired value. Minutes Per Unit = desired value. Note the service code/value, Minutes Per Unit and 'Covered Charge Category' for the service code. Service Code 2: Component service code. 'Type of 'Fee' = desired value, Minutes Per Unit = desired value. Note the service. Service Fee/Cross Reference Maintenance: All service codes have a 'Fee', 'UB-04 Revenue Code' and/or 'CPT-4 / HCPCS Code' defined in 'Service Fee/Cross Reference Maintenance'. Note the fees. Steps Open 'Roll-Up Services Definition'. Select 'Add' in 'Add/Edit/Delete Roll-Up Services Definition'. Enter a 'Roll-Up Description'. Select a 'Roll-Up Service'. Select desired 'Component Services'. Select desired 'Required Component Service(s) for Roll-Up to Occur'. Select desired 'Component Service Date Rules'. Select desired value in 'Is This Roll-Up Services Dependent On Units, Duration, Or None'. Select desired 'Date Of Service For Roll-Up Service'. Enter data in remaining required fields, noting the values. Validate the 'Service Start Time For Roll-Up Service' field is available with the 'Time Of First Component Service' option to the 'Roll-Up Services Definition' form. Verify the 'Time Of First Component Service' option is unchecked in the 'Service Start Time For Roll-Up Service' field. Select the 'Time Of First Component Service' in the Service Start Time For Roll-Up Service' field. Click [Submit]. Click [Yes] to return to the form. Select 'Edit' in 'Add/Edit/Delete Roll-Up Services Definition'. Select the same definition. Verify the fields retained all the values. Click [Submit]. Click [No] to return to the form.	Topics • Roll-Up Services Definition
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 Financial Eligibility 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 Open the "System Task Scheduler" form: In the "Schedules" field, select the quick billing group definition task created in the 'Quick Billing Group Definition' from the list. Select a recurrence type pattern from the "Recurrence Pattern" field. For example "Daily". Populate the "Task Occurrence Sequence". For example "1". Populate the "Start by" field. Populate the "Start Time" field. Click [Schedule Task] Wait until after the date and time that the task is scheduled to execute. Open the 'Client Ledger' form: Select desired client. Select "All Episode" from the 'Claim/Episode/All Episode' field. Select "Simple" from the 'Ledger Type' field. Select desired date in the 'From Date' and 'To Date' fields to include the service date range for the client. Click [Process]. 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 Open the 'Client Merge' form. Select desired client as a source client. Select desired client as a target client. Populate all other required fields. Verify the source client merged in to the target client successfully. Open the 'Client Ledger' for the target client. Verify all the merged services distributed correctly to the correct guarantor. Open the ‘Quick Billing’ form. Set the field ‘Add New Or Edit Existing Quick Billing Batch’ to "Add New". Set the field ‘First Date Of Service To Include’ to desired date based on the services rendered to the client in the setup section. Set the field ‘Last Date Of Service To Include’ to desired date based on the services rendered to the client in the setup section. Set the field ‘Billing Rule Group To Execute’ to desired rule group created in the setup section. 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. Set the field ‘Date Of Claim’ to desired date. Submit the form. Verify the 'Compile Complete' message. The message also contains the quick billing batch number, Interim Billing Batch number and contractual adjustment posted notification. Click [OK]. Click [NO] to 'Form Return' message. Open the 'Client Ledger' form. Select desired client. Select 'All Episode' from the 'Claim/Episode/All Episode' field. Select 'Simple' from the 'Ledger Type' field. Select desired date in the 'From Date' and 'To Date' fields to include the service date range for the client. Click [Process]. 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 Open the 'Contractual Allowance (Inpatient)' form. Select 'Compile' for the 'Compile, View or Post' field. Enter the month and year for the services rendered to the client. Fill out the remaining required fields. Click [Process]. Verify the services displayed correctly in the report with the expected contractual adjustments. Select 'View' from the 'Compile, View or Post' field. Click [Process]. Verify the services to be posted displayed correctly in the report with the expected contractual adjustments. Open the 'Change MR#' form. Select a client set up in the setup section. Click [Assign MR#]. Verify the 'New Client ID#' field contains different id than the previous one. Note the client id. Click [Submit]. Verify the form submits successfully. Open the 'Contractual Allowance (Inpatient)' form. Select 'Post' from the 'Compile, View or Post' field. Set the 'Month/Year To Run Report For' field to desired month and year such that it covers the services for the client. Enter the 'Posting Date'. Select all other required fields. Click [Process]. Verify the services posted displayed correctly in the report with the expected contractual adjustments for the new client. Open 'Client Ledger' form. Verify the contractual adjustments are correctly posted for the services that are included in the batch. 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 Open the 'Contractual Allowance (Inpatient)' form. Select 'Compile' for the 'Compile, View or Post' field. Enter the month and year for the services rendered to the client. Fill out the remaining required fields. Click [Process]. Verify the services displayed correctly in the report with the expected contractual adjustments. Select 'View' from the 'Compile, View or Post' field. Click [Process]. Verify the services to be posted displayed correctly in the report with the expected contractual adjustments. Delete all the services rendered to the client. Delete all the movements using 'Delete Last Movement' form. Open the 'Client Delete' form. Delete the client. Open the 'Contractual Allowance (Inpatient)' form. Select 'Post' from the 'Compile, View or Post' field. Set the 'Month/Year To Run Report For' field to desired month and year such that it covers the services for the client. Enter the 'Posting Date'. Select all other required fields. Click [Process]. Verify the services posted displayed correctly in the report with the expected contractual adjustments for the new client. Open 'Client Ledger' form. 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. 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 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 Open the 'Functional or Implementation Acknowledgement (997/999)' form. Load/ Compile the 999 file. Verify the file loads successfully. Compile the recently loaded file. 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 Open the 'Eligibility Inquiry (270) Request' form. Create a generic request for a client and a guarantor. Make sure to use the same client/guarantor. Click [Select Pending Inquiry]. Select the inquiry which is added in above steps. Click [Delete Inquiry]. Review the pending inquiry again. 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 Financial Eligibility Electronic Billing 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 Open the 'Electronic Billing' form. Compile the 837 Professional bill for the interim billing batch created in the setup section. Verify the file compiles successfully. Review the 837 file dump file. Locate the 2400-SV1 segment. 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. 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. Open the 'Individual Cash Posting' form. Transfer the service from the primary guarantor to secondary guarantor. Submit the form. Open the 'Client Ledger' form. Verify the service correctly transferred to the secondary guarantor. Close the form. Open the 'Individual Cash Posting' form. Transfer all the service(es) from the secondary guarantor to the primary guarantor. Submit the form. Open the 'Client Ledger' form. Verify the service correctly transferred back to the secondary guarantor. Close the form. Open the 'Electronic Billing' form. Compile the 837 Professional bill again for the primary guarantor. Verify the bill compiles successfully. Review the 837 file dump file. Locate the 2400-SV1 segment. 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. 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. 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 86 Summary \| Details Guarantor/Program Billing Defaults - CCBHC Claim Grouping Scenario 1: Guarantor/Program Billing Defaults - CCBHC Claim Grouping - Help Message Steps Open 'Guarantor/Program Billing Defaults'/ Select 'Edit Template' in 'Action'. Select the desired template in 'Select Template'. Select the '837 Professional' section. Click the help message on the 'CCBHC Claim Grouping; field. Validate that the message contains: When 'None' is selected, the PPS charge will be billed immediately with no special claims grouping. If a CCBHC component charge associated with the PPS charge is still awaiting remittance from private insurance, it will be indicated on the billing report but the PPS charge will not be inhibited for billing. When 'Same Claim: Hold PPS Charges for Remittances from Private Insurance and Group with Component Services on the Same Claim' is selected, the PPS charge will be inhibited for billing until the remittances for all CCBHC component charges are received. The PPS charge will be output to the same claim as the associated CCBHC component services, with the PPS charge listed first. Please Note: Selecting this value will also set the 'Maximum Service Information Per Claim Information (Maximum LX Per CLM)' and 'Maximum Service Information Per Claim Information For Re-Billing (Maximum LX Per CLM)' fields to a value of "1" during the 837 bill creation. When 'Separate Claims: Hold PPS Charges for Remittances from Private Insurance and Include Component Services on Separate Claims' is selected, the PPS charge will be inhibited for billing until the remittances for all CCBHC component charges are received. The PPS charge and associated CCBHC component charges will not be output to the same claim. Instead, the billing template associated to each PPS charge and CCBHC component charge will be used, making it possible for them to be output to different claims and/or billing files. Note: PPS charges are only held for remittances from private insurance when the guarantor for the associated CCBHC component charges have the Extended Dictionary Data Element 'CCBHC Billing - Exclude from check for remittance from private insurance' set to 'No'. This Extended Dictionary Data Element can be found off of the Financial Class (1000) dictionary. Click 'Return to Form'. Select the '837 Institutional' section. Click the help message on the 'CCBHC Claim Grouping; field. Validate that the message contains: When 'None' is selected, the PPS charge will be billed immediately with no special claims grouping. If a CCBHC component charge associated with the PPS charge is still awaiting remittance from private insurance, it will be indicated on the billing report but the PPS charge will not be inhibited for billing. When 'Same Claim: Hold PPS Charges for Remittances from Private Insurance and Group with Component Services on the Same Claim' is selected, the PPS charge will be inhibited for billing until the remittances for all CCBHC component charges are received. The PPS charge will be output to the same claim as the associated CCBHC component services, with the PPS charge listed first. Please Note: Selecting this value will also set the 'Maximum Service Information Per Claim Information (Maximum LX Per CLM)' and 'Maximum Service Information Per Claim Information For Re-Billing (Maximum LX Per CLM)' fields to a value of "1" during the 837 bill creation. When 'Separate Claims: Hold PPS Charges for Remittances from Private Insurance and Include Component Services on Separate Claims' is selected, the PPS charge will be inhibited for billing until the remittances for all CCBHC component charges are received. The PPS charge and associated CCBHC component charges will not be output to the same claim. Instead, the billing template associated to each PPS charge and CCBHC component charge will be used, making it possible for them to be output to different claims and/or billing files. Note: PPS charges are only held for remittances from private insurance when the guarantor for the associated CCBHC component charges have the Extended Dictionary Data Element 'CCBHC Billing - Exclude from check for remittance from private insurance' set to 'No'. This Extended Dictionary Data Element can be found off of the Financial Class (1000) dictionary. Click 'Return to Form'. Click [Discard]. Click [Yes].	Topics • 837 Professional • 837 Institutional • Guarantor / Program Billing Defaults • NX
Update 87 Summary \| Details Client Charge Input forms Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Treatment Plan Scenario 1: Client Charge Input - Treatment Plan - Intervention - Assigned Services Specific Setup: Client A: Select a client that has a ‘Treatment Plan’ with values in the ‘'Assigned Services' grid’ of the ‘Intervention’ section. The grid should contain the program and service codes at a minimum. Steps Open ‘Client Charge Input’. Create a service for Client A, with the desired service code, and a service program that differs from the treatment plan. Validate that the service program is not permitted, Change the service program to the program that is in the treatment plan. Validate that the service can be submitted. Close the form.	Topics • Treatment Plan • Recurring Client Charge Input • NX • Client Charge Input • Client Ledger
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: Electronic Billing 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 Open ‘Electronic Billing’. Using the interim batch created in setup, create an unclaimed bill for client A. Export the dump file and compare it to the previous exported dump file 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 dump file and compare it to the previous exported dump file 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 dump file and compare it to the previous exported dump file 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 ‘Electronic Billing’. Using the interim batch created above, create an unclaimed bill for client A. 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. Using the interim batch created above, create an unclaimed bill for client B. 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. Using the interim batch created above, create an unclaimed bill for the group clients. 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: Financial Eligibility Service Codes Practitioner Numbers By Guarantor And Program Electronic Billing 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 Open ‘Electronic Billing’. Create an 837 Institutional for Guarantors/Payors 2. Review the dump file to validate that the following: 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: ‘REFSYxxx-xx-xxxx, which represents the SSN with dashes. This segment will exist for Client 1 and Client 2. 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: ‘REFSYxxxxxxxxx, which represents the SSN with no dashes. There will not be a ‘REFSY segment for Client 2. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘No’, there will be no ‘K3’ segment. 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. Close the dump file. 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 Open ‘Electronic Billing’. Create an 837 Professional for Guarantors/Payors 2. Review the dump file to validate that the following: 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: ‘REFSYxxx-xx-xxxx, which represents the SSN with dashes. This segment will exist for Client 1 and Client 2. 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: ‘REFSYxxxxxxxxx, which represents the SSN with no dashes. There will not be a ‘REFSY segment for Client 2. If the billing template selection for ‘Include Race/Ethnicity/SSN in 2300-K3’ is ‘No’, there will be no ‘K3’ segment. 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. Close the dump file. Close the form.	Topics • 837 Institutional • 837 Professional
Update 93 Summary \| Details Payment Acknowledgement - Check/EFT Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Payment Acknowledgement Service Codes Scenario 1: Payment Acknowledgement - Post Payment Accounting Entry / Reverse Payment Accounting Entry Specific Setup: Registry Setting: ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ has a ‘Registry Setting Value’ of ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: Definitions exist for ‘Payment’. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Payment’ definitions will be available in the ‘Payment Acknowledgement’ form. Clients: Identify one or more clients that a balance due to a self-pay guarantor. Note the balance due amounts. Note the 'Treatment Setting' of the client's program. Steps Open ‘Payment Acknowledgement’ form. Verify that ‘Action’ defaults to ‘New’. Verify that ‘Transaction Number’ is read only. Verify that ‘Entered By’ is read only and defaults to the signed in user. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. All payment posting codes will display. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay' guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. The field is only available for ‘Self-Pay' guarantors. Enter desired value in ‘Check/EFT Date’. Note the date cannot be a future date. Enter desired value in ‘Receipt Date’. Note the date cannot be before the ‘Check/EFT Date’, Enter desired value in ‘Deposit Date’. Note the date cannot be before the ‘Check/EFT Date’ or the ‘Receipt Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Inactive dictionary codes will not display in this filed. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is 6. Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Click [Yes] to continue to Post Payment Accounting Entry section or [No] to remain in the ‘Payment Acknowledgement’ section. If [Yes] was clicked, go to step 30. If [No] was clicked, select ‘Edit or View’ in ‘Action, which will enable the ‘Payment Acknowledgement Search’ section. Enter data from the filed ‘Payment Acknowledgement’ into desired search fields. The ’Transaction Number’ and ‘Batch Number’ are specific to only one ‘Payment Acknowledgement’. The following fields may return results for more than one ‘Payment Acknowledgement’ when applicable: ‘Client’, ‘Guarantor’, ‘Amount Type’, ‘Check/EFT #’, ‘Check/EFT From Date’, ‘Check/EFT To Date’, ‘Deposit From Date’, and ‘Deposit To Date’. Click [Search]. Select the desired item in the ‘Payment Acknowledgement’ grid. Click [OK] to continue or [Cancel] to end the search. Click [OK]. The following ‘Payment Acknowledgement’ displays: Do you need to continue to Post Payment Accounting Entry? Click [Yes]. Validate that the grid is not enabled. Click [New Row] in ‘Post Payment Accounting Entry’. Validate that the grid becomes enabled. Select desired ‘Treatment Service’. It will default if filed in the ‘Payment Acknowledgement’. Select desired ‘Program’. This is from ‘Other Table Files: (5521) Program’, not a program in ‘Program Maintenance’. Select desired ‘Account’. Select desired ‘Amount’. If the amount is an even dollar amount such as $500.00, enter '500' and validate that the field displays as '500.00'. Validate that the ‘Posting Code; defaulted from the ‘Payment Acknowledgement’. Select desired ‘Posting Date’. Note the date cannot be before the ‘Check/EFT Date’, the ‘Receipt Date’ or the ‘Deposit Date’. If desired, enter a ‘Comment’. Validate that the ‘Posting Summary’ is correct. If desired, click [New Row] and repeat the steps. If desired, click [Delete Row]. A ‘Confirm Delete’ message will be displayed. Select desired value. Click [File]. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? Click [Yes]. Click the ‘Reverse’ checkbox in one row of the ‘Post Payment Accounting Entry’. Enter desired ‘Reversal Reason’. Click [Reverse]. Validate that a message is received stating: Reversal Posting Date is required. Enter a ‘Reversal Posting Date’ that is on or after the ‘Posting Date’. Click [Reverse]. Validate that a new row was added to the ‘Post Payment Accounting Entry’ grid and that it mirrors the row that was selected to reverse, except for ‘Amount’ displays in parentheses, indicating a negative amount. The ‘Comment’ for the new row will contain the ‘Reversal Reason’. Attempt to reverse the row that was previously reversed. Validate that a message is received that states: Rows selected to reverse that are already reversed: xx – where xx is the row number. If desired, add a new row to post an additional payment. Close the form. Payment Acknowledgement - Post Payment Accounting Entry Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Payment Acknowledgement Service Codes Scenario 1: Payment Acknowledgement - Post Payment Accounting Entry / Reverse Payment Accounting Entry Specific Setup: Registry Setting: ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ has a ‘Registry Setting Value’ of ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: Definitions exist for ‘Payment’. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Payment’ definitions will be available in the ‘Payment Acknowledgement’ form. Clients: Identify one or more clients that a balance due to a self-pay guarantor. Note the balance due amounts. Note the 'Treatment Setting' of the client's program. Steps Open ‘Payment Acknowledgement’ form. Verify that ‘Action’ defaults to ‘New’. Verify that ‘Transaction Number’ is read only. Verify that ‘Entered By’ is read only and defaults to the signed in user. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. All payment posting codes will display. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay' guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. The field is only available for ‘Self-Pay' guarantors. Enter desired value in ‘Check/EFT Date’. Note the date cannot be a future date. Enter desired value in ‘Receipt Date’. Note the date cannot be before the ‘Check/EFT Date’, Enter desired value in ‘Deposit Date’. Note the date cannot be before the ‘Check/EFT Date’ or the ‘Receipt Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Inactive dictionary codes will not display in this filed. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is 6. Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Click [Yes] to continue to Post Payment Accounting Entry section or [No] to remain in the ‘Payment Acknowledgement’ section. If [Yes] was clicked, go to step 30. If [No] was clicked, select ‘Edit or View’ in ‘Action, which will enable the ‘Payment Acknowledgement Search’ section. Enter data from the filed ‘Payment Acknowledgement’ into desired search fields. The ’Transaction Number’ and ‘Batch Number’ are specific to only one ‘Payment Acknowledgement’. The following fields may return results for more than one ‘Payment Acknowledgement’ when applicable: ‘Client’, ‘Guarantor’, ‘Amount Type’, ‘Check/EFT #’, ‘Check/EFT From Date’, ‘Check/EFT To Date’, ‘Deposit From Date’, and ‘Deposit To Date’. Click [Search]. Select the desired item in the ‘Payment Acknowledgement’ grid. Click [OK] to continue or [Cancel] to end the search. Click [OK]. The following ‘Payment Acknowledgement’ displays: Do you need to continue to Post Payment Accounting Entry? Click [Yes]. Validate that the grid is not enabled. Click [New Row] in ‘Post Payment Accounting Entry’. Validate that the grid becomes enabled. Select desired ‘Treatment Service’. It will default if filed in the ‘Payment Acknowledgement’. Select desired ‘Program’. This is from ‘Other Table Files: (5521) Program’, not a program in ‘Program Maintenance’. Select desired ‘Account’. Select desired ‘Amount’. If the amount is an even dollar amount such as $500.00, enter '500' and validate that the field displays as '500.00'. Validate that the ‘Posting Code; defaulted from the ‘Payment Acknowledgement’. Select desired ‘Posting Date’. Note the date cannot be before the ‘Check/EFT Date’, the ‘Receipt Date’ or the ‘Deposit Date’. If desired, enter a ‘Comment’. Validate that the ‘Posting Summary’ is correct. If desired, click [New Row] and repeat the steps. If desired, click [Delete Row]. A ‘Confirm Delete’ message will be displayed. Select desired value. Click [File]. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? Click [Yes]. Click the ‘Reverse’ checkbox in one row of the ‘Post Payment Accounting Entry’. Enter desired ‘Reversal Reason’. Click [Reverse]. Validate that a message is received stating: Reversal Posting Date is required. Enter a ‘Reversal Posting Date’ that is on or after the ‘Posting Date’. Click [Reverse]. Validate that a new row was added to the ‘Post Payment Accounting Entry’ grid and that it mirrors the row that was selected to reverse, except for ‘Amount’ displays in parentheses, indicating a negative amount. The ‘Comment’ for the new row will contain the ‘Reversal Reason’. Attempt to reverse the row that was previously reversed. Validate that a message is received that states: Rows selected to reverse that are already reversed: xx – where xx is the row number. If desired, add a new row to post an additional payment. Close the form. Payment Acknowledgement - Reverse Payment Accounting Entry Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Posting/Adjustment Codes Definition Payment Acknowledgement Service Codes Scenario 1: Payment Acknowledgement - Post Payment Accounting Entry / Reverse Payment Accounting Entry Specific Setup: Registry Setting: ‘Avatar PM->Billing->Remittance Processing->->->Enable Payment Acknowledgement’ has a ‘Registry Setting Value’ of ‘Y’. Dictionary Update: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Other Table Files: (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. Other Table Files: (9712) Payment Acknowledgement Type – extended dictionary values have been added to the locked dictionary. Posting/Adjustment Codes Definitions: Definitions exist for ‘Payment’. The definitions may have a value in the ‘Payment Acknowledgement Type’ field. All ‘Payment’ definitions will be available in the ‘Payment Acknowledgement’ form. Clients: Identify one or more clients that a balance due to a self-pay guarantor. Note the balance due amounts. Note the 'Treatment Setting' of the client's program. Steps Open ‘Payment Acknowledgement’ form. Verify that ‘Action’ defaults to ‘New’. Verify that ‘Transaction Number’ is read only. Verify that ‘Entered By’ is read only and defaults to the signed in user. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. All payment posting codes will display. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay' guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. The field is only available for ‘Self-Pay' guarantors. Enter desired value in ‘Check/EFT Date’. Note the date cannot be a future date. Enter desired value in ‘Receipt Date’. Note the date cannot be before the ‘Check/EFT Date’, Enter desired value in ‘Deposit Date’. Note the date cannot be before the ‘Check/EFT Date’ or the ‘Receipt Date’. Select desired ‘Treatment Service’. Select desired ‘Category’. Inactive dictionary codes will not display in this filed. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is 6. Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Click [Yes] to continue to Post Payment Accounting Entry section or [No] to remain in the ‘Payment Acknowledgement’ section. If [Yes] was clicked, go to step 30. If [No] was clicked, select ‘Edit or View’ in ‘Action, which will enable the ‘Payment Acknowledgement Search’ section. Enter data from the filed ‘Payment Acknowledgement’ into desired search fields. The ’Transaction Number’ and ‘Batch Number’ are specific to only one ‘Payment Acknowledgement’. The following fields may return results for more than one ‘Payment Acknowledgement’ when applicable: ‘Client’, ‘Guarantor’, ‘Amount Type’, ‘Check/EFT #’, ‘Check/EFT From Date’, ‘Check/EFT To Date’, ‘Deposit From Date’, and ‘Deposit To Date’. Click [Search]. Select the desired item in the ‘Payment Acknowledgement’ grid. Click [OK] to continue or [Cancel] to end the search. Click [OK]. The following ‘Payment Acknowledgement’ displays: Do you need to continue to Post Payment Accounting Entry? Click [Yes]. Validate that the grid is not enabled. Click [New Row] in ‘Post Payment Accounting Entry’. Validate that the grid becomes enabled. Select desired ‘Treatment Service’. It will default if filed in the ‘Payment Acknowledgement’. Select desired ‘Program’. This is from ‘Other Table Files: (5521) Program’, not a program in ‘Program Maintenance’. Select desired ‘Account’. Select desired ‘Amount’. If the amount is an even dollar amount such as $500.00, enter '500' and validate that the field displays as '500.00'. Validate that the ‘Posting Code; defaulted from the ‘Payment Acknowledgement’. Select desired ‘Posting Date’. Note the date cannot be before the ‘Check/EFT Date’, the ‘Receipt Date’ or the ‘Deposit Date’. If desired, enter a ‘Comment’. Validate that the ‘Posting Summary’ is correct. If desired, click [New Row] and repeat the steps. If desired, click [Delete Row]. A ‘Confirm Delete’ message will be displayed. Select desired value. Click [File]. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? Click [Yes]. Click the ‘Reverse’ checkbox in one row of the ‘Post Payment Accounting Entry’. Enter desired ‘Reversal Reason’. Click [Reverse]. Validate that a message is received stating: Reversal Posting Date is required. Enter a ‘Reversal Posting Date’ that is on or after the ‘Posting Date’. Click [Reverse]. Validate that a new row was added to the ‘Post Payment Accounting Entry’ grid and that it mirrors the row that was selected to reverse, except for ‘Amount’ displays in parentheses, indicating a negative amount. The ‘Comment’ for the new row will contain the ‘Reversal Reason’. Attempt to reverse the row that was previously reversed. Validate that a message is received that states: Rows selected to reverse that are already reversed: xx – where xx is the row number. If desired, add a new row to post an additional payment. Close the form.	Topics • NX • Payment Acknowledgement
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 Open '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'. 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. 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. Click [Submit]. Open 'AR Console Configuration'. Validate the 'Default Managed Care Authorization Form to Display' value. Validate the 'Include AR Data from All Sub System Codes' value. Validate the 'AR Auto Batch Number of Days Prior to Current Date to Include' value. Validate the 'Exclude Financial Class(es) from AR Console' values. Validate the 'Allow Re-bill Assignment of Paper Claims' value. Validate the 'Maximum Number of Claims to Return in Search' value. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'. Close the form. Open 'AR Console User Defaults Setup'. 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. Process the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’. Sign out and back in. Validate that the excluded financial class and the associated guarantors no longer display in the 'Accounts Receivable Console'. Validate that the tester has access to Financial Class 3 and Financial Class 4, and all associated guarantors in the 'Accounts Receivable Console'. Enter the 'Client' from 'SETUP'. Select 'No' in 'Claim Follow-Up Records Exist'. Click [Search]. Select the claim in the 'Claims with Outstanding Receivables' grid. Click [Add/Claim Follow-Up Note]. Click [OK]. Set the section to 'Claim Follow-Up Entry'. Validate the claim number in the 'Services' grid. Enter the desired value in 'Payer ICN #'. Note the value. Enter the desired value in 'Claim Submission Reason Code'. Note the value. Click [File Updates]. Set the section to 'AR List'. Select 'Yes' in 'Claim Follow-Up Records Exist'. Click [Search]. Select the claim in the 'Claims with Outstanding Receivables' grid. Click [Add/Claim Follow-Up Note]. Verify the value in 'Payer ICN #'. 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 Open ‘AR Console User Defaults Setup’. Click ‘New Row’ and add a row for the signed in user, or if the signed in user exists in a row select the row. Click ‘All’ in the following fields: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Add desired value to ‘Aged Over # Days’. Note the value. Add desired value to 'Allow 'Copy Note' from one client to another'. Click ‘New Row’ and add a row for the first additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’. Note the values of each field. Click ‘New Row’ and add a row for the second additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, ‘Aged Over # Days’ and 'Allow 'Copy Note' from one client to another'. Note the values of each field. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Validate that the following fields have every available item in the checklist selected: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Verify that ‘Aged Over # Days' contains the value entered above. Deselect one or more items in 'Financial Class(es)'. Select the row for the first additional user. Validate that the values that were submitted were retained. Select the row for the second additional user. Validate that the values that were submitted were retained. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Open the 'Account Receivable Console' widget for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Close the widget. 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 Open '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'. 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. 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. Click [Submit]. Open 'AR Console Configuration'. Validate the 'Default Managed Care Authorization Form to Display' value. Validate the 'Include AR Data from All Sub System Codes' value. Validate the 'AR Auto Batch Number of Days Prior to Current Date to Include' value. Validate the 'Exclude Financial Class(es) from AR Console' values. Validate the 'Allow Re-bill Assignment of Paper Claims' value. Validate the 'Maximum Number of Claims to Return in Search' value. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated 'AR Console Follow-Up Created'. Validate the 'Allow 'Claim Follow-Up Record Exists' filter to include system-generated '835 Remittance' notes in search results'. Close the form. Open 'AR Console User Defaults Setup'. 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. Process the ‘System Task Scheduler’, ‘Auto AR Batch Update Task’. Sign out and back in. Validate that the excluded financial class and the associated guarantors no longer display in the 'Accounts Receivable Console'. Validate that the tester has access to Financial Class 3 and Financial Class 4, and all associated guarantors in the 'Accounts Receivable Console'. Enter the 'Client' from 'SETUP'. Select 'No' in 'Claim Follow-Up Records Exist'. Click [Search]. Select the claim in the 'Claims with Outstanding Receivables' grid. Click [Add/Claim Follow-Up Note]. Click [OK]. Set the section to 'Claim Follow-Up Entry'. Validate the claim number in the 'Services' grid. Enter the desired value in 'Payer ICN #'. Note the value. Enter the desired value in 'Claim Submission Reason Code'. Note the value. Click [File Updates]. Set the section to 'AR List'. Select 'Yes' in 'Claim Follow-Up Records Exist'. Click [Search]. Select the claim in the 'Claims with Outstanding Receivables' grid. Click [Add/Claim Follow-Up Note]. Verify the value in 'Payer ICN #'. 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 Open ‘AR Console User Defaults Setup’. Click ‘New Row’ and add a row for the signed in user, or if the signed in user exists in a row select the row. Click ‘All’ in the following fields: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Add desired value to ‘Aged Over # Days’. Note the value. Add desired value to 'Allow 'Copy Note' from one client to another'. Click ‘New Row’ and add a row for the first additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, and ‘Aged Over # Days’. Note the values of each field. Click ‘New Row’ and add a row for the second additional user from ‘Setup’, or if the user exists in a row select the row. Select desired values in ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’, ‘Client Last Name Initials to be Worked’, ‘Aged Over # Days’ and 'Allow 'Copy Note' from one client to another'. Note the values of each field. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Validate that the following fields have every available item in the checklist selected: ‘Financial Class(es)’, ‘Guarantor(s)’, ‘Treatment Setting(s)’ ‘Program(s)’ and ‘Client Last Name Initials to be Worked’. Verify that ‘Aged Over # Days' contains the value entered above. Deselect one or more items in 'Financial Class(es)'. Select the row for the first additional user. Validate that the values that were submitted were retained. Select the row for the second additional user. Validate that the values that were submitted were retained. Click [Submit]. Open ‘AR Console User Defaults Setup’. Select the row for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Open the 'Account Receivable Console' widget for the signed in user. Verify that the ‘Financial Class(es)’ does not contain the deselected items. Close the widget. 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 Open the ‘Account Receivable Console’ widget. Validate that the ‘Guarantor’ field contains the selected guarantors, including the guarantor with the ‘&’ in the 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' Enter the ‘Client ID for Client A. Click [Search]. Select a minimum of two clients, and two or more claims per client, in the ‘Claims with Outstanding Receivables’ gird. Click [Add Claim Follow-Up/Note]. Validate the claim number in ‘Claim Follow-Up’ and note the client. Go to the Follow-Up Notes’ section. Validate the note created by the AR Console exists. Click [New Row]. Enter desired ‘Follow-Up Date’, ‘Comments’ and any other desired data. Click [File Updates]. Click [OK]. Select the row that was added above. Click [Copy Note]. Select the client/claim to copy the note to in ‘Copy Follow-Up Note’. Click [Save]. Select the claim number in ‘Claim Follow-Up’ that was selected in ‘Copy Follow-Up Note’. Validate that the copy note, and the note created by the AR Console exist in ‘Claim Follow-Up’. Select the ‘AR List’ section. Repeat steps 3 - 20 for Client B. 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 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 Open the ‘Account Receivable Console’ widget. Validate that the ‘Guarantor’ field contains the selected guarantors, including the guarantor with the ‘&’ in the 'Guarantor Name' & the 'Guarantor Name For Alpha Lookup' Enter the ‘Client ID for Client A. Click [Search]. Select a minimum of two clients, and two or more claims per client, in the ‘Claims with Outstanding Receivables’ gird. Click [Add Claim Follow-Up/Note]. Validate the claim number in ‘Claim Follow-Up’ and note the client. Go to the Follow-Up Notes’ section. Validate the note created by the AR Console exists. Click [New Row]. Enter desired ‘Follow-Up Date’, ‘Comments’ and any other desired data. Click [File Updates]. Click [OK]. Select the row that was added above. Click [Copy Note]. Select the client/claim to copy the note to in ‘Copy Follow-Up Note’. Click [Save]. Select the claim number in ‘Claim Follow-Up’ that was selected in ‘Copy Follow-Up Note’. Validate that the copy note, and the note created by the AR Console exist in ‘Claim Follow-Up’. Select the ‘AR List’ section. Repeat steps 3 - 20 for Client B. 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 Access the ‘AR Console’. Enter desired client in the ‘Client' search box. Select a client identified in the setup section. Click [Search]. Validate all the claims for the client are displayed in the ‘Claims with Outstanding Receivables’ grid. Select one claim row, noting the claim number. Validate the 'Claim Service Information' table displays all the services of the client / claim selected. Click [Add Claim Follow-Up/Notes]. Validate the user is navigated to the 'Claim Follow-Up Entry' tab. Validate the 'Client' drop down field is populated with the selected client. Validate that ‘Claim Follow-Up’ drop down field contains the selected claim number. Validate the 'Services' table displays all the services attached to the client/claim selected. Validate the 'Follow-Up Notes' table contains any follow-up note created for the client/claim selected. Click [New row]. Add another follow-up note for the client/claim. Click [File Updates]. Go back to 'AR List' tab. Click [Reset Defaults]. Enter desired client in the ‘Client' search box. Select a client identified in the setup section. Click [Search]. Validate all the claims for the client are displayed in the ‘Claims with Outstanding Receivables’ grid. Select one claim row, noting the claim number. Validate the 'Claim Service Information' table displays all the services of the client / claim selected. Click [Add Claim Follow-Up/Notes]. Validate the user is navigated to the 'Claim Follow-Up Entry' tab. Validate the 'Client' drop down field is populated with the selected client. Validate that ‘Claim Follow-Up’ drop down field contains the selected claim number. Validate the 'Services' table displays all the services attached to the client/claim selected. 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 Access the ‘Accounts Receivable Console’ widget. Enter a value in ‘Claim #’ and/or ‘Client’. Select desired value in ‘Claim Follow-Up Record Exists’. Click [Search]. Validate that the appropriate claims are returned in the ‘Claims with Outstanding Receivables’ grid based on the information provided in ‘Setup’. Select one or more claims in the grid. Click [Add Claim Follow-Up Notes]. Validate the claim(s) information in the ‘Claim Follow-Up Entry’ section. Go to the ‘Follow-Up Notes’ section. Validate existing follow-up notes. If desired create a new row and add a new note. Click [File Updates]. Return to the ‘AR List’ section. Change the value in’ Claim Follow-Up Record Exists’ and repeat the steps above.	Topics • Accounts Receivable Management • NX
Update 95 Summary \| Details Change Program/Admission Date Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Change Program/Admission Date Change Program/Admission Date Dialogue Scenario 1: Change Program/Admission Date - verification of form filing Specific Setup: Client must be admitted to an active episode (Client A). Steps Access the 'Change Program/Admission Date' form. Select Client A in the 'Client ID' field. Select the desired episode in the 'Episode Number' field. Select the desired program in the 'New Program' field. Select the desired date in the 'New Admission Date' field. Select the desired time in the 'New Admission Time' field. Click [Submit]. Validate that a 'Change Program/Admission Date' message is displayed stating "Admission Program and Date has been changed". Click [OK]. Open the admission form for the client. Edit the episode, Validate that the admission date contains the new value. Close the form.	Topics • Change Program/Admission Date
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 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 Open the "Admission" form. Enter a new client into any episode. Populate the "Preferred Appointment Site" field. Submit to file the form. Open the "Admission" form. Edit the admission episode that was just entered. 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 Select "Client A" and access the 'Update Client Data' form. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?" Click [No]. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?" Click [Yes]. Validate a dialog stating: "Cancelled." and click [OK]. Validate the 'Client's Address - Street' field is cleared. Enter a valid address and populate any desired fields. Enter a 'Place of Birth' value that contains 40 characters. Select a preferred site in the "Preferred Site" field. Click [Submit]. 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 Select "Client A" and access the 'Pre Admit' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "Yes" in the 'Consent On File For Use of Integrated eSignature' field. Select desired site in the "Preferred Appointment Site" field. Click [Submit]. Select "Client A" and access the 'Pre Admit' form. Select an existing episode and click [Edit]. Select the "Demographics" section. Validate "Yes" is selected in the 'Consent On File For Use of Integrated eSignature' field. Validate the site that was previously selected displays in the "Preferred Appointment Site". Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "Y". Validate the 'esig_consent_on_file_value' field is present and contains "Yes". 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 Select "Client A" and access the 'Call Intake' form. Select the existing call intake record and click [Edit]. Select the "Demographics" section. Validate the 'Consent On File For Use of Integrated eSignature' field is present with values of "Yes" and "No". Select "No" in the 'Consent On File For Use of Integrated eSignature' field. Select desired site from the "Preferred Site" field. Click [Submit]. Select "Client A" and access the 'Call Intake' form. Select the existing call intake record and click [Edit]. Select the "Demographics" section. Validate "No" is selected in the 'Consent On File For Use of Integrated eSignature' field. Validate the Preferred site from the "Preferred Site" field. Close the form. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.patient_current_demographics' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". Close the report. Create a report using the 'SYSTEM.patient_demographic_history' SQL table. Navigate to the row for "Client A". Validate the 'esig_consent_on_file_code' field is present and contains "N". Validate the 'esig_consent_on_file_value' field is present and contains "No". 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 Using 'SoapUI' or another web service tool, consume the WSDL for the 'Pre Admit Discharge' form. Set the 'SystemCode' code to the agency system code for testing. Set the 'UserName' to the logged in user name. Set the 'Password' to the logged in user password. Set the 'DateOfDischarge' to the discharge date. Set the 'DischargeTime' to the time of discharge. Set the 'Discharge Practitioner' to a practitioner code (not the practitioner’s name). Set the 'Client ID' to the ID for the client to be discharged. Set the 'EpisodeNumber' to the client episode to be discharged. Set the "PreferredAppointmentSite" to the desired site. Click [Send]. Review the response and verify the response message displays: <Message>Client Pre-Admit Discharge web service has been filed successfully.</Message> Open 'Pre Admit Discharge' in Avatar. Select the client discharged in the Web Service. Verify the 'Date of Discharge' is set to the date entered in the Web Service. Verify the 'Time of Discharge' is set to the time entered in the Web Service. Verify the 'Discharge Practitioner' is set to the practitioner entered in the Web Service. Verify the "Preferred Appointment Site" is set to the desired site. 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 Access SoapUI for the 'ClientAdmission' - 'AddAdmission' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired date in the 'AdmissionDate' field. Enter the desired time in the 'AdmissionTime' field. Enter the desired practitioner in the 'AdmittingPractitioner' field. Enter the desired value in the 'ClientFirstName' field. Enter the desired value in the 'ClientLastName' field. Enter the desired value in the 'ClientMiddleName' field. Enter the corresponding name in the 'ClientName' field. Enter the desired value in the 'ESignatureConsentOnFile' field. Note: "Y" and "N" are accepted values. Enter the desired value in the 'Program' field. Enter the desired value in the 'Sex' field. Select the desired value in the "PreferredAppointmentSite". Populate any other required and desired fields. Click [Run]. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #". Validate the 'Message' field contains: "Client Admission web service has been filed successfully". Select the client filed in the previous steps and access the 'Admission' form. Select the record filed in the previous steps and click [Edit]. Validate all populated fields are displayed. Select the "Demographics" section. Validate the 'Client Last Name' field contains the value filed in the previous steps. Validate the 'Client First Name' field contains the value filed in the previous steps. Validate the 'Client Middle Name' field contains the value filed in the previous steps. Validate the 'Consent On File For Use of Integrated eSignature' field contains the value filed in the previous steps. Validate the "Preferred Appointment Site" contains the value filed in the previous steps. 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 Using 'Client Discharge' web service submit 'Discharge' record for valid client and episode. Set "PreferredAppointmentSite" to the desired value. 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>) Open Avatar 'Discharge' form. Select client record/episode used in 'Client Discharge' web service filing. Ensure that 'Discharge' record filed via web service is present in Avatar Cal-PM with values filed via web service. 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 Using soapUI or some other web service tool, file the ClientDemographics web service. Set up a request to update the client demographic data. Include the field "Preferred Appointment Site" by populating it. Submit to file the request. Open the "Update Client Data" form. 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 Access SoapUI for the 'ClientAdmission' - 'UpdateAdmission' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Populate all required and desired fields. Enter the desired value in the 'ClientDeclinedToProvideInfo' field. Enter the desired value in the 'MothersMaidenName' field. Enter the desired value in the 'NameQualifier' field. Enter the desired value in the 'OtherLanguages' field. Enter the desired value in the 'ProtectionIndicator' field. Enter the desired value in the 'ProtectionIndicatorDate' field. Enter "Client A" in the 'ClientID' field. Enter "Client A's" episode in the 'Episode' field. Enter the desired value in the "PreferredAppointmentSite" field. Click [Run]. Validate the 'Confirmation' field contains a value such as: "Client Unique ID: # Unique ID: #". Validate the 'Message' field contains: "Client Admission web service has been filed successfully". Select the client filed in the previous steps and access the 'Admission' form. Select the admission updated in the previous steps and click [Edit]. Validate all populated fields are displayed. Validate the 'Client Declined To Provide Information On The Following' field contains the value entered in the previous steps. Validate the 'Mother's Maiden Name' field contains the value entered in the previous steps. Validate the 'Protection Indicator' field contains the value entered in the previous steps. Validate the 'Protection Indicator Effective Date' field contains the value entered in the previous steps. Validate the 'Name Qualifier' field contains the value entered in the previous steps. Validate the 'Other Language(s)' field contains the value entered in the previous steps. Validate the "Preferred Appointment Site" field contains the value entered in the previous steps. 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 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, Confirm 'ClientCallIntake' web service responds with confirmation data/Client Unique ID on successful filing of 'UpdateCallIntake' method. Example:"<Confirmation>Client Unique ID : P26 Unique ID: CAL66110.001</Confirmation>" Confirm 'ClientCallIntake' web service responds with confirmation message on successful filing of 'UpdateCallIntake' method. Example:"<Message>Client Call Intake web service has been filed successfully.</Message>" Confirm 'ClientCallIntake' web service responds with successful status value on successful filing of 'UpdateCallIntake' method. Example:"<Status>1</Status>" Open Avatar PM 'Call Intake' form and select client/Call Intake record updated via web service for view/update. 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 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. Ensure that Call Intake record returns 'Client Call Intake web service has been filed successfully' message. 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 Open Avatar PM 'Admission (Outpatient)' form. In 'Select Client' dialog, enter values for search criteria and click 'Search' button. Select existing client record to enter Admission record or click 'New Client' button to create new client record via Admission record entry. 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. Navigate to 'Demographics' section of form. 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. Verify that 'Communication Preference' contains the following: Email, Regular Mail, Home Phone, Text, Work Phone, Cell Phone, Do Not Contact, and Consumer Portal. Select any value in 'Communication Preference'. Select any value in "Preferred Site". Click 'Submit' button to file new Admission/episode for existing client/new client creation. 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 Open Avatar PM 'Pre Admit Discharge' form. In 'Select Client' dialog, enter values for search criteria and click 'Search' button. Select existing client episode and click 'OK' button to enter new Pre Admit Discharge record or view/edit existing Pre Admit Discharge record. 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. Navigate to 'Demographics' section of form. 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). Select a site in the "Preferred Appointment Site" field. Click 'Submit' button to file Pre Admit Discharge record. Open the "Pre Admit Discharge" form. 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 Open the "Discharge" form. Select a client to be discharged. Complete all required fields. 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: Financial Eligibility 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 Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Select the ‘Unpost Selected Roll-Up Services’ section. Select desired value in ‘Select By Posting Date or Date of Service’. Enter desired value in ‘From Date’. Enter desired value in ‘To Date’. Select ‘Individual Client’ in ‘All or Individual Client’. Select the desired 'Client'. Select desired ‘Roll-Up Worklists’. Click [Select Roll-Ups to Unpost]. Select desired rows in the ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’ grid. Click [Save]. Click [Unpost Roll-Ups]. Click [OK]. Validate the date in the report and close the report. Close the form. Open ‘Client Ledger’. Process the ledger for the date range of the rolled-up services and the client that was selected to be unposted. Validate that the services are not rolled-up. Close the report. Process the ledger for the date range of the rolled-up services and the client that was not selected to be unposted. Validate that the services are rolled-up. Close the report. 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 Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Verify that the fields ‘Roll-Up Definitions’ and ‘Roll-Up Group’ are enabled. Enter the desired ‘From Date’ and ‘To Date’. Select a value in ‘Roll-Up Definitions’. Validate that no value can be selected in ‘Roll-Up Group’. Click [Compile Worklist]. Click [OK]. Select the ‘Post Roll-Up Services Worklist’ section. Select the desired ‘Through Date’. Select the desired 'Write Off Posting Code’. Click [Post Worklist]. Click [OK]. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. Close the form. Open ‘Compile/Edit/Post/Unpost Roll-Up Services Worklist’. Enter the desired ‘From Date’ and ‘To Date’. Select a value in ‘Roll-Up Group’. Validate that no value can be selected in ‘Roll-Up Definitions’. Click [Compile Worklist]. Click [OK]. If the group definition is set to roll-up the definition individually, the compile will be posted. If the group definition is not set to roll-up the definition individually, the compile will not be posted. Post the compile. Close the form. Open ‘Client Ledger’ for the desired client and date range. Select ‘Simple’ in the ‘Ledger Type’ 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’. Close the report. 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 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 Access the 'Service Code Upload Process' form. Click [Select File]. Select "File A" click [Open]. Select "Compile" in the 'Compile Or Post' field. Select "No" in the 'Override Existing Service Codes' field. Click [Submit]. Validate a message is displayed stating: Compile Completed. To view results review accepted and rejected reports. Click [OK] and leave the form opened. Access the 'Service Code Upload Accepted Codes' form. Select "File A" in the 'Select Desired Service Code Import File Name' field. Click [Process]. Validate "File A" contents are displayed in the report. Validate the 'Always Allow Overbooking' field is populated with the value defined in the file. Close the report and the form. Navigate back to the 'Service Code Upload Process' form. Select "Post" in the 'Compile Or Post' field. Click [Submit]. Validate a message is displayed stating: Posting completed. Click [OK] and close the form. Access the 'Service Codes' form. Select "Edit" in the 'Add New Or Edit Existing' field. Select the service code uploaded in the previous steps in the 'Service Code' field. Validate 'Always Allow Overbooking' field contains the uploaded value. Validate all other information displays as expected. Close the form Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.batchload_tx_accepted' SQL table. Validate a row is displayed for the service code uploaded in the previous steps. Validate the 'alwoverbook_code' field contains the uploaded value. Validate the 'alwoverbook_value' field contains the uploaded value. 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 Access the 'Service Codes' form. Select "Add" in the 'Add New Or Edit Existing' field. Validate the 'Clinic Hours' field is displayed and disabled. Validate the 'Always Allow Overbooking' field is displayed and disabled. Populate the required and desired fields. Select "Provider" in the 'Service Required By' field. 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. Select "Yes" in the 'Clinic Hours' field. Select "Yes" in the 'Always Allow Overbooking' field. Click [Submit]. Access Crystal Reports or other SQL reporting tool. Create a report using the 'SYSTEM.billing_tx_master_table' SQL table. Validate a row is displayed for the service code filed in the previous steps. Validate the 'clinic_hours_code' field contains "Y". Validate the 'clinic_hours_value' field contains "Yes". Validate the 'alwoverbook_code' field contains "Y". Validate the 'alwoverbook_value' field contains "Yes". Access the 'Service Codes' form. Select "Edit" in the 'Add New Or Edit Existing' field. Select the service code filed in the previous steps. Validate "Yes" is selected in the 'Clinic Hours' field. Select "No" in the 'Always Allow Overbooking' field. Click [Submit]. Access Crystal Reports or other SQL reporting tool. Refresh the report using the 'SYSTEM.billing_tx_master_table' SQL table. Validate the 'alwoverbook_code' field contains "N". Validate the 'alwoverbook_value' field contains "No". Close the report.	Topics • Service Codes • Service Code Upload Process
Update 99 Summary \| Details 'Allow Spaces in Client Name' registry setting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareFabric Monitor Scenario 1: Update Client Data - Validate the 'Allow spaces in Client Name' registry setting Specific Setup: The 'Client Demographics - Additional Fields' registry setting must be set to include "3" for 'Detailed Client Name'. The 'Allow Spaces in Client Name' registry setting is set to "Y". A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Update Client Data' form. Enter any name including one or more spaces in the 'Client Last Name' field (Ex. Last Name). Enter any name including one or more spaces in the 'Client First Name' field (Ex. First Name). Enter any name including one or more spaces in the 'Client Middle Name' field (Ex. Middle Name). Click [Submit]. Select "Client A" and validate the name displays with spaces as entered in the 'Update Client Data' form. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Enter "Client A" in the 'Client ID' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' is displayed. Validate a "ClientUpdated" record is displayed and click [Click To View Record]. Validate the 'name' - 'first' field contains the first name with spaces entered in the previous steps. Validate the 'name' - 'last' field contains the last name with spaces entered in the previous steps. Validate the 'name' - 'middle' field contains the middle name with spaces entered in the previous steps. Navigate back to the 'CareFabric Monitor Report'. Validate a "ClientDemographicsCreated" record is displayed and click [Click To View Record]. Validate the 'clientName' - 'first' field contains the first name with spaces entered in the previous steps. Validate the 'clientName' - 'last' field contains the last name with spaces entered in the previous steps. Validate the 'clientName' - 'middle' field contains the middle name with spaces entered in the previous steps. Close the report and the form.	Topics • Registry Settings • Update Client Data
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 Open ‘AR Console Export’. Validate that the ‘AR Console Data to Export’ field defaults to ‘All’. Validate that only the ‘Export to CSV’ button is enabled. Click the ‘Export to CSV’ button. Validate that the file is created and available to download, Download the file. Open the file and validate that the file is a comma delimited text file that contains data for unpaid claims. In ‘AR Console Export’, change ‘ AR Console Data to Export’ to ‘Selected Values’. Validate that ‘Financial Class Selection’ and ‘Treatment Setting Selection’ are enabled and not required. Validate that ‘Guarantors’ and ‘Programs’ are enabled and required. Select a ‘Financial Class Selection’ that contains more than one ‘Guarantor’. Validate that only guarantors/payors in that class display in ‘Guarantors’. Select one value in ‘Guarantors’. Select one ‘Treatment Setting Selection’. Validate that only programs in that setting display in ‘Programs’. Select one value in ‘Programs’. Click the ‘Export to CSV’ button. Validate that the file is created and available to download, Download the file. Open the file and validate that the file contains claims for the selected guarantor and program. Close the form.	Topics • Accounts Receivable Management • NX
Update 102 Summary \| Details Remittance Functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Remittance Processing Widget Crystal Reports or other SQL Reporting tool (PM Namespace) Internal Test Only	Topics n/a
Update 104 Summary \| Details File Import - Posting/Adjustment Code Definition Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Posting/Adjustment Codes Definition Scenario 1: File Import: Posting/Adjustment Codes Definition Specific Setup: The registry setting 'Import File Delimiter' is enabled with desired value. File Import: A file import file of 'Posting/Adjustment Codes Definition' file type is created to add a new posting code. A file import file of 'Posting/Adjustment Codes Definition' file type is created to edit the above posting code. Steps Open the 'File Import' form. Select the 'Posting/Adjustment Codes Definition' from the 'File Type' field. Upload the 'add' file created in the setup section. Compile the file. Verify the information message : 'Compiled'. Click [OK]. Post the file. Verify the file posted successfully. Close the form. Open the 'Posting/Adjustment Codes Definition' form. Validate the Code contains the imported data. Close the form. Open the 'File Import' form. Select the 'Posting/Adjustment Codes Definition' from the 'File Type' field. Upload the 'edit' file created in the setup section. Compile the file. Verify the information message : 'Compiled'. Click [OK]. Post the file. Verify the file posted successfully. Close the form. Open the 'Posting/Adjustment Codes Definition' form. Validate the Code contains the edited imported data. Close the form.	Topics • File Import • Posting/Adjustment Codes Definition • NX
Update 105 Summary \| Details File Import - Benefit Plan Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: File Import Scenario 1: File Import - Benefit Plans Specific Setup: The registry setting 'Import File Delimiter' is enabled with desired value. File Import: A file import file of 'Benefit Plan' file type is created to add a new plan. A file import file of 'Benefit Plan' file type is created to edit the above plan. Steps Open the 'File Import' form. Select the 'Benefit Plan' from the 'File Type' field. Upload the 'add' file created in the setup section. Compile the file. Verify the information message : 'Compiled'. Click [OK]. Post the file. Verify the file posted successfully. Close the form. Open the 'Benefit Plan' form. Validate the plan contains the imported data. Close the form. Open the 'File Import' form. Select the 'Benefit Plan' from the 'File Type' field. Upload the 'edit' file created in the setup section. Compile the file. Verify the information message : 'Compiled'. Click [OK]. Post the file. Verify the file posted successfully. Close the form. Open the 'Benefit Plan' form. Validate the plan contains the edited imported data. Close the form.	Topics • File Import • NX
Update 107 Summary \| Details Consent for Access - External Network Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Consent For Access Scenario 1: "Consent for Access" form - Consent on External Network section Specific Setup: An existing client must be identified, Client A. Steps Open the 'Consent For Access' form for the client identified in the setup section. Select the "External Network" section. Click [Add New Item]. Select "Network" in the 'Consent for' field. Select the desired network in the 'Network' field. Select "Grant" in the 'Consent to Opt In/Opt Out' field. Validate no warning message is displayed. Enter the desired date in the 'Start Date' field. Click [Add New Item]. Select "Organization" in the 'Consent for' field. Select the desired organization in the 'Organization' field. Select "Grant" in the 'Consent to Opt In/Opt Out' field. Validate a "Warning" message is displayed stating: "Granting individual consent to an organization includes the granting of access to information covered under the 42 CFR Part 2. Do you want to continue?" Please note: This message will only be displayed when selecting "Grant" consent for an organization or referral provider. Click [Yes]. Enter the desired date in the 'Start Date' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Create a report using the 'SYSTEM.consent_for_access' table. Validate two rows are displayed for the consent records filed in the previous steps - One for Network and one for Organization. Validate all information is displayed correctly. Select the client identified in setup section and access the 'Consent For Access' form. Select the "External Network" section. Select one of the records created in the previous steps. Click [Edit Selected Item]. Enter any new value in the 'Start Date' field. Click [Submit]. Access Crystal Reports or other SQL Reporting tool. Refresh the report using the SYSTEM.consent_for_access table. Navigate to row associated to the consent record updated in the previous steps. Validate the 'data_entry_by' field contains the user who updated the record. Validate the 'data_entry_date' field contains the date the record was updated. Validate the 'data_entry_time' field contains the time the record was updated. Validate the 'start_date' field contains the new date. Close the report. Create a new report using the SYSTEM.audit_consent_for_access table. Validate a row is displayed for the consent record updated in the previous steps. Validate the 'PATID' field contains 'Client A' ID. Validate the 'audit_data_entry_section' field contains "Updated". Validate the 'audit_data_entry_by' field contains the user who updated the record. Validate the 'audit_date' field contains the date the record was updated. Validate the 'audit_time' field contains the time the record was updated. Validate the 'start_date' field contains the original start date filed, not the updated date. Validate all other fields contain the original data for the consent record. Close the report. Scenario 2: Dictionary Update - Client file - Add/Edit/Print dictionary Steps Open the 'Dictionary Update' form. Select 'Client' in the 'File' field. Select 'Location' in the 'Data Element' field. Enter desired code to the 'Dictionary Code' field. Note the code. Enter desired value to the 'Dictionary Value' field. Note the value. Enter in extended data elements as necessary. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Location Status' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values added in previous step display correctly. Close the report. Select 'Input Dictionary Code(s)' section. Verify the 'File' field contains 'Client'. Verify the 'Data Element' is set to the 'Location'. Select desired code which is added in previous step in the 'Dictionary Code' field. Verify the correct 'Dictionary Value' displays for the selected code. Update the value in the 'Dictionary Value' field. Click [Apply Changes]. Validate that the 'Information' dialog contains 'Filed!'. Click [OK]. Select 'Print Dictionary' section. Select 'Client' in the 'File' field. Select 'Individual Data Element' radio button. Select 'Location' from the 'Data Element' field. Click [Print Dictionary]. Review the report. Verify the dictionary codes / values updated in previous step display correctly. Close the report. Close the form. Open the "Scheduling Calendar" form. Select an open time slot on the calendar and RightClick. Select "Add Appointment" from the dropdown. Note that the "Location" field contains the dictionary code(s)/value(s) entered in previous steps.	Topics • Consent for Access • Dictionary
Update 109 Summary \| Details Remittance Functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Remittance Processing Widget Quick Billing Rule Definition Quick Billing Internal Test Only	Topics • Remittance Processing • NX
Update 111 Summary \| Details Lab orders - Placing multiple orders Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Cross Episode Financial Eligibility Order Entry Console Orders This Episode Financial Eligibility Electronic Billing Service Codes Print Bill Scenario 1: LAB Orders - Creating LAB Orders - Client with Cross Episode Financial Eligibility Specific Setup: Admission: Create or identify a client in the system. Note the client id, admission program, admission date. Cross Episode Financial Eligibility: Assign 'Cross-Episode Financial Eligibility' with at least two guarantors. Program Maintenance: Set the 'Financially Responsible Party for Lab Orders' = "Based on Financial Eligibility" for the admission program of the client. External Lab/Radiology Definition for CareConnect: Identify or create one or more vendors with 'Lab Vendor Company' set to either "LabCorp" or "Quest" and 'ABN Required' set to "Yes." Order Code Setup: Create or identify two or more order codes that use the vendors from the 'External Lab Definition' grid. Note the order codes. Steps Select the Order Entry Console (Orders This Episode section). Select the client from set up in the setup section. Enter desired order code in the 'New Order' lookup that is identified in the setup section. Fill out all required fields for this order. Confirm that the 'External Lab Vendor Destination' is set to one of the vendors set up in the setup section. Verify that the 'Specimen Collection' field has 'Lab Vendor Staff will Collect' value selected. Add this order to the Scratchpad. Enter different order code in the 'New Order' lookup that is identified in the setup section. Fill out all required fields for this order. Confirm that the 'External Lab Vendor Destination' is set to one of the vendors set up in the setup section. Verify that the 'Specimen Collection' field has 'Lab Vendor Staff will Collect' value selected. Add this order to the Scratchpad. Verify that two orders are in the scratchpad, Click [Sign]. Verify two orders are saved successfully under the 'Order This Episode' section. Scenario 2: Electronic Billing - Running an 837 Professional and Institutional bills Specific Setup: Guarantors/Payors: Two guarantor is identified to be used. Note the guarantor code/name. Service codes: Two existing service codes are identified to be used for outpatient and inpatient services. 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. The CPT code and/or revenue code is attached to service code. Admission: An existing inpatient and outpatient clients are identified or created. Note client id, admission program, admission date. Financial Eligibility: Two guarantors are identified in the 'Guarantors/Payors' form are assigned to the client as a primary and secondary guarantor. Client Charge Input: A professional service is rendered to the outpatient client using the service code identified above. Note service date, service code. A service is rendered to the inpatient client using the service code identified above. Note service date, service code. Client Ledger: A service distributed correctly to the assigned guarantor. Steps Open the 'Electronic Billing' form. Select the 'Billing Form'. Select the 'Type Of Bill'. Select the 'Individual Or All Guarantors'. Select the 'Guarantor'. Select the 'Billing Type'. Select 'Run Report' in the 'Billing Option' field. Click 'Print' in the 'Print Or Delete Report' field. Select 'File' from the drop down. Click 'Print 837 Report' button. Verify that the report launched without any error. Scenario 3: Print Bill - Running HCFA - 1500 and UB-04 paper bills Specific Setup: Guarantors/Payors: Two guarantors are identified to be used. Note the guarantor's code/name. Service codes: Two existing service codes are identified to be used for outpatient and inpatient services. 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. The CPT code and/or revenue code is attached to service code. Admission: An existing inpatient and outpatient clients are identified or created. Note client id, admission program, admission date. Financial Eligibility: Two guarantors identified in the 'Guarantors/Payors' form are assigned to the client as a primary and secondary guarantor. Client Charge Input: A professional service is rendered to the outpatient client using the service code identified above. Note service date, service code. A service is rendered to the inpatient client using the service code identified above. Note service date, service code. Client Ledger: A service distributed correctly to the assigned guarantor. Steps Open 'Print Bill'. Enter a date in 'Print Charges Thru'. Select 'Yes' in 'Create Claims Y/N'. Enter a 'Date of Claim'. Select 'UB-04' in 'Print On What Form'. Click 'No' in 'Print For Interim Batch'. Select the 'Guarantor'. Select 'Individual' in 'Print For An Individual Or All Clients'. Select the 'Client ID'. Select 'Yes' in 'Print All Episodes'. Select 'No' in 'Print Summary By Revenue Code'. Click [Process]. Validate that the inpatient client, with the unclaimed service date range, is included in the output. Open 'Print Bill'. Enter a date in 'Print Charges Thru'. Select 'Yes' in 'Create Claims Y/N'. Enter a 'Date of Claim'. Select 'HCFA-100-NPI version' in 'Print On What Form'. Click 'No' in 'Print For Interim Batch'. Select the 'Guarantor'. Select 'Individual' in 'Print For An Individual Or All Clients'. Select the 'Client ID'. Select 'Yes' in 'Print All Episodes'. Select 'No' in 'Print Summary By Revenue Code'. Click [Process]. Validate that the outpatient client, with the unclaimed service date range, is included in the output.	Topics • Order Entry Console • NX • 837 Professional • 837 Institutional
Update 112 Summary \| Details 'Task Scheduler Status' widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: System Task Scheduler Task Scheduler Status Scenario 1: Validate the 'Task Scheduler Status' widget Specific Setup: In the 'System Task Scheduler', a minimum of two active tasks and one inactive task should be filed. 'View Definition' form has been used to add the ‘Task Scheduler Status’ widget to HomeView for the logged in user. Steps Access the ‘Task Scheduler Status’ widget on the Home View. Validate that the widget can be undocked, refreshed, and either minimized (Non NX View) or removed (NX View). Validate that the widget contains the following columns: ‘Application’, ‘Task’. ‘Inactive’, ‘Recur’, ‘Start Date’, ‘End Date’, ‘Last Run Start Date’, ‘Last Run Start Time’, ‘Last Run End Date’, ‘Last Run End Time’, and ‘Last Run Status’. Validate the data in each column is accurate. Note that for any task which errors, the error will display in the 'Last Run Status' column.	Topics • Widgets • System Task Scheduler
Update 114 Summary \| Details Medicare Part D Eligibility for RxConnect Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Enterprise.Configuration.Rules Reports/Labels.Periodic.Orders.Order Entry Statistics Scenario 1: Validate Order Entry Statistics Report displays who coded the order as well as the count of rules overridden and display the rules overridden when the order was initially coded Steps Internal testing only. Scenario 2: Validate 'Bill Billable Items' column on 'Order Entry Statistics' report Steps Internal testing only.	Topics • Reports/Labels
Update 115 Summary \| Details Payment Acknowledgement - Pending Posting Summary Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Print General Ledger Payment Acknowledgement Interface Detail General Ledger Payment Acknowledgement Account Numbers Compile General Ledger Payment/Adjustment Interface File Financial Eligibility Payment Acknowledgement GL_Payment_Acknowledgement_Interface_Detail.rpt Batch Cash Posting Scenario 1: Print General Ledger Payment Acknowledgement Interface Detail - Pre Compile - Payment Acknowledgement Specific Setup: Please note: The 'Print General Ledger Payment Acknowledgement Interface Detail' form is only available if the Avatar PM registry setting 'Enable Payment Acknowledgement' is enabled and Avatar PM 2023 update 115 is installed. System updated with Avatar GL module. General Ledger Charge Account Numbers and default account numbers are defined. General Ledger Payment/Adjustment components and account numbers are defined. Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting is set to '1&2'. Dictionary Update: File: Client (101) - Treatment Service - enter a code/value and then select the Program extended dictionary and enter desired value (i.e. 000111). Note dictionary code/value. Please note - The value entered here will also need to be added to the 'Program (5521)' dictionary in other tabled files for testing the GL compile. File: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Add the extended dictionary value from the '(101) Client' file and 'Treatment Service' dictionary. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. Admission: A new client is created, or an existing client is identified with charges that resulted in payments, and/or adjustments being posted to the charges. Guarantor/Payors: An existing guarantor is identified who does not have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Note the guarantor's code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open the 'Payment Acknowledgement General Ledger Interface Components' form. Select components. Submit the form. Open the 'General Ledger Payment Acknowledgement Account Numbers' form. Select component and the component value for each of the components. Select credit and debit account numbers. File Account numbers for each component and date range (optional) combination. Go to section 'G/L Payment Acknowledgement Defaults'. Add default account numbers. File Default account numbers. Submit the form. Open ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’. Note the Check/EFT number to be used in the 'Batch Cash Posting'. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Please note: The treatment service used must have program extended dictionary setup in the setup section. Select desired ‘Category’ from 'Account' dictionary. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Include in Category Dictionary: Yes' the dictionary item will be available for selection. No = not available for selection. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Require Name/Source in Payment Acknowledgement', has a value of 'Y' the 'Name/Source' field will become required. No = not required. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is [Number]. Click [Discard]. Open the 'Compile General Ledger Payment/Adjustment Interface File' form. Select dates that cover the transactions above and select 'Yes' for pre compile. Select 'Payment Acknowledgement' in the 'Include Payment Acknowledgement' field. Click [Process]. Validate the message that ask user to navigate to 'Print General Ledger Payment/Adjustment Interface File Detail' form to see the report. Open the 'Print General Ledger Payment/Adjustment Interface File Detail' form. Enter the date range of the report. Process the report. Verify the report displays data correctly. Close the report. Close the form. Enter rows with the Account, Treatment Service and Program used as components. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? File the form. Open the 'Compile General Ledger Payment/Adjustment Interface File' form. Select dates that cover the transactions above and select 'Yes' for pre compile. Select 'Payment Acknowledgement' in the 'Include Payment Acknowledgement' field. Click [Process]. Verify the GL strings for the Payment Acknowledgement GL Account Numbers are generated and that contains date specific entry and an entry without a date. Close the form. Scenario 2: Print General Ledger Payment Acknowledgement Interface Detail - Form / Fields validation Specific Setup: Please note: The 'Print General Ledger Payment Acknowledgement Interface Detail' form is only available if the Avatar PM registry setting 'Enable Payment Acknowledgement' is enabled and Avatar PM 2023 update 115 is installed. Steps Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'N'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is not available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components', 'General Ledger Payment Acknowledgement Account Numbers' and 'Print General Ledger Payment Acknowledgement Interface Detail' forms are not available under the 'General Ledger Interface' item. Click [OK]. Click [Submit]. Click [No]. Open the ‘Compile General Ledger Payment/Adjustment Interface File’ form. Verify that the ‘Include Payments Acknowledgments’ field not displayed on the form. Close the form. Open the 'Registry Settings' form. Select the 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting. Verify the registry setting is set to '0' and system does not allow to make any selections other than zero. Open the 'Registry Settings' form. Set the 'Enable Payment Acknowledgement' registry setting to 'Y'. Submit the form. Open the 'User Definition' form. Select the login user from the 'Select User' field. Click 'Forms and Tables' item. Click [Select Forms for User Access]. Verify the 'Payment Acknowledgement' form is available under the 'Remittance Processing' item. Verify the 'General Ledger Payment Acknowledgement Interface Components', 'General Ledger Payment Acknowledgement Account Numbers' and 'Print General Ledger Payment Acknowledgement Interface Detail' forms are available under the 'General Ledger Interface' item. Select the 'Payment Acknowledgement', 'General Ledger Payment Acknowledgement Interface Components', 'General Ledger Payment Acknowledgement Account Numbers' and 'Print General Ledger Payment Acknowledgement Interface Detail' forms. Click [OK]. Click [Submit]. Click [No]. Verify the 'General Ledger Payment Acknowledgement Interface Components', 'General Ledger Payment Acknowledgement Account Numbers' and 'Print General Ledger Payment Acknowledgement Interface Detail' forms are accessible from the menu. Scenario 3: Print General Ledger Payment Acknowledgement Interface Detail - Pre Compile - Post Payment Entry Specific Setup: Please note: The 'Print General Ledger Payment Acknowledgement Interface Detail' form is only available if the Avatar PM registry setting 'Enable Payment Acknowledgement' is enabled and Avatar PM 2023 update 115 is installed. System updated with Avatar GL module. General Ledger Charge Account Numbers and default account numbers are defined. General Ledger Payment/Adjustment components and account numbers are defined. Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting is set to '1&2'. Dictionary Update: File: Client (101) - Treatment Service - enter a code/value and then select the Program extended dictionary and enter desired value (i.e. 000111). Note dictionary code/value. Please note - The value entered here will also need to be added to the 'Program (5521)' dictionary in other tabled files for testing the GL compile. File: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Add the extended dictionary value from the '(101) Client' file and 'Treatment Service' dictionary. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. Admission: A new client is created, or an existing client is identified with charges that resulted in payments, and/or adjustments being posted to the charges. Guarantor/Payors: An existing guarantor is identified who does not have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Note the guarantor's code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open the 'Payment Acknowledgement General Ledger Interface Components' form. Select components. Submit the form. Open the 'General Ledger Payment Acknowledgement Account Numbers' form. Select component and the component value for each of the components. Select credit and debit account numbers. File Account numbers for each component and date range (optional) combination. Go to section 'G/L Payment Acknowledgement Defaults'. Add default account numbers. File Default account numbers. Submit the form. Open ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’. Note the Check/EFT number to be used in the 'Batch Cash Posting'. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Please note: The treatment service used must have program extended dictionary setup in the setup section. Select desired ‘Category’ from 'Account' dictionary. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Include in Category Dictionary: Yes' the dictionary item will be available for selection. No = not available for selection. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Require Name/Source in Payment Acknowledgement', has a value of 'Y' the 'Name/Source' field will become required. No = not required. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is [Number]. Click [Discard]. Open the 'Compile General Ledger Payment/Adjustment Interface File' form. Select dates that cover the transactions above and select 'Yes' for pre compile. Select 'Payment Acknowledgement' in the 'Include Payment Acknowledgement' field. Click [Process]. Validate the message that ask user to navigate to 'Print General Ledger Payment/Adjustment Interface File Detail' form to see the report. Open the 'Print General Ledger Payment/Adjustment Interface File Detail' form. Enter the date range of the report. Process the report. Verify the report displays data correctly. Close the report. Close the form. Enter rows with the Account, Treatment Service and Program used as components. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? File the form. Open the 'Compile General Ledger Payment/Adjustment Interface File' form. Select dates that cover the transactions above and select 'Yes' for pre compile. Select 'Payment Acknowledgement' in the 'Include Payment Acknowledgement' field. Click [Process]. Verify the GL strings for the Payment Acknowledgement GL Account Numbers are generated and that contains date specific entry and an entry without a date. Close the form. Scenario 4: Payment Acknowledgement - Post Payment Entry - Batch Cash Posting Specific Setup: Please note: The 'Print General Ledger Payment Acknowledgement Interface Detail' form is only available if the Avatar PM registry setting 'Enable Payment Acknowledgement' is enabled and Avatar PM 2023 update 115 is installed. System updated with Avatar GL module. General Ledger Charge Account Numbers and default account numbers are defined. General Ledger Payment/Adjustment components and account numbers are defined. Registry Setting: The 'Enable Payment Acknowledgement' registry setting is enabled. The 'Prevent Posting Payments Unless Payment has been Acknowledged' registry setting is set to '1&2'. Dictionary Update: File: Client (101) - Treatment Service - enter a code/value and then select the Program extended dictionary and enter desired value (i.e. 000111). Note dictionary code/value. Please note - The value entered here will also need to be added to the 'Program (5521)' dictionary in other tabled files for testing the GL compile. File: Other Table Files: (5521) Program - contains dictionary codes and dictionary values. Add the extended dictionary value from the '(101) Client' file and 'Treatment Service' dictionary. (5522) Account - contains dictionary codes, dictionary values and extended dictionary values. File: G/L Interface (204) - Credit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. (205) - Debit G/L Payment Acknowledgement Account Number - contains dictionary codes and dictionary values. Admission: A new client is created, or an existing client is identified with charges that resulted in payments, and/or adjustments being posted to the charges. Guarantor/Payors: An existing guarantor is identified who does not have a Financial Class that has the Extended Data Element for (1500) System Financial Class set to Self Pay. Note the guarantor's code/name. Financial Eligibility: Assign desired guarantor to the client. Client Charge Input: A service is rendered to the client. Client Ledger: Make sure the service is distributed to the guarantor assigned to the client. Steps Open ‘Payment Acknowledgment’ form. Enter desired value in ‘Batch Number’. Select desired ‘Posting Code’. Enter desired value in ‘Check/EFT Number’. Enter desired value in ‘Amount’. Select desired ‘Guarantor’. If a ‘Self-Pay guarantor is selected, the ‘Client’ field will be enabled. Enter desired value in ‘Name/Source’. Enter desired value in ‘Client’, if enabled. Enter desired value in ‘Check/EFT Date’. Note the Check/EFT number to be used in the 'Batch Cash Posting'. Enter desired value in ‘Receipt Date’. Enter desired value in ‘Deposit Date’. Select desired ‘Treatment Service’. Please note: The treatment service used must have program extended dictionary setup in the setup section Select desired ‘Category’ from 'Account' dictionary. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Include in Category Dictionary: Yes' the dictionary item will be available for selection. No = not available for selection. If the selected item, extended data dictionary value of 'Other Table Files: (5522) Account' - 'Require Name/Source in Payment Acknowledgement', has a value of 'Y' the 'Name/Source' field will become required. No = not required. Enter desired value in ‘Bank Ref #’. Enter desired value in ‘Comments’. Click [File]. Verify that the ‘Payment Acknowledgement’ message is received and states the following: Filed successfully. The Transaction Number is 6. Do you need to continue to Post Payment Accounting Entry? Note: The Transaction Number’ increments by one number with each filing. Clicking [No] returns the user to the ‘Payment Acknowledgement’ section to enter additional payments. Clicking [Yes] allows the user to post payments in 'Post Payment Accounting Entry'. Click [Yes]. Click [New Row] in ‘Post Payment Accounting Entry’. Select desired ‘Treatment Service’. It will default if filed in the ‘Payment Acknowledgement’. Select desired ‘Program’. This is from ‘Other Table Files: (5521) Program’, not a program in ‘Program Maintenance’. Select desired ‘Account’. Select desired ‘Amount’. Validate that the ‘Posting Code; defaulted from the ‘Payment Acknowledgement’. Select desired ‘Posting Date’. Validate that the ‘Posting Summary’ is correct. If desired, and first row partially posts the 'Amount', click [New Row] and repeat the steps. If desired, click [Delete Row]. A ‘Confirm Delete’ message will be displayed. Select desired value. Click [File]. The following ‘Payment Acknowledgement’ displays: Filed successfully. Do you need to continue with Post Payment Accounting Entry? Click [Yes]. Open the 'Batch Cash Posting' form. Enter desired date to the 'Date of Receipt or Adjustment' field. Enter desired date to the 'Cash Posting Date' field. Select 'Payment' in the 'Posting Type' field. Select 'Yes' in the 'Payment Acknowledgment' field. Select desired guarantor. Validate the 'Selected Payment Acknowledgment' field exist and lists all payment acknowledgments that have a balance greater than $0. If a guarantor is selected in the prior field, filter by that guarantor. Select payment acknowledgement defined for the selected guarantor. Validate the 'Amount to Post' field defaults to the remaining amount of the selected payment acknowledgment. Select desired value in the 'Individual or All Clients' field. Select desired client from the 'Client ID' field if the 'Client ID' field is marked as the required field. Select desired program from the 'Program of Service' field. Select service start date in the 'From Date' field. Select service end date in the 'To Date' field. Select desired payment acknowledgement code from the 'Posting Code' field. Validate the 'Receipt' field defaults in the transaction number of the payment acknowledgment If payment acknowledgment is selected. Enter the same Check/EFT # in the 'Check #' field that is entered in the 'Payment Acknowledgement'. Select 'Ignore' in the 'Write Off or Ignore Remaining Balance' field. Click [Process]. Validate the form files successfully. Open ‘Payment Acknowledgment’ form. Enter the transaction number from the above payment acknowledgement. Click [Search]. Verify all the details related to the transaction populated correctly in the 'Payment Acknowledgement' section of the form. Verify the 'Posting summary' field is updated correctly with the transaction posted through the 'Batch Cash Posting'. Open the 'Crystal Reports' or any other SQL Data Reporting tool. Select the PM namespace. Identify desired database and SQL table - SYSTEM.pay_ack_post_pay_acc_ent Locate to the SQL Editor Query 'select * from Select * from SYSTEM.pay_ack_post_pay_acc_ent where transaction_number=25 Validate the ID cell is equal to '13' Validate the account_code cell is equal to '501' Validate the account_value cell is equal to 'IncludeYRequireY' Validate the GUARANTOR_ID cell is equal to '100' Validate the date_of_payment cell is equal to '2022-03-01' Validate the payment_type_code cell is equal to '100' Validate the payment_type_value cell does not contain 'Payment - Check' Validate the payment_amount cell does not contain '25.00' Validate the option_desc cell is equal to 'Payment Acknowledgement' Validate the type_of_payment cell is equal to 'PAYMENT' Close the SQL data viewer.	Topics • GL • NX • Payment Acknowledgement
Update 117 Summary \| Details Avatar NX - Guardiant Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Treatment Plan Guardiant Individual Progress Note Scenario 1: Avatar NX - Validate 'Program' and 'Location' in Guardiant Steps Internal Testing Only. Scenario 2: Avatar NX - Guardiant/Flight Recorder Enhancements Steps Internal Testing Only.	Topics • Diagnosis • Treatment Plan • Progress Notes • NX • myAvatar NX Only • Progress Notes (Group And Individual)
Update 124 Summary \| Details Avatar NX - 'Update Client Data' Quick Action Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick Actions Page Scenario 1: Validate the 'Update Client Data' quick action Specific Setup: The 'Update Client Data' Quick Action must be assigned to the user's myDay view in the 'NX View Definition' form. A client is enrolled in an existing episode (Client A). Steps Select "Client A" and navigate to the 'Quick Actions' widget. Click [Update Client Data - Add]. Populate all required and desired fields. Enter "1" in the 'Home Phone' field. Validate a message is displayed stating: Invalid phone format specified. Valid phone formats are: '000-0000', '000-0000 X 0000', '000-000-0000', '000-000-0000 X - 0000'. Click [OK]. Validate the 'Home Phone' field is cleared out. Enter "111-111-1111" in the 'Home Phone' field. Enter "abcdefg" in the 'Work Phone' field. Validate a message is displayed stating: Invalid phone format specified. Valid phone formats are: '000-0000', '000-0000 X 0000', '000-000-0000', '000-000-0000 X - 0000'. Click [OK]. Validate the 'Work Phone' field is cleared out. Enter "222-2222" in the 'Work Phone' field. Enter "555" in the 'Cell Phone' field. Validate a message is displayed stating: Invalid phone format specified. Valid phone formats are: '000-0000', '000-0000 X 0000', '000-000-0000', '000-000-0000 X - 0000'. Click [OK]. Validate the 'Cell Phone' field is cleared out. Enter "333-3333 X - 3333" in the 'Cell Phone' field. Click [Save]. Select "Client A" and access the 'Update Client Data' form. Validate the 'Home Phone' field contains "111-111-1111". Validate the 'Work Phone' field contains "222-2222". Validate the 'Cell Phone' field contains ""333-3333 X - 3333". Validate all other previously filed data is displayed. Close the form.	Topics • Update Client Data • 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 126 Summary \| Details SQL Table Validation - SYSTEM.view_episode_summary_admit table Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Pre Admit Scenario 1: SQL table validation - SYSTEM.view_episode_summary_admit - Outpatient Client Admission on the cache system Specific Setup: Admission: Create a new client and do not enter date of birth of the client. Note the client id. Steps Open the 'Crystal report' or any other SQL data viewer. Query the 'Select * from SYSTEM.view_episode_summary_admit' table. Verify the client without a date of birth have a blank value in the 'c_date_of_birth' field. Open the 'Admission (Outpatient)' form for the client. Edit an existing admission record. Enter desired date of birth. Open the 'Crystal report' or any other SQL data viewer. Query the 'Select * from SYSTEM.view_episode_summary_admit' table for the client. Verify the client updated with a date of birth have correct date in the 'c_date_of_birth' field.	Topics • Admission • Admission (Outpatient) • Database Tables • NX
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 Access SoapUI for the 'ClientDischarge' - 'DischargeClient' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired date in the 'DateOfDischarge' field. Enter the desired practitioner in the 'DischargePractitioner' field. Enter the desired time in the 'DischargeTime' field. Enter the desired value in the 'TypeOfDischarge' field. Enter "Client A" in the 'ClientID' field. Enter the episode number to be discharged in the 'EpisodeNumber' field. Click [Run]. Validate the 'Message' field contains: Client Discharge web service has been filed successfully. Select "Client A" and access the 'Discharge' form. Validate all populated fields are displayed as entered in the web service. 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 Access SoapUI for the 'ClientPreAdmitDischarge' - 'PreAdmitDischargeClient' web service. Enter the system code that will be used to log into Avatar in the 'SystemCode' field. Enter the user name that will be used to log into Avatar in the 'UserName' field. Enter the password that will be used to log into Avatar in the 'Password' field. Enter the desired date in the 'DateOfDischarge' field. Enter the desired practitioner in the 'DischargePractitioner' field. Enter the desired time in the 'DischargeTime' field. Enter the desired value in the 'TypeOfDischarge' field. Enter "Client A" in the 'ClientID' field. Enter the Pre Admit episode number to be discharged in the 'EpisodeNumber' field. Click [Run]. Validate the 'Message' field contains: Client Discharge web service has been filed successfully. Select "Client A" and access the 'Pre Admit Discharge' form. Validate all populated fields are displayed as entered in the web service. Close the form.	Topics • Discharge • Web Services • Pre Admit Discharge
Update 129 Summary \| Details Remittance Processing widget - future functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Financial Eligibility Remittance Processing Widget Payment Acknowledgement Electronic Billing Internal Test Only	Topics n/a
Update 135 Summary \| Details Service Codes - Use Site or Service Based Appointment Color Coding Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Codes Site Registration Service Code Upload Process Service Code Upload Accepted Codes (2) Service Code Upload Rejected Codes (2) Scenario 1: Registry Settings - Use Site or Service Based Appointment Color Coding Steps Internal testing only	Topics • Service Codes • Site Registration
Update 144 Summary \| Details System Task Scheduler - Tasks Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: System Task Scheduler Task Scheduler Status Scenario 1: Validate the 'Task Scheduler Status' widget Specific Setup: In the 'System Task Scheduler', a minimum of two active tasks and one inactive task should be filed. 'View Definition' form has been used to add the ‘Task Scheduler Status’ widget to HomeView for the logged in user. Steps Access the ‘Task Scheduler Status’ widget on the Home View. Validate that the widget can be undocked, refreshed, and either minimized (Non NX View) or removed (NX View). Validate that the widget contains the following columns: ‘Application’, ‘Task’. ‘Inactive’, ‘Recur’, ‘Start Date’, ‘End Date’, ‘Last Run Start Date’, ‘Last Run Start Time’, ‘Last Run End Date’, ‘Last Run End Time’, and ‘Last Run Status’. Validate the data in each column is accurate. Note that for any task which errors, the error will display in the 'Last Run Status' column.	Topics • System Task Scheduler • Widgets

Avatar_PM_2023_Quarterly_Release_2023.03_Details.csv