RFI 31210 Ambulatory Online Patient Scheduling Solutions

Agency:	University of Missouri System
State:	Missouri
Type of Government:	State & Local
NAICS Category:	511210 - Software Publishers 541511 - Custom Computer Programming Services 541512 - Computer Systems Design Services
Posted Date:	Jan 15, 2026
Due Date:	Feb 20, 2026
Original Source:	Please Login to View Page
Contact information:	Please Login to View Page
Bid Documents:	Please Login to View Page

RFI 31210

Description: RFI 31210 Ambulatory Online Patient Scheduling Solutions

Closing Date/Time: Friday, February 20, 2026

Buyer:

Marcy Maddox

maddoxml@health.missouri.edu

573-882-8916

Documents

MUHC RFI Ambulatory Online Scheduling Platform.docx

Reviewed 2026-01-15

Attachment Preview

Test Title

Request for Information

For

Ambulatory Online Patient Scheduling Solutions

for

The Curators of the University of Missouri

On behalf of MU Health Care

RFI #31210

Due Date: February 20, 2026

Submit responses to Marcy Maddox at maddoxml@health.missouri.edu no later than

February 20, 2026 at 3:00 p.m. CDT.

Introduction: MUHC is seeking information regarding ambulatory online patient scheduling solutions that support patient self-scheduling, operational efficiency, and integration with enterprise clinical and revenue systems.

Objective: The purpose of this RFI is to:

• Understand current market capabilities

• Assess vendor fit for ambulatory scheduling use cases

• Inform a potential future RFP and shortlist

This RFI is not a solicitation for pricing or contract award.

Scope: MU Health Care has more than 50 outpatient clinics that offer primary care and specialty care services.

Respondents should provide information on the following. Additional supporting documentation in form of narrative, brochures, supplemental materials, etc. should be provided.

Solution Overview

Please provide a concise overview of your solution.

• Company name, ownership structure, and years in healthcare

• Primary product name(s) relevant to ambulatory scheduling

• Target customer profile (practice size, health systems, AMCs)

• Approximate number of healthcare clients using online scheduling

• Typical implementation model (hosted / SaaS)

Core Scheduling Capabilities

Indicate whether each capability is Available Today, Configurable, Planned, or Not Supported.

• Patient self-scheduling (web & mobile)
• Real-time provider availability
• Multi-location scheduling
• Multi-provider / specialty scheduling
• New vs. established patient rules
• Appointment type logic
• Cancellation by patient
• Rescheduling by patient
• Centralized scheduling view for staff
• Search for back-to-back slots at the same time (family scheduling)
• Prevent fired patients from scheduling with a provider or clinic
• Relationship-based scheduling – look at past appointments to determine who the patient can schedule with
• Return first available appointment regardless of appointment type (telehealth vs. in-clinic)
• Centralized scheduling view for patients (family/proxy view of all appts)

Workflow, Automation & Access Management

Indicate whether each capability is Available Today, Configurable, Planned, or Not Supported.

• Automated confirmations & reminders (SMS/email)
• Waitlist & slot-fill automation
• Intake forms / pre-visit questionnaires
• Eligibility checks or prompts
• Referral-based scheduling support
• Telehealth scheduling
• Real-time alerts to staff if patient schedules same day appointment

Integration & Interoperability

Please describe your integration capabilities.

• Supported EHR / PM systems (list certified or active integrations)

• Integration method(s):
☐ HL7 ☐ FHIR ☐ API ☐ Flat File ☐ Other

• Directionality:
☐ Read ☐ Write ☐ Bi-directional

• Real-time vs. batch sync

• Single Sign-On (SSO) support

• Typical integration timeline

• Patient matching methodologies

• Workflows for managing “not a match” scenarios

Patient Experience & Accessibility

Indicate whether each capability is Available Today, Configurable, Planned, or Not Supported.

• Mobile responsiveness
• Patient login requirements
• Language support
• ADA / accessibility compliance
• Custom branding options
• Patient satisfaction measurement

Reporting, Analytics & Outcomes

Describe reporting and performance tracking available.

• Appointment utilization

• No-show rates

• Waitlist conversion

• Patient adoption of self-scheduling

• Front desk efficiency metrics

• User workflow metrics – i.e. how many users started their appt process, progress, abandonment and completion.

Please indicate whether reports are:
☐ Standard ☐ Configurable ☐ Exportable ☐ Dashboard-based

Implementation, Support & Governance

• Typical implementation timeline

• Client responsibilities vs. vendor responsibilities

• Training approach (virtual, on-site, self-guided)

• Ongoing support model & SLAs

• Product roadmap highlights (next 12–24 months)

Security, Privacy & Compliance

Please review and address all items in Exhibit A – indicating any issues, concerns or inability to meet requirements.

Commercial & Pricing Model (High-Level)

Do not provide pricing quotes, but describe your typical model:

• Pricing basis (per provider, per clinic, per appointment, platform fee)

• One-time vs. recurring costs

• Implementation or integration fees

• Contract length options

Client Experience & References

• Number of ambulatory clients similar in size/complexity

• Referenceable clients (optional)

• Common reasons clients select your solution

• Common reasons clients do not select your solution

Additional Information

Please include any differentiators, innovations, or considerations you believe are relevant to ambulatory scheduling in complex health systems.

Include other features that would complement the user scheduling experience.

Virtual Presentations/Demos: Selected top supplier may be requested to provide virtual presentations/demos, applicable to all MU Health Care, System offices, and affiliates as needed.

Other Information:

• Qualifications of the firm.

• Similar engagements for higher education, academic health, and healthcare clients.

• Organization profile, including employee count and client list.

• Background/resume of team members assigned to this engagement.

Cost: Please provide a flat fee for the entire project, covering professional services and associated expenses.

EXHIBIT A

RFP SECURITY RELATED CRITERIA

MU Healthcare \| Information Security
RFP Mandatory and Desired
08/12/2025	Most recent document can be found here.

Security Related

	Type	Category	Requirement	Conditions
1.	Mandatory	Agreements	The vendor will enter into a Business Associate Agreement provided or agreed to by UM System.	Solutions that involve PHI.
1.	Mandatory	Agreements	The vendor confirms that any subcontractors who have access to protected health information (PHI) have signed a Business Associate Agreement (BAA) with the vendor.	Solutions that involve PHI.
1.	Mandatory	Practices	Vendor will provide evidence of independent audit (SOC 2 Type 2, HITRUST, ISO 27001) where the scope of the audit covers the vendor’s operational practices and technical controls or complete a HECVAT FULL (most recent version). Note: Independent audit is desired over HECVAT	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC data.
1.	Mandatory	Practices	Manufacturer Disclosure Statement for Medical Device Security (MDS2)	For solutions that involve medical devices.
1.	Mandatory	Practices	Vendor provides evidence of secure coding practices, including framework adoption.	All
1.	Mandatory	Practices	Vendors must provide complete vulnerability scan and penetration testing reports conducted within the past 12 months. Note: Independent vulnerability scan and penetration test is desired over internal.	For solutions that involve cloud-based, web-based, or API components.
1.	Mandatory	Best Practices & Compliance	Solution supports unique user identification requirement.	All
1.	Mandatory	Best Practices & Compliance	Solution supports Role-Based Access Controls (RBAC).	All For solutions involving PHI, RBAC must support minimum necessary standard.
1.	Mandatory	Compliance	The solution meets user access log requirements below .	Solutions that involve PHI.
1.	Mandatory	Compliance	All PHI on vendor’s systems and subsystems are encrypted with industry approved encryption technology.	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC PHI.
1.	Mandatory	Best Practices & Compliance	Vendor utilizes zero trust methodology. On-prem Servers, Appliances, and Devices (if applicable) must: • Support residing in an isolated VLAN where inbound and outbound traffic must be allow-listed. • Support MUHC endpoint detection and response (malware protection). • Support operating systems that are not end of life support.	All solutions.
1.	Mandatory	Best Practices	If the solution needs to send email where the “from” email address is from a UM domain (e.g., @health.missouri.edu, @umsystem.edu, @missouri.edu), the solution must support subdomains (e.g., @vendorsolution.health.missouri.edu).	All solutions.
1.	Mandatory	Best Practices	Mobile apps must be capable of running under MUHC’s Mobile Device Management solutions.	All solutions that involve a mobile app used by MUHC workforce.
1.	Mandatory	Best Practices	User accounts can be disabled or deactivated rather than deleted and disabled accounts are not subject to licensing.	All
1.	Mandatory	Best Practices	Meets Authentication Requirements listed below.	All
1.	Desired	Practices	Desktop application must not require admin privileges to be used by the end user of the application.
1.	Desired	Best Practices	Solution supports Microsoft Azure’s Single-Sign-On through UM System’s Azure instance or LDAP.	All
1.	Desired	Practices	Supports Allow-Listing of University IP address.	For solutions that involve cloud-based, web-based, or API components.

Non-Security Related

	Type	Category	Requirement	Conditions
1.	Mandatory	Integrations	Solution supports integration to Oracle Electronic Medical Record (EMR) system.	All solutions requiring integration with MUHC EMR.

Documentation Requested

	Type	Category	Requirement	Conditions
1.	Requested	Documentation	• Provide a general description of how the solution will be used. • For clinical use, describe what clinical procedures or type of patients. • For operational use, describe workflows, business processes, or analytic capabilities the solution provides.	All
1.	Requested	Documentation	Where multiple subscriptions and options exist, provide a list specific subscription and options are included in RFP (or reference which document has information).	All
1.	Requested	Documentation	Documentation of Azure Application Registrations or service accounts, including permissions that are needed.	For solutions requiring Application Registrations or service accounts.
1.	Requested	Documentation	Inventory of desktop-based software, modules, or add-ons, with documentation on what permissions are needed to install or run the application.	For solutions that require desktop software to be installed.
1.	Requested	Documentation	List of all user-facing access points to the solution, such as web portals, mobile applications, or other interfaces. This does not require detailing every individual screen or page. The goal is to provide a clear understanding of each unique method by which users, whether patients, providers, or administrators, can access the system.	All
1.	Requested	Documentation	Network requirements, including, but not limited to firewall rules.	All
1.	Requested	Documentation	Describe solution’s backup methodology.
1.	Requested	Documentation	Recovery Time Objective - specify the maximum acceptable amount of time the solution may be unavailable during a disruption before normal operations are restored, in alignment with the defined Recovery Time Objective (RTO).	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC data.
1.	Requested	Documentation	Documentation on how the vendor intends to meet and how they have tested the RTO?	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC data.
1.	Requested	Documentation	Recovery Point Objective – specify the maximum acceptable amount of data loss measured in time (i.e., the point in time to which data must be restored following a disruption) in accordance with the solution’s Recovery Point Objective (RPO).	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC data.
1.	Requested	Documentation	Documentation on how the vendor intends to meet and how they have tested the RPO?	Solutions that are fully or partially hosted by the vendor, or where the vendor stores, processes, creates, receives, or transmits MUHC data.
1.	Requested	Documentation	Requirements and options for remote access.	Solutions where remote access is needed by the vendor to access servers or devices on MUHC’s network.
1.	Requested	Documentation	Documentation of intended use of MUHC’s de-identified data. Include detailed description of how the data will be de-identified and if the vendor will be maintaining a mapping table (to re-identify a record) to the de-identified dataset.	Where the vendor intends to de-identify and use MUHC’s data.

User Access Log Requirements

Record Access – when a user views the single record or partial record of an individual within the solution.

List Access – when a user views PHI presented in a list view (i.e., list of patients scheduled that day, list of patients based on search).

• The solution creates audit logs on the following:

o When a user authenticates (login) to the solution.

o When a user creates, modifies, or deletes a user of the solution.

o When a user accesses, creates, modifies, or deletes PHI of an individual (Record Access).

o When a user views PHI of individuals (List Access).

o When a user exports PHI (e.g., creates a report, exports data to Excel or CSV).

• Logs contain the following information:

o User identifier such as username.

o Description of action.

o Date and time of action.

o Description of data accessed or reference window name (e.g., demographics, lab results, clinical note).

o Identifier of patient(s) (e.g., name, patient ID number, or medical record number).

• For List Access, having the ability to determine which patients were displayed when the user accessed the list would be an acceptable compensating control with confirmation from the vendor that the report was thorough and accurate.

• Access to Audit Logs: Customer can access the above-mentioned audit logs via the application.

• Log Retention: The above-mentioned audit logs are available for no less than 12 months.

• Log Integrity: Vendor implements protections to ensure that audit logs cannot be modified by the customer or vendor.

Authentication Requirements

The solution must support one of the following authentication methods:

• Single Sign-On (SSO) via the UM System’s Microsoft Azure instance

• Integration with the UM’ Systems LDAP directory

• Application-based authentication that meets the criteria outlined below

If using application-based authentication, the solution must:

• Support multi-factor authentication (MFA) using an authenticator app

• Alternatively, support email or SMS-based MFA combined with IP allow-listing

If the application is internet-accessible and hosted by the vendor:

The vendor must confirm that login activity logs are actively monitored for suspicious access attempts.

This page summarizes the opportunity, including an overview and a preview of the attached documents.

* Disclaimer: This website provides information about bids, requests for proposals (RFPs), or requests for qualifications (RFQs) for convenience only and does not serve as an official public notice. Individuals who wish to respond to or inquire about bids, RFPs, or RFQs should contact the relevant government department directly.

Sign-up for a Free Trial, Government Bid Alerts

With Free Trial, you can:

You will have a full access to bids, website, and receive daily bid report via email and web.

Try One Week FREE Now

RFI 31210 Ambulatory Online Patient Scheduling Solutions

Attachment Preview

Sign-up for a Free Trial, Government Bid Alerts

See Also