RFI Document.pdf

University of South Dakota 414 E Clark St

Vermillion, SD 5706957

REQUEST FOR INFORMATION

RFI No. USD10072026

Clinical Rotation Scheduling Software

I. BACKGROUND

The University of South Dakota (USD) is soliciting information regarding scheduling software that can support the planning, release, adjustment, approval, and administration of our Pillar 3 clinical rotation schedules. The University seeks information from experienced vendors about available products, implementation approaches, workflow support, technical capabilities, data export options, and approximate costs.

This RFI is intended for information-gathering and market research purposes. Responses may be used to inform whether the University issues a subsequent solicitation, pilot request, demonstration request, or other procurement activity.

II. OVERVIEW

The University is interested in a scheduling platform that supports structured student scheduling, lottery release, post-lottery changes, approval workflows, departmental administration, enrollment safeguards, and reporting. The solution should support efficiency, accuracy, transparency, and configurable controls for clinical rotation scheduling.

• Allow students to create a full Pillar 3 schedule in advance and release the schedule into a lottery system on a specified date and time.

• Release post-lottery schedules to students and support a defined change window for schedule modifications and rotation swaps.

• Route finalized schedules to the Registrar for approval and, after approval, release schedules to department assistants for confirmation of rotations.

• Allow ongoing drop/add activity throughout Pillar 3, including notifications and approval routing to the appropriate department assistants and Registrar.

• Support configurable lockout dates and timed lockout periods before scheduled rotations.

• Support online schedule-change requests during lockout periods, including approval or denial workflows.

• Prevent duplicate course scheduling and enforce course-specific week and credit-hour limits.

• Provide course-linked document storage, exports to spreadsheet format, departmental availability controls, and “sister course” capacity logic.

III. CONTACT INFORMATION

The point of contact for this solicitation is:

Mr. Chris Phillips Director of Auxiliary Services University of South Dakota 414 East Clark St.

Vermillion, SD 57069 chris.phillips@usd.edu

IV. SPECIFICATIONS

Vendors should describe how the proposed solution can model course requirements, electives, rotation duration, specialty limits, total scheduling requirements, and configurable constraints.

The following example schedule structure is provided to illustrate expected schedule complexity.

Qty Course / Category Duration / Constraint Type

2 SURG 764 Surgery Specialties

4 weeks; two 2-week rotations Required

1 FAMP 823 Emergency Room 3 weeks Required

Sub-Internship:

MEDC, FAMP,

OGYN, PEDS,

PTRY, or other approved option

4 weeks Required

FAMP 810 Rural

Family Medicine

4 weeks Required

1 Transition to Residency 1 week Required

1 Student Affairs Course 1 week Required Total Required 17 weeks Summary

34 Elective courses

34 weeks listed;

vendor should support configurable elective totals and validations

Elective

Total Elective 30 weeks Summary mailto:chris.phillips@usd.edu

Total 51 weeks Summary

Functional Capabilities

A. Student Scheduling and Lottery Release

• Describe how students can build a full schedule before a release date.

• Describe how the system supports release of schedules into a lottery system on a configured date and time.

• Describe how post-lottery schedules are released to students.

• Describe how students can change schedules during a defined post-release window, including rotation swaps.

B. Approval Workflow and Routing

• Describe how finalized schedules can be routed to the Registrar for approval.

• Describe how Registrar-approved schedules can be released to department assistants for rotation confirmation.

• Describe how change requests and notifications are routed to the correct department assistant and Registrar.

• Describe role-based permissions for students, Registrar users, department assistants, administrators, and read-only stakeholders.

C. Drop/Add, Lockout, and Exception Requests

• Describe how students can drop and add courses throughout Pillar 3.

• Describe how the system supports a timed lockout period before scheduled rotations, such as a three-week lockout.

• Describe how students can submit online schedule-change requests during the lockout period.

• Describe approval, denial, notification, and audit-trail capabilities for lockout-period exception requests.

D. Scheduling Rules and Safeguards

• Describe how the system prevents duplicate course scheduling.

• Describe how the system prevents scheduling for fewer or more weeks than allowed for a course.

• Describe how the system prevents students from signing up for more than the allotted number of credit hours per specialty.

• Describe how administrators can configure course duration, maximum credits, prerequisites, capacity, rotation dates, and specialty groupings.

E. Course Availability and Sister Course Logic

• Describe how department assistants can make a rotation available or unavailable.

• Describe how the system notifies students and department assistants if a rotation becomes unavailable after a student has scheduled it.

• Describe how the solution supports “sister courses,” where multiple courses share a capacity constraint and only one student may schedule within the shared clinical location or rotation block at a time.

F. Content, Documents, Exports, and Reporting

• Describe how course-level documents can be stored and linked, including important forms, syllabi, and other course materials.

• Describe available spreadsheet export options, including exports that support creation of monthly elective spreadsheets.

• Describe standard reports, configurable reports, dashboards, data filters, and export formats.

• Describe how the system supports historical schedule review, audit logs, and reporting by student, course, department, rotation location, and month.

Technical Requirements

A. System Architecture and Hosting

• Describe the proposed hosting model, including cloud, SaaS, on-premises, or hybrid options.

• Describe system availability, maintenance windows, backup practices, disaster recovery, and data retention capabilities.

• Describe scalability for student cohorts, courses, rotations, locations, and administrative users.

B. Security, Privacy, and Compliance

• Describe security controls for authentication, authorization, encryption, logging, audit trails, and privileged access management.

• Describe FERPA-relevant data protection practices and any higher-education compliance experience.

• Provide available third-party security certifications or assessments, such as SOC 2 Type

II, ISO 27001, or equivalent documentation, if applicable.

• Describe data ownership, data residency, breach notification, and contract termination data-return or deletion processes.

C. Identity, Integration, and Data Exchange

• Describe identity integration options such as single sign-on, SAML, OIDC, Microsoft Entra ID, or other supported approaches.

• Describe options for inbound and outbound data feeds, API access, flat-file import/export, and scheduled reporting.

• Describe integration experience with student information systems, learning management systems, calendaring platforms, email notification systems, and institutional reporting tools.

• Describe support for role-based access, delegated administration, and department-specific configuration.

Implementation, Support and Training

• Provide an implementation approach, including discovery, configuration, testing, migration/import, training, go-live support, and post-go-live optimization.

• Describe customer support options, escalation paths, support hours, account management, and service-level commitments.

• Describe administrator, department assistant, Registrar, and student training resources.

• Describe documentation, knowledge base, release notes, upgrade cadence, and change-management processes.

V. RESPONSE

1) USD is requesting a response that would provide the best fit for the USD’s requirements as described in this RFI. The response should include both technical and non-technical information that the USD would use in understanding different types of contract management software systems available in the marketplace, and the requirements for implementing such a system. Address minimum and optional capabilities as described in Section IV above.

Requested Response Contents

• Executive summary of the proposed solution.

• Description of scheduling, lottery, approval, lockout, drop/add, notification, reporting, export, and document-management capabilities.

• Technical architecture, hosting model, integration options, security controls, data protection practices, and compliance documentation.

• Implementation plan, training plan, support model, timeline assumptions, and customer responsibilities.

• Known limitations, configuration dependencies, customization options, and assumptions.

• Pricing model and cost estimates as described below.

• References for similar implementations, preferably in higher education or health sciences / clinical education scheduling.

2) Please provide your response to this RFI in pdf format, by 3:00 p.m. Central Time, Wednesday, October 28, 2026, by emailing chris.phillips@usd.edu.

VI. PRICING

1) Please provide 3 and 5-year cost estimates to support our use of the proposed solution for the

USD system.

Provide Individual pricing on the following areas: maintenance; subscriptions; services; support;

interfaces; or other costs required to implement and support the use of the system.

VII. PRODUCT DEMONSTRATIONS

1) USD may request product demonstrations based on the information received, therefor not all respondents may be invited to provide a demonstration. Demonstrations shall be online and allow for multiple users to view the presentation.

2) Please provide three references (including contact information) of implementations completed within the last two years.

VIII. QUESTIONS

USD requests all questions be submitted via email, no later than Friday, October 16, 2026 to chris.phillips@usd.edu. Responses to all questions will be distributed to all who are interested.

USD reserves the right to reject or deny any requests(s) made by potential respondents.

Impromptu, oral questions are permitted, but are only intended as general direction and will not represent and official USD position.

IX. USE OF INFORMATION

1) USD, at its sole discretion, may or may not issue a related solicitation or issue multiple solicitations based on the responses to this RFI.

2) All material and information provided to USD in response to this RFI shall upon receipt become the property of USD and shall not be returned.

3) By submitting a response, the respondent agrees that USD may copy the response for purposes of facilitating USD’s review or use of the information. The respondent also acknowledges that such copying will not violate any copyrights, licenses, or other agreements with respect to the materials submitted in accordance with USD’s intended use.

4) USD is not responsible for any costs incurred by the respondent that are related to the preparation or delivery of the response or any other activities of the respondent related to this

RFI.

X. ADDITIONAL QUESTIONS

Scheduling Workflow

1) How does the solution support students building a full Pillar 3 schedule before release?

2) How does the lottery release work, and what configuration options are available?

3) How are post-lottery changes, swaps, and approvals handled?

4) How does the solution prevent duplicate courses, incorrect week counts, and excess credit hours by specialty?

5) How are drop/add requests handled throughout Pillar 3?

6) How are lockout periods configured and enforced?

7) How are exception requests submitted, routed, approved, denied, and audited?

Administration and Availability

8) How can department assistants manage rotation availability?

9) How does the system notify affected students and staff when a rotation becomes unavailable?

10) How does the solution support “sister courses” with shared capacity constraints?

11) What administrative controls are available at the course, department, rotation, location, and student levels?

Reporting, Documents, and Data

12) What document storage and course-linking features are available?

13) What spreadsheet exports are available for monthly electives and other operational reporting?

14) Can reports be scheduled, filtered, customized, and exported?

15) What audit logs and historical records are retained?

Technical, Security, and Support

16) What authentication and identity integration options are available?

17) What APIs, imports, exports, or integration methods are available?

18) What security certifications, third-party assessments, or compliance documentation can be provided?

19) How is FERPA-relevant student data protected?

20) What support, training, and service-level commitments are included?

21) How are upgrades, product changes, maintenance, and outages communicated?

22) Do you have a trust center that outlines your Security, Accessibility, Data Processing, and overall compliance. Please provide a link and access

23) Describe your overall security implementation including but not limited to Data Security, Breach Notification, and protections regarding application development.

24) Provide all details regarding accessibility compliance including a VPAT

25) Please provide data processing agreement template

26) Please describe the use of AI in the application, including but not limited to where and how it is used

27) Do your customers typically have you engage with a Business Association Agreement?