Skip to main content

RADplus 2022 Monthly Release 2022.02.02 Acceptance Tests


Update 37 Summary | Details
Modeling - Event logic
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • UCLA PTSD
  • Modeled form with Multiple Tables and Event Logic
Scenario 1: Modeling - Validate "Event" logic added in forms containing multiple tables
Specific Setup:
  • Have a modeled form [FormA] that contains a primary table [TableA] and a second table[TableB],
  • Have two fields defined in each table, for this example a "Date" field [FieldA] and a "Multi-Select" dictionary field [FieldB], that is set to be initially 'Disabled', exist in each table
  • Have a modeled form that contains [TableA] in the first section of the form and [TableB] in the second section
  • In each section, set [FieldA] with following event logic:
  • 'Type of Event' set to 'Result of Input with Value Checking'
  • 'Compare with for Event' set to 'Other Tabled Column'
  • 'Table Column for Comparison' set to 'Data_Entry_Date' (Note: this is always the (current date) at the time of new row data entry)
  • 'Comparison Value to Trigger Event' set to 'Less Than'
  • 'Required' set to [FieldB]
Steps
  1. Open "Form Definition" and select [FormA]
  2. Click the first section of the form
  3. Click the "Object Def" tab
  4. Select [FieldA]
  5. Click to the "Event Definition" section
  6. Select the event created in the set up
  7. Validate the field and field values selected for the event defined in the set up, are all populated as expected
  8. Click the second section of the form
  9. Click the "Object Def" tab
  10. Select [FieldA]
  11. Click to the "Event Definition" section
  12. Select the event created in the set up
  13. Validate the field and field values selected for event defined in the set up, are all populated as expected
  14. Close the form
  15. Open [FormA]
  16. Click to "Add" a new row
  17. Click to the first section of the form
  18. Validate [FieldB] is not required, as expected
  19. Enter a date in [FieldA] that is greater than or equal to today's date
  20. Validate [FieldB] is still not required
  21. Enter a date in [FieldA] that is less than today's date
  22. Validate [FieldB] is now required, as expected
  23. Click to the first section of the form
  24. Validate [FieldB] is not required, as expected
  25. Enter a date in [FieldA] that is greater than or equal to today's date
  26. Validate [FieldB] is still not required
  27. Enter a date in [FieldA] that is less than today's date
  28. Validate [FieldB] is now required, as expected

Topics
• Modeling • NX
Update 39 Summary | Details
User File Import
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User File Import
  • User Definition
Scenario 1: Verify 'User File Import'
Specific Setup:
  • Have a system with prompt "Include Supplemental Information within User Definition" to "Yes" in form "System security defaults"
  • In form "User Definition" have an existing user [UserA] who is assigned to a user role [RoleA] and has "Date of Hire" and "Date of Birth" prompts populated on the "Supplemental" section of the form.
  • Have a "User File Import" file created [UserFileA] that includes:
  • [UserA] set with a different user role [RoleB] to be updated in the "User Role" field
  • A new user [UserB], with the "User Role" field populated with any valid user role. For this test [RoleA] is used
Steps
  1. Open the 'User File Import' form.
  2. Click [Select User Import File]
  3. Navigate to the location of [UserFileA] and select the file
  4. Click [Open].
  5. Validate the scan results display messages, "Warning: Row 1 contains an existing User ID which will be edited on import (UserA)" and "Warnings but no errors detected in import file. Import may proceed"
  6. Click [Process User Import File]
  7. Validate there are no errors
  8. Click [OK].
  9. Validate the import completes successfully
  10. Open form "User Definition"
  11. Select [UserA] in the "Select User" field
  12. Validate the user is not assigned to user role [RoleB], as expected
  13. Click "Supplemental" section of the form
  14. Validate "Date of Hire" and "Date of Birth" prompts are populated, as expected
  15. Select [UserB] in the "Select User" field
  16. Validate the user is assigned to user role [RoleA], as expected
Service Documentation - modeled form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Modeled Form With Service Documentation
  • Modeled 'Service Documentation' Forms - Field Validations (w/Service Doc prompts removed from form)
Scenario 1: Modeled 'Service Documentation' Forms - Field Validations
Specific Setup:
  • Have a Modeled [TableA] which is includes:
  • Fields added that will be mapped in the "Service Documentation" section of "Table Definition" that required for service documentation functionality. These include: "Data Row for", "Date of Service", "Service Start Time", "Service End Time", "Service Duration", "Location" "Service Program", "Service Charge". "Service Practitioner" and "Draft/Final" fields
  • Any other desired added that are "not" mapped for service documentation functionality
  • [FormA] contains both the fields that are mapped for "Service Documentation" and also those are not
Steps
  1. Select [ClientA]
  2. Open [FormA]
  3. Set the "Documentation For" field to "New Service
  4. Set the "Draft/Final" field to "Final"
  5. Validate a message is displayed indicating there are required fields on the form that are not populated and the fields are listed
  6. Click [OK]
  7. Validate the "Draft/Final" field is set back to "Draft"
  8. Select a program in the "Service Program" field
  9. Select a service code in the "Service Charge Code" field
  10. Select a location in the "Service Location" field
  11. Select a practitioner in the "Service Practitioner" field
  12. Set the "Service Start Time" to the current time
  13. Set the "Service End Time" to a time prior to the current time
  14. Set the "Service Duration(Minutes) field to "30""
  15. Set the "Draft/Final" field to "Final"
  16. Validate a message is displayed indicating the required field "Date of Service" is not populated
  17. Click [OK]
  18. Validate the "Draft/Final" field is set back to "Draft"
  19. Populate the "Date of Service" field
  20. Set the "Draft/Final" field to "Final"
  21. Validate an error is displayed indicating that the service end time must be after the service start time
  22. Click [OK]
  23. Validate the "Draft/Final" field is set back to "Draft"
  24. Set the "Service Start Time" to one hour earlier than the current time
  25. Set the "Service End Time" to the current time
  26. Set the "Draft/Final" field to final
  27. Validate an error is displayed indicating that time between the service start date and end date is "60" minutes but the "Service Duration(Minutes) field to set to "30"
  28. Click [OK]
  29. Validate the "Draft/Final" field is set back to "Draft"
  30. Set the "Service Duration(Minutes)" field to "60"
  31. Set the "Draft/Final" field to "Final"
  32. At the "Confirm" dialog, click [OK]
  33. Click [Submit]
  34. Validate the form files successfully
  35. Return to [FormA] and select [ClientA]
  36. Edit the row just submitted
  37. Validate all fields are populated, as expected
Scenario 2: Modeled 'Service Documentation' Forms - Field Validations (w/Service Doc prompts removed from form)
Specific Setup:
  • Have a Modeled [TableA] which is includes:
  • Fields added that will be mapped in the "Service Documentation" section of "Table Definition" that required for service documentation functionality. These include: "Data Row for", "Date of Service", "Service Start Time", "Service End Time", "Service Duration", "Location" "Service Program", "Service Charge". "Service Practitioner" and "Draft/Final" fields
  • Any other desired fields that are "not" mapped for service documentation functionality. For this test a "Date", "Scrolling Text", "Picture" and "Dictionary" fields are used.
  • Have one of the fields set to be required, for the test the "Dictionary" field is set to be required.
  • [FormA] contains [TableA] but "only" contains the fields that are "not" mapped for service documentation on the form
Steps
  1. Select [ClientA]
  2. Open [FormA]
  3. Populate just the "Date" field
  4. Set the "Draft/Final" field to "Final"
  5. Validate a message indicating "Dictionary" field is required and is not populated
  6. Click [OK]
  7. Validate the "Draft/Final" field is set back to "Draft"
  8. Populate the "Scrolling Text" field
  9. Populate the "Client Picture" field
  10. Set the "Draft/Final" field to "Final"
  11. Validate a message indicating "Dictionary" field is required and is not populated
  12. Click [OK]
  13. Validate the "Draft/Final" field is set back to "Draft"
  14. Populate the "Dictionary" field
  15. Set the "Draft/Final" field to "Final"
  16. Validate there are no messages
  17. Click [Submit]
  18. Validate the form files successfully
  19. Return to [FormA] and select [ClientA]
  20. Edit the row just submitted
  21. Validate all fields are populated, as expected
Client Header- client "Age" value
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Discharge
  • Update Client Data
Scenario 1: "Client Header" validation
Specific Setup:
  • Have a testing client [ClientA] with two episodes.
  • Episode "1" is an open episode
  • Episode "2" is a discharged episode
  • Have Registry Setting "Add Date of Death and Reason for Death to Discharge" Set this to "Yes"
  • In PM "Dictionary Update", select the "Client" database and search for dictionary "970"(Type of Discharge)
  • Edit dictionary code "3 (Death)" and click to the extended attribute section
  • In the "Extended Dictionary Element" field, select "Discharge Due to Death?" and ensure its set to "Yes"
  • In form "Client Lookup/Header Configuration" go to the "Client Header" section:
  • Have fields "Location", "Attending Practitioner", "Admitting Practitioner" included as part of the Client Header.
Steps
  1. Select [ClientA]
  2. Open the " Discharge" form and select the discharged Episode "2"
  3. Ensure "Date of Death" and "Reason for Death" are present, initially not required and disabled.
  4. Change "Type of Discharge" to "Death"
  5. Validate "Date of Death" and "Reason for Death" enable.
  6. Enter a "Date of Death"
  7. Enter a "Reason for Death"
  8. Submit the form
  9. Select [ClientA]
  10. Select episode "1" in the "Episodes" drop down list on the home view
  11. Right-click on the client to open "Chart"
  12. Validate the calculated "Age" value displayed in the client header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  13. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  14. Close the "Chart"
  15. Select episode "2" in the "Episodes" drop down list on the home view
  16. Right-click on the client to open "Chart"
  17. Validate the calculated "Age" value displayed in the client header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  18. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  19. Close the "Chart"
  20. For [ClientA] open the non-episodic form
  21. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth".
  22. Validate fields "Location", "Program", "Attending Practitioner" are 'not' populated as expected in client header, since this is an episodic form
  23. For [ClientA] open the "episodic" form for open episode, episode "1"
  24. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  25. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  26. For [ClientA] open the "episodic" form for discharged episode, episode "2"
  27. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  28. Validate fields "Location", "Program", "Attending Practitioner", are populated as expected in client header, since this is an episodic form

Topics
• File Import • NX • 835 • 835 Health Care Claim Payment/Advice • 837 Institutional • 837 Professional • About... • Accounts Receivable Management • Accu-Chek • Service Documentation • Client Banner • Discharge
Update 53 Summary | Details
RADplus - Diagnosis Search
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • SOAPUI - FileClientChargeInputICD10
  • SOAPUI - AddClientAlert
  • Diagnosis
Scenario 1: Enrollment Diagnosis - add/edit a diagnosis record
Specific Setup:
  • The 'Avatar PM->Episode Management->Movement Options->->Enable Enrollments' registry setting is enabled.
  • Programs must be defined as Enrollment Programs in the 'Program Maintenance' form.
  • Client must be admitted to an active episode (Client A).
Steps
  1. Select "Client A" and access the 'Enrollment Diagnosis' form.
  2. Select the desired enrollment in the 'Enrollment Number' field.
  3. Enter the desired date in the 'Date of Diagnosis' field.
  4. Enter the desired time in the 'Time of Diagnosis' field.
  5. Click [New Row].
  6. Select the desired value in the 'Diagnosis Search' field.
  7. Select "Active" in the 'Status' field.
  8. Enter the desired date in the 'Estimated Onset Date' field.
  9. Select "Primary" in the 'Ranking' field.
  10. Enter the desired practitioner in the 'Diagnosis Practitioner' field.
  11. Click [Submit].
  12. Validate a message displays stating: Do you want to return to Pre-Display?
  13. Click [Yes].
  14. Validate the Pre-Display is displayed and contains the diagnosis record added in the previous steps.
  15. Select the diagnosis record added in the previous steps and click [Edit].
  16. Click [New Row].
  17. Select the desired value in the 'Diagnosis Search' field.
  18. Select "Active" in the 'Status' field.
  19. Enter the desired date in the 'Estimated Onset Date' field.
  20. Select "Secondary" in the 'Ranking' field.
  21. Enter the desired practitioner in the 'Diagnosis Practitioner' field.
  22. Click [Submit].
  23. Validate a message displays stating: Do you want to return to Pre-Display?
  24. Click [No].
Scenario 2: File Import - Client Charge Input with Diagnosis ICD10
Specific Setup:
  • Sample import file with the ICD Diagnosis Code 1, ICD Diagnosis Code 2, ICD Diagnosis Code 3, ICD Diagnosis Code 4 populated (fields 54-57 of the import file).
Steps
  1. Open the "File Import" form.
  2. Select "File Type" of "Client Charge Input".
  3. Upload, Compile/Validate and Post the sample file.
  4. Open the "Client Ledger" form.
  5. Validate that a charge was generated by the File Import.
Scenario 3: Docked/Undocked Diagnosis form - Validate Add Multiple Search
Specific Setup:
  • Client must be enrolled in an active episode (Client A).
  • Registry setting: Avatar PM->Client Information->Diagnosis->->->Enable Multiple Diagnosis Search must be set to "Yes"
Steps
  1. Select 'Client A' from the 'My Clients' list and navigate to the 'Diagnosis' form.
  2. Click [Undock].
  3. Select “Admission” in "Type of Diagnosis".
  4. Validate that "Date Of Diagnosis" is auto-filled with admission date.
  5. Set the "Time of Diagnosis" field to any time.
  6. Click [New Row].
  7. Set "Diagnosis Search" to any diagnosis.
  8. Validate that the multiple diagnosis search screen displays as expected.
  9. Select a diagnosis from the search list.
  10. Validate that "Status" is “Active”.
  11. Validate that "Ranking" is “Primary”.
  12. Validate that "Bill Order" is “1”.
  13. Validate that “Present On Admission Indicator” is “Yes”.
  14. Select any value from the "Classification" drop down list field.
  15. Select any practitioner from the "Diagnosing Practitioner" field.
  16. Click [Submit].
  17. Select 'Client A' from the 'My Clients' list and navigate to the 'Diagnosis' form (docked).
  18. Click [Edit]
  19. Select the previously filed Diagnosis record.
  20. Validate that the diagnosis data appears as expected.
  21. Navigate to another view or open a form.
  22. Navigate back to the 'Diagnosis' form and validate that all data appears as expected in the Diagnosis grid.
  23. Click [Discard].
Scenario 4: Diagnosis - Diagnosis Entry
Specific Setup:
  • Client must be enrolled in an active episode and have a diagnosis on file (Client A).
Steps
  1. Select "Client A" and access the ‘Diagnosis’ form.
  2. Select the diagnosis row to edit.
  3. Click [Edit].
  4. Click [New Row].
  5. Search for and select the desired value in the 'Diagnosis Search' field.
  6. Validate the 'Diagnosis Search' returns the expected diagnoses.
  7. Populate all required and desired fields.
  8. Click [Submit] and [No].
  9. Select "Client A" and access the 'Diagnosis' form.
  10. Select the diagnosis row edited in the previous steps.
  11. Click [Edit].
  12. Validate the newly added diagnosis row is displayed.
  13. Close the form.
Scenario 5: Validate the 'RADplus->IMO Diagnosis Web Service->ICD-10 Diagnosis Search->->->URL' registry setting
Specific Setup:
  • A client is enrolled in an existing episode (Client A).
Steps
  1. Access the 'Registry Settings' form.
  2. Search for and select the "RADplus->IMO Diagnosis Web Service->ICD-10 Diagnosis Search->->->URL" registry setting.
  3. Validate the 'Registry Setting Details' field contains "Enter or update the URL for the ICD-10 Diagnosis code web search. Please note: If the 'Avatar CareFabric' module is loaded and enabled (requires Avatar CareFabric 2018 Update #22 and Avatar CareFabric 2022 Update #62) then the SDK based services will be used."
  4. Close the form.
  5. Select "Client A" and access the 'Diagnosis' form.
  6. Click [Add] to add a new record.
  7. Select the desired value in the 'Type Of Diagnosis' field.
  8. Enter the desired date in the 'Date Of Diagnosis' field.
  9. Enter the desired time in the 'Time Of Diagnosis' field.
  10. Click [New Row].
  11. Search for and select the desired diagnosis in the 'Diagnosis Search' field.
  12. Validate the 'Diagnosis Search' returns the expected diagnoses.
  13. Select the desired practitioner in the 'Diagnosing Practitioner' field.
  14. Populate any other desired fields.
  15. Click [Submit] and [Yes] to return to the pre-display.
  16. Validate the pre-display contains the diagnosis filed in the previous steps.
  17. Select the new diagnosis record and click [Edit].
  18. Validate all previously filed diagnosis data is displayed.
  19. Close the form.

Topics
• Diagnosis • Registry Settings
Update 56 Summary | Details
Client Merge - Event log entries
Scenario 1: Client Merge (Create New Episode On Merge) - Validate "SYSTEM.RADplus_event_log" table entries
Specific Setup:
  • Have two clients on the system [ClientA] is identified as the "Target" client for the client merge and [ClientB] is identified as the "Source" client for the merge
  • [ClientA] is admitted in [Episode1], [ProgramA] on [DateA]
  • [ClientB] is admitted in [Episode1], [ProgramA] on a later date [DateB]
  • A row [RowA] has been filed in [FormA], for [ClientA] on [DateA]
  • A row [RowB] has been filed in [FormA], for [ClientB] on [DateB]
  • Have registry setting "Allow Merging of All Client Data Through Single Filing" set to "Yes"
  • Have registry setting "Allow Merging Into Existing Episode" set to "No"
  • Have access to a database program and table permissions to run an "SQL" query on the "SYSTEM.RADplus_event_log" table
Steps
  1. Open the 'Client Merge' form.
  2. Enter [ClientB] in the 'Source Client' field.
  3. Select "Yes" in the 'Merge All Client Data Through Single Filing' field.
  4. Enter [ClientA] in the 'Target Client' field.
  5. Select "No" in the 'Create New Episode On Merge' field.
  6. Click [File].
  7. Validate a "Client Merge" message is displayed stating: Do you wish to continue with the indicated action?
  8. Click [Yes].
  9. Validate a "Client Merge" message is displayed stating: All information has been merged into the target client and the source client has been deleted from the system.
  10. Click [OK].
  11. Close the form.
  12. At the home view, search for [ClientB] in the "Search Clients" field
  13. Validate [ClientA] is not found
  14. At the home view, search for [ClientA] in the "Search Clients" field
  15. Open [FormA]
  16. Validate there are now two episodes displayed [EpisodeA] and [EpisodeB]
  17. Select [EpisodeB]
  18. Validate the merged row [RowB] from [ClientB] on [DateB] is displayed for selection, as expected
  19. Select [RowB]
  20. Validate data is displayed as expected
  21. Close the form
  22. Run the following SQL Query for [ClientB]: "SELECT ID, application, entity_database_code, entity_id, EPISODE_NUMBER, event_date,event_time, event_type, system_code, USERID FROM SYSTEM.RADplus_event_log WHERE FACILITY = [applicable Facility number associated to logged in System Code] AND entity_id = [ClientB]"
  23. Validate the results first include two entries, "Entry Copied" and "Entry Deleted" for client merge transaction process itself. Then following that, the "Data Copied" and an "Entry Deleted" records for [Row1], which was merged from [ClientB] to [ClientA]
  24. For example:

ID......... Application..EntityType..............EntityID.Epis. .EventDate/Time..........Event Type

507937.. Avatar PM. PATIENT... ............602.......1. ........8/12/2022..2:30 PM.....Data Copied

507939.. Avatar PM. PATIENT................602.......1..........8/12/2022..2:31 PM.....Entry Deleted

507942.. Avatar PM. USER_DEFINED....602.......1..........8/12/2022..2:31 PM.....Data Copied

507943.. Avatar PM. USER_DEFINED....602 ......1..........8/12/2022..2:31 PM.....Entry Deleted

Scenario 2: Client Merge (Merge Into Existing Episode) - Validate "SYSTEM.RADplus_event_log" table entries
Specific Setup:
  • Have two clients on the system [ClientA] is identified as the "Target" client for the client merge and [ClientB] is identified as the "Source" client for the merge
  • [ClientA] is admitted in [Episode1], [ProgramA] on [DateA]
  • [ClientB] is admitted in [Episode1], [ProgramA] on a later date [DateB]
  • A row [RowA] has been filed in [FormA], for [ClientA] on [DateA]
  • A row [RowB] has been filed in [FormA], for [ClientB] on [DateB]
  • Have registry setting "Allow Merging of All Client Data Through Single Filing" set to "Yes"
  • Have registry setting "Allow Merging Into Existing Episode" set to "Yes"
  • Have access to a database program and table permissions to run an "SQL" query on the "SYSTEM.RADplus_event_log" table
Steps
  1. Open the 'Client Merge' form.
  2. Enter [ClientB] in the 'Source Client' field.
  3. Select "Yes" in the 'Merge All Client Data Through Single Filing' field.
  4. Enter [ClientA] in the 'Target Client' field.
  5. Select "No" in the 'Create New Episode On Merge' field.
  6. Click [File].
  7. Validate a "Client Merge" message is displayed stating: Do you wish to continue with the indicated action?
  8. Click [Yes].
  9. Validate a "Client Merge" message is displayed stating: All information has been merged into the target client and the source client has been deleted from the system.
  10. Click [OK].
  11. Close the form.
  12. At the home view, search for [ClientB] in the "Search Clients" field
  13. Validate [ClientA] is not found
  14. At the home view, search for [ClientA] in the "Search Clients" field
  15. Open [FormA]
  16. Select [EpisodeA]
  17. Validate the data for row [RowA] field for [ClientA] on [DateA] is displayed for selection
  18. Validate the merged row [RowB] from [ClientB] on [DateB] is also displayed for selection, as expected
  19. Select [RowB] for edit
  20. Validate date is filed as expected
  21. Close the form
  22. Run the following SQL Query for [ClientB]: "SELECT ID, application, entity_database_code, entity_id, EPISODE_NUMBER, event_date,event_time, event_type, system_code, USERID FROM SYSTEM.RADplus_event_log WHERE FACILITY = [applicable Facility number associated to logged in System Code] AND entity_id = [ClientB]"
  23. Validate the results first include two entries, "Entry Copied" and "Entry Deleted" for client merge transaction process itself. Then following that, the "Data Copied" and an "Entry Deleted" records for [Row1], which was merged from [ClientB] to [ClientA]
  24. For example:

ID......... Application..EntityType..............EntityID.Epis. .EventDate/Time..........Event Type

507937.. Avatar PM. PATIENT... ............602.......1. ........8/12/2022..2:30 PM.....Data Copied

507939.. Avatar PM. PATIENT................602.......1..........8/12/2022..2:31 PM.....Entry Deleted

507942.. Avatar PM. USER_DEFINED....602.......1..........8/12/2022..2:31 PM.....Data Copied

507943.. Avatar PM. USER_DEFINED....602 ......1..........8/12/2022..2:31 PM.....Entry Deleted


Topics
• Client Merge • NX
Update 68 Summary | Details
Widget Definition - Enhanced widget functionality
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Widget Definition (PM)
  • Dynamic Form - Widget Definition - Select Widgets
  • NX Enhanced View Widget
Scenario 1: Avatar NX - Validate "Enhanced" widget view UI Functionality
Specific Setup:
  • In form "Widget Definition" have a 'Multiple Row SQL' widget defined [WidgetA] with the 'Enhanced Widget View' field set to "Yes"
  • Have [WidgetA] placed on a users home view [UserA]
  • Log in as [UserA]
Steps
  1. Click to "Refresh" [WidgetA]
  2. Validate the columns display data as expected and the columns are not sorted
  3. Locate a desired column [ColumnA], in the widget
  4. Click column header name once
  5. Validate the "Up" arrow icon is highlighted and data in the column is sorted in ascending order
  6. Click column header a second time
  7. Validate the "Down" arrow icon is highlighted and data in the column is sorted in descending order
  8. Click column header a third time
  9. Validate the "Up" and "Down" arrows are no longer highlighted and data is no longer sorted in the column
  10. Holding the "Shift" key, select [ColumnA] and click the column header name once to sort it in ascending order
  11. While still holding the 'Shift' key, select another column [ColumnB] and click the column header name twice to sort it in descending order
  12. Validate widget data results are sorted by [ColumnA] in ascending order and then by [ColumnB] in descending order, as expected
  13. Select any column in the widget, for example [ColumnA] which for this test is "Client ID #"
  14. In the search input box below the column name type in search criteria, for example "4"
  15. Validate the list is filtered and displays only clients whose client ID contains a "4"
  16. Click in the input box and clear the search criteria entered
  17. Validate the list is refreshed and displays all results in column again
  18. Click the line between [ColumnA] and [ColumnB] and drag the line to the left in order to reduce the size of [ColumnA]
  19. Validate the width of the column is reduced, as expected
  20. Click the line between [ColumnA] and [ColumnB] drag the line to the right in order to increase the size of [ColumnA]
  21. Validate the width of the column is increased as expected
  22. Repeat steps 1 thru 4 sorting, filtering and resizing any desired columns
  23. Click the "Refresh" button in the widget
  24. Validate all sorting, filtering and resizing results remain
  25. Log out as the same user and log back in using the same browser session
  26. Validate all sorting, filtering and resizing results have remained the same as before the user logged out
  27. Log out as the same user and close the browser session
  28. Open a new browser session and log back in
  29. Validate all sorting, filtering and resizing set prior to logging out, has been removed

Topics
• NX
Update 77 Summary | Details
Progress Note - Console widget
Scenario 1: Validate "Console" widget column data
Specific Setup:
  • Have a progress note "Console" widget [WidgetA] created in form "Console Widget Configuration" for any form [FormA]. For example, the "Individual Progress Notes" form.
  • Include the following fields columns among the those selected to display in the widget, 'Practitioner ', 'Service Charge Code 'Date of Service', 'Service Program' and 'Draft/Final'
  • Have [WidgetA] and the "Console Widget Viewer" widget placed on the home view a user [UserA]
  • Log in as [UserA]
Steps
  1. Open [FormA]
  2. Select [ClientA]
  3. Click to add a new row
  4. In the "Progress Note For" field select "New Service"
  5. Populate all required fields, including, 'Practitioner ', 'Service Charge Code', 'Date of Service' and 'Service Program'
  6. Select "Draft" in the "Draft/Final" field
  7. Submit the form
  8. Validate the form files successfully
  9. Click the [WidgetA] refresh button
  10. Validate the "Draft/Final" column contains "Draft", as expected
  11. Validate all columns are populated as expected, including the 'Practitioner', 'Service Charge Code', 'Date of Service' and 'Service Program'
  12. Re-open [FormA] for [ClientA]
  13. In the 'Select Draft Note to Edit" field, select the row filed in Step 1
  14. Set the "Draft/Final" field to "Final"
  15. Submit the form
  16. Validate the form files successfully
  17. Click the [WidgetA] refresh button
  18. Validate the "Draft/Final" column contains "Final", as expected
  19. Validate all columns are populated as expected, including the 'Practitioner', 'Service Charge Code', 'Date of Service' and 'Service Program'
  20. Click the [View]
  21. In the "Console Widget Viewer" widget,
  22. Validate the "Draft/Final" column displays "Final", as expected
  23. Validate all other field values are displayed as expected, including the 'Practitioner', 'Service Charge Code', 'Date of Service' and 'Service Program' fields

Topics
• Console Widget • Console Widget Configuration • NX
Update 78 Summary | Details
RADplus - Support for future functionality
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Definition
Scenario 1: Scheduling Calendar - Validate user defined time zones
Specific Setup:
  • The Avatar system being used for testing is in Eastern Standard time zone.
  • Logged in user does not have a user defined time zone in 'User Definition' (User A).
Steps
  1. Access the 'Scheduling Calendar' form.
  2. Select "Day" in the 'View' field.
  3. Validate there is only one time column on the left-hand side for the system time in Eastern Standard Time.
  4. Select "Week" in the 'View' field.
  5. Validate there is only one time column on the left-hand side for the system time in Eastern Standard Time.
  6. Click [Dismiss].
  7. Access the 'User Definition' form.
  8. Select "User A" in the 'Select User' field.
  9. Select the "Appointment Scheduling" section.
  10. Select "Pacific/Honolulu" in the 'Time Zone' field.
  11. Click [Submit].
  12. Access the 'Scheduling Calendar' form.
  13. Select "Day" in the 'View' field.
  14. Validate there is now two time columns on the left-hand side: one for the system time in Eastern Standard Time and one for the user defined time zone for Pacific/Hawaii Time.
  15. Select "Week" in the 'View' field.
  16. Validate there is now two time columns on the left-hand side: one for the system time in Eastern Standard Time and one for the user defined time zone for Pacific/Hawaii Time.
  17. Click [Dismiss].
  18. Access the 'User Definition' form.
  19. Select "User A" in the 'Select User' field.
  20. Select the "Appointment Scheduling" section.
  21. Remove the value in the 'Time Zone' field.
  22. Click [Submit].
  23. Access the 'Scheduling Calendar' form.
  24. Select "Day" in the 'View' field.
  25. Validate there is only one time column on the left-hand side for the system time in Eastern Standard Time.
  26. Select "Week" in the 'View' field.
  27. Validate there is only one time column on the left-hand side for the system time in Eastern Standard Time.
  28. Click [Dismiss].

Topics
• Scheduling Calendar • User Definition
Update 88 Summary | Details
RADplus - Support for future functionality
Scenario 1: Current Database Locks - viewing current locks in the database
Steps
  1. Access the 'Current Database Locks' form.
  2. Click [Update Display].
  3. Validate the 'Current Database Locks' field contains any current locks.
  4. Click [Print].
  5. Validate a 'Current Database Locks' report is displayed.
  6. Validate that any current locks are displayed.
  7. Click [Dismiss] and close the form.
Scenario 2: Validate undocked 'Progress Notes (Group and Individual)'
Specific Setup:
  • A client is enrolled in an existing episode (Client A).
Steps
  1. Access the undocked 'Progress Notes (Group and Individual)' form.
  2. Select "Client A" in the 'Select Client' field.
  3. Select the desired episode in the 'Select Episode' field.
  4. Select the desired value in the 'Progress Note For' field.
  5. Leave the undocked window open.
  6. Access the 'Current Database Locks' form.
  7. Validate the 'Current Database Locks' field contains a lock for the progress note opened.
  8. Leave the form open.
  9. Navigate back to the undocked 'Progress Notes (Group and Individual)' form.
  10. Click [X] in the upper right corner.
  11. Validate the undocked window is closed.
  12. Navigate back to the 'Current Database Locks' form.
  13. Click [Update Display].
  14. Validate the 'Current Database Locks' field no longer contains a lock for the progress note.
  15. Click [Discard].
  16. Access the 'Progress Notes (Group and Individual)' form.
  17. Select "Client A" in the 'Select Client' field.
  18. Select the desired episode in the 'Select Episode' field.
  19. Select the desired value in the 'Progress Note For' field.
  20. Populate all other required and desired fields.
  21. File the note.
  22. Validate the note files successfully.
Scenario 3: Validate various undocked forms open & close as expected
Specific Setup:
  • User must have access to the 'Admission', 'Pre Admit', 'Scheduling Calendar', 'Individual Progress Note', and 'Ambulatory Progress Notes' form in the 'User Definition' form.
Steps
  1. Access the undocked 'Admission' form.
  2. Validate the undocked 'Admission' form pre-display opens.
  3. Click [Cancel].
  4. Validate the undocked 'Admission' form closes and user is brought back to the myDay view.
  5. Access the undocked 'Pre Admit' form.
  6. Validate the undocked 'Pre Admit' form pre-display opens.
  7. Click [Cancel].
  8. Validate the undocked 'Pre Admit' form closes and user is brought back to the myDay view.
  9. Access the undocked 'Individual Progress Note' form.
  10. Validate the undocked 'Individual Progress Note' form opens.
  11. Click [Discard].
  12. Validate the undocked 'Individual Progress Note' form closes and user is brought back to the myDay view.
  13. Access the undocked 'Scheduling Calendar' form.
  14. Validate the undocked 'Scheduling Calendar' form opens.
  15. Click [Dismiss].
  16. Validate the undocked 'Scheduling Calendar' form closes and user is brought back to the myDay view.
  17. Access the undocked 'User Role Definition' form.
  18. Validate the undocked 'User Role Definition' form opens.
  19. Click [Select User Role].
  20. Select any value from the 'Select one of the following' field.
  21. Click [OK].
  22. Make the desired changes and click [Submit].
  23. Validate a 'Form Return' dialog stating: "User Role Definition has completed. Do you wish to return to form?"
  24. Click [No].
  25. Validate the undocked 'User Role Definition' form closes and user is brought back to the myDay view.
  26. Access the undocked 'Individual Progress Note' form.
  27. Validate the undocked 'Individual Progress Note' form opens.
  28. Access the undocked 'Ambulatory Progress Notes' form.
  29. Validate the undocked 'Ambulatory Progress Notes' form opens.
  30. Switch to the 'Individual Progress Note' window and click [Discard].
  31. Validate the undocked 'Individual Progress Note' form closes.
  32. Switch to the 'Ambulatory Progress Notes' window and click [Cancel].
  33. Validate the undocked 'Ambulatory Progress Notes' form closes and user is brought back to the myDay view.
  34. Access the 'Admission' form.
  35. Validate the 'Admission' form pre-display opens.
  36. Click [Cancel].
  37. Validate the 'Admission' form closes and user is brought back to the myDay view.
Scenario 4: Validate record locks are cleared in NX after X minutes
Steps

Internal Testing Only.


Topics
• NX • RADplus Utilities
Update 95 Summary | Details
POVClinician - "Site Specific" forms
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Patient Health Questionnaire-9
Scenario 1: "Patient Health Questionnaire-9" form - Validate data after Clinician<>Avatar data synchronization
Specific Setup:
  • In Avatar, file a [RowA] for [ClientA] in form ""Patient Health Questionnaire-A" form" with field "Assessment Date" populated with a date less than or equal to current date [DateA]
  • In Avatar, file another [RowB] for [ClientA] in form ""Patient Health Questionnaire-A" form" with field "Assessment Date" populated with any future date [DateB]
  • The "Patient Health Questionnaire-9" form is marked for inclusion in form "Mobile Application Build"
Steps
  1. Log into "Clinician"
  2. Click [Synchronize] to sync data with Avatar
  3. Validate synchronization is successful
  4. Select [ClientA]
  5. Open the "Patient Health Questionnaire-9" form
  6. Validate the form launches successfully
  7. Validate in the pre-display, [RowA] is displayed
  8. Select the row and click [Edit]
  9. Validate "Assessment Date" is populated as expected with [DateA]
  10. Validate all other fields are populated as expected
  11. Add or update a value of any field [FieldA] and make a note of the change
  12. Submit the form
  13. Validate the form files successfully
  14. Open the "Patient Health Questionnaire-9" form
  15. Validate the form launches successfully
  16. Validate in the pre-display, [RowB] is displayed
  17. Select the row and click [Edit]
  18. Validate "Assessment Date" is populated as expected with [DateB]
  19. Validate all other fields are populated as expected
  20. Add or update a value of any field [FieldB] and make a note of the change
  21. Submit the form
  22. Validate the form files successfully
  23. Click [Synchronize] to sync data with Avatar
  24. Validate synchronization is successful
  25. Log into Avatar
  26. Select [ClientA]
  27. Open the "Patient Health Questionnaire-9" form
  28. In the pre-display, select [RowA] for edit
  29. Validate [FieldA] updated in step 1b, is populated as expected
  30. Close the form
  31. Open the "Patient Health Questionnaire-9" form
  32. In the pre-display, select [RowB] for edit
  33. Validate [FieldB] updated in step 1b, is populated as expected
  34. Close the form
Scenario 2: Treatment Plan - Validate data after Clinician<>Avatar data synchronization
Specific Setup:
  • In Avatar, file a [RowA] for [ClientA] in form "Treatment Plan" form with field "Plan Date" populated with a date less than or equal to the current date
  • In Avatar, file another [RowB] for [ClientA] in form "Treatment Plan" form with field "Plan Date" populated with any future date
  • Have the "Treatment Plan" form marked for inclusion in form "Mobile Application Build"
Steps
  1. Log into "Clinician"
  2. Click [Synchronize] to sync data with Avatar
  3. Select [ClientA]
  4. Open the "Treatment Plan" form
  5. Validate the form launches successfully
  6. Validate in the pre-display, [RowA] is displayed
  7. Select the row and click [Edit]
  8. Validate "Plan Date" is populated as expected with [DateA]
  9. Validate all other fields are populated as expected
  10. Add or update a value of any field [FieldA] and make a note of the change
  11. Submit the form
  12. Validate the form files successfully
  13. Open the "Treatment Plan" form
  14. Validate the form launches successfully
  15. Validate in the pre-display, [RowB] is displayed
  16. Select the row and click [Edit]
  17. Validate "Plan" is populated as expected with [DateB]
  18. Validate all other fields are populated as expected
  19. Add or update a value of any field [FieldB] and make a note of the change
  20. Submit the form
  21. Validate the form files successfully
  22. Log into Avatar
  23. Select [ClientA]
  24. Open the "Treatment Plan" form
  25. In the pre-display, select [RowA] for edit
  26. Validate [FieldA] updated in step 1b, is populated as expected
  27. Close the form
  28. Open the " "Treatment Plan" form
  29. In the pre-display, select [RowB] for edit
  30. Validate [FieldB] updated in step 1b, is populated as expected
  31. Close the form
Scenario 3: Progress Notes - Validate data after Clinician<>Avatar data synchronization
Specific Setup:
  • In Avatar, file a [RowA] for [ClientA] in any "Progress Note" form" for a "New Service" with the "Date Of Service" field populated with the current date
  • Have the "Progress Note" form marked for inclusion in form "Mobile Application Build"
Steps
  1. Log into Avatar
  2. Select [ClientA]
  3. Open the "Progress Note" form
  4. Click [Add] to add a new row [RowB]
  5. in the "Progress Note For" field, select "New Service"
  6. Set the "Date of Service" field to a future date
  7. Validate an error is displayed "Future Dates Not Permitted"
  8. Click [OK]
  9. Enter today's date
  10. Validate entry is permitted
  11. Enter a date prior to the current date
  12. Validate entry is permitted
  13. Populate all other required and desired fields
  14. Submit the form
  15. Validate the form files successfully
  16. Log into "Clinician"
  17. Click [Synchronize] to sync data with Avatar
  18. Select [ClientA]
  19. Open the "Progress Note" form
  20. Validate the form launches successfully
  21. Validate in the pre-display, [RowA] is displayed
  22. Select the row and click [Edit]
  23. Validate "Plan Date" is populated as expected with [DateA]
  24. Validate all other fields are populated as expected
  25. Add or update a value in any field [FieldA] and make a note of the change
  26. Submit the form
  27. Validate the form files successfully
  28. Open the "Progress Note" form
  29. Validate the form launches successfully
  30. Validate in the pre-display, [RowB] is displayed
  31. Select the row and click [Edit]
  32. Validate "Plan" is populated as expected with [DateB]
  33. Validate all other fields are populated as expected
  34. Add or update a value in any field [FieldB] and make a note of the change
  35. Submit the form
  36. Validate the form files successfully
  37. In Avatar
  38. Select [ClientA]
  39. Open the "Progress Note" form
  40. In the pre-display, select [RowA] for edit
  41. Validate [FieldA] updated in step 1b, is populated as expected
  42. Close the form
  43. Open the "Progress Note" form
  44. In the pre-display, select [RowB] for edit
  45. Validate [FieldB] updated in step 1b, is populated as expected
  46. Close the form


Topics
• NX • Patient Health Questionnaire-9 • Progress Notes • Site Specific Section Modeling • Treatment Plan
Update 97 Summary | Details
The 'Allow Users Access To All Forms on NX 'All Documents' Widget' registry setting
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 - Validate user access levels
Specific Setup:
  • A client must be enrolled in an existing episode (Client A).
  • There must be three users:
  • A user who has full access to forms and is logged in (User A)
  • A user who has read-only access to the 'Progress Notes (Group and Individual)' and 'Treatment Plan' forms (User B).
  • A user who doesn't have access to the 'Progress Notes (Group and Individual)' and 'Treatment Plan' forms (User C).
  • 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).
  • Document routing must be enabled for the 'Progress Notes (Group and Individual)' and 'Treatment Plan' forms.
  • The 'Allow Users Access To All Forms on NX 'All Documents' Widget' registry setting must be set to "N".
  • Please note: this scenario is for Avatar NX systems.
Steps
  1. Select "Client A" and access the 'Progress Notes (Group and Individual)' form.
  2. Select any value in the 'Progress Note For' field.
  3. Populate all required and desired fields.
  4. Select "Final" in the 'Draft/Final' field.
  5. Click [Submit Note].
  6. Validate a 'Confirm Document' dialog displays the progress note from the previous steps and click [Sign].
  7. Enter the password associated with the logged in user and click [Verify].
  8. Close the form.
  9. Navigate to the 'All Documents' view.
  10. Select 'All Forms'.
  11. Select "Progress Notes (Group and Individual)" in the 'Form Description' field.
  12. Validate the time and staff credentials display.
  13. Validate the progress note from the previous steps is present and select it.
  14. Validate the note displays in the 'Console Widget Viewer'.
  15. Validate the 'Open' and 'Open Record' buttons are enabled.
  16. Access the 'Treatment Plan' form.
  17. Enter the desired date in the 'Plan Date' field.
  18. Populate all required and desired fields.
  19. Select "Draft" in the 'Treatment Plan Status' field.
  20. Click [Launch Plan].
  21. Populate all required and desired fields.
  22. Click [Return to Plan] and [OK].
  23. Select "Final" in the 'Treatment Plan Status' field.
  24. Click [Submit].
  25. Validate a 'Confirm Document' dialog displays the progress note from the previous steps and click [Sign].
  26. Enter the password associated with the logged in user and click [Verify].
  27. Navigate to the 'All Documents' view.
  28. Select 'All Forms'.
  29. Select "Treatment Plan" in the 'Form Description' field.
  30. Validate the treatment plan from the previous steps is present and select it.
  31. Validate the plan displays in the 'Console Widget Viewer'.
  32. Validate the 'Open' and 'Open Record' buttons are enabled.
  33. Validate the 'Launch Report' button exists.
  34. Click [Launch Report].
  35. Validate a report displays with the information filed in the previous steps.
  36. Close the report.
  37. Log out.
  38. Login as "User B".
  39. Select "Client A" and navigate to the 'All Documents' view.
  40. Select 'All Forms'.
  41. Select "Progress Notes (Group and Individual)" in the 'Form Description' field.
  42. Validate the progress note from the previous steps is present and select it.
  43. Validate the note displays in the 'Console Widget Viewer'.
  44. Validate the 'Open' and 'Open Record' buttons are disabled.
  45. Select "Treatment Plan" in the 'Form Description' field.
  46. Validate the treatment plan from the previous steps is present and select it.
  47. Validate the plan displays in the 'Console Widget Viewer'.
  48. Validate the 'Open' and 'Open Record' buttons are disabled.
  49. Validate the 'Launch Report' button exists.
  50. Click [Launch Report].
  51. Validate a report displays with the information filed in the previous steps.
  52. Close the report.
  53. Log out.
  54. Login as "User C".
  55. Select "Client A" and navigate to the 'All Documents' view.
  56. Validate "Progress Notes (Group and Individual)" and "Treatment Plan" and not present in the 'Form Description' field.
  57. Access the 'Registry Settings' form.
  58. Enter "allow users access to all" in the 'Limit Registry Settings to the Following Search Criteria' field.
  59. Click [View Registry Settings].
  60. Select "Allow Users Access to All Forms on NX 'All Documents' Widget Registry Setting" from the 'Registry Settings' field.
  61. Click [OK].
  62. Enter "Y" in the 'Registry Setting Value' field.
  63. Click [Submit].
  64. Validate a 'Registry Editor Filing' dialog.
  65. Click [OK] and [No].
  66. Navigate to the 'All Documents' view.
  67. Refresh the 'All Documents' widget.
  68. Select 'All Forms'.
  69. Select "Progress Notes (Group and Individual)" in the 'Form Description' field.
  70. Validate the progress note from the previous steps is present and select it.
  71. Validate the note displays in the 'Console Widget Viewer'.
  72. Validate the 'Open' and 'Open Record' buttons are disabled.
  73. Click [Clear Filters].
  74. Select "Treatment Plan" in the 'Form Description' field.
  75. Validate the treatment plan from the previous steps is present and select it.
  76. Validate the plan displays in the 'Console Widget Viewer'.
  77. Validate the 'Open' and 'Open Record' buttons are disabled.
Scenario 2: Clinical Document Viewer - Validate user access levels
Specific Setup:
  • A client has finalized documents for 'Progress Notes (Group and Individual)' (Client A).
  • There must be two users:
  • A user who has full access to forms and is logged in (User A).
  • A user who doesn't have access to the 'Progress Notes (Group and Individual)' form (User B).
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. Click [Close].
  12. Log out.
  13. Log in as "User B".
  14. Access the 'Clinical Document Viewer' form.
  15. Select "Individual" in the 'Select All or Individual Client' field.
  16. Enter "Client A" in the 'Select Client' field.
  17. Select "All" in the 'Episode' field.
  18. Click [Process].
  19. Validate the desired document has a lock next to it in the 'Search Results' field.
  20. Validate the user is unable to select and view the document.
  21. Navigate back to the "Search" section.
  22. Click [Close].
Scenario 3: Validate the 'Allow Users Access To All Forms on NX 'All Documents' Widget' registry setting
Specific Setup:
  • A client must be enrolled in an existing episode and has 'Progress Notes (Group and Individual)' and 'Treatment Plan' records on file (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).
  • A user who doesn't have access to the 'Progress Notes (Group and Individual)' and 'Treatment Plan' forms (User A).
  • Please note: this scenario is for Avatar NX systems.
Steps
  1. Log in as "User A".
  2. Access the 'Registry Settings' form.
  3. Enter "allow users access to all" in the 'Limit Registry Settings to the Following Search Criteria' field.
  4. Click [View Registry Settings].
  5. Validate the "Allow Users Access To All Forms on NX 'All Documents' Widget" registry setting is present.
  6. Select the registry setting and click [OK].
  7. Validate the 'Registry Setting Details' field contains "When set to 'Y', the user may view all forms on the Documentation View and 'All Documents' widget per the configuration of the 'All Documents' widget displayed, regardless of individual form access permissions configured in 'User Definition' or 'User Role Definition'. When set to 'N', the user's form access permissions will apply to the list of forms on the Documentation View, suppressing the forms to which the user does not have either read or read/write permission."
  8. Validate the 'Registry Setting Value' field contains "N".
  9. Click [Submit], [OK], and [No].
  10. Select "Client A" and navigate to the 'All Documents' view.
  11. Select 'All Forms'.
  12. Validate "Progress Notes (Group and Individual)" and "Treatment Plan" and not present in the 'Form Description' field.
  13. Access the 'Registry Settings' form.
  14. Enter "allow users access to all" in the 'Limit Registry Settings to the Following Search Criteria' field.
  15. Click [View Registry Settings].
  16. Select the "Allow Users Access To All Forms on NX 'All Documents' Widget" registry setting and click [OK].
  17. Enter "Y" in the 'Registry Setting Value' field.
  18. Click [Submit].
  19. Validate a 'Registry Editor Filing' dialog.
  20. Click [OK] and [No].
  21. Navigate to the 'All Documents' view.
  22. Refresh the 'All Documents' widget.
  23. Select 'All Forms'.
  24. Select "Progress Notes (Group and Individual)" in the 'Form Description' field.
  25. Select a progress note and validate the note displays in the 'Console Widget Viewer'.
  26. Validate the 'Open' and 'Open Record' buttons are disabled.
  27. Click [Clear Filters].
  28. Select "Treatment Plan" in the 'Form Description' field.
  29. Select a treatment plan and validate the plan displays in the 'Console Widget Viewer'.
  30. Validate the 'Open' and 'Open Record' buttons are disabled.

Topics
• All Documents Widget • NX • Progress Notes • Progress Notes (Group And Individual) • Registry Settings • Treatment Plan
Update 102 Summary | Details
POV Clinician - (NIAM) Login
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Definition
  • Netsmart Identity and Access Management (NIAM) Login
Scenario 1: Clinician - Validate user login using "Netsmart Identity and Access Management (NIAM)" functionality
Specific Setup:
  • Have registry setting "Enable OpenID Connect Support" enabled in the system
  • The system has been configured for (NIAM) functionality with the appropriate settings configured in the "OpenID Connect Configuration" section of form "System Security Defaults"
  • An "(ODIC) Identity Provider" solution is enabled that will be used in conjunction with Avatar to authenticate a user set up as a "NAIM" user, for example provider "Okta"
  • The "(ODIC) Identity Provider" solution has been enabled for "MFA (Multi factor authentication)".
  • [UserA] is assigned an external login ID and password to login as "NIAM" user using the "(ODIC) Identity Provider" solution and their login is enabled for "MFA (Multi factor authentication)" in order to send a one time code to the user at the time of login, for authentication
  • [UserA] is configured in form "User Definition" with prompt "User External Login" set to "Yes" and field "External Login ID" populated with external login ID assigned by the "(ODIC) Identity Provider". This will be used as "Netsmart ID" during login.
Steps
  1. Launch the "Clinician" application
  2. Click [Login with Enterprise Credentials]
  3. Verify the "Netsmart Identity and Access Management" login page is displayed
  4. At the "Netsmart ID" field, populate the "Username" field with the user configured for [UserA]
  5. Click [Next]
  6. At the "Sign In" screen.
  7. Populate the "Username" field
  8. Populate the "Password" field
  9. Click [Sign In]
  10. At the "SMS Authentication" screen
  11. Click [Send Code]
  12. Enter the code received
  13. Click [Verify]
  14. Select any system code from the "Select System Code" field, if not already defaulted
  15. Populate the "Please re-enter password for local (disconnected state) encryption" field
  16. Click the [->]
  17. If applicable, the message "You haven't synced your device today. Performing a sync can prevent errors from occurring while using Clinician" will display.
  18. Click [Sync]
  19. Verify synchronization is successful
  20. At the home view, select a desired client [ClientA]
  21. Open any [FormA]
  22. Populate the form
  23. Click [Submit]
  24. Validate the form filed successfully
  25. Click [Synchronize]
  26. Verify synchronization is successful
  27. Log into "Avatar"
  28. Select [ClientA]
  29. Open [FormA]
  30. Select the row just submitted in Clinician
  31. Verify the form is populated as expected
Topics
• User Definition