Attachment A.docx
DOCX document 32 KB Posted
- Attached to
- CORE MANAGEMENT SOFTWARE
- Solicitation number
- 5400030147
- Issued by
- Charleston County, South Carolina
About this file
This document is a requirements compliance matrix for core management software to be implemented by the Medical University of South Carolina (MUSC). The matrix outlines comprehensive functional and technical specifications across eleven major requirement categories, including core capacity and scalability, deployment model, implementation timeline, financial system integration, data migration, training and onboarding, and post-go-live support. The solution must support 15 to 20 core facilities at contract inception with the ability to add, remove, merge, or reconfigure cores throughout the contract term. The system must be cloud-based and contractor-hosted within the continental United States, with implementation completed within nine months of contract execution. The contractor must integrate fully with MUSC financial systems including Workday, migrate legacy data while preserving logical organization, and provide role-based training for system administrators, core staff, financial users, and end users.
The requirements matrix additionally specifies capabilities for single sign-on authentication via SAML 2.0 or OpenID Connect against Microsoft Entra ID, support for multiple user types including faculty, staff, students, and external users, and role-based permission controls with administrative oversight. The solution must support end-to-end service request workflows from intake through fulfillment and billing, core-level workflow configuration, custom request forms, and multi-step workflows with dependencies and branching. Critical operational capabilities include real-time usage tracking linked directly to billing, automated invoicing with editing and reversal functionality, support for tiered and dynamic pricing models, and operational and financial reporting at core and institutional levels. The system must maintain comprehensive audit logging for authentication, authorization, administrative actions, and financial transactions; provide data retention and recovery capabilities for five to ten years; and include a documented REST API supporting OAuth 2.0 and OpenID Connect with webhook capabilities. The contractor must provide clearly defined support model with production SLAs, uptime commitments, severity-based response and restoration targets, and demonstrate WCAG 2.1 Level AA and Section 508 conformance with current VPAT documentation.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Amendment 1.pdf | ||
| Attachment B.xlsx | XLSX spreadsheet | |
| Attachment C.xlsx | XLSX spreadsheet | |
| RFP.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
ATTACHMENT A: Please complete matrix below by specifying if your solution meets, does not meet, or exceeds the specification. Additional information may be provided in the notes
| No. |
| Requirement |
| Specification |
| Compliance |
| Notes |
| 1.1.1 |
| Core Capacity and Scalability |
| The solution must support approximately 15 to 20 core facilities at contract inception and allow MUSC to add, remove, merge, or reconfigure cores at any time during the contract term. |
| ☐ Does Not Meet |
☐ Meets ☐ Exceeds
| 1.1.2 |
| Deployment Model |
| The solution must be cloud-based and contractor-hosted; identify hosting model, cloud provider, geographic region, tenant isolation, and confirm all production data, backups, disaster recovery copies, storage, processing, access, and support remain within the continental United States. |
| ☐ Does Not Meet |
| 1.1.3 |
| Implementation Timeline |
| The contractor must complete implementation within nine months of contract execution, including configuration, testing, SSO, Workday integration, legacy data migration, training, go-live, and hypercare before final acceptance. |
| ☐ Does Not Meet |
| 1.1.4 |
| Financial System Integration |
| The solution must be able to integrate fully with MUSC financial systems, including Workday, at go-live and describe integration mechanism, processing mode, error handling, reconciliation, worktag mapping, and non-production testing. |
| ☐ Does Not Meet |
| 1.1.5 |
| Data Migration |
| The contractor must migrate legacy data, preserve logical organization, and describe validation and reconciliation before final acceptance. |
| ☐ Does Not Meet |
| 1.1.7 |
| Training and Onboarding |
| The contractor must provide implementation onboarding and role-based training for system administrators, core staff, financial users, and end users. |
| ☐ Does Not Meet |
| 1.1.8 |
| Post-Go-Live Support |
| The contractor must provide post-go-live support, including issue resolution and optional training refresh resources. |
| ☐ Does Not Meet |
| 1.2.1 |
| Single Sign-On |
| The solution must support federated authentication via SAML 2.0 and/or OpenID Connect against Microsoft Entra ID; enforce MUSC MFA policies; support SCIM 2.0, just-in-time provisioning, timely deprovisioning, group-based role mapping, and disallow local contractor-issued credentials except for documented break-glass access. |
| ☐ Does Not Meet |
| 1.2.2 |
| User Types |
| The solution must support multiple user types, including faculty, staff, students, and external users. |
| ☐ Does Not Meet |
| 1.2.3 |
| External User Access |
| The system must support configurable access requirements and approval controls for external users. |
| ☐ Does Not Meet |
| 1.2.4 |
| Role-Based Permissions |
| The solution must provide role-based permissions and administrative controls. |
| ☐ Does Not Meet |
| 1.2.6 |
| Administrative Controls |
| The solution must include administrative controls such as account locks and billing holds. |
| ☐ Does Not Meet |
| 1.3.1 |
| PI Membership Tracking |
| The solution must support tracking and management of principal investigator membership status. |
| ☐ Does Not Meet |
| 1.3.2 |
| Subsidy Management |
| The system must dynamically apply subsidized pricing rules based on PI status or other institutional criteria. |
| ☐ Does Not Meet |
| 1.3.3 |
| Flexible Pricing Models |
| The solution must support tiered pricing, volume-based pricing, and dynamic pricing, including consumables. |
| ☐ Does Not Meet |
| 1.3.4 |
| Funding Source Association |
| The solution must allow users, projects, or requests to be linked to grant and funding sources. |
☐ Does Not Meet
| 1.4.1 |
| End-to-End Workflow Support |
| The solution must support end-to-end service request workflows from intake through fulfillment, billing, and closure. |
| ☐ Does Not Meet |
| 1.4.2 |
| Core-Level Workflow Configuration |
| The system must permit each core to configure workflow steps, approvals, and routing according to its operational needs. |
| ☐ Does Not Meet |
| 1.4.3 |
| Custom Request Forms |
| The solution must support creation and management of custom request forms. |
| ☐ Does Not Meet |
| 1.4.4 |
| Multi-Step Workflow Support |
| The solution must support multi-step workflows that include dependencies, branching, and approvals where needed. |
| ☐ Does Not Meet |
| 1.4.5 |
| High-Volume Request Handling |
| The solution must support large sample volumes and high-volume service requests without degrading functionality or usability. |
| ☐ Does Not Meet |
| 1.4.6 |
| Multi-Core Routing |
| The solution must allow requests to be routed across multiple cores or services. |
| ☐ Does Not Meet |
| 1.4.7 |
| Automated Notifications and Alerts |
| The system must provide automated notifications and reminders for request status changes, milestones, scheduling updates, and other workflow-driven events. |
| ☐ Does Not Meet |
| 1.5.1 |
| Scheduling Functionality |
| The solution must provide integrated scheduling for instruments and services. |
| ☐ Does Not Meet |
| 1.5.2 |
| Real-Time Usage Tracking |
| The solution must support real-time usage tracking through instrument-connected systems and disclose agent requirements, supported operating systems, footprint, network destinations and ports, deployment method, administrator rights, and compatibility with MUSC endpoint controls. Solutions requiring disabled endpoint protection or inbound ports will not be accepted. |
| ☐ Does Not Meet |
| 1.5.3 |
| Usage-to-Billing Linkage |
| Usage data must be directly linked to billing functionality. |
| ☐ Does Not Meet |
| 1.5.4 |
| Session and Service Types |
| The solution must support multiple session and service types. |
| ☐ Does Not Meet |
| 1.5.5 |
| Training-Based Access Controls |
| The solution must track user training status and restrict access accordingly. |
| ☐ Does Not Meet |
| 1.5.6 |
| Consultation Time Tracking |
| The solution must support logging of consultation time. |
| ☐ Does Not Meet |
| 1.6.1 |
| Automated Invoicing |
| The solution must support automated invoicing. |
| ☐ Does Not Meet |
| 1.6.2 |
| Invoice Editing and Reversal |
| The system must allow invoices to be edited, reversed, and disputed. |
| ☐ Does Not Meet |
| 1.6.3 |
| Internal and External Billing |
| The solution must support both internal and external billing. |
| ☐ Does Not Meet |
| 1.6.4 |
| Recurring Charges |
| The system must support recurring charges, including annual fees. |
| ☐ Does Not Meet |
| 1.6.5 |
| Differential Billing |
| The system must support billing rules based on PI status, subsidies, and institutional criteria. |
| ☐ Does Not Meet |
| 1.6.6 |
| CSV Export |
| The proposed solution must provide a configurable custom export containing all PI, financial, invoice, project, and service-level data required to support direct integration with Workday. |
| ☐ Does Not Meet |
| 1.7.1 |
| Operational Reporting |
| The solution must support operational reporting by PI, service type, and activity. |
| ☐ Does Not Meet |
| 1.7.2 |
| Financial Reporting |
| The solution must support financial reporting at both the core and institutional levels. |
| ☐ Does Not Meet |
| 1.7.3 |
| Custom Reporting |
| The solution must provide ad hoc and customizable reporting beyond standard operational and financial reports. |
| ☐ Does Not Meet |
| 1.7.4 |
| Data Retention and Recovery |
| MUSC must retain ownership of all customer data. The solution must support five to ten years of retention, full export in non-proprietary documented formats, post-termination export availability, documented RPO/RTO, U.S.-based geographically redundant backups, annual restore testing, and documented backup, disaster recovery, and restoration procedures. |
| ☐ Does Not Meet |
| 1.7.5 |
| Audit Support and Logging |
| The solution must maintain auditable records for authentication events, authorization and permission changes, administrative actions, and financial transactions; support export or retrieval for review; and support log export to MUSC’s SIEM, including Splunk. |
| ☐ Does Not Meet |
| 1.7.6 |
| API and Interoperability |
| The solution must provide a documented REST API supporting OAuth 2.0 and/or OpenID Connect, versioning, deprecation notice, API documentation, machine-readable schema, disclosed rate limits, webhook or event-based notifications, and bulk export or equivalent data extraction for institutional systems and integrations. |
| ☐ Does Not Meet |
| 1.7.7 |
| Publication Tracking |
| The solution should support publication tracking and external integrations. |
| ☐ Does Not Meet |
| 1.8.1 |
| Staff-to-User Messaging |
| The solution must support direct communications from core staff to users. |
| ☐ Does Not Meet |
| 1.8.2 |
| Administrative Messaging |
| The solution must support administrative communications that can be sent across multiple cores. |
| ☐ Does Not Meet |
| 1.9.1 |
| User Interface |
| The solution must provide a user-friendly interface. |
| ☐ Does Not Meet |
| 1.9.2 |
| Dashboards |
| The solution must provide customizable dashboards for directors and administrators. |
| ☐ Does Not Meet |
| 1.9.3 |
| Core-Level Administration |
| The system must allow core-level administrators to manage forms, pricing, and workflows. |
| ☐ Does Not Meet |
| 1.10.1 |
| Support Model and Escalation |
| The contractor must provide a clearly defined support model including production SLA, uptime commitments, service credits, severity levels, response and restoration targets, escalation path, 24x7 critical incident contact path, maintenance/change notice windows, API access, and non-production sandbox or test environment. |
| ☐ Does Not Meet |
| 1.10.2 |
| Accessibility and Browser Support |
| The contractor must identify supported browsers and minimum versions, demonstrate WCAG 2.1 Level AA and Section 508 conformance, and provide a current VPAT or Accessibility Conformance Report upon request. |
| ☐ Does Not Meet |
| 1.11.1 |
| Search Functionality |
| The system should provide search functionality for instruments and services. |
| ☐ Does Not Meet |
| 1.11.2 |
| Cross-Core Project Tracking |
| The solution should support project tracking across cores. |
| ☐ Does Not Meet |
| 1.11.3 |
| Inventory Management |
| The solution should support inventory management for samples and supplies. |
| ☐ Does Not Meet |
| 1.11.4 |
| Issue Reporting |
| The system should include issue reporting tools. |
| ☐ Does Not Meet |
| 1.11.5 |
| Feedback Tools |
| The solution should support user feedback or survey tools. |
| ☐ Does Not Meet |
| 1.11.6 |
| Marketing Portal |
| The solution should provide a marketing or web portal for cores. |
| ☐ Does Not Meet |
| 1.11.7 |
| Mobile Access |
| The solution should support mobile application access. |
| ☐ Does Not Meet |
| 1.11.8 |
| Scheduling Optimization |
| The solution should support no-show automation and scheduling optimization. |
| ☐ Does Not Meet |
| 1.11.9 |
| Interoperability with Additional Systems |
| The solution should support integration with additional institutional systems, including SPARC, beyond the required integrations identified elsewhere in the document. |
| ☐ Does Not Meet |
| 1.11.10 |
| Contractor Experience |
| Contractors should demonstrate experience implementing core facility or shared resource management solutions in universities, academic health centers, research institutions, or similarly complex environments. |
| ☐ Does Not Meet |
| 1.11.11 |
| Experience With WorkDay ERP |
| Preference will be given for solutions with experience integrating with the WorkDay ERP and capacity to export reports in the exact format shown in Attachment B. |
| ☐ Does Not Meet |
File details come from the government source that posted it. Updated .