Attachment B - Requested System Functionality Document.docx

SOM | F3 Project Faculty Data Management Vendor Selection Project Requested System Functionality Document Table of Contents

1. Introduction

1.1. Purpose

This document's purpose is to share context of the existing solutions in the CU School of Medicine with proposers (vendors) in a project that is focused on the implementation and rollout of a new comprehensive data management solution for the Office for Faculty Affairs. The document acts as a benchmark for comparing different vendors and their proposed solutions. It helps the organization assess if the vendor's system can meet the desired functionality and standards.

1.2. Intended Audience

This document is intended to outline requested functionality of a faculty data management system as defined by the School of Medicine faculty and administrators, for review by system proposers (vendors).

1.3. Intended Use

This document is intended to serve as a guide for all stakeholders, including vendors, developers, and end-users. The primary audience for this document is the vendors or solution providers who will be designing, developing, or implementing the system. The document outlines the specific functionalities requested by the organization, helping vendors understand what needs to be delivered in the final solution. This document will be used to assess and develop a Gap Analysis (between the vendor solutions and the organization’s desired future state), LOE (level of effort) and/or SOW (scope of work) proposals for consideration.

Vendor Response The vendor needs to respond in one of the following ways to each of the Functional and Nonfunctional Requirements:

“Our solution fully complies with this requirement and addresses this functionality completely.”

Or

“Our solution does not comply or only partially complies with this requirement, and more details on this non-compliance or partial compliance, and our potential future mitigation in this regard are as follows:”

If your proposed solution for meeting our needs relative to a particular requirement is not in production elsewhere, is not part of the universal codebase for all your customers, and/or is being developed and rolled out for the first time, please call that out as part of your overall response to the requirement.

1.4. Background

All medical schools conduct faculty performance reviews. Yet, there are no accepted standards for conducting these reviews, and practices across schools vary. CU SOM created a web platform, PRiSM (Performance Reviews in the School of Medicine), to track faculty accomplishments, promotion readiness, upload teaching evaluations and publications, and allow faculty to define career goals and list challenges. PRiSM encourages faculty to adopt a growth mindset. Reviews include an inquiry into faculty well-being and alignment with purpose.

Outcome: 93% of faculty complete reviews on time.

Conclusion: PRiSM helps build an appreciative culture and promotes faculty and institutional excellence through reflection, goal setting, and constructive feedback.

Currently, CU SOM has over 5,800 full-time faculty who are managed within 24 departments, which include 78 divisions or sections. In the current annual review system (PRiSM), each of these units utilizes its own administrative staff to manage the workflows and the overall status of their unit’s annual reviews. The faculty data utilized by PRiSM feeds in from a separate faculty database called FIMS (Faculty Information Management System), which contains base data sourced from PeopleSoft HCM, and is currently updated by manual data entry from information entered into a separate faculty action system in Smartsheet. In addition, each department, division, or section is required to run their own reports to request information from the system, such as review status, and ensure that all faculty have completed their annual reviews.

1.5. Product Scope

The purpose of the SOM data management system specified in this document, is to:

· Modernize data architecture and converge data and business processes into a central hub

· This application is based on a relational database with both administrative and faculty end-user functionality.

· The database and user interface will support thousands of faculty with varying workflows as well as the administrative support staff who manage the business processes.

· Design an electronic faculty review system that meets the needs of a large medical school’s faculty, administration, and clinical partners and is consistent with its missions and values

· Consolidate governance of business processes into a single hub to include Faculty Roster (complete faculty database including faculty paid by affiliates and historical faculty members), Faculty Profiles, Faculty Activity Reporting (grants, publications, etc.), Annual Performance Review, and Promotion/Tenure

· Consolidate data from multiple sources ensuring data is available in real-time, and providing all or most of the relevant faculty data in a “single pane of glass”

· To the greatest extent possible provide a solution that automates data extraction, transformation, and upload from multiple data sources, alleviating the need for faculty and support staff to create important documents, portfolios, and artifacts from scratch, such as a CV (utilizing a standard document template)

· Empower faculty and staff with self-service business intelligence capability

· Showcase faculty achievements

· Quickly create comprehensive reports

· View dynamic, visually appealing individual faculty dashboards

· Produce artifacts and outcomes that meet and/or exceed accreditation requirements

· Alert faculty to needed actions or opportunities in their faculty lifecycle

· The goal is to provide a system that can evolve over time and adapt to changing business and compliance requirements without requiring significant rework, and can cater to different users' unique workflows and preferences

2. Definitions and Acronyms

· SOM - School of Medicine

· LOE – Level of effort

· SOW – Scope of work

· HCM – Human Capital Management

· FIMS – Faculty Information Management System

· PRiSM – Performance Reviews in the School of Medicine

· CV – Curriculum vitae

· CFTE – Clinical FTE

· FTE - Full-time equivalent

· CHCO – Children’s Hospital of Colorado

· DHHA – Denver Health Medical Center

· VAMC – Veteran Association Medical Center, or “VA”

· RVU – Revenue generating units

3. Overall Description

3.1. User Needs

3.1.1. Adaptive workflows: Offer customizable workflows and automation rules to accommodate diverse user needs

3.1.2. Clear configuration management: Provide an easy-to-understand configuration system for users and administrators to customize the software

3.2. User Classes/Roles and Characteristics

3.2.1. User roles and permissions: Define flexible user roles and role-based security, allowing access levels and permissions to be based on different user needs

3.2.2. Faculty: Need their own custom view

3.2.3. Administrators: Need their own custom view

3.2.3.1. Ability to assign cases to faculty members

3.2.3.2. Ability to easily track review and promotion process steps

3.2.4. Delegated access feature: Assistant can support a faculty member- delegate access, with system credentials for the person receiving the delegation

3.2.5. Promotion committee members: need their own custom view

3.2.6. Database Administrator

3.2.7. Analyst

3.3. Assumptions and Dependencies

3.3.1. Assume there will be API integrations to upstream systems like PeopleSoft HCM facilitated/managed by SOM IT to supplement the selected vendor’s software. In general, this product should support future integrations where interfaces or APIs allow new features, third-party tools, or services to be added seamlessly.

3.3.2. All functionalities should be designed with the goal of providing users with the ability to customize their user preferences and adapt any templates or fields to reflect their specific needs. Specific examples may be included in the system features and requirements, but a successful product will allow for user’s ability for customization of settings, themes, and workflows. A successful product will allow users to adjust the software to their preferences without needing to modify code.

3.3.3. Other CU projects and initiatives may impact or change the requirements, and scope. However, any change in scope and requirements will be mutually agreed upon in writing between the vendor and the organization (CU SOM).

4. System Features

4.1. Functional Requirements

4.1.1. Single sign-on for all faculty including faculty employed by affiliate institutions

4.1.1.1. Integration with CU/Anschutz Campus standard technologies for Single Sign-On and Multi-Factor Authentication including Duo

4.1.1.2. Desktop icon for product

4.1.1.3. Option to contact help desk for support at sign on

4.1.1.4. Link to OFA website for support and guidance on the business processes

4.1.1.5. Role-Based Access: Different users (e.g., faculty, administrators, department heads) should have different levels of access to the faculty roster. For example: Faculty locked out of editing certain data (e.g., demographic data and select professional data)

4.1.2. Database

4.1.2.1. Unified database whereby the solution or application should be able to operate transparently on data that is sourced from a variety of different databases and connected by a communication network

4.1.2.2. Need to house historical data such as appointment status data

4.1.2.3. Ideally, the new product will replace FIMS and PRiSM. FIMS How to Update CU Medicine Provider Profiles via FIMS has been included for reference.

4.1.3. Custom User Notifications

4.1.3.1. Alert faculty and others about upcoming dates such as early-career review, appointment renewal date, dossier due date, etc.

4.1.3.2. Automated alert to notify faculty to complete updates, e.g. before annual review

4.1.3.3. Faculty and support staff should be able to tell (through system-provided prompts) that certain fields are read-only and that any changes to the data in these fields needs to be addressed through processes that are authorized to update base or original data in upstream systems like PeopleSoft HCM

4.1.3.4. Faculty must validate most data pulled in

4.1.3.4.1. Need notification stating that approval is needed and a process to edit the imported data

4.1.3.4.2. Nice to have: If data is edited, is there a way to trigger an alert to the source where the data originated, in case it may be inaccurate?

4.1.3.5. Faculty must confirm ‘ongoing’ activities are still current.

4.1.3.5.1. Find a streamlined approach to editing information that is incorrect or inaccurate

4.1.3.6. Email notifications triggering faculty to act

4.1.3.6.1. Note: We would like to avoid notifications contained in the app and not sent to faculty email

4.1.3.7. Alert faculty when the early-career review is required

4.1.3.8. Alert Promotion and Tenure committee members of when dossiers are ready for review

4.1.3.9. Prompts or contextual help for the end-user describing what to type in a free text box and how long it ought to be

4.1.3.10. Nice to have: Rate or review your experience message after the review has been completed (star rating and comment box) to collect data for enhancements

4.1.3.11. Hover-over functionality to provide clarity on terms

4.1.3.12. Mobile notifications

4.1.3.13. Ability to interact with the system and/or enter information via mobile device

4.1.3.14. Planned downtime notifications for users via email, and in prominent places within the system including the login page and the menu

4.1.4. Complete Faculty Roster

4.1.4.1. Faculty Roster section must be both comprehensive and user-friendly. The goal is to ensure that the system can store, manage, and retrieve all relevant information about faculty members efficiently, while also providing easy access to various stakeholders

4.1.4.2. The system should support both mandatory and optional fields that can be customized or updated as needed (e.g., additional certifications, new research interests)

4.1.4.3. Need ability to pull a faculty roster using an effective date

4.1.4.4. Index data with some identifier, for example an Employee ID/POI

4.1.4.4.1. Note: Paid employees are issued an Employee ID and volunteers are issued a Person of Interest (POI) number

4.1.4.5. Visibility of faculty roster for select department leaders with limited ability to update fields, such as phone numbers, when an early-career review is due, etc. (Keep in mind that the base or original data about each faculty member comes from PeopleSoft HCM, which does not have the capability of receiving any updates from downstream systems like this solution. There will likely be certain fields or attributes about faculty that will exist in this system or solution only, and will not be reflected in the original or base data in PeopleSoft HCM.)

4.1.4.6. Ability to filter roster data with multiple filters at the same time (limited to select user types) such as type and rank, point in time, date search, degree, clinical type, specialty, volunteer faculty, paid by affiliate, etc.

4.1.4.7. Flexibility to produce canned and ad hoc reports

4.1.4.8. Faculty roster must include, at a minimum, the following fields:

4.1.4.8.1. Degree

4.1.4.8.2. Race/Ethnicity

4.1.4.8.3. Gender

4.1.4.8.4. Administrative position such as Department Chair, Division Head, etc.

4.1.4.8.5. Academic rank & date

4.1.4.8.6. Primary department

4.1.4.8.7. Secondary department

4.1.4.8.8. Provider type

4.1.4.8.9. Appointment type

4.1.4.8.10. FTE

4.1.4.8.11. Distribution of FTE (nice to have cFTE)

4.1.4.8.12. Location such as SOM, CHCO, DHHA, VAMC

4.1.4.8.13. Employed by field

4.1.4.8.14. Department, Division, Center

4.1.4.8.15. Status such as Active, Terminated, Leave of Absence, Sabbatical

4.1.4.8.16. Method to identify volunteer faculty

4.1.4.8.17. Tenure start date

4.1.4.8.18. MPA agreement status

4.1.4.8.19. Historical data (current faculty only)

4.1.4.8.20. Years at Rank

4.1.4.8.21. Years of Service

4.1.4.8.22. FPSC Specialty

4.1.4.8.23. Productivity Data

4.1.4.8.24. P&L data

4.1.4.8.25. Salary/funding data

4.1.4.8.26. Credentialing data (incl. expirations)

4.1.4.8.27. Licensure data (incl. expirations)

4.1.5. Profiles Section

4.1.5.1. The "Profiles" section of a faculty roster is typically where detailed information about each faculty member is stored, enabling easy access to essential data. This section is especially important for managing faculty lifecycle processes, as it helps administrators, HR personnel, and others involved in faculty management to quickly understand the background and qualifications of each member of the faculty.

4.1.5.2. Please refer to How to Update CU Medicine Provider Profiles via FIMS for a description of the current process, and for additional insight into our requirements in this area

4.1.5.3. Ability for faculty to edit fields (other than fields that are populated by data from upstream systems like PeopleSoft HCM)

4.1.5.4. Customization for each department to have different views or add (activate or deactivate) specific fields

4.1.5.5. Ability for dates to be set by department administrator

4.1.5.6. Ability to have a parent department and divisions, or sections under parent department. For additional context on faculty profile connection to Health System Profiles, refer to How to Update CU Medicine Provider Profiles via FIMS for data diagram

4.1.6. Faculty Activity Reporting

4.1.6.1. Faculty Activity Reporting (FAR) section will be capturing, tracking, and analyzing various faculty activities such as teaching, research, service, and professional development. The platform should streamline the process of faculty reporting, making it easy for faculty members to document their activities, while ensuring that administrators and other stakeholders can efficiently review and generate reports based on this data. FAR will streamline the process of documenting, reviewing, and analyzing faculty activities, ensuring efficiency and transparency while complying with institutional and regulatory standards.

4.1.6.2. System should be broken down into smaller, independent modules that can be updated or extended without impacting other parts of the system

4.1.6.3. Data schema flexibility: Ensure that the underlying data model can be extended to accommodate new data types or structures without breaking existing functionality

4.1.6.4. AI-powered capabilities to minimize administrative burden

4.1.6.4.1. Example: If a user imports a CV, AI will populate the activity reporting fields appropriately.

4.1.6.5. Customizable activity categories and fields

4.1.6.6. Ability to add data throughout the year

4.1.6.7. For input fields, default setting for dates should be ‘Month, Year’ to align to SOM practices as opposed to using semesters.

4.1.6.8. Research Management System Integration. Integration with systems used to manage research projects, publications, and grants (e.g., faculty can sync their publications and research funding data from institutional research databases). Automatic pulls from other institutional sources such as grants and contracts

4.1.6.9. Access to teaching evaluation data (bulk uploads and ad hoc)

4.1.6.9.1. Medical student teaching evaluations from the Office of Undergraduate Medical Education (UME) will be automatically uploaded from OASIS.

4.1.6.9.2. Resident and fellow teaching evaluations from the Office of Graduate Medical Education (GME) will be automatically uploaded from MedHub.

4.1.6.9.3. Ability to upload additional teaching evaluations (for example, from graduate students)

4.1.6.9.4. Ability for quantitative teaching eval scores to be aggregated

4.1.6.10. Provide instructions for each section with concrete examples of what to include

4.1.6.11. Nice to have: FTE distribution productivity

4.1.6.12. The system shall support multi-level approval workflows, allowing department heads, deans, and other administrators to review and approve faculty activity reports.

4.1.7. Promotion & Tenure

4.1.7.1. While the process for Promotion and Tenure is conducted offline from existing systems like Prism and FIMS, the expectation is that the proposed new system will include functionality to support the latest version of the CU SOM Promotion and Tenure process.

4.1.7.2. Ensure that Promotion and Tenure committee members cannot access annual review information

4.1.7.3. Ability to manage ~300 dossiers per year

4.1.7.4. Auto-populate promotion matrix

4.1.7.5. Software platform will allow a faculty member to access CV and/or database to pull into a promotion matrix document

4.1.7.5.1. Ideally, the matrix document relies on AI to format the data

4.1.8. Dossier Preparation and Review

4.1.8.1. Request external letters and access them within system

4.1.8.2. Template request letter and form for faculty with expected evaluation criteria

4.1.8.2.1. Send link with template for the author to send the completed letter back to the platform

4.1.9. Annual Review/Performance Evaluations

4.1.9.1. Solution will replace PRiSM and meet or exceed the currently existing functionality for reviews and evaluations. Screenshots from the current system and a flowchart of the process have been provided for context.

4.1.9.1.1. Summary of accomplishments section, including automated uploads of teaching evaluations, grant information, and PubMed publications

4.1.9.1.2. Provide the opportunity to upload other relevant documents

4.1.9.1.3. Provide opportunity to add professional development goals

4.1.9.2. Ability to create and edit templates

4.1.9.2.1. If the template is edited and a faculty member has started to compile their data, the template should default to the most recent version

4.1.9.3. Option to pull faculty activity from past year and auto-populate to the current year

4.1.9.4. Narrative fields for faculty and supervisors

4.1.9.5. Ability for department to modify routing scheme as needed

4.1.9.6. Annual performance reviewers must be able to return faculty form back to faculty

4.1.9.7. Flexibility for ‘below’ standards process and appeals process

4.1.9.8. Flexible review process with dashboard tracking

4.1.9.8.1. Seamless transition from submission to reviewer

4.1.9.8.2. Ability to have multiple reviewers

4.1.9.8.3. Pull in historical reviewers to auto populate reviewers, but flexibility to add/remove as necessary

4.1.9.8.4. Need final reviewer to assign rating

4.1.9.8.5. Need rating form to be exported or list to be sent to HR in an HR-approved format

4.1.9.8.6. Must have: Administrators need a dashboard or other mechanism to easily track where annual reviews are in the system at any given time, both at an individual and higher level.

4.1.9.8.7. Ability for faculty to add comments after the review has been completed

4.1.9.8.8. Link to file an appeal if faculty member disagrees with performance rating

4.1.9.8.9. Faculty Attestation section

4.1.10. File Operations

4.1.10.1. Open File

4.1.10.1.1. The application must allow users to open a document from a chosen file.

4.1.10.2. Save Local File

4.1.10.2.1. The application must allow users to save the opened document into a file.

4.1.10.3. Document Template

4.1.10.3.1. The application must allow users to create a document template file from the opened document.

4.1.10.3.2. Document templates must store the structure of document sections, definitions, and values of requirement attributes.

4.1.10.3.3. The application must allow users to create a new document from a chosen document template file, preserving the structure of document sections and the definition and values of requirement attributes.

4.1.10.4. Import

4.1.10.4.1. The application must allow users to import a Microsoft Word document, preserving structure of document sections and paragraphs and rich text description of requirements and images.

4.1.10.4.2. The application must allow users to import a Microsoft Excel table of requirements preserving section headings, levels, unformatted text description of requirements and values of custom attributes.

4.1.10.4.3. Import and format with AI

4.1.10.4.4. Deduplication functionality

4.1.10.4.5. Bulk upload: Ability to ingest all promotion letters at the same time

4.1.10.5. Export

4.1.10.5.1. The application must allow users to export the displayed document view to HTML.

4.1.10.5.2. The application must allow users to export requirements to CSV.

4.1.10.5.2.1. Multiple CV templates available for faculty to select

4.1.10.5.2.2. Must be visually appealing, easy to read, and customizable

4.1.10.5.2.3. Provide different templates for annual review that can be customized to the type of faculty to increase relevance and inclusiveness

4.1.10.5.2.4. Export data directing into a CU Promotion Template

4.1.10.5.2.5. Export data directly into the NIH Template

4.1.10.5.3. Customizable reports of faculty activity by faculty profile data

4.1.10.5.3.1. Every field can be queried and reported on

4.1.10.5.3.2. Ability to have reporting templates for frequently pulled reports, such as committee work

4.1.10.5.3.3. Ability to generate departmental reports needed to determine incentive payments, example of an incentive payment spreadsheet in appendix

4.1.11. Additional Functionality in Existing Systems (PRiSM and FIMS)

4.1.11.1. As part of the system implementation planning, Vendor will conduct detailed discovery and requirements validation in collaboration with CU SOM SMEs and IT staff to identify and understand additional functionality provided by Prism and FIMS that is not listed in this document.

4.1.11.2. Vendor will help CU SOM understand the options that can be utilized to address this existing, additional functionality. Options may include aspects of the vendor’s proposed solution, extensions to the proposed solution, and/or other third-party systems or solutions that may need to be considered in this regard.

5. Nonfunctional (Technical) Features

5.1. Performance Requirements

5.1.1. Performance

5.1.1.1. There must be no lag or delay in response time for any system functionality including web forms and validation controls or logic, reports, queries, and data updates

5.1.1.2. The system must be able to process a projected volume of >5,000 faculty members in various phases of their employment cycle.

5.1.2. Reliability

5.1.2.1. Underlying data in the system must always be backed up, and available to SOM system administrator(s) through multiple means including replication to a SOM-operated Operational Data Store via API, or other approaches.

5.1.2.2. Vendor must be able to provide documentation on frequency and reliability of backups of application code and data when requested by SOM.

5.1.2.3. Maintenance or system downtime must be communicated to SOM system owners with an advanced notice of at least seven calendar days paired with a fixed pop-up banner prominently displayed for end-user visibility before or during log-in.

5.1.3. Availability

5.1.3.1. The system uptime must be 99.99999% for the hours of 6:00 AM - 6:00 PM Mountain Time on non-federal holiday weekdays.

5.1.3.2. The system must always be available but will likely be accessed mostly during business hours.

5.1.4. Supportability

5.1.4.1. All system development, including and especially new releases and versions, will be subjected to rigorous testing by the vendor before being submitted for end-user acceptance testing by the SOM, after which it will be added to the production environment along with the appropriate change management and go-live support. This process will be formally planned by the vendor and agreed upon well in advance with power users and/or system owners in the SOM.

5.1.4.2. Change management for any system rollout or changes from the vendor will include instructor-led virtual education for key system owners and stakeholders, available before milestone events along with other necessary and appropriate supports including documentation and communication collateral. Change management from the vendor will also include self-service materials and/or training materials for the larger user or customer base of the system across SOM.

5.1.4.3. Vendor must provide the SOM with a formal process by which suggested system improvements can be prioritized and addressed by the vendor and reviewed in periodic meetings between the SOM system owners and vendor account management director, sales director, or higher.

5.1.4.4. The SOM must be included on any product advisory committees or focus groups run by the vendor to gather input from the customer base.

5.1.4.5. Vendors must provide 24/7 helpline support with live voice or video call support by expert, senior technical support staff prioritized between the hours of 6:00 AM – 6 :00 PM Mountain Time.

5.1.4.6. Response and resolution time for SOM requests and system interruptions are specified in a mutually agreed upon SLA, a sample of which is provided with this solicitation.

5.1.4.6.1. Penalties on the vendor will apply if the agreed upon SLA cannot be supported by the vendor.

5.1.5. Flexibility

5.1.5.1. System functionality should accommodate and comply with evolving CU SOM practices, standards, policies and processes, and the system should be configured and tested with input from CU SOM subject matter experts.

5.1.6. Interoperability

5.1.6.1. The system must conform to all IT standards, policies, and laws that apply to such systems in the context of CU and the larger digital ecosystem across the organization.

5.1.6.2. The system must be able to receive migrated data from existing applications, and/or integrate in real-time with other applications in the digital ecosystem of the SOM including, but not limited to:

5.1.6.2.1. Smartsheet

5.1.6.2.2. Salesforce

5.1.6.2.3. HCM

5.1.6.2.4. FIMS

5.1.6.2.5. PRiSM

5.1.6.2.6. Grants (NIH)

5.1.6.2.7. Publication databases

5.1.6.2.8. OASIS

5.1.6.2.9. MedHub

5.1.6.2.10. UME

5.1.6.2.11. GME

5.1.6.2.12. ORCID

5.1.6.2.13. Google Scholar

5.1.6.2.14. PubMed

5.1.6.2.15. OnBase

5.1.6.2.16. Peoplesoft

5.1.6.2.17. Portability

5.1.6.3. Transactional system data, including tables, relationships, and constraints, in the database that underlies the application must be available via database replication to SOM IT for inclusion in a SOM Operational Data Store and/or Data Warehouse.

5.1.6.4. Must always be accessible on Windows and Apple desktop and mobile devices as a web-based technology that is agnostic to the major web browsers in the marketplace during the application's life, including the latest or near-latest releases of Microsoft Edge, Google Chrome, Safari, etc. that are required by campus IT for cybersecurity purposes.

5.1.6.5. Must always be accessible through smartphones and mobile devices, in a manner that is agnostic to the major mobile technologies in the marketplace during the application's life, including the latest or near-latest releases of Android, iOS, ChromeOS, etc. that are required by campus IT for cybersecurity purposes.

5.1.7. Recoverability

5.1.7.1. Process of recovery and restoration, and time to restore during system failure

5.1.7.1.1. The vendor will respect the mutually agreed upon SLA and its provisions relative to such failure and recovery.

5.1.7.2. Autosave functionality

5.1.7.2.1. The application will autosave all work without users needing to initiate a save across all system functionalities.

5.1.7.3. System backups

5.1.7.3.1. Vendor regularly tests application and data restoration from system backups that includes multiple approaches such as enterprise on-premises or cloud backup, virtual machine replication, offsite backups, incremental backups, and/or full backups.

5.1.7.4. Redundancy in datacenter and application architecture

5.1.7.4.1. System is architected and hosted in a manner that eliminates downtime and data loss, through redundancy, failover, and other safeguards

5.2. Cyber Security and Data Privacy Requirements

5.2.1. Data Encryption

5.2.1.1. All data in the application and overall system is encrypted at rest, and while in motion.

5.2.2. Compliance with applicable laws and policies

5.2.2.1. System and vendor comply with CU policies, and state and federal laws, that govern such data and systems

5.2.3. Defense in Depth or Multi-Layered Defense

5.2.3.1. Vendor has implemented a multi-layered cyber defense strategy that is in alignment with cyber security best practices rooted in standards such as OWASP Top 10, Soc 2, and/or national standards such as NIST 800-171, which is the basis for a lot of the NIH grants going forward.

5.2.4. Regular Security Scans and Audits

5.2.4.1. Vendor confirms that audit logging, risk assessments, vulnerability scans, penetration tests, and security audits, along with risk mitigation are taking place on a regular basis, in conformance with cybersecurity best practices set by standards such as OWASP Top 10, Soc 2, and/or NIST 800-171.

5.2.5. Integration with MFA/SSO (Multi Factor Authentication/Single Sign-On)

5.2.5.1. Vendor confirms that the system will integrate seamlessly with the single sign-on system in use at the university, utilizing multi-factor authentication for log-in and access.

5.2.6. Role-based security

5.2.6.1. Vendor confirms that the system limits access to data and functionality for each user, based on their role.

5.3. Company Strength and Stability

5.3.1. Customer base

5.3.1.1. Vendor confirms that it has implemented the proposed solution in organizations of equal or greater complexity (when compared against CU SOM) and can provide references for such accounts.

5.3.1.2. Please provide a list of all medical schools running the proposed solution(s).

5.3.2. Financial strength

5.3.2.1. Please provide financial reports, disclosures or other statements that can help us assess your company’s financial strength.

5.3.3. Escrow Clause

5.3.3.1. Please confirm if your company will agree to a software escrow clause that allows us access via a neutral third-party to the application source code and other artifacts in case your company ceases operations for any reason.

5.3.4. Reference checks from customers of like or greater complexity

5.3.4.1. Please provide at least three references where the proposed solution is in use in its entirety, or almost in its entirety.

5.3.4.2. Please also provide at least three references where the proposed solution is in use, and the customer is of equal or greater complexity.

Appendix:

Annual Review Process Workflow

Annual Performance Rating Form

Screenshots from PRiSM | Faculty Annual Review

Department of Medicine Academic, Educational and Community/Citizenship Incentive Point Calculation Worksheet

CU Medicine Salesforce and CU SOM FIMS data relationships with affiliated systems image5.png image6.png image7.png image8.png image9.png image10.png image11.png image12.png image13.png image14.png image15.png image16.png image17.png image18.png image19.png image20.png image21.png image22.png image23.png image24.png image25.png image26.png image27.png image28.png image29.png image30.gif image1.png image2.png image3.png image4.png