...
SPARCRequest Version 3.7.0 New Features
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 |
|---|---|
 |  |
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:
...
SPARCRequest Step 1 When Not logged in | SPARCCatalog | SPARCRequest Organization API |
|---|---|---|
 |  |  |
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.
SPARCRequest NarBar on iPad Screen | SPARCRequest NarBar Module List on iPad Screen |
|---|---|
 |  |
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.
SPARCRequest Step 1 | SPARCCatalog |
|---|---|
 |  |
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.
Previously | Now |
|---|---|
 |  |
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.
...
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.
Previous Bug | Current |
|---|---|
 |  |
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.
...
Previous Silent Error | Now | Slack Hook Integration |
|---|---|---|
 |  |  |
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).
...
SPARC Permissible Values | Proposal Funding Status Dropdown Menu |
|---|---|
 |  |
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,
...
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.
1). | 2). |
|---|---|
 |  |
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.7.0) 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.
...
| Anchor | ||||
|---|---|---|---|---|
|
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.
Previous Misalignment | Now |
|---|---|
 |  |
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.
...
“Max“ button on Edit Subject Count Window | “Apply to All” button on Edit Arm Window |
|---|---|
 |  |
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.
Previous | Current |
|---|---|
 |
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.
Previous Bug |
|---|
 |
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.
...
(SPARCRequest Step 5) “Get Cost Estimate” Button Removed | (SPARCDashboard Admin Edit) Status Dropdown Menu | (SPARCCatalog) Get Cost Estimate No longer a Default Status |
|---|---|---|
%20(2).png?version=2&modificationDate=1590086642150&cacheVersion=1&api=v2&width=204) | %20(2).png?version=1&modificationDate=1590087326636&cacheVersion=1&api=v2&width=374) |
|
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.
...
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.
Previous | Current |
|---|---|
 |  |
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.
Previous Bug |
|---|
 |
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:
...
Lock/Unlock Calendar & Funding | Study Information Funding Source Locked Down |
|---|---|
|  |
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.
...
SPARCDashboard Cost Analysis Button | Cost Analysis Report |
|---|---|
 |  |
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.
Previous | Current |
|---|---|
 |  |
36. (SPARCDashboard Admin Edit) Auto-refresh Issue for Modified Rate, Add/Delete Services Bug Fix
There was a previous bug that occurred on the SPARCDashboard Admin Edit section where the Modified Rate was not auto-refreshing and reflected in the header cost columns. This bug occurred when modifying a rate on a service line item from its original value or when services were added/deleted on a request.
In this release, the Modified Rate is auto-refreshing correctly and the Organization Cost and Total Cost are auto-updated.
...
37. (SPARCDashboard Admin Edit) Line Item Subject Count Set Status Back to Draft Bug Fix
In SPARCDashboard Admin Edit Clinical Service tab, there was a bug causing updating of the subject count N on a line item changing the request status to draft. This bug has been fixed in this release.
...
Acceptance Criteria:
1). On SPARCDashboard Admin Edit section Non-Clinical Service tab, display a visual cue for the services (line items) that are already in SPARCFulfillment;
2). For the line items that are already in SPARCFulfillment and have fulfillment items, disable deletion from SPARCDashboard, and add tooltip saying "this service already has fulfillments and can not be removed";
3). When there is a new line item added in SPARCDashboard (or from SPARCRequest), which is not in SPARCFulfillment yet, please allow "Re-push to Fulfillment" or "Sync Updates to Fulfillment" using the same button that currently "Send to Fulfillment".
39. (SPARCDashboard Messages Page) Subject Column Styling and Display Update (LA CaTS Contribution)
For the the Inbox/Sent table inside of the Message Tab in SPARCDashboard, the subject column has been updated to mimic Outlook style; i.e., showing subject with the quick-view version of the most recent received message when Inbox is selected, and the most recent sent message if Sent is selected.
|  |
|---|
40. (SPARCDashboard & SPARCReport) Shared Notification Feature and New Notifications Report
Previously, notifications sent to specific users were only visible to the person receiving or sending the message. For units with multiple providers this posed a problem as it was unclear what has been communicated.
...
SPARCReport | Notifications Report |
|---|---|
 |  |
41. (SPARCDashboard) Protocol Merge Request Order Improvement
A previous bug existed when merging two duplicate protocols using the “Merge Protocols” button on SPARCDashboard, where the secondary (i.e. slave) protocol request numbers were currently kept first due to submission dates sequence. In this release, this bug has since been, and the primary (master) protocol request order will remain in tact, with the slave protocol requests being renumbered after the primary protocol request.
In addition, validation has been added to prevent requests from the same provider (not in finished statuses) to be merged.
...
42. (SPARCDashboard Epic Queue) Protocol Update Epic Interface Better Error Handling
Previously, for the Epic Queue Protocol Update tab, if one of the protocol on the queue list for the day is missing a validation (such as missing study type answers), the rest of the queue was skipped.
In this release, se have added better logic to handle the protocol update queue, so that the failed protocols are skipped, and the rest of the queue are still pushed to Epic.
...
43. (SPARCForms) Filter Bug Fix
In the SPARCForms module, the filters were previously not consistently displaying the correct information. For example, when "active" was selected, the list of forms that displayed were null. However, when deselecting active, the Form list then appeared as selectable. In this release, the filter issues have been resolved and now work as intended and logic-driven.
...
44. (SPARCForms) User Access Update (LA CaTS Contribution)
Previously, admin users (super users, service providers, and site admins) can see every form and responses in SPARCForms, although they only have access to view and/or edit the ones they have organizational level rights to.
...
2). This display restriction only limits super user and service providers. Site admin users still have access to every form (for ease of management).
45. (SPARCForms) Export Form Responses Incomplete Query Bug Fix (LA CaTS Contribution)
Previously, on SPARCForms module when “Include Incomplete“ option is selected and used to filter form responses, clicking “Export“ button was causing an error. This bug has been since fixed.
...
46. (SPARCForm) Resend button bugs - for incomplete survey (LA CaTS Contribution)
Previously, there was a bug causing “Resend“ buttons not disabled on “System Satisfaction Survey“ (triggered at submission of SPARCRequest Step 5) and was sending blank survey to admin user;
...
Updated Resend Button UI | Email to User | After Survey Completion |
|---|---|---|
 |  |
47. (SPARCReport) Service Pricing Report Bug
Previously, there was a bug causing the previous fiscal year’s Pricing Map to show in the Service Pricing Report instead of the showing the corresponding effective pricing at that time;
This bug has been fixed, and the Service Pricing Report is showing the corresponding effective pricing.
48. (SPARCCatalog) New Survey Notification Email Feature (LA CaTS Contribution)
For institutions who has management groups interested in receiving notification when user submits a service satisfaction survey, our Open Source partner LA CaTS created a new feature for “Survey Alert“ to be turned on in SPARCCatalog. When the “Survey Alert“ is turned on in SPARCCatalog and the user submits a service satisfaction survey on a completed request, the super users who are not holding their emails from SPARCRequest will receive a system-generated email titled “Service Survey Completed in SPARCRequest“, with link showing the survey result.
SPARCCatalog Survey Alert Switch | SPARCCatalog Super User Setting | System Generated Notification Email Upon Survey Completion |
|---|---|---|
 |  |
|
...
49. (SPARC API and Catalog) Organization Deep Link
In this release, new deep link feature was created for Organization links. The deep link URL are now shown on active organizations in SPARCCatalog as “Sharable Link“ and copyable. In addition the deep linking URL has been added into the SPARC API.
SPARCCatalog Sharable Link | Organization Deep Link |
|---|---|
 |  |
| Anchor | ||||
|---|---|---|---|---|
|
...
50. (SPARCCatalog and SPARCRequest) Service Order Inconsistency Bug Fix
There was a bug with SPARCCatalog causing some services not displayed in the correct order as they were set up. This bug has been fixed.
Previous Bug | |
|---|---|
%20Service%20Order%20Inconsistency%20Bug_1.png?version=1&modificationDate=1590517919209&cacheVersion=1&api=v2) |
|
%20Service%20Order%20Inconsistency%20Bug_3.png?version=1&modificationDate=1590517923332&cacheVersion=1&api=v2)
...
51. (SPARC/OnCore API) Create Endpoint to Receive OnCore Protocol Calendar Structure
In this release, we have created endpoint in SPARCRequest to receive protocol calendar structure information from OnCore, the Clinical Trial Management System;
...
All protocols pushed from OnCore are currently recorded in the OnCore.log file.
...
52. (SPARC/OnCore API) Design Responses for Differentiate RPE and CRPC Messages
For the SPARC/OnCore Endpoint, we have designed difference responses for the RPE (protocol information only) and CRPC (protocol information with service calendar) SOAP messages.
...
53. (SPARC/OnCore API) Added Customized Error Language
Customized Error messages has been created for two scenarios below, to help OnCore and SPARCRequest admin users figure out what was causing interface failures:
1). When OnCore is trying to push a calendar via CRPC message onto an existing SPARC protocol that has an existing calendar, specific error message is shown: "Error: SPARC Protocol XXXXX has an existing calendar and cannot be overwritten."
2). When OnCore is trying to push a protocol via RPE to SPARC that does not currently exist in SPARC (this could happen by accident, or somehow due to confusion of naming convention, or protocol merge, etc), specific error message is shown: "Error: No existing SPARC protocol with this identifier."
SPARCRequest Rake Tasks and Setting Changes
...
SPARCFulfillment Version 3.1.0 New Features
1. (SPARCFulfillment Code) Copyright Update 2020
In this release, the copyright language has been updated via script throughout the SPARCFulfillment code repository to be: “Copyright © 2011-2020 MUSC Foundation for Research Development“
2. (SPARCFulfillment) Move ID and Recruitment Source onto Participant Protocols level
Previously, the "External ID" field was located on the Participants Level (participants.external_id). However, when the "External ID" was referenced for de-identified patients, and other cases, the "External ID," as well as the "Recruitment Source," had the potential to vary for that participant on different protocols. In this release, the "External ID" (external_id) field and the "Recruitment Source" (recruitment_source) field have been moved to the Participant level (protocols_participants level).
...
3. To improve the searching tolerance for ignoring lower case and upper case of protocols_participants attributes (such as External ID), MUSC handled it by changing the setting of “collation” on the protocols_participants table to utf8_general_ci
ALTER TABLE protocols_participants
CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
| Anchor | ||||
|---|---|---|---|---|
|
...