Skip to main content

RADplus 2022 Update 39

Product Requirements / Recommendations

RADplus required

Recommended Update Level

RADplus 2021 Update 125
RADplus 2021 Update 129

Product Update Form Description

The following issues are resolved: [ILLEGAL VALUE]FileSubData+17^GUIRADplusUser during User File Import in systems where the Supplemental information form section is enabled and 'Date of Hire' or 'Date of Birth' is completed for some of the Avatar Users in the import file. The message 'Date of Service must be answered before this field can be accessed.' is incorrectly given for User Modeled forms where the primary table has Service Documentation enabled, but Service Documentation is not in use on the form. An issue where a consumer's Age in the Client Header may change when entering episode based forms versus non-episode based forms is resolved; following RADplus2018 #115, Age is calculated to stop at any Date of Death entered to the SYSTEM.discharge_data_other table via the "Discharge" form.

Included Updates

18

Required Updates

None

Details

NEW0 CHANGED0 FIXED3
Fixed (3)
User File Import
An error is resolved that could occur when a user included in the import file, has the 'Date of Hire' or 'Date of Birth' fields populated and filed in the "Supplemental" information section of form "User Definition"
Topics
• File Import • NX
 
Service Documentation - modeled form
An issue is resolved to ensure that the validation message 'Date of Service must be answered before this field can be accessed.' does not display when the Modeled forms primary table is enabled for "Service Documentation" and has fields mapped to be used for service documentation, but the fields are not actually used in the form
Topics
• 835 • 835 Health Care Claim Payment/Advice • 837 Institutional • 837 Professional • About... • Accounts Receivable Management • Accu-Chek • NX • Service Documentation
 
Client Header- client "Age" value
An issue is resolved to ensure that when the clients "Date of Death" is used to calculate a clients age, that the client header displays the calculated age accurately whether a user enters an 'Episodic' or a "Non Episodic" form
Topics
• Client Banner • Discharge • NX
 
Acceptance Tests

AV-78066 Summary | Details
User File Import
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • User Definition
  • User File Import
Scenario 1: Verify 'User File Import'
Specific Setup:
  • Have a system with prompt "Include Supplemental Information within User Definition" to "Yes" in form "System security defaults"
  • In form "User Definition" have an existing user [UserA] who is assigned to a user role [RoleA] and has "Date of Hire" and "Date of Birth" prompts populated on the "Supplemental" section of the form.
  • Have a "User File Import" file created [UserFileA] that includes:
  • [UserA] set with a different user role [RoleB] to be updated in the "User Role" field
  • A new user [UserB], with the "User Role" field populated with any valid user role. For this test [RoleA] is used
Steps
  1. Open the 'User File Import' form.
  2. Click [Select User Import File]
  3. Navigate to the location of [UserFileA] and select the file
  4. Click [Open].
  5. Validate the scan results display messages, "Warning: Row 1 contains an existing User ID which will be edited on import (UserA)" and "Warnings but no errors detected in import file. Import may proceed"
  6. Click [Process User Import File]
  7. Validate there are no errors
  8. Click [OK].
  9. Validate the import completes successfully
  10. Open form "User Definition"
  11. Select [UserA] in the "Select User" field
  12. Validate the user is not assigned to user role [RoleB], as expected
  13. Click "Supplemental" section of the form
  14. Validate "Date of Hire" and "Date of Birth" prompts are populated, as expected
  15. Select [UserB] in the "Select User" field
  16. Validate the user is assigned to user role [RoleA], as expected

Topics
• File Import • NX
AV-78625 Summary | Details
Service Documentation - modeled form
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • Modeled Form With Service Documentation
  • Modeled 'Service Documentation' Forms - Field Validations (w/Service Doc prompts removed from form)
Scenario 1: Modeled 'Service Documentation' Forms - Field Validations
Specific Setup:
  • Have a Modeled [TableA] which is includes:
  • Fields added that will be mapped in the "Service Documentation" section of "Table Definition" that required for service documentation functionality. These include: "Data Row for", "Date of Service", "Service Start Time", "Service End Time", "Service Duration", "Location" "Service Program", "Service Charge". "Service Practitioner" and "Draft/Final" fields
  • Any other desired added that are "not" mapped for service documentation functionality
  • [FormA] contains both the fields that are mapped for "Service Documentation" and also those are not
Steps
  1. Select [ClientA]
  2. Open [FormA]
  3. Set the "Documentation For" field to "New Service
  4. Set the "Draft/Final" field to "Final"
  5. Validate a message is displayed indicating there are required fields on the form that are not populated and the fields are listed
  6. Click [OK]
  7. Validate the "Draft/Final" field is set back to "Draft"
  8. Select a program in the "Service Program" field
  9. Select a service code in the "Service Charge Code" field
  10. Select a location in the "Service Location" field
  11. Select a practitioner in the "Service Practitioner" field
  12. Set the "Service Start Time" to the current time
  13. Set the "Service End Time" to a time prior to the current time
  14. Set the "Service Duration(Minutes) field to "30""
  15. Set the "Draft/Final" field to "Final"
  16. Validate a message is displayed indicating the required field "Date of Service" is not populated
  17. Click [OK]
  18. Validate the "Draft/Final" field is set back to "Draft"
  19. Populate the "Date of Service" field
  20. Set the "Draft/Final" field to "Final"
  21. Validate an error is displayed indicating that the service end time must be after the service start time
  22. Click [OK]
  23. Validate the "Draft/Final" field is set back to "Draft"
  24. Set the "Service Start Time" to one hour earlier than the current time
  25. Set the "Service End Time" to the current time
  26. Set the "Draft/Final" field to final
  27. Validate an error is displayed indicating that time between the service start date and end date is "60" minutes but the "Service Duration(Minutes) field to set to "30"
  28. Click [OK]
  29. Validate the "Draft/Final" field is set back to "Draft"
  30. Set the "Service Duration(Minutes)" field to "60"
  31. Set the "Draft/Final" field to "Final"
  32. At the "Confirm" dialog, click [OK]
  33. Click [Submit]
  34. Validate the form files successfully
  35. Return to [FormA] and select [ClientA]
  36. Edit the row just submitted
  37. Validate all fields are populated, as expected
Scenario 2: Modeled 'Service Documentation' Forms - Field Validations (w/Service Doc prompts removed from form)
Specific Setup:
  • Have a Modeled [TableA] which is includes:
  • Fields added that will be mapped in the "Service Documentation" section of "Table Definition" that required for service documentation functionality. These include: "Data Row for", "Date of Service", "Service Start Time", "Service End Time", "Service Duration", "Location" "Service Program", "Service Charge". "Service Practitioner" and "Draft/Final" fields
  • Any other desired fields that are "not" mapped for service documentation functionality. For this test a "Date", "Scrolling Text", "Picture" and "Dictionary" fields are used.
  • Have one of the fields set to be required, for the test the "Dictionary" field is set to be required.
  • [FormA] contains [TableA] but "only" contains the fields that are "not" mapped for service documentation on the form
Steps
  1. Select [ClientA]
  2. Open [FormA]
  3. Populate just the "Date" field
  4. Set the "Draft/Final" field to "Final"
  5. Validate a message indicating "Dictionary" field is required and is not populated
  6. Click [OK]
  7. Validate the "Draft/Final" field is set back to "Draft"
  8. Populate the "Scrolling Text" field
  9. Populate the "Client Picture" field
  10. Set the "Draft/Final" field to "Final"
  11. Validate a message indicating "Dictionary" field is required and is not populated
  12. Click [OK]
  13. Validate the "Draft/Final" field is set back to "Draft"
  14. Populate the "Dictionary" field
  15. Set the "Draft/Final" field to "Final"
  16. Validate there are no messages
  17. Click [Submit]
  18. Validate the form files successfully
  19. Return to [FormA] and select [ClientA]
  20. Edit the row just submitted
  21. Validate all fields are populated, as expected

Topics
• 835 • 835 Health Care Claim Payment/Advice • 837 Institutional • 837 Professional • About... • Accounts Receivable Management • Accu-Chek • NX • Service Documentation
AV-79774 Summary | Details
Client Header- client "Age" value
Note - These testing guidelines assume the user is skilled in the use of, at a minimum, the following:
  • App Dashboard
  • Discharge
  • Update Client Data
Scenario 1: "Client Header" validation
Specific Setup:
  • Have a testing client [ClientA] with two episodes.
  • Episode "1" is an open episode
  • Episode "2" is a discharged episode
  • Have Registry Setting "Add Date of Death and Reason for Death to Discharge" Set this to "Yes"
  • In PM "Dictionary Update", select the "Client" database and search for dictionary "970"(Type of Discharge)
  • Edit dictionary code "3 (Death)" and click to the extended attribute section
  • In the "Extended Dictionary Element" field, select "Discharge Due to Death?" and ensure its set to "Yes"
  • In form "Client Lookup/Header Configuration" go to the "Client Header" section:
  • Have fields "Location", "Attending Practitioner", "Admitting Practitioner" included as part of the Client Header.
Steps
  1. Select [ClientA]
  2. Open the " Discharge" form and select the discharged Episode "2"
  3. Ensure "Date of Death" and "Reason for Death" are present, initially not required and disabled.
  4. Change "Type of Discharge" to "Death"
  5. Validate "Date of Death" and "Reason for Death" enable.
  6. Enter a "Date of Death"
  7. Enter a "Reason for Death"
  8. Submit the form
  9. Select [ClientA]
  10. Select episode "1" in the "Episodes" drop down list on the home view
  11. Right-click on the client to open "Chart"
  12. Validate the calculated "Age" value displayed in the client header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  13. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  14. Close the "Chart"
  15. Select episode "2" in the "Episodes" drop down list on the home view
  16. Right-click on the client to open "Chart"
  17. Validate the calculated "Age" value displayed in the client header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  18. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  19. Close the "Chart"
  20. For [ClientA] open the non-episodic form
  21. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth".
  22. Validate fields "Location", "Program", "Attending Practitioner" are 'not' populated as expected in client header, since this is an episodic form
  23. For [ClientA] open the "episodic" form for open episode, episode "1"
  24. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  25. Validate fields "Location", "Program", "Attending Practitioner" are populated as expected in client header, since this is an episodic form
  26. For [ClientA] open the "episodic" form for discharged episode, episode "2"
  27. Validate the calculated "Age" value displayed in the header, is a factor of the clients "Date of Death" entered in step1 minus the client "Date of Birth"
  28. Validate fields "Location", "Program", "Attending Practitioner", are populated as expected in client header, since this is an episodic form
Topics
• Client Banner • Discharge • NX