The Regents of the University of California_

The Regents of the University of California, On behalf of the School of Medicine’s Office of Educational Technology THIS IS NOT AN ORDER REQUEST FOR PROPOSAL # ILIOS001 FOR WEB-BASED CURRICULUM MANAGEMENT SOFTWARE SYSTEM AND IMPLEMENTATION SERVICES It is the Vendor's responsibility to read the entire document and to comply with all requirements listed herein. Submittal due Date and Time All submittals must be received on or before 1:00 p.m. Pacific Time, Friday, April 4, 2008. Return 5 copies to: University of California, San Francisco Campus Procurement & Business Contracts 1855 Folsom Street Suite 304 San Francisco, CA 94143 Courier Deliveries require Zip Code 94103 Attn.: Tanya Krupsky, Procurement Specialist (415) 502-3015, fax (415) 502-3031 Faxed Submittals Will Not Be Accepted Late Submittals Will Not Be Accepted Respondent Identification __________________________________________ Company Name _______________________________________________ Company Contact _______________________________ Telephone no. (include area code) ________________________ Fax no. _______________________________ E-Mail [ ] If not submitting a response to this request and your company wishes to remain on the bid list for this product and/or service, then check box and return this sheet. Vendors not responding to this request may be removed from future bid lists. TABLE OF CONTENTS 1 1.1 1.2 INTRODUCTION ....................................................................................................... 1 Project Purpose ................................................................................................................................................1 Definitions.........................................................................................................................................................2 1.3 Project Background .........................................................................................................................................5 1.3.1 History .......................................................................................................................................................5 1.3.2 System Architecture ...................................................................................................................................5 1.3.3 Current System Gaps .................................................................................................................................6 1.3.3.1 Structure.................................................................................................................................................6 1.3.3.2 Scheduling/Calendar ..............................................................................................................................6 1.3.3.3 Security ..................................................................................................................................................6 1.3.3.4 Data Availability ....................................................................................................................................7 1.3.3.5 Course Rollover .....................................................................................................................................7 1.3.3.6 Instructor & Learner Enrollment & Group Management.......................................................................7 1.3.3.7 Data Integration .....................................................................................................................................7 1.3.3.8 Ad-Hoc Querying and Reporting ...........................................................................................................8 1.3.3.9 Learning Materials Management ...........................................................................................................8 2 GENERAL REQUIREMENTS, TERMS & CONDITIONS ......................................... 9 2.1 Contract Period................................................................................................................................................9 2.1.1 Initial Contract Period................................................................................................................................9 2.1.2 Contract Extension.....................................................................................................................................9 2.2 Estimated Value ...............................................................................................................................................9 2.3 Price ..................................................................................................................................................................9 2.3.1 Pricing Structure ........................................................................................................................................9 2.3.2 Pricing Certification...................................................................................................................................9 2.3.3 Total Cost of Ownership ............................................................................................................................9 2.4 INVOICING ................................................................................................................................................... 10 2.4.1 Payment Terms ........................................................................................................................................ 10 2.5 SCOPE OF WORK ....................................................................................................................................... 10 2.5.1 Purpose .................................................................................................................................................... 10 2.5.2 General Requirements.............................................................................................................................. 10 2.6 GENERAL CONDITIONS ........................................................................................................................... 11 2.6.1 Time of Essence ....................................................................................................................................... 11 2.6.2 Key Staff and Organizational Chart ......................................................................................................... 11 2.6.3 Insurance Requirements ........................................................................................................................... 11 2.6.4 Record Keeping and Auditing ................................................................................................................. 11 2.6.5 Terms and Conditions .............................................................................................................................. 12 2.6.6 Termination of RFP Process or Ensuing Contract ................................................................................... 12 2.6.7 Additional Terms and Conditions ............................................................................................................ 12 3 INSTRUCTIONS TO BIDDERS .............................................................................. 12 3.1 Quotation Due Date and Time. ..................................................................................................................... 12 3.1.1 Submittal Process..................................................................................................................................... 12 3.1.2 Responsive Proposals .............................................................................................................................. 13 3.1.3 Required Information and Data ............................................................................................................... 13 3.1.4 Caution to Respondents ........................................................................................................................... 13 3.1.5 Withdrawal or Modification of Bids ........................................................................................................ 13 3.1.6 Bid Results ............................................................................................................................................... 13 3.1.7 Submittal Costs ........................................................................................................................................ 14 3.1.8 Contacts with UCSF Management........................................................................................................... 14 3.1.9 Disclosure of Records/Confidentiality of Information ............................................................................ 14 3.1.10 Respondent Certification ......................................................................................................................... 14 3.1.11 Penalty for Collusion ............................................................................................................................... 15 3.1.12 Bid Acceptance Period............................................................................................................................. 15 3.1.13 Rejection of Bids ..................................................................................................................................... 15 3.1.14 Award Schedule ....................................................................................................................................... 15 3.1.15 Business Information Form ..................................................................................................................... 15 3.1.16 Proposal Protest ....................................................................................................................................... 16 4 4.1 4.2 4.3 EVALUATION FACTORS& BASIS AWARD ......................................................... 17 Evaluation Criteria ........................................................................................................................................ 17 Evaluation Procedure .................................................................................................................................... 17 References/Reference Checks ....................................................................................................................... 18 5 5.1 5.2 SUBMITTAL REQUEST ......................................................................................... 21 Letter of Transmittal ..................................................................................................................................... 21 Proposal .......................................................................................................................................................... 21 5.3 ADDITIONAL REQUIRED VENDOR INFORMATION ........................................................................ 21 5.3.1 GENERAL VENDOR INFORMATION ................................................................................................ 21 5.3.2 VENDOR FINANCIALS ........................................................................................................................ 22 6 7 ATTACHMENTS: .................................................................................................... 24 EXHIBIT 1 SYSTEM REQUIREMENTS AND APPLICATION FUNCTIONALITY .. 25 8 EXHBIT 2: USE CASES: BUSINESS PROCESSES FOR MODIFYING, SCHEDULING AND DELIVERING CURRICULUM. ..................................................... 33 9 EXHIBIT 3: SYSTEM REQUIREMENTS AND APPLICATION FUNCTIONALITY CHECKLIST FOR BIDDERS ........................................................................................ 36 10 EXHIBIT 4: APPLICATION SOFTWARE DEVELOPMENT, TRAINING & INSTALLATION COSTS WORKSHEET ...................................................................... 44 1 1.1 INTRODUCTION Project Purpose The University of California, San Francisco‘s School of Medicine (SOM) is seeking a partner to replace its current web-based curriculum management system, known as Ilios. Ilios was created to provide medical education users the ability to view course calendars and search Ilios‘s vast catalog of teaching sessions, learning materials, self-directed learning modules, and publication citations. It enables users to meet objectives such as automatic notification of faculty regarding their teaching obligations, management of digital learning materials, and delivery of content to learners through their online courses in WebCT 1, sharing of curricular data with all medical schools through the Association of American Medical Colleges (AAMC) curriculum database, CurrMIT2, and connectivity to course and teacher evaluation processes. Ilios was jointly developed by the SOM‘s Office of Educational Technology (OET), whose vision is to develop a digital curriculum that enhances face-to-face learning, extends teaching and promotes lifelong learning, and the SOM‘s Information Services Unit (ISU). Ilios is currently licensed and used by eight health professions schools across the United States. Primary Objectives of this RFP are to: 1) Create a web-based-solution that supports community, collaboration and sharing of all medical education knowledge based resources, which can be used by other medical schools and beyond medicine in health science education. 2) Provide improved access to planned curriculum and schedules to instructors, learners, staff and public users. 3) Provide improved access to learning objectives, curricular themes, course/program schedules and learning materials to instructors and learners, who are teaching and learning across disparate geographical locations. 4) Manage an ever-growing number of digital learning materials so they can be protected, accessed, tracked and incorporated into any teaching session. 5) Develop a complete and accurate picture of a complex four/five-year health science curriculum in order to identify gaps, reduce unintentional redundancy, improve integration, and satisfy important requirements for accreditation. 6) Manage learners and instructors in groups so they can be efficiently assigned to any teaching session. 7) Index the curriculum using an international standard for fast, reliable retrieval of data and for comparison across other health science schools and the published medical literature. 8) Customize and maximize on content rolled over from one academic year to the next. 9) Capture basic teaching hours effort. 10) Provide ability to leverage data from/to other campus‘s authoritative data sources via combination of web services (API‘s) and XML feeds. 11) Continue to share curricular data with AAMC‘s CurrMIT database in a cost and time efficient method. 12) Provide state-of-the-art reporting. The new web solution will use best of breed Web 2.0 technologies and services to improve the end-user experience and provide for rich user contribution and community building functions. Much of the current functionality will be maintained in the new system, however, the processes and technology will be completely new and redefined. SOM is looking for a partner who is willing to stretch their thought processes and become creative and innovative while developing this solution. 1 2 WebCT is the Learning Content Management system used at UCSF http://www.webct.com/ CurrMIT (Curriculum Management Information Tool) http://www.aamc.org/meded/curric/start.htm 1 Key success criteria are: 1. 2. 3. The new solution should be written in a modern language (.NET, Java/J2EE, PHP) and should be a scalable, flexible, and highly-available system. The solution must allow rapid integration of new components in the future and the ability to replace or upgrade existing components as required. The current database design has been architected to allow for growth and flexibility. Ideally, the new database design will leverage this current design wherever possible which will reduce the complexity of any legacy data migration issues and keep design costs to a minimum. The new solution will have a modular application design to facilitate integration with other applications. The system will need to support integration with in-house-developed and third party applications. 4. Current application can be found at: https://www.medschool.ucsf.edu/ilios_public/index.aspx 1.2 Definitions AAMC Association of American Medical Colleges BIDDER Company proposing to sell an online curriculum management tool to UCSF in response to this Request for Proposals (RFP) CONTRACT The contract document to be furnished to Seller by University jurisdictional personnel which specifically describes goods and/or services to be covered under this RFP process. CONFIDENTIAL INFORMATION Shall mean the information identified in Exhibit 1, Security Policies and Project Background section 1.3. Shall also refer to any source code or sensitive or private information transferred to the successful bidder upon award of the contract. CurrMIT AAMC‘s Curriculum Management Information Tool DAYS Calendar Days EFFECTIVE DATE Is as defined in the preamble in this Agreement Existing Customers Existing Health Science Education Institutions external to UCSF who have licensed and deployed Ilios. FERPA Family Educational Rights and Privacy Act GME Graduate Medical Education HEAL 2 Health Education Assets Library HIPAA Health Insurance Portability and Accountability Act Ilios The UCSF School of Medicine‘s Online Curriculum Management Too. Also referred to as the current system or current application. iROCKET UCSF School of Medicine‘s digital curriculum ISU UCSF School of Medicine Information Services Unit LOM Learning Objects Metadata MeSH Medical Subject Headings: Standardized vocabulary used by the National Library of Medicine to index the health science literature. OET UCSF School of Medicine Office of Educational Technology PRODUCT The proposed Online Curriculum Management Tool also referred to as the proposed solution. POTENTIAL CUSTOMERS Health Science Education Institutions external to UCSF who would be potential customers of a new solution. SOA Service oriented architecture SOM UCSF School of Medicine REGENTS OF THE UNIVERSITY The terms "University", "University of California, San Francisco", "UCSF", "Buyer", "Department", ―Office of Chancellor‖ and "Regents of the University of California" are used interchangeably herein and refer to the same entity: Regents of the University. SELLER The term "Seller", "Supplier", "Contractor", ―Bidder‖, "Respondent", "Provider", ―Consultant‖ and "Vendor", are used interchangeably herein and refer to the same entity, the provider of goods and services to the University. SOLUTION The proposed Online Curriculum Management Tool UNIVERSITY UCSF as an entity or any person affiliated with UCSF 3 USER Any users including UCSF Faculty, Staff, students, public, etc. WebCT Course Management System currently in use at UCSF. WARRANTY Vendors warrants to UCSF that commencing from the date of final deployment of proposed solution and continuing for a period of one year: that the furnished solution to be free of defects and workmanship under normal usage and service and conforms in all material respect to the agreed upon specifications for the solution, and any applicable equipment on which it resides, which have been delivered to UCSF in connection with the proposed solution in this RFP. WORK "Work" shall include all obligation, duties, requirements, and responsibilities required for the successful completion of the Contract by the Seller, including the furnishing of all supervision, labor, materials, equipment and other supplies, incidental with the execution of the Contract and in accordance with the terms and conditions set forth in the Contract. 4 1.3 Project Background 1.3.1 History Ilios is a curriculum content management system created by the University of California, San Francisco‘s School of Medicine (SOM). It was originally developed to facilitate discussion and collaboration among instructors and departments as the School of Medicine undertook curriculum reform that entailed a shift from traditional discipline based course structures to a broader focus on the integration of basic, clinical, and social sciences, and working with learners as a class cohort rather than single learners who take classes on an a la carte basis. Originally conceived as a curriculum management system that would enable instructors and staff to have an overview of course offerings and their relation to the new curriculum, Ilios rapidly evolved to become a full-fledged curriculum content management system, delivering curricular materials directly to learners and instructors. In addition to the standard functions of a data-driven web application, Ilios users can upload teaching files, such as Word documents, PDFs, and images. These documents can then be associated with teaching sessions and accessed, by learners and registered users, through the web interface. Ilios also strengthens and reinforces strong teamwork, promoting oversight, revision, and evaluation of the curriculum, and making critical contributions to instructor and learner development. The School‘s instructors and educational leaders now say that it is inconceivable for the curriculum to operate without Ilios. Ilios is recognized nationally as an extremely flexible and easy-to-use curriculum management tool for medical education. Health Science Institutions, from within the University of California system and around the country, have implemented Ilios to promote their own educational innovations and teaching mission. Ilios has also garnered two significant awards. In 2004, UCSF SOM‘s Ilios developers won the University of California Larry L. Sautter Award for Achievement in University Computing. In 2007, UC Davis School of Veterinary Medicine, which licensed Ilios in 2005, was also awarded the Larry L. Sautter Award for Innovation and Entrepreneurship in Information Technology for their product VIPER (Veterinary Information Portal and Educational Resources), part of which is based on Ilios. 1.3.2 System Architecture The existing Ilios application was developed by and is maintained by the School of Medicine‘s Information Services Unit (ISU). It is a Classic ASP application built for IIS with a SQL Server backend. However, there are peripheral pieces built in VB6, Crystal Reports, and ASP.Net. Ilios spans three physical servers: a web server, a database server, and a file server. All three are running Windows Server 2003, with all the latest security updates, and the .NET Framework version 1.0.3705. Ilios has not been tested with the newer .NET Framework 1.1. The web server is running IIS 6.0 and the database server is running SQL Server 2005. Ilios uses ASP Upload, a third-party active-x control, to handle the document upload functionality. Ilios also contains many peripheral functions that contribute to the overall success of the application. There are three custom Visual Basic 6 applications that facilitate the integration of data. For example, we use both SQLXML and SAXX to import (MeSH terms from National Institute of Health‘s National Library of Medicine website) and export XML (course data consistent with the CurrMIT schema from the AAMC). Ilios uses ASP.Net with Crystal.Net to generate reports of teaching hours by department. Finally, Ilios generates SMTP email, such as teaching reminders sent to instructors, via a customized version of a freeware Winsock active-x control and our Exchange email server. Although the current version of Ilios running in SOM is Version5, only Version2 is made available to external customers. Technical or customer support is not provided to external customers. Please refer to Exhibit 1 for a diagram of the current System Architecture and differences between Version5 and Version2 5 1.3.3 Current System Gaps 1.3.3.1 Structure The UCSF SOM curriculum is made up of pre-clerkship (Essential Core) and clerkship (Clinical Studies) components. The Essential Core constitutes the first 18 months of medical school and consists of nine interdisciplinary block courses organized around central themes or organ systems. The Foundation of Patient Care (FPC), a longitudinal clinical and interviewing skills course, runs in parallel to the other block course for both years. Each block course is offered once throughout the year and the curriculum is primarily lectures, small groups and labs which are scheduled in advance and occur at predictable times and locations. The Clinical Studies curriculum is offered to 3rd & 4th year learners and is more fluid and less predictable, and hence more difficult to capture in an application as the majority of the learning (>80%) is based on participatory learning experiences in the clinical setting. These experiences can change from day to day, hour to hour based upon what types of patients or learning opportunities are present. The clinical curriculum is also offered at many different sites, across the bay area and Northern California, and the same curriculum is repeated many times during each academic year for different cohorts of learners. Ilios was originally developed to primarily capture the Essential Core curriculum and now needs to be enhanced to facilitate administration of the Clinical Studies Curriculum and also similarly structured components of the GME Curriculum3. Ilios is currently composed of six types of components: Courses, Sessions, Cases, Independent Learning Modules, Learning Materials, and Publication Citations. Courses consist of teaching sessions offered at certain times and locations. Within Sessions, learners have access to curriculum modules, such as cases and Independent Learning Modules, which are composed of Learning Materials assets, such as publications, and learning outcomes, such as objectives and concepts. The new solution will allow new types of components to be added easily, and automatically take advantage of much of the application‘s core functionality, such as the ability to attach keywords, objectives, and disciplines. A new Program component will be added at the highest level. A program may represent one or many related courses. 1.3.3.2 Scheduling/Calendar The calendar is at the heart of the Ilios interface, and represents the primary point of contact between most users and the application. In the current system, users view the calendar by Course. Sessions for that course, and for certain other Courses designated by an Administrator, appear on the calendar. The calendar view shows a time grid of onehour blocks, divided into fifteen-minute increments. All sessions for the course are represented graphically on the calendar in exact relation to the amount of time scheduled for that session. In addition, all sessions are color-coded to represent their type. In this way, users have a precise graphical overview of the actual relation between sessions in terms of time and type. The new solution will offer user-centric calendaring and the ability to view the calendar across courses or programs and provide calendar updates via RSS and/or CalDAV into the user‘s favorite web portal, personalized homepage or calendaring application. 1.3.3.3 Security Ilios contains both a public and a private web interface. Anyone can browse the Ilios website to view course calendars and search summaries of Ilios‘s vast catalog of published sessions. In order to see the details or to get 3 Graduate Medical Education: The period of didactic and clinical education in a medical specialty which follows the completion of a recognized undergraduate medical education and which prepares physicians for the independent practice of medicine in that specialty, also referred to as residency education. (http://acgme.org/acWebsite/about/ab_ACGMEglossary.pdf) 6 access to the actual files, a person must log on. Once logged on, access is controlled at a very granular level. Learners may view materials relevant to their courses while Instructors can view all published materials, but edit only information associated with their courses. More rigid security needs to be provided to comply with Family Educational Rights and Privacy Act (FERPA) and to ensure learners can only see learning materials linked to courses they are assigned to. 1.3.3.4 Data Availability All components in Ilios are created in draft mode. While in draft mode, the component is only available to course developers, course directors, and Ilios administrators. Draft components do not need to meet all data integrity rules to be saved, allowing a user to create, edit, and prepare a component over multiple sessions. Once a component is complete, the user can mark it as ―Published‖. Published components are available to all Ilios users and summaries of published components are available to the public. Another method users have to control data availability is release dates. Components can have release dates for each course and session to which they are attached. This allows course directors and developers to keep even published components hidden from learners until the release date has passed. Since a single component can have multiple release dates, learners from one course might have access to a case that learners in another course cannot yet see. Currently it is difficult to determine the draft/published status for objects in Ilios. The new solution will provide improvements to the user interface as well as tools, such as a user dashboard to enable users to better manage the draft/publish status of content. 1.3.3.5 Course Rollover As courses and course schedules, content, and instructors are fairly consistent from year to year, Ilios contains a mechanism to copy a course into the next academic year. This rollover greatly simplifies the process of preparing a course. Instead of recreating the course from scratch, all the users have to do is delete old, unnecessary content and enter any new data. The rollover copies all user security settings, sessions, and learning materials for the course. The new course is marked as ―draft‖ so that it will not appear to the public until it is ready to be published. Also, the rollover includes an algorithm that preserves the day of the week for sessions. A version-history is maintained for everything that is copied which allows users to track the creation and modification of objects and also allows administrators to rollback a rollover if there are issues. This functionality will be enhanced in the new solution by offering users the ability to select which components should be rolled over so that all or a subset of the program or course content can be rolled over. 1.3.3.6 Instructor & Learner Enrollment & Group Management Ilios provides administrators with the ability to create groups within a course. This functionality enables course administrators to easily and efficiently assign instructors and learners to courses. Each time a course offering is made, the administrator does not have to reselect the list of learners and instructors assigned to that course offering. The new solution will offer a more flexible group management module that can be applied at the Program or course level. The new solution should incorporate appropriate group and enrollment standards such as the IMS Global Learning Consortium standards.4 1.3.3.7 Data Integration Ilios data is currently compatible and integrated with AAMC‘s online CurrMIT database via XML, but Ilios is also designed for future integration with other data systems. The database is consistent with both the IMS/Dublin Core 4 The IMS Global Learning Consortium develops and promotes the adoption of open technical specifications for interoperable learning technology [http://www.imsglobal.org/]. Enterprise Information Model specifications can be found here: http://www.imsglobal.org/enterprise/eninfo03.html 7 Metadata Guidelines and the IMS LOM (Learning Objects Metadata) schema. As The Health Education Assets Library (HEAL) database is also based on LOM, Ilios learning material data is compatible with the HEAL system. This solution will maintain the above integration capabilities and also provide improved integration within the existing computing environment at UCSF, such as the ability to send to and receive data from a variety of existing systems. For third party integration requirements please refer to Third Party Interfaces. 1.3.3.8 Ad-Hoc Querying and Reporting Although Ilios contains numerous reports, it proved impossible to anticipate and create every report that users may want. Therefore, we built an ad-hoc query interface to the SQL Server database. As the database is designed for maintainability, extensibility, and speed, and not for simplicity, it can be daunting for novice query writers to find the data they may need. While users of the ad-hoc interface may query any table in the database, we built a number of views specifically designed to simplify the database structure, particularly to help traverse the complex hierarchical relationships of the various Ilios components. The new web solution will provide a powerful, state of the art reporting interface. 1.3.3.9 Learning Materials Management Ilios includes a management system for digital learning materials. Built on IMS/HEAL standards for management of digital learning materials, the repository manages citations, files and URLs. The materials can be incorporated into any teaching session as a required or supplemental exercise along with instructions to the learner. Materials can be easily used across teaching sessions and even courses, minimizing the need to duplicate and recreate materials from course to course and year to year. Instructors can upload their materials to Ilios and designate if the material is a required or supplemental part of the course. Once learning materials are published instructors have the ability to choose ‗selective release‘ dates. The new solution should also provide:  Users the ability to choose who the learning material is available to at a group or at an individual level.  Media display tools, such as embedding media content in line with our curricular data, instructions, etc.  Learners with the: o Ability to add learning materials & content o Ability to rate, tag & comment on content (sessions, cases, learning materials, etc.) o Views of learning material usage data  The ability to receive updates on learning materials additions/modifications via RSS feeds 8 2 2.1 2.1.1 GENERAL REQUIREMENTS, TERMS & CONDITIONS Contract Period Initial Contract Period The University is estimating this agreement to be a six to twelve month engagement. The initial agreement period is estimated to commence on or about May 2008, and end on or about April 2009; however, this may change due to early completion or delays which are unknown at this time . 2.1.2 Contract Extension The University reserves the right, and Seller, as condition of this solicitation, agrees to allow the University the option to extend, solely and at its discretion, this contract term for an undetermined period of time required to complete the project as determined by the University in one (1) month periods, at the same pricing basis, terms and conditions as proposed to the University in the vendor‘s response. The University at the time of execution of this option, if exercised, will inform the vendor(s) of the estimated number of month(s) the University expects to use the services of the vendor(s) on this project. 2.2 Estimated Value The Department considers this engagement to have significant value in meeting the needs and goals of UCSF. The successful vendor is expected to be an expert in their field, with sufficient time, experience and resources in this type of engagement to bring considerable insights and methodologies to conduct this project in an efficient and innovative manner incorporating established technology with cutting edge innovation for future requirements. 2.3 2.3.1 Price Pricing Structure In consideration of services as specified and detailed in this RFP, respondent will provide UCSF a detailed rate for providing these services. This rate shall be all inclusive of aspects of the services herein described. Any variables or additional services deemed as value added by the vendor shall be clearly described along with their underlying assumption for inclusion in the vendor‘s response. Charges for additional / value added services, if applicable, shall be clearly labeled and identified as such. The intent is to determine the value of the optional services to the overall project, and if the cost benefits analysis, as determined by the department, warrants these services being included in this agreement. 2.3.2 Pricing Certification Vendor certifies that pricing submitted in response to this Request for Proposal shall be valid for a period of not less than one hundred twenty (120) days after the close of this RFP process (Certification sheet to be signed, page 23). 2.3.3 Total Cost of Ownership Total (lifetime) cost of ownership, including acquisition cost, ancillary licenses required (e.g., for database management systems) and on-going maintenance is an important consideration. While UCSF realizes that the cost 9 of maintenance depends on many factors, Bidders are expected to provide justified cost estimates by citing actual costs from comparable projects. Please provide both a clear narrative and cost figures as outlined in Exhibit 4 and then fill in the table with cost figures, including development costs and the rates that would be charged for each of the application functionality and specification areas as outlined under Scope of Work below and Exhibit 4: Application Software Development, Training & Installation Costs Worksheet. Describe and itemize types of human resources that would be assigned (time and salary), and any materials. 2.4 2.4.1 INVOICING Payment Terms Invoice(s) will be paid within Net 30 days. 2.5 2.5.1 SCOPE OF WORK Purpose This RFP process is seeking to locate a Bidder who can deliver an online curriculum management tool to the UCSF School of Medicine, with the option of supporting existing and potential external customers. This system should be, flexible and capable of embracing new technology in support of health science curriculum management. UCSF expects the Bidder‘s solution to already meet the standard requirements that follow, or for the Bidder to be able to respond to the RFP questions with specific proposed solutions that the Bidder would develop and build. UCSF expects that the successful vendor will not only have an innovative solution to our requirements but will incorporate the University‘s ideas and suggestions in their final submittal and will be willing to adjust and modify the design as appropriate. 2.5.2 General Requirements The following topical areas form the basis upon which the vendor‘s response will be evaluated. Application Functionality & Specifications Application Functionality—Managing Curriculum Content for a Program/Course/Sessions Application Functionality—Managing Curriculum Schedules (offerings) Application Functionality—Group Management Application Functionality—Learning Materials Management Application Functionality—Email Notifications & Reminders Application Functionality—Instructors‘ Dashboard Application Functionality—Learners‘ Dashboard Application Functionality—Course Rollover Application Functionality—General Administration Application Functionality—Reporting Interfaces Software, Hardware, Operating Systems, and Security 10 Implementation and Training Services, and Database Maintenance Vendor Experiences and References Key Staff and Organizational Chart Vendor Financial Information Pricing 2.6 2.6.1 GENERAL CONDITIONS Time of Essence This project is extremely time sensitive and as a result the ability of the vendor to engage quickly, efficiently and accurately is vital to the requirements and goals of the University. It is essential that the vendor identified for this project be expert in their professional abilities to assess and understand the needs and requirements of the University and to provide a clear and comprehensive response to this RFP. 2.6.2 Key Staff and Organizational Chart Supplier shall submit to the University an organizational chart, listing key staff that would be assigned to the project which is the focus of this RFP. Along with the chart, the resumes of key staff proposed to be working on the UCSF project should be submitted (e.g., technology lead, project manager(s), highest-level developers, etc.) and the percentage of time projected for them to be working on the UCSF project, along with their rate of pay. Other projects (outside of the UCSF project) these staff would be working on, and their time on these, should be included as well. Staff assigned to the UCSF project shall be subject to the review and acceptance of the University. 2.6.3 Insurance Requirements Supplier shall provide University with certification, by a properly qualified representative of the insurer that Seller's insurance complies with the requirements of this section. In addition, such certification shall describe each of the coverage depicted on the attached Appendix A, page 3 of 3 as either on an "occurrence" form or a "claims made" form. All insurance policies required shall be issued by companies who hold a current Policyholder's Alphabetic and Financial Size Category Rating of not less than A XIII according to Best's Insurance Reports. Seller's obligation to maintain the insurance required herein and to provide evidence of same shall survive for a period of no less than five (5) years beyond the termination, cancellation, or expiration of this Agreement. If Seller's insurance coverage are on "claims made" form, Seller agrees to maintain such insurance and to provide University with satisfactory evidence thereof for the period. Seller hereby agrees that no payment shall be made by the University until University is in receipt of Seller's insurance certificate. All insurance coverage and carriers are subject to the approval of the University. 2.6.4 Record Keeping and Auditing This contract shall be subject to the examination and audit of the Auditor General of the State of California and UCSF Campus Procurement and Business Contracts for a period of three years after final payment under this order. The examination and audit shall be confined to those matters connected with the performance of the contract, including, but not limited to, the costs of administering the contract. Until the expiration of four years after the furnishing of the services provided under this contract, Seller will make available to the Secretary, U.S. Department of Health and Human Service, the U.S. Controller General, and their representatives, this contract and all books, documents and records necessary to certify the nature and extent of the costs of those services. If Seller carries out the duties of the contract through a subcontract worth $10,000 or more 11 over a 12 month period with a related organization, the subcontract will also contain an access clause to permit access by the Secretary, Controller General, and their representatives to the related organization's books and records. 2.6.5 Terms and Conditions The terms and conditions applicable to any subsequent contract derived from this RFP are those contained hereon, any additional negotiated terms, revisions or extension and those terms contained in Appendix A, B and Appendix C. Any different or additional terms contained in Seller's purchase acknowledgment, or other document(s), are unacceptable to the University and are hereby rejected. 2.6.6 Termination of RFP Process or Ensuing Contract This RFP process and any resulting contract may be terminated by University or Seller for convenience in whole or in part at any time in accordance with the terms of Article 4 of the attached Appendix A as amended above. In the event of such termination, both parties agree to provide at least five (5) days prior written notice of the effective date of termination and the extent thereof. If within five (5) calendar days of receipt of written notice to Seller from University of Seller's breach of any term or condition of this contract, Seller shall fail to remedy such breach, then University may, by prior written notice, terminate this contract in whole or in part at any time. In addition to other remedies described in Article 4, it should be understood that future contracts with the University may be limited or withheld completely, pending re-establishment of an acceptable record by Seller. 2.6.7 Additional Terms and Conditions Respondent shall notify University within ten (10) days of any substantial change inownership of its company, and University will thereupon have the right, but not the obligation, to terminate this Agreement. It is mutually understood and agreed that no modification to the terms of this Agreement shall be valid unless made in writing and executed by both University and Respondent. The terms and conditions of this Agreement shall remain in full force and effect if a part of this Agreement is held unenforceable in an action proceeding, or arbitration. Upon termination or expiration of this Agreement, patient records provided to Respondent shall be returned to University or a certificate of destruction provided within fifteen (15) days of the termination or expiration date without assessment of any commissions, fee, or charges. This Agreement supersedes any prior Agreement, written or oral, which may exist between the University and the Respondent regarding the auditing of patient(s) billing files. 3 3.1 3.1.1 INSTRUCTIONS TO BIDDERS Quotation Due Date and Time. Submittal Process On or before 1:00 PM Pacific Time, Friday April 4, 2008, submit four (4) copies [one (1) signed original and three (3) copies] of your proposal to the University of California, San Francisco Campus Procurement and Business 12 Contracts at the address listed on the Cover Page. Additionally, one (1) electronic copy on CD-Rom is required as a submittal. In keeping with University policy to reduce use of paper, please keep your submittal to required responses. Late Proposals will be NOT be Accepted 3.1.2 Responsive Proposals Your proposal must be complete, signed, submitted on the forms provided, and comply with the specifications and legal requirements. Proposals made on other forms, paperwork, etc. will be rejected without further consideration. All information furnished on the proposal must be typewritten or written in ink. Additional information may be submitted as attachments; however; alternative proposals (not in conformance to this document) will not be considered for award. All attachments must specify the section and question being addressed. 3.1.3 Required Information and Data An online demonstration of the existing Ilios application will be offered to bidders on Thursday March 20, 2008 from 1-3pm PST. Instructions for accessing the online demonstration will be sent out to interested bidders by Monday, March 17th. Participation in the online demonstration requires the completion and submission of Appendix C: Nondisclosure Agreement to Tanya Krupsky, Procurement Specialist (415-502-3015/Fax 415-502-3031 tkrupsky@finance.ucsf.edu) by 5pm, Wednesday, March 19, 2008. Shall be furnished as requested. Vendor shall refer to the attached appendices and exhibits to ensure they have completed all required information for submittal. 3.1.4 Caution to Respondents Respondent is cautioned not to delete or make changes in provisions, terms or specifications of this proposal, as such changes may render your bid non responsive. 3.1.5 Withdrawal or Modification of Bids Proposals may be withdrawn or modified by a written or faxed request from respondent no less than three (3) days prior to the time fixed for receiving the RFP. The University may, by written notice to all respondents, amend the Request for Proposal prior to the due date. If, in the opinion of the University, the revisions or amendments will require additional time for a response, the due date will be extended to all participants. If revisions and amendments are not furnished to the respondents prior to the due date, proposals shall be considered withdrawn and the process shall be reinitiated without further discussion. Questions and responses of any one respondent, which the University deems may affect or cause an ambiguity in bid responses received, will be supplied to all bidders by addendum. The University reserves the right to negotiate minor exceptions, irregularities, or errors taken by respondent in this RFP. These errors may be negotiated with or corrected by the vendor involved provided that, in the judgment of the Director of Campus Procurement & Business Contracts or designee, such action will not negate fair competition and will permit proper evaluation of proposals received. 3.1.6 Bid Results 13 Bid openings are not public. An Award Summary will be made available to bidders, upon their written request, after the award of the contract. 3.1.7 Submittal Costs University is not liable for any costs incurred by prospective respondents. Respondent is responsible for all costs associated with information, proposals, visitations & demonstrations and personnel furnished to comply with this RFP or any subsequent request before issuance of a contract. 3.1.8 Contacts with UCSF Management For technical and commercial queries regarding this Request for Proposal (RFP) contact: Tanya Krupsky, Procurement Specialist 415-502-3015/Fax 415-502-3031 tkrupsky@finance.ucsf.edu For technical queries following award of the contract and throughout its duration, contact: Chandler Mayfield, Assistant Director, Learning Technologies UCSF School of Medicine, Office of Educational Technology 415/502-2800, chandler.mayfield@ucsf.edu Respondents can send questions related to this RFP to Tanya Krupsky via e-mail up until Friday, March 28, 2008. The PMO will later issue an official response to address all Bidders‘ questions. 3.1.9 Disclosure of Records/Confidentiality of Information This RFP, and one copy of each original response received, together with copies of all documents pertaining to any award, if issued, shall be kept by UCSF for a period of five years from date of contract expiration or termination and made a part of a file or record which shall be open to public inspection. If your response contains any trade secrets that you do not want disclosed to the public or used by UCSF for any purpose other than evaluation of your approach, the top of each sheet of such information must be marked with the following legend: "CONFIDENTIAL INFORMATION" All information submitted as a part of that bid must be open to public inspection (except items marked as trade secrets and considered a trade secret under the California Public Records Act) after the award has been made. Should a request be made of UCSF for information that has been designated confidential by the bidder and on the basis of that designation, UCSF denies the request for information; the bidder may be responsible for all legal costs necessary to defend such action if the denial is challenged in a court of law. 3.1.10 Respondent Certification The respondent certifies that: 1) the prices and terms specified in this Request for Proposal represent the most favorable that will be offered any University of California location; 2) the respondent agrees, if not awarded an order as a result of the proposal submitted, not to solicit business from any University department for the services listed 14 on this Request for Proposal at lower prices or better terms than specified in the proposal; and 3) the respondent understands that violation of any of the above shall be grounds for disqualification on future bids. Respondent certifies that the only persons or parties interested in this Request for Proposal (RFP) as Principals, are those named herein as Seller; that this RFP is made without collusion with any other person, firm or corporation, either directly or indirectly, or taken any action in restraint of free competitive bidding; and in submitting this RFP respondent has examined instructions, terms and conditions and specifications of this RFP. Respondent proposes and agrees to execute and fully perform in accordance with any proposal offered to the University. 3.1.11 Penalty for Collusion If at any time it shall be found that the person, firm or corporation to which a contract has been awarded has, in presenting a proposal, colluded with any other party or parties, the contract so awarded shall be null and void and the seller shall be liable to the University for all loss or damage which the University may have suffered. 3.1.12 Bid Acceptance Period. As a condition of participating in the Request for Proposal your bid response must be valid for one hundred twenty (120) days from the Request for Proposal Due Date. 3.1.13 Rejection of Bids The University reserves the right to accept or reject proposals as a whole, without further discussion. Exceptions taken to the terms of the Request for Proposal may result in rejection of the bid as being non-responsive. Bids that are incomplete will be considered non-responsive to this solicitation and may be rejected without further consideration. If, in the opinion of the University, the solicitation does not result in reasonable prices to the University considering price and cost factors associated with the acquisition of required services, then all bids shall be rejected. All participating respondents shall be notified of the rejection, the reasons for the rejection, and advised of the disposition of the requirements. The University may reject a bid of any party who has been delinquent or unfaithful in any former contract with the University. 3.1.14 Award Schedule The University will make all efforts to award contract before the effective date described herein. In the event award is not made prior to the described date, the University reserves the right to set the actual contract period without separate notification to bidders. 3.1.15 Business Information Form Complete and submit the form in Appendix B (University of California Vendor Set Up Form / Substitute W-9 Form) only if your firm is awarded a contract as a result of this RFP proceeding. 15 3.1.16 Proposal Protest Any actual or prospective vendor or contractor who has a complaint regarding the solicitation or award of a contract should first attempt to resolve the grievance with the Buyer, Procurement Manager or Executive Director of Campus Procurement & Business Contracts involved in the transaction. If the controversy over the solicitation or award of a contract cannot be resolved at this level, the complainant may file a protest or notice of other controversy with the Senior Vice Chancellor – Finance and Administration. A protest or notice of other controversy shall be filed promptly and in any event within two (2) calendar weeks after such complainant knows or should have known of the facts giving rise thereto. All protests or notices of other controversies shall be in writing. The Senior Vice Chancellor – Finance and Administration Services shall appoint individuals to investigate the issues involved in the complaint, analyze the findings, consult with General Counsel, and promptly issue a decision in writing. A copy of that decision shall be mailed or otherwise furnished to the aggrieved party and shall state the reasons for the action taken. In the event of a protest timely filed, the University shall not proceed further with the solicitation or award involved until the protest is resolved or withdrawn unless the Senior Vice Chancellor – Finance and Administration consults with General Counsel and makes a written and adequately supported determination that continuation of the procurement is necessary to protect substantial interests of the University. It is expected that any decision to proceed with the solicitation or award prior to the University's resolution of the protest will occur infrequently. Such circumstances include but are not limited to: 1. When the award of an extramurally funded contract or grant would be jeopardized, or when a material breach or significant delay in timely performance of an extramurally funded contract or grant would result. 2. Contracts for repair, operation and maintenance of equipment used in scientific and medical research projects, food service operations, waste removal, building systems (e.g., utilities, elevators, heating, air conditioning, security, etc.), voice and data communications, and computers, provided that the lack of such contracts would substantially interfere with the University's functions in these areas. 3. 4. Equipment, supplies, or services directly or indirectly related to patient care. Equipment, supplies, and services required for scheduled events (e.g., classes, public functions, athletic events) when absence of needed material could result in cancellation or rescheduling the programs and events. The responsible University official shall document in the contract file, in detail, the reasons for proceeding prior to resolution of a bid protest. Written notice of the decision to proceed shall be given to the complainant and others concerned with the transaction. 16 4 4.1 EVALUATION FACTORS& BASIS AWARD Evaluation Criteria Submittals will be evaluated and awarded as described below: A subset of requirements (1A-1D, below) is deemed mandatory and if not adequately addressed in the Bidder‘s proposal may disqualify the Bidder from participating further in the bidding process. 1. Supplier and System Qualifications a. b. c. Supplier must be able to offer an online curriculum management tool. System must meet the application functionality and specifications outlined in Section 2 General Requirements above and details set forth in Exhibits 1 and 3. Sufficiency of the offer. All specifications and requirements of this RFP, unless otherwise noted, must be met without exception. The University shall be the sole judge in determining whether a submittal meets qualification requirements. The respondent must be in possession of all applicable licenses. The respondent must provide all other documents specified herein. The respondent must be able to provide required verification of insurance coverage. Documented evidence of ability to perform the tasks as herein described d. e. f. g. Only bids from respondents determined to be qualified as described above will be given consideration for award. Furthermore only bidders meeting the qualifications listed above will be invited to present their proposed solutions. 2. Weighted Score Weighing factors for the RFP will be respondent‘s data responses and references. The sum of points for respondent‘s data responses and references equals the highest weighted score. The number of points assigned to each factor will be available from Tanya Krupsky, Campus Procurement & Business Contracts, after the bid closing date on April 4, 2008. A written request for this information must be made and submitted to address on the front of the RFP. 3. Vendor Demonstrations Those Bidders whose proposals are evaluated to be among the best RFP responses according to the evaluation procedure mentioned in B., below, will be invited to present their proposed solution at UCSF and if appropriate asked to provide a UCSF accessible demonstration environment. 4. Award Method After review of proposals, references and presentations a selection will be made. Awards will be made to the respondent with the highest weighted scores. One contract will be issued from this solicitation to the successful vendor. The successful vendor shall be offered a contract for the services herein described based upon the terms and conditions of this solicitation. Should the successful vendor fail to enter a contract with the University, the respondent with next lowest cost per quality shall be considered for award of the contract for the services. 4.2 Evaluation Procedure 17 1. The University may, at its option, contact vendor‘s customers for references, by telephone or other means and evaluate the vendor based on these references. University will ask such questions that will help to ascertain the manner in which service has been provided in other engagements. All responses will be reviewed by the Campus Procurement Department to determine compliance with administrative requirements (both process related and general requirements) in the RFP. Only responses meeting all of the general administrative requirements will be evaluated further. The University reserves the right at its sole discretion to waive minor administrative irregularities in a response. If responses fail to meet any single mandatory requirement, the University reserves the right at its sole discretion to do the following: a. cancel the solicitation b. re-solicit vendors with new requirements Responses meeting the General Requirements will progress to the next step at this evaluation. The University may contact vendor for clarification of the response. 2. 3. 4. Cost Per Quality Point Computation In order to determine the lowest cost per quality point, each bidder‘s response will be used to compute the cost per quality point using the method described below: 1. 2. 3. Each bidder‘s proposal will be used to determine the total cost of the service. Each bidder‘s response will be rated using a score sheet– Quality Point Score Sheet. To determine the lowest cost per quality point (CPQP), each bidder‘s total delivered cost will be divided by the Total Quality Points (TCP) (or average quality points) awarded to that particular bidder. For example, if the responses and points awarded are as follows: Total Cost Vendor # 1 Vendor # 2 Vendor # 3 $ 56,725.00 $ 63,659.00 $ 50,125.00 Quality Pts Awarded 525 600 325 Final CPQP 108.04 106.09 154.23 Vendor # 2 would have the lowest cost per quality point and would tentatively be the successful bidder. 4.3 References/Reference Checks To warrant consideration for the award of the contract, respondent must provide verifiably satisfactory reference checks. Respondent shall provide a reference to three (3) of your clients who use the same services specified herein; and must be (or has been) comparable to UCSF in terms of overall mission and academic standards, size of budget and financial standing: E1 Describe any experience you‘ve had in Higher Education, Health Sciences Education or applicable industry. Provide specific examples which demonstrate your company‘s ability to provide cutting edge, innovative technology solutions using best of breed technologies in a timely and cost-effective manner. List 3 references currently using your product(s). Supply the institution name, address, e-mail address, contact name and phone number and brief description of reference accounts. E2 E3 The references you furnish shall be asked to rate your performance either: 18 EXCELLENT: GOOD: POOR: Frequently exceeds standard requirements. Meets standard requirements. Frequently does not meet standard requirements. The areas of performance to be rated are: 1. 2. 3. 4. Meeting defined timelines and costs for deliverables. Quality and professional level of assigned staff to the project. Technical expertise of staff and ability to deliver service as specified. Customer Service Any respondent receiving a ―poor‖ rating from any reference check on any part of the criteria listed above may be eliminated from further consideration for the contract. The decision to reject a proposal for unsatisfactory references shall be at the sole discretion of the University and not subject to appeal. References must be listed in the spaces provided below. Reference Number One: Customer Name: ________________________________________________ Street Address: __________________________________________________ City/State/Zip Code: ______________________________________________ Contact Name/Title: ______________________________________________ Contact Telephone Number: ________________________________________ Description of engagement: ______________________ Type of Organization (Educational, Research, Government Entity, Corp.) _______________________ Reference Number Two: Customer Name: ________________________________________________ Street Address: __________________________________________________ City/State/Zip Code: ______________________________________________ Contact Name/Title: ______________________________________________ Contact Telephone Number: ________________________________________ Description of engagement: ______________________ Type of Organization (Educational, Research, Government Entity, and Corp.): ______________________ Reference Number Three: Customer Name: ________________________________________________ 19 Street Address: __________________________________________________ City/State/Zip Code: ______________________________________________ Contact Name/Title: ______________________________________________ Contact Telephone Number: ________________________________________ Description of engagement: ______________________ Type of Organization (Educational, Research, Government Entity. Corp.):_____________________ 20 5 SUBMITTAL REQUEST To be considered for an award, respondents must meet all the requirements listed below and answer all the questions without exception. The University shall be the sole judge in determining whether a respondent meets qualification requirements. The information set forth in this section should be included with the proposal. 5.1 Letter of Transmittal The Letter of Transmittal should reflect the Request for Proposal subject, name of the firm, address, telephone number, contact person and date of preparation. 5.2 Proposal The proposal should include: A. A statement of the contractor‘s understanding of the services required by the Request for Proposal and attached specifications. The contract must explain how it would provide these services to UCSF. B. The names of the persons who are authorized to make representations on behalf of the contractor (include their titles, addresses, telephone number and email address). C. A description of any comparable services performed by the contractor during the most recent five-year period similar in scope to the work set forth above. In particular, the contractor should highlight any experience with placements at institutions like UCSF, to include accredited universities, medical centers, etc. If the contract has provided services comparable to those specified in this RFP, provide a minimum of three (3) references. Provide complete addresses and telephone numbers of each reference, as well as the name, title and the telephone number of a contact individual. D. The contractor should include an outline of any additional services or alternative approaches that contractor feels is in University‘s best interest. E. The contractor should guarantee delivery of services in accordance with such delivery schedule as provided in the specifications. F. The bidder should explain the means, terms, and costs by which the University will gain access to complete, well-documented source code for the proposed solution delivered under the Contract. Note that the Contract must include an assignment to University of all rights, title and interests in any inventions and/or code, whether patentable or not, developed specifically for the University In addition to the information required as stated in this RFP, the University may request additional information either from the Bidder or others, to verify the Bidder‘s ability to successfully meet the requirements of this RFP. 5.3 5.3.1 a. ADDITIONAL REQUIRED VENDOR INFORMATION GENERAL VENDOR INFORMATION Full legal company name 21 b. c. d. e. f. g. h. i. j. Year company founded Brief company history Has it changed ownership(s) in the past? If so, when? Does another company own you? What other companies are you affiliated with? Current number of employees Average tenure of employees Is your company currently involved in any litigation that may result in a material change in the company? Does your company have a standard set of terms and conditions associated with the purchase of a license for your software? If so, please provide them in your response. 5.3.2 VENDOR FINANCIALS a. Has the vendor ever defaulted on a contract? If yes, explain. b. Vendor can truthfully state the firm has not been disqualified or barred from doing business with a public agency (e.g. federal, state, county, city, University of California System, California State University System, etc.) within the last four years. (TRUE/FALSE) c. Provide copy of the most recent audited annual report. d. Is company public or private?  If public, when was IPO?  If private, what % of company owned by founders?  If private, how much outside capital has been raised?  If private, when was the last close date for funding (and how much)? e. Is your company currently profitable? f. When did your company first become profitable? g. If not profitable, when do you expect to become profitable? h. What was your total gross revenue for 2007? i. What is your projected total gross revenue for 2008? j. Please add any documentation that would offer assurance of your financial viability In addition to the information required as stated in this RFP, the University may request additional information either from the Bidder or others, to verify the Bidder‘s ability to successfully meet the requirements of this RFP. 22 CERTIFICATION SHEET The undersigned, as Respondent, certifies that the only persons or parties interested in this Request for Proposal (RFP) as principals are those named herein; that this RFP response is made without collusion with any other person, firm, or corporation; and in submitting a response to this RFP, Respondent has examined instructions, specifications, and terms and conditions of the RFP. Respondent proposes and agrees to execute and fully perform in accordance with the instructions, specifications, and terms and conditions of this Request for Proposal. Respondent agrees that the offer to provide to the University the services described herein shall be valid for a period of one hundred twenty (120) days from the due date and time for receiving proposals. Type of Business: Corporation Partnership Individual doing business under his/her own name Individual doing business using a firm name Business Name of Respondent: Business Address: Street City State Zip Code Authorized Signature Type Name Title 23 6 ATTACHMENTS: Appendix A University Terms and Conditions Appendix B University of California Vendor Set Up Form Appendix C Nondisclosure Agreement Exhibit 1 System Requirements and Application Functionality Exhibit 2 Use Cases Business Processes for Modifying, Scheduling and Delivering Curriculum Exhibit 3 System Requirements and Application Functionality Checklist for Bidders Exhibit 4 Application Software Development, Training & Installation Costs Worksheet 24 7 Exhibit 1 System Requirements and Application Functionality The features and functionality listed below are expected of the new web solution. Please refer to and respond to Exhibit 3: System Requirements and Application Functionality Checklist for Bidders for a full list of system requirements. 1. Application Functionality Provide the following features:  Program/Course Calendaring o Ability to view user specific calendar o Ability to download calendar to user specified calendaring application (Google, yahoo, outlook etc) o View Calendar across multiple programs/courses o Url addressable views of calendar content Easy Sharing of Curriculum Modules Longitudinal curriculum monitoring and planning Draft and Publish Modes for all content Digital Learning Materials Management Built on IMS/HEAL Standards CurrMIT5 Data Export Easy Integration with Other Third Party Systems such as scheduling system, evaluations system or course/learning management systems. Advanced Searching Capability Customizable and user configurable email notification and reminders Customizable Content Archiving and Rollover Learner /Instructor Enrollment and Group Management Instructors dashboard which provides direct management of curriculum content o List and easily navigate to unpublished content o List and easily navigate to groups designations which have not been assigned o Notice board with broadcast messages, for example, if there has been a instructor substitution o Ability to correspond with other instructors (both within your course and external) o Assign sessions to certain instructors for review o Ability to set up email alerts and receive information via email or RSS feeds. o View schedules Learner dashboard o Support rich media source formats (for view & upload) e.g.  Active Streaming Format (.asf)  AVI video (.avi)  DV Stream (.dv)  QuickTime Movie (.mov)  MPEG-4 Movie (.mp4)  MPEG Movie (.mpg, .mpeg)  Windows Media Video (.wmv)  Flash Video (flv., fla.) o Support binary file upload (images, mp3, Windows Media, and other formats) o ―Talkback‖ (user-posted comments to content/materials with editorial review and workflow similar to blog comments)             5 CurrMIT (Curriculum Management & Information Tool) is managed by the Association of American Medical Colleges. [http://www.aamc.org/meded/curric/start.htm] 25   o Identify related materials by taxonomy, author, user, or other metadata o Rate an article o Request most accessed learning materials, etc. o View schedules Tagging content o Track competencies & objectives & assessment methods o Track hot-topics (AAMC) o Track primary, secondary or tertiary themes (e.g. ethics, patient safety) Wide-ranging searching and reporting capabilities. 2. Standards Ilios was built in conformance with several sets of standards for the indexing of medical curriculum information, subject information, and Web-based multimedia learning materials. Conformance with these standards allows researchers throughout the medical community to have access to information stored in Ilios, and greatly enhances the ability to generate information for curriculum review, accreditation, and other reporting functions. The new solution must conform to the following standards: 3. CurrMIT CurrMIT is the curriculum database of the Association of American Medical Colleges. Submission of curriculum information to CurrMIT is achieved through an XML export function. CurrMIT‘s reporting tools can then be utilized to generate analyses of the curriculum, including information needed for accreditation review. 4. MeSH MeSH is the National Library of Medicine's controlled vocabulary thesaurus. It consists of sets of terms and naming descriptors in a hierarchical structure that permits searching at various levels of specificity. Courses, sessions, cases, ILMs, and other curricular components in Ilios can have MeSH terms associated with them to facilitate rapid and efficient searching for content related to specific subjects. 5. HEAL/LOM/Dublin Core The IMS Global Learning Consortium develops and promotes the use of open technical specifications for interoperable learning technology. The Health Education Assets Library (HEAL) is a digital library of freely accessible, Web-based multimedia teaching materials that meet the needs of today's health sciences educators and learners. The ILIOS digital learning materials repository is built in compliance with HEAL standards based on the IMS LOM (Learning Objects Metadata) schema and with the basic data elements based on the Dublin Core Metadata Guidelines. 6. Third Party Interfaces The purpose of this section is outlined in the following two classes and must strictly conform to SOA principles. 1. Standard External Interfaces between the solution and outside systems or agents are associated with core functionality and adhere to a modern and standard web services standard. This would include normal HTML interaction with browsers and crawlers and similar functionality such as providing Google Maps, and RSS feeds. Non-Standard External Interfaces include all non-standard interactions with systems either inside or outside UCSF. These interfaces will be listed and briefly described below. 2. 26 Standard & Non-Standard External Interfaces include: First Release      Export evaluations data such as instructor name, location and session to the different evaluations systems via XML feeds or APIs. (data will be manually imported into the evaluations system) Complete integration with UCSF- SOM Educational Management Systems (ISIS, SSIS) XML feeds into CurrMIT Syndicate learning materials to HEAL, MedEdPortal6, and Library podcasting system and retrieve learning material meta data from PubMed. Provide means for users to access personalized dashboards from Course Management Systems (currently achieved through url addressing). Future Releases (This functionality should be considered but is not part of requirements for this proposal)  Integration with Course Management Systems - (Moodle, Sakai, Blackboard/WebCT)  Integration with Course/Room Scheduling Systems - Resource25, E*Value for eGME schedules  Complete integration with Evaluations Systems - E*Value Figure 3.3. Provides a diagrammatic view of all the possible components and interfaces for this new solution Fig 3.3. New Solutions Solar System 6 MedEdPORTAL is a system hosted by the AAMC that publishes peer-reviewed learning materials. 27 7. System Sizing Guidelines (As of 11/28/2007) This is a snapshot of data from the academic year 2006-2007. Ilios maintains curriculum data from the academic year 2001-2002 to the present.  21 courses (143 learners per course) o 14 core courses o 7 elective courses  1599 teaching sessions, such as lectures, small-groups and labs  32 self-paced learning modules  6759 unique learning objectives  2493 unique learning materials, including o 2345 files o 430 journal and book citations o 282 web sites (URLs) 8. Data Migration The new solution must include the migration of all legacy data from the old database and files from the file server. In addition, the new solution should provide the ability to upload data from spreadsheets if required for certain functions (enrollment, session creation). Although UCSF is currently running v5 of Ilios, only v2 is available to external clients. When migrating data for external clients, these difference need to be considered. Please see Exhibit 1 for differences in versions. 9. Web Development Web development must support integration with stand-alone, industry-standard source control systems. Versioning, revision control, and build-release principles must apply to all development and maintenance. 10. Open Architecture Beyond the initial set of features and standard services, the solution architecture should allow for the incorporation of new features through the use of services and components, both through third party products (buy) and native development (build). To ensure future growth and usability, all features and services must be built with a flexible sharing, reuse, and inheritance framework. The solution must support application programming interfaces (API) and web-services, both for consumption from external sources and for delivery to external systems. 11. Usability & Accessibility All tools should employ consistent information architecture and demonstrate best principles of human computer interaction. Web content accessibility guidelines and standards should be taken into consideration when designing user interfaces. Internal tools for web development and software engineering should support the use of industrystandard integrated development environments. 12. Current Data Size & File Server Guidelines (as of 10/31/2007) The database is composed of Full Text indexes and all data access is executed through stored procedures. The database is currently 200MB and includes the following objects: 28 DB Object Functions Stored Procedures Tables Triggers Views Qty 16 367 121 19 112 The production file server space currently used by Ilios documents stands at approximately 45 GBs. 13. Version 2 versus Version 5 Database Differences DB Object Functions Stored Procedures Tables Triggers Views Version 3 5 204 95 9 64 Version 5 16 367 121 19 112 Application Differences The application GUI has been modified quite dramatically since V2, and huge efforts have been made to improve efficiency and the user experience. The following functionality does not exist in V2     Group Management (for learners & Instructors) Personalized Calendars and ability to download Calendar views via .ics files. Enhanced Search and Reporting Interface Additional Reports Current System Architecture 29 Clent Email ISIS Client Tier Clent Browser HTTP WebCT Website AAMC CurrMIT Website NIH-NLM Website SMTP Upload XML Two Way Data Feed Exchange 2000 Web Server Application Server Application Tier IIS 6 HTML JavaScript ASP ASP.NET SQL-XML SAX XML Reader SOAP SDK Mail Server ASP Upload ADO.NET ADO SQLXMLOLEDB SQLOLEDB File Copy SMTP SQL Server 2005 Data Tier Send Mail Database Server Stored Procedures File Server Diagram of Ilios system architecture 14. Security Policies J2EE It is expected that the approach will conform to J2EE security standards for enterprise web application development. HIPAA HTTP Download HTTP (S) HTTP 30 At any medical institution data must be protected by and comply with the Health Insurance Portability and Accountability Act (HIPAA). HIPAA addresses the use and disclosure of individuals‘ health information—called ―protected health information‖ by organizations subject to the Privacy Rule — called ―covered entities,‖ as well as standards for individuals' privacy rights to understand and control how their health information is used. In the furture, the new system may need to interface with HIPAA compliant systems. However, the proposed solution will NOT contain any protected health information. FERPA All data must be protected by and comply with the Family Educational Rights and Privacy Act (FERPA). FERPA is a Federal law that protects the privacy of student education records. The law applies to all schools that receive funds under an applicable program of the U.S. Department of Education Non-Functional Requirements     99% uptime Response time – 2 second page load W3C(World Wide Web Consortium) compliance for browser compatibility o XHTML 1.0 Transitional o CSS 1 Mac and Windows browser compatibility supporting Firefox 2+, IE 6+, Safari 2+ Existing External Ilios Customers As of October 2007, eight health science professional schools7 have licensed and deployed Ilios (four University of California schools and three external schools). Existing customers should be provided with the option to upgrade to the new solution. Existing customers external to the University of California system should be offered the option to upgrade at a reduced cost to what new external customers would pay. The upgrade will consist of deploying the new solution and migrating existing historical data. Any modifications made to the data structure, user interface or integrations with other systems of their current licensed version of Ilios will not be migrated or preserved. Specific value-added services required to deploy the new solution as well as service and licensing fee structure will be determined in the future. 15. Software Development Software Development Environments The solution must institute a formal Software Development Environment (SDE). According to the Software Engineering Institute, SDE is ―a complete, unifying framework of services supporting most or all phases of software development and maintenance.‖ As part of this initiative, the SDE must encompass       Standard development, quality assurance (QA), staging, and production environments Defined and automated build processes Defined change management Defined release management Defined QA processes Detailed documentation such as: APIs, UML, coding standards, use cases, schemas 7 University of Alabama Birmingham School of Medicine, University of Arizona College of Medicine, University of Colorado School of Medicine, Texas Tech University Health Science Center El Paso, University of California Davis School of Medicine, University of California Davis School of Veterinary Medicine, University of California Los Angeles David Geffen School of Medicine, University of California San Diego School of Medicine. 31 Rapid Development Framework The overall solution needs to be constructed as a framework or integrate frameworks that inherently allow for rapid development, whether it is for proof of concepts, or at the enterprise level. To get a better understanding of such frameworks refer to the following:    http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse http://www.rubyonrails.org/ http://cakephp.org/ Device Compatibility The overall solution should incorporate, where possible, W3C mobile best practices 8 to allow for the browsing, updating and modifying content such as scheduling data or learning materials via mobile devices. 8 http://www.w3.org/Mobile/ 32 8 Exhibit 2: Use Cases: Business Processes for Modifying, Scheduling and Delivering Curriculum. Scenario #1 Actor: Course Director/Administrator Curriculum: Essential Core The Essential Core constitutes the first 18 months of medical school and consists of 9 interdisciplinary block courses organized around central themes or systems. The Foundation of Patient Care (FPC), a longitudinal clinical and interviewing skills course, runs in parallel to the other block course for both years. Each block course is offered once throughout the year and the curriculum is primarily lectures, small groups and labs which are scheduled in advanced and occur at predictable times and locations. Each block course integrates basic and clinical sciences with other aspects of the practice of medicine, including public health, epidemiology, and the social and behavioral sciences. Essential Core course administrator‘s currently use Ilios to prepare and offer their curriculum. Ilios supports some of these processes and not others. Those processes currently not supported are noted below. Course content and related sessions are rolled over by the application from the previous year Course administrator creates groups for each course and assigns these groups to sessions; each group is also assigned a room number. Each time that group is linked to a session the same room number is applied. 3. Course administrator creates session offerings for each group, (i.e. schedule dates for delivery of the content) 4. Course administrator assigns an instructor or faculty member to a session offering. 5. The system notifies the instructor of all the offerings they have been assigned to, the instructor can accept or reject that offering. If the instructor accepts, the system updates the offering as ‗instructor assigned‘, if rejected a notification is sent to the course administrator to reassign that offering to a different instructor and the cycle continues again. (Not supported) 6. Once instructors have been approved, learners are assigned to groups (via a spreadsheet) and the sessions are published. 7. Once published, the system will send notifications to the learners indicating which groups they have been assigned to and listing their session offerings. (Not supported) 8. Once the rooms have been assigned the system send an export to the room scheduling system. The course administrator can set up parameters on how often the room booking export should be sent. I.e. only after the session has been published. The export will include the list all offerings for that session. (Not supported) 9. Once the schedules have been approved, the course administrator may then edit and publish syllabus content. 10. When adding syllabus, course administrator may want to add the same learning materials to multiple sessions. (Not supported) 11. Course director will have the ability to set up teaching reminders for each session that will be sent to the instructors to remind them to upload their teaching materials. (Not supported) Scenario #2 Actor: Course Director/Administrator Curriculum: Clinical Core (or similar GME course) The Clinical Core runs for 54 weeks. It is comprised of six eight-week long clerkship periods. Three weeklong intersessions punctuate the clerkship rotations. Intersessions enable students to meet and exchange thoughts about their recent clinical experiences, further refine critical thinking skills, and explore more fully medical ethics, health systems, medical sciences, and evidenced-based medicine. The third year also includes the Longitudinal Clinical 1. 2. 33 Experience, which runs concurrently with the clerkships, meeting for half a day each week and giving students exposure to an out-patient clinical setting in a field of their choice Less than 20% of the clinical studies experiences are classroom-based, unlike the essential core. The new application will be able to capture the schedules, the supporting learning materials, and curriculum behind the schedules for these classroom-based experiences. For the remaining 80%, the application will help administrators to capture the learners schedule but the details of the experiences will not be known. For example if a learner is attending rounds from 8 a.m. to 10 a.m., the administrator will know the learner needs to be at a location at a certain time with general learning objectives, but will not know what types of experiences or patients the learner will have. Currently syllabus information for each of the 9 clinical core clerkships is stored in WebCT (iROCKET). Course directors place their learning materials, course handbooks, objectives, and assignments on this portal for students to access. Currently each clerkship director/administrator manages their clerkship schedules on spreadsheets. As students need to rotate between all nine required clerkships during their third year, each clerkship needs to be offered multiple times at different sites. There are subtle differences in what is taught site to site and course directors are responsible for ensuring that students have exposure to all clerkship objectives regardless of the site. The new application should help deliver the supplemental curriculum needed to provide consistency at each site. Example: The Medicine 110 Clerkship Director knows what the challenges are at each site, without having to gather a lot of data. We have an extensive evaluation system that gathers these data. What the Clerkship Director would like is a way to balance the learning across the sites. Lets say there was a Site attribute called, ―Strengths‖ and one called ―Challenges‖: Strengths: Medicine 110 at SF VAMC offers a great o pportunity for learners to see xxxx‖ Challenges: Medicine 110 at SF VAMC offers few opportunities to see xxx‖ then the course director could assign supplemental cases or exercises so that VA students are offered the things they are likely to miss. Students would appreciate this because currently there is a hidden curriculum or culture of the pros and cons of learning at each site. Clerkship director would like it because it gives them a formal way of balancing the learning across sites. This would further assist the school with accreditation requirements. The course administrator needs to manage the schedule for each occurrence of the course during the year, keeping track of which learners attended which course, which instructors delivered the didactic mat erial, which faculty member led the rotations, etc. After a clerkship rotation is completed, learners and faculty are required to fill out evaluations on the curriculum content, their experiences, and each other. Using the schedules, the course administra tors need to create a list of learners and instructors who met and send this list to the evaluations system administrator. The application should be able to provide a report like this directly from the schedules which can be exported as XML files and/or sent directly to the evaluations system. If there is a change to the schedule the course administrators have to send an email to the learners and faculty, the new system will automatically allow users to pick up these change via RSS feeds. Scenario #3 Actor: Student Curriculum: All Currently learners use an array of systems to view and understand their curriculum and schedules across their four or five year curriculum. It is very difficult for students to know  Where they need to be at a certain date or time? (sometimes need to sieve through emails)  What should I be learning there?  What assignments are due?  Where can I discuss content from my last lab or session? 34  Where do I get access to the most recent, relevant or related learning materials? Currently students need to access all the above information using the following applications.  Ilios – This is where all essential core students would log in to view their schedules and understand their learning objectives and its related curriculum.  iROCKET/WebCT – iROCKET is the name of the School of Medicine's new digital curriculum. All Essential Core and Clinical Core courses will have iROCKET components. Students have online discussion groups based on their small groups sessions. It would make sense to have these discussions linked to where the content is stored.  Informational pages within the UCSF SOM web portal.  Email: For schedule changes (location, date etc) learners are sent emails and need to keep track of their schedules themselves. It will be easier if the learner can go to one place and view an updated schedule there.  Personal calendaring systems 35 9 Exhibit 3: System Requirements and Application Functionality Checklist for Bidders Bidder: Please don't list answers here. This document is provided solely for your use to ensure you've responded to all the RFP questions/statements that need answering/illustration. Web-based Curriculum Management System Specifications & Requirements 1. Application Functionality—Managing Curriculum Content for a Program/Course/Sessions (Note: Manage denotes add/modify/delete) 1.1 Add new objects (i.e. program or course or session), providing descriptive information about them. These objects can exist independent of each other, so that programs maybe shared across site, courses may be shared across programs, and sessions maybe shared across courses. 1.2 Add customizable attributes to objects such as ‗disciplines‘, ‗Themes‘, ‗Hot Topics‘ etc. to draw attention to object in the presentation layer. 1.3 Manage objectives to objects and link those to predefined competencies and assessment methods for that program/course or session. 1.4 Manage MeSH terms and Hot topics (MeSH terms will be selected form a master list) so that they may be linked to objects. 1.5 Manage disciplines – selected from a predefine master list of disciplines program, course or session 1.6 Manage Learning Materials (also known as assets, the same learning material can be used by multiple objects (programs, courses, and sessions). Upload the Learning material once, but assign it to many places. (See Learning Materials Management requirements) 1.7 Manage groups of learners and instructors and assign them to programs, courses and sessions. (Please see section 3 on group management) 1.8 Manage any of the content mentioned above even after the program, course or session has been published. If one copy of content is stored and modified the changes will reflect in all programs, course or sessions 1.9 Ability to copy object (Program, course, sessions) details from one week to the next, then assign different learning materials to that object i.e. the time, location, instructor and groups remain the same but related assets are different 36 1.10 Easily navigate to most recent content being edited 1.11 Easily navigate to unpublished content 1.12 Easily Publish unpublished content 2. Application Functionality— Managing Curriculum Schedules (offerings) 2.1 Capture and view individual learner, program and course schedules 2.2 Easily modify the date and time of a course or program schedule using a drag & drop feature within the calendar 2.3 Allow content to exist independently of a schedule.(I.e. the content is required learning but it is not linked to a specific time & place but rather must be carried out over an elapsed time) 2.4 User Configure how many sessions may be offered simultaneously for the same course or program. Multiple sessions (up to a maximum number) maybe offered simultaneously for different groups at the same time, all visible on the one calendar (currently the calendar only allows 2 session to be visible) 2.5 Ability to choose to view Calendar for a day, week or month 2.6 Ability to view calendar across programs or courses 2.7 Ability to easily access content information from within the schedule 2.8 When the schedule is changed, notify the instructors and learner of the change and provide the ability to download the new schedule via RSS and/or CalDAV into the user‘s favorite web portal, personalized homepage or calendaring application 3. Application Functionality— Group Management 3.1 Automatically create a group for the whole class (i.e. all 141 students for each level (level1, 2, 3, 4) 3.2 Assign the group to a program, course or session 3.3 Assign the same group to multiple sessions across different programs (groups do not need to be unique to the course or program) 3.4 Ability to assign a room number & instructor to a group of learners. When the group is used at multiple sessions, ability to edit the room number and instructor just for that session 3.5 Ability to assign multiple learners to a group.(i.e. a group of learners) or assign multiple instructors (i.e. an instructor group) 37 3.6 Divide groups into designations and assign room numbers to group designations. 3.7 perform a random assignment which automatically assigns learners to groups or enable users to manually assign learners to groups 3.8 Once a group has been used, be able to edit the group assignment and designations. The old group assignment will remain in place for any offerings which occurred before the date of the group change.(i.e. the user historic calendar will show schedules linked the original grouping and the future schedule will reflect the schedules for the new grouping) 3.9 Allow learners to assign themselves to editable groups, and to view their group assignments (see learner dashboard). 3.10 Groups may be copied and, if the Group is for the same graduating class, the copy may include the learner designation 3.11 Group Management to support three methods of enrollment: 1) Integrated Enrollment where the Program or course enrollment is provided by another system, 2) Batch Enrollment where a user enrolls learners in a course, and 3) Self Enrollment where learner can register for certain courses online. 3.10 Ability for course directors/administrators to upload learner group assignments from a spreadsheet. 4. Application Functionality—Learning Materials Management 4.1 Ability to upload new or assigned existing learning materials to multiple sessions simultaneously. 4.2 Support rich media source formats (for view & upload) for linking videos as learning materials to sessions, courses and programs to learning materials e.g.  Active Streaming Format (.asf)  AVI video (.avi)  DV Stream (.dv)  QuickTime Movie (.mov)  MPEG-4 Movie (.mp4)  MPEG Movie (.mpg, .mpeg)  Windows Media Video (.wmv)  Flash Video (flv., fla.) 4.3 Provide course directors/ administrators the ability to associate learning material to a group or an individual. 4.4 Provide course directors/administrators ability to define dates for releasing content to learners. 4.5. Provide users with the ability to rate, tag & comment on learning materials. 4.6 Provide users with views of learning material usage data. 4.7 The ability to receive updates on learning materials additions on the day they were added 38 via mobile dashboard 4.8 The ability to share learning materials across elements such as Courses, programs and sessions. 4.9 The ability to mark the learning material as ‗recommended‘,‘required‘ or ‗supplemental reading‘ when linked to a program, course or session. 5. Application Functionality—Email Notifications & Reminders 5.1 Ability for course directors to set up user configurable email notification and reminders to instructors, by attaching email templates and modifying text for notifications and selecting the frequency of the reminders and by defining conditions when notifications and reminders should be sent. For example, when an instructor has been assigned to a course offering or when the instructor needs to upload their learning materials, or when the room number has changed. 5.2 The ability for users to set up user configurable email notification and reminders for themselves to receive updates on learning materials , schedule changes, room changes and content additions/modifications via RSS feeds into the user‘s favorite web portal, personalized homepage or calendaring application 6. Application Functionality— Instructors’ Dashboard 6.1 Provide a user-friendly interface that allows instructors to view and upload their curriculum content & schedules. 6.2 Allow instructors to customize their dashboards to view unpublished content, unassigned group designations, recently accessed learning materials etc. 6.4 Notice board with broadcast messages, for example, if there has been an instructor substitution. 6.5 Ability to communicate with other instructors (both within your course and external). 6.6. Assign sessions to certain instructors for review. 6.7 Allow instructors to see their group assignments. 6.8 Ability to upload documents (i.e. presentations, required learning materials). 6.9 Provide a mobile web version of the instructors personalized dashboard 7. Application Functionality— Learners’ Dashboard 7.1 Allow learners to assign themselves to editable groups and to view their group assignments (see group management). 7.2 Allow users to customize their dashboards to view assessed learning materials (based on permissions), view schedules as daily, monthly or weekly, Identify related articles by 39 taxonomy, author, user, or other metadata. 7.3 Ability to upload files (see system requirements). 7.4 Ability to add user-posted comments to content/materials with editorial review and workflow similar to blog comments. 7.5 Ability for learners to keep notes or attach documents to a piece of curriculum. 7.6 Ability to rate a learning material, a session, a course a program. 7.7 Provide a mobile web version of the Learners personalized dashboard 8. Application Functionality— Course Rollover 8.1 Ability to copy all or a subset of user security settings, sessions, and learning materials for the course or program. Rolled over course content will be marked as ‗unpublished‘ until it has been reviewed. 8.2 Preserve the day of the week for sessions. A version-history must be maintained for everything that is copied which allows users to track the creation and modification of objects and also allows administrators to rollback a rollover if there are issues. 8.3 User Configurable interface to allow course administrator to choose which parts of the program/course or session need to be rolled over, and to indicate if the day of the week should be preserved for the sessions, or if the date (day of the month) should be the master data point. This should also provide the ability to choose if all groups attached to the course or program should be rolled over. 9. Application Functionality—General Administration 9.1 Manage Reference tables such as Rooms Academic Years Current Yr, default Yr # of MeSH terms Admin email Manage Users and User Roles & Permissions Create/Edit Programs, Courses and sessions Manage Course Rollover & Archive Manage CurrMIT Export & other XML feeds (see interfaces) Manage system email notifications & reminders (see email notifications and reminders) 9.2 9.3 9.4 9.5 9.6 10. Application Functionality—Reporting 40 10.1 Ability to search using a free text field where users can enter keywords and set the search parameters which may search across all content & learning materials which contains ‗any‘, ‗all‘ or the ‘exact phrase‘. 10.2 Ability to perform an advanced search based on MeSH terms, objectives, competencies or disciplines. 10.3 Provide a roadmap of curriculum across all years by obtaining a longitudinal view from a cross section of levels for the current academic year. 10.4 Ability to extract the teaching hrs efforts by departments or by instructor (taken from the schedule). 10.5 Ability to provide a list of predefined reports such as ‗Program or course evaluation roster‘, ‗Program or Course Instructor Roster‘, ‗List of Group assignments for a course or group or session‘. 10.9 The ability to save search criteria. 11. Interfaces 11.1 Export scheduling data from the application to whatever scheduling system is in use via XML feeds or APIs... (data will be manually imported into the evaluations system) 11.2 Export evaluations data such as instructor name, location and session to the different evaluations systems via XML feeds or APIs. (data will be manually imported into the evaluations system) 11.3 Export XML files containing curricular information about courses and upload these directly to the CurrMIT database. 11.4 Import enrollment data from the student enrollment system (e.g. ISIS). 11.5 Import scheduling data from the clerkship scheduling system (SSIS). 11.6 CalDAV (iCal) 11.7 Syndicate learning materials to HEAL. 11.8 RSS feeds and Library podcasting tool. 12. Software, Hardware, Operating Systems, and Security 12.1 The new solution must include the migration of all legacy data from the old database and file system. In addition, provide the ability to upload data from spreadsheets if required. 12.2 System will be built in conformance with several sets of standards for the indexing of medical curriculum information, subject information, and Web-based multimedia learning materials such as MeSH, Heal/LOM/Dublin, CurrMIT as explained in RFP Exhibit 1. 12.5 A minimum of two environments would be preferred – one for production, and one for testing/training. 12.6 Spell checking functionality within the system would be preferred. 41 12.7 System must be web-based for cross platform compatibility on both Macs & PC‘s supporting Firefox 2+, IE 6+, Safari 2+ 12.8 Must have multiple levels of security that meet campus requirements and the ability to manage access locally. 12.9 Ability to add custom tables to database. 12.10 Users will be able to access and enter data via the web and PDAs. Application should support Blackberry browser, Safari on iPhone, IE on Windows Mobile 5/6. 12.11 Support binary file upload (images, mp3, Windows Media, and other formats). 13. Implementation and Training Services, and Database Maintenance 13.1 Project Plan - Provide a summary of the implementation plan and training schedule for UCSF, including milestone events. Your plan should incorporate sign offs for detailed requirements, wireframes, detailed design, quality assurance and delivery. If you plan to do this in multiple releases we would prefer to be part of incremental releases to provide adequate feedback. If the project plan includes hosting the solution, please provide information about your hosting services and how you would also support or external customers. 13.2 Hardware and Software Planning. Provide the SOM with specifications and planning support necessary for the software applications both within the SOM and for external clients. 13.3 The system's database server and the system's interface server must be accessible to remotely located client, or thin client, workstations located on LANs, over a TCP/IP WAN network. 13.4 Database Implementation. Build customized database, build unidirectional transfer of required fields, and test the completed database. This includes configuration of database and definition of security levels of program administrators, faculty, and learners. 13.5 The vendor must, after the training of the SOM staff, assist with loading data into the system. 13.6 Documentation, including all technical, software, database and end-user documentation. 13.7 Support & Upgrade options for SOM. The vendor must provide a detailed description of their software support program for SOM to include what is covered, hours and days of coverage, response time to problems, hotline number, and whether both updates and upgrades are provided. 13.8 Support & Upgrade options for Existing Clients. The vendor must provide a detailed description of their software support & upgrade programs and release options for existing clients, to include what is covered, hours and days of coverage, response time to problems, and whether both updates and upgrades are provided. 13.9 Support & upgrade options for new clients. The vendor must provide a detailed description 42 of their software support program and release options for new clients, to include what is covered, hours and days of coverage, response time to problems and whether both updates and upgrades are provided. 13.10 Must provide 99% uptime. 43 10 Exhibit 4: Application Software Development, Training & Installation Costs Worksheet Part A One time Costs Use the table below to itemize the cost as well as person-days for each section. For detailed descriptions for each area see Exhibit 1: Systems Requirements & Application Functionality and Exhibit 3: Systems Specifications & Requirements Checklist for Bidders. Where appropriate please provide estimates in both person days and dollar amounts. Requirement Analysis Person Cost Days $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Design Person Days Cost $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Construction/QA and Release Person Cost Days $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Description Managing Curriculum Content for a Programs, Courses and Sessions Managing Curriculum Schedules (offerings) Group Management Learning Materials Management Email Notifications & Reminders Instructors Dashboard Learners Dashboard Course Rollover General Administration Reporting Interfaces Security Database Maintenance Training Costs Other one time costs (please describe) Total Part B Optional One time Costs Use the table below to itemize the costs of any applicable services and fees. For each service or fee please provide a detailed rationale and description, including any human resources (time and salary) used. Where appropriate please provide estimates in both person days and dollar amounts. Optional Services & Fees Description Maintenance fees Additional third-party licenses Travel Equipment and supplies Total Requirement Analysis Person Cost Days $ $ $ $ $ Design Person Days Cost $ $ $ $ $ Construction/QA and Release Person Cost Days $ $ $ $ $ 44 Part C Ongoing or Recurring Costs (if applicable): Use the table below to itemize the costs of any ongoing or recurring applicable services and fees. For each service or fee please provide a detailed rationale and description, including any human resources (time and salary) used. Where appropriate please provide estimates in both person days and dollar amounts. If Bidder proposes hosting or providing upgrades or enhancements, please provide a narrative description of release schedule philosophy (temporary bug fixes, spacing of maintenance and functional upgrade releases; a description of the manner in which UCSF‘s functional requirements are incorporated into the development calendar and release schedule; and whether the Bidder‘s human resource would be housed on UCSF premises. Ongoing/Recurring Services & Fees Description Maintenance fees Hosting fees Additional third-party licenses Technical Support Travel Equipment and supplies Other recurring costs Total Person Days Cost $ $ $ $ $ $ $ $ 45