The Regents of the University of California_.doc by yan198555

VIEWS: 92 PAGES: 50

									  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      INTRODUCTION ....................................................................................................... 1

1.1        Project Purpose ................................................................................................................................................1

1.2        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      EVALUATION FACTORS& BASIS AWARD ......................................................... 17

4.1       Evaluation Criteria ........................................................................................................................................ 17

4.2       Evaluation Procedure .................................................................................................................................... 17

4.3       References/Reference Checks ....................................................................................................................... 18


5      SUBMITTAL REQUEST ......................................................................................... 21

5.1       Letter of Transmittal ..................................................................................................................................... 21

5.2       Proposal .......................................................................................................................................................... 21

5.3    ADDITIONAL REQUIRED VENDOR INFORMATION ........................................................................ 21
  5.3.1   GENERAL VENDOR INFORMATION ................................................................................................ 21
  5.3.2   VENDOR FINANCIALS ........................................................................................................................ 22


6      ATTACHMENTS: .................................................................................................... 24

7      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      INTRODUCTION

1.1      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
    WebCT is the Learning Content Management system used at UCSF http://www.webct.com/
2
    CurrMIT (Curriculum Management Information Tool) http://www.aamc.org/meded/curric/start.htm

                                                                                                                      1
Key success criteria are:

      1.    The new solution should be written in a modern language (.NET, Java/J2EE, PHP) and should be a scalable,
            flexible, and highly-available system.
      2.    The solution must allow rapid integration of new components in the future and the ability to replace or
            upgrade existing components as required.
      3.    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.
      4.    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.
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 one-
hour 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       GENERAL REQUIREMENTS, TERMS & CONDITIONS

2.1     Contract Period

2.1.1    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     Price

2.3.1    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     INVOICING

2.4.1    Payment Terms

Invoice(s) will be paid within Net 30 days.

2.5     SCOPE OF WORK

2.5.1    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     GENERAL CONDITIONS

2.6.1    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       INSTRUCTIONS TO BIDDERS

3.1     Quotation Due Date and Time.

3.1.1    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.   Equipment, supplies, or services directly or indirectly related to patient care.

         4.    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     EVALUATION FACTORS& BASIS AWARD

4.1    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.   Supplier must be able to offer an online curriculum management tool.
             b.   System must meet the application functionality and specifications outlined in Section 2 General
                  Requirements above and details set forth in Exhibits 1 and 3.
             c.   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.
             d.   The respondent must be in possession of all applicable licenses.
             e.   The respondent must provide all other documents specified herein.
             f.   The respondent must be able to provide required verification of insurance coverage.
             g.   Documented evidence of ability to perform the tasks as herein described


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.
      2.    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.
      3.    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
      4.    Responses meeting the General Requirements will progress to the next step at this evaluation. The
            University may contact vendor for clarification of the response.

      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.    Each bidder‘s proposal will be used to determine the total cost of the service.
     2.    Each bidder‘s response will be rated using a score sheet– Quality Point Score Sheet.
     3.    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                   Quality Pts               Final
                                                                Awarded                  CPQP

           Vendor # 1              $ 56,725.00                   525                    108.04
           Vendor # 2              $ 63,659.00                   600                    106.09
           Vendor # 3              $ 50,125.00                   325                    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.

E2              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.

E3              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.

The references you furnish shall be asked to rate your performance either:


                                                                                                                       18
    EXCELLENT:              Frequently exceeds standard requirements.

     GOOD:              Meets standard requirements.

     POOR:              Frequently does not meet standard requirements.

The areas of performance to be rated are:

    1.       Meeting defined timelines and costs for deliverables.
    2.       Quality and professional level of assigned staff to the project.
    3.       Technical expertise of staff and ability to deliver service as specified.
    4.       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        ADDITIONAL REQUIRED VENDOR INFORMATION
5.3.1       GENERAL VENDOR INFORMATION
     a.     Full legal company name


                                                                                                                     21
    b.   Year company founded
    c.   Brief company history
    d.   Has it changed ownership(s) in the past? If so, when?
    e.   Does another company own you?
    f.   What other companies are you affiliated with?
    g.   Current number of employees
    h.   Average tenure of employees
    i.   Is your company currently involved in any litigation that may result in a material change in the company?
    j.   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.

2.   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.



                                                                                                                        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 industry-
standard 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              Qty
   Functions              16
   Stored Procedures      367
   Tables                 121
   Triggers               19
   Views                  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                  Version 3    Version 5
   Functions                  5            16
   Stored Procedures          204          367
   Tables                     95           121
   Triggers                   9            19
   Views                      64           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             ISIS
                                       Email
  Client Tier




                                                                                                                                                                                                  AAMC
                                                                                                     Clent                                                  WebCT                                                                  NIH-NLM
                                                                                                                                               HTTP                                              CurrMIT
                                                                                                    Browser                                                 Website                                                                Website
                                                                                                                                                                                                 Website
                                         SMTP




                                                                                                                                                                                                              Upload XML




                                                                                                                                                                                                                                      Download
                                                                                                                   HTTP (S)




                                                                                                                                                              HTTP
                                       Exchange
                                                          Two Way Data Feed




                                       2000                                                        Web Server
                                                                                                                                                                       IIS 6
  Application Tier




                                                                              Application Server




                                                                                                     HTML                        JavaScript       ASP       ASP.NET                    SQL-XML   SAX XML Reader                   SOAP SDK
                       Mail Server




                                                                                                                                               ASP Upload             ADO.NET                                      ADO
                                                                                                     SQLXMLOLEDB




                                                                                                                                    SQLOLEDB




                                                                                                                                                                                                  File Copy
                                                SMTP




                                                                                                                                                                                                                           HTTP



                                       SQL Server 2005
                                          Send
                                                                                                   Stored Procedures
  Data Tier




                                          Mail
                     Database Server




                                                                                                                                                                         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



                                                                                                                                                                                                                                                 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.

    1.  Course content and related sessions are rolled over by the application from the previous year
    2.  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


                                                                                                                        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

9.2       Manage Users and User Roles & Permissions

9.3       Create/Edit Programs, Courses and sessions

9.4       Manage Course Rollover & Archive

9.5       Manage CurrMIT Export & other XML feeds (see interfaces)

9.6      Manage system email notifications & reminders (see email notifications and reminders)

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             Design                  Construction/QA
                                               Analysis                                        and Release
   Description                                 Person Cost             Person     Cost         Person      Cost
                                               Days                    Days                    Days
   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                    Requirement             Design                  Construction/QA
                                               Analysis                                        and Release
   Description                                 Person Cost             Person     Cost         Person      Cost
                                               Days                    Days                    Days
   Maintenance fees                                     $                         $                        $
   Additional third-party licenses                      $                         $                        $
   Travel                                               $                         $                        $
   Equipment and supplies                               $                         $                        $

   Total                                                  $                       $                          $

                                                                                                                       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                                Person     Cost
                                              Days
   Maintenance fees                                      $
   Hosting fees                                          $
   Additional third-party licenses                       $
   Technical Support                                     $
   Travel                                                $
   Equipment and supplies                                $

   Other recurring costs                                 $
   Total                                                 $




                                                                                                                   45

								
To top