Skip to main content

RADplus 2022 Quarterly Release 2022.01 Acceptance Tests

  1. Last updated
  2. Save as PDF
Update 1 Summary | Details
Avatar RADplus 2022 is Installed
Scenario 1: Validate Upgrading RADplus 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 2 Summary | Details
Document Routing - Table Aliasing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Envelope Import (CWS)
  • Dynamic Form - Document Management Form Re-Mapping - Selection Dialog
  • Table Definition (CWS)
  • Dynamic Form Draft Final Document Routing
  • Form Definition (CWS)
  • Dynamic Form - Form Definition - Confirm
  • DOCMANAGEMENT3000
  • Final to Draft Override (CWS)
  • Dynamic Form ICD10 Diagnosis
  • Dynamic Form Final To Draft Override
  • Final to Draft Override (PM)
  • User Definition
  • PM USER37
  • Dynamic Form - Disclosure
  • Dynamic Form Disclosure Management Alias Primary
Scenario 1: Child Namespace User Modeled Diagnosis form with table aliasing
Specific Setup:
  • A user modeled form set up with the primary table being aliased to the Diagnosis History (ICD10).
  • Admit or select a test client.
Steps
  1. Open the user modeled form from setup.
  2. Fill out all the fields on the form.
  3. Set "Draft/Final" to "Draft".
  4. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  5. Open the user modeled form from setup.
  6. Fill all the fields on the form.
  7. Set "Draft/Final" to "Final".
  8. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the form was flagged as Final.
  9. Open the "Document Routing Setup" form.
  10. Enable document routing for the user modeled created during setup.
  11. Open the user modeled form from setup.
  12. Fill out all the fields on the form.
  13. Set "Draft/Final" to "Draft".
  14. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  15. Open the user modeled form from setup.
  16. Fill all the fields on the form.
  17. Set "Draft/Final" to "Final".
  18. Click "Accept" or "Sign" on the "Confirm Document" screen.
  19. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the form was flagged as Final.
  20. Open the "Registry Settings" form.
  21. Enable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  22. Open the user modeled form from setup.
  23. Fill out all the fields on the form.
  24. Set "Draft/Final" to "Draft".
  25. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  26. Open the user modeled form from setup.
  27. Fill all the fields on the form.
  28. Set "Draft/Final" to "Final".
  29. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  30. Route to another user.
  31. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the registry setting mentioned previously is enabled and the document routing is not finalized as yet.
  32. Log in as the user the document was routed to.
  33. Navigate to the "My ToDo" widget.
  34. Approve the document by electronic signing it.
  35. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the registry setting mentioned previously is enabled and the document routing is now finalized for the form.
  36. Open the "Registry Settings" form.
  37. Disable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  38. Open the user modeled form from setup.
  39. Fill out all the fields on the form.
  40. Set "Draft/Final" to "Draft".
  41. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  42. Open the user modeled form from setup.
  43. Fill all the fields on the form.
  44. Set "Draft/Final" to "Final".
  45. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  46. Route to another user.
  47. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the registry setting mentioned previously is disabled and the therefor not waiting for document routing to be finalized as yet.
  48. Log in as the user the document was routed to.
  49. Navigate to the "My ToDo" widget.
  50. Approve the document.
  51. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the registry setting is disabled and the record was filed when the form was routed.
  52. Open the "Final To Draft Override" form.
  53. Select a finalized document to return to draft status.
  54. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  55. Complete process.
  56. Open the "Delete Document" form.
  57. Choose to delete one of the user modeled/aliased documents.
  58. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  59. Complete the process.
Scenario 2: Parent Namespace User Modeled Disclosure Management form with table aliasing
Specific Setup:
  • A user modeled form set up with the primary table being aliased to the Disclosure Management data.
  • Admit or select a test client.
Steps
  1. Open the user modeled form from setup.
  2. Fill out all the fields on the form.
  3. Set "Draft/Final" to "Draft".
  4. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  5. Open the user modeled form from setup.
  6. Fill all the fields on the form.
  7. Set "Draft/Final" to "Final".
  8. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the form was flagged as Final.
  9. Open the "Document Routing Setup" form.
  10. Enable document routing for the user modeled created during setup.
  11. Open the user modeled form from setup.
  12. Fill out all the fields on the form.
  13. Set "Draft/Final" to "Draft".
  14. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  15. Open the user modeled form from setup.
  16. Fill all the fields on the form.
  17. Set "Draft/Final" to "Final".
  18. Click "Accept" or "Sign" on the "Confirm Document" screen.
  19. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the form was flagged as Final.
  20. Open the "Registry Settings" form.
  21. Enable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  22. Open the user modeled form from setup.
  23. Fill out all the fields on the form.
  24. Set "Draft/Final" to "Draft".
  25. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  26. Open the user modeled form from setup.
  27. Fill all the fields on the form.
  28. Set "Draft/Final" to "Final".
  29. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  30. Route to another user.
  31. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the registry setting mentioned previously is enabled and the document routing is not finalized as yet.
  32. Log in as the user the document was routed to.
  33. Navigate to the "My ToDo" widget.
  34. Approve the document by electronic signing it.
  35. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the registry setting mentioned previously is enabled and the document routing is now finalized for the form.
  36. Open the "Registry Settings" form.
  37. Disable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  38. Open the user modeled form from setup.
  39. Fill out all the fields on the form.
  40. Set "Draft/Final" to "Draft".
  41. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  42. Open the user modeled form from setup.
  43. Fill all the fields on the form.
  44. Set "Draft/Final" to "Final".
  45. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  46. Route to another user.
  47. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the registry setting mentioned previously is disabled and therefor not waiting for document routing to be finalized as yet.
  48. Log in as the user the document was routed to.
  49. Navigate to the "My ToDo" widget.
  50. Approve the document by electronic signing it.
  51. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the registry setting is disabled and the record was filed when the form was routed.
  52. Open the "Final To Draft Override" form.
  53. Select a finalized document to return to draft status.
  54. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  55. Complete process.
  56. Open the "Delete Document" form.
  57. Choose to delete one of the user modeled/aliased documents.
  58. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  59. Complete the process.
Topics
• Modeling • Diagnosis • Document Routing • NX
Update 3 Summary | Details
Identity Manager - logins
Scenario 1: Avatar "Identity Manager" - User Login validation
Specific Setup:
  • Have a system with the "Identity Manager" module installed and configured
  • Have an active "Identity Manager" user set up in form "User Definition" [UserA]
Steps
  1. Launch the Avatar login screen
  2. Select the desired system code in the "System Code" field
  3. Populate the "Username" field with the user name for [UserA]
  4. Populate the "Password" field with the password for [UserA]
  5. Click [Sign In]
  6. In the "Search Forms" search box, search for any form
  7. Validate the form is launched as expected
  8. Populate any desired fields in the form
  9. Submit the form
  10. Validate submission is successful
Topics
• Cache • NX
Update 6 Summary | Details
Routing Admin Dashboard
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Routing Admin Dashboard
Scenario 1: Routing Admin Dashboard - Search results validations
Specific Setup:
  • The system is set up for "Rule Based Routing"
  • The system has over a "1000" documents filed in a single rule based routing queue.[QueueA]
Steps
  1. Open the 'Routing Admin Dashboard' form.
  2. Select [QueueA] in the 'Queue' field and leave all other search criteria fields unpopulated
  3. Click [Search]
  4. Validate up to "1000" rows of data are displayed in the grid. (The system maximum number of rows that can be displayed in the grid)
  5. in the "Queue Search Criteria" section, use any of the search fields to narrow down the results, for example the "Select Programs" field
  6. Click [Search]
  7. Validate the results are displayed as expected, based on the search criteria
Topics
• Rule Based Routing
Update 7 Summary | Details
Avatar NX - connecting to external ODBC sources
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • NX External ODBC Data Sources
Scenario 1: 'NX External ODBC Data Sources" form - Functionality
Specific Setup:
  • Have access to an external database server [ServerA], that contains table data [TableA]. For example, an "SQL Server"
  • Using the windows "ODBC Data Source Administrator", create a "User Data Source" [DataSourceA] configured to use an "SQL Server" driver to connect to the [ServerA]
Steps
  1. Open form "NX External ODBC Data Sources"
  2. Select "Create New" in the "Action" field
  3. Set the "Driver Type" field to desired value
  4. Set the "ODBC Data Source Name" to [DataSourceA]
  5. Set the "Server Host/IP" to the "Host" name or "IP Address" of [ServerA]
  6. Set the "Username" field to the login user name for [ServerA]
  7. Set the "Password" field to the login password for [ServerA]
  8. Click the [File] button
  9. Click the [OK] button
  10. Return to form "NX External ODBC Data Sources"
  11. Select "Edit Existing" in the "Action" field
  12. In the "Select Existing Data Source" field, select [DataSourceA]
  13. Validate the "Driver Type" field is populated with the value selected in step 3
  14. Validate the "ODBC Data Source Name" is populated with [DataSourceA]
  15. Validate the "Server Host/IP" field is set to the value populated in step 5
  16. Validate the "Username" field is set to the value populated in step 6
  17. Validate the Password field is populated with the value populated in step 7
  18. Exit the form
Scenario 2: 'Import Reports' Form (Avatar NX) - Validate "Import Report for Command Button Launch" requiring and External "ODBC" connection
Specific Setup:
  • An external database exists on [ServerA] that contains data in a table [TableA].
  • Using form "NX External ODBC Data Sources", have an "ODBC Data Source" created [DataSourceA] configured to use an ODBC driver to connect to the external database server [ServerA]
  • Have a Crystal Report [ReportA] created that connects to the external database [ServerA] using [DataSourceA] in order to display data in [TableA].
Steps
  1. Open form "Import Reports"
  2. Select "Import Report for Command Button Launch" in the "Select Import Type"
  3. Select "Import New Report" in the "New or Existing Report" field
  4. Set the "Report Description" field to a desired report name
  5. Click the [Select Report for Import] button
  6. Navigate to the location of [ReportA]
  7. Select the report
  8. Select "Yes" in field "Does This Report Require ODBC Connections In Addition To The Current Database" field
  9. In the "Connection Type" field, select "myAvatar NX"
  10. In the "myAvatar NX Connection" field, select [DataSourceA]
  11. Click [Add New Connection] button
  12. Validate the Additional ODBC Connections text box is populated with the [DataSourceA] connection
  13. Click [Submit]
  14. Return to the form
  15. Select "Import Report for Document Routing" in the "Select Import Type"
  16. Select "Update Existing Report" in the "New or Existing Report" field
  17. From the "Existing Report" field drop down list, select the report added in step 4
  18. Validate the "Report Description" field is the value set in step 4
  19. Validate the "Additional ODBC Connections" text box is populated with the connection for [DataSourceA]
  20. Close the form
Scenario 3: 'Import Reports' Form (Avatar NX) - Validate "Import Report for Document Routing" requiring an External "ODBC" connection
Specific Setup:
  • An external cache database exists on [ServerA] that contains data in a table [TableA].
  • Using form "NX External ODBC Data Sources", have an "ODBC Data Source" created [DataSourceA] configured to use an ODBC driver to connect to the external database server [ServerA]
  • Have a Crystal Report [ReportA] created that connects to the external database [ServerA] using [DataSourceA] to display data in [TableA].
Steps
  1. Open form "Import Reports"
  2. Select "Import Report for Document Routing" in the "Select Import Type"
  3. Select "Import New Report" in the "New or Existing Report" field
  4. Set the "Report Description" field to a desired report name
  5. Click the [Select Report for Import] button
  6. Navigate to the location of [ReportA]
  7. Select the report
  8. Select "Yes" in field "Does This Report Require ODBC Connections In Addition To The Current Database" field
  9. In the "Connection Type" field, select "myAvatar NX"
  10. In the "myAvatar NX Connection" field, select [DataSourceA]
  11. Click [Add New Connection] button
  12. Validate the Additional ODBC Connections text box is populated with the [DataSourceA] connection
  13. Click [Submit]
  14. Return to the form
  15. Select "Import Report for Document Routing" in the "Select Import Type"
  16. Select "Update Existing Report" in the "New or Existing Report" field
  17. From the "Existing Report" field drop down list, select the report added in step 4
  18. Validate the "Report Description" field is the value set in step 4
  19. Validate the "Additional ODBC Connections" text box is populated with the connection for [DataSourceA]
  20. Close the form
Topics
• Query/Reporting • NX • Import Reports
Update 8 Summary | Details
Prepared for future functionality.
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Product Scrolling Free Text Templates (CWS)
Scenario 1: Product Scrolling Free Text Templates- Validate functionality
Specific Setup:
  • In form "Product Scrolling Free Text Templates", have a templates set up for a text field in any product form. For this test the "Notes" field of the "Ambulatory Progress Notes" form is used
Steps
  1. Open the product form.
  2. Right click in the "Notes Text" field.
  3. Select one of the "System" templates created.
  4. Validate the text populated is as expected for that template.
  5. Right click in the "Notes" field.
  6. Select the "System" template created.
  7. Validate the text populated, is as expected for that template.
  8. Submit the form.
  9. Re-open the product form.
  10. Select the row just submitted.
  11. Validate all template data filed in the text field is present on the form.
  12. Close the form.
Scenario 2: Modeled Form - Validate Table Row Data
Specific Setup:
  • In the parent namespace "Avatar PM", have modeled form [PMFormA] that contains a table [PMTableA] which includes a binary storage field, for example a picture or signature field. [PMFormA]
  • In a child application for example "Avatar CWS", have an envelope [CWSEnvelopeA] that is set with prompt "Include Envelope in CDR" set to "Yes" and contains a form [CWSFormA], that includes a [CWSTableA] which includes a binary storage field
  • Have a report [PMReportA] to display data filed in [PMTableA]
  • Have a report [CWSReportA] to display data filed in [CWSTableA]
  • Have a report [CWSReportB] set up to display data filed in [CWSTableA] but using the "CDR" table in "Avatar PM" to display the data
  • [UserA] has access to [PMFormA] and [CWSFormA]
  • Have two clients [ClientA] and [ClientB] who are enrolled in an open episode
Steps
  1. Select [ClientA]
  2. Open [PMFormA]
  3. Select an episode
  4. Populate data in all fields, including the picture and/or signature fields. [Note the values populated in each field]
  5. Submit the form
  6. Validate the form files successfully
  7. Repeat step 2 a thru c, two or more times. [Note the total amount of times the form was submitted]
  8. Select [ClientB]
  9. Open [CWSFormA]
  10. Select an episode
  11. Populate data in all fields, including the picture and/or signature fields. [Note the values populated in each field]
  12. Submit the form
  13. Validate the form files successfully
  14. Repeat step 2 a thru 2c, two or more times. [Note the total amount of times the form was submitted]
  15. Run [PMReportA] to display table rows filed in the [PMTableA]
  16. Validate the total row count display is consistent with total amount of times the form was submitted, noted in step 2
  17. Validate the values populated in each row is consistent with values noted after each submission in step 2
  18. Run [CWSReportA] to display data rows filed in the [CWSTableA] table
  19. Validate the total row count display is consistent with total amount of times the form was submitted, noted in step 4
  20. Validate the values populated in each row is consistent with values noted after each submission in step 4
  21. Run [CWSReportB] to display data rows filed in the [CWSTableA] table using the "CDR" table in "Avatar PM"
  22. Validate the total row count display is consistent with total amount of times the form was submitted, noted in step 4
  23. Validate the values populated in each row is consistent with values noted after each submission in step 4
Topics
• Cache • Modeling • NX
Update 10 Summary | Details
Modeled Form
Scenario 1: Modeled Form - Validate results of an "Event" defined on field using the "Sum" calculation type
Specific Setup:
  • A client with an existing episode is identified. [Client A].
  • Have access to a user modeled form [Form A] defined with:
  • Four 'Dictionary" fields, for this example: [FieldA], [FieldB], [FieldC] and [FieldD] are used
  • Each dictionary field has two or more numerical values for selection
  • One "Integer" type field [FieldE]
  • In 'Form Definition', for [FieldD], define an event that will sum the values in fields [FieldA], [FieldB], [FieldC] and [FieldD] and populate that value in [FieldE], when as specific value [TriggerValue] is selected in [FieldD].
  • This can be done with the following event setup on [FieldD]:
  • 'Type of Event' is "Result of Input With Value Checking".
  • 'Compare with For Event' is "Specific Value", with the "Specific Value (Dictionary)" field set to the [TriggerValue]
  • 'Relationship to Comparison Value' to Trigger Event ' is "Include"
  • 'Table Column to Have Value Changed on Event': [FieldE]
  • 'Set Table Column Value' is "Calculation Result".
  • 'Calculation Type' is "Sum".
  • 'Fields for Summation': [FieldA], [FieldB], [FieldC] and [FieldD]
Steps
  1. Select [ClientA]
  2. Access [FormA]
  3. In [FieldA], select a dictionary value
  4. In [FieldB], select dictionary value
  5. In [FieldC], select dictionary value
  6. In [FieldD], select a dictionary value other than the [TriggerValue] defined in the set up
  7. Validate [FieldE] is not populated with any summation value, as expected
  8. In [FieldD] select the [TriggerValue] defined in the set up
  9. Validate the expected summation value is populated in [FieldE] (sum of [FieldA] thru [FieldD]).
  10. Click [Submit]
  11. Validate the form files successful
  12. Access [FormA]
  13. Select the row filed in step 2
  14. Validate all fields are populated, as expected

"

Scheduling Widgets
Scenario 1: Scheduling Widget - Data validations
Specific Setup:
  • In form "Console Widget Configuration", have the following two "Scheduling" widgets defined:
  • [WidgetA] - Includes an "SQL Query" to display data in the "SYSTEM.appt_data" table and includes fields; "ApptDate", "StartTime", "ClientID", "StaffID", "Staff_Name" and "User Logged In"
  • [WidgetB] - Includes an "SQL Query" to display data in the "SYSTEM.appt_data_all" table and includes fields; "ApptDate", StartTime", "Staff_Name", StaffID and "User Logged In"
  • Have both widgets placed on the home view for [UserA]
  • Log in as [UserA]
Steps
  1. On the home view, refresh [WidgetA]
  2. Valid the "ApptDate" column contains the expected data
  3. Valid the "StartTime" column contains the expected data
  4. Valid the "ClientID" column contains the expected data
  5. Valid the "StaffID" column contains the expected data
  6. Valid the "Staff_Name" column contains the expected data
  7. Valid the "UserLoggedIn column contains the expected data
  8. On the home view, refresh [WidgetB]
  9. Valid the "ApptDate" column contains the expected data
  10. Valid the "StartTime" column contains the expected data
  11. Valid the "StaffID" column contains the expected data
  12. Valid the "Staff_Name" column contains the expected data
  13. Valid the "UserLoggedIn column contains the expected data
Modeled form - with "Table" alias
Scenario 1: Modeled form with table aliasing - validations
Specific Setup:
  • Have a modeled table, [TableA] that contains:
  • Fields mapped to a "Table" alias [Alias1], for example the "Treatment History" table alias
  • Fields mapped to another "Table" alias [Alias2], for example the ""Patient Notes" table alias
  • Have a modeled form [FormA] that contains fields from [TableA] in two sections:
  • [Section1] contains just fields mapped to table alias [Alias1]
  • [Section2] contains just fields mapped to table alias [Alias2]
  • For [ClientA] in [EpisodeA], populate the fields available in [FormA] and file two rows of data [Row1] and [Row2]
  • Create another table in "Table Definition" [TableB] which includes the same fields mapped in [Alias2] from the "Patient Notes" table alias
  • In "Form Definition", edit [FormA]
  • Add [TableA] as a secondary table
  • Edit [Section2], and replace the "Table" aliased fields from [TableA] with the same ones form [TableB] and submit the form
Steps
  1. Open [FormA]
  2. Select [ClientA]
  3. Select [Episode1]
  4. In the pre-display, validate [Row1] and [Row2] a displayed for selection
  5. Select [Row1]
  6. Click the [Delete] button to delete the row
  7. Click [Yes] to confirm the deletion
  8. Exit the form
  9. Open [FormA]
  10. Select [ClientA]
  11. Select [Episode1]
  12. In the pre-display, validate [Row1] is no longer present and [Row2] a displayed, as expected
  13. Select [Row2]
  14. Click the [Edit] button to edit the row
  15. Edit any field on the form [FieldA]
  16. Click [Submit]
  17. Validate the form files successfully
  18. Open [FormA]
  19. Select [ClientA]
  20. Select [Episode1]
  21. In the pre-display, select [Row2]
  22. Click the [Edit] button to edit the row
  23. Validate the change made to [FieldA] is present, as expected
Sub System Codes
Scenario 1: Sub System Code's - User access to clients validation
Specific Setup:
  • Have a system with multiple system code functionality enabled
  • Have system has a root system code [RootA] and three sub system codes on the system
  • [SubA] - assigned to only "ProgramA"
  • [SubB] - assigned to only "ProgramB"
  • [SubC] - assigned to only "ProgramC"
  • User "STAFFA" has three clients in his caseload
  • "ClientA" - admitted to "ProgramA"
  • "ClientB" - admitted to "ProgramB"
  • "ClientC" - admitted to "ProgramC"
Steps
  1. Log into the root system code [RootA] as [StaffA]
  2. Validate "ClientA", "ClientB" and "ClientC" are displayed in the user's "My Clients" widget
  3. Select each client and open any client based form, for example "Update Client Data"
  4. Add or edit any data and submit the form
  5. Validate the form files successfully
  6. Log out of [RootA]
  7. Log into sub system code, [SubA]
  8. Validate "ClientA" is displayed in the users in the user's "My Clients" widget
  9. Validate "ClientB" and "ClientC" are not displayed in the user's "My Clients" widget
  10. In the "Search Clients" field, search for "ClientB"
  11. Validate "ClientB" is not found
  12. In the "Search Clients" field, search for "ClientC"
  13. Validate "ClientC" is not found
  14. Select "ClientA" and open any client based form,
  15. Add or edit any data and submit the form
  16. Validate the form files successfully
  17. Log out of [SubA]
  18. Log into sub system code, [SubB]
  19. Validate "ClientB" is displayed in the user's "My Clients" widget
  20. Validate "ClientA" and "ClientC" are not displayed in the user's "My Clients" widget
  21. In the "Search Clients" field, search for "ClientA"
  22. Validate "ClientA" is not found
  23. In the "Search Clients" field, search for "ClientC"
  24. Validate "ClientC" is not found
  25. Select ClientA open any client based form,
  26. Add or edit any data and submit the form
  27. Validate the form files successfully
  28. Log out of [SubB]
  29. Log into sub system code, [SubC]
  30. Validate "ClientC" is displayed in the user's "My Clients" widget
  31. Validate "ClientA" and "ClientB" are not displayed in the user's "My Clients" widget
  32. In the "Search Clients" field, search for "ClientA"
  33. Validate "ClientA "is not found
  34. In the "Search Clients" field, search for "ClientB"
  35. Validate "ClientB" is not found
  36. Select "ClientC" open any client based form,
  37. Add or edit any data and submit the form
  38. Validate the form files successfully
Topics
• Modeling • NX • Scheduling Calendar • Console Widget Configuration
Update 18 Summary | Details
Clinical Pathways - Client Header
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Clinical Pathway Enrollment
  • Clinical Pathway Disenrollment
  • HomeView.Client Information widget
  • Client Header
Scenario 1: Clinical Pathway Disenrollment - Disenroll from a clinical pathway
Specific Setup:
  • A pathway is defined in the 'Clinical Pathway Definition' form. "Yes" is selected in the 'Alert When Accessed' field. This pathway is also defined with a color (Pathway A).
  • Dictionary values must be defined for the "CWS" file - "(5010) Reason for Disenrollment" data element. This can be done in the 'Dictionary Update' form.
Steps
  1. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  2. Verify the 'Date of Enrollment' field defaults to the current date.
  3. Select "Pathway A" in the 'Pathway Name' field.
  4. Select "Yes" for 'Primary Pathway'.
  5. Click [Submit] and [No].
  6. Validate the 'My Clients' list contains "Client A" in the pathway color.
  7. Select "Client A" and access the 'Clinical Pathway Disenrollment' form.
  8. Validate the 'Date of Disenrollment' field defaults the current date.
  9. Select "Pathway A" in the 'Pathway Name' field.
  10. Select desired value in the 'Reason for Disenrollment' field.
  11. Click [Submit] and [No].
  12. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  13. Validate the Pre-Display contains the prior enrollment record in "Pathway A" and the 'Disenrollment Date' field contains the date of disenrollment.
  14. Click [Edit].
  15. Validate a "Clinical Pathway Enrollment" message is displayed stating: Disenrollment exists. Enrollment can only be viewed.
  16. Click [OK].
  17. Validate the 'Date of Enrollment' field is disabled and cannot be edited.
  18. Validate the 'Pathway Name' field is disabled and cannot be edited.
  19. Validate the 'Primary Pathway' field is disabled and cannot be edited.
  20. Close the form.
  21. Validate the 'My Clients' list contains "Client A" without the pathway color.
Scenario 2: Clinical Pathway Enrollment - Add an enrollment
Specific Setup:
  • A pathway is defined in the 'Clinical Pathway Definition' form. "Yes" is selected in the 'Alert When Accessed' field. This pathway is also defined with a color (Pathway A).
  • Multiple other pathways are defined with colors in the 'Clinical Pathway Definition' form.
  • A client is enrolled in an existing episode (Client A).
Steps
  1. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  2. Verify the 'Date of Enrollment' field defaults to the current date.
  3. Select "Pathway A" in the 'Pathway Name' field.
  4. Select "Yes" for 'Primary Pathway'.
  5. Click [Submit] and [No].
  6. Validate the 'My Clients' list contains "Client A" in the pathway color.
  7. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  8. Click [Add] to add an additional pathway.
  9. Select "Pathway A" in the 'Pathway Name' field.
  10. Validate a message is displayed stating: Client is already enrolled in the selected Clinical Pathway.
  11. Click [OK].
  12. Select any new value in the 'Pathway Name' field.
  13. Select "Yes" for 'Primary Pathway'.
  14. Validate a message is displayed stating: Primary Pathway already exists. "Pathway A" is the current Primary Pathway.
  15. Click [OK].
  16. Select "No" in the 'Primary Pathway' field.
  17. Click [Submit] and [No].
  18. Validate the 'My Clients' list contains "Client A" in the primary pathway color.
Scenario 3: Clinical Pathway Enrollment - Delete an enrollment
Specific Setup:
  • A pathway is defined in the 'Clinical Pathway Definition' form. "Yes" is selected in the 'Alert When Accessed' field. This pathway is also defined with a color (Pathway A).
  • A client is enrolled in an existing episode (Client A).
Steps
  1. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  2. Verify the 'Date of Enrollment' field defaults to the current date.
  3. Select "Pathway A" in the 'Pathway Name' field.
  4. Select "Yes" for 'Primary Pathway'.
  5. Click [Submit] and [No].
  6. Validate the 'My Clients' list contains "Client A" in the pathway color.
  7. Select "Client A" and access the 'Clinical Pathway Enrollment' form.
  8. Select the existing enrollment in the pre-display.
  9. Click [Delete].
  10. Validate a message is displayed stating: Are you sure you want to delete this item?
  11. Click [Yes].
  12. Validate a message is displayed stating: Enrollment was successfully deleted.
  13. Click [OK] and exit the form.
  14. Validate the 'My Clients' list contains "Client A" without the pathway color.
Scenario 4: Validate support for Clinical Pathways in the 'My Clients' widget, 'Client Header' and 'Client Information' widget
Specific Setup:
  • A pathway is defined in the 'Clinical Pathway Definition' form. "Yes" is selected in the 'Alert When Accessed' field. This pathway is also defined with a color and icon (Pathway A).
  • A client is enrolled in "Pathway A" (Client A). This can be done in the 'Clinical Pathway Enrollment' form.
  • "Client A" has an existing appointment scheduled for the current date.
  • The 'Client Information' widget is added to the HomeView.
  • "Clinical Pathway" must be added to the 'Field to Include in Client Header' field in the 'Client Lookup/Header Configuration Manager' form.
Steps
  1. Access the 'My Clients' widget.
  2. Validate the 'My Clients' widget contains "Client A" and it is displayed in the color defined in the 'Clinical Pathway Definition' form.
  3. Click on the "Site" section of the 'My Clients' widget.
  4. Select the site that has the appointment for "Client A".
  5. Validate "Client A" is displayed in the color defined in the 'Clinical Pathway Definition' form.
  6. Click the 'My Clients' widget "Client" tab
  7. Double click on "Client A".
  8. Validate a "Client Alert" message is displayed stating: Selected Client is Enrolled in the following Clinical Pathways: PATHWAY A. Continue?
  9. Click [Yes].
  10. Validate the 'Client Chart' and 'Client Header' are displayed.
  11. Validate the 'Client Header' contains "Client A" and it is displayed in the color defined in the 'Clinical Pathway Definition' form.
  12. Validate the 'Client Header' contains the icon defined in the 'Clinical Pathway Definition' form.
  13. Close the chart.
  14. Select "Client A" in the 'My Clients' widget.
  15. Validate a "Client Alert" message is displayed stating: Selected Client is Enrolled in the following Clinical Pathways: PATHWAY A. Continue?
  16. Click [Yes].
  17. Access the 'Client Information' widget.
  18. Validate the 'Client Information' widget contains "Client A" and it is displayed in the color defined in the 'Clinical Pathway Definition' form.
  19. Validate the 'Client Information' widget contains the icon defined in the 'Clinical Pathway Definition' form.
Scenario 5: Avatar NX - Validate support for Clinical Pathways in the 'My Clients' list, 'Recent Clients' list, 'Client Information' header, and 'Clients for Today' option
Specific Setup:
  • A pathway is defined in the 'Clinical Pathway Definition' form. "Yes" is selected in the 'Alert When Accessed' field. This pathway is also defined with a color and icon (Pathway A).
  • A client is enrolled in an existing episode and is in the user's caseload. This client is also enrolled in "Pathway A" (Client A).
  • A client is enrolled in an existing episode and is not in the user's caseload. This client is also enrolled in "Pathway A" (Client B).
  • The 'Include Client Information header in view' setting is enabled for the user's myDay view.
  • The logged in user must have an appointment scheduled for the current date for "Client A" and "Client B".
  • "Clinical Pathway" must be added to the 'Field to Include in Client Header' field in the 'Client Lookup/Header Configuration Manager' form.
Steps
  1. Navigate to the 'My Clients' list.
  2. Validate "Client A" is displayed in the pathway color.
  3. Select "Client A" in the 'My Clients' list.
  4. Validate an alert is displayed stating: Selected Client is Enrolled in the following Clinical Pathways: "Pathway A". Continue?
  5. Click [Yes].
  6. Validate the 'Client Information' header displays "Client A" in the pathway color. Please note: the client name above the 'Client Information' header with the white background will display the pathway color. The client name in the 'Client Information' header with the blue background will not display the pathway color.
  7. Validate the 'Client Information' header displays the icon associated to "Pathway A".
  8. Click [Clear Client].
  9. Search for and select "Client B".
  10. Validate an alert is displayed stating: Selected Client is Enrolled in the following Clinical Pathways: "Pathway A". Continue?
  11. Click [Yes].
  12. Validate "Client B" is displayed in the 'Recent Clients' list in the pathway color.
  13. Validate the 'Client Information' header displays "Client B" in the pathway color. Please note: the client name above the 'Client Information' header with the white background will display the pathway color. The client name in the 'Client Information' header with the blue background will not display the pathway color.
  14. Validate the 'Client Information' header displays the icon associated to "Pathway A".
  15. Click [Clear Client].
  16. Navigate to the 'Clients for Today' item.
  17. Validate the 'Clients for Today' list contains "Client A" and "Client B" in the pathway color.
  18. Navigate to the 'My Clients' list.
  19. Select the "Site" section.
  20. Select the site that has the appointments for "Client A" and "Client B".
  21. Validate the 'Site' list contains "Client A" and "Client B" in the pathway color.
Topics
• NX • Clinical Pathway • Client Banner • Widgets • My Clients
Update 19 Summary | Details
'Team Assignment' form, 'My Clients' Widget', and 'Order Entry Console- Consult Teams
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Team Definition
  • Dictionary Update (CWS)
  • Order Code Setup
  • Order Entry User Role
  • Orders This Episode
  • Order Entry User Definition
Scenario 1: 'Team Definition' form - adding a Physician Team
Specific Setup:
  • A User Role must exist in the system. (User Role A)
  • A User must exist in the system. (User A)
Steps
  1. Access the ‘Team Definition’ form.
  2. Set the ‘Team ID’ field to "TeamIDA".
  3. Set the ‘Team Description’ field to "Team A".
  4. Select “Yes” in the ‘Active’ field.
  5. Select “Yes” in the ‘Physician Team’ field.
  6. Select “Yes” in the ‘Team Accepts Consult Orders’ field.
  7. Click [Select Roles].
  8. Select “User Role A” and click [OK].
  9. Validate the ‘Team Information’ field contains “User Role A”.
  10. Click [File].
  11. Validate a message displays stating “Filed” and click [OK].
  12. Set the ‘Team ID’ field to any value.
  13. Set the ‘Team Description’ field to "Team B".
  14. Select “Yes” in the ‘Active’ field.
  15. Select “Yes” in the ‘Physician Team’ field.
  16. Select “Yes” in the ‘Team Accepts Consult Orders’ field.
  17. Click [Select Roles].
  18. Select “User Role A” and click [OK].
  19. Validate a message is displayed stating “The following Roles are assigned to other Physician Teams. Role: User Role A Team(s): TeamIDA Do you wish to continue?” and click [Cancel].
  20. Validate a message is displayed stating “Cancelled” and click [OK].
  21. Set the ‘Team ID’ field to any value.
  22. Set the ‘Team Description’ field to "Team C".
  23. Select “Yes” in the ‘Active’ field.
  24. Select “Yes” in the ‘Physician Team’ field.
  25. Select “Yes” in the ‘Team Accepts Consult Orders’ field.
  26. Click [Select Users].
  27. Select “User A” and click [OK].
  28. Validate the ‘Team Information’ field contains “User A”.
  29. Click [File].
  30. Validate a message displays stating “Filed.” and click [OK].
  31. Set the ‘Team ID’ field to any value.
  32. Set the ‘Team Description’ field to "Team D".
  33. Select “Yes” in the ‘Active’ field.
  34. Select “Yes” in the ‘Physician Team’ field.
  35. Select “Yes” in the ‘Team Accepts Consult Orders’ field.
  36. Click [Select Users].
  37. Select “User A” and click [OK].
  38. Validate a message is displayed stating “The following Users are assigned to other Physician Teams. Users: User A Team(s): Team C Do you wish to continue?” and click [Cancel].
  39. Validate a message is displayed stating “Cancelled” and click [OK].
  40. Close the form.
Scenario 2: 'Admission' form - admission of a new client with a 'Team Assignment' filed
Specific Setup:
  • The 'RADplus->System Security->Team Definition->->->Update Physician Team Caseload based on Admitting or Attending Practitioner' registry setting must be set to "Y".
  • Please log out of the application and log back in after completing the above configuration.
  • Avatar PM 2021 Update 118 and RADplus 2021 Update 116 must be installed to utilize full functionality.
  • A Physician team must exist via the 'Team Definition' form with two Practitioners (Practitioner A and Practitioner B)
  • The user must have access to the 'SYSTEM.RADplus_caseload' table.
  • The user must have access to Crystal Reports or SQL tool.
Steps
  1. Access the 'Admission' form.
  2. Admit a new client (Client A) ensuring that "Practitioner A" is selected in the 'Admitting Practitioner' field.
  3. Create a report using the ‘SYSTEM.RADplus_caseload’ table with the following fields included: 'PATID', 'USERID', 'caseload_type_csm_code', and 'caseload_type_csm_value' .
  4. Filter the report by selecting "Client A's PATID" in the 'PATID' field.
  5. Validate there are two rows displayed for the team assignment for the new client created.
  6. Validate the ‘USERID’ field contains the USERID for the user logged into the application.
  7. Validate the 'caseload_type_CSM_code' field contains a row with "ADMITTING" and two rows with "TEAM".
  8. Validate the 'caseload_type_CSM_value' field contains a row with "Admitting Practitioner Caseload" and two rows with "Team Caseload Assignment".
  9. Close the report.
  10. Access the 'Admission' form.
  11. Admit a new client (Client B) ensuring that "Practitioner B" is selected in the 'Admitting Practitioner' field.
  12. Create a report using the ‘SYSTEM.RADplus_caseload’ table with the following fields included: 'PATID', 'USERID', 'caseload_type_csm_code', and 'caseload_type_csm_value' .
  13. Filter the report by selecting "Client A's PATID" in the 'PATID' field.
  14. Validate there are two rows displayed for the team assignment for the new client created.
  15. Validate the ‘USERID’ field contains the USERID for the user logged into the application.
  16. Validate the 'caseload_type_CSM_code' field contains a row with "ATTENDING" and two rows with "TEAM".
  17. Validate the 'caseload_type_CSM_value' field contains a row with "Attending Practitioner Caseload" and two rows with "Team Caseload Assignment".
  18. Close the report.
Scenario 3: OE NX - Orders This Episode - Create a new 'Consult' order, copy order, modify order and DC order.
Specific Setup:
  • Avatar OE 2021 Update 61, RADplus 2022 Update 19, RADplus 2021 Update 116 and myAvatar NX Release 2021.11.00 are required in order to utilize full functionality.
  • An 'Order Type' of "Consult Order" must exist in the Order Entry Tabled Files '(500) Order Types' dictionary with the following extended attributes set:
  • '(501) Order Type Category' extended attribute = "Consult"
  • '(506) Default Orders To Open-Ended When No Default Duration' = "No"
  • '(561) Display/Require Consult Clinician Name/Team prompts' = "Show both, require neither"
  • '(565) Default Consult 'Clinician Team' prompt based on 'Clinician Name' = "Yes"
  • Please log out of the application and log back in after completing the above configuration.
  • A user role must exist that has the ability to perform actions for "Consult Orders". This is done in the 'Order Entry User Role' form. (OE User Role A)
  • A user must exist who is associated with "OE User Role A". (User A)
  • A team must be defined in 'Team Definition' with the following configuration (Team A):
  • 'Physician Team' set to "Yes"
  • 'Team Accepts Consult Orders' is set to "Yes"
  • "User A" must be selected after clicking [Select Users]
  • 'Disable Adding Client to Caseload' is set to "No"
  • 'Use Team Finalizer as Default Supervisor for Document Routing' is set to "No"
  • A consult-type order code must exist that has "Team A" selected in the 'Limit Consult 'Clinician Team' prompt to the following Team' field and the 'Limit Consult 'Clinician Name' Prompt to Staff members having the following Category' field must have multiple values selected and must have the value associated with the Staff Member associated with "User A" selected. (Consult Order Code A)
  • A client must have an active episode. (Client A)
  • “Client A” must have a ‘Date of Birth’, ‘Sex’ and address on file in the ‘Update Client Data’ form, as well as information filed in the ‘Allergies and Hypersensitivities’ form, ‘Diagnosis’ form, and in the ‘Height’ and ‘Weight’ fields in the ‘Vitals Entry’ form.
  • "User A" is logged in to the application.
Steps
  1. Select “Client A” and access the Order Entry Console.
  2. Search for and select “Consult Order Code A” in the ‘New Order Field’.
  3. Select “Team A” in the ‘Clinician Team’ field.
  4. Search for and select “User A” in the ‘Clinician Name’ field.
  5. Set the ‘Frequency’ field to “AS NEEDED”.
  6. Set the ‘Duration’ field to “48” and click [Hours].
  7. Click [Add to Scratchpad] and [Sign].
  8. Validate the ‘Order grid’ contains an order for “Consult Kidneys ClinicianTeam: Team A Clinician Name: User A AS NEEDED”.
  9. Select the order and click [Copy].
  10. Validate the ‘Clinician Team’ field contains “Team A”.
  11. Validate the ‘Clinician Name’ field contains “User A”.
  12. Validate the ‘Frequency’ field contains “AS NEEDED”.
  13. Validate the ‘Duration’ field contains “48” and [Hours] is selected.
  14. Click [Add to Scratchpad] and [Sign].
  15. Validate the ‘Interactions’ dialog displays.
  16. Override all interactions and click [Save Override and Exit].
  17. Validate the ‘Order grid’ contains two orders for “Consult Kidneys ClinicianTeam: Team A Clinician Name: User A AS NEEDED”.
  18. Select the 2nd order and click [Modify].
  19. Set the ‘Frequency’ field to “3 TIMES A DAY”.
  20. Click [Add to Scratchpad] and [Sign].
  21. Validate the ‘Interactions’ dialog displays.
  22. Override all interactions and click [Save Override and Exit].
  23. Validate the ‘Order grid’ contains an order for "Consult Kidneys ClinicianTeam: Team A Clinician Name: User A 3 TIMES A DAY” and an order for “Consult Kidneys ClinicianTeam: Team A Clinician Name: User A AS NEEDED”.
Scenario 4: 'My Clients' widget - Add to My Caseload, Remove From My Caseload
Specific Setup:
  • Avatar PM 2021 Update 118, RADplus 2021 Update 116, and myAvatar Client Update 2513-003 or 3201-001 must be installed in order to utilize full functionality.
  • The 'RADplus->Database Management->Client Lookup->->->Enable enhanced caseload management from the 'Clients and Data' widget' registry setting must be set to the User Role associated to the user logged into the application.
  • Please log out of the application and log back in after completing the above configuration.
  • "User A" must have access to all tables.
  • "User A" must be logged into the application.
Steps
  1. Access the ‘Admission’ form.
  2. Fill out all required fields and click [Submit]. This will be "Client A"
  3. Validate that "Client A" displays in the ‘Recent Clients’ list.
  4. Right click "Client A" and select [Add to My Caseload].
  5. Validate the ‘My Clients’ widget contains “Client A”.
  6. Right click "Client A" under 'My Clients' and select [Remove From My Caseload].
  7. Validate that “Client A” no longer displays in the ‘My Clients’ widget.
  8. Create a report using the 'SYSTEM.radplus_caseload' table using the following fields: 'PATID', 'USERID' and 'caseload_type_CSM_value, hidden'.
  9. Filter the report by selecting "Client A's PATID" in the 'PATID' field.
  10. Validate the report contains no rows of data for "Client A".
  11. Access the ‘Team Definition’ form.
  12. Click [Select Team].
  13. Select “PT1 (Physician Team Test)” in the ‘Select one of the following’ field and click [OK].
  14. Select the ‘Individual Client Assignment’ section.
  15. Search for and select “Client A” in the ‘Client ID’ field.
  16. Select the ‘Team Definition’ section and click [File].
  17. Validate a "Filed" message is displayed and click [OK].
  18. Close the form.
  19. Validate that “Client A” does not display in the ‘My Clients’ widget.
  20. Refresh the report using the 'SYSTEM.radplus_caseload' table
  21. Validate a row is displayed for "Client A".
  22. Validate the 'caseload_type_CSM_value' field contains "Team Caseload Assignment".
  23. Validate the 'hidden' field contains "X"
  24. Right click "Client A" in 'Recent Clients' and select [Add to My Caseload].
  25. Validate the ‘My Clients’ widget contains “Client A”.
  26. Refresh the report using the 'SYSTEM.radplus_caseload' table
  27. Validate the report contains two rows of data for "Client A".
  28. Validate the 'caseload_type_CSM_value' field contains "Individually Selected" for the new row added.
  29. Validate the 'hidden' field contains no value for both rows.
  30. Right click "Client A" and select [Remove From Physician Team].
  31. Validate the ‘My Clients’ widget contains “Client A”.
  32. Refresh the report using the 'SYSTEM.radplus_caseload' table
  33. Validate there is only one row of data for "Client A" that has "Individually Selected" in the 'caseload_type_CSM_value' field.
  34. Right click "Client A" under 'My Clients' and select [Remove From My Caseload].
  35. Validate that “Client A” no longer displays in the ‘My Clients’ widget.
  36. Refresh the report using the 'SYSTEM.radplus_caseload' table.
  37. Validate the report contains no rows of data for "Client A"
  38. Close the report.
Topics
• Team Definition
Update 23 Summary | Details
Support is added for other products and modules
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Clinical Document Viewer
  • Patient Health Questionnaire-A
  • Review/Co-Sign Documents (PM)
  • User Definition
  • Individual Progress Note
  • Review To Do Item
Scenario 1: Approve a document from the "Sign" tab of the 'My To Do's' widget
Specific Setup:
  • User must have the 'My To Do's' widget on the HomeView.
  • Document routing is enabled on the 'Progress Notes (Group and Individual)' form.
  • A user is defined with an associated staff member (User A, Staff Member A).
  • Must be logged in as "User A".
  • A client is enrolled in an existing episode (Client A). "Staff Member A" is the admitting practitioner for "Client A".
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select "Independent Note" in the 'Progress Note For' field.
  4. Select the desired value in the 'Note Type' field.
  5. Enter the desired value in the 'Notes Field' field.
  6. Select "Final" in the 'Draft/Final' field.
  7. Click [File Note].
  8. Validate that the 'Confirm Document' dialog is displayed with the progress note data, including an electronic signature at the bottom for the current user/staff member as the Author.
  9. Click [Accept and Route].
  10. Validate the 'Route Document To' dialog is displayed.
  11. Select the 'Admitting Practitioner' and validate "Staff Member A" displays as the 'Approver'.
  12. Click [Submit].
  13. Validate a "Progress Notes" dialog is displayed stating: Note Filed.
  14. Click [OK].
  15. Navigate to the 'My To Do's' widget.
  16. Validate there is a To-Do for the progress note filed in the previous steps.
  17. Select the "Sign" tab.
  18. Validate the 'Search Documents' field contains the progress note document for "Client A".
  19. Validate the 'Document' field contains the progress note data, including an electronic signature at the bottom for "Staff Member A" as both the Author and Admitting Practitioner.
  20. Click [Accept].
  21. Validate the 'Search Documents' field no longer contains the progress note document for "Client A".
  22. Validate the 'Accepted Documents' field contains the accepted progress note document for "Client A".
  23. Click [Sign All].
  24. Enter the password for "User A" in the 'Verify Password' dialog and click [OK].
  25. Validate the 'Accepted Documents' field no longer contains the progress note document for "Client A".
  26. Access the 'Clinical Document Viewer' form.
  27. Select "Client" in the 'Select All or Individual Client' field.
  28. Select "Client A" in the 'Select Client' field.
  29. Click [Process].
  30. Validate the progress note document appears in the document list and double click on it to view.
  31. Validate that the document displays with the progress note data and an electronic signature for the Author & Admitting Practitioner.
  32. Close the form.
Scenario 2: Approve a document from the "All" tab of the 'My To Do's' widget
Specific Setup:
  • User must have the 'My To Do's' widget on the HomeView.
  • Document routing is enabled on the 'Progress Notes (Group and Individual)' form.
  • A user is defined with an associated staff member (User A, Staff Member A).
  • Must be logged in as "User A".
  • A client is enrolled in an existing episode (Client A). "Staff Member A" is the admitting practitioner for "Client A".
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select "Independent Note" in the 'Progress Note For' field.
  4. Select the desired value in the 'Note Type' field.
  5. Enter the desired value in the 'Notes Field' field.
  6. Select "Final" in the 'Draft/Final' field.
  7. Click [File Note].
  8. Validate that the 'Confirm Document' dialog is displayed with the progress note data, including an electronic signature at the bottom for the current user/staff member as the Author.
  9. Click [Accept and Route].
  10. Validate the 'Route Document To' dialog is displayed.
  11. Select the 'Admitting Practitioner' and validate "Staff Member A" displays as the 'Approver'.
  12. Click [Submit].
  13. Validate a "Progress Notes" dialog is displayed stating: Note Filed.
  14. Click [OK].
  15. Navigate to the 'My To Do's' widget.
  16. Select the "All" section.
  17. Validate there is a To-Do for the progress note filed in the previous steps.
  18. Click [Approve Document].
  19. Validate the document is displayed with the progress note data, including an electronic signature at the bottom for "Staff Member A" as both the Author and Admitting Practitioner.
  20. Click [Accept].
  21. Enter the password for "User A" in the 'Verify Password' dialog and click [OK].
  22. Validate the To-Do is no longer displayed.
  23. Access the 'Clinical Document Viewer' form.
  24. Select "Client" in the 'Select All or Individual Client' field.
  25. Select "Client A" in the 'Select Client' field.
  26. Click [Process].
  27. Validate the progress note document appears in the document list and double click on it to view.
  28. Validate that the document displays with the progress note data and an electronic signature for the Author & Admitting Practitioner.
  29. Close the form.
Scenario 3: Patient Health Questionnaire-A - File an assessment with document routing enabled
Specific Setup:
  • A client is enrolled in an existing episode (Client A).
  • Document routing is enabled on the 'Patient Health Questionnaire-A' form.
Steps
  1. Select "Client A" and access the 'Patient Health Questionnaire-A' form.
  2. Populate all required and desired fields.
  3. Select "Final" in the 'Assessment Status' field.
  4. Validate a message is displayed stating: Once set to "Final", the data will be view only.
  5. Click [Submit].
  6. Validate a 'Confirm Document' dialog is displayed.
  7. Validate the assessment is displayed with an electronic signature for the logged in user/associated staff member as the Author.
  8. Click [Accept].
  9. Enter the password for the logged in user and click [OK].
Scenario 4: "Append Documents" - Document display validations
Specific Setup:
  • A client must be enrolled in an existing episode (Client A).
  • "Client A" must have a document routed to the logged in user for the current date (Document A).
Steps
  1. Access the 'Append Documents' form.
  2. Select the form type used for one of the documents in the 'Form Type' field.
  3. Select "Client A" in the 'Entity' field.
  4. Enter the current date in the 'From Date' and 'End Date' fields.
  5. Select "Document A" in the 'List of Documents' field.
  6. Populate the "From Date" and "End Date" fields
  7. Enter the desired value in the 'New Comments to Be Appended in the Original Document' field.
  8. Click [Submit].
  9. Validate the 'Confirm Document' dialog is displayed:
  10. Validate the document is displayed in the expected format, including proper spacing between characters and lines on the form.
  11. Validate field heading characters are in bold, when applicable.
  12. Validate there is an electronic signature from the Appended Author at the end of the document.
  13. Click [Accept].
  14. Enter the user's password and click [Verify].
  15. Validate the form files successfully.
Scenario 5: Review/Co-Sign Documents - Document Routed and Document Approved
Specific Setup:
  • Document routing is enabled on the 'Progress Notes (Group and Individual)' form.
  • A user is defined with an associated staff member (User A, Staff Member A).
  • Must be logged in as "User A".
  • A client is enrolled in an existing episode (Client A). "Staff Member A" is the admitting practitioner for "Client A".
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select "Independent Note" in the 'Progress Note For' field.
  4. Select the desired value in the 'Note Type' field.
  5. Enter the desired value in the 'Notes Field' field.
  6. Select "Final" in the 'Draft/Final' field.
  7. Click [File Note].
  8. Validate that the 'Confirm Document' dialog is displayed with the progress note data, including an electronic signature at the bottom for the current user/staff member as the Author.
  9. Click [Accept and Route].
  10. Validate the 'Route Document To' dialog is displayed.
  11. Select the 'Admitting Practitioner' and validate "Staff Member A" displays as the 'Approver'.
  12. Click [Submit].
  13. Validate a "Progress Notes" dialog is displayed stating: Note Filed.
  14. Click [OK].
  15. Access the 'Review/Co-Sign Documents' form.
  16. Select "Progress Notes (Group and Individual)" in the 'Form Type' field.
  17. Select "Client A" in the 'Entity' field.
  18. Enter the current date in the 'From Date' and 'To Date' fields.
  19. Select the progress note for "Client A" in the 'List of Documents' field.
  20. Click [Submit].
  21. Validate the 'Confirm Document' dialog is displayed and contains the progress note data and an electronic signature for "Staff Member A" as both the Author & Admitting Practitioner.
  22. Click [Accept].
  23. Enter the password for "User A" in the 'Verify Password' dialog and click [OK].
  24. Validate a message is displayed stating: Review/Co-Sign Documents has completed. Do you wish to return to form?
  25. Click [No].
Scenario 6: Document Routing - Approve and Route - Final Approver Required
Specific Setup:
  • A client is enrolled in an existing episode (Client A).
  • Document routing is enabled for the 'Progress Notes (Group and Individual)' form and "Yes" is selected for 'Require Final Approver'.
  • A user is defined with an associated staff member (Staff Member A) and "Yes" selected in the 'User Can Be Final Approver' field in 'User Definition' (User A).
  • Must be logged in as "User A".
  • Must have the 'My To Do's' widget accessible on the HomeView.
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select "Independent Note" in the 'Progress Note For' field.
  4. Select the desired value in the 'Note Type' field.
  5. Enter the desired value in the 'Notes Field' field.
  6. Select "Final" in the 'Draft/Final' field.
  7. Click [File Note].
  8. Validate that the 'Confirm Document' dialog is displayed with the progress note data, including an electronic signature at the bottom for "Staff Member A" as the Author.
  9. Click [Accept and Route].
  10. Validate the 'Route Document To' dialog is displayed.
  11. Validate the "Search here - Supervisor" field is not required.
  12. Validate the "Search here - Team" field is not required.
  13. Validate the "Search here - Add Approver" field is required.
  14. Validate that as long as a "Final Approver" checkbox is checked, the "Submit" button is enabled.
  15. Validate that if a "Final Approver" checkbox is not checked, the "Submit" button is disabled.
  16. Add "Staff Member A" as the 'Final Approver'.
  17. Click [Submit].
  18. Validate a "Progress Notes" dialog is displayed stating: Note Filed.
  19. Click [OK].
  20. Navigate to the 'My To Do's' widget.
  21. Validate there is a To-Do for the progress note filed in the previous steps.
  22. Click [Approve Document].
  23. Validate the document is displayed with the progress note data, including an electronic signature at the bottom for "Staff Member A" as both the Author and Final Approver.
  24. Click [Accept].
  25. Enter the password for "User A" in the 'Verify Password' dialog and click [OK].
  26. Validate the To-Do is no longer displayed.
Scenario 7: Document Routing - "Allow Transcriber" functionality
Specific Setup:
  • A user has an associated staff member and has "Yes" selected in the 'Transcriber' field in 'User Definition (User A).
  • A user has an associated staff member and is not a transcriber in 'User Definition' (User B).
  • "User A" and "User B" have the 'My To Do's' widget on their HomeView.
  • Document routing is enabled for 'Progress Notes (Group and Individual)' and 'Allow Transcriber' is set to "Yes".
  • Must be logged in as "User A".
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select "Independent Note" in the 'Progress Note For' field.
  4. Select the desired value in the 'Note Type' field.
  5. Enter the desired value in the 'Notes Field' field.
  6. Select "Final" in the 'Draft/Final' field.
  7. Click [File Note].
  8. Validate a "Select Author" dialog is displayed.
  9. Select the staff member associated to "User B" in the 'Select Author' field.
  10. Click [Submit] and verify successful filing.
  11. Log out.
  12. Log in as "User B".
  13. Navigate to the 'My To Do's' widget.
  14. Validate there is a To Do for "Client A".
  15. Click [Approve Document].
  16. Validate the document is displayed with the progress note data and has electronic signatures for the Transcriber (User A) & Author (User B).
  17. Click [Respond].
  18. Enter the desired value in the 'Response for Transcriber' field and click [OK].
  19. Validate the To Do is no longer displayed.
  20. Log in as "User A".
  21. Navigate to the 'My To Do's' widget.
  22. Validate there is a To Do for "Client A".
  23. Click [Review To Do Item].
  24. Validate the 'To Do Information' field contains the response from "User B".
  25. Select "Reviewed" in the 'Set To Do Item to Reviewed' field.
  26. Click [Submit].
  27. Validate the To Do is no longer displayed.
Scenario 8: Treatment Plan - File a Treatment Plan with Document Routing
Specific Setup:
  • Client must be admitted into an active episode with problems recorded in 'Problem List' form (Client A).
  • Google Chrome Browser settings are set to enable Autofill for passwords and the logged in user's password has been saved.
Steps
  1. Select "Client A" and access the 'Treatment Plan' form.
  2. Click [Add].
  3. Set the 'Plan Date' field to the current date.
  4. Select any value in the 'Plan Type' field.
  5. Select any value from 'Problem List'.
  6. Navigate to another view or open a form.
  7. Navigate back to the 'Treatment Plan' form and validate that all data appears as expected in the 'Problem List' grid.
  8. Click [New Row].
  9. Select any value from the 'Role' field in the 'Participation' section.
  10. Select 'Staff ID' and enter "Staff Member A".
  11. Validate that the selected staff member's name displays in the 'Participant Name' field.
  12. Select any value from the 'Plan Author' field.
  13. Select any value from the 'Notification' field,
  14. Add multiple staff members as needed.
  15. Enter any value in the 'Strengths' field.
  16. Enter any value in the 'Weakness' field.
  17. Enter any value in the 'Discharge Planning' field.
  18. Select "Draft" in the 'Draft/Final' field.
  19. Click [Launch Plan].
  20. Select the problem from the 'Tree View'.
  21. Select any value from the Status field.
  22. Click [Add New Goal].
  23. Enter any value (a large amount of data) in the 'Goal' field.
  24. Validate that the data wraps correctly and displays as expected.
  25. Select any value from the Status field.
  26. Click [Add New Objective].
  27. Enter any value (a large amount of data) in the 'Objective' field.
  28. Validate that the data wraps correctly and displays as expected.
  29. Select any value from the Status field.
  30. Click [Add New Intervention].
  31. Enter any value in the 'Intervention' field.
  32. Select any value in the 'Status' field.
  33. Click [Return to Plan].
  34. Select "Final" in the 'Draft/Final' field.
  35. Click [Submit] and [Sign].
  36. Validate the 'Password' field autofill's with the user's password that is saved in Google Chrome.
  37. Press the 'Enter' key.
  38. Select the desired staff member in the 'Route Document To' field and click [Add].
  39. Click [Submit]
  40. Select "Client A" and navigate to the 'Documentation' view.
  41. Validate the recently filed 'Treatment Plan' is displayed in the 'Console Widget Viewer' when selected.
Topics
• Document Routing • Progress Notes • My To Do's • NX • To-Do's
Update 34 Summary | Details
All Documents Widget- 'Form Specific PreDisplay' filter
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • HomeView - Primary All Documents Widget
Scenario 1: All Documents Widget - 'Form Specific Pre Display' validations
Specific Setup:
  • Have a form [FormA] that contains a "Pre-display" configured in the form. For example, a modeled form with pre-display turned "On" in "Form Definition". (Note the names of the fields defined to display in the pre-display)
  • [ClientA] that has two or more rows of data filed in [FormA] in an episode [EpisodeA]
  • Have a form [FormB] that does contain a "Pre-display" in the form. For example, form "Vitals Entry
  • [ClientA] that has two or more rows of data filed in [FormB]
  • Have the "All Documents Widget" configured with both [FormA] and [FormB] in the widget
  • Have the "All Documents Widget" included on a users home view [UserA]
Steps
  1. At the Home View, select [ClientA]
  2. Select "Episode A" from the "Episodes" field drop down list on the home view
  3. Navigate to the "All Documents Widget"
  4. Click the "All Forms" tab
  5. Select [FormB] from the "Form Description" drop down list
  6. Validate the row filed in the setup for [FormA] is displayed in the results list
  7. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns, are as expected
  8. Scroll to the bottom of the results list
  9. Validate the "Form Specific PreDisplay" checkbox is not enabled, since the form does not contain a "Pre-display"
  10. Deselect [FormB] from the "Form Description" drop down list
  11. Select [FormA] from the "Form Description" drop down list
  12. Validate the rows filed in the setup for [FormB] are displayed in the results list
  13. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns, are as expected
  14. Scroll to the bottom of the results list
  15. Click the "Form Specific PreDisplay" checkbox
  16. Validate the label name of the "Form Specific PreDisplay" check box field now says ""Form Specific PreDisplay - [FormB]"
  17. Validate the "Pre-display" results list contains results for each a row field in the set up
  18. Validate all pre-display "Column" header labels and data displayed in each column is as expected
  19. Click any desired column, for example a "Draft/Final" column and select a value to filter on
  20. Validate data row pre-display results are displayed as expected based on the value selected
  21. Deselect the "Form Specific PreDisplay" check box
  22. Validate the results are returned to values displayed in step 3b
Console Widget Viewer - Perceptive viewer
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Console Widget Viewer
Scenario 1: Console Widget Viewer (Avatar NX) - Validate Document display in "Perceptive" enabled systems
Specific Setup:
  • "Perceptive" document storage method is enabled and configured in the system
  • A form [FormA] has been enabled for document routing
  • A console widget [WidgetA] has been created for [FormA] in form "Console Widget Configuration"
  • [FormA] has been submitted for [ClientA] and the document has been routed and approved
  • [UserA] has [WidgetA] and the "Console Widget Viewer" widget on their home view
  • Log in as [UserA]
Steps
  1. Select any client [ClientA]
  2. Select "All Episodes" from the "Episodes" drop down list on the home view
  3. On the home view, navigate to [WidgetA]
  4. Locate the row filed for [FormA]
  5. Click the [View] button for the row
  6. Validate a tab is opened in the "Console Widget Viewer" for [FormA]
  7. Scroll down the document
  8. Validate the data displayed is as expected
  9. Validate the document image properties contains a "Thumbnail Image" object
  10. Click the "Show/Hide Thumbnails" button
  11. Verify the "Thumbnail Image" object is removed
  12. Click the Thumbnail Image object again
  13. Verify the Thumbnail Image object is returned to the document
  14. Click the "Annotations" Icon
  15. Click "Create Annotation"
  16. Select an area to annotate and select an annotation type. For example "Highlight"
  17. Click "Add"
  18. Validate the selected are is annotated on the document
  19. Click the [Save] Icon in the top left of the document image
  20. Validate the selected area is saved annotated on the document, as expected
  21. Click the "Zoom Slider" arrow icon on the bottom left of the document image
  22. Drag the slider to the left to reduce the document text size
  23. Validate the document text size is reduced
  24. Drag the slider to the right to reduce increase the document text size
  25. Validate the document text size is increased
  26. Click the [Close All] button
  27. Validate the tab in the "Console Widget Viewer" for [FormA] is removed
All Documents Widget -
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Console Widget Viewer
Scenario 1: All Documents Widget - column data validations
Specific Setup:
  • Have three forms [FormA], [FormB] and [FormC] with data rows filed for [ClientA].
  • One or more forms contains a workflow status "Draft/Final" column
  • The "All Documents Widget" and the "Console Widget Viewer" are placed on a users home view [UserA]
  • Log in as [UserA]
Steps
  1. Select "Client A" and navigate to the "All Documents Widget".
  2. Click the "All Forms" tab
  3. Click 'Form Description' selection filter and select just one form, for example [FormA]
  4. Validate the rows listed in the "Form Description" column results are only the rows filed for [FormA]
  5. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns, are as expected
  6. Click to select any row
  7. Validate a tab is displayed in the "Console Widget Viewer", for [FormA] containing the expected data
  8. Click 'Form Description' selection filter and select any two forms, for example [FormA] and [FormB]
  9. Validate the rows listed in the "Form Description" column results are only the rows filed for [FormA] and [FormB]
  10. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns, are as expected for each row
  11. Click to select a row for each form
  12. Validate a tab is displayed in the "Console Widget Viewer" for [FormA] and [FormB], containing the expected data
  13. Click 'Form Description' selection filter and select another set of multiple forms, for example [FormB] and [FormC]
  14. Validate the rows listed in the "Form Description" column results are only the rows filed for [FormB] and [FormC]
  15. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns are as expected for each row
  16. Click to select a row for each form
  17. Validate a tab is displayed in the "Console Widget Viewer" for [FormB] and [FormC], containing the expected data
  18. Click the "Refresh" button for the "All Documents Widget"
  19. Click the "All Forms" tab
  20. Click 'Form Description' selection filter and select [FormA], [FormB] and [FormC]
  21. Validate the rows listed in the "Form Description" column results are only the rows filed for [FormA] and [FormB] and [FormC]
  22. Validate the data results displayed in the "Form Description", "Episode", "Date", "Data Entry By" and "Workflow Status" columns, are as expected for each row
  23. Click to select a row for each form
  24. Validate a tab is displayed in the "Console Widget Viewer" for each form, containing the expected data
Topics
• Widgets • NX • Perceptive • Console Widget
Update 35 Summary | Details
Document Routing - Table Aliasing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • GA_ASO_Entity_Form
  • Dynamic Form - Disclosure
  • Dynamic Form - Form Definition - Confirm
  • Envelope Import (CWS)
  • Dynamic Form - Document Management Form Re-Mapping - Selection Dialog
  • Table Definition (CWS)
  • Dynamic Form Draft Final Document Routing
  • Form Definition (CWS)
  • DOCMANAGEMENT3000
  • Final to Draft Override (CWS)
  • Dynamic Form ICD10 Diagnosis
  • Dynamic Form Final To Draft Override
  • Final to Draft Override (PM)
  • User Definition
  • PM USER37
  • Dynamic Form Disclosure Management Alias Primary
Scenario 1: User Modeled Form - Table Aliasing on secondary tables
Specific Setup:
  • A user modeled form set up with the primary table (not aliased) and secondary table aliased to the Disclosure Management data. Please note: For internal testing purposes the disclosure management SQL table is validated. For your test, you may alias a different form. Note that table and validate it in place of SYSTEM.disclo_mgmt.
  • Admit or select a test client.
Steps
  1. Open the "Document Routing Setup" form.
  2. Enable document routing for the user modeled form created during setup.
  3. Open the "Registry Settings" form.
  4. Enable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  5. Open the user modeled form from setup.
  6. Fill out all the fields on the form.
  7. Set "Draft/Final" to "Draft".
  8. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  9. Open the user modeled form from setup.
  10. Fill all the fields on the form.
  11. Set "Draft/Final" to "Final".
  12. Click "Accept" or "Sign" on the "Confirm Document" screen.
  13. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the form was flagged as Final.
  14. Validate the secondary tables was also aliased to the SYSTEM.disclo_mgmt SQL table.
  15. Open the user modeled form from setup.
  16. Fill all the fields on the form.
  17. Set "Draft/Final" to "Final".
  18. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  19. Route to another user.
  20. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the registry setting mentioned previously is enabled and the document routing is not finalized.
  21. Log in as the user the document was routed to.
  22. Navigate to the "My ToDo" widget.
  23. Approve the document by electronic signing it.
  24. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the registry setting mentioned previously is enabled and the document routing is now finalized for the form.
Scenario 2: Child Namespace User Modeled Diagnosis form with table aliasing
Specific Setup:
  • A user modeled form set up with the primary table being aliased to the Diagnosis History (ICD10).
  • Admit or select a test client.
Steps
  1. Open the user modeled form from setup.
  2. Fill out all the fields on the form.
  3. Set "Draft/Final" to "Draft".
  4. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  5. Open the user modeled form from setup.
  6. Fill all the fields on the form.
  7. Set "Draft/Final" to "Final".
  8. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the form was flagged as Final.
  9. Open the "Document Routing Setup" form.
  10. Enable document routing for the user modeled created during setup.
  11. Open the user modeled form from setup.
  12. Fill out all the fields on the form.
  13. Set "Draft/Final" to "Draft".
  14. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  15. Open the user modeled form from setup.
  16. Fill all the fields on the form.
  17. Set "Draft/Final" to "Final".
  18. Click "Accept" or "Sign" on the "Confirm Document" screen.
  19. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the form was flagged as Final.
  20. Open the "Registry Settings" form.
  21. Enable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  22. Open the user modeled form from setup.
  23. Fill out all the fields on the form.
  24. Set "Draft/Final" to "Draft".
  25. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  26. Open the user modeled form from setup.
  27. Fill all the fields on the form.
  28. Set "Draft/Final" to "Final".
  29. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  30. Route to another user.
  31. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the registry setting mentioned previously is enabled and the document routing is not finalized.
  32. Log in as the user the document was routed to.
  33. Navigate to the "My ToDo" widget.
  34. Approve the document by electronic signing it.
  35. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the registry setting mentioned previously is enabled and the document routing is now finalized for the form.
  36. Open the "Registry Settings" form.
  37. Disable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  38. Open the user modeled form from setup.
  39. Fill out all the fields on the form.
  40. Set "Draft/Final" to "Draft".
  41. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the form was filed in draft mode.
  42. Open the user modeled form from setup.
  43. Fill all the fields on the form.
  44. Set "Draft/Final" to "Final".
  45. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  46. Route to another user.
  47. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was added to the table because the registry setting mentioned previously is disabled and system is not waiting for document routing to be finalized.
  48. Log in as the user the document was routed to.
  49. Navigate to the "My ToDo" widget.
  50. Approve the document.
  51. By viewing the SQL table from the PM namespace, SYSTEM.client_diagnosis_record, validate a row was not added to the table because the registry setting is disabled, and the record was filed when the form was routed.
  52. Open the "Final To Draft Override" form.
  53. Select a finalized document to return to draft status.
  54. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  55. Complete process.
  56. Open the "Delete Document" form.
  57. Choose to delete one of the user modeled/aliased documents.
  58. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  59. Complete the process.
Scenario 3: Parent Namespace User Modeled Disclosure Management form with table aliasing
Specific Setup:
  • A user modeled form set up with the primary table being aliased to the Disclosure Management data. Please note: For internal testing purposes the disclosure management SQL table is validated. For your test, you may alias a different form. Note that table and validate it in place of SYSTEM.disclo_mgmt.
  • Admit or select a test client.
Steps
  1. Open the user modeled form from setup.
  2. Fill out all the fields on the form.
  3. Set "Draft/Final" to "Draft".
  4. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  5. Open the user modeled form from setup.
  6. Fill all the fields on the form.
  7. Set "Draft/Final" to "Final".
  8. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the form was flagged as Final.
  9. Open the "Document Routing Setup" form.
  10. Enable document routing for the user modeled created during setup.
  11. Open the user modeled form from setup.
  12. Fill out all the fields on the form.
  13. Set "Draft/Final" to "Draft".
  14. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  15. Open the user modeled form from setup.
  16. Fill all the fields on the form.
  17. Set "Draft/Final" to "Final".
  18. Click "Accept" or "Sign" on the "Confirm Document" screen.
  19. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the form was flagged as Final.
  20. Open the "Registry Settings" form.
  21. Enable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  22. Open the user modeled form from setup.
  23. Fill out all the fields on the form.
  24. Set "Draft/Final" to "Draft".
  25. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  26. Open the user modeled form from setup.
  27. Fill all the fields on the form.
  28. Set "Draft/Final" to "Final".
  29. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  30. Route to another user.
  31. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the registry setting mentioned previously is enabled and the document routing is not finalized.
  32. Log in as the user the document was routed to.
  33. Navigate to the "My ToDo" widget.
  34. Approve the document by electronic signing it.
  35. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the registry setting mentioned previously is enabled and the document routing is now finalized for the form.
  36. Open the "Registry Settings" form.
  37. Disable the registry setting "RADplus->Document Routing->Routing Setup->->->Alias Data File Upon Document Routing Completion".
  38. Open the user modeled form from setup.
  39. Fill out all the fields on the form.
  40. Set "Draft/Final" to "Draft".
  41. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the form was filed in draft mode.
  42. Open the user modeled form from setup.
  43. Fill all the fields on the form.
  44. Set "Draft/Final" to "Final".
  45. Click "Accept and Route" or "Sign and Route" on "Confirm Document" pop up.
  46. Route to another user.
  47. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was added to the table because the registry setting mentioned previously is disabled, the system is not waiting for document routing to be finalized.
  48. Log in as the user the document was routed to.
  49. Navigate to the "My ToDo" widget.
  50. Approve the document by electronic signing it.
  51. By viewing the SQL table from the PM namespace, SYSTEM.disclo_mgmt, validate a row was not added to the table because the registry setting is disabled, and the record was filed when the form was routed.
  52. Open the "Final To Draft Override" form.
  53. Select a finalized document to return to draft status.
  54. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  55. Complete process.
  56. Open the "Delete Document" form.
  57. Choose to delete one of the user modeled/aliased documents.
  58. A message should pop up noting that "Please note that filed Alias data will not be deleted or altered in any way as a result of filing the override for this row".
  59. Complete the process.
Topics
• Document Routing • NX • Modeling • Diagnosis
Update 38 Summary | Details
Rule Based Routing - Encounter Date
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Routing Role Definition
  • Routing Queue Definition
  • Routing Assignment Definition
  • Routing Configuration Definition
  • Medical Coding Note
  • Rule Based Routing Widget (Home View)
  • Routing Worklist Item
  • Admission (Outpatient)
  • Financial Eligibility
  • Routing Role Assignment
  • Routing Views Definition
  • DDTT Note w/ Encounter Info
  • Client Charge Input
Scenario 1: Rule Based Routing widget - Validating 'Encounter Date' after submitting progress note - New Service
Specific Setup:
  • The system is set up for Rule based routing with a queue functionality.
  • The 'Rule Based Routing' widget is placed on HomeView.
  • Any progress note form is set up for the document routing (i.e. Progress Notes (Group and Individual)). Note the form name and product name where it is created for further testing. Please Note: The 'Medical Coding Note' form used in this test is the copy of the progress note and renamed to 'Medical Coding Note'.
  • Document Routing Setup:
  • Document routing functionality is enabled for the 'Medical Coding Note' form.
  • Routing Role Definition:
  • Must have an active routing role created in the form.
  • Routing Queue Definition:
  • Must have an active queue set up where the 'Medical Coding Note' is selected in the 'Form' field. Note the name of the queue for further testing.
  • Routing Assignment Definition:
  • Two routing assignments are created such that one assignment that completes a workflow and one that doesn't. Note the name of the assignments.
  • Routing Configuration Definition:
  • The 'Product' field is set to the product where the progress note form exists (i.e. CWS). Note the value for further testing.
  • The progress note form configured above is selected in the 'Form' field. Note the name of the form for further testing.
  • The queue created is selected in the "Initial Assignment" field. Note the name of the queue for further testing.
  • Select 'Yes' in the 'Active' field.
  • Desired value is selected in the 'Initial Service Status' field. Note the value for further validation.
  • Desired value in the 'Coding Complete Service Status' fields. Note the value for further testing.
  • Apply Status without Coding Form Submission = 'No'. Note the value for further testing.
  • Routing Views Definition:
  • Desired columns are defined to display in the 'Rule Based Routing' widget.
  • User Definition:
  • A staff member is associated with the current user.
  • Guarantor:
  • An existing guarantor is identified.
  • Admission:
  • An existing outpatient client is identified with the guarantor assigned to the client. Note the Client ID/name, Admission program, Admission date.
  • Service Code:
  • An existing professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance Form:
  • The service fee and HCPCS code are defined for the service code identified above.
  • Medical Coding Note:
  • A final note is filed for the client using 'New Service' option.
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue identified in the setup section.
  3. Select desired queue from the 'Queue' dropdown list.
  4. Select 'All Statuses' from the 'Status' dropdown.
  5. Click [Refresh].
  6. Verify the document finalized from the 'Medical Coding Note' in the setup is available in this widget.
  7. Verify the 'Encounter Date' column displays the 'Date of Service' from the medical coding note.
Scenario 2: Rule Based Routing widget - Validating 'Encounter Date' after submitting progress note - Existing Appointment
Specific Setup:
  • The system is set up for Rule based routing with a queue functionality.
  • The 'Rule Based Routing' widget is placed on HomeView.
  • Any progress note form is set up for the document routing (i.e. Progress Notes (Group and Individual)). Note the form name and product name where it is created for further testing. Please Note: The 'Medical Coding Note' form used in this test is the copy of the progress note and renamed it to 'Medical Coding Note'.
  • Document Routing Setup:
  • Document routing functionality is enabled for the 'Medical Coding Note' form.
  • Routing Role Definition:
  • Must have an active routing role created in the form.
  • Routing Queue Definition:
  • Must have an active queue set up where the medical coding form is selected in the 'Form' field. Note the name of the queue for further testing.
  • Routing Assignment Definition:
  • Two routing assignments are created such that one assignment that completes a workflow and one that doesn't. Note the name of the assignments.
  • Routing Configuration Definition:
  • The 'Product' field is set to the product where the progress note form exists (i.e. CWS). Note the value for further testing.
  • The progress note form configured above is selected in the 'Form' field. Note the name of the form for further testing.
  • The queue created is selected in the "Initial Assignment" field. Note the name of the queue for further testing.
  • Select 'Yes' in the 'Active' field.
  • Desired value is selected in the 'Initial Service Status' field. Note the value for further validation.
  • Desired value in the 'Coding Complete Service Status' fields. Note the value for further testing.
  • Apply Status without Coding Form Submission = 'No'. Note the value for further testing.
  • Routing Views Definition:
  • Desired columns are defined to display in the 'Rule Based Routing' widget.
  • User Definition:
  • A staff member is associated with the current user.
  • Guarantor:
  • An existing guarantor is identified.
  • Admission:
  • An existing outpatient client is identified with the guarantor assigned to the client. Note the Client id/name, Admission program, Admission date.
  • Service Code:
  • An existing professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance Form:
  • The service fee and HCPCS code are defined for the service code identified above.
  • Scheduling Calendar:
  • A new appointment is created for the client. Note the date of the appointment.
  • Medical Coding Note:
  • A final note is filed for the client using 'Existing Appointment' option. The 'Date of Service' field of the medical coding note defaults to the appointment date.
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue identified in the setup section.
  3. Select desired queue from the 'Queue' dropdown list.
  4. Select 'All Statuses' from the 'Status' dropdown.
  5. Click [Refresh].
  6. Verify the document finalized from the 'Medical Coding Note' using 'Existing Appointment' option is available in this widget.
  7. Verify the 'Encounter Date' column displays the 'Date of Service' from the medical coding note that is appointment date of the client.
Scenario 3: Rule Based Routing widget - Validating 'Encounter Date' after submitting modeled form with date/time
Specific Setup:
  • The system is set up for Rule based routing with a queue functionality.
  • The 'Rule Based Routing' widget is placed on HomeView.
  • A modeled form is set up for the document routing. Note the form name and the product name where it is created for further testing. Please Note: The 'DDTT Note w/Encounter Info' form used in this test is the modeled form with date/time.
  • Document Routing Setup:
  • Document routing functionality is enabled for the 'DDTT Note w/Encounter Info' form.
  • Routing Role Definition:
  • Must have an active routing role created in the form.
  • Routing Queue Definition:
  • Must have an active queue set up where the medical coding form is selected in the 'Form' field. Note the name of the queue for further testing.
  • Routing Assignment Definition:
  • Two routing assignments are created such that one assignment that completes a workflow and one that doesn't. Note the name of the assignments.
  • Routing Configuration Definition:
  • The 'Product' field is set to the product where the progress note form exists (i.e. CWS). Note the value for further testing.
  • The progress note form configured above is selected in the 'Form' field. Note the name of the form for further testing.
  • The queue created is selected in the "Initial Assignment" field. Note the name of the queue for further testing.
  • Select 'Yes' in the 'Active' field.
  • Desired value is selected in the 'Initial Service Status' field. Note the value for further validation.
  • Desired value in the 'Coding Complete Service Status' fields. Note the value for further testing.
  • Apply Status without Coding Form Submission = 'No'. Note the value for further testing.
  • Routing Views Definition:
  • Desired columns are defined to display in the 'Rule Based Routing' widget.
  • User Definition:
  • A staff member is associated with the current user.
  • Guarantor:
  • An existing guarantor is identified.
  • Admission:
  • An existing outpatient client is identified with the guarantor assigned to the client. Note the Client id/name, Admission program, Admission date.
  • Service Code:
  • An existing professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance Form:
  • The service fee and HCPCS code are defined for the service code identified above.
  • DDTT Note w/Encounter Info:
  • A final document is filed for the client.
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue identified in the setup section.
  3. Select desired queue from the 'Queue' dropdown list.
  4. Select 'All Statuses' from the 'Status' dropdown.
  5. Click [Refresh].
  6. Verify the document finalized from the 'DDTT Note w/ Encounter Info' in the setup is available in this widget.
  7. Verify the 'Encounter Date' column displays the 'Date of Service' from the note.
Scenario 4: Rule Based Routing widget - Validating 'Encounter Date' after submitting progress note - Independent Note
Specific Setup:
  • The system is set up for Rule based routing with a queue functionality.
  • The 'Rule Based Routing' widget is placed on HomeView.
  • Any progress note form is set up for the document routing (i.e. Progress Notes (Group and Individual)). Note the form name and product name where it is created for further testing. Please Note: The 'Medical Coding Note' form used in this test is the copy of the progress note and renamed it to 'Medical Coding Note'.
  • Document Routing Setup:
  • Document routing functionality is enabled for the 'Medical Coding Note' form.
  • Routing Role Definition:
  • Must have an active routing role created in the form.
  • Routing Queue Definition:
  • Must have an active queue set up where the medical coding form is selected in the 'Form' field. Note the name of the queue for further testing.
  • Routing Assignment Definition:
  • Two routing assignments are created such that one assignment that completes a workflow and one that doesn't. Note the name of the assignments.
  • Routing Configuration Definition:
  • The 'Product' field is set to the product where the progress note form exists (i.e. CWS). Note the value for further testing.
  • The progress note form configured above is selected in the 'Form' field. Note the name of the form for further testing.
  • The queue created is selected in the "Initial Assignment" field. Note the name of the queue for further testing.
  • Select 'Yes' in the 'Active' field.
  • Desired value is selected in the 'Initial Service Status' field. Note the value for further validation.
  • Desired value in the 'Coding Complete Service Status' fields. Note the value for further testing.
  • Apply Status without Coding Form Submission = 'No'. Note the value for further testing.
  • Routing Views Definition:
  • Desired columns are defined to display in the 'Rule Based Routing' widget.
  • User Definition:
  • A staff member is associated with the current user.
  • Guarantor:
  • An existing guarantor is identified.
  • Admission:
  • An existing outpatient client is identified with the guarantor assigned to the client. Note the Client id/name, Admission program, Admission date.
  • Service Code:
  • An existing professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance Form:
  • The service fee and HCPCS code are defined for the service code identified above.
  • Medical Coding Note:
  • A final note is filed for the client using 'Independent Note' option.
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue identified in the setup section.
  3. Select desired queue from the 'Queue' dropdown list.
  4. Select 'All Statuses' from the 'Status' dropdown.
  5. Click [Refresh].
  6. Verify the document finalized from the 'Medical Coding Note' in the setup is available in this widget.
  7. Verify the 'Encounter Date' column displays the date when the medical coding note is filed.
Scenario 5: Rule Based Routing widget - Validating 'Encounter Date' after submitting progress note - Existing Service
Specific Setup:
  • The system is set up for Rule based routing with a queue functionality.
  • The 'Rule Based Routing' widget is placed on HomeView.
  • Any progress note form is set up for the document routing (i.e. Progress Notes (Group and Individual)). Note the form name and product name where it is created for further testing. Please Note: The 'Medical Coding Note' form used in this test is the copy of the progress note and renamed it to 'Medical Coding Note'.
  • Document Routing Setup:
  • Document routing functionality is enabled for the 'Medical Coding Note' form.
  • Routing Role Definition:
  • Must have an active routing role created in the form.
  • Routing Queue Definition:
  • Must have an active queue set up where the medical coding form is selected in the 'Form' field. Note the name of the queue for further testing.
  • Routing Assignment Definition:
  • Two routing assignments are created such that one assignment that completes a workflow and one that doesn't. Note the name of the assignments.
  • Routing Configuration Definition:
  • The 'Product' field is set to the product where the progress note form exists (i.e. CWS). Note the value for further testing.
  • The progress note form configured above is selected in the 'Form' field. Note the name of the form for further testing.
  • The queue created is selected in the "Initial Assignment" field. Note the name of the queue for further testing.
  • Select 'Yes' in the 'Active' field.
  • Desired value is selected in the 'Initial Service Status' field. Note the value for further validation.
  • Desired value in the 'Coding Complete Service Status' fields. Note the value for further testing.
  • Apply Status without Coding Form Submission = 'No'. Note the value for further testing.
  • Routing Views Definition:
  • Desired columns are defined to display in the 'Rule Based Routing' widget.
  • User Definition:
  • A staff member is associated with the current user.
  • Guarantor:
  • An existing guarantor is identified.
  • Admission:
  • An existing outpatient client is identified with the guarantor assigned to the client. Note the Client id/name, Admission program, Admission date.
  • Service Code:
  • An existing professional service code is identified. Note the service code.
  • Service Fee/Cross Reference Maintenance Form:
  • The service fee and HCPCS code are defined for the service code identified above.
  • Client Charge Input:
  • A service is rendered to the client using the service code identified above. Note the service date for further testing.
  • Registry setting:
  • Set the 'Days After Service Date to Allow a Progress Note' registry setting is set to desired value such that the service rendered to the client in 'Client Charge Input' can be associated in the progress note.
  • Medical Coding Note:
  • A final note is filed for the client using 'Existing Service' option for the service rendered using 'Client Charge Input' form.
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue identified in the setup section.
  3. Select desired queue from the 'Queue' dropdown list.
  4. Select 'All Statuses' from the 'Status' dropdown.
  5. Click [Refresh].
  6. Verify the document finalized from the 'Medical Coding Note' in the setup is available in this widget.
  7. Verify the 'Encounter Date' column displays the 'Date of Service' from the medical coding note.
Topics
• Rule Based Routing
Update 42 Summary | Details
Quick Actions - Alerts (Avatar NX Only)
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Client Alerts
  • Quick Actions Page
Scenario 1: Client Alerts - Add Active - Warning
Specific Setup:
  • A client must have an active episode. (Client A)
Steps
  1. Select "Client A" and access the 'Client Alerts' form.
  2. Click [Add].
  3. Select 'Warning (Custom)" in the 'Type of Alert' field.
  4. Set the 'Custom Message' field to "Test Message".
  5. Select "Active" in the 'Active or Active for Date Range' field.
  6. Select "No' in the 'Disabled' field.
  7. Validate the data in the 'Applicable Forms' is displayed alphabetically.
  8. Select 'Vital Entry (Avatar CWS)' in the 'Applicable Forms' field.
  9. Validate the 'Confirm' dialog displays with a message stating: "By selecting individual forms, All forms will be unchecked." and click [OK].
  10. Validate the 'All Episodes from Episode(s)' field is checked.
  11. Select "No" in the 'Community Alert' field.
  12. Click [Submit].
  13. Select "Client A" and access the 'Client Alerts' form.
  14. Select the row and click [Edit].
  15. Validate the 'Type of Alert' field contains "Warning (Custom)".
  16. Validate the 'Custom Message' field contains "Test Message".
  17. Validate "Active" is selected in the 'Active or Active for Date Range' field.
  18. Validate "No" is selected in the 'Disabled' field.
  19. Validate "No" is selected in the 'Community Alert' field.
  20. Close the form.
  21. Access the 'Vitals Entry' form.
  22. Validate the client alert warning displays in the client header with a message stating: "Test Message".
  23. Validate "Add" is selected in the 'Add/Edit/Delete Vital Sign' field.
  24. Set the 'Weight (lbs)' field to "185".
  25. Set the 'Height (ft in)' field to "5 7".
  26. Set the 'Date' field to "Yesterday's date".
  27. Set the 'Time' field to the current time.
  28. Click [Submit].
Scenario 2: Validate accessing various 'Quick Actions' from the 'Client Dashboard'
Specific Setup:
  • A client must be admitted to an active episode (Client A).
  • 'Update Client Data', 'Smoking Assessment', 'Problem List', and 'Alerts' Quick Actions must be assigned to the user in the 'NX View Definition' form.
  • This scenario must be tested in an Avatar NX system.
Steps
  1. Select "Client A" and launch the 'Client Dashboard'.
  2. Validate there is no grey box behind the client's name.
  3. Navigate to the 'Quick Actions' widget.
  4. Click [Update Client Data - Add].
  5. Click outside of the 'Update Client Data' dialog.
  6. Validate the dialog is fixed and centered in the screen.
  7. Click the 'State' field and validate the states are listed alphabetically.
  8. Populate the required and desired fields.
  9. Click [Save].
  10. Click [Smoking Assessment - Add].
  11. Click outside of the 'Smoking Assessment' dialog.
  12. Validate the dialog is fixed and centered in the screen.
  13. Populate the required fields.
  14. Click [Save].
  15. Click [Problems List - Add].
  16. Click outside of the 'Problems List' dialog.
  17. Validate the dialog is fixed and centered in the screen.
  18. Populate the required and desired fields.
  19. Click [Save].
  20. Click [Alerts - Add].
  21. Select "Warning (Custom)" in the 'Type of Alert' field.
  22. Select "All Episodes" in the 'Episode(s)' field.
  23. Enter any value in the 'Custom Message' field.
  24. Select "No" in the 'Disabled' field.
  25. Select any value in the 'Active or Active for Date Range' field.
  26. Select any form in the 'Applicable Forms' field (Form A).
  27. Validate the 'Applicable Forms' are listed alphabetically.
  28. Click [Save].
  29. Close the 'Client Dashboard'.
  30. Access 'Form A'.
  31. Validate the 'Client Alert' message is displayed and contains the message entered in the previous steps.
  32. Click [OK].
  33. Close the form.
Topics
• Client Alerts • NX
Update 43 Summary | Details
Clinical Document Viewer - "Void and Copy"
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Clinical Document Viewer
Scenario 1: Clinical Document Viewer - "Void & Copy" documents
Specific Setup:
  • Perceptive is enabled.
  • User has permissions to void documents.
  • A client must have non-routed documents on file in the 'Clinical Document Viewer' (Client A).
Steps
  1. Access the 'Clinical Document Viewer' form.
  2. Select "Individual" in the 'Select All or Individual Client' field.
  3. Select "Client A" in the 'Select Client' field.
  4. Click [Process].
  5. Select a nonepisodic, non-routed document and view it.
  6. Click [Void] and [Void & Copy]
  7. Select "Client A" in the 'Select Client' field.
  8. Select the desired episode in the 'Select Episode' field.
  9. Enter the desired value in the 'Void Reason' field.
  10. Enter the desired value in the 'Void Comments' field.
  11. Enter the desired value in the 'Change Description' field.
  12. Click [Void] and [Close All Documents].
  13. Select the "Search" section.
  14. Click [Process].
  15. Locate the nonepisodic document that was voided and validate the 'Document Status' contains "Void".
  16. Validate the copied document now has the episode in the 'Episode' column.
  17. Validate the copied document has the new description.
  18. View the copied document and validate it displays as expected.
  19. Click [Close All Documents].
  20. Select the "Search" section.
  21. Click [Close].
Scenario 2: Clinical Document Viewer - "Void" documents
Specific Setup:
  • Perceptive is enabled.
  • User has permissions to void documents.
  • A client must have non-routed documents on file in the 'Clinical Document Viewer'.
Steps
  1. Access the 'Clinical Document Viewer' form.
  2. Select "Individual" in the 'Select All or Individual Client' field.
  3. Select "Client A" in the 'Select Client' field.
  4. Click [Process].
  5. Select any non-routed document and view it.
  6. Click [Void] and [Void] again.
  7. Select the desired value in the 'Void Reason' field.
  8. Enter the desired value in the 'Void Comments' field.
  9. Click [Void] and [Close All Documents].
  10. Locate the document that was just voided and validate the 'Document Status' is now "Void".
  11. Select the "Search" section.
  12. Click [Close].
Scenario 3: Clinical Document Viewer - View documents for an individual client
Specific Setup:
  • A client has one or more documents on file (Client A).
Steps
  1. Access the 'Clinical Document Viewer' form.
  2. Select "Individual" in the 'Select All or Individual Client' field.
  3. Enter "Client A" in the 'Select Client' field.
  4. Select "All" in the 'Episode' field.
  5. Click [Process].
  6. Select the desired document in the 'Search Results' field.
  7. Click to view the document.
  8. Validate document data is displayed.
  9. Click [Close All Documents].
  10. Navigate back to the "Search" section.
  11. Leave the 'Clinical Document Viewer' open and idle for 10 minutes.
  12. After 10 minutes, validate there is no timeout error.
  13. Click [Close].
Topics
• Clinical Document Viewer • NX
2021 Update 85 Summary | Details
The 'Modify "Client" Terminology' registry setting - Filing the ‘Treatment Plan’ form successfully
Scenario 1: The 'Modify "Client" Terminology' registry setting is currently set.
Specific Setup:
  • The 'RADplus->General->->->->Modify "Client" Terminology' registry setting must be set to "Patient^Patients^Patient(s)". This is a Netsmart Staff Only registry setting, please contact your Netsmart Representative to set this value.
  • Please log out of the application and log back in after completing the above configuration.
  • A client must have an active episode. (Client A)
  • “Client A” must have a ‘Date of Birth’ and address on file in the ‘Update Client Data’ form, as well as information filed in the ‘Diagnosis’ form.
Steps
  1. Access the 'Treatment Plan' form.
  2. Set to "Client A".
  3. Click [Select] and [Add].
  4. Set the 'Plan Date' field to the current date.
  5. Set the 'Plan Name' field to "Test".
  6. Click [Plan Type] and select "Test".
  7. Set the 'Plan End Date' field to the current date.
  8. Set the 'Next Review Date' field to a date in the future from the current date.
  9. Select "Draft" and click [Submit].
  10. Validate the 'Treatment Plan' was filed successfully and contains a new row for the client.
The 'Modify "Client" Terminology' registry setting - Form Designer changes are maintained.
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Form Designer (CWS)
Scenario 1: Form designer changes are maintained on the "Physician Order Validation" form after installing any updates into the system, where the 'Modify "Client" Terminology' registry setting is currently set.
Specific Setup:
  • The 'RADplus->General->->->->Modify "Client" Terminology' registry setting must be set to "Patient^Patients^Patient(s)". This is a Netsmart Staff Only registry setting, please contact your Netsmart Representative to set this value.
  • Please log out of the application and log back in after completing the above configuration.
Steps
  1. Access the 'Form Designer' form.
  2. Select "Physician Order Validation" from the 'Forms' field.
  3. Select "(Physician Order Validation)" from the 'Tabs' field.
  4. Click [Show Tab].
  5. Switch the positions of buttons 'Refresh List Of Patients' and 'Select Orders To Validate'.
  6. Click [Save].
  7. Validate the 'Save layout' dialog exists and click [Yes].
  8. Validate the 'Confirm' dialog exists and click [OK].
  9. Click [Submit].
  10. Access the 'Product Updates' form and install any update into the environment.
  11. Click [Discard].
  12. Validate the 'Confirm Close' dialog exists and click [Yes].
  13. Access the 'Physician Order Validation' form.
  14. Validate the 'Form Designer' form changes are maintained for the buttons 'Refresh List Of Patients' and 'Select Orders To Validate'.
Topics
• Registry Settings • Treatment Plan
2021 Update 100 Summary | Details
'System Security Defaults' Form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • System Security Defaults
Scenario 1: 'System Security Defaults' Form - Verification of 'Identity Manager Settings' Section/Fields
Specific Setup:

Avatar Identity Manager module must be installed

Steps
  1. Open the 'System Security Defaults' form (under 'Avatar PM / RADPlus Utilities / System Security / System Administration' path).
  2. Navigate to the 'Identity Manager Settings' section of form.
  3. Enter value including up to 150 characters in the 'Admin DN' configuration field.
  4. Enter value including up to 150 characters in the 'Identity Manager Base DN' configuration field.
  5. Enter/select values for all other 'Identity Manager Settings' configuration fields as required/desired.
  6. Click 'Submit' button to file 'System Security Defaults' form/values.
  7. Re-open 'System Security Defaults' form.
  8. Navigate to the 'Identity Manager Settings' section of form.
  9. Ensure that previously entered/filed value is present in the 'Admin DN' configuration field.
  10. Ensure that previously entered/filed value is present in the 'Identity Manager Base DN' configuration field.
Topics
• System Security Defaults • NX
2021 Update 119 Summary | Details
Avatar NX - URL Widgets
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Widget Definition (PM)
Scenario 1: Validate creation and functionality of a "URL" type Widget
Specific Setup:
  • [UserA] has access to form "Widget Definition"
  • [UserA] is assigned to a home view [HomeviewA]
  • [UserA] has access to form "View Definition"
  • Login as [UserA]
Steps
  1. Launch form "Widget Definition"
  2. Click 'Select Widget'
  3. Select 'Add New Widget'
  4. Populate the "Title" field, with the name of the widget. For this example "WidgetA"
  5. In the "Widget Type" field select any other selection other than "URL"
  6. Validate the prompt "Launch URL in New Window in myAvatar NX" is disabled
  7. In the "Widget Type" field, select "URL"
  8. Set prompt "Launch URL in New Window in myAvatar NX" to "Yes"
  9. Select "Allow Re-fresh" and any other desired values in the "Widget Attributes" field
  10. Enter a valid URL in the "URL" field. [WebsiteA]
  11. Populate any other desired fields on the form
  12. Click [Submit] to create "WidgetA"
  13. Click "Yes" to return to the form
  14. Click 'Select Widget'
  15. Select "WidgetA"
  16. Validate all fields are populated as expected
  17. Close the form
  18. Open form "View Definition"
  19. Select the [HomeviewA]
  20. Drag and place "WidgetA" onto the view's layout
  21. Submit the form
  22. On the home view in the upper right-hand corner click "Customize" and click to "Reload" the home view
  23. Navigate to [WidgetA] on the home view
  24. Validate the widget contains a link that states, "Resource cannot be viewed in the widget, click here to open in a new tab." [Note: this only displays in "myAvatar NX", in "myAvatar" the results will always display within the widget]
  25. Click on the link
  26. Validate [WebsiteA] set as the "URL" in step 8, is displayed in a new window as expected
  27. Launch form "Widget Definition"
  28. Click 'Select Widget'
  29. Select [WidgetA]
  30. Set prompt "Launch URL in New Window in myAvatar NX" to "No"
  31. Click [Submit]
  32. Repeat step 14
  33. Navigate to [WidgetA] on the home view
  34. Validate [WebsiteA] set as the "URL" in step 8, is displayed within the widget
Topics
• Widget Definition • NX
2021 Update 123 Summary | Details
Acuity Compile - Domain score validation on the report
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Acuity Compile
  • Avatar NX Report Viewer
  • Dictionary Update (PM)
  • Confirm Compile Completed
  • Acuity Rule Definition
  • Admission (Outpatient)
  • Data Trail Configuration
  • Form and Table Documentation (PM)
  • Dictionary Update
  • User Definition
  • System Task Scheduler
  • Acuity Report
Scenario 1: Acuity Compile - Compile the acuity rule defined in the 'Acuity Rule definition' form.
Specific Setup:
  • Dictionary Update:
  • A 'Practitioner Category' must be defined in system for the 'Acuity Rule Definition' entry. Note the dictionary code/value.
  • A new dictionary code/value is created in the RADplus_Client file and 'Domain' data element (i.e. "HI - Homeless Indicator"). Note the dictionary code/value.
  • User definition:
  • Make sure the user has access to SYSTEM.admission_data_other SQL table.
  • Admission:
  • Two clients are admitted in the system as follows:
  • The 'Homeless indicator' on the 'Other Client Data' section is set to desired value for both the clients and is unique for each client. Note the value.
  • Acuity Rule Definition
  • Practitioner Category = Desired value defined in the 'Dictionary Update' section. Note the value.
  • Domain = Desired value defined in the 'Dictionary Update' section. Note the value.
  • Define Acuity Rules
  • Enter/select values in one or more Information Grid fields, ensuring that entered values are saved/present in grid.
  • Domain = Desired value. Note the value.
  • Subdomain = Desired value. Note the value.
  • System Table = Desired value. Note the value.
  • Field = Desired value. Note the value.
  • Conditional = Contains (CO)
  • Field Value = Desired value. Note the value.
  • Record Selection = Desired value. Note the value.
  • Weight = Desired value
Steps
  1. Open 'Acuity Compile' form.
  2. Select 'Compile' in the 'Options' field.
  3. Click [Submit].
  4. Click [Yes] to 'Form Return' message.
  5. Select 'Run Report' in the 'Options' field.
  6. Select the recently compiled 'Acuity File' from the drop down list.
  7. Verify the report launches successfully.
  8. Verify that the clients are included in the report with appropriate data and non-zero score.
Scenario 2: 'Acuity Rule Definition' form submission - The SYSTEM.acuity_rule table is setup in the 'Data Trail Configuration table for auditing
Specific Setup:
  • Data Trail Configuration:
  • The SYSTEM.acuity_rule table is selected for auditing.
  • Acuity Rule Definition:
  • An existing Acuity rule is identified or a new Acuity rule is created.
Steps
  1. Open the 'Acuity Rule Definition' form.
  2. Enter/select Practitioner Category/Domain combination for record entry/edit.
  3. Click [Define Acuity Rules].
  4. Ensure that Acuity Rules information grid is opened for entry/edit.
  5. Ensure existing Acuity Rules entries are present in Information Grid for display/edit.
  6. Select existing row for edit.
  7. Enter/edit/delete additional Acuity Rules information grid entries as desired, ensuring that all entered values are saved/present in grid.
  8. Click [Save].
  9. Ensure user is presented with dialog noting 'Save Successful'.
  10. Click [OK].
  11. Click [Submit].
  12. Verify the form submitted successfully.
Scenario 3: System Task Scheduler - Compile and Post Acuity scores
Specific Setup:
  • Dictionary Update:
  • A 'Practitioner Category' must be defined in system for the 'Acuity Rule Definition' entry. Note the dictionary code/value.
  • A new dictionary code/value is created in the RADplus_Client file and 'Domain' data element (i.e. "HI - Homeless Indicator"). Note the dictionary code/value.
  • User definition:
  • Make sure the user has access to SYSTEM.admission_data_other SQL table.
  • Admission:
  • An existing inpatient client is identified, or a new client admitted in the inpatient program as follows:
  • The 'Homeless indicator' on the 'Other Client Data' section is set to desired value. Note Client id/Name, Admission Unit.
  • Acuity Rule Definition
  • Practitioner Category = Desired value defined in the 'Dictionary Update' section. Note the value.
  • Domain = Desired value defined in the 'Dictionary Update' section. Note the value.
  • Define Acuity Rules
  • Enter/select values in one or more Information Grid fields, ensuring that entered values are saved/present in grid.
  • Domain = Desired value. Note the value.
  • Subdomain = Desired value. Note the value.
  • System Table = SYSTEM.admission_data_other. Note the value.
  • Field = SYSTEM.admission_data_other.holeless_code. Note the value.
  • Conditional = Contains (CO)
  • Field Value = Desired value. Note the value.
  • Record Selection = Desired value. Note the value.
  • Weight = Desired value
Steps
  1. Open the 'System Task Scheduler' form.
  2. Select the 'Compile and post Acuity Score' from the 'Schedule(s)' field.
  3. Set the 'Recurrence Pattern to 'Daily'.
  4. Set 'Start By' to current date.
  5. Set 'Start Time' to current time plus 5 minutes.
  6. Set 'Inactive Task to 'No'.
  7. Click [Schedule Task].
  8. Close the form.
  9. Open the 'Acuity report' form after 6 minutes from the 'Start Time' defined in the 'System Task Scheduler'.
  10. Set the 'Acuity date' to desired date.
  11. Select client's admission unit from the 'Unit' drop down.
  12. Click [Submit].
  13. Review the report.
  14. Verify the client is displayed in the report with correct scores as defined in the 'Acuity Rule Definition' form.
Topics
• RADplus Utilities • NX • Client Acuity
2021 Update 125 Summary | Details
Service Documentation form - field and service record validations
Scenario 1: Modeled 'Service Documentation' forms - Field checking and Service creation validations
Specific Setup:
  • Have a Modeled form enabled for "Service Documentation" [FormA] that includes among the fields on the form, "Service Start Time", "Service End Time" and "Duration".
  • Have a Modeled form enabled for "Service Documentation" [FormB] that includes among the fields on the form, "Service Start Time", "Service End Time" but does not contain the field "Duration".
  • Have registry setting "Activate Program/Location Filter" set to "Y".
  • Have "Program" [ProgramA] defined on the system that is only assigned as specific "Location" in form "Program Maintenance".
  • Have a client [Client] admitted in an episode to [ProgramA] and has an appointment scheduled for that episode in form "Scheduling Calendar". [ApptA].
  • Have a report created to display data in the "SYSTEM.billing_tx_history" table.
Steps
  1. Open [FormA].
  2. Select [ClientA].
  3. Select [EpisodeA].
  4. In the "Data Row For" field, select "New Service".
  5. Set the service "Start Time" to be later than the service "End Time".
  6. Populate the "Duration" field.
  7. Populate valid values in the other required fields on the form.
  8. Set the "Draft/Final" field to "Final".
  9. Validate an error message is displayed indicating that service start time must be prior to the service end time.
  10. Click [OK].
  11. Set the service "Start Time" to be prior the service "End Time".
  12. Set the "Draft/Final" field to "Final".
  13. Validate there is no message related to start time or end times.
  14. Set the "Draft/Final" field back to "Draft".
  15. Set the "Location" field to a location that is not assigned to [ProgramA].
  16. Set the "Draft/Final" field to "Final".
  17. Validate an error message is displayed indicating the location populated in the "Location" field that is valid for program [ProgramA].
  18. Click [OK].
  19. Set the "Location" field to a location that is valid for [ProgramA].
  20. Set the "Draft/Final" field to "Final".
  21. File the [FormA].
  22. Validate the form files successfully.
  23. Open [FormB].
  24. Select [ClientA] and [EpisodeA].
  25. Repeat steps 4 thru 18, omitting 6, as this form does not have the "Duration" field.
  26. Set the "Draft/Final" field to "Final".
  27. File the [FormB].
  28. Validate the form files successfully.
  29. Open [FormA].
  30. Select [ClientA].
  31. Select [EpisodeA].
  32. In the "Data Row For" field, select "Existing Appointment".
  33. Select [ApptA] from the "Note Addresses Which Existing Service/Appointment" field.
  34. Populate all the required fields on the form.
  35. Set the "Draft/Final" field to "Final".
  36. File the form.
  37. Validate the form files successfully.
  38. Run the report to display data in the "SYSTEM.billing_tx_history" table.
  39. Locate the row associated to service filed in step 20.
  40. Validate the 'option_desc' field is populated as [FormA].
  41. Locate the row associated to service filed in step 26.
  42. Validate the 'option_desc' field is populated as [FormB].
  43. Locate the row associated to service filed in step 36.
  44. Validate the 'option_desc' field is populated as [FormA].
Topics
• Modeling
2021 Update 128 Summary | Details
Avatar NX - ScriptLink
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Form Designer (PM)
Scenario 1: Avatar NX - Form designer 'ScriptLink' configuration, functionality and logging
Specific Setup:
  • Have a form [FormA] containing one or more fields, For this example a modeled form is used with dictionary field [FieldA], containing several values
  • Have a "ScriptLink" script created and added to the system. For example, a script that will display a message when a value is selected in a field. For this example, [ValueB] in [FieldA] is used
  • Have the "WSDL" for the script exported and ready for import
Steps
  1. Open "Form Designer" and select [FormA]
  2. In the "Tabs" field, select the tab
  3. Click [Show Tab]
  4. Click "Settings"
  5. Populate the "Import WSDL for ScriptLink" field
  6. Click "Import" and click [OK]
  7. Click the 'Verbose' radio button 12
  8. Uncheck the 'Disable All Scripts for Form' checkbox
  9. Uncheck the 'Disable All Scripts for Error' checkbox
  10. Click [Return To Designer]
  11. Click the [Save] button and then click [Yes]
  12. Click the [OK]
  13. Select the field [FieldA], on the form that will be used to trigger the script
  14. In the 'Properties' pane on the left side, double-click "ScriptLink"
  15. Click [Edit]
  16. Select the script from the "Available Scripts" drop down list
  17. Populate the 'Script Parameter' input box with the parameter needed to trigger the script (if applicable)
  18. Click [Apply]
  19. Click [Save]
  20. Click [Submit]
  21. Open [FormA]
  22. Navigate to [FieldA], set with the "ScriptLink" script
  23. Select the value in the field needed to trigger the script. In this example [ValueB]
  24. Validate the message configured in the script, is displayed as expected. (Note the date and time the message was displayed)
  25. Close the form
  26. Repeat steps 1 thru 4
  27. Click the 'Print Scripts for This Form' button
  28. Validate the report contains script name imported on step 6
  29. Close the report
  30. Back on the "Settings" page, navigate to the "ScriptLink Logs" section
  31. Populate the "From Date & Time" field and the "To Date & Time" field with the date and time noted in step 24
  32. Click and select the row in the drop down list
  33. Validate the "Radplus Script Log" report contains the expected run date/time and script execution logging information, for the event triggered in step 24
Topics
• Forms Designer • NX
2021 Update 132 Summary | Details
Launching Hyperlinks from a modeled form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Form Designer (CWS)
  • Form Definition (CWS)
Scenario 1: Validate launching "Hyperlinks" from a Modeled Form
Specific Setup:
  • Have a modeled form [FormA], that contains a "Label" object configured in "Form Definition" with a valid hypertext link, for example " https://www.google.com/"
  • [UserA] has access to the modeled form
  • [UserA] has access to "Form Designer"
  • [UserA] has access to "Form Definition"
  • Login as [UserA]
Steps
  1. Open [FormA]
  2. Navigate the label containing the hyperlink
  3. Click on the hyperlink
  4. Validate the expected web page is launched successfully
  5. Open "Form Designer"
  6. Select [FormA]
  7. Navigate to the label containing the hyperlink
  8. Move the hyperlink to a new location on the form
  9. Submit the form
  10. Repeat steps 1 thru 3
  11. Validate results are as expected
  12. Open "Form Definition"
  13. Select [FormA]
  14. Navigate to the label containing the hyperlink
  15. Change the hyperlink to a new web page
  16. Submit the form
  17. Repeat steps1 thru 3
  18. Validate results are as expected
  19. Open "Form Designer"
  20. Select [FormA]
  21. Navigate to the label containing the hyperlink
  22. Edit the HTML code for the label. For this example "<html><font face=SansSerif style="font-size: 12pt;", is used to change the font size
  23. Submit the form
  24. Open [FormA]
  25. Navigate the label containing the hyperlink
  26. Validate the font size of the text is as expected
  27. Click on the hyperlink
  28. Validate the expected web page is launched successfully
Topics
• Modeling • Forms Designer • NX
2021 Update 133 Summary | Details
Documents- console widget
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Definition
  • Delete Document
Scenario 1: "Documents" type Console widget - validate functionality
Specific Setup:
  • Have the system configured with a sub system code [SubcodeA]
  • [SubcodeA] is assigned only to [ProgramA]
  • [UserA] only has access to [SubCodeA]
  • [UserA] has access to form "User Definition" and form "Delete Document"
  • [ClientA] is admitted to [ProgramA] in "Episode1"and also to [ProgramB] in "Episode2"
  • [FormA] is enabled for document routing with document type [DocA], assigned in form "Document Routing Setup"
  • A document "DocumentA", has been created for [ClientA] in "Episode1", using [FormA]
  • Another document "DocumentB", has been created for [ClientA] in "Episode2", using [FormA]
  • Have a "Documents" console widget created using form, "Console Widget Definition" with document type [DocA] included to display in the widget
  • Have the "Documents" widget placed on the home view for [UserA]
  • Have the "My To Do's widget placed on the home view for [UserA]
  • [UserA] has logged into [SubcodeA]
Steps
  1. Select [ClientA]
  2. In the 'Episode Selection' at the top of the home view, select "All" episodes
  3. Validate "DocumentA" filed in [Episode1] is displayed in the "Documents" widget
  4. Validate "DocumentB" filed in [Episode2] is 'not' displayed in the "Documents" widget, as sub system code does not have access to the program used to generate
  5. Open form "User Definition" and select [UserA] for edit
  6. In the "Document Management" section, click on field "Specify Forms", deselect document type [DocA]
  7. Submit the form
  8. Re-fresh the "Documents" widget
  9. Validate "DocumentA" filed in [Episode1] is no longer displayed in the "Documents" widget as access to document type [DocA] used in "DocumentA" has been removed
  10. Validate "DocumentB" filed in [Episode2] is 'not' displayed in the "Documents" widget, as sub system code does not have access to the program used to generate
  11. Repeat step 5 thru 7, this time returning access to [DocA] for [UserA]
  12. Re-fresh the "Documents" widget
  13. Validate "DocumentA" filed in [Episode1] is displayed in the "Documents" widget
  14. Validate "DocumentB" filed in [Episode2] is 'not' displayed in the "Documents" widget, as sub system code does not have access to the program used to generate
  15. Open form "Delete Document"
  16. Select "Client" in the "Entity Type" field
  17. Select "Individual" in the "Include" field
  18. In the "Entity" field, select the [ClientA]
  19. Select [EpisodeA] in the "Episode" field where the document was filed
  20. Click [Form Search]
  21. Select the [FormA] in the "Select a Form" screen
  22. Click "OK"
  23. Click the "Select Form" drop down list
  24. Select the row pertaining to the document in "Episode1" for [UserA]
  25. Click [Delete]
  26. Click [Yes], confirming the deletion
  27. In the 'Episode Selection' at the top of the home view, select "All" episodes
  28. Click the "Refresh" button on the "Documents Widget"
  29. Validate "DocumentA" filed in [Episode1], is no longer present in the list
Topics
• Document Management • NX
2021 Update 134 Summary | Details
Export Reports Form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Export Crystal Report File (PM)
  • Export Crystal Report File (MSO)
  • Export Crystal Report File (CFMS)
Scenario 1: Validate form "Export Crystal Report File"
Steps
  1. Open form "Export Crystal Report" form in application "PM"
  2. In the "Report Type" field, select the "Command Button Report"
  3. Click the "Select Report" field drop down list
  4. Select any desired report from the list [ReportA] (Note: A system may not have any reports for export)
  5. Click [Export Report]
  6. In the "Save" dialog, click the "Save In" field and navigate to a desired folder location [FolderA],
  7. Click [Save]
  8. Open "File Explorer" and navigate to [FolderA]
  9. In the "File Name" column, double click on [ReportA] to open the report
  10. Validate the report opens successfully
  11. Close the report
  12. In the "Report Type" field, select "Disclosure Management Report"
  13. Repeat steps 2 and 3
  14. Validate results are as expected
  15. In the "Report Type" field, select "Menu Report"
  16. Repeat steps 2 and 3
  17. Validate results are as expected
  18. In the "Report Type" field, select "Document Routing Report"
  19. Repeat steps 2 and 3
  20. Validate results are as expected
  21. In the "Report Type" field, select "Report Definition Report"
  22. Repeat steps 2 and 3
  23. Validate results are as expected
  24. In the "Report Type" field, select "RADplus Report"
  25. Repeat steps 2 and 3
  26. Validate results are as expected
  27. Close the form
  28. Open form "Export Crystal Report" form in application "CWS" (If applicable)
  29. Repeat steps 2 thru 9
  30. Validate results are as expected
  31. Open form "Export Crystal Report" form in application "MSO" (If applicable)
  32. Repeat steps 2 thru 9
  33. Validate results are as expected
  34. Open form "Export Crystal Report" form in application "CFMS" (If applicable)
  35. Repeat steps 2 thru 9
  36. Validate results are as expected
Topics
• Query/Reporting • NX
2021 Update 139 Summary | Details
State Form Tools
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • State Form File Generation
Scenario 1: State Form File Generation - Validations
Specific Setup:
  • Have a definition created [DefintionA] in form "State Forms Definition" with a "File Type" set to "XML".
  • [DefinitionA] is set with "Output as Multiple Files" set to "Yes" and field "Multiple File Format" set to "One file Per Record".
  • [DefinitionA] contains two records [Rec1] and [Rec2]. (For this example, [Rec1] is defined to output the "PatID" of clients on the system and [Rec2] is defined to output the "Client Name" of clients on the system).
  • Have both [Rec1] and [Rec2] defined with same value in the "XML Tag" field of their record definition in form "State Form Definition".
Steps
  1. Open form "State Form File Generation".
  2. Select definition [DefinitionA] in field "State Form".
  3. Populate the "File Description" field.
  4. In the "File Generation Options" field, select "Compile".
  5. Click [Process].
  6. Validate the process completes successfully.
  7. In the "File Generation Options" field, select "Dump File".
  8. Click [Process].
  9. Validate the "RADplus_SF_File_Dump.rpt" includes two records [Rec1] and [Rec2].
  10. Validate [Rec1] contains the expected data. In this example, the "PatID" number of clients in the system.
  11. Validate [Rec1] contains the expected data. In this example, the "Client name" of clients in the system.
Topics
• NX • State Form Tools
2021 Update 140 Summary | Details
State Form Tools - Import Data
Scenario 1: State Form Tools - Data Import functionality
Specific Setup:
  • Have two modeled forms, for this example one is called 'Parent Form' and the other 'Child Form' each form.
  • Have a "State Form Definition" [Defintion1], set up by Netsmart, that is configured to execute a data import from the "Child" form to the "Parent form" when the "Child" form is submitted. (For this test, [Definition1] uses the "Program" field (which exists on both forms) as a link to update the data filed in "Date" and "Time" fields on the "Parent" form)
  • Have Netsmart set up a "Programmer Override" on the "Child" form that will compile [Definition1] which then executes the data import
Steps
  1. Select a client [ClientA]
  2. Open the 'Parent Form' form
  3. Click on the "Program" field and select a program [ProgramA]
  4. Populate the "Date" and "Time" fields on the form. (Note the date and time values)
  5. Submit the form
  6. Open the 'Child Form' form for [ClientA]
  7. In the "Program" field, select the same program filed in the "Parent" form, [ProgramA]
  8. Populate other desired fields on the form
  9. Submit the form. (Note the date and time of the submission)
  10. Open the 'Parent Form' form
  11. Select the row filed in step 5
  12. Validate the "Date" and "Time" fields are now populated with the date and time noted in step 9
Topics
• NX • State Form Tools
2021 Update 147 Summary | Details
Form Definition
Scenario 1: Modeling- validate event logic 'Focus' functionality
Specific Setup:
  • Have a modeled form[FormA] with two tables a "Primary" table and a "Multiple Iteration" table
  • [FormA] has three sections:
  • [SectionA] contains a single select dictionary field "SingleA" and scrolling text field "ScrA" from the "Primary" table
  • [SectionB] contains a single select dictionary field "SingleB" and scrolling text field "ScrB" from the "Primary" table
  • [SectionM] contains a single select dictionary field "SingleM" and scrolling text field "ScrM" from the "Multiple Iteration" table
  • In [SectionA]
  • Have a "Set Focus on Specific Object on Event" type event set on field "SingleA", to set cursor focus on field "ScrA" when "ValueA" is selected in field "SingleA"
  • Have a "Set Focus on Specific Object on Event" type event set on field "SingleA", to set cursor focus on field "ScrB" when "ValueB" is selected in field "SingleA"
  • In [SectionB]
  • Have a "Set Focus on Specific Object on Event" type event set on field "SingleB", to set cursor focus on field "ScrB" when "ValueA" is selected in field "SingleB"
  • Have a "Set Focus on Specific Object on Event" type event set on field "SingleB", to set cursor focus on field "ScrA" when "ValueB" is selected in field "SingleB"
  • In [SectionM]
  • Have a "Set Focus on Specific Object on Event" type event set on field "SingleM", to set cursor focus on field "ScrM" when "ValueA" is selected in field "SingleM". [Note: For "Multiple Iteration" sections, focus events can only be set to focus on fields on the multiple iteration section itself, not on fields that exist in other sections of the form]
  • [Please Note: "Focus" event functionality in Modeling is not yet supported in "Avatar NX"]
Steps
  1. Access [FormA].
  2. Select [SectionA]
  3. In field "SingleA", select "ValueA"
  4. Validate cursor focus is set on field "ScrA"
  5. In field "SingleA", select "ValueB"
  6. Validate cursor focus jumps to "SectionB" and is set on field "ScrB", as expected
  7. Select [SectionB]
  8. In field "SingleB", select "ValueB"
  9. Validate cursor focus jumps to "SectionA" and is set on field "ScrA", as expected
  10. In field "SingleB", select "ValueA"
  11. Validate cursor focus is set on field "ScrB"
  12. Select [SectionM]
  13. In field "SingleM", select "ValueA"
  14. Validate cursor focus is set on field "ScrM".
Modeled Forms - with 'Table Alias' configured
Scenario 1: Modeled Forms - "Table Alias" field and data validations
Specific Setup:
  • Have a client [ClientA], with an existing inpatient episode [EpisodeA]
  • The registry setting 'Require Present on Admission Indicator on Inpatient Episodes' is set to "Yes".
  • Have a modeled form [FormA], that includes a "Diagnosis-IMO Mapped Search" field [FieldA], that is mapped to the "Diagnosis Search" field on the "Diagnosis" form set by using the "Table Alias" and "Column Mapping" functionality in "Table Definition
  • FormA also includes these field mapped from the "Diagnosis" using "Table Alias" functionality
  • A dictionary field [FieldB] mapped to the "Type Of Diagnosis" field.
  • A dictionary field [FieldC] mapped to the "Present on Admission Indicator" field
  • A dictionary field [FieldD] mapped to the "Status" field
  • A dictionary field [FieldE] mapped to the "Diagnosing Practitioner" field
  • Have a crystal report [ReportB] to display the data filed in the "SYSTEM.client_diagnosis_record" table
  • Have access to the "Diagnosis" form
Steps
  1. Open [FormA]
  2. Select [ClientA]
  3. Select [EposideA]
  4. Select a value [FieldA]
  5. Select a value [FieldB]
  6. Don't select a value in [FieldC]
  7. Select a value [FieldD]
  8. Select a value [FieldE]
  9. Submit [FormA]
  10. Validate a submission error stating "Present On Admission Indicator" is missing" is displayed
  11. Click [OK]
  12. Select a value [FieldC]
  13. Submit the form
  14. Validate the form files successfully
  15. Open the "Diagnosis" form
  16. Select [ClientA]
  17. Select [EposideA]
  18. Select the diagnosis row in the "Diagnosis" grid
  19. Validate the "Type of Diagnosis" field at the top of the form contains the value filed in [FieldB]
  20. Below the "Diagnosis" grid, validate the "Diagnosis Search" field contains the value filed in [FieldA]
  21. Validate the "Status" field contains the value filed in [FieldD]
  22. Validate the "Present on Admission Indicator" field contains the value filed in [FieldC]
  23. Validate the "Diagnosing Practitioner" field contains the value filed in [FieldE]
  24. Generate the [ReportB] to display the data filed in the "SYSTEM.client_diagnosis_record" table
  25. Locate the record for [ClientA]. [EpisodeA]
  26. Validate data displayed contains the field values selected and submitted in steps 4 thru 12
Console Widgets
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • HomeView - Console Widget Viewer
Scenario 1: Validate "Console" widget column data
Specific Setup:
  • Have a "Console" widget [WidgetA] created in form "Console Widget Configuration" for any form [FormA], For example the "Inpatient Progress Notes" form.
  • Include the field "Practitioner (7000)" and any other desired fields in the widget
  • Have the [WidgetA] placed on a home view for [UserA]
  • Have the "Console Widget Viewer" widget on a home view for [UserA]
  • Log in as [UserA]
Steps
  1. Open [FormA]
  2. Select [EpisodeA]
  3. Select [ClientA]
  4. Click to add a new row
  5. Populate all required fields
  6. In the "Practitioner" field, populate the field with a valid practitioner.
  7. Populate any other desired fields
  8. Submit the form
  9. Validate the form files successfully
  10. Select [EpisodeA] in the "Episodes" drop down list on the home view
  11. Click the [WidgetA] refresh button
  12. Validate the "Practitioner" column contains the practitioner name along with the practitioner's staff ID number.
  13. Validate all other columns chosen for the widget in the set up are populated, as expected
  14. Click the [View] button
  15. Validate the "Console Widget Viewer" widget, is populated with all the expected field values
Topics
• Modeling • NX • Diagnosis
2021 Update 149 Summary | Details
To Do's Widget - reassigning routed documents
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Approver Override
Scenario 1: My To Do's Widget - Reassign a To Do routed for Approval
Specific Setup:
  • Have a form enabled for document routing [FormA]
  • [FormA] has been submitted today for [ClientA] and routed to [UserA], who is a staff member
  • Have a second user who is also a staff member [UserB]
  • [UserA] and [UserB] have the "My To do's" widget on their home view"
  • Log in as [UserA]
Steps
  1. Navigate to the "My To Do's" widget and click on the "New" tab
  2. In the "Client" column,
  3. Locate the To Do routed in form [FormA], for [ClientA]
  4. Validate the "Sent" column, validate the date
  5. Right-click on the "Approve Document" link and then click Reassign"
  6. In the "Continue" dialog, click [OK] to proceed to the "Approver Override" form
  7. In the "Approver Override" form
  8. Validate the "Entity" field contains [ClientA]
  9. Validate the "From Date" and the "To Date" contains today's date
  10. Click the drop down list in the field "List of Document" and select the row
  11. Validate the row contains the "Option" field populated with "FormA" and the "Date Created" field populated with today's date, as expected
  12. Click [Update Approvers]
  13. In the "Route Document To" dialog, deselect [UserA] as an approver in the approver list
  14. In the "Add Approver" field search for [UserB] and then click [Add] to add the user to approver list
  15. Click [Submit]
  16. Close the form
  17. Validate the To Do reassigned, is removed from the "My To do's" widget for [UserA]
  18. Log out as [UserA] and then log in as [UserB]
  19. Navigate to the "My To Do's" widget and click on the "New" tab
  20. Click the "Refresh" button in the widget
  21. Validate the To Do reassigned to [UserB] for approval in the step 2, is present in the list
  22. Click [Approve Document]
  23. In the "Approve Document" form, click [Sign] to approve the document
  24. Validate the To Do is removed from the "My To Do's" widget for [UserB]
Document Management Definition - form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Document Management Definition
Scenario 1: Validate form "Document Management Definition"
Steps
  1. Open "Document Management Definition" form.
  2. Click [Select Form].
  3. Click [Add New].
  4. Populate the "Form Name" field.
  5. Select the desired form type in the "Form Type" field
  6. Select the desired entity in the "Entity" field
  7. Populate any other desired fields in the "Form" section
  8. Click the [Categories] section.
  9. Click [Select Categories].
  10. Select the desired category from the selection list
  11. Click [OK].
  12. Click the [Display] section.
  13. Select the desired selections form the "Forms to Display" box.
  14. Click the [Reports] section.
  15. Click any to launch any desired report, for example the "Display Form Report"
  16. Validate the "Document Management Form Report" is displayed.
  17. Close the report.
  18. Click back to the [Form] section
  19. Click [File].
  20. Validate the form files successfully
  21. Click [Select Form].
  22. Select the form just submitted in 5
  23. Validate all fields populated in steps 1 thru 5, are populated as expected
  24. Click back to the [Form] section
  25. Click [Delete].
  26. Click [Yes] to accept the deletion.
  27. Click [Select Form].
  28. Validate the form that was deleted in step 7, is no longer present in the list
  29. Click [Select Form].
  30. Select the form "Inbox Attachments"
  31. Click [Delete]
  32. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed."
  33. Click [OK]
  34. Click [Select Form].
  35. Select the form "Results Document"
  36. Click [Delete]
  37. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed."
  38. Click [OK]
  39. Close the form
Topics
• NX • My To Do's
2021 Update 150 Summary | Details
'SYSTEM.RADplus_dict_user_def_stateform' table
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Form and Table Documentation (PM)
Scenario 1: Validate table 'SYSTEM.RADplus_dict_user_def_stateform'
Specific Setup:
  • UserA has access to the 'SYSTEM.RADplus_dict_user_def_stateform' table
  • UserA has access to the "Form and Table Documentation" form
  • Have a Crystal Report or other SQL query program to query the 'SYSTEM.RADplus_dict_user_def_stateform' table
  • Log in as [UserA]
Steps
  1. Open form "Form and Table Documentation"
  2. Select "Table" in the "Type of Documentation" field
  3. In the "Table(s) to be Documented" table list, select the " RADplus_dict_user_def_stateform" table
  4. Click [Process]
  5. Validate the "Facility" field contains the following:
  6. "Type" field value is "Integer"
  7. "Max Length" field value is "50"
  8. Validate the "dictionary_code" field contains the following:
  9. "Type" field value is "String"
  10. "Max Length" field value is "40"
  11. Validate the "dictionary_value" field contains the following:
  12. "Type" field value is "String"
  13. "Max Length" field value is "50"
  14. Validate the "field_description" field contains the following:
  15. "Type" field value is "String"
  16. "Max Length" field value is "40"
  17. Validate the "field_number" field contains the following:
  18. "Type" field value is "String"
  19. "Max Length" field value is "40"
  20. Validate the "inactive_codes" field contains the following:
  21. "Type" field value is "String"
  22. "Max Length" field value is "5"
  23. Using a Crystal Report or other SQL program, execute a query to display the fields in the "RADplus_dict_user_def_stateform" table. For example query: "SELECT * FROM RADplus_dict_user_def_stateform"
  24. Validate the "Column", "Type" and "Max Length" field values validated in steps 5 thru 10, are present in the results as expected
Add/Remove State Form Processing Flags' form
Scenario 1: Add/Remove State Form Processing Flags - form field validations
Specific Setup:
  • Have two state form definition files created
  • FileA has two records rec1 and rec2, each record has a "different" primary table
  • FileB has two records rec1 and rec2, each record has a "same" primary table
  • Each file has been compiled in form "State Form File Definition" with prompt "Generate Flag on Compile" set to "Y"
Steps
  1. Open the 'Add/Remove State Form Processing Flags' form
  2. In the "Action" field, select "Add Flags"
  3. In the "State Form" field, select the 'FileA' definition
  4. Click the "Record" field
  5. Validate, "ALL" is not an available for selection, since all records in the definition do not have the same primary table
  6. In the "State Form" field, select the 'FileB' definition
  7. Click the "Record" field
  8. Validate, "ALL" is listed, as this definition does contain all records with the same primary table
  9. Select the value
  10. In the "Properties to Display" list box, select the fields in the file to display for selection
  11. Click [Select Table Rows]
  12. In the "Row Data" selection list box, select any desired row [RowA]
  13. Click [OK]
  14. Click [Submit] to file the form
  15. Validate the form files successfully
  16. Open the 'Add/Remove State Form Processing Flags' form
  17. In the "Action" field, select "Remove Flags"
  18. In the "State Form" field, select the 'FileA' definition
  19. Click the "Record" field
  20. Validate, "ALL" is not an available for selection, as expected
  21. In the "State Form" field, select the definition Select the 'FileB' definition
  22. Click the "Record" field
  23. Validate, "ALL" is listed, as expected
  24. Select the value
  25. In the "Properties to Display" list box, select the same fields selected in step 5
  26. Click [Select Table Rows]
  27. In the "Row Data" selection list box, deselect the row selected in step 6, [RowA]
  28. Click [OK]
  29. Click [Submit] to file the form
  30. Validate the form files successfully
Topics
• NX • State Form Tools
2021 Update 151 Summary | Details
Document Routing - Tiff Image display
Scenario 1: "Document Routing" - Document display validations
Specific Setup:
  • Have a system that has the (Internal only) Registry Setting 'Enable Fixed-Width Font' set to the default setting of "Y". Please contact your Netsmart representative to enable this setting.
  • A form must be defined that has document routing enabled [FormA]
  • [UserA] is a staff member with the "My To Do's" widget on their home view
  • Log in as [UserA]
Steps
  1. Access [FormA]
  2. Populate all desired fields on the form, including the "Time" field
  3. Select "Final" in the 'Draft/Final' field.
  4. Click "OK"
  5. Click [Submit]
  6. In the "Confirm Document" screen:
  7. Verify document is displayed in the expected format, including proper spacing between characters and lines on the form
  8. Verify characters are displayed in the proper 'Font', in this test the "Lucida Sans Typewriter" font is validated
  9. Validate field heading characters are bold, when applicable
  10. Click [Accept and Route].
  11. Enter the user's password in the 'Password' field.
  12. Click [OK].
  13. In the "Route Document To" screen, select and add an approver
  14. Click [Submit].
  15. Click "No" to not return to the form
  16. Navigate to the 'My To Do's' widget.
  17. Locate the document in the "My To Do's" widget for [FormA]
  18. Click [Approve Document]
  19. In the "Confirm Document" screen:
  20. Verify document is displayed in the expected format, including proper spacing between characters and lines on the form
  21. Verify all text characters are displayed in the proper 'Font'
  22. Validate field heading characters are bold, when applicable
  23. Click [Accept].
  24. Enter the user's password in the 'Password' field.
  25. Click [OK].
  26. Validate the "To Do" accepted successfully and is removed from the 'My To Do's' widget.
Add User Signature - Tiff display
Scenario 1: "Append Documents" - Document display validations
Specific Setup:
  • Have a system that has the (Internal only) Registry Setting 'Enable Fixed-Width Font' set to the default setting of "Y". Please contact your Netsmart representative to enable this setting.
  • Have a document [DocumentA] for [ClentA] routed to [UserA]
  • Login as [UserA]
Steps
  1. Open the "Append Documents" form
  2. Select the form type used for one of the documents from the "Form Type" drop down list.
  3. Select [ClientA] in the "Entity" field
  4. Populate the "From Date" and "End Date" fields
  5. Click the drop down list in the "List of Documents" field
  6. Select [DocumentA] to append to
  7. Enter free text in the "New Comments to Be Appended in the Original Document" field
  8. Click [Submit]
  9. In the "Confirm Document" screen:
  10. Verify document is displayed in the expected format, including proper spacing between characters and lines on the form
  11. Verify all text characters are displayed in the proper 'Font', in this test the "Lucida Sans Typewriter" font is validated
  12. Validate field heading characters are in bold, when applicable
  13. Click [Accept]
  14. Enter the user's password
  15. Click [Verify]
  16. Validate the form files successfully
Append Document - Tiff Image display
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Add Non-User Signature (PM)
Scenario 1: Add Non User Signature - Document display validations
Specific Setup:
  • Have a system with registry setting "Enable Military Time" set to "Y"
  • Have documents created and routed using any form. For example a modeled form enabled for document routing
  • Have a user who is not a staff member with access to form "Add Non-User Signature"
Steps
  1. Open the "Add Non User Signature" form
  2. Select the form type used for one of the documents from the "Form Type" drop down list.
  3. Select [ClientA] in the "Entity" field
  4. Populate the "From Date" and "End Date" fields
  5. Click the drop down list in the "List of Documents" field
  6. Select [DocumentA]
  7. Enter free text in the "New Comments to Be Appended in the Original Document" field
  8. Populate any other required fields
  9. Click [Submit]
  10. In the "Confirm Document" screen:
  11. Verify document is displayed in the expected format, including proper spacing between characters and lines on the form
  12. Verify all text characters are displayed in the proper 'Font', in this test the "Lucida Sans Typewriter" font is validated
  13. Validate field heading characters are in bold, when applicable
  14. Click [Accept]
  15. Enter the user's password
  16. Click [Verify]
  17. Validate the form files successfully
Topics
• Document Routing • NX
2021 Update 155 Summary | Details
'Change User Role ID' - support for other modules
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Role Definition
  • User Permissions for Multiple Iteration Tables
  • Change User Role ID
  • User Definition
  • User Merge
Scenario 1: 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 2: 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 3: 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.
Topics
• Change User Role Id • User Permissions for Multiple Iteration Tables • Change User ID • User Merge
2021 Update 156 Summary | Details
State Form Tools
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • State Form Definition
  • State Form File Generation
Scenario 1: State Form Definition - Field and data validation's
Specific Setup:
  • Have any existing state form definition defined in form "State Form Definition" [DefinitionA] that contains a main record [Main] and a sub record [Sub]
  • The main record contains data fields from the "SYSTEM.patient_current_demographics" table that includes the "patient_name" field
  • Have a client on the system with a name that includes an "underscore". [ClientA]
Steps
  1. Open the 'State Form Definition' form
  2. Select "Existing" in the 'New or Existing' field
  3. Select the [DefinitionA] from the 'Select State Form' field drop down list
  4. Click the [Record Definition] section
  5. Select "Update" in the "Add or Update Record" field
  6. Select the [Main] record in the "Select Record" field
  7. Click [Define Record Data Elements]
  8. Select the row that contains the clients name field
  9. Double-click in the "Format" column input field
  10. In the search results grid, scroll down the "Code" column and select the code "TXT9" (Remove Underscores)
  11. Click [Save] to save the changes
  12. Select the [Sub] record in the "Select Record" field
  13. Click [Define Record Data Elements]
  14. Double-click in the "Force Error Condition" field
  15. Populate the field, for this example, "p2.PATID=1"
  16. Double-click in the "Default Error Message" field
  17. Populate the field with a value, for this example "Test"
  18. Click [Save] to save the changes
  19. Click [Define Record Data Elements] to return to the grid
  20. Validate the "Force Error Condition" field contains the expected value
  21. Double-click in the "Force Error Condition" field, remove the current value and click [OK]
  22. Validate the field is empty
  23. Validate the "Default Error Message" field contains the expected value
  24. Double-click in the "Default Error Message" field, remove the current value and click [OK]
  25. Validate the field is empty
  26. Click [Save] to save the changes
  27. Open form "State Form File Generation" form
  28. In the field "State Form", select [DefinitionA]
  29. In the "File Generation Options" field, select "Compile"
  30. Click [Process]
  31. In the "File Generation Options" field, select "Create File on Server"
  32. Click [Process]
  33. In the "Save In" dialog, select a folder location to save the file [LocationA]
  34. Set the "File Name" field to desired file name [DefinitionFileA]
  35. Click [Save]
  36. Open "Windows Explorer", and navigate to the location of the file [LocationA]
  37. Right-click on [DefinitionFileA] to open the file
  38. Search for [ClientA]
  39. Validate the name displayed for [ClientA] does not contain any underscores, as expected
Topics
• State Form Tools