Upcoming Release: SPARCRequest Version 3.7.0 & SPARCFulfillment Version 3.1.0

Kyle Hutson (Unlicensed) 21 (1638 days ago), Wenjun He (Unlicensed) 18 (1518 days ago), harikrip 11 (1527 days ago)

MUSC Release Date: 5/26/2020 OS Release Date: TBD

IN PROCESS

Page Index:

SPARCRequest Version 3.7.0 New Features

SPARCRequest Rake Tasks and Setting Changes

List of Programming Changes with Links to GitHub

SPARCRequest Version 3.7.0 New Features

1. (SPARC Code) Copyright Language Update

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:

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.

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.

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.

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.

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.

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

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.

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,

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.

1).	2).

14. (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.

15. (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.

16. (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

17. (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.

“Max“ button on Edit Subject Count Window	“Apply to All” button on Edit Arm Window

18. (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

19. (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.

20. (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

21. (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).

(SPARCRequest Step 5) “Get Cost Estimate” Button Removed	(SPARCDashboard Admin Edit) Status Dropdown Menu	(SPARCCatalog) Get Cost Estimate No longer a Default Status

22. (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.

23. (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.

24. (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.

25. (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.

26. (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.

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

There was a 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

28. (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).

29. (SPARCDashboard Homepage) New Historical Protocol Merges Column

With the features of protocol merge to cleanup duplicative records, there is 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.

30. (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 has been cases where people can't search or see the protocols that they should have access to.

In this release, we have added a new filter option, “All Protocols“ , for general study team users, for them 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.

31. (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

32. (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“.

Lock/Unlock Calendar & Funding

Study Information Funding Source Locked Down

33. (SPARCDashboard) Inactive Non-Clinical Services Tab and Inactive Clinical Services Tab Not Shown Bug Fix

On SPARCDashboard, filter for an inactive organization

Choose a protocol and enter the SSR that belongs to that inactive organization

Click Admin Edit

Expected

The inactive service(s) should still shown under the Non-Clinical (and/or Clinical) tab in Admin Edit section.

Actual

Some of the non-clinical service tab are not displayed at all, although the cost is shown in the header, and the "View" modal from dashboard still shows it; Same with Clinical Service tab.

Previous	Current

34. (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.

35. (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 update the subject count N on a line item changing the request status to draft. This bug has been fixed in this release.

Previous Bug

36. (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.

37. (SPARCDashboard & SPARCReport) Shared Notification Feature and New Notifications Report

Previously, notifications sent to specific users are only visible to the person receiving or sending the message. For units with multiple providers this poses a problem as it is unclear what has been communicated.

In this release, we created the new “Shared Notification“ feature to help with the communication within a service provider group:
1). In SPARCDashboard, when sending a notification related to a request, users should be able to publish/share a notification. Default to "share" when not selected otherwise.

2). On Messages page, add a third tab "View All Shared", which display shared notifications (history) on sub_service_requests that the logged in user has access to. This should be view-only for previous records, and shouldn't have the mark as unread/read functions.

2). In SPARCReport, add a new canned report to export all notification, with date and organization filters. The report should include: SRID, Request Organization, From, To, Date, Subject, Content.

SPARCReport	Notifications Report

37. (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.

38. (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.

(SPARCRequest) SPARCForms View Update

Background:
Currently, 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. Previous related story can be found here: https://www.pivotaltracker.com/story/show/156232184.

Acceptance Criteria:
1). Please update the SPARC Forms "dashboard" to only show those completed forms associated with the admin user currently logged in? For example, when you open your Dashboard, the user can only view those projects associated with them.

2). This display restriction should work for super user and service providers. For site admin users, they should still have access to every form (for ease of management).

(SPARCForms) Export Form Responses bug - when Include Incomplete is checked

It only happens when Include Incomplete is checked

Steps to reproduce

Login as a site admin, click SPARCForms on the navbar
Filters: Select 'Form' Type and check Include Incomplete
Click Filter to render results
From Form Responses, click the Export Data buttonExpectedDownload or open an xlsx file

39. (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

40. (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

41. (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

SPARCRequest Rake Tasks and Setting Changes

SPARCFulfillment Version 3.1.0 New Features

1. (SPARCCodebase) Copyright Update 2020

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

ID and Recruitment Source

3. (SPARCFulfillment) Insert Visit Bug

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.

Previous Insert Visit Bug

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.

SPARCRequest IRB Data	SPARCFulfillment IRB Data

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

Additional Validation for De-identified Patients

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.

External ID Selectable Column (Patient Registry)	External ID Column and Search (Patient Registry)	External ID (Participant Tracker)

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,

Previous	Current

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.

Previous Functionality	New Functions: Sync Changes to Fulfillment

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.

SPARCFulfillment Line Item Level Components Removed	Fulfillment Level Components

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.

Previous	Current

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.

Clinical Services Credit	Non-Clinical Services Credit: View Only and with Billing Manager Credit Rights	SPARCCatalog

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.