Skip to main content

RADplus 2022 Monthly Release 2022.01.00 Acceptance Tests

  1. Last updated
  2. Save as PDF
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
  • Dynamic Form - Admission - Client
  • Form Definition (CWS)
  • CWS General Form Test
  • Dynamic Form - Select A Form
  • Dynamic Form - Form Definition - Confirm
  • DOCMANAGEMENT3000
  • Dynamic Form - Delete Document
  • 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
  • Delete Document
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 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
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Update Client Data
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 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:
  • Dynamic Form - Admission - Client
  • GA_ASO_Entity_Form
  • Dynamic Form - Disclosure
  • Dynamic Form - Select A Form
  • 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)
  • CWS General Form Test
  • DOCMANAGEMENT3000
  • Dynamic Form - Delete Document
  • 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
  • Delete Document
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
  • Dynamic Form - Admission - Client
  • 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
  • Update Client Data
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