Skip to main content

RADplus 2024 Monthly Release 2024.01.00 Acceptance Tests

  1. Last updated
  2. Save as PDF
Update 3 Summary | Details
Internal Utilities
Scenario 1: 'Support Utilities' Form (Internal only) - Validate Export 'Envelope' and Export 'Report' Attributes functionality
Steps
  1. Internal Testing Only
Topics
• Modeling
Update 7 Summary | Details
Client Alerts - SQL Table
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • SQL Query/Reporting Tool
  • Client Alerts
Scenario 1: Validate querying data in the "SYSTEM.RADplus_client_alerts table"
Specific Setup:
  • Have two "Alert Types" configured in form "Alert Types"
  • [TypeA] is configured with prompt "Community Alert" set to "Yes"
  • [TypeB] is configured with prompt "Community Alert" set to "No"
  • Have access to form "Client Alerts" to add alerts for a desired client [TestClient]
  • Have a report or query to display field data in the "SYSTEM.RADplus_client_alerts" table
Steps
  1. At the Home View, select [TestClient]
  2. Open the "Client Alerts" form.
  3. From the "Type of Alert" select alert type [TypeA]
  4. From the Episode field select a desired episode [EpisodeA]
  5. Populate the "Start Date" and "End Date" fields
  6. Submit the form
  7. Validate the form files successfully
  8. Re-open the "Client Alerts" form.
  9. From the "Type of Alert" select alert type [TypeB]
  10. From the Episode field select a desired episode [EpisodeA]
  11. Populate the "Start Date" and "End Date" fields
  12. Submit the form
  13. Validate the form files successfully
  14. Open the report or query defined in the set up for the "SYSTEM.RADplus_client_alerts" table
  15. Click to preview data
  16. Validate there are two rows of data for [TestClient], one for each alert submitted
  17. Validate the data displayed in each row, is consistent with the data populated for each alert in steps 2 and 3
Topics
• Client Alerts • SQL Data Access • Community Alert
Update 9 Summary | Details
Bells Notes Integration - Progress Note document images
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Clinical Document Viewer
Scenario 1: Bells Notes Integration - Validate self approval of progress notes from Bells
Specific Setup:
  • myAvatar must be configured to integrate with Bells Notes. Please note: this must be done by a Netsmart Associate.
  • The 'Progress Notes (Group and Individual)' form must have 'Document Routing' enabled.
  • Must have a note type in Bells for the 'Progress Notes (Group and Individual)' form (Note Type A).
  • A user is defined with the following (User A):
  • Access to Bells Notes
  • Associated practitioner
  • Does not require a supervisor's approval for document routing
  • Access to the 'My To Do's' and 'Progress Notes' widgets on the HomeView.
  • A client is enrolled in an existing episode (Client A).
Steps
  1. Log into Bells Notes with existing login credentials for "User A".
  2. Search for "Client A".
  3. Click [Start Note] and verify the existence of the 'Session Information' window.
  4. Fill out all required fields and select "Note Type A".
  5. Verify the existence of "Client A" in the client header when note is started.
  6. Fill out all required fields.
  7. Click [Sign Note].
  8. Validate the Sign Note' dialog is displayed.
  9. Enter the pin for "User A" in the 'Pin' field and click [Sign].
  10. Validate a message is displayed stating: Note Signed Successfully.
  11. Log into myAvatar as "User A".
  12. Navigate to the "My To Do's" widget.
  13. Validate a 'To-Do' is not displayed for the note sent via Bells Notes since "User A" does not require an approver.
  14. Select "Client A" and navigate to the 'Progress Notes' widget.
  15. Validate the progress note filed from Bells Notes is displayed.
  16. Access the 'Clinical Document Viewer' form.
  17. Select "Client" in the 'Select Type' field.
  18. Select "Individual" in the 'Select All or Individual Client' field.
  19. Select "Client A" in the 'Select Client' field.
  20. Select "All" in the 'Episode' field.
  21. Click [Process].
  22. Validate a document is displayed for the progress note filed from Bells Notes.
  23. Select the document and click [View].
  24. Validate the PDF generated from Bells Notes is displayed with the note details.
  25. Click [Close All Documents], [Search], and [Close].
'Envelope Import' form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Envelope Export (PM)
  • Envelope Export (CWS)
Scenario 1: Envelope Import - Validate importing 'Document Routing' enabled forms
Specific Setup:
  • Have an envelope (Envelope A) with a modeled form (Form A) that is enabled for document routing with the following prompts set in 'Document Routing Setup':
  • 'Skip Password Entry' set to "Yes"
  • 'Acknowledgement Allowed' set to "Yes"
  • Have an envelope (Envelope B) with a modeled form (Form B) that is enabled for document routing with the following prompts set in the 'Document Routing Setup' form:
  • 'Skip Password Entry' set to "No"
  • 'Acknowledgement Allowed' set to "No"
Steps
  1. Access the 'Envelope Export' form.
  2. Select "Envelope A".
  3. Select the desired value in the 'Include Form Designer Changes' field.
  4. Click [Begin Export].
  5. Validate the file is exported to the desired location.
  6. Close the form.
  7. Access the 'Envelope Import form.
  8. Click [Select Envelope Import File].
  9. Select the export file for "Envelope A".
  10. Select "Overwrite Existing".
  11. Select the desired value in the 'Load Un-Locked Dictionary Entries' field.
  12. Select the desired value in the 'Load Locked Dictionary Entries' field.
  13. Select the desired value in the 'Include Form Designer Changes' field.
  14. Click [Begin Import Scan].
  15. Validate the 'Import Scan Results' field does not contain errors.
  16. Click [Begin Import].
  17. Validate a message is displayed stating: Import Complete.
  18. Click [OK] and close the form.
  19. Access the 'Document Routing Setup' form.
  20. Click [Select Form].
  21. Select "Form A" and click [OK].
  22. Validate the 'Skip Password Entry' field is set to "Yes".
  23. Validate the 'Acknowledgement Allowed' field is set to "Yes".
  24. Close the form.
  25. Access the 'Envelope Export' form.
  26. Select "Envelope B".
  27. Select the desired value in the 'Include Form Designer Changes' field.
  28. Click [Begin Export].
  29. Validate the file is exported to the desired location.
  30. Close the form.
  31. Access the 'Envelope Import form.
  32. Click [Select Envelope Import File].
  33. Select the export file for "Envelope B".
  34. Select "Overwrite Existing".
  35. Select the desired value in the 'Load Un-Locked Dictionary Entries' field.
  36. Select the desired value in the 'Load Locked Dictionary Entries' field.
  37. Select the desired value in the 'Include Form Designer Changes' field.
  38. Click [Begin Import Scan].
  39. Validate the 'Import Scan Results' field does not contain errors.
  40. Click [Begin Import].
  41. Validate a message is displayed stating: Import Complete.
  42. Click [OK] and close the form.
  43. Access the 'Document Routing Setup' form.
  44. Click [Select Form].
  45. Select "Form B" and click [OK].
  46. Validate the 'Skip Password Entry' field is set to "No".
  47. Validate the 'Acknowledgement Allowed' field is set to "No".
  48. Close the form.
Rule Based Routing - 'DocR.rule_based_routing' SQL table
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Rule Based Routing
  • Routing Admin Dashboard
Scenario 1: Rule-Based Routing - Validate the 'DocR.rule_based_routing' SQL table
Specific Setup:
  • Rule-Based Routing must be configured.
  • The 'Ambulatory Progress Notes' form must be selected in the 'Routing Configuration Definition' form.
  • A client is enrolled in an existing episode.
  • Two users must be defined (User A & User B).
  • The users must have the 'My To Do's' and 'Rule Based Routing' widgets accessible.
  • Must be logged in as "User A" initially.
Steps
  1. Select "Client A" and access the 'Ambulatory Progress Notes' form.
  2. Select "Independent Note" in the 'Progress Note For' field.
  3. Select the desired value in the 'Note Type' field.
  4. Enter the desired value in the 'Notes Field'.
  5. Select "Final" in the 'Draft/Final' field.
  6. Click [Submit].
  7. Validate a "Confirm Document" dialog is displayed.
  8. Click [Accept and Route].
  9. Enter the password associated to "User A" and click [OK].
  10. Select "User B" as an approver and click [Submit].
  11. Log out.
  12. Log in as "User B".
  13. Navigate to the 'My To Do's' widget.
  14. Validate a To Do is displayed for "Client A".
  15. Click [Review].
  16. Validate the document is displayed.
  17. Accept and sign off on the document.
  18. Validate the To Do is no longer displayed.
  19. Navigate to the 'Rule Based Routing' widget.
  20. Select the corresponding value in the 'Queue' field.
  21. Validate an item is displayed for "Client A" as expected.
  22. Access Crystal Reports or other SQL Reporting Tool.
  23. Create a report using the 'DocR.rule_based_routing' SQL table.
  24. Validate a row is displayed with the data filed for "Client A" as expected.
  25. Close the report.
Topics
• Progress Notes • CareFabric • Bells Notes • Document Routing • Envelope Import • Envelope Export • Query/Reporting • Rule Based Routing
Update 10 Summary | Details
Rule Based Routing widget - performance
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Rule Based Routing widget
  • Rule Based Routing
  • Routing Worklist Item
Scenario 1: 'Rule Based Routing' widget - Submission and form data validations
Specific Setup:
  • Have a system enabled for "Rule Based Routing"
  • Modeled form [TestForm] exists and has various field types on the form.
  • In form 'Routing Role Assignment', a role is defined [TestRole] and [TestUser] has been assigned to the role
  • In form "Routing Queue Definition", [TestForm] has been assigned to a rule based routing queue [TestQueue]. (Note: When a row launched from the via "Launch Worklist Item" in the widget, this is the form that will be populated and submitted).
  • In form "Routing Configuration Definition", a desired form that is enabled for document routing, has been selected in the "Initial Assignment" field
  • Several rows has been submitted in that form and routed to [TestUser], who has approved the document(s)
  • [TestUser] has the "Rule Based Routing" widget on their home view
Steps
  1. Locate the 'Rule Based Routing' widget.
  2. Select the queue [TestQueue] identified in the setup section
  3. Validate data rows are loaded and in a timely manner
  4. Select a row and click "Launch Worklist Item"
  5. Validate the "Routing Worklist Item" screen is loaded and contains [TestForm] and its expected field, for data entry
  6. For each field on the form, enter a value
  7. Click [File button].
  8. Validate when applicable, that an error dialog is displayed indicating fields where an incorrect value was entered.
  9. Populate each field indicated with a valid value
  10. Click the [File Button]
  11. Validate the form submits successfully and in a timely manner
  12. Validate the 'Rule Based Routing' widget refreshes in a timely manner
  13. Validate data rows are loaded, as expected
  14. Open form [TestForm]
  15. Select the row just submitted in the widget
  16. Validate all fields are populated, as expected
Rule Based Routing Widget - filing validation logic
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Rule Based Routing widget
  • Rule Based Routing
  • Routing Worklist Item
  • Order Fulfillment Widget
  • Order Entry Console
  • POC Results Entry
Scenario 1: Order Fulfillment widget - "Require Fulfillment" modeled form field validations
Specific Setup:
  • Have CWS Modeled form [TestForm], that contains various different field types.
  • Have an order code set up in 'Order Code Setup', that has the 'Require Fulfillment' set to "Yes" and [TestForm] selected in the "Fulfillment Form" field
  • The 'Order Fulfillment' widget and "Orders" widget exist on the logged in users home view
Steps
  1. Select a client [TestClient] and navigate the "Order" widget
  2. Search for the order code you defined in the 'New Order' field.
  3. Fill out the required fields and click 'Add to Scratchpad', then 'click Sign'.
  4. Validate a row for the order [TestOrder] is displayed in the widget
  5. Return to your homeview and
  6. Refresh the 'Order Fulfillment' widget.
  7. Validate the widget contains a row for the order entered in step 1
  8. Select the row and click 'Fulfill Order'.
  9. Validate [TestForm] is open
  10. For each field on the form enter a value
  11. Click [File button].
  12. Validate when applicable, that an error dialog is displayed indicating fields where an incorrect value was entered.
  13. Populate each field indicated with a valid value
  14. Click the [File Button]
  15. Validate the form submits successfully
  16. Select client [TestClient]
  17. Open form [TestForm]
  18. Validate the row submitted in the widget in step 2, is present
  19. Select the row
  20. Validate all fields are populated as expected
Scenario 2: POC Results Entry - "Associated Form" modeled form field validations
Specific Setup:
  • Have a non episodic modeled form [TestForm], in application "CWS" that contains a variety of columns types, as well as a multiple iteration section.
  • In Order Code setup have "Lab" type order code created [TestCode]
  • Have a client [TestClient] with an active order [TestOrder] that uses [TestCode]
  • In form 'POC Results Entry Configuration'
  • On the 'Observation Definition' section, add a new definition [TestDef] and fill out the required fields
  • On the 'Test Definition' page, add a new test
  • In the 'Associated Form', select [TestForm]
  • Submit the form
  • Have the eMAR widget to your homeview.
Steps
  1. Select [TestClient]
  2. Navigate to the "Emar" widget
  3. Validate the order displays in the 'Lab Orders' tab
  4. Select the order in the widget and click 'Administer'.
  5. Fill out the required fields and click [OK]
  6. Open the 'POC Results Entry' form.
  7. Select [TestOrder] from the 'Order' dropdown.
  8. Validate the collection data is populated
  9. Validate the [TestForm] displays in another window.
  10. Fill out all the fields on the modeled form, including the multiple iteration row, and submit.the form
  11. Validate when applicable, that an error dialog is displayed indicating fields where an incorrect value was entered.
  12. Populate each field indicated with a valid value
  13. Click the [File Button]
  14. Validate the form submits successfully
  15. Reopen the 'POC Results Entry' form
  16. Select [TestOrder].
  17. Validate the collection is not automatically loaded (as it was already submitted)
  18. Change 'Include Resulted Collections' to 'Yes'.
  19. Validate the collection load with the values submitted in step 1.
  20. Edit some field values
  21. Submit the form
  22. Reopen the 'POC Results Entry' form
  23. Select [TestOrder].
  24. Select the collection again.
  25. Validate the changes you made in step 3 are displayed as expected.
Topics
• Rule Based Routing • Order Fulfillment
Update 16 Summary | Details
Document Capture - Allow full text of the Episode field
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Document Capture
  • Client Document Capture
  • Clinical Document Viewer
Scenario 1: Validate Document Capture - Import Episodic
Specific Setup:
  • Perceptive must be installed and enabled.
Steps
  1. Select a client from "myClients" or from the Client search.
  2. Open the client's dashboard.
  3. Using "Document Capture", scan or import in a document.
  4. Select the desired episode to assign the document to.
  5. Validate the correct Episode displays in the "Document Properties" pane.
  6. Capture and save the document.
  7. View the document using "Clinical Document Viewer" or the Chart to ensure it has the correct episode designation and that it displays.
Scenario 2: Validate Document Capture - Import Non-Episodic
Specific Setup:
  • Perceptive must be configured and enabled.
  • Please note: this is for Avatar NX systems only.
  • A client must be enrolled in an existing episode (Client A).
  • A Documentation View must be set up on a user's view containing the 'All Documents' widget and the 'Console Widget Viewer' ('All Documents' view).
Steps
  1. Select "Client A" and launch the 'Client Dashboard'.
  2. Click 'Document Capture' icon.
  3. Validate a 'Capture Mode' dialog stating: 'How would you like to capture documents?'
  4. Click [Import].
  5. Select 'Non-episodic' in the 'Episode' field.
  6. Validate the 'Document Capture' opens in a new window.
  7. Select any value in the 'Document Type' field.
  8. Enter any value in the 'Document Description' field.
  9. Click [Capture] and [Browse].
  10. Locate the file to be imported and click [Open] and [Done].
  11. Validate the image displays.
  12. Click [Save].
  13. Validate a message stating: 'Save Was Successful.' and 'Document Added to Avatar!'
  14. Click [Close Document Capture].
  15. Close the 'Client Dashboard'.
  16. Navigate to the 'All Documents' view.
  17. Validate the newly imported non-episodic document is present and select it.
  18. Validate the 'Console Widget Viewer' displays the document as expected.
  19. Click [Close All].
  20. Validate the 'Console Widget Viewer' no longer displays the document.
  21. Click 'Document Capture' icon.
  22. Validate a 'Capture Mode' dialog stating: "How would you like to capture documents?"
  23. Click [Import].
  24. Select 'Non-episodic' in the 'Episode' field.
  25. Validate the 'Document Capture' opens in a new window.
  26. Click [Close all open forms].
  27. Validate the 'Document Capture' form is closed as expected.
Scenario 3: Client Document Capture - Validation
Specific Setup:
  • Perceptive storage method must be utilized.
  • A client must be enrolled in an existing episode (Client A).
  • A document must exist for import.
Steps
  1. Access the 'Client Document Capture' form.
  2. Enter "Client A" in the 'Client ID' field.
  3. Select any episode for the 'Episode Number' field.
  4. Click [Launch POS Capture].
  5. Validate a 'Capture Mode' dialog stating: "How would you like to capture documents?"
  6. Click [Import].
  7. Validate the 'Document Capture' opens in a new window.
  8. Select any value in the 'Document Type' field.
  9. Enter any value in the 'Document Description' field.
  10. Click [Capture] and [Browse].
  11. Locate the file to be imported and click [Open] and [Done].
  12. Validate the image displays.
  13. Click [Save].
  14. Validate a message stating: 'Save Was Successful.' and 'Document Added to Avatar!'
  15. Close the form.
  16. Access the undocked 'Clinical Document Viewer' form.
  17. Validate the form opens in a new window.
  18. Select "Client" in the 'Select Type' field.
  19. Select 'Individual' in the 'Select All or Individual Client' field.
  20. Enter "Client A" in the 'Select Client' field.
  21. Select the episode from the previous steps in the 'Episode' field.
  22. Click [Process].
  23. Locate and select the document that was saved in the previous steps.
  24. Validate the image displays.
  25. Click [Close All Documents], [Search] and [Close].
Scenario 4: Chart - Client Document Capture - Scan Episodic
Specific Setup:
  • Perceptive must be configured and enabled.
Steps
  1. Open the "Chart Review" form.
  2. Select the desired client.
  3. Navigate to the "Chart".
  4. Click "Document Capture".
  5. Scan a document and identify an episode.
  6. Note the document type.
  7. Save the document.
  8. Click the document type the document was just saved under.
  9. Locate the document that was just saved.
  10. Validate the document displays as it was scanned.
  11. Print the document and validate it prints as it was scanned.
  12. Close the forms.
Topics
• Perceptive
Update 22 Summary | Details
Crystal Report Document Routing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Registry Settings (PM)
  • Treatment Plan
  • Site Specific Section Modeling (CWS)
  • Registry Settings (CWS)
  • Ambulatory Progress Note
Scenario 1: Progress Notes (Group and Individual) - Validate 'Treatment Plan' Grid and 'Signature' fields
Specific Setup:
  • Signature support must be enabled in the 'System Security Defaults' form.
  • The 'Progress Notes' widget is accessible on the HomeView.
  • The 'Enable Treatment Plan Grid' registry setting is set to "Y" for the 'Progress Notes (Group and Individual)' form.
  • The 'Progress Notes (Group and Individual)' form must have a signature field added via 'Site Specific Section Modeling' (Signature A).
  • A client must have a Treatment Plan filed with a problem, goal, objective, and intervention associated (Client A).
  • Must have a crystal report configured for document routing configured for "Signature A" and the 'Treatment Plan' grid for progress notes (Crystal Report A).
  • Crystal Report Document Routing must be configured for the 'Progress Notes (Group and Individual)' form using "Crystal Report 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'.
  6. Click [New Row] in the 'Treatment Plan Grid'.
  7. Select "Treatment Plan" in the 'Select T.P. Version' field.
  8. Click [View].
  9. Select the desired treatment plan item and click [Return].
  10. Enter the desired value in the 'T.P. Item Notes/Documentations' field.
  11. Click [Sign] for "Signature A" and enter the desired signature.
  12. Select "Final" in the 'Draft/Final' field.
  13. Click [File Note].
  14. Validate the 'Confirm Document' dialog is displayed with "Crystal Report A". Validate the signature and treatment plan grid data display as expected.
  15. Leave the form open.
  16. Access Crystal Reports or other SQL Reporting Tool.
  17. Create a report using the 'CWSTEMP.cw_patient_notes_tpnotes' SQL table.
  18. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  19. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_patient_notes_tpnotes' SQL table after filing the note.
  20. Close the report.
  21. Create a report using the 'CWSTEMP.cw_tx_pn_sign_data' SQL table.
  22. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  23. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_tx_pn_sign_data' SQL table after filing the note.
  24. Close the report.
  25. Navigate back to the 'Progress Notes (Group and Individual)' form.
  26. Click [Accept].
  27. Enter the password associated to the logged in user.
  28. Close the form.
  29. Select "Client A" and access the 'Progress Notes' widget.
  30. Validate the progress note filed in the previous steps is displayed with the treatment plan and signature data.
  31. Access Crystal Reports or other SQL Reporting Tool.
  32. Create a report using the 'SYSTEM.cw_patient_notes_tpnotes' SQL table.
  33. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  34. Close the report.
  35. Create a report using the 'SYSTEM.cw_tx_pn_sign_data' SQL table.
  36. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  37. Close the report.
Scenario 2: Ambulatory Progress Notes - Validate 'Treatment Plan' Grid and Signature fields
Specific Setup:
  • Signature support must be enabled in the 'System Security Defaults' form.
  • The 'Progress Notes' widget is accessible on the HomeView.
  • The 'Enable Treatment Plan Grid' registry setting is set to "Y" for the 'Ambulatory Progress Notes' form.
  • The 'Ambulatory Progress Notes' form must have a signature field added via 'Site Specific Section Modeling' (Signature A).
  • A client must be enrolled in an outpatient episode and have a Treatment Plan filed with a problem, goal, objective, and intervention associated (Client A).
  • Must have a crystal report configured for document routing configured for "Signature A" and the 'Treatment Plan' grid for 'Ambulatory Progress Notes' (Crystal Report A).
  • Crystal Report Document Routing must be configured for the 'Ambulatory Progress Notes' form using "Crystal Report A".
Steps
  1. Select "Client A" and access the 'Ambulatory Progress Notes' form.
  2. Select "Independent Note" in the 'Progress Note For' field.
  3. Select the desired value in the 'Note Type' field.
  4. Enter the desired value in the 'Notes Field'.
  5. Click [New Row] in the 'Treatment Plan Grid'.
  6. Select "Treatment Plan" in the 'Select T.P. Version' field.
  7. Click [View].
  8. Select the desired treatment plan item and click [Return].
  9. Enter the desired value in the 'T.P. Item Notes/Documentations' field.
  10. Click [Sign] for "Signature A" and enter the desired signature.
  11. Select "Final" in the 'Draft/Final' field.
  12. Click [Submit].
  13. Validate the 'Confirm Document' dialog is displayed with "Crystal Report A". Validate the signature and treatment plan grid data display as expected.
  14. Leave the form open.
  15. Access Crystal Reports or other SQL Reporting Tool.
  16. Create a report using the 'CWSTEMP.cw_patient_notes_tpnotes' SQL table.
  17. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  18. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_patient_notes_tpnotes' SQL table after filing the note.
  19. Close the report.
  20. Create a report using the 'CWSTEMP.cw_tx_pn_sign_data' SQL table.
  21. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  22. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_tx_pn_sign_data' SQL table after filing the note.
  23. Close the report.
  24. Navigate back to the 'Ambulatory Progress Notes' form.
  25. Click [Accept].
  26. Enter the password associated to the logged in user.
  27. Close the form.
  28. Select "Client A" and access the 'Progress Notes' widget.
  29. Validate the progress note filed in the previous steps is displayed with the treatment plan and signature data.
  30. Access Crystal Reports or other SQL Reporting Tool.
  31. Create a report using the 'SYSTEM.cw_patient_notes_tpnotes' SQL table.
  32. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  33. Close the report.
  34. Create a report using the 'SYSTEM.cw_tx_pn_sign_data' SQL table.
  35. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  36. Close the report.
Scenario 3: Inpatient Progress Notes - Validate 'Treatment Plan' Grid and 'Signature' fields
Specific Setup:
  • Signature support must be enabled in the 'System Security Defaults' form.
  • The 'Progress Notes' widget is accessible on the HomeView.
  • The 'Enable Treatment Plan Grid' registry setting is set to "Y" for the 'Inpatient Progress Notes' form.
  • The 'Inpatient Progress Notes' form must have a signature field added via 'Site Specific Section Modeling' (Signature A).
  • A client must be enrolled in an inpatient episode and have a Treatment Plan filed with a problem, goal, objective, and intervention associated (Client A).
  • Must have a crystal report configured for document routing configured for "Signature A" and the 'Treatment Plan' grid for Inpatient progress notes (Crystal Report A).
  • Crystal Report Document Routing must be configured for the 'Inpatient Progress Notes' form using "Crystal Report A".
Steps
  1. Select "Client A" and access the 'Inpatient Progress Notes' form.
  2. Select "Independent Note" in the 'Progress Note For' field.
  3. Select the desired value in the 'Note Type' field.
  4. Enter the desired value in the 'Notes Field'.
  5. Click [New Row] in the 'Treatment Plan Grid'.
  6. Select "Treatment Plan" in the 'Select T.P. Version' field.
  7. Click [View].
  8. Select the desired treatment plan item and click [Return].
  9. Enter the desired value in the 'T.P. Item Notes/Documentations' field.
  10. Click [Sign] for "Signature A" and enter the desired signature.
  11. Select "Final" in the 'Draft/Final' field.
  12. Click [File Note].
  13. Validate the 'Confirm Document' dialog is displayed with "Crystal Report A". Validate the signature and treatment plan grid data display as expected.
  14. Leave the form open.
  15. Access Crystal Reports or other SQL Reporting Tool.
  16. Create a report using the 'CWSTEMP.cw_patient_notes_tpnotes' SQL table.
  17. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  18. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_patient_notes_tpnotes' SQL table after filing the note.
  19. Close the report.
  20. Create a report using the 'CWSTEMP.cw_tx_pn_sign_data' SQL table.
  21. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  22. Please note: this is a temporary storage table. A process will run once daily that will clean up this data, which will become available in the SYSTEM.cw_tx_pn_sign_data' SQL table after filing the note.
  23. Close the report.
  24. Navigate back to the ' InpatientProgress Notes ' form.
  25. Click [Accept].
  26. Close the form.
  27. Select "Client A" and access the 'Progress Notes' widget.
  28. Validate the progress note filed in the previous steps is displayed with the treatment plan and signature data.
  29. Access Crystal Reports or other SQL Reporting Tool.
  30. Create a report using the 'SYSTEM.cw_patient_notes_tpnotes' SQL table.
  31. Validate a row is displayed for the treatment plan data entered for "Client A" in the previous steps.
  32. Close the report.
  33. Create a report using the 'SYSTEM.cw_tx_pn_sign_data' SQL table.
  34. Validate a row is displayed for the signature data entered for "Client A" in the previous steps.
  35. Close the report.
Topics
• Document Routing • Progress Notes • Query/Reporting
Update 23 Summary | Details
Connect/Disconnect Application Namespace
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Connect/Disconnect Application Namespace
  • Application Namespace Connections Validation
Scenario 1: Connect/Disconnect Application Namespace - Disconnect Database/then Reconnect with "CDR" Link 'enabled'
Specific Setup:
  • Have a system with a child namespace, for example "Avatar MSO", that is already connected to the parent namespace, for example "Avatar PM", via the "Connect/Disconnect Application Namespace" form
  • Have a report to display data in the "SYSTEM.radplus_error_log" table
Steps
  1. Open the "Connect/Disconnect Application Namespace" form:
  2. From the "Application" field, select the application noted in the setup
  3. In the "Connect or Disconnect" field, select:
  4. "Connect/Maintain Connection/Repair Connection".
  5. Submit the form (Note submission can take some time):
  6. Validate submission is successful.
  7. Close the form
  8. Run the report based on the "SYSTEM.radplus_error_log"
  9. In the "Option Description" field, validate there are no rows listed for the "Connect/Disconnect Application Namespace" form:
  10. Re-open the "Connect/Disconnect Application Namespace" form:
  11. From the "Application" field, select the application noted in the setup
  12. In the "Connect or Disconnect" field, select:
  13. "Connect/Maintain Connection/Repair Connection"
  14. In the "Clinical Data Repository (CDR) Link", select "No"
  15. Submit the form (Note submission can take some time):
  16. Validate submission is successful.
  17. Run the report based on the "SYSTEM.radplus_error_log"
  18. In the "Option Description" field, validate there are no rows listed for the "Connect/Disconnect Application Namespace" form:
  19. Open form "Applications Namespace Connection Validations":
  20. Validate "Currently Connected Namespaces" text box lists the expected child applications and namespace(s):
  21. Validate there is a message stating "There are no Application/Namespace errors".
  22. Close the form.
Scenario 2: Connect/Disconnect Application Namespace - Disconnect Database/then Reconnect with "CDR" Link 'disabled'
Specific Setup:
  • Have a system with a child namespace, for example "Avatar MSO, that is already connected to the parent namespace, for example "Avatar PM", via the "Connect/Disconnect Application Namespace" form
  • Have a report to display data in the "SYSTEM.radplus_error_log' table
Steps
  1. Open the "Connect/Disconnect Application Namespace" form:
  2. From the "Application" field, select the application noted in the setup
  3. In the "Connect or Disconnect" field, select:
  4. "Connect/Maintain Connection/Repair Connection".
  5. Submit the form (Note submission can take some time):
  6. Validate submission is successful.
  7. Close the form
  8. Run the report based on the 'SYSTEM.radplus_error_log"
  9. In the "Option Description" field, validate there are no rows listed for the "Connect/Disconnect Application Namespace" form:
  10. Re-open the "Connect/Disconnect Application Namespace" form:
  11. From the "Application" field, select the application noted in the setup
  12. In the "Connect or Disconnect" field, select:
  13. "Connect/Maintain Connection/Repair Connection"
  14. In the "Clinical Data Repository (CDR) Link", select "Yes"
  15. Submit the form (Note submission can take some time):
  16. Validate submission is successful.
  17. Run the report based on the "SYSTEM.radplus_error_log"
  18. In the "Option Description" field, validate there are no rows listed for the "Connect/Disconnect Application Namespace" form:
  19. Open form "Applications Namespace Connection Validations":
  20. Validate "Currently Connected Namespaces" text box lists the expected child applications and namespace(s):
  21. Validate there is a message stating "There are no Application/Namespace errors".
  22. Close the form.
"Service Documentation" enabled modeled forms
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Registry Settings (PM)
  • Modeled Form With Service Documentation
Scenario 1: Service Documentation - Validate 'Autosave' functionality (Registry setting "Default to Draft" set to "N")
Specific Setup:
  • Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields
  • Open 'Form Definition' for the [TestForm] and set 'Form supports automatic backup' to 'Yes'.
  • Registry setting "RADplus->Modeling->Settings->Default To Draft" is set to "N"
  • An appointment [TestAppt] has been scheduled with a client [TestClient] in form "Appointment Scheduling"
  • An existing service exists for [TestClient]
Steps
  1. Open form [TestForm]
  2. Select [TestClient] in the client search field
  3. In the "Documentation For" selection field
  4. Select "Existing Appointment"
  5. Validate the "Draft/Final" field has 'not' defaulted to "Draft" selected, as expected
  6. Do not make a selection in the field
  7. Populate any other required or desired fields
  8. Click the "Backup Form" button to auto save your changes
  9. Validate a message is displayed on the form indicating the time of the backup.
  10. Close the form
  11. Reopen form [TestForm]
  12. Select [TestClient] in the client search field
  13. Validate "Restore/Delete Backup Data" screen is displayed
  14. Validate a row is displayed indicating there is an unsubmitted backup
  15. Click "Yes" to accept the backup
  16. Validate [TestForm] is loaded successfully
  17. Validate the "Draft/Final" field has 'not' defaulted to "Draft" selected, as expected
  18. Validate all fields populated prior to backing up the form in step 1, are populated as expected
  19. Submit the form
  20. Validate the form submits successfully
  21. Re- open form [TestForm]
  22. Select [TestClient] in the client search field
  23. Select the row just submitted
  24. Validate the "Draft/Final" field has 'not' defaulted to "Draft" selected, as expected
  25. Validate all fields populated prior to backing up the form in step 1, are populated as expected
  26. Repeat steps 1 thru 3 for [TestClient]
  27. Selecting the clients existing service in the "Documentation For" selection field and clicking the "Backup Form" button to auto save your changes
  28. Validate results are as expected
Scenario 2: Service Documentation - Validate 'Autosave' functionality (Registry setting "Default to Draft" set to "Y")
Specific Setup:
  • Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields
  • Open 'Form Definition' for the [TestForm] and set 'Form supports automatic backup' to 'Yes'.
  • Registry setting "RADplus->Modeling->Settings->Default To Draft" is set to "Y"
  • An appointment [TestAppt] has been scheduled with a client [TestClient] in form "Appointment Scheduling"
  • An existing service exists for [TestClient]
Steps
  1. Open form [TestForm]
  2. Select [TestClient] in the client search field
  3. In the "Documentation For" selection field
  4. Select "Existing Appointment"
  5. Validate the "Draft/Final" field has defaulted with "Draft" selected, as expected
  6. Populate any other required or desired fields
  7. Click the "Backup Form" button to auto save your changes
  8. Validate a message is displayed on the form indicating the time of the backup
  9. Close the form
  10. Reopen form [TestForm]
  11. Select [TestClient] in the client search field
  12. Validate "Restore/Delete Backup Data" screen is displayed
  13. Validate a row is displayed indicating there is an unsubmitted backup
  14. Click "Yes" to accept the backup
  15. Validate [TestForm] is loaded
  16. Validate all fields populated prior to backing up the form in step 1, are populated as expected
  17. Validate in the "Draft/Final" is set to "Draft", as expected
  18. Submit the form
  19. Validate the form submits successfully
  20. Re- open form [TestForm]
  21. Select [TestClient] in the client search field
  22. Select the row just submitted
  23. Validate all fields populated prior to backing up the form in step 1, are populated as expected
  24. Validate in the "Draft/Final" is set to "Draft", as expected
  25. Repeat steps 1 thru 3 for [TestClient]
  26. Selecting the clients existing service in the "Documentation For" selection field and clicking the "Backup Form" button to auto save your changes
  27. Validate results are as expected
ODBC connection requests
Internal Test Only
Topics
• Database Management • Auto Save • Service Documentation
Update 28 Summary | Details
Avatar NX - Widget Buttons on Client Header
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Update Client Data
  • Client Lookup/Header Configuration Manager
  • Individual Progress Note
Scenario 1: Avatar NX - Validate widget buttons in client header
Specific Setup:
  • The logged in user must have the 'Client Information header' configured to their 'myDay' view.
  • The logged in user must have additional view configured.
  • The 'Default Value for Console View Episodes' registry setting must be set to "0"
  • There must be 5 widgets assigned in the 'Client Lookup/Header Configuration Manager' form.
  • Two program overrides must be configured in the 'Client Lookup/Header Configuration Manager' form:
  • Program A and Program B
  • "Program B" must have a widget assigned.
  • Three clients must be defined:
  • A client must be enrolled in more than one existing episodes (Client A).
  • Episode 1 must be 'Program A' and the other can be any other program that's not an override.
  • A client must be enrolled in 'Program A' (Client B).
  • A client must be enrolled in 'Program B' (Client C).
  • Please note: this is for Avatar NX systems only.
Steps
  1. Select "Client A" and access the 'Update Client Data' form.
  2. Validate five widgets buttons display in the client header.
  3. Undock one the widgets.
  4. Validate the undocked widgets displays: "Client A | Episode: All" as well as the appropriate data.
  5. Continue undocking widgets in the client header.
  6. Validate the undocked widgets display the correct client information.
  7. Navigate back to the 'myDay' view.
  8. Validate all the undocked widgets close.
  9. Navigate back to the 'Update Client Data' form.
  10. Click [Discard] and [Yes].
  11. With "Client A" selected, undocked the widgets from the client header.
  12. Validate the undocked widgets display the correct client information.
  13. Select a different episode from the 'Episode Selection' field in the top navigation
  14. Validate the undocked widgets update accordingly.
  15. Select "Client B".
  16. Validate no widget buttons display in the client header since none are configured for "Program A".
  17. Validate the undocked widgets update accordingly.
  18. Close the undocked widgets.
  19. Access the 'Progress Notes (Group and Individual)' form.
  20. Validate no widget buttons display in the client header.
  21. Clear the 'Select Episode' field.
  22. Validate the five configured widget buttons display in the client header.
  23. Select "Client C" from the 'Select Client' field.
  24. Validate the widget button configured for "Program B" displays in the client header.
  25. Undock this widget.
  26. Validate the undocked widget displays the correct client information.
  27. Select the desired value in the 'Progress Note For' field.
  28. Select the desired value in the 'Note Type' field.
  29. Enter the desired value in the 'Notes' field.
  30. Select "Draft" in the 'Draft/Final' field.
  31. Click [File Note] and [No].
  32. Validate the undocked widget closes.
  33. Clear the client.
Scenario 2: 'Client Lookup/Header Configuration Manager' - Adding widgets
Specific Setup:
  • Two program overrides must be configured in the 'Client Lookup/Header Configuration Manager' form:
  • Program A and Program B
  • Three clients must be defined:
  • A client must be enrolled in an existing episode (Client A).
  • A client must be enrolled in Program A (Client B).
  • A client must be enrolled in Program B (Client C).
  • Please note: this is for Avatar NX systems only.
Steps
  1. Access the 'Client Lookup/Header Configuration Manager' form.
  2. Validate the additional form sections: Client Header Widgets, Client Header Override, and Client Header Override Fields.
  3. Navigate to the "Client Header Widgets" form section.
  4. Select the desired widget from the 'Select Widget Button to Include (Max 5)' field.
  5. Click [Add Widget to Header].
  6. Validate the widget displays in the 'Included Widget Buttons' field.
  7. Repeat steps 1c-1e four more times.
  8. Click [Submit].
  9. Access the 'Client Lookup/Header Configuration Manager' form.
  10. Navigate to the "Client Header Override" form section.
  11. Select "Program A" from the 'Client Header Override' field.
  12. Click [Edit Selected Item].
  13. Select the desired widget from the 'Select Widget Button to Include (Max 5)' field.
  14. Click [Add Widget to Header].
  15. Validate the widget displays in the 'Included Widget Buttons' field.
  16. Navigate to the "Client Header Override Fields" form section.
  17. Validate the previously submitted data for "Program A" displays as expected.
  18. Click [Submit].
  19. Select "Client A".
  20. Validate the widget buttons configured in step 1 display as expected.
  21. Select "Client B".
  22. Validate the widget buttons configured in step 2 displays as expected.
  23. Select "Client C".
  24. Validate no widget buttons display in the client header since none were configured for this program.
  25. Access the 'Client Lookup/Header Configuration Manager' form.
  26. Navigate to the "Client Header Widgets" form section.
  27. Select the desired widget from the 'Select Widget to Remove' field.
  28. Click [Remove Widget].
  29. Validate the 'Included Widget Buttons' field updates and displays accordingly.
  30. Click [Submit].
  31. Select "Client A".
  32. Validate the widget buttons display as expected.
  33. Access the 'Client Lookup/Header Configuration Manager' form.
  34. Navigate to the "Client Header Widgets" form section.
  35. Select the desired widget from the 'Select Widget to Change Display Order' field.
  36. Select the desired value from the 'Display Order' field.
  37. Click [Update Order].
  38. Validate the 'Included Widget Buttons' field updates and displays accordingly.
  39. Click [Submit].
  40. Select "Client A".
  41. Validate the widget buttons display as expected.
The 'Client Lookup/Header Configuration Manager' form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Update Client Data
  • Client Lookup/Header Configuration Manager
  • Individual Progress Note
Scenario 1: 'Client Lookup/Header Configuration Manager' - Adding widgets
Specific Setup:
  • Two program overrides must be configured in the 'Client Lookup/Header Configuration Manager' form:
  • Program A and Program B
  • Three clients must be defined:
  • A client must be enrolled in an existing episode (Client A).
  • A client must be enrolled in Program A (Client B).
  • A client must be enrolled in Program B (Client C).
  • Please note: this is for Avatar NX systems only.
Steps
  1. Access the 'Client Lookup/Header Configuration Manager' form.
  2. Validate the additional form sections: Client Header Widgets, Client Header Override, and Client Header Override Fields.
  3. Navigate to the "Client Header Widgets" form section.
  4. Select the desired widget from the 'Select Widget Button to Include (Max 5)' field.
  5. Click [Add Widget to Header].
  6. Validate the widget displays in the 'Included Widget Buttons' field.
  7. Repeat steps 1c-1e four more times.
  8. Click [Submit].
  9. Access the 'Client Lookup/Header Configuration Manager' form.
  10. Navigate to the "Client Header Override" form section.
  11. Select "Program A" from the 'Client Header Override' field.
  12. Click [Edit Selected Item].
  13. Select the desired widget from the 'Select Widget Button to Include (Max 5)' field.
  14. Click [Add Widget to Header].
  15. Validate the widget displays in the 'Included Widget Buttons' field.
  16. Navigate to the "Client Header Override Fields" form section.
  17. Validate the previously submitted data for "Program A" displays as expected.
  18. Click [Submit].
  19. Select "Client A".
  20. Validate the widget buttons configured in step 1 display as expected.
  21. Select "Client B".
  22. Validate the widget buttons configured in step 2 displays as expected.
  23. Select "Client C".
  24. Validate no widget buttons display in the client header since none were configured for this program.
  25. Access the 'Client Lookup/Header Configuration Manager' form.
  26. Navigate to the "Client Header Widgets" form section.
  27. Select the desired widget from the 'Select Widget to Remove' field.
  28. Click [Remove Widget].
  29. Validate the 'Included Widget Buttons' field updates and displays accordingly.
  30. Click [Submit].
  31. Select "Client A".
  32. Validate the widget buttons display as expected.
  33. Access the 'Client Lookup/Header Configuration Manager' form.
  34. Navigate to the "Client Header Widgets" form section.
  35. Select the desired widget from the 'Select Widget to Change Display Order' field.
  36. Select the desired value from the 'Display Order' field.
  37. Click [Update Order].
  38. Validate the 'Included Widget Buttons' field updates and displays accordingly.
  39. Click [Submit].
  40. Select "Client A".
  41. Validate the widget buttons display as expected.
Topics
• Progress Notes (Group And Individual) • Update Client Data • Client Header • NX
Update 35 Summary | Details
'User Merge' form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Merge
Scenario 1: 'User Merge' - merge existing user into a new user
Specific Setup:
  • A CWS form must be attached to the PM menu using the 'Attach Other Application Form To Menu' form (Form A).
  • A user role must be defined (User Role A) with the following:
  • Access to "Form A" in the 'Select Forms' field in the 'Appointment Scheduling' section.
  • A user must be defined and associated to "User Role A" (User A).
Steps
  1. Access the 'User Merge' form.
  2. Select "New" in the 'Merge Into New or Existing User' field.
  3. Enter "MergeUser" in the 'New User ID' field.
  4. Enter "Merge User" in the 'New User Description' field.
  5. Select "User A" in the 'Source User 1' field.
  6. Click [Submit].
  7. Validate a "Form Return" message is displayed stating: User Merge has completed. Do you wish to return to form?
  8. Click [Yes].
  9. Select the "User Merge Process" section.
  10. Select "User" in the 'All or User' field.
  11. Select "MergeUser" in the 'User Part of Merge' field.
  12. Click [Display Progress Log].
  13. Validate the 'User Merge Progress Log' shows 100% complete. This may take a few moments.
  14. Close the form.
  15. Access the 'User Definition' form.
  16. Select "User A" in the 'Select User' field.
  17. Validate a message is displayed stating: User ID "User A" is disabled. Only User Description can be updated.
  18. Click [OK].
  19. Select "MergeUser" in the 'Select User' field.
  20. Validate the 'User ID' field contains "MergeUser".
  21. Validate the 'User Description' field contains "Merge User".
  22. Validate "User Role A" is selected in the 'User Role(s)' field.
  23. Close the form.
Routing Admin Dashboard - Completed Items
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Routing Admin Dashboard
  • Rule Based Routing
  • Routing Worklist Item
Scenario 1: Routing Admin Dashboard - Re-Assign
Specific Setup:
  • The system is set up for Rule-Based Routing.
  • Must have a rule-based routing item that has been completed (Item A).
  • Must have a rule-based routing item that has not been completed (Item B).
Steps
  1. Access the 'Routing Admin Dashboard' form.
  2. Select the desired value in the 'Queue' field and click [Search].
  3. Select "Item A" from the 'Results' list and click [Re-Assign].
  4. Validate a message is displayed stating: Completed documents may not be re-assigned.
  5. Click [OK].
  6. Select "Item B" in the 'Results' list and click [Re-Assign].
  7. Select "Direct Assignment" in the 'Assignment Type' field.
  8. Select the desired value in the 'New Queue' field.
  9. Select the desired value in the 'New Status' field.
  10. Select the desired user in the 'New User' field.
  11. Click [File].
  12. Select the queue the document has been re-assigned to in the 'Queue' field.
  13. Click [Search].
  14. Validate "Item B" is displayed in the 'Results' list with the updated status/user.
  15. Close the form.
Scenario 2: Routing Admin Dashboard - Re-Assign
Specific Setup:
  • The system is set up for Rule-Based Routing.
  • Must have a rule-based routing item that has been completed (Item A).
  • Must have a rule-based routing item that has not been completed (Item B).
Steps
  1. Access the 'Routing Admin Dashboard' form.
  2. Select the desired value in the 'Queue' field and click [Search].
  3. Select "Item A" from the 'Results' list and click [Re-Assign].
  4. Validate a message is displayed stating: Completed documents may not be re-assigned.
  5. Click [OK].
  6. Select "Item B" in the 'Results' list and click [Re-Assign].
  7. Select "Direct Assignment" in the 'Assignment Type' field.
  8. Select the desired value in the 'New Queue' field.
  9. Select the desired value in the 'New Status' field.
  10. Select the desired user in the 'New User' field.
  11. Click [File].
  12. Select the queue the document has been re-assigned to in the 'Queue' field.
  13. Click [Search].
  14. Validate "Item B" is displayed in the 'Results' list with the updated status/user.
  15. Close the form.
Topics
• User Definition • User Merge • Rule Based Routing
Update 37 Summary | Details
Avatar NX - 'Online Documentation URL'
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Form Designer (PM)
  • Progress Notes
  • Diagnosis
Scenario 1: Validate 'Online Documentation URL' links set up in 'Form Designer'
Specific Setup:
  • Please note: this is for Avatar NX.
  • User must have an 'Online Documentation' link set up in 'Form Designer' for the 'Progress Notes (Group and Individual)' form.
  • User must have an 'Online Documentation' link set up in 'Form Designer' for the 'Diagnosis' form.
  • A modeled form is defined (Form A).
  • User must have an 'Online Documentation' link set up in 'Form Designer' for "Form A".
Steps
  1. Access the 'Progress Notes (Group and Individual)' form.
  2. Validate the 'Online Documentation' link is present.
  3. Click the 'Online Documentation' link and verify a new browser window opens to the URL set up in the pre-conditions.
  4. Validate when you close the new browser window, the NX screen should still be open, and you can close the form successfully.
  5. Access the 'Diagnosis' form.
  6. Validate the 'Online Documentation' link is present.
  7. Click the 'Online Documentation' link and verify a new browser window opens to the URL set up in the pre-conditions.
  8. Validate when you close the new browser window, the NX screen should still be open, and you can close the form successfully.
  9. Access "Form A".
  10. Validate the 'Online Documentation' link is present.
  11. Click the 'Online Documentation' link and verify a new browser window opens to the URL set up in the pre-conditions.
  12. Validate when you close the new browser window, the NX screen should still be open, and you can close the form successfully.
Topics
• Form Designer • NX
Update 42 Summary | Details
'User File Import' form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User File Import
Scenario 1: User File Import - File Validations
Specific Setup:
  • Have a "User File Import" file created that includes pipe characters in the 'User Description' (File A).
Steps
  1. Access the 'User File Import' form.
  2. Click [Select User Import File].
  3. Select "import1" and click [Open].
  4. Validate the 'Import File Scan Results' field contains: No errors or warnings detected in import file.
  5. Click [Process User Import File].
  6. Validate a message is displayed stating: Import Completed!
  7. Click [OK] and close the form.
  8. Access the 'User Definition' form.
  9. Select the user imported via "File A" in the 'Select User' field.
  10. Validate the 'User Description' field contains exclamation points instead of pipe characters.
  11. Validate all imported data is displayed as expected.
  12. Close the form.
  13. Access Crystal Reports or other SQL Reporting Tool.
  14. Create a report using the SYSTEM.RADplus_users SQL table.
  15. Validate a row is displayed for the user imported via "File A".
  16. Validate the 'user_description' field contains values with exclamation points.
  17. Close the report.
Topics
• User Definition
Update 44 Summary | Details
Client Search Results
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Client Ledger
  • Client Charge Input
  • Update Client Data
Scenario 1: Validate "Client" search field functionality and results
Specific Setup:
  • The 'Disable Soundex in Smart Search' registry setting must be set to "Y".
  • Must have the 'Client and Staff' widget on the HomeView.
Steps
  1. In the 'Search Clients' field on the HomeView, enter a single letter without clicking the [Search] button.
  2. Validate the 'Results' list contains clients whose last name starts with that letter.
  3. In the 'Search Clients' field on the HomeView, enter a single letter and click [Search].
  4. Validate the 'Select Client' dialog is displayed and the 'Results' list contains clients whose last name starts with that letter.
  5. Repeat steps 1 and 2 entering two or more letters.
  6. Validate the 'Results' list contains clients whose last name begins with those two letters.
  7. In the 'Search Clients' field on the HomeView, enter a last name followed by a comma (Ex. LASTNAME,).
  8. Validate the 'Results' list contains clients with the last name entered.
  9. In the 'Search Clients' field, enter a single number without clicking [Search].
  10. Validate the 'Results' list contains clients whose PATID contain that number.
  11. In the 'Search Clients' field, enter a single number and click [Search].
  12. Validate the 'Select Client' dialog is displayed and the 'Results' list contains clients whose PATID contain that number.
  13. Repeat steps 5 and 6 entering two or more numbers.
  14. Validate the 'Results' list contains clients containing PATIDs with those numbers.
  15. Access any client based form and in the 'Select Client' field, enter a single letter without clicking [Search].
  16. Validate the 'Results' list contains clients whose last name starts with that letter.
  17. Access any client based form and in the 'Select Client' field, enter a single letter and click [Search].
  18. Validate the 'Select Client' dialog is displayed and the 'Results' list contains clients whose last name starts with that letter.
  19. Repeat steps 8 and 9 entering two or more letters.
  20. Validate the 'Results' list contains clients whose last name begins with those two letters.
  21. Access any client based form and in the 'Select Client' field, enter a last name followed by a comma (Ex. LASTNAME,).
  22. Validate the 'Results' list contains clients with the last name entered.
  23. Access any client based form and in the 'Select Client' field, enter a single number without clicking [Search].
  24. Validate the 'Results' list contains clients whose PATID contain that number.
  25. Access any client based form and in the 'Select Client' field, enter a single number and click [Search].
  26. Validate the 'Select Client' dialog is displayed and the 'Results' list contains clients whose PATID contain that number.
  27. Repeat steps 9 and 10 entering two or more numbers.
  28. Validate the 'Results' list contains clients containing PATIDs with those numbers.
Topics
• Client Search
2023 Update 121 Summary | Details
All Documents Widget Definition- Select/Deselect forms
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • All Documents Widget Definition
Scenario 1: 'All Documents Widget Definition' Form- (Forms attached to a menu from another application) - 'Forms Assigned' Validations
Specific Setup:
  • Have two forms in an application that can be used for testing. For this test, "Avatar PM" is used. [PMForm1] and [PMForm2]
  • In another application, (e.g. Avatar CWS), open form "Attach Other Application Form to Menu"
  • In the "Application" field select the 'Avatar PM' application and in the "Form To Attach" choose the form [PMForm1]
  • In the" Menu to Place Form Under" field choose a desired " CWS" menu for the "PM" form
  • Update "Form Description' field with a new desired name, that will appear on the "CWS" menu [PMForm1CWS]
  • Submit the form
  • Repeat the previous step for [PMForm2], assigning the form a different name [PMForm2CWS], in the 'Form Description' field
  • The logged in user has the [AllDocWidget] is their home view
  • The logged in user has access to form "All Document Widget Definition"
Steps
  1. Open the "All Documents Widget Definition" form.
  2. Select the "Multi-Form Tab" section and select "Add" to create a new tab
  3. Populate the "Tab ID" with a desired value and enter a desired name for the tab [CrossNamespaceTab], in the "Tab Name" field
  4. Click the 'Forms Assigned" button.
  5. Validate both forms PM forms that were attached to a CWS menu in the set up, [PMForm1CWS] and [PMForm2CWS], are available for selection
  6. Validate neither of the forms are currently selected
  7. Select [PMForm1CWS] and leave [PMForm2CWS] unselected
  8. Select any other form [TestForm] leaving any others unselected
  9. Click [OK] to save the changes
  10. Click the "Forms Assigned" button
  11. Validated [PMForm1CWS] is selected and [PMForm2cws] is not, as expected
  12. Validate [TestForm] is still selected and all other forms are still unselected, as expected
  13. Now deselect form [PMForm1CWS] and select [PMForm2CWS]
  14. Click [OK] to save the changes
  15. Click the "Forms Assigned" button
  16. Validated [PMForm2CWS] is selected and [PMForm1CWS] is not, as expected
  17. Validate [TestForm] is still selected and all other forms are still unselected, as expected
  18. Click [OK]
  19. Click [File] to create the tab and save the changes made
  20. Validate submission is successful and exit the form
  21. Open the "All Documents Widget Definition" form.
  22. Select the "Multi-Form Tab" section and select "Edit"
  23. Select tab [CrossNamespaceTab] for edit
  24. Click the 'Forms Assigned" button
  25. Validated [PMForm2CWS] is selected and [PMForm1CWS] is not, as expected
  26. Validate [TestForm] is still selected and all other forms are still unselected, as expected
  27. Click [OK]
  28. Exit the form
All Document Widget - forms
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • All Documents Widget Definition
Scenario 1: 'All Document Widget"- (Form attached to a menu from another application) - "Tab" Form/Data validations
Specific Setup:
  • Have a form in any application that can be used for testing. For this testing "Avatar CWS" is used. [CWSForm]
  • In another application, (e.g. Avatar PM), open form "Attach Other Application Form to Menu'
  • In the "Application" field select the 'Avatar CWS' application and in the "Form To Attach" choose [CWSForm]
  • In the "Menu to Place Form Under" choose a desired "PM" menu for the "CWS" form
  • Update "Form Description" field as a desired distinguishable name for "CWS" form that will appear on the "PM" menu [CWSFormPM]
  • Submit the form
  • In form "All Documents Widget Definition", have an all document widget defined [AllDocWidget]
  • The logged in user has the [AllDocWidget] as their home view
  • The logged in user has access to form "All Document Widget Definition" and [CWSForm] and [CWSFormPM]
Steps
  1. Open the "All Documents Widget Definition" form.
  2. Select the "Multi-Form Tab" section and select "Edit"
  3. From the "Select Tab" field, select any existing Tab [CrossNamespaceTab]
  4. Click the "Forms Assigned" button
  5. Select [CWSFormPM], the form attached from a "PM" forms list
  6. Do not select [CWSForm] from the "CWS" forms list, the form used to attach to the other application menu
  7. Click [OK]
  8. Click the "Forms Assigned" button
  9. Validate [CWSformPM] is selected and [CWSForm] is not, as expected
  10. Click [OK] to save the changes
  11. Click [File] to save the tab changes
  12. Navigate the home view
  13. Select a desired client [TestClient]
  14. From the "PM" menu open form [CWSFormPM]
  15. Populate the desired fields and submit the form
  16. At the homeview, click to refresh the [AllDocWidget]
  17. Click the [CrossNamespaceTab] tab
  18. Validate a data row is present in the widget for the row submitted in step 2
  19. Validate "Form Description" field for the row is [CWSForm] as expected. [Note: the name from the original form name used to attach to the other application menu, will always display]
  20. Validate all other column data is displayed, as expected
  21. Navigate back to the home view
  22. Select a desired client [TestClient]
  23. This time from the "CWS" menu, open form [CWSForm]
  24. Populate the desired fields and submit the form
  25. Navigate back to the [AllDocWidget] and click to refresh the widget
  26. Click the [CrossNamespaceTab] tab
  27. Validate a data row is present in the widget for the row submitted in step 4
  28. Validate "Form Description" field for the row is [CWSForm] as expected.
  29. Validate all other column data is displayed, as expected
All document Widget - form data rows
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Risk Level Update
Scenario 1: 'All Documents' widget - Form data row validations
Specific Setup:
  • A client is enrolled in an existing episode [TestClient]
  • Have two modeled forms [FormA] and [FormB]
  • [FormA] is based on a table that is "Date" sorted. [Note: this is configured with prompt "Is This Table Date Sorted" set to "Yes" in "Table Definition"]
  • [FormB] is not based on a table that is "Date Sorted"
  • Have any other desired form [FormC],
  • [FormC] has many rows of data submitted for a client[TestClient], for example four hundred rows or more
  • Have the registry setting "Enable Risk Level Functionality" enabled
  • Have access to the "Risk Level Update" for [TestClient].
  • Have an "All Documents Widget" created [AllDocsWidget], in form " All Documents Widget Definition"
  • Have [FormA], [FormB], [FormC] and the "Risk Level Update" from, added for selection in any tab in the widget, For this test, the "All Forms" tab is used
  • The logged in user has access to all forms in the setup above and the "All Documents Widget Definition" form
  • The logged in user has the "All Document Widget" on their home view
Steps
  1. Select a client [TestClient]
  2. Open [FormA] (Modeled Form 'Date Sorted')
  3. Select an episode
  4. Populate the required "Date Sorted" date field with a date other than the current date
  5. Populate any desired fields
  6. Submit the form
  7. Validate the form files successfully
  8. Note the current date and the "Date Sorted" date entered in step 2b
  9. Open [FormB] (Modeled form not 'Date Sorted')
  10. Select an episode
  11. Populate any desired fields
  12. Submit the form
  13. Validate the form files successfully
  14. Note the submission the date and time
  15. Open the "Risk Level Update" form
  16. Add a row the "Risk Level Change" grid
  17. Populate the "Date of Change" field. Make note of the date value.
  18. Populated other fields, as required
  19. Submit the form
  20. Validate the form submits successfully
  21. At the home view, select [TestClient]
  22. Navigate to the "All Documents Widget" and click the "Refresh" button
  23. Click the "All Forms" tab
  24. Select [FormA] from the 'Form Description' field.
  25. Validate the "Form Description" field is populated with the form name for [FormA]
  26. Select the episode from the "Episode" field
  27. Validate the "Date" column field value, is populated with the "Date Sorted" date noted in step 2d
  28. Validate the "Time" column field value is 'not' populated. [This modeled form based on a table that is "Date Sorted". By design, for tables that are date sorted, the "Date" field will be populated with the sort date instead of the "Date Entry Date" and the "Time" field will be left unpopulated]
  29. Validate each of the columns are populated, as expected
  30. Select [FormB] from the 'Form Description' field.
  31. Validate the "Form Description" field is populated with the form name for [FormB]
  32. Select the episode from the "Episode" field
  33. Validate the "Date" column is populated with the date noted in step 3, which is the 'Date Entry Date'
  34. Validate the "Time" field is populated, as expected with time noted in step 3, which is the "Date Entry Time"
  35. Validate each of the columns are populated, as expected
  36. Select the "Risk Level Update" from the 'Form Description' field.
  37. Validate the "Form Description" field is populated with the form name for [FormA]
  38. Select the episode from the "Episode" field
  39. Validate the "Date" column is populated with "Date of Change" date noted in step 4.[Note: This product form is based on a table that is "Date Sorted". By design, for tables that are date sorted, the "Date" field will be populated with the sort date instead of the "Date Entry Date" and the "Time" field will be left unpopulated]
  40. Validate the "Time" field is 'not' populated, as expected. [Note: as the date displayed in "Date" column field is the data sorted date not the date entry date, by design, the "Time" field value will be blank]
  41. Validate other columns are populated, as expected
  42. Select [FormC] from the 'Form Description' field.
  43. Validate in the right-hand corner of the widget, a counter is displayed indicting "50 of xxx rows"
  44. For example, for this test "50 of 450 rows" is displayed
  45. Validate all "50" rows are displayed, as expected
  46. In the center of the widget, at the bottom
  47. Validate there are left arrow and right arrow navigation buttons bracketing the number of pages of data. For example: < 1 2 3 4 5 >
  48. Validate the page "1" navigation link is currently highlighted
  49. Click the right arrow navigation button again
  50. Validate the next 50 rows are displayed along with previous rows, as expected
  51. Validate in the lower right corner, the counter changes to "100 of 450 rows"
  52. Validate the page "2" navigation link is currently highlighted
  53. Click the right arrow navigation button again
  54. Validate the next 50 rows are displayed along with previous rows, as expected
  55. Validate the counter changes to "200 of 450 rows"
  56. Validate the page "3" navigation link is currently highlighted
  57. Click the right arrow navigation button again
  58. Validate the next 50 rows are displayed along with previous rows, as expected
  59. Validate the counter changes to "250 of 450 rows"
  60. Validate the page "4" navigation link is currently highlighted
  61. If applicable, repeat the last step by clicking the right arrow till the last page is displayed
  62. Validate the next 50 rows are always displayed along with previous rows, as expected
  63. Validate the counter changes to "300 of 450", "350 of 450", "400 of 450" etc., as expected
  64. Validate the page number navigation link increments by one for each page, and is highlighted
Topics
• Forms • All Documents Widget Definition • All Documents Widget
 

RADplus_2024_Monthly_Release_2024.01.00_Details.csv