RADplus 2023 Quarterly Release 2023.04 Acceptance Tests

Last updated
Save as PDF

Update 1 Summary \| Details Avatar PM 2023 is Installed Scenario 1: Validate Upgrading RADplus 2022 to 2023 is successful when 2022.04.00 is loaded Specific Setup: Latest Monthly Release is installed. Steps Open the "Product Updates" form. Select the appropriate [Namespace] from the Application dropdown list Click [Select Update/Customization Pack]. Browse to the location for the updates and select the Update 1. Click [OK] on the "File Upload Complete" window. Click [Review Update/Customization Pack Contents]. Verify Update 1 is included. Click [Install Update/Customization Pack]. Click [OK] when the install completes. Click [Close Form].	Topics • Upgrade
Update 2 Summary \| Details Append Document Scenario 1: Append Documents - Validate user permissions to append documents Specific Setup: Have a system with a [Root] system code and sub system code defined [TestSub] Sub system code [TestSub] has been assigned a specific program [ProgramA] [TestClient] is admitted in two episodes: [Episode1] to [ProgramA] [Episode2] to [ProgramB] [UserA] has access to both the [Root] system code and sub system code [TestSub] [UserB] has access only to the sub system code [TestSub] [FormA] has been submitted for [TestClient] in [Episode1] and a document has been generated [DocA] [FormB] has been submitted for [TestClient] in [Episode2] and a document has been generated [DocB] Log in as [UserB] into the [TestSub] sub system code Steps Open form "Append Documents" Select the applicable form type in the "Form Type" field Select [TestClient] in the "Entity" field Enter the applicable date range in the "From Date" and "To Date" fields Click the "List of Documents" field Validate the drop down list displays [Doc1] filed for [FormA] in [Episode1, ProgramA] Validate the drop down list does not display [Doc2] filed for [FormB] in [Episode2, ProgramB], as expected Select the row for [Doc1] Add any desired comments in the "New Comments to be Appended to Original Document" field Submit the form Validate the 'Confirm Document' dialog displays the appended comments Validate the document contains the appended signature of the logged in user [UserB] at the end of the document. Click [Accept]. Validate the form files successfully. Log out as [UserB] Log in as [UserA] into the sub system code [SubCode] Repeat step1 Validate the results are the same, as the sub code is restricted to only [ProgramA] Log out as [UserA] Log in as [UserA] into the [Root] system code Repeat step 1 Validate the drop down list displays [Doc1] filed for [FormA] in [Episode1, ProgramA] Validate the drop down list also displays [Doc2] filed for [FormB] in [Episode2, ProgramB], as [UserA] has access to both the root and sub system code. My To Do's Widget - Sign Tab Scenario 1: 'My To Do's Widget - Validate user permissions to access documents Specific Setup: Have a system with a root and a sub system code The sub system is code is assigned to only [ProgramA] [UserA] is a staff member that can cosign for other staff members and has access to log into both the root and the sub code [UserB] is a staff member and cannot cosign for other staff members and has access to log both the root and the sub code [TestClient] has been admitted in two episodes: "Episode1" in [ProgramA] "Episode2" in [ProgramB] Two documents have been routed for [TestForm] for [TestClient] [DocA] - was routed to [UserA] for an [Epsiode1] [DocB] - was routed to [UserB] for [Episode2] [UserA] and [UserB] have the "My To Do's" widget on their home view Steps Log in to the sub code as [UserA] Navigate to the "My To Do's" widget Click the [Sign] tab Search for [UserA] in the "Staff" search field Validate [DocA] is found Search for [UserB] in the Staff field Validate [DocB] is not found, as [DocB] was filed in [Episode2], [ProgramB], which is not a program assigned to the logged in sub code Log out as [UserA] from sub code Log in as [UserA] to the root system code Navigate to the "My To Do's" widget Click the [Sign] tab Search for [UserA] in the "Staff" search field Validate [DocA] is found Search for [UserB] in the "Staff" search field Validate [DocB] is found, as [UserA] can co-sign for other staff members is logged into the root system code, which has access to all programs Log out as [UserA] Log in as [UserB] into the sub code Navigate to the "My To Do's" widget Click the [Sign] tab Validate the "Staff" search field is disabled, as [UserB] cannot cosign for any other staff members. Validate [DocA] is not listed in the "Search Documents" list, as that document was routed to another staff member. Validate [DocB] is not listed in the "Search Documents" list, as that document was filed in [Episode2], [ProgramB], which is not a program assigned to the logged in sub code Log out as [UserB] from sub code Log in as [UserB] to the root system code Navigate to the "My To Do's" widget Click the [Sign] tab Validate the "Staff" search field is disabled, as [UserB] cannot cosign for any other staff members. Validate [DocA] is not listed in the "Search Documents" list, as that document was routed to another staff member. Validate [DocB] is listed in the "Search Documents" list, as the document was routed to [UserB] and is logged into the root system code, which has access to all programs My To Do's Widget - Sign Tab Scenario 1: 'My To Do's Widget (Sign Tab) - Validate approving documents as as Co-Signer Specific Setup: [UserA] is a staff member [UserB] is a staff member [UserC] is a staff member that can co-sign To Do's for other staff members Two documents have been routed in form [TestForm], for [TestClient] [DocA] - was routed to [UserA] in [Episode1] [DocB] - was routed to [UserB] in [Episode2] [UserC] has the "My To Do's" widget on their home view Log in as [UserC] Steps Navigate to the "My To Do's" widget Click the [Sign] tab In the "Staff" search filed, search for [UserA] Validate the row for [DocA] is the "Search Documents" list, and select the row Validate the "Document" preview pane displays data as expected for the document Navigate to the end of the document Validate the last signature indicates [UserC], as the "Co-Signer" signature. For example, "Electronically Signed By: [UserC] (Date and Time) - Co-Signer" Click [Accept], to move the document to the "Accepted Documents" section Select the document Click [Sign All] Validate the document is removed from the "Sign Tab" In the "Staff" search filed, search for [UserB] Validate the row for [DocB] is the "Search Documents" list, and select the row Validate the "Document" preview pane displays data as expected for the document Navigate to the end of the document Validate the last signature indicates [UserC], as the "Co-Signer" signature. For example, "Electronically Signed By: [UserC] (Date and Time) - Co-Signer" Click [Accept], to move the document to the "Accepted Documents" section Select the document Click [Sign All] Validate the document is removed from the "Sign Tab" Open form "Clinical Document Viewer" Select [TestClient] in the "Select Client" field Click [Process] Click the [Results] tab Locate the row for the [DocA] signed in step 1b and select the "View" check box Click the [View] button Validate the "Document" preview pane displays data as expected for the document Navigate to the end of the document Validate the last signature indicates [UserC], as the "Co-Signer" signature. For example, "Electronically Signed By: [UserC] (Date and Time) - Co-Signer" Click [Close All Documents] Locate the row for the [DocB] signed in step 1b and select the "View" check box Click the [View] button Validate the "Document" preview pane displays data as expected for the document Navigate to the end of the document Validate the last signature indicates [UserC], as the "Co-Signer" signature. For example, "Electronically Signed By: [UserC] (Date and Time) - Co-Signer" Click [Close All Documents] Click the [Search] tab Click [Close] Document Archiving Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Document Archiving Scenario 1: Document Archiving - Form field validations Specific Setup: A "Form" type [FormtypeA], is defined in form "Document Management Definition" and includes restrictions selected in field "Document Restrictions' [FormA] is set up in form "Document Routing Setup" with [FormtypeA] A document [DocumentA] generated with [FormA] exists for [TestClient], that was created over "180" days ago A "Form" type [FormtypeB], is defined in form "Document Management Definition" and does "not" include any restrictions selected in field "Document Restrictions' [FormB] is set up in form "Document Routing Setup" with [FormtypeB] A document [DocumentB] that was generated with [FormB] exists for [TestClient], that was created over "180" days ago Steps Open form "Clinical Document Viewer" Select [TestClient] Click [Process] Validate [DocumentA] generated by [FormA], is displayed as expected date Validate [DocumentB] generated by [FormB], is displayed as expected date Close the form Open form "Document Archiving" Select "Client" the entity type in the "Entity Type" field Select "Individual" in the "Include" field Select [TestClient] in the "Entity" field Select the applicable episode in the "Episode" field In the "Archive Documents Older Than" enter the desired date greater than "180" days Click the "View Form Types Included" Validate row is displayed for [FormTypeA] for [FormA] Validate row is displayed for [FormTypeB] for [FormB] Click [Archive] At the "Are you sure you want to Archive these Documents" dialog, click [Yes] Close the form Open form "Clinical Document Viewer" Select [TestClient] Click [Process] Validate [DocumentA] generated by [FormA] is no longer displayed, as expected Validate [DocumentB] generated by [FormB] is no longer displayed, as expected	Topics • Document Routing • NX • My To Do's • Document Management
Update 3 Summary \| Details Modeled Forms - 'Decimal' and 'Integer' fields Scenario 1: Modeled Form - 'Decimal' and 'Integer' field validations Specific Setup: A client must be enrolled in an existing episode (Client A). Have a modeled form with "Decimal" and "Integer" field types (Form A). "Form A" must be accessible from the Chart View. Steps Select "Client A" and access "Form A". Enter a negative decimal value in the 'Decimal' field (Ex: -1.24). Validate the value is accepted. Enter a negative integer value in the 'Integer' field (Ex: -1212). Validate the value is accepted. Click [Submit]. Double click on "Client A" in the 'My Clients' widget. Validate that the 'Chart View' is displayed. Select "Form A" from the left-hand side. Validate the record filed in the previous steps is displayed. Validate the 'Decimal' field contains the value filed in the previous steps (Ex: -1.24). Validate the 'Integer' field contains the value filed in the previous steps (Ex: -1212). Close the Chart. Select "Client A" and access "Form A". Click [Edit] to edit the previous filed record. Enter a positive decimal value in the 'Decimal' field (Ex: 2.41). Validate the value is accepted. Enter a positive integer value in the 'Integer' field (Ex: 1212). Validate the value is accepted. Click [Submit]. Double-click on "Client A" in the 'My Clients' widget. Validate that the 'Chart View' is displayed. Select "Form A" from the left-hand side. Validate the record updated in the previous steps is displayed. Validate the 'Decimal' field contains the value filed in the previous steps (Ex: 2.41). Validate the 'Integer' field contains the value filed in the previous steps (Ex: 1212). Close the Chart.	Topics • Modeling
Update 4 Summary \| Details Avatar Data Warehouse - IRIS Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: SQL Query/Reporting Tool Scenario 1: Data Warehouse Processing (IRIS)- Table row validations Specific Setup: Have Avatar database server set up that is running on "IRIS" based system that's configured with the parent namespace and one or more child namespaces Have a server installed with the latest released version of "Avatar Data Warehouse Middleware" for "IRIS". Netsmart has been configured the middleware to initiate the data warehouse process Have a "Microsoft SQL Server" where table data processed by the data warehouse process will be stored Have a database program that can query the data in the tables stored on the data warehouse server. For example program "DBeaver Universal Database Manager" or "Crystal Reports" In form "User Definition", a user had been created [AvatarDW] as the designated data warehouse user. [AvatarDW] has been assigned permissions to tables determined to be included in the data warehouse process, that includes tables selected in parent namespace and in any child namespaces In form "Data Warehouse Transient Comparison Configuration", the designated data warehouse user [AvatarDW] has the designated tables selected in previous selected in "Mark Tables for Full Load" section Have a report or query that will display data in the "SYSTEM.dss_inc_error_log" table Have a report or query that will display data in the "SYSTEM.dss_inc_full_load_history" table Netsmart has run "Data Warehouse Middleware" process on the middleware server, in the parent namespace and each child namespace Steps Generate the report to display data in the "SYSTEM.dss_inc_error_log" table Validate there are no results indicating the data warehouse middleware process has completed successfully Generate the report to display data in the "SYSTEM.dss_inc_full_load_history" table Validate the expected data rows are present on the report for the parent and child namespace tables selected for data warehouse processing in the setup Validate each row has "Insert" populated in the "Type" field Open the program to query data on the 'SQL' database server and connect to the database Run at query to display rows filed the "dss_completion_flag" table. Validate the expected tables are present on the results, for the parent and child namespace tables selected for data warehouse processing, in the setup Validate the "dss_status" field for each row is set to "1", indicating the table was loaded successfully From the database "Table" tree list, select tables form the parent and child namespaces Click to display the rows in the table Validate all data rows are displayed, as expected	Topics • Data Warehouse
Update 6 Summary \| Details Form Definition - Document Routing Scenario 1: Form Definition (Document Routing) - 'Skip Display of Document Image' and 'Skip Password' validations Specific Setup: Have a user [TestUser] who is a staff member and has the "My To Do's" widget on their home view. Have a modeled form [FormA] with a "Draft/Final" field and any other desired fields on the form. A client must be admitted in an existing episode. [ClientA]. [TestUser] has access to form "Document Routing Setup" and "Form Definition". Login as [TestUser] Steps Open form "Form Definition" and select [FormA]. Navigate to the "Document Routing" section. Set field "Enable Document Routing" to "Yes". Click [Select Type] and select a desired form type. Populate the "Void Reason Code" field. Set field "Skip Display of Document Image" to "Yes". Validate field "Skip Password Entry" is set to "Yes" and is "Disabled". Submit the form. Open form "Document Routing Setup". Select [TestForm]. Validate field "Enable Document Routing" to "Yes". Validate the "Type Name" field is populated with the form type selected in step1a. Validate the "Void Reason Code" field is populated with the value selected in step1a. Validate the "Skip Display of Document Image" to "Yes". Validate field "Skip Password Entry" is set to "Yes" and is "Disabled". Close the form. Select [Client A] and open [FormA]. Populate the desired fields on form and submit the form as "Final". Validate the 'Document Preview' screen does not display, as expected. Validate the "Password Entry" dialog does not display. At the "Route Document To" screen. Search and select [UserA] as the "Approver" and click [Add] to add the user as an approver. Click [Submit]. Navigate to the 'My To Do's' widget.. Validate there is a To-Do present for [FormA] routed in the previous step. Click [Approve Document]. Validate the 'Document Preview' displays the expected data. Click [Accept]. Enter the password associated with "User A" and click [OK]. Validate the To Do is no longer present in the "My To Do's" widget. Open form "Form Definition" and select [FormA]. Navigate to the "Document Routing" section. Set field "Skip Display of Document Image" to "No". Validate field "Skip Password Entry" is now enabled. Set the value to "No". Submit the form. Open form "Document Routing Setup". Select [TestForm]. Validate field "Skip Display of Document Image" to "No" as expected. Validate field "Skip Password Entry" to "Yes", as expected. Close the form. Select [Client A] and open [FormA]. Populate the desired fields on form and submit the form as "Final". At the "Confirm Document" screen, validate the 'Document Preview' is displayed and populated as expected. Click the [Accept and Route] button. Validate the user is not prompted to enter their password, as expected. At the "Route Document To" screen. Search and select [UserA] as the "Approver" and click [Add] to add the users as an approver. Click [Submit]. Repeat step 4 Validate results are as expected. Open form "Form Definition" and select [FormA]. Navigate to the "Document Routing" section. Validate field "Skip Display of Document Image" to "No" as expected. This time set field "Skip Password Entry" to "No". Submit the form. Open form "Document Routing Setup". Select [TestForm]. Validate field "Skip Display of Document Image" to "No" as expected. Validate field "Skip Password Entry" to "No", as expected. Close the form. Select [Client A] and open [FormA]. Populate the desired fields on form and submit the form as "Final". Validate the 'Document Preview' is displayed and populated, as expected. Click the [Accept and Route] button. Validate the user is prompted this time to enter their password. Populate the password field. At the "Route Document To" screen. Search and select [UserA] as the "Approver" and click [Add] to add the users as an approver. Click [Submit].. Repeat step 4 Validate results are as expected. Scenario 2: Form Definition (Document Routing) - "Acknowledgment" field and functionality validations Specific Setup: Have two users [StaffA] and [StaffB]. Both users have the "My To Do's" widget on their home view. Have a modeled form [TestFormA] with a "Draft/Final" field and any other desired fields on the form. A client [TestClient] has been admitted in an existing episode and his "Admitting Practitioner" is [StaffA]. Login as [StaffA]. Steps Open form "Form Definition" and select [TestFormA]. Select the "Document Routing" section. Set field "Enable Document Routing" to "Yes". Click [Select Type] and select a desired form type. Populate the "Void Reason Code" field. Set field 'Approver Required' to "Yes". Navigate to the "Acknowledgments" sub-section. Validate field "Acknowledgments Allowed" is set to "No" and enabled. Validate all other fields in the section are disabled. Set field 'Acknowledgment Allowed' field set to "Yes". Validate the following fields are present and now are enabled. "Acknowledgment List Defaults". "Verification Level of Acknowledgments". "Days after finalized document to alert". "Forms to error when accessed". In the "Acknowledgment List Defaults" field select a desired value, for example "Admitting Practitioner". In the "Verification Level of Acknowledgments" field select a desired value, for example "Warn User if Acknowledgment is Missing". Set field "Days After Finalized document to alert" to the desired value. In the "Forms to error when access" select any desired form [TestFormB] from the selection list. Submit the form. Validate the form files successfully. Open form "Document Routing Setup". Select [TestForm]. Validate the fields set in step1b are set with the same values. Close the form. Select [TestClient] and open [TestFormA]. Populate the desired fields on form and submit the form as "Final". Validate the 'Document Preview' displays the expected data. At the "Confirm Document" screen. Validate the document contains the expected values. Click the [Accept and Route] button. Populate the "Verify Password Prompt" with a password and click [OK]. At the "Route Document To" screen. Validate "Admitting Practitioner" is selected in the "Add Members to Acknowledge" selection box. Validate [StaffA] has been automatically added and selected as an acknowledger. Validate the [Submit] button is disabled. In the "Add" approver search field, select [StaffB]. Validate [StaffB] has been added and selected as an "Approver". Validate the [Submit] button is now enabled. Click [Submit]. Logout a [StaffA]. Login as [StaffB]. Select [TestClient]. Navigate to the 'My To Do's' widget. Validate there is a To-Do present for [TestFormA] routed in step 2a. Click [Approve Document]. Validate the 'Document Preview' displays the expected data. Click [Accept]. Enter the users password and click [OK]. Validate the To Do is no longer present in the "My To Do's" widget. Logout a [StaffB]. Login as [StaffA]. Select [TestClient]. Access [TestFormB]. Validate a "Verification Acknowledgment" dialog is displayed, indicating "[TestFormB] has an acknowledgment that has not been addressed. Please provide a reason for not acknowledging". Populate the text field with a reason and click [OK]. Validate [TestFormB] loads as expected. Populate the form and submit it. Validate the form files successfully. Navigate to the 'My To Do's' widget. Validate there is an "Acknowledgments" To Do present for [TestFormA] in the To Do list. Click [Acknowledge Document]. Validate the 'Document Preview' displays the expected data. Click [Acknowledge]. Enter the password associated with user and click [OK]. Validate the To Do is no longer present in the "My To Do's" widget. Access [TestFormB]. Validate this time there is no "Verification Acknowledgment" dialog displayed, as the user has already acknowledged the 'To Do' waiting for the form. Validate the form opens successfully. Populate the form and submit it. Validate the form files successfully. Scenario 3: Envelope Import - Validate "Document Routing" settings set on forms after import Specific Setup: Have or create a modeled envelope [TestEnvelope] that contains a modeled form [TestForm]. Configure [TestForm] in the document routing section of "Form Definition" or in form "Document Routing Setup", with the following document routing fields set as well as any other desired fields: "Enable Document Routing" ; "Void Reason Code" ; "Create Document Only" ; "Skip Display of Document Image" ; "Skip Password Entry" ; "Require Final Approver" ; "Allow Transcriber" ; "Allow Notifications When Final" ; "Allow Notification With No Approvers" ; "Allow Comments During Approval" ; "Acknowledgment Allowed" ; "Acknowledgement List Defaults" ; "Verification Level of Acknowledgments" ; "Days after finalized document to alert" ; "Forms to error when accessed". In form "Envelope Export", have envelope [TestEnvelope], exported and saved. Steps Open form "Envelope Import". Click [Select Envelope Import File]. In Windows Explorer, navigate to the location of [TestEnvelope]. Select the file. Click [Save]. In the "Overwrite Existing or Create New Envelope" field. Select "Overwrite Existing" if [TestEnvelope] already exists in the testing environment. Select "Create New" if [TestEnvelope] does not already exist in the current environment. Click [Begin Import Scan]. Validate the import scan is successful. Click [Begin Import]. Validate the envelope imports successfully. Open form "Document Routing Setup". Select [TestForm]. Validate each of the document routing fields set in the setup are populated as expected. Validate any fields not set in the set up are not populated, as expected. Close the form. Open form "Form Definition". Navigate to the "Document Routing Section". Validate each of the document routing fields set in the setup are populated as expected. Validate any fields not set in the set up, are not populated as expected.	Topics • Modeling • NX • Document Routing • Envelope Import • Envelope Export
Update 7 Summary \| Details 'Client Lookup/Header Configuration Manager' - Client Header Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CarePOV Management CLIENT DASHBOARD Allergies and Hypersensitivities Client Lookup/Header Configuration Manager Scenario 1: Bed Board client alert icons display in the client header Specific Setup: Bed Board POV widget is installed and enabled. Five "Client Alerts" are defined in "CarePOV Management" form with icons. The "Client Information" widget is present on the Home View. A client is enrolled in an inpatient episode and has data filed for the five client alerts to display (Client A). Steps Open "CarePOV Management" form. Select the "Client Alerts" section. Select "Edit" in the 'Add or Edit Alert' field. Select an alert in the 'Client Alert' field. Select "Yes" in the 'Include in Client Header' field. Click [Save]. Repeat the above steps to add the five defined client alerts to the client header. Select "Client A" and navigate to the "Client Information" widget. Validate the five "Client Alert" icons are displayed. Select "Client A" and access the 'Progress Notes (Group and Individual)' form. Validate the five "Client Alert" icons are displayed in the client header. Close the form. Scenario 2: Validate form access in the Client Header Specific Setup: A client must be admitted into an active episode and have 100 allergies on file (Client A). There must be two users: A user that is logged in and has full access to forms (User A). A user that does not have access to the 'Allergies and Hypersensitivities' form (User B). The users' myDay view must be configured to include the Client Information header (View A). Please note: This is for Avatar NX systems only. Steps Select "Client A" and navigate to "View A". Hover over the 'Allergies (100)' link in the 'Client Header'. Validate a flyover displays fifteen allergies listed and 85 more. Click the 'Allergies (100)' link. Validate a menu displays and the user can scroll through all the allergies. Close the menu. Click edit icon. Validate the 'Allergies and Hypersensitivities' form opens. Validate the edit icon no longer displays in the 'Client Header'. Discard the form. Select "Client A" and launch the 'Client Dashboard'. Validate the 'Client Dashboard' displays as expected. Hover over the 'Allergies (100)' link in the 'Client Header'. Validate a flyover displays fifteen allergies listed and 85 more. Click the 'Allergies (100)' link. Validate a menu displays and the user can scroll through all the allergies. Close the menu. Click edit icon. Validate the 'Allergies and Hypersensitivities' form opens. Validate the edit icon no longer displays in the 'Client Header'. Discard the form. Log out. Log in as "User B". Select "Client A" and navigate to "View A". Validate the edit icon does not display in the 'Client Header'. Validate a flyover displays fifteen allergies listed and 85 more. Click the 'Allergies (100)' link. Validate a menu displays and the user can scroll through all the allergies. Close the menu. Launch the 'Client Dashboard'. Validate the edit icon does not display in the 'Client Header'. Hover over the 'Allergies (100)' link in the 'Client Header'. Validate a flyover displays fifteen allergies listed and 85 more. Click the 'Allergies (100)' link. Validate a menu displays and the user can scroll through all the allergies. Close the menu. Scenario 3: Condensed Client Header validations Specific Setup: The logged in user must have access to the 'Client Lookup/Header Configuration Manager' form (User A). The 'Bed Board POV' widget is installed and enabled. Five "Client Alerts" are defined in the 'CarePOV Management' form with icons. 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 client is enrolled in an existing episode and has data filed for the five client alerts to display (Client A). "Client A" must have allergies on file. A program is defined (Program A). A client is admitted in "Program A" (Client B). Please note: This is for Avatar NX systems only. This is for initial configuration. Once the 'Expand/Collapse' toggle has been selected, it will override settings in the 'Client Lookup/Header Configuration Manager' form for the user. Steps Access the 'Client Lookup/Header Configuration Manager' form. Validate the "Condensed Header" and "Condensed Header Override" fields display. Navigate to the 'Condensed Header' tab. Validate "Bed Board Alerts" is selected in the 'Condensed Header Field Position 2' field. Select any value in the 'Condensed Header Field Position 1' field. Select "Yes" in the 'Default Views To Condensed Header' field. Select "Yes" in the 'Default Client Entity Forms to Condensed Header' field. Validate text displays stating: "Note: This setting will default all views configured to include client information header in view to utilize the condensed header. Individual views may still override this setting via the options 'Default Client Information header to condensed view' in View Definition > View Designer." Navigate to the 'Condensed Header Override' tab. Click [Add New Item]. Select "Program A" in the 'Program' field. Select any value in the 'Condensed Header Field Position 1' field. Select any value in the 'Condensed Header Field Position 2' field. Select "No" in the 'Default Client Entity Forms To Condensed Header' field. Click [Submit]. Log out. Log in as "User A". Navigate to the 'All Documents' view. Select "Client A" from the 'My Clients' list. Validate the client information header is condensed. Validate the value selected in the 'Condensed Header Field Position 1' field displays. Validate the 'Bed Board Alerts' display. Click [View] and validate a menu displaying all 'Active Alerts'. Close the menu. Click [Allergies] and validate a menu displaying allergies. Close the menu. Click the 'Expand/Collapse' toggle. Validate the client information header is full size. Navigate to the 'myDay' view. Navigate to the 'All Documents' view. Validate the client information header is full size. Launch the 'Client Dashboard'. Validate the client information header is full size. Click the 'Expand/Collapse' toggle. Validate the client information header is condensed. Click [Close]. Navigate to the 'myDay' view. Access the 'Progress Notes (Group and Individual)' form. Validate the client information header is condensed. Clear the 'Select Client' field. Enter and select "Client B" in the 'Select Client' field. Validate the client information header is full size. Close the form. Access the 'View Definition' form. Click [Select View]. Select "Add New View" in the 'Select Views' field. Click [OK]. Enter any value in the 'View ID' field. Enter "View A" in the 'View Description' field. Select "Home View" in the 'View Type' field. Select "Yes" in the 'Allow User To Customize View' field. Click [Launch View Designer]. Validate 'Default Client Information header to condensed view' is disabled. Click [Include Client Information header in view]. Validate 'Default Client Information header to condensed view' is now enabled. Select the desired widgets and arrange them as desired. Click [Submit], [Submit], and [No]. Access the 'NX View Definition' form. Select "User" in the 'User or Role' field. Enter and select "User A" in the 'Select User' field. Click [Additional myDay Views]. Select "View A" and click [OK]. Click [File]. Validate an 'Avatar NX View Definition' dialog stating: "Filed" and click [OK]. Close the form. Validate "View A" displays in the top navigation. Navigate to "View A". Validate the client information header is full size. Select the 'Customize Toggle' button. Select the 'My Activity' menu. Select the 'View/Add Widgets' tab. De-select 'Include Client Information header in view'. Validate the client information head no longer displays. Select the 'Customize Toggle' button and close the menu.	Topics • Progress Notes (Group And Individual) • RADplus Utilities • NX • Allergies and Hypersensitivities • myAvatar NX Only • View Definition
Update 8 Summary \| Details myClients widget - Room numbers removed after Discharge Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Delete Last Movement Scenario 1: 'Include Active Room Number with Client Name' Registry Setting - validate room number is omitted from myClient's widget when client is removed from bed Specific Setup: A room and bed must be configured via the 'Maintain Hospital Bed File' form. The 'My Clients' widget must be added to the 'HomeView' of the user logged into the application. Steps Access the ‘Registry Settings’ form. Set the ‘Select Registry Setting’ field to “Include Active Room Number”. Set the ‘RADplus->General->Facility->->->Include Active Room Number With Client Name’ registry to “3,1&BED”. Close the form. Log out of the application and log back in. Validate the 'My Clients' widget contains the room number and bed in the following format: Room number followed by a "." and the bed number. Select the test client in 'myClients' widget and access the ‘Admission’ form. Select the episode in the ‘Episode’ pre-display and click [Edit]. Validate the client header contains the room number next to the client name. Close the form. Access the 'Discharge' form. Select the text client and submit the discharge. Access the 'Delete Last Movement' form. Select the test client and delete the last movement record (discharge). Validate room number doesn't display next to the client name when selected in 'myClients' widget.	Topics • Widgets
Update 10 Summary \| Details User Modeled Forms - Multiple Iterations Sections Scenario 1: Validate modeled forms that have various multiple iterations sections when document routing is enabled Specific Setup: A user-modeled form (Form A) is defined with the following: 10+ multiple iterations sections Document routing enabled Accessible from the Chart View Steps Select "Client A" and access the "Form A". Populate all sections in the form. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate the 'Confirm Document' dialog is displayed. Validate the TIFF image contains the form sections in proper order. Click [Accept]. Enter the password associated to the logged in user and click [OK]. Double click on "Client A" in the 'My Clients' widget. Validate that the 'Chart View' is displayed. Select "Form A" from the left-hand side. Validate all previously filed data is displayed. Validate the form sections appear in the proper order. Close the Chart.	Topics • Modeling • Document Routing
Update 12 Summary \| Details Progress Notes and User Modeled Form - Default Author for Transcribing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Enrollment User Role Definition Envelope Definition (CWS) Attending Practitioner Treatment Plan (Non-Episodic) Scenario 1: User Modeled Forms - Transcriber Default Author Specific Setup: Using the "Practitioner Enrollment" form, create 8 practitioners. Admit a client into an outpatient episode, populate the "Attending Practitioner" field with the staff designated as "Practitioner 1" and designate this "Client A". Admit a client into an outpatient episode, do not populate the "Attending Practitioner" field and designate this "Client B". Using user modeling, create a user modeled form that contains a Draft/Final field so it can be routed. Using "User Role Definition" add or edit a user role to give users access to the form being tested, to not allow customization and to designate the user role as a transcriber and set the "Default Author" to "Practitioner 3". Designate this "User Role A". Set up a user for each of the 8 practitioners using "User Definition". User 1 must be "Practitioner 1" and should not be a transcriber on the "Document Routing" section. User 2 must be "Practitioner 2" and should not be a transcriber on the "Document Routing" section. User 3 must be "Practitioner 3" and should not be a transcriber on the "Document Routing" section. User 4 must be "Practitioner 4" and should be designated a transcriber on the "Document Routing" section and should have "Practitioner 2" assigned as "Default Author" on the "Document Routing" section. User 5 must be "Practitioner 5" and should be assigned to "User Role A" and designated a transcriber on the "Document Routing" section. User 6 must be "Practitioner 6" and must be designated a transcriber but should have no "Default Author" defined on the "Document Routing" section. User 7 must be "Practitioner 7", should be assigned to "User Role A" and should be designated a transcriber and should have the "Default Author" set to "Practitioner 3" on the "Document Routing" section. User 8 must be "Practitioner 8", should be assigned to "User Role A" and should be designated a transcriber, the "Default Author" should be set to "Practitioner 2" on the "Document Routing" section. All users must be given access to the form being tested on the "Forms and Table" section of the "User Definition" form. All users must be set up to have a home view that contains the "MyToDo's" widget. Using the "Document Routing Setup" form, enable document routing and allow transcriber for the form being tested. Steps Test 1: User who is a transcriber, but has no default author assigned, client who has no attending practitioner. The result is the Select Author field will be blank. Login as "User 6". Using the user modeled form, generate a progress note for "Client B" and set it to final. Validate the "Select Author" field is blank. Set "Select Author" to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the author column is correctly populated with the author in the SQL table "DocR.transcriber". Test 2: User who is a transcriber, and has a default author assigned in the "User Definition" form, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" in the "User Definition". Login as "User 4". Using the user modeled form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 3: User who is a transcriber, is assigned to a default author assigned in the "User Definition" form, is also assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's default author from "User Definition". Login as "User 8". Using the user modeled form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 4: User who is a transcriber, is assigned to a user role that has default author assigned, and has the same default author assigned on the user definition form and client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Definition" form. Login as "User 7". Using the user modeled form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 5: User who is a transcriber, is assigned to a user role that has default author assigned, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Role Definition". Login as "User 5". Using the user modeled form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 6: User who is a transcriber, is assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's user role default author from "User Role Definition". Login as "User 5". Using the user modeled form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 7: User who is a transcriber, has no "Default Author" in "User Definition" and a client who does not have an attending practitioner. The result is the Select Author field will default to blank. Login as "User 6". Using the user modeled form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 8: User who is a transcriber, has no "Default Author" defined client who has an attending practitioner. Author rejected the initial note and returned to transcriber for corrections. Login as "User 6". Using the user modeled form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Reject the note to send it back to the transcriber. Log off and login as "User 6". Navigate to the "myToDo's" widget. Open the user modeled form from the myToDo's item. Correct and finalize the note. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User 2". Finalize the progress note. Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the progress note. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Scenario 2: Progress Notes (Group and Individual) - Transcriber Default Author Specific Setup: Using the "Practitioner Enrollment" form, create 8 practitioners. Admit a client into an outpatient episode, populate the "Attending Practitioner" field with the staff designated as "Practitioner 1" and designate this "Client A". Admit a client into an outpatient episode, do not populate the "Attending Practitioner" field and designate this "Client B". Using "User Role Definition" add or edit a user role to give users access to the form being tested, to not allow customization and to designate the user role as a transcriber and set the "Default Author" to "Practitioner 3". Designate this "User Role A". Set up a user for each of the 8 practitioners using "User Definition". User 1 must be "Practitioner 1" and should not be a transcriber on the "Document Routing" section. User 2 must be "Practitioner 2" and should not be a transcriber on the "Document Routing" section. User 3 must be "Practitioner 3" and should not be a transcriber on the "Document Routing" section. User 4 must be "Practitioner 4" and should be designated a transcriber on the "Document Routing" section and should have "Practitioner 2" assigned as "Default Author" on the "Document Routing" section. User 5 must be "Practitioner 5" and should be assigned to "User Role A" and designated a transcriber on the "Document Routing" section. User 6 must be "Practitioner 6" and must be designated a transcriber but should have no "Default Author" defined on the "Document Routing" section. User 7 must be "Practitioner 7", should be assigned to "User Role A" and should be designated a transcriber and should have the "Default Author" set to "Practitioner 3" on the "Document Routing" section. User 8 must be "Practitioner 8", should be assigned to "User Role A" and should be designated a transcriber, the "Default Author" should be set to "Practitioner 2" on the "Document Routing" section. All users must be given access to the form being tested on the "Forms and Table" section of the "User Definition" form. All users must be set up to have a home view that contains the "MyToDo's" widget. Using the "Document Routing Setup" form, enable document routing and allow transcriber for the form being tested. Steps Test 1: User who is a transcriber, but has no default author assigned, client who has no attending practitioner. The result is the Select Author field will be blank. Login as "User 6". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client B" and set it to final. Validate the "Select Author" field is blank. Set "Select Author" to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the author column is correctly populated with the author in the SQL table "DocR.transcriber". Test 2: User who is a transcriber, but has no default author assigned, client who has an attending practitioner. The result is the Select Author will default to the client's attending practitioner. Login as "User 6". Using the "Progress Notes (Group and Individual)" form, generate a progress note and for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 1". Log off and login as "User/Practitioner 1". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 3: User who is a transcriber, and has a default author assigned in the "User Definition" form, client who has an attending practitioner. The result is the Select Author field will default to the client's attending practitioner. Login as "User 4". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 4: User who is a transcriber, is assigned to a user role that has default author assigned, client who has an attending practitioner. The result is the Select Author field will default to the client's attending practitioner. Login as "User 5". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 5: User who is a transcriber, is assigned to a user role that has default author assigned, and has the same default author assigned on the user definition form and client who has an attending practitioner. The result is the Select Author field will default to the client's attending practitioner. Login as "User 7". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 6: User who is a transcriber, and has a default author assigned in the "User Definition" form, client who does not have an attending practitioner. The result is the Select Author field will default to the user's default author from "User Definition". Login as "User 4". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 7: User who is a transcriber, is assigned to a default author assigned in the "User Definition" form, is also assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's default author from "User Definition". Login as "User 8". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 8: User who is a transcriber, is assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's user role default author from "User Role Definition". Login as "User 8". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 9: User who is a transcriber, is assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is that no matter the default value, if you change the "Select Author" to someone else, the note will be routed to them. Login as "User 8". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Change the "Select Author" to "User/Transcriber 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 10: User who is a transcriber, is assigned to a user role that has default author assigned, and has the same default author assigned on the user definition form, client who has an attending practitioner. Author rejected the initial note and returned to transcriber for corrections. Login as "User 7". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 1". Log off and login as "User/Practitioner 1". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Reject the note to send it back to the transcriber. Log off and login as "User 7". Navigate to the "myToDo's" widget. Open the "Progress Notes (Group and Individual)" form from the myToDo's item. Correct and finalize the note. Validate "Select Author" defaults to "User/Practitioner 1". Log off and login as "User 1". Finalize the progress note. Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the progress note. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 11: User who is a transcriber, has no default author assigned, is not assigned to a user role., client who has an attending practitioner. After note is transcribed, the client's attending practitioner is changed to another practitioner. Note remains with the original author and doesn't transfer to the new attending practitioner for the client. Login as "User 8". Using the "Progress Notes (Group and Individual)" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 1". Open the "Attending Practitioner" form and change the practitioner to "Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. This user won't get a To Do for this item because the To do will stay with the original author. Log off and log in as "User/Practitioner 1". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the progress note. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Scenario 3: Episodic Treatment Plans - Transcriber Default Author Specific Setup: Using the "Practitioner Enrollment" form, create 8 practitioners. Admit a client into an outpatient episode, populate the "Attending Practitioner" field with the staff designated as "Practitioner 1" and designate this "Client A". Admit a client into an outpatient episode, do not populate the "Attending Practitioner" field and designate this "Client B". Using "User Role Definition" add or edit a user role to give users access to the form being tested, to not allow customization and to designate the user role as a transcriber and set the "Default Author" to "Practitioner 3". Designate this "User Role A". Set up a user for each of the 8 practitioners using "User Definition". User 1 must be "Practitioner 1" and should not be a transcriber on the "Document Routing" section. User 2 must be "Practitioner 2" and should not be a transcriber on the "Document Routing" section. User 3 must be "Practitioner 3" and should not be a transcriber on the "Document Routing" section. User 4 must be "Practitioner 4" and should be designated a transcriber on the "Document Routing" section and should have "Practitioner 2" assigned as "Default Author" on the "Document Routing" section. User 5 must be "Practitioner 5" and should be assigned to "User Role A" and designated a transcriber on the "Document Routing" section. User 6 must be "Practitioner 6" and must be designated a transcriber but should have no "Default Author" defined on the "Document Routing" section. User 7 must be "Practitioner 7", should be assigned to "User Role A" and should be designated a transcriber and should have the "Default Author" set to "Practitioner 3" on the "Document Routing" section. User 8 must be "Practitioner 8", should be assigned to "User Role A" and should be designated a transcriber, the "Default Author" should be set to "Practitioner 2" on the "Document Routing" section. All users must be given access to the form being tested on the "Forms and Table" section of the "User Definition" form. All users must be set up to have a home view that contains the "MyToDo's" widget. Using the "Document Routing Setup" form, enable document routing and allow transcriber for the form being tested. Steps Test 1: User who is a transcriber, but has no default author assigned, client who has no attending practitioner. The result is the Select Author field will be blank. Login as "User 6". Using the "Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate the "Select Author" field is blank. Set "Select Author" to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the author column is correctly populated with the author in the SQL table "DocR.transcriber". Test 2: User who is a transcriber, and has a default author assigned in the "User Definition" form, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" in the "User Definition". Login as "User 4". Using the "Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 3: User who is a transcriber, is assigned to a default author assigned in the "User Definition" form, is also assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's default author from "User Definition". Login as "User 8". Using the "Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 4: User who is a transcriber, is assigned to a user role that has default author assigned, and has the same default author assigned on the user definition form and client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Definition" form. Login as "User 7". Using the "Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 5: User who is a transcriber, is assigned to a user role that has default author assigned, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Role Definition". Login as "User 5". Using the "Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 6: User who is a transcriber, is assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's user role default author from "User Role Definition". Login as "User 5". Using the "Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 7: User who is a transcriber, has no "Default Author" in "User Definition" and a client who does not have an attending practitioner. The result is the Select Author field will default to blank. Login as "User 6". Using the "Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 8: User who is a transcriber, has no "Default Author" defined client who has an attending practitioner. Author rejected the initial note and returned to transcriber for corrections. Login as "User 6". Using the "Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Reject the note to send it back to the transcriber. Log off and login as "User 6". Navigate to the "myToDo's" widget. Open the "Treatment Plan" form from the myToDo's item. Correct and finalize the note. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User 2". Finalize the progress note. Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the progress note. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Scenario 4: Non Episodic Treatment Plan - Transcriber Default Author Specific Setup: Using the "Practitioner Enrollment" form, create 8 practitioners. Admit a client into an outpatient episode, populate the "Attending Practitioner" field with the staff designated as "Practitioner 1" and designate this "Client A". Admit a client into an outpatient episode, do not populate the "Attending Practitioner" field and designate this "Client B". Using "User Role Definition" add or edit a user role to give users access to the form being tested, to not allow customization and to designate the user role as a transcriber and set the "Default Author" to "Practitioner 3". Designate this "User Role A". Set up a user for each of the 8 practitioners using "User Definition". User 1 must be "Practitioner 1" and should not be a transcriber on the "Document Routing" section. User 2 must be "Practitioner 2" and should not be a transcriber on the "Document Routing" section. User 3 must be "Practitioner 3" and should not be a transcriber on the "Document Routing" section. User 4 must be "Practitioner 4" and should be designated a transcriber on the "Document Routing" section and should have "Practitioner 2" assigned as "Default Author" on the "Document Routing" section. User 5 must be "Practitioner 5" and should be assigned to "User Role A" and designated a transcriber on the "Document Routing" section. User 6 must be "Practitioner 6" and must be designated a transcriber but should have no "Default Author" defined on the "Document Routing" section. User 7 must be "Practitioner 7", should be assigned to "User Role A" and should be designated a transcriber and should have the "Default Author" set to "Practitioner 3" on the "Document Routing" section. User 8 must be "Practitioner 8", should be assigned to "User Role A" and should be designated a transcriber, the "Default Author" should be set to "Practitioner 2" on the "Document Routing" section. All users must be given access to the form being tested on the "Forms and Table" section of the "User Definition" form. All users must be set up to have a home view that contains the "MyToDo's" widget. Using the "Document Routing Setup" form, enable document routing and allow transcriber for the form being tested. Steps Test 1: User who is a transcriber, but has no default author assigned, client who has no attending practitioner. The result is the Select Author field will be blank. Login as "User 6". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate the "Select Author" field is blank. Set "Select Author" to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the author column is correctly populated with the author in the SQL table "DocR.transcriber". Test 2: User who is a transcriber, and has a default author assigned in the "User Definition" form, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" in the "User Definition". Login as "User 4". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 3: User who is a transcriber, is assigned to a default author assigned in the "User Definition" form, is also assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's default author from "User Definition". Login as "User 8". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 4: User who is a transcriber, is assigned to a user role that has default author assigned, and has the same default author assigned on the user definition form and client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Definition" form. Login as "User 7". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 5: User who is a transcriber, is assigned to a user role that has default author assigned, client who has an attending practitioner. The result is the Select Author field will default to the "Default Author" from the "User Role Definition". Login as "User 5". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 6: User who is a transcriber, is assigned to a user role that has a default author assigned and a client who does not have an attending practitioner. The result is the Select Author field will default to the user's user role default author from "User Role Definition". Login as "User 5". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 3". Log off and login as "User/Practitioner 3". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 7: User who is a transcriber, has no "Default Author" in "User Definition" and a client who does not have an attending practitioner. The result is the Select Author field will default to blank. Login as "User 6". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client B" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the note and sign it. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber". Test 8: User who is a transcriber, has no "Default Author" defined client who has an attending practitioner. Author rejected the initial note and returned to transcriber for corrections. Login as "User 6". Using the "Non Episodic Treatment Plan" form, generate a progress note for "Client A" and set it to final. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User/Practitioner 2". Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Reject the note to send it back to the transcriber. Log off and login as "User 6". Navigate to the "myToDo's" widget. Open the "Non Episodic Treatment Plan" form from the myToDo's item. Correct and finalize the note. Validate "Select Author" defaults to "User/Practitioner 2". Log off and login as "User 2". Finalize the progress note. Navigate to the "myToDo's" widget. Select the transcription note that has transferred to this practitioner. Finalize the progress note. Open the "Clinical Document Viewer" form. Validate the form displays and prints. Validate the "author" column is correctly populated with the author in the SQL table "DocR.transcriber".	Topics • NX • Non-episodic CWS user modeled form • Progress Notes (Group And Individual) • Treatment Plan
Update 13 Summary \| Details Avatar NX - Client Header Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Alerts (PM) Scenario 1: Avatar NX - Validate the 'See more...' text color in the Client Header Specific Setup: A client is enrolled in an existing episode (Client A). The 'Client Information' header should be included on the users myDay view. Steps Select "Client A" and access the 'Client Alerts' form. Select "Warning (Custom)" in the 'Type Of Alert' field. Select "All Forms" in the 'Applicable Forms' field. Enter the desired value in the 'Custom Message' field. Click [Submit]. Repeat steps 1-5 to create 3 additional client alerts. Once complete, navigate to the 'Client Header'. Validate the 'See more...' text is readable and displayed in white color. Mouse over the 'See more...' text and validate the client alerts created in the previous steps are displayed. Widget Wizard - Widget Deletion Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Widget Wizard (PM) Scenario 1: Widget Wizard - Validate ability to delete user created widgets that have been imported Specific Setup: A user created widget must be defined (Widget A). Steps Access the 'Widget Import' form. Click [Select Import File]. Select the "Widget A". Validate the 'Import Scan Results' field contains: No errors found. Click [Begin Import]. Validate a message is displayed stating: Import Complete. Click [OK] and close the form. Access the 'Widget Wizard' form. Click [Select Widget]. Select "Widget A" and click [OK]. Validate the data for "Widget A" is populated. Validate the 'Delete Widget' button is enabled. Click [Delete Widget]. Validate a message is displayed stating: Delete Widget "Widget A"? Click [Yes]. Click [Select Widget]. Validate "Widget A" is no longer displayed in the 'Select Widgets' dialog. Click [Cancel] and close the form.	Topics • Client Alerts • Widgets
Update 14 Summary \| Details Console Widgets - Military Time Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Console Widget Configuration (PM) Console Widget Configuration (CWS) Patient/Family Teaching Scenario 1: Console Widgets - Validate the 'Enable Military Time' registry setting for user modeled forms Specific Setup: The 'Enable Military Time' registry setting must be enabled. Please note: this must be done by a Netsmart Associate. A user modeled form is defined with a 'Time' field (Form A). A console widget must be configured for "Form A" in the 'Console Widget Configuration' form (Widget A). A view must be defined with "Widget A" and the 'Console Widget Viewer' (View A). A client must be enrolled in an existing episode (Client A). Steps Select "Client A" and access "Form A". Enter the desired time in the 'Time' field. Validate the time displays in military time format. Populate all other required and desired fields. Click [Submit] and close the form. Select "Client A" and navigate to "View A". Validate "Widget A" contains the record filed in the previous steps. Validate the 'Time' field displays in military time. Click [View]. Validate the 'Console Widget Viewer' displays the data filed in the previous steps. Validate the 'Time' field displays in military time. Click [Close All].	Topics • Console Widget • Modeling • Console Widget Configuration
Update 15 Summary \| Details Import Reports - "Report Description" field. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Import Reports (PM) Scenario 1: "Import Reports" Form - Field Validations Specific Setup: One or more "Crystal Report's" have been imported in the system using form "Import Reports". Steps Open the ‘Import Reports’ form. Select “Import Report as Form” in the ‘Select Import Type’ field. Select “Update Existing Report” in the ‘New or Existing Report’ field. Select the desired report in the ‘Existing Report’ dropdown. Validate the ‘Report Description’ field updated with the name of the report selected in the ‘Existing Report’ field. Select “Import New Report” in the ‘New or Existing Report’ field. Validate the ‘Report Description’ field has cleared as expected. With “Import Report as Form” still selected also select “Import Report for Document Routing” in the ‘Select Import Type’ field. Select “Update Existing Report” in the ‘New or Existing Report’ field. Select the desired report in the ‘Existing Report’ dropdown. Validate the ‘Report Description’ field updated with the name of the report selected in the ‘Existing Report’ field. Close the form. Open the ‘Import Reports’ form. Select “Import Report as Form” in the ‘Select Import Type’ field. Select “Yes” in the ‘Does This Report Require ODBC Connections In Addition To The Current Database’ field. Validate the "ODBC" section of the form is enabled and select a value in the "Connection Type" field. Select “Import Report for Document Routing” in the ‘Select Import Type’ field. Validate "Yes" is still selected in the ‘Does This Report Require ODBC Connections" field. Validate the "ODBC" section of the form is still enabled and select a value in the "Connection Type" field. De-Select “Import Report for Document Routing” in the ‘Select Import Type’ field. Validate "Yes" is still selected in the ‘Does This Report Require ODBC Connections" field. Validate the "ODBC" section of the form is still enabled and select a value in the "Connection Type" field. Select “No” in the ‘Does This Report Require ODBC Connections In Addition To The Current Database’ field. Validate the "ODBC" section of the form is removed from the form. Close the form.	Topics • Import Reports • NX
Update 16 Summary \| Details Results To Review To Do List - Removing ToDos Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Order Entry Console Notifications Setup Order Code Setup Order Entry Console - Interactions dialog Results Importing Scenario 1: Validate results in the Lab Results widget Steps Open the "Results Entry" form. File a header and then file details to enter a lab order for CBC. Validate you can see the order in the "Lab Results" Widget. Scenario 2: Lab Result ToDos Specific Setup: Using the "Notifications Setup" form: Enter a notification for the "Results" notification type. Set the "Notification Text" to "<FULL_NAME><PATID>. Enter a notification for the "Results (Abnormal)" notification type. Set the "Notification Text" to "<FULL_NAME><PATID> has new lab results (Abnormal)". Using the "Order Code Setup" form: Set up a lab order code called "Comprehensive Metabolic Panel (CMP)". Set up a lab order code called "Lipid Panel". Admit or select a test client into any episode. "Order Entry Console" must be set up on the user's homeview or associated home view. Steps Using the "Order Entry Console", enter a lab order for CMP. Complete the order, add it to the scratchpad and Sign the order. Note the order number. User the "Order Entry Console", enter a lab order for LIPID. Complete the order, add it to the scratchpad and Sign the order. Note the order number. Using the data from the orders entered into the "Order Entry Console", mockup an HL7 import file. Import the file using the "Results Importing" file. Results ToDos will be generated for the 2 orders included in the mocked up import file. Navigate to the "TodDo's" Widget. Mark the Results ToDo's as reviewed. Note the ToDo's are removed from the ToDo Widget.	Topics • Widgets • Results • NX
Update 17 Summary \| Details Internal Utilities Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Scenario 1: Envelope Export/Import Steps Internal Testing Only	Topics • Forms
Update 19 Summary \| Details Root system code creation Scenario 1: New "Root" System Code creation (Internal Only) - Table data validations Steps Internal Testing Only	Topics • Forms
Update 20 Summary \| Details Team File Import Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Team File Import Team Definition Scenario 1: Team Definition Import - Validations Specific Setup: Have a "Team Definition" import file that contains the "Team Finalizer" field populated [ImportA]. (Make a note of the "Team Description" and the user set in the file as the finalizer) Have a "Team Definition" import file that does not contain the "Team Finalizer" field populated [ImportB]. (Make a note of the "Team Description" set in the file) Have a report created to display data in the "SYSTEM.RADPlus_teams" table Steps Open form "Team File Import" Click [Select Import File] Navigate to the location of [ImportA] and select the file Validate the "Team Import File Scan Results" field indicates "No errors detected in import file." Close the form Open form "Team Definition" Click [Select Team] Validate [TeamA] is present in the list and select the team Validate the "Team ID" is populated. Note the value Validate "Team Description" is populated as expected based on the set up Validate the "Team Finalizer" field is populated as expected based on the setup Validate any other fields set in the import file are displayed as expected Close the form Open form "Team File Import" Click [Select Import File] Navigate to the location of [ImportB] and select the file Validate the "Team Import File Scan Results" field indicates "No errors detected in import file." Close the form Open form "Team Definition" Click [Select Team] Validate [TeamB] is present in the list and select the team Validate the "Team ID" is populated. Note the value Validate "Team Description" is populated as expected based on the set up Validate the "Team Finalizer" field is blank, as expected based on the setup Validate any other fields set in the import file are displayed as expected Close the form Run the report created to display data in the "SYSTEM.RADPlus_teams" table Validate a row for [TeamA] imported via [ImportA], is displayed Validate the "Team ID" is populated.with value noted in step 2a Validate "Team Description" is populated as expected based on the set up Validate the "Team Finalizer" field is populated as expected based on the setup Validate the other fields set in the import file are displayed as expected Validate a row for [TeamB] imported via [ImportB], is displayed Validate the "Team ID" is populated.with value noted in step 5a Validate "Team Description" is populated as expected based on the set up Validate the "Team Finalizer" field is blank, as expected Validate the other fields set in the import file are displayed as expected Modeled Form - service documentation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form With Service Documentation Appointment Move/Delete Scenario 1: Modeled Form with service documentation - Submission validations when filing a form as "Draft" for an Appointment Specific Setup: Have a modeled form configured and enabled for service documentation [TestClient] is enrolled in an episode and has two existing appointments [TestApptA] and [TestAppB] User has access to form "Appointment Move/Delete" Steps Access the modeled form. Select [TestClient] in the 'Select Client' dialog. Select "Existing Appointment" in the 'Data Row For' field. Select [TestAppt] in the 'Addresses Which Service/Appointment' field. Populate any other desired field Select "Draft" in the 'Draft/Final' field. Click [Submit]. Validate the form files successfully Access form "Appointment Move/Delete form" Select the practitioner for [TestAppt] Populate the "Appointment Start Time" and "Appointment End Time" fields s Select [TestClient] in the "Client ID" field Click the [Appointment Select] button Select the row for [TestAppt] in the "Appointment Move/Delete" selection dialog Click [OK] Click [Delete/Move Appointment] button Click [OK] Access the modeled form. Search for and select "Client A" in the 'Select Client' dialog. Select the row submitted in step 1 for edit Validate the "Draft/Final" field has "Draft" selected Validate 'Addresses Which Service/Appointment' field., no longer has [TestApptA] selected, as expected Click 'Addresses Which Service/Appointment' field Select [TestApptB] Validate the other data fields are now populated as expected, based on data filed for [TestApptB] Populate any other desired fields Submit the form Validate the form files successfully Return to the modeled form and select [TestClient] Select the row just submitted in step 3 Validate all fields are populated as expected Close the form 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 Order Entry User Definition Scenario 1: 'User File Import' - "Staff" user validations Specific Setup: Have a system with "Avatar Order Entry" installed Have an existing practitioner [StaffTest] who has not yet been assigned to any user in form "User Definition". In form "Practitioner Enrollment", select [StaffTest] and note the "ID#" assigned to the practitioner Create a "User File Import" file [ImportA], for a new user [UserA] Have the "Practitioner ID" field in the file populated with the "ID#" noted in the previous step Create a "User File Import" file [ImportB], for a new user [UserB] Leave the "Practitioner ID" field in file unpopulated Have a report created, to display data in the "SYSTEM.RADplus_Users" table User has access forms "User Definition" and the "Order Entry User Definition" Steps Open the 'User File Import' form. Click [Select User Import File]. Select [ImportA] Click [Open]. Validate the "Import File Scan Results" field indicates the file is ready for import Click [Process User Import File] Validate message "Import Completed" is displayed Click [OK]. Close the form Open form "User Definition" Select [UserA] Navigate to the "User Caseload" section Validate the "Staff Member" field is populated with name of [StaffA] and their "ID#" (noted in the setup) Close the form Open form "Order Entry User Definition" Search for [UserA] in the "Select Order Entry User" field Validate [UserA] is found, as expected Validate the "Staff Member" field is populated with [StaffA] and their "ID#", as expected Close the form Open the 'User File Import' form. Click [Select User Import File]. Select [ImportB] Click [Open]. Validate the "Import File Scan Results" field indicates the file is ready for import Click [Process User Import File] Validate message "Import Completed" is displayed Click [OK]. Open form "User Definition" Select [UserB] Navigate to the "User Caseload" section Validate the "Staff Member" field not populated, as expected Close the form Open form "Order Entry User Definition" Search for [UserB] in the "Select Order Entry User" field Validate [UserB] is not found, as expected Close the form Run the report to display data in the "SYSTEM.RADplus_Users" table Validate row is present for [UserA] Validate the "staff_member_ID" field is populated with "ID#" imported for [StaffA] in step 1, as expected Validate a row is present for [UserB] Validate the "staff_member_ID" field is blank, as expected Modeling - Table Alias fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (CWS) Scenario 1: Modeled Forms - Validate form submission when hiding fields using "Form Designer" Specific Setup: Have a modeled form that contains mapped "Table" aliased fields on the form For this example, a form [TestForm] has the following "Service" alias type fields mapped on the form which are necessary to file a service in the modeled form: "Date of Service", "Service Code", "Practitioner, Program", and "Duration" Have access to "Form Designer" Have a report created to display data in the "SYSTEM.Billing_tx_history" table Steps Open form "Form Designer" Select form [TestForm] Select the section containing the table aliased fields. Highlight the label and text box for "Duration" and uncheck the box On left side panel, uncheck the box named "Visible" Click [Save] Submit the form Open [TestForm] Select any client [TestClient] Complete Date of Service, Service Code, Practitioner, and Program. These are required. Complete any other prompts desired. Submit the form as "Final". Validate submission is blocked with an error message "Prompt mapped to Duration (Minutes) is missing." Close the form Open form "Form Designer" Select form [TestForm] Select the section containing the table aliased fields. Highlight the label and text box for "Duration" On the left side panel, check the box named "Visible" to unhide the field on the form Click [Save] Submit the form Open [TestForm] Select [TestClient] Complete "Date of Service", "Service Code", "Practitioner", and "Program". Submit as the form as "Final" Validate the form files successfully Generate the report to display the fields in the "SYSTEM.billing_tx_history" table for [TestClient] Validate a new row is found for the service created by the [TestForm] form in the previous steps Validate the "Date of Service", "Service Code", "Practitioner, Program", "Duration" and "Join_To_Tx_history" fields are populated as expected	Topics • NX • Service Documentation • User Definition • Modeling
Update 22 Summary \| Details Table Definition Scenario 1: Modeled Form - Validate results after submitting form and table definition changes Specific Setup: Have a modeled "Table" [TestTable] included in form [TestForm], that contains the following fields: [FieldA] Set in "Table Definition", with prompt "Always Required" set to "No" Set in "Form Definition", with prompt "Object Width" prompt set to "Half Screen" [FieldB] Set in "Table Definition", with prompt "Always Required" set to "No" Set in "Form Definition", with prompt "Object Width" prompt set to "Full Screen" [FieldC] Set in "Table Definition", with prompt "Always Required" set to "No" Set in "Form Definition", with prompt "Object Width" prompt set to "Full Screen" A "Draft/Final field" A "Workflow Controlling Notification" field. (Note: workflow notification fields are created in form "Notification Type Definition" and then become available as a column in "Table Definition") Any other desired fields Steps Open form [TestForm] Validate [FieldA] is display in "Half Screen" width and is not a required field, as per the setup Validate [FieldB] and [FieldC] are displayed in "Full Screen" width and are not required fields, as per the setup Validate all other fields display as expected Close the form Open form "Table Definition" Select table [TestTable] Select [FieldB] Set prompt "Always Required" to "Yes" Submit the form Open form [TestForm] Validate [FieldA] is still displayed in "Half Screen" width and is not a required field Validate [FieldB] is still displayed in "Full Screen" width and is now displayed as a required field, as expected Validate [FieldC] is still displayed in "Full Screen" width and is not a required field Validate all other fields display as expected Close the form Open form "Form Definition" Select form [TestForm] Select [FieldB] Set prompt "Object Width" prompt set to "Half Screen" Submit the form Open form [TestForm] Validate [FieldA] is still displayed in "Half Screen" width and is not a required field Validate [FieldB] is now displayed in "Half Screen" width and is still displayed as required, as expected Validate [FieldC] is still displayed in "Full Screen" width and is not a required field Validate all other fields display as expected Close the form Open form "Table Definition" Select table [TestTable] Click [Add New Item] Select a "Column" type Populate the "Column Name" with the new field [FieldD] Populate any other required fields Submit the form Open form "Form Definition" Select form [TestForm] Select [FieldB] Click to the "Object Def" section Click [Add New Item] Select [FieldD] Submit the form Open form [TestForm] Validate [FieldA] is still displayed in "Half Screen" width and is not a required field Validate [FieldB] is now displayed in "Half Screen" width and is still displayed as required, as expected Validate [FieldC] is still displayed in "Full Screen" width and is not a required field Validate [FieldD] is displayed on the form Populate the field Populate all the fields on the form Submit the form Validate the form files successfully	Topics • Modeling
Update 23 Summary \| Details State Form Task Scheduler Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form Task Scheduler Scenario 1: Scheduling a "State Form Definition" file(s) to be sent to an "FTP" Server (File Type - 'SFTP-Password') Specific Setup: Have two state form definition files created in form "State Form Definition" [DefA] and [DefB] In form "State Form Definition", [DefA] and [DefB] have the following fields populate: The "File Path" field is populated with a directory location [FileLocation], that exists on the logged in users workstation In form "State Form Batch Creation" a batch file [Batchfile], has been created that contains state form definition files [DefA] and [DefB] Have an "FTP Server" set up to receive files Have the following "FTP Server" information available in order to populate the "State Form Task Scheduler" form during testing: The "Service Directory" location The "Server Host Name" The "Server Port Number" The "Server Username" field The "Server Password" field Steps Open the 'State Form Task Scheduler' form Select [DefA] Select "Yes" in the "Create File" field Select "Yes" in "Send File To FTP Server" field In the "FTP Type" field, select "SFTP - Password" Based on the valid FTP values stated in the setup, populate the following required fields: "Server Host Name" "Server Port Number" "Server Username" "Server Password" "Service Directory" Click [Test FTP Connection] Validate test is successful For each FTP field populated in step 1e, enter an invalid value Click [Test FTP Connection] Validate the test is not successful Set the field back to the valid entry Submit the form Validate the form files successfully Open form "System Task Scheduler" Select the task set up for [DefA] in step 2 from the "Schedule(s)" field Populate the "Recurrence Pattern" field with desired value Populate the "Task Occurrence" field with the desired value Populate the "Start By" field with the desired date for the task to start Populate the "Start Time" field with the desired time for the task to start Select "No" in the "Inactive Task" field Click [Schedule Task] Close the form When the scheduled start by date and time for task filed in step 3 has passed: Validate the state form file [DefA] exists in the folder [FileLocation] on the logged in users server, set in step1 Open the file Validate data results are as expected Validate the state form file [DefA] exists in the [Service Directory] location on the "FTP" server, specified in step 1e Open the file Validate date results are as expected Repeat steps 1 and 2, selecting the batch file [DefB] When the scheduled start by date and time for task filed has passed: Validate the state form file(s) [DefA] and [DefB] exists in the folder [FileLocation] on the logged in users server, set in step1 Open each file Validate data results are as expected Validate the state form file [DefA] and [DefB] exists in the [Service Directory] location on the "FTP" server, specified in step 1e Open each file Validate date results are as expected State Form Task Scheduler Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form File Generation State Form Task Scheduler Scenario 1: "State Form Task Scheduler" - Scheduled a task for a' State Form Definition' file (Create File - No) Specific Setup: Have a state form definition file created in form "State Form Definition" [DefinitionA] with the "File Path" field populated with a valid folder location on the Avatar server. Make note of the folder location Steps Open form "State Form Task Scheduler" Select "Single Definition" in the "Type" field Select the [DefinitionA] from the "Select Batch or Definition" drop down list Set field "Create File" to "No" Set the "File Description" field to a desired file name Select "Static" in the "Change From Date" Set the "Static Date" field to today's date Select "Static" in the "Change Through Date" Set the "Static Date" field to today's date Select "Yes" in the "Create File" field Click [Submit] At the dialog, "Filed. In order for compiles to be run, the new task must be scheduled using the 'System Task Scheduler' form", click [OK] Open the "System Task Scheduler" form In the "Schedule(s)" field, select the task created in step for [DefinitionA] in step 1 Select a desired recurrence type pattern from the "Recurrence Pattern" field. For example "Daily" Populate a desired value in the "Task Occurrence Sequence". Populate the "Start By" field with today's date Populate the "Start Time" field with a time later than the current time Click [Schedule Task] Close the form Wait till the "Start Time" set in step 2 has passed Open the "State Form File Generation" form. Select [DefinitionA] in the "State Form" field Select "Dump File" in the "File Generation Options" field In the "Select File" field, select the compiled file for [DefinitionA], generated by the automated task set up in step 2 Click [Process] Validate data displayed on the report is as expected On the Avatar server: Navigate to the folder location noted in the setup, where the state form file was set to be created Validate no file was generated, as expected since field "Create File" was set to "No" in step 1c	Topics • State Form Task Scheduler • NX
Update 24 Summary \| Details Console Widget Viewer - Printing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Console Widget Viewer Scenario 1: Console Widget Viewer - validate print preview and print output Specific Setup: 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 client is enrolled in an existing episode (Client A). "Client A" has data filed in various forms: A diagnosis entry (Diagnosis A) A Problem (Problem List A) Please note: This is for Avatar NX systems only. Steps Select "Client A" and navigate to the 'All Documents' view. Select 'All Forms'. Select the first desired form, for example "Diagnosis A". Click [Print] and [Print Current]. Validate the 'Print' dialog displays a header containing the client, episode, and submission information at the top. Click [Cancel]. Select several other desired forms. Click [Print] and [Print All]. Validate the 'Print' dialog displays a header containing at least the client name and there are no empty headers. Please note: Certain forms do not generate a full form header containing client, episode, and submission information, but the client name will always display. Click [Print]. Validate the printed forms display as expected, without any truncation. Scenario 2: Console Widget Viewer - Progress Notes Specific Setup: A client is enrolled in an existing episode (Client A). A user must have a console widget configured for Progress Notes in the 'Console Widget Configuration' form. A user must have a view configured containing the Console Widget and Console Widget Viewer (View A). The 'Limit Console Widget Viewer To Text Only' registry setting must be enabled. Please note: This is for Avatar NX systems only. Steps Access 'Progress Notes (Group and Individual)' for "Client A". Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Draft" in the 'Draft/Final' field. Submit the note. Select "Client A" and navigate to "View A". Validate the 'Progress Notes' console widget contains the draft note filed in the previous steps and select it. Click [View]. Validate the 'Console Widget Viewer' displays the draft progress note details filed in the previous steps as text. Click [Print] and [Print Current]. Validate the 'Print' dialog displays a header containing the client, episode, and submission information at the top. Close the dialog. Click [Open Record]. Validate the draft note is opened. Select "Final" in the 'Draft/Final' field. Submit the note. Select "Client A" and navigate back to "View A". Validate the 'Progress Notes' console widget contains the finalized note filed in the previous steps and select it. Click [View]. Validate the 'Console Widget Viewer' displays the finalized progress note details filed in the previous steps as text. Click [Open Record]. Validate a message is displayed stating "This note is already set to 'Final'." Click [OK] and validate the finalized note is not displayed. Scenario 3: Console Widget Viewer - Treatment Plan Specific Setup: A client is enrolled in an existing episode (Client A). A user must have a console widget configured for the Treatment Plan in the 'Console Widget Configuration' form. A user must have a view configured containing the Console Widget and Console Widget Viewer (View A). Please note: This is for Avatar NX systems only. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field. Select "Draft" in the 'Treatment Plan Status' field. Click [Launch Plan]. Add any problem. Click [Return To Plan] and [OK]. Submit the form. Select "Client A" and navigate to "View A". Validate the 'Treatment Plan' console widget contains the draft treatment plan filed in the previous steps and select it. Click [View]. Validate the 'Console Widget Viewer' displays the draft treatment plan details filed in the previous steps. Click [Print] and [Print Current]. Validate the 'Print' dialog displays a header containing the client, episode, and submission information at the top. Close the dialog. Click [Open Record]. Validate the draft treatment plan is opened. Select "Final" in the 'Treatment Plan Status' field. Submit the note. Select "Client A" and navigate back to "View A". Validate the 'Treatment Plan' console widget contains the finalized treatment plan filed in the previous steps and select it. Click [View]. Validate the 'Console Widget Viewer' displays the finalized treatment plan details filed in the previous steps. Click [Open Record]. Validate a message is displayed stating "This plan is marked as Final. Changes are not allowed. Do you want to continue?" Click [No]. Scenario 4: 'All Documents' widget - Validate 'Diagnosis' records Specific Setup: 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). Please note: This is for Avatar NX systems only. Steps Select "Client A" and access the 'Diagnosis' form. Select "Admission" in the 'Type Of Diagnosis' field. Enter the desired time in the 'Time Of Diagnosis' field. Click [New Row]. Select the desired value in the 'Diagnosis Search' field. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Select "Client A" and navigate to the 'All Documents' view. Select 'All Forms'. Select "Diagnosis" in the 'Form Description' field. Validate the entry from the previous steps is present. Validate the 'Time' field displays. Select the entry and validate it displays in the 'Console Widget Viewer'. Click [Print] and [Print Current]. Validate the 'Print' dialog displays a header containing the client, episode, and submission information at the top. Close the dialog.	Topics • NX • All Documents Widget • Progress Notes (Group And Individual) • Console Widget • Treatment Plan • Diagnosis
Update 25 Summary \| Details Document Routing - Approver Comments Scenario 1: Document Routing (Progress Notes) - (Accept / Route) Documents with 'Approval Comments' Specific Setup: Have a "Progress Notes" form [TestForm], for example form "Progress Notes (Group and Individual)", that has been enabled for document routing in form "Document Routing Setup" and has prompt "Allow Comments During Approval" to "Yes" [TestForm] includes a "Signature" field Have three users: [StaffA] and [StaffB] are staff members and have the "My To Do's" widget on their home view [StaffC] is a staff member and has the 'Co Signer for Other Practitioners' prompt in the document routing section set to 'Yes'.in form 'User Definition' All three users are set with the "My To Do's" widget on their home view Have a report to display data in the "SYSTEM.DocR.comments" table Log in as [StaffA] Steps Open form [TestForm] and select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept] Provide the password and click [Verify] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document submitted in step 1. Validate the "Signature" field on the document is populated with signature noted in step 1. Validate the "Comments" entered and noted in step 1, are displayed as expected At the bottom of the document, validate that the document includes the "Electronically Signed By:" field, populated with name of [StaffA] Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate a row is present for the "Approval Comments" entered in step 1 and is displayed as expected Open [TestForm] and a select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept and Route] At the "Route To Document" screen, add [StaffA], [StaffB] and [StaffC] as approvers Click [Submit] Log out as [StaffA] Log in as [StaffB] Navigate the "My To Do's widget Click on the "New" tab and validate the To Do sent in step 4, is present Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes two "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" and below it, [StaffB] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment Click [OK] Log out as [StaffB] Log in as [StaffC] Navigate the "My To Do's widget Click on the "Sign" tab In the "Staff" search field, search for [StaffA]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do sent to [StaffA] is found, select the To Do to review it Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Click [Sign All] Validate the To Do is removed from the To Do list Navigate back to the "My To Do's" widget Click on the "Sign" tab In the "Staff" search field, search for [StaffC]. Validate the To Do sent to [StaffC] in step 4 is present, select the To Do Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author", [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document that was just created in the previous step Validate the "Signature" field on the document is populated with signature noted in step 10 Validate the "Comments" entered noted in step 10, are displayed as expected At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author" [StaffB] signed as "Staff" Validate the comments entered by [StaffB] are entered in step 7 are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffA]) Validate the comments entered by [StaffC] in step 9, are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffC]) Validate the comments entered by [StaffC] in step 10, are displayed as expected Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate the following rows are present on the report, displayed as expected: A row displaying the "Approval Comments" entered in step 1 by [StaffA] A row displaying the "Approval Comments" entered in step 7 by [StaffB] A row displaying the "Approval Comments" entered in step 9 by [StaffC] when signing for [StaffA] A row displaying the "Approval Comments" entered in step 10 by [StaffC], signing as [StaffC] Document Routing - Signature Images Scenario 1: Document Routing - (Accept / Route) Documents with 'Approval Comments' Specific Setup: Have a form [TestForm], for example a "Modeled" form or "Treatment Plan" form that has been enabled for document routing in form "Document Routing Setup" and has prompt "Allow Comments During Approval" to "Yes" [TestForm] includes a "Signature" field Have three users: [StaffA] and [StaffB] are staff members and have the "My To Do's" widget on their home view [StaffC] is a staff member and has the "Co Signer for Other Practitioners" prompt in the document routing section set to 'Yes'.in form 'User Definition' All three users have the "My To Do's" widget on their home views Have a report to display data in the "SYSTEM.DocR.comments" table Log in as [StaffA] Steps Open form [TestForm] and select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept] Provide the password and click [Verify] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document submitted in step 1. Validate the "Signature" field on the document is populated with signature noted in step 1. Validate the "Comments" entered and noted in step 1, are displayed as expected At the bottom of the document, validate that the document includes the "Electronically Signed By:" field, populated with name of [StaffA] Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate a row is present for the "Approval Comments" entered in step 1 and is displayed as expected Open [TestForm] and a select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept and Route] At the "Route To Document" screen, add [StaffA], [StaffB] and [StaffC] as approvers Click [Submit] Log out as [StaffA] Log in as [StaffB] Navigate the "My To Do's widget Click on the "New" tab and validate the To Do sent in step 4, is present Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes two "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" and below it, [StaffB] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment Click [OK] Log out as [StaffB] Log in as [StaffC] Navigate the "My To Do's widget Click on the "Sign" tab In the "Staff" search field, search for [StaffA]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do sent to [StaffA] is found, select the To Do to review it Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Click [Sign All] Validate the To Do is removed from the To Do list Navigate back to the "My To Do's" widget Click on the "Sign" tab In the "Staff" search field, search for [StaffC]. Validate the To Do sent to [StaffC] in step 4 is present, select the To Do Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author", [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document that was just created in the previous step Validate the "Signature" field on the document is populated with signature noted in step 10 Validate the "Comments" entered noted in step 10, are displayed as expected At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author" [StaffB] signed as "Staff" Validate the comments entered by [StaffB] are entered in step 7 are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffA]) Validate the comments entered by [StaffC] in step 9, are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffC]) Validate the comments entered by [StaffC] in step 10, are displayed as expected Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate the following rows are present on the report, displayed as expected: A row displaying the "Approval Comments" entered in step 1 by [StaffA] A row displaying the "Approval Comments" entered in step 7 by [StaffB] A row displaying the "Approval Comments" entered in step 9 by [StaffC] when signing for [StaffA] A row displaying the "Approval Comments" entered in step 10 by [StaffC], signing as [StaffC]	Topics • Progress Notes • NX • Modeling
Update 26 Summary \| Details SQL table permissions Scenario 1: User Definition - Validate a user's SQL "ODBC" Table permissions Specific Setup: Two users exist on the system that have the same "User ID", but which differ by where the period within their user ID is placed. For this example: "U.serA" and "User.A" "U.serA" has access to the "SYSTEM.patient_current_demographics" table "U.serA" does not have access "SYSTEM.Admission_data" and "SYSTEM.Appoinment_data" table "User.A" also has access to "SYSTEM.patient_current_demographics" table "User.A" does have access to the "SYSTEM.Admission_data" and "SYSTEM.Appiontment_data" tables' Each user has access to 'Crystal Reports" or other database program to make an ODBC connection and view their assigned SQL Table Steps Open the database program, for this example "Crystal Reports" is used Click "File" on the menu and then "New" to create a new report At the "Data" dialog, click "Create New Connection" Double-click "ODBC" From the "Data Source Selection" dialog, locate the data source name created for user ID "U.serA" and double-click to select it Populate the "User ID" field and "Password" with the credentials for "U.serA" Click "Finish" At the table tree list Click the "SYSTEM" schema folder and then click "Tables" Validate the "SYSTEM.patient_current_demographics' table is present in the list Validate the "SYSTEM.Admission_data" and "SYSTEM.Apppintmentt_data" tables are "not" present, as expected Click 'Cancel" Click "File" on the menu and then "New" to create a new report At the "Data" dialog, click "Create New Connection" Double-click "ODBC" From the "Data Source Selection" dialog, locate the data source name created for user ID "User.A" Populate the "User ID" field and "Password" with the credentials for "User.A" Click "Finish" At the table tree list At the table tree list Click the "SYSTEM" schema folder and then click "Tables" Validate the "SYSTEM.patient_current_demographics' table is present in the list Validate the "SYSTEM.Admission_data" and "SYSTEM.Appointment_data" tables "are" present, as expected	Topics • SQL Data Access
Update 28 Summary \| Details Support is added for other products and modules Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Appointment Management Staff Members Hours And Exceptions Scenario 1: Progress Notes (Group and Individual) - Validate the 'Enable Treatment Plan Grid' registry setting Specific Setup: A client must have a Treatment Plan filed with a problem, goal, objective, and intervention associated (Client A). The 'Progress Notes' widget is on the HomeView for the logged in user. Steps Access the 'Registry Settings' form. Enter "Enable Treatment Plan Grid" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings] Select "Enable Treatment Plan Grid" for 'Progress Notes (Group and Individual)' from the 'Registry Setting' list. Click [OK]. Validate the 'Registry Setting Details' field contains "Enter "Y" to add 'Treatment Plan' grid field to the form. Enter "YD" to add the grid field and enable the functionality to default the previously selected treatment plan to the new row. Enter "N" to remove the field from the form." Enter "Y" in the 'Registry Setting Value' field. Click [Submit]. Validate a "Registry Editor Filing" message is displayed stating: Successful filing. Click [OK]. Validate a "Form Return" message is displayed stating: Submitting has completed. Do you wish to return to form? Click [No]. Access the 'Progress Notes (Group and Individual)' form. Verify the 'Treatment Plan' grid is displayed. Enter "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select any value in the 'Note Type' field. Click [New Row] in the 'Treatment Plan' grid. Select the desired Treatment Plan in the 'Select T.P. Version' field. Click [View] in the 'Select T.P. Item Note Addresses' field. Verify the 'Treatment Plan' window is displayed with "Client A's" treatment plan(s). Select the desired treatment plan item in the 'Treatment Plan' window. Click [Return]. Validate the 'Note Addresses Which Treatment Plan Problem' field contains the Treatment Plan item selected in the previous step. Enter the desired value in the 'T.P. Item Notes/Documentations' field. Enter the desired value in the 'Notes Field' field. Select "Draft" in the 'Draft/Final' field. Click [File Note]. Validate a "Progress Notes" message is displayed stating: Note Filed. Click [OK]. Validate the 'Treatment Plan' grid no longer contains the previously filed row. Select the note filed in the previous steps in the 'Select Draft Note To Edit' field. Validate the 'Treatment Plan' grid contains the row filed in the previous steps. Click [New Row] in the 'Treatment Plan' grid. Validate the 'Select T.P. Version' field does not contain a value. Select the second row in the 'Treatment Plan' grid. Click [Delete Row]. Validate a "Confirm" message is displayed stating: Are you sure you want to delete these rows? Click [Yes]. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a "Progress Notes" message is displayed stating: Note Filed. Click [OK] and close the form. Access the 'Registry Settings' form. Enter "Enable Treatment Plan Grid" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings] Select "Enable Treatment Plan Grid" for 'Progress Notes (Group and Individual)' from the 'Registry Setting' list. Click [OK]. Enter "YD" in the 'Registry Setting Value' field. Click [Submit]. Validate a "Registry Editor Filing" message is displayed stating: Successful filing. Click [OK]. Validate a "Form Return" message is displayed stating: Submitting has completed. Do you wish to return to form? Click [No]. Access the 'Progress Notes (Group and Individual)' form. Verify the 'Treatment Plan' grid is displayed. Enter "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select any value in the 'Note Type' field. Click [New Row] in the 'Treatment Plan' grid. Select the desired Treatment Plan in the 'Select T.P. Version' field. Click [View] in the 'Select T.P. Item Note Addresses' field. Verify the 'Treatment Plan' window is displayed with "Client A's" treatment plan(s). Select the desired treatment plan item in the 'Treatment Plan' window. Click [Return]. Validate the 'Note Addresses Which Treatment Plan Problem' field contains the Treatment Plan item selected in the previous step. Enter the desired value in the 'T.P. Item Notes/Documentations' field. Click [New Row] in the 'Treatment Plan' grid. Validate the 'Select T.P. Version' field defaults in with the value selected in the first row. Click [View] in the 'Select T.P. Item Note Addresses' field. Verify the 'Treatment Plan' window is displayed with "Client A's" treatment plan(s). Select the desired treatment plan item in the 'Treatment Plan' window. Click [Return]. Validate the 'Note Addresses Which Treatment Plan Problem' field contains the Treatment Plan item selected in the previous step. Enter the desired value in the 'T.P. Item Notes/Documentations' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a "Progress Notes" message is displayed stating: Note Filed. Click [OK] and close the form. Select "Client A" and navigate to the 'Progress Notes' widget. Validate the progress notes filed in the previous steps are displayed. Validate the rows filed in the 'Treatment Plan' grid are displayed. Scenario 2: Enhanced Appointment Management Grid - Validate scheduling/posting individual appointments Specific Setup: A client is enrolled in an existing episode (Client A). A practitioner has hours defined for scheduling (Practitioner A). The 'Enable Enhanced Appointment Management Grid' registry setting is set to "Y". Steps Access the 'Appointment Management' form. Select "Practitioner A" in the 'Practitioner' field. Enter the current date in the 'Appointment Start Date' and 'Appointment End Date' fields. Click [Add/Edit Appointments]. Validate the 'Appointment Management' grid is displayed and contains any existing appointments for the current date. Click [New Row]. Enter the desired time in the 'Start' field. Enter the desired duration in the 'Duration' field. Validate the 'End' field is calculated based on the start time/duration of the appointment. Enter "Practitioner A" in the 'Practitioner' field. Enter the desired value in the 'Service Code' field. Enter "Client A" in the 'Client' field. Check "Post" for the appointment for "Client A". Click [Save] and validate the grid closes. Close the form. Access the 'Client Ledger' form. Select "Client A" in the 'Client ID' field. Select "All Episodes" in the 'Claim/Episode/All Episodes' field. Select "Simple" in the 'Ledger Type' field. Select "Yes" in the 'Include Zero Charges' field. Click [Process]. Validate the report contains the posted visit for "Client A". Close the report and the form. Scenario 3: Diagnosis - Add new / Add to Problem List Specific Setup: A client must be enrolled in an existing episode (Client A). A practitioner must be defined (Practitioner A). Steps Select "Client A" and access the 'Diagnosis' form. Click [Add] if present. Select any value for the 'Type of Diagnosis' field. Enter the desired values for the 'Date of Diagnosis' and 'Time of Diagnosis' fields. Click [New Row]. Enter and select the desired value in the 'Diagnosis Search' field. Select "Practitioner A" in the 'Diagnosing Practitioner' field. Populate any desired and required fields. Select "Yes" in the 'Add to Problem List' field. Submit the form. Select "Client A" and access the 'Problem List' form. Click [Enter Problems]. Validate the new diagnosis is included. Click [View - DSM/IDC Code]. Validate a dialog opens with the DSM/IDC code data for the problem. Close out of the dialog. Click [View - System Notes]. Validate the dialog displays the user information for the problem. Close out of the dialog. Click [Close/Cancel]. Close the form. Scenario 4: Site Registration - Add a site with hours of operation Specific Setup: Please note: This is for Avatar NX systems only. Steps Access the 'Site Registration' form. Enter any value in the 'Select Site' field (Site A). Click [New Site]. Validate a 'Site' dialog stating: "Auto Assign Next ID Number?" Click [Yes]. Validate the 'Site Name' field contains "Site A". Enter the desired value in the 'Site Registration Date' field. Populate all required and desired fields. Select "Yes" in the 'Copy Information From An Existing Site?' field. Validate a 'Warning' dialog stating: "Copying information from an existing site will overwrite current 'Site Registration' Information. You must file this form prior to viewing/editing the 'Site Registration' information. Do you want to continue?" and click [Yes]. Validate the 'Select Existing Site' field is enabled and required. Select "No" in the 'Copy Information From An Existing Site?' field. Validate the 'Select Existing Site' field is disabled. Select "All" in the 'Associated Programs' field. Verify the 'Time Zone' field is present and required. Select the desired value in the 'Time Zone' field. Click [Site Hours of Operation]. Add the desired hours of operation and click [Save]. Validate an 'Exit Grid' dialog stating: "Save Successful." and click [Yes]. Click [Submit]. Access the 'Site Registration' form. Enter "Site A" in the 'Select Site' field. Validate the form populates with the values entered in the previous steps. Close the form. Scenario 5: 'Staff Members Hours and Exceptions' - Verification of 'Staff Member Hours' Information Entry/Filing Specific Setup: A staff member must be defined in 'Practitioner Enrollment' (Staff Member A). Steps Access the 'Staff Members Hours and Exceptions' form for "Staff Member A". Click [Staff Member Hours]. Validate the 'Staff Member Hours' grid is displayed. Click [New Row]. Enter the desired date in the 'Effective Date' field. Select the desired day in the 'Day' field. Select the desired site in the 'Site' field. Enter the desired times in the 'Start Time' and 'End Time' fields. Populate any other desired values. Click [Save], [Yes], and [Submit]. Access the 'Staff Members Hours and Exceptions' form for "Staff Member A". Click [Staff Member Hours]. Validate the 'Staff Member Hours' grid is displayed. Validate the hours entered in the previous steps are displayed as expected. Close the form.	Topics • Progress Notes • Appointment Management • Diagnosis • Site Registration • Practitioner
Update 29 Summary \| Details My To Do's Widget - Client name Scenario 1: Validate display of the clients name in the "My To Do's" widget Specific Setup: In form "Dictionary Update", have the "Client Prefix (175)" and the "Client Suffix (174)" dictionary's, populated with dictionary values. Have clients admitted on the system defined that have client names in the following formats:: [ClientA] has just a "first and last name" defined. [ClientB] has a "first name, middle name, last name" defined. [ClientC] has a "first name, middle name, last name and a suffix" defined. [ClientD] has a "prefix, first name, middle name, last name" defined. [ClientE] has a "prefix, first name, middle name, last name and a suffix defined. Have a user [TestUser] who is a staff member and has the "My To Do's" widget on their home view For each client in step 2, have a "To Do" item generated and sent to [TestUser]. (For example, this can be done using form "Send To Do Notification" or any form enabled for document routing) Log in as [TestUser] Steps Navigate to the "My To Do's" widget In the "Client" column, locate the To Do generated for [ClientA] Validate the clients name displays in the format "First Name Last Name" as expected Click "Review To Do Item" in the "Action" column to launch the "Review To Do Item" form Validate the "Client Header" displays the name as expected, in the format "First Name Last Name" Click the "Reviewed" check box Submit the form Validate the To Do is removed from the To Do's list In the "Client" column locate the To Do generated for [ClientB] Repeat step 1a, Validate results are as expected, ensuring the clients name displays in the format, "First Name Middle Name Last name" In the "Client" column locate the To Do generated for [ClientC] Repeat step 1a Validate results are as expected, ensuring the clients name displays in the format, "First Name Middle Name Last name Suffix" In the "Client" column locate the To Do generated for [ClientD] Repeat step 1a Validate results are as expected, ensuring the clients name displays in the format, "Prefix First Name Middle Name Last Name" In the "Client" column locate the To Do generated for [ClientE] Repeat step 1a Validate results are as expected, ensuring the clients name displays in the format, "Prefix First Name Middle Name Last name Suffix"	Topics • NX
Update 30 Summary \| Details All Doc Widget - Time field Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: LookupTypes UserModeledFormA Scenario 1: 'All Documents' widget - Modeled 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 the "Primary All Documents Widget" on the users home view [FormA] and [FormB] have been added to the "All Forms" tab of the widget using form "All Documents Widget Definition" [FormB] have been added to the "All Forms" tab of the widget using form "All Documents Widget Definition" Please note: The "Primary All Documents Widget" is for Avatar NX systems only. Steps Select a client [TestClient] Open [FormA] (Modeled Form 'Date Sorted') Select an episode Populate any desired fields Submit the form Validate the form files successfully Note the data entry date and time Open [FormB] (Modeled form not 'Date Sorted') Select an episode Populate any desired fields Submit the form Validate the form files successfully Note the data entry date and time At the home view, select [TestClient] Navigate to the "Primary All Documents Widget" and click the "Refresh" button Click the "All Forms" tab Select [FormA] from the 'Form Description' field. Validate the "Form Description" field is populated with the form name for [FormA] Select the episode from the "Episode" field Validate the "Date" column is populated with date noted in step 2 Validate the "Time" field is 'not' populated, as expected Validate each of the columns are populated, as expected Select [FormB] from the 'Form Description' field. Validate the "Form Description" field is populated with the form name for [FormB] Select the episode from the "Episode" field Validate the "Date" column is populated with date noted in step 3 Validate the "Time" field is populated, as expected with time noted in step 3 Validate each of the columns are populated, as expected	Topics • All Documents Widget
Update 31 Summary \| Details Client Purge Setup - Deleting record Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Purge Setup Scenario 1: Client Purge Setup - Define Exception Rules - Adding / Deleting rules Specific Setup: User Definition: The 'Client Purge Setup' form is available in the list of forms. The 'Client Purge Setup' form is selected to enable them in the Avatar menu. Steps Open the 'Client Purge Setup' form. Enter the number of years since the last movement or service for a client to be eligible for purge in the field ‘Years After Last Contact to Be Excluded From Purge’. In the field 'Months After Last Payment/Adjustment To Be Eligible From Purge', enter the number of months since the last payment/adjustment a client should have to be eligible for purge. In the ‘Default Reason for Exclusion’ field, select a default reason value to be used by the purge form when clients qualified to be purged are manually excluded. Click [Define Exception Rules]. Verify the grid opens successfully. Enter one exception rule to be used by the 'Client Purge' form. Enter the name of the table to be used for the exception criteria in the 'System Table' field. Enter the name of the field to be used for the exception criteria in the 'Field' field. Enter one of the operators to be used for the exception criteria in the 'Conditional' field. Note - The ‘BT’(Between) conditional requires a properly formatted value in the ‘Field Value’ column formatted as number, comma, number. When the ‘Exists’ conditional is selected the ’Field Value’ column is not required but it remains a required field for all other conditionals. Enter desired value in the 'Field Value' field. Enter desired value in the 'Record Selection' field, select 'Most Recent’ to use the most recent records regardless of the date and time. Select ‘Past (Minutes)’ to use only records from today created in the past minutes as defined in the field ‘Record Selection Range (Minutes)’. In the field ‘Record Selection Range (Minutes)’, enter the number of minutes to be used when evaluating a Record Selection defined as ‘Past (Minutes)’ Ensure the field ‘Record Selection Date Field’ displays only date properties and will default to the data entry date field if it exists in the table. Click [Save]. Click [Yes]. Click [Submit]. Open the 'Client Purge Setup' form. Click [Define Exception Rules]. Verify the exception rule created displays correctly as entered. Select the rule. Click [Delete]. Click [Save]. Click [Submit]. Open the 'Client Purge Setup' form. Click [Define Exception Rules]. Verify the exception rule does not display and deleted permanently. Close the grid. Click [Discard].	Topics • RADplus Utilities
Update 32 Summary \| Details Form Designer - field labels Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Scenario 1: Envelope Import (with Form Designer changes) - Field validations after import Specific Setup: Have an existing modeled envelope [TestEnvelope] that contains a form [TestForm] that includes a "Date" type field and any other desired field types Using "Form Designer", edit [TestForm] and navigate to any field [TestField] on the form. Edit the field label name of the field to include a '~' tilde character within the field label name. For example a field label name of "Te~stField" Steps Open form [TestForm] Navigate to [TestField] Validate the form designer change to add a '~' tilde character within the field label name, is displayed as expected Navigate to the "Date" field Enter a desired date Click the 'T' and 'Y' buttons of date field Validate the date field reflects the expected value Click the 'Calendar' icon and select a date Validate the date field reflects the expected value Populate any other fields on the form Submit the form Validate the form files successfully Open form "Envelope Export" Select [TestEnvelope] for export Select "Yes" in prompt "Include Form Design Changes" Click to [Export] the file and save the file to a folder location Validate the export is successful Close the form Open form "Envelope Import" Click [Select Envelope For Import] Navigate the location of export file for [TestEnvelope] saved in step 2 Select the file Select "Yes" in prompt "Include Form Design Changes" In the "Overwrite Existing Envelope or Create New Envelope" field, select "Create New" At the dialog prompt, "This envelope already exists within this system. Are you sure that you would like to create a new envelope?" Click [Yes] Click [Begin Import Scan] In the "Import Scan Results" field, validate there are the following warnings: Warning: Envelope The import file contains an envelope name which is already in use. The import process will assign a new envelope name based upon the existing name and a counter. Warning: Table: The import file contains a table name which is already in use. The import process will assign a new table name based upon the existing name and a counter. Click [Begin Import] Validate the following "Import" warning is received Import: The envelope to be imported is currently defined and can be imported as an 'Overwrite' with no errors. Selecting 'Create New' may cause conflicts in future envelope imports. Are you sure that you want to 'Create New'? Click [Yes] Validate import is completed successfully Close the form Open "Form Definition" and select the new import version of [TestForm]. Note: the new copy form will have the same name as the original, but the (ID#) of the form next to the form name will be a higher number Rename the form to a desired name [TestFormNew] and submit the form Open the new form [TestFormNew] Navigate to [TestField] Validate the form designer change, to add a '~' tilde character within the field label name, is displayed as expected Navigate to the "Date" field Enter a desired date Click the 'T' and 'Y' buttons of date field Validate the date reflects the expected value Click the 'Calendar' icon and select a date Validate the date field reflects the expected value Populate any other desired fields on the form Submit the form Validate the form files successfully Repeat step 5 for the original version of the form [TestForm] Validate results are as expected Form Designer - Date field components Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Internal Test Only Form Designer- ScriptLink settings Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (CWS) Scenario 1: Form Designer (Export/Import) - Validate "ScriptLink" configuration" settings after form designer changes Specific Setup: Have a form [TestForm] with one or more fields on the form Have a "ScriptLink" script configured [ScriptTest] that exists in the system In "Form Designer", the "WSDL" for [ScriptTest] has already been imported for form [TestForm] The logged in user must have access to 'Form Designer'. Steps Access 'Form Designer'. Select "TestForm" from the 'Forms' field. Select a section [TestSection] from the 'Sections' field. Click [Show Section]. Navigate to the "ScriptLink" settings section Click the "Post-File" field in the "Available Scripts" column Select [TestScript] Populate the "Script Parameter" field with a parameter [TestParam] Return to the form layout section Click to select any field [TestField] On the left side panel in the "General" settings section Click the "ScriptLink" setting link From the "Available Scripts" field, select [TestScript] Populate the "Script Parameter" field with a parameter [TestParam] Click [Apply] Click [Save] Submit the form Validate the form submits successfully Return to "Form Designer" Navigate to the form layout and make any desired form designer change to the layout. For this example, [TestField] is moved to a new location on the layout Click [Save] Submit the form Return to "Form Designer" Select "TestForm" Select [TestSection] From the "Export All Tabs or Select Tab" field? Select "Selected Section" Click "Export Form Designer Copy" Navigate to a folder location and save the file Close the form Re-open "Form Designer" Select "TestForm" Select [TestSection] Click "Import Form Designer Copy" Navigate the folder location of the export file saved in step 3, and select the file Submit the form Return to "Form Designer" Select "TestForm" Select [TestSection] Click [Show Section]. Navigate to the "ScriptLink" settings section Click the "Post-File" field in the "Available Scripts" column Validate script [TestScript] is selected as expected Validate the "Script Parameter" field is populated with parameter [TestParam] as expected Return to the form layout section Validate the form designer change made to [TestField] in step 2 is displayed as expected Select [TestFeild] Click to select the "General" settings section on the left side panel Click the "ScriptLink" setting link From the "Available Scripts" field, validate script [TestScript] is selected as expected Validate the "Script Parameter" field is populated with parameter [TestParam] as expected Re-submit the form Return to "Form Designer" Repeat step 5c and 5d Validate all "ScriptLink" configuration setting are still present, as expected Console Widgets - SQL query override Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Console Widget Viewer Scenario 1: Validate data displayed in the "Console Widget Viewer" widget Specific Setup: Have registry setting "Enable Console Widgets/Views" is set to "Y" Have access to the 'Admission' form Have an episodic modeled form [TestForm] created In form "Console Widget Configuration": Create a console widget for the "Admission" form [AdminWidget] with "SQL Query override" field populated with a query that does not include an episode in the link. For example: "SELECT <LINK:PATIENT510:PATID:EPN_uniqueid>PATID,EPN_uniqueid FROM SYSTEM.episode_history WHERE FACILITY=?FACILITY AND PATID=?PATID" Create a console widget for the "Modeled" form [ModeledWidget] with "SQL Query override" field populated with a query that does not include an episode in the link. For example: "SELECT <LINK:USER19:PATID:CUSTHAAS_UID>PATID,CUSTHAAS_UID FROM SYSTEM.testtable1 WHERE FACILITY=?FACILITY AND PATID=?PATID" Note: (replace the row ID and option ID values as applicable) Add the two widgets and the 'Console Widget Viewer' widget to the logged in users home view Have a client [TestClient] admitted in two episodes In each episode, have a row filed for that client in the modeled form Steps At the homeview, select [TestClient] Select 'All Episodes' from the episode dropdown field. Navigate to the [AdminWidget] Validate a row for both admission episodes are present in the widget Click the "View" button for "Episode 1" row Validate data is displayed for that episode in the 'Console Widget Viewer", as expected Click the "View" button for "Episode 2" row Validate data is displayed for that episode in the 'Console Widget Viewer", as expected Select "Episode 1" from the episode dropdown field. Validate the following message is displayed in the widget, as expected "The LINK tag in the SQL query does not contain an EPISODE value". Select "Episode 2" from the episode dropdown field. Validate the following message is displayed in the widget, as expected "The LINK tag in the SQL query does not contain an EPISODE value". Select 'All Episodes' from the episode dropdown field. Navigate to the [ModeledWidget] Validate a row for both modeled form episodes are present in the widget Click the "View" button for "Episode 1" row Validate data is displayed for that episode in the 'Console Widget Viewer", as expected Click the "View" button for "Episode 2" row Validate data is displayed for that episode in the 'Console Widget Viewer", as expected Select "Episode 1" from the episode dropdown field. Validate the following message is displayed in the widget, as expected "The LINK tag in the SQL query does not contain an EPISODE value". Select "Episode 2" from the episode dropdown field. Validate the following message is displayed in the widget, as expected "The LINK tag in the SQL query does not contain an EPISODE value".	Topics • Envelope Import • NX • Scriptlink • Console Widget
Update 33 Summary \| Details Integrated eSignature - 'Send Document' form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Send Document Pending eSignatures Scenario 1: Integrated eSignature - 'Send Document' form - Send Document Only Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". User must have access to the 'Send Document' form. Document Routing is enabled on the 'Progress Notes (Group and Individual)' form. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Access the 'Send Document' form. Select the form type associated to 'Progress Notes (Group and Individual)' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Validate 'Episode Number' field contains "All Episodes". Enter the current date in the 'From Date' and 'To Date' fields. Select the progress note filed in the previous steps in the 'Select Document' field. Click [Display Document]. Validate the document displays as filed. Click [Close All Documents and Exit]. Validate "Send Document Only" is defaulted in the 'Reason for Sending' field. Once the document has received all approvals, it is considered finalized and may not be sent for eSignature but the document can still be sent for review only. Click [Send Request]. Validate a message is displayed stating: Request Sent. Click [OK] and close the form. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Document sent for review" - this is what was sent to myHealthPointe for review. One 'Document Description' contains "Progress Notes (Group and Individual)" - this is the finalized progress note form finalized via document routing. Select both documents for viewing and click [View]. Validate the documents display as expected. Click [Close All Documents] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents" section. Validate the document sent via the 'Send Document' form is displayed. Select the document and validate the pdf opens and displays as expected. Close the document. Scenario 2: Integrated eSignature - 'Send Document' form - Send for eSignature Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". User must have access to the 'Send Document' form. Document Routing is enabled on the 'Treatment Plan' form. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add the staff associated to the logged in user as an approver. Select "None" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A" but do not approve it. Click [Close]. Access the 'Send Document' form. Select the form type associated to 'Treatment Plan' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Validate 'Episode Number' field contains "All Episodes". Enter the current date in the 'From Date' and 'To Date' fields. Select the treatment plan filed in the previous steps in the 'Select Document' field. Click [Display Document]. Validate the document displays as filed. Click [Close All Documents and Exit]. Validate both "Send Document Only" and "Send for eSignature" are enabled in the 'Reason for Sending' field. "Re-send for eSignature" is disabled because the document has not been sent for eSignature yet. Validate "Send for eSignature" is the default value in the 'Reason for Sending' field. Click [Send Request]. Validate a message is displayed stating: Request Sent. Click [OK] and close the form. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Navigate to the 'My To Do's' widget. Validate the To-Do is no longer displayed for "Client A". The To-Do will display after the eSignature has been collected. Click [Close]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by "Client A" Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Treatment Plan" - this is the finalized treatment plan form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Treatment Plan" finalized document displays the document with the author's signature, "Client A" signature, and the approving practitioner signature. Click [Close All Documents] and close the form. Scenario 3: Integrated eSignature - 'Send Document' form - Re-Send for eSignature Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". User must have access to the 'Send Document' form. Document Routing is enabled on the 'Treatment Plan' form. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add the staff associated to the logged in user as an approver. Select "None" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A" but do not approve it. Click [Close]. Access the 'Send Document' form. Select the form type associated to 'Treatment Plan' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Validate 'Episode Number' field contains "All Episodes". Enter the current date in the 'From Date' and 'To Date' fields. Select the treatment plan filed in the previous steps in the 'Select Document' field. Click [Display Document]. Validate the document displays as filed. Click [Close All Documents and Exit]. Validate both "Send Document Only" and "Send for eSignature" are enabled in the 'Reason for Sending' field. "Re-send for eSignature" is disabled because the document has not been sent for eSignature yet. Validate "Send for eSignature" is the default value in the 'Reason for Sending' field. Click [Send Request]. Validate a message is displayed stating: Request Sent. Click [OK] and close the form. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Navigate to the 'My To Do's' widget. Validate the To-Do is no longer displayed for "Client A". The To-Do will display after the eSignature has been collected. Click [Close]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access the 'Send Document' form. Select the form type associated to 'Treatment Plan' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Validate 'Episode Number' field contains "All Episodes". Enter the current date in the 'From Date' and 'To Date' fields. Select the treatment plan filed in the previous steps in the 'Select Document' field. Validate both "Send Document Only" and "Re-send for eSignature" are enabled in the 'Reason for Sending' field. Validate "Re-send for eSignature" is the default value in the 'Reason for Sending' field. Click [Send Request]. Validate a message is displayed stating: Request Sent. Click [OK] and close the form. Navigate to the 'Pending eSignatures' widget. Validate the row for "Client A" is updated with the current time for 'Time Sent'. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed with an updated time uploaded. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by "Client A" Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate three document rows are displayed for the client with the following: 'Document Description' contains "Integrated eSignature request" - this is the initial request sent to myHealthPointe for eSignature. 'Document Description' contains "Integrated eSignature request" - this is the re-sent request sent to myHealthPointe for eSignature. 'Document Description' contains "Treatment Plan" - this is the finalized treatment plan form finalized via document routing. Select the documents for viewing and click [View]. Validate the initial "Integrated eSignature request" displays the document with the author's signature. Validate the latest "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Treatment Plan" finalized document displays the document with the author's signature, "Client A" signature, and the approving practitioner signature. Click [Close All Documents] and close the form. Scenario 4: Integrated eSignature - Validate the 'Enable Send Document to myHealthPointe functionality' registry setting Specific Setup: Please note: this is for Avatar NX systems only. Steps Access the 'Registry Settings' form. Enter "Send Document To" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains "RADplus->Document Routing->->->->Enable Send Document to myHealthPointe functionality". Validate the 'Registry Setting Detail' field contains "Documents may be sent to myHealthPointe for client eSignature or review. When enabled, the form 'Send Document' will be made available, and the field 'Send to myHealthPointe' will be added to the 'Route Document To' screen in the 'Accept and Route' document routing process. Set to 'Y' to enable this functionality, or 'N' to disable." Validate the 'Registry Setting Value' field contains "N" as this is the default value. Enter "Y" in the 'Registry Setting Value' field. Click [Submit] and close the form. Access the 'User Definition' form. Select the logged in user in the 'Select User' field. Select the "Forms and Tables" section. Click [Select Forms for User Access]. Validate the 'Send Document' form is available for selection under "Avatar PM" forms and select it. Click [OK] and [Submit]. Navigate to the 'User Menu'. Click [Refresh Forms]. Access the 'Send Document' form. Validate the 'Send Document' form is displayed as expected. Close the form. Integrated eSignature - 'DocR.esignature' SQL table Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Final to Draft Override (CWS) Void Progress Notes Select Note To Void Progress Note Corrections Treatment Plan Status Override (CWS) Scenario 1: Integrated eSignature - Void Sent Documents Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form and an approver is not required. User must have access to the 'DocR.esignature' SQL table in 'User Definition'. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Enter the desired value in the 'Plan Name' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select the staff associated to the logged in user as an approver. Select "Document Only" in the 'Send to myHealthPointe' field. Click [Submit]. Log in to myHealthPointe for "Client A". Select the "Documents" section. Validate the document sent via document routing is displayed. Select the document and validate the pdf opens and displays as expected. Close the document. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document sent to myHealthPointe for "Client A". Validate the 'eSignature_status' field contains "Sent - No Signature Requested". Navigate to the 'My To Do's' widget. Click [Review] for the To-Do for "Client A". Click [Reject]. Enter the desired value in the 'Comments for Rejected' field. Click [Sign]. Validate the To-Do is no longer displayed. Log in to myHealthPointe for "Client A". Select the "Documents" section. Validate the rejected document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Voided". Close the report. Scenario 2: Integrated eSignature - Collect eSignature via Document Routing - Reject and Delete Document Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". A "Client" entity modeled form must be defined (Form A). Document Routing is enabled on "Form A". Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add the staff associated to the logged in user as an approver. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Navigate to the 'My To Do's' widget. Validate a To-Do is not displayed for the document for "Client A" that has eSignature requested. The To-Do will only be generated after the document has been signed by the client in myHealthPointe. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Reject]. Enter the desired value in the 'Comments for Rejected' field. Click [Sign]. Validate the To-Do is no longer displayed. Click [Close]. Select "Client A" and access "Form A". Validate the rejected document has been reverted to draft. Delete the draft row. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the "Integrated eSignature Request" is displayed with "Void" as the 'Document Status'. Close the form. Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the row for "Client A" is no longer displayed since the document has been deleted. Scenario 3: Integrated eSignature - Modeled Form - Collect eSignature via Document Routing (No Approvers) Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". A "Client" entity modeled form must be defined (Form A). Document Routing is enabled on "Form A" and an approver is not required. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Form A" - this is the modeled form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Form A" finalized document displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Click [Close All Documents] and close the form. Scenario 4: Integrated eSignature - Void Progress Notes Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Void Progress Notes' form. Select "Client A" in the 'Client ID' field. Select the episode used in the previous steps in the 'Episode Number' field. Enter the current date in the 'Start Date' and 'End Date' fields. Click [Select Note To Void]. Validate the 'Select Note To Void' dialog contains the note filed in the previous steps with an indicator stating: [eSignature Requested on XX/XX/XXXX at XX:XX]. Select the note and click [OK]. Select the desired value in the 'Reason For Voiding The Note' field. Enter the desired value in the 'Comments' field. Click [Submit] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the voided document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the row for "Client A" is no longer displayed. Close the report. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate there is a row for the voided note with the following: Document Description of "Integrated eSignature Request" Document Status of "Void" Close the form. Scenario 5: Integrated eSignature - Progress Note Corrections Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Progress Note Corrections' form. Select "Client A" in the 'Client ID' field. Select the episode used in the previous steps in the 'Episode Number' field. Enter the current date in the 'Start Date' and 'End Date' fields. Click [Select Note To Correct]. Validate the 'Select Note To Correct' dialog contains the note filed in the previous steps with an indicator stating: [eSignature Requested on XX/XX/XXXX at XX:XX]. Select the note and click [OK]. Select "Revert Final Note to Draft" in the 'Correction Action' field. Select the desired value in the 'Reason for Correction' field. Enter the desired value in the 'Comments' field. Click [Submit]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Rescinded". Close the report. Scenario 6: Integrated eSignature - Treatment Plan Status Override Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form and an approver is not required. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Treatment Plan Status Override' form. Select "Client A" in the 'Select Client' field. Select "(60000) Treatment Plan" in the 'Select Treatment Plan' field. Select the treatment plan filed in the previous steps in the 'Select Client Plan' field. Enter the desired value in the 'Override Reason' field. Click [Submit]. Validate a message is displayed stating: Are you sure you want to change this treatment plan status back to draft? Click [Yes]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Rescinded". Close the report. Integrated eSignature - 'Pending eSignatures' widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Pending eSignatures Scenario 1: Integrated eSignature - Validate the 'Pending eSignatures' widget Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. Multiple clients are enrolled in existing episodes with the following: 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe Various documents pending eSignature in myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Navigate to the 'Pending eSignatures' widget. Validate the 'Filter By Program' field is displayed. Validate the following columns are displayed: Client Name Client ID Episode Program Form Name Date Sent Time Sent Sent By Staff Name Status Validate all documents pending eSignature are displayed for all clients. Select the desired program in the 'Filter By Program' field. Validate only documents associated to the selected program are displayed (if any). Clear the program in the 'Filter By Program' field. Select a client with documents pending eSignature from the 'My Clients' list. Validate only documents pending eSignature for the selected client are displayed. De-select the client. Validate all documents pending eSignature for all clients are displayed. Click on the 'Client Name' column. Validate the documents are sorted by 'Client Name'. Click on the 'Client ID' column. Validate the documents are sorted by 'Client ID'. Click on the 'Date Sent' column. Validate the documents are sorted by 'Date Sent'. Scenario 2: Integrated eSignature - Treatment Plan - Collect eSignature via Document Routing (No Approvers) Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form and an approver is not required. The 'Pending eSignatures' widget must be accessible on the HomeView. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Enter the desired value in the 'Plan Name' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Treatment Plan" - this is the treatment plan document finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Treatment Plan" finalized document displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Click [Close All Documents] and close the form. Integrated eSignature - Document Routing Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Final to Draft Override (CWS) Approver Override Void Progress Notes Select Note To Void Progress Note Corrections Treatment Plan Status Override (CWS) Scenario 1: Integrated eSignature - Collect eSignature via Document Routing - Reject and Delete Document Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". A "Client" entity modeled form must be defined (Form A). Document Routing is enabled on "Form A". Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add the staff associated to the logged in user as an approver. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Navigate to the 'My To Do's' widget. Validate a To-Do is not displayed for the document for "Client A" that has eSignature requested. The To-Do will only be generated after the document has been signed by the client in myHealthPointe. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Reject]. Enter the desired value in the 'Comments for Rejected' field. Click [Sign]. Validate the To-Do is no longer displayed. Click [Close]. Select "Client A" and access "Form A". Validate the rejected document has been reverted to draft. Delete the draft row. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the "Integrated eSignature Request" is displayed with "Void" as the 'Document Status'. Close the form. Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the row for "Client A" is no longer displayed since the document has been deleted. Scenario 2: Integrated eSignature - Modeled Form - Collect eSignature via Document Routing (No Approvers) Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". A "Client" entity modeled form must be defined (Form A). Document Routing is enabled on "Form A" and an approver is not required. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Form A" - this is the modeled form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Form A" finalized document displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Click [Close All Documents] and close the form. Scenario 3: Integrated eSignature - Progress Notes - Send Document Only via Document Routing Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Ambulatory Progress Notes' form and an approver is not required. Steps Select "Client A" and access the 'Ambulatory Progress Notes' form. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Document Only" in the 'Send to myHealthPointe' field. Click [Submit]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Document sent for review" - this is what was sent to myHealthPointe for review. One 'Document Description' contains "Ambulatory Progress Notes" - this is the finalized progress note form finalized via document routing. Select both documents for viewing and click [View]. Validate the documents display as expected. Click [Close All Documents] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents" section. Validate the document sent via document routing is displayed. Select the document and validate the pdf opens and displays as expected. Close the document. Scenario 4: Integrated eSignature - Treatment Plan - Collect eSignature via Document Routing (With Approvers) Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Enter the desired value in the 'Plan Name' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add the staff associated to the logged in user as an approver. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Navigate to the 'My To Do's' widget. Validate a To-Do is not displayed for the document for "Client A" that has a pending eSignature. The To-Do will only be generated after the document has been signed by the client in myHealthPointe. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by "Client A" Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Treatment Plan" - this is the treatment plan finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Treatment Plan" finalized document displays the document with the author's signature, "Client A" signature, and the approving practitioner signature. Click [Close All Documents] and close the form. Scenario 5: Integrated eSignature - Request eSignature and add approvers via 'Approver Override' Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form and an approver is not required. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Enter the desired value in the 'Plan Name' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Approver Override' form. Select the form type associated to the 'Treatment Plan' form in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Validate the 'List of Documents' field contains the treatment plan filed in the previous steps with an indicator stating: [eSignature Requested on XX/XX/XXXX at XX:XX]. Click [Display Document]. Validate the document displays as filed. Click [Close]. Validate the 'List of Approvers' field does not contain any approvers. Click [Update Approvers]. Validate the 'Send to myHealthPointe' field is disabled and "Collect eSignature" is selected. Add the staff associated to the logged in user as an approver. Click [Submit] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by "Client A" Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent via document routing. One 'Document Description' contains "Treatment Plan" - this is the finalized treatment plan form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Treatment Plan" finalized document displays the document with the author's signature, "Client A" signature, and the approving practitioner signature. Click [Close All Documents] and close the form. Scenario 6: Integrated eSignature - Approver Override - Collect eSignature Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. The logged in user must have an associated staff member (Staff A). Another user must have an associated staff member (Staff B). Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add "Staff B" as an approver. Select "None" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Access the 'Approver Override' form. Select the form type associated to the 'Progress Notes (Group and Individual)' form in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Validate the 'List of Documents' field contains the progress note filed in the previous steps. Click [Display Document]. Validate the document displays as filed. Click [Close]. Validate the 'List of Approvers' field contains "Staff B". Click [Update Approvers]. Validate "None" is selected in the 'Send to myHealthPointe' field. Select "Collect eSignature" in the 'Send to myHealthPointe' field. De-select "Staff B" as an approver. Select "Staff A" as an approver. Click [Submit] and close the form. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by "Client A" Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent via the 'Approver Override' form. One 'Document Description' contains "Progress Notes (Group and Individual)" - this is the progress note form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Progress Notes (Group and Individual)" finalized document displays the document with the author's signature, "Client A" signature, and the approving practitioner signature. Click [Close All Documents] and close the form. Scenario 7: Integrated eSignature - Void Progress Notes Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Void Progress Notes' form. Select "Client A" in the 'Client ID' field. Select the episode used in the previous steps in the 'Episode Number' field. Enter the current date in the 'Start Date' and 'End Date' fields. Click [Select Note To Void]. Validate the 'Select Note To Void' dialog contains the note filed in the previous steps with an indicator stating: [eSignature Requested on XX/XX/XXXX at XX:XX]. Select the note and click [OK]. Select the desired value in the 'Reason For Voiding The Note' field. Enter the desired value in the 'Comments' field. Click [Submit] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the voided document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the row for "Client A" is no longer displayed. Close the report. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate there is a row for the voided note with the following: Document Description of "Integrated eSignature Request" Document Status of "Void" Close the form. Scenario 8: Integrated eSignature - Progress Note Corrections Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Progress Note Corrections' form. Select "Client A" in the 'Client ID' field. Select the episode used in the previous steps in the 'Episode Number' field. Enter the current date in the 'Start Date' and 'End Date' fields. Click [Select Note To Correct]. Validate the 'Select Note To Correct' dialog contains the note filed in the previous steps with an indicator stating: [eSignature Requested on XX/XX/XXXX at XX:XX]. Select the note and click [OK]. Select "Revert Final Note to Draft" in the 'Correction Action' field. Select the desired value in the 'Reason for Correction' field. Enter the desired value in the 'Comments' field. Click [Submit]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Rescinded". Close the report. Scenario 9: Integrated eSignature - Treatment Plan Status Override Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing outpatient episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Treatment Plan' form and an approver is not required. Steps Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field. Populate all other required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed but do not sign it. Access Crystal Reports or other SQL Reporting Tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the document pending eSignature for "Client A". Validate the 'eSignature_status' field contains "Pending". Access the 'Treatment Plan Status Override' form. Select "Client A" in the 'Select Client' field. Select "(60000) Treatment Plan" in the 'Select Treatment Plan' field. Select the treatment plan filed in the previous steps in the 'Select Client Plan' field. Enter the desired value in the 'Override Reason' field. Click [Submit]. Validate a message is displayed stating: Are you sure you want to change this treatment plan status back to draft? Click [Yes]. Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document is no longer displayed. Access Crystal Reports or other SQL Reporting Tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Rescinded". Close the report. Scenario 10: Integrated eSignature - Approver Override - Document Only Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. The logged in user must have an associated staff member (Staff A). Another user must have an associated staff member (Staff B). Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired episode in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Add "Staff B" as an approver. Select "None" in the 'Send to myHealthPointe' field. Click [Submit]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Access the 'Approver Override' form. Select the form type associated to the 'Progress Notes (Group and Individual)' form in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Validate the 'List of Documents' field contains the progress note filed in the previous steps. Click [Display Document]. Validate the document displays as filed. Click [Close]. Validate the 'List of Approvers' field contains "Staff B". Click [Update Approvers]. Validate "None" is selected in the 'Send to myHealthPointe' field. Select "Document Only" in the 'Send to myHealthPointe' field. De-select "Staff B" as an approver. Select "Staff A" as an approver. Click [Submit] and close the form. Navigate to the 'My To Do's' widget. Validate a To-Do is displayed for "Client A". Click [Review] and [Accept]. Validate the 'Document Preview' contains the following electronic signatures appended to the end of the document: Electronically signed by Author Electronically signed by Approver Click [Sign]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Validate the To-Do is no longer displayed. Click [Close]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Document sent for review" - this is what was sent via the 'Approver Override' form One 'Document Description' contains "Progress Notes (Group and Individual)" - this is the progress note form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Document sent for review" displays the document with the author's signature. Validate the "Progress Notes (Group and Individual)" finalized document displays the document with the author's signature and the approving practitioner signature. Click [Close All Documents] and close the form. Log in to myHealthPointe for "Client A". Select the "Documents" section. Validate the document sent via the 'Approver Override' form is displayed. Select the document and validate the pdf opens and displays as expected. Close the document. Entity-Based Document Capture Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Entity-Based Document Capture Scenario 1: Entity-Based Document Capture - Validation Specific Setup: Perceptive storage method must be utilized. Select a client, staff, provider, incident and performing provider for the tests. Steps Access the 'Entity-Based Document Capture' form. Select "Performing Provider" in the 'Entity Type' field. Enter the desired performing provider in the 'Entity' field in the format of "LAST,FIRST". Validate the 'Results' field displays the performing provider and select it. Click [Launch POS Capture]. Import in a document saved as a file on the server. Validate the document renders on screen. Select the desired value in the 'Document Type' field. Enter the desired value in the 'Document Description' field. Click [Save]. Validate that messages display indicating the document was successfully saved. Close the form. Access the 'Clinical Document Viewer' form. Select "Performing Provider" in the 'Entity' field. Select "Individual" in the 'Select All or Individual Performing Provider' field. Select the performing provider from the previous steps in the 'Select Performing Provider' field. Click [Process]. Validate a row was added for the document that was just saved. View the document to validate it displays as it was captured. Close the form. Move Selected Data Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Move Selected Data (CWS) Move Selected Data (PM) Scenario 1: Move Selected Data [CWS] - Move data from one episode to another when document routing is enabled Specific Setup: A client is enrolled in two existing episodes (Client A). Steps Access the 'Document Routing Setup' form. Select "Avatar CWS" in the 'Application' field. Click [Select Form]. Select "Progress Notes (Group and Individual)" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Enable Document Routing' field. Select "Yes" in the 'Allow Comments During Approval' field. Click [File] and close the form. Select "Client A" and access the 'Progress Notes (Group and Individual)' form. Select "Episode 1" in the 'Select Episode' field. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate the 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Enter the desired comments in the 'Approval Comments' field and click [OK]. Validate a message is displayed stating: Note Filed. Click [OK] and close the form. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed for "Episode 1" and select it for viewing. Click [View]. Validate the document displays as expected with the approver signature and approval comments. Click [Close All Documents] and close the form. Access the 'Move Selected Data' CWS form. Select "Client" in the 'Entity Database' field. Select "Progress Notes (Group and Individual)" in the 'Form' field. Select "Client A" in the 'Old Entity' field. Select "Episode 1" in the 'Old Episode' field. Click [Select Row to be Moved]. Select the record filed in the previous steps and click [OK]. Validate a message is displayed stating: Warning!! The selected row is marked as "Final" and is associated with a finalized document. This row can only be moved to a different episode of the same entity. Click [OK]. Select "Client A" in the 'New Entity' field. Select "Episode 2" in the 'New Episode' field. Enter the desired value in the 'Reason for Moving Data' field. Click [Submit]. Validate the 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Enter the desired comments in the 'Approval Comments' field and click [OK]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed for "Episode 2" and select it for viewing. Click [View]. Validate the document displays as expected with the initial approver's signature and approval comments, information from 'Move Selected Data', and the appending author's signature and approval comments. Click [Close All Documents] and close the form. Scenario 2: Move Selected Data [PM] - Move data from one episode to another when document routing is enabled Specific Setup: Must have a PM modeled form defined with a 'Draft/Final' field (Form A). A client is enrolled in two existing episodes (Client A). Steps Access the 'Document Routing Setup' form. Select "Avatar PM" in the 'Application' field. Click [Select Form]. Select "Form A" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Enable Document Routing' field. Select "Yes" in the 'Allow Comments During Approval' field. Click [File] and close the form. Select "Client A" and access "Form A". Select "Episode 1" and click [OK]. Populate all required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate the 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Enter the desired comments in the 'Approval Comments' field and click [OK]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed for "Episode 1" and select it for viewing. Click [View]. Validate the document displays as expected with the approver signature and approval comments. Click [Close All Documents] and close the form. Access the 'Move Selected Data' PM form. Select "Client" in the 'Entity Database' field. Select "Form A" in the 'Form' field. Select "Client A" in the 'Old Entity' field. Select "Episode 1" in the 'Old Episode' field. Click [Select Row to be Moved]. Select the record filed in the previous steps and click [OK]. Validate a message is displayed stating: Warning!! The selected row is marked as "Final" and is associated with a finalized document. This row can only be moved to a different episode of the same entity. Click [OK]. Select "Client A" in the 'New Entity' field. Select "Episode 2" in the 'New Episode' field. Enter the desired value in the 'Reason for Moving Data' field. Click [Submit]. Validate the 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Enter the desired comments in the 'Approval Comments' field and click [OK]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed for "Episode 2" and select it for viewing. Click [View]. Validate the document displays as expected with the initial approver's signature and approval comments, information from 'Move Selected Data', and the appending author's signature and approval comments. Click [Close All Documents] and close the form. Integrated eSignature - Append Documents Scenario 1: Integrated eSignature - Append Documents Specific Setup: Please note: this is for Avatar NX systems only. Avatar NX must be configured to integrate with myHealthPointe. A client is enrolled in an existing episode with the following (Client A): 'Date of Birth' on file 'Email Address' on file Login credentials for myHealthPointe The 'Enable Send Document to myHealthPointe functionality' registry setting is set to "Y". Document Routing is enabled on the 'Progress Notes (Group and Individual)' form and an approver is not required. The 'Pending eSignatures' widget must be accessible on the myDay view. Steps Access the 'Progress Notes (Group and Individual)' form. Select "Client A" in the 'Select Client' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [File Note]. Validate a 'Confirm Document' dialog is displayed. Click [Accept and Route]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Select "Collect eSignature" in the 'Send to myHealthPointe' field. Click [Submit]. Navigate to the 'Pending eSignatures' widget. Validate a row is displayed for the eSignature request sent for "Client A". Access Crystal Reports or other SQL Reporting tool. Create a report using the 'DocR.esignature' SQL table. Validate a row is displayed for the eSignature request sent for "Client A". Validate the 'eSignature_status' field contains "Pending". Log in to myHealthPointe for "Client A". Select the "Documents Awaiting Signature" section. Validate the document sent for eSignature is displayed. Click [Sign and Submit]. Enter an eSignature in the 'Enter the Signature' field. Click [Sign and Submit]. Validate the document is no longer displayed. Navigate to the 'Pending eSignatures' widget. Validate the row is no longer displayed for "Client A". Access Crystal Reports or other SQL Reporting tool. Refresh the report using the 'DocR.esignature' SQL table. Validate the 'eSignature_status' field now contains "Approved". Close the report. Access the 'Append Documents' form. Select the note type associated to the 'Progress Notes (Group and Individual)' form in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Select the progress note filed in the previous steps in the 'List of Documents' field. Click [Display Document]. Validate the document displays with the signature for "Client A" appended to the bottom right corner. Click [Close All Documents and Exit]. Enter the desired value in the 'New Comments to Be Appended to the Original Document' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Validate the document is displayed with the signature for "Client A" in the bottom right corner and the new comments appended to the end of the original document. Click [Accept]. Enter the password for the logged in user in the 'Password' field and click [Verify]. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Client:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate two document rows are displayed for the client: One 'Document Description' contains "Integrated eSignature request" - this is what was sent to myHealthPointe for eSignature. One 'Document Description' contains "Progress Notes (Group and Individual)" - this is the finalized progress notes form finalized via document routing. Select both documents for viewing and click [View]. Validate the "Integrated eSignature request" displays the document with the author's signature and the signature for "Client A" appended to the bottom right corner. Validate the "Progress Notes (Group and Individual)" finalized document displays the document with the author's signature, the signature for "Client A" in the bottom right corner, and the new comments appended to the end of the original document. Click [Close All Documents] and close the form. 'Add Non-User Signature' - Appending Documents Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Add Non-User Signature (PM) Scenario 1: Progress Notes - Validate 'Add Non-User Signature' functionality Specific Setup: A client is enrolled in an existing outpatient episode (Client A). Steps Access the 'Document Routing Setup' form. Select "Avatar CWS" in the 'Application' field. Click [Select Form]. Select "Ambulatory Progress Notes" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Enable Document Routing' field. Select "No" in the 'Use Crystal Report Template' field. Click [File] and close the form. Select "Client A" and access the 'Ambulatory Progress Notes' form. Select "Independent Note" in the 'Progress Note For' field. Select the desired value in the 'Note Type' field. Enter the desired value in the 'Notes Field' field. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password associated to the logged in user and click [Verify]. Access the 'Document Routing Setup' form. Select "Avatar CWS" in the 'Application' field. Click [Select Form]. Select "Ambulatory Progress Notes" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Use Crystal Report Template' field. Select the desired crystal report template in the 'Crystal Report' field. Click [File] and close the form. Access the 'Add Non-User Signature' form. Select the form type for 'Ambulatory Progress Notes' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Select the progress note filed in the previous steps in the 'List of Option Documents and Snapshots' field. Click [Display Document]. Validate the document is displayed as expected. Click [Close All Documents and Exit]. Enter the desired value in the 'Comments' field. Click [Sign]. Sign in the 'Please Sign Below' dialog and click [OK]. Validate the signature is displayed. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Validate the document preview displays as expected and the non-user signature is appended to the end of the document. Click [Accept]. Enter the password associated to the logged in user and click [Verify]. Close the form. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed and select it for viewing. Click [View]. Validate the document displays as expected with the non-user signature appended to the end of the document. Click [Close All Documents] and close the form. Scenario 2: Treatment Plan - Validate 'Add Non-User Signature' functionality Specific Setup: A client is enrolled in an existing outpatient episode (Client A). Steps Access the 'Document Routing Setup' form. Select "Avatar CWS" in the 'Application' field. Click [Select Form]. Select "Treatment Plan" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Enable Document Routing' field. Select "No" in the 'Use Crystal Report Template' field. Click [File] and close the form. Select "Client A" and access the 'Treatment Plan' form. Enter the desired date in the 'Plan Date' field. Enter the desired value in the 'Plan Name' field. Select the desired value in the 'Plan Type' field. Populate all required and desired fields. Select "Final" in the 'Treatment Plan Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password associated to the logged in user and click [Verify]. Access the 'Document Routing Setup' form. Select "Avatar CWS" in the 'Application' field. Click [Select Form]. Select "Treatment Plan" in the 'Select a form to enable Document Routing' field and click [OK]. Select "Yes" in the 'Use Crystal Report Template' field. Select the desired crystal report template in the 'Crystal Report' field. Click [File] and close the form. Access the 'Add Non-User Signature' form. Select the form type for 'Treatment Plan' in the 'Form Type' field. Select "Client A" in the 'Entity' field. Enter the current date in the 'From Date' and 'To Date' fields. Select the treatment plan filed in the previous steps in the 'List of Option Documents and Snapshots' field. Click [Display Document]. Validate the document is displayed as expected. Click [Close All Documents and Exit]. Enter the desired value in the 'Comments' field. Click [Sign]. Sign in the 'Please Sign Below' dialog and click [OK]. Validate the signature is displayed. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Validate the document preview displays as expected and the non-user signature is appended to the end of the document. Click [Accept]. Enter the password associated to the logged in user and click [Verify]. Close the form. Access the 'Clinical Document Viewer' form. Select "Client" in the 'Select Type:' field. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the document filed is displayed and select it for viewing. Click [View]. Validate the document displays as expected with the non-user signature appended to the end of the document. Click [Close All Documents] and close the form.	Topics • NX • Integrated eSignature • Registry Settings • Perceptive • Move Selected Data • Clinical Document Viewer • Progress Notes • Add Non-User Signature • Treatment Plan
Update 34 Summary \| Details eMAR Downtime reports Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Order Entry Forms Definition FTP Setup eMAR Downtime Automation Scenario 1: NX - eMAR Downtime Automation - 7 Day Administration Record Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record (7 day grid)" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record - 7 day grid" 'Order Types To Be Included' = all values selected. 'Printed Time Format (Supported forms Only)' = "Military". 'Include Routine / PRN / STAT/ Other' = all values checked. 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "No". 'Include Future-Start Orders' = "Yes" 'Include Future-Discontinued Orders' = "Yes" An active 'SFTP - Password' configuration must exist for the server where the application resides that communicates with the FTP server. An active configuration must exist for the 'Administration Record - 7 day grid' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "No" 'Sort Clients' = "Alphabetically by Client Name (across Units/Programs)" 'Create a Separate Report File for Each Selected Unit/Program' = "No" 'eMAR Downtime Report to Include' = "Units" 'Include All Units' = "Yes" 'File Path' = a valid directory on the server where the application resides 'Send File to FTP Server' = "Yes" 'FTP Definition' = the definition configured for "SFTP - Password" in the 'FTP Setup' form. Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate a file is displayed in the following format: YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'. (ex. 2023-05-31_1036_7 day Administration Record) Open the pdf and validate that the 'Administration Record - 7 day grid' report is displayed and contains the following: Validate all clients are in one file and that they are in alphabetical order by client's last name, first name across all units selected. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Access the FTP server and access the directory where the pdf's will be stored. Validate a file is displayed in the following format: YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'. (ex. 2023-05-31_1036_7 day Administration Record) Open the pdf and validate that the 'Administration Record - 7 day grid' report is displayed and contains the following: Validate all clients are in one file and that they are in alphabetical order by client's last name, first name across all units selected. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Scenario 2: NX - eMAR Downtime Automation - 1 Day Administration Record Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record (1 day grid)" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record - 1 day" 'Order Types To Be Included' = "Pharmacy" 'Printed Time Format (Supported forms Only)' = "AM/PM". 'Include Routine / PRN / STAT/ Other' = all values checked. 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "No". 'Include Future-Start Orders' = "No" 'Include Future-Discontinued Orders' = "No" An active configuration must exist for the 'Administration Record' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "No" 'Sort Clients' = "Alphabetically by Client Name (across Units/Programs)" 'Create a Separate Report File for Each Selected Unit/Program' = "Yes" 'eMAR Downtime Report to Include' = "Programs" 'Include All Programs' = "No" 'Outpatient/Partial Hospitalization Programs to Include' = "(302) O.P. Adult Psych", "(303) O.P. Mature Adult Psych", and "(307) O.P. Mature Adult S.A". 'File Path' = a valid directory on the server where the application resides 'Delete Files After X Days' = "5" 'Send File to FTP Server' = "No" Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. The user logged into the application must have their action require validation. (User A) Three clients must have active episodes for the following programs with qualifying orders: "(302) O.P. Adult Psych" (Client A) "(303) O.P. Mature Adult Psych" (Client B) "(307) O.P. Mature Adult S.A" (Client C) Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate there are 3 files, one for every Outpatient and Partial Hospitalization program that was selected that contains clients with qualifying orders in the following format "Program_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. O.P. Adult Psych_2023-06-06_1638_1 Day Administration Record). Open one of the pdf's and validate that the 'Administration Record - 1 Day' report is displayed and contains the following: Validate that the pdf will contain all clients in that program sorted in alphabetical order by client's last name, first name. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Scenario 3: NX - eMAR Downtime Automation - Administration Record Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record" 'Order Types To Be Included' = all values selected. 'Printed Time Format (Supported forms Only)' = "24-Hr (colon)". 'Include Routine / PRN / STAT/ Other' = all values checked. 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "No". 'Include Future-Start Orders' = "Yes" 'Include Future-Discontinued Orders' = "No" An active configuration must exist for the 'Administration Record' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "No" 'Sort Clients' = "By Unit or Program, then by Room/Bed (for Units) or alphabetically by Client Name (for Programs)" 'Create a Separate Report File for Each Selected Unit/Program' = "Yes" 'eMAR Downtime Report to Include' = "Both" 'Include All Units' = "Yes" 'Include All Programs' = "Yes" 'File Path' = a valid directory on the server where the application resides 'Delete Files After X Days' = "1" 'Send File to FTP Server' = "No" Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate there are files for every unit that contains clients with qualifying orders in the following format "Unit_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex.1East_2023-06-01_1038_Administration Record). Validate there are files for every Outpatient and Partial Hospitalization program that contains clients with qualifying orders in the following format "Program_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. O.P. Adult Psych_2023-06-01_1038_Administration Record). Open one of the pdf's and validate that the 'Administration Record' report is displayed and contains the following: Validate that the pdf for units will contain all clients in that unit and then sorted in Room/Bed order. Validate that the pdf for programs will contain all client in that program sorted in alphabetical order by client's last name, first name. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Scenario 4: NX - eMAR Downtime Automation - 1 Day Alt Administration Record Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record (1 day grid Alternate Format 1)" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record - 1 Day Alternate" 'Order Types To Be Included' = "Pharmacy" 'Printed Time Format (Supported forms Only)' = "AM/PM". 'Include Routine / PRN / STAT/ Other' = all values checked. 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "Yes" 'Incl. Exp. Orders For How Many Days Past Order's Stop Date' = "5" 'Include Future-Start Orders' = "No" 'Include Future-Discontinued Orders' = "No" An active configuration must exist for the 'Administration Record' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "Yes" 'Sort Clients' = "By Unit or Program, then alphabetically by Client Name" 'Create a Separate Report File for Each Selected Unit/Program' = "No" 'eMAR Downtime Report to Include' = "Units" 'Include All Units' = "No" 'Units to Include' = "(1E) 1East" and "(1N) 1North" 'File Path' = a valid directory on the server where the application resides 'Delete Files After X Days' = "1" 'Send File to FTP Server' = "No" Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate there is one pdf that contains clients with qualifying orders in the following format "YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. 2023-06-06_1638_1 Day Administration Record - Alternate). Open the pdf and validate that the 'Administration Record - 1 Day Alternate' report is displayed and contains the following: Validate that the pdf will contain all clients in the two units selected, sorted in alphabetical order by client's last name, first name. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Scenario 5: eMAR Downtime Automation - 7 Day Alt Administration Record Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record (7 day grid Alternate Format 1)" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record - 7 Day Alt" 'Order Types To Be Included' = "Pharmacy" 'Printed Time Format (Supported forms Only)' = "Military" 'Include Routine / PRN / STAT/ Other' = all values checked 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "Yes" 'Incl. Exp. Orders For How Many Days Past Order's Stop Date' = "5" 'Include Future-Start Orders' = "No" 'Include Future-Discontinued Orders' = "No" An active 'SFTP - Key Pair' configuration must exist for the server where the application resides that communicates with the FTP server. An active configuration must exist for 'Administration Record - 7 Day Alt' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "Yes" 'Sort Clients' = "Alphabetically by Client Name (across Units/Programs)" 'Create a Separate Report File for Each Selected Unit/Program' = "Yes" 'eMAR Downtime Report to Include' = "Units" 'Include All Units' = "No" 'Units to Include' = "1North" 'File Path' = a valid directory on the server where the application resides 'Send File to FTP Server' = "Yes" 'FTP Definition' = the definition configured for "SFTP - Key Pair" in the 'FTP Setup' form. Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate a file is displayed in the following format: "Units selected_YYYY-MM-DD_time in military format_Form Description name" set up in 'Order Entry Forms Definition'. (ex.1North_2023-05-31_1651_Administration Record - 7 Day Alternate) Open the pdf and validate that the 'Administration Record - 7 Day Alt' report is displayed and contains the following: Validate all clients are in one file and that they are in alphabetical order by client's last name, first name across all units selected. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Access the FTP server and access the directory where the pdf's will be stored. Validate a file is displayed in the following format: "Units selected_YYYY-MM-DD_time in military format_Form Description name" set up in 'Order Entry Forms Definition'. (ex.1North_2023-05-31_1651_Administration Record - 7 Day Alternate) Open the pdf and validate that the 'Administration Record - 7 Day Alt' report is displayed and contains the following: Validate all clients are in one file and that they are in alphabetical order by client's last name, first name across all units selected. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. Scenario 6: NX - eMAR Downtime Automation - Administration Record Alternate Specific Setup: An active definition must exist in the 'Order Entry Forms Definition' form for the "Administration Record (Alternate Format 1)" that is configured with the following: 'Form Description' and 'Form Title To Be Printed' = "Administration Record - Alternate" 'Order Types To Be Included' = all values selected. 'Printed Time Format (Supported forms Only)' = "Military". 'Include Routine / PRN / STAT/ Other' = all values checked. 'Include Orders That Require Validation' = "Yes" 'Include Expired Orders' = "No". 'Include Future-Start Orders' = "No" 'Include Future-Discontinued Orders' = "No" An active configuration must exist for the 'Administration Record' in the 'eMAR Downtime Automation' form that fits the following criteria: 'Print A Blank Form for Clients With No Qualifying Orders' = "Yes" 'Sort Clients' = "Alphabetically by Client Name (across Units/Programs)" 'Create a Separate Report File for Each Selected Unit/Program' = "Yes" 'eMAR Downtime Report to Include' = "Both" 'Include All Units' = "No" 'Units to Include' = "(1N) 1North" 'Include All Programs' = "No" 'Programs to Include' = "(306) O.P. Adult S.A." 'File Path' = a valid directory on the server where the application resides 'Delete Files After X Days' = "1" 'Send File to FTP Server' = "No" Validate "Schedule Description: eMAR Downtime Automation(4) Recurrence Pattern : Daily" exists in the 'System Task Scheduler' and configure the 'Start Date' and 'Start Time'. This is the date and time that this task will run each day. The 'RADplus Install Configuration' form must contain an active server configuration for the cache server where the application resides that uses the 'NX URL'. This is a CSMPROG only form and will be configured by a Netsmart Representative. Please Note: For testing purposes, it is assumed that the 'eMAR Downtime Automation' task has run for the day. Steps Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate there is a file for the unit selected (1North) that contains clients with qualifying orders in the following format "Unit_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. 1North_2023-05-30_1039_Administration Record - Alternate). Validate there is a file for every the program selected (O.P. Adult S.A.) that contains clients with qualifying orders in the following format "Program_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. O.P. Adult S.A._2023-05-30_1039_Administration Record - Alternate). Open one of the pdf's and validate that the 'Administration Record - Alternate' report is displayed and contains the following: Validate that the pdf for units will contain all clients in that unit and then sorted in Room/Bed order. Validate that the pdf for programs will contain all client in that program sorted in alphabetical order by client's last name, first name. Validate the 'PRINTED DATE/TIME' field contains the date and time the report was created. The time will be in whichever format was selected in the 'Printed Time Format (Supported forms Only)' field on the 'Order Entry Forms Definition' form. Validate the 'D.O.B' field contains the Client's Date Of Birth. Validate the 'PAGE' field contains "Page # of #", and that it will reset for each client. If a client has multiple pages of orders it will read "Page 1 of # of total pages" and then for the next client it will return to "Page 1 of 1". Close the report and log off of the server. After 2 days and after the 'eMAR Downtime Automation' task has run for the day, Access the cache server where the application resides and access the directory specified in the 'File Path' field on the 'eMAR Downtime Automation' form. Validate the "1North_2023-06-01_1039_Administration Record - Alternate" and "O.P. Adult S.A._2023-06-01_1039_Administration Record - Alternate" files are no longer displayed. Validate there is a new file for the unit selected (1North) that contains clients with qualifying orders in the following format "Unit_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. 1North_2023-06-01_1039_Administration Record - Alternate) Validate there is a file for every the program selected (O.P. Adult S.A.) that contains clients with qualifying orders in the following format "Program_YYYY-MM-DD_time in military format_Form Description name set up in 'Order Entry Forms Definition'." (ex. O.P. Adult S.A._2023-06-01_1039_Administration Record - Alternate)	Topics • NX • eMAR Downtime Automation
Update 35 Summary \| Details Envelope definition data Scenario 1: Validate data in the 'SYSTEM.radplus_envelope_info' SQL Table View Specific Setup: Have one or more modeled "Envelopes" defined in form "Envelope Definition" in the "PM" namespace and in any child namespace's. For this test "CWS" and "MSO" have envelopes defined The user has permissions assigned to query table view 'SYSTEM.radplus_envelope_info' in their user definition Have a report created to display data in table view 'SYSTEM.radplus_envelope_info', in each namespace Steps Open the report created for table view 'SYSTEM.radplus_envelope_info' in the "PM" namespace Click to generate the report Validate the report reflects all the expected envelopes, defined in that namespace Validate the following fields are populated for each envelope, based the field values selected in form "Envelope Definition" Build Application (Avatar PM) Build Environment Envelope ID Envelope Name Envelope (SQL) Schema Envelope Version Is Envelope Eligible for Export? Always Allow Export Open the report created for table view 'SYSTEM.radplus_envelope_info' in the "CWS" namespace Click to generate the report Validate the report reflects all the expected envelopes, defined in that namespace Validate the following fields are populated for each envelope, based the field values selected in form "Envelope Definition" Build Application (Avatar CWS) Build Environment Envelope ID Envelope Name Envelope (SQL) Schema Envelope Version Is Envelope Eligible for Export? Always Allow Export CDR (SQL) Schema Open the report created for table view 'SYSTEM.radplus_envelope_info' in the " MSO" namespace Click to generate the report Validate the report reflects all the expected envelopes, defined in that namespace Validate the following fields are populated for each envelope, based the field values selected in form "Envelope Definition" Build Application (Avatar MSO) Build Environment Envelope ID Envelope Name Envelope (SQL) Schema Envelope Version Is Envelope Eligible for Export? Always Allow Export CDR (SQL) Schema	Topics • SQL Data Access
Update 36 Summary \| Details Perceptive - Scanning/Importing Documents Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Batch Capture and Indexing Client Document Capture Document Capture Scenario 1: Perceptive Batch Capture and Indexing - JxBrowser enabled Specific Setup: Perceptive storage method must be utilized. Steps Open the "Batch Capture and Indexing" form. Click "Capture" to create a new batch. Choose "Scanner" for the "Source". Click "Open Batch". Scan a document If Batch Verify is utilized, then click "Send To". If Batch Verify is not utilized, then click "Submit". If Batch Verify is utilized, select Avatar Batch Validate in the left-hand pane. Select the batch that was sent to this queue. Open the batch and click "Submit". Close form. Open the "Batch Capture and Indexing" form. Click "Capture" to create a new batch. Choose "File" for the "Source". Click "Browse" and browse to the location of where the file is stored on the server. Click "Open". Click "Open Batch". If Batch Verify is utilized, then click "Send To". If Batch Verify is not utilized, then click "Submit". If Batch Verify is utilized, select Avatar Batch Validate in the left-hand pane. Select the batch that was sent to this queue. Open the batch and click "Submit". Close form. Open "Chart Review" form for the client and episode that the documents were just scanned and imported for. Navigate to the form/category that you want to validate. Select a document that was scanned in. Validate that the document displays. Click the "Print" button. Print the document. Validate that the printed document matches what displayed on the viewer. Select a document that was imported in. Validate that the document displays. Click the "Print" button. Print the document. Validate that the printed document matches what displayed on the viewer. Open "Clinical Document Viewer". Validate you can view and print both the scanned and imported document. Scenario 2: Perceptive Individual Scanning/Importing/Viewing/Printing through Chart Review Specific Setup: Perceptive storage method must be utilized. Steps Open the "Chart Review" form. Select the desired client and episode. Open the "Document Capture" form within Chart. Scan a document. Assign the document to a particular "Document Type". Save the document. Import a document. Assign the document to a particular "Document Type". Save the document. Navigate to the section designated by the "Document Type" the document was saved under. Navigate to the "Episode" tab. Open the document(s). Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the document. Open the "Clinical Document Viewer". Select the desired client and episode. Locate the document(s) that were just scanned in or imported. Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the form. 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 Access the 'Client Document Capture' form. Enter "Client A" in the 'Client ID' field. Select any episode for the 'Episode Number' field. Click [Launch POS Capture]. Validate a 'Capture Mode' dialog stating: "How would you like to capture documents?" Click [Import]. Validate the 'Document Capture' opens in a new window. Select any value in the 'Document Type' field. Enter any value in the 'Document Description' field. Click [Capture] and [Browse]. Locate the file to be imported and click [Open] and [Done]. Validate the image displays. Click [Save]. Validate a message stating: "Save Was Successful." and "Document Added to Avatar!" Close the form. Access the undocked 'Clinical Document Viewer' form. Validate the form opens in a new window. Select "Client" in the 'Select Type' field. Select "Individual" in the 'Select All or Individual Client' field. Enter "Client A" in the 'Select Client' field. Select the episode from the previous steps in the 'Episode' field. Click [Process]. Locate and select the document that was saved in the previous steps. Validate the image displays. Click [Close All Documents], [Search] and [Close]. Scenario 4: Perceptive Individual Scanning/Importing/Viewing/Printing Workflow - Client Terminology Modified Specific Setup: Test only in Perceptive enabled environments. Steps Open the "Chart Review" form. Select the desired client and episode. Open the "Document Management" form within Chart. Scan a document. Assign the document to a particular "Document Type". Save the document. Open the "Document Management" form within Chart. Import a document. Assign the document to a particular "Document Type". Save the document. Navigate to the section designated by the "Document Type" the document was saved under. Navigate to the "Episode" tab. Open the document(s). Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the document. Open the "Clinical Document Viewer". Select the desired client and episode. Locate the document(s) that were just scanned in or imported. Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the form. Scenario 5: Client Document Capture - Scan Episodic Specific Setup: Perceptive must be configured and enabled. Steps Open the "Chart Review" form. Select the desired client. Navigate to the "Chart". Click "Document Capture". Scan a document and identify an episode. Note the document type. Save the document. Click the document type the document was just saved under. Locate the document that was just saved. Validate the document displays as it was scanned. Print the document and validate it prints as it was scanned. Close the forms. Document Management Definition - Duplicate Forms created Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Document Capture Document Capture Scenario 1: Validate form "Document Management Definition" Steps Open "Document Management Definition" form. Click [Select Form]. Click [Add New]. Populate the "Form Name" field. Select the desired form type in the "Form Type" field Select the desired entity in the "Entity" field Populate any other desired fields in the "Form" section Click the [Categories] section. Click [Select Categories]. Select the desired category from the selection list Click [OK]. Click the [Display] section. Select the desired selections form the "Forms to Display" box. Click the [Reports] section. Click any to launch any desired report, for example the "Display Form Report" Validate the "Document Management Form Report" is displayed. Close the report. Click back to the [Form] section Click [File]. Validate the form files successfully Click [Select Form]. Select the form just submitted in 5 Validate all fields populated in steps 1 thru 5, are populated as expected Click back to the [Form] section Click [Delete]. Click [Yes] to accept the deletion. Click [Select Form]. Validate the form that was deleted in step 7, is no longer present in the list Click [Select Form]. Select the form "Inbox Attachments" Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed." Click [OK] Click [Select Form]. Select the form "Results Document" Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed." Click [OK] Close the form Scenario 2: Document Management Definition - Perceptive Syncing Form Definitions in Multiple Server environment Specific Setup: To be tested in a multiple server environment that has multiple root system codes. Using the "Document Management Definition" form: Identify a form that exists in all system codes. Steps Using the "Document Management Definition" form Edit the existing form identified as existing in all root system codes. File t he form. Open the "Client Document Capture" form. Scan or import a document. Select the form edited in "Document Management Definition". Scan or import the document. Using "Clinical Document Viewer", select the test client. Validate the document that was just filed for the form that exists in all root system codes displays as it was previously filed.	Topics • Document Scan/Import • Document Import/Scan • Document Management • NX
Update 37 Summary \| Details 'Create New Treatment Plan' process - Registry Setting creation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Create New Treatment Plan Registry Settings (CWS) Scenario 1: Create a new copy of the 'Treatment Plan' form using 'Create New Treatment Plan' Steps Access the 'Create New Treatment Plan' form. Enter the desired value in the 'Treatment Plan Name' field. Select the desired value in the 'Episode Required' field. Click [Submit]. Validate a message is displayed stating: Are you sure you want to create a new copy of the Treatment Plan? Click [Yes]. Validate a message is displayed indicating the Treatment Plan form has been created. Click [OK] and close the form. Access the 'Registry Settings' form. Enter "Level of Care" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Enable Level of Care Functionality' registry setting is displayed for all 'Treatment Plan' forms, including the newly created 'Treatment Plan' copy. Close the form.	Topics • Registry Settings • Treatment Plan
Update 38 Summary \| Details State Form Definition - Form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form Definition State Form File Generation Scenario 1: State Form Definition - Field and data validation's Specific Setup: Have a "State Form Definition" file [TestFile] created based on a table [TestTable] that contains two or more numerical fields and any other fields For this test, numerical fields [FieldA], [FieldB] and [FieldC] exist and are set to display data when the file is generated Have access to the form [TestForm] where data can filed in table [TestTable] Have access to form "State Form Definition" and "State Form File Generation" An active client [TestClient] exists on the system Steps Open [TestForm] Select [TestClient] Set [FieldA] to a desired value. For this test "10" Set [FieldB] to a desired value. For this test "20" Set [FieldC] to a desired value. For this test "5" Populate any other desired fields Submit the form Open the 'State Form Definition' form Select "Existing" in the 'New or Existing' field Select the [TestFile] from the 'Select State Form' field drop down list Click the [Record Definition] section Select "Update" in the "Add or Update Record" field Select the existing record in the "Select Record" field Click [Define Record Data Elements] Click [New Row] In the "Element Name" field, enter a description of a math function to perform using the numerical fields stated in the set up fields in the file. For this test, "Add fields FieldA, FieldB subtract FieldC" is entered Tab over to the "SQL Generated Data" field Add a math function to accomplish the result For this example, the following expression would be used: MATH(MATH(p.FIELDA,p.FIELDB,'+'),p.FIELDC,'-') Click [New Row] again to add another math function In the "Element Name" field, enter a description of another math function to perform using the numerical fields stated in the set up fields in the file. For this test, "Multiply fields FieldA and FieldB divide by FieldC" is entered Tab over to the "SQL Generated Data" field Add a math function to accomplish the result For this example, the following expression would be used. MATH(MATH(p.FIELDA,p.FIELDB,''),p.FIELDC,'/') Click [Save] to save the changes Click [File Record] Click back to the "State Form Definition" section Click [File Form] Validate the definition files successfully Open form "State Form File Generation" In the "State Form" field, select [TestFile] Select the "Compile" button in the "File Generations Options" field Click [Process] Click [OK] at the "Compile Complete" message Select the "Dump File" button in the "File Generations Options" field Click [Process] The "RADplus_SF_File_Dump" report will display Locate the record row for [TestClient] Validate the resulting value for the math calculation set up in step 2g is correct. For this test (10+20-5), the expected result would be "15" Validate the resulting value for the math calculation set up in step 2h is correct. For this test (10 x 20 divided by 5), the result would be "40" Scenario 2: State Form Definition -Validate 'Automatically Purge Posted Compiles' with "Days To Save Compile Data" set to "0"* Specific Setup: Have a state form definition file created [SFfile] in form "State Form Definition" that has not yet been complied in form "State Form File Definition" Steps Open the 'State Form Definition' form Select 'Existing' in the 'New or Existing' field Select the [SFfile] Scroll to the bottom of the form Set the 'Days to Save Compile Data' field to "0". Navigate to the 'Definition Options' field. Click the help message icon next to field label. Validate message includes information regarding the "Automatically Purge Posted Compiles" selection that states, If selected, compiles automatically deleted based on the selection in the 'Days To Save Compile Data' field value will "also" delete Posted files (where a file has been generated on server) Leave the 'Automatically Purge Posted Compiles' selection, not selected File the definition Open the 'State Form File Generation' form Select the [SFfile] Select "Compile" in the "File Generations Options" field Click [Process] to create the compile. [CompileA] Validate "Process Complete" is displayed Click to [Dump the File] in the "File Generations Options" field Click [Process]. Validate the dump file report displays data Repeat step 4b to compile another file. [CompileB] Click the "Select File" dropdown to view the compiles Validate [CompileA] is not present as expected, as prompt 'Days to Save Compile Data' field was set to "0". Validate the new compile [CompileB], is available for selection Select [CompileB] Select "Create File on Server" in the "File Generations Options" field Click [Process]. Validate "Process Complete" is displayed Repeat step 8b to create another compile. [CompileC] Click the 'Select File" dropdown to view the compiles Validate the new compile is present [CompileC] Validate [CompileB] the one created on the server is present as well as expected, since prompt 'Automatically Purge Posted Compiles' was not selected in step 3d Re-open the 'State Form Definition' form Select the [SFfile] for edit Navigate to the 'Definition Options' field This time select the 'Automatically Purge Posted Compiles' selection File the definition Return to the 'State Form File Generation' form Select the [SFfileA] Select "Compile" in the "File Generations Options" field Click [Process] to create another compile. [CompileD] Validate "Process Complete" is displayed Click the 'Select File" dropdown to view the compiles Validate the new compile is present [CompileD] Validate [CompileC] is not present as 'Days to Save Compile Data' field to "0". Validate [CompileB] the one created on the server is also not present this time, since prompt 'Automatically Purge Posted Compiles' was selected in step 5 Scenario 3: State Form Definition -Validate 'Automatically Purge Posted Compiles' with "Days To Save Compile Data" greater than "0" Specific Setup: Have a state form definition file created [SFfile] in form "State Form Definition" that has not yet been complied in form "State Form File Definition" Steps Open the 'State Form Definition' form Select 'Existing' in the 'New or Existing' field Select the [SFfile] Scroll to the bottom of the form Set the 'Days to Save Compile Data' field to any value greater than "0". Navigate to the 'Definition Options' field. Click the help message icon next to field label. Validate message includes information regarding the "Automatically Purge Posted Compiles" selection that states, If selected, compiles automatically deleted based on the selection in the 'Days To Save Compile Data' field value will "also" delete Posted files (where a file has been generated on server) Leave the 'Automatically Purge Posted Compiles' selection, not selected File the definition Open the 'State Form File Generation' form Select the [SFfile] Select "Compile" in the "File Generations Options" field [CompileA] Click [Process] to create the compile [CompileA] Validate "Process Complete" is displayed Click to [Dump the File] in the "File Generations Options" field Click [Process]. Validate the dump file report displays data Repeat step 4b to compile the file again, to create another compile [CompileB] Click the "Select File" dropdown to view the compiles Validate [CompileA] is present as expected, as prompt 'Days to Save Compile Data' field was set to greater than "0". Validate the new compile [CompileB], is also available for selection Select [CompileB] Select "Create File on Server" in the "File Generations Options" field Click [Process]. Validate "Process Complete" is displayed Repeat step 8b to compile the file again to create another compile [CompileC] Click the "Select File" dropdown to view the compiles Validate the new compile is present [CompileC] Validate [CompileA] is still present Validate [CompileB] the one created on the server is present as well as expected, since prompt 'Automatically Purge Posted Compiles' was not selected in step 3d Re-open the 'State Form Definition' form Select the [SFfile] for edit Navigate to the 'Definition Options' field This time select the 'Automatically Purge Posted Compiles' selection File the definition Return to the 'State Form File Generation' form Select the [SFfile] Select "Compile" in the "File Generations Options" field Click [Process] to create the new compile. [CompileD] Validate "Process Complete" is displayed Click the "Select File" dropdown to view the compiles Validate the new compile is present [CompileD] Validate [CompileA], [CompileB] and [CompileC] are also still present, since the 'Days to Save Compile Data' field is set greater than "0".	Topics • State Form Tools • NX
Update 39 Summary \| Details Widget - form launch links Scenario 1: Validate data in Widgets enabled with "Enhanced Widget View" functionality Specific Setup: [TestClientA] has a row [RowA] submitted in a "Progress Notes" form [TestForm]. For this test form "Progress Notes (Group and Individual)" is used [TestClientB] does not have a row filed yet in [TestForm] Have the following widgets created to display "Progress Notes" data in the "SYSTEM.cw_patient_notes" table [WidgetA] created in form "Widget Definition" with prompt "Enhanced Widget View" set to "Yes" [WidgetB] created in form "Widget Wizard" with prompt "Enhanced Widget View" set to "Yes" Each widget includes the field "NOT_uniqueid", which is configured as a link that will launch [TestForm] and populate the form with the data filed in [RowA] Logged in user has all widgets set up on their home view or alternate view Steps At the home view, select [TestClientA] Validate [WidgetA] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column has "Up/Down" arrows and a "Search" filter box below each column name, indicative that enhanced widget functionality is enabled for the widget as expected Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view Validate [WidgetB] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column does "not" have "Up/Down" arrows and a "Search" filter box below each column name as expected, indicative that enhanced widget functionality is "not" enabled for the widget Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed for [RowA] Close the form, to return to the home view At the home view, select [TestClientB] Open [TestForm] Populate all the desired fields and submit the row [RowA] for [TestClientB] At the home view, select [TestClientB] Validate [WidgetA] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column has "Up/Down" arrows and a "Search" filter box below each column name, indicative that enhanced widget functionality is enabled for the widget as expected Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view Validate [WidgetB] is populated with the expected column data filed in [RowA] for form [TestForm] Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed for [RowA] Close the form, to return to the home view Scenario 2: Validate data in Widgets 'not' enabled with "Enhanced Widget View" functionality Specific Setup: [TestClientA] has a row [RowA] submitted in a '"Progress Notes" form [TestForm]. For this test form "Progress Notes (Group and Individual)" is used [TestClientB] does not have a row filed yet in [TestForm] Have the following widgets created to display "Progress Notes" data in the "SYSTEM.cw_patient_notes" table [WidgetA] created in form "Widget Definition" with prompt "Enhanced Widget View" set to "No" [WidgetB] created in form "Widget Wizard" with prompt "Enhanced Widget View" set to "No" Each widget includes the field "NOT_uniqueid", which is configured as a link that will launch [TestForm] and populate the form with the data filed in [RowA] Logged in user has all widgets set up on their home view or alternate view Steps At the home view, select [TestClientA] Validate [WidgetA] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column does "not" have "Up/Down" arrows and a "Search" filter box below each column name indicative that enhanced widget functionality is "not" enabled for the widget, as expected Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view Validate [WidgetB] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column does "not" have "Up/Down" arrows and a "Search" filter box below each column name as expected, indicative that enhanced widget functionality is "not" enabled for the widget Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view At the home view, select [TestClientB] Open [TestForm] Populate all the desired fields and submit row [RowA] for [TestClientB] At the home view, select [TestClientB] Validate [WidgetA] is populated with the expected column data filed in [RowA] for form [TestForm] Verify each column does "not" have "Up/Down" arrows and a "Search" filter box below each column name, indicative that enhanced widget functionality is "not" enabled for the widget as expected Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view Validate [WidgetB] is populated with the expected column data filed in [RowA] for form [TestForm] Click the highlighted data link in column "NOT_uniqueid" Validate [TestForm] is launched and contains the expected data filed in [RowA] Close the form, to return to the home view ScriptLink - Multiple Iteration Grids Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: TestFormA (Modeled form with Multiple Iteration Table) Scenario 1: Validate a "ScriptLink" script is triggered on a forms containing a "Multiple Iteration" grid Specific Setup: Have a modeled form [TestForm] that contains a "Multiple Iteration" section on the form The "Multiple Iteration" section contains a "Scrolling Text Field" and any other desired field types Have any "ScriptLink" script imported in the section containing the "Multiple Iteration" grid. For this example, a script is used that will display a test warning when a value is entered in a specific field [FieldA] Steps Open form [TestFormA] and select a desired client [TestClient] Click to the main section of the form Populate all the desired fields in that section Click to the "Multiple Iteration Section" Click to add the first row to the grid Populate the "Scrolling Text Field" with the desired text [TextFirstRow] Navigate to [FieldA] and enter a value Validate the "ScriptLink" script is triggered and warning message is displayed and click [OK] Populate any other desired fields in the section Click to add the second row to the grid Populate the "Scrolling Text Field" with the desired text [TextSecondRow] Navigate to [FieldA] and enter a value Validate the "ScriptLink" script is triggered and warning message is displayed and click [OK] Populate any other desired fields in the section Click to add the third row to the grid Populate the "Scrolling Text Field" with the desired text [TextThridRow] Navigate to [FieldA] and enter a value Validate the "ScriptLink" script is triggered and warning message is displayed and click [OK] Populate any other desired fields in the section Submit the form Return to form [TestForm] and select [TestClient] Select the row filed in step 1 for edit Click to the main section of the form Validate all the other fields are populated as expected Click to the "Multiple Iteration Section" Select the first row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextFirstRow] populated in step 1 Validate all the other fields are populated as expected Select the second row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextSecondRow] populated in step 1 Validate all the other fields are populated as expected Select the third row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextThirdRow] populated in step 1 Validate all the other fields are populated as expected Select the first row to the grid again and click [Edit] Change the text in the "Scrolling Text Field" to a new value [TextNewValue] Click the [Add] button to add a new row Populate the "Scrolling Text Field" with the desired text [TextFourthRow] Populate any other desired fields in the section Submit the form Return to form [TestForm] and select [TestClient] Click to the "Multiple Iteration Section" Select the first row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with the new text [TextNewValue] entered in step 2 Select the second row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextSecondRow] populated in step 1 Select the third row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextThirdRow] populated in step 1 Select the fourth row to the grid and click [Edit] Validate the "Scrolling Text Field" is populated with [TextFourthRow] populated in step 2	Topics • Widget Definition • Widgets • NX • Scriptlink
Update 41 Summary \| Details Forms - Switching from "Final" to "Draft" Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form With Service Documentation Draft/Final Dialog - The following required prompt(s) do not contain information Patient Health Questionnaire-9 Scenario 1: Modeled 'Service Documentation' Forms - Field Validations Specific Setup: A modeled table must be defined in 'Table Definition' with the following (Table A): Fields that are mapped in the 'Service Documentation' section that are required for Service Documentation functionality. These include: 'Progress Note For', 'Date of Service', 'Service Start Time', 'Service End Time', 'Service Duration', 'Location', 'Service Program', 'Service Charge Code', 'Service Practitioner' and 'Draft/Final' fields. Fields added that are not mapped for Service Documentation functionality. A modeled form (Form A) must be defined in 'Form Definition' that uses "Table A" and contains all Service Documentation and non-Service Documentation fields. A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access "Form A". Select "New Service" in the 'Progress Note For' field. Enter the desired date in the 'Date of Service' field. Enter the desired time in the 'Service Start Time' and 'Service End Time' fields. Select the desired value in the 'Service Charge Code' field. Enter the desired value in the 'Service Duration' field. Select the desired value in the 'Service Practitioner' field. Populate all other required and desired fields. Select "Final" in the 'Draft/Final' field. Validate a message is displayed stating: Selecting "Final" prevents future edits. Click [OK]. Validate all fields are disabled. Select "Draft" in the 'Draft/Final' field. Validate all fields are enabled. Click [Submit]. Select "Client A" and access "Form A". Select the draft filed in the previous steps and click [Edit]. Validate all previously filed data is displayed. Close the form.	Topics • Forms • Service Documentation
Update 42 Summary \| Details Client Chart - Credentialing information Scenario 1: Chart View - Form data row validations Specific Setup: In form "Practitioner Enrollment": [StaffA] and [StaffB] both have "Practitioner Credentials" added with an "Effective" date that ends after today. [CredToday] In addition, [StaffA] and [StaffB] both have "Practitioner Credentials" added with an "Effective" date that starts tomorrow. [CredTomorrow] Have a form [TestForm] enabled for document routing [StaffB] has [TestForm] added to their "Chart" view [StaffB] has the "My To Do's" widget on their home view Have registry setting "Display Document Routing Status on Chart Items" set to "Yes" Log in as [StaffA] Steps Open form [TestForm] Populate any desired fields Submit the form as "Final" Click to accept and route the document At the "Route To Document" screen, add [StaffB] as the approver Submit the form to route the document Log out as [StaffA] Log in as [StaffB] Navigate to the "My To Do's" widget Locate the to sent in step 1 Click to review the To Do Validate information is displayed as expected Click [Accept] to approve the To Do Navigate to the home view Select [TestClient] and double click to open their chart In "Chart", select [TestForm] from the forms list to review the record filed Validate record header data bar indicates the record was submitted by [StaffA] and based on the "Effective" date in the setup, their expected credentials [CredToday]. For example "Submitted by [StaffA] Certified Drug/Alcohol Counselor (CADC)" Validate the record data (Main Section) region contains the expected data submitted Validate the record data (Document Routing) region contains the "Approvers" field populated with [StaffB] and based on the "Effective" date in the setup, their expected credentials [CredToday]. For example "Approvers: [StaffB] Certified Pediatric Nurse (CPN)" Close Chart The following day, repeat steps 1 thru 4 again Navigate to the home view Select [TestClient] and double click to open their chart In "Chart", select [TestForm] from the forms list to review the record filed Validate record header data bar indicates the record was submitted by [StaffA] and based on the "Effective" date in the setup, their expected credentials [CredTomorrow] Validate the record data (Main Section) region contains the expected data submitted Validate the record data (Document Routing) region contains the "Approvers" field populated with [StaffB] and based on the "Effective" date in the setup, their expected credentials [CredTomorrow]	Topics • Chart Review
Update 43 Summary \| Details Identity Manager - logins Scenario 1: Avatar "Identity Manager" - User Login validation Specific Setup: Have a system with the "Identity Manager" module installed and configured Have an active "Identity Manager" user set up in form "User Definition" [TestUser] Have a query or report to display data in the "SYSTEM.radplus_audit_failed_login" table Steps Launch the Avatar login screen Select the desired system code in the "System Code" field Populate the "Username" field with any invalid user name [InvalidUser] Populate the "Password" field with any desired password [DesiredPassword] Click [Sign In] Validate the presented with a "Sign In" dialog error message that states, "'Login Failed'. Note the current date and time and click [OK] Validate the user is returned to the login screen Run the query or report on the "SYSTEM.radplus_audit_failed_login' table. Validate the results include the failed login information for [InvalidUser] for the date and time noted in step 1 Validate the "login_failed_reason" field is populated with "Invalid User" At the login screen Select the desired system code in the "System Code" field Populate the "Username" field with a valid "Identity Manager" user name [TestUser] Populate the "Password" field with an invalid password [InvalidPassword] Click [Sign In] Validate the presented with a "Sign In" dialog error message that states, "Login Failed" Note the current date and time and click [OK] Validate the user is returned to the login screen Run the query or report on the "SYSTEM.radplus_audit_failed_login" table. Validate the results include the failed login information for [TestUser], for the date and time noted in step 3 Validate the "login_failed_reason" field is populated with "Invalid Password" At the login screen Select the desired system code in the "System Code" field Populate the "Username" field with the user name for user [TestUser] Populate the "Password" field with the valid password for user [TestUser] Click [Sign In] Validate the user has logged in successfully. In the "Search Forms" search box, search for any form Validate the form is launched as expected Populate any desired fields in the form Submit the form Validate submission is successful	Topics • Identity Manager
Update 44 Summary \| Details "Registry Settings" form - Scenario 1: Registry Settings - submitting a registry setting Specific Setup: In form "Registry Settings", have two registry settings whose current submitted value haves the following character lengths. For example the "URL" type registry setting, "ICD-10 Diagnosis Search" [RegA] has a value [CurrValue] that is greater than "50" characters in length [RegB] has a value [CurrValue] that is less than or equal to "50" characters in length. Steps Access the "Registry Settings" form. In the registry settings search field, search for [RegA] Validate the "Registry Setting Value" field is populated with value [CurrValue], whose length is greater than "50" characters Change the current value to any other value greater that's greater than "50" characters [NewValue] Submit the form Validate the submission results indicate that the registry setting has been submitted successfully Click "Yes" to return to the form In the registry settings search field, search for [RegA] again Validate the current value is the [NewValue] entered in step 1a Change the current value to a value greater less than "50" characters Submit the form Validate the submission results indicate that the registry setting has been submitted successfully Click "Yes" to return to the form In the registry settings search field, search for registry setting [RegA] again Validate the current value is the [NewValue] entered in step 1b Close the form Re-open form "Registry Settings" In the registry settings search field, search for [RegB] Validate the "Registry Setting Value" field is populated with value [CurrValue], whose length is less than or equal to "50" characters Change the current value to a value greater than "50" characters [NewValue] Submit the form Validate the submission results indicate that the registry setting has been submitted successfully Click "Yes" to return to the form In the registry settings search field, search for [RegB] again Validate the current value is the [NewValue] entered in step 2a Change the current value to a value that is less than or equal to "50" characters [NewValue] Submit the form Validate the submission results indicate that the registry setting has been submitted successfully Click "Yes" to return to the form In the registry settings search field, search for [RegB] again Validate the current value is the [NewValue] entered in step 2b Close the form	Topics • Registry Settings • NX
Update 45 Summary \| Details Tabular Data Editor - grids Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Guarantors/Payors Scenario 1: Validate results adding multiple rows in "Tabular Data Editor" (TDE) grids Specific Setup: Have access to one or more forms that contain a "(TDE) Tabular Data Editor" grid on the form. For this test, the "Treatment Plan" and the "Guarantor/Payers" forms are used Admit a new client or have an existing client on the system for testing [TestClient] Multiple "Guarantors" exist on the system, for example ten or more Multiple "Problem" codes exist in the system, for example ten or more Steps Open the "Treatment Plan" form Select [TestClient]. Populate any required fields on the main form. Navigate to the "Problems" grid and click [New Row] Add a problem to the grid Add another new row the same problem as in the previous step Validate a message displays blocking entry that states "Problem already exists", as expected. Continue adding ten or more rows to the grid Click [Launch Plan]. Validate the treatment plan tree view loads without any warnings. Validate all the problems entered in step 1c are present are displayed in the view as expected Click [Back to Plan Page] Navigate to the "Problems" grid and add one or more problems Click [Launch Plan]. Validate the treatment plan tree view loads without any warnings. Validate all the problems added in the previous steps are displayed in the view as expected Click [Back to Plan Page] Submit the treatment plan as "Draft" Validate submission is successful Re-open "Treatment Plan form" Select [TestClient]. Click to edit the row submitted in step 1 Navigate to the "Problems" grid Add one more problems to the grid Click [Launch Plan]. Validate the treatment plan tree view loads without any warnings. Validate all the problems entered in step 1 and in the previous step, are present are displayed in the tree view as expected Click [Back to Plan Page] Submit the treatment plan Validate submission is successful Re-open "Treatment Plan form" Select [TestClient]. Click to edit the row just submitted Click [Launch Plan]. Validate the treatment plan tree view loads without any warnings. Validate all the problems added in the previous steps are present are displayed in the tree view as expected Open the "Guarantors/Payors" form Click "Edit" In the "Guarantor Code" field, select a desired guarantor [TestGuarantor] Navigate to the "Carrier Codes" section In the "Carrier Codes for Secondary Billing" grid, click [New Row] Select any guarantor in the "Guarantor" field Enter a desired code in the "Carrier Code" field Click [File] Validate the guarantor and carrier code are added to the grid Click [New Row] again to add another guarantor Select the same guarantor as in the previous step Validate the error "Please select a different Guarantor, Guarantor is already in the grid", is displayed Click [OK] Click [New Row] again, this time add a different guarantor Enter a desired code in the "Carrier Code" field Click [File] Validate the guarantor and carrier code are added to the grid Repeat the previous step ten or more times Validate all rows added are displayed as expected in the grid Navigate back to the "Guarantor/Payors" section Click [File] to submit the changes Close the form Re-open "Guarantors/Payors" form Click "Edit" In the "Guarantor Code" field, select [TestGuarantor] Navigate to the "Carrier Codes" section Validate all the rows added in the "Carrier Codes for Secondary Billing" grid in step 4, are present and populated as expected Add one or more rows to the grid Navigate back to the "Guarantor/Payors" section Click [File] to submit the changes Close the form Re-open "Guarantors/Payors" form Click "Edit" In the "Guarantor Code" field, select [TestGuarantor] Navigate to the "Carrier Codes" section Validate all the rows added in the "Carrier Codes for Secondary Billing" grid in step 4 and 5, are present and populated as expected in the grid	Topics • Tabular Data Editor
Update 46 Summary \| Details Progress Notes (Group and Individual) - Open to Group Default Notes Section Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Group Registration Create New Progress Notes Form Progress Notes (Group and Individual) 11 Scenario 1: Progress Notes (Group and Individual) - Open To Group Default Notes Specific Setup: Enable the registry setting "Open To 'Group Default Notes' Section" by setting it to "Y". Using "Document Routing Setup", enable document routing for the "Progress Notes (Group and Individual)" form. Create a group with 2 or more group members using the "Group Registration" form. Steps Open the "Progress Notes (Group and Individual)" form. Validate the form opens to the "Group Default Notes" section. Fill out all required fields and create a group note. Edit the group note. Navigate to the "Individual Note" section. Individualize the progress notes for each group member. Using the "Clinical Document Viewer" form, validate the documents were filed. Open the "Registry Settings" form. Disable the "Open To 'Group Default Notes' Section" registry setting by setting it to "N". Open the "Progress Notes (Group and Individual)" form. Validate the form opens to the "Individual Notes" section. Navigate to the "Group Default Notes" section. Fill out all required fields and create a group note. Edit the group note. Navigate to the "Individual Note" section. Individualize the progress notes for each group member. Using the "Clinical Document Viewer" form, validate the documents were filed. Scenario 2: Registry Setting - Open to 'Group Default Notes' Section Specific Setup: Disable the registry setting "Open To 'Group Default Notes' section" registry setting by setting it to "N". Steps Open the "Progress Notes (Group and Individual)" form. Validate the form opens to the "Individual Progress Notes" section. Open the "Registry Settings" form. Enable the registry setting "Open To 'Group Default Notes' Section" by setting it to "Y". Open the "Progress Notes (Group and Individual)" form. Validate the form opens to the "Group Default Notes" section. Scenario 3: Copy of Progress Notes (Group and Individual) - Open To Group Default Notes section Specific Setup: Using the "Create New Progress Notes" form, create a new copy of the Progress Notes (Group and Individual). Note the copy number. Using the "User Definition" or "User Role Definition" form: Give the user access to this new progress notes form on the "Forms and Tables" section under the "Select forms for User Access" button. Using the "Registry Settings" form, enable "Open To 'Group Default Notes' Section" registry setting by setting it to "Y" for the form created in previous steps. Using the "Document Routing Setup" form, enable document routing for the form created in previous steps. Create a group of 2 or more clients using the "Group Registration" form. Steps Using the new group progress note form: Validate the form opens to the "Group Default Note" section. Generate a group default note and click [Submit Note]. Edit the "Group Default Note". Navigate to the "Individual Note" section and individualize, finalize and route the document to an approver. Repeat above until all group members are processed. Navigate to the "ToDo" widget: Approve the "ToDo" for each group member. Using the "Clinical Document Viewer" form: Validate the documents were filed by viewing/print each one. Using the "Registry Settings" form: Enable "Open To 'Group Default Notes' Section" registry setting by setting it to "Y" for the form created in setup. Using the new group progress note form: Validate the form opens to the "Individual Note" section. Navigate to the "Group Default Note" section. Generate a group default note and click [Submit Note]. Edit the "Group Default Note". Navigate to the "Individual Note" section and individualize, finalize and route the document to an approver. Repeat above until all group members are processed. Navigate to the "ToDo" widget: Approve the "ToDo" for each group member. Using the "Clinical Document Viewer" form. Validate the documents were filed by viewing/print each one.	Topics • Progress Notes • NX
Update 47 Summary \| Details Form Launch events Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Call Intake Practitioner Enrollment Scenario 1: Validate triggering site specific event logic to launch an additional form Specific Setup: Have access to any "Progress" note form [FormA] Have access to any "Client" based modeled form [FormB] Have access to any "Staff" based modeled form [FormC] Have access to form "Call Intake" and form "Practitioner" enrollment In form "Dictionary Update", select the "Client" database and search for any "SS Call Intake Dictionary" field Add three dictionary values: [DictA], [DictB] and [DictC] Open form "Site Specific Section Modeling", select form "Site Specific Call Intake" form Select "Yes" in prompt "Enable Site Specific Section" Click the "Prompt Definition" section and add the "SS Call Intake Dictionary" Set field "Initially Required" to "No" In the "Event Definition" section, add three events The first event set will launch [FormA] with [DictA] is selected in the field The second event set will launch [FormB] with [DicB] is selected in the field The third event set will launch [FormC] with [DictAC] is selected in the field Submit the form Open form "Site Specific Section Modeling", select form "(Practitioner Enrollment) Site Specific Enrollment" form Select "Yes" in prompt "Enable Site Specific Section" Click the "Prompt Definition" section and add any "SS Enrollment Dictionary" Set field "Initially Required" to "No" In the "Event Definition" section, add three events The first event set will launch [FormA] with [DictA] is selected in the field The second event set will launch [FormB] with [DicB] is selected in the field The third event set will launch [FormC] with [DictAC] is selected in the field Submit the form The logged in user has the "Client & Staff" widget on their home view Steps Open the "Call Intake" form At the "Select Client" dialog Populate the last and first name for a new client [NewClientA] Click Search Click [OK] to the no records found Click [New] client to launch the "Call Intake" form On the "Call Intake" section Validate the client name field indicates [NewClient] Populate any required and desired fields on that section Click the "Site Specific Call Intake" section Click the "SS Call intake dictionary" field drop down list and select [DictA] At the "Form Launch" dialog, click [OK] to launch the "Progress Note" form Validate a message is received "Based on your inputs the [FormA] should launch, however this form cannot be launched for a Client not submitted to the database" Click [OK] Validate the user is returned to the form Click the "SS Call intake dictionary" field drop down list and select [DictB] At the "Form Launch" dialog, click [OK] to launch the "Client" based modeled form Validate a message is received "Based on your inputs the [FormB] should launch, however this form cannot be launched for a Client not submitted to the database" Click [OK] Validate the user is returned to the form Click the "SS Call intake dictionary" field drop down list and select [DictC] At the "Form Launch" dialog, click [OK] to launch the "Staff" based modeled form Enter a valid "Staff" member [TestStaff] in the search field and click [Select] On [FormC], populate the desired fields on the form Submit the form Validate the form files successfully Click [Submit] to submit the "Call Intake" form Validate the form files successfully At the home view, navigate to the "Client & Staff" widget Search for [NewClientA] Validate the client is found Open the "Practitioner Enrollment" form At the "Select Staff" dialog, enter the desired name for the new staff member [StaffNew] Validate there are no matches found Click [New Staff] to launch the "Practitioner Enrollment" form Click the "Practitioner Enrollment" section Populate the required fields and any other desired fields in that section Click the "Site Specific Enrollment" section Click the "SS Enrollment Dictionary" field and select [DictA] At the "Form Launch" dialog, click [OK] to launch the "Progress Note" form On [FormA], populate the required and desired fields Submit the form Validate the form files successfully Navigate back to the "Practitioner Enrollment" form Click the "SS Enrollment Dictionary" field and select [DictB] At the "Form Launch" dialog, click [OK] to launch the "Client" based modeled form Select any client and click [OK] On [FormB], populate the required and desired fields on the form Submit the form Validate the form files successfully Navigate back to the "Practitioner Enrollment" form Click the "SS Enrollment Dictionary" field and select [DictC] Validate a message is received "Based on your inputs the [FormC] should launch, however this form cannot be launched for a Staff not submitted to the database" Click [OK] Validate the user is returned to the form Click [Submit] to submit the form Validate the form files successfully At the home view, navigate to the "Client & Staff" widget Click the "Staff" tab Search for [StaffNew] Validate the staff member is found	Topics • Site Specific Section Modeling • NX
Update 48 Summary \| Details Document Routing - Replace ‘Date Created’ with ‘Date Signed’ on Document Routing Images. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Disclosure Management Disclosure Management Configuration Scenario 1: Disclosure Management - Date Created vs. Date Signed - Document Routing disabled Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be enabled. Using the "Document Routing Setup" form, disable document routing for Progress Notes (Group and Individual), Treatment Plan and a user modeled form. Using "Disclosure Management Configuration", include "Progress Notes (Group and Individual), Treatment Plan and a user modeled form among the forms available to the "Disclosure Management" form. Steps Using the "Progress Notes (Group and Individual)" form: Generate a progress note. Finalize the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using the "Treatment Plan" form: Generate a new treatment plan. Finalize the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using a user modeled form: Generate a new form. Finalize the form. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Open the "Disclosure Management" form: Generate a disclosure packet. On the Request section, select the client, episode and Request Information Start and End Dates that will encompass the forms previously generated for this test. Click "Apply Filters to Document Images" button. In the "Requested Chart Items" box, select "Progress Notes (Group and Individual)", Treatment Plan, user modeled forms you want to include in the disclosure packet. In the "Requested Document Images" box, select the forms for Progress Notes (Group and Individual), Treatment Plan and user modeled form you want to include in the disclosure packet. Navigate to the "Authorization" section. Select the same Episode and the Authorization Start and End Dates. Click "Yes - Default All Chat Items to Yes" radio button. Click "Update Chart Items Authorized for Disclosure" button. Click "Save" button. Click "Refresh Chart Items" button. Click "Yes - Default All Document Items To Yes" radio button. Click the "Update Document Images Authorized for Disclosure" button. Click "Save" button. Click "Refresh Document Images" button. Navigate to the "Disclosure" section. Populate the "Disclosure Date" and "Disclosure Time". Select all items in the "Chart Disclosure Information" box. Select all items in the "Disclosure Images" box. Select "Electronic" in the "Disclosure Method" field. Click "Process" button. Select various forms and then press "View". Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Disclose" button. The final disclosure packet is presented. Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Save" to generate the disclosure packet into a PDF document to be provided for the request, authorization and disclosure. Open the "Disclosure Management" form: Select to edit the disclosure that was just filed. Validate it displays as it was previously saved. Scenario 2: Disclosure Management - Form Validations Specific Setup: In the 'View Attachment Types field on the 'Disclosure Management Configuration' form, select various modeled and product form type attachments to include for requesting and authorizing document images for disclosure. In the product and modeled forms selected in the previous step, have documents generated for a client in multiple episodes (Client A). The 'Sort Episodes by Admission Date' registry setting must be enabled. Steps Select "Client A" and access the 'Disclosure Management' form. Enter a date in the 'Request Date' field. Enter a date in the 'Request Information Start Date' field. Enter a date in the 'Request Information End Date' field. In the 'Requested Episode(s)' field, validate all episodes are listed and displayed in a readable format. Select the desired episodes to include. Click [Apply Filter to Document Images]. Select the desired items in the 'Requested Chart Items' field. Select the desired documents in the 'Requested Document Images' field. Enter an organization name in the 'Organization' field. Go to the 'Authorization' section. Select "Yes" in the 'Signed Authorization On File' field. Enter a date in the 'Authorization Start Date' field. Enter a date in the 'Authorization End Date' field. Validate all episodes are listed and displayed in a readable format in the 'Authorization Episode(s)' field. Select desired episodes to include in the 'Authorization Episode(s)' field. Click [Update Chart Items Authorized For Disclosure]. Validate all items are set to "Yes" in the 'Authorized' field. Click [Save]. Click [Refresh Chart Items]. Click [Apply Filter to Document Images]. Click [Update Document Images Authorized for Disclosure]. Validate all items are set "Yes" in the 'Authorized' field. Click [Save]. Click [Refresh Document Images]. Go to the 'Disclosure' section. Enter a date in the 'Disclosure Date' field Enter a time in the 'Disclosure Time' field. Select "Electronic" in the 'Disclosure Method' field. Click [Process]. Validate the items list in the 'Disclosure Management' panel are as expected. Select the item and click [View]. Validate the documents displays as expected. Click [Disclose]. Validate the disclosure displays as expected and 'Save' displays. Click [Save]. Validate a 'Confirm' dialog stating: "Save PDF on your computer?" and click [OK]. Validate the file downloads. Validate a 'Disclosure' dialog stating: "Once this Disclosure Management record is filed with a Disclosure Date entered it will no longer be available for edit. This record will be available to view and print items." and click [Cancel]. Validate a dialog stating: "Filing cancelled." and click [OK]. Click [Save]. Validate a 'Confirm' dialog stating: "Save PDF on your computer?" and click [Cancel]. Validate nothing downloads. Validate a 'Disclosure' dialog stating: "Once this Disclosure Management record is filed with a Disclosure Date entered it will no longer be available for edit. This record will be available to view and print items." and click [OK]. Validate the form closes. Scenario 3: Registry Setting - Replace 'Date Created' with 'Date Signed' Steps Open the "Registry Setting" form. Set the "RADplus->Document Routing->Document Routing Setup->->->Replace 'Date Created' with 'Date Signed' on Document Routing Images' to any value other than "Y" or "N". Validate the error message "The selected value is not valid in the current system code for the following reason: Please enter "Y" or "N". Set registry setting to "N". Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form, Open the "Progress Notes (Group and Individual)" form. File an individual progress note. Finalize and route the note. Navigate to the "ToDo" widget for the approver. Validate the first line of every page of the document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Using the "Clinical Document Viewer", validate the document displays as it was filed with "Date Crated" on the first line of every page. Open the "Registry Setting" form. Set registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" to "Y". Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form, form. Open the "Progress Notes (Group and Individual)" form. File and individual progress note. Finalize and route the note. Navigate to the "ToDo" widget for the approver. Validate the first line of every page of the document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Using the "Clinical Document Viewer", validate the document displays as it was filed with "Date Signed" on the first line of every page. Scenario 4: Progress Notes (Group and Individual) - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for the "Progress Notes (Group and Individual)" form. Using "Disclosure Management Configuration", the "Progress Notes (Group and Individual)" form among the forms available to the "Disclosure Management" form. Steps Open the "Progress Notes (Group and Individual) form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the "Progress Notes (Group and Individual)" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 5: Treatment Plan - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for the "Treatment Plan" form. Using "Disclosure Management Configuration", the "Progress Notes (Group and Individual)" form among the forms available to the "Disclosure Management" form. Steps Open the "Treatment Plan" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the "Treatment Plan" form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 6: User Modeled Form - Date Created vs. Date Signed Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be disabled. Using the "Document Routing Setup" form, enable document routing for a user modeled form. Using "Disclosure Management Configuration", the user modeled form among the forms available to the "Disclosure Management" form. Steps Open the user modeled form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Created" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Registry Setting" form. Enable the registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing images". Open the user modeled form. Create a form. Finalize and route the document. Navigate to the "ToDo" widget. Validate the first lien of every document begins with "Date Signed" followed by the date and time the document was finalized. Click "Accept". Click "Sign". Close the "ToDo" widget. Open the "Clinical Document Viewer" form. View both documents that were just saved with the different labels. Validate the first one finalized includes the "Date Created" label. Validate the second one finalized includes the "Date Signed" label. Scenario 7: Disclosure Management - Date Created vs. Date Signed - Document Routing Enabled Specific Setup: Registry setting "Replace 'Date Created' with 'Date Signed' on Document Routing Images" must be enabled. Using the "Document Routing Setup" form, enable document routing for Progress Notes (Group and Individual), Treatment Plan and a user modeled form. Using "Disclosure Management Configuration", include "Progress Notes (Group and Individual), Treatment Plan and a user modeled form among the forms available to the "Disclosure Management" form. Steps Using the "Progress Notes (Group and Individual)" form: Generate a progress note. Finalize and route the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using the "Treatment Plan" form: Generate a new treatment plan. Finalize and route the note. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Using a user modeled form: Generate a new form. Finalize and route the form. Validate the first line of ever page of the document begins with "Date Signed" followed by the date and time the document was finalized. Open the "Disclosure Management" form: Generate a disclosure packet. On the Request section, select the client, episode and Request Information Start and End Dates that will encompass the forms previously generated for this test.. Click "Apply Filters to Document Images" button. In the "Requested Chart Items" box, select "Progress Notes (Group and Individual), Treatment Plan, user modeled forms you want to include in the disclosure packet. In the "Requested Document Images" box, select the forms for Progress Notes (Group and Individual), Treatment Plan and user modeled form you want to include in the disclosure packet. Navigate to the "Authorization" section. Select the same Episode and the Authorization Start and End Dates. Click "Yes - Default All Chat Items to Yes" radio button. Click "Update Chart Items Authorized for Disclosure" button. Click "Save" button. Click "Refresh Chart Items" button. Click "Yes - Default All Document Items To Yes" radio button. Click the "Update Document Images Authorized for Disclosure" button. Click "Save" button. Click "Refresh Document Images" button. Navigate to the "Disclosure" section. Populate the "Disclosure Date" and "Disclosure Time". Select all items in the "Chart Disclosure Information" box. Select all items in the "Disclosure Images" box. Select "Electronic" in the "Disclosure Method" field. Click "Process" button. Select various forms and then press "View". Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Disclose" button. The final disclosure packet is presented. Validate the forms that were filed after the registry setting for "Replace 'Date Created' With 'Date Signed" on all "Document Routing Images" labels begin with "Date Signed" and the date and time the form was finalized. Click "Save" to generate the disclosure packet into a PDF document to be provided for the request, authorization and disclosure. Open the "Disclosure Management" form ; Select to edit the disclosure that was just filed. Validate it displays as it was previously saved.	Topics • Disclosure • NX • Progress Notes (Group And Individual) • Treatment Plan • Modeling
Update 49 Summary \| Details Widget - Data display Scenario 1: Validate "Widget" data load and data refresh Specific Setup: Have a system with various types of widgets defined. For example a "Widget Wizard", "Widget Definition", "SQL Query" and "Console Widget" type widgets Each widget has the field "Allow Refresh" selected For two clients [ClientA] and [ClientB] and any other desired clients, have data filed in the tables that are defined in each widget All widgets have been assigned to a user's [TestUser] home view or additional view Log in as [TestUser] Steps Select [ClientA] Validate all widgets display data as expected Click the "Refresh" button on each widget Validate data displays as expected Repeat step b three or more times for each widget Validate each time, data is returned and displays as expected Select [ClientB] Validate all widgets display data as expected Click the "Refresh" button on each widget Validate data displays as expected Repeat step b three or more times for each widget Validate each time, data is returned and displays as expected Repeat step 2 for any other desired clients Validate results are as expected From the recent client list Click thru each client selected in the previous steps, consecutively As each client is selected: Validate all widgets return and display data as expected My To Do's - Widget Scenario 1: My To Do's Widget - Validate To Do's sent for review or approval Specific Setup: Have a system that has two forms set up, that will generate To Do's. For example forms enabled for document routing [FormA] is a "PM" form [FormB] is a "CWS" form Each form also has the "Enable To Do Creation from Form" functionality set on the form. (This can be done in "Form Definition" or in form "To Do Button Settings") User [StaffA] has access to both [FormA] and [FormB] User [StaffB] has the "My To Do's widget on their home view Log in as [StaffA] Steps Open [FormA] Populate all the desired fields on the form On the left side panel click on the "Create To Do" icon In the "Select Staff" field, select and [StaffB] Click [Add] Validate [StaffB] is added to the "Send To" box In the "Note" field, add a message that will be sent with the To Do Click [Save] Set the form to "Final" At the "Confirm Document" screen, click [Sign and Route] At the "Route To Document" screen, select [StaffB] as the approver Submit the form Validate the form files successfully Repeat step 1 for [FormB] Logout as [StaffA] Log in as [StaffB] Navigate to the "My To Do's: widget Validate for [FormA] there is an "Approve Document" To Do for the for document routed in step 1 Click [Approve Document] Click [Sign] to approve the document Validate for [FormA] there is a "Review To Do Item" To Do for the "Create To Do" sent in step 1 Click the [Review To Do Item] button Click the "Reviewed" check box Click [Submit] Validate for [FormB] there is an "Approve Document" To Do for the for document routed in step 2 Click [Approve Document] Click [Sign] to approve the document Validate for [FormB] there is a "Review To Do Item" To Do for the "Create To Do" sent in step 2 Click the [Review To Do Item] button Click the "Reviewed" check box Click [Submit] Validate all To Do's approved and reviewed have been cleared from the "My To Do's" widget	Topics • Widgets • NX • My To Do's • "My To Do's" widget
Update 50 Summary \| Details View Definition - "View Type" Scenario 1: View Definition - Validate fields Specific Setup: Create or modify a view that is associated with other views in "View Definition". Registry Setting "RADplus->General->Enable Console Widget/Views" must be enabled. Steps Access the 'View Definition' form. Click [Select View]. Select "Add New View" in the 'Select Views' field and click [OK]. Enter "View A" in the 'View ID' field. Enter any value in the 'View Description' field. Select "Home View" in the 'View Type' field. Select any value in the 'Allow User To Customize View' field. Click [Associated Views]. Check all applicable "Associated Views" in the left pane. Validate that the selected views show up in the right pane. Rearrange the views in desired order and click [OK]. Click [Launch View Designer]. Validate that the Widgets are listed in alphabetical order in the Widgets pane. Select one or more widgets and click the right arrow. Validate the selected widgets appear in the 'Available Widgets' field. Drag the Available widgets and drop it onto the 'Default Role Layout' field. Click [Submit], [Submit] and [No]. Access the 'User Definition' form. Enter "User B" in the 'User ID' field. Select "Yes" in the 'Is this user a system administrator' field. Select "No" in the 'Associate User with a User Role' field. Select 'Forms and Tables'. Click [Select Forms for User Access]. Select the 'Avatar PM' item and click [OK]. Select "Level 4" in the 'User Security Level' field. Select "View A" in the 'Home View' field. Populate any desired and required fields. Select 'User Definition' section Click [Generate New Password]. Take note of password and click [Submit]. Validate a 'Form Access' dialog stating: "The following forms are on the menu more than once, and different access levels were selected. The highest selected access will be applied to all menu locations." Click [OK] and [No]. Logout. Log into Avatar as "User B". Validate that the views are displaying on the home view and that they are in the order as rearranged. Access the 'Registry Setting' form. Enter "Enable Documentation View" in the 'Limit Registry Settings to the Following Search Criteria' field. Enter "Y" in the 'Registry Setting Value' field. Click [Submit], [OK], and [No]. Access the 'View Definition' form. Click [Select View]. Select "Add New View" in the 'Select Views' field and click [OK]. Enter "View B" in the 'View ID' field. Enter any value in the 'View Description' field. Navigate to the "View Type" field Validate three selections are available, "Home View", "Chart View" and "Documentation View" Click the "Help Message"(Light bulb) icon Validate the help message displayed indicates "The 'Documentation' view type is only supported in myAvatar NX." Click [OK] to return to the form Select "Documentation View" in the 'View Type' field. Validate the 'Allow Users to Customize View' field is disabled. Click [Associated Views]. Check all applicable "Associated Views" in the left pane. Validate that the selected views show up in the right pane. Rearrange the views in desired order and click [OK]. Validate the 'All Documents Widget' field is enabled. Select any value in the 'All Documents Widget' field. Click [Submit] and [Yes]. Click [Select View]. Select "View B" in the "Select Views" field and click [OK]. Validate that the view displays as it was entered. Click [Delete View] and [Yes]. Click [Select View]. Validate the view has been removed. Close the form.	Topics • NX • NX View Definition
Update 51 Summary \| Details Modeled Forms - Table Alias Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (CWS) Scenario 1: Modeled Forms - "Table Alias" field and data validations Specific Setup: Have a client [TestClient] who is active in an existing episode Have a modeled form [TestForm] that contains: A field [TestField] that is not mapped to any of the field in the "Vital Signs" alias table. For this example a "Dictionary" type field is used Mapped "Table" aliased fields. For this test [TestForm] has the following fields in its table [TestTable], that are mapped in "Table Definition" to the following fields in the "CWS" table alias, "Vital Signs": Date Time Diastolic Blood Pressure Systolic Blood Pressure Respiration Please Note: For the "CWS" "Vital Signs" table alias used in this test, the "Date" and "Time" alias fields are required to be populated at the time submission in order to file the data submitted in the mapped alias fields, into the "SYSTEM.cw_vital_signs" table. Have a report created to display data in the modeled table [TestTable] Have a report created to display data in the "SYSTEM.cw_vital_signs" table Have a report created to display data in the "SYSTEM.RADplus_error_log" table Steps On the home view, select [TestClient] Open form [TestForm] Populate the field [TestField] Populate the table alias mapped "Date" and "Time" fields Populate the other mapped alias fields noted in the setup. Submit the form Validate the form submits successfully Run the report to display data in the modeled table [TestTable] Validate data for all fields populated in step 2a and b, are displayed as expected Run the report to display data in the "SYSTEM.cw_vital_signs" table Validate rows for all the mapped table alias fields populated in step 2b, are displayed as expected Run the report to display data in the "SYSTEM.RADplus_error_log" Validate there are no messages related to the table alias submission displayed, as expected Open form [TestForm] and add a new row Populate just the field [TestField], which is not a mapped alias field Submit the form Validate the form files successfully Run the report to display data in the modeled table [TestTable] Validate data for field [TestField] populated in step 3a is displayed populated as expected Validate none of the other fields are populated in the report, as expected Run the report to display data in the "SYSTEM.cw_vital_signs" table Validate there are no rows populated from the form submission in step 4a, as the required table alias mapped "Date" and "Time" fields were both not populated. Run the report to display data in the "SYSTEM.RADplus_error_log" Validate there are no messages related to table alias submission, as both of the required alias mapped fields were not populated, indicating no attempt to file data in the alias table Open form [TestForm] and add a new row Populate field [TestField] Leave either the alias mapped "Date" or mapped "Time" field unpopulated, and populate any of the other alias mapped fields. Submit the form Validate the form submits successfully Run the report to display data in the modeled table [TestTable] Validate data for all fields populated in step 4a and 4b, are displayed as expected Run the report to display data in the "SYSTEM.cw_vital_signs" table Validate there are no rows populated for the submission in step 4c, as one of the two required fields for alias table submission was not populated. Run the report to display data in the "SYSTEM.RADplus_error_log" Validate there is a row with a message stating "Table Alias Submission Failed Validation" displayed	Topics • Diagnosis • NX
Update 52 Summary \| Details Customization Pack - installation Scenario 1: Load & Verify Successful Customization Pack Installation Specific Setup: Customization pack [TestCustPack] is available for installation in the system Steps Internal Testing Only Namespace validation and correction process Scenario 1: Application Namespace Connection Validation process - (Internal) Validations Steps Internal Testing Only Scenario 2: Application Namespace Connection Validation Specific Setup: Have a system with one or more child namespaces. For example: "PM" or "CWS" namespaces Have a system that the following modules installed in the system: "Avatar Data Warehouse", " Avatar CWS State Forms" or "Avatar ProviderConnect NX 2023 " and any other desired modules Steps Open form "Applications Namespace Connection Validations" Validate "Currently Connected Namespaces" text box lists the expected child applications and namespace(s): Validate "Currently Connected Namespaces" text box indicates there are no application namespace connection or mapping errors. Click [Process] Validate the "Application Namespace Connections Validation" report list the expected connected child applications and namespace(s) Validate "Currently Connected Namespaces" text box indicates there are no application namespace connection or mappings errors. Netsmart Programmer Alerts Scenario 1: Validate (Internal) "Programmer Alert" functionality Steps Internal Testing Only	Topics • Update Install • Cache • NX • Database Management
Update 53 Summary \| Details All Documents Widget - Episode selection Scenario 1: Avatar NX "All Documents Widget" - Validate a users "Episode" access to documents Specific Setup: Have a system with two sub system codes: Sub code [Test1] is assigned to [Program1] Sub code [Test2] is assigned to [Program2] Have two users defined with the following permissions assigned in the user definition or assigned user role: [User1] has permission to sub code [Test1], but not to sub code [Test2] [User2] has permissions to both sub code [Test1] and [Test2] [User1] and [User2] have prompt "Limit Episodes to Current System Code in Chart View" set to "N", in the user definition or assigned user role [User1] and [User2] Client [TestClient] has been admitted in two episodes: in [Episode1] to [Program1] and in [Episode2] to [Program2] Client [TestClient] has a row of data filed in [TestForm] in both [Episode1] and [Episode2] Form [TestForm] has been added to the users chart view [User1] and [User2] have the "All Document Widget" on their home view Log into the [Test1] sub code as [User2] Steps Select client [TestClient] In the upper right-hand corner, click the "Episodes" field and choose "All Episodes" Navigate to the "All Documents Widget" Click on the tab containing [TestForm], for example the "All Forms" tab Click the "Form Description" filter and select [TestForm] Click "Episodes" filter Validate both [Episode1] and [Episode2] are displayed, as expected Select [Episode1] and click [Open] Validate data is displayed as expected Close the form Repeat the last step for [Episode2] Validate results are as expected Log out of sub code [Test1] as [User2] Log into sub code [Test2] as [User2] Repeat step 1 Validate results are the same, as [User2] has permissions to both sub system codes Log out of sub code [Test2] as [User2] Log into sub code [Test1] as [User1], who only has permissions to episodes in sub code [Test1] Select client [TestClient] In the upper right-hand corner, click the "Episodes" field and choose "All Episodes" Navigate to the "All Documents Widget" Click on the tab containing [TestForm], for example the "All Forms" tab Click the "Form Description" filter and select [TestForm] Click "Episodes" filter Validate only [Episode1] are displayed for selection, as expected Select [Episode1] and click [Open] Validate data is displayed as expected Close the form Log out of sub code [Test1] as [User1] Attempt to login into sub code [Test2] as [User1] Validate login is unsuccessful as expected as [User1] does not have permissions to log into sub code [Test2]	Topics • All Documents Widget • Episodes
Update 54 Summary \| Details State Form Definition - Form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form Definition State Form File Generation Scenario 1: State Form Definition - file "Definition Options" validations Specific Setup: Have a definition file created [TestDef], in form "State Form Definition" for any table on the system. For this test a definition is created using the "Admission" table, that will select and display "PATID" and "Episode" for each client admission on the system Steps Open form "State Form File Generation" Select definition file [TestDef] In the "File Generations Options" field, Click "Compile" Set prompt 'Generate Flag On Compile' to "Yes" Click [Process] Validate "Compile Complete" is displayed Click "Create File On Server" Click [Process] Validate a file is created and view the file Validate data as expected for each client admitted on the system, as expected In the "File Generations Options" field, Click "Compile" again Validate a message containing no records are found is displayed, since all records were previously flagged and no changes were made to any records since the last compile Open the 'Admission' form for any client [TestClient] Select an episode and change any of the data in the form and then submit the form Return to the "State Form File Generation" In the "File Generations Options" field, Click "Compile" Set prompt 'Generate Flag On Compile' to "Yes" Click [Process] Click "Create File On Server" Click [Process] Validate a file is created and view the file Validate data for just [TestClient] is present, as expected Open the 'State Form Definition' form Select definition file [TestDef] Select 'Single Submission Flagging' in the 'Definition Options' field File the definition Open the 'Admission' form for any client [TestClient] Select an episode and change any of the data in the form and then submit the form Return to the "State Form File Generation" In the "File Generations Options" field, Click "Compile" Set prompt 'Generate Flag On Compile' to "Yes" Click [Process] Click "Create File On Server" Click [Process] Validate no records are present even though the data was modified, since prompt "Single Submission Flagging" was selected in step 5 State Form Tools - Import/Export Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form Field Translation Scenario 1: State Form Field Translation Form - field entry and validation Specific Setup: Have a state form file created in form "State Form Definition" [FileA] Steps Open form "State Form Field Translation" Select the state form [FileA] from the "State Form" field drop-down list. In the "Record" field, select a record. In the "Table" field, select the desired table. In the "Table Property" field, select the desired table property. In the "Action field", select "Single Translation" In the "Dictionary Code" field, enter a dictionary code [Code1] In the "State Forms Dictionary Code" field, enter a desired state form dictionary code [StateCode1] Click [Submit] to record the changes. Click [Yes] to return to the form In the "Dictionary Code" field, enter another dictionary code [Code2] In the "State Forms Dictionary Code" field, enter another desired state form dictionary code [StateCode2] Click [Submit] to record the changes. Click [Yes] to return to the form In the "Dictionary Code" field, enter another dictionary code [Code3] In the "State Forms Dictionary Code" field, enter another desired state form dictionary code [StateCode3] Click [Submit] to record the changes. Click [No] not to return to the form Open form "State Form Field Translation" Click the [Print Translations] button Validate the "File Name Override Field Translations" report contains the three codes filed in the previous steps Repeat step 2, selecting the same values In the "Dictionary Code" field, enter dictionary code [Code1] entered in step 4 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode1] In the "Dictionary Code" field, enter dictionary code [Code2] entered in step 6 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode2] In the "Dictionary Code" field, enter dictionary code [Code3] entered in step 8 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode3] Navigate back to the "Action" field Select "Export Translations to CSV" Click the [Select CSV File] button Validate a file is location and save the file Navigate to location of the file and open it Validate all three translations entered in the previous steps, are present in the file as expected Closet the report Click the [Select Translations to Delete] button Validate all three translations are preset Click the check box for each item Click [OK] and [Yes] to continue Click [Submit] Click [Yes] to return to the form Repeat step 2, selecting the same values In the "Dictionary Code" field, enter dictionary code [Code1] entered in step 4 Validate the "State Forms Dictionary Code" field is blank, as expected In the "Dictionary Code" field, enter dictionary code [Code2] entered in step 6 Validate the "State Forms Dictionary Code" field is blank, as expected In the "Dictionary Code" field, enter dictionary code [Code3] entered in step 8 Validate the "State Forms Dictionary Code" field is blank, as expected Navigate back to the "Action" field Select "Import Translations to CSV" Click the [Select CSV File] button Navigate to the location of file exported in step 14 Select the file Validate a "Confirm" dialog is displayed, stating that 3 translations were processed and to submit the report to finalize the import Submit the form Return to the form Repeat step 2 In the "Dictionary Code" field, enter dictionary code [Code1] entered in step 4 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode1] In the "Dictionary Code" field, enter dictionary code [Code2] entered in step 6 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode2] In the "Dictionary Code" field, enter dictionary code [Code3] entered in step 8 Validate the "State Forms Dictionary Code" field, contains the expected value [StateCode3] State Form Query Logging- form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: State Form File Generation State Form Query Logging Scenario 1: 'State Form Query Logging' form - Functionality and validations Specific Setup: Have a system with two state form file definitions created in form "State Form Definition" [SFileA] and [SFileB] [SFileA] is a definition that contains one record [Rec] [SFileB] is a definition that contains two records [Rec] and [Rec2] Have a report to display data in the "RADplus_sf_audit_query" table, sorted by the "ID" field and displaying the fields "ID", "Query" and "Rec" Steps Open form "State Form File Generation" Select definition [SFileA] in the "State Form" field. (Make a note of the file "ID" number located next to the state form file name) Select "Compile" in the "File Generation Options" field Populate the "File Description" field Click [Process] At the "Compile Complete" dialog, click [OK] Open form "State Form Query Logging" Select definition [SFileA] in the "State Form" field Validate the "Record" filed is automatically populated with the record name [Rec]. (Make a note of the record name) Validate "Query" field is populated with the expected SQL query based on the table and selection criteria being executed in the record, [Make a note of the query displayed] Click the [Refesh] button Validate the query field refreshes as expected with with the expected SQL query based on the table and selection criteria being executed in the record, Close the form Run the report created to query table "RADplus_sf_audit_query" table In the "ID" column, locate the row that contains a value starting with the definition "ID" for [SFileA], noted in step 1a Validate the "Record" field value matches the value noted in step 2a Validate the "Query" field value matches the value noted in step 2a Close the report Open form "State Form File Generation" Select definition [SFileB] in the "State Form" field. (Make a note of the file "ID" number, located next to the state form file name) Select "Compile" in the "File Generation Options" field Populate the "File Description" field Click [Process] At the "Compile Complete" dialog, click [OK] Open form "State Form Query Logging" Select definition [SFileB] in the "State Form" field Click the "Record" field Validate there are two records for selection, as expected. [Rec] and [Rec2] Select [Rec] Validate the "Record" field is automatically populated with the record name [Rec]. (Make a note of the record name) Validate "Query" field is populated with the expected SQL query based on the table and selection criteria being executed in the record, [Make a note of the query displayed] Click the [Refesh] button Validate the query field refreshes as expected with with the expected SQL query based on the table and selection criteria being executed in the record, Navigate back to the "Record" field Select [Rec2] Validate the "Record" field is automatically populated with the record name [Rec]. (Make a note of the record name) Validate "Query" field is populated with the expected SQL query based on the table and selection criteria being executed in the record, [Make a note of the query displayed] Click the [Refesh] button Validate the query field refreshes as expected with with the expected SQL query based on the table and selection criteria being executed in the record Run the report created to query table "RADplus_sf_audit_query" table In the "ID" column, locate the row(s) that contains a value starting with the definition "ID" for [SFileB], noted in step 4a Validate a row is found for record name [Rec] Validate the "Query" field value for record [Rec] matches the value noted in step 5a Validate a row is also found for record name [Rec] Validate the "Query" field value for record [Rec2] matches the value noted in step 5a Close the report	Topics • State Forms • State Form Tools • NX
Update 55 Summary \| Details Dictionary Import - values Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Dictionary Import (PM) Scenario 1: Dictionary Import - Data import validations Specific Setup: Have a form [TestForm] that contains a "Dictionary" type field [TestDict] on the form Have access to form "Dictionary Update" Have two "Dictionary Import" files available to import values in field [TestDict] [FileA] is an import file created that contains dictionary codes for import, whose values all include an unsupported character: [Code1] includes a dictionary value containing a less than sign (<) [Code2] includes a dictionary value containing a caret symbol (^) [Code3] includes a dictionary value containing an equal sign (=) [Code4] includes a dictionary value containing a tilde symbol (~) [FileB] does "not" contain any dictionary codes for import, whose values include any of the unsupported characters [FileB] also contains a dictionary code that is flagged as "Inactive". (Note: an "X" needs to be placed in the "Inactive" column in the import file in order for the dictionary code being imported, to be considered "Inactive") Steps Open form "Dictionary Import" Click [Select File] Navigate the location of [FileA] and select it Click "Scan Import File" Validate the scan results indicate Error in row 1: Caret(s) found in dictionary value. Error in row 2: Equal sign(s) found in dictionary value. Error in row 3: Tilde(s) found in dictionary value. Error in row 4: Less than sign(s) found in dictionary value. Import file cannot be processed due to critical errors. Click [OK] Click [Select File] Navigate the location of [FileB] and select it Click "Scan Import File" Validate the scan results indicate "No errors or warnings found in file." Click "Begin Import" At the "Dictionary Import Complete" dialog, click [OK] Open [TestForm] Navigate to the [TestDict] field, and click on the field Validate all 'Active' dictionaries imported in [FileB] in step 1, are present in the selection list as expected Validate any 'Inactive' dictionaries imported are not displayed, as expected. Note: Inactive dictionary values are not displayed on forms Close the form Open form "Dictionary Update" Click the "Print Dictionary" section Select the file in "File" field where [TestDict] resides Select "Individual Data Element" Select [TestDict] in the "Data Element" field Click [Print Dictionary] Validate all 'Active' and 'Inactive' dictionaries imported in [FileB] in step 1, are present in the results	Topics • Dictionary
Update 56 Summary \| Details Report Definition and Site Specific Section Modeling Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Report Definition Export Report Definition (PM) Report Definition Import (PM) Site Specific Section Modeling Import/Export (CWS) Site Specific Section Modeling (CWS) Scenario 1: Report Definition "Export/Import" - "Version" number and "Audit" data validations Specific Setup: Have report [TestReport] form created using form "Report Definition" The logged in user has access to form "Report Definition", "Report Definition Import" and "Report Definition Export" Have a report or query to display data in tables 'SYSTEM.RADplus_Import_Audit' and 'SYSTEM.RADplus_Export_Audit' Steps Open form "Report Definition Export" Select [TestReport] Validate the "Report Version Number" field present and arranged on the form layout along with the other expected fields Validate the "Report Version Number" field is populated with the current version number. For this test "1.01" is used. Note the version number value Validate the field is disabled Click [Begin Export] Validate the report export file name automatically includes the report definition name and the "Version" number noted in step 1a. For example: "ReportExportReportTestReportV1_01.TXT" Save the file in a desired folder location. Note the current date and time Close the form Navigate to the location of the export file saved in step 1b Open the exported file in a text editor, confirm the file is encrypted. Run a report or query on the "SYSTEM.RADplus_export_audit" table, displaying field data Validate the "Version" number field is populated with same value of the version field noted in step 1a Validate "data_entry_user_name" field is the logged in user Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 1b Validate the "Report Name" field contains [TestReport] Open form "Report Definition" Select [TestReport] Validate the "Report Version Number" field reflects the value in step 1a Validate the field is disabled Make any change to a prompt or parameter on the form Set field "Is Report Eligible for Export * to "Yes" Validate the "Report Version Number" has incremented. For this test the version number is now "1.02". Note the version number. Note: "Version Number" will be increased by ".01" whenever the form is updated i Submit the form Validate the form files successfully Open form "Report Definition Export" Select [TestReport] Validate the "Report Version Number" field is populated with the current version number noted in step 2a Click [Begin Export] Validate the report export file name automatically includes the report definition name and the "Version" number noted in step 2a. For example: "ReportExportReportTestReportV1_02.TXT" Save the file in a desired folder location. Note the date and time Close the form Run a report or query on the "SYSTEM.RADplus_export_audit" table, displaying field data Validate the "Version" number is populated with same value of the version number field noted in step 3a. Validate "data_entry_user_name" field is the logged in user Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 3b Validate the "Report Name" field contains [TestReport] Open the form 'Report Definition Import' Click [Select Report Import File] Navigate to the location of the original file version exported in step 1b Validate the field "Report Version Number To Be Imported" is populated with expected version number. For this example "1.01" Select the "Overwrite Existing" radio button Click [Begin Import Scan] Validate the "Import Scan Results" box contains: "Critical Error: Report Name: Report [TestReport]. The import file report version (1.01) is prior to the current report version (1.02). The file contains one or more critical errors and therefore can not be imported. Note the version number of the import file Validate the [Begin Import] button is disabled Select the "Create New" radio button Click [Yes] when prompted with the dialog "This report already exists within this system. Are you sure that you would like to create a new report Click [Begin Import Scan] Validate the "Import Scan Results" box contains "There are no errors/warnings found within the import file." Click [Begin Import] Click [Yes] at "Are you sure that you want to 'Create New'?" import dialog Click [OK] at the "Import Complete" dialog. Note the date and time Close the form. [Please Note: An export file that has been exported with update "RADplus 2023 Update 56" installed, will not be able to imported in systems that do not have that update installed yet] Run a report or query on the "SYSTEM.RADplus_import_audit" table, displaying field data Validate the "Version" number is populated with same value version number noted in step 4a Validate "data_entry_user_name" field is the logged in user `Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 4a Validate the "Report Name" field contains [TestReport] Open form "Report Definition" Search for [TestReport] Validate the search display two results for [TestReport], the original version and new copy of the report imported in step 4. Note: the search results will include the form name of the report appended by the form ID# in parenthesis. Note that the newly imported copy in step 4, will have the higher form (ID#) number. For example: TestReport (3) TestReport (4) Select the first selection, the current updated report Validate the "Report Version Number" is populated with the current version of the report, for example "1.02" Validate the change made to the prompt or parameter on the form in step 2a, is displayed as expected Close the form Re-open form "Report Definition" Search for [TestReport] From the search results select the second selection, which is the imported copy containing the original version of the report Validate the "Report Version Number" is populated with the version number of the original version of the report, for this example "1.01" Validate the change made to the prompt or parameter in step 2a is not present, as expected Close the form Scenario 2: Site Specific Section Modeling "Export/Import" File - "Version" number and "Audit" data validations Specific Setup: Have a form [TestForm] that's available for site specific section modeling in form "Site Specific Section Modeling", for example form "Vitals Entry" The logged in user has access to form "Site Specific Section Modeling" and "Site Specific Section Modeling Import/Export" Have a report or query to display data in tables 'SYSTEM.RADplus_Import_Audit' and 'SYSTEM.RADplus_Export_Audit' Steps Open form "Site Specific Section Modeling Import/Export" In the "Select Form to Export" field, select [TestForm] Validate the "Version Number" field is populated with the current version number and the field is disabled. For this test "1" is used. Note the version number value Click on the "light bulb" icon to display the help message for the field. Validate the help message is updated to include the following verbiage: "The 'Site Specific Section Modeling Version' is increased by .01 whenever the form is updated in 'Site Specific Section Modeling'. When the 'Site Specific Section Modeling Import/Export' form is used for importing, then the 'Site Specific Section Modeling Version' value will be set to the value from the imported file." Click [Begin Export]. Note the current date and time Navigate to a desired file location to save the file Save the file name with a desired file name and append the version number noted in step 1a to the name. For example, "SSTabExportTestFormV1" Note the current date and time the file is saved Close the form Run a report or query on the "SYSTEM.RADplus_export_audit" table, displaying field data Validate the "Version" number field is populated with same value of the version field noted in step 1a Validate "data_entry_user_name" field is the logged in user Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 1b Validate the "option_desc" field contain [TestForm] Open form "Site Specific Section Modeling" Select [TestForm] Validate the "Version Number" field reflects the value in step 1a and the field is disabled Make any change to a prompt or parameter on the form Submit the form Validate the form files successfully Open form "Site Specific Section Modeling Import/Export" Select [TestForm] Validate the "Version Number" field has been incremented. For this example "1.01". Click [Begin Export]. Navigate to a desired file location to save the file Save the file name with a desired file name and append the new version number noted in step 3a to the name. For example, "SSTabExportTestFormV1.01" Note the current date and time the file is saved Close the form Run a report or query on the "SYSTEM.RADplus_export_audit" table, displaying field data Validate the "Version" number field is populated with same value of the version field noted in step 3a Validate "data_entry_user_name" field is the logged in user Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 3b Validate the "option_desc" field contain [TestForm] Open the form "Site Specific Section Modeling Import/Export" Click [Select Import File] Navigate to the location of the original file version exported in step 1b. For this test "SSTabExportTestFormV1" Validate the field "Version Number" is populated with expected version number. For this example "1". Click [Begin Import Scan] Validate the "Import Scan Results" box contains: " Warning: The Form Version Number In The System Is Higher Than The Form Version Number In The File" Click [OK] Click [Process Import File]. Note the current date and time of the import Close the form Run a report or query on the "SYSTEM.RADplus_import_audit" table, displaying field data Validate the "Version" number is populated with same value version number noted in step 4a Validate "data_entry_user_name" field is the logged in user `Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 4a Validate the "option_desc" field contain [TestForm] Open form "Site Specific Section Modeling" Select [TestForm] Validate the "Version Number" is populated with the original version exported in step 1. For this test "1" is noted. Validate the change made to the prompt or parameter on the form in step 2, is 'not' present as expected Close the form Open the form "Site Specific Section Modeling Import/Export" Click [Select Import File] Navigate to the location of the update file version exported in step 3. For this test "SSTabExportTestFormV1.01" Validate the field "Version Number" is populated with expected version number. For this example "1.01". Note the version number value. Click [Begin Import Scan] Validate the "Import Scan Results" box contains: "No errors or warnings found" Click [Process Import File] Click [OK] at the "Import Complete" dialog. Note the current date and time of the import Close the form Run a report or query on the "SYSTEM.RADplus_import_audit" table, displaying field data Validate the "Version" number is populated with same value version number noted in step 6a Validate "data_entry_user_name" field is the logged in user `Validate the "data_entry_date" and "data_entry_time" fields are consistent with the date and time noted in step 6a Validate the "option_desc" field contain [TestForm] Close the form Open form "Site Specific Section Modeling" Select [TestForm] Validate the "Version Number" is populated with the version number noted in step 6a Validate the change made to the prompt or parameter on the form in step 2, is present as expected Close the form	Topics • Report Definition Import • NX • 835 Health Care Claim Payment/Advice • 835 • Site Specific Section Modeling
Update 57 Summary \| Details Console Widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Scheduling Calendar Scenario 1: Scheduling Calendar - Delete Individual and Group Appointments Specific Setup: A client has an existing appointment scheduled (Client A). Steps Access the 'Scheduling Calendar' form. Validate the 'Appointment Grid' contains the appointments for "Client A" and "Group A". Right click on the appointment for "Client A" and click [Delete]. Validate a "Delete Appointment" dialog is displayed stating: Are you sure? Click [Yes]. Validate the 'Appointment Grid' no longer contains the appointment for "Client A". Click [Dismiss].	Topics • Console Widget • NX • Scheduling Calendar
Update 58 Summary \| Details My To Do's Widget- to do approval Scenario 1: 'My To Do's' Widget - Co-signing a To Do document sent to a Staff member('Final Approver') Specific Setup: A client [TestClient] must be enrolled in an existing episode. Document routing must be enabled for a form [TestForm]. [StaffA], [StaffB] and [StaffC] have permissions set in their user definition or user role as "Final Approver", with [TestForm] selected as one of the forms they can be final approver on [StaffC] also has "Co-Signer for Other Practitioners' set to "Yes" in their user definition or user role This allows a staff member to sign to do's for other staff members All three staff members have the 'My To Do's' widget on their home view Log in as [StaffA] Steps Access [TestForm] Select [TestClient] Populate any required and desired fields File the form as "Final" At the 'Confirm Document" screen Validate the document preview displays data as expected Click to accept and route the document [TestDoc] At the "Route Document To" screen Add [StaffB] as an approver Validate [StaffB] is added to the approver list Click the check box for "Final Approver" Click [Submit] Validate submission is successful Log out a [StaffA] Log in as [StaffC] Navigate to the "My To Do's" list Click the [Sign Tab] In the "Staff" search field, search for [StaffB]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do for [TestDoc] sent to [StaffB] in step 1 is present in the To Do list Select the To Do Validate the document preview displays data as expected Click [Accept] Validate the To do is removed from the To Do's widget, as expected Log out as [StaffC] Log in as [StaffB] Navigate to the "My To do's" list Validate the To Do for [TestDoc] sent to [StaffB] is not present in the To Do list, as expected Log out as [StaffB] Log in as [StaffA] Navigate to the "My To do's" list Validate there are no To Do's present, relating the To Do [TestDoc] sent to [StaffB] in step 1 Open form "Clinical Document Viewer" Select [TestClient] in the "Select Client" field Click [Process] Click the [Results] tab Locate the row for the [TestDoc] and select the document Click [View] Validate the "Document" preview pane displays data as expected for the document Navigate to the end of the document Validate the last signature indicates [UserC], as the "Co-Signer" signature. For example, "Electronically Signed By: [UserC] (Date and Time) - Co-Signer" Click [Close All Documents]	Topics • NX • "My To Do's" widget
Update 59 Summary \| Details Document Routing - comments Scenario 1: Validate "Doc Routing" workflow "Approval Comments" data in SQL table "DocR.Comments" Specific Setup: Have a system with both "PM" and "CWS" namespaces Have the following forms set up on the system [FormA] is "PM" form that is enabled for document routing and has prompt "Allow Comments During Approval" set to "Yes" in form "Document Routing Setup" Have a report or query set up that can used to display data in the SQL table "Doc.R.Comments" pointing to the "PM" namespace [ReportA] [FormB] is "CWS" form that is enabled for document routing and has prompt "Allow Comments During Approval" set to "Yes" in form "Document Routing Setup" Have a report or query set up that can used to display data in the SQL table "Doc.R.Comments" pointing to the "CWS" namespace [ReportB] [FormC] can be set up in either "PM" or "CWS". Is enabled for document routing and has prompt "Allow Comments During Approval" set to "Yes" in form "Document Routing Setup" Have a report or query [ReportC] set up that can used to display data in the SQL table "Doc.R.Comments" pointing to the namespace the [FormC] was created in [UserA] and [UserB] are staff members. In form "User Definition" [UserA] has permissions set to be a to be a "Co-signer" for other staff members Log in as [UserA] Steps Open [FormA] Select a client [TestClient] Populate the desired fields on the form File the form as "Final" At the "Route To" screen Add [UserB] as an approver Submit the form Validate submission is successful Repeat step 1 for forms for [FormB] Validate results are as expected Log out as [UserA] Log in as [UserB] Navigate to the "My To Do's" widget and locate the To Do sent in step 1 for [FormA] Click to [Review] At the "Document Preview" screen, validate the document contents are as expected Click [Accept] Click [Sign] At the "Approval Comments" dialog, enter the desired comments Click [OK] Validate submission is successful In the "My To Do's" widget, locate the To Do sent in step 2 for [FormB] Click to [Review] At the "Document Preview" screen, validate the document contents are as expected Click [Accept] Click [Sign] At the "Approval Comments" dialog, enter the desired comments Click [OK] Validate submission is successful Run [ReportA] to display data in the SQL table "Doc.R.Comments" in the "PM" namespace Validate a row is displayed for [TestClient] for the To Do approved in sent in step 1 Validate the "approved_user" field reflects [UserB] who approved the To Do in step 5 Validate the "Appoved_Comment" field reflects the comment entered in step 5 by [UserB] Run [ReportB] to display data in the SQL table "Doc.R.Comments" in the "CWS" namespace Validate a row is displayed for [TestClient] for the To Do approved in sent in step 2 Validate the "approved_user" field reflects [UserB] who approved the To Do in step 6 Validate the "Appoved_Comment" field reflects the comment entered in step 5 by [UserB] Log out as [UserB] Log in as [UserA] Open [FormC] Select a client [TestClient] Populate the desired fields on the form File the form as" Final" At the "Route To" screen Add [UserB] as an approver Submit the form Validate submission is successful Navigate the "My To Do's widget Click on the "Sign" tab In the "Staff" search field, search for [UserB]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do sent to [UserB] is found, select the To Do to review it Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment Click [OK] Click [Sign All] Validate the To Do is removed from the To Do list Then right a way, in the "Staff" search field, search for [UserA]. Locate the To Do for [FormC] Click [Review] Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment Click [OK] Validate the To Do is removed from the To Do list successfully Run [ReportC] to display data in the SQL table "Doc.R.Comments" Validate there are two rows displayed for [TestClient], for the To Do sent to [UserB] in step 11 For the first row, Validate the "approved_user" field reflects [UserA] who signed the To Do sent to [UserB] in step 11 Validate the "AppovedComment" field reflects the comment entered in step 12b by [UserA] For the second row Validate the "approved_user" field reflects [UserA] who approved the To Do that was sent to themselves in step 11 Validate the "AppovedComment" field reflects the comment entered in step 12b by [UserA] "DocR.comments" - To Do approvals Internal Test Only	Topics • Document Routing • My To Do's • Approval Comments
Update 60 Summary \| Details Support for the 'Alternate Lookup By Room' registry setting Scenario 1: Validate the 'Alternate Lookup By Room' registry setting Specific Setup: Two clients (Client A & Client B) must be admitted into inpatient episodes in the same room (Room A). The registry setting "Include Active Room Number with Client" is set to "1". Steps Access the 'Registry Settings' form. Enter "Alternate Lookup By Room" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains: Avatar PM->Client Information->Client Lookup->->->Alternate Lookup By Room. Validate the 'Registry Setting Detail' field contains: Selecting 'Y' will add an alternate search for clients by room number in the My Clients widget and Client Search. This must be an exact match and will look at the 'Include Active Room Number With Client Name' registry setting to potentially parse the room number. Select 'N' to disable this functionality. Enter "Y" in the 'Registry Setting Value' field. Click [Submit] and close the form. Search for "Room A" in the 'Search Clients' field. Validate both "Client A" and "Client B" are displayed. Access the 'Progress Notes (Group and Individual)' form. Enter "Room A" in the 'Select Client' field. Validate "Client A" and "Client B" are displayed. Close the form. Access the 'Client Ledger' form. Enter "Room A" in the 'Client ID' field. Validate "Client A" and "Client B" are displayed. Close the form. Access the 'Account Registration' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are displayed. Click [Cancel]. Access the 'Service Authorization' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are displayed. Click [Cancel]. Access the 'Registry Settings' form. Enter "Alternate Lookup By Room" in the 'Limit Registry Settings to the Following Search Criteria' field. Click [View Registry Settings]. Validate the 'Registry Setting' field contains: Avatar PM->Client Information->Client Lookup->->->Alternate Lookup By Room. Enter "N" in the 'Registry Setting Value' field. Click [Submit] and close the form. Search for "Room A" in the 'Search Clients' field. Validate "Client A" and "Client B" are not displayed. Access the 'Progress Notes (Group and Individual)' form. Enter "Room A" in the 'Select Client' field. Validate "Client A" and "Client B" are not displayed. Close the form. Access the 'Client Ledger' form. Enter "Room A" in the 'Client ID' field. Validate "Client A" and "Client B" are not displayed. Close the form. Access the 'Account Registration' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are not displayed. Click [Cancel]. Access the 'Service Authorization' form. Enter "Room A" in the 'Select Client' dialog. Validate "Client A" and "Client B" are not displayed. Click [Cancel]. Client Lookups Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Final to Draft Override (CWS) Practitioner Enrollment Scenario 1: Final to Draft Override - Form Validations Specific Setup: A modeled form is defined with the 'Draft/Final' prompt (Form A). A client is enrolled in an existing episode (Client A). A practitioner is defined with credentials on file (Practitioner A). "Client A" and "Practitioner A" must have the same ID numbers. Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit]. Access the 'Final to Draft Override' form. Select "Form A" in the 'Form' field. Select "Client A" in the 'Entity Lookup' field. Validate "Client A" does not display with practitioner credentials. Click [Select Row]. Select the finalized record filed in the previous steps and click [OK]. Validate the 'Row Contents' field contains the values entered in the previous steps. Enter the desired value in the 'Override Reason' field. Click [Submit]. Select "Client A" and access "Form A". Select the record filed in the previous steps and click [Edit]. Validate "Draft" is now selected in the 'Draft/Final' field. Close the form.	Topics • Registry Settings • Client Search • Final to Draft Override
Update 61 Summary \| Details Modeled forms - table aliasing Scenario 1: Modeled Forms - "Table Alias" field and data validations Specific Setup: Have two clients who are active in an existing episode's. [TestClientA], [TestClientB] and [TestClientC] Have a modeled form [TestAlias] that contains a table with: Mapped "Table" aliased fields. For example "Service" alias type fields: "Date of Service", "Service Code", "Practitioner", "Program", and "Duration". (Note: these fields all must be populated to file the table alias) Any other fields. For example, a "Draft/Final" or a "Date" field Have a report [ReportA] created to display data in the "SYSTEM.Billing_tx_history" table Have a report [ReportB] created to display data filed in the table used in form [TestAlias] Steps Open [AliasForm] Select [TestClientA] Populate all the required fields to file the table alias: "Date of Service", "Service Code", "Practitioner", "Program", and "Duration" Populate any other desired fields on the form Submit the form as "Final". Validate submission is successful Close the form Generate [ReportA] to display the fields in the "SYSTEM.billing_tx_history" table Validate a new row is found for the service created by the modeled form in step1a Validate the "Date of Service", "Service Code", "Practitioner, Program", "Duration" and "Join_To_Tx_history" fields are populated as expected Generate [ReportB] to display data in the table field in the modeled form Validate all fields populated in step1a, are populated as expected Open [AliasForm] Select [TestClientB] Populate just one or more but "not" all the required fields necessary, to file the table alias data Populate any other desired fields on the form Submit as the form as "Final" Validate there are no messages indicating required fields are missing and the form files successfully Generate [ReportA] to display the fields in the "SYSTEM.billing_tx_history" table Validate there is not a new row in the table for the row filed in step 2a as expected, since not all the required fields to file the table alias were not populated when submitting the form Generate [ReportB] to display data in the table field in the modeled form Validate all fields populated in step 2a, are populated as expected Open [AliasForm] Select [TestClientC] Populate none of the required fields necessary to file the table alias data Populate any other desired fields on the form Submit as the form as "Final" Validate there are no messages indicating required fields are missing and the form files successfully Generate [ReportA], to display the fields in the "SYSTEM.billing_tx_history" table Validate there is not a new row in the table for the row filed in step 3a as expected, since all the required fields to file the table alias were not populated when submitting the form Generate [ReportB] to display data in the table field in the modeled form Validate any fields populated in step 3a, are populated as expected	Topics • Diagnosis • NX
Update 62 Summary \| Details Service Documentation - New "Registry" settings Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form With Service Documentation Scenario 1: Service Documentation - Validate Registry Setting - "Default Staff Associated With Current Login User" Specific Setup: Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields [UserA] is a staff member [StaffA] [UserB] is not a staff member [TestClient] has an existing appointment [TestAppt] scheduled with staff member [StaffB] [TestClient] has an existing service [TestService] filed staff member [StaffC] Log in as [UserA] Steps Open form "Registry setting" Set setting "Default Staff Associated With Current Login User" to "Y." [Note: This will default the Service Documentation "Practitioner" field with the current user's staff member set in form "User Definition", if defined. Selecting 'N' will leave the Practitioner field blank] Open [TestForm] Select client [TestClient] Select "New Service" in the "Documentation For" selection field Navigate to the "Practitioner" field Validate the field has defaulted in [StaffA] who associated with user [UserA], as expected Navigate back to the "Documentation For" selection field Select "Existing Appointment" Select [TestAppt] from the drop down list Navigate back to the "Practitioner" field Validate the field is now populated with [StaffB] not [StaffA], since [StaffB] is who the appointment was scheduled with Navigate back to the "Documentation For" selection field Select "Existing Service" Select [TestService] from the drop down list Navigate back to the "Practitioner" field Validate the field is now populated with [StaffC] not [StaffA], since [StaffC] is who the service was filed with Close the form Log out a [UserA] Log in as [UserB], who is not a staff member Open [TestForm] Select client [TestClient] Select 'New Service" in the "Documentation For" selection field Navigate to the "Practitioner" field Validate the field is not populated as expected, as the logged in user is not associated with a staff member Navigate back to the "Documentation For" selection field Select "Existing Appointment" Select [TestAppt] from the drop down list Navigate back to the "Practitioner" field Validate the field is populated with [StaffB], as expected Navigate back to the "Documentation For" selection field Select "Existing Service" Select [TestService] from the drop down list Navigate back to the "Practitioner" field Validate the field is populated with [StaffC], as expected Open form "Registry setting" Set setting "Default Staff Associated With Current Login User" to "N". Open [TestForm] Select client [TestClient] Select "New Service" in the "Documentation For" selection field Navigate to the "Practitioner" field Validate the Practitioner field is blank, as expected based on the registry setting Navigate back to the "Documentation For" selection field Select "Existing Appointment" Select [TestAppt] from the drop down list Navigate back to the "Practitioner" field Validate the field is populated with [StaffB], as expected Navigate back to the "Documentation For" selection field Select "Existing Service" Select [TestService] from the drop down list Navigate back to the "Practitioner" field Validate the field is populated with [StaffC], as expected Log out a [TestUserB] Log in as [TestUserA] Repeat step 7 Validate results are the same, as expected Scenario 2: Service Documentation - Validate Registry Setting - "Allow Appointment Modifications" Specific Setup: Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields Have two appointments set for a client [TestClient] for today, one set earlier than the other. For this example: [ApptA] exists for staff [StaffA] from 7am to 8am today [ApptB] exists for staff [StaffB] from 8am to 9am today Have access to the "Registry Settings", "Scheduling Calendar" and form [TestForm] Steps Open form "Registry Settings" Search for and select setting "Allow Appointment Modifications" for edit. Note: Selecting 'Y' will enable the Service Code, Location, Duration, Start Time and End Time fields on Service Documentation-enabled modeled forms when editing an existing appointment. Changes to these values will be applied to the appointment when the data is filed as Final. Selecting 'N' will disable the service documentation fields." Set the registry setting value to "N" and submit the form Open form [TestForm] Select client [TestClient] In the "Documentation For" selection field Select "Existing Appointment" Select [ApptA] from the drop down list Validate fields "Service Charge Code", "Location", "Duration, "Start Time" and "End Time" are "Disabled" as expected, based on the registry setting. Close the form Open form "Registry Settings" Search for and select setting "Allow Appointment Modifications" for edit. Set the registry setting value to "Y" Submit the form Open form [TestForm] Select client [TestClient] In the "Documentation For" selection field, select "Existing Appointment" Select [ApptA] from the drop down list Validate fields "Service Charge Code", "Location", "Duration', "Start Time" and "End Time" are "Enabled" this time as expected, based on the registry setting. Change the appointment start and end times for [ApptA] to the same times as those of [ApptB] Set the "Draft/Final" field to "Final Validate there's a message displayed blocking the change, indicating the [TestClient] already has an appointment for the new start and end times inputted. Change the appointment start and end times for [ApptA] to a start and end time that does not conflict with another appointment Set the "Duration" field to the correct value based on the appointment start and end times entered Change the "Service Charge Code" field to a new value Validate the value is accepted Change the "Service Location" to a new value Validate the value is accepted Populate the other required fields and any other fields on the form Set the "Draft/Final" field to "Final Click [OK] at the "Selecting 'Final' prevents further edits dialog Click [Submit] Validate submission is successful Open form "Scheduling Calendar" Navigate to [ApptA] in the appointment grid Validate the start and end times of the appointment on the grid is match new values entered in step 1c Click to edit the appointment Validate the value "Service Start Time" field, is the new value entered in step 1c Validate the value "Service End Time" field, is the new value entered in step 1c Validate the value "Duration" field, is the new value entered in step 1d Validate the "Service Code" field, is the new value entered in step 1e Validate the "Location" field, is the new value entered in step 1f Validate all other fields are populated, as expected Close the form Scenario 3: Service Documentation - Validate Registry Setting - "Check Service Programs" Specific Setup: Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields In form "Program Maintenance" [ProgramA] has [ProgramB] selected as an associated service program in the field "Associated Service Programs" [ProgramA] does not have [ProgramC] selected as and associated service program in the field "Associated Service Programs" [TestClient] is admitted in [ProgramA] Have registry setting "Restrict Practitioner Search By Program" set to "Y" In form "Practitioner Enrollment", [StaffA] has [ProgramA] selected as a program their associated to in the "Program Association" field [StaffA] does not have [ProgramD] selected as a program their associated to in the "Program Association" field Logged in user has access to the "Registry Settings" and [TestForm] Steps Open form "Registry Settings" Search for and select setting "Check Service Program". Set the registry setting value to 'W' Note: a registry setting value set of 'W' or 'E' will enable checks on any "Service Documentation" enabled forms to ensure the "Service Program" value is a valid selection based on the practitioner's program associations and the current episodes program association. A registry setting value set of 'N', will disable these checks, and no error or warning will display to the user." Submit the form Open [TestForm] Select [TestClient] Select to create a "New Service" In the "Practitioner" field select [StaffA] Populate all the other required and desired fields other than the "Service Program" field In the "Service Program" field select [ProgramB] Validate the value is accepted and there are no messages In the "Service Program" field select [ProgramC] Validate a warning message indicating the following is displayed, "WARNING: Service program not valid for the given episodes program. Do you wish to continue do you want to continue? Click [No] Click [OK] in the "Action Cancelled" dialog Validate the Service Program" field is cleared In the "Service Program" field select [ProgramC] again This time at the "Warning" message, click [Yes] to continue Validate the Service Program" field is still populated with [ProgramC] In the "Service Program" field select [ProgramD] Validate a message is displayed, "WARNING: Service program not associated with the selected practitioner. Do you wish to continue? Click [No] Click [OK] in the "Action Cancelled" dialog Validate the Service Program" field is returned to its previous value [ProgramC] In the "Service Program" field select [ProgramD] again This time at the "Warning" message, click [Yes] to continue Validate the Service Program" field is still populated with [ProgramD] Select a "Final" in the "Draft/Final" field Validate a warning message indicating the following is displayed again as a final check, "WARNING: Service program not associated with the selected practitioner. Do you wish to continue finalizing? Click [Yes] At the "Selecting "Final" prevents future edits\" dialog Click [OK] Click [Submit] Validate the form files successfully Open form "Registry Settings", search for and select setting "Check Service Program". Set the registry setting value to 'E' and submit the form Open [TestForm] Select [TestClient] Select to create a "New Service" In the "Practitioner" field select [StaffA] Populate all the other required and desired fields other than the "Service Program" field In the "Service Program" field select [ProgramB] Validate the value is accepted and there are no messages In the "Service Program" field select [ProgramC] Validate an "Error" message is displayed stating, "Service program not valid for the given episodes program" Click [OK] Validate the Service Program" field is cleared In the "Service Program" field select [ProgramD] Validate there is an "Error" message stating "Service program not associated with the selected practitioner" Click [OK] Validate the Service Program" field is cleared In the "Service Program" field select [ProgramA] Validate there are no messages blocking entry Validate the Service Program" field is populated with [ProgramA], as expected Select a "Final" in the "Draft/Final" field Validate there are no messages blocking entry At the "Selecting "Final" prevents future edits." dialog Click [OK] Click [Submit] Validate the form files successfully Open form "Registry Settings" Search for and select setting "Check Service Program". Set the registry setting value to any value other than 'W', 'E', or 'N' Validate an error is displayed "The selected value is not valid in the current system code for the following reason: Please enter 'N', 'W' or 'E' Set the registry setting value to 'N' Submit the form Open [TestForm] Select [TestClient] Select to create a "New Service" In the "Practitioner" field select [StaffA] Populate all the other required and desired fields other than the "Service Program" field In the "Service Program" field select [ProgramB] Validate the value is accepted and there are no messages Validate the Service Program" field is populated with [ProgramB], as expected In the "Service Program" field select [ProgramC] Validate the value is accepted and there are no messages Validate the Service Program" field is populated with [ProgramC], as expected In the "Service Program" field select [ProgramD] Validate the value is accepted and there are no messages Validate the Service Program" field is populated with [ProgramD], as expected In the "Service Program" field select [ProgramA] Validate the value is accepted and there are no messages Validate the "Service Program" field is populated with [ProgramD], as expected Select a "Final" in the "Draft/Final" field Validate there are no messages blocking entry At the "Selecting "Final" prevents future edits." dialog Click [OK] Click [Submit] Validate the form files successfully	Topics • Service Documentation • NX
Update 63 Summary \| Details GA ASO - Entity dictionaries Scenario 1: Validate the "SYSTEM.RADplus_dict_user_def_gaaso table Specific Setup: Have a modeled envelope [TestEnvelope] set to use "GA ASO" entity database Have a modeled table[TestTable] created in [TestEnvelope] that contains the following dictionary fields. For this test the following will be used: A 'Single-select" dictionary: Field number '1.01", with field description of "Dictionary 1". Has the following dictionary code/values added: Dictionary Code "1" with a dictionary value of "Single 1" Dictionary Code "2" with a dictionary value of "Single 2' A 'Multiple-select" dictionary: Field number '1.02", with a field description of "Dictionary 2" Has the following dictionary code/values added: Dictionary Code "5" with a dictionary value of "Mult 1" Dictionary Code "6" with a dictionary value of "Mult 2" Have a report or query created for table 'RADplus_dict_user_def_gaaso', to display dictionary codes, values and descriptions Steps Generate the report or query created for table 'RADplus_dict_user_def_gaaso', to display field values Based on the set up, validate the report results display rows with the expected data populated in each column. For example, in this test following results would be expected: Field Number: "1.01" ; Field Description: "Dictionary 1" ;Dictionary Code: "1 ; Dictionary Value : "Single 1" Field Number: "1.01" ; Field Description: "Dictionary 1" ;Dictionary Code: "2" ; Dictionary Value : "Single 2" Field Number: "1.02" ; Field Description: "Dictionary 2" ;Dictionary Code: "5" ; Dictionary Value : "Mult 1" Field Number: "1.02" ; Field Description: "Dictionary 2" ;Dictionary Code: "6" ; Dictionary Value : "Mult 2" State Form - Modeling table Scenario 1: Validate table 'SYSTEM.RADplus_dict_user_def_stateform' Specific Setup: Have a modeled envelope [TestEnvelope] set to use "Stateform" entity database Have a modeled table[TestTable] created in [TestEnvelope] that contains the following dictionary fields. For this test the following will be used: A 'Single-select" dictionary: Field number '1.02", with field description of "Single Dictionary". Has the following dictionary code/values added: Dictionary Code "1" with a value of "One" Dictionary Code "2" with a value of "Two" Dictionary Code "3" with a value of "Three" A 'Multiple-select" dictionary: Field number "1.03", with a field description of "Multiple Dictionary" Has the following dictionary code/values added: Dictionary Code "1" with a value of "One" Dictionary Code "2" with a value of "Two" Dictionary Code "3" with a value of "Three" Have a report or query created for table 'SYSTEM.RADplus_dict_user_def_stateform', to dicitonary codes, values and descriptions Steps Generate the report or query created for table 'SYSTEM.RADplus_dict_user_def_stateform' to display field values Based on the set up, validate the report results display rows with the expected data populated in each column. For example, in this test following results would be expected: Field Number: "1.02" ; Field Description: "Single Dictionary"; Dictionary Code: "1" ; Dictionary Value : "One" Field Number: "1.02" ; Field Description: "Single Dictionary"; Dictionary Code: "2" ; Dictionary Value : "Two" Field Number: "1.02" ; Field Description : "Single Dictionary"; Dictionary Code: "3"; Dictionary Value : "Three" Field Number: "1.03"; Field Description : "Multiple Dictionary" ;Dictionary Code: "1" ; Dictionary Value : "One" Field Number: "1.03"; Field Description : "Multiple Dictionary" ;Dictionary Code: "2" ; Dictionary Value : "Two Field Number: "1.03"; Field Description : "Multiple Dictionary" ;Dictionary Code: "3" ; Dictionary Value : "Three	Topics • SQL Data Access • NX • State Form Tools
Update 64 Summary \| Details Envelope Import - support for Multiple Envelope Export Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Deletion (PM) Table Deletion (PM) Envelope Deletion (PM) Form Deletion (CWS) Table Deletion (CWS) Envelope Deletion (CWS) Modeled Form Doc Routing Envelope Export (PM) Multiple Envelope Export Envelope Import (MSO) Envelope Definition (MSO) Scenario 1: "Envelope Import" - Validate importing envelope(s) containing modeled form(s) in parent and child namespaces Specific Setup: Have an envelope "Envelope A", exported from the parent namespace. For example, the "PM" Namespace. Have an envelope "Envelope B", exported from a child namespace. For example, the "CWS" namespace. Have another envelope "Envelope C", exported from any namespace that contains a modeled form that is enabled for document routing. Have an envelope "Envelope D", exported from a child namespace. For example, the "MSO" namespace. Steps Open the "Envelope Import" form from the PM menu. Import "Envelope A" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the CWS menu. Import "Envelope B" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the CWS menu. Import "Envelope C" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the MSO menu. Import "Envelope D" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Scenario 2: Envelope Export - validations Specific Setup: Have an existing Modeled form [FormA] that exists in [EnvelopeA]. Steps Open form "Envelope Definition". Select [EnvelopeA]. Note the value in the "Envelope Version Number" field, for example "1.01". Close the form. Open form "Envelope Export". Select [EnvelopeA]. Click [Begin Export]. In the "File Explorer" dialog, select a folder location in the "Save In" field to save the export file. In the "File_Name" field, validate that the file name populated includes the name of [ReportA], appended by a "V" followed by the "Report Version Number" value noted in step 1 and the file extension. For example, "NetsmartExportModeledFormV1_01.TXT". Click [Save]. Close the form. Open file "Envelope Import". Click [Select Envelope Import File] In the "File Explorer" dialog, navigate to the location of the export file. Select the file and click [Open]. Select the "Overwrite Existing" radio button. Click [Begin Import Scan]. Click [Begin Import]. At the "Import Complete" dialog, click [OK]. Close the form. At the Home View, search for [FormA] and open the form. Populate the desired fields on the form. Submit the form. Validate the form files successfully. Scenario 3: Multiple Envelope Export - Form Validation Specific Setup: Using the "User Definition" form: Give the user access to the "Multiple Envelope Export" form. This form is available under the "Modeling" menu in the parent and child namespaces. File the form. Must have envelopes available for export. Steps Open the "Multiple Envelope Export" in the parent or child namespace. Select several envelopes to export. Open the "Envelope Import" in the parent or child namespace selected above. Import the envelope creating a new envelope if it doesn't exist already or overwriting an existing envelope. Open the "Envelope Definition" form in the parent or child namespace selected above. Validate the envelope imported. Multiple Envelope Export - Functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Deletion (PM) Table Deletion (PM) Envelope Deletion (PM) Form Deletion (CWS) Table Deletion (CWS) Envelope Deletion (CWS) Modeled Form Doc Routing Envelope Export (PM) Multiple Envelope Export Envelope Import (MSO) Envelope Definition (MSO) Scenario 1: "Envelope Import" - Validate importing envelope(s) containing modeled form(s) in parent and child namespaces Specific Setup: Have an envelope "Envelope A", exported from the parent namespace. For example, the "PM" Namespace. Have an envelope "Envelope B", exported from a child namespace. For example, the "CWS" namespace. Have another envelope "Envelope C", exported from any namespace that contains a modeled form that is enabled for document routing. Have an envelope "Envelope D", exported from a child namespace. For example, the "MSO" namespace. Steps Open the "Envelope Import" form from the PM menu. Import "Envelope A" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the CWS menu. Import "Envelope B" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the CWS menu. Import "Envelope C" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Open the "Envelope Import" form from the MSO menu. Import "Envelope D" from setup. Create a new envelope. Click "Yes" in "Load Un-Locked Dictionary Entries" and "Load Locked Dictionary Entries". Import file. Refresh Menus. Open the form associated with the import. File the form. Validate it files successfully. Scenario 2: Envelope Export - validations Specific Setup: Have an existing Modeled form [FormA] that exists in [EnvelopeA]. Steps Open form "Envelope Definition". Select [EnvelopeA]. Note the value in the "Envelope Version Number" field, for example "1.01". Close the form. Open form "Envelope Export". Select [EnvelopeA]. Click [Begin Export]. In the "File Explorer" dialog, select a folder location in the "Save In" field to save the export file. In the "File_Name" field, validate that the file name populated includes the name of [ReportA], appended by a "V" followed by the "Report Version Number" value noted in step 1 and the file extension. For example, "NetsmartExportModeledFormV1_01.TXT". Click [Save]. Close the form. Open file "Envelope Import". Click [Select Envelope Import File] In the "File Explorer" dialog, navigate to the location of the export file. Select the file and click [Open]. Select the "Overwrite Existing" radio button. Click [Begin Import Scan]. Click [Begin Import]. At the "Import Complete" dialog, click [OK]. Close the form. At the Home View, search for [FormA] and open the form. Populate the desired fields on the form. Submit the form. Validate the form files successfully. Scenario 3: Multiple Envelope Export - Form Validation Specific Setup: Using the "User Definition" form: Give the user access to the "Multiple Envelope Export" form. This form is available under the "Modeling" menu in the parent and child namespaces. File the form. Must have envelopes available for export. Steps Open the "Multiple Envelope Export" in the parent or child namespace. Select several envelopes to export. Open the "Envelope Import" in the parent or child namespace selected above. Import the envelope creating a new envelope if it doesn't exist already or overwriting an existing envelope. Open the "Envelope Definition" form in the parent or child namespace selected above. Validate the envelope imported. Envelope Export - exporting aliased dictionaries Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Definition (MSO) Table Definition (MSO) Form Definition (MSO) Envelope Export (MSO) Envelope Import (MSO) Scenario 1: Table Definition - Export a single response dictionary item that maps to a different entity Specific Setup: Using "Envelope Definition": Create a new envelope form in the child or parent namespace. Allow the envelope to be exportable. Using "Table Definition" form: Navigate to the "Column Definition" section. Add desired fields. Add a Single Response Dictionary field that is mapped to another database. Using "Form Definition" form: Create a new form utilizing all the fields created under the "Table Definition". Steps Open "Envelope Export". Export the envelope you created in setup. Log into another test system. Open "Envelope Import". Import the envelope you just exported. Open "Envelope Definition". Validate the envelope you just imported exists. Open the form that was imported. Populate with data. File the form.	Topics • Modeling • Envelope Import • NX • Envelope Definition • Envelope Export
Update 65 Summary \| Details Document Management Definition - Syncing multiple root system environments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Document Capture Document Capture Scenario 1: Validate form "Document Management Definition" Steps Open "Document Management Definition" form. Click [Select Form]. Click [Add New]. Populate the "Form Name" field. Select the desired form type in the "Form Type" field. Select the desired entity in the "Entity" field. Populate any other desired fields in the "Form" section. Click the [Categories] section. Click [Select Categories]. Select the desired category from the selection list. Click [OK]. Click the [Display] section. Select the desired selections form the "Forms to Display" box. Click the [Reports] section. Click any to launch any desired report, for example the "Display Form Report". Validate the "Document Management Form Report" is displayed. Close the report. Click back to the [Form] section. Click [File]. Validate the form files successfully. Click [Select Form]. Select the form just submitted in step 5. Validate all fields populated in steps 1 thru 5, are populated as expected. Click back to the [Form] section. Click [Delete]. Click [Yes] to accept the deletion. Click [Select Form]. Validate the form that was deleted in step 7, is no longer present in the list. Click [Select Form]. Select the form "Inbox Attachments". Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Click [Select Form]. Select the form "Results Document". Click [Delete]. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Close the form. Scenario 2: Document Management Defaults - Perceptive Synchronization Options field Steps Internal Testing Only Scenario 3: Document Management Definition - Perceptive Syncing Form Definitions in Multiple Server environment Specific Setup: To be tested in a multiple server environment that has multiple root system codes. Using the "Document Management Definition" form: Identify a form that exists in all system codes. Steps Using the "Document Management Definition" form: Edit the existing form identified as existing in all root system codes. File the form. Open the "Client Document Capture" form. Scan or import a document. Select the form edited in "Document Management Definition". Scan or import the document. Using "Clinical Document Viewer", select the test client. Validate the document that was just filed for the form that exists in all root system codes displays as it was previously filed. Scenario 4: Clinical Document Viewer - Filters, Selections and Restrictions Specific Setup: Select an existing client who has multiple documents on file that have been scanned, imported or routed via document routing, scanned. Steps Open the "Clinical Document Viewer" form. Validate the filters such as "Select All or Individual", "User", "Document Status", "Program", "Episode", "Document Source", "Document Origination Date Start", "Document Origination Date End" all filter in the appropriate manner. Under Form Selection, validate that you can choose the form selection by "Categories/Forms" and only those documents appear in the document list. Using the "Document Management Definition" form, identify a form as to "Exclude from Electronic Medical Record". Validate the document list doesn't include documents that are to be excluded. Using the "Document Management Definition" form, identify a form as "Do Not Print". Going back to the "Clinical Document Viewer" form, validate the forms marked as "Do Not Print" are excluded, Using "Document Management Definition" form, mark a document type as "Do not release". Going back to the "Clinical Document Viewer" form, validate the forms marked as "Do Not Release" are excluded. Document Management Definition - Syncing multiple root system environments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Document Capture Document Capture Scenario 1: Validate form "Document Management Definition" Steps Open "Document Management Definition" form. Click [Select Form]. Click [Add New]. Populate the "Form Name" field. Select the desired form type in the "Form Type" field. Select the desired entity in the "Entity" field. Populate any other desired fields in the "Form" section. Click the [Categories] section. Click [Select Categories]. Select the desired category from the selection list. Click [OK]. Click the [Display] section. Select the desired selections form the "Forms to Display" box. Click the [Reports] section. Click any to launch any desired report, for example the "Display Form Report". Validate the "Document Management Form Report" is displayed. Close the report. Click back to the [Form] section. Click [File]. Validate the form files successfully. Click [Select Form]. Select the form just submitted in step 5. Validate all fields populated in steps 1 thru 5, are populated as expected. Click back to the [Form] section. Click [Delete]. Click [Yes] to accept the deletion. Click [Select Form]. Validate the form that was deleted in step 7, is no longer present in the list. Click [Select Form]. Select the form "Inbox Attachments". Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Click [Select Form]. Select the form "Results Document". Click [Delete]. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Close the form. Scenario 2: Document Management Definition - Perceptive Syncing Form Definitions in Multiple Server environment Specific Setup: To be tested in a multiple server environment that has multiple root system codes. Using the "Document Management Definition" form: Identify a form that exists in all system codes. Steps Using the "Document Management Definition" form: Edit the existing form identified as existing in all root system codes. File the form. Open the "Client Document Capture" form. Scan or import a document. Select the form edited in "Document Management Definition". Scan or import the document. Using "Clinical Document Viewer", select the test client. Validate the document that was just filed for the form that exists in all root system codes displays as it was previously filed. Document Management Definition - Syncing multiple root system environments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Document Capture Document Capture Scenario 1: Validate form "Document Management Definition" Steps Open "Document Management Definition" form. Click [Select Form]. Click [Add New]. Populate the "Form Name" field. Select the desired form type in the "Form Type" field. Select the desired entity in the "Entity" field. Populate any other desired fields in the "Form" section. Click the [Categories] section. Click [Select Categories]. Select the desired category from the selection list. Click [OK]. Click the [Display] section. Select the desired selections form the "Forms to Display" box. Click the [Reports] section. Click any to launch any desired report, for example the "Display Form Report". Validate the "Document Management Form Report" is displayed. Close the report. Click back to the [Form] section. Click [File]. Validate the form files successfully. Click [Select Form]. Select the form just submitted in step 5. Validate all fields populated in steps 1 thru 5, are populated as expected. Click back to the [Form] section. Click [Delete]. Click [Yes] to accept the deletion. Click [Select Form]. Validate the form that was deleted in step 7, is no longer present in the list. Click [Select Form]. Select the form "Inbox Attachments". Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Click [Select Form]. Select the form "Results Document". Click [Delete]. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Close the form. Scenario 2: Document Management Defaults - Perceptive Synchronization Options field Steps Internal Testing Only Scenario 3: Document Management Definition - Perceptive Syncing Form Definitions in Multiple Server environment Specific Setup: To be tested in a multiple server environment that has multiple root system codes. Using the "Document Management Definition" form: Identify a form that exists in all system codes. Steps Using the "Document Management Definition" form: Edit the existing form identified as existing in all root system codes. File the form. Open the "Client Document Capture" form. Scan or import a document. Select the form edited in "Document Management Definition". Scan or import the document. Using "Clinical Document Viewer", select the test client. Validate the document that was just filed for the form that exists in all root system codes displays as it was previously filed.	Topics • Document Management • NX • Document Routing
Update 66 Summary \| Details Client Picture - Table Scenario 1: Validate data in the "SYSTEM.RADplus_client_picture" table Specific Setup: Have a report or query [TestReport]" created to display data in the ""SYSTEM.RADplus_client_picture"' table Have client [ClientA] who does not have a picture image uploaded yet in the system Have an image [TestImageA] on the system available for import for [ClientA] Have client [ClientB] who already has a picture image uploaded [TestImageB] Have an image [TestImageC] on the system available for import to replace the current image for [ClientB] [TestUser] has access to form "Import Client Picture" Log in as [TestUser] Steps Access the 'Import Client Picture' form. Select [ClientA] in the 'Client' field. Right click in the 'Picture' field. Click [Acquire Image]. Navigate to [TestImageA] and select the image Validate the image in the 'Picture' field is displayed as expected Submit the form. [Note the current date and time] Validate the form files successfully Access [TestReport] and generate the report or query Locate the row just submitted for [ClientA] Validate the "PATID" field value for [ClientA], is populated as expected Validate the 'data_entry_date" field value reflects the date noted in step 1 Validate the 'data_entry_time" field value reflects the time noted in step 1 If "UTC" time is enabled on the system: Validate the 'data_entry_utc" field value reflects the date and time noted in step 1 but in "UTC" time and date format. (For example, if the time zone is "Eastern" and the date and time in step 1 was "6/22/23" at "1:52 PM", the value would be display as "6/22/2023 5:52:16PM") Validate the "data_entry_timezone_info_all" field value is displayed as expected, based on the time zone. (For example, if the time zone is "Eastern", the value displayed would be "EDT;Eastern Daylight Time;-0400") Validate the 'data_entry_by_login' field value is [TestUser] Validate the "picture" field is populated with [TestImageA], as expected Access the 'Import Client Picture' form. Select [ClientB] in the 'Client' field. Validate [TestImageB], is displayed as expected Right click on the image in the 'Picture' field. Click [Acquire Image]. Navigate to [TestImageC] and select the image Validate that image is now displayed as expected Submit the form. [Note the current date and time] Validate the form files successfully Access [TestReport] and generate the report or query Locate the row just submitted for [ClientB] Validate the "PATID" column for [ClienB], is populated as expected Validate the 'data_entry_date" field value reflects the date noted in step 3 Validate the 'data_entry_time" field value reflects the time noted in step 3 When "UTC" time is enabled on the system: Validate the 'data_entry_utc" field value reflects the date and time noted in step 3 in "UTC" time format Validate the "data_entry_timezone_info_all" field values displayed as expected based on the time zone. Validate the 'data_entry_by_login' field value is [TestUser] Validate the "picture" field is populated with [TestImageC], as expected	Topics • SQL Data Access • NX
Update 67 Summary \| Details All Documents Widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Console Widget Viewer Scenario 1: All Documents Widget - column data validations Specific Setup: [TestFormA] is a form that contains an apostrophe within the forms name [TestFormB] is a form that does not contain an apostrophe within the forms name Have a 'Program" [ProgramA] defined that has an apostrophe in the program description name Have a 'Program" [ProgramB] defined that does not have an apostrophe in the program description name [TestClient] is admitted in [ProgramA] in [Ep1] A row of data for has been submitted in [Ep1] for form [TestFormA] A row of data for has been submitted in [Ep2] for form [TestFormB] [TestClient] is admitted in [ProgramB] in [Ep2] A row of data for has been submitted in [Ep1] for form [TestFormA] A row of data for has been submitted in [Ep2] for form [TestFormB] Have the "All Documents Widget" configured with a "Tab" [TestTab] defined in the widget, that contains [TestFormA] and [TestformB] The logged in user has the "All Document Widget" widget on their home view and has permissions to both test forms Steps At the home view, select [TestClientA] Navigate to the "All Document Widget" Navigate to the "All Document Widget" and select tab [TestTab] in the widget From the "Form Description' column drop down list, select [TestFormA], the form that includes an apostrophe in its form name From the "Episode" column drop down list, select the "All" check box For [TestFormA], validate the row filed in [Ep1] [ProgramA] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected For [TestFormA], validate the row filed in [Ep2] [ProgramB] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected From the "Episode" column drop down list, select just [Ep1] For [TestFormA], validate only the row filed in [Ep1] [ProgramA] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected From the "Episode" column drop down list, select just [Ep2] For [TestFormA], validate only the row filed in [Ep2] [ProgramB] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected From the "Form Description' column drop down list, select [TestFormB], the form that does 'not' include an apostrophe in its form name For [TestFormB], validate the row filed in [Ep1] [ProgramA] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", Data Entry By" and "Workflow Status" columns, are populated as expected For [TestFormB], validate the row filed in [Ep2] [ProgramB] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected From the "Episode" column drop down list, select just [Ep1] For [TestFormB], validate only the row filed in [Ep1] [ProgramA] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected From the "Episode" column drop down list, select just [Ep2] For [TestFormB], validate only the row filed in [Ep2] [ProgramB] is displayed Validate the data results displayed in the "Form Description", "Episode(Program Name)", "Date", "Time", "Data Entry By" and "Workflow Status" columns, are populated as expected	Topics • Widgets • NX
Update 69 Summary \| Details Multi-row SQL Widgets - Event log entries Scenario 1: SQL Widget ('Multiple Row SQL' Type) - Validate entries in the "SYSTEM.radplus_event_log" table Specific Setup: Have a report or query to display data in the "SYSTEM.RADplus_event_log" table [TestReport] In form "Widget Definition" have a "Multiple Row SQL" type widget created [MultWidget] based on a table. For this test the "cw_hist_client_allergies" filed in form "Client Allergies and Hypersensitivities", is used Have a client [ClientA] with just one allergy filed in form "Client Allergies and Hypersensitivities" Have another client [ClientB] with two more allergies filed in form "Client Allergies and Hypersensitivities" Have [MultWidget] placed on a user's home view or additional console view Steps At the home view, select [ClientA], the client with just one entry filed in the table Navigate to location of widget [MultWidget] Click the "Refresh" button in the widget (Note the current date and time) Validate results are displayed as expected. For this test, just one row is displayed as expected for the "Allergies" on file for [ClientA] Run the [TestReport], created to display data in the "SYSTEM.RADplus_event_log" table Validate there are only two event log rows displayed for the transaction to step 1a: One entry row is displayed for accessing [ClientA] Validate the 'event_date' and 'event-time' are consistent with the date time noted in step 1a Second row entry is for refreshing the widget with the loaded data for [ClientA] Validate the 'event_date' and 'event-time' are consistent with the date time noted in step 1a Click to refresh the widget again Repeat steps 1a and 1b Validate results are as expected At the home view, select [ClientB], the client with multiple entries filed in the table Navigate to location of widget [MultWidget] Click the "Refresh" button in the widget (Note the current date and time) Validate results are displayed as expected. For this test, just one row is displayed as expected for the "Allergies" on file for [ClientB] Run the [TestReport], created to display data in the "SYSTEM.RADplus_event_log" table Validate there are still only two event log rows displayed for the transaction to step 2a, as expected. (Note: only two event log entries are expected, even when multiple entire are displayed in the widget) One entry row is displayed for accessing [ClientB] Validate the 'event_date' and 'event-time' are consistent with the date time noted in step 2a Second row entry is for refreshing the widget with the loaded data for [ClientB] Validate the 'event_date' and 'event-time' are consistent with the date time noted in step 2a Click to refresh the widget again Repeat steps 2a and 2b Validate results are as expected	Topics • Admission • Audit Log
Update 70 Summary \| Details Envelope Import - UTC data entry fields Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Scenario 1: Validate Envelope "Export/Import" in "UTC" Date/Time enabled systems Specific Setup: Have a system enabled to use "UTC" date and time. Please note: this must be done by a Netsmart Representative. [EnvelopeA] contains modeled form [FormA], which contains one or more of the available "UTC" related date/time fields as one of the fields in the forms "Pre-display". For example: "Data Entry Calculated Timezone", "Data Entry Offset", "Data Entry UTC Timestamp" or "Data Entry Workstation Timezone". [EnvelopeB] contains modeled form [FormB] which does not contain any of the available "UTC" related date/time fields as one of the fields in the forms "Pre-display". Steps Open form "Envelope Export" Select [EnvelopeA] Click [Begin Export] In the "File Explorer" dialog, select a folder location in the "Save In" field to save the export file. Click [Save] Close the form Open file "Envelope Import" Click [Select Envelope Import File] In the "File Explorer" dialog, navigate to the location of the [EnvelopeA] export file Select the file and click [Open] Select the "Overwrite Existing" radio button Click [Begin Import Scan] Click [Begin Import] At the "Import Complete" dialog, click [OK] Close the form At the Home View, search for [FormA] and open the form Populate the desired fields on the form Submit the form Validate the form files successfully Re-open [FormA] Select the row just submitted in step 3 At the "Pre-Display" screen, validate the values for all pre-display fields selected in the setup, are displayed as expected Click to edit the row Validate al fields are populated as expected Repeat steps 1 thru 4 for [EnvelopeB] Validate results are as expected	Topics • Envelope Import • NX • Envelope Export
Update 71 Summary \| Details User Definition - User External Login Scenario 1: User Definition (Field Validation) - Enable/Disable a "Netsmart Identity and Access Management(NIAM)" User Specific Setup: Have registry setting "Enable OpenID Connect Support" enabled in the system by Netsmart 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 [NIAMuser] has been assigned an external login ID and password by "(ODIC) Identity Provider" to enable login as a "NIAM" user, once they are configured in "myAvatar" The logged in user has permissions to add and edit users in form "User Definition" Steps Open form "User Definition" Enter a new user ID or existing user [NIAMuser] in "User ID" field, that will be enabled as a "NIAM" user Click the "Yes" in the "Use External Login" field Set the "External Login ID' field to the external login name assigned to [NIAMuser] Validate there is no value in "System Generated Password" field and the field is disabled Validate there is no value in "Password Term Duration (Days)" field and the field is disabled Validate there is no value in "Reminder Notice Number of Days" field and the field is disabled Validate the "Allow User Renewal" selection field is disabled Populate any other required and/or desired fields on the form Submit the form Validate the form files successfully Re-open form "User Definition" Select the [NIAMUser] just updated in step 1 Validate the "Use External Login" field is set to "Yes" Validate there is no value in "System Generated Password" field and the field is disabled Validate there is no value in "Password Term Duration (Days)" field and the field is disabled Validate there is no value in "Reminder Notice Number of Days" field and the field is disabled Validate the "Allow User Renewal" selection field is disabled Validate the values of any other required and/or desired fields populated in step 1, are as expected Navigate back to the "Use External Login" field and set the value to "No" Validate the "System Generated Password" field is now enabled Populate the field with a desired password or click the [Generate New Password] button to auto generate a new password Validate the "Password Term Duration (Days)" field is now enabled Populate the field with a desired value Validate the "Reminder Notice Number of Days" field is now enabled Populate the field with a desired value Validate the "Allow User Renewal" selection field is now enable Select the desired value in the field Validate all other fields populated in step 2a, are still populated as expected Submit the form Validate the form files successfully Re-open form "User Definition" Select the [NIAMUser] just updated in step 2 Validate all fields in step 2b are still enabled and populated as expected Validate all other fields populated as expected Navigate back to "Use External Login" field and set the value back to "Yes" again Validate the "External Login ID" field is populated with the login name assigned to [NIAMuser] Validate the value in "System Generated Password" field is cleared and the field is disabled Validate the value in "Password Term Duration (Days)" field is cleared and the field is disabled Validate the value in the "Reminder Notice Number of Days" field is cleared and the field is disabled Validate the "Allow User Renewal" selection field is still selected but the field is disabled Validate all other fields on the form are populated as expected Submit the form Validate the form files successfully Re-open form "User Definition" Select the [NIAMUser] just updated in step 3 Validate all fields in step 3b are still populated as expected and disabled Validate all other fields populated as expected Close the form Envelope Import - Doc Routing Scenario 1: Envelope Import - Validate importing "Document Routing" enabled forms Specific Setup: Have an envelope [DocEnvA] with a modeled form [DocFormA] that is enabled for document routing in form "Document Routing Setup' and has the following prompts set in the "Acknowledgments" section of the form: Prompt 'Acknowledgement Allowed' set to 'Yes' All other prompts in the section are not populated Have an envelope [DocEnvB] with a modeled form [DocFormB] that is enabled for document routing in form "Document Routing Setup' and has the following prompts set in the "Acknowledgments" section of the form Prompt 'Acknowledgement Allowed' set to 'No All other prompts in the section are disabled, as expected Steps Open form "Envelope Export". At the "Select Envelope" prompt, select [DocEnvA] Click [Begin Export]. At "File Explorer" dialog, navigate to a desired folder location to save the export file In the "File_Name" field, enter the desired name for the export file or use the default name already populated Click [Save]. Close the form. Open form "Envelope Import" Click [Select Envelope Import File] In "File Explorer, navigate to the location of [DocEnvA] and select the file Click [Overwrite Existing] Click [Begin Import Scan] Validate the import scan contains no errors or warnings related to "Acknowledgement" related fields Click [Begin Import] Validate the envelope imports successfully Open form "Document Routing Setup" Click [Select Form] and select [DocFormA] Navigate to the "Acknowledgement" section of the form Validate prompt 'Acknowledgement Allowed' set to 'Yes', as expected Validate all the other prompts in the section are not populated, as expected Open form "Envelope Export". At the "Select Envelope" prompt, select [DocEnvB] Click [Begin Export]. At "File Explorer" dialog, navigate to a desired folder location to save the export file In the "File_Name" field, enter the desired name for the export file or use the default name already populated Click [Save]. Close the form. Open form "Envelope Import" Click [Select Envelope Import File] In "File Explorer, navigate to the location of [DocEnvB] and select the file Click [Overwrite Existing] Click [Begin Import Scan] Validate the import scan contains no errors or warnings related to "Acknowledgement" related fields Click [Begin Import] Validate the envelope imports successfully Open form "Document Routing Setup' Click [Select Form] and select [DocFormB] Navigate to the "Acknowledgement" section of the form Validate prompt 'Acknowledgement Allowed' set to 'No', as expected Validate all the other prompts in the section are disabled, as expected Console Widgets Scenario 1: Validate "Console" Widgets using a "SQL Query Override" Specific Setup: Have registry setting "Enable Console Widgets/Views" is set to "Y" In form "Console Widget Configuration", create a console widget [TestWidget] for any desired form, for this test the "Admission" form is used: In the "SQL Query Override" section, populate the field with a valid SQL query to display date. For this example, the following query is used: SELECT <LINK:PATIENT510:PATID:EPN_uniqueid:EPISODE_NUMBER>PATID,EPISODE_NUMBER, EPN_uniqueid, preadmit_admission_date FROM SYSTEM.episode_history WHERE FACILITY=?FACILITY AND PATID=?PATID Have a client [TetClient] who is admitted in two active episodes. [EpisodeA] and [EpisodeB] Have [TestWidget] and the "Console Widget Viewer" widget added to the logged in user's home view Steps At the home view, select [TestClient] Select [EpisodeA] in the "Episodes" drop down list Navigate to [TestWidget] Validate a row is display with admission data for [TestClient] for the [EpisodeA], as expected Click the [Open Record] button. Validate the "Admission" form opens for edit and displays the data for [EpisodeA], as expected. Close the form Click the [View] button in the row Validate the "Console Widget Viewer" display data for [EpisodeA], as expected Click the [Open Record] button in the console viewer Validate the "Admission" form opens for edit display data for [EpisodeA], as expected Close the form Navigate back to the home view Select [EpisodeB] in the "Episodes" drop down list Navigate to [TestWidget] Validate a row is display with admission data for [TestClient] for the [EpisodeB], as expected Click the [Open Record] button. Validate the 'Admission" form opens for edit and displays the data for [EpisodeB], as expected. Close the form Click the [View] button in the row Validate the "Console Widget Viewer" display data for [EpisodeB], as expected Click the [Open Record] button in the console viewer Validate the "Admission" form opens for edit display data for [EpisodeB], as expected Close the form Envelope Import Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (PM) Envelope Export (PM) Scenario 1: Envelope Import - Importing an envelope containing "Form Designer" and "Form Definition" changes Specific Setup: Create a new modeled envelope [TestEnvelope] containing a form [TestForm] with two or more sections containing any desired field types Steps Open form "Form Designer" Select [TestForm] Select [Section1] Make any kind of form designer change to the section and click [Save] Select [Section2] Make any kind of form designer change to the section and click [Save] Select [Section3] Make any kind of form designer change to the section and click [Save] Repeat the last step for any other sections Submit the form Validate submission is successful Open "Form Definition" Select [TestForm] Navigate to "Section Def" section Select any desired section and delete the section Submit the form Validate the form submits successfully Open form "Form Designer" Select [TestForm] Click the "Sections" field Validate the section deleted in the previous step is not present in the list, as expected Validate the other sections are still present in the list Close the form Open form "Envelope Export" Select [TestEnvelope] Set prompt "Include Form Designer changes?" to "Yes" Export the envelope and save the file Close the form Open form "Envelope Import" Select the file exported in the previous step Select "Overwrite Existing" Set prompt "Include Form Designer changes?" to "Yes" Click [Begin Import Scan] Validate there are messages blocking import Click [Begin Import] Validate import is successful Open form "Form Designer" Select [TestForm] Click the "Sections" field Validate the section deleted in step 2 is not present in the list, as expected Validate the other sections are still present in the list Open [TestForm] Validate the section removed in step 2 is no longer present, as expected Navigate to each of the other sections of the form Validate the form designer changes made in those sections in step 1 are present, as expected Populate fields on the other sections Submit the form Validate the form submits successfully Modeled Form - Referral Sources Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Referral Source Contact Scenario 1: Modeled Form (w/Primary Table "Date Sorted" )- field validations Specific Setup: In form "Envelope Definition" create or have an envelope [TestEnvelope], that is defined with "Referral Sources" entity database selected in the "Entity Database" field In form "Table Definition" field create a table [TestTable], that is configured to used envelope [TestEnvelope] and has prompt "Is this Table Date or Order of Entry Sorted" set to "Date Sorted" and field "Column Name of Sort Date" populated with a desired column name [ReferralSortDate]. Include any other desired field types in the table Have a modeled form [TestForm] created using table [TestTable] adding the desired columns from the table to the form. Note: the sort date column [RefferralSortDate] defined in step 2 will automatically be displayed as field on the form In form "Referral Source Maintenance" Have a "Referral Source" [RefSourceTestA] submitted that has a "Referral Source" code entered than includes an uppercase "P" character anywhere within its name along with any other desired characters Have a "Referral Source" [RefSourceTestB] submitted that has a "Referral Source" code entered than does 'not' include an uppercase "P" character anywhere within its name along with any other desired character Steps Open form [TestForm] In the "Select Referral Source" field, select [RefSourceTestA] Validate the [RefferralSortDate] field is automatically populated with today's date, as expected Populate all other required and desired fields on the form Submit the form Validate the form submits successfully Re-open form [TestForm] In the "Select Referral Source" field, select [RefSourceTestA] At the "Pre-Display" screen, select the row just submitted in step 1 Validate the [RefferralSortDate] field is automatically populated with today's date, as expected Validate all other fields populated in step 1, are populated as expected Open form [TestForm] In the "Select Referral Source" field, select [RefSourceTestB] Validate the [RefferralSortDate] field is automatically populated with today's date, as expected Populate all other required and desired fields on the form Submit the form Validate the form submits successfully Re-open form [TestForm] In the "Select Referral Source" field, select [RefSourceTestB] At the "Pre-Display" screen, select the row just submitted in step 3 Validate the [RefferralSortDate] field is automatically populated with today's date, as expected Validate all other fields populated in step 3, are populated as expected	Topics • User Definition • NX • Document Routing • Envelope Import • Console Widget • Form Designer • Modeling • Referral
Update 72 Summary \| Details IRIS - updates Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: IRIS Terminal Session IRIS System Management Portal Scenario 1: Guardiant form - Field validations Specific Setup: Have a system configured for "Guardiant" reporting Have a user with access to the "Guardiant" form Steps Open form "Guardiant" Click the "Guardiant Configuration" section Click [Test Connectivity] Validate message "Connectivity Test Successful" is displayed Click [OK] Click [Test Daily Collection] Click [Yes] to the warning message Validate message "Test Succeeded" is displayed Click [Test Metrics Collection] Click [Yes] to the warning message Validate message "Test Succeeded" is displayed Click "Export Configuration" In "File Explorer", select a directory to save file Click [Save] Go to the directory where the file was saved Open the "GuardiantConfiguration.txt" file Validate data is present in the file Scenario 2: Windows "ODBC Data Source Administrator" - Validate successfully ODBC connection to Avatar database Specific Setup: Have a "Cache 2017" or "IRIS" Avatar database for testing Have the "Host" name or "IPaddress" assigned to that system available for testing Have a user [TestUser] who has ODBC SQL table access assigned in form "User Definition" or "User Role Definition" Steps Open the Windows "ODBC Data Source Administrator" utility program Click "Add" Select the desired "ODBC" driver In the ODBC set up screen Populate the "Name" and "Description" fields with the desired value Populate the "Host", "Port" and "Cache Namespace" fields with the appropriate values to connect to the Avatar Database Populate the user name field with system code and user [TestUser] who has "ODBC" table access. For example "SBOX:Testuser" Populate the "Password" field with password assigned to [TestUser] Click [Test Connection] Validate the connections is successful	Topics • Cache • Guardiant • NX • Database Management
Update 74 Summary \| Details Modeled Forms with 'Treatment Plan' selection leaf fields Scenario 1: Modeled forms - Validate Modeled form with 'Treatment Plan' selection leaf Specific Setup: A modeled form must be configured with a 'Treatment Plan' selection leaf that is initially enabled and required (Form A). A client is enrolled in an existing episode and has a 'Treatment Plan' on file (Client A). Steps Select "Client A" and access "Form A". Validate the 'Treatment Plan' field label is required. Populate all fields except the 'Treatment Plan' selection leaf field. Select "Final" in the 'Draft/Final' field. Validate a message is displayed stating: The following required prompt(s) do not contain information: Treatment Plan. Click [OK]. Validate a message is displayed stating: "Final" cannot be selected until all of the required prompts within the form contain information. Click [OK]. Click [Select Treatment Plan Item]. Select the desired treatment plan item(s) and click [Return]. Validate the 'Treatment Plan' field contains the selected item(s). Select "Final" in the 'Draft/Final' field. Validate a message is displayed stating: Selecting "Final" prevents future edits. Click [OK] and [Submit]. Select "Client A" and access "Form A". Select the record filed in the previous steps and click [Edit]. Validate a message is displayed stating: The selection is set to "Final". Data may be viewed only. Click [OK]. Validate all previously filed data is displayed. Validate the 'Select Treatment Plan Item' button is disabled. Close the form.	Topics • Modeling • Treatment Plan • NX
Update 75 Summary \| Details Document Routing - RADplus Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form With Service Documentation Add Non-User Signature (PM) Scenario 1: Inpatient Progress Notes - Validate document routing Specific Setup: Document routing must be enabled for the "Inpatient Progress Notes" form. Tester must select a client for testing who has an inpatient episode. Steps Open the "Inpatient Progress Notes" form. Create and finalize a document. Sign the document. Using "Clinical Document Viewer", view and print the document. Validate the document displays and prints. Open the "Inpatient Progress Notes" form. Create and route a progress note to an approver. Sign on as the approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document" and approve the document. Using the "Clinical Document Viewer", view the document that was just approved. Open the "Inpatient Progress Notes" form. Create and route a note to multiple approvers. Sign on as the first approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Open the "Clinical Document Viewer" form. Select the document that was just routed/finalized. Validate that the document displays and prints. Open the "Inpatient Progress Notes" form. Create a progress note and route to several approvers. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Repeat steps 12b-13c for each additional approver. Open "Clinical Document Viewer". Validate the document that was just filed display and prints. Scenario 2: Document Routing - (Accept/Route) Modeled Form Specific Setup: Have any form [TestForm] enabled for document routing, for this example a Modeled form will be used [TestUser] is a staff member with access to [TestFom] and has the "My To Do's" widget on their home view Log in as [TestUser] Steps Access [TestForm] for any client [TestClient] Populate the desired fields on the form Select "Final" in the 'Draft/Final' field. A message displays indicating "Selecting Final prevents future edits". Click [OK] and [Submit]. Verify the document preview displays the data as expected Click [Accept and Route]. Enter the password for the user in the 'Password' field Click [OK]. In the "Route Document To" screen, select [TestUser] in the "Add Approver" search field and click [Add] Click [Submit] to route the document [TestDoc] Navigate to the 'My To Do's' widget. Locate the To Do for document just routed in step 1 Click [Approve Document] Verify the document preview displays the data as expected Click [Accept]. Enter the password for the user in the 'Password' field. Click [OK]. Validate the "To Do" has been removed from the "My To Do's" widget Access the 'Clinical Document Viewer' form. Enter [TestClient] in the 'Select Client' field. Locate [TestDoc] in the document results list Click [View] to display the document Verify the document preview displays the data as expected Close the form. Scenario 3: Document Routing - (Accept/Route) Modeled Form with "Service Documentation" Specific Setup: Have a modeled form that is enabled for "Service Documentation" Steps Open the modeled form Select a client [TestClient] In the "Data Row For" field, select "New Service" Set the "Service Date" field Populate all other required fields on the form Set the "Draft/Final" field to "Final" Click "Accept and Route" at the document routing "Confirm Document" screen On the "Route Document To" screen, select and add an approver in the "Add" prompt box Click "Submit" to route the document [TestDoc] Navigate to the 'My To Do's' widget. Locate the To Do for document just routed in step 1 Click [Approve Document] Verify the document preview displays the data as expected Click [Accept]. Enter the password for the user in the 'Password' field. Click [OK]. Validate the "To Do" has been removed from the "My To Do's" widget Access the 'Clinical Document Viewer' form. Enter [TestClient] in the 'Select Client' field. Locate [TestDoc] in the document results list Click [View] to display the document Verify the document preview displays the data as expected Close the form. Scenario 4: Treatment Plan - File a Treatment Plan with Document Routing Specific Setup: Client is enrolled in an existing episode (Client A). The 'Treatment Plan' form must have document routing enabled. Must have the 'My To Do's' widget configured on a view. The 'Set Current Status To Active When Plan Is Finalized' registry setting is set to "N" for the 'Treatment Plan' form. The 'Set Current Status To Completed On Plan End Date' registry setting is set to "N" for the 'Treatment Plan' form. Steps Select "Client A" and access the 'Treatment Plan' form. Click [Add]. Enter the current date is displayed in the 'Plan Date' field. Select the desired date in the 'Plan Date' field. Select the desired value in the 'Plan Type' field Select "Draft" in the 'Treatment Plan Status' field. Validate "Draft" is now selected in the 'Current Status' field. Click [Launch Plan]. Add a problem, goal, objective, and intervention. Click [Return to Plan] and [OK]. Hover over the problem in the 'Problems' field. Validate a "not allowed" icon displays indicating the field cannot be edited. Validate the 'Problem' is displayed in dark grey text. Select "Final" in the 'Draft/Final' field. Select "Active" in the 'Current Status' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Validate the user is unable to print. Validate all treatment plan data displays as expected. Please note: the 'Current Status' field will not be included in the document image. This is because the 'Current Status' field can be updated after a 'Treatment Plan' has been finalized. Click [Accept]. Enter the password and click [Verify]. Select "Client A" and access the 'Treatment Plan' form. Select the record from the previous steps and click [Edit]. Validate a message is displayed stating: This plan is marked as Final. Only the following field(s) may be updated: 'Current Status'. Do you want to continue? Click [Yes]. Validate the plan displays as expected and fields are disabled, except for the 'Current Status' field. Select "Completed" in the 'Current Status' field. Click [Submit]. Validate a message is displayed stating: The following fields are updated: 'Current Status'. Click [OK]. Select "Client A" and access the 'Treatment Plan' form. Select the record from the previous steps and click [Edit]. Validate a message is displayed stating: This plan is marked as Final. Only the following field(s) may be updated: 'Current Status'. Do you want to continue? Click [Yes]. Validate "Completed" is selected in the 'Current Status' field. Close the form. Scenario 5: Document Routing (Modeled Form) - (Accept / Route) Documents with 'Approval Comments' Specific Setup: Have a form [TestForm], for example a "Modeled" form or "Treatment Plan" form that has been enabled for document routing in form "Document Routing Setup" and has prompt "Allow Comments During Approval" to "Yes" [TestForm] includes a "Signature" field Have three users: [StaffA] and [StaffB] are staff members and have the "My To Do's" widget on their home view [StaffC] is a staff member and has the "Co Signer for Other Practitioners" prompt in the document routing section set to 'Yes'.in form 'User Definition' All three users have the "My To Do's" widget on their home views Have a report to display data in the "SYSTEM.DocR.comments" table Log in as [StaffA] Steps Open form [TestForm] and select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept] Provide the password and click [Verify] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document submitted in step 1. Validate the "Signature" field on the document is populated with signature noted in step 1. Validate the "Comments" entered and noted in step 1, are displayed as expected At the bottom of the document, validate that the document includes the "Electronically Signed By:" field, populated with name of [StaffA] Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate a row is present for the "Approval Comments" entered in step 1 and is displayed as expected Open [TestForm] and a select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept and Route] At the "Route To Document" screen, add [StaffA], [StaffB] and [StaffC] as approvers Click [Submit] Log out as [StaffA] Log in as [StaffB] Navigate the "My To Do's widget Click on the "New" tab and validate the To Do sent in step 4, is present Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes two "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" and below it, [StaffB] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment Click [OK] Log out as [StaffB] Log in as [StaffC] Navigate the "My To Do's widget Click on the "Sign" tab In the "Staff" search field, search for [StaffA]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do sent to [StaffA] is found, select the To Do to review it Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Click [Sign All] Validate the To Do is removed from the To Do list Navigate back to the "My To Do's" widget Click on the "Sign" tab In the "Staff" search field, search for [StaffC]. Validate the To Do sent to [StaffC] in step 4 is present, select the To Do Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author", [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document that was just created in the previous step Validate the "Signature" field on the document is populated with signature noted in step 10 Validate the "Comments" entered noted in step 10, are displayed as expected At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author" [StaffB] signed as "Staff" Validate the comments entered by [StaffB] are entered in step 7 are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffA]) Validate the comments entered by [StaffC] in step 9, are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffC]) Validate the comments entered by [StaffC] in step 10, are displayed as expected Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate the following rows are present on the report, displayed as expected: A row displaying the "Approval Comments" entered in step 1 by [StaffA] A row displaying the "Approval Comments" entered in step 7 by [StaffB] A row displaying the "Approval Comments" entered in step 9 by [StaffC] when signing for [StaffA] A row displaying the "Approval Comments" entered in step 10 by [StaffC], signing as [StaffC] Scenario 6: Document Routing (Treatment Plan) - (Accept / Route) Documents with 'Approval Comments' Specific Setup: Have a "Treatment Plan" form [TestForm] has been enabled for document routing in form "Document Routing Setup" and has prompt "Allow Comments During Approval" to "Yes" [TestForm] includes a "Signature" field Have three users: [StaffA] and [StaffB] are staff members and have the "My To Do's" widget on their home view [StaffC] is a staff member and has the 'Co Signer for Other Practitioners' prompt in the document routing section set to 'Yes'.in form 'User Definition' All three users the "My To Do's" widget on their home views Have a report to display data in the "SYSTEM.DocR.comments" table Log in as [StaffA] Steps Open form [TestForm] and select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept] Provide the password and click [Verify] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document submitted in step 1. Validate the "Signature" field on the document is populated with signature noted in step 1. Validate the "Comments" entered and noted in step 1, are displayed as expected At the bottom of the document, validate that the document includes the "Electronically Signed By:" field, populated with name of [StaffA] Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate a row is present for the "Approval Comments" entered in step 1 and is displayed as expected Open [TestForm] and a select any client Populate the "Signature" field. Make a note of the signature entered. Set the "Draft/Final" field to "Final". Submit the form. At the "Confirm Document" screen Validate the "Signature" field is populated as expected Click [Accept and Route] At the "Route To Document" screen, add [StaffA], [StaffB] and [StaffC] as approvers Click [Submit] Log out as [StaffA] Log in as [StaffB] Navigate the "My To Do's widget Click on the "New" tab and validate the To Do sent in step 4, is present Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes two "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" and below it, [StaffB] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment Click [OK] Log out as [StaffB] Log in as [StaffC] Navigate the "My To Do's widget Click on the "Sign" tab In the "Staff" search field, search for [StaffA]. [Note: for Avatar NX, clicking the 'Change' link located in the top left corner of the widget, allows the user to search for another staff member] Validate the To Do sent to [StaffA] is found, select the To Do to review it Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures: [StaffA] signed as the "Author" [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Click [Sign All] Validate the To Do is removed from the To Do list Navigate back to the "My To Do's" widget Click on the "Sign" tab In the "Staff" search field, search for [StaffC]. Validate the To Do sent to [StaffC] in step 4 is present, select the To Do Click [Approve Document] At the document preview Validate the "Signature" field on the document is populated with signature noted in step 4 At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author", [StaffB] signed as "Staff" [StaffC] signed as "Staff" Click [Accept] At the "Approval Comments" dialog, populate the text field with a desired comment [TestComments]. Make note of the comment entered Click [OK] Open the "Clinical Document Viewer" form. Select the client and click [Process] Select and view the document that was just created in the previous step Validate the "Signature" field on the document is populated with signature noted in step 10 Validate the "Comments" entered noted in step 10, are displayed as expected At the bottom of the document, validate that the document includes three "Electronically Signed By:" field signatures, [StaffA] signed as the "Author" [StaffB] signed as "Staff" Validate the comments entered by [StaffB] are entered in step 7 are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffA]) Validate the comments entered by [StaffC] in step 9, are displayed as expected [StaffC] signed as "Staff" (Signing for [StaffC]) Validate the comments entered by [StaffC] in step 10, are displayed as expected Close the form Run the report or query on the "SYSTEM.DocR.comments" table Validate the following rows are present on the report, displayed as expected: A row displaying the "Approval Comments" entered in step 1 by [StaffA] A row displaying the "Approval Comments" entered in step 7 by [StaffB] A row displaying the "Approval Comments" entered in step 9 by [StaffC] when signing for [StaffA] A row displaying the "Approval Comments" entered in step 10 by [StaffC], signing as [StaffC] Scenario 7: Ambulatory Progress Notes - Validate document routing Specific Setup: Document routing must be enabled for the "Ambulatory Progress Notes" form. Steps Open the "Ambulatory Progress Notes" form. Create and finalize a document. Sign the document. Using "Clinical Document Viewer", view and print the document. Validate the document displays and prints. Open the "Ambulatory Progress Notes" form. Create and route a progress note to an approver. Sign on as the approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document" and approve the document. Using the "Clinical Document Viewer", view the document that was just approved. Open the "Ambulatory Progress Notes" form. Create and route a note to multiple approvers. Sign on as the first approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Open the "Clinical Document Viewer" form. Select the document that was just routed/finalized. Validate that the document displays and prints. Open the "Ambulatory Progress Notes" form. Create a progress note and route to several approvers. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Repeat steps 7b-8c for each additional approver. Open "Clinical Document Viewer". Validate the document that was just filed display and prints.	Topics • Document Routing • NX • Service Documentation • Treatment Plan
Update 76 Summary \| Details Client/Staff widget - Staff Credentials Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Practitioner Category Practitioner Enrollment Scenario 1: Practitioner - Practitioner Credentials - Search Results Specific Setup: Dictionary Update: Staff File - (214) Practitioner Credential - has desired values. Identify two practitioners to add credentials to. Steps Open 'Practitioner Category' Enter the first staff member in 'Select Staff'. Select the desired search result. Select the desired 'Enrollment History'. Select the desired 'Category/Taxonomy'. Click [Practitioner Credentials]. Select the desired value in 'Select Credentials'. Note the value. Click [OK]. Click [Add Practitioner Categories]. Click [OK]. Submit the form. Search for the practitioner and verify that the dictionary code displays after the name and before the ID number. Open 'Practitioner Enrollment'. Enter the second staff member in 'Select Staff'. Select the desired search result. Select the 'Categories/Taxonomy' section. Select the desired 'Category/Taxonomy'. Click [Practitioner Credentials]. Select the desired value in 'Select Credentials'. Note the value. Click [OK]. Click [Add Practitioner Categories]. Click [OK]. Submit the form. Search for the practitioner and verify that the dictionary code displays after the name and before the ID number.	Topics • Database Management • NX
Update 78 Summary \| Details Documents Console Widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: HomeView.Documents.Console Widget Scenario 1: Documents Console Widget - Column data validations Specific Setup: Have a client [TestClientA] who has existing documents on the system that were created on various dates and with various document types Have another client [TestClientB] who has existing documents on the system that were created in different episodes Have a "Documents" widget created [TestWidget] set up in form "Console Widget Configuration", configured to include all document types available in the "Document Types to Display" field [TestWidget] is included on the logged in user's Home View Steps At the Home View, select [TestClientA] Navigate to "Documents" console widget [TestWidget] Click the "Document Description" column header Validate all documents are listed and sorted by document description in ascending alphabetical order, as expected Click the "Document Description" column header again Validate all documents are listed and sorted by document description in descending alphabetical order, as expected Click the "Document Date" column header Validate all documents are listed and sorted by document date in ascending date order, as expected Click the "Document Date" column header again Validate all documents are listed and sorted by document date in descending date order, as expected At the Home View, select [TestClientB] Navigate back to "Documents" console widget [TestWidget] Click the "Document Episode" column header Validate all documents are listed and sorted by episode number in ascending numerical order, as expected Click the "Document Episode" column header again Validate all documents are listed and sorted by episode number in descending numerical order, as expected	Topics • Console Widget • NX
Update 79 Summary \| Details Block Client - report Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Block Client Chart Scenario 1: Block Client Chart (Form) - "Blocked Clients" Report Specific Setup: In form "Block Client Chart" Have a client [TestClientA] already added in the "Blocked Clients" section Have another client [TestClientB] who needs to be added to the list Have access to form "Block Client Chart" Steps Open form "Block Client Chart" Click the "Blocked Clients" section In the "Block Clients" grid Validate a row is present for [TestClientA], as expected Click the [Add New Item] button In the "Select Client" field, search and select [TestClientB] Populate the required and desired fields in the section Click [Submit] Validate the form files successfully Re-open form "Block Client Chart" Click the "Blocked Clients" section In the "Block Clients" grid Validate a row is present for [TestClientA], as expected Validate a row is present for [TestClientB], as expected Click back to the main section of the form In the "Clients to Display" field, select "All" clients Click the [List Blocked Clients] button to generate the report Validate the "Block Clients" report contains Information submitted for [TestClientA] and [TestClientB], as expected	Topics • 835 Health Care Claim Payment/Advice • 835 • 837 Institutional • Block Client Chart
Update 80 Summary \| Details Modeling - 'SYSTEM.radplus_envelope_info' table Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Data Element Help Message Definition (PM) Envelope Merge (PM) Form Designer (PM) Form Deletion (PM) Table Deletion (PM) Import Reports (PM) Caseload Type Definition (PM) Dynamic Form - Caseload Type Definition - Select Existing Caseload Type Notification Type Definition Form Signature Authentication (PM) Report Definition (PM) Report Definition Export Report Definition Import (PM) Dictionary Import (PM) Change Envelope Build Environment (PM) Scenario 1: Validate (Audit Field) data in the 'SYSTEM.radplus_envelope_info' SQL Table View Specific Setup: Have the following "modeled" envelopes created: [TestEnvelopeA] contains a modeled table [TestTable] and modeled form [TestForm] that includes a "Scrolling Free Test" field, a "Draft/Final" field, a "Dictionary" field and any other desired field types [TestEnvelopeB] contains a modeled table [TestTableB] and modeled form [TestFormB] that includes any desired field types and no data has been filed in the form yet [TestEnvelopeC] contains a modeled table and modeled form that includes any desired field types In form "Envelope Export", export [TestEnvelopeB] and store the export file in a folder The user [TestUser] has permissions assigned to query table view 'SYSTEM.radplus_envelope_info' in their user definition Have a report [TestReport] created to display field data in the 'SYSTEM.radplus_envelope_info': table In form "Import Reports", have a report [ImportReport] imported as import type "Import Report for command button launch Log in as [TestUser] Steps Open form "Envelope Definition" Select [TestEnvelopeA] Make any change and submit the form or just submit the form without any changes Validate submission is successful. (Note the current date and time) Run [TestReport] Validate the following audit fields are populated as expected for the form just submitted, based on the submission date/time noted and the user submitting the form: *"data_entry_by", "data_entry_by_option", "data_entry_user_id", "data_entry_user_name", "data_entry_option", "data_entry_source", "data_entry_date", "data_entry_time"* In addition, if "UTC" time is enabled on the system, validate the following fields are populated as expected: *"data_entry_utc", "data_entry_timezone_info_all", "data_entry_time_j", "data_entry_offset", "data_entry_timezone_short"* Open form "Form Definition" Select the modeled form [TestEnvelopeA] Make any change to the form or just submit the form without any changes Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Table Definition" Select the modeled table [TestTableA] Make a change and submit the form or just submit the form without any changes Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Document Routing Setup" Select [TestFormA] If the form is already enabled for document routing, just submit the form, if not, then enable the form for document routing and submit the form Validate the form submits successfully (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Data Element Help Message Definition" In the "File" field, select the "File" used in envelope [TestEnvelopeA]. For example, the "User Defined Client" file In the "Data Element" field, select one of fields used on form [TestFormA]. For example, the dictionary field Enter any text in the "Data Element Help Message' Submit the form Validate the form submits successfully (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Scrolling Free Text Templates" Select the modeled table [TestTableA] In the "Template Definition" section add a row and select the "Scrolling Text Field" Populate the required fields and submit the form Validate the form submits successfully (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Envelope Merge" Select [TestEnvelopeA] In field "Envelope to Merge into Current Envelope", select [TestEnvelopeC] Submit the form Validate the form submits successfully (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Form Designer" Select the modeled form [TestFormA] Select a section of the form in the "Sections" field and click [Show Section] Either make a change in the section and submit the form or just submit the form without any changes Validate the form submits successfully (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Form Deletion" Select modeled form [TestFormB] Populate the required fields and submit the form Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Table Deletion" Select modeled table [TestTableB] Populate the required fields and submit the form Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Envelope Import" Click "Select Envelope" Navigate to location of the export file saved for [TestEnvelopeB] Select to import the envelope as an "Overwrite" Submit the form Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form "Form Definition" again Select the form [TestForm] Go to the "Object Def" section and add a "Report" object In the "Report" field select report [ImportReport] imported in the set up Submit the form Open form 'Import Reports Click "Update Existing Report" Select the report [ImportReport] imported in the setup Click [Select Report for Import] and select a new report Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected Open form 'Caseload Type Definition' to define a new modeled caseload type Submit the form Open form 'Table Definition' Select [TestTable] Add a column to the table using the caseload type just created in the previous step Submit the form Return to 'Caseload Type Definition' Select the caseload type just added in step 15 any change any field on the form. Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected Open form 'Notification Type Definition' to define a notification type. Submit the form Open form 'Table Definition' Select [TestTable] Add a column to the table using the "Notification" type just created in the previous step Submit the form Return to 'Notification Type Definition' Select the notification type just added in step 28 any change any field on the form. Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected Open form 'Form Signature Authentication' Select [TestFormA] Set "Require Signature at Form Filing" to "Yes" and populated any require fields Submit the form Validate submission is successful. (Note the current date and time) Repeat step 2 Validate results are as expected Open form 'Report Definition' to create a new report Select any report in the "Select Report" field Set 'Associate Report with Modeling Envelopes' to 'Yes' and select [TestEnvelopeA] in the "Envelopes" field Populate any other required fields Submit the form (Note the current date and time). Repeat step 2 Validate results are as expected Open form "Report Definition Export" Export the report definition created in previous step Open form "Report Definition Import" Import the report definition exported in the previous step as an "Overwrite" Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected Open form 'Dictionary Update' Select the dictionary field used in form [TestFormA] Make a change to field, for example the dictionary description Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected. Open form "Dictionary Export" Select the dictionary field modified in the previous step and export the file Open form "Dictionary Import" In the "Select file" field, select the file just exported in the previous step Submit the form (Note the current date and time) Repeat step 2 Validate results are as expected. It will record that the envelopes were modified by 'Dictionary Import'	Topics • Modeling • SQL Data Access • NX
Update 81 Summary \| Details Quick Link - Reports Scenario 1: Validate quick links for launching reports Specific Setup: Have a modeled form [TestForm] in application PM, that is not "Client" based. For example a form that is "Staff" entity based Using form "Report Definition" in "CWS", have a report definition defined [TestReport] with a "PATID" defined as a parameter that will be passed to the report defined in the form In "Form Designer" edit [TestForm] and add [TestReport] as a "Quick Link" In "Form Designer" edit the "Admission" form add also add [TestReport] as a "Quick Link" Steps Open [TestForm]: Select the entity required to launch into the form. For this example, user is prompted with "Select Staff". Navigate to the quick link [TestReport] defined on the form in the setup. Click on the quick link to launch the report definition. Populate the "Select Client" search prompt with any client [TestClient]. Validate the form opens successfully and [TestClient] is populated in the "Client" search field. Populate any other desired fields on the form. Click [Process]. Validate the report launches and data is displayed as expected. Close the report. Close [TestForm]: Open the "Admission" for an existing client [TestClient]. Navigate to the quick link [TestReport] defined in the setup. Click on the link to launch the report definition. Validate the form opens successfully and [TestClient] is populated in the "Client" search field. Populate any other desired fields on the form. Click [Process]. Validate the report launches and data is displayed as expected. Close the report. Submit or close the "Admission" form. Open the "Admission" for a "New" client: Navigate to the quick link [TestReport] defined in the setup/ Click on the link to launch the report definition/ Validate an error is displayed indicating that the form cannot be opened for a client that has not been admitted yet. Click [OK]/ Close the "Admission" form. Modeled forms Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form with Multiple Iteration Sections Scenario 1: Validate filing Modeled forms that contain "Multiple Iteration" sections Specific Setup: Have a modeled form [TestForm] that contains one "Primary" section and two "Multiple Iteration" sections on the form Have two client [TestClientA] and [TestClientB] For [TestClientA], data has already submitted in [TestForm] that includes "5000" or more rows filed in the multiple iteration section grids For [TestClientB], no data has been submitted in [TestForm] Steps Open [TestForm] and select [TestClientB]: At the primary section: Populate the desired fields on the section. Click to the first multiple iteration section: Click to 'Add' a new row. Populate the desired fields on the section. Click to the second multiple iteration section: Click to 'Add' a new row. Populate the desired fields on the section. Submit the form. Validate the form files successfully. Return to [TestForm] and select [TestClientB]: Select the row submitted in step 1.. Validate each section displays data as expected Open [TestForm] select [TestClientA]: Select the row of data already submitted, as stated in the setup: At the primary section Validate data is displayed as expected. Click to the first multiple iteration section: Validate the rows of data already submitted are displayed. Click to 'Add' a new row: Populate the desired fields on the section. Click to the second multiple iteration section: Validate the rows of data already submitted are displayed. Click to 'Add' a new row: Populate the desired fields on the section. Submit the form. Validate the form files successfully. Return to [TestForm] and select [TestClientA] Select the row submitted in step 3 Validate each section displays data as expected, including the new rows added in the multiple iteration sections.	Topics • Forms • Forms Designer • Modeling
Update 82 Summary \| Details Guardiant - metrics Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Avatar Clinical - Dashboards - Grafana Scenario 1: Guardiant Metric "Analytics" Data - Validations Specific Setup: Have a system installed and configured with "Avatar eMAR" and "Avatar Order Entry" and is enabled to send "Metric" data to "Guardiant" Have "Order Entry" order(s) posted in the system. Note the number of orders [TestOrders] and the date the orders were entered [TestOrderDate] Have "Administrative Events" performed for one or more orders on a specific date. Note the number of events [TestEvent] and the date enter [TestEventDate] Have "Services" posted in the system on a specific date. Note the number of services [TestServices] and the date entered [TestServicesDate] Have access to log into "Guardiant" Steps Log into "Guardiant" At the "Client Search", select the desired client account number In the right-hand corner, click "Analytics" Click the "Clinical" tab Navigate down to the "# of Orders" graph Hover over date in graph of when order(s) was added [TestOrderDate] Validate the number of orders [TestOrders] equals the number of expected orders for that day Navigate to "# of eMAR Administrations" graph Hover over date [TestEventDate] in graph, the date when the administration event(s) were added Validate the number equals the expected number of events for that day [TestEvent] Navigate to "Services by Week" graph Hover over date [TestServicestDate] in graph of when the services were added Validate the number equals the expected number of services [TestServices] for that day.	Topics • Guardiant
Update 83 Summary \| Details View Definition - view deletion Scenario 1: NX "View Definition" - Validate 'myDay', 'Client Dashboard' and "Additional myDayViews" load successfully after an assigned "View" is deleted Specific Setup: Have or create two views in form "View Definition". [TestViewA] is set as a home view [TestViewB] is set as a chart view Have four existing users set up in form "User Definition" that are either assigned to one or more roles or not assigned to a role [UserA], [UserB], [UserC] and [UserD]. In form 'NX View Definition' Each user has been set up with a "myDay" and "Client Dashboard" and "Additional myDay Views", that don't include [TestViewA] and [TestViewB] as a selected view Logged in user has access to "NX View Definition" and "View Definition" Steps Open 'NX View Definition' and select [UserA] in the "Select User" field Change their current 'myDay' to the view [TestViewA] Click [File] to submit the changes In the "Select User" field select [UserB] Change their current 'Client Dashboard' view to [TestViewB] Click [File] to submit the changes In the "Select User" field select [UserC] Change their 'myDay' to the view [TestViewA] Change their 'Client Dashboard' to the view [TestViewB] Click [File] to submit the changes In the "Select User" field select [UserD] Leave the current values selected in the 'myDay' and 'Client Dashboard' fields Click "Additional myDay Views" Select [TestViewA] and any other desired views Click [File] to submit the changes Open "View Definition" Click "Select View" and select [TestViewA] Click [Delete View] Submit the form Validate the form files successfully Click "Select View" and select [TestViewB] Click [Delete View] Submit the form Validate the form files successfully Log out as the current logged in user Log in as [UserA] Validate their "myDay" view [TestViewA] has not loaded and the view has defaulted to the "Netsmart Default" view as expected, as their assigned view [TestViewA] had been deleted. (Note: the Netsmart default view has just the "Did You Know?" widget and "Message Center" widget on the view) Select any client and click "Open Dashboard" link next to their name Validate their assigned "Client Dashboard" view loads as expected Close the client dashboard Click back to the "myDay "view Validated any "Additional myDay Views" assigned, are displayed across the top of the page as expected Click on any of the additional views Validate the views loads as expected Log out as [UserA] Log in as [UserB] Validate their assigned "myDay" view has loaded as expected Select any client and click "Open Dashboard" link next to their name Validate their assigned "Client Dashboard" view [TestViewB] is not displayed and the view has defaulted to the "Netsmart Default" dashboard view as expected. [Note: the Netsmart default dashboard view only contains the "My To Do's" widget] Close the client dashboard Click back to the "myDay "view Validated any "Additional myDay Views" assigned, are displayed across the top of the page as expected Click on any of the additional views Validate the views loads as expected Log out as [UserB] Log in as [UserC] Validate their "myDay" view [TestViewA] has not loaded and the view has defaulted to the "Netsmart Default" view as expected, as their assigned view [TestViewA] had been deleted. Select any client and click ""Open Dashboard" link next to their name Validate their assigned "Client Dashboard" view [TestViewB] is not displayed and the view has defaulted to the "Netsmart Default" dashboard view as expected Close the client dashboard Click back to the "myDay "view Validated any "Additional myDay Views" assigned, are displayed across the top of the page as expected Click on any of the additional views Validate the views loads as expected Log out as [UserC] Log in as [UserD] Validate their assigned "myDay" view has loaded as expected Select any client in the "My Clients" widget and click ""Open Dashboard" link next to their name Validate their assigned "Client Dashboard" loads as expected Select any client and click "Open Dashboard" link next to their name Validate their assigned "Client Dashboard" loads as expected Click back to the "myDay" view. Validate their assigned "Additional myDay Views" are displayed as expected except for [TestViewA], as that view was deleted Click on any of the additional views Validate the views loads as expected	Topics • NX • NX View Definition
Update 84 Summary \| Details Cache - prepared for future functionality Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: cache - System Management Portal [ServerA] cache - System Management Portal [ServerA] - Globals Processes View Global Data cache - System Management Portal [ServerB] cache - System Management Portal [ServerB] - Globals Cache Terminal Session (ServerA) Cache Terminal Session (ServerB) Scenario 1: Validate "Results Queue" and "Garbage Collector" (Internal) processes - (Standard System Environment) Steps Internal Testing Only	Topics • Cache
Update 85 Summary \| Details User SQL table permissions Scenario 1: Validate a user's SQL "ODBC" Table permissions Specific Setup: Have two users exist on the system that have the same "User ID" that differ only by where the period within their user ID is placed. These users are 'not' assigned to a user role. For this test: "U.serA" and "User.A" "U.serA" has access to the "SYSTEM.patient_current_demographics" table but does 'not' have access to the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" table. "User.A" also has access to "SYSTEM.patient_current_demographics" table and 'does' have access to the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables. Two other users exist on the system that have the same "User ID", that differ only by where the period within their user ID is placed. These users 'are' assigned to a user role. For this test: "R.user" and Ruse.r" "R.user" has access to the "SYSTEM.patient_current_demographics" table but 'does not' have access to the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" table. "Ruse.r" also has access to "SYSTEM.patient_current_demographics" table and 'does' have access to the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables. Each user has a "User Data Sources" name configured using MS-Windows "ODBC Data Source Administrator" application, to connect to the testing data base. Have access to "Crystal Reports" or other database program to make an ODBC connection and view SQL Table permissions for the users defined in this set up. Steps Open the database program, for this example "Crystal Reports" is used. Click "File" on the menu and then "New" to create a new report. At the "Data" dialog, click "Create New Connection". Double-click "ODBC". From the "Data Source Selection" dialog, locate the data source name created for user ID "U.serA" and double-click to select it. Populate the "User ID" field and "Password" with the credentials for "U.serA". Click "Finish". At the table tree list: Click the "SYSTEM" schema folder and then click "Tables". Validate the "SYSTEM.patient_current_demographics' table is present in the list. Validate the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables are "not" present, as expected. Click 'Cancel". Click "File" on the menu and then "New" to create a new report. At the "Data" dialog, click "Create New Connection". Double-click "ODBC". From the "Data Source Selection" dialog, locate the data source name created for user ID "User.A". Populate the "User ID" field and "Password" with the credentials for "User.A". Click "Finish". At the table tree list: Click the "SYSTEM" schema folder and then click "Tables". Validate the "SYSTEM.patient_current_demographics' table is present in the list. Validate the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables "are" present, as expected. Open the database program, for this example "Crystal Reports" is used. Click "File" on the menu and then "New" to create a new report. At the "Data" dialog, click "Create New Connection". Double-click "ODBC". From the "Data Source Selection" dialog, locate the data source name created for user ID "R.user" and double-click to select it. Populate the "User ID" field and "Password" with the credentials for "R.user". Click "Finish". At the table tree list: Click the "SYSTEM" schema folder and then click "Tables". Validate the "SYSTEM.patient_current_demographics' table is present in the list. Validate the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables are "not" present, as expected. Click 'Cancel". Click "File" on the menu and then "New" to create a new report. At the "Data" dialog, click "Create New Connection". Double-click "ODBC". From the "Data Source Selection" dialog, locate the data source name created for user ID "Ruse.r". Populate the "User ID" field and "Password" with the credentials for "Ruse.r". Click "Finish". At the table tree list: Click the "SYSTEM" schema folder and then click "Tables". Validate the "SYSTEM.patient_current_demographics" table is present in the list. Validate the "SYSTEM.Admission_data" and "SYSTEM.Appt_data" tables "are" present, as expected. Team Definition - Web Service Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Team Definition Scenario 1: "Team Definition" Web Service - Add/Remove Client from Team Specific Setup: Have a team [TestTeam] defined in form "Team Definition". Have a client [TestClient] that's admitted in an episode [TestEpisode], that needs to be added to that team. Have the "WEBSVC.TeamDefinition" set up and configured to connect to the testing database in program "SoapUI" or other web service program. Steps Open "SoapUI". Navigate to the "WEBSVC.TeamDefinition" web service. Click "AddClientToTeam" item and double click on "Request1" to open a new request. Populate the following required fields with the values needed to execute the web service on the testing system. With "Client ID" set to [TestClient], "EpisodeNumber" set to [TestEpisode] and "TeamID" set to the team ID number for [TestTeam]. SystemCode UserName Password ClientID EpisodeNumber TeamID Click to process the request. Validate the request results indicate "Client has been successfully added to the team". In Avatar: Navigate to the "Team Definition" form. Select [TestTeam] for edit. Navigate to the "Individual Client Assignment" section. Validate a row is present for [TestClient] in the "Individual Client Assignment" grid, as expected. Validate the "Client ID" field is populated with [TestClient]. Validate the "Episode(s)" field is populate with [TestEpisode]. Close the form. Return to "SoapUI". Navigate to the "WEBSVC.TeamDefinition" web service. Click "RemoveClientFromTeam" item and double click on "Request1" to open a new request. Populate the following required fields with the values needed to execute the web service on the testing system. With "Client ID" set to [TestClient], "EpisodeNumber" set to [TestEpisode] and "TeamID" set to the team ID number for [TestTeam]. SystemCode UserName Password ClientID EpisodeNumber TeamID Click to process the request. Validate the request results indicate "Client has been successfully removed from the team". In Avatar: Navigate to the "Team Definition" form. Select [TestTeam] for edit. Navigate to the "Individual Client Assignment" section. Validate the row for [TestClient] has been removed from the "Individual Client Assignment" grid, as expected. Close the form.	Topics • SQL Data Access • Team Definition
Update 86 Summary \| Details Document Management Form Re-Mapping Scenario 1: Document Management Form Re-Mapping (Re-Map Synced Facilities) Steps Internal Testing Only Document Routing Scenario 1: Document Routing - (Route) a document Specific Setup: Have any form [TestForm] enabled for document routing, for this example a Modeled form will be used [TestUser] is a staff member with access to [TestFom] and has the "My To Do's" widget on their home view Log in as [TestUser] Steps Access [TestForm] for any client [TestClient] Populate the desired fields on the form Select "Final" in the 'Draft/Final' field. A message displays indicating "Selecting Final prevents future edits". Click [OK] and [Submit]. Verify the document preview displays the data as expected Click [Accept]. Enter the password for the user in the 'Password' field Validate the form submits successfully to create the document [TestDoc] Access the 'Clinical Document Viewer' form. Enter [TestClient] in the 'Select Client' field. Locate [TestDoc] in the document results list Click [View] to display the document Verify the document preview displays the data as expected Close the form. Open form "Print Error Log" Enter today's date in the date fields Click [Submit] Validate there are messages relating to document created in step 1 Scenario 2: Document Routing - (Accept & Route) a document Specific Setup: Have any form [TestForm] enabled for document routing, for this example a Modeled form will be used [TestUser] is a staff member with access to [TestFom] and has the "My To Do's" widget on their home view Log in as [TestUser] Steps Access [TestForm] for any client [TestClient] Populate the desired fields on the form Select "Final" in the 'Draft/Final' field. A message displays indicating "Selecting Final prevents future edits". Click [OK] and [Submit]. Verify the document preview displays the data as expected Click [Accept and Route]. Enter the password for the user in the 'Password' field Click [OK]. In the "Route Document To" screen, select [TestUser] in the "Add Approver" search field and click [Add] Click [Submit] to route the document [TestDoc] Navigate to the 'My To Do's' widget. Locate the To Do for document just routed [TestDoc] Click [Approve Document] Verify the document preview displays the data as expected Click [Accept]. Enter the password for the user in the 'Password' field. Click [OK]. Validate the "To Do" has been removed from the "My To Do's" widget Access the 'Clinical Document Viewer' form. Enter [TestClient] in the 'Select Client' field. Locate [TestDoc] in the document results list Click [View] to display the document Verify the document preview displays the data as expected Close the form. Open form "Print Error Log" Enter today's date in the date fields Click [Submit] Validate there are messages relating to document created in step 1 Document Routing - Default From Last Filing Scenario 1: Doc Routing -Default Notification User from Last Filing (Send to 'Non-Staff' enabled) Specific Setup: Have a form [TestForm] set up in form "Document Routing Setup" with following prompts set: 'Enable Document Routing' se to 'Yes'. 'Allow Notifications When Final' set to 'Yes'. 'Notification List Defaults' set to 'Default From List Filing' Have "Registry setting" 'Allow sending notifications to non-staff users' set to "Y". [UserA] has access to [TestForm] and form 'Registry Settings' [UserB] is a Staff member and has the "My To Do's" widget on their home view [UserC] is not a Staff member and has the "My To Do's" widget on their home view Log in as [UserA] Steps Access [TestForm] and select any client [TestClient] Populate all desired fields on the form. Select "Final" in the 'Draft/Final' field. Click [Accept and Route/Notify] Enter the user's password in the 'Password' field. Click [OK]. On the "Route To Document" screen, navigate to the "Add Users to Notify when Final" search box Search for [UserB] Validate the user is found Click [Add] to have [UserB] receive a To do notification Search for [UserC] Validate that [UserC] is found as expected based on the setup Click [Add] to have [UserC] receive a To do notification Click [Submit] Validate the form files successfully Repeat step 1 a thru e On the "Route To Document" screen, navigate to bottom where the approvers and notifiers are listed Validate the [UserB] has been automatically defaulted as a notifier and the "Notify" check box is populated Validate the [UserC] has been automatically defaulted as a notifier and the "Notify" check box is populated Click [Submit] Validate the form files successfully Log in as [UserB] Navigate to the "My To Do's" widget Click to refresh the widget Click the "New" tab Validate there are two new notification To Do's for review, for [TestForm] submitted in step 1 Click to open each To Do Validate the "To Do Information" box contains the expected data Click the "Reviewed" check box Click [Submit] Validate submission is successful and each To Do has been removed form the To Do's list Log out as [UserB] Log in as [UserC] Navigate to the "My To Do's" widget Click to refresh the widget Click the "New" tab Validate there are two new notification To Do's for review, for [TestForm] submitted in step 1 Click to open each To Do Validate the "To Do Information" box contains the expected data Click the "Reviewed" check box Click [Submit] Validate submission is successful and each To Do has been removed form the To Do's list Scenario 2: Doc Routing -Default Notification User from Last Filing (Send to 'Non-Staff' user disabled) Specific Setup: Have a form [TestForm] set up in form "Document Routing Setup" with following prompts set: 'Enable Document Routing' se to 'Yes'. 'Allow Notifications When Final' set to 'Yes'. 'Notification List Defaults' set to 'Default From List Filing' Have "Registry setting", "Allow sending notifications to non-staff users" set to "N". [UserA] has access to [TestForm] and form "Registry Settings" [UserB] is a Staff member and has the "My To Do's" widget on their home view [UserC] is not a Staff member and has the "My To Do's" widget on their home view Log in as [UserA] Steps Access [TestForm] and select any client [TestClient] Populate all desired fields on the form. Select "Final" in the 'Draft/Final' field. Click [Accept and Route/Notify] Enter the user's password in the 'Password' field. Click [OK]. On the "Route To Document" screen, navigate to the "Add Users to Notify when Final" search box Search for [UserB] Validate the user is found Click [Add] to have [UserB] receive a To do notification Search for [UserC] Validate that [UserC] is 'not' found as expected based on the setup Repeat step 1 a thru e On the "Route To Document" screen, navigate to bottom where the approvers and notifiers are listed Validate the [UserB] has been automatically defaulted as a notifier and the "Notify" check box is populated Click [Submit] Validate the form files successfully Log out as [UserA] Log in as [UserB] Navigate to the "My To Do's" widget Click to refresh the widget Click the "New" tab Validate there are two new notification To Do's for review, for [TestForm] submitted in step 1 Click to open each To Do Validate the "To Do Information" box contains the expected data Click the "Reviewed" check box Click [Submit] Validate submission is successful and each To Do has been removed form the To Do's list	Topics • Document Routing • NX
Update 87 Summary \| Details Modeled Forms - 'Data Entry Local Time' pre-display field Scenario 1: Modeled forms - Validate 'Data Entry Local Time' pre-display field Specific Setup: Have a system enabled to use UTC date and time. Please note: this must be done by a Netsmart Representative. Have a modeled form configured to have the 'Data Entry Local Time' field in the pre-display (Form A). This form also has a 'Draft/Final' field. A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access "Form A". Populate all required and desired fields. Select "Draft" in the 'Draft/Final' field. Submit the form. Select "Client A" and access "Form A". Validate a pre-display is displayed. Validate the 'Data Entry Local Time' field contains the time the record was filed. Select the record and click [Edit]. Validate all previously filed values are displayed. Close the form.	Topics • Modeling
Update 88 Summary \| Details Table Definition Scenario 1: Table Definition - Validate creating table configured with "Table Alias" column mappings Specific Setup: Have access to form "Table Definition" in "CWS". Have an existing envelope created in form "Envelope Definition" [TestEnvelope]. Steps Open form "Table Definition". In the "Select Table" field, enter a desired new table name [AliasTable]. Click [New Avatar Table]. At the 'Table Definition" prompt, select [TestEnvelope] from the drop down list. Click [OK]. In the "Table Description" field , enter a desired table description. In the "Is This Table Date or Order of Entry Sorted". Populate the "Column Name of Sort Date", Column Description of Sort Date and the Column Label of Sort Date with desired values. Click to the "Table Alias" section: Click [Add New Item]. From the 'Alias Table Entity Database' field. Select "Client". From the "Alias Table' field. Select "Diagnosis History (ICD-100). At the "Table Alias" dialog, click [OK]. Click to the "Column Definition" section: Click [New Avatar Item]. Add the following columns: "Type of Diagnosis", using column type "Dictionary - Single Response". "Diagnosis Time", using column type of "Time". "Diagnosing Practitioner", using column type "Other entity Lookup", selecting "Staff File" in the "Entity field. "Status", using with column type "Dictionary - Single Response". "Diagnosis Search", using column type "Diagnosis - IMO Mapped Search". "Ranking", using "Dictionary - Single Response". Click to the "Column Mapping" section: Click [Add New item]. Select "Type of Diagnosis" from the "Table Column" field. Select "Type of Diagnosis" in the "Alias Table Column" field. Click [Add New item]. Select ""Diagnosis Time" from the "Table Column" field. Select "Time of Diagnosis" in the "Alias Table Column" field. Click [Add New item]. Select "Diagnosing Practitioner" from the "Table Column" field. Select "Diagnosing Practitioner" in the "Alias Table Column" field. Click [Add New item]. Select "Diagnosis Search" from the "Table Column" field. Select "Diagnosis Search" in the "Alias Table Column" field. Click [Add New item]. Select "Status" from the "Table Column" field. Select "Type of Diagnosis" in the "Alias Table Column" field. Click [Add New item]. Select "Ranking" from the "Table Column" field. Select "Type of Diagnosis" in the "Ranking" field. Click [Submit]. Validate submission is successful. Return to 'Table Definition: In the "Select Table" field, enter [AliasTable] to edit the table just created. Click the "Table Definition" section. Validate all fields populated in step 3, are populated as expected. Click to the "Table Alias" section: Validate all fields populated in step 4, are populated as expected, Click to the ""Column Definition"" section: Validate all fields populated in step 5, are populated as expected, Click to the "Column Mapping" section: Validate all fields populated in step 6, are populated as expected, Close the form, ScriptLink and event logic Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form with ScriptLink and Event Logic Scenario 1: Validate functionality of forms with "Scriptlink" and field "Event Logic" defined on a form Specific Setup: Have form [TestForm] for testing. For this test, a modeled form is used that contains three fields of any type: [FieldA], [FieldB] and [FieldC] and any other desired fields. [FieldA] is a search type field, "SQL Query Search". [FieldB] is an "Integer" field and [FieldC] is a "Date" type field. Using form "Form Definition", have event logic set on [FieldA], so that when a specific value [TestValue] is selected in the field, it will make a change to [FieldB]. For this test, [TestValue] is set to disable [FieldB]. Have a "ScriptLink" script [TestScript] created, that will pass a value to a field based on two parameters, the field number, and the value. Using form "Form Designer", edit [TestForm] and import the script [TestScript]. Navigate to and click field [FieldC] on the form: On the left side panel, click to edit the "ScriptLink" properties for the field. From the "Available Scripts" field, select [TestScript]. In the "Script Parameter" field, enter the two parameters, "Field Number" for the [FieldC], followed by a comma and then the trigger value for the event logic [TestValue], For example: "123.46,99". [Note: field numbers for fields on forms, can be found by using "Form and Table Documentation"]. Save the changes and submit the form. Steps Launch [TestForm]: Do not populate [FieldC]. Populate [FieldB]. Populate [FieldA] with a value other than [TestValue] stated in the setup. Validate the value is accepted. Validate [FieldB] is still enabled. Now populate [FieldA] with value [TestValue]. Validate the value is accepted. Validate [FieldB] is now disabled, as expected based on the event logic set in the setup. Populate any other desired fields on the form. Submit the form. Validate the form files successfully. Return to [TestForm]: Edit the row just submitted in step 1. Validate [FieldB] is now enabled and populated as expected. Validate all other fields are populated, as expected. Close the form. Return to [TestForm]: Click to add a new row. Populate [FieldB]. Navigate to [FieldC] and populate the field with any value. Validate [FieldA] is automatically populated with [TestValue]. Validate [FieldB] is now disabled, as expected based on the event logic set in the setup. Populate any other desired fields on the form. Submit the form. Validate the form files successfully. Return to [TestForm]: Click to edit the row submitted in step 3. Validate [FieldB] is now enabled and populated as expected. Validate all other fields are populated, as expected. Close the form. To Do's - Cosigner final approver Scenario 1: My To Do's Widget - Validate a user approving documents as a Co-Signer and a Final Approver Specific Setup: Have two users [UserA and [UserB] who are staff members and have the "My To Do's" widget on their home view. Enable document routing for any form [TestForm]. In form 'User Definition' , [UserA] is set to be a "Final Approver" for form [TestForm] and is set with prompt "Co-signer for other Practitioners" set to "Yes". Have a report or query to display field values in the "DocR.Document" table. Log in as [UserA]. Steps Open [TestForm]: Select any client. Populate the form and submit as "Final". At the routing screen, add just [UserA] as the approver. Submit the form. Navigate to the "My To Do's" widget. Validate the to do sent in step 1 is present. Click to approve the document [DocA]. Validate submission is successful. Validate to do is removed from the to dos list. Return to [TestForm]: Select any client. Populate the form and submit as "Final". At the routing screen, add [UserA] and [UserB] as the approver's. Submit the form. Navigate to the "Sign" tab of the "My To Do's" widget: Validate there is no to do sent yet for [DocB], as the document needs to signed by [UserB] first, In the "Staff" search field, search and select [UserB], Validate the To Do sent in step 3 is now present, Select and approve the To Do document [DocB], Validate the to do is removed, In the "Staff" search field, search for [StaffA], Validate there is a to do now for final approval, as [UserB] has approved the To Do, Select and final approve the To Do document [DocB], Validate the to do is removed from the to do list, Run the the report or query for "DocR.Document" table: Locate the row for [DocA]: Validate the document "Status" field is populated with "Final", as expected. Locate the row for [DocB]: Validate the document "Status" field is populated with "Final", as expected.	Topics • Modeling • Table • Document Routing
Update 89 Summary \| Details Deactivating Users Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Deactivate Users By Role Scenario 1: 'Deactivate Users by Role' Form- (Deactivate All Selected User's) Specific Setup: In form "User Definition", the following users have these "User Role" assignments: [User1] is assigned to "User Role" [TestRole1] [User2] is assigned to roles [TestRole1] and [TestRole2] [User3] is assigned to [TestRole2] [User4] is not assigned to any role [User5] is assigned to [TestRole1] and has prompt "Allow User Role Customization" set to "Yes" [User6] has been "Disabled" in the system. [Note: For example, a user can become disabled via the 'Change User ID' or 'User Merge' forms. 'Disabled' users are automatically "Deactivated" and that status can no longer be updated.] Steps Open form "Deactivate Users By Role" Select prompt *"Deactivate All Selected Users" In the "Select Role" field, select [TestRole1] Please Note:* *Upon submitting the form with this prompt selected, the following will outcomes are to be expected:* Users assigned to the selected Role will be "Deactivated" Users not assigned to any Role will also be "Deactivated" Users not assigned to the selected Role but are assigned to any other role will be “Activated” Submit the form Validate form submits successfully and a message is displayed indicating the number of user "Deactivated" and the number of users "Activated" Click [OK] Open form "User Definition", For each user listed below from the setup, verify that their "Deactivated" or "Activated" status is as follows, following the form submission in step 2: [User1] who is assigned to the role that was selected in step 1 [TestRole1], is "Deactivated" [User2] who is assigned to multiple roles [TestRole1] and [TestRole2], is also "Deactivated". [Note: As long as one of roles assigned to a user is the selected role, the user is deactivated] [User3] who is assigned to [TestRole2] is "Active", as they are not assigned to the selected role in step1 [User4] who is not assigned to any role is "Deactivated" [User5] who is assigned to [TestRole1] but has prompt "Allow User Role Customization" set to "Yes", is "Deactivated". (Note: This form treats customized users, as a user who is not assigned to any role(s)) [User6] who is a "Disabled" user in the system Validate, a message indicating the user is disabled and cannot be updated, is displayed when selecting the user. Validate the user is "Deactivated" and the "Deactivate" checkbox is disabled, as expected Scenario 2: 'Deactivate Users by Role' Form- (Deactivate All User's Except Selected) Specific Setup: In form "User Definition", the following users have these "User Role" assignments: [User1] is assigned to "User Role" [TestRole1] [User2] is assigned to roles [TestRole1] and [TestRole2] [User3] is assigned to [TestRole2] [User4] is not assigned to any role [User5] is assigned to [TestRole1] and has prompt "Allow User Role Customization" set to "Yes" [User6] has been "Disabled" in the system. [Note: For example, a user can become disabled via the 'Change User ID' or 'User Merge' forms. 'Disabled' users are automatically "Deactivated" and that status can no longer be updated.] Steps Re- open form "Deactivate User's By Role" Select prompt *"Deactivate All Users Except Selected" In the "Select Role" field, select [TestRole1] again Please Note: Upon submitting the form with this prompt selected, the following will occur:* Users assigned to the ‘selected’ Role will be “Activated” Users not assigned to the ‘selected’ Role will be “Deactivated” Users not a member of “any” Role will also be "Deactivated" Submit the form Validate form submits successfully and a message is displayed indicating the number of user "Deactivated" and the number of users "Activated" Click [OK] Open form "User Definition", For each user listed below from the setup, verify that their "Deactivated" or "Activated" status is as follows, following form submission in step 3: [User1] who is assigned to the role selected in step 1[TestRole1], is "Activated" [User2] who is assigned to multiple roles [TestRole1] and [TestRole2], is also "Activated". [Note: As long as one of roles assigned to a user is the selected role, the user is activated] [User3] assigned to [TestRole2] is "Deactivated", as they are not assigned to the selected role in step4 [User4] not assigned to any role, still remains "Deactivated" [User5] assigned to [TestRole1] but has prompt "Allow User Role Customization" set to "Yes", is "Deactivated". (Note: This form treats customized users as a user who are not assigned to any role(s)) [User6] who is a "Disabled" user in the system. Validate a message indicating the user is disabled and cannot be updated, is displayed when selecting the user. Validate the user is "Deactivated" and the "Deactivate" checkbox is disabled, as expected	Topics • User Definition • User Role Definition • NX • "My To Do's" widget
Update 90 Summary \| Details Site Specific Section Modeling - form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (CWS) Scenario 1: Site Specific Section Modeling Form - prompt and value validations Specific Setup: Have access to form "Site Specific Section Modeling" Steps Open form "Site Specific Section Modeling" Select any form [TestFormA] from the "Site Specific Section" drop down list that has not already been configured, for example the "(Inpatient Progress Notes) Supplemental Information" form Click [OK] to edit the form. Validate the "Site Specific Section Description" field is enabled and pre-populated with the default description of "Supplemental Information", as expected Change the name of the field to a new desired value [ValueA] Validate the "Form Description" field is enabled and blank, as expected Populate the field to a desired value [ValueB] Validate the "Menu Location" field is enabled Click the drop down list and select a menu location Select the "Prompt Definition" section Click "Add New Item" and add any desired field [NewField1] Submit the form Validate the form files successfully Return to "Site Specific Section Modeling" and select [TestFormA] Select the "Prompt Definition" section In the "Prompt Definition" grid, validate [NewField1] is present, as expected Select the prompt and click [Delete Selected Item]. Validate message "Are Your Sure?" is displayed. Click [OK]. Validate the prompt is removed from the "Prompt Definition" grid. Click "Add New Item" and add any desired field [NewField2] Navigate to the "Initially Required" prompt and set it to "Yes" Navigate to prompt "Exclude from Data Collection Instrument" and set it to "Yes" Validate a message is displayed "Cannot exclude a required prompt", is displayed Click "OK" \Navigate to the "Initially Required" prompt and set it to "No" Navigate to prompt "Exclude from Data Collection Instrument" and set it to "Yes" Validate the selection is accepted Submit the form Validate the form files successfully Return to "Site Specific Section Modeling" and select [TestFormA] Validate the "Site Specific Section Description" field is still enabled and populated as expected Validate the "Form Description" field is populated as expected and is now disabled as the form, since the form has already been submitted. Validate the "Menu Location" field is populated as expected and also now disabled after form submission, as expected Navigate the "Prompt Definition" section Validate [NewField2] is present in the grid and the prompts populated in step 2 are populated as expected Validate [NewField1] that was deleted, is not present in the grid as expected ScriptLink - form launch Scenario 1: "ScriptLink' - Launch additional form validations Specific Setup: Have two "ScriptLink" scripts configured to prompt the user with a message to launch an additional form [TestFormC] [ScriptA] is 'not' configured with user defined message and will contain the default message to the user when the prompt is launched. For example "ScriptLink is attempting to launch the Avatar form "Update Client Data. Press OK to do this now" [ScriptB] is configured with user defined message when the prompt is launched. For example "Launch Form "Update Client Data" ? Have two forms for testing. [TestFormA] is configured with [ScriptA]. For this example, it is configured to trigger when the [TestFormA] is launched [TestFormB] is configured with [ScriptB]. For this example, it is configured to trigger when a value in [TesField] on the form Steps Open [TestFormA] Select a desired client Click to add a new row Validate the user is prompted with the Avatar default message "ScriptLink is attempting to launch the Avatar form '[TestFormC]'. Press 'OK' to do this now" Click "No" Validate the user is returned to [TestFormA] Close the form Re-open [TestFormA] Select a desired client Click to add a new row Validate the user is prompted with the Avatar default message "ScriptLink is attempting to launch the Avatar form '[TestFormC]'. Press 'OK' to do this now" Click "OK" Validate [TestFormC] is launched, as expected Submit or close the form Open [TestFormB] Select a desired client Navigate to [TestField] Select a value in the field other than the value set to trigger the script Validate [TestFormC] is not launched, as expected Select the value in the field set to trigger the script Validate the form launch message is displayed Validate the message includes the user defined message configured in the script, as expected. For example "Launch form [TestFormC] ? Click "No" Validate the user is returned to [TestFormB] Select the value in the field set to trigger the script again Validate the form launch message is displayed Validate the message includes the user defined message configured in the script. For example "Launch form [TestFormC] ?" Click "Yes" Validate [TestFormC] is launched as expected Submit or close the form	Topics • Site Specific Section Modeling • NX • Scriptlink
Update 92 Summary \| Details Telehealth - Daylight Savings Time setting Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Registration - Assign ID Staff Members Hours And Exceptions Member Specific Information Scenario 1: 'Update Client Data' - Verification of form filing Specific Setup: If custom Form Designer changes are present in 'Update Client Data' form, please use 'Form Designer' to revert to 'Netsmart Produced Changes'. A client is enrolled in an existing episode (Client A). The 'Enable Address Validation' registry setting must be enabled. Using the "Site Registration" form: Create additional sites. Using the "Site Hours of Operation" button to enter in operating days/hours for the sites. Using the "User Definition" form: In the "Appointment Scheduling" section, give the user access to the new sites added. Using the "Staff Members Hours and Exceptions" form: Enter hours for the staff member. Steps Select "Client A" and access the 'Update Client Data' form. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?" Click [No]. Enter an invalid address in the 'Client's Address - Street' field and press the 'Tab' key. Validate an 'Address Validation' dialog stating: "The address was invalid for the following reason: Address Not Found. Discard changes?" Click [Yes]. Validate a dialog stating: "Cancelled." and click [OK]. Validate the 'Client's Address - Street' field is cleared. Enter a valid address and populate any desired fields. Enter a 'Place of Birth' value that contains 40 characters. Select a preferred site in the "Preferred Site" field. Select a time zone in the "Time Zone for Appointment Reminders". Click [Submit]. Re-enter the form for the client and validate that the data submitted successfully. Scenario 2: Time Zone Globals - PM Steps Internal Testing Only Scenario 3: Time Zone Globals - CWS Steps Internal Testing Only Scenario 4: Time Zone Globals - MSO Steps Internal Testing Only Scenario 5: 'Member Specific Information' form - Verification of form filing Specific Setup: Avatar MSO Registry Setting 'Require Member Enrollment' must be disabled Steps Open the 'Member Specific Information' form. Select value in 'Add/Edit/Delete Funding Source Information' field. Enter/select values for 'Funding Source', 'Benefit Plan' and 'Effective Date' fields. Enter/select values for any other desired fields. Click 'Update Funding Source Information' button to save Funding Source Information entry. Click the 'Submit' button. Open the 'Member Specific Information' form. Select same client ID for record view/edit. In 'Member Specific Information' form, confirm that values previously filed are present in all fields. (This can also be confirmed directly via Avatar MSO SQL table 'SYSTEM.member_specific_info') Scenario 6: Ambulatory Progress Notes - Validate document routing Specific Setup: Document routing must be enabled for the "Ambulatory Progress Notes" form. Steps Open the "Ambulatory Progress Notes" form. Create and finalize a document. Sign the document. Using "Clinical Document Viewer", view and print the document. Validate the document displays and prints. Open the "Ambulatory Progress Notes" form. Create and route a progress note to an approver. Sign on as the approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document" and approve the document. Using the "Clinical Document Viewer", view the document that was just approved. Open the "Ambulatory Progress Notes" form. Create and route a note to multiple approvers. Sign on as the first approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Open the "Clinical Document Viewer" form. Select the document that was just routed/finalized. Validate that the document displays and prints. Open the "Ambulatory Progress Notes" form. Create a progress note and route to several approvers. Log on as another approver. Locate the document in the approver's "My To Do's" widget. Click on "Approve Document". Click "Accept". Enter the approver's password. Repeat steps 7b-8c for each additional approver. Open "Clinical Document Viewer". Validate the document that was just filed display and prints.	Topics • Update Client Data • Dictionary • Member Specific Information • Document Routing • Progress Notes
Update 93 Summary \| Details Modeled form with Service Documentation Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Modeled Form With Service Documentation Scenario 1: Service Documentation - Validate Registry Setting - "Allow Appointment Modifications" Specific Setup: Have a modeled form [TestForm] configured and enabled for service documentation that contains all the required service documentation type fields Have two appointments set for a client [TestClient] for today, one set earlier than the other. For this example: [ApptA] exists for staff [StaffA] from 7am to 8am today [ApptB] exists for staff [StaffB] from 8am to 9am today Have access to the "Registry Settings", "Scheduling Calendar" and form [TestForm] Steps Open form "Registry Settings" Search for and select setting "Allow Appointment Modifications" for edit. Note: Selecting 'Y' will enable the Service Code, Location, Duration, Start Time and End Time fields on Service Documentation-enabled modeled forms when editing an existing appointment. Changes to these values will be applied to the appointment when the data is filed as Final. Selecting 'N' will disable the service documentation fields." Set the registry setting value to "N" and submit the form Open form [TestForm] Select client [TestClient] In the "Documentation For" selection field Select "Existing Appointment" Select [ApptA] from the drop down list Validate fields "Service Charge Code", "Location", "Duration, "Start Time" and "End Time" are "Disabled" as expected, based on the registry setting. Close the form Open form "Registry Settings" Search for and select setting "Allow Appointment Modifications" for edit. Set the registry setting value to "Y" Submit the form Open form [TestForm] Select client [TestClient] In the "Documentation For" selection field, select "Existing Appointment" Select [ApptA] from the drop down list Validate fields "Service Charge Code", "Location", "Duration", "Start Time" and "End Time" are "Enabled" and this time and populated as expected. Change the appointment start and end times for [ApptA] to the same times as those of [ApptB] Set the "Draft/Final" field to "Final Validate there's a message displayed blocking the change, indicating the [TestClient] already has an appointment for the new start and end times inputted. Change the appointment start and end times for [ApptA] to a start and end time that does not conflict with another appointment Set the "Duration" field to the correct value based on the appointment start and end times entered Change the "Service Charge Code" field to a new value Validate the value is accepted Change the "Service Location" to a new value Validate the value is accepted Populate the other required fields and any other fields on the form Set the "Draft/Final" field to "Draft" Click [Submit] Validate submission is successful Open form [TestForm] Select client [TestClient] Validate all the fields on the form are populated as expected, including the fields updated in step 4 Set the "Draft/Final" field to "Final Click [OK] at the "Selecting 'Final' prevents further edits dialog Click [Submit] Validate submission is successful Open form "Scheduling Calendar" Navigate to [ApptA] in the appointment grid Validate the start and end times of the appointment on the grid is match new values entered in step 4b Click to edit the appointment Validate the value "Service Start Time" field, is the new value entered in step 4b Validate the value "Service End Time" field, is the new value entered in step 4b Validate the value "Duration" field, is the new value entered in step 4b Validate the "Service Code" field, is the new value entered in step 4b Validate the "Location" field, is the new value entered in step 4b Validate all other fields are populated, as expected Close the form	Topics • Service Documentation • NX
Update 94 Summary \| Details Product Scrolling Free Text Templates - System Templates Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Product Scrolling Free Text Templates (CWS) Append / Replace Scenario 1: Product Scrolling Free Text Templates- Validate 'Append', 'Replace', 'Cancel' functionality Specific Setup: In form "Product Scrolling Free Text Templates", have a template set up for a text field in any product form. For example, the 'Notes Field' in any progress notes form. Steps Open the product form. Right click in the text field. Select the template. Validate the text in the template is populated as expected. Hit "Enter" to go to the next line. Right click in the text field again. Select the template. Click [Append]. Validate the text in the template is populated as expected after the first template. Validate any lines after the first line and before the appended system template line should not have a leading space. Hit "Enter" to go to the next line. Right click in the text field again. Select the template. Click [Cancel]. Right click in the text field again. Select the template. Click [Append]. Validate the text in the template is populated as expected after the first two templates. Validate any lines after the second line and before the appended system template line should not have a leading space. Hit "Enter" to go to the next line. Right click in the text field again. Select the template. Click [Replace]. Validate all the templates are removed and just the new template is populated. Repeat step 1 but without hitting the "Enter" key after each template is chosen. Validate results are as expected.	Topics • Product Scrolling Free Text Templates
Update 95 Summary \| Details Routing Admin Dashboard - Query data Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Routing Admin Dashboard Scenario 1: Routing Admin Dashboard - View Queries Specific Setup: User has the "Rule Based Routing" widget and the "My To Do's" widget on their home view In the "Routing Queue Definition" form, have a queue [TestQueue] defined Have a modeled form [TestForm] that is enabled for document routing In the "Routing Configuration Definition form" Select the "Product" that modeled form [TestForm] was created in Select [TestForm] in the "Form" field Select "Yes" in the "Active" field Submit the form Have two clients [ClientA] and [ClientB] Open [TestForm] and submit and route a row for [ClientA] Open [TestForm] and submit and route a row for [ClientB] In the "My To Do's" widget, locate the to do's sent for [TestForm] in the previous step and approve them In the "Rule Based Routing" widget Locate the row for the document submitted for [ClientA] Click [Launch Workflow List] Fill out the form and click [Send Query] Populate the "Enter Reason" text field and click [Save] In the "Query Definition" grid, add two new query rows [Row1] and [Row2], populating the desired columns in each row and then save the form Locate the row for the document submitted for [ClientB] Click [Launch Workflow List] Fill out the form and click [Send Query] Populate the "Enter Reason" text field and click [Save] In the "Query Definition" grid, add just one query row [Row1] and save the form Steps Open the 'Routing Admin Dashboard' form. Select [ClientA] from the 'Queue' field. Click [Search]. Select the row from the 'Results' grid. Click [View Summary]. Select the row in the "Document Summary" screen Click [View Queries]. In the "Query Definition", queries grid Validate there are two query rows present, [Row1] and [Row2] for [ClientA] in the grid, as expected Click [Close] to the "Query Definition" screen Click [Close] again in the "Document Summary" screen Returning to the open 'Routing Admin Dashboard' form. Select [ClientB] from the 'Queue' field. Click [Search]. Select the row from the 'Results' grid. Click [View Summary]. Select the row in the "Document Summary" screen Click [View Queries]. In the "Query Definition", queries grid Validate there is just one row [Row1] present for [ClientB] in the grid, as expected	Topics • Rule Based Routing
Update 96 Summary \| Details Data reports/queries Scenario 1: Validate data results from reports generated using an ODBC login connection Specific Setup: Create a new user in form "User Definition" [TestUserA] and assign the user permissions to a table, for example table "SYSTEM. patient_current_demographics" is used Have a "Crystal Report" [ReportA] created to display data in that table using and ODBC connection configured for [TestUserA] Have a second user [TestUserB] who that already has access to that same table as [TestUserA] Have a "Crystal Report" [ReportB] created to display data in that table using and ODBC connection configured for [TestUserB] In form "Import Reports" Using the "Import Report as Form" option, have a report [ReportC] imported configured to run from a menu [TestUserC] has access to "Report Definition" form type report [ReportD] for testing. For example, product form "Admits By Program, Zip Code, Ethnicity" can be used Have three modeled forms available for testing [FormA] is enabled for document routing set in form "Document Routing Setup", to use a crystal report [ReportE] as a template to display the document image. (Note: The "Import Report for Document Routing" option in form "Import Reports", can be used to import the report into the system for use) [FormB] configured with a "Post Filing" report [ReportF] that will run at form submission [FormC] configured with a "Command Button" on the form that will run a report [ReportG] [TestUserC] has access to all forms stated in the setup and has the "Crystal Report" application on their desktop Steps In application "Crystal Reports" Open [ReportA], that has the "ODBC" connection configured for [TestUserA] Click to process the report Validate the report display all data as expected Close the report Repeat step 1a again to regenerate the report Validate results are as expected Open [ReportB], that has the "ODBC" connection configured for [TestUserB] Click to process the report Validate the report display all data as expected Close the report Repeat step 1c again to regenerate the report Validate results are as expected Log in Avatar Search for and open [ReportC], the report imported to run from a menu Validate when selected form the menu, the report launches successfully Validate the report display all data as expected Close the report Repeat step 2a again to regenerate the report Validate results are as expected Close the report Search for and open [ReportD], the "Report Definition" report Populate any prompts on the form Click to process the report Validate the report display all data as expected Close the report Repeat step 2b again to regenerate the report Validate results are as expected Search for and open [FormA], the document routing enabled modeled form set to use a "Crystal Report" [ReportE] as template to display the document image Populate the form Submit the form as "Final" Validate the document image is displayed using the format of [ReportE] and data is displayed, as expected Approve/ route and submit the document Validate submission is successful Repeat step 2c again Validate results are as expected Search for and open [FormB], the form configured with a post filing report Populate the fields on the form Submit the form Validate the form files successfully Validate the post filing report [ReportF] is launched Validate the data is displayed as expected Repeat step 2e again to regenerate the report Validate results are as expected Search for and open [FormC], the form configured with the command button report Populate the fields on the form Navigate to the "Command Button" field Click the field to launch the report Validate [ReportG] is launched Validate data is displayed as expected Submit the form Validate the form submits successfully Validate the command button report [ReportF] is launched Validate the data is displayed as expected Submit the form Validate the form files successfully Repeat step 2g again to regenerate the report Validate results are as expected Scenario 2: Validate data results from reports generated using an ODBC login connection Specific Setup: Create a new user in form "User Definition" [TestUserA] and assign the user permissions to a table, for example table "SYSTEM. patient_current_demographics" is used Have a "Crystal Report" [ReportA] created to display data in that table using and ODBC connection configured for [TestUserA] Have a second user [TestUserB] who that already has access to that same table as [TestUserA] Have a "Crystal Report" [ReportB] created to display data in that table using and ODBC connection configured for [TestUserB] In form "Import Reports" Using the "Import Report as Form" option, have a report [ReportC] imported configured to run from a menu [TestUserC] has access to "Report Definition" form type report [ReportD] for testing. For example, product form "Admits By Program, Zip Code, Ethnicity" can be used Have three modeled forms available for testing [FormA] is enabled for document routing set in form "Document Routing Setup", to use a crystal report [ReportE] as a template to display the document image. (Note: The "Import Report for Document Routing" option in form "Import Reports", can be used to import the report into the system for use) [FormB] configured with a "Post Filing" report [ReportF] that will run at form submission [FormC] configured with a "Command Button" on the form that will run a report [ReportG] [TestUserC] has access to all forms stated in the setup and has the "Crystal Report" application on their desktop Steps In application "Crystal Reports" Open [ReportA], that has the "ODBC" connection configured for [TestUserA] Click to process the report Validate the report display all data as expected Close the report Repeat step 1a again to regenerate the report Validate results are as expected Open [ReportB], that has the "ODBC" connection configured for [TestUserB] Click to process the report Validate the report display all data as expected Close the report Repeat step 1c again to regenerate the report Validate results are as expected Log in Avatar Search for and open [ReportC], the report imported to run from a menu Validate when selected form the menu, the report launches successfully Validate the report display all data as expected Close the report Repeat step 2a again to regenerate the report Validate results are as expected Close the report Search for and open [ReportD], the "Report Definition" report Populate any prompts on the form Click to process the report Validate the report display all data as expected Close the report Repeat step 2b again to regenerate the report Validate results are as expected Search for and open [FormA], the document routing enabled modeled form set to use a "Crystal Report" [ReportE] as template to display the document image Populate the form Submit the form as "Final" Validate the document image is displayed using the format of [ReportE] and data is displayed, as expected Approve/ route and submit the document Validate submission is successful Repeat step 2c again Validate results are as expected Search for and open [FormB], the form configured with a post filing report Populate the fields on the form Submit the form Validate the form files successfully Validate the post filing report [ReportF] is launched Validate the data is displayed as expected Repeat step 2e again to regenerate the report Validate results are as expected Search for and open [FormC], the form configured with the command button report Populate the fields on the form Navigate to the "Command Button" field Click the field to launch the report Validate [ReportG] is launched Validate data is displayed as expected Submit the form Validate the form submits successfully Validate the command button report [ReportF] is launched Validate the data is displayed as expected Submit the form Validate the form files successfully Repeat step 2g again to regenerate the report Validate results are as expected	Topics • Query/Reporting • SQL Data Access • Import Reports
Update 96.1 Summary \| Details Sessions Widget Scenario 1: "Avatar Sessions" Widget - validate data results Specific Setup: Have user [UserA] logged in who has the "Avatar Sessions" widget on their desktop. Have another user [UserB] who has not logged in yet. Have a third user [UserC] who has a ODBC connection created to connect to the testing system, that is configured using his userID and password [UserC] has a report created [ReportA], to display data in a table in the testing system, using his ODBC connection Steps Log in as [UserA] and note the date and time of login Navigate to the "Avatar Sessions" widget Refresh the widget and and note the current date and time Validate the "UserID" column of the widget includes the expected user ID associated with [UserA]. If this is a Netsmart hosted system Validate the "Login Date" and "Login Time" are consistent with time a date noted in step 1 Validate the "Last Activity" date and time are consistent with the date and time noted in step 2a Note the current number of connections stated in the "# of Connections" column Launch any form Refresh the the "Avatar Sessions" widget Validate the number of connections in the "# of Connections" column has incremented by 1 Close the form just launched Validate the number of connections in the "# of Connections" column has decreased by 1 Log in as [UserB] and note the current date and time. Navigate to the "Avatar Sessions" widget and refresh the widget Validate a row for both [UserA] and [UserB] are listed in the widget Validate the "UserID" column of the widget includes the expected user ID associated with [UserA] Validate the "UserID" column of the widget includes the expected user ID associated with [UserB] Repeat step 2b for [UserB] Validate results are as expected As [UserC] Open [ReportA] Click to generate the report. Note the date and time Validate the report launches successfully As [UserA] Click the 'Refresh' button on the "Avatar Sessions" widget Validate a row for both [UserA] and [UserB] are listed in the widget Validate in the "UserID" column of the widget includes the expected user ID associated with [UserA] Validate in the "UserID" column of the widget includes the expected user ID associated with [UserB] Validate a new row is present in the widget for [UserC] Validate in the "UserID" column of the widget includes the expected user ID associated with [UserC]. Note the number of connections in the "# of Connections" column As [UserC], close [ReportA] As [UserA] Click the 'Refresh' button on the "Avatar Sessions" widget Validate the row for [UserC] is no longer present in the widget, as expected Validate the rows for [UserA] and [UserB] are still present As [UserB] Log out of Avatar As [UserA] Click the 'Refresh' button on the "Avatar Sessions" widget Validate the row for [UserB] is no longer present in the widget, as expected Validate the row for [UserA] is present, as expected Data reports/queries Scenario 1: Validate data results from reports generated using an ODBC login connection Specific Setup: Create a new user in form "User Definition" [TestUserA] and assign the user permissions to a table, for example table "SYSTEM. patient_current_demographics" is used Have a "Crystal Report" [ReportA] created to display data in that table using and ODBC connection configured for [TestUserA] Have a second user [TestUserB] who that already has access to that same table as [TestUserA] Have a "Crystal Report" [ReportB] created to display data in that table using and ODBC connection configured for [TestUserB] In form "Import Reports" Using the "Import Report as Form" option, have a report [ReportC] imported configured to run from a menu [TestUserC] has access to "Report Definition" form type report [ReportD] for testing. For example, product form "Admits By Program, Zip Code, Ethnicity" can be used Have three modeled forms available for testing [FormA] is enabled for document routing set in form "Document Routing Setup", to use a crystal report [ReportE] as a template to display the document image. (Note: The "Import Report for Document Routing" option in form "Import Reports", can be used to import the report into the system for use) [FormB] configured with a "Post Filing" report [ReportF] that will run at form submission [FormC] configured with a "Command Button" on the form that will run a report [ReportG] [TestUserC] has access to all forms stated in the setup and has the "Crystal Report" application on their desktop Steps In application "Crystal Reports" Open [ReportA], that has the "ODBC" connection configured for [TestUserA] Click to process the report Validate the report display all data as expected Close the report Repeat step 1a again to regenerate the report Validate results are as expected Open [ReportB], that has the "ODBC" connection configured for [TestUserB] Click to process the report Validate the report display all data as expected Close the report Repeat step 1c again to regenerate the report Validate results are as expected Log in Avatar Search for and open [ReportC], the report imported to run from a menu Validate when selected form the menu, the report launches successfully Validate the report display all data as expected Close the report Repeat step 2a again to regenerate the report Validate results are as expected Close the report Search for and open [ReportD], the "Report Definition" report Populate any prompts on the form Click to process the report Validate the report display all data as expected Close the report Repeat step 2b again to regenerate the report Validate results are as expected Search for and open [FormA], the document routing enabled modeled form set to use a "Crystal Report" [ReportE] as template to display the document image Populate the form Submit the form as "Final" Validate the document image is displayed using the format of [ReportE] and data is displayed, as expected Approve/ route and submit the document Validate submission is successful Repeat step 2c again Validate results are as expected Search for and open [FormB], the form configured with a post filing report Populate the fields on the form Submit the form Validate the form files successfully Validate the post filing report [ReportF] is launched Validate the data is displayed as expected Repeat step 2e again to regenerate the report Validate results are as expected Search for and open [FormC], the form configured with the command button report Populate the fields on the form Navigate to the "Command Button" field Click the field to launch the report Validate [ReportG] is launched Validate data is displayed as expected Submit the form Validate the form submits successfully Validate the command button report [ReportF] is launched Validate the data is displayed as expected Submit the form Validate the form files successfully Repeat step 2g again to regenerate the report Validate results are as expected	Topics • Widgets • Forms Designer • Query/Reporting • SQL Data Access • Import Reports
Update 97.1 Summary \| Details Client Chart - Non-episodic Documents Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Document Capture Entity-Based Document Capture Scenario 1: 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 Select "Client A" and launch the 'Client Dashboard'. Click 'Document Capture' icon. Validate a 'Capture Mode' dialog stating: "How would you like to capture documents?" Click [Import]. Select "Non-episodic" in the "Episode" field. Validate the 'Document Capture' opens in a new window. Select any value in the 'Document Type' field. Enter any value in the 'Document Description' field. Click [Capture] and [Browse]. Locate the file to be imported and click [Open] and [Done]. Validate the image displays. Click [Save]. Validate a message stating: "Save Was Successful." and "Document Added to Avatar!" Click [Close Document Capture]. Close the 'Client Dashboard'. Navigate to the 'All Documents' view. Validate the newly imported non-episodic document is present and select it. Validate the 'Console Widget Viewer' displays the document as expected. Click [Close All]. Validate the 'Console Widget Viewer' no longer displays the document. Scenario 2: Client Chart - Document Capture - Import Non-Episodic Specific Setup: Perceptive must be configured and enabled. Please note: this is for myAvatar systems only. A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Client Chart'. Click "Document Capture". Import a non-episodic document. Select the desired value in the 'Document Type' field. Enter the desired value in the 'Document Description' field. Save the document. Validate messages display that indicate the document was successfully saved. Refresh the 'Client Chart'. Select the document type from the list that the document was just saved under. Select the non-episodic document that was just saved from the document list. Validate the document displays as expected. Click [Close All Documents] and close the 'Client Chart'.	Topics • Document Capture • Perceptive
Update 98 Summary \| Details Document Archiving - 'Entity' field Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Document Archiving Scenario 1: Document Archiving - archive documents for "Individual" Specific Setup: A client must have documents for archiving (Client A). Steps Access the 'Document Archiving' form. Select "Client" in the 'Entity Type' field. Select "Individual" in the 'Include' field. Select "Client A" in the 'Entity' field. Clear the value from the 'Entity' field. Validate no error is displayed. Select "Client A" in the 'Entity' field. Set "All Episodes" in the 'Episode' field. Enter the desired date in the 'Archive Documents Older Than' field. Click [View Form Types Included]. Validate forms for archive are displayed. Click [Archive]. Validate a message is displayed stating: Are you sure you want to archive these documents? Click [Yes]. Validate a message is displayed stating: Documents archived. Click [OK] and close the form. User Definition - 'External Login ID' field Scenario 1: User Definition (Field Validation) - Enable/Disable a "Netsmart Identity and Access Management(NIAM)" User Specific Setup: The 'Enable OpenID Connect Support' registry setting enabled by a Netsmart Representative. The 'System Security Defaults' form must be configured with the appropriate settings in the "OpenID Connect Configuration" section. The logged in user has permissions to add and edit users in the 'User Definition' form. Steps Access the 'User Definition' form. Enter the desired value in the 'User ID' field. Enter the desired value in the 'User Description' field. Select "Yes" in the 'Use External Login' field. Enter a value containing an apostrophe in the 'External Login ID'. Validate the 'System Generated Password' field is disabled and does not contain a value. Validate the 'Password Term Duration (Days)' field is disabled and does not contain a value. Validate the 'Reminder Notice Number of Days' field is disabled and does not contain a value. Validate the 'Allow User Renewal' field is disabled. Populate any other required and desired fields. Click [Submit]. Note: this will now be referred to as "User A". Access the 'User Definition' form. Select "User A" in the 'Select User' field. Validate the 'Use External Login' field is set to "Yes". Validate the 'External Login ID' field contains the value filed in the previous steps. Validate the 'System Generated Password' field is disabled and does not contain a value. Validate the 'Password Term Duration (Days)' field is disabled and does not contain a value. Validate the 'Reminder Notice Number of Days' field is disabled and does not contain a value. Validate the 'Allow User Renewal' field is disabled. Select "No" in the 'Use External Login' field. Validate the 'System Generated Password' field is now enabled. Enter the desired value in the 'System Generated Password' field, or click [Generate New Password] to auto generate a new password. Validate the 'Password Term Duration (Days)' field is now enabled. Enter the desired value in the 'Password Term Duration (days)' field. Validate the 'Reminder Notice Number of Days' field is now enabled. Enter the desired value in the 'Reminder Notice Number of Days' field. Validate the 'Allow User Renewal' field is now enabled. Select the desired value in the 'Allow User Renewal' field. Click [Submit]. Access the 'User Definition' form. Select "User A" in the 'Select User' field. Validate the 'Use External Login' field is set to "No". Validate the values filed in the previous steps are displayed. Select "Yes" in the 'Use External Login' field. Validate the 'System Generated Password' field is disabled and does not contain a value. Validate the 'Password Term Duration (Days)' field is disabled and does not contain a value. Validate the 'Reminder Notice Number of Days' field is disabled and does not contain a value. Validate the 'Allow User Renewal' field is disabled. Click [Submit]. Access the 'User Definition' form. Select "User A" in the 'Select User' field. Validate the 'Use External Login' field is set to "Yes". Validate the values filed in the previous steps are displayed. Close the form. Document Management Definition - Special Characters in Form Type Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Scenario 1: Document Management Definition - Validate form names with special characters Specific Setup: A modeled form must be defined (Form A). A client is enrolled in an existing episode (Client A). Steps Access the 'Document Management Definition' form. Click [Select Form]. Select "Add New" and click [OK]. Enter "<Test>" in the 'Form Name' field. Select the desired value in the 'Form Type' field. Select "Client" in the 'Entity Database' form. Click [File] and close the form. Access the 'Document Routing Setup' form. Select the desired value in the 'Application' field. Click [Select Form]. Select "Form A" in the 'Select a form to enable Document Routing' field. Click [Select Type]. Select "<Test>" as the form type. Select "Yes" in the 'Enable Document Routing' field. Select the desired value in the 'Void Reason Code' field. Click [File]. Access the 'Envelope Export' form. Select the envelope for "Form A" and click [Select]. Click [Begin Export]. Navigate to the desired export location and click [Save]. Access the 'Envelope Import' form. Click [Select Envelope Import File] and [OK]. Navigate to the exported file and select it for import. Click "Overwrite Existing". Click [Begin Import Scan]. Validate the 'Import Scan Results' field contains: There are no errors/warnings found within the import file. Select the desired value in the 'Include Form Designer Changes?' field. Click [Begin Import]. Validate a message is displayed stating: Import Completed! Click [OK] and close the form. Select "Client A" and access "Form A". Populate all required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate a "Confirm Document" document routing dialog is displayed with the data filed. Click [Accept]. Enter the password for the logged in user and click [OK]. View Definition - Disabling view customization in Avatar NX Scenario 1: View Definition - Validate disabling view customization removes existing customizations Specific Setup: Please note: this test is for Avatar NX systems. Two users must be configured for testing (User A & User B). Steps Log in as "User A". Access the 'View Definition' form. Click [Select View]. Select "Add New View" and click [OK]. Enter the desired value in the 'View ID' field. Enter the desired value in the 'View Description' field. Select "Home View" in the 'View Type' field. Select "Yes" in the 'Allow User To Customize View' field. Select 'Home view' in the field 'View Type' radio button Click [Launch View Designer]. Drag and drop the desired widgets to the view. Click [Submit]. Please note: this will now be referred to as "View A". Access the 'User Definition' form. Select "User B" in the 'Select User' field. Select the "Forms and Tables" sections. Select "View A" in the 'Home View' field. Click [Submit]. Log out. Log in as "User B". Validate "View A" is displayed. Customize the view as desired. Log out. Log in as "User A". Access the 'View Definition' form. Click [Select View]. Select "View A" and click [OK]. Select "No" in the 'Allow User To Customize View' field. Click [Submit] and close the form. Log in as "User B". Validate "View A" is displayed with the default layout and customizations have been removed. Validate the user is not able to customize the view. Envelope Import Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Envelope Export (PM) Scenario 1: Envelope Export/Import - Validations Specific Setup: Must have an envelope available for export (Envelope A). Steps Access the 'Envelope Export' form. Select "Envelope A". Select the desired value in the 'Include Form Designer Changes' field. Click [Begin Export]. Validate the file is exported to the desired location. Close the form. Access the 'Envelope Import form. Click [Select Envelope Import File]. Select the export file for "Envelope A". Select "Overwrite Existing". Select the desired value in the 'Load Un-Locked Dictionary Entries' field. Select the desired value in the 'Load Locked Dictionary Entries' field. Select the desired value in the 'Include Form Designer Changes' field. Click [Begin Import Scan]. Validate the 'Import Scan Results' field does not contain errors. Click [Begin Import]. Validate a message is displayed stating: Import Complete. Click [OK] and close the form. Access the 'Envelope Definition' form. Select "Envelope A". Validate the envelope details are displayed as expected. Close the form. Search Fields Scenario 1: Client Search - Search using large amount of characters Specific Setup: A client is enrolled in an existing episode (Client A). A client form must have document routing enabled (Form A). The logged in user must have an associated practitioner (Practitioner A). Steps Navigate to the 'My Clients' widget. Enter a large value in the 'Search Clients' field that should not return results. Validate the 'Search Results' field contains "No matches found, please refine search". Validate no errors are displayed. Enter "Client A" in the 'Search Clients' field. Validate the 'Search Results' field contains "Client A". Access "Form A". In the 'Select Client' dialog, enter a large value that should not return results. Validate the 'Search Results' field contains "No matches found, please refine search". Validate no errors are displayed. In the 'Select Client' dialog, search and select "Client A". Populate all required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate a "Confirm Document" document routing dialog is displayed with the document data. Click [Accept and Route]. Enter the password for the logged in user and click [OK]. Enter a large value in the 'Supervisor' search field that should not return results. Validate the 'Search Results' field contains "No matches found, please refine search". Validate no errors are displayed. Enter "Practitioner A" in the 'Supervisor' field. Click [Add] and [Submit]. Navigate to the 'My To Do's' widget. Validate a To Do is displayed for the document routed in the previous steps. Click [Approve Document]. Validate the document data is displayed as expected. Click [Accept]. Enter the password for the logged in user and click [OK]. Validate a To Do is no longer displayed. Quick User Definition - Identity Manager users Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Quick User Definition Scenario 1: Quick User Definition - Field Validations Specific Setup: Have a system with the following configured: The 'Enable OpenID Connect Support' registry setting enabled by a Netsmart Representative. The 'System Security Defaults' form must be configured with the appropriate settings in the "OpenID Connect Configuration" section. The 'Identity Manager' module is installed and configured. The 'System Security Defaults' form must be configured with the appropriate settings in the "Identity Manager Settings" section. Steps Access the 'User Definition' form Enter the desired value in the 'User ID' field. Enter the desired value in the 'User Description' field. Select "Yes" in the 'Associate User with a User Role' field. Select the desired user role in the 'User Role(s)' field. Select "Yes" in the 'Associate User To Network ID Through Avatar Identity Manager' field. Populate any other required and desired fields. Click [Submit] Access the 'Quick User Definition' form Select the user created in the previous steps in the 'Select User' field. Select "Yes" in the 'Use External Login' field. Validate a message is displayed stating: A user may not be associated to network logins through both Identity Manager and an external ID. Click [OK] and close the form.	Topics • NX • Document Archiving • User Definition • Document Routing • Envelope Import • View Definition • Envelope Export • Client Search • Quick User Definition • Identity Manager
Update 99 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 a user that has a 'User Description' greater than 40 characters (File A). Have a "User File Import" file created that includes a user that has a 'User Description' less than 40 characters (File B). Steps Access the 'User File Import' form. Click [Select User Import File]. Select "File A" and click [Open]. Validate the 'Import File Scan Results' field contains: Row 1 new user description is greater than 40 characters. Import file cannot be processed due to one or more errors. Validate the [Process User Import File] button is disabled. Click [Select User Import File]. Select "File B" and click [Open]. Validate the 'Import File Scan Results' field contains: No errors or warnings detected in import file. Click [Process User Import File]. Validate a message is displayed stating: Import Completed! Click [OK] and close the form. Access the 'User Definition' form. Select the user imported via "File B" in the 'Select User' field. Validate all imported data is displayed as expected. Close the form.	Topics • User Definition
Update 100 Summary \| Details Avatar RADplus 'Event Log Definition' Data Archive/Purge Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Event Log Definition Scenario 1: 'Event Log Definition' - Verification of Event Log SQL Table information Archive/Purge Specific Setup: RADplus Event Auto Archiving must be enabled, with values selected/defined for 'Purge data from SYSTEM.radplus_event_log_audit after selected duration', 'Create file of archived/purged data', 'Minimum Number of Days to Keep' and 'Directory to Place Archive Files In' fields (via 'Event Log Definition' form) 'Event Log Archiving' task must be enabled/scheduled in system (via 'System Task Scheduler' form) Crystal Reports or other SQL reporting tool Steps Where RADplus Event Log 'Enable Auto Archiving' is enabled (and archive/purged file settings defined via 'Event Log Definition' form), verify the following items after occurrence and completion of 'Event Log Archiving' scheduled system task: Open Crystal Reports or other SQL reporting tool. In SQL table 'SYSTEM.radplus_event_log', ensure that records/rows where difference of system task date and 'event_date' exceeds value defined for 'Minimum Number of Days to Keep' Event Log Definition setting are removed from table (to be added to 'SYSTEM.radplus_event_log_audit'). In SQL table 'SYSTEM.radplus_event_log_audit', ensure that records/rows moved from 'SYSTEM.radplus_event_log' are present. Where 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' Event Log Definition setting is 'Yes', ensure that existing 'SYSTEM.radplus_event_log_audit' records/rows where difference of system task date and 'audit_date' exceeds value defined for 'Minimum Number of Days to Keep' setting are removed from table. Where 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' Event Log Definition setting is 'No', ensure that existing 'SYSTEM.radplus_event_log_audit' records/rows are not removed from/remain in SQL table. Navigate to server output directory defined for 'Directory to Place Archive Files In'. If SQL table 'SYSTEM.radplus_event_log' is selected in the 'Create file of archived/purged data' Event Log Definition setting, ensure that output file is created on server containing information for archived rows/records. File Name Example: 'EventLogArchive_SBOXSBOX_98_10312023' If SQL table 'SYSTEM.radplus_event_log' is not selected/deselected in the 'Create file of archived/purged data' Event Log Definition setting, ensure that no output file is created. If SQL table 'SYSTEM.radplus_event_log_audit' is selected in the 'Create file of archived/purged data' Event Log Definition setting, ensure that output file is created on server containing information for audit rows/records which were purged/deleted. File Name Example: 'EventLogAuditArchive_SBOXSBOX_98_10312023' If SQL table 'SYSTEM.radplus_event_log_audit' is selected in the 'Create file of archived/purged data' Event Log Definition setting, ensure that no output file is created. Scenario 2: 'Event Log Definition' - Form Verification Steps Open RADplus 'Event Log Definition' form. Ensure that on opening form, existing/currently filed location for 'Directory to Place Archive Files In' field is present in form, and is not overwritten/re-defaulted where value defined. Note - 'Directory to Place Archive Files In' field may be read-only dependent on user login account/system configuration Ensure 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' field is present in form, set to 'Yes' by default. This field controls whether Event Log Audit SQL table 'SYSTEM.radplus_event_log_audit' information/records are removed from database upon exceeding the 'Minimum Number of Days to Keep' setting (default) or will remain in/are not removed from 'SYSTEM.radplus_event_log_audit' (if field set to 'No') Ensure 'Create file of archived/purged data' field is present in form, with selections for 'SYSTEM.RADplus_event_log' and 'SYSTEM.RADplus_event_log_audit' tables available This field controls whether/which Event Log SQL tables create information output files for 'SYSTEM.radplus_event_log'/'SYSTEM.radplus_event_log_audit' archived/deleted records in location specified for 'Directory to Place Archive Files In' (files for both tables created by default) or to not create these output files for either/both tables (if tables deselected) Update selected values in 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' and/or 'Create file of archived/purged data' fields if desired. Select/enter values for any other fields as required/desired. Click 'Submit' button to file 'Event Log Definition' form. Re-open 'Event Log Definition' form. Ensure that previously selected/filed values are present for all fields in 'Event Log Definition' form (including 'Directory to Place Archive Files In', 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' and 'Create file of archived/purged data' fields). Avatar RADplus 'Event Log Definition' Form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Event Log Definition Scenario 1: 'Event Log Definition' - Form Verification Steps Open RADplus 'Event Log Definition' form. Ensure that on opening form, existing/currently filed location for 'Directory to Place Archive Files In' field is present in form, and is not overwritten/re-defaulted where value defined. Note - 'Directory to Place Archive Files In' field may be read-only dependent on user login account/system configuration Ensure 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' field is present in form, set to 'Yes' by default. This field controls whether Event Log Audit SQL table 'SYSTEM.radplus_event_log_audit' information/records are removed from database upon exceeding the 'Minimum Number of Days to Keep' setting (default) or will remain in/are not removed from 'SYSTEM.radplus_event_log_audit' (if field set to 'No') Ensure 'Create file of archived/purged data' field is present in form, with selections for 'SYSTEM.RADplus_event_log' and 'SYSTEM.RADplus_event_log_audit' tables available This field controls whether/which Event Log SQL tables create information output files for 'SYSTEM.radplus_event_log'/'SYSTEM.radplus_event_log_audit' archived/deleted records in location specified for 'Directory to Place Archive Files In' (files for both tables created by default) or to not create these output files for either/both tables (if tables deselected) Update selected values in 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' and/or 'Create file of archived/purged data' fields if desired. Select/enter values for any other fields as required/desired. Click 'Submit' button to file 'Event Log Definition' form. Re-open 'Event Log Definition' form. Ensure that previously selected/filed values are present for all fields in 'Event Log Definition' form (including 'Directory to Place Archive Files In', 'Purge data from SYSTEM.radplus_event_log_audit after selected duration' and 'Create file of archived/purged data' fields).	Topics • RADplus Utilities
Update 101 Summary \| Details User Caseload - Add/Remove Scenario 1: Enhanced Caseload Menu Functionality - Validate adding and removing clients from a user's caseload Specific Setup: Registry setting "Enable enhanced caseload management from the 'Clients and Data' widget" is enabled: In the registry setting, have a user role [TestRoleA] submitted with access to this functionality. [TestUserA] is assigned to [TestRoleA] in form "User Definition". [TestUserB] is 'not' assigned to [TestRoleA] in form "User Definition". Both users have the "My Clients" widget on their home view and have other clients already on their caseload present in the widget. [TestUserA] has access to forms "Registry Settings" and "Discharge". Log in as [TestUserB]. Steps At the home view: Navigate to the "My Clients" widget: Search for [ClientA], and select the client. Right-click on the client in the "Recent Clients" list: Validate there is no option to add the client to the caseload as expected, as the user is not assigned to the user role enabled with this functionality, in the setup. Select any existing client in the user's caseload: Right-click on the client. Validate there is no option to remove the client from their caseload as expected, as the user is not assigned to the user role enabled with this functionality, in the setup. Log out as [TestUserB]. Log in as [TestUserA]. At the home view: Navigate to the "My Clients" widget: Search for [ClientA] and select the client: In the "Recent Clients" list, right-click on the client. Validate "Add to Caseload" is a selection. Click 'Add to Caseload'. Validate the [ClientA] is added to the users "My Clients" list in the widget. Search for [ClientB]: Validate the [ClientB] is added to the users "My Clients" list in the widget. Navigate back to the "My Clients" widget. In the "My Clients" list: Right-click on [ClientA] a click "Remove form Caseload". Validate the [ClienA] is removed from to the users "My Clients" list in the widget. Right-click on the [ClientB] and click "Add to Caseload". Validate the [ClientB] is removed from the users "My Clients" list in the widget. Repeat step 4a to add [ClientA] and [ClientB] to client caseload again for [TestUserA]. Open form "Discharge": Select [ClientB]. Populate the required fields on the form. Submit the form. Validate the form files successfully. Navigate back to the "My Clients" widget: Right-click on [ClientB] the client discharged and click "Remove form Caseload". Validate the [ClientB] is removed from to the users "My Clients" list in the widget. Right-click on the [ClientA] and click "Remove to Caseload". Validate the [ClientA] is removed from the users "My Clients" list in the widget. Site Specific Section Modeling - field values Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Authorization Scenario 1: Validate values in "Site Specific" fields after adding or deleting a row in a form Specific Setup: Have a form [TestForm] that has a "Site Specific" section enabled in the form, via "Site Specific Section Modeling". For this test, the "Service Authorization" form is used Using the "Site Specific Section Modeling" enable one or more site specific fields on the site specific section. Steps Open [TestForm]: Select any client [TestClient]: Click to add a new row [Row1]: Navigate to the site specific section. Populate the fields on that section with any desired values. Populate any desired fields on other sections of the form. Submit the form. Return to [TestForm]: Select [TestClient]: At the "Pre-Display" screen, select [Row1]. Navigate to the site specific section. Validate the site specific fields are populated as expected. Validate any fields populated in step 1, are populated as expected. Close the form. Repeat step 1, adding a new row [Row2], and submitting the form. Repeat step 2, editing [Row2]. Validate data results are as expected. Close the form. Return to [TestForm]. Select [TestClient]: At the pre-display, select either [Row1] or [Row2] to be deleted. For this test, [Row1] is selected: Click [Delete]. Validate [Row1] is removed from the pre-display row selection list. Click to [Add] a new row, [Row3]. Navigate to the site specific section. Validate all site specific fields on the section are not populated, as expected. Populate the desired fields on the section. Navigate to any other desired section of the form. Populate the desired fields on that section. Submit the form. Return to [TestForm]. Select [TestClient]: At the pre-display screen: Validate the [Row1] is not present as expected. Validate that [Row2] is present. Validate [Row3] is present: Click [Edit] to edit the row. Navigate to the site specific section: Validate the site specific fields are populated as expected. Navigate to the other sections of the form. Validate fields are populated as expected. My To Do's widget Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Site Specific Section Modeling (CWS) Scheduling Calendar Progress Notes (Group and Individual) 4 Scenario 1: "My To Do' s" widget - Validate approving "Progress Note" Appointment To Do's Specific Setup: Have two existing appointments [TestApptA] and [TestApptB] scheduled for staff member [TestStaff] with client [TestClient]. Using any progress note form [TestForm] enabled for document routing: Submit a row for any client [DocClient], selecting the existing appointment [TestApptA] and route the document to [TestStaff]. Submit a second row for [DocClient], selecting the existing appointment [TestApptB] and also route the document to [TestStaff] In form "Scheduling Calendar", navigate to the appointment [TestApptA] in the grid. Right-click on the appointment and either delete or reschedule the appointment to a new date and time [TestStaff] has the "My To Do's" widget on their home view. Log in as [TestStaff]. Steps Log in as [TestStaff]. Navigate to the "My To Do's" widget. Locate the "To Do" sent for [TestApptA]. Click to review the To Do. Validate the document [DocA] is displayed as expected. Click to "Accept" and then "Sign" the To Do. Validate submission is successful. Validate the To Do is removed from the To Do's list. Locate the "To Do" sent for [TestApptB]. Click to review the To Do.. Validate the document [DocB] is displayed as expected Click to "Accept" and then "Sign" the To Do. Validate submission is successful. Validate the To Do is removed from the To Do's list. Open form "Clinical Document Viewer". Select [TestClient]. Click to display all documents. Select [DocA]. Click [View]. Validate the document is displayed as expected. Close the document. Select [DocA]. Click [View]. Validate the document is displayed as expected. Close the document. Guardiant - progress note metrics Scenario 1: Validate "Guardiant" (Internal) Metric processing time performance Steps Internal Testing Only	Topics • My Clients • Site Specific Section Modeling • Document Routing • My To Do's • Guardiant
Update 102 Summary \| Details Team Definition - 'Individual Client Assignment' section Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Team Definition Scenario 1: Team Definition - 'Individual Client Assignment' section Specific Setup: Two clients are enrolled in existing episodes (Client A & Client B). Steps Access the 'Team Definition' form. Enter the desired value in the 'Team ID' field. Enter the desired value in the 'Team Description' field. Select "Yes" in the 'Active' field. Select the "Individual Client Assignment" section. Click [Add New Item]. Select "Client A" in the Client ID' field. Populate any other desired fields. Click [Add New Item]. Select "Client B" in the 'Client ID' field. Populate any other desired fields. Select the "Team Definition" section. Click [File] and close the form. Access the 'Team Definition' form. Click [Select Team]. Select the team filed in the previous steps and click [OK]. Validate focus does not shift to the "Individual Client Assignment" section automatically. Select the "Individual Client Assignment" section. Validate "Client A" and "Client B" are displayed in the 'Individual Client Assignment' grid. Close the form.	Topics • Team Definition
Update 103 Summary \| Details Avatar NX - Dialog boxes Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: User Role Definition Service Codes Service Fee/Cross Reference Maintenance CPT Code Definition (PM) Scenario 1: Service Fee/Cross Reference Maintenance - Add/Edit Service Fee Definition Specific Setup: Service Codes: Add a new service code for testing purposes (Service Code A). CPT Code Definition: A CPT Code must be defined (CPT Code A). Steps Access the ‘Service Fee/Cross Reference Maintenance’ form. Select "Enter New" in the ‘Enter New Or Edit Existing Fee/Cross Reference’ field. Enter "Service Code A" in the 'Service Code' field. Enter the desired date in the ‘From Date’ field. Enter the desired value in the 'Fee' field. Enter "CPT Code A" in the 'CPT-4 / HCPCS Code' field. Enter desired value with quotation marks into the 'CPT-4 / HCPCS Modifier' field. Click [Submit]. Click [Yes]. Select "Edit Existing" in the ‘Enter New Or Edit Existing Fee/Cross Reference’ field. Enter "Service Code A" in the 'Service Code' field. Enter the same date in the ‘From Date’ field. Click [Select Fee/Cross Ref To Edit/Default From Existing Row]. Select the desired row that filed in above steps. Click [OK]. Validate that the entered 'Fee' exists. Validate that the entered 'CPT-4 / HCPCS Code' exists. Validate that the selected ‘CPT-4 / HCPCS Modifier’ exists. Close the form. Access the ‘Service Fee/Cross Reference Maintenance’ form. Select "Enter New" in the ‘Enter New Or Edit Existing Fee/Cross Reference’ field. Enter "Service Code A" in the 'Service Code' field. Enter the same date entered in the previous steps in the 'From Date' field. Click [Submit]. Validate a dialog is displayed stating: Fee Definition already exists, please edit the existing definition. Click [OK] and validate the dialog closes. Validate a 'Filing Error' dialog stating "Filing aborted." and click [OK]. Validate the form is still open with the data entered in the previous steps. Close the form.	Topics • NX • Service Fee/Cross Reference Maintenance
Update 106 Summary \| Details Append Document - Approval Comments omitted from workflow Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Add Non-User Signature (PM) Scenario 1: Progress Notes (Group and Individual) - Validate Approval Comment Specific Setup: Define additional Avatar users to be as document approvers for the purposed of document routing. Steps Open "Document Routing Setup" form. Select the "Progress Notes (Group and Individual)" form. Set "Enable Document routing" field to "Yes". Set "Allow Comments During Approval" to "Yes". Click "Submit" to file the data. Open the "Progress Notes (Group and Individual)" form. File the form in draft mode. Retrieve the drafted form. Finalize the form by setting the "Draft/Final" field to "Final". Submit the form. Click "Accept". Provide the password. When prompted, provide the "Approval Comments". Open the "Clinical Document Viewer" form. Locate and view the document that was just filed. Validate that the document includes the authors Approval Comments in the signature area of the document. Open the "System Management Portal". Using SQL, execute the following query: SELECT * from DocR.comments Validate that a row has been added to the table. Open the "Progress Notes (Group and Individual)" form. File the form in draft mode. Retrieve the drafted form. Finalize the form by setting the "Draft/Final" field to "Final". Submit the form. Click "Accept and Route". Provide the password. Indicate who the approver(s) are. To Do's are sent to the approver(s). Log into Avatar using the User ID of an additional approver. Select the To Do the "My To Do" widget. Click "Accept" to approve the form. Enter the "Approval Comments". Log into Avatar using the User ID of an additional approver. Select the To Do the "My To Do" widget. Click "Accept" to approve the form. Enter the "Approval Comments" for this approver. Open the "Clinical Document Viewer" form. Locate and view the document that was just filed. Validate that the document includes the approver(s) Approval Comments in the signature area of the document. Open the "System Management Portal". Using SQL, execute the following query: SELECT * from DocR.comments Validate that a row has been added for each "Approval Comment" entered. Scenario 2: Add Non-User Signature - Form Validation Specific Setup: Using the "Document Routing Setup" form Enabled document routing for any progress note form. Create a user modeled form in the PM namespace. This form must contain a "Draft/Final" field. Using "Document Routing Setup" Enable document routing for the user modeled form. Click "Yes" in the "Allow Approval Comments" field. Refresh the menus. Select or admit client to be used as test client into any valid program. Steps Open the progress note form from the Setup section. Fill out and finalize a progress note. Click "Accept" and provide the password. Open the "Add Non-User Signature" form. Select the progress note that was filed in the previous step. Add text to the "Comments" field. Submit to file. Open the "Clinical Document Viewer" form. Bring up the document the non-user signature was added to. Validate the document displays as it was recorded along with the non-user signature line. Open the user modeled form. Fill out all required/desired fields. Click "Final" in the "Draft/Final" field. Click "Submit" button. Click "Sign" button'. Provider the user's password. Fill in the "Approval Comments" field. Open the "Clinical Document Viewer" form. Validate the document that was just saved displays as it was recorded. Open the "Add Non-User Signature" form. Select the document that was just saved. Display the document to validate the signature line and approval comments are listed. Enter the text in the "Comments" field. Click "Accept". Provide the user's password. Open the "Clinical Document Viewer" form. Validate the document that was just saved displays as it was recorded. Scenario 3: Append Documents Specific Setup: Create a user modeled form in the PM namespace. This form must contain a "Draft/Final" field. Using "Document Routing Setup" Enable document routing for the user modeled form. Click "Yes" in the "Allow Approval Comments" field. Refresh the menus. Select or admit client to be used as test client into any valid program. Steps Open the user modeled form. Fill out all required/desired fields. Click "Final" in the "Draft/Final" field. Click "Submit" button. Click "Sign" button'. Provider the user's password. Fill in the "Approval Comments" field. Open the "Clinical Document Viewer" form. Validate the document that was just saved displays as it was recorded. Open the "Append Document" form. Select the document that was just saved. Display the document to validate the signature line and approval comments are listed. Enter the text to be appended to the document. Click "Sign". Provide the user's password. Open the "Clinical Document Viewer" form. Validate the document that was just saved displays as it was recorded. Document Management Defaults - Perceptive synchronization streamlined. Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Client Document Capture Document Capture Scenario 1: Validate form "Document Management Definition" Steps Open "Document Management Definition" form. Click [Select Form]. Click [Add New]. Populate the "Form Name" field. Select the desired form type in the "Form Type" field. Select the desired entity in the "Entity" field. Populate any other desired fields in the "Form" section. Click the [Categories] section. Click [Select Categories]. Select the desired category from the selection list. Click [OK]. Click the [Display] section. Select the desired selections form the "Forms to Display" box. Click the [Reports] section. Click any to launch any desired report, for example the "Display Form Report". Validate the "Document Management Form Report" is displayed. Close the report. Click back to the [Form] section. Click [File]. Validate the form files successfully. Click [Select Form]. Select the form just submitted in step 5. Validate all fields populated in steps 1 thru 5, are populated as expected. Click back to the [Form] section. Click [Delete]. Click [Yes] to accept the deletion. Click [Select Form]. Validate the form that was deleted in step 7, is no longer present in the list. Click [Select Form]. Select the form "Inbox Attachments". Click [Delete] Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Click [Select Form]. Select the form "Results Document". Click [Delete]. Validate message "This form is attached to Perceptive functionality text contains "This form is attached to Perceptive functionality that is required by other parts of the system, deleting is not allowed". Click [OK]. Close the form. Scenario 2: Document Management Defaults - Perceptive Synchronization Options field Steps Internal Testing Only Scenario 3: Document Management Definition - Perceptive Syncing Form Definitions in Multiple Server environment Specific Setup: To be tested in a multiple server environment that has multiple root system codes. Using the "Document Management Definition" form: Identify a form that exists in all system codes. Steps Using the "Document Management Definition" form: Edit the existing form identified as existing in all root system codes. File the form. Open the "Client Document Capture" form. Scan or import a document. Select the form edited in "Document Management Definition". Scan or import the document. Using "Clinical Document Viewer", select the test client. Validate the document that was just filed for the form that exists in all root system codes displays as it was previously filed. Clinical Document Viewer - Printing Perceptive documents Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Batch Capture and Indexing Scenario 1: Perceptive scan, import, print,view - JxBrowser enabled Specific Setup: Perceptive storage method must be utilized. Steps Open the "Batch Capture and Indexing" form. Click "Capture". Select "Scanner" as the "Source". Scan in a document. Validate that the document capture opens in a window within Avatar and not as an Internet Explorer window. Close the batch by selecting "Send to" and sent it to the Batch Validate queue. Open the Avatar Batch Validate queue. Open the batch that was just scanned in. Click "Submit" to save the document to Avatar. Open the "Batch Capture and Indexing" form. Click "Capture". Select "File" as the "Source". Browse to the location of the file to be imported. Import the file. Validate that the document capture opens in a window within Avatar and not as an Internet Explorer window. Close the batch by selecting "Send to" and sent it to the Batch Validate queue. Open the Avatar Batch Validate queue. Open the batch that was just scanned in. Click "Submit" to save the document to Avatar. Close the form. Open the "Chart Review" form. Select the test client. Navigate to the category/section that the documents were scanned/imported into. View the scanned document. Click "Print". Validate that the print window opens in Avatar and not in Internet Explorer. Print the document. View the imported document. Click "Print". Validate that the print window opens in Avatar and not in Internet Explorer Print the document. Select the "Document Capture" link in the "Chart Review" form. Select "Capture". Select "Scanner" as the "Source". Scan in a document. Validate that the capture window opens in Avatar and not in Internet Explorer. Save the document to Avatar. Select the "Document Capture" link in the "Chart Review" form. Select "Capture". Select "Filer" as the "Source". Browse to the location on server of the file to be imported. Import a document. Validate that the capture window opens in Avatar and not in Internet Explorer. Save the document to Avatar. Navigate to the section that the items scanned/imported in with "Chart Review" are stored. Open the scanned document. Click "Print". Validate that the document displays in an Avatar popup and not an Internet Explorer popup. Print the document. Open the imported document. Click "Print". Validate that the document displays in an Avatar popup and not an Internet Explorer popup. Print the document. Open "Batch Capture and Indexing". Scan in a large multi page document. Open "Clinical Document Viewer". Open the large document. Validate that the document displays in an Avatar popup and not an Internet Explorer popup. Click "Print". Validate that the document displays in an Avatar popup and not an Internet Explorer popup. Print the document. Scenario 2: Perceptive Individual Scanning/Importing/Viewing/Printing through Chart Review Specific Setup: Perceptive storage method must be utilized. Steps Open the "Chart Review" form. Select the desired client and episode. Open the "Document Capture" form within Chart. Scan a document. Assign the document to a particular "Document Type". Save the document. Import a document. Assign the document to a particular "Document Type". Save the document. Navigate to the section designated by the "Document Type" the document was saved under. Navigate to the "Episode" tab. Open the document(s). Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the document. Open the "Clinical Document Viewer". Select the desired client and episode. Locate the document(s) that were just scanned in or imported. Validate the document(s) can be viewed and display as scanned. Validate the document(s) can be printed and display as scanned. Close the form.	Topics • Progress Notes (Group And Individual) • Envelope Import • Add Non-User Signature • Document Management • NX • Perceptive • Document Scan/Import
Update 107 Summary \| Details Transfer Caseload Scenario 1: Transfer Caseload - Client transfer validations Specific Setup: In form "Caseload Type Definition", have or create caseload type [TestCasetype]. [Note: Once created, caseload type created can be added as a field in any modeled table and used to add a client to user's caseload] Have or create a modeled form [TestForm] and add the caseload type field [TestCasetype] to the form Have two existing clients on the system for testing: [ClientA] and [ClientB] Have two users [UserA] and [UserB] Both users do not currently have [ClientA] and [ClientB] in their client caseload Both users have the "My Clients" widget on their home view [UserA] has access to [TestForm] and form "Transfer Caseload" Steps Log in as [UserA] Open [TestForm] Select [ClientA] for any episode [EpisodeA] Click to add a row [RowClientA] In the"Add to Caseload" field, select [UserA] Submit the form Re-open [TestForm] Select [ClientB] for any episode [EpisodeA] Click to add a row [RowClientB] In the"Add to Caseload" field, select [UserA] Submit the form Navigate to the "My Clients" widget Validate [ClientA] and [ClientB] are displayed in their "My Clients" list Open [TestForm] Select either [ClientA] or [ClientB]. For this test [ClientA] is used Select [RowClientA] for edit Validate fields are populated as expected Leaving the form open, navigate back to the home view Open form "Transfer Caseload" In the "Transfer Caseload From" field, select [UserA] In the "Caseload Assignment Type" field, select the "[TestForm]:Add to Caseload" selection In the "All or Selected Caseload Entries" field, click the "Selected" radio button Click [Select Caseload Entries] Validate the rows, [RowClientA] and [RowClientB] are present, as expected Click [Cancel] In the "All or Selected Caseload Entries" field, this time click the "All" radio button Populate the "Reason For Transfer" text field Submit the form Validate a message is displayed indicating: You are about to transfer a caseload for [ClientA] in [EpisodeA] form [UserA] to [UserB] Click the [Transfer] button Validate submission is successful and the following message is displayed: Some records were locked by another user and have not been updated [ClientB] in [EpisodeA] from [UserA] to [UserB] Click [OK] Close the form Navigate to the "My Clients" widget Validate [ClientA] is no longer present in their "My Clients" list Validate [ClientB] is still present in their "My Clients" list Log out as [UserA] Log in as [UserB] Validate [ClientA] is not present in their "My Clients" list, as expected Validate [ClientB] is present in their "My Clients" list, as expected Delete/Re-Assign To Do Items - form Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Escalate To Do Item Delete/Re-Assign To Do Items Scenario 1: Delete/Re-Assign To Do's - Validations Specific Setup: [UserA] has sent a notification To Do [NoteTodoA] to [UserB] via form "Send To Do Notification" [UserA] has also sent a notification to do [NoteTodoB] to [UserC] via form "Send To Do Notification" [UserD] does not have any To Do's in their "My To Do's" list [UserE] has two To Do items [TestToDoA] and [TestToDoB] in their "My To Do's" list, not generated via form "Send To Do Notification" Log in as [UserA] Steps Navigate to the "My ToDo's" widget and click to refresh the widget Click the "Sent & Not Received" column in the widget Validate [NoteTodoA] generated in setup that was sent to [UserB] is present Validate [NoteTodoB] generated in setup that was sent to [UserC] is present Select [NoteTodoA] and click the "Escalate" column in the widget Click the "Escalate To Do Item" link in the column In the "Escalate To Do Item" form Search for [UserD], in the "Select User" search field Click [Add User] In the "Sent To" field, click the check box for [UserD] In the "Note" field, enter a desired message for [UserD] Click [Submit] At the "To Do Sent" message dialog, click [OK] Now select the row for the to do [NoteTodoB] click the "Escalate" column Click the "Escalate To Do Item" link in the column In the "Escalate To Do Item" form Search for [UserE], in the "Select User" search field Click [Add User] In the "Sent To" field, click the check box for [UserE] In the "Note" field, enter a message for [UserE]. Click [Submit] At the "To Do Sent" message dialog, click [OK] At the Home View, open form "Delete/Re-Assign To Do Items" Select "Delete" in the "Delete/Re-assign" field In the "Select User" field, select [UserD] Validate a message stating "All To-Do Items for this user have been reviewed or deleted" is displayed Click [OK] Validate there are no to do's present in the "To Do's" list box as expected, including the escalated notification [NoteToDoA] sent to [UserD] in step1, [*Please Note: Any To Do's generated via "Send Notification To Do" form, are excluded from the "Delete/Re-Assign To Do Items" form]* Click [OK] Select "Re-Assign" in the "Delete/Re-assign" field In the "Select User" field, select [UserD] again Validate a message stating "All To-Do Items for this user have been reviewed or deleted" is displayed again Click [OK] Validate there are no To Do's present in the "To Do's" list box as expected, including the escalated notification [NoteToDoA] sent to [UserD] in step 1. Click [OK] Select "Delete" again in the "Delete/Re-assign" field This time in the "Select User" field, select [UserE] Validate the notification to do [NoteToDoB], escalated to [UserE] in step1 is not present in the "To Do's" list box, as expected Validate [TestToDoA] and [TestToDoB] that were not generated from the "Send To Do Notification" form are present in the "To Do's" list box Select [TestToDoA] in the "To Do's" list box Enter any desired comment in the "Comment" field Submit the form and return to the form Select "Re-Assign" in the "Delete/Re-assign" field In the "Select User" field, select [UserE] Validate [TestToDoA] just deleted is not present in the "To Do's" list box. Validate the notification [NoteToDoB], escalated to [UserE] is also not present in the "To Do's" list box Validate [TestToDoB] is present in the "To Do's" list box Select [TestToDoB] In the "Select Target User" field, select any other user [UserF] to re-assign the to do to Submit the form Validate the form submits successfully Closet the form Log out as [UserA] Log in as [UserF] Navigate to the "My To Do's" list Validate the to do reassigned to [UserF] is present in their to do's list as expected Click [Review To Do Item] Validate the to do information for [TestToDoB], is displayed as expected Select the "Review" check box Submit the form Validate the To Do is removed from the "My To Do's" widget Document Routing - status information Scenario 1: Document Routing - Validate a document's routing "Status" displayed in "Chart" and "Console Widget Viewer" Specific Setup: [TestFormA] is a modeled form enabled for document routing A console widget [WidgetA] has been created for the form in form "Console Widget Configuration" [TestFormB] is a progress note form enabled for document routing A console widget [WidgetB] has been created for the form in form "Console Widget Configuration" [TestFormC] is a treatment plan form enabled for document routing A console widget [WidgetC] has been created for the form in form "Console Widget Configuration" [TestUser] has access all three widgets on their home view along with the "Console Widget Viewer" widget [TestUser] has all three test forms added to their chart view Have three users who are staff members: [StaffA], [StaffB], and [StaffC] Registry setting "Display Document Routing Status on Chart Items' has been set to "Y" Log in as [TestUser] Steps Select a client [TestClient] Open [TestFormA] Populate all the required and desired fields on the form Submit the form as "Final" Click [Accept and Rout] At the "Route to Document" screen In the "Supervisor" search field, select [StaffA] Click [Add] to add them to the list of approvers In the "Add Approver" search field, select [StaffB] Click [Add] to add them to the list of approvers In the "Add Members to Acknowledge" search field, select [StaffC] Click [Add] to add them to the list of approvers Click [Submit] Validate the form submits successfully Repeat step 1 for [TestformB] and [TestFormC] Validate results are as expected At the home view Select [TestClient] and right click to open their chart Select [TestFormA] on the left side panel Validate the row filed in step 1 is displayed Validate data is displayed as expected Scroll to the bottom of the document to the "Document Routing" section Validate the "Status" field is populated with "Pending" Validate the "Approvers" field contains [StaffA] with title "Supervisor (Pending)" [StaffB] with title "Staff (Pending)" Validate the "Acknowledgers" section contains [StaffC] (Pending Acknowledgment) Repeat step 4a selecting [TestFormB] on the left side panel Validate results are as expected Repeat step 4a selecting [TestFormC] on the left side panel Validate results are as expected Return to the home view, select [TestClient] Navigate to [WidgetA] and refresh the widget Validate the row filed in step 1 is present in the widget Click the [View] button Validate data for the row is displayed in the "Console Widget Viewer" as expected Scroll to the bottom of the document to the "Document Routing" section Validate the "Status" field is populated with "Pending" Validate the "Approvers" field contains [StaffA] with title "Supervisor (Pending)" [StaffB] with title "Staff (Pending)" Validate the "Acknowledgers" section contains [StaffC] (Pending Acknowledgment) Navigate to [WidgetB], refresh the widget and repeat step 4a for the widget Validate results are as expected Navigate to [WidgetC], refresh the widget and repeat step 4a for the widget Validate results are as expected Log out as [TestUser] Log in as [StaffA] Navigate to their "My To Do's" widget Click and approve the To Do for [TestFormA] Click and approve the To Do for [TestFormbB] Click and approve the To Do for [TestFormC] Log out as [StaffA] Log in as [StaffB] Repeat step 6 approving the To Do's Log out as [StaffB] Log in as [StaffC] Repeat step 6 approving the To Do's Log out as [StaffC] Log back in as [TestUser] At the home view Select [TestClient] and right click to open their chart Select [TestFormA] on the left side panel Validate the row filed in step 1 is displayed Validate data is displayed as expected Scroll to the bottom of the document to the "Document Routing" section Validate the "Status" field is populated with "Pending" Validate the "Approvers" field contains [StaffA] with title "Supervisor (Accepted)" [StaffB] with title "Staff (Accepted)" Validate the "Acknowledgers" section contains [StaffC] (Acknowledged) Return to the home view, select [TestClient] Navigate to [WidgetA] and refresh the widget Validate the row filed in step 1 is present in the widget Click the [View] button Validate data for the row is displayed in the "Console Widget Viewer" as expected Scroll to the bottom of the document to the "Document Routing" section Validate the "Status" field is populated with "Pending" Validate the "Approvers" field contains [StaffA] with title "Supervisor (Accepted)" [StaffB] with title "Staff (Accepted)" Validate the "Acknowledgers" section contains [StaffC] (Acknowledged) Navigate to [WidgetB], refresh the widget and repeat step 14a for the widget Validate results are as expected Navigate to [WidgetC], refresh the widget and repeat step 14a for the widget Validate results are as expected	Topics • My Clients • Document Management • Document Routing
Update 108 Summary \| Details Support for other products and modules Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: CareFabric Monitor GAIN Agency Configuration Scheduling Calendar Scenario 1: 'Admission' form - Validate the 'ProgramAdmissionCreated' payload Steps Access the 'Admission' form. Verify the 'Select Client' dialog is displayed. Enter any new value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [Search]. Validate a "Search Results" message is displayed stating: No matches found. Click [New Client]. Validate a "Client" message displays indicating "Auto Assign Next ID Number?" Click [Yes]. Enter a date prior to daylight savings time in the 'Preadmit/Admission Date' field (Ex. 03/10/2023). Enter "10:00 AM" in the 'Preadmit/Admission Time' field. Select the desired program in the 'Program' field. Enter any value in the 'Type Of Admission' field. Enter the desired practitioner in the 'Admitting Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter the client admitted in the previous steps in the 'Client ID' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' is displayed. Select the 'ProgramAdmissionCreated' activity type. Click [Click to View Record]. Validate all filed information is populated. Validate the 'admissionDate' field contains the 'Preadmit/Admission Date' and 'Preadmit/Admission Time' populated in the previous steps with the correct time zone offset prior to daylight savings time (Ex: 2023-03-01T10:00:00.000-05:00). Close the report and the form. Access the 'Admission' form. Verify the 'Select Client' dialog is displayed. Enter any new value in the 'Last Name' and 'First Name' fields. Select any value in the 'Sex' field. Click [Search]. Validate a "Search Results" message is displayed stating: No matches found. Click [New Client]. Validate a "Client" message displays indicating "Auto Assign Next ID Number?" Click [Yes]. Enter a date during daylight savings time in the 'Preadmit/Admission Date' field (Ex. 05/01/2023). Enter "10:00 AM" in the 'Preadmit/Admission Time' field. Select the desired program in the 'Program' field. Enter any value in the 'Type Of Admission' field. Enter the desired practitioner in the 'Admitting Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter the second client admitted in the previous steps in the 'Client ID' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' is displayed. Select the 'ProgramAdmissionCreated' activity type. Click [Click to View Record]. Validate all filed information is populated. Validate the 'admissionDate' field contains the 'Preadmit/Admission Date' and 'Preadmit/Admission Time' populated in the previous steps with the correct time zone offset during daylight savings time (Ex: 2023-05-01T10:00:00.000-04:00). Close the report and the form. Scenario 2: 'Discharge' form - Validate the 'ProgramDischargeCreated' payload Specific Setup: Two clients must be enrolled in existing episodes (Client A & Client B). Steps Select "Client A" and access the 'Discharge' form. Enter a date prior to daylight savings time in the 'Date Of Discharge' field (Ex. 03/10/2023). Enter "10:00 AM" in the 'Discharge Time' field. Select any value in the 'Type Of Discharge' field. Enter the desired practitioner in the 'Discharge Practitioner' field. Select the desired value in the 'Discharge Client Living Arrangement' field. Enter the desired value in the 'Hospital Discharge Instructions' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter "Client A" in the 'Client ID' field. Click [View Activity Log]. Select "ProgramDischargeCreated" in the 'Activity Type' field. Click [Click to View Record]. Validate all filed information is populated. Validate the 'dischargeDate' field contains the 'Date Of Discharge' and 'Discharge Time' populated in the previous steps with the correct time zone offset prior to daylight savings time (Ex: 2023-03-01T10:00:00.000-05:00). Close the report and the form. Select "Client B" and access the 'Discharge' form. Enter a date during daylight savings time in the 'Date Of Discharge' field (Ex. 05/01/2023). Enter "10:00 AM" in the 'Discharge Time' field. Select any value in the 'Type Of Discharge' field. Enter the desired practitioner in the 'Discharge Practitioner' field. Select the desired value in the 'Discharge Client Living Arrangement' field. Enter the desired value in the 'Hospital Discharge Instructions' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter "Client B" in the 'Client ID' field. Click [View Activity Log]. Select "ProgramDischargeCreated" in the 'Activity Type' field. Click [Click to View Record]. Validate all filed information is populated. Validate the 'dischargeDate' field contains the 'Date Of Discharge' and 'Discharge Time' populated in the previous steps with the correct time zone offset during daylight savings time (Ex: 2023-05-01T10:00:00.000-04:00). Close the report and the form. Scenario 3: Diagnosis - Validate the 'DiagnosisCreated' and 'DiagnosisUpdated' SDK events Specific Setup: A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access the 'Diagnosis' form. Select the desired value in the 'Type Of Diagnosis' field. Enter the desired date in the 'Date Of Diagnosis' field. Enter the desired time the 'Time Of Diagnosis' field. Click [New Row]. Select the desired value in the 'Diagnosis Search' field. Select "Active" in the 'Status' field. Select the desired practitioner in the 'Diagnosing Practitioner' field. Click [Submit]. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' and 'Through Date' fields. Select "Client A" in the 'Client ID' field. Select "DiagnosisCreated" in the 'Event/Action Search' field. Click [View Activity Log]. Validate the 'CareFabric Monitor Report' displays a 'DiagnosisCreated' record. Click [Click To View Record]. Validate the 'startDate' field contains the 'Date Of Diagnosis' and 'Time Of Diagnosis' populated in the previous steps. Validate the 'statusCode' - 'code' field contains "1". Validate the 'statusCode' - 'displayName' field contains "Active". Validate all other previously filed data displays as expected. Close the report and the form. Scenario 4: Create an appointment and validate the 'AppointmentCreated' SDK event is raised Specific Setup: A client is enrolled in an existing episode (Client A). Multiple practitioners are defined with hours for scheduling (Practitioner A, Practitioner B and Practitioner C). Steps Access the 'Scheduling Calendar' form. Right click in the 'Appointment Grid' and click [Add Appointment]. Set the 'Service Code' field to the desired service code. Set the 'Client' field to "Client A". Select the desired value in the 'Episode Number' field. Set the 'Practitioner' field to "Practitioner A". Select the desired location in the 'Location' field. Set the 'First Co-Practitioner' field to "Practitioner B". Set the 'Second Co-Practitioner' field to "Practitioner C". Fill out all required fields. Click [Submit]. Validate successful submission. Validate the scheduled appointment is added to the 'Scheduling Calendar' form. Access the 'CareFabric Monitor' form. Enter the current date in the 'From Date' field. Enter the current date in the 'Through Date' field. Enter "Client A" in the 'Client ID' field. Click [View Activity Log]. Select "AppointmentCreated" in the 'Activity Type' field. Click [Click to View Record]. Validate the 'appointmentID' - 'humanReadableValue' - 'id' field contains the scheduled appointment ID. Validate the 'scheduledProviderIDs' - 'humanReadableValue' - 'id' field contains the name and ID for the co-practitioners. Validate the 'scheduledProviderIDs' - 'humanReadableValue' - 'id' field contains the name and ID for "Practitioner A". Validate the 'scheduledProviderIDs' - 'humanReadableValue' - 'id' field contains the name and ID for "Practitioner B". Validate the 'scheduledProviderIDs' - 'humanReadableValue' - 'id' field contains the name and ID for "Practitioner C". Close the report and the form.	Topics • Admission • CareFabric Monitor • Discharge • Forms
Update 112 Summary \| Details System Security Defaults form - 'Outlook 365 Integration Configuration' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Display User Role System Security Defaults Microsoft Outlook Calendar Scenario 1: System Security Defaults - 'Outlook 365 Integration Configuration' setting validations Specific Setup: The "Microsoft Azure" cloud computing platform or similar platform has been setup by the client's system administrators to integrate with "Microsoft 365", to provide the "Microsoft Outlook" application to users "Microsoft Outlook 365" integration certificate values : "Client ID", "Client Secret" and "Tenant ID", have been generated by the client's system administration and provided to the logged in user Logged in user has access to form, "Registry Settings" and form "System Security Defaults" Steps Open form "Registry Settings" Search for registry setting "Enable Outlook 365 Integration" Entering a value of "Y" in the "Registry Settings Value" field will: Enables support for "Outlook 365 Integration" in the system Creates a new section in form "System Security Defaults", called "Outlook 365 Integration Configuration", where integration certificate values may be entered and submitted Entering a value of "N" in the "Registry Settings Value" field will: Disables support for "Outlook 365 Integration" in the system Removes section "Outlook 365 Integration Configuration" in form "System Security Defaults" Set the value in the "Registry Settings Value" field to a value other than "Y" or "N" Validate the error message "The selected value is not valid in the current system code for the following reason: Valid values are Y or N", is displayed Set the value in the "Registry Settings Value" field to "Y" Validate the value is accepted Submit the form Validate the form files successfully Click "Yes" to return to the form Search for registry setting "Enable Outlook 365 Integration" Validate the "Registry Setting Value" is set to "Y", as expected Close the form Open form "System Security Defaults" Validate a new section is displayed on the left side, called "Outlook 365 Integration Configuration" Click section "Outlook 365 Integration Configuration" Navigate to the "Client ID" field Attempt to enter a value greater than "50" characters Validate any characters entered over "50" characters does not display Enter any value up to "50" characters Validate all characters are displayed and accepted Enter the "Client ID" value provided, as noted in the setup Submit the form Validate an error is displayed 'The following fields are missing: "Client Secret" and "Tenant ID"' Click [OK] Navigate to the "Client Secret" field Attempt to enter a value greater than 50 characters Validate any characters entered over 50 characters do not display Enter a value up to 50 characters Validate all characters are displayed and accepted Enter the "Client Secret" value provided, as noted in the setup Navigate to the "Tenant ID" Attempt to enter a value greater than 50 characters Validate any characters entered over 50 characters do not display Enter a value up to 50 characters Validate all charters are displayed and accepted Enter the "Tenant ID" value provided, as noted in the setup Submit the form Validate submission is successful Return to the form "System Security Defaults" Select section "Outlook 365 Integration Configuration" Validate the values entered in the "Client ID", "Client Secret" and "Tenant ID" fields in step 2, are as expected Open form "Registry Settings" Search for registry setting "Enable Outlook 365 Integration" Entering a value of "N" in the "Registry Settings Value" field Submit the form Validate the form files successfully Return to the form "System Security Defaults" Validate the section "Outlook 365 Integration Configuration", is not longer present on the form as expected Open form "Registry Settings" Search for registry setting "Enable Outlook 365 Integration" Entering a value of "Y" in the "Registry Settings Value" field Submit the form Validate the form files successfully Return to the form "System Security Defaults" Validate the section "Outlook 365 Integration Configuration", is now present on the form again, as expected Scenario 2: Avatar NX - 'Outlook 365 Integration" - User set up and "My Calendar" widget validations Specific Setup: The "Microsoft Azure" cloud computing platform or similar platform, has been setup by the client's system administrators to integrate with "Microsoft 365" to provide the "Microsoft Outlook" application to users Registry setting '"Enable Outlook 365 Integration" has been set to "Y" to enable support for "Outlook 365" integration. [Note: this registry setting is introduced with "RADplus 2023 Update 112"] In form "System Security Defaults", in the "Outlook 365 Integration Configuration" section, the "Client ID", "Client Secret" and "Tenant ID" field values needed for integration provided by the Admin team, have been populated and the form has been submitted successfully [TestUser] has "Microsoft Outlook" installed on their desktop and has a "Microsoft Outlook" email account assigned to them [TestEmail] [TestUser] has an appointment or meeting [TestApptA], scheduled in their "Microsoft Outlook" on [TestDateA] [TestUser] is also a staff member and has a client appointment [TestApptB], already scheduled on [TestDateB], via form "Scheduling Calendar" in myAvatar [TestUser] has the "My Calendar" widget on their home view Log in as [TestUser] Steps At the home view, select the "User Menu" icon in the top right corner Click "Preferences" Click the "Calendar" tab and then click "Add Source" and From the "Select Source Type" drop down list, select "Microsoft Outlook" Click [Add] At the "Microsoft Sign In", dialog enter the email address [TestEmail] for the logged in user Click [Next] At the "Enter Password" prompt, enter the email login password Click [Sign in] Validate message "Successfully linked Microsoft Outlook account to email [TestUser]" Click [OK] Validate "Microsoft Outlook" is added in the source list box Validate the check box next to the source is checked Click [Save] Click 'Preferences' to return to the form Validate "Microsoft Outlook" is added in the source list box Validate the check box next to the source is checked Close the form At the home view, navigate to the "My Calendar" widget Click the "Refresh" button on the widget On the calendar, navigate to [TestDateA] Validate [TestApptA] scheduled in "Microsoft Outlook" is displayed on the calendar for that day On the calendar, navigate to [TestDateB] Validate [TestApptB], the appointment scheduled in form "Scheduling Calendar', is displayed on the calendar for that day In "Microsoft Outlook" Open the calendar and delete [TestApptA] In Avatar Open form "Scheduling Calendar" and delete [TestAppB] Refresh the "My Calendar" widget Validate [TestApptA] and [TestApptB] have been removed from the calendar In "Microsoft Outlook" Schedule a new meeting [TestMeeting] on a desired date [TestDateC] In Avatar Schedule a new appointment [TestApptD] on a desired date [TestDateD] At the home view, navigate to the "My Calendar" widget Click the "Refresh" button on the widget On the calendar, navigate to [TestDateC] Validate [TestMeeting] scheduled in "Microsoft Outlook" is displayed on the calendar for that day On the calendar, navigate to [TestDateD] Validate [TestApptD], the appointment scheduled in form "Scheduling Calendar', is displayed on the calendar for that day	Topics • User Role Definition • System Security Defaults • NX • My Calendar
Update 114 Summary \| Details New dictionary value named "Integrated Apps Admin" added in the field "Netsmart Mobile App Access". Internal Test Only	Topics n/a
Update 115 Summary \| Details DCI Import process Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Data Import (PM) Scenario 1: Data Import - validate functionality when errors occur Specific Setup: A data import file containing a "SQL Query Custom Search" field must exist for import (File A). Steps Access the 'Data Import' form. Click [Select Data Import File]. Validate a dialog stating: "Warning!! The file upload process may take a few minutes to process." and click [OK]. Select "File A" and click [Open]. Validate the 'Select Data Import File' button is disabled. Click [Validate Data Import File]. Validate a 'Confirm' dialog stating: "There are 1 or more errors within the file import." and click [OK]. Validate the error(s) display in the 'Errors and Warnings' field. Validate the error states: Option contains a "SQL Query - Custom Search" object which is not eligible for data import. Note: "SQL Query - Custom Search" fields will only be supported when coming from Avatar CareFabric. Validate the 'Validate Data Import File' and 'Process Data Import File' buttons are disabled. Click [Download Data Import Error/Warning File]. Validate the file downloads and the 'Download Data Import Error/Warning File' button is disabled. Close the form.	Topics • Data Import • NX
Update 116 Summary \| Details Rule Based Routing - Perceptive documents Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Routing Role Definition Routing Queue Definition Routing Status Definition Routing Role Assignment Routing Assignment Definition Routing Configuration Definition Routing Views Definition Routing Action Definition Rule Based Routing Routing Worklist Item Scenario 1: Validate 'Rule Based Routing' document routing functionality Specific Setup: Multiple users must be created with access to all forms: USER A, USER B, USER C, and USER D. A user modeled form must be imported that has 'Service Documentation' fields or a progress note form must be used. Document routing must be enabled for this form. The 'Rule Based Routing' widget must be added to the myDay view. Must create four roles in the 'Routing Role Definition' form. Must assign users with each of the roles created in the 'Routing Role Assignment' form. Must create queues and assign a form to them in the 'Routing Queue Definition' form (Queue 1, Queue 2, and Queue 3). Must create statuses associated with each queue in the 'Routing Status Definition' form. Must configure each queue in the 'Routing Assignment Definition' form. Must select a form in the 'Routing Configuration Definition' form (For example Ambulatory Progress Notes). Must configure header fields and worklist widget details for each queue in the 'Routing Views Definition' form. Must have specific actions configured to route documents to subsequent queues in the 'Routing Action Definition' form. Must be signed in as User A. Steps Select any desired client (Client A) and access the 'Ambulatory Progress Notes' form. Select any value in the 'Progress Note For' field. Select any value in the 'Note Type' field. Populate all required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit] and [Sign and Route/Notify]. Input password associated with "User A" and click [Verify]. Select the practitioner associated with "User A" in the 'Approver' field. Click [Add] and [Submit]. Navigate to the 'My To-Do's' widget. Validate the document filed is in the 'Documents to Sign' column. Click [Review]. Validate the document opens. Click [Accept] and [Sign]. Enter the password associated with "User A" and click [Verify]. Logout. Login with "User B". Navigate to the 'Rule Based Routing' widget. Select "Queue 1" in the queue field. Select the entry associated with "Client A". Click [Launch Worklist Item]. Fill out the desired and required fields. Click [Save for Later]. Validate the entry is now "In Process" in the 'Status' field. Select the item again and click [Launch Worklist Item]. Click [Submit]. Refresh the 'Rule Based Routing' widget. Validate the entry is no longer present. Logout. Login with "User C". Navigate to the 'Rule Based Routing' widget. Select "Queue 2" in the queue field. Select the entry associated with "Client A". Click [Launch Worklist Item]. Fill out the desired and required fields. Click [Submit]. Refresh the 'Rule Based Routing' widget. Validate the entry is no longer present. Logout. Login with "User D". Navigate to the 'Rule Based Routing' widget. Select "Queue 3" in the queue field. Select the entry associated with "Client A". Click [Launch Worklist Item]. Fill out the desired and required fields. Click [Submit]. Refresh the 'Rule Based Routing' widget. Validate the entry is now "Completed" in the 'Status' field. Logout.	Topics • Document Routing • Rule Based Routing
Update 117 Summary \| Details Service Documentation Corrections - Delete Service Documentation Row Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Service Documentation Corrections Scenario 1: Service Documentation Corrections - Delete Service Documentation Row Specific Setup: A modeled form configured for 'Service Documentation' is defined (Form A). Document routing is enabled for "Form A". A client is enrolled in an existing episode (Client A). Steps Select "Client A" and access "Form A". Select "New Service" in the 'Data Row For' field. Enter the desired date in the 'Date' field. Enter the desired time in the 'Start Time' and 'End Time' fields. Populate all other required and desired fields. Select "Final" in the 'Draft/Final' field. Click [Submit]. Validate a 'Confirm Document' dialog is displayed. Click [Accept]. Enter the password for the logged in user and click [OK]. Access the 'Clinical Document Viewer' form. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the 'Document List' displays the document filed via "Form A" with a 'Document Status' of "Final". View the document and validate the data displays as expected. Click [Close All Documents]. Validate the document is no longer displayed. Close the form. Access the 'Client Ledger' form. Select "Client A" in the 'Client ID' field. Select "All Episodes" in the 'Claim/Episode/All Episodes' field. Select "Simple" in the 'Ledger Type' field. Select "Yes" in the 'Include Zero Charges' field. Click [Process]. Validate the 'Client Ledger' report is displayed and contains the service filed via "Form A". Close the form. Access the 'Service Documentation Corrections' form. Select "Form A" in the 'Form' field. Select "Client A" in the 'Client ID' field. Select the corresponding episode in the 'Episode Number' field. Click [Select Row to Correct]. Select the service filed in the previous steps in the 'Select Row To Correct' dialog and click [OK]. Select "Delete Service Documentation Row" in the 'Correction Action' field. Validate a message is displayed stating: PLEASE NOTE: Once the data has been deleted, it cannot be recovered. Are you sure you wish to continue? Click [OK]. Enter the desired value in the 'Comments' field. Select "Yes" in the 'Delete Service' field. Click [Submit] and [No] to close the form. Access the 'Clinical Document Viewer' form. Select "Individual" in the 'Select All or Individual Client' field. Select "Client A" in the 'Select Client' field. Click [Process]. Validate the 'Document List' displays the document filed via "Form A" with a 'Document Status' of "Void" since the service documentation row has now been deleted. Close the form. Access the 'Client Ledger' form. Select "Client A" in the 'Client ID' field. Select "All Episodes" in the 'Claim/Episode/All Episodes' field. Select "Simple" in the 'Ledger Type' field. Select "Yes" in the 'Include Zero Charges' field. Click [Process]. Validate the 'Client Ledger' report is displayed and does not contain the deleted service. Close the form. Form Designer - 'Section Name' field Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (PM) Form Designer (CWS) Modeled form with Default Dictionary Values Scenario 1: Form Designer - Validate changes to the 'Section Name' field Specific Setup: Please note: this is for Avatar NX systems. Steps Access the 'Form Designer' PM form. Select "Admission" in the 'Forms' field. Select "(Demographics)" in the 'Sections' field. Validate the 'Section Name' field contains "Demographics". Enter "Demographics Test" in the 'Section Name' field. Click [Submit]. Access the 'Form Designer' PM form. Select "Admission" in the 'Forms' field. Select "Demographics Test (Demographics)" in the 'Sections' field. Validate the 'Section Name' field contains "Demographics Test". Close the form. Select any existing client and access the 'Admission' form. Select any existing episode and click [Edit]. Validate the 'Demographics Test' section displays as expected. Close the form. Access the 'Form Designer' PM form. Select "Admission" in the 'Forms' field. Select "Demographics Test (Demographics)" in the 'Sections' field. Validate the 'Section Name' field contains "Demographics Test". Enter "Demographics" in the 'Section Name' field. Click [Submit]. Access the 'Form Designer' PM form. Select "Admission" in the 'Forms' field. Select "(Demographics)" in the 'Sections' field. Validate the 'Section Name' field contains "Demographics". Close the form. Select any existing client and access the 'Admission' form. Select any existing episode and click [Edit]. Validate the 'Demographics' section displays as expected. Close the form. Form Designer - 'Export Form Designer Copy' button Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Form Designer (CWS) Form Designer (PM) Modeled form with Default Dictionary Values Scenario 1: Form Designer - Validate the 'Export Form Designer Copy' button is disabled when there are no changes to export Specific Setup: Please note: this is for Avatar NX systems. Must have a form that does not have any 'Form Designer' changes (Form A). Steps Access the 'Form Designer' form. Select "Form A" in the 'Forms' field. Select the desired section in the 'Sections' field. Validate the 'Export Form Designer Copy' button is disabled since there are no 'Form Designer' changes to export. Click [Show Section]. Make any desired changes and click [Save]. Validate a "Save layout?" dialog is displayed stating: Are you sure you wish to save your changes? Click [Yes]. Validate a message is displayed stating: Form saved. Click [OK]. Submit the form. Access the 'Form Designer' form. Select "Form A" in the 'Forms' field. Validate the 'Export Form Designer Copy' button is now enabled since 'Form Designer' changes are present. Click [Export Form Designer Copy]. Validate a message is displayed stating: Export Complete. Click [OK] and close the form.	Topics • Service Documentation • Form Designer • NX
Update 120 Summary \| Details Widget Wizard - widgets Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: WidgetWizardEnhancedWidget Scenario 1: "Widget Wizard" - Validate "Enhanced Widget View" column sorting/filtering/resizing and form launch functionality Specific Setup: In form "Widget Wizard" have a widget defined [TestWidget] with the 'Enhanced Widget View' field set to "Yes" Have a field selected in prompt "Associate Which Field to Link" (for example, the "Episode" field) to be used as a hyperlink to launch a form [TestForm] Have [TestWidget] placed on the logged in users home view Steps Click to "Refresh" [TestWidget] Validate all column data is displayed, as expected Validate a "Search:' filter box is displayed at the top of the widget [This is for Avatar NX only] In the 'Search" filter box, enter a search to filter on any data displayed in any of the columns For example, a "Data Entry Date" column exists with two client rows with same date displayed In the "Search" box, enter that date Validate the two expected client rows, are displayed in the widget results Clear the "Search" filter box Validate all data is displayed again in the widget, as expected Click to "Refresh" [TestWidget] Validate all data is displayed in the widget, as expected Validate there is a "Search" box in each column under their respective column name header Select any column [TestColumnA] in the widget In the search box below the column name, enter a search criteria to filter the data Validate the list is filtered and displays as expected based on the search criteria In any of rows returned via the search, click the hyperlink to launch [TestForm], which was configured in the setup Validate [TestForm] is launched successfully, as expected Close or submit the form Validate the search criteria is still entered in "Search" field for [TestColumnA] and the widget still displays only rows based on the search criteria entered Clear the search criteria in the "Search" box Validate all columns display all their data again, as expected Navigate to any desired column [TestColumnA], in the widget Click column header name once Validate the "Up" arrow icon is highlighted and data in the column is sorted in ascending order Click column header a second time Validate the "Down" arrow icon is highlighted and data in the column is sorted in descending order Click column header a third time Validate the "Up" and "Down" arrows are no longer highlighted and data is no longer sorted in the column Press and hold down the "Shift" key while doing the following: Click the column name for [TestColumnA] name once and then the column name for [TestColumnB] twice Validate widget data results are sorted by [TestColumnA] in ascending order and then by [TestColumnB] in descending order, as expected Click the line between [TestColumnA]and [TestColumnB] and drag the line to the right, in order to increase the size of [TestColumnA] Validate the width of [TestColumnA] is increased as expected Click the line between [TestColumnA] and [TestColumnB] and drag the line to the left, in order to reduce the size of [TestColumnA] Validate the width of [TestColumnA] is reduced, as expected	Topics • Widgets
Update 126 Summary \| Details 'Form and Table Documentation' form Scenario 1: "Form and Table Documentation" form (Modeled Forms) - Validate "Generate Form Map' report results Specific Setup: Have a "Modeled" form that contains event logic defined on the form [FormA]. Make a note or all the fields on the form. Make a note of the event logic defined on the form. Have a "Modeled" form that does 'not' contain event logic defined on the form [FormB] Make a note or all the fields on the form Have access to form "Form and Table Documentation" Steps Open 'Form and Table Documentation'. Set 'Type of Documentation' to 'Form'. Select "Individual" in the "Individual or All Forms" field Select [FormA] from the 'Form to be Documented' field. (Modeled form with event logic defined) Navigate to the "Generate Form Map" button and click to launch the w Validate the user is presented with a file explorer dialog [Note: In Avatar NX the file will automatically be created and saved in the windows "Downloads" directory on the server] Validate the (.htm) type file name field is populated in the file name field Validate the file name includes the associated internal "FormID' for [FormA], followed by its form "Name". For example: "NetsmartFormMap_USER9_Modeled Form with Event logic" Select a folder location to save the file and click [Save] Navigate to the location of the (.htm) file Click to open the file Validate the title of the report reflects the name of [FormA] and its associated internal "FormID" Validate each "Section" name is displayed on the form as expected with each field contained in that section listed beneath it Validate the field names contain both the name and its associated field number in brackets, for example "Date of Entry (777.77)" Locate a field on the form that contains event logic defined Validate the event logic noted in the setup is displayed as expected. For example: Date of Entry(777.77) Type of Event: Result of Input With Value Checking Compare with For Event: Specific Value Specific Value: 12/06/2022 Relationship To Comparison Value to Trigger Event: Less Than Set Specific Objects to Required on Event: Yes Required: Integer (FormA_Integerfield) Close the page Select [FormB] from the 'Form to be Documented' field. (Modeled form with 'no' event logic defined) Repeat steps 1a thru 1e Validate results are as expected Close the form Scenario 2: "Form and Table Documentation" form (Product Forms) - Validate "Generate Form Map' report results Specific Setup: Have a "Product" form that is available to be configured for site specific section modeling in form "Site Specific Section" modeling and contains event logic defined on the form [FormA]. For example form "Update Client Data" Make a note or all the fields on the form. Make a note of the event logic defined on the form Have a "Product" form that is available to be configured for site specific section modeling in form "Site Specific Section" modeling and does 'not' have event logic defined on the form [FormB]. For example form "Client Charge Input" Make a note or all the fields on the form Have a "Product" form that is 'not' available to be configured for site specific section modeling in form "Site Specific Section" modeling [FormC]. For example, the "Billed Charges" form' Have access to form "Form and Table Documentation" Steps Open 'Form and Table Documentation'. Set 'Type of Documentation' to 'Form'. Select "Individual" in the "Individual or All Forms" field Select [FormA] from the 'Form to be Documented' field. (A 'Product' form that can be configured with site-specific section modeling and contains event logic defined) Navigate to the "Generate Form Map" button and click to launch the report Validate the user is presented with a file explorer dialog. [Note: In Avatar NX, the file will automatically be created and saved in the windows "Downloads" directory on the server] Validate the (.htm) type file name field is populated in the file name field Validate the file name includes the associated internal "FormID" for [FormA], followed by its form "Name". For example: "NetsmartFormMap_PATIENT14_Update Client Data.htm" Select a folder location to save the file and click [Save] Navigate to the location of the (.htm) file Click to open the file Validate the title on the page reflects the name of [FormA] and its associated internal "FormID". For example, "Update Client Data (PATIENT14)" Validate each "Section" name is displayed on the form as expected, with each field contained in that section listed beneath it. Validate the field names contain both the name and its associated field number in brackets, for example "Date of Citizenship (631.1)" Locate a field on the form that contains event logic defined Validate the event logic noted in the setup is displayed as expected. For example: Date of Citizenship (631.1) Type of Event: Valid Entry Prompts To Be Disabled: Gender Identity (730) Close the page Select [FormB] from the 'Form to be Documented' field. (A 'Product' form that can be configured with site-specific section modeling and does 'not' contain event logic) Repeat steps 1a thru 1c Validate results are as expected Close the form Open 'Form and Table Documentation'. Set 'Type of Documentation' to 'Form'. Select "Individual" in the "Individual or All Forms" field Select [FormC] from the 'Form to be Documented' field. (The 'Product' form that can 'not' be configured with site-specific section modeling) Validate "Generate Form Map" button is not present on the form as expected	Topics • Modeling • Forms
Update 131 Summary \| Details Issue resolved where users were unable to log into Med Note due to blank Organization email address in User Definition Scenario 1: SOAP UI - Med Note errors for users who had the User Management web service submitted with a blank email address Steps Internal testing only	Topics • User Definition
Update 138 Summary \| Details Progress Notes - Widget Scenario 1: Progress Notes (Product) Widget - Validate data display and formatting Specific Setup: Have a client [TestClient] with a row of data in submitted in each of the product progress note forms: "Ambulatory Progress Notes", "Ambulatory Progress Notes(Diagnosis Entry)", "Inpatient Progress Notes", "Inpatient Progress Notes(Diagnosis Entry)", "Progress Notes (Group and Individual)" and a copy of the "Progress Notes (Group and Individual)" [TestUser] also has product "Progress Notes Widget" on their home view an in their "Chart" view Steps At Home View, select [TestClient] Navigate to the "Progress Notes" widget Scroll down to row submitted for the "Progress Notes (Group and Individual)" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, are displayed with the same indentation Scroll down to row submitted for the copy of the "Progress Notes (Group and Individual)" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, are displayed with the same Scroll down to row submitted for the "Ambulatory Progress Notes" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, contain the same indentation Scroll down to row submitted for the "Ambulatory Progress Notes (Diagnosis Entry)" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, contain the same indentation Scroll down to row submitted for the "Inpatient Progress Notes" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, contain the same indentation Scroll down to row submitted for the "Inpatient Progress Notes (Diagnosis Entry)" form Validate all field data is populated, as expected Validate the following data formatting: Validate the "Form" name heading is left justified with no indentation Validate all the "Field" names listed under the heading, are displayed with the same indentation At Home View, select [TestClient] and click to open their "Chart" view Navigate to the "Progress Notes" widget in the view Repeat step 1a for each of the forms in that step Validate results are as expected	Topics • Progress Notes
Update 139 Summary \| Details Document Routing - Document Image Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: ModeledForm (w/Doc routing Crystal Report Template) Scenario 1: "Document Routing" - Document display validations Specific Setup: Have two users for testing [TestUserA] and [TestUserB]. Both users have the "My To Do's" widget on their home view. Have two forms enabled for document routing: [TestFormA] is enabled in form "Document Routing Setup" with "User Crystal Report Template" set to "Y" and report selected in the "Crystal Report" field. [TestFormB] is not enabled to use a crystal report template. Log in as [TestUserA]. Steps Access [TestFormA]: Populate all desired fields on the form. Select "Final" in the 'Draft/Final' field. Click "OK". Click [Submit]. In the "Confirm Document" screen: Verify document is displayed in the expected the "Crystal Report" template format. Validate all data is populated as expected. Click [Accept and Route]. Enter the user's password in the 'Password' field. Click [OK]. In the "Route Document To" screen, select [TestUserB] as an approver. Click [Submit]. Validate the form submits successfully. Log out as [TestUserA]. Log in as [TestUserB]. Navigate to the 'My To Do's' widget: Locate the document in the "My To Do's" widget for [TestFormA]: Click [Approve Document]. In the "Confirm Document" screen: Verify document is displayed in the expected "Crystal Report" template format. Validate all data is populated as expected. Click [Accept]. Validate the "To Do" accepted successfully and is removed from the 'My To Do's' widget. Access [TestFormB]: Populate all desired fields on the form. Select "Final" in the 'Draft/Final' field. Click "OK". Click [Submit]. In the "Confirm Document" screen: Verify document is displayed in the expected as a standard "TIF" image, not in a "Crystal Report" 'PDF' template format. Validate all data is populated as expected. Click [Accept and Route]. Enter the user's password in the 'Password' field. Click [OK]. In the "Route Document To" screen, select [TestUserA] as an approver. Click [Submit]. Validate the form submits successfully. Log out as [TestUserB]. Log in as [TestUserA]. Navigate to the 'My To Do's' widget. Locate the document in the "My To Do's" widget for [TestFormB]: Click [Approve Document]. In the "Confirm Document" screen: Verify document is displayed in the expected as a standard "TIF" image, not in a "Crystal Report" 'PDF' template format. Validate all data is populated as expected. Click [Accept]. Validate the "To Do" accepted successfully and is removed from the 'My To Do's' widget. Approver Override - document image Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Approver Override Scenario 1: "Approver Override" form - Validate Document display and functionality Specific Setup: Have two users who are staff members [StaffA] and [StaffB]. Have two forms enabled for document routing [FormA] and [FormB] and both use form type, [TypeA]. [ClientA] has two document rows [DocRow1] and [DocRow2] submitted in [FormA] that has been routed to [StaffB] for approval. [ClientB] has two document rows [DocRow1] and [DocRow2] submitted in [FormB] that has been routed to [StaffB] for approval. [StaffA] has the "My To Do's" widget on their home view. Log in as [StaffA]. Steps Open form "Approver Override": In the "Form Type" field choose In the "Entity" field, select [TypeA]. In the "Entity" field select [ClientA]: Populate the "From" and "To", date fields. Click the "List of Documents" field: Validate both [DocRow1] and [DocRow2] are displayed as expected. Select [DocRow1]: Click [Display Document] to view the document: Validate the "Confirm Document" screen displays document data for [ClientA], [DocRow1], as expected. Click [Close]. Click the "List of Documents" field: Select [DocRow2]. Click [Display Document] to view the document: Validate the "Confirm Document" screen displays document data for [ClientA], [DocRow2], as expected. Click [Close]. In the "Entity" field select [ClientB]: Populate the "From" and "To", date fields. Click the "List of Documents" field. Validate both [DocRow1] and [DocRow2] are displayed as expected. Select [DocRow1]: Click [Display Document] to view the document: Validate the "Confirm Document" screen displays document data for [ClientB], [DocRow1], as expected. Click [Close] Click the "List of Documents" field Select [DocRow2] Click [Display Document] to view the document Validate the "Confirm Document" screen displays document data for [ClientB], [DocRow2], as expected Click [Update Approvers] In the "Route Document To" screen, uncheck the current selected approver In the "Add Approver" field, select [StaffA] Click [Submit] Navigate to the "My To Do's" widget, and locate the row with the To Do sent in step 1d Click [Approve Document] Validate the "Confirm Document" screen displays document data for [ClientB], [DocRow2], as expected Click [Accept] Populate the "Verify Password" prompt Click [OK] Validate the "To Do" is removed from the "My To Do's" My To Do's widget - Approval comments Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Add Non-User Signature (PM) Scenario 1: 'My To Dos' Widget - Validate display of "Approval Comments" and "DocR.Comments" table data Specific Setup: Have a testing system that is accessible via "myAvatar" and/or "Avatar NX". Enable document routing for any form [TestForm] in form "Document Routing Setup": Set prompt 'Allow Comments During Approval' to 'Yes' for the form. Have three users, [StaffA], [StaffB] and [StaffC]. Each user has the "My To Do's" widget on their home view. Have report that will display data in the "SYSTEM.DocR.comments" table. Steps Log in as [StaffA] via "AvatarNX" (if applicable). Launch [TestForm] for any client: Populate all desired fields on the form. Submit the form as "Final". At the "Route To" dialog. Add [StaffA] as an approver. Submit the document [DocA] to be routed. Validate submission is successful. Repeat step 2, for [StaffB] and routing [DocB]. Repeat step 2, for [StaffC] and routing [DocC]. Navigate to the "My To Do's" widget: In the "Documents to Sign" column, validate the To Do for [DocA] is present in the widget as expected Click to review the To Do. Validate the document contents are as expected. Click to "Accept" the documents. In the "Approval Comments" field, enter desired comments [DocAComments] for [DocA] Click [Sign]: Validate the To Do is approved successfully. Log out a [StaffA]. Log in as [StaffB] via "myAvatar". Navigate to the "My To Do's" widget: Click the "All" or "New" tab in the widget: Validate a row is present for the [DocB] as expected. Click "Approve Document" link in the "Action" column of the row In the document preview screen, validate the document contents are as expected. Click to "Accept". In the "Approval Comments" dialog, enter desired comments [DocBComments] for [DocA]. Click [OK]. Validate the To Do is approved successfully. Log out as [StaffB]. Log in as [StaffC] via "myAvatar". Navigate to the "My To Do's" widget: Click the "Sign" tab in the widget. In the "Search Documents" section, validate a row is present for [DocC] as expected: Click to select that row. In the "Document Preview", validate the document contents are as expected. Click "Accept". In the "Approval Comments" dialog, enter desired comments [DocCComments] for [DocC]. Click [OK]. In the "Accepted Documents" section. Click [Sign All]. Validate the To Do is approved successfully. Generate the report for the "SYSTEM.DocR.comments" table. Locate the row for [StaffA]: Validate the "Approved Comment" column is populated with the comments [DocAComments], entered in step 7. Locate the row for [StaffB]: Validate the "Approved Comment" column is populated with the comments [DocBComments], entered in step 8. Locate the row for [StaffC]: Validate the "Approved Comment" column is populated with the comments [DocCComments], entered in step 9.	Topics • Document Routing • NX • Document Management • My To Do's
Update 141 Summary \| Details Product Updates Scenario 1: Validate accessabilty to the "Product Updates" form based on system configuration Steps Internal Testing Only	Topics • Update Install
Update 142 Summary \| Details User Role Definition - 'My Forms' Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following: Change User Role ID User Role Definition Scenario 1: User Role Definition - 'My Forms' section validations Specific Setup: Two users must exist for testing (User A & User B). Steps Login as "User A". Access the 'User Role Definition' form. Create a new user role. Populate all required and desired fields. Select the "My Forms" section. Add the desired forms. Click [Submit] and close the form. Access the 'Change User Role ID' form. Select the user role created in the previous steps from the 'User Role' field. Validate the 'Current User Role ID' field contains the user role ID defined in the previous steps. Enter any new value in the 'New User Role ID' field. Click [Submit] and close the form. Access the 'User Role Definition' form. Click [Select User Role]. Select the user role ID updated in the previous steps. Select the "My Forms" section. Validate all previously selected forms are displayed. Close the form. Access the 'User Definition' form. Select "User B" in the 'Select User' field. Select "Yes" in the 'Associate User with User Role' field. Select "No" in the 'Allow User Role Customization' field. Select the user role created in the previous steps in the 'User Role(s)' field. Click [Submit] and close the form. Logout. Login as "User B". For myAvatar users - Validate the 'My Forms' list in the 'Forms & Data' widget contains the forms selected in the "My Forms" section of 'User Role Definition'. For myAvatar NX users - Validate the 'My Favorites' list contains the forms selected in the "My Forms" Section of 'User Role Definition'.	Topics • Change User Role Id • User Role Definition • User Definition

RADplus_2023_Quarterly_Release_2023.04_Details.csv