Last Meeting’s Minutes

Institutional Updates:

Louisiana Clinical & Translational Science Center: 

8/13/2025

• Not in attendance

8/27/2025

• Rails Security and Upgrade Plans: Ying informed the group that Rails 7.0.8.1 has it’s end of life (Ruby on Rails) is no longer maintained and it’s recommended to move to 7.1.5.2 due to critical security alerts. They have upgraded to 7.1.5.2, with plans to move to 7.2 once testing is complete. Brigette confirmed that this information would be relayed to the MUSC development team.

MUSC:

Links are accessible by Open-Source Members

8/27/2025

• Discussion - Admin services story development: Greg led a walkthrough of the new administrative service feature, explaining its technical implementation & permission structure.

  • Technical Implementation Overview: Addition of an ‘administrative' column to the services table, allowing services to be flagged as administrative. This feature is currently limited to one-time fee services, displays 'Admin Service’ in parentheses, and the toggle to mark a service as administrative becomes active only when the service has a pricing map with a full rate of zero.

  • Admin Edit Functionality: These services can be added to existing requests via the admin edit interface, following the original design intent. This method mirrors the process for routine services and ensures that administrative services are available in the appropriate dropdowns when active.

  • Permission and Visibility Logic: Only users with both service provider and catalog overlord permissions, or super users with catalog overlord access, can see and add administrative services in the shopping cart. The system filters out these services for users without the required permissions, ensuring that only authorized personnel can interact with them.

    • Rationale for Cart Integration: The ability to add administrative services via the cart was introduced to accommodate scenarios where such services need to be requested independently, not just as additions to existing requests. This change was based on feedback from service providers and aims to support workflows where administrative services may be the sole item on a request.

  • Notification and Email Suppression Logic: If a service request contains only administrative services, the system suppresses confirmation emails to submitters, requesters, and service providers. However, if administrative services are included alongside other services, they currently appear in notifications. Adjustment to this can be considered.

  • User Experience and Workflow Concerns: Discussion regarding the potential workflow configuration & exceptions and user confusion if administrative services appear as standalone requests on dashboards, and without notifications.

    • User Notification and Dashboard Visibility: Ying questioned the logic of suppressing notifications for requests containing only administrative services, noting that users might see unexplained requests on their dashboards, leading to confusion. Brigette acknowledged this concern and discussed the trade-offs between hiding such requests, sending notifications, or providing explanatory messages.

    • Workflow Impact and Institutional Variability: Ying & Ruvina highlighted that the new workflow could disrupt existing processes, especially where requests are tied to compliance or reporting (e.g., MOU tracking). They suggested that allowing administrative services to be added only to existing requests via admin edit would be cleaner and less disruptive.

    • Customization and Flexibility: Brigette proposed that the feature could be made customizable, allowing institutions to enable or disable the ability to add administrative services via the cart based on their needs. This would accommodate different institutional workflows and minimize unintended consequences.

  • Ongoing Design Review: Brigette noted that the administrative service feature is still in the piloting phase, and the team will continue to refine the design and implementation based on feedback and testing outcomes.

• Sparc and Fulfillment Release Schedule:

  • SPARC v3.14.0 Release - Fall 2025. Targeting a September release, but the timeline may extend depending on the completion of the fulfillment upgrade and other project dependencies.

  • SPARCFulfillment v.3.7.0 Release - Server & Ruby/Rails upgrade - Fall 2025

  • SPARCFulfillment v.3.8.0 Release - Late Winter 2026

Oregon Health & Science University:

8/13/2025

• Have conducted an initial review of the upgrade to Spark 3.13.0, originally planning to implement the upgrade in the next sprint, but it might be delayed until September.

8/27/2025

• Not in attendance

Iowa

8/13/2025

• Not in attendance

8/27/2025

• Not in attendance

Case Western

8/13/2025

• Not in attendance

8/27/2025

• Will bring the Admin Service topic to their group for additional perspectives and to report back.

Children’s National

8/13/2025

• Not in attendance

8/27/2025

• Not in attendance

Stony Brook:

8/13/2025

• Not in attendance

8/27/2025

• Not in attendance

Morehouse:

8/13/2025

• Upcoming meeting for SPARC walk through, focused on the service provider actions.

• An additional, technical meeting will be scheduled to make sure connections are working, and for overview of Catalog to Fulfillment set up.

8/27/2025

• Fulfillment connection setup & management meeting with MUSC tomorrow