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
- Clinical Document Viewer
- 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 - 'Pending eSignatures' widget
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
- Clinical Document Viewer
- View Definition
- Pending eSignatures
- Ambulatory Progress Notes
- Treatment Plan
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.
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
- Clinical Document Viewer
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.
Integrated eSignature - Append Documents
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
- Clinical Document Viewer
- Ambulatory Progress Notes
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.
|
Topics
• NX
• Integrated eSignature
• Registry Settings
• Perceptive
• Move Selected Data
• Clinical Document Viewer
• Progress Notes
• Add Non-User Signature
• Treatment Plan
|
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
|
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
|
"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
|
Tabular Data Editor - grids
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
- Treatment Plan
- 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
|
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
|
View Definition - "View Type"
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
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
|
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
|
Dictionary Import - values
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
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
|
My To Do's Widget- to do approval
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
- HomeView - My To Do's widget
- Clinical Document Viewer
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
|
Modeled forms - table aliasing
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
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
|
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
|
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
|
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
- Document Capture Window
- Clinical Document Viewer
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
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
- Document Capture Window
- Clinical Document Viewer
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
- Document Capture Window
- Clinical Document Viewer
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
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
|
Envelope Import - UTC data entry fields
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
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
|
| |
