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.

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.

38. (SPARCDashboard) Admin Edit Non-Clinical Service Synchronization

Background:
Currently, after the initial push of a request from SPARCDashboard to SPARCFulfillment, any new service added on SPARCDashboard are not linked with SPARCFulfillment anymore, vice versa with deleted ones.

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.

In this release, the new “Shared Notification“ feature was created to help further communication within a service provider group:
1). In SPARCDashboard, when sending a notification related to a request, users are able to select to share a notification. The option is default to "share" but can be turned off.

2). On SPARCDashboard Messages page, a third tab "View All Shared" has been added, which display shared notifications (history) on sub-service-requests that the logged in user has access to. This is view-only for previous records, and can’t be marked as unread/read.

3). In SPARCReport, a new canned report has been built to to export all notification, with date and organization filters - 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.

In this release, user access to SPARCForms has be updated so that:
1). SPARCForms page only show those completed forms that the logged in admin user has access 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;

This bug has been fixed, and the “Resend“ button styling has also been updated for ease of use.

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.

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.

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.

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;

This endpoint currently allows calendar structure (arms and visits) to be created in SPARCRequest on protocols that exist, and doesn’t already has a protocol calendar.

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."

1. Update Setting.contact_us_mail_to ("SPARCRequest@musc.edu") for email last paragraph language

2. Update Setting.contact_us_cc ("success@musc.edu") for email last paragraph language

3. Setting.epic_user_api_error_slack_webhook has been added, and add Slack hook channel info if applicable

4. Run rake data:import_settings

5. Install proper rack gem version in server gemset

6. Add ROOT_URL to .env

7. Run rake import_permissible_values

8. Set permissible_values.is_available (key==unfunded, value==Unfunded) = 0 (or to 1 if institution desires to use the unfunded funding status)

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. (SPARCFulfillment) Insert Visit Bug Fix

When inside of a request in the Clinical Services tab in SPARCFulfillment, a previous bug existed where users were unable to add a visit due to an error message stating "Visit Day must be in order." This bug has since been fixed.

4. (SPARCFulfillment) Update IRB Data Structure to Match SPARC

In this release, the SPARCFulfillment data structure has been updated to account for the new structure that allows multiple IRB’s to be listed in SPARCRequest.

5. (SPARCFulfillment) De-identified Patient Additional Validation

In this release, additional validations have been added to the De-identified patient functions for existing patients. The following improvements have been made:
1). If a participant has been associated to more than 1 protocol in the Patient Registry, "De-identified Patient" checkbox is now disabled when editing a participant.

2). A tool-tip has been added stating “Patient cannot be de-identified because he/she is already associated to more than 1 protocol.”

6. (SPARCFulfillment) Patient Registry Display ID Column and Allow Search

In this release, users are now able to search by the External ID field in the patient registry (which could have multiple values for the same patient. The following changes have been made to accommodate this new feature:

1)."ID" has been added as a selectable column on the Patient Registry page;
2). When selected to display, multiple IDs (if they exist) on the same patient are displayed and delimited;
3). Users are able to search by an ID value;
4). ID column has been added into the column selector on the Participant Tracker page and is now searchable.

7. (SPARCFulfillment) Add "Other" Reason when Creating Custom Visit

Previously, "Other"  was added as a reason for incomplete procedures in SPARCFulfillment. In this release, "Other" has been added to the Reason list when a user creates a custom visit in SPARCFulfillment,

8. (SPARCFulfillment) Non-Clinical Services Tab: Take Away Editing Functions

In this release, the next steps have bee added for synchronization between SPARCRequest and SPARCFulfillment. The editing functions (add, edit, delete) in SPARCFulfillment have been removed for Non-clinical services and all edits must now be made in SPARCDashboard and then synced to SPARCFulfillment. In addition, a label has been added in SPARCFulfillment that states “All editing functions for non-clinical services should be done from SPARCDashboard,” and then synced to SPARCFulfillment.

9. (SPARCFulfillment) Remove Line Item Level Components

In this release, line item level components have been removed from SPARCFulfillment. The existing line item level components have been migrated down to fulfillment level, if there were no existing fulfillment components. The line item level component was not working as originally intended when built. Fulfillment level line items are the desired way to track components of services in a meaningful manner.

10. (SPARCFulfillment) Add Consistent Documents Indicator_Part II

In this release, a widget count and color indicator has been added to better identify "Notes" & "Documents" in SPARCFulfillment.

11. (SPARCFulfillment) Ability to Remove Uploaded Document

Fulfillment users (Clinical Providers and Super Users) are able to upload documents into SPARCFulfillment (onto line items), but there was no way to remove a document when needed. In this release, the ability to remove uploaded documents in SPARCFulfillment has been added. When a document is removed, there will no longer be a widget count or color indication for the removed document.

12. (SPARCFulfillment) Ability to Forfeit Charges

In this release, the ability to "Credit" a previous Fulfillment has been added. In some use cases, the Billing Manager needed a way to deduct the cost of a fulfilled service, based on previous agreements. The following changes have been made to accommodate this new feature:

1). A "Credit" option has been added at the fulfillment and procedure level (both Clinical and Non-Clinical Services)

2). When the "Credit" option is chosen on a fulfillment item or procedure level, the service_cost is kept and that item is also taken away from the Invoice Report.

3). When a Fulfillment and Procedure are "Invoiced" or "Credited," the remove button is disabled, as well as the "Reset Visit," so that procedures are not wiped out. These buttons are exclusive and cannot both be used for the same Fulfillment or Procedure.

4).In SPARCCatalog, the Billing Manager user group now has an attribute for "Allow Credit." Once that option is selected for a Billing Manager, they will have access to the "Credit" button(s). Non Billing Managers will still see this column as a view-only.

13. (SPARCFulfillment) Store Subsidy % at Fulfillment and Procedure level

Subsidy is a function that can be turned on for split/notify organizations in SPARCCatalog, and then applied to eligible requests when a subsidy is approved by the admin user. Previously, the subsidy % data was generated and stored only in SPARCRequest, and then SPARCFulfillment pulled it in when generating the invoicing report, on a request level. This workflow had potential pitfalls if/when the subsidy % changed during the reported time period on a request, resulting in discrepancies.

In this release, the following enhancements have been made for subsidies:

1). The subsidy % has been migrated to each fulfilled item level (fulfillments and procedures), so they are stored with the fulfillments when applicable.
2). Historical data has been migrated for consistency;
3). The Invoice Report has been updated to include the subsidy % as a column with updated calculation, while removing it from the end of the request.

1. Run set_percent_subsidy.rake

2. Run fix_one_time_fee_line_items.rake

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

SPARCRequest v3.7.0

• Synched Line Item Delete Bug

• Fix Reports Broken by Multiple IRB Changes

• Fixing Service Cost Report

• Check if Line Items in FULFILLMENT_DB Only When fulfillment_contingen…

• [SPARCForms]Resend Button Color Change

• SOAP Fault Formatting Changes

• Fix RMID API IRB Synchronization & Synchronization Errors When RMID Server Down

• OTF Fulfillment Line Item Synchronization Bugs

• Change 'Sign In / Sign Up' Label to 'Sign In'

• "Get a Cost Estimate" & Updatable Status Updates

• Protocol-Only and Multiple Epic Queue Record Bug

• Fix Typo in Epic Queue Push Rake Task 

• Spec Fixes for Fulfillment Synchronization

• Non-Clinical Line Item Fulfillment Synchronization

• Add "Primary" Text for Primary IRB

• Remove "Get a Cost Estimate" From List of Disabled Statuses for Catalog Manager

• More Notification Sharing Updates 

• Import/Remove IRB From RMID Search

• Update "Get a Cost Estimate" Available/Editable Statuses for Default Status Organizations

• Short Interaction Minute Must be a Positive Integer

• Incomplete Responses Bug

• Fix SSR Resubmission Issues

• Fix Typo in SSR Resubmission Logic

• Push to Epic on Update

• Fixing Query for Incomplete Responses

• Only Prompt SSR Resubmission if There are SSRs to be Resubmitted

• (SPARC NavBar) UI Improvement Needed for Narrow Screens

• UI - OFT Table

• Epic Interface Broken Bug

• Update Get a Cost Estimate Removal Migration

• Hide Federal Grant Information When Not Funded is Selected

• Remove Catalog Managers Access to Form Responses

• Minor Ordering Bug

• Notification Sharing Feature

• Fixing Submitted SR's

• 'Not Funded' Funding Status Related UI Updates

• Add a Hold_Emails Attrirbute to Super Users

• Add Primary Contacts to Organization API

• Add Description to Service/Org Searches

• Fix Protocol Search Code When Search Term Blank

• Fix for Phone Format

• Adding "Other" Role Details to Users Table

• Survey/Form Responses View Update [#16707638]

• Service Request Resubmission Epic Queue Push Logic Change

• Inactive Service Display Bug

• Fix Survey Responses Resend Button Bugs

• Multiple IRBs Per Protocol, Primary and Secondaries

• Protocol Merge SSR Ordering and New Validations

• Random Spec Failures

• Service Calendar Cell Wrapping

• Fix Duplicate SSR / Skipped SSR ID Bugs

• Add Service Name Display For All Calendar Field Editing

• Enable Other Funding Status Options[#170883735]

• Historical Protocol Merge Refactor

• Fixing IE Bug with Epic Questions

• Service Survey Complete Alerts

• Remove "Get a Cost Estimate" Button / Default Status

• Max Subject Count "Apply to All" Tooltip

• SSR Resubmission-Related Request Submission Bug

• Fix Service Calendar "Consolidated Request" Alignment

• Improved Epic Interface Push Error Handling

• Add "All Protocols" Protocol Filter for General Users

• Cache Available Permissible Values

• Update Messages Subject Column Display[169276107]

• SSR Resubmission Review Modal

• RMID Validated Flag When RMID Removed

• Max Subject Count Buttons

• Admin Edit Subject Count Don't Change to Draft

• Removes Invalid xplat Characters from File Names

• (SPARCRequest) Errors With lazy_load_ldap Enabled [#171888331]

• Add Funding Lock

• Fix Broken SubServiceRequest ssr_id Code

• SPARCForms Filter Bug

• Added Timestamp to Epic SOAP Log

• Calendar Bugs

• Organization Deep Link

• SR Submission Confirmation Page 'Go to" Button Change

• Historical Protocol Merges

• Attempting to Fix Random Spec Failures

• Auto-Refresh Bug for Modified Rate, Add/Delete Services

• Remove Unnecessary SQL Files / Move CONTRIBUTION.md To Correct Directory

• Add Primary Contact Information to Homepage When Not Logged In

• Add CD2H Language to Homepage

• (SPARCFulfillment) Ability to Forfeit Charges

• Plain Text Document Upload Bug

• Epic User API Down Error Handling

• (SPARCCloud) New User ldap_uid Error / Add Message About .edu Email

• (SPARCCloud) Homepage Primary Contacts Improvements

• Move Service Catalog Search

• [Cloud] Update Homepage Service Provider Contacts

• Improve Push to Epic Performance

• Mailer Contact Language Update

SPARCFulfillment v3.1.0

• Components Move

• Reworking Document Logic

• Remove Editing Nonclinical Tab

• Fixing IRB Data

• Fixing Soft Delete Visit Issue

• Remove Editing Functionality for Non-Clinical Tab

• (SPARCFulfillment) Display ID Column and Allow Search

• (SPARCFulfillment) Move ID and Recruitment Source onto Participant Protocols Level

• (SPARCFulfillment) Add "Other" Reason When Creating Custom Visit

• (SPARCFulfillment) Ability to Forfeit Charges