Skip to main content

Avatar PM 2022 Monthly Release 2022.00.00 Acceptance Tests

  1. Last updated
  2. Save as PDF
Update 1 Summary | Details
Avatar PM 2022 is Installed
Scenario 1: Validate Upgrading Avatar PM 2021 to 2022 is successful when 2021.04.00 is loaded
Specific Setup:
  • Latest Monthly Release is installed.
Steps
  1. Open the "Product Updates" form.
  2. Select the appropriate [Namespace] from the Application dropdown list
  3. Click [Select Update/Customization Pack].
  4. Browse to the location for the updates and select the Update 1.
  5. Click [OK] on the "File Upload Complete" window.
  6. Click [Review Update/Customization Pack Contents].
  7. Verify Update 1 is included.
  8. Click [Install Update/Customization Pack].
  9. Click [OK] when the install completes.
  10. Click [Close Form].
Topics
• Upgrade
Update 8 Summary | Details
Service Fee/Cross Reference Maintenance - Pro-Rated Fees
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dictionary Update (PM)
  • Program Maintenance
  • Dynamic Form - Admission - Client
  • Admission
  • Diagnosis
  • Financial Eligibility
  • Post Residential/Inpatient Worklist
  • Dynamic Form - OCR Template Import - Warning
  • Client Ledger
  • Discharge
  • Leaves
Scenario 1: Validate Pro-Rated Fees Calculation - Client without leave or discharge
Specific Setup:
  • The following registry setting has a value of '2', at a minimum: Avatar PM->System Maintenance->Service Code Maintenance->->->Additional Service Fee Configuration Fields.
  • The following registry setting has a value of '5': Avatar PM->Services->Inpatient/Residential->->->Number Of Daily Charge Codes.
  • Guarantors/Payors 1 is an active guarantor.
  • Service Code 1: Is an active service code that will be used for pro-rated services room and board charges.
  • Service Code 2: Is an active service code that will be used for pro-rated services daily charge (1).
  • Service Code 3: Is an active service code that will be used for pro-rated services daily charge (2).
  • Service Code 4: Is an active service code that will be used for pro-rated services daily charge (3).
  • Service Code 5: Is an active service code that will be used for pro-rated services daily charge (4).
  • Service Code 6: Is an active service code that will be used for pro-rated services daily charge (5).
  • Service Fee/Cross Reference Maintenance:
  • Service Code 1 - Service Code 6:
  • From Date = desired date.
  • Fee = desired amount, which is distributed across the monthly services. Note each value.
  • UB-94 Revenue Code = desired value.
  • Fee type = Monthly.
  • Pro-Rate Fee For = desired values.
  • Pro-Rated Fee Calculation = Fee/Monthly Days.
  • Client A:
  • Is admitted to an inpatient program on or after the earliest 'Service Fee/Cross Reference Maintenance', 'From Date'. Note the ‘Unit’ the client is assigned to. Client has not been placed on leave or discharged during the month.
  • Has a 'Financial Eligibility' record for Guarantors/Payors 1.
  • Equations are used for fee verification based on the value in 'Pro-Rated Fee Calculation'
  • The value of 'Pro-Rated Fee Calculation' is 'Fee/Monthly Days'. The equation is: the 'Fee' divided by the number of days in the month, times the number of valid days, divided by the number of days in the month.
  • Example 1: Fee is 350.00. Days in month = 31. Valid days = 31. 350/31 = 11.29 for days 1-30, and 11.30 for day 31.
  • Example 2: Fee is 120.00. Days in month = 30. Valid days = 15. 120.00/30x15/30 = 2.00 for the valid days.
Steps
  1. Open ‘Compile Residential/Inpatient Charges’.
  2. Select ‘Individual’ in ‘Individual Or All Units’.
  3. Select desired Unit in ‘Select Unit(s)’.
  4. Set the ‘Compile Charges From Date’ to desired value.
  5. Set the ‘Compile Charges Through Date’ to desired value.
  6. Select ‘Yes’ in ‘Do You Wish To Recreate The Residential/Inpatient Worklist’
  7. Click [Process].
  8. Validate that the report fees are correct for each service code, ensuring that at a minimum the first and last page of the report are verified. Calculate the fees to verify that the fee in ‘Service Fee/Cross Reference Maintenance’ is correct for the valid number of days in the month.
  9. Open ‘Post Residential/Inpatient Worklist’.
  10. Select ‘Individual’ in ‘Individual Or All Units’.
  11. Select desired Unit in ‘Select Unit(s)’.
  12. Set the ‘Post Charges From Date’ to desired value.
  13. Set the ‘Post Charges Through Date’ to desired value.
  14. Click [Process].
  15. Validate that the report fees are the same as above.
  16. If desired, open ‘Client Ledger’ and verify the fees for the date range and services.
Scenario 2: Validate Pro-Rated Fees Calculation - Discharged client
Specific Setup:
  • The following registry setting has a value of '2', at a minimum: Avatar PM->System Maintenance->Service Code Maintenance->->->Additional Service Fee Configuration Fields.
  • The following registry setting has a value of '5': Avatar PM->Services->Inpatient/Residential->->->Number Of Daily Charge Codes.
  • Guarantors/Payors 1 is an active guarantor.
  • Service Code 1: Is an active service code that will be used for pro-rated services room and board charges.
  • Service Code 2: Is an active service code that will be used for pro-rated services daily charge (1).
  • Service Code 3: Is an active service code that will be used for pro-rated services daily charge (2).
  • Service Code 4: Is an active service code that will be used for pro-rated services daily charge (3).
  • Service Code 5: Is an active service code that will be used for pro-rated services daily charge (4).
  • Service Code 6: Is an active service code that will be used for pro-rated services daily charge (5).
  • Service Fee/Cross Reference Maintenance:
  • Service Code 1 - Service Code 6:
  • From Date = desired date.
  • Fee = desired amount, which is distributed across the monthly services. Note each value.
  • UB-94 Revenue Code = desired value.
  • Fee type = Monthly.
  • Pro-Rate Fee For = desired values.
  • Pro-Rated Fee Calculation = Fee/Monthly Days.
  • Client A:
  • Is admitted to an inpatient program on or after the earliest 'Service Fee/Cross Reference Maintenance', 'From Date'. Note the ‘Unit’ the client is assigned to. Client has not been placed on leave during the month. The client has been discharged before the end of the month. Note how many days that client was in the program.
  • Has a 'Financial Eligibility' record for Guarantors/Payors 1.
  • Equations are used for fee verification based on the value in 'Pro-Rated Fee Calculation'
  • The value of 'Pro-Rated Fee Calculation' is 'Fee/Monthly Days'. The equation is: the 'Fee' divided by the number of days in the month, times the number of valid days, divided by the number of days in the month.
  • Example 1: Fee is 350.00. Days in month = 31. Valid days = 31. 350/31 = 11.29 for days 1-30, and 11.30 for day 31.
Steps
  1. Open ‘Compile Residential/Inpatient Charges’.
  2. Select ‘Individual’ in ‘Individual Or All Units’.
  3. Select desired Unit in ‘Select Unit(s)’.
  4. Set the ‘Compile Charges From Date’ to desired value.
  5. Set the ‘Compile Charges Through Date’ to desired value.
  6. Select ‘Yes’ in ‘Do You Wish To Recreate The Residential/Inpatient Worklist’
  7. Click [Process].
  8. Validate that the report fees are correct for each service code, ensuring that at a minimum the first and last page of the report are verified. Calculate the fees to verify that the fee in ‘Service Fee/Cross Reference Maintenance’ is correct for the valid number of days in the month. Validate that the fees are not calculated after the client was discharged.
  9. Open ‘Post Residential/Inpatient Worklist’.
  10. Select ‘Individual’ in ‘Individual Or All Units’.
  11. Select desired Unit in ‘Select Unit(s)’.
  12. Set the ‘Post Charges From Date’ to desired value.
  13. Set the ‘Post Charges Through Date’ to desired value.
  14. Click [Process].
  15. Validate that the report fees and days are the same as above.
  16. If desired, open ‘Client Ledger’ and verify the fees for the date range and services.
Scenario 3: Validate Pro-Rated Fees Calculation - Client with leave
Specific Setup:
  • The following registry setting has a value of '2', at a minimum: Avatar PM->System Maintenance->Service Code Maintenance->->->Additional Service Fee Configuration Fields.
  • The following registry setting has a value of '5': Avatar PM->Services->Inpatient/Residential->->->Number Of Daily Charge Codes.
  • Guarantors/Payors 1 is an active guarantor.
  • Service Code 1: Is an active service code that will be used for pro-rated services room and board charges.
  • Service Code 2: Is an active service code that will be used for pro-rated services daily charge (1).
  • Service Code 3: Is an active service code that will be used for pro-rated services daily charge (2).
  • Service Code 4: Is an active service code that will be used for pro-rated services daily charge (3).
  • Service Code 5: Is an active service code that will be used for pro-rated services daily charge (4).
  • Service Code 6: Is an active service code that will be used for pro-rated services daily charge (5).
  • Service Fee/Cross Reference Maintenance:
  • Service Code 1 - Service Code 6:
  • From Date = desired date.
  • Fee = desired amount, which is distributed across the monthly services. Note each value.
  • UB-94 Revenue Code = desired value.
  • Fee type = Monthly.
  • Pro-Rate Fee For = desired values. If 'Missing Service Code' is not selected in the field, leave days will be counted as valid days.
  • Pro-Rated Fee Calculation = Fee/Monthly Days.
  • Client A:
  • Is admitted to an inpatient program on or after the earliest 'Service Fee/Cross Reference Maintenance', 'From Date'. Note the ‘Unit’ the client is assigned to. Client has a non-billable leave during the month. Note the number of leave days. The client has not been discharged during the month.
  • Has a 'Financial Eligibility' record for Guarantors/Payors 1.
  • Equations are used for fee verification based on the value in 'Pro-Rated Fee Calculation'
  • The value of 'Pro-Rated Fee Calculation' is 'Fee/Monthly Days'. The equation is: the 'Fee' divided by the number of days in the month, times the number of valid days, divided by the number of days in the month.
  • Example 1: Fee is 350.00. Days in month = 31. Valid days = 31. 350/31 = 11.29 for days 1-30, and 11.30 for day 31.
  • Example 2: Fee is 120.00. Days in month = 30. Valid days = 15. 120.00/30x15/30 = 2.00 for the valid days.
Steps
  1. Open ‘Compile Residential/Inpatient Charges’.
  2. Select ‘Individual’ in ‘Individual Or All Units’.
  3. Select desired Unit in ‘Select Unit(s)’.
  4. Set the ‘Compile Charges From Date’ to desired value.
  5. Set the ‘Compile Charges Through Date’ to desired value.
  6. Select ‘Yes’ in ‘Do You Wish To Recreate The Residential/Inpatient Worklist’
  7. Click [Process].
  8. Validate that the report fees are correct for each service code, ensuring that at a minimum the first and last page of the report are verified. Calculate the fees to verify that the fee in ‘Service Fee/Cross Reference Maintenance’ is correct for the valid number of days in the month.
  9. Open ‘Post Residential/Inpatient Worklist’.
  10. Select ‘Individual’ in ‘Individual Or All Units’.
  11. Select desired Unit in ‘Select Unit(s)’.
  12. Set the ‘Post Charges From Date’ to desired value.
  13. Set the ‘Post Charges Through Date’ to desired value.
  14. Click [Process].
  15. Validate that the report fees are the same as above.
  16. If desired, open ‘Client Ledger’ and verify the fees for the date range and services.
Topics
• NX • Pro Rated Fee
Update 9 Summary | Details
Compile/Edit/Post/Unpost Roll-Up Services Worklist for "NCPDP"
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Orders This Episode
  • HL7 Connection Monitor
  • Launch RxConnect
  • Compile Inbound HL7 Charge Batch File
  • Post Inbound HL7 Charge Batch File
  • Compile/Edit/Post/Unpost Roll-Up Services Worklist
  • National Drug Code Reporting
  • Rx Summary
  • Order Tracking
  • Client Ledger
Scenario 1: NCPDP Roll-Up Billing via the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form- Ensuring excluded component services are not included on the worklist or in National Drug Code Reporting
Specific Setup:
  • myAvatar must be configured to communicate with RxConnect via Avatar HL7 and vice versa.
  • Avatar HL7 must be installed and configured with an 'ADT-RXCONNECT', 'ORDERS-RXCONNECT', 'BILLING-RXCONNECT' and 'FILLDETAILS-RXCONNECT'.
  • The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y".
  • The applications must be configured for NCPDP Billing.
  • A client must have an active inpatient episode. (Client A)
  • "Client A" must be associated with a NCPDP guarantor in the 'Financial Eligibility' form.
Steps
  1. Select "Client A" and access the Order Entry Console.
  2. Search for and select "PRILOSEC (OMEPRAZOLE) 20 MG CAPSULE, DELAYED RELEASE ORAL" in the 'New Order' field.
  3. Set the 'Dose' field to "1".
  4. Select "Capsule" in the 'Dose Unit' field.
  5. Select "Twice A Day" in the 'Freq' field.
  6. Set the 'Duration' field to "90" and click [Days].
  7. Set the 'Days Supply' field to "90".
  8. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  9. Set the 'Start Time' field to "12:00 AM".
  10. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  11. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  12. Click [Add to Scratchpad].
  13. Search for and select "ADVIL 200 MG TABLET ORAL" in the 'New Order' field.
  14. Set the 'Dose' field to "1".
  15. Select "Tablet" in the 'Dose Unit' field.
  16. Select "Every Day" in the 'Freq' field.
  17. Set the 'Duration' field to "90" and click [Days].
  18. Set the 'Days Supply' field to "90".
  19. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  20. Set the 'Start Time' field to "12:00 AM".
  21. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  22. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  23. Click [Add to Scratchpad] and [Sign].
  24. Validate the 'Order grid' contains an order for "ADVIL 200 MG ORAL TABLET 1 Tablet, EVERY DAY" and an order for "PRILOSEC (OMEPRAZOLE) 20 MG ORAL CAPSULE, DELAYED RELEASE 1 Tablet, TWICE A DAY".
  25. Access the 'HL7 Connection Monitor' form.
  26. Select "(Outbound) ORDERS-RXCONNECT" in the 'Select Row' field.
  27. Set the 'Transaction Log From Date' field to the current date.
  28. Set the 'Transaction Log Through Date' field to the current date.
  29. Set the 'Search Pattern 1' field to "Client A's First Name".
  30. Set the 'Search Pattern 2' field to "Client A's Last Name".
  31. Click [Show Transaction Log].
  32. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "ORM^O01" for "Client A".
  33. Close the report and the form.
  34. Access the 'Launch RxConnect' form.
  35. Click [Launch RxConnect].
  36. Validate that 'RxConnect' is displayed.
  37. Access 'RxSummary'.
  38. Find "Client A's" orders for "PRILOSEC 20 MG ORAL CAPSULE, DELAYED RELEASE" and "ADVIL 200 MG TABLET ORAL" and process the orders, which will result in an 'Rx #'s' being displayed for each order.
  39. Click 'Order Tracking'.
  40. Select the hospital that is associated with the Avatar application and click [Change and Resume].
  41. Set the 'Rx #' field to the value for the "PRILOSEC" order and press Enter.
  42. Validate the 'Order Item(s) - Drug' cell contains "Omeprazole(et PRILOSEC)".
  43. Validate the 'Order Item(s) - Strength' cell contains "20 MG".
  44. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  45. Set the 'Order Item(s) - Administer' field to "1".
  46. Click [Calculate Days Supply].
  47. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  48. Click [Post].
  49. Set the 'Apply On' field to the date that the order was created and a time that is in the evening.
  50. Set the 'Order Item(s) - Administer' field to "1".
  51. Click [Calculate Days Supply].
  52. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  53. Click [Post].
  54. Repeat steps 3j - 3s until the 29th day.
  55. On the 30th day set the 'Apply On' field to the 30th day and a time that is in the morning.
  56. Set the 'Order Item(s) - Administer' field to "1".
  57. Click [Calculate Days Supply].
  58. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  59. Click [Post].
  60. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  61. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "PRILOSEC" order.
  62. Set the 'Rx #' field to the value received for the "ADVIL" order and click [Enter].
  63. Validate the 'Order Item(s) - Drug' cell contains "Ibuprofen(et IBUPROFEN)".
  64. Validate the 'Order Item(s) - Strength' cell contains "200 MG".
  65. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  66. Set the 'Order Item(s) - Administer' field to "1".
  67. Click [Calculate Days Supply].
  68. Validate the 'Order Item(s) - Days Supply' field contains "1.0000".
  69. Click [Post].
  70. Repeat steps 3ae - 3ai through the 30th of the month.
  71. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  72. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "ADVIL" order.
  73. Wait until the files batch, this is done at a specific time each day.
  74. Once that has been completed access the 'Order Tracking' section and validate that for each 'Rx #' that the administrations were batched.
  75. Click 'Logout' and close the form.
  76. Access the 'HL7 Connection Monitor' form.
  77. Select "(Outbound) FILL DETAILS-RXCONNECT" in the 'Select Row' field.
  78. Set the 'Transaction Log From Date' field to the current date.
  79. Set the 'Transaction Log Through Date' field to the current date.
  80. Set the 'Search Pattern 1' field to "Client A's First Name".
  81. Set the 'Search Pattern 2' field to "Client A's Last Name".
  82. Click [Show Transaction Log].
  83. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "O01-RDE" for "Client A".
  84. Select "(Outbound) BILLING-RXCONNECT" in the 'Select Row' field.
  85. Set the 'Transaction Log From Date' field to the current date.
  86. Set the 'Transaction Log Through Date' field to the current date.
  87. Set the 'Search Pattern 1' field to "Client A's First Name".
  88. Set the 'Search Pattern 2' field to "Client A's Last Name".
  89. Click [Show Transaction Log].
  90. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "P03" for "Client A".
  91. Close the report and the form.
  92. Access the 'Compile Inbound HL7 Charge Batch File' form
  93. Select "Pharmacy" in the 'Compile For Which Charge Type' field.
  94. Validate a message is displayed stating "The system will now populate those fields for which a default value has been defined for the charge type selected." and click [OK].
  95. Set the 'Through Date of Service' field to the 30th day of the month and click [Process].
  96. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  97. Close the report and the form.
  98. Access the 'Post Inbound HL7 Charge Batch File' form.
  99. Select "Pharmacy" in the 'Charge Type' field.
  100. Select "Post" in the 'Action' field.
  101. Select the batch that was just compiled in the 'HL7 Charge Batch File' field.
  102. Select "Yes, but in the background after posting has finished" in the 'Run Liability Update' field and click [Process].
  103. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  104. Close the report and the form.
  105. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form.
  106. Set the 'Through Date' field to the 30th day of the month.
  107. Check off "NCPDP ***System Generated***" in the 'Roll-Up Definitions' field.
  108. Set the 'From Date' field to the first date of the month in which the orders were compiled and posted.
  109. Click [Compile Worklist].
  110. Validate a message is displayed stating "Compile complete" and click [OK].
  111. Click [Run Report].
  112. Validate that the 'Roll-Up Services Worklist' report is displayed and contains "29.00" under 'Days' and "58.00" under 'Quantity' for the "OMEPRAZOLE" charge code.
  113. Validate that the charge on the 30th of the month has been excluded from roll-up totals.
  114. Close the report.
  115. Select the 'Post Roll-Up Services Worklist' menu item.
  116. Select the through date with NCPDP rules included in the 'Through Date' field.
  117. Select any value in the 'Write Off Posting Code' field.
  118. Click [Post Worklist].
  119. Validate a 'Post Complete' message is displayed and click [OK] and close the form.
  120. Access the 'National Drug Code Reporting' form.
  121. Select "Client A" in the 'Client ID' field.
  122. Validate the 'Episode Number' field contains "Episode #1".
  123. Set the 'Service Start Date' field to the first date of the month for the charges that were billed.
  124. Set the 'Service End Date' field to the last date of the month for the charges that were billed.
  125. Select the "PRILOSEC (OMEPRAZOLE)" service in the 'Service To Record Information For' field.
  126. Click [Launch NDC Input].
  127. Validate that the 'Quantity' field and the 'Medicare Billing Units' field both contain "58".
  128. Click [Close/Cancel].
  129. Select the 'Additional Drug Information' section.
  130. Validate the 'Days Supply' field contains "29".
  131. Close the form.
Scenario 2: NCPDP Roll-Up billing via the Compile/Edit/Post/Unpost Roll-Up Services Worklist
Specific Setup:
  • myAvatar must be configured to communicate with RxConnect via Avatar HL7 and vice versa.
  • Avatar HL7 must be installed and configured with an 'ADT-RXCONNECT', 'ORDERS-RXCONNECT', 'BILLING-RXCONNECT' and 'FILLDETAILS-RXCONNECT'.
  • The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y".
  • The application must be configured for NCPDP billing.
  • A client must have a posted Inbound HL7 Charge Batch file. (Client A).
  • "Client A" must have open charges going to a NCPDP guarantor.
Steps
  1. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form.
  2. Enter the current date in the 'Through Date' field.
  3. Select "NCPDP ***System Generated***" in the 'Roll-Up Definitions' field.
  4. Click [Compile Worklist].
  5. Validate that an 'Information' message is displayed that states: "Compile complete."
  6. Click [OK].
  7. Click [Run Report].
  8. Validate the 'Roll-Up Services Worklist' report is displayed.
  9. Validate that Client A's name is displayed in the format of Last Name,First Name (PATID).
  10. Validate the contents of the Roll-Up are displayed.
  11. Close the report.
  12. Select "Post Roll-Up Services Worklist"
  13. Select the only value in the 'Through Date' field.
  14. Select any value in the 'Write Off Posting Code' field. (ex. Contractual Write Off - CR)
  15. Click [Post Worklist].
  16. Validate that a Post complete message is displayed.
  17. Click [OK] and close the form.
  18. Access the 'Client Ledger' form.
  19. Select "Client A" in the 'Client ID' field.
  20. Select "Episode" in the 'Claim/Episode/All Episodes' field.
  21. Select "Episode 1" in the 'Episode Number' field.
  22. Validate the 'From Date' field contains the admission date of the episode.
  23. Validate the 'To Date' field contains the last date of service that is included in the Client ledger.
  24. Select "Simple" in the 'Ledger Type' field.
  25. Click [Process].
  26. Validate that the 'Client Ledger Report' is displayed.
  27. Validate that the 'Client Ledger Report' contains Client A's Name in the format of Last Name,First Name next to the 'Name' label.
  28. Validate the 'Client Ledger Report' contains "Roll-Up" in the 'Claim Number' column.
  29. Validate that a 'Processing Report has Completed. Do You wish to Return to form?' message is displayed.
  30. Click the [No].
Scenario 3: NCPDP Roll-Up Billing via the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form- Ensuring excluded component services are not included on the worklist or in National Drug Code Reporting
Specific Setup:
  • myAvatar must be configured to communicate with RxConnect via Avatar HL7 and vice versa.
  • Avatar HL7 must be installed and configured with an 'ADT-RXCONNECT', 'ORDERS-RXCONNECT', 'BILLING-RXCONNECT' and 'FILLDETAILS-RXCONNECT'.
  • The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y".
  • The applications must be configured for NCPDP Billing.
  • A client must have an active inpatient episode. (Client A)
  • "Client A" must be associated with a NCPDP guarantor in the 'Financial Eligibility' form.
Steps
  1. Select "Client A" and access the Order Entry Console.
  2. Search for and select "PRILOSEC (OMEPRAZOLE) 20 MG CAPSULE, DELAYED RELEASE ORAL" in the 'New Order' field.
  3. Set the 'Dose' field to "1".
  4. Select "Capsule" in the 'Dose Unit' field.
  5. Select "Twice A Day" in the 'Freq' field.
  6. Set the 'Duration' field to "90" and click [Days].
  7. Set the 'Days Supply' field to "90".
  8. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  9. Set the 'Start Time' field to "12:00 AM".
  10. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  11. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  12. Click [Add to Scratchpad].
  13. Search for and select "ADVIL 200 MG TABLET ORAL" in the 'New Order' field.
  14. Set the 'Dose' field to "1".
  15. Select "Tablet" in the 'Dose Unit' field.
  16. Select "Every Day" in the 'Freq' field.
  17. Set the 'Duration' field to "90" and click [Days].
  18. Set the 'Days Supply' field to "90".
  19. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  20. Set the 'Start Time' field to "12:00 AM".
  21. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  22. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  23. Click [Add to Scratchpad] and [Sign].
  24. Validate the 'Order grid' contains an order for "ADVIL 200 MG ORAL TABLET 1 Tablet, EVERY DAY" and an order for "PRILOSEC (OMEPRAZOLE) 20 MG ORAL CAPSULE, DELAYED RELEASE 1 Tablet, TWICE A DAY".
  25. Access the 'HL7 Connection Monitor' form.
  26. Select "(Outbound) ORDERS-RXCONNECT" in the 'Select Row' field.
  27. Set the 'Transaction Log From Date' field to the current date.
  28. Set the 'Transaction Log Through Date' field to the current date.
  29. Set the 'Search Pattern 1' field to "Client A's First Name".
  30. Set the 'Search Pattern 2' field to "Client A's Last Name".
  31. Click [Show Transaction Log].
  32. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "ORM^O01" for "Client A".
  33. Close the report and the form.
  34. Access the 'Launch RxConnect' form.
  35. Click [Launch RxConnect].
  36. Validate that 'RxConnect' is displayed.
  37. Access 'RxSummary'.
  38. Find "Client A's" orders for "PRILOSEC 20 MG ORAL CAPSULE, DELAYED RELEASE" and "ADVIL 200 MG TABLET ORAL" and process the orders, which will result in an 'Rx #'s' being displayed for each order.
  39. Click 'Order Tracking'.
  40. Select the hospital that is associated with the Avatar application and click [Change and Resume].
  41. Set the 'Rx #' field to the value for the "PRILOSEC" order and press Enter.
  42. Validate the 'Order Item(s) - Drug' cell contains "Omeprazole(et PRILOSEC)".
  43. Validate the 'Order Item(s) - Strength' cell contains "20 MG".
  44. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  45. Set the 'Order Item(s) - Administer' field to "1".
  46. Click [Calculate Days Supply].
  47. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  48. Click [Post].
  49. Set the 'Apply On' field to the date that the order was created and a time that is in the evening.
  50. Set the 'Order Item(s) - Administer' field to "1".
  51. Click [Calculate Days Supply].
  52. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  53. Click [Post].
  54. Repeat steps 3j - 3s until the 29th day.
  55. On the 30th day set the 'Apply On' field to the 30th day and a time that is in the morning.
  56. Set the 'Order Item(s) - Administer' field to "1".
  57. Click [Calculate Days Supply].
  58. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  59. Click [Post].
  60. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  61. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "PRILOSEC" order.
  62. Set the 'Rx #' field to the value received for the "ADVIL" order and click [Enter].
  63. Validate the 'Order Item(s) - Drug' cell contains "Ibuprofen(et IBUPROFEN)".
  64. Validate the 'Order Item(s) - Strength' cell contains "200 MG".
  65. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  66. Set the 'Order Item(s) - Administer' field to "1".
  67. Click [Calculate Days Supply].
  68. Validate the 'Order Item(s) - Days Supply' field contains "1.0000".
  69. Click [Post].
  70. Repeat steps 3ae - 3ai through the 30th of the month.
  71. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  72. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "ADVIL" order.
  73. Wait until the files batch, this is done at a specific time each day.
  74. Once that has been completed access the 'Order Tracking' section and validate that for each 'Rx #' that the administrations were batched.
  75. Click 'Logout' and close the form.
  76. Access the 'HL7 Connection Monitor' form.
  77. Select "(Outbound) FILL DETAILS-RXCONNECT" in the 'Select Row' field.
  78. Set the 'Transaction Log From Date' field to the current date.
  79. Set the 'Transaction Log Through Date' field to the current date.
  80. Set the 'Search Pattern 1' field to "Client A's First Name".
  81. Set the 'Search Pattern 2' field to "Client A's Last Name".
  82. Click [Show Transaction Log].
  83. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "O01-RDE" for "Client A".
  84. Select "(Outbound) BILLING-RXCONNECT" in the 'Select Row' field.
  85. Set the 'Transaction Log From Date' field to the current date.
  86. Set the 'Transaction Log Through Date' field to the current date.
  87. Set the 'Search Pattern 1' field to "Client A's First Name".
  88. Set the 'Search Pattern 2' field to "Client A's Last Name".
  89. Click [Show Transaction Log].
  90. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "P03" for "Client A".
  91. Close the report and the form.
  92. Access the 'Compile Inbound HL7 Charge Batch File' form
  93. Select "Pharmacy" in the 'Compile For Which Charge Type' field.
  94. Validate a message is displayed stating "The system will now populate those fields for which a default value has been defined for the charge type selected." and click [OK].
  95. Set the 'Through Date of Service' field to the 30th day of the month and click [Process].
  96. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  97. Close the report and the form.
  98. Access the 'Post Inbound HL7 Charge Batch File' form.
  99. Select "Pharmacy" in the 'Charge Type' field.
  100. Select "Post" in the 'Action' field.
  101. Select the batch that was just compiled in the 'HL7 Charge Batch File' field.
  102. Select "Yes, but in the background after posting has finished" in the 'Run Liability Update' field and click [Process].
  103. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  104. Close the report and the form.
  105. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form.
  106. Set the 'Through Date' field to the 30th day of the month.
  107. Check off "NCPDP ***System Generated***" in the 'Roll-Up Definitions' field.
  108. Set the 'From Date' field to the first date of the month in which the orders were compiled and posted.
  109. Click [Compile Worklist].
  110. Validate a message is displayed stating "Compile complete" and click [OK].
  111. Click [Run Report].
  112. Validate that the 'Roll-Up Services Worklist' report is displayed and contains "29.00" under 'Days' and "58.00" under 'Quantity' for the "OMEPRAZOLE" charge code.
  113. Validate that the charge on the 30th of the month has been excluded from roll-up totals.
  114. Close the report.
  115. Select the 'Post Roll-Up Services Worklist' menu item.
  116. Select the through date with NCPDP rules included in the 'Through Date' field.
  117. Select any value in the 'Write Off Posting Code' field.
  118. Click [Post Worklist].
  119. Validate a 'Post Complete' message is displayed and click [OK] and close the form.
  120. Access the 'National Drug Code Reporting' form.
  121. Select "Client A" in the 'Client ID' field.
  122. Validate the 'Episode Number' field contains "Episode #1".
  123. Set the 'Service Start Date' field to the first date of the month for the charges that were billed.
  124. Set the 'Service End Date' field to the last date of the month for the charges that were billed.
  125. Select the "PRILOSEC (OMEPRAZOLE)" service in the 'Service To Record Information For' field.
  126. Click [Launch NDC Input].
  127. Validate that the 'Quantity' field and the 'Medicare Billing Units' field both contain "58".
  128. Click [Close/Cancel].
  129. Select the 'Additional Drug Information' section.
  130. Validate the 'Days Supply' field contains "29".
  131. Close the form.
Topics
• Compile/Edit/Post/Unpost Roll-up Services Worklist • NX • NCPDP
Update 24 Summary | Details
'Discharge' form - 'Time Verifications' registry setting
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dynamic Form - Admission - Client
  • Pre Admit
  • Discharge
  • Admission
  • Admission (Outpatient)
Scenario 1: Validating editing 'Discharge' after 'Pre Admission', 'Discharge', and 'Admission' on same date.
Specific Setup:
  • Registry Settings: The following registry settings contain a value of 'Y'.
  • Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking.
  • Avatar PM->Client Management->Movement Options->->->Time Verifications.
  • Avatar PM->Client Management->Movement Options->->->Allow Discharge To File/Edit Pre-Admits.
  • Client: A:
  • Has a 'Pre Admit' record. Note the admission time.
  • Was discharged from the Pre Admit' record in the 'Discharge' form on the same date, later than the admission time. Note the discharge time.
  • Has an 'Admission' or 'Admission (Outpatient)' record on same date, later than the discharge time.
  • Client: B:
  • Has a 'Pre Admit' record. Note the admission date and time.
Steps
  1. Open the existing ‘Discharge’ record for 'Client A'.
  2. Edit the discharge reason and/or the practitioner.
  3. Click [Submit].
  4. The form files successfully.
  5. Open ‘Discharge for 'Client B'.
  6. Set the 'Date Of Discharge' and the 'Discharge Time' to the same values noted in 'Setup'.
  7. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  8. Click [OK].
  9. Change the 'Discharge Time' to a time that is at least on minute later than the value noted in 'Setup'. Note the value.
  10. Select all other required or desired fields.
  11. Click [Submit].
  12. Open 'Admission' or 'Admission (Outpatient)' for 'Client B' to add a new record.
  13. Set the 'Preadmit/Admission Date' to the value noted in 'Setup'.
  14. Set the 'Preadmit/Admission Time' to the value noted in 'Discharge.
  15. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  16. Click [OK].
  17. Change the 'Preadmit/Admission Time' to a time that is at least on minute later than the value noted in 'Discharge'.
  18. Add data to all required or desired fields.
  19. Click [Submit].
  20. If desired, change the 'Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking' registry setting to a value of 'N' and repeat the testing.
  21. The ''Another movement (Preadmit Admission) exists for this date and time' displays' message will not be received.
Scenario 2: Validating editing 'Discharge' after 'Admission' , 'Discharge', and 'Admission' on same date.
Specific Setup:
  • Registry Settings: The following registry settings contain a value of 'Y'.
  • Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking.
  • Avatar PM->Client Management->Movement Options->->->Time Verifications.
  • Client: A:
  • Has an 'Admission' or ‘Admission (Outpatient)’ record. Note the admission time.
  • Was discharged from the above record in the 'Discharge' form on the same date, later than the admission time. Note the discharge time.
  • Has another 'Admission' or 'Admission (Outpatient)' record on same date, later than the discharge time.
  • Client: B:
  • Has an 'Admission' or ‘Admission (Outpatient)’ record. Note the admission date and time.

 

Steps
  1. Open the existing ‘Discharge’ record for 'Client A'.
  2. Edit the discharge reason and/or the practitioner.
  3. Click [Submit].
  4. The form files successfully.
  5. Open ‘Discharge for 'Client B'.
  6. Set the 'Date Of Discharge' and the 'Discharge Time' to the same values noted in 'Setup'.
  7. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  8. Click [OK].
  9. Change the 'Discharge Time' to a time that is at least on minute later than the value noted in 'Setup'. Note the value.
  10. Select all other required or desired fields.
  11. Click [Submit].
  12. Open 'Admission' or 'Admission (Outpatient)' for 'Client B' to add a new record.
  13. Set the 'Preadmit/Admission Date' to the value noted in 'Setup'.
  14. Set the 'Preadmit/Admission Time' to the value noted in 'Discharge.
  15. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  16. Click [OK].
  17. Change the 'Preadmit/Admission Time' to a time that is at least on minute later than the value noted in 'Discharge'.
  18. Add data to all required or desired fields.
  19. Click [Submit].
  20. If desired, change the 'Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking' registry setting to a value of 'N' and repeat the testing.
  21. The ''Another movement (Preadmit Admission) exists for this date and time' displays' message will not be received.
Topics
• Pre Admit • Admission (Outpatient) • Discharge
2021 Update 54 Summary | Details
'Compile/Edit/Post/Unpost Roll-Up Services Worklist' - component services
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Orders This Episode
  • HL7 Connection Monitor
  • Launch RxConnect
  • Compile Inbound HL7 Charge Batch File
  • Post Inbound HL7 Charge Batch File
  • Compile/Edit/Post/Unpost Roll-Up Services Worklist
  • National Drug Code Reporting
  • Rx Summary
  • Order Tracking
Scenario 1: NCPDP Roll-Up Billing via the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form- Ensuring excluded component services are not included on the worklist or in National Drug Code Reporting
Specific Setup:
  • myAvatar must be configured to communicate with RxConnect via Avatar HL7 and vice versa.
  • Avatar HL7 must be installed and configured with an 'ADT-RXCONNECT', 'ORDERS-RXCONNECT', 'BILLING-RXCONNECT' and 'FILLDETAILS-RXCONNECT'.
  • The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y".
  • The applications must be configured for NCPDP Billing.
  • A client must have an active inpatient episode. (Client A)
  • "Client A" must be associated with a NCPDP guarantor in the 'Financial Eligibility' form.
Steps
  1. Select "Client A" and access the Order Entry Console.
  2. Search for and select "PRILOSEC (OMEPRAZOLE) 20 MG CAPSULE, DELAYED RELEASE ORAL" in the 'New Order' field.
  3. Set the 'Dose' field to "1".
  4. Select "Capsule" in the 'Dose Unit' field.
  5. Select "Twice A Day" in the 'Freq' field.
  6. Set the 'Duration' field to "90" and click [Days].
  7. Set the 'Days Supply' field to "90".
  8. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  9. Set the 'Start Time' field to "12:00 AM".
  10. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  11. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  12. Click [Add to Scratchpad].
  13. Search for and select "ADVIL 200 MG TABLET ORAL" in the 'New Order' field.
  14. Set the 'Dose' field to "1".
  15. Select "Tablet" in the 'Dose Unit' field.
  16. Select "Every Day" in the 'Freq' field.
  17. Set the 'Duration' field to "90" and click [Days].
  18. Set the 'Days Supply' field to "90".
  19. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  20. Set the 'Start Time' field to "12:00 AM".
  21. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  22. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  23. Click [Add to Scratchpad] and [Sign].
  24. Validate the 'Order grid' contains an order for "ADVIL 200 MG ORAL TABLET 1 Tablet, EVERY DAY" and an order for "PRILOSEC (OMEPRAZOLE) 20 MG ORAL CAPSULE, DELAYED RELEASE 1 Tablet, TWICE A DAY".
  25. Access the 'HL7 Connection Monitor' form.
  26. Select "(Outbound) ORDERS-RXCONNECT" in the 'Select Row' field.
  27. Set the 'Transaction Log From Date' field to the current date.
  28. Set the 'Transaction Log Through Date' field to the current date.
  29. Set the 'Search Pattern 1' field to "Client A's First Name".
  30. Set the 'Search Pattern 2' field to "Client A's Last Name".
  31. Click [Show Transaction Log].
  32. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "ORM^O01" for "Client A".
  33. Close the report and the form.
  34. Access the 'Launch RxConnect' form.
  35. Click [Launch RxConnect].
  36. Validate that 'RxConnect' is displayed.
  37. Access 'RxSummary'.
  38. Find "Client A's" orders for "PRILOSEC 20 MG ORAL CAPSULE, DELAYED RELEASE" and "ADVIL 200 MG TABLET ORAL" and process the orders, which will result in an 'Rx #'s' being displayed for each order.
  39. Click 'Order Tracking'.
  40. Select the hospital that is associated with the Avatar application and click [Change and Resume].
  41. Set the 'Rx #' field to the value for the "PRILOSEC" order and press Enter.
  42. Validate the 'Order Item(s) - Drug' cell contains "Omeprazole(et PRILOSEC)".
  43. Validate the 'Order Item(s) - Strength' cell contains "20 MG".
  44. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  45. Set the 'Order Item(s) - Administer' field to "1".
  46. Click [Calculate Days Supply].
  47. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  48. Click [Post].
  49. Set the 'Apply On' field to the date that the order was created and a time that is in the evening.
  50. Set the 'Order Item(s) - Administer' field to "1".
  51. Click [Calculate Days Supply].
  52. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  53. Click [Post].
  54. Repeat steps 3j - 3s until the 29th day.
  55. On the 30th day set the 'Apply On' field to the 30th day and a time that is in the morning.
  56. Set the 'Order Item(s) - Administer' field to "1".
  57. Click [Calculate Days Supply].
  58. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  59. Click [Post].
  60. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  61. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "PRILOSEC" order.
  62. Set the 'Rx #' field to the value received for the "ADVIL" order and click [Enter].
  63. Validate the 'Order Item(s) - Drug' cell contains "Ibuprofen(et IBUPROFEN)".
  64. Validate the 'Order Item(s) - Strength' cell contains "200 MG".
  65. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  66. Set the 'Order Item(s) - Administer' field to "1".
  67. Click [Calculate Days Supply].
  68. Validate the 'Order Item(s) - Days Supply' field contains "1.0000".
  69. Click [Post].
  70. Repeat steps 3ae - 3ai through the 30th of the month.
  71. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  72. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "ADVIL" order.
  73. Wait until the files batch, this is done at a specific time each day.
  74. Once that has been completed access the 'Order Tracking' section and validate that for each 'Rx #' that the administrations were batched.
  75. Click 'Logout' and close the form.
  76. Access the 'HL7 Connection Monitor' form.
  77. Select "(Outbound) FILL DETAILS-RXCONNECT" in the 'Select Row' field.
  78. Set the 'Transaction Log From Date' field to the current date.
  79. Set the 'Transaction Log Through Date' field to the current date.
  80. Set the 'Search Pattern 1' field to "Client A's First Name".
  81. Set the 'Search Pattern 2' field to "Client A's Last Name".
  82. Click [Show Transaction Log].
  83. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "O01-RDE" for "Client A".
  84. Select "(Outbound) BILLING-RXCONNECT" in the 'Select Row' field.
  85. Set the 'Transaction Log From Date' field to the current date.
  86. Set the 'Transaction Log Through Date' field to the current date.
  87. Set the 'Search Pattern 1' field to "Client A's First Name".
  88. Set the 'Search Pattern 2' field to "Client A's Last Name".
  89. Click [Show Transaction Log].
  90. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "P03" for "Client A".
  91. Close the report and the form.
  92. Access the 'Compile Inbound HL7 Charge Batch File' form
  93. Select "Pharmacy" in the 'Compile For Which Charge Type' field.
  94. Validate a message is displayed stating "The system will now populate those fields for which a default value has been defined for the charge type selected." and click [OK].
  95. Set the 'Through Date of Service' field to the 30th day of the month and click [Process].
  96. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  97. Close the report and the form.
  98. Access the 'Post Inbound HL7 Charge Batch File' form.
  99. Select "Pharmacy" in the 'Charge Type' field.
  100. Select "Post" in the 'Action' field.
  101. Select the batch that was just compiled in the 'HL7 Charge Batch File' field.
  102. Select "Yes, but in the background after posting has finished" in the 'Run Liability Update' field and click [Process].
  103. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  104. Close the report and the form.
  105. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form.
  106. Set the 'Through Date' field to the 30th day of the month.
  107. Check off "NCPDP ***System Generated***" in the 'Roll-Up Definitions' field.
  108. Set the 'From Date' field to the first date of the month in which the orders were compiled and posted.
  109. Click [Compile Worklist].
  110. Validate a message is displayed stating "Compile complete" and click [OK].
  111. Click [Run Report].
  112. Validate that the 'Roll-Up Services Worklist' report is displayed and contains "29.00" under 'Days' and "58.00" under 'Quantity' for the "OMEPRAZOLE" charge code.
  113. Validate that the charge on the 30th of the month has been excluded from roll-up totals.
  114. Close the report.
  115. Select the 'Post Roll-Up Services Worklist' menu item.
  116. Select the through date with NCPDP rules included in the 'Through Date' field.
  117. Select any value in the 'Write Off Posting Code' field.
  118. Click [Post Worklist].
  119. Validate a 'Post Complete' message is displayed and click [OK] and close the form.
  120. Access the 'National Drug Code Reporting' form.
  121. Select "Client A" in the 'Client ID' field.
  122. Validate the 'Episode Number' field contains "Episode #1".
  123. Set the 'Service Start Date' field to the first date of the month for the charges that were billed.
  124. Set the 'Service End Date' field to the last date of the month for the charges that were billed.
  125. Select the "PRILOSEC (OMEPRAZOLE)" service in the 'Service To Record Information For' field.
  126. Click [Launch NDC Input].
  127. Validate that the 'Quantity' field and the 'Medicare Billing Units' field both contain "58".
  128. Click [Close/Cancel].
  129. Select the 'Additional Drug Information' section.
  130. Validate the 'Days Supply' field contains "29".
  131. Close the form.
Scenario 2: NCPDP Roll-Up Billing via the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form- Ensuring excluded component services are not included on the worklist or in National Drug Code Reporting
Specific Setup:
  • myAvatar must be configured to communicate with RxConnect via Avatar HL7 and vice versa.
  • Avatar HL7 must be installed and configured with an 'ADT-RXCONNECT', 'ORDERS-RXCONNECT', 'BILLING-RXCONNECT' and 'FILLDETAILS-RXCONNECT'.
  • The 'Avatar PM->Billing->Electronic Billing->NCPDP->->Enable NCPDP Billing' registry setting must be set to "Y".
  • The applications must be configured for NCPDP Billing.
  • A client must have an active inpatient episode. (Client A)
  • "Client A" must be associated with a NCPDP guarantor in the 'Financial Eligibility' form.
Steps
  1. Select "Client A" and access the Order Entry Console.
  2. Search for and select "PRILOSEC (OMEPRAZOLE) 20 MG CAPSULE, DELAYED RELEASE ORAL" in the 'New Order' field.
  3. Set the 'Dose' field to "1".
  4. Select "Capsule" in the 'Dose Unit' field.
  5. Select "Twice A Day" in the 'Freq' field.
  6. Set the 'Duration' field to "90" and click [Days].
  7. Set the 'Days Supply' field to "90".
  8. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  9. Set the 'Start Time' field to "12:00 AM".
  10. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  11. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  12. Click [Add to Scratchpad].
  13. Search for and select "ADVIL 200 MG TABLET ORAL" in the 'New Order' field.
  14. Set the 'Dose' field to "1".
  15. Select "Tablet" in the 'Dose Unit' field.
  16. Select "Every Day" in the 'Freq' field.
  17. Set the 'Duration' field to "90" and click [Days].
  18. Set the 'Days Supply' field to "90".
  19. Set the 'Start Date' field to a date that is two months in the past and starts on the first of the month.
  20. Set the 'Start Time' field to "12:00 AM".
  21. Validate the 'Stop Date' field contains a date that is 90 days in the future of the 'Start Date'.
  22. Validate the 'Stop Time' field contains a time that is one minute prior than the 'Start Time'.
  23. Click [Add to Scratchpad] and [Sign].
  24. Validate the 'Order grid' contains an order for "ADVIL 200 MG ORAL TABLET 1 Tablet, EVERY DAY" and an order for "PRILOSEC (OMEPRAZOLE) 20 MG ORAL CAPSULE, DELAYED RELEASE 1 Tablet, TWICE A DAY".
  25. Access the 'HL7 Connection Monitor' form.
  26. Select "(Outbound) ORDERS-RXCONNECT" in the 'Select Row' field.
  27. Set the 'Transaction Log From Date' field to the current date.
  28. Set the 'Transaction Log Through Date' field to the current date.
  29. Set the 'Search Pattern 1' field to "Client A's First Name".
  30. Set the 'Search Pattern 2' field to "Client A's Last Name".
  31. Click [Show Transaction Log].
  32. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "ORM^O01" for "Client A".
  33. Close the report and the form.
  34. Access the 'Launch RxConnect' form.
  35. Click [Launch RxConnect].
  36. Validate that 'RxConnect' is displayed.
  37. Access 'RxSummary'.
  38. Find "Client A's" orders for "PRILOSEC 20 MG ORAL CAPSULE, DELAYED RELEASE" and "ADVIL 200 MG TABLET ORAL" and process the orders, which will result in an 'Rx #'s' being displayed for each order.
  39. Click 'Order Tracking'.
  40. Select the hospital that is associated with the Avatar application and click [Change and Resume].
  41. Set the 'Rx #' field to the value for the "PRILOSEC" order and press Enter.
  42. Validate the 'Order Item(s) - Drug' cell contains "Omeprazole(et PRILOSEC)".
  43. Validate the 'Order Item(s) - Strength' cell contains "20 MG".
  44. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  45. Set the 'Order Item(s) - Administer' field to "1".
  46. Click [Calculate Days Supply].
  47. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  48. Click [Post].
  49. Set the 'Apply On' field to the date that the order was created and a time that is in the evening.
  50. Set the 'Order Item(s) - Administer' field to "1".
  51. Click [Calculate Days Supply].
  52. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  53. Click [Post].
  54. Repeat steps 3j - 3s until the 29th day.
  55. On the 30th day set the 'Apply On' field to the 30th day and a time that is in the morning.
  56. Set the 'Order Item(s) - Administer' field to "1".
  57. Click [Calculate Days Supply].
  58. Validate the 'Order Item(s) - Days Supply' field contains "0.5000".
  59. Click [Post].
  60. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  61. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "PRILOSEC" order.
  62. Set the 'Rx #' field to the value received for the "ADVIL" order and click [Enter].
  63. Validate the 'Order Item(s) - Drug' cell contains "Ibuprofen(et IBUPROFEN)".
  64. Validate the 'Order Item(s) - Strength' cell contains "200 MG".
  65. Set the 'Apply On' field to the date that the order was created and a time that is in the morning.
  66. Set the 'Order Item(s) - Administer' field to "1".
  67. Click [Calculate Days Supply].
  68. Validate the 'Order Item(s) - Days Supply' field contains "1.0000".
  69. Click [Post].
  70. Repeat steps 3ae - 3ai through the 30th of the month.
  71. In the 'Tracking Information area, set the 'Start Date' to the first date of the order.
  72. Validate that the 'Tracking Information' grid and the 'Billing(current)' grid contains the administrations that were done for the "ADVIL" order.
  73. Wait until the files batch, this is done at a specific time each day.
  74. Once that has been completed access the 'Order Tracking' section and validate that for each 'Rx #' that the administrations were batched.
  75. Click 'Logout' and close the form.
  76. Access the 'HL7 Connection Monitor' form.
  77. Select "(Outbound) FILL DETAILS-RXCONNECT" in the 'Select Row' field.
  78. Set the 'Transaction Log From Date' field to the current date.
  79. Set the 'Transaction Log Through Date' field to the current date.
  80. Set the 'Search Pattern 1' field to "Client A's First Name".
  81. Set the 'Search Pattern 2' field to "Client A's Last Name".
  82. Click [Show Transaction Log].
  83. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "O01-RDE" for "Client A".
  84. Select "(Outbound) BILLING-RXCONNECT" in the 'Select Row' field.
  85. Set the 'Transaction Log From Date' field to the current date.
  86. Set the 'Transaction Log Through Date' field to the current date.
  87. Set the 'Search Pattern 1' field to "Client A's First Name".
  88. Set the 'Search Pattern 2' field to "Client A's Last Name".
  89. Click [Show Transaction Log].
  90. Validate the 'HL7 Outbound Transaction Log' report is displayed and contains two messages with an 'Event Type' of "P03" for "Client A".
  91. Close the report and the form.
  92. Access the 'Compile Inbound HL7 Charge Batch File' form
  93. Select "Pharmacy" in the 'Compile For Which Charge Type' field.
  94. Validate a message is displayed stating "The system will now populate those fields for which a default value has been defined for the charge type selected." and click [OK].
  95. Set the 'Through Date of Service' field to the 30th day of the month and click [Process].
  96. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  97. Close the report and the form.
  98. Access the 'Post Inbound HL7 Charge Batch File' form.
  99. Select "Pharmacy" in the 'Charge Type' field.
  100. Select "Post" in the 'Action' field.
  101. Select the batch that was just compiled in the 'HL7 Charge Batch File' field.
  102. Select "Yes, but in the background after posting has finished" in the 'Run Liability Update' field and click [Process].
  103. Validate the 'Inbound HL7 Charge Batch File Details Report' is displayed and contains the charges for the "PRILOSEC (OMEPRAZOLE)" and "ADVIL (IBUPROFEN)" orders.
  104. Close the report and the form.
  105. Access the 'Compile/Edit/Post/Unpost Roll-Up Services Worklist' form.
  106. Set the 'Through Date' field to the 30th day of the month.
  107. Check off "NCPDP ***System Generated***" in the 'Roll-Up Definitions' field.
  108. Set the 'From Date' field to the first date of the month in which the orders were compiled and posted.
  109. Click [Compile Worklist].
  110. Validate a message is displayed stating "Compile complete" and click [OK].
  111. Click [Run Report].
  112. Validate that the 'Roll-Up Services Worklist' report is displayed and contains "29.00" under 'Days' and "58.00" under 'Quantity' for the "OMEPRAZOLE" charge code.
  113. Validate that the charge on the 30th of the month has been excluded from roll-up totals.
  114. Close the report.
  115. Select the 'Post Roll-Up Services Worklist' menu item.
  116. Select the through date with NCPDP rules included in the 'Through Date' field.
  117. Select any value in the 'Write Off Posting Code' field.
  118. Click [Post Worklist].
  119. Validate a 'Post Complete' message is displayed and click [OK] and close the form.
  120. Access the 'National Drug Code Reporting' form.
  121. Select "Client A" in the 'Client ID' field.
  122. Validate the 'Episode Number' field contains "Episode #1".
  123. Set the 'Service Start Date' field to the first date of the month for the charges that were billed.
  124. Set the 'Service End Date' field to the last date of the month for the charges that were billed.
  125. Select the "PRILOSEC (OMEPRAZOLE)" service in the 'Service To Record Information For' field.
  126. Click [Launch NDC Input].
  127. Validate that the 'Quantity' field and the 'Medicare Billing Units' field both contain "58".
  128. Click [Close/Cancel].
  129. Select the 'Additional Drug Information' section.
  130. Validate the 'Days Supply' field contains "29".
  131. Close the form.
Topics
• Compile/Edit/Post/Unpost Roll-up Services Worklist • NX • NCPDP
2021 Update 85 Summary | Details
The 'Diagnosis' and 'Enrollment Diagnosis' forms.
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Diagnosis
  • HL7 Connection Monitor
Scenario 1: Client Diagnosis Web Service - Validating site specific section modeling field - Initially required
Specific Setup:
  • An existing client is identified. Note client and episode number.
  • A valid ICD-9 code, ICD-9 description, ICD-10 code, ICD-10 description, SNOMED code, SNOMED description and IMO code are identified for web service request.
  • Dictionary Update - Input Dictionary Codes section:
  • Enter a minimum of two dictionary codes and values. Note all the codes and values added.
  • File = Client
  • Data Element by number
  • Data Element = 31032.1.
  • Site Specific Section Modeling - (PATIENT590) Additional Diagnosis Information - 'Prompt Definition' tab:
  • The site specific field 'SS Diagnosis Single Select Dictionary 1' is added with following options.
  • Set Label to any desired value. Note the label.
  • Set the 'Initially Required' to "Yes".
  • Set the 'Lock Dictionary' Values to "Yes".
  • Diagnosis -'Additional Diagnosis Information' section:
  • Make sure the 'SS Diagnosis Single Select Dictionary 1' is added with the same label defined in the above section.
Steps
  1. Open SoapUI or any other web service tool.
  2. Use the WEBSVC.Diagnosis - AddClientDiagnosis web service.
  3. Enter desired SYSTEM CODE, UserName and Password.
  4. Enter Client ID from the setup section.
  5. Enter client's episode number in the 'EpisodeNumber' from the setup section.
  6. Enter desired value in the 'Type Of Diagnosis'. Note the value.
  7. Enter date of client's episode or after in the 'Date Of Diagnosis'. Note the value.
  8. Enter desired time in the 'Time Of Diagnosis'. Note the value.
  9. Enter desired clinician in the 'Diagnosing Clinician'. Note the value.
  10. Enter desired value in the 'Status' field. Note the value.
  11. Enter desired value in the 'Bill Order'. Note the value.
  12. Enter desired value in the 'SSDiagnosisDict1'. Note the value.
  13. Enter 'ICD9Code' from the setup section.
  14. Enter 'ICD10Code' from the setup section.
  15. Enter 'SNOMEDCode' from the setup section.
  16. Send a request to create a diagnosis record for an existing client.
  17. Verify the web service files successfully.
  18. Login to Avatar.
  19. Open the 'Diagnosis' form.
  20. Verify the diagnosis record is created for the client as specified in the web service request.
  21. Select the 'Additional Diagnosis Information' section.
  22. Verify the new Site Specific Single Select Dictionary field is populated correctly with the value entered through web service request.
  23. Close the form.
Scenario 2: Modeled forms support 'First Ever Diagnosis', 'Classification', and 'Problem List'
Specific Setup:
  • Modeled form with a Diagnosis section and with the following fields added via "Modeling" options.
  • Diagnosis mapped from the product Diagnosis form.
  • Up to 5 First Ever Diagnosis columns
  • Up to 5 Classification columns
  • Up to 5 AddToProblemList columns
  • Registry Settings that may impact the modeled form are:
  • Avatar PM->Client Information->Diagnosis->->->Require Classification.
  • Avatar PM->Client Information->Diagnosis->->->Enable Diagnosis Filtering based on Classification. Note that this registry setting can never be disabled once it is enabled.
  • Avatar CWS->Problem List->->->->Problem Classification Required.
Steps
  1. Open the modeled form.
  2. Complete required fields and go to the "Diagnosis" section.
  3. Enter a "Diagnosis" of "B20" for "AIDS".
  4. Set "First Ever Dx" field to any value.
  5. Select a "Classification".
  6. Select a "Problem Classification".
  7. Select "Final" in the "Draft/final" field.
  8. Click [OK] on the "Selecting "Final" prevents future edits" dialog.
  9. Click [Submit].
  10. Access the 'Diagnosis' form.
  11. Verify that the 'Diagnosis pre-display' is displayed.
  12. Validate that one row is displayed in the pre-display.
  13. Select the row and click [Edit].
  14. Validate that the 'Diagnoses' grid contains a 'Description' of "AIDS" for row 1.
Scenario 3: Diagnoses entered via an Inbound ADT HL7 message
Specific Setup:
  • Set the 'Avatar PM->Client Information->Diagnosis->->->Add First Ever Diagnosis Check' registry setting must be set to "1".
  • Please log out of the application and log back in after completing the above configuration.
  • There must be an Inbound ADT connection for 'ADT-GENERIC'.
  • Ensure the 'Program Map' For Processing Inbound ADT' form contains a program map for a 'Receiving Facility (MSH-6.1)' is "98", 'Patient Class (PV1-2.1)' is "I" and the 'Program' is a value other than the one that "Client A" is currently in.
  • A client must have an active inpatient episode (Client A).
Steps
  1. Validate an ADT inbound message was sent for "Client A" that contains an 'ICD10' diagnosis code of "B20".
  2. Access the 'HL7 Connection Monitor' form.
  3. Select "ADT-GENERIC" Inbound connection from the 'Select Row' field,
  4. Click [Show Transaction Log].
  5. Validate the 'HL7 Inbound Transaction Report' contains an 'Event Type' of "A08".
  6. Validate the 'HL7 Inbound Transaction Report' contains a 'Filing Status' value of "OK Diagnosis Information - 'Is this the first ever diagnosis?' is missing for row: 1.|".
  7. Validate the 'HL7 Inbound Transaction Report' contains "Client A's" name in the format of "Last Name^First Name" next to 'Name'.
  8. Close the report.
  9. Set the 'Avatar PM->Client Information->Diagnosis->->->Add First Ever Diagnosis Check' registry setting must be set to "2".
  10. Please log out of the application and log back in.
  11. Validate an ADT inbound message was sent for "Client A" that contains an 'ICD10' diagnosis code of "B20".
  12. Access the 'HL7 Connection Monitor' form.
  13. Select "ADT-GENERIC" Inbound connection from the 'Select Row' field,
  14. Click [Show Transaction Log].
  15. Validate the 'HL7 Inbound Transaction Report' contains an 'Event Type' of "A08".
  16. Validate the 'HL7 Inbound Transaction Report' contains a 'Filing Status' value of "OK".
  17. Validate the 'HL7 Inbound Transaction Report' contains "Client A's" name in the format of "Last Name^First Name" next to 'Name'.
  18. Close the report.
  19. Select "Client A" and access the 'Diagnosis' form.
  20. Verify that the 'Diagnosis pre-display' is displayed.
  21. Validate that one row is displayed in the pre-display.
  22. Select the row and click [Edit].
  23. Validate that the 'Diagnoses' grid contains a 'Description' of "AIDS" for row 1.
Topics
• Web Services • Diagnosis • HL7
2021 Update 124 Summary | Details
Accounts Receivable Console - Posting/Adjustment Codes Definition
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • AR Console Configuration
  • AR Console User Defaults Setup
  • Posting/Adjustment Codes Definition
  • Dynamic Form - Admission - Client
  • Admission
  • Diagnosis
  • Financial Eligibility
  • Client Charge Input
  • Guarantors/Payors
  • Practitioner Numbers By Guarantor And Program
  • Program Maintenance
  • Dynamic Form - Edit Service Fee Definition
  • Client Ledger
  • System Task Scheduler
  • User Definition
Scenario 1: Validate 'Posting Code' availability in 'Post Transaction' pop-up screen.
Specific Setup:

Identify a client with an unpaid claim. Note the claim number, client last name, guarantor and program.

The tester has been assigned the corresponding 'Client Last Name Initials to be Worked', 'Guarantor' and 'Program(s)' in 'AR Console User Defaults Setup'.

The tester has access to the 'Accounts Receivable Console' widget.

The 'System Task Scheduler', 'Auto AR Batch Update' was processed after the above claim was created in billing.

Sign out of the system and back in after the 'System Task Scheduler', 'Auto AR Batch Update' has completed.

'Posting/Adjustment Codes Definition' has been used to create 'payment codes', 'adjustment codes' and 'transfer codes'.

Steps
  1. Open 'Accounts Receivable Console'.
  2. Enter the 'Claim #'.
  3. Click [Search].
  4. Verify that the claim is added to the 'Claims with Outstanding Receivables' grid.
  5. Select the claim in the 'Claims with Outstanding Receivables' grid.
  6. Verify that the service(s) display in the 'Claim Service Information' grid.
  7. Click [Post Transaction].
  8. Enter the 'Posting Date'.
  9. Enter the 'Date of Receipt'.
  10. Note the 'Current Balance'.
  11. Enter an 'Amount' that will not pay the service in full.
  12. Enter a question mark in 'Posting Code'.
  13. Verify that the 'Posting/Adjustment Codes Definitions' display.
  14. Select a value from the 'Posting/Adjustment Codes Definitions'.
  15. Note the 'New Balance'.
  16. Click [New Row].
  17. Enter an amount equal to the 'New Balance'.
  18. Enter a question mark in 'Posting Code'.
  19. Verify that the 'Posting/Adjustment Codes Definitions' display.
  20. Select a different value from the 'Posting/Adjustment Codes Definitions'.
  21. Note the 'New Balance' is $0.00.
  22. Click [Save].
Topics
• Accounts Receivable Management • myAvatar/myAvatar NX
2021 Update 137 Summary | Details
Discharge - closing form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dynamic Form - Admission - Client
  • Pre Admit
  • Discharge
  • Admission
  • Admission (Outpatient)
Scenario 1: Validating editing 'Discharge' after 'Pre Admission', 'Discharge', and 'Admission' on same date.
Specific Setup:
  • Registry Settings: The following registry settings contain a value of 'Y'.
  • Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking.
  • Avatar PM->Client Management->Movement Options->->->Allow Discharge To File/Edit Pre-Admits.
  • Client: A:
  • Has a 'Pre Admit' record. Note the admission time.
  • Was discharged from the Pre Admit' record in the 'Discharge' form on the same date, later than the admission time. Note the discharge time.
  • Has an 'Admission' or 'Admission (Outpatient)' record on same date, later than the discharge time.
  • Client: B:
  • Has a 'Pre Admit' record. Note the admission date and time.
Steps
  1. Open the existing ‘Discharge’ record for 'Client A'.
  2. Edit the discharge reason and/or the practitioner.
  3. Click [Submit].
  4. The form files successfully.
  5. Open ‘Discharge for 'Client B'.
  6. Set the 'Date Of Discharge' and the 'Discharge Time' to the same values noted in 'Setup'.
  7. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  8. Click [OK].
  9. Change the 'Discharge Time' to a time that is at least on minute later than the value noted in 'Setup'. Note the value.
  10. Select all other required or desired fields.
  11. Click [Submit].
  12. Open 'Admission' or 'Admission (Outpatient)' for 'Client B' to add a new record.
  13. Set the 'Preadmit/Admission Date' to the value noted in 'Setup'.
  14. Set the 'Preadmit/Admission Time' to the value noted in 'Discharge.
  15. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  16. Click [OK].
  17. Change the 'Preadmit/Admission Time' to a time that is at least on minute later than the value noted in 'Discharge'.
  18. Add data to all required or desired fields.
  19. Click [Submit].
  20. If desired, change the 'Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking' registry setting to a value of 'N' and repeat the testing.
  21. The ''Another movement (Preadmit Admission) exists for this date and time' displays' message will not be received.
Scenario 2: Validating editing 'Discharge' after 'Admission' , 'Discharge', and 'Admission' on same date.
Specific Setup:
  • Registry Settings: The following registry settings contain a value of 'Y'.
  • Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking.
  • Client: A:
  • Has an 'Admission' or ‘Admission (Outpatient)’ record. Note the admission time.
  • Was discharged from the above record in the 'Discharge' form on the same date, later than the admission time. Note the discharge time.
  • Has another 'Admission' or 'Admission (Outpatient)' record on same date, later than the discharge time.
  • Client: B:
  • Has an 'Admission' or ‘Admission (Outpatient)’ record. Note the admission date and time.

 

Steps
  1. Open the existing ‘Discharge’ record for 'Client A'.
  2. Edit the discharge reason and/or the practitioner.
  3. Click [Submit].
  4. The form files successfully.
  5. Open ‘Discharge for 'Client B'.
  6. Set the 'Date Of Discharge' and the 'Discharge Time' to the same values noted in 'Setup'.
  7. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  8. Click [OK].
  9. Change the 'Discharge Time' to a time that is at least on minute later than the value noted in 'Setup'. Note the value.
  10. Select all other required or desired fields.
  11. Click [Submit].
  12. Open 'Admission' or 'Admission (Outpatient)' for 'Client B' to add a new record.
  13. Set the 'Preadmit/Admission Date' to the value noted in 'Setup'.
  14. Set the 'Preadmit/Admission Time' to the value noted in 'Discharge.
  15. Validate that the message 'Another movement (Preadmit Admission) exists for this date and time' displays.
  16. Click [OK].
  17. Change the 'Preadmit/Admission Time' to a time that is at least on minute later than the value noted in 'Discharge'.
  18. Add data to all required or desired fields.
  19. Click [Submit].
  20. If desired, change the 'Avatar PM->Client Management->Movement Options->->->Duplicate Date/Time Checking' registry setting to a value of 'N' and repeat the testing.
  21. The ''Another movement (Preadmit Admission) exists for this date and time' displays' message will not be received.
Service Fee/Cross Reference Maintenance - Guarantor Definitions
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Service Fee/Cross Reference and Guarantor Definition Export
  • File Import
  • Dynamic Form - Restore Definition
Scenario 1: File Import - Service Guarantor Definitions - 'Import Process Type' Registry Setting
Specific Setup:
  • Registry Settings:
  • The 'Avatar PM->System Maintenance->File Import->->->Import Process Type'' has the following values: 'FU&GU'.
  • Service Fee/Cross Reference and Guarantor Definition Export has been used to export the 'Guarantor Definition. Select a service code with a definition to update.
  • File Import:
  • A 'Service Guarantor Definition' file exists to update the guarantor fee for the service code.
Steps
  1. Open 'File Import'.
  2. Select 'Service Guarantor Definitions' in 'File Type'.
  3. Upload/compile/post the 'Service Guarantor Definition' file.
  4. Open 'Service Fee/Cross Reference Maintenance'.
  5. Select the 'Guarantor Definitions' section.
  6. Click [Guarantor Definitions Report].
  7. Validate that the fee for the service code was updated.
  8. Close the report.
  9. Select the 'Restore Definitions' section.
  10. Click [Restore Maximum Liability Assignment Definition That Existed Prior to Last File Import].
  11. Select the 'Guarantor Definitions' section.
  12. Click [Guarantor Definitions Report].
  13. Validate that the fees were restored.
Topics
• Discharge • NX • Registry Settings • Service Fee/Cross Reference Maintenance • File Import
2021 Update 140 Summary | Details
Edit service Information - Enable 'Admission vs. Service Program' Functionality registry setting
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Program Maintenance
  • Dynamic Form - Admission - Client
  • Admission (Outpatient)
  • Client Charge Input
  • Program Transfer (OutPatient)
  • Client Ledger
  • Dynamic Form - Edit Service Information - Select Service(s) to Edit
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 in to 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 in to 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.
Scenario 2: Edit Service Program - Editing service program to another associated program - 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 in to 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.
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 were associated with the admission program at the time of service creation.
  7. Change the service program.
  8. Enter desired practitioner.
  9. Submit the form.
  10. Verify the form submits successfully.
Topics
• Registry Settings • Program Maintenance • Edit Service Information • Program Transfer • NX
2021 Update 141 Summary | Details
Service Panel Charge Input - Incident-To Practitioner
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Practitioner Enrollment
  • User Definition
  • Incident-To Practitioner Daily Log
  • Dynamic Form - Edit Service Fee Definition
  • Service Panel
  • Dynamic Form - Admission - Client
  • Admission
  • Service Panel Charge Input
  • SQL Query/Reporting
Scenario 1: Service Panel Charge Input - Filing incident-to practitioner with the panel services - 'Enable Incident-To Practitioner' registry setting is set to "YC"
Specific Setup:
  • Registry Setting:
  • The 'Enable Incident-To Practitioner' registry setting is set to 'YC'.
  • The 'Service Panel Charge Input - Fields To Include' registry setting is set to desired value to add 'Service Start Time' and 'Service End Time' fields to 'Service Panel Charge Input' form.
  • Practitioner Enrollment:
  • Create a new practitioner or edit an existing practitioner. Note the practitioner id and practitioner name.
  • The 'Incident-To Practitioner' field is set to "Yes" for the practitioner identified above.
  • Service Code:
  • Parent service codes should be defined before they are used in this form. Note the service code.
  • Service Fee/Cross Reference:
  • The service fee is defined for the service code.
  • The 'Incident-To' field is set to Y.
Steps
  1. Open the 'Incident-To Practitioner Daily Log' form.
  2. Select the 'Add Daily Log Entry' tab.
  3. Select the practitioner identified in the setup section. Note the practitioner.
  4. Select the desired date to 'Date' field. Note the date.
  5. Select 'Start Time'. Note the time.
  6. Select the 'End time'. Note the time.
  7. Select desired 'Location'. Note the location.
  8. Click [File Entry].
  9. Validate the 'Information' dialogue contains 'Filed Successfully' message.
  10. Click [OK].
  11. Open the 'Service Panel' form.
  12. Select 'Add' In the 'Add New or Edit Existing Service Panel' field.
  13. Select an existing service code in the 'Service Code' field (i.e. Service Code 1).
  14. Enter desired date based on the date defined in the 'Effective Date' field.
  15. Select 'Yes' in the 'File The Parent Service With This Panel' field.
  16. Select another existing service code from the 'Select Service Code To Add To Panel' search box (i.e. Service Code 2).
  17. Click [Add selected Service To Panel].
  18. Verify the service code selected is displayed in the 'Service Panel' item.
  19. Submit the form.
  20. Verify that the form submitted successfully.
  21. Open the 'Service Panel Charge Input' form.
  22. Enter desired date in the 'Date Of Service' field.
  23. Select the client in the 'Client ID' field.
  24. Enter 'Service Start Time' based on the time range defined for the Incident-To Practitioner in the 'Incident-To Practitioner Daily Log' form.
  25. Enter 'Service End Time' based on the time range defined for the Incident-To Practitioner in the 'Incident-To Practitioner Daily Log' form.
  26. Select the 'Panel Description'.
  27. Select the 'Panel Service(s)'.
  28. Select the 'Incident-To Practitioner'.
  29. Verify the panel service files successfully.
  30. Open the 'Crystal Report' or any other SQL data viewer.
  31. Query the 'SYSTEM.billing_tx_history' SQL table.
  32. Verify the Incident To practitioner is filed correctly for the service.
Scenario 2: Service Panel Charge Input - Filing incident-to practitioner with the panel services - 'Enable Incident-To Practitioner' registry setting is set to "Y"
Specific Setup:
  • Registry Setting:
  • The 'Enable Incident-To Practitioner' registry setting is set to 'Y'.
  • The 'Service Panel Charge Input - Fields To Include' registry setting is set to desired value to add 'Service Start Time' and 'Service End Time' fields to 'Service Panel Charge Input' form.
  • Practitioner Enrollment:
  • Create a new practitioner or edit an existing practitioner. Note the practitioner id and practitioner name.
  • The 'Incident-To Practitioner' field is set to "Yes" for the practitioner identified above.
  • Service Code:
  • Parent service codes should be defined before they are used in this form. Note the service code.
  • Service Fee/Cross Reference:
  • The service fee is defined for the service code.
  • The 'Is This Incident-To Service' field is set to 'Y'.
Steps
  1. Open the 'Incident-To Practitioner Daily Log' form.
  2. Select the 'Add Daily Log Entry' tab.
  3. Select the practitioner identified in the setup section. Note the practitioner.
  4. Select the desired date to 'Date' field. Note the date.
  5. Select 'Start Time'. Note the time.
  6. Select the 'End time'. Note the time.
  7. Select desired 'Location'. Note the location.
  8. Click [File Entry].
  9. Validate the 'Information' dialogue contains 'Filed Successfully' message.
  10. Click [OK].
  11. Open the 'Service Panel' form.
  12. Select 'Add' In the 'Add New or Edit Existing Service Panel' field.
  13. Select an existing service code in the 'Service Code' field (i.e. Service Code 1).
  14. Enter desired date based on the date defined in the 'Effective Date' field.
  15. Select 'Yes' in the 'File The Parent Service With This Panel' field.
  16. Select another existing service code from the 'Select Service Code To Add To Panel' search box (i.e. Service Code 2).
  17. Click [Add selected Service To Panel].
  18. Verify the service code selected is displayed in the 'Service Panel' item.
  19. Submit the form.
  20. Verify that the form submitted successfully.
  21. Open the 'Service Panel Charge Input' form.
  22. Enter desired date in the 'Date Of Service' field.
  23. Select the client in the 'Client ID' field.
  24. Enter 'Service Start Time' based on the time range defined for the Incident-To Practitioner in the 'Incident-To Practitioner Daily Log' form.
  25. Enter 'Service End Time' based on the time range defined for the Incident-To Practitioner in the 'Incident-To Practitioner Daily Log' form.
  26. Select the 'Panel Description'.
  27. Select the 'Panel Service(s)'.
  28. Select the 'Incident-To Practitioner'.
  29. Verify the panel service files successfully.
  30. Open the 'Crystal Report' or any other SQL data viewer.
  31. Query the 'SYSTEM.billing_tx_history' SQL table.
  32. Verify the Incident To Practitioner is not filed for the service.
Quick Billing - Add/Edit quick billing batch
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Quick Billing
  • Guarantors/Payors
  • Dynamic Form - Admission - Client
  • Admission (Outpatient)
  • Financial Eligibility
  • Diagnosis
  • Client Ledger
  • Quick Billing Rule Definition
  • Dynamic Form Compile Complete
Scenario 1: Quick Billing - Validating work screen and 837 report through 'Edit Existing' quick billing batch
Specific Setup:
  • Registry Setting:
  • The 'Enable New Quick Billing Format' registry setting is enabled.
  • Please note: This is a one-time, system-wide registry setting and the associated functionality cannot be disabled once the registry setting is enabled. Once this setting has been enabled, it will no longer be able to be viewed in the 'Registry Settings' form.
  • Admission:
  • Two outpatient clients are identified. Please note the admission program of the clients.
  • Guarantors/Payor:
  • An existing guarantor is identified.
  • Financial Eligibility:
  • Guarantor identified above is assigned to the clients.
  • Client Charge Input:
  • 1-2 days of professional charges are rendered to the clients. Please note the service codes used during rendering services.
  • Client Ledger:
  • The charges are distributed to the guarantors assigned to the clients.
  • Quick Billing Rule Definition:
  • A new quick billing rule is created as follows:
  • The admission programs are selected in the 'Program' field.
  • An '837 Professional' is selected in the 'Billing Form' field.
  • The guarantors assigned to the clients in their financial eligibility are selected in the 'Guarantors' field.
  • All required fields are populated.
  • The 'Create Interim Billing Batch' field is set to 'Yes'.
Steps
  1. Open the 'Quick Billing' form.
  2. Run a new quick billing batch using the rule created in the setup section.
  3. Use a date range spanning services entered.
  4. Select 'Create Batch', 'Close Charges', and 'Generate Bills' in the 'Quick Billing Tasks To Execute' field.
  5. Submit the form.
  6. Verify that compile completes and the prompt states 'Compile Complete'. A Quick Billing Batch and an Interim Billing Batch will be created.
  7. Select the 'Edit Existing' option.
  8. Select the quick bill that was created in previous step.
  9. Submit the form again.
  10. Click [OK].
  11. Select the 'Edit Existing' option.
  12. Select the quick bill that was created in previous step.
  13. Click [Print 837 Report].
  14. Verify the report launched successfully.
  15. Close the report.
  16. Click [Launch Workscreen].
  17. Verify the work screen contains all the clients included in the batch.
  18. Deselect one client from the 'Client' filter at the top of the work screen.
  19. Verify the grid does not display the services of that client.
  20. Select the same client again from the 'Client' filter at the top of the work screen.
  21. Verify the grid displays the services of that client.
  22. Save the grid.
  23. Verify the grid saves successfully.
  24. Close the form.
Spreadsheet Batch Remittance Posting - Security level of the posting code
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Posting/Adjustment Codes Definition
  • User Definition
  • Dynamic Form - Admission - Client
  • Admission (Outpatient)
  • Financial Eligibility
  • Spreadsheet Batch Remittance Posting
  • Client Ledger
  • Individual Cash Posting (PM)
  • Dynamic Form - Individual Cash Posting - Information
  • Dynamic Form - Individual Cash Posting - Alert
  • Dynamic Form - Individual Cash Posting - Client
  • Spreadsheet Remittance Posting
Scenario 1: Spreadsheet Batch Remittance Posting - Validating security level of the posting code
Specific Setup:
  • Posting/Adjustment Codes Definition:
  • Identify an existing posting code. Note the code/value of the posting code.
  • Security level is set up to desired level. Note the security level of the code.
  • User Definition:
  • Set the security level of the user to a lower level than the security level set up for the posting code identified.
  • Admission:
  • An existing client is identified. Note the client ID and client name.
  • Financial Eligibility:
  • An existing guarantor is assigned to the client. Note the guarantor code and value.
  • Client Charge Input:
  • 5-6 services are rendered to the client.
  • Close Charges:
  • The services rendered to the client are closed.
  • Client Ledger:
  • The services are distributed correctly to the guarantor.
  • Create Interim Billing Batch:
  • An interim billing batch is created to include client/guarantor and services. Note the interim billing batch number generated and name.
Steps
  1. Open the 'Spreadsheet Batch Remittance Posting' form.
  2. Select "Create Batch" in the "Create, Edit Or Delete Remittance Batch" field.
  3. Enter a description in the “Batch Description” field. Note the batch description.
  4. Select the interim billing batch created in the setup section in the 'Interim Batch Number' field.
  5. Enter a date in the “Posting Date” field.
  6. Enter a date in the “Date Of Receipt” field.
  7. Select all other fields as required.
  8. Click the "Launch Work Screen" button.
  9. Validate the Client, Ep#, Payor, Begin Date/Svc Date, End Date, Total Charges, Liability fields populated correctly based on the client, guarantor and services included in the interim billing batch.
  10. Validate the 'Payment Code' dropdown field does not contain the payment code created in the 'Posting /Adjustment Code Definition' form.
  11. Click [Cancel].
  12. Click [Close Form].
  13. Open the 'User Definition' form.
  14. Update the security level of the user so that it is greater than or equal to the security level of the posting code identified above in the setup section.
  15. Click "Refresh Forms" icon.
  16. Open the 'Spreadsheet Batch Remittance Posting' form.
  17. Select "Create Batch" in the "Create, Edit Or Delete Remittance Batch" field.
  18. Enter a description in the “Batch Description” field. Note the batch description.
  19. Select the interim billing batch created in the setup section in the 'Interim Batch Number' field.
  20. Enter a date in the “Posting Date” field.
  21. Enter a date in the “Date Of Receipt” field.
  22. Select all other fields as required.
  23. Click the "Launch Work Screen" button.
  24. Validate the Client, Ep#, Payor, Begin Date/Svc Date, End Date, Total Charges, Liability fields populated correctly based on the client, guarantor and services included in the interim billing batch.
  25. Validate the 'Payment Code' dropdown field contains the payment code created in the 'Posting /Adjustment Code Definition' form.
  26. Select the posting amount/code identified in the setup section.
  27. Click [Accept].
  28. Click [Submit].
  29. Validate the 'Remittance Batch [Batch# created] Posted' message.
  30. Click [OK].
  31. Select "No" to form return message.
Scenario 2: Individual Cash Posting - Validating security level of the user based on the security level of the posting code
Specific Setup:
  • Posting/Adjustment Codes Definition:
  • Identify an existing posting code. Note the code/value of the posting code.
  • Security level is set up to desired level. Note the security level of the code.
  • User Definition:
  • Set the security level of the user to a same level as the security level set up for the posting code identified.
  • Admission:
  • An existing client is identified. Note the client ID and client name.
  • Financial Eligibility:
  • An existing guarantor is assigned to the client. Note the guarantor code and value.
  • Client Charge Input:
  • 5-6 services are rendered to the client.
  • Close Charges:
  • The services rendered to the client are closed.
  • Client Ledger:
  • The services are distributed correctly to the guarantor.
  • Create Interim Billing Batch:
  • An interim billing batch is created to include client/guarantor and services. Note the interim billing batch number generated and name.
Steps
  1. Open the 'Individual Cash Posting' form.
  2. Select desired client.
  3. Click the 'Select the Item(s) to Post Against'.
  4. Select the desired row.
  5. Enter 'Posting Date'.
  6. Enter 'Date of Receipt'.
  7. Select the desired 'Guarantor'.
  8. Enter the 'Dollar Amount To Be Posted'.
  9. Select the payment posting code set up in the setup section.
  10. Click [Update Temporary Files].
  11. Click [OK].
  12. Click [Submit].
  13. Verify the posting submitted successfully.
Scenario 3: Spreadsheet Remittance Posting - Validating security level of the user based on the security level of the posting code
Specific Setup:
  • Posting/Adjustment Codes Definition:
  • Identify an existing posting code. Note the code/value of the posting code.
  • Security level is set up to desired level. Note the security level of the code.
  • User Definition:
  • Set the security level of the user to a lower level than the security level set up for the posting code identified.
  • Admission:
  • An existing client is identified. Note the client ID and client name.
  • Financial Eligibility:
  • An existing guarantor is assigned to the client. Note the guarantor code and value.
  • Client Charge Input:
  • 5-6 services are rendered to the client.
  • Close Charges:
  • The services rendered to the client are closed.
  • Client Ledger:
  • The services are distributed correctly to the guarantor.
  • Create Interim Billing Batch:
  • An interim billing batch is created to include client/guarantor and services. Note the interim billing batch number generated and name.
Steps
  1. Open the 'Spreadsheet Remittance Posting' form.
  2. Select desired client.
  3. Enter a date in the “Posting Date” field.
  4. Enter a date in the “Date Of Receipt” field.
  5. Select all other fields as required.
  6. Click the "Launch Work Screen" button.
  7. Validate the Client, Ep#, Payor, Begin Date/Svc Date, End Date, Total Charges, Liability fields populated correctly based on the client, guarantor and services included in the interim billing batch.
  8. Validate the 'Payment Code' dropdown field contains the payment code created in the 'Posting /Adjustment Code Definition' form.
  9. Select the payment code created in the 'Posting /Adjustment Code Definition' form.
  10. Enter desired amount in the 'Payment Amount' field.
  11. Click [Accept].
  12. Click [Submit].
  13. Verify the error message for the security level.
  14. Open the 'User Definition' form.
  15. Update the security level of the user such that it is greater than or equal to the security level of the posting code identified above in the setup section.
  16. Open the 'Spreadsheet Remittance Posting' form.
  17. Select desired client.
  18. Enter a date in the “Posting Date” field.
  19. Enter a date in the “Date Of Receipt” field.
  20. Select all other fields as required.
  21. Click the "Launch Work Screen" button.
  22. Validate the Client, Ep#, Payor, Begin Date/Svc Date, End Date, Total Charges, Liability fields populated correctly based on the client, guarantor and services included in the interim billing batch.
  23. Validate the 'Payment Code' dropdown field contains the payment code created in the 'Posting /Adjustment Code Definition' form.
  24. Select the payment code created in the 'Posting /Adjustment Code Definition' form.
  25. Enter desired amount in the 'Payment Amount' field.
  26. Click [Accept].
  27. Click [Submit].
  28. Validate the amount posted successfully.
  29. Click [X].
  30. Select "No" to form return message.

;

Web Service - Edit Service Information
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dynamic Form - Admission - Client
  • Admission (Outpatient)
  • Financial Eligibility
  • Client Charge Input
  • Client Ledger
  • Dynamic Form - Edit Service Information - Select Service(s) to Edit
  • SQL Query/Reporting
  • Admission
Scenario 1: Edit Service Information - Editing 'Open' services
Specific Setup:
  • Identify an existing client that have at least one existing open service.
Steps
  1. Open the 'Edit Service Information' form.
  2. Select the desired client in the 'Client ID' field.
  3. Select desired episode from the 'Episode Number' field.
  4. Click [Select Service(s) To Edit].
  5. Verify the 'Select Service(s) To Edit' dialog is displayed.
  6. Select desired service from the 'Select Service(s) To Edit' dialog.
  7. Enter a different value in the 'Duration (Minutes)' field.
  8. Select a new service code in the 'Service Code' field.
  9. Click [OK].
  10. Submit the form.
  11. Validate a "Form Return" message is displayed stating: Submitting has completed. Do you wish to return to form?
  12. Click [No].
  13. Query the 'SYSTEM.billing_tx_history' SQL table.
  14. Validate the 'PATID' column is equal to the correct client id identified in the setup.
  15. Validate the 'date_of_service' column is equal to correct date of service rendered to the client.
  16. Validate the 'Service Code' column contains correct service code entered in the 'Edit Service Information' form.
  17. Validate the 'data_entry_source' column contains 'Edit Service Information'.
Scenario 2: 'Edit Service Information' web service - Editing 'Open' services
Specific Setup:
  • Identify an existing client that have at least one existing open service. Note the client id/name, service code and 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.
  3. Enter same value in the SYSTEMCODE which is used to sign in to Avatar.
  4. Enter same value in the USERNAME which is used to sign in to Avatar.
  5. Enter values for all required fields.
  6. Select desired service from the 'Select Service(s) To Edit' dialog.
  7. Select a new service code in the 'Service Code' field.
  8. Submit the request.
  9. Verify the message: "Edit Service Information web service has been filed successfully."
  10. Select desired items from the 'Content' checkbox.
  11. Click [Submit].
  12. Open the 'Crystal Reports' or any other SQL Data Reporting tool.
  13. Select the PM namespace.
  14. Query the 'SYSTEM.billing_tx_history' SQL table.
  15. Validate the 'PATID' column is equal to the correct client id identified in the setup.
  16. Validate the 'date_of_service' column is equal to correct date of service rendered to the client.
  17. Validate the 'Service Code' column contains correct service code entered in the web service request.
  18. Validate the 'data_entry_source' column contains 'WEBSVC.EditServiceInformation:EditServiceInformationICD10'.
837 Professional - Place of service (CLM-05-01)
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dynamic Form - Admission - Client
  • Admission (Outpatient)
  • Financial Eligibility
  • Diagnosis
  • Dictionary Update (PM)
  • Client Charge Input
  • Client Ledger
  • Admission
  • Dynamic Form - Edit Service Fee Definition
Scenario 1: 837 Professional - Validating Place of Service Code (2300-CLM-05-1) field for the primary service associated to the add-on service code
Specific Setup:
  • Guarantors/Payors:
  • A new guarantor is created or an existing guarantor is identified.
  • 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 the admission date/program.
  • Financial Eligibility:
  • The guarantor identified above is assigned to the client.
  • Diagnosis:
  • An admission diagnosis record is created for the client.
  • Dictionary Update:
  • File = Client
  • Dictionary Element - Location
  • Dictionary Code - Desired code that is different than the default location for the admission program
  • Dictionary Value - Desired value
  • Extended Dictionary Data Element - Place Of Service (837 Electronic Billing)
  • Extended Dictionary Value (Single Dictionary) - Desired value
  • Service Codes:
  • An add-on code is created of desired 'Service Code Type'. Note the code/value.
  • A primary service code is created of the desired 'Service Type Code'. Note the code/value.
  • Service Fee/Cross Reference Maintenance:
  • Fee definitions are created for the service codes and CPT codes are 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).
  • 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:
  • A billing batch is created for the client, service and guarantor. Note the batch number to be used during 'Electronic Billing'.
Steps
  1. Open the 'Electronic Billing' form.
  2. Compile an 837 professional bill for the interim billing batch created in the setup section.
  3. Verify the bill compiles successfully.
  4. Dump the file.
  5. Review an 837 professional dump file.
  6. Verify the 'Place of Service Code' at the claim level (2300-CLM-05-1) is based on the location selected for the service.
  7. Click [X].
  8. Click [Discard].
Scenario 2: 837 Professional - Validating Place of Service Code (CLM-05-1) field for the service that is not associated to the add-on service code
Specific Setup:
  • Guarantors/Payors:
  • A new guarantor is created or an existing guarantor is identified.
  • 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 the admission date/program.
  • Financial Eligibility:
  • The guarantor identified above is assigned to the client.
  • Diagnosis:
  • An admission diagnosis record is created for the client.
  • Dictionary Update:
  • File = Client
  • Dictionary Element - Location
  • Dictionary Code - Desired code that is different than the default location for the admission program
  • Dictionary Value - Desired value
  • Extended Dictionary Data Element - Place Of Service (837 Electronic Billing)
  • Extended Dictionary Value (Single Dictionary) - Desired value
  • Service Codes:
  • An existing service code is identified or a new service code is created of desired 'Service Code Type'. Note the code/value.
  • Service Fee/Cross Reference Maintenance:
  • Fee definitions 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).
  • 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:
  • A billing batch is created for the client, service and guarantor. Note the batch number to be used during 'Electronic Billing'.
Steps
  1. Open the 'Electronic Billing' form.
  2. Compile an 837 professional bill for the interim billing batch created in the setup section.
  3. Verify the bill compiles successfully.
  4. Dump the file.
  5. Review an 837 professional dump file.
  6. Verify the 'Place of Service Code' at the claim level (2300-CLM-05-1) is based on the location selected for the service.
  7. Click [X].
  8. Click [Discard].
Topics
• NX • Spreadsheet Batch Remittance Posting • Spreadsheet Remittance Posting • Individual Cash Posting • Edit Service Information • Web Services • 837 Professional
2021 Update 142 Summary | Details
Client Ledger - 'Claim' Ledger type
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Posting/Adjustment Codes Definition
  • Dynamic Form - Admission - Client
  • Admission
  • Financial Eligibility
  • Diagnosis
  • Client Ledger
  • Individual Cash Posting (PM)
  • Dynamic Form - Individual Cash Posting - Information
  • Dynamic Form - Individual Cash Posting - Alert
  • Dynamic Form - Individual Cash Posting - Client
Scenario 1: Registry Setting Validation - Include Non-Chargeable Leaves in Client Ledger View
Steps

Set the 'Limit Registry Settings to the Following Search Criteria' to "Include Non-Chargeable Leaves in Client".

Click [View Registry Settings].

Validate the 'Registry Setting' field contains "Avatar PM->Billing->Client Ledger->->->Include Non-Chargeable Leaves in Client Ledger View".

Validate the Registry Setting Details text area contains "[FACILITY SPECIFIC] Selecting 'Y' allows for Leaves defined as non-chargeable to report on the simple view of the Client Ledger. The system will include any '(757) Type of Leave From' value that has the defined extended dictionary element '(10031) Chargeable Leave Y/N' set to 'No' as a line item on the Client Ledger. The claim view will also show all leaves.

Please Note: this will add information to the Client Ledger for reporting purposes only. The system will not generate charges for these types of Leaves.

Selecting 'N' continues to not report non-chargeable Leaves in the Client Ledger. This is the default behavior of the system."

Validate the 'Registry Setting Value' field is equal to "N".

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 -- Must be Y or N".

Click [OK].

Set the 'Registry Setting Value' input box to "0".

Validate the Error dialog contains "The selected value is not valid in the current system code for the following reason: Invalid response -- Must be Y or N".

Click [OK].

Set the 'Registry Setting Value' input box to "".

Click [Submit].

Validate the Filing Error dialog contains "Filing Error The following fields are missing: Registry Setting Value"

Click [OK].

Set the Registry Setting Value input box to "@"

Validate the Error dialog contains "The selected value is not valid in the current system code for the following reason: Invalid response -- Must be Y or N".

Click [OK].

Set the Registry Setting Value input box to "Y".

Click [Submit].

Validate the Filing Results text area contains "Results filing value Y to Avatar PM->Billing->Client Ledger->->->Include Non-Chargeable Leaves in Client Ledger View Successful filing in System Code SBOX. "

Click [OK].

Validate the Form Return dialog contains "Form Return Registry Settings has completed. Do you wish to return to form?"

Click [No].

Scenario 2: Client Ledger - Validating 'Claim' based crystal reort
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 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
  1. Open the 'Electronic Billing' form.
  2. Run an 837 Institutional bill for the client.
  3. Verify the bill compiles successfully.
  4. Claim the services.
  5. Verify the bill compiles successfully.
  6. Open the 'Client Ledger' form.
  7. Process the report using 'Claim' ledger type and validate that the claim based report displays all the claim specific information.
  8. Open the ‘Individual Cash Posting’ form.
  9. Select the ‘Client’.
  10. Select desired value in the ‘Post By’ field.
  11. Click [Select Item(s) To Post Against].
  12. A grid opens containing a row for all services.
  13. Select a desired row.
  14. Click [OK] when all desired rows have been selected.
  15. Note the ‘Information’ message and the current balance for the guarantor.
  16. Click [OK].
  17. Enter desired value in ‘Posting Date’.
  18. Enter desired value in ‘Date of Receipt’.
  19. Validate that the ‘Guarantor’ defaulted to the guarantor in the current balance message.
  20. Enter desired value in ‘Dollar Amount To Be Posted’. Amount entered can be the full amount due or a partial amount due.
  21. Enter desired value in ‘Posting Code’.
  22. If desired, enter a value in ‘Check #’.
  23. Enter desired value in ‘Action For Remaining Balance If Applicable’.
  24. Click [Update Temporary File].
  25. If desired, continue to add payment/adjustments/transfers using the steps above for all other services.
  26. Click [Submit] when all payment/adjustments/transfers have been completed.
  27. Open ‘Client Ledger’ for the client’.
  28. Process the report using ‘Simple' ledger type and validate that the payment/adjustments/transfers posted correctly.
  29. Process the report using ‘Claim' ledger type and validate that the payment/adjustments/transfers posted correctly specific to claim.
  30. Close the form.
Client Ledger - Leave of absence view in the 'Simple' and 'Claim' crystal report
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Dynamic Form - Admission - Client
  • Admission
  • Financial Eligibility
  • Client Ledger
  • Leaves
  • Client Charge Input
  • Dictionary Update (PM)
  • Posting/Adjustment Codes Definition
  • Diagnosis
  • Individual Cash Posting (PM)
  • Dynamic Form - Individual Cash Posting - Information
  • Dynamic Form - Individual Cash Posting - Alert
  • Dynamic Form - Individual Cash Posting - Client
  • Discharge
Scenario 1: Client Ledger - Validating leave of absence in the 'Simple' and 'Claim' report - Client with a single episode - Registry setting 'Include Non-Chargeable Leaves in Client Ledger View' = "Y"
Specific Setup:
  • Registry Setting:
  • The 'Include Non-Chargeable Leaves in Client Ledger View' registry setting is set to "Y".
  • Dictionary Update:
  • Dictionary = Client
  • Data Element = Type of Leave From
  • Identify an existing non-billable leave type or create a new dictionary code/value for a non-billable leave type that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing same day leave type or create a new dictionary code/value for a same day leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing billable leave type or create a new dictionary code/value for a billable leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘Yes’. Note the type of leave.
  • Guarantor/Payors:
  • An existing guarantor is identified to assign to the client.
  • Admission:
  • A new client is admitted in an inpatient program. Note the client id/name, admission program, admission date.
  • Financial Eligibility:
  • The existing guarantor is assigned to the client. Note the Guarantor code/value.
  • Service Codes:
  • An existing service code is identified to render services to the client. Note the service code.
Steps
  1. Open the 'Client Charge Input' form.
  2. Render desired days of the service to the client starting from the admission date.
  3. Open the 'Leaves' form.
  4. Place the client on a non-billable leave for desired days after the admission date. Note the date.
  5. Open the 'Return From Leaves' form.
  6. Return the client. Note the date of return.
  7. Open the 'Client Charge Input' form.
  8. Render desired days of the service to the client starting after date of the return.
  9. Open the 'Leaves' form.
  10. Place a client on a billable leave for desired days after last date of the service. Note the date.
  11. Open the 'Return From Leaves' form.
  12. Return the client after desired days from the leave start date. Note the date of return.
  13. Open the 'Client Charge Input' form.
  14. Render desired days of the service to the client after date of return.
  15. Open the 'Leaves' form.
  16. Place a client on a same day leave after last date of the service. Note the date.
  17. Open the 'Return From Leaves' form.
  18. Return the client on a same day a few hours from the leave start time.
  19. Open the 'Client Ledger' form for the client.
  20. Process the 'Simple' ledger for the client.
  21. Review the report.
  22. Verify the ledger displays no-billable leaves along with the services rendered to the client in the report and does not display billable and/or same day leave in the report.
  23. Close the report.
  24. Process the 'Claim' ledger for the client.
  25. Verify the ledger displays non-billable leaves, billable leaves and/or same day leave in the report.
  26. Close the report.
Scenario 2: Client Ledger - Validating 'Claim' based crystal reort
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 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
  1. Open the 'Electronic Billing' form.
  2. Run an 837 Institutional bill for the client.
  3. Verify the bill compiles successfully.
  4. Claim the services.
  5. Verify the bill compiles successfully.
  6. Open the 'Client Ledger' form.
  7. Process the report using 'Claim' ledger type and validate that the claim based report displays all the claim specific information.
  8. Open the ‘Individual Cash Posting’ form.
  9. Select the ‘Client’.
  10. Select desired value in the ‘Post By’ field.
  11. Click [Select Item(s) To Post Against].
  12. A grid opens containing a row for all services.
  13. Select a desired row.
  14. Click [OK] when all desired rows have been selected.
  15. Note the ‘Information’ message and the current balance for the guarantor.
  16. Click [OK].
  17. Enter desired value in ‘Posting Date’.
  18. Enter desired value in ‘Date of Receipt’.
  19. Validate that the ‘Guarantor’ defaulted to the guarantor in the current balance message.
  20. Enter desired value in ‘Dollar Amount To Be Posted’. Amount entered can be the full amount due or a partial amount due.
  21. Enter desired value in ‘Posting Code’.
  22. If desired, enter a value in ‘Check #’.
  23. Enter desired value in ‘Action For Remaining Balance If Applicable’.
  24. Click [Update Temporary File].
  25. If desired, continue to add payment/adjustments/transfers using the steps above for all other services.
  26. Click [Submit] when all payment/adjustments/transfers have been completed.
  27. Open ‘Client Ledger’ for the client’.
  28. Process the report using ‘Simple' ledger type and validate that the payment/adjustments/transfers posted correctly.
  29. Process the report using ‘Claim' ledger type and validate that the payment/adjustments/transfers posted correctly specific to claim.
  30. Close the form.
Scenario 3: Validating leave of absence in the 'Simple' and 'Claim' report - Registry setting 'Include Non-Chargeable Leaves in Client Ledger View' = "N"
Specific Setup:
  • Registry Setting:
  • The 'Include Non-Chargeable Leaves in Client Ledger View' registry setting is set to "N".
  • Dictionary Update:
  • Dictionary = Client
  • Data Element = Type of Leave From
  • Identify an existing non-billable leave type or create a new dictionary code/value for the non-billable leave type that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing same day leave type or create a new dictionary code/value for the same day leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing billable leave type or create a new dictionary code/value for the billable leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘Yes’. Note the type of leave.
  • Guarantor/Payors:
  • An existing guarantor is identified to assign to the client.
  • Admission:
  • A new client is admitted in the inpatient program. Note the client id/name, admission program, admission date.
  • Financial Eligibility:
  • The existing guarantor is assigned to the client. Note the Guarantor code/value.
  • Service Codes:
  • An existing service code is identified to render services to the client. Note the service code.
Steps
  1. Open the 'Client Charge Input' form.
  2. Render desired days of the service to the client starting from the admission date.
  3. Open the 'Leaves' form.
  4. Place the client on a non-billable leave for desired days after the admission date. Note the date.
  5. Open the 'Return From Leaves' form.
  6. Return the client. Note the date of return.
  7. Open the 'Client Charge Input' form.
  8. Render desired days of the service to the client starting after date of the return.
  9. Open the 'Leaves' form.
  10. Place the client on a billable leave for desired days after last date of the service. Note the date.
  11. Open the 'Return From Leaves' form.
  12. Return the client after desired days from the leave start date. Note the date of return.
  13. Open the 'Client Charge Input' form.
  14. Render desired days of the service to the client after date of return.
  15. Open the 'Leaves' form.
  16. Place the client on a same day leave after last date of the service. Note the date.
  17. Open the 'Return From Leaves' form.
  18. Return the client on a same day after few hours from the leave start time.
  19. Open the 'Client Ledger' form for the client.
  20. Process the 'Simple' ledger for the client.
  21. Review the report.
  22. Verify the ledger does not include no-billable leaves in the report and does not display billable and/or same day leave in the report.
  23. Close the report.
  24. Process the 'Claim' ledger for the client.
  25. Verify the ledger does not include non-billable leaves, billable leaves and/or same day leave in the report.
  26. Close the report.
Scenario 4: Client Ledger - Validating leave of absence in the 'Simple' and 'Claim' report - Client with multiple episode - Registry setting 'Include Non-Chargeable Leaves in Client Ledger View' = "Y"
Specific Setup:
  • Registry Setting:
  • The 'Include Non-Chargeable Leaves in Client Ledger View' registry setting is set to "Y".
  • Dictionary Update:
  • Dictionary = Client
  • Data Element = Type of Leave From
  • Identify an existing non-billable leave type or create a new dictionary code/value for the non-billable leave type that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing same day leave type or create a new dictionary code/value for the same day leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘No’. Note the type of leave.
  • Identify an existing billable leave type or create a new dictionary code/value for the billable leave that has the defined extended dictionary value for ‘Chargeable Leave Y/N’ set to ‘Yes’. Note the type of leave.
  • Guarantor/Payors:
  • An existing guarantor is identified to assign to the client.
  • Admission:
  • A new client is admitted in two inpatient episodes. Note the client id/name, admission program, admission date.
  • 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.
Steps
  1. Open the 'Client Charge Input' form.
  2. Render desired days of the service to the client starting from the admission date.
  3. Open the 'Leaves' form.
  4. Place the client on a non-billable leave for desired days after the admission date. Note the date.
  5. Open the 'Return From Leaves' form.
  6. Return the client. Note the date of return.
  7. Open the 'Client Charge Input' form.
  8. Render desired days of the service to the client starting after date of the return.
  9. Open the 'Leaves' form.
  10. Place the client on a billable leave for desired days after last date of the service. Note the date.
  11. Open the 'Return From Leaves' form.
  12. Return the client after desired days from the leave start date. Note the date of return.
  13. Open the 'Client Charge Input' form.
  14. Render desired days of the service to the client after date of return.
  15. Open the 'Leaves' form.
  16. Place the client on a same day leave after last date of the service. Note the date.
  17. Open the 'Return From Leaves' form.
  18. Return the client on a same day after few hours from the leave start time.
  19. Open the 'Client Ledger' form for the client.
  20. Process the 'Simple' ledger for the client.
  21. Review the report.
  22. Verify the ledger displays no-billable leaves along with the services rendered to the client in the report and does not display billable and/or same day leave in the report.
  23. Close the report.
  24. Process the 'Claim' ledger for the client.
  25. Verify the ledger displays non-billable leaves, billable leaves and/or same day leave in the report.
  26. Close the report.
  27. Open the 'Discharge' form.
  28. Discharge the client. Note the discharge date.
  29. Open the 'Admission' form for the same client.
  30. Admit the client in a new inpatient episode.
  31. Open the 'Financial Eligibility' form.
  32. Assign an existing guarantor to the second episode of the client. Note the guarantor id/name.
  33. Open the 'Client Charge Input' form.
  34. Render three days of the service to the client starting from the admission date.
  35. Open the 'Leaves' form.
  36. Place a client on a non-billable leave for desired days after 1 week from the admission date. Note the date.
  37. Open the 'Return From Leaves' form.
  38. Return the client. Note the date of return.
  39. Open the 'Client Charge Input' form.
  40. Render desired days of the service to the client starting after date of the return.
  41. Open the 'Leaves' form.
  42. Place a client on a billable leave for desired days after last date of the service. Note the date.
  43. Open the 'Return From Leaves' form.
  44. Return the client after desired days from the leave start date. Note the date of return.
  45. Open the 'Client Charge Input' form.
  46. Render desired days of the service to the client after date of return.
  47. Open the 'Leaves' form.
  48. Place a client on a same day leave after last date of the service. Note the date.
  49. Open the 'Return From Leaves' form.
  50. Return the client on a same day after few hours from the leave start time.
  51. Open the 'Client Ledger' form for the client.
  52. Process the 'Simple' ledger for the client.
  53. Review the report.
  54. Verify the ledger displays no-billable leaves along with the services rendered to the client in the report and does not display billable and/or same day leave in the report.
  55. Close the report.
  56. Process the 'Claim' ledger for the client.
  57. Verify the ledger displays non-billable leaves, billable leaves and/or same day leave in the report.
  58. Close the report.
Topics
• Registry Settings • Client Ledger • NX
2021 Update 143 Summary | Details
The 'User Permissions for Multiple Iteration Tables' form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Definition
  • User Permissions for Multiple Iteration Tables
  • Financial Eligibility
  • Cross Episode Financial Eligibility
  • Family Financial Eligibility
  • Managed Care Authorizations
  • Managed Care Authorizations By Provider
  • Family Registration
  • User Role Definition
  • Change User Role ID
  • User Merge
Scenario 1: Validate the 'Enable User Permissions for Multiple Iteration Tables' registry setting
Steps
  1. Access the 'Registry Settings' form.
  2. Enter "Enable User Permissions for Multiple Iteration Tables" in the 'Limit Registry Settings to the Following Search Criteria' field.
  3. Click [View Registry Settings].
  4. Validate the 'Registry Setting' field contains "Avatar PM->System Maintenance->System Definition->->->Enable User Permissions for Multiple Iteration Tables".
  5. Validate the 'Registry Setting Details' field contains: Selecting "Y" will add the form 'User Permissions for Multiple Iteration Tables'. This form allows users to assign permissions for adding, editing and deleting rows from multiple iteration tables. The following forms will allow user permissions to be set: 'Financial Eligibility' (Guarantor Selection), 'Financial Eligibility' (Customize Plan), 'Cross Episode Financial Eligibility' (Guarantor Selection),'Cross Episode Financial Eligibility' (Customize Plan), 'Family Financial Eligibility' (Guarantor Selection), 'Family Financial Eligibility' (Customize Plan), 'Family Financial Eligibility' (Guarantor Assignment), 'Managed Care Authorizations' (Managed Care Authorization Data), 'Managed Care Authorizations by Provider' (Managed Care Authorizations by Practitioner Data), and 'Family Registration' (Family Members). Selecting "N", will remove this form and all associated logic.
  6. Validate the default value is "N" in the 'Registry Setting Value' field.
  7. Enter "Y" in the 'Registry Setting Value' field.
  8. Click [Submit].
  9. Access the 'User Definition' form.
  10. Select the logged in user in the 'Select User' field.
  11. Select the "Forms and Tables" section.
  12. Click [Select Forms for User Access].
  13. Validate the 'User Permissions for Multiple Iteration Tables' form is available under PM and select it.
  14. Click [OK] and [Submit].
  15. Click [Refresh Forms].
  16. Access the 'User Permissions for Multiple Iteration Tables' form.
  17. Validate the form displays.
  18. Validate the 'User' field is displayed.
  19. Validate the 'User Role' field is displayed.
  20. Validate the 'Permissions Table' is displayed.
  21. Validate the 'Add/Edit/Delete Permission' field is displayed.
  22. Validate the 'Row Selection' field is displayed.
  23. Validate the 'Forms' field is displayed.
  24. Validate the 'Select Permission' field is displayed.
  25. Validate the 'Update Table' button is displayed.
  26. Close the form.
  27. Access the 'Registry Settings' form.
  28. Enter "Enable User Permissions for Multiple Iteration Tables" in the 'Limit Registry Settings to the Following Search Criteria' field.
  29. Click [View Registry Settings].
  30. Enter "N" in the 'Registry Setting Value' field.
  31. Click [Submit].
  32. Click [Refresh Forms].
  33. Validate the 'User Permissions for Multiple Iteration Tables' form is no longer available.
Scenario 2: User Permissions for Multiple Iteration Tables (User) - Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A client has existing rows in both the "Guarantor Selection" and "Customize Plan" sections of the 'Financial Eligibility' form (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Financial Eligibility (Guarantor Selection)" and "Financial Eligibility (Customize Plan)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permissions just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Populate any desired fields and submit the form.
  31. Access the 'User Permissions for Multiple Iteration Tables' form.
  32. Select "User A" in the 'User' field.
  33. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  34. Select the permissions filed in the previous steps in the 'Row Selection' field.
  35. Deselect "Add" in the 'Select Permissions' field.
  36. Select "Edit" in the 'Select Permissions' field.
  37. Click [Update Table].
  38. Validate a message is displayed stating: Filed Successfully!
  39. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  40. Close the form.
  41. Select "Client A" and access the 'Financial Eligibility' form.
  42. Select the "Guarantor Selection" section.
  43. Click [Add New Item].
  44. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  45. Click [OK] and validate a row has not been added.
  46. Select an existing row filed in a previous session and click [Delete Selected Item].
  47. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  48. Click [OK].
  49. Select an existing row filed in a previous session and click [Edit Selected Item].
  50. Update any desired fields.
  51. Select the "Customize Plan" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Click [Submit].
  61. Access the 'User Permissions for Multiple Iteration Tables' form.
  62. Select "User A" in the 'User' field.
  63. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  64. Select the permissions filed in the previous steps in the 'Row Selection' field.
  65. Deselect "Edit" in the 'Select Permissions' field.
  66. Select "Delete" in the 'Select Permissions' field.
  67. Click [Update Table].
  68. Validate a message is displayed stating: Filed Successfully!
  69. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  70. Close the form.
  71. Select "Client A" and access the 'Financial Eligibility' form.
  72. Select the "Guarantor Selection" section.
  73. Click [Add New Item].
  74. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK] and validate a row has not been added.
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  78. Click [OK] and validate all fields are disabled and read-only.
  79. Select an existing row filed in a previous session and click [Delete Selected Item].
  80. Validate a message is displayed stating: Are you sure?
  81. Click [Yes] and validate the record is deleted from the 'Guarantor Information' table.
  82. Select the "Customize Plan" section.
  83. Click [Add New Item].
  84. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and validate a row has not been added.
  86. Select an existing row filed in a previous session and click [Edit Selected Item].
  87. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  88. Click [OK] and validate all fields are disabled.
  89. Select an existing row filed in a previous session and click [Delete Selected Item].
  90. Validate a message is displayed stating: Are you sure?
  91. Click [Yes] and validate the record is deleted from the 'Billing Plan Assigned' table.
  92. Click [Submit].
  93. Access the 'User Permissions for Multiple Iteration Tables' form.
  94. Select "User A" in the 'User' field.
  95. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  96. Select the permissions filed in the previous steps in the 'Row Selection' field.
  97. Deselect "Delete" in the 'Select Permissions' field.
  98. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  99. Click [Update Table].
  100. Validate a message is displayed stating: Filed Successfully!
  101. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  102. Close the form.
  103. Select "Client A" and access the 'Financial Eligibility' form.
  104. Select the "Guarantor Selection" section.
  105. Click [Add New Item].
  106. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  107. Click [OK] and validate a row has not been added.
  108. Select an existing row filed in a previous session and click [Edit Selected Item].
  109. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  110. Click [OK] and validate all fields are disabled and read-only.
  111. Select an existing row filed in a previous session and click [Delete Selected Item].
  112. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Select the "Customize Plan" section.
  114. Click [Add New Item].
  115. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate a row has not been added.
  117. Select an existing row filed in a previous session and click [Edit Selected Item].
  118. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  119. Click [OK] and validate all fields are disabled and read-only.
  120. Select an existing row filed in a previous session and click [Delete Selected Item].
  121. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  122. Click [OK] and close the form.
  123. Access the 'User Permissions for Multiple Iteration Tables' form.
  124. Select "User A" in the 'User' field.
  125. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  126. Select the permissions filed in the previous steps in the 'Row Selection' field.
  127. Deselect "None" in the 'Select Permissions' field.
  128. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  129. Click [Update Table].
  130. Validate a message is displayed stating: Filed Successfully!
  131. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  132. Close the form.
  133. Select "Client A" and access the 'Financial Eligibility' form.
  134. Select the "Guarantor Selection" section.
  135. Validate the ability to add new rows and edit/delete new and existing rows.
  136. Select the "Customize Plan" section.
  137. Validate the ability to add new rows and edit/delete new and existing rows.
  138. Click [Submit].
Scenario 3: User Permissions for Multiple Iteration Tables (User) - Cross Episode Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A client has existing rows in both the "Guarantor Selection" and "Customize Plan" sections of the 'Cross Episode Financial Eligibility' form (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Cross Episode Financial Eligibility (Guarantor Selection)" and "Cross Episode Financial Eligibility (Customize Plan)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permissions just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Populate any desired fields and submit the form.
  31. Access the 'User Permissions for Multiple Iteration Tables' form.
  32. Select "User A" in the 'User' field.
  33. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  34. Select the permissions filed in the previous steps in the 'Row Selection' field.
  35. Deselect "Add" in the 'Select Permissions' field.
  36. Select "Edit" in the 'Select Permissions' field.
  37. Click [Update Table].
  38. Validate a message is displayed stating: Filed Successfully!
  39. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  40. Close the form.
  41. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  42. Select the "Guarantor Selection" section.
  43. Click [Add New Item].
  44. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  45. Click [OK] and validate a row has not been added.
  46. Select an existing row filed in a previous session and click [Delete Selected Item].
  47. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  48. Click [OK].
  49. Select an existing row filed in a previous session and click [Edit Selected Item].
  50. Update any desired fields.
  51. Select the "Customize Plan" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Click [Submit].
  61. Access the 'User Permissions for Multiple Iteration Tables' form.
  62. Select "User A" in the 'User' field.
  63. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  64. Select the permissions filed in the previous steps in the 'Row Selection' field.
  65. Deselect "Edit" in the 'Select Permissions' field.
  66. Select "Delete" in the 'Select Permissions' field.
  67. Click [Update Table].
  68. Validate a message is displayed stating: Filed Successfully!
  69. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  70. Close the form.
  71. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  72. Select the "Guarantor Selection" section.
  73. Click [Add New Item].
  74. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK] and validate a row has not been added.
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  78. Click [OK] and validate all fields are disabled and read-only.
  79. Select an existing row filed in a previous session and click [Delete Selected Item].
  80. Validate a message is displayed stating: Are you sure?
  81. Click [Yes] and validate the record is deleted from the 'Guarantor Information' table.
  82. Select the "Customize Plan" section.
  83. Click [Add New Item].
  84. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and validate a row has not been added.
  86. Select an existing row filed in a previous session and click [Edit Selected Item].
  87. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  88. Click [OK] and validate all fields are disabled.
  89. Select an existing row filed in a previous session and click [Delete Selected Item].
  90. Validate a message is displayed stating: Are you sure?
  91. Click [Yes] and validate the record is deleted from the 'Billing Plan Assigned' table.
  92. Click [Submit].
  93. Access the 'User Permissions for Multiple Iteration Tables' form.
  94. Select "User A" in the 'User' field.
  95. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  96. Select the permissions filed in the previous steps in the 'Row Selection' field.
  97. Deselect "Delete" in the 'Select Permissions' field.
  98. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  99. Click [Update Table].
  100. Validate a message is displayed stating: Filed Successfully!
  101. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  102. Close the form.
  103. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  104. Select the "Guarantor Selection" section.
  105. Click [Add New Item].
  106. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  107. Click [OK] and validate a row has not been added.
  108. Select an existing row filed in a previous session and click [Edit Selected Item].
  109. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  110. Click [OK] and validate all fields are disabled and read-only.
  111. Select an existing row filed in a previous session and click [Delete Selected Item].
  112. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Select the "Customize Plan" section.
  114. Click [Add New Item].
  115. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate a row has not been added.
  117. Select an existing row filed in a previous session and click [Edit Selected Item].
  118. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  119. Click [OK] and validate all fields are disabled and read-only.
  120. Select an existing row filed in a previous session and click [Delete Selected Item].
  121. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  122. Click [OK] and close the form.
  123. Access the 'User Permissions for Multiple Iteration Tables' form.
  124. Select "User A" in the 'User' field.
  125. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  126. Select the permissions filed in the previous steps in the 'Row Selection' field.
  127. Deselect "None" in the 'Select Permissions' field.
  128. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  129. Click [Update Table].
  130. Validate a message is displayed stating: Filed Successfully!
  131. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  132. Close the form.
  133. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  134. Select the "Guarantor Selection" section.
  135. Validate the ability to add new rows and edit/delete new and existing rows.
  136. Select the "Customize Plan" section.
  137. Validate the ability to add new rows and edit/delete new and existing rows.
  138. Click [Submit].
Scenario 4: User Permissions for Multiple Iteration Tables (User) - Family Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A family is defined in the 'Family Registration' form with family members added (Family A).
  • "Family A" has an existing guarantor on file in 'Family Financial Eligibility' with a row defined in the 'Customize Plan' and 'Guarantor Assignment' sections.
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Family Financial Eligibility (Guarantor Selection)","Family Financial Eligibility (Customize Plan)", and "Family Financial Eligibility (Guarantor Assignment)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Family A" and access the 'Family Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Select the "Guarantor Assignment" section.
  31. Validate the ability to add new rows.
  32. Validate the ability to edit/delete rows added in the current session.
  33. Select an existing row filed in a previous session and click [Edit Selected Item].
  34. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  35. Click [OK].
  36. Select an existing row filed in a previous session and click [Delete Selected Item].
  37. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  38. Click [OK].
  39. Populate any desired fields and submit the form.
  40. Access the 'User Permissions for Multiple Iteration Tables' form.
  41. Select "User A" in the 'User' field.
  42. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  43. Select the permissions filed in the previous steps in the 'Row Selection' field.
  44. Deselect "Add" in the 'Select Permissions' field.
  45. Select "Edit" in the 'Select Permissions' field.
  46. Click [Update Table].
  47. Validate a message is displayed stating: Filed Successfully!
  48. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  49. Close the form.
  50. Select "Family A" and access the 'Family Financial Eligibility' form.
  51. Select the "Guarantor Selection" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Select the "Customize Plan" section.
  61. Click [Add New Item].
  62. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  63. Click [OK] and validate a row has not been added.
  64. Select an existing row filed in a previous session and click [Delete Selected Item].
  65. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  66. Click [OK].
  67. Select an existing row filed in a previous session and click [Edit Selected Item].
  68. Update any desired fields.
  69. Select the "Guarantor Assignment" section.
  70. Click [Add New Item].
  71. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  72. Click [OK] and validate a row has not been added.
  73. Select an existing row filed in a previous session and click [Delete Selected Item].
  74. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK].
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Update any desired fields.
  78. Click [Submit].
  79. Access the 'User Permissions for Multiple Iteration Tables' form.
  80. Select "User A" in the 'User' field.
  81. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  82. Select the permissions filed in the previous steps in the 'Row Selection' field.
  83. Deselect "Edit" in the 'Select Permissions' field.
  84. Select "Delete" in the 'Select Permissions' field.
  85. Click [Update Table].
  86. Validate a message is displayed stating: Filed Successfully!
  87. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  88. Close the form.
  89. Select "Family A" and access the 'Family Financial Eligibility' form.
  90. Select the "Guarantor Selection" section.
  91. Click [Add New Item].
  92. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  93. Click [OK] and validate a row has not been added.
  94. Select an existing row filed in a previous session and click [Edit Selected Item].
  95. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  96. Click [OK] and validate all fields are disabled and read-only.
  97. Select an existing row filed in a previous session and click [Delete Selected Item].
  98. Validate a message is displayed stating: Are you sure?
  99. Click [Yes] and validate the record is deleted.
  100. Select the "Customize Plan" section.
  101. Click [Add New Item].
  102. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  103. Click [OK] and validate a row has not been added.
  104. Select an existing row filed in a previous session and click [Edit Selected Item].
  105. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  106. Click [OK] and validate all fields are disabled.
  107. Select an existing row filed in a previous session and click [Delete Selected Item].
  108. Validate a message is displayed stating: Are you sure?
  109. Click [Yes] and validate the record is deleted.
  110. Select the "Guarantor Assignment" section.
  111. Click [Add New Item].
  112. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Click [OK] and validate a row has not been added.
  114. Select an existing row filed in a previous session and click [Edit Selected Item].
  115. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate all fields are disabled.
  117. Select an existing row filed in a previous session and click [Delete Selected Item].
  118. Validate a message is displayed stating: Are you sure?
  119. Click [Yes] and validate the record is deleted.
  120. Click [Submit].
  121. Access the 'User Permissions for Multiple Iteration Tables' form.
  122. Select "User A" in the 'User' field.
  123. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  124. Select the permissions filed in the previous steps in the 'Row Selection' field.
  125. Deselect "Delete" in the 'Select Permissions' field.
  126. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  127. Click [Update Table].
  128. Validate a message is displayed stating: Filed Successfully!
  129. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  130. Close the form.
  131. Select "Family A" and access the 'Family Financial Eligibility' form.
  132. Select the "Guarantor Selection" section.
  133. Click [Add New Item].
  134. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  135. Click [OK] and validate a row has not been added.
  136. Select an existing row filed in a previous session and click [Edit Selected Item].
  137. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  138. Click [OK] and validate all fields are disabled and read-only.
  139. Select an existing row filed in a previous session and click [Delete Selected Item].
  140. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  141. Select the "Customize Plan" section.
  142. Click [Add New Item].
  143. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  144. Click [OK] and validate a row has not been added.
  145. Select an existing row filed in a previous session and click [Edit Selected Item].
  146. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  147. Click [OK] and validate all fields are disabled and read-only.
  148. Select an existing row filed in a previous session and click [Delete Selected Item].
  149. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  150. Click [OK].
  151. Select the "Guarantor Assignment" section.
  152. Click [Add New Item].
  153. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  154. Click [OK] and validate a row has not been added.
  155. Select an existing row filed in a previous session and click [Edit Selected Item].
  156. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  157. Click [OK] and validate all fields are disabled and read-only.
  158. Select an existing row filed in a previous session and click [Delete Selected Item].
  159. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  160. Click [OK] and close the form.
  161. Access the 'User Permissions for Multiple Iteration Tables' form.
  162. Select "User A" in the 'User' field.
  163. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  164. Select the permissions filed in the previous steps in the 'Row Selection' field.
  165. Deselect "None" in the 'Select Permissions' field.
  166. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  167. Click [Update Table].
  168. Validate a message is displayed stating: Filed Successfully!
  169. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  170. Close the form.
  171. Select "Family A" and access the 'Family Financial Eligibility' form.
  172. Select the "Guarantor Selection" section.
  173. Validate the ability to add new rows and edit/delete new and existing rows.
  174. Select the "Customize Plan" section.
  175. Validate the ability to add new rows and edit/delete new and existing rows.
  176. Select the "Guarantor Assignment" section.
  177. Validate the ability to add new rows and edit/delete new and existing rows.
  178. Click [Submit].
Scenario 5: User Permissions for Multiple Iteration Tables (User) - Managed Care Authorizations
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A client has an existing record in the 'Managed Care Authorization' form with existing rows filed in the 'Managed Care Authorization History' table (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Managed Care Authorizations (Managed Care Authorization Data)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Managed Care Authorizations' form.
  11. Select the "Managed Care Authorization Data" section.
  12. Validate the ability to add new rows.
  13. Validate the ability to edit/delete rows added in the current session.
  14. Select an existing row filed in a previous session and click [Edit Selected Item].
  15. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  16. Click [OK] and validate all fields are disabled and read-only.
  17. Select an existing row filed in a previous session and click [Delete Selected Item].
  18. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  19. Click [OK].
  20. Populate any desired fields and click [Submit].
  21. Access the 'User Permissions for Multiple Iteration Tables' form.
  22. Select "User A" in the 'User' field.
  23. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  24. Select the permission filed in the previous steps in the 'Row Selection' field.
  25. Deselect "Add" in the 'Select Permissions' field.
  26. Select "Edit" in the 'Select Permissions' field.
  27. Click [Update Table].
  28. Validate a message is displayed stating: Filed Successfully!
  29. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  30. Close the form.
  31. Select "Client A" and access the 'Managed Care Authorizations' form.
  32. Select the "Managed Care Authorization Data" section.
  33. Click [Add New Item].
  34. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  35. Click [OK] and validate a row has not been added.
  36. Select an existing row filed in a previous session and click [Delete Selected Item].
  37. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  38. Click [OK].
  39. Select an existing row filed in a previous session and click [Edit Selected Item].
  40. Update any desired fields and click [Submit].
  41. Access the 'User Permissions for Multiple Iteration Tables' form.
  42. Select "User A" in the 'User' field.
  43. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  44. Select the permission filed in the previous steps in the 'Row Selection' field.
  45. Deselect "Edit" in the 'Select Permissions' field.
  46. Select "Delete" in the 'Select Permissions' field.
  47. Click [Update Table].
  48. Validate a message is displayed stating: Filed Successfully!
  49. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  50. Close the form.
  51. Select "Client A" and access the 'Managed Care Authorizations' form.
  52. Select the "Managed Care Authorization Data" section.
  53. Click [Add New Item].
  54. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  55. Click [OK].
  56. Select an existing row filed in a previous session and click [Edit Selected Item].
  57. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  58. Click [OK] and validate all fields are disabled and read-only.
  59. Select an existing row filed in a previous session and click [Delete Selected Item].
  60. Validate a message is displayed stating: Are you sure?
  61. Click [Yes] and validate the row is deleted from the 'Practitioner Authorization Data' table.
  62. Click [Submit].
  63. Access the 'User Permissions for Multiple Iteration Tables' form.
  64. Select "User A" in the 'User' field.
  65. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  66. Select the permission filed in the previous steps in the 'Row Selection' field.
  67. Deselect "Delete" in the 'Select Permissions' field.
  68. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  69. Click [Update Table].
  70. Validate a message is displayed stating: Filed Successfully!
  71. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  72. Close the form.
  73. Select "Client A" and access the 'Managed Care Authorizations' form.
  74. Select the "Managed Care Authorization Data" section.
  75. Click [Add New Item].
  76. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  77. Click [OK] and validate a row has not been added.
  78. Select an existing row filed in a previous session and click [Edit Selected Item].
  79. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  80. Click [OK] and validate all fields are disabled and read-only.
  81. Select an existing row filed in a previous session and click [Delete Selected Item].
  82. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  83. Click [OK] and close the form.
  84. Access the 'User Permissions for Multiple Iteration Tables' form.
  85. Select "User A" in the 'User' field.
  86. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  87. Select the permission filed in the previous steps in the 'Row Selection' field.
  88. Deselect "None" in the 'Select Permissions' field.
  89. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  90. Click [Update Table].
  91. Validate a message is displayed stating: Filed Successfully!
  92. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  93. Close the form.
  94. Select "Client A" and access the 'Managed Care Authorizations' form.
  95. Select the "Managed Care Authorization Data" section.
  96. Validate the ability to add new rows and edit/delete new and existing rows.
  97. Click [Submit].
Scenario 6: User Permissions for Multiple Iteration Tables (User) - Managed Care Authorizations By Provider
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A client has an existing record in the 'Managed Care Authorization By Provider' form with existing rows filed in the 'Practitioner Authorization Data' table (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Managed Care Authorizations by Provider (Managed Care Authorization by Provider Data)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  11. Select the existing authorization record in the 'Managed Care Authorizations' field.
  12. Select the "Managed Care Authorization By Practitioner Data" section.
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Populate any desired fields and click [Submit].
  22. Access the 'User Permissions for Multiple Iteration Tables' form.
  23. Select "User A" in the 'User' field.
  24. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  25. Select the permission filed in the previous steps in the 'Row Selection' field.
  26. Deselect "Add" in the 'Select Permissions' field.
  27. Select "Edit" in the 'Select Permissions' field.
  28. Click [Update Table].
  29. Validate a message is displayed stating: Filed Successfully!
  30. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  31. Close the form.
  32. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  33. Select the existing authorization record in the 'Managed Care Authorizations' field.
  34. Select the "Managed Care Authorization By Practitioner Data" section.
  35. Click [Add New Item].
  36. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  37. Click [OK] and validate a row has not been added.
  38. Select an existing row filed in a previous session and click [Delete Selected Item].
  39. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  40. Click [OK].
  41. Select an existing row filed in a previous session and click [Edit Selected Item].
  42. Update any desired fields and click [Submit].
  43. Access the 'User Permissions for Multiple Iteration Tables' form.
  44. Select "User A" in the 'User' field.
  45. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  46. Select the permission filed in the previous steps in the 'Row Selection' field.
  47. Deselect "Edit" in the 'Select Permissions' field.
  48. Select "Delete" in the 'Select Permissions' field.
  49. Click [Update Table].
  50. Validate a message is displayed stating: Filed Successfully!
  51. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  52. Close the form.
  53. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  54. Select the existing authorization record in the 'Managed Care Authorizations' field.
  55. Select the "Managed Care Authorization By Practitioner Data" section.
  56. Click [Add New Item].
  57. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  58. Click [OK].
  59. Select an existing row filed in a previous session and click [Edit Selected Item].
  60. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  61. Click [OK] and validate all fields are disabled and read-only.
  62. Select an existing row filed in a previous session and click [Delete Selected Item].
  63. Validate a message is displayed stating: Are you sure?
  64. Click [Yes] and validate the row is deleted from the 'Practitioner Authorization Data' table.
  65. Click [Submit].
  66. Access the 'User Permissions for Multiple Iteration Tables' form.
  67. Select "User A" in the 'User' field.
  68. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  69. Select the permission filed in the previous steps in the 'Row Selection' field.
  70. Deselect "Delete" in the 'Select Permissions' field.
  71. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  72. Click [Update Table].
  73. Validate a message is displayed stating: Filed Successfully!
  74. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  75. Close the form.
  76. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  77. Select the existing authorization record in the 'Managed Care Authorizations' field.
  78. Select the "Managed Care Authorization By Practitioner Data" section.
  79. Click [Add New Item].
  80. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  81. Click [OK] and validate a row has not been added.
  82. Select an existing row filed in a previous session and click [Edit Selected Item].
  83. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  84. Click [OK] and validate all fields are disabled and read-only.
  85. Select an existing row filed in a previous session and click [Delete Selected Item].
  86. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  87. Click [OK] and close the form.
  88. Access the 'User Permissions for Multiple Iteration Tables' form.
  89. Select "User A" in the 'User' field.
  90. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  91. Select the permission filed in the previous steps in the 'Row Selection' field.
  92. Deselect "None" in the 'Select Permissions' field.
  93. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  94. Click [Update Table].
  95. Validate a message is displayed stating: Filed Successfully!
  96. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  97. Close the form.
  98. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  99. Select the existing authorization record in the 'Managed Care Authorizations' field.
  100. Select the "Managed Care Authorization By Practitioner Data" section.
  101. Validate the ability to add new rows and edit/delete new and existing rows.
  102. Click [Submit].
Scenario 7: User Permissions for Multiple Iteration Tables (User) - Family Registration
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined (User A) and is currently logged in.
  • A family is defined in the 'Family Registration' form with family members added (Family A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Family Registration (Family Members)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Access the 'Family Registration' form for "Family A".
  11. Select the "Family Members" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Populate any desired fields and click [Submit].
  22. Access the 'User Permissions for Multiple Iteration Tables' form.
  23. Select "User A" in the 'User' field.
  24. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  25. Select the permission filed in the previous steps in the 'Row Selection' field.
  26. Deselect "Add" in the 'Select Permissions' field.
  27. Select "Edit" in the 'Select Permissions' field.
  28. Click [Update Table].
  29. Validate a message is displayed stating: Filed Successfully!
  30. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  31. Close the form.
  32. Access the 'Family Registration' form for "Family A".
  33. Select the "Family Members" section.
  34. Click [Add New Item].
  35. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  36. Click [OK] and validate a row has not been added.
  37. Select an existing row filed in a previous session and click [Delete Selected Item].
  38. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  39. Click [OK].
  40. Select an existing row filed in a previous session and click [Edit Selected Item].
  41. Update any desired fields.
  42. Click [Submit].
  43. Access the 'User Permissions for Multiple Iteration Tables' form.
  44. Select "User A" in the 'User' field.
  45. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  46. Select the permission filed in the previous steps in the 'Row Selection' field.
  47. Deselect "Edit" in the 'Select Permissions' field.
  48. Select "Delete" in the 'Select Permissions' field.
  49. Click [Update Table].
  50. Validate a message is displayed stating: Filed Successfully!
  51. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  52. Close the form.
  53. Access the 'Family Registration' form for "Family A".
  54. Select the "Family Members" section.
  55. Click [Add New Item].
  56. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK] and validate a row has not been added.
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  60. Click [OK] and validate all fields are disabled and read-only.
  61. Select an existing row filed in a previous session and click [Delete Selected Item].
  62. Validate a message is displayed stating: Are you sure?
  63. Click [Yes] and validate the record is deleted from the 'Family Membership Information' table.
  64. Click [Submit].
  65. Access the 'User Permissions for Multiple Iteration Tables' form.
  66. Select "User A" in the 'User' field.
  67. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  68. Select the permission filed in the previous steps in the 'Row Selection' field.
  69. Deselect "Delete" in the 'Select Permissions' field.
  70. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  71. Click [Update Table].
  72. Validate a message is displayed stating: Filed Successfully!
  73. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  74. Close the form.
  75. Access the 'Family Registration' form for "Family A".
  76. Select the "Family Members" section.
  77. Click [Add New Item].
  78. Validate a message is displayed stating: Cannot add rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  79. Click [OK] and validate a row has not been added.
  80. Select an existing row filed in a previous session and click [Edit Selected Item].
  81. Validate a message is displayed stating: Cannot edit rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  82. Click [OK] and validate all fields are disabled and read-only.
  83. Select an existing row filed in a previous session and click [Delete Selected Item].
  84. Validate a message is displayed stating: Cannot delete rows because the User Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and close the form.
  86. Access the 'User Permissions for Multiple Iteration Tables' form.
  87. Select "User A" in the 'User' field.
  88. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  89. Select the permission filed in the previous steps in the 'Row Selection' field.
  90. Deselect "None" in the 'Select Permissions' field.
  91. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  92. Click [Update Table].
  93. Validate a message is displayed stating: Filed Successfully!
  94. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  95. Close the form.
  96. Access the 'Family Registration' form for "Family A".
  97. Select the "Family Members" section.
  98. Validate the ability to add new rows and edit/delete new and existing rows.
  99. Click [Submit].
Scenario 8: User Permissions for Multiple Iteration Tables (User Role) - Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A client has existing rows in both the "Guarantor Selection" and "Customize Plan" sections of the 'Financial Eligibility' form (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Financial Eligibility (Guarantor Selection)" and "Financial Eligibility (Customize Plan)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permissions just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Populate any desired fields and submit the form.
  31. Access the 'User Permissions for Multiple Iteration Tables' form.
  32. Select "PermissionsROLE" in the 'User Role' field.
  33. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  34. Select the permissions filed in the previous steps in the 'Row Selection' field.
  35. Deselect "Add" in the 'Select Permissions' field.
  36. Select "Edit" in the 'Select Permissions' field.
  37. Click [Update Table].
  38. Validate a message is displayed stating: Filed Successfully!
  39. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  40. Close the form.
  41. Select "Client A" and access the 'Financial Eligibility' form.
  42. Select the "Guarantor Selection" section.
  43. Click [Add New Item].
  44. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  45. Click [OK] and validate a row has not been added.
  46. Select an existing row filed in a previous session and click [Delete Selected Item].
  47. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  48. Click [OK].
  49. Select an existing row filed in a previous session and click [Edit Selected Item].
  50. Update any desired fields.
  51. Select the "Customize Plan" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Click [Submit].
  61. Access the 'User Permissions for Multiple Iteration Tables' form.
  62. Select "PermissionsROLE" in the 'User Role' field.
  63. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  64. Select the permissions filed in the previous steps in the 'Row Selection' field.
  65. Deselect "Edit" in the 'Select Permissions' field.
  66. Select "Delete" in the 'Select Permissions' field.
  67. Click [Update Table].
  68. Validate a message is displayed stating: Filed Successfully!
  69. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  70. Close the form.
  71. Select "Client A" and access the 'Financial Eligibility' form.
  72. Select the "Guarantor Selection" section.
  73. Click [Add New Item].
  74. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK] and validate a row has not been added.
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  78. Click [OK] and validate all fields are disabled and read-only.
  79. Select an existing row filed in a previous session and click [Delete Selected Item].
  80. Validate a message is displayed stating: Are you sure?
  81. Click [Yes] and validate the record is deleted from the 'Guarantor Information' table.
  82. Select the "Customize Plan" section.
  83. Click [Add New Item].
  84. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and validate a row has not been added.
  86. Select an existing row filed in a previous session and click [Edit Selected Item].
  87. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  88. Click [OK] and validate all fields are disabled.
  89. Select an existing row filed in a previous session and click [Delete Selected Item].
  90. Validate a message is displayed stating: Are you sure?
  91. Click [Yes] and validate the record is deleted from the 'Billing Plan Assigned' table.
  92. Click [Submit].
  93. Access the 'User Permissions for Multiple Iteration Tables' form.
  94. Select "PermissionsROLE" in the 'User Role' field.
  95. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  96. Select the permissions filed in the previous steps in the 'Row Selection' field.
  97. Deselect "Delete" in the 'Select Permissions' field.
  98. Select "None" in the 'Select Permissions' field. This means the user role will not have permissions to add/edit/delete.
  99. Click [Update Table].
  100. Validate a message is displayed stating: Filed Successfully!
  101. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  102. Close the form.
  103. Select "Client A" and access the 'Financial Eligibility' form.
  104. Select the "Guarantor Selection" section.
  105. Click [Add New Item].
  106. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  107. Click [OK] and validate a row has not been added.
  108. Select an existing row filed in a previous session and click [Edit Selected Item].
  109. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  110. Click [OK] and validate all fields are disabled and read-only.
  111. Select an existing row filed in a previous session and click [Delete Selected Item].
  112. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Select the "Customize Plan" section.
  114. Click [Add New Item].
  115. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate a row has not been added.
  117. Select an existing row filed in a previous session and click [Edit Selected Item].
  118. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  119. Click [OK] and validate all fields are disabled and read-only.
  120. Select an existing row filed in a previous session and click [Delete Selected Item].
  121. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  122. Click [OK] and close the form.
  123. Access the 'User Permissions for Multiple Iteration Tables' form.
  124. Select "PermissionsROLE" in the 'User Role' field.
  125. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  126. Select the permissions filed in the previous steps in the 'Row Selection' field.
  127. Deselect "None" in the 'Select Permissions' field.
  128. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  129. Click [Update Table].
  130. Validate a message is displayed stating: Filed Successfully!
  131. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  132. Close the form.
  133. Select "Client A" and access the 'Financial Eligibility' form.
  134. Select the "Guarantor Selection" section.
  135. Validate the ability to add new rows and edit/delete new and existing rows.
  136. Select the "Customize Plan" section.
  137. Validate the ability to add new rows and edit/delete new and existing rows.
  138. Click [Submit].
Scenario 9: User Permissions for Multiple Iteration Tables (User Role) - Cross Episode Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A client has existing rows in both the "Guarantor Selection" and "Customize Plan" sections of the 'Cross Episode Financial Eligibility' form (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Cross Financial Eligibility (Guarantor Selection)" and "Cross Financial Eligibility (Customize Plan)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permissions just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Populate any desired fields and submit the form.
  31. Access the 'User Permissions for Multiple Iteration Tables' form.
  32. Select "PermissionsROLE" in the 'User Role' field.
  33. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  34. Select the permissions filed in the previous steps in the 'Row Selection' field.
  35. Deselect "Add" in the 'Select Permissions' field.
  36. Select "Edit" in the 'Select Permissions' field.
  37. Click [Update Table].
  38. Validate a message is displayed stating: Filed Successfully!
  39. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  40. Close the form.
  41. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  42. Select the "Guarantor Selection" section.
  43. Click [Add New Item].
  44. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  45. Click [OK] and validate a row has not been added.
  46. Select an existing row filed in a previous session and click [Delete Selected Item].
  47. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  48. Click [OK].
  49. Select an existing row filed in a previous session and click [Edit Selected Item].
  50. Update any desired fields.
  51. Select the "Customize Plan" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Click [Submit].
  61. Access the 'User Permissions for Multiple Iteration Tables' form.
  62. Select "PermissionsROLE" in the 'User Role' field.
  63. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  64. Select the permissions filed in the previous steps in the 'Row Selection' field.
  65. Deselect "Edit" in the 'Select Permissions' field.
  66. Select "Delete" in the 'Select Permissions' field.
  67. Click [Update Table].
  68. Validate a message is displayed stating: Filed Successfully!
  69. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  70. Close the form.
  71. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  72. Select the "Guarantor Selection" section.
  73. Click [Add New Item].
  74. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK] and validate a row has not been added.
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  78. Click [OK] and validate all fields are disabled and read-only.
  79. Select an existing row filed in a previous session and click [Delete Selected Item].
  80. Validate a message is displayed stating: Are you sure?
  81. Click [Yes] and validate the record is deleted from the 'Guarantor Information' table.
  82. Select the "Customize Plan" section.
  83. Click [Add New Item].
  84. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and validate a row has not been added.
  86. Select an existing row filed in a previous session and click [Edit Selected Item].
  87. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  88. Click [OK] and validate all fields are disabled.
  89. Select an existing row filed in a previous session and click [Delete Selected Item].
  90. Validate a message is displayed stating: Are you sure?
  91. Click [Yes] and validate the record is deleted from the 'Billing Plan Assigned' table.
  92. Click [Submit].
  93. Access the 'User Permissions for Multiple Iteration Tables' form.
  94. Select "PermissionsROLE" in the 'User Role' field.
  95. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  96. Select the permissions filed in the previous steps in the 'Row Selection' field.
  97. Deselect "Delete" in the 'Select Permissions' field.
  98. Select "None" in the 'Select Permissions' field. This means the user role will not have permissions to add/edit/delete.
  99. Click [Update Table].
  100. Validate a message is displayed stating: Filed Successfully!
  101. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  102. Close the form.
  103. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  104. Select the "Guarantor Selection" section.
  105. Click [Add New Item].
  106. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  107. Click [OK] and validate a row has not been added.
  108. Select an existing row filed in a previous session and click [Edit Selected Item].
  109. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  110. Click [OK] and validate all fields are disabled and read-only.
  111. Select an existing row filed in a previous session and click [Delete Selected Item].
  112. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Select the "Customize Plan" section.
  114. Click [Add New Item].
  115. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate a row has not been added.
  117. Select an existing row filed in a previous session and click [Edit Selected Item].
  118. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  119. Click [OK] and validate all fields are disabled and read-only.
  120. Select an existing row filed in a previous session and click [Delete Selected Item].
  121. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  122. Click [OK] and close the form.
  123. Access the 'User Permissions for Multiple Iteration Tables' form.
  124. Select "PermissionsROLE" in the 'User Role' field.
  125. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  126. Select the permissions filed in the previous steps in the 'Row Selection' field.
  127. Deselect "None" in the 'Select Permissions' field.
  128. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  129. Click [Update Table].
  130. Validate a message is displayed stating: Filed Successfully!
  131. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  132. Close the form.
  133. Select "Client A" and access the 'Cross Episode Financial Eligibility' form.
  134. Select the "Guarantor Selection" section.
  135. Validate the ability to add new rows and edit/delete new and existing rows.
  136. Select the "Customize Plan" section.
  137. Validate the ability to add new rows and edit/delete new and existing rows.
  138. Click [Submit].
Scenario 10: User Permissions for Multiple Iteration Tables (User Role) - Family Financial Eligibility
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A family is defined in the 'Family Registration' form with family members added (Family A).
  • "Family A" has an existing guarantor on file in 'Family Financial Eligibility' with a row defined in the 'Customize Plan' and 'Guarantor Assignment' sections.
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Family Financial Eligibility (Guarantor Selection)","Family Financial Eligibility (Customize Plan)", and "Family Financial Eligibility (Guarantor Assignment)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Family A" and access the 'Family Financial Eligibility' form.
  11. Select the "Guarantor Selection" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Select the "Customize Plan" section.
  22. Validate the ability to add new rows.
  23. Validate the ability to edit/delete rows added in the current session.
  24. Select an existing row filed in a previous session and click [Edit Selected Item].
  25. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  26. Click [OK].
  27. Select an existing row filed in a previous session and click [Delete Selected Item].
  28. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  29. Click [OK].
  30. Select the "Guarantor Assignment" section.
  31. Validate the ability to add new rows.
  32. Validate the ability to edit/delete rows added in the current session.
  33. Select an existing row filed in a previous session and click [Edit Selected Item].
  34. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  35. Click [OK].
  36. Select an existing row filed in a previous session and click [Delete Selected Item].
  37. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  38. Click [OK].
  39. Populate any desired fields and submit the form.
  40. Access the 'User Permissions for Multiple Iteration Tables' form.
  41. Select "PermissionsROLE" in the 'User Role' field.
  42. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  43. Select the permissions filed in the previous steps in the 'Row Selection' field.
  44. Deselect "Add" in the 'Select Permissions' field.
  45. Select "Edit" in the 'Select Permissions' field.
  46. Click [Update Table].
  47. Validate a message is displayed stating: Filed Successfully!
  48. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  49. Close the form.
  50. Select "Family A" and access the 'Family Financial Eligibility' form.
  51. Select the "Guarantor Selection" section.
  52. Click [Add New Item].
  53. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  54. Click [OK] and validate a row has not been added.
  55. Select an existing row filed in a previous session and click [Delete Selected Item].
  56. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK].
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Update any desired fields.
  60. Select the "Customize Plan" section.
  61. Click [Add New Item].
  62. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  63. Click [OK] and validate a row has not been added.
  64. Select an existing row filed in a previous session and click [Delete Selected Item].
  65. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  66. Click [OK].
  67. Select an existing row filed in a previous session and click [Edit Selected Item].
  68. Update any desired fields.
  69. Select the "Guarantor Assignment" section.
  70. Click [Add New Item].
  71. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  72. Click [OK] and validate a row has not been added.
  73. Select an existing row filed in a previous session and click [Delete Selected Item].
  74. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  75. Click [OK].
  76. Select an existing row filed in a previous session and click [Edit Selected Item].
  77. Update any desired fields.
  78. Click [Submit].
  79. Access the 'User Permissions for Multiple Iteration Tables' form.
  80. Select "PermissionsROLE" in the 'User Role' field.
  81. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  82. Select the permissions filed in the previous steps in the 'Row Selection' field.
  83. Deselect "Edit" in the 'Select Permissions' field.
  84. Select "Delete" in the 'Select Permissions' field.
  85. Click [Update Table].
  86. Validate a message is displayed stating: Filed Successfully!
  87. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  88. Close the form.
  89. Select "Family A" and access the 'Family Financial Eligibility' form.
  90. Select the "Guarantor Selection" section.
  91. Click [Add New Item].
  92. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  93. Click [OK] and validate a row has not been added.
  94. Select an existing row filed in a previous session and click [Edit Selected Item].
  95. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  96. Click [OK] and validate all fields are disabled and read-only.
  97. Select an existing row filed in a previous session and click [Delete Selected Item].
  98. Validate a message is displayed stating: Are you sure?
  99. Click [Yes] and validate the record is deleted.
  100. Select the "Customize Plan" section.
  101. Click [Add New Item].
  102. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  103. Click [OK] and validate a row has not been added.
  104. Select an existing row filed in a previous session and click [Edit Selected Item].
  105. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  106. Click [OK] and validate all fields are disabled.
  107. Select an existing row filed in a previous session and click [Delete Selected Item].
  108. Validate a message is displayed stating: Are you sure?
  109. Click [Yes] and validate the record is deleted.
  110. Select the "Guarantor Assignment" section.
  111. Click [Add New Item].
  112. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  113. Click [OK] and validate a row has not been added.
  114. Select an existing row filed in a previous session and click [Edit Selected Item].
  115. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  116. Click [OK] and validate all fields are disabled.
  117. Select an existing row filed in a previous session and click [Delete Selected Item].
  118. Validate a message is displayed stating: Are you sure?
  119. Click [Yes] and validate the record is deleted.
  120. Click [Submit].
  121. Access the 'User Permissions for Multiple Iteration Tables' form.
  122. Select "PermissionsROLE" in the 'User Role' field.
  123. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  124. Select the permissions filed in the previous steps in the 'Row Selection' field.
  125. Deselect "Delete" in the 'Select Permissions' field.
  126. Select "None" in the 'Select Permissions' field. This means the user role will not have permissions to add/edit/delete.
  127. Click [Update Table].
  128. Validate a message is displayed stating: Filed Successfully!
  129. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  130. Close the form.
  131. Select "Family A" and access the 'Family Financial Eligibility' form.
  132. Select the "Guarantor Selection" section.
  133. Click [Add New Item].
  134. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  135. Click [OK] and validate a row has not been added.
  136. Select an existing row filed in a previous session and click [Edit Selected Item].
  137. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  138. Click [OK] and validate all fields are disabled and read-only.
  139. Select an existing row filed in a previous session and click [Delete Selected Item].
  140. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  141. Select the "Customize Plan" section.
  142. Click [Add New Item].
  143. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  144. Click [OK] and validate a row has not been added.
  145. Select an existing row filed in a previous session and click [Edit Selected Item].
  146. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  147. Click [OK] and validate all fields are disabled and read-only.
  148. Select an existing row filed in a previous session and click [Delete Selected Item].
  149. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  150. Click [OK].
  151. Select the "Guarantor Assignment" section.
  152. Click [Add New Item].
  153. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  154. Click [OK] and validate a row has not been added.
  155. Select an existing row filed in a previous session and click [Edit Selected Item].
  156. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  157. Click [OK] and validate all fields are disabled and read-only.
  158. Select an existing row filed in a previous session and click [Delete Selected Item].
  159. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  160. Click [OK] and close the form.
  161. Access the 'User Permissions for Multiple Iteration Tables' form.
  162. Select "PermissionsROLE" in the 'User Role' field.
  163. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  164. Select the permissions filed in the previous steps in the 'Row Selection' field.
  165. Deselect "None" in the 'Select Permissions' field.
  166. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  167. Click [Update Table].
  168. Validate a message is displayed stating: Filed Successfully!
  169. Click [OK] and validate the 'Permissions Table' contains the updated permissions.
  170. Close the form.
  171. Select "Family A" and access the 'Family Financial Eligibility' form.
  172. Select the "Guarantor Selection" section.
  173. Validate the ability to add new rows and edit/delete new and existing rows.
  174. Select the "Customize Plan" section.
  175. Validate the ability to add new rows and edit/delete new and existing rows.
  176. Select the "Guarantor Assignment" section.
  177. Validate the ability to add new rows and edit/delete new and existing rows.
  178. Click [Submit].
Scenario 11: User Permissions for Multiple Iteration Tables (User Role) - Managed Care Authorizations
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A client has an existing record in the 'Managed Care Authorization' form with existing rows filed in the 'Managed Care Authorization History' table (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Managed Care Authorizations (Managed Care Authorization Data)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Managed Care Authorizations' form.
  11. Select the "Managed Care Authorization Data" section.
  12. Validate the ability to add new rows.
  13. Validate the ability to edit/delete rows added in the current session.
  14. Select an existing row filed in a previous session and click [Edit Selected Item].
  15. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  16. Click [OK] and validate all fields are disabled and read-only.
  17. Select an existing row filed in a previous session and click [Delete Selected Item].
  18. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  19. Click [OK].
  20. Populate any desired fields and click [Submit].
  21. Access the 'User Permissions for Multiple Iteration Tables' form.
  22. Select "PermissionsROLE" in the 'User Role' field.
  23. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  24. Select the permission filed in the previous steps in the 'Row Selection' field.
  25. Deselect "Add" in the 'Select Permissions' field.
  26. Select "Edit" in the 'Select Permissions' field.
  27. Click [Update Table].
  28. Validate a message is displayed stating: Filed Successfully!
  29. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  30. Close the form.
  31. Select "Client A" and access the 'Managed Care Authorizations' form.
  32. Select the "Managed Care Authorization Data" section.
  33. Click [Add New Item].
  34. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  35. Click [OK] and validate a row has not been added.
  36. Select an existing row filed in a previous session and click [Delete Selected Item].
  37. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  38. Click [OK].
  39. Select an existing row filed in a previous session and click [Edit Selected Item].
  40. Update any desired fields and click [Submit].
  41. Access the 'User Permissions for Multiple Iteration Tables' form.
  42. Select "PermissionsROLE" in the 'User Role' field.
  43. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  44. Select the permission filed in the previous steps in the 'Row Selection' field.
  45. Deselect "Edit" in the 'Select Permissions' field.
  46. Select "Delete" in the 'Select Permissions' field.
  47. Click [Update Table].
  48. Validate a message is displayed stating: Filed Successfully!
  49. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  50. Close the form.
  51. Select "Client A" and access the 'Managed Care Authorizations' form.
  52. Select the "Managed Care Authorization Data" section.
  53. Click [Add New Item].
  54. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  55. Click [OK].
  56. Select an existing row filed in a previous session and click [Edit Selected Item].
  57. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  58. Click [OK] and validate all fields are disabled and read-only.
  59. Select an existing row filed in a previous session and click [Delete Selected Item].
  60. Validate a message is displayed stating: Are you sure?
  61. Click [Yes] and validate the row is deleted from the 'Practitioner Authorization Data' table.
  62. Click [Submit].
  63. Access the 'User Permissions for Multiple Iteration Tables' form.
  64. Select "PermissionsROLE" in the 'User Role' field.
  65. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  66. Select the permission filed in the previous steps in the 'Row Selection' field.
  67. Deselect "Delete" in the 'Select Permissions' field.
  68. Select "None" in the 'Select Permissions' field. This means the user role will not have permissions to add/edit/delete.
  69. Click [Update Table].
  70. Validate a message is displayed stating: Filed Successfully!
  71. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  72. Close the form.
  73. Select "Client A" and access the 'Managed Care Authorizations' form.
  74. Select the "Managed Care Authorization Data" section.
  75. Click [Add New Item].
  76. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  77. Click [OK] and validate a row has not been added.
  78. Select an existing row filed in a previous session and click [Edit Selected Item].
  79. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  80. Click [OK] and validate all fields are disabled and read-only.
  81. Select an existing row filed in a previous session and click [Delete Selected Item].
  82. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  83. Click [OK] and close the form.
  84. Access the 'User Permissions for Multiple Iteration Tables' form.
  85. Select "PermissionsROLE" in the 'User Role' field.
  86. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  87. Select the permission filed in the previous steps in the 'Row Selection' field.
  88. Deselect "None" in the 'Select Permissions' field.
  89. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  90. Click [Update Table].
  91. Validate a message is displayed stating: Filed Successfully!
  92. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  93. Close the form.
  94. Select "Client A" and access the 'Managed Care Authorizations' form.
  95. Select the "Managed Care Authorization Data" section.
  96. Validate the ability to add new rows and edit/delete new and existing rows.
  97. Click [Submit].
Scenario 12: User Permissions for Multiple Iteration Tables (User Role) - Managed Care Authorizations By Provider
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A client has an existing record in the 'Managed Care Authorization By Provider' form with existing rows filed in the 'Practitioner Authorization Data' table (Client A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Managed Care Authorizations by Provider (Managed Care Authorization by Provider Data)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  11. Select the existing authorization record in the 'Managed Care Authorizations' field.
  12. Select the "Managed Care Authorization By Practitioner Data" section.
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Populate any desired fields and click [Submit].
  22. Access the 'User Permissions for Multiple Iteration Tables' form.
  23. Select "PermissionsROLE" in the 'User Role' field.
  24. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  25. Select the permission filed in the previous steps in the 'Row Selection' field.
  26. Deselect "Add" in the 'Select Permissions' field.
  27. Select "Edit" in the 'Select Permissions' field.
  28. Click [Update Table].
  29. Validate a message is displayed stating: Filed Successfully!
  30. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  31. Close the form.
  32. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  33. Select the existing authorization record in the 'Managed Care Authorizations' field.
  34. Select the "Managed Care Authorization By Practitioner Data" section.
  35. Click [Add New Item].
  36. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  37. Click [OK] and validate a row has not been added.
  38. Select an existing row filed in a previous session and click [Delete Selected Item].
  39. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  40. Click [OK].
  41. Select an existing row filed in a previous session and click [Edit Selected Item].
  42. Update any desired fields and click [Submit].
  43. Access the 'User Permissions for Multiple Iteration Tables' form.
  44. Select "PermissionsROLE" in the 'User Role' field.
  45. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  46. Select the permission filed in the previous steps in the 'Row Selection' field.
  47. Deselect "Edit" in the 'Select Permissions' field.
  48. Select "Delete" in the 'Select Permissions' field.
  49. Click [Update Table].
  50. Validate a message is displayed stating: Filed Successfully!
  51. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  52. Close the form.
  53. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  54. Select the existing authorization record in the 'Managed Care Authorizations' field.
  55. Select the "Managed Care Authorization By Practitioner Data" section.
  56. Click [Add New Item].
  57. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  58. Click [OK].
  59. Select an existing row filed in a previous session and click [Edit Selected Item].
  60. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  61. Click [OK] and validate all fields are disabled and read-only.
  62. Select an existing row filed in a previous session and click [Delete Selected Item].
  63. Validate a message is displayed stating: Are you sure?
  64. Click [Yes] and validate the row is deleted from the 'Practitioner Authorization Data' table.
  65. Click [Submit].
  66. Access the 'User Permissions for Multiple Iteration Tables' form.
  67. Select "PermissionsROLE" in the 'User Role' field.
  68. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  69. Select the permission filed in the previous steps in the 'Row Selection' field.
  70. Deselect "Delete" in the 'Select Permissions' field.
  71. Select "None" in the 'Select Permissions' field. This means the user role will not have permissions to add/edit/delete.
  72. Click [Update Table].
  73. Validate a message is displayed stating: Filed Successfully!
  74. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  75. Close the form.
  76. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  77. Select the existing authorization record in the 'Managed Care Authorizations' field.
  78. Select the "Managed Care Authorization By Practitioner Data" section.
  79. Click [Add New Item].
  80. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  81. Click [OK] and validate a row has not been added.
  82. Select an existing row filed in a previous session and click [Edit Selected Item].
  83. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  84. Click [OK] and validate all fields are disabled and read-only.
  85. Select an existing row filed in a previous session and click [Delete Selected Item].
  86. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  87. Click [OK] and close the form.
  88. Access the 'User Permissions for Multiple Iteration Tables' form.
  89. Select "PermissionsROLE" in the 'User Role' field.
  90. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  91. Select the permission filed in the previous steps in the 'Row Selection' field.
  92. Deselect "None" in the 'Select Permissions' field.
  93. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  94. Click [Update Table].
  95. Validate a message is displayed stating: Filed Successfully!
  96. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  97. Close the form.
  98. Select "Client A" and access the 'Managed Care Authorizations By Provider' form.
  99. Select the existing authorization record in the 'Managed Care Authorizations' field.
  100. Select the "Managed Care Authorization By Practitioner Data" section.
  101. Validate the ability to add new rows and edit/delete new and existing rows.
  102. Click [Submit].
Scenario 13: User Permissions for Multiple Iteration Tables (User Role) - Family Registration
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role.
  • A family is defined in the 'Family Registration' form with family members added (Family A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Family Registration (Family Members)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission just filed.
  9. Close the form.
  10. Access the 'Family Registration' form for "Family A".
  11. Select the "Family Members" section.
  12. Click [Add New Item].
  13. Validate the ability to add new rows.
  14. Validate the ability to edit/delete rows added in the current session.
  15. Select an existing row filed in a previous session and click [Edit Selected Item].
  16. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  17. Click [OK] and validate all fields are disabled and read-only.
  18. Select an existing row filed in a previous session and click [Delete Selected Item].
  19. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  20. Click [OK].
  21. Populate any desired fields and click [Submit].
  22. Access the 'User Permissions for Multiple Iteration Tables' form.
  23. Select "PermissionsROLE" in the 'User Role' field.
  24. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  25. Select the permission filed in the previous steps in the 'Row Selection' field.
  26. Deselect "Add" in the 'Select Permissions' field.
  27. Select "Edit" in the 'Select Permissions' field.
  28. Click [Update Table].
  29. Validate a message is displayed stating: Filed Successfully!
  30. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  31. Close the form.
  32. Access the 'Family Registration' form for "Family A".
  33. Select the "Family Members" section.
  34. Click [Add New Item].
  35. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  36. Click [OK] and validate a row has not been added.
  37. Select an existing row filed in a previous session and click [Delete Selected Item].
  38. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  39. Click [OK].
  40. Select an existing row filed in a previous session and click [Edit Selected Item].
  41. Update any desired fields.
  42. Click [Submit].
  43. Access the 'User Permissions for Multiple Iteration Tables' form.
  44. Select "PermissionsROLE" in the 'User Role' field.
  45. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  46. Select the permission filed in the previous steps in the 'Row Selection' field.
  47. Deselect "Edit" in the 'Select Permissions' field.
  48. Select "Delete" in the 'Select Permissions' field.
  49. Click [Update Table].
  50. Validate a message is displayed stating: Filed Successfully!
  51. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  52. Close the form.
  53. Access the 'Family Registration' form for "Family A".
  54. Select the "Family Members" section.
  55. Click [Add New Item].
  56. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  57. Click [OK] and validate a row has not been added.
  58. Select an existing row filed in a previous session and click [Edit Selected Item].
  59. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  60. Click [OK] and validate all fields are disabled and read-only.
  61. Select an existing row filed in a previous session and click [Delete Selected Item].
  62. Validate a message is displayed stating: Are you sure?
  63. Click [Yes] and validate the record is deleted from the 'Family Membership Information' table.
  64. Click [Submit].
  65. Access the 'User Permissions for Multiple Iteration Tables' form.
  66. Select "PermissionsROLE" in the 'User Role' field.
  67. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  68. Select the permission filed in the previous steps in the 'Row Selection' field.
  69. Deselect "Delete" in the 'Select Permissions' field.
  70. Select "None" in the 'Select Permissions' field. This means the user will not have permissions to add/edit/delete.
  71. Click [Update Table].
  72. Validate a message is displayed stating: Filed Successfully!
  73. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  74. Close the form.
  75. Access the 'Family Registration' form for "Family A".
  76. Select the "Family Members" section.
  77. Click [Add New Item].
  78. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  79. Click [OK] and validate a row has not been added.
  80. Select an existing row filed in a previous session and click [Edit Selected Item].
  81. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  82. Click [OK] and validate all fields are disabled and read-only.
  83. Select an existing row filed in a previous session and click [Delete Selected Item].
  84. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  85. Click [OK] and close the form.
  86. Access the 'User Permissions for Multiple Iteration Tables' form.
  87. Select "PermissionsROLE" in the 'User Role' field.
  88. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  89. Select the permission filed in the previous steps in the 'Row Selection' field.
  90. Deselect "None" in the 'Select Permissions' field.
  91. Select "Add", "Edit", and "Delete" in the 'Select Permissions' field.
  92. Click [Update Table].
  93. Validate a message is displayed stating: Filed Successfully!
  94. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  95. Close the form.
  96. Access the 'Family Registration' form for "Family A".
  97. Select the "Family Members" section.
  98. Validate the ability to add new rows and edit/delete new and existing rows.
  99. Click [Submit].
Scenario 14: User Permissions for Multiple Iteration Tables - Change User Role ID
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
Steps
  1. Access the 'User Role Definition' form.
  2. Enter "PermissionsNEW" in the 'User Role ID' field.
  3. Populate all required fields.
  4. Click [Submit] and [No].
  5. Access the 'User Permissions for Multiple Iteration Tables' form.
  6. Select "PermissionsNEW" in the 'User Role' field.
  7. Select "Add" in the 'Add/Edit/Delete Permission' field.
  8. Select "Family Registration (Family Members)" in the 'Forms' field.
  9. Select "Add" in the 'Select Permissions' field.
  10. Click [Update Table].
  11. Validate a message is displayed stating "Filed Successfully".
  12. Click [OK] and validate the 'Permissions Table' contains the permission added.
  13. Close the form.
  14. Access the 'Change User Role ID' form.
  15. Select "PermissionsNEW" in the 'User Role' field.
  16. Validate the 'Current User Role ID' field contains "PermissionsNEW".
  17. Enter "PermissionsTEST" in the 'New User Role ID' field.
  18. Click [Submit].
  19. Validate a message is displayed stating "Change User Role ID has completed. Do you wish to return to form?"
  20. Click [No].
  21. Access the 'User Permissions for Multiple Iteration Tables' form.
  22. Validate the 'User Role' field contains "PermissionsTEST" and no longer contains "PermissionsNEW".
  23. Select "PermissionsTEST" in the 'User Role' field.
  24. Validate the 'Permissions Table' contains the permission filed in the previous steps indicating the user role ID has been updated successfully.
  25. Close the form.
Scenario 15: User Permissions for Multiple Iteration Tables - Change User ID
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
Steps
  1. Access the 'User Definition' form.
  2. Enter "TestPermissions1" in the 'User ID' field.
  3. Enter "Test Permissions 1" in the 'User Description' field.
  4. Select "Yes" in the 'Is this user a system administrator' field.
  5. Select "No" in the 'Associate User with a User Role' field.
  6. Select the "Forms and Tables" section.
  7. Select the desired system codes in the 'System Code(s)' field.
  8. Click [Submit] and [No].
  9. Access the 'User Permissions for Multiple Iteration Tables' form.
  10. Select "TestPermissions1" in the 'User' field.
  11. Select "Add" in the 'Add/Edit/Delete Permission' field.
  12. Select "Financial Eligibility (Guarantor Selection)" in the 'Forms' field.
  13. Select "Add" in the 'Select Permissions' field.
  14. Click [Update Table].
  15. Validate a message is displayed stating "Filed Successfully".
  16. Click [OK] and validate the 'Permissions Table' contains the permission added.
  17. Close the form.
  18. Access the 'Change User ID' form.
  19. Select "Test Permissions 1 (TestPermissions1)" in the 'User' field.
  20. Enter "TestPermissions" in the 'New User ID' field.
  21. Validate the 'Old User ID' field contains "TestPermissions1".
  22. Click [Submit].
  23. Validate a message is displayed stating "Change User ID has completed. Do you wish to return to form?"
  24. Click [No].
  25. Access the 'User Permissions for Multiple Iteration Tables' form.
  26. Validate the 'User' field contains "TestPermissions" and no longer contains "TestPermissions1".
  27. Select "TestPermissions" in the 'User' field.
  28. Validate the 'Permissions Table' contains the permission filed in the previous steps indicating the user ID has updated successfully.
  29. Close the form.
Scenario 16: User Permissions for Multiple Iteration Tables - User Merge
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
Steps
  1. Access the 'User Definition' form.
  2. Enter "Merge1" in the 'User ID' field.
  3. Enter "Merge Test 1" in the 'User Description' field.
  4. Select "Yes" in the 'Is this user a system administrator' field.
  5. Select "No" in the 'Associate User with a User Role' field.
  6. Select the "Forms and Tables" section.
  7. Select the desired system code(s) in the 'System Code(s)' field.
  8. Click [Submit] and [No].
  9. Access the 'User Permissions for Multiple Iteration Tables' form.
  10. Select "Merge1" in the 'User' field.
  11. Select "Add" in the 'Add/Edit/Delete Permission' field.
  12. Select "Financial Eligibility (Guarantor Selection)' in the 'Forms' field.
  13. Select "None" in the 'Select Permissions' field.
  14. Click [Update Table].
  15. Validate a message is displayed stating "Filed Successfully".
  16. Click [OK] and validate the 'Permissions Table' contains the permission added.
  17. Close the form.
  18. Access the 'User Merge' form.
  19. Select "New" in the 'Merge Into New Or Existing User' field.
  20. Enter "Merge2" in the 'New User ID' field.
  21. Enter "Merge Test 2" in the 'New User Description' field.
  22. Select "Merge Test 1 (Merge1)" in the 'Source User 1' field.
  23. Click [Submit] and [No].
  24. Access the 'User Permissions for Multiple Iteration Tables' form.
  25. Validate the 'User' field contains "Merge2" and no longer contains "Merge1".
  26. Select "Merge2" in the 'User' field.
  27. Validate the 'Permissions Table' contains the permission filed in the previous steps indicating the user permissions have been merged successfully.
  28. Close the form.
Scenario 17: User Permissions for Multiple Iteration Tables - validate the 'mult_iter_permission_user' table
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user is defined and currently logged in (User A).
  • "User A" has access to the 'mult_iter_permission_user' table in 'User Definition'.
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "User A" in the 'User' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Financial Eligibility (Guarantor Selection)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating "Filed Successfully".
  8. Click [OK] and validate the 'Permissions Table' contains the added permission.
  9. Close the form.
  10. Access Crystal Reports or other SQL Reporting Tool.
  11. Select the PM namespace.
  12. Create a report using the 'mult_iter_permission_user' table.
  13. Validate there is a row displayed for the permission added in the previous steps.
  14. Validate the 'ID' field contains a unique identifier for the user (ex. 98||UserA||1).
  15. Validate the 'forms' field contains "1".
  16. Validate the 'forms_value' field contains "Financial Eligibility (Guarantor Selection)".
  17. Validate the 'status' field contains "1".
  18. Validate the 'status_value' field contains "Add".
  19. Validate the 'user' field contains "PermissionsTEST".
  20. Access the 'User Permissions for Multiple Iteration Tables' form.
  21. Select "User A" in the 'User' field.
  22. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  23. Select the permission filed in the previous steps in the 'Row Selection' field.
  24. Validate "Add" is selected in the 'Select Permissions' field.
  25. Select "Delete" and "Edit" in the 'Select Permissions' field.
  26. Click [Update Table].
  27. Validate a message is displayed stating "Filed Successfully".
  28. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  29. Close the form.
  30. Access Crystal Reports or other SQL Reporting Tool.
  31. Refresh the report using the 'mult_iter_permission_user' table.
  32. Validate the permission updated in the previous steps is displayed.
  33. Validate the 'status' field contains "1&3&2".
  34. Validate the 'status_value' field contains "Add, Delete, Edit".
  35. Access the 'User Permissions for Multiple Iteration Tables' form.
  36. Select "User A" in the 'User' field.
  37. Select "Delete" in the 'Add/Edit/Delete Permission' field.
  38. Select the permission filed in the previous steps in the 'Row Selection' field.
  39. Click [Update Table].
  40. Validate a message is displayed stating "Filed Successfully".
  41. Click [OK] and validate the 'Permissions Table' no longer contains the permission.
  42. Close the form.
  43. Access Crystal Reports or other SQL Reporting Tool.
  44. Refresh the report using the 'mult_iter_permission_user' table.
  45. Validate a row is no longer displayed for the permission since it has been deleted.
  46. Close the report.
Scenario 18: User Permissions for Multiple Iteration Tables - validate the 'mult_iter_permission_role' table
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined (PermissionsROLE is used for testing).
  • The logged in user is associated to the "PermissionsROLE" user role and has access to the 'mult_iter_permission_role' table in 'User Role Definition'.
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Financial Eligibility (Guarantor Selection)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permissions' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating "Filed Successfully".
  8. Click [OK] and validate the 'Permissions Table' contains the added permission.
  9. Close the form.
  10. Access Crystal Reports or other SQL Reporting Tool.
  11. Select the PM namespace.
  12. Create a report using the 'mult_iter_permission_role' table.
  13. Validate there is a row displayed for the permission added in the previous steps.
  14. Validate the 'ID' field contains a unique identifier for the user role (ex. 98||PermissionsROLE||1).
  15. Validate the 'forms' field contains "1".
  16. Validate the 'forms_value' field contains "Financial Eligibility (Guarantor Selection)".
  17. Validate the 'status' field contains "1".
  18. Validate the 'status_value' field contains "Add".
  19. Validate the 'user_roles' field contains "PermissionsROLE".
  20. Access the 'User Permissions for Multiple Iteration Tables' form.
  21. Select "PermissionsROLE" in the 'User Role' field.
  22. Select "Edit" in the 'Add/Edit/Delete Permission' field.
  23. Select the permission filed in the previous steps in the 'Row Selection' field.
  24. Validate "Add" is selected in the 'Select Permissions' field.
  25. Select "Delete" and "Edit" in the 'Select Permissions' field.
  26. Click [Update Table].
  27. Validate a message is displayed stating "Filed Successfully".
  28. Click [OK] and validate the 'Permissions Table' contains the updated permission.
  29. Close the form.
  30. Access Crystal Reports or other SQL Reporting Tool.
  31. Refresh the report using the 'mult_iter_permission_role' table.
  32. Validate the permission updated in the previous steps is displayed.
  33. Validate the 'status' field contains "1&2&3".
  34. Validate the 'status_value' field contains "Add, Edit, Delete".
  35. Access the 'User Permissions for Multiple Iteration Tables' form.
  36. Select "PermissionsROLE" in the 'User Role' field.
  37. Select "Delete" in the 'Add/Edit/Delete Permission' field.
  38. Select the permission filed in the previous steps in the 'Row Selection' field.
  39. Click [Update Table].
  40. Validate a message is displayed stating "Filed Successfully".
  41. Click [OK] and validate the 'Permissions Table' no longer contains the permission.
  42. Close the form.
  43. Access Crystal Reports or other SQL Reporting Tool.
  44. Refresh the report using the 'mult_iter_permission_role' table.
  45. Validate a row is no longer displayed for the permission since it has been deleted.
  46. Close the report.
Scenario 19: User Permissions for Multiple Iteration Tables - Validate user permissions override user role permissions when both are defined
Specific Setup:
  • The 'Enable User Permissions for Multiple Iteration Tables' registry setting is set to "Y".
  • A user role is defined in 'User Role Definition' (PermissionsROLE is used for testing).
  • A user is defined in the 'User Definition' form (User A) and is associated to the "PermissionsROLE" user role.
  • Must be logged in as "User A".
  • A family is defined in the 'Family Registration' form with family members added (Family A).
Steps
  1. Access the 'User Permissions for Multiple Iteration Tables' form.
  2. Select "PermissionsROLE" in the 'User Role' field.
  3. Select "Add" in the 'Add/Edit/Delete Permission' field.
  4. Select "Family Registration (Family Members)" in the 'Forms' field.
  5. Select "Add" in the 'Select Permission' field.
  6. Click [Update Table].
  7. Validate a message is displayed stating: Filed Successfully!
  8. Click [OK] and validate the 'Permissions Table' contains the permission added for the user role.
  9. Select "User A" in the 'User' field.
  10. Select "Add" in the 'Add/Edit/Delete Permission' field.
  11. Select "Family Registration (Family Members)" in the 'Forms' field.
  12. Select "None" in the 'Select Permission' field.
  13. Click [Update Table].
  14. Validate a message is displayed stating: Filed Successfully!
  15. Click [OK] and validate the 'Permissions Table' contains the permission added for "User A".
  16. Close the form.
  17. Access the 'Family Registration' form for "Family A".
  18. Select the "Family Members" section.
  19. Click [Add New Item].
  20. Validate a message is displayed stating: Cannot add rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  21. Click [OK] and validate a row has not been added.
  22. Select an existing row filed in a previous session and click [Edit Selected Item].
  23. Validate a message is displayed stating: Cannot edit rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  24. Click [OK] and validate all fields are disabled and read-only.
  25. Select an existing row filed in a previous session and click [Delete Selected Item].
  26. Validate a message is displayed stating: Cannot delete rows because the User Role Permissions does not allow it. Permissions are set in the 'User Permissions for Multiple Iteration Tables' form.
  27. Click [OK] and close the form.
Topics
• Registry Settings • User Permissions for Multiple Iteration Tables • Financial Eligibility • NX • Managed Care Authorizations • Family Registration • Change User Role Id • Change User ID • User Merge • Query/Reporting
2021 Update 144 Summary | Details
'Practitioner Enrollment' Electronic Visit Verification Fields
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Practitioner Enrollment
  • Practitioner Enrollment (Brief)
Scenario 1: 'ClinicianServices' Web Service - Verification Of 'putClinicianCreation' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'ClinicianServices' web service
Steps
  1. Using Avatar PM 'ClinicianServices' web service, submit request to 'putClinicianCreation' method to create new Avatar PM Practitioner Enrollment (and optionally Avatar MSO Performing Provider Registration record), including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'ClinicianServices' web service responds with confirmation data on successful filing of 'putClinicianCreation' method.
  3. Example: "<Confirmation>Practitioner ID:000017||||First Name:FIRSTNAME||Last Name:LASTNAME||Registration Date:01/01/2022||NPI:123456789</Confirmation>"
  4. Confirm 'ClinicianServices' web service responds with confirmation message on successful filing of 'putClinicianCreation' method.
  5. Example: "<Message>Clinician Services web service has been filed successfully.</Message>"
  6. Confirm 'ClinicianServices' web service responds with successful status value on successful filing of 'putClinicianCreation' method.
  7. Example: " <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm new Practitioner Enrollment record is created in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values (as well as values assigned for Avatar MSO 'Performing Provider' and 'Performing Provider Registration' practitioner association/link fields if enabled).
Scenario 2: 'ClinicianServices' Web Service - Verification Of 'putClinicianUpdate' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'ClinicianServices' web service
Steps
  1. Using Avatar PM 'ClinicianServices' web service, submit request to 'putClinicianUpdate' method to edit/update Avatar PM Practitioner Enrollment (and optionally Avatar MSO Performing Provider Registration record if linked), including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'ClinicianServices' web service responds with confirmation data on successful filing of 'putClinicianUpdate' method.
  3. Example: "<Confirmation>Practitioner ID:000017||||First Name:FIRSTNAME||Last Name:LASTNAME||Registration Date:01/01/2022||NPI:123456789</Confirmation>"
  4. Confirm 'ClinicianServices' web service responds with confirmation message on successful filing of 'putClinicianUpdate' method.
  5. Example: "<Message>Clinician Services web service has been filed successfully.</Message>"
  6. Confirm 'ClinicianServices' web service responds with successful status value on successful filing of 'putClinicianUpdate' method.
  7. Example: " <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm Practitioner Enrollment record is updated in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values.
Scenario 3: 'ClinicianServicesV2' Web Service - Verification Of 'putClinicianCreation' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'ClinicianServicesV2' web service
Steps
  1. Using Avatar PM 'ClinicianServicesV2' web service, submit request to 'putClinicianCreation' method to create new Avatar PM Practitioner Enrollment (and optionally Avatar MSO Performing Provider Registration record), including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'ClinicianServicesV2' web service responds with confirmation data on successful filing of 'putClinicianCreation' method.
  3. Example: "<Confirmation>Practitioner ID:000017||||First Name:FIRSTNAME||Last Name:LASTNAME||Registration Date:01/01/2022||NPI:123456789</Confirmation>"
  4. Confirm 'ClinicianServicesV2' web service responds with confirmation message on successful filing of 'putClinicianCreation' method.
  5. Example: "<Message>Clinician Services web service has been filed successfully.</Message>"
  6. Confirm 'ClinicianServicesV2' web service responds with successful status value on successful filing of 'putClinicianCreation' method.
  7. Example: " <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm new Practitioner Enrollment record is created in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values (as well as values assigned for Avatar MSO 'Performing Provider' and 'Performing Provider Registration' practitioner association/link fields if enabled).
Scenario 4: 'ClinicianServicesV2' Web Service - Verification Of 'putClinicianUpdate' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'ClinicianServicesV2' web service
Steps
  1. Using Avatar PM 'ClinicianServicesV2' web service, submit request to 'putClinicianUpdate' method to edit/update Avatar PM Practitioner Enrollment (and optionally Avatar MSO Performing Provider Registration record if linked), including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'ClinicianServicesV2' web service responds with confirmation data on successful filing of 'putClinicianUpdate' method.
  3. Example: "<Confirmation>Practitioner ID:000017||||First Name:FIRSTNAME||Last Name:LASTNAME||Registration Date:01/01/2022||NPI:123456789</Confirmation>"
  4. Confirm 'ClinicianServicesV2' web service responds with confirmation message on successful filing of 'putClinicianUpdate' method.
  5. Example: "<Message>Clinician Services web service has been filed successfully.</Message>"
  6. Confirm 'ClinicianServicesV2' web service responds with successful status value on successful filing of 'putClinicianUpdate' method.
  7. Example: " <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm Practitioner Enrollment record is updated in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values.
Scenario 5: 'Practitioner Enrollment' - Form Verification
Specific Setup:
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Practitioner Enrollment' form (under 'Avatar PM / Practitioner / Practitioner Registration' menu path).
  2. Enter/select existing Practitioner Enrollment record for viewing/update (or click 'New Staff' button for new Practitioner Enrollment entry).
  3. Ensure new input fields 'Staff EVV ID' and 'Office Location ID' are added to 'Practitioner Enrollment' form (in 'Practitioner Enrollment' first/primary form section).
  4. Enter value for 'Staff EVV ID' field (up to 30 characters).
  5. Enter value for 'Office Location ID' field (up to 30 characters).
  6. Enter/select values for all other form fields as required/desired.
  7. Click 'Submit' button to file 'Practitioner Enrollment' form/record.
  8. Re-open Avatar PM 'Practitioner Enrollment' form and select same/previously filed Practitioner Enrollment record for view/update.
  9. Ensure that previously entered/filed values for 'Staff EVV ID' and 'Office Location ID' fields are present/displayed in form for selected record.
  10. Open Crystal Reports or other SQL reporting tool.
  11. In Avatar PM SQL table 'SYSTEM.staff_enrollment_history', ensure that fields 'Staff_EVV_ID' and 'office_location_ID' are available, and contain values filed for 'Staff EVV ID' and 'Office Location ID' (respectively) via Avatar PM 'Practitioner Enrollment' form.
Scenario 6: 'Practitioner Enrollment (Brief)' - Form Verification
Specific Setup:
  • Crystal Reports or other SQL reporting tool
Steps
  1. Open Avatar PM 'Practitioner Enrollment (Brief)' form (under 'Avatar PM / Practitioner / Practitioner Registration' menu path).
  2. Enter/select existing Practitioner Enrollment record for viewing/update (or click 'New Staff' button for new Practitioner Enrollment entry).
  3. Ensure new input fields 'Staff EVV ID' and 'Office Location ID' are added to 'Practitioner Enrollment (Brief)' form (in 'Practitioner Enrollment (Brief)' first/primary form section).
  4. Enter value for 'Staff EVV ID' field (up to 30 characters).
  5. Enter value for 'Office Location ID' field (up to 30 characters).
  6. Enter/select values for all other form fields as required/desired.
  7. Click 'Submit' button to file 'Practitioner Enrollment (Brief)' form/record.
  8. Re-open Avatar PM 'Practitioner Enrollment (Brief)' form and select same/previously filed Practitioner Enrollment record for view/update.
  9. Ensure that previously entered/filed values for 'Staff EVV ID' and 'Office Location ID' fields are present/displayed in form for selected record.
  10. Open Crystal Reports or other SQL reporting tool.
  11. In Avatar PM SQL table 'SYSTEM.staff_enrollment_history', ensure that fields 'Staff_EVV_ID' and 'office_location_ID' are available, and contain values filed for 'Staff EVV ID' and 'Office Location ID' (respectively) via Avatar PM 'Practitioner Enrollment (Brief)' form.
Scenario 7: 'PractitionerRegister' Web Service - Verification Of 'PractitionerRegister' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'PractitionerRegister' web service
Steps
  1. Using Avatar PM 'PractitionerRegister' web service, submit request to 'PractitionerRegister' method to create new Avatar PM Practitioner Enrollment, including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'PractitionerRegister' web service responds with confirmation data/ID on successful filing of 'PractitionerRegister' method.
  3. Example:"<Confirmation>Unique ID : 000056</Confirmation>"
  4. Confirm 'PractitionerRegister' web service responds with confirmation message on successful filing of 'PractitionerRegister' method.
  5. Example:"<Message>Practitioner Enrollment web service has been filed successfully.</Message>"
  6. Confirm 'PractitionerRegister' web service responds with successful status value on successful filing of 'PractitionerRegister' method.
  7. Example:" <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm new Practitioner/Practitioner Enrollment record is created in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values.
Scenario 8: 'PractitionerRegister' Web Service - Verification Of 'EditPractitionerRegister' Filing
Specific Setup:
  • Application utilizing the Avatar PM 'PractitionerRegister' web service
Steps
  1. Using Avatar PM 'PractitionerRegister' web service, submit request to 'EditPractitionerRegister' method to edit/update Avatar PM Practitioner Enrollment, including values for 'StaffEVVID' and 'OfficeLocationID' fields/segments.
  2. Confirm 'PractitionerRegister' web service responds with confirmation data/ID on successful filing of 'EditPractitionerRegister' method.
  3. Example:"<Confirmation>Unique ID : 000056</Confirmation>"
  4. Confirm 'PractitionerRegister' web service responds with confirmation message on successful filing of 'EditPractitionerRegister' method.
  5. Example:"<Message>Practitioner Enrollment web service has been filed successfully.</Message>"
  6. Confirm 'PractitionerRegister' web service responds with successful status value on successful filing of 'EditPractitionerRegister' method.
  7. Example:" <Status>1</Status>"
  8. Open Avatar PM 'Practitioner Enrollment' form and select Practitioner Enrollment record filed via web service for view/update.
  9. Confirm Practitioner/Practitioner Enrollment record is updated in Avatar PM, with values/data submitted via web service including 'Staff EVV ID' and 'Office Location ID' field values.
Topics
• Practitioner • Web Services • Practitioner Enrollment • NX