Skip to main content

Avatar PM 2022 Update 94

  1. Last updated
  2. Save as PDF

Product Requirements / Recommendations

Avatar PM required
RADplus required

Product Update Form Description

The following issues are resolved: 1) An incorrect error message is displayed when editing a service in the 'Edit Service Information' form for a client when the client has been transferred to another program. 2) 835 remittance posting process will incorrectly transfer liability to NTST Default Payor (99999) if the next applicable guarantor subsequent to the billing guarantor has already met their monthly maximum allowable limit. 3) Editing a service via the Edit Service Information web service might incorrectly result in the "Discipline : Code [XX] not shared by practitioner and service." error message. Additionally, the 835 remittance crossover logic is enhanced to properly process CCBHC crossover guarantors.

Included Updates

3, 9, 18, 34, 41, 55, 59, 62, 67, 77, 84, 87, 90

Required Updates

None

Details
NEW1 CHANGED0 FIXED3
New (1)
835 Crossover Logic - CCBHC guarantors
The 835 Crossover Logic has been updated to process CCBHC guarantors.
Value Added: 835 Crossover logic will be used with CCBHC guarantors
Topics
• 835 Health Care Claim Payment/Advice
 
Fixed (3)
Edit Service Information - Admission vs. Service Program
Edit Service Information functionality is updated to ensure the successful editing of an open service when the client was transferred from an admission program to another program after the date of service.
Topics
• Edit Service Information • Practitioner • Program Transfer
 
835 Crossover Logic - Posting Code = Transfer Type - Redistribute (Close)
The 835 Crossover Logic has been updated to ensure that the amount not paid on a service is correctly transferred to the next eligible guarantor when the posting code = Transfer Type - Redistribute (Close).
Topics
• 835 Health Care Claim Payment/Advice • NX
 
Web Service - Edit Service Information - Practitioner Disciple
The Edit Service Information web service has been updated to display the following message when the services being edited does not contain a discipline assigned to the service Practitioner.
Topics
• Edit Service Information • Web Services
 
Acceptance Tests
AV-79144 Summary | Details
Edit Service Information - Admission vs. Service Program
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Admission (Outpatient)
  • Client Charge Input
  • Client Ledger
  • Program Maintenance
  • Program Transfer (OutPatient)
  • Registry Settings (PM)
  • Service Codes
Scenario 1: Edit Service Program - Editing the service information after program transfer - Enable 'Admission vs. Service Program' Functionality registry setting
Specific Setup:
  • Registry Setting:
  • The "Enable 'Admission vs. Service Program' Functionality" registry setting is set to 'Y'.
  • Program Maintenance:
  • Two new outpatient admission programs are created such that there is no overlap of the associated service programs between the two admission programs. Note the admission programs and associated service programs.
  • Admission (Outpatient):
  • The client is admitted into the first admission program.
  • Client Charge Input:
  • A service is rendered to the client under one of the associated service programs. Note the service date and service code.
  • Program Transfer (Outpatient):
  • The client is transferred into the second admission program.
Steps
  1. Open the 'Edit Service Information' form.
  2. Fill in all required fields.
  3. Click [Select Service(s) to Edit].
  4. Verify the 'Select Service(s) to Edit' dialog box launched with all the services rendered to the selected client.
  5. Select desired service to edit.
  6. Verify the 'Program' field is populated with the service programs that was associated with the admission program at the time of service creation.
  7. Submit the form.
  8. Verify the form submits successfully.
Topics
• Edit Service Information • Practitioner • Program Transfer
AV-80773 Summary | Details
835 Crossover Logic - Posting Code = Transfer Type - Redistribute (Close)
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • 835 Health Care Claim Payment/Advice (PM)
  • Admission (Outpatient)
  • Claim Adjustment Group/Reason Code Definition
  • Client Charge Input
  • Client Ledger
  • Diagnosis
  • Electronic Billing
  • Financial Eligibility
  • Guarantors/Payors
  • Posting/Adjustment Codes Definition
  • Practitioner Enrollment
  • Practitioner Numbers By Guarantor And Program
  • Program Maintenance
  • Registry Settings (PM)
  • Service Codes
Scenario 1: Crossover Claims - Allow Billing Next Guarantor
Specific Setup:
  • The following registry setting has a value of 'Y': Avatar PM->Billing->Electronic Billing->All 837 Submissions->->Enable Support For Crossover Claims.
  • Practitioner Enrollment is used to identify desired service practitioner and the ‘Practitioner Categories for Coverage’.
  • Service Code: Identify a service code that will be used to create services. Note the service code fee in Service Fee/Cross Reference Maintenance.
  • Benefit Plan: All benefit plans contain ‘Practitioner Categories for Coverage’ in ‘Covered Charge Categories’.
  • Plan for Guarantor 1 will fully cover the service fee.
  • Plan for Guarantor 2 contains a value in ‘Monthly Maximum Responsibility’. Note the value.
  • Plan for Guarantor 3 will fully cover the service fee.
  • Guarantors/Payors: Three guarantors are identified that do not share the same ‘Default Guarantor Plan’.
  • Admit a new client: Note the admission date and program.
  • Add a diagnosis record.
  • Add a financial eligibility record:
  • Guarantor #1 = Guarantor 1.
  • Guarantor #2 = Guarantor 2.
  • Guarantor #31 = Guarantor 3.
  • Guarantor/Program Billing Defaults:
  • Edit the template for the secondary guarantor, section 837 Professional or 837 Institutional.
  • Select Guarantor(s) Responsible For Crossover Claim Submission = Primary Guarantor.
  • Number of Days to Hold Billing of Claim = 15. Note: Zero is a valid value for this field and if used the primary and secondary guarantors can be billed immediately.
  • Client Charge Input is used to create two services 25 and 26 days in the past, ensuring they are in the same month.
  • Client Ledger is used to validate that the charge distributed full liability to Guarantor 1.
  • Close Charges is used to close the charge.
  • Electronic Billing: Guarantor 1: has been used to create a claim 19 days in the past.
  • An '835 Health Care Claim Payment/Advice’ exists that pays each of the two services, minus the ‘Monthly Maximum Responsibility’ amount noted above, for each service. Note the Claim Adjustment Group/Reason Code used in the ‘CAS’ segment.
  • Verify the that ‘Claim Adjustment Group/Reason Code Definition’ exists for the guarantors and that the posting code = 'Transfer – Redistribute (Close)’.
Steps
  1. Open ‘835 Health Care Claim Payment/Advice’.
  2. Load, compile and post the '835 Health Care Claim Payment/Advice’.
  3. Close the form.
  4. Open ‘Client Ledger’ and validate that Guarantor 2 has a ‘LINE BALANCE’ equal to the ‘Monthly Maximum Responsibility’ amount due to the transfer. Also, validate that Guarantor 3 has a ‘LINE BALANCE’ equal to the ‘Monthly Maximum Responsibility’ amount due to the transfer.
  5. If desired post an ‘835 Health Care Claim Payment/Advice’ files for Guarantor 2 and Guarantor 3.
  6. Close the form.
Topics
• 835 Health Care Claim Payment/Advice • NX
AV-81250 Summary | Details
835 Crossover Logic - CCBHC guarantors
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • 835 Health Care Claim Payment/Advice (PM)
  • Admission (Outpatient)
  • App Dashboard
  • Claim Adjustment Group/Reason Code Definition
  • Client Charge Input
  • Client Ledger
  • Diagnosis
  • Dictionary Update (PM)
  • Dynamic Form - Admission - Client
  • Dynamic Form - Form and Table Documentation / File Export - File Name
  • Electronic Billing
  • Financial Eligibility
  • Guarantors/Payors
  • Posting/Adjustment Codes Definition
  • Practitioner Enrollment
  • Practitioner Numbers By Guarantor And Program
  • Program Maintenance
  • Registry Settings (PM)
  • Service Codes
Scenario 1: Crossover Claims - Allow Billing Next Guarantor - Primary Guarantor is not CCBHC - Secondary Guarantor is CCBHC
Specific Setup:
  • The following registry setting has a value of 'Y': Avatar PM->Billing->Electronic Billing->All 837 Submissions->->Enable Support For Crossover Claims.
  • Practitioner Enrollment is used to identify desired service practitioner and the ‘Practitioner Categories for Coverage’.
  • Service Code: Identify a CCBHC service code that will be used to create a service. Note the service code fee in Service Fee/Cross Reference Maintenance.
  • Benefit Plan: All benefit plans contain ‘Practitioner Categories for Coverage’ in ‘Covered Charge Categories’.
  • Plan for Guarantor 1 will fully cover the service fee.
  • Plan for Guarantor 3 will fully cover the service fee.
  • Guarantors/Payors:
  • Guarantor 1 is not a CCBHC guarantor.
  • Guarantor 2 is a CCBHC guarantor.
  • Admit a new client that bills CCBHC services. Note the admission date and program.
  • Add a diagnosis record.
  • Add a financial eligibility record:
  • Guarantor #1 = Guarantor 1.
  • Guarantor #2 = Guarantor 2.
  • Guarantor/Program Billing Defaults:
  • Edit the CCBHC template for the secondary guarantor, section 837 Professional or 837 Institutional.
  • Select Guarantor(s) Responsible For Crossover Claim Submission = Primary Guarantor.
  • Number of Days to Hold Billing of Claim = 15. Note: Zero is a valid value for this field and if used the primary and secondary guarantors can be billed immediately.
  • Client Charge Input is used to create two services 25 and 26 days in the past, ensuring they are in the same month.
  • Client Ledger is used to validate that the charge distributed full liability to Guarantor 1.
  • Close Charges is used to close the charges.
  • Electronic Billing: Guarantor 1: has been used to create a claim 19 days in the past.
  • An '835 Health Care Claim Payment/Advice’ exists that pays the service, minus $10.00. Note the Claim Adjustment Group/Reason Code used in the ‘CAS’ segment.
  • Verify the that ‘Claim Adjustment Group/Reason Code Definition’ exists for the three guarantor and that the posting code = 'Transfer – Redistribute (Close)’.
Steps
  1. Open ‘835 Health Care Claim Payment/Advice’.
  2. Load, compile and post the '835 Health Care Claim Payment/Advice’.
  3. Close the form.
  4. Open ‘Client Ledger’ and validate that Guarantor 2 has a ‘LINE BALANCE’ equal to $10.00 due to the transfer.
  5. If desired post an ‘835 Health Care Claim Payment/Advice’ file for Guarantor 2.
  6. Close the form.
Topics
• 835 Health Care Claim Payment/Advice
AV-81402 Summary | Details
Web Service - Edit Service Information - Practitioner Disciple
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Admission
  • Client Ledger
  • Financial Eligibility
  • Practitioner Enrollment
  • Registry Settings (PM)
  • Service Codes
  • SQL Query/Reporting
Scenario 1: 'Edit Service Information' web service - Editing 'Open' services
Specific Setup:
  • Practitioner Enrollment is used to validate the 'Discipline' of the desired practitioner.
  • Service Code 1: Is a service code that does not contain the practitioner's discipline in 'Discipline(s)'.
  • Service Code 2: Is a service code that does contain the practitioner's discipline in 'Discipline(s)'.
  • Identify an existing client that has at least one existing open service for Service Code 2 and the practitioner. Note the client's id/name, service code, practitioner's id, and the service date.
Steps
  1. Open the SoapUI or any other web service testing tool.
  2. Create a web service request to edit the service information, using ‘WEBSVC.EditServiceInformation:EditServiceInformationICD10'.
  3. The 'SystemCode' will be equal to the value used when logging into myAvatar.
  4. The 'UserName' will be equal to the value used when logging into myAvatar.
  5. The 'Password' will be equal to the value used when logging into myAvatar.
  6. Enter values for all required fields.
  7. Select Service Code 1 in ‘ServiceCode’.
  8. Submit the request.
  9. Verify the response message contains: Discipline : No common disciplines found for Practitioner and Service code selected.
  10. Change the service code to Service Code 2.
  11. Add data to one field that had no date or change existing data for a field.
  12. Submit the request.
  13. Verify the message: "Edit Service Information web service has been filed successfully".
  14. If desired, open 'Crystal Reports' or any other SQL Data Reporting tool.
  15. Select the PM namespace.
  16. Query the 'SYSTEM.billing_tx_history' SQL table.
  17. Validate the 'PATID' column is equal to the correct client id identified in the setup.
  18. Validate the 'date_of_service' column is equal to correct date of service rendered to the client.
  19. Validate the 'Service Code' column contains correct service code entered in the web service request.
  20. Validate the 'data_entry_source' column contains 'WEBSVC.EditServiceInformation:EditServiceInformationICD10'.
Topics
• Edit Service Information • Web Services