SPARCRequest Version 3.7.0 & SPARCFulfillment Version 3.1.0

MUSC Release Date: 5/26/2020        OS Release Date: 6/10/2020 Document Status: Complete

Page Index:

1. (SPARC Code) Copyright Language Update

In this release, the copyright language has been updated via script throughout the SPARCRequest code repository to be: “Copyright © 2011-2020 MUSC Foundation for Research Development“

2. (SPARCRequest Step 1) New Search Bar Location On Top of Service Catalog

In this release, the Search Bar on SPARCRequest Homepage (Step 1: Manage Services) has been moved to the top of the Service Catalog Tree on the left side to improve usability.

Previous	Current

Previous	Current
Open

3. (SPARCRequest Step 1) CD2H Search Engine language Added

In this release, the following language has been added to the SPARCRequest homepage (Step 1) to link with the CTSASearch discovery engine (http://labs.cd2h.org/search/), which has SPARCRequest integrations.

4. (SPARCRequest Step 1 and API) Display Primary Service Provider Contact Information on Homepage before User Login and Expose fields to Organization API

In this release, the following changes were made to provide more information to users who are exploring SPARCRequest:

1). When users are not logged in, Service Provider primary contact information and language are now displayed for users on SPARCRequest Step 1 when browsing (based on SPARCCatalog service provider/primary contact info). If the user is accessing a single service using the SPARCCatalog deep link, the same contact info will be provided as well.

2). The same primary service provider contact information/fields are also exposed to the SPARCRequest Organization API now.

5. (SPARC NavBar) UI Improvement Needed for Narrow Screens (LA CaTS Contribution)

In order to improve the user experience when using SPARCRequest on different sized screens, the SPARC Navigation bar has been improved so the module menu lists are consistently shown on the left, and the message count indication stays in place on narrow screens.

6. (SPARCRequest Step 1 & SPARCCatalog) Add Organization and Service Description into the Search Key words

Previously, the service catalog search functionality on SPARCRequest Step 1 page and SPARCCatalog is only searching by organization/service name, CPT code, EAP ID. In this release, the searchable fields have been expanded to include organization and service description, to better assist user searches.

7. (SPARCRequest Step 2 and SPARCDashboard) Remove RMID Validation Flag when an RMID is Removed from Protocol

Previously, when a Research Master ID (RMID) was removed from a SPARC protocol, and that protocol already had a "rmid_validated" flag on it, the validation flag was kept. This behavior was problematic since the RMID was no longer associated with the SPARC record.

In this release, the RMID validation flag and visual cue is removed when a RMID number is removed from a SPARC protocol on SPARCRequest Step 2 and SPARCDashboard.

8. (SPARCRequest Step 2 and SPARCDashboard) Allow Multiple sets of IRB fields for Non-local/ Central/ Secondary IRBs

In this release, the IRB fields have been expanded to allow for multiple IRB fields (i.e. local, non-local, central, or secondary IRB) on a given protocol. The following changes have been made:
1). On SPARCRequest Step 2 and SPARCDashboard, the Protocol Information form "Human Subjects Information" section has been re-arranged, and the 8 IRB-related fields are grouped and displayed together: "Pro#", "Study Phases", "IRB of Record", "Submission Type," "Pending Approval," "Initial IRB Approval Date," "Current IRB Approval Date," "IRB Expiration Date" fields together, as the IRB-related fields.

2). The first IRB record is added as the "Primary IRB Record," and the primary IRB record is the record with the RMID API integration, when that configuration is turned on.

3). Users can now add new IRB records besides the Primary IRB, with a different set of the IRB fields.

9. ( SPARCRequest Step 2 & SPARCDashboard) IE Study Question 5 Bug Fix

There was a previous bug that occurred with Internet Explorer (IE), on the Study Information section of SPARCDashboard and SPARCRequest Step 2 page, where only 4 out of the 5 Study questions appeared. In addition, the study couldn’t be saved when it was selected to “Publish in Epic.“ This bug with IE has since been fixed.

10. (SPARCRequest Step 2 and SPARCDashboard) Display Specified "Other" Authorized User Role

On SPARCRequest Step 2 and SPARCDashboard Authorized User section, when selecting the "Other" use role, the user is prompted to specify a custom role. Now the manually entered role label is also displayed in the Authorized User table as “Other - xxxxxx“ for ease of view.

11. (SPARCRequest Step 2 and SPARCDashboard) Improvement to Epic User API Error Handling

Previously, when the Epic User API went down due to server issues, adding/editing authorized users on a study that was selected to “Send to Epic“ on SPARCRequest Step 2 and SPARCDashboard would throw a silent error.

In this release, error handling method to show a front-end error message stating the "Epic user api server is down." In addition, this type of error feed can be integrated to a Slack channel using the new settings option epic_user_api_error_slack_webhook for real-time error tracking to development team.

12. (SPARCRequest Step 2 and SPARCDashboard) New Configuration for Funding Status (LA CaTS Contribution)

A new configuration, “Unfunded,“ has been added to SPARC permissible values, so that an additional Funding Status options of "Unfunded" can be turned on (permissible_values.is_available = 1).

When the configuration is turned on, on SPARCRequest Step 2 and SPARCDashboard Study Information Financial Information section, the option of “Unfunded“ will show up for “Proposal Funding Status“ drop-down menu.

This configuration was suggested and will be utilized by some of our SPARCRequest Open Source partners.

13. (SPARCRequest Step 2 and SPARCDashboard) UI Improvement with Funding Status Option (LA CaTS Contribution)

On SPARCRequest Step 2 and SPARCDashboard Study Information section, when the 'Unfunded' configuration is turned on and selected as the funding status,

1). Funding Source, Funding Start Date, and Federal Grant Information fields under Financial Information section no longer displayed on Edit and View Protocol form;

2). Under 'Study/Project Summary' section, display the (Pending) Funding Source only if the funding status is Funded or Pending, otherwise, display Funding Status instead.

14. (SPARCRequest Step 2 & SPARCDashboard, Epic Interface) Add Other Epic Interfaced Fields as Protocol Update Trigger

Previously, we have built functions to trigger and automatically update protocol information when there is any epic-related authorized user update after a protocol has been sent to Epic.
On top of existing logic, in this release, more automatic triggers are built for Protocol Update as listed below:
1). On SPARCRequest Step 2 and SPARCDashboard Study Information section, when a user edits any of the interfaced protocol information fields and saves, the protocol information update should be put into the Epic queue for protocol update. (i.e., title, Protocol ID, , Funding Source, NCT number, eIRB Pro#, Study Type, etc.) The complete list of fields interfaced with Epic can be found here: Epic Interface User Guide (SPARCRequest v3.12.1) This happens only for protocols that have been pushed successfully to Epic before;
2). A protocol is be listed in the daily update queue once, so that if multiple updates happens on the same day (i.e. protocol information was updated as well as the users), the protocol update will still only be triggered once.
3). This functionality is tied with epic setting use_epic, and only turned on when use_epic = true.

15. (SPARCRequest Step 2 & Configurations) is_available Flag for Other Details Table Bug Fix (OHSU Contribution)

Since the previous release (v3.6.0), the permissible value is_available attribute was not working, which caused the inactive values in the Other Details section of SPARCRequest Step 2 protocol information to display (is_available = "No"). This bug has since been fixed.

16. (SPARCRequest Step 2, SPARCDashboard & Configuration) Errors With lazy_load_ldap Enabled Bug Fix (OHSU Contribution)

Previously, there was a bug with lazy_load_ldap configuration, which occurred when the lazy_load_ldap was turned on. The identity search on SPARCRequest Step 2 failed to return results, and saving a new protocol caused a silent failure for a missing PI. This fix has been fixed by our Open Source partner OHSU.

17. (SPARCRequest Step 3 & SPARCDashboard) Service Calendar Misalignment UI Fix

Previously, the service calendar header and content had a slight misalignment on the SPARCRequest Step 3 Consolidated Request Tab, SPARCDashboard View Consolidated Request, and within the SPARCDashboard Admin Edit Clinical Services Consolidated Request Tab. This misalignment has been fixed in this release.

18. (SPARCRequest Step 3 & SPARCDashboard) Edit Subject Count Add Max button 

Previously, if a user changed the subject count (N) value on an Arm, the N value on each service line item would have to be updated individually in order be updated to the new (max) value.

In this release, new features have been built to allow users to update the Subject Count to the max value by one click. The new “Apply to all” checkbox allows the user to apply the arm max subject count to all of the service line items.

19. (SPARCRequest Step 3 and SPARCDashboard) Service Name Wrapping added to Clinical Service Calendar

On the SPARCRequest Step 3 page and SPARCDashboard Admin Edit clinical service tab, the CPT codes (if exist) are displayed in "()" after the service name for the CPT-coded services. However, most hospital services CPT codes were partially, or not displayed because the service name could run long. Hovering over each service to be able to see the CPT codes caused inconvenience for calendar users.
In this release, the “Service“ column was re-adjusted on the service calendar, and service names were wrappd, so that the full length with CPT codes are shown on the calendar view.

20. (SPARCRequest Step 3 and SPARCDashboard Admin Edit) Display Service Name and CPT Code in Edit Billing Quantities Window

Previously, when users were working on a service calendar on the SPARCRequest Step 3 (Service Details) page or SPARCDashboard Admin Edit Clinical Services tab and editing the billing quantities (R/T), it was confusing which service was being edited when there were multiple services on the calendar. In this release, both the service name and CPT code have been added to the header of the editing window for better usability.

21. (SPARCRequest Step 4 & SPARCDashboard) Can’t Upload .txt File Bug Fix

Previously, a bug occurred on SPARCRequest Step 4 and SPARCDashboard where .txt files couldn’t be uploaded, although the file type is listed as supported. In this release, this invalid file type bug has been fixed.

22. (SPARCRequest Step 5 & SPARCDashboard) Remove "Get a Cost Estimate" Button  and Status Re-arrangement

The "Get Cost Estimate" functionality has been causing user and workflow issues. In this release, changes have been made to the "Get Cost Estimate" status for better system usability with the following changes. 

1). The"Get Cost Estimate" button has been removed from SPARCRequest Step 5;

2). The “Get Cost Estimate“ status is no longer a system default status in SPARCCatalog;

3). The “Get Cost Estimate“ status now behaves as an admin status and displays in the status list inside the SPARCDashboard Admin Edit status drop-down menu.

4). Status is now an updatable_status, which means that it will be updated to "Submitted" when user re-submits a request.

5). Historical data has been migrated (If ever submitted before, move it to submitted; otherwise move to draft).

23. (SPARCRequest Step 5) Ability to Select Requests at Re-submission

Previously, a workflow issue was highlighted when Overlord users were working on a protocol using the "Add/Modify Request" button and going through the SPARC system steps to re-submit. The resubmission by the Overlord resulted in  all sub-service-requests that were not finished (complete, invoiced, withdrawn), locked (defined by the organizational\ status lock) or under an admin status (submitted and beyond) to be re-submitted. This use case was causing several workflow issues, especially when the Overlord did not intend to change the status of "Awaiting Requester Response" and "Draft" status to be submitted, since those were still waiting for response from study team members.

In this release, the following changes have been made to enhance the re-submission logic:

1). When the "Add/Modify Request" button is used on a protocol that was previously submitted at least once, and users are re-submitting a protocol on SPARCRequest Step 5 page, a multiple selection popup window is now displayed asking users to select/confirm which sub-service-requests they desire to re-submit (as shown in the screenshot below), with all the eligible requests defaulted to be selected, and users can elect to deselect the requests they do not wish to resubmit.;

2). The window only lists the sub-service-requests (SSRs) that are in "Draft" , “Get Cost Estimate“ and "Awaiting Requester Response" statuses, with the split/notify organization and the current statuses displayed;

3). The SSRs that are deselected will maintain their current status afterward re- submission, with no system emails triggered. Only the effective re-submission will trigger a status change and system emails.

24. (SPARCRequest Submission Confirmation Page) Replace "Go to Dashboard" Button (LA CaTS Contribution)

Previously after submitting a request, the Submission Confirmation page had the "Go to Dashboard" button, which directed a user back to the SPARCDashboard homepage. In this release, this button has been replaced with the "Go to Protocol," which routes the user directly into the protocol that has just been "Submitted."

This change has been made to allow better system usability since users typically go into their study directly after submission to manage Authorized Users, Documents, Forms, etc.

25. (SPARCRequest Step 5 and EPIC Interface) Submission Logic Revamp for Triggering Whole Protocol Epic Queue

Previously, when a user was submitting, or re-submitting, a protocol from SPARCRequest Step 5, and that protocol had been selected to "send to epic," the API logic always put the protocol in the Epic queue, even if there are no changes. This caused confusion at times because the protocol could have been re-submitted (with non-clinical services like consultation) without changing anything on the calendar.

In this release, when users are re-submitting a protocol that has been successfully pushed to Epic before, the protocol will only be queued in the “Current“ Protocol queue page in SPARCDashboard (shown in screenshot below) for designated Epic queue users to review, if the resubmission involves revised requests (indicated by Draft status) that has services interfaced with Epic.

26. (SPARC/Epic Interface) Improve Push To Epic Performance

Previously, the Epic Interface codes contained multiple n+1 queries while generating the SOAP messages to send to Epic. In this release, the SPARC to Epic push queries has been optimized using eager loading.

27. (SPARC/Epic Interface) Added Timestamp In the Log SOAP Message

In this release, the SPARC/Epic Interface has been improved upon by including timestamp information in the SOAP message sent to Epic. The timestamp will help auditing and troubleshooting the SPARCRequest/Epic API.

28. (SPARCRequest Emails) Service Provider Email Missing First Paragraph Bug Fix

There was a previous bug causing occasional absence of the first paragraph in submission email to the service providers email. This bug has been fixed in this release.

29. (SPARCRequest Emails) Updated Last Paragraph Language in All System Generated Emails

Previously, all of the SPARC system generated emails had the hard-coded language "Please contact the SUCCESS Center at (843) 792-8300 or success@musc.edu for assistance with this process or with any questions you may have." at the end of the email.

This language has been updated to be "Please contact SPARCRequest@musc.edu or call (843) 792-8300 for technical assistance or contact the service provider directly for questions related to your service request.", with the contact information not tied to settings (settings.contact_us_mail_to and settings. contact_us_phone).

30. (SPARCDashboard Homepage) New Historical Protocol Merges Column

With the protocol merge features for duplicate records cleanup, there was a need for keeping the historical trace of protocol IDs after merging for communication. In this release, a new column “Historical Protocol Merges“ has been added on SPARCDashboard homepage, where all the previously Protocol IDs that have been merged into the current protocol are listed if exist. This new column is searchable. This release also includes a migration to dig out the historical protocol IDs from audit trail and fill in this column for historical data.

31. (SPARCDashboard Homepage) New Feature to Search All Protocols

When there are multiple users managing the same set of protocols, or staff turn-over period happens, there have been cases where people can't search or see the protocols in which they should have access.

In this release, a new filter option has been added called “All Protocols,“ for general study team users to be able to search through all protocols in SPARCDashboard and browse existing protocols when needed, instead of just the ones they have access to already.

32. (SPARCDashboard) Empty Calendar Structure Table for Non-Clinical Service Provider

A previous bug occurred in SPARCDashboard where the Calendar Structure table was displaying as empty when a service provider whose organization only had non-clinical services accessed a protocol. This bug has since been fixed and the calendar structure is now displayed to all users when service calendar exists.

33. (SPARCDashboard) New Funding Source Lock for Overlord Users 

Previously, users had the ability to go into a protocol and update the funding source and funding status at any point of time on the Study Information page. This lack of restriction was causing downstream issues when a study was approved and pushed to SPARCFulfillment, with possible items fulfilled. In this release, the following changes have been made:

1). When an overlord uses the "Lock Calendar & Funding" button on the SPARCDashboard Calendar Structure table, the funding related fields (Proposal Funding Status, Potential Funding/Funding Source) become un-editable;

2). On the Protocol Study Information page, a visual indication and corresponding tooltip has been added when the two funding status and funding source fields are locked;

3). Overlord users can revert the lock by “Unlock Calendar & Funding“.

34. (SPARCDashboard) Add non-clinical services to Cost Analysis Report (Iowa Contribution)

Previously, non-clinical services (one time fees) are not showing up in the cost analysis report, and there are user groups who are interested in the report.

In this release, we have:
1). Added the non-clinical services and their costs onto the Cost Analysis report;
2). Removed the trigger for the Cost Analysis report button to show up by protocol type, so that it shows up for both projects and studies.

35. (SPARCDashboard Admin Edit) Non-Clinical Services Tab and Clinical Services Tab Display Bug for Inactive Services Fixed

Previously, if an organization is inactive, on SPARCDashboard Admin Edit page, there was a bug causing the non-clinical and clinical services tabs to be hidden. This bug has been fixed.