Avatar PM 2023 Quarterly Release 2023.02 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'. 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]. 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: Bed Availability Report 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 Progress Notes (Group and Individual) 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 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: Scheduling Calendar 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 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 Bed Availability Report 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 Progress Notes (Group and Individual) 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 Progress Notes (Group and Individual) 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 Update Client Data 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: Update Client Data 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 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 Update Client Data 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 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 Update Client Data 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 Progress Notes (Group and Individual) 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 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 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 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 Progress Notes (Group and Individual) 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 Update Client Data 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 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 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 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 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 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

Avatar_PM_2023_Quarterly_Release_2023.02_Details.csv