MUSC Release Date: 9/23/2020 OS Release Date: TBD
IN PROCESS
Table of Contents:
SPARCRequest Version 3.8.0 New Features and Bug Fixes
1. (SPARC All Modules) Supported Browser Language Added with New Footer Styling
In this release, the footer styling of the SPARCRequest modules framework has been updated for better visualization. In addition, language has been added for supported browser types for the current version of codes.
2. (SPARCRequest & SPARCDashboard) Outside User Login and Registration Bug Fix
Previously, when the use_shibboleth_only setting was turned on, the outside user login and registration link and pages were still displaying to users when clicking on the SPARCDashboard Navigation button or use URL without being logged in. In this release, the display has now been tied to the use_shibboleth_only setting and these pages are no longer displaying.
Previous Bug | Current |
|---|---|
 |  |
3. (SPARC - All Modules) Edit Profile Page Not Saving Updates Bug Fix
There was a previous bug where the Edit Profile page was not saving updates, however this went unnoticed since there was no error message in the front UI. This bug has since been fixed.
4. (SPARCRequest Step 1) Remove Last Service Triggers No Email Bug Fix
There was a previous bug that was found in SPARCRequest that resulted in no emails sending when when a previously submitted SSR was removed. This bug was only occurring when one line item was deleted, but did not occur when multiple line items were deleted. This bug has since been fixed in our latest release and is now properly sending a service request deletion email.
SSR Removal | Service Request Deletion Email |
|---|---|
 |  |
5. (SPARCRequest Step 2 and SPARCDashboard) Research Master ID Added as Optional Field on Projects
With the growing request to integrate the Research Master ID (RMID) into more systems, there have been several use cases where RMID would help link across systems and to avoid duplicate entries. This task was increasingly difficult without having RMID on a “Project” in SPARCRequest Step 2 and SPARCDashboard, resulting in missing data linkage(s). In this release, the RMID field has been added as an optional field for “Projects.”
6. (SPARCRequest Step 2 and SPARCDashboard) RMID validation Label Removal when RMID is Deleted (SPARC/RMID API)
Previously, when a RMID was deleted from the RMID site, or when an associated eIRB record state updated out of the verified states set, and the RMID was used on a SPARCRequest protocol which is flagged as verified (because it has passed eIRB approval), the corresponding "Updated according to…" labels were still displaying improperly in SPARCRequest Step 2 and SPARCDashboard.
In this release, we made the following improvements:
1). The RMID validation flag in SPARC resets with eIRB record state updates and correspondingly;
2). The RMID validation flag with the RMID# are also removed from an SPARC record when the Research Master ID record is deleted.
These updates are done daily with scheduled jobs, and the summary of updates are being fed into a Slack hook/channel for auditing.
RMID Deletion | Updated SPARC Record | Slack Channel Feed |
|---|---|---|
 |  |  |
7. (SPARCRequest Step 2 and SPARCDashboard) Title Single Quote Symbol Display Bug Fix
When there is an " ' " in the protocol Title, or Short Title field that is pulled into SPARC via the RMID API, it was being displayed as "'" (its HTML numeric code). This bug has since been fixed and now displays correctly.
Previous | Current |
|---|---|
  |  |
8. (SPARCRequest Step 2 and SPARCDashboard) Study Type Question Typo Bug Fix
There was a previous bug/typo in the Study Type Questions of SPARCRequest Step 2 and SPARCDashboard page. The second study type question contained a grammatical error in its content which stated: "Your study needs "break the glass" functionality because it is collection sensitive data." This was corrected to say: "Your study needs "break the glass" functionality because it is collecting sensitive data”.
9. (SPARCRequest Step 2 & SPARCDashboard) Configurable Confidentiality and Epic Study Type Questions (LA CATS Contribution)
Previously, the confidentiality questions were displaying for all studies, even if the study was not chosen to send to Epic (when the setting use_epic = yes). In addition, the first 2 questions were also displaying when institutions were not using the Epic interface (use_epic = no). In this release, the Epic configurations have been revamped to allow adopting institutions to choose whether they want their users to see/answer the confidentiality questions at all.
The following changes have been made in this release:
1). On the SPARCRequest Step 2 and SPARCDashboard Study Information page, the confidentiality-related and EPIC push-related questions have been organized into their own section. When use_epic = true, this section is called "Confidentiality and Epic Questions"; When use_epic = false, this section is called "Confidentiality Questions".
2). A new setting was created for the study type questions (use_confidentiality_questions). When this new setting is turned off, then the first two study type questions (when use_epic = true) do not display, and when (use_epic = false, no) the study type questions display, and the "Confidentiality Questions" section is hidden.
3). When this new setting is turned on (use_confidentiality_questions = true) and (use_epic = true) and (send_to_epic = yes) on a study, the Study Type Questions should always show up, as required section to fill out (see screenshot above).
4). When this new setting is turned on (use_confidentiality_questions = true) and (use_epic = true) and (send_to_epic = no), additional logic has been added to only display the study type questions when "Human Subjects" checkbox is selected.
Human Subject Unchecked & Not Publishing to Epic | Human Subject Selected & Not Publishing to Epic |
|---|---|
 |  |
 |  |
10. (SPARCRequest Step 2) Overlord User Access Inconsistency Bug Fix (OHSU Finding)
Previously, if an Overlord User built a protocol from SPARCRequest Step 1, and removed themselves from the protocols on Step 2 page, the application re-directed the user to SPARCDashboard and out of that protocol. This behavior was not consistent with the Overlord User access from SPARCDashboard. In this release, this inconsistency has been fixed, and Overlord Users can edit protocol in SPARCRequest without having their names listed as an authorized user.
11. (SPARCRequest Step 3 & SPARCDashboard) Edit Visit Window Improvement
The "Edit Visit" window on SPARCRequest Step 3 and the SPARCDashboard Admin Edit Clinical Services tab had a display sequence that was counter-intuitive. In this release, we improved the visit window display based upon user feedback:
1). On the "Edit Visit" popup window, the display arrangement has been changed so the "Day" and "Position" are on the same row in display, and then the visit windows are on the 3rd row of display;
2). The display sequence on the calendar template has been changed to display Visit Name first, to be consistent with the Edit Visit window.
3). The loading and processing speed of this window is also improved.
Previous | Current |
|---|---|
 |  |
12. (SPARCRequest Step 3 and SPARCDashboard) Easier Visit Editing Actions
Previously when editing Visit Days and Windows, users only had the ability to edit one visit at a time, submit their changes, and then click on another visit to edit. The editing function was very tedious when studies had multiple visits that required changes.
In this release, improvements have been made on the "Edit Visit" pop-up window. Users now have the ability to save their changes on the current visit and then move to the previous, or following, visit(s) to continue editing, while automatically saving without having to click “Submit.”
13. (SPARCRequest Step 3 and SPARCDashboard) Able to Default R/T for Service Indication
Previously, the service indications were all defaulted to be "R" (paid by research) on the "Quantity Billing" tab on SPARCRequest Step 3 and SPARCDashboard. When a study needed to be switched to “T” (paid by third party), the user would have to manually move all the values from R to T one by one, which can be very time consuming. In this release, a functionality “Set Default Billing Designation“ has been added to allow uses to default everything to be “T”, on Step 3 Quantity/Billing tab, or on SPARCDashboard Admin Edit Clinical Services Tab, to help accelerate coverage analysis indications.
 |  |
14. (SPARCRequest Step 3) Continue Action Bar Blocking Display of Visit Drop-down
On SPARCRequest Step 3 page, previously when the visit drop-down menu was too long, the "Save & Continue" floating action bar was blocking the display of part of the visit drop-down menu. In some scenarios, users were unable to check on the visit days. In this release, the display front/back sequence has been fixed so the drop-down menu will now default to 15 visits and also appear in the front of display.
Previous | Current |
|---|---|
 |  |
15. (SPARCRequest Step 4 & SPARCDashboard) Able to Expose Documents to All Service Providers
Previously, when users uploaded a document to a protocol the system allowed the user to default access to all current service providers. However, if other requests were added on later, the new service provider groups were not allowed to access the previously uploaded documents, unless a study team member goes back and give the providers access. In this release, when uploading a document, it is defaulted to share the document with all current and future service providers on the protocol, unless a user unselects this checkbox and subsequently chooses specific service provider groups to share documents with.
 |  |
16. (SPARCRequest) Step 5 System Satisfaction Survey Multi-Click Bug
There was a previous bug that occurred when a user elected to take the System Satisfaction Survey on Step 5. When multi-clicking the System Satisfaction Survey submission, the response was being recorded multiple times. This bug has since been fixed and responses only record one time per survey submission.
17. (SPARCRequest Email) Updated Epic Queue Language in Submission Email (LA CATS Contribution)
In this release, the Epic Queue submission email language has been updated to reflect historical changes in the queue process. Previously, there was language that stated "*Note: upon submission, services selected to go to Epic will be sent daily at 4:30pm."
This language was inaccurate, since the Office of Clinical Research (OCR) is reviewing to ensure compliance and pushing records to Epic, and the queue is no longer being automatically sent daily. In this release, the language has been updated: "*Note: upon submission, services selected to go to Epic will be reviewed by Office of Clinical Research and sent to Epic when all Institutional approvals are met." The display of this paragraph is now tied to the use_epic configuration as well.
18. (SPARCDashboard) Admin User Modify Requests Access Bug Fix (LA CATS Contribution)
Previously, there was a bug that was found in SPARCDashboard that occurred when an admin user added themselves to a study, the “Add/Modify Requests" button did not appear until the page is refreshed.
In this release, this bug has been fixed.
19. (SPARCDashboard) Authorized User_PI Epic User Interface Enhancement
A Primary PI on a SPARC protocol is defaulted to "Yes" for Epic EMR Access, even if they have not completed the Epic training to have this right (have EMP record). The SPARC/Epic API requires each protocol to have at least one epic-access user. In this release, a warning message will now display on the user rights sections on SPARCDashboard, when a protocol is chosen to be sent to Epic, but the PI does not have Epic access.
20. (SPARCDashboard) Message Content Alignment Improvement
The SPARCDashboard Messages alignment has been improved in this release by left aligning both the message content and the logged in Users name. Previously, the user name was displayed on the right side, as well as the message content if it was longer than one row, and made reading the content difficult.
21. (SPARCDashboard) Request Access to Protocol New Feature
Expanding on the previous feature in v3.7.0 where users were given the ability to "Search All Protocols" to find a protocol that they need access, there needed to be a way for users to then request access. In this release, the addition of requesting access to a protocol has been added.
The Requests column on SPARCDashboard now states “Request Access” when the logged in user does not have access to the selected protocol. Upon clicking Request Access and choosing which authorized user to notify, an automatic email is triggered to the chosen authorized user, and Cc’s the person who's requesting access, with reference to the Protocol ID and an direct URL to the protocol. This feature is another step to make the system more intuitive for both new and existing users that were previously unaware a protocol already existed in the system, which is the most common cause of duplicative protocols.
 |  |
22. (SPARCDashboard) Change Export Report Label (LA CATS Contribution)
In this release, the "Export" button label on SPARCDashboard has been changed to "Budget Template" to clarify the type of the generated report
23. (SPARCDashboard) Cost Analysis Report Non-clinical Service Total Calculation Bug Fix (Iowa Contribution)
In this release, a previous issue where the incorrect total of Non-clinical services was displayed using the full service rate instead of using funding-driven rate in the cost analysis report is fixed.
 |  |
|---|
24. (SPARCReport) Protocol Report and Service Request Report Need to Include Multiple IRBs
In our last release (v3.7.0), the functionality to allow multiple IRB records on a protocol was added. With this new feature, the Protocols and Service Request Reports have been modified to incorporate the Multiple IRB Records by the following:
1). A new column, “Number of IRBs”, is added to both Protocol and Service Request reports, to indicate how many IRB records the reported protocol has.
2). When there are multiple IRB records entered on a protocol, the multiple IRB information will show up in the “PRO#“, “IRB of Record“, “Study Phase“, “IRB Expiration Date“ in the format of “IRB1:xxxxxx, IRB2: xxxxxx, IRB3: xxxxxx“.
25. (SPARCReport) - Protocols Report Submission Date Bug Fix and New Pre-Submission Filter (OHSU Finding)
It was brought to our attention that the Protocols Report in the SPARCReport module was not pulling in any protocols prior to March 1st, 2012. This date restraint has been fixed and now allows for potential migrated legacy data to pull into the Protocol Report that occurred prior to 2012. In addition, the Protocols Report was not previously pulling in any Protocols that were Pre-Submission. In this release, the option to “Include Pre-Submission Protocols” (excludes first draft) can be added when running a Protocols Report.
Protocols Report Changes |
|---|
  |
26. (SPARCReport) New Division Column Added to SPARC Account Report (LA CATS Contribution)
The SPARC Account report in the SPARCReport module was designed to export the SPARC accounts with related information that were created during a time frame.
In this release, the SPARC Account report has been improved with the new “Division” column.
27. (SPARCReport) Email, ERA Commons Name, ORCID Columns Added to Unique PI Report (LA CATS Contribution)
In this release, the Unique PI report has been improved to include the PI Email to make communications more readily available, as well as the ERA Commons Name and ORCID for publication tracking.
28. (SPARC/OnCore API) OnCore Receiver UI Page
In this release, a User Interface (UI) page has been added to display which OnCore calendars (via CRPC push) have been received by the SPARCRequest Endpoint with a date stamp. The log was created to track the status of pushes in a user friendly format and will remain the record-keeper for the full SOAP message for any future troubleshooting. The OnCore UI page consists of the following:
1). A navigation button called "OnCore Endpoint" from SPARCDashboard, which leads to the UI page;
2). A new setting ("oncore_endpoint_access") for the group of users who will have access to this page is created;
3). A list of protocols which have received CRPC pushes from OnCore, with the columns: Protocol (URL linking back to protocol page), PI(s), (OnCore) Calendar Version, Last Push Date; Status, with the Push History log.
OnCore Log UI | OnCore Log UI History |
|---|---|
 |  |
29. (SPARC/OnCore API) Connecting SPARC Protocol to Minimal Footprint API in OnCore
In this release, new functionalities have been created to allow users to push study records (with 7 minimum footprint fields) from SPARCDashboard to OnCore:
1). A “Push to OnCore“ button now shows up on SPARCDashboard on Study Summary tab for all studies, for a defined group of admin users (settings.oncore_endpoint_access).
2). New settings have been added for connecting to OnCore minimal footprint API;
3). When a study is pushed to OnCore, SPARCRequest creates a json file and sends that to OnCore’s API to create a protocol. After a successful push, a success message is displayed; Otherwise, a failure message displays.
4). This new button only shows up when the "use_oncore" configuration is turned on.
Example of Failed Minimal Footprint API Push | |
 |  |
Example of Successful Minimal Footprint API Push | Record Shows in OnCore |
 |  |
30. (SPARC API) New Page to Generate and Manage API Tokens
Previously, SPARCRequest did not have a standardized API exchange password, and was using a fixed account and password for communication with other applications. In this release, the following changes have been made:
1). The ability to generate API tokens for different applications to use for connection to SPARCRequest has been added;
2). This new SPARCAdmin module and page is limited to Site Admin users;
3). Client Secret can be regenerated when necessary, and Access log shows the utilization of an existing API token.
 |  |
31. (SPARCRequest API) Protocols Added to SPARCFulfillment Delayed Job Queue Without Sub Service Requests Bug Fix
Previously, when attributes on a protocol were updated the protocol was also being pushed over to SPARCFulfillment. The push occurred regardless of whether the protocol actually had any requests in fulfillment or not. This bug has since been fixed.
32. (SPARC Settings) Only Enqueue Remote Service Notifier When fulfillment_contingent_on_catalog_manager Setting is True Bug Fix (LA CATS Contribution)
There was a bug for institutions which are not using SPARCFulfillment module (fulfillment_contingent_on_catalog_manager=false), causing data to be stuck in the delayed_jobs queue when there was a request update. This bug has since been fixed.
33. (SPARC Settings) Investigating/Removing a couple existing settings
In this release, some previously excessive settings were removed, i.e., "dashboard_link", "header_link_2_catalog", "header_link_2_proper", "header_link_2_dashboard", "root_url".
SPARCRequest Rake Tasks and Setting Changes
SPARCFulfillment Version 3.2.0 New Features and Bug Fixes
1. (SPARCFulfillment) Reconfigure SPARC API Communication
With the new API Client ID and Secret Token authentication mechanism in SPARCRequest, SPARCFulfillment’s connection method was also updated to use the new API authentication method.
SPARCFulfillment now needs to be given a Client ID and Secret which are generated/registered in SPARCRequest, and will then need to use that to request a token (<sparcurl>/api/token) then use that token to request data from the SPARC API (add access_token=<token> or add the token to the authorization header).
2. (SPARCFulfillment) Added Fulfilled Quantity Column for Non-clinical Service Line Item Page
Previously, the Non-clinical services tab of SPARCFulfillment was defaulted to display the "Requested" amount and "Remaining" amount, but it was lacking the display of what has been “Fulfilled.” In this release, a “Fulfilled” column has been added as a selectable field, however this does not display as a “default” column and will be continue to be left as a selectable column for user preference.
3. (SPARCFulfillment) Line Item Table Layout Improvement
In our last release (v3.2.0), the line item level components were migrated down to the fulfillment component level and removed from the layout on the Non-clinical services request page.
In this release, the Notes and Documents are no longer underneath the Actions column and are now stand-alone. In addition, the Actions column has been removed from this level.
Previous | Current |
|---|---|
 |  |
4. (SPARCFulfillment) Numbering Gadget Alignment and Refresh Bug Fix
Previously, there was a bug that occurred with the numbering gadget on the “Actions” dropdown in SPARCFulfillment where the number gadget/number indicator did not display without refreshing the page. In addition, the numbering gadget on “Documents” and “Notes“ were misaligned. Both of these issues have since been fixed in this release.
5. (SPARCFulfillment) Non-Clinical Service Pricing Bug Fix and Added Validation
Previously, a bug existed in SPARCFulfillment where pricing on a Non-Clinical service was being incorrectly applied, if a fulfillment with cost associated was entered for a different time period that would have another applied price. This bug has since been fixed, and a query has been run to identify any prior pricing inconsistencies between fulfillments for historical data clean-up.
In addition, new validations have been added to Non-clinical services, so that if a user selected a fulfillment date for Non-clinical services where a pricing map did not exist, an error would be thrown and also prevented from happening.
6. (SPARCFulfillment) Able to Change the Sequence of Clinical Procedures
In this release, the ability to change the display sequence of Clinical Services was built, once inside of a participant with a chosen visit, using the Actions menu.
The customized sequence is shared among users; Users can still switch between the customized ordered view and the original view.
New View Toggle | Ability to move services in Custom Order View |
|---|---|
 |  |
7. (SPARCFulfillment) New Subsidy Report
A new report has been added to the SPARCFulfillment "All Reports" tab, called "Subsidy Report.” The need for this report became apparent with wider user of requesting subsidies in SPARCRequest and no systematic way to track subsidy expenditures to date. When using SPARCFulfillment and the subsidy feature within SPARCRequest, admins can now keep track of approved subsidies and expenditures.
  |   |
8. (SPARCFulfillment) Add Auto Restart For Faye Errors
Previously, even with the hourly auto-check delayed job cronjob, the system was still making API calls while reports were still getting stuck in the delayed job when Faye failed. When this occurred, the issue was not always reported, or resolved in real-time. In this release, the following changes have been made to combat the delayed_job issues:
1). a check for Faye failures, and restart Faye when applicable has been added into the hourly auto-check and restart delayed job cronjob,
2). Faye error detection and restart message feed has been added into the existing Slack hook channel.
Slack Hook Feed |
|---|
 |
9. (SPARCFulfillment API) Klok Import Entry Pricing Bug Fix
Previously, there was a bug that occurred during Klok imports where pricing was inconsistent for different Clinical Providers, due to the record creation time and actual fulfillment time stamp difference from the Klok XML file. In this release, the bug has been fixed, and the Klok API will always be using the actual fulfillment start time stamp for pulling service pricing.
SPARCFulfillment Rake Tasks and Setting Changes
List of Programming Changes with Links to GitHub
SPARCRequest v3.8.0
Adding Multiple IRBs to Protocols Report and Service Request Report
Protocol Report Default to Any Date, Include Unsubmitted Option
Keep the Most Recent Service Request (LA CaTS Contribution)
Capitalize the ORCID Column Header in Unique PI Report (LA CaTS Contribution)
Add Division Column to SPARC Account Report (LA CaTS Contribution)
Add Few Columns to Unique PI Report (LA CaTS Contribution)
(SPARCReport) Add User's Email Column to Survey Responses Report (LA CaTS Contribution)
Change Export Report Label to 'Budget Template' (LA CaTS Contribution)
notify remote around update only if fulfillment_contingent_on_catalog… (LA CaTS Contribution)
Step 2 Don't Redirect if Removing Own Authorized User and You're an Overlord
Fix Modify Requests Access Bug (LA CaTS Contribution)
Move the Confidentiality Section Below General Information (LA CaTS Contribution)
Fix SSR Deletion Bug (LA CaTS Contribution)
Update Epic Language in Submission Emails (LA CaTS Contribution)